Pre-flight checks
OpenCode version reviewed: 1.18.29
Problem statement
OpenCode Quota solves a problem anyone on an AI coding plan knows: quota and token spend are opaque until you hit a limit mid-session. It surfaces them in OpenCode's sidebar, status line, and /tokens_* reports, plus JSON output for scripts and CI, with an explicit zero context-window-pollution design that keeps accounting local and deterministic, which is why it can cover so many plans and gateways cleanly.
Provider choice is already first-class here: the README tables span personal and business plans across American and Chinese vendors, OpenRouter included. Users who route OpenCode models through OrcaRouter to reach many models with one key have no matching provider entry today, so that usage stays invisible beside providers that do report budget and spend. An optional OrcaRouter provider would close that gap.
Proposed change
Add OrcaRouter as an optional provider for OpenCode Quota, without replacing or altering any existing provider. OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so the natural fit follows this repo's existing abstraction: a provider entry whose providerId matches the OpenCode-side endpoint, reporting through the same remote-API or local-estimate machinery used by custom providers and by built-ins such as OpenRouter. No code is written or tested yet; this issue-first proposal is to gauge maintainer interest.
Capabilities most relevant to OpenCode Quota users:
- Multiple chat, reasoning, image, and video models through one OpenAI-compatible endpoint and a single API key.
- Automatic model routing and provider failover, so a degraded upstream does not stall a session.
- Usage tracking and budgets, matching this repo's quota and spend reporting model.
- Team access controls, for the Business/Team audiences already listed in the README.
OrcaRouter is already used across open-source tools such as promptfoo, goose, and Dify, so the pattern should fit an OpenCode-adjacent project.
Alternatives considered
A user can already add an OrcaRouter definition through the custom provider add path, and the CONTRIBUTING.md built-in-provider policy expects a models.dev listing plus independent demand. I am happy to follow whichever route maintainers prefer, from a documented custom-provider recipe to a built-in row if it qualifies.
Acceptance criteria
- Maintainer confirmation that OrcaRouter support is welcome and which route fits.
- A provider entry or documented recipe so OrcaRouter users see usage and spend in OpenCode Quota.
- README setup label and tests consistent with provider conventions.
Transparency note: OrcaRouter runs an optional open-source partner program where approved OSS projects can receive a 5% revenue share from usage attributed to their integration. Participation is not a precondition, and I will follow any disclosure or governance rules this project requires. Existing integrations are at https://www.orcarouter.ai/built-with. I'm an engineer on the OrcaRouter team and, with your go-ahead, I am glad to submit an implementation PR meeting this repo's quality gates.
Pre-flight checks
OpenCode version reviewed: 1.18.29
Problem statement
OpenCode Quota solves a problem anyone on an AI coding plan knows: quota and token spend are opaque until you hit a limit mid-session. It surfaces them in OpenCode's sidebar, status line, and
/tokens_*reports, plus JSON output for scripts and CI, with an explicit zero context-window-pollution design that keeps accounting local and deterministic, which is why it can cover so many plans and gateways cleanly.Provider choice is already first-class here: the README tables span personal and business plans across American and Chinese vendors, OpenRouter included. Users who route OpenCode models through OrcaRouter to reach many models with one key have no matching provider entry today, so that usage stays invisible beside providers that do report budget and spend. An optional OrcaRouter provider would close that gap.
Proposed change
Add OrcaRouter as an optional provider for OpenCode Quota, without replacing or altering any existing provider. OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so the natural fit follows this repo's existing abstraction: a provider entry whose
providerIdmatches the OpenCode-side endpoint, reporting through the same remote-API or local-estimate machinery used by custom providers and by built-ins such as OpenRouter. No code is written or tested yet; this issue-first proposal is to gauge maintainer interest.Capabilities most relevant to OpenCode Quota users:
OrcaRouter is already used across open-source tools such as promptfoo, goose, and Dify, so the pattern should fit an OpenCode-adjacent project.
Alternatives considered
A user can already add an OrcaRouter definition through the custom
provider addpath, and the CONTRIBUTING.md built-in-provider policy expects a models.dev listing plus independent demand. I am happy to follow whichever route maintainers prefer, from a documented custom-provider recipe to a built-in row if it qualifies.Acceptance criteria
Transparency note: OrcaRouter runs an optional open-source partner program where approved OSS projects can receive a 5% revenue share from usage attributed to their integration. Participation is not a precondition, and I will follow any disclosure or governance rules this project requires. Existing integrations are at https://www.orcarouter.ai/built-with. I'm an engineer on the OrcaRouter team and, with your go-ahead, I am glad to submit an implementation PR meeting this repo's quality gates.