OrcaRouter provider support for the OpenRouter TypeScript SDK

[nissrin2020ali-ux]

OrcaRouter provider support for the OpenRouter TypeScript SDK

What this proposal is

The OpenRouter TypeScript SDK is the official type-safe toolkit for building AI features in any JS or TS runtime, and how it standardizes provider integrations is why teams reach for it. OVERVIEW.md puts it plainly: integrating AI models means juggling different provider APIs and model-specific requirements, and this SDK protects you from those footguns with a single typed client for 400+ models, generated from OpenRouter's spec so new models land in your IDE autocomplete with no version drift. The provider preferences on chat requests (order, allowFallbacks, only, sort) show that provider-level routing is a first-class concern here.

Because the SDK already lets callers override the server via serverURL/OPENROUTER_BASE_URL and authenticates with a standard API key, it is a natural fit for an OpenAI-compatible endpoint such as OrcaRouter. This issue proposes adding OrcaRouter as an optional provider, so developers can point the same typed client at a second gateway without changing their existing OpenRouter usage. It would not replace or modify any current provider.

Why OrcaRouter is relevant to this SDK's users

OrcaRouter exposes an OpenAI-compatible API at https://api.orcarouter.ai/v1 and uses standard API-key authentication, the same auth shape the SDK already models through its apiKey option. The natural integration point would be the existing server override in src/lib/config.ts and src/lib/sdks.ts, so callers keep the full typed surface while targeting OrcaRouter's endpoint. Nothing here claims code exists: this is a proposal for maintainers to weigh in on.

For the teams this SDK serves, a few OrcaRouter capabilities stand out:

• Automatic model routing and provider failover through one endpoint, matching the provider-routing questions this repo already receives (Feature request: Explicit provider selection for LLM inference in SDK #430).
• Prompt caching billed at the provider's cache rate, plus per-request cost visibility, relevant for SDK users who reuse the same prompts across many calls.
• Usage tracking and budgets with spend caps and scoped keys, useful for organizations adopting the SDK across teams.

OrcaRouter already documents wiring for the open-source ecosystem: its docs cover OpenCode with a ready-made opencode.json provider block, and its built-with page lists open-source tools shipping OrcaRouter. OpenCode shows the pattern of shipping OrcaRouter as one configurable provider option.

Disclosure

I'm an engineer on the OrcaRouter team. OrcaRouter also runs an optional open-source partner program: approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a prerequisite for integration; it is entirely optional, and I'm happy to follow any disclosure or governance rules this project has. The primary ask is simply feedback on whether an OrcaRouter provider is welcome here.

Ask

If maintainers are open to this, I would be glad to submit an implementation PR once approved, following this repo's contribution process (I understand the SDK is Speakeasy-generated and changes flow through upstream). Please let me know your thoughts.