Skip to content

serve: GET /api/model omits auth.json providers #42737

Closed

Description

@Newarr

serve: GET /api/model omits auth.json providers

Problem

GET /api/model on opencode serve leaves out every provider whose credentials live in ~/.local/share/opencode/auth.json. The CLI lists them. The server will even start sessions with them. They just never appear in the list.

Context

I hit this through T3 Code, which spawns opencode serve and builds its model picker from the API. My config default is zai-coding-plan/glm-5.3. It works fine in the TUI. Inside T3 the model is absent from the picker, so it looks like the provider vanished.

Any client that spawns a server and lists models over the API will hit this.

Reproduction

opencode 1.18.18, macOS.

  1. opencode auth login for a provider (zai-coding-plan here). Check opencode models | grep zai-coding-plan: the models appear.
  2. opencode serve --hostname 127.0.0.1 --port 4100
  3. List models:
curl -s -H "x-opencode-directory: $HOME" http://127.0.0.1:4100/api/model \
  | jq -r '.data[].providerID' | sort -u

I get 9 providers: openrouter, google, openai, xai, cerebras, cloudflare-ai-gateway, cloudflare-workers-ai, sakana, opencode. All keyed by env vars or catalog entries. No zai-coding-plan, no opencode-go, no kimi-for-coding, no fireworks-ai. All four of those are type: api entries in auth.json.

  1. Now ask the same server for a session with the "missing" model:
curl -s -X POST -H "x-opencode-directory: $HOME" -H 'content-type: application/json' \
  -d '{"providerID":"zai-coding-plan","modelID":"glm-5.3","title":"probe"}' \
  http://127.0.0.1:4100/api/session

Returns a session ID. Streaming with that model works too.

Two side notes. The x-opencode-directory header is required, otherwise data comes back empty and will waste your repro time. Setting OPENCODE_SERVER_PASSWORD does not change the outcome.

Expected behavior

The list includes models from authenticated providers. If leaving them out is intentional, the endpoint docs should say it lists only config and env-keyed providers.

Notes

I have not traced the handler. My guess: the v2 list builds from catalog, config and env credentials and never reads the auth store. The session path clearly does.

Activity

  1. benjaminfrombe commented on Sep 17, 2026

    @benjaminfrombe

    Possibly related, depending on how you queried: on 2.0.6 the catalog hydrates a couple of seconds after serve starts accepting connections, and during that window /api/model and /api/provider return empty or partial results while the CLI is already correct. Measurements and a repro script are in #41360.

    That would explain the CLI/API split described here without the auth store being ignored, but only if your requests happened early in the process lifetime. If you saw the API stay incomplete for minutes on a long-running server, then it is a different problem and this is noise, apologies.

    One detail that might help you tell the two apart: during the hydration window the providers declared in config land about a second after the built-in one, so an early read returns a catalog that is populated but missing exactly the providers you configured yourself.

  2. neriousy commented on Oct 20, 2026

    @neriousy
    Member

    Thanks for the detailed zai-coding-plan /api/model reproduction. In v2, legacy auth.json credentials are imported into the credential store, provider availability includes those stored connections, and the model-list endpoint waits for plugins to finish activating before returning. V1 now only receives critical fixes; please update with npm i -g @opencode/cli@latest. If authenticated providers are still missing on current v2, please open a new issue with the v2 version and a redacted API response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions