[opencode-local] `opencode models` returned no models…

Error message

[opencode-local] `opencode models` returned no models; proceeding with the configured model "${model}".

What it means

The local availability probe ran `opencode models` successfully (no exception) but parsing produced zero models — e.g. a transient provider-auth blip. Following the same best-effort policy, the adapter warns and returns a fallback single-model list; the run proceeds and only a genuinely unavailable model fails later, at invocation time.

Solutions

Run `opencode models` on the same machine and env; confirm your model id appears.
Re-authenticate the provider (`opencode auth login` or refresh the API key env var).
If the list looks non-empty but the warn still fires, check for an `opencode` CLI version mismatch and pin a compatible one.
Confirm the configured model id string exactly matches a listed entry.

Defensive patterns

Strategy: validation

Validate before calling

const { stdout } = await exec('opencode', ['models']);
const listed = stdout.split('\n').map((s) => s.trim()).filter(Boolean);
if (!listed.includes(configuredModel)) {
  throw new Error(`Model ${configuredModel} not listed by opencode models; run opencode auth login`);
}

Prevention

Run `opencode models` in server bootstrap smoke tests and assert the configured model id appears.
Automate provider credential refresh before expiry.
Pin the opencode CLI version in deployment images.
Alert on this warn: it usually precedes a hard model-unavailable error on the next real run.

When it happens

Trigger: `opencode models` exits 0 but stdout parses to an empty list: no authenticated providers locally, expired credentials, provider API returning an empty catalog, or a CLI output-format change that defeats the parser.

Common situations: Fresh install without `opencode auth login`; expired or rotated provider API keys; custom provider misconfiguration; opencode CLI major upgrade changing the models output shape.

Related errors

AI-assisted analysis of paperclipai/paperclip@01ad858492 (2026-08-18). Data as JSON: /api/errors/38903bd71158cecc. Report an issue: GitHub.

Appendix: source

Thrown at packages/adapters/opencode-local/src/server/models.ts:314

  } catch (err) {
    // The availability probe is a best-effort pre-flight guard, not a gate. If
    // `opencode models` itself cannot run — a transient CLI error, a timeout, a
    // provider hiccup — do NOT abort the run. The real invocation is
    // authoritative, so a probe that can't execute must never be fatal.
    // (Previously this threw and crashed runs mid-flight, discarding the agent's
    // completed work and its terminal disposition, which then reopened the issue.)
    console.warn(
      `[opencode-local] Model availability probe could not run for "${model}" (${
        err instanceof Error ? err.message : String(err)
      }); proceeding with the configured model.`,
    );
    return [{ id: model, label: model }];
  }

  if (models.length === 0) {
    // The probe ran but returned nothing (e.g. a transient provider-auth blip).
    // Same reasoning as above: warn, don't block the run.
    console.warn(
      `[opencode-local] \`opencode models\` returned no models; proceeding with the configured model "${model}".`,
    );
    return [{ id: model, label: model }];
  }

  if (!models.some((entry) => entry.id === model)) {
    // `opencode models` reads a persistent models.dev cache. Long-lived runner
    // hosts can therefore report a stale non-empty catalog even while the
    // configured provider serves the model. Refresh once before treating a
    // cached miss as authoritative; a successful refresh that still omits the
    // model retains the strict availability rejection below.
    try {
      const refreshedModels = await refreshOpenCodeModelsCached({
        command: input.command,
        cwd: input.cwd,
        env: input.env,
      });
      if (refreshedModels.some((entry) => entry.id === model)) {

View on GitHub (pinned to 01ad858492)