Skip to main content

​
OpenCode provider

This page is the Orbi integration note for Pi’s native OpenCode provider. It is part of the provider series. The facts below were checked on 2026-09-08 with Pi 0.85.1 (pi --version). OpenCode’s catalog and plans are service-controlled and can change; repeat the catalog command before a new deployment.

​
What is authenticated

Pi 0.85.1 treats opencode as an API-key provider, not an OAuth provider. Its provider documentation maps it to OPENCODE_API_KEY and to the opencode key in Pi’s auth.json. The key is an OpenCode Zen/OpenCode account key; it is not an Orbi token and not OPENAI_API_KEY. Choose one of these equivalent setup paths:
  1. Create/copy the key in the OpenCode account, following the official OpenCode Zen documentation.
  2. In an interactive Pi session run /login, choose OpenCode Zen, and paste the API key. Pi stores it in its user auth file (mode 0600). This is an API-key login, not an OAuth browser flow.
  3. Or provide the key to the Orbi service through its gitignored environment file:
    The installed Orbi systemd unit loads .orbi/env. For a manual check, export it in the shell first:
Check readiness without printing the credential:
Pi 0.85.1 returned credentials_not_configured when no key was present. A successful check is evidence that credentials are configured, not evidence that the account has quota. Do not use --credentials in a transcript.

​
Catalog and Orbi configuration

opencode is built into Pi’s catalog. The catalog check used for this page was:
The placeholder only makes Pi display the catalog; it was not used for a request. On 2026-09-08 Pi listed these opencode model IDs (context/output limits are also shown by the command and are intentionally not copied here as quota promises):
The same Pi catalog also exposes a separate opencode-go provider. Do not change pi_provider to it unless the account is an OpenCode Go account; its model IDs and plan are separate. The catalog can be filtered again with pi --list-models opencode after authentication/catalog refresh. For the smallest Orbi setup, select a model ID exactly as Pi printed it:
Do not create .orbi/pi-providers.json for this setup. Pi already owns the provider, endpoint, API type, model metadata, and API-key mapping. Defining a second opencode entry can shadow or stale the native catalog. Use a pi_providers file only for providers that Pi does not natively supply, such as Orbi’s local-qwen or z-ai templates. Before dispatching an Issue, run a real, non-secret smoke request with the selected account and model:

​
Quota, limits, and observed boundary

OpenCode’s Zen page and OpenCode Go page are the authority for current pricing, free models, account plans, rate limits, and reset behavior. These values are not Pi catalog metadata and must not be inferred from contextWindow, maxTokens, or a model name. As of the dated check above, this worktree had no usable OpenCode account:
  • real OpenCode inference request: not tested;
  • quota consumption or remaining allowance: not measured;
  • rate-limit/429 response and reset time: not tested;
  • real Orbi Issue delivery and PR: not tested.
Therefore this page makes no numeric quota or reset claim. A credential error means authentication/configuration is wrong; an upstream quota or rate-limit error is account/service state. Orbi does not silently retry or rotate providers. Preserve the failed run evidence and change the selectors manually.

​
Minimal fallback

To switch after an auth, quota, or limit failure, change only the provider selection and use that provider’s existing setup:
Copy the matching template from templates/pi-providers/, put its key in .orbi/env (local Qwen uses its documented dummy key), and run the provider validation plus one real pi --print request. Switching is manual; it does not repair an invalid OpenCode key or create an automatic fallback.