v2: config-declared custom-provider models silently become 0 in catalog when models.opencode.ai fetch fails at boot (provider survives, resolution-by-ID still works) #41360

Activity

1. github-actions

   assigned

   rekram1-node

   on Aug 9, 2026
2. opencode-agent

   added

   2.0

   on Aug 9, 2026
3. benjaminfrombe commented on Sep 17, 2026

   

   benjaminfrombe

   on Sep 17, 2026

   More actions

   I think a good part of what is reported here is a startup race rather than a config parsing problem: serve starts answering requests before the catalog is hydrated, so what you get back depends entirely on how soon after startup you ask.

   Repro on 2.0.6 (macOS arm64), with six providers declared in ~/.config/opencode/opencode.jsonc:

   OPENCODE_SERVER_PASSWORD=test opencode serve --port 19060 --hostname 127.0.0.1 &
   START=$(date +%s.%N)
   for i in $(seq 1 8); do
     T=$(echo "$(date +%s.%N) - $START" | bc | cut -c1-4)
     P=$(curl -s -u opencode:test localhost:19060/api/provider | jq '.data | length')
     M=$(curl -s -u opencode:test localhost:19060/api/model    | jq '.data | length')
     echo "t+${T}s providers=$P models=$M"
     sleep 1
   done

   t+0.03s  (connection refused)
   t+1.25s  providers=0  models=70
   t+2.53s  providers=6  models=138
   t+3.64s  providers=6  models=138
      ... stable from here on
   

   Two things stand out:

   1. The window is real but short. Before roughly 2.5s the catalog is empty or partial; after that it is complete and stays that way. Nothing about the config changes in between, so a client that asks once at the wrong moment concludes the providers do not exist.

   2. The endpoints disagree during that window. At t+1.25s /api/provider returns zero entries while /api/model already returns 70. Anything that guards on "no providers, so bail out" gives up even though the model list is populated.

   There is also a staged fill: the built-in provider lands about a second before the ones declared in config, so an early read can produce a catalog that looks valid but silently omits every user-declared provider. That is the failure mode I would worry about most, because it does not raise an error anywhere.

   The CLI is not affected, which I think is why this looks like an API-only bug: opencode models resolves through Provider.Service.list() in-process and waits for hydration, while the HTTP handler reads Catalog.Service state as it stands at request time.

   For anyone hitting this from a client: the server listening on ... line and /api/info both become available before the catalog does, so neither is usable as a readiness signal today. Polling until the contents stop changing works, but an explicit signal (or having the list endpoints await hydration) would obviously be nicer.

   Happy to test a patch against this setup if that helps.