Repository navigation
[Feature] Add Command Code (api.commandcode.ai) as a provider — API-key + subscription OAuth flow #909
Copy link
Copy link
Closed
Labels
account-poolOAuth, credentials, Codex pool, quota, failover, plansOAuth, credentials, Codex pool, quota, failover, planscatalogModel catalog, slugs, visibility, routed entriesModel catalog, slugs, visibility, routed entriesenhancementNew feature or requestNew feature or requestproviderProvider adapters, OpenAI-compat presets, upstream API quirksProvider adapters, OpenAI-compat presets, upstream API quirks
Description
What are you trying to accomplish?
I want to use my Command Code Go subscription (or the paid Provider plan) as a provider inside OpenCodex, so Codex CLI/App can route to Command Code's model catalog (DeepSeek, Kimi, GLM, MiniMax, Qwen, Grok, etc.) through the same proxy — alongside the existing providers.
Command Code offers an official Provider API (OpenAI- and Anthropic-compatible) that is currently missing from the provider registry. It is especially valuable because Command Code subscriptions (Go/Pro plans) authenticate the CLI but do not include direct API access; the Provider plan ($15/mo, pay-as-you-go) unlocks the API. OpenCodex is the ideal place to expose it.
What prevents this today?
- The
opencode-goprovider in the registry (opencode.ai/zen/go/v1) is a different product (OpenCode Zen) and requires an API key — it is not the Command Code Provider API. - There is no registry entry for Command Code (
api.commandcode.ai/provider), so users must hand-roll a custom provider (ocx provider add commandcode --adapter openai-chat --base-url http://...) and, for subscriptions, run a local bridge (e.g. thehermes-commandcode-providerproject) to convert the CLI login into an OpenAI-compatible endpoint. - The subscription→API gap forces either a third-party bridge or the paid Provider plan, with no first-class support.
What should OpenCodex do?
- Add a Command Code provider entry to the registry (
id: "commandcode") using theopenai-chatadapter pointed athttps://api.commandcode.ai/provider/v1. - Support API-key auth (
authKind: "key", dashboard URLhttps://commandcode.ai/studio/) for Provider-plan users. - Optionally support an OAuth/CLI-login flow (like
kimi/xai/anthropicOAuth entries) via the CLI auth endpoint the CLI itself uses — so Go/Pro subscription holders can authenticate without a separate API key. Reference implementation: OmniRoute'scommand-codeprovider useshttps://commandcode.ai/studio/auth/clifor the device/OAuth flow. - Seed the model catalog from the public
GET /provider/v1/modelsendpoint, with per-plan filtering (403MODEL_NOT_IN_PLANfor models outside the active plan).
Example usage or interface
# After implementation:
ocx login commandcode # OAuth/CLI flow for subscription holders
# or
ocx provider add commandcode --api-key <CMD_API_KEY> # Provider plan
# Codex then uses any Command Code model:
# codex -m commandcode/deepseek/deepseek-v4-flash
# codex -m commandcode/moonshotai/Kimi-K3Registry entry sketch:
{
id: "commandcode",
label: "Command Code",
adapter: "openai-chat",
baseUrl: "https://api.commandcode.ai/provider/v1",
authKind: "key", // + optional oauthId for CLI-login flow
dashboardUrl: "https://commandcode.ai/studio/",
defaultModel: "deepseek/deepseek-v4-flash",
liveModels: true, // GET /provider/v1/models is public
}Alternatives or workarounds
- Custom provider + local bridge (current workaround): run
hermes-commandcode-provider(bridge on127.0.0.1:8788exposing/v1/chat/completions) and add it as a customopenai-chatprovider withallowPrivateNetwork: true. Works, but adds a third-party daemon and manual model allowlisting. - Provider plan + custom provider:
ocx provider add commandcode --adapter openai-chat --base-url https://api.commandcode.ai/provider/v1 --api-key ...— works today, but no registry entry, no OAuth, no catalog seeding.
Additional context
- Upstream docs: https://commandcode.ai/docs/provider
POST https://api.commandcode.ai/provider/v1/chat/completions(OpenAI Chat Completions)POST https://api.commandcode.ai/provider/v1/messages(Anthropic Messages)GET https://api.commandcode.ai/provider/v1/models(public model list)- Auth:
Authorization: Bearer <CMD_API_KEY>(same key as the CLI) - Errors:
403 upgrade_required(no Provider plan),403 MODEL_NOT_IN_PLAN(model outside plan),401 authentication_error
- Plans: Provider plan starts at $15/mo pay-as-you-go; Go/Pro subscription plans authenticate the CLI but need OAuth/bridge for API use.
- Model naming: upstream ids are namespaced (
deepseek/deepseek-v4-flash,moonshotai/Kimi-K3,zai-org/GLM-5.2), which maps cleanly onto OpenCodex's<provider>/<model>namespace. - Reference: OmniRoute already ships a
commandCodeprovider with OAuth viahttps://commandcode.ai/studio/auth/cli(see itssrc/app/api/providers/command-code/routes) — a good pattern to mirror.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
account-poolOAuth, credentials, Codex pool, quota, failover, plansOAuth, credentials, Codex pool, quota, failover, planscatalogModel catalog, slugs, visibility, routed entriesModel catalog, slugs, visibility, routed entriesenhancementNew feature or requestNew feature or requestproviderProvider adapters, OpenAI-compat presets, upstream API quirksProvider adapters, OpenAI-compat presets, upstream API quirks
Activity
github-actions commentedon Aug 2, 2026
Automated translation bookkeeping — detected language: unknown.
Wibias commentedon Aug 3, 2026
[shipping-github] Opened PR #923 to address this.
Wibias commentedon Aug 3, 2026
Thanks @rrmlima - fixed by PR #923 (
ad4eb58b): Command Code is now a built-in key provider (ocx provider add commandcode) with live discovery of the public/provider/v1/modelscatalog, Bearer auth tohttps://api.commandcode.ai/provider/v1, and honest "unverifiable" key validation since the catalog is public. API-key (Provider plan) support is in; the optional OAuth/CLI-login flow remains a follow-up.