[Provider] Promote a verified batch of OpenAI-compatible inference providers

[olddonkey]

Area

Provider adapters, provider registry, model discovery, CLI, dashboard, and documentation.

What are you trying to accomplish?

Add a coherent batch of first-class OpenAI-compatible inference providers so users can select them in ocx init or the dashboard, store an API key, discover usable chat models, and route Codex or Claude Code requests through the normal provider/model interface.

Together AI is already a canonical provider on the current main and dev branches, so it should be treated as the baseline for this work rather than added again.

I intend to implement this batch. If the scope is acceptable, please assign this issue to @olddonkey.

What prevents this today?

Most of the proposed services are absent from PROVIDER_REGISTRY. Several are already documented in the intentionally inert FREE_PROVIDER_DIRECTORY, but directory entries are not canonical runtime providers and cannot be selected as maintained presets.

Users can configure these services through the custom OpenAI-compatible flow, but every user must know the correct base URL, authentication, model-discovery behavior, and provider-specific limitations.

Blindly copying every candidate into the runtime registry would also create two correctness and safety problems:

1. Model discovery currently assumes ${baseUrl}/models, reads the entire response, and exposes every valid data[].id. Some providers return embeddings, image, audio, or video models alongside chat models.
2. Promoting a previously non-canonical id can cause an existing same-named custom provider to be canonicalized onto a new host. A persisted API key must never be silently retargeted to a different destination.

A credential-free probe on 2026-07-27 confirmed that all proposed model endpoints are live and either return an OpenAI-style model list or the expected 401 authentication boundary. Existing issues and pull requests were searched for every provider below; no duplicate provider request was found.

What should OpenCodex do?

Promote the following verified providers to first-class API-key presets.

Provider id	Service	OpenAI-compatible base URL	Discovery notes
baseten	Baseten Model APIs	https://inference.baseten.co/v1	Authenticated GET /v1/models; managed Model APIs only
deepinfra	DeepInfra	https://api.deepinfra.com/v1/openai	Public model list currently has 172 rows; filter to the 92 rows tagged chat
sambanova	SambaNova Cloud	https://api.sambanova.ai/v1	Public OpenAI list currently has 6 models
nebius	Nebius Token Factory	https://api.tokenfactory.nebius.com/v1	Authenticated OpenAI GET /v1/models; use the current Token Factory endpoint, not the retired AI Studio host
novita	Novita AI	https://api.novita.ai/openai/v1	Public list currently has 142 rows and all report model_type: chat
chutes	Chutes	https://llm.chutes.ai/v1	Public list currently has 14 models; 12 advertise tool support
hyperbolic	Hyperbolic Inference API	https://api.hyperbolic.xyz/v1	Authenticated model list; official docs cover streaming and function calling
digitalocean	DigitalOcean Serverless Inference	https://inference.do-ai.run/v1	Authenticated model list; scope is the shared serverless endpoint, not per-agent or dedicated hosts
scaleway	Scaleway Generative APIs	https://api.scaleway.ai/v1	Authenticated OpenAI model list; chat, Responses, tools, and multimodal features are documented
nscale	Nscale Serverless Inference	https://inference.api.nscale.com/v1	Authenticated model list; filter to chat-compatible models
vultr	Vultr Serverless Inference	https://api.vultrinference.com/v1	Authenticated OpenAI model list; preserve documented normalizer model ids and tool-call behavior
featherless	Featherless AI	https://api.featherless.ai/v1	The unfiltered endpoint currently returns about 21,500 rows; use a bounded chat/tool-capable query rather than importing the whole catalog

All entries should initially use:

• Adapter: openai-chat
• Authentication: Authorization: Bearer <key>
• Official API-key/dashboard URL
• Provider-native model ids preserved end to end, including embedded / characters
• The existing flattened Codex alias form for namespaced model ids, while retaining raw full-slash routing

Discovery and safety requirements

• Add an explicit, registry-derived model-discovery URL/query mechanism (or an equivalent safe design) instead of assuming every provider can use an unqualified ${baseUrl}/models.
• Filter discovery to models that can serve the configured chat path. Do not expose embedding, reranking, image, audio, or video-only ids in the Codex model catalog.
• Bound the model response body and accepted row count before parsing/caching so a large or hostile upstream catalog cannot cause unbounded memory or catalog growth.
• Preserve useful upstream metadata where present, including common fields such as context_length, max_model_len, context_size, input modalities, and tool/reasoning capability arrays. Full per-model capability UX remains related to [Feature]: GUI fields (or a built-in registry) for per-model capability metadata on relay providers #485.
• Keep provider discovery failure behavior unchanged: cached/static degradation, observable status, and no credential logging.
• Do not automatically turn every free-directory row into a canonical provider. Promotion must remain an explicit allowlist.
• Preserve the destination of existing same-named custom providers, or provide an explicit safe migration. Adding a canonical id must never silently send a stored key to a newly registered host.
• Keep Baseten dedicated Truss model/chain predict endpoints out of scope; their hosts, Api-Key authentication, and arbitrary schemas are different from Baseten Model APIs.
• Keep DigitalOcean agent-specific and dedicated endpoint hosts out of scope for this preset.

User-facing behavior

Each promoted provider should:

• appear consistently in ocx init, the dashboard provider catalog, key-login flow, and provider workspace;
• link to its official API-key management page;
• validate a key against the provider's safe model-discovery endpoint;
• sync only eligible chat models into the OpenCodex/Codex catalog;
• support streaming, tool calls, structured output, cancellation, usage, and upstream error propagation where the selected upstream model implements them;
• document material provider-specific limitations without claiming unsupported capabilities.

Verification

Add focused coverage for:

• registry id uniqueness and EXPECTED_KEY_PROVIDER_IDS parity;
• derived CLI, key-login, and dashboard presets;
• provider-specific model URLs and authentication headers;
• mixed-catalog filtering;
• bounded response/model counts;
• namespaced model-id routing and flattened aliases;
• same-named custom-provider destination preservation;
• representative provider metadata parsing;
• documentation/provider-table parity.

Normal feature pull requests should target dev.

Example usage or interface

ocx init
# Select one of the new providers, paste its API key, and sync eligible models.

codex -m "baseten/deepseek-ai-DeepSeek-V4-Pro" \
  "Review this repository and propose the smallest safe fix."

codex -m "chutes/Qwen-Qwen3-32B-TEE" \
  "Run the tests and diagnose the first failure."

The raw full-slash selector should continue to work as well:

codex -m "chutes/Qwen/Qwen3-32B-TEE" "Inspect the routing code."

Representative configuration:

{
  "defaultProvider": "sambanova",
  "providers": {
    "sambanova": {
      "adapter": "openai-chat",
      "baseUrl": "https://api.sambanova.ai/v1",
      "authMode": "key",
      "apiKey": "${SAMBANOVA_API_KEY}",
      "liveModels": true
    }
  }
}

Alternatives or workarounds

Users can continue adding each service as a custom OpenAI-compatible provider. That covers the basic wire protocol but provides no maintained preset, key link, safe provider-specific discovery, or consistent documentation.

Opening one issue per provider would make each item smaller, but most implementation and review work is shared: registry derivation, model-list filtering, response bounds, slug routing, migration safety, tests, and docs. One umbrella issue with reviewable phases or pull requests makes the shared contract explicit while still allowing commits to be grouped by provider.

Providers that need a materially different transport or discovery contract should remain separate follow-ups. Examples include Perplexity's Agent/Responses API, GitHub Models' separate catalog endpoint and API-version header, Clarifai's URL-shaped model ids, AWS Bedrock's regional/authentication requirements, and Replicate's arbitrary prediction schemas.

Additional context

Canonical/inert directory precedent:

• feat(providers): add canonical free provider directory #405 added FREE_PROVIDER_DIRECTORY as intentionally inert metadata.
• [Provider] Add Modelsell as a built-in OpenAI-compatible provider #561 is the current single-provider preset precedent.
• [Feature]: GUI fields (or a built-in registry) for per-model capability metadata on relay providers #485 tracks broader per-model capability metadata UX and registry work.

Official provider documentation:

• Baseten: https://docs.baseten.co/inference/model-apis/overview
• DeepInfra: https://docs.deepinfra.com/chat/overview
• SambaNova: https://docs.sambanova.ai/docs/en/get-started/api-keys-urls
• Nebius Token Factory: https://docs.tokenfactory.nebius.com/quickstart
• Novita: https://novita.ai/docs/api-reference/model-apis-llm-create-chat-completion
• Chutes: https://chutes.ai/agents/connect
• Hyperbolic: https://www.hyperbolic.ai/docs/inference/text-apis
• DigitalOcean: https://docs.digitalocean.com/products/inference/reference/api/serverless-inference/
• Scaleway: https://www.scaleway.com/en/docs/generative-apis/quickstart/
• Nscale: https://docs.nscale.com/docs/use-cases/chat
• Vultr: https://docs.vultr.com/how-to-use-vultr-serverless-inference-in-python
• Featherless: https://featherless.ai/docs/api-overview-and-common-options

The current upstream/dev branch was also checked and contains none of these canonical provider entries.

Checks

• I searched existing issues, pull requests, and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming desired providers.
• I removed secrets and personal data.

[github-actions]

_{Automated translation bookkeeping — detected language: English.}

[Ingwannu]

Thanks for the unusually thorough proposal and endpoint verification. The direction is useful, but this should remain an umbrella issue rather than become one review-sized change containing all twelve providers.

Please proceed in phases against dev:

1. Land the shared discovery contract first: registry-derived discovery URL/query/filtering, bounded response bytes and accepted row count, chat-model eligibility filtering, representative metadata parsing, and same-named custom-provider destination preservation. Keep tests fixture-based; CI must not depend on live provider endpoints.
2. Add providers in small reviewable batches (roughly 2–4 with the same discovery shape), with registry/CLI/dashboard/docs parity and provider-specific fixtures in each PR.
3. Keep providers requiring a different transport, authentication scheme, or arbitrary prediction schema out of this issue. Together AI remains the existing baseline and must not be re-added.

The safety requirements in the report are acceptance criteria, especially preventing an existing custom provider/key from being silently retargeted and preventing oversized mixed catalogs from entering the Codex catalog. A provider should not claim streaming, tools, structured output, or multimodal support beyond what its selected upstream models and official documentation actually establish.

I am assigning this to you. You do not need to implement every provider in one PR; reference this umbrella issue from each phased PR and target dev.

[lidge-jun]

Phase 1 landed: #652 merged as 48f2e8362.

That is the shared discovery contract you were asked to land first — registry-owned endpoint/query policy, declarative eligibility filters, bounded response bytes and row count, redirect: "error" so credentials cannot follow a redirect, destination-policy checks before fetch, OAuth host pinning for fixed presets, and same-named custom-provider collision preservation.

Verified on the merged dev tip rather than from the PR branch: bun x tsc --noEmit clean, and 151 tests pass across the discovery-contract, provider-registry-parity, and codex-catalog suites.

Keeping this umbrella open for the remaining provider batches. Next up is #653 (Baseten pilot), which no longer has the contract as a blocker. Its windows-latest job is currently failing on the Test step — I confirmed that is a genuine failure rather than a cancelled run, and I have dispatched a rerun now that the prerequisite is on dev. Worth noting for the follow-on batches: the same PR's focused suites pass locally here (38 pass, typecheck clean), so if the Windows failure persists it is more likely a runner-level problem than a defect in the preset itself — the earlier #610 investigation hit EEXIST: epoll_ctl from the Bun test runner on Linux CI, and I could not find a matching upstream Bun issue to pin it to.

Thanks for structuring this as phases. Landing the contract before the twelve presets is what made #652 reviewable as one security-boundary change instead of twelve.