How to use Lyceum models in goose

How to connect goose to an OpenAI-compatible API

To use a Lyceum model in goose, set GOOSE_PROVIDER to openai and GOOSE_MODEL to a Lyceum model id such as z-ai/glm-5.2 in ~/.config/goose/config.yaml, split the base URL shown in your Lyceum dashboard into OPENAI_HOST (scheme and host) and OPENAI_BASE_PATH (the full path including /chat/completions), and export your Lyceum API key as OPENAI_API_KEY before you start goose session. Everything else in this guide is detail around those three moves.

goose is an open source terminal agent that started at Block and now lives with the Agentic AI Foundation at the Linux Foundation. It runs shell commands and edits files through its built-in developer extension, and its openai provider reaches any endpoint compatible with the OpenAI API. That makes goose one of the coding assistants you can point at your own OpenAI-compatible model endpoint. Our serverless inference is one such endpoint: open models such as GLM and Kimi behind one OpenAI-compatible API, billed per token with no base fee.

Four steps take you from a clean machine to a first goose task on a Lyceum model:

1. Install the goose CLI without the setup wizard, because the wizard accepts no custom model names.
2. Write ~/.config/goose/config.yaml by hand, with the endpoint split into OPENAI_HOST and OPENAI_BASE_PATH.
3. Export the Lyceum API key as OPENAI_API_KEY in the shell that starts goose.
4. Pick a model with tool calling and run a first task in approve mode on a git branch.

How to install the goose CLI without the setup wizard

On macOS or Linux, install the goose CLI from its GitHub releases with CONFIGURE=false, which skips the interactive setup wizard. The wizard accepts no custom model names, and goose's own documentation points you at GOOSE_MODEL in config.yaml instead, so the config is written by hand in the next section.

curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | CONFIGURE=false bash

You need two things before the config step: a Lyceum account, and an API key created in the Lyceum dashboard. With CONFIGURE=false, nothing overwrites the config you are about to write.

How to set OPENAI_HOST and OPENAI_BASE_PATH in goose

goose takes the endpoint as two keys: OPENAI_HOST (scheme and host only, no trailing path) plus OPENAI_BASE_PATH (the full path including /chat/completions). Most OpenAI-compatible tools take one base URL and append the path themselves; our goose setup page notes that every other client on our pages takes one base URL, so do not copy a config from another guide.

Write the config by hand in ~/.config/goose/config.yaml. goose's openai provider takes the endpoint through these two keys, as its provider documentation shows.

GOOSE_PROVIDER: openai
GOOSE_MODE: approve
GOOSE_MODEL: z-ai/glm-5.2
OPENAI_HOST: https://api.lyceum.technology
OPENAI_BASE_PATH: openai/v1/chat/completions

extensions:
  developer:
    enabled: true
    name: developer
    type: builtin

If you switch models later and requests start failing, the cause is usually in one of these lines; our guide on what breaks when you switch models on an OpenAI-compatible API covers the general case.

The developer extension is what gives goose its shell commands and file edits, and goose enables it at install. Keep the extensions block in the hand-written config. If goose cannot touch files in a session, run goose configure and enable it under Toggle Extensions.

Export the Lyceum API key

The key is supplied through the environment, not the config file: export it in the same shell that starts the session.

export OPENAI_API_KEY="your-lyceum-api-key"
goose session

If you prefer not to keep the key in shell profiles, store it in the system keyring through goose configure instead. Either way, the key must be loaded before goose session starts, or the first request fails with a 401.

GLM-5.2 vs Kimi-K2.7-Code for goose tool calls

Both models our goose setup page recommends, moonshotai/kimi-k2.7-code and z-ai/glm-5.2, support tool calling. goose leans on tool calling heavily: every file edit and shell command goes through a tool call, so the model has to handle that loop reliably.

The table shows our list prices, read from our model list with current prices on 9 October 2026. Our serverless inference is billed per token with no base fee, and repeated prompt starts still in GPU memory bill at the cached input price where the model lists one.

GLM-5.2 has a 1M-token context window; Kimi-K2.7-Code has a 256K window and the lower input price, $1.25 per 1M tokens against GLM-5.2's $1.50. As a worked example of our own (uncached input, list prices of 9 October 2026), a goose session that sends 1M input tokens and receives 100K output tokens costs:

We make no benchmark or speed claims here; if you are choosing between open models for agentic edits, our guide on testing open coding models on multi-file edits shows a way to test them on your own repositories. Our dashboard breaks cost and tokens down by model, by member or by API key, so a week of goose sessions gives you a real per-developer cost.

To try the other model without editing config, --model overrides it for a single run:

goose run --model moonshotai/kimi-k2.7-code -t "Summarise the changes on this branch"

How to fix goose 404 and 401 errors on custom endpoints

goose 404 and 401 errors on a custom endpoint almost always trace back to two config mistakes, a wrong OPENAI_BASE_PATH or an unloaded key, and a third issue covers long sessions:

• 404 on every request: OPENAI_BASE_PATH is wrong. The usual causes are the full URL pasted into OPENAI_HOST, or /chat/completions missing from the end of the path. Check the two lines against the yaml block above.
• 401 with "No api key passed in": the key is not loaded. Follow the export step above: OPENAI_API_KEY must be set in the same shell that starts goose.
• Truncated or over-long sessions: goose's context limit defaults to a model-specific value or 128,000 tokens. Set GOOSE_CONTEXT_LIMIT to override it, never above the model's context window.

A 429 means you have hit a rate limit or the model is under load; the answer in the FAQ below covers the retry. If errors persist after these fixes, add --debug to a goose run command: goose's CLI docs say it outputs complete tool responses, detailed parameter values and full file paths.

How to run a first goose task in approve mode

Run the first goose task in approve mode on a new git branch, because goose starts in Autonomous mode by default, where it can modify files, use extensions and delete files without requiring approval. Set GOOSE_MODE: approve in config.yaml, or switch inside a session with /mode approve. Approve mode asks before every write and shell command. smart_approve is the middle setting: it approves low-risk actions automatically and flags the rest. A branch helps review tracked file changes with git diff. It does not contain shell side effects, untracked files or changes outside the repository.

git checkout -b goose-first-run
goose session

For scripts and CI, goose run executes one instruction and exits. The --no-session flag runs the command without creating or storing a session file, which is what you want for automated runs:

goose run --no-session -t "Add a docstring to every function in utils.py"

goose is one of several coding assistants that run on the same Lyceum endpoint. If your team uses others, each has its own Lyceum guide: Cline setup, Cursor setup, Zed setup, Kilo Code, OpenCode setup and Claude Code.

The endpoint behind all of this is our serverless inference: open models through one OpenAI-compatible API, billed per token with no base fee, on GPUs in European data centres. Lyceum is a sovereign European AI inference provider for open-source models: our serverless models run in Paris and Finland. That suits a coding agent like goose, which puts your code into its prompts, because the prompts and outputs we process are not stored and never used for training. Start on serverless inference while traffic varies, then compare a dedicated endpoint if measured utilisation and cost justify it.

Create an API key in the Lyceum dashboard and run goose in approve mode on a branch of your own repository.

• goose needs the endpoint as OPENAI_HOST plus OPENAI_BASE_PATH, not one base URL.
• The Lyceum key goes in the environment as OPENAI_API_KEY, never in config.yaml.
• Use approve mode and inspect each requested command; use a branch to review tracked edits.