Skip to content

feat(reactor-cli): add OrcaRouter as a named built-in provider - #164

Open
XiaoHuo888-hue wants to merge 1 commit into
openprose:mainfrom
XiaoHuo888-hue:feat/orcarouter-provider
Open

feat(reactor-cli): add OrcaRouter as a named built-in provider#164
XiaoHuo888-hue wants to merge 1 commit into
openprose:mainfrom
XiaoHuo888-hue:feat/orcarouter-provider

Conversation

@XiaoHuo888-hue

Copy link
Copy Markdown

This adds a dedicated OrcaRouter provider rather than relying on the generic OpenAI-compatible endpoint, mirroring how this repo already treats openrouter-style aggregators. Named routers such as orcarouter/auto pick an upstream per request. OrcaRouter is an OpenAI-compatible gateway that exposes 150+ models behind one API key, and it also provides gateway-level security controls for AI agents.

I'm an engineer on the OrcaRouter team.

What & why

packages/reactor-cli's KNOWN_PROVIDERS registry documents its extension mechanism ("Add a row as new vendors are asked for in the wild"). This PR adds one row for orcarouter:

  • baseURL: https://api.orcarouter.ai/v1
  • apiKeyEnv: ORCAROUTER_API_KEY

so a reactor.yml with model.provider: orcarouter resolves the OrcaRouter gateway base URL + key env through the exact same openai-compat (Chat Completions) path the existing openrouter / openai / google built-ins use — buildLiveProvider injects a scoped OpenAIProvider with useResponses: false, unchanged.

Changes

  • src/model/provider-plan.ts — add orcarouter to KNOWN_PROVIDERS (base URL + key env)
  • src/commands/init.ts — scaffold reactor.yml comment lists orcarouter + ORCAROUTER_API_KEY
  • src/config.tsbase_url docstring lists orcarouter
  • README.md — built-in provider list includes orcarouter
  • src/__tests__/provider-plan.test.ts — new unit test asserting the orcarouter plan

Verification

  • pnpm --filter @openprose/reactor-cli typecheck — clean
  • pnpm --filter @openprose/reactor-cli build:test — clean
  • provider-plan suite: 10/10 pass (baseline 9/9 + new orcarouter test)
  • Full node --test over dist-test: 210 pass / 1 fail — the single failure is the contract-images symlink-cycle test on Windows (EPERM: operation not permitted, symlink), a pre-existing platform limitation unrelated to this change
  • L3 live with a real OrcaRouter key: resolveProviderPlan({ provider: 'orcarouter' })https://api.orcarouter.ai/v1 + ORCAROUTER_API_KEY; reactor doctor --live smoke render OK (model anthropic/claude-haiku-4.5, 38 tokens); a structured render + function tool through the gateway returned 1872 tokens
  • reactor init scaffold → reactor.yml documents the orcarouter provider; doctor recognizes ORCAROUTER_API_KEY

Notes

No behavior change for existing users: openrouter remains the default, and the SDK's lazy default-OpenRouter path is untouched (custom: true only for non-default providers).

Registers the orcarouter built-in in the KNOWN_PROVIDERS registry, so
`model.provider: orcarouter` + `ORCAROUTER_API_KEY` resolve to
https://api.orcarouter.ai/v1 through the same openai-compat path as the
existing OpenRouter/OpenAI/Google built-ins. Updates the init scaffold
comment, config docstring, README provider list, and adds a provider-plan
unit test. Verified: typecheck clean, provider-plan suite 10/10, L3 live
render through the OrcaRouter gateway (structured output + tool call).

Co-Authored-By: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant