OrcaRouter provider support for Code Puppy
Code Puppy was, per its own README, "coded angrily in reaction to Windsurf and Cursor removing access to models and raising prices." That motivation is the product: instead of a locked-in IDE model plan, you get a terminal agent where model freedom is the point. /add_model browses 65+ providers through models.dev, and round-robin distribution cycles several API keys so rate limits stop blocking a session.
That same freedom is why another provider option matters here. Code Puppy already treats OpenAI-compatible gateways as first-class, with openrouter as a native model type in model_factory.py and custom_openai accepting any compatible endpoint. An optional OrcaRouter provider would slot into that existing seam and give your users another resilient route to the exact models they already rely on.
I would like to propose adding OrcaRouter as an optional provider. I am an engineer on the OrcaRouter team. This is purely additive: it would not replace or change any existing provider, model config, or the round-robin and models.dev paths in use. Anyone happy with their current setup (or a fully local vLLM/SGLang server) would be unaffected.
For Code Puppy users, the relevant capabilities are:
- One endpoint, many model classes. Chat, reasoning, image, and video models behind a single OpenAI-compatible endpoint, so one
extra_models.json entry can reach several model families without per-vendor base URLs and keys.
- Automatic routing and failover. When a provider degrades mid-session, OrcaRouter can route to an alternate model that supports the same request, a real time-saver for long agent runs.
- Usage tracking and budgets. Given the project's origin story about vendors raising prices, per-project usage tracking and budget caps give solo developers control over what a session costs.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. Based on how Code Puppy wires models today, the natural seam is the dispatch in model_factory.py: an orcarouter type could mirror the existing openrouter branch (an OpenAIChatModel over pydantic-ai), following the same env-var convention, for example ORCAROUTER_API_KEY. Until then, users could point a custom_openai entry at OrcaRouter's base URL. None of this is implemented or tested yet; I am describing where it could fit and would welcome your read.
OrcaRouter is already used across the open-source ecosystem, including RAGFlow, Dify, goose, and promptfoo. We also run an optional open-source partner program: approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. To be transparent, that is optional and not a prerequisite. If Code Puppy wants no partnership, nothing changes about this proposal, and we will follow whatever disclosure or governance rules you set.
You can see existing integrations at https://www.orcarouter.ai/built-with. I would welcome your thoughts and, with your go-ahead, am happy to open an implementation PR.
OrcaRouter provider support for Code Puppy
Code Puppy was, per its own README, "coded angrily in reaction to Windsurf and Cursor removing access to models and raising prices." That motivation is the product: instead of a locked-in IDE model plan, you get a terminal agent where model freedom is the point.
/add_modelbrowses 65+ providers through models.dev, and round-robin distribution cycles several API keys so rate limits stop blocking a session.That same freedom is why another provider option matters here. Code Puppy already treats OpenAI-compatible gateways as first-class, with
openrouteras a native model type inmodel_factory.pyandcustom_openaiaccepting any compatible endpoint. An optional OrcaRouter provider would slot into that existing seam and give your users another resilient route to the exact models they already rely on.I would like to propose adding OrcaRouter as an optional provider. I am an engineer on the OrcaRouter team. This is purely additive: it would not replace or change any existing provider, model config, or the round-robin and models.dev paths in use. Anyone happy with their current setup (or a fully local vLLM/SGLang server) would be unaffected.
For Code Puppy users, the relevant capabilities are:
extra_models.jsonentry can reach several model families without per-vendor base URLs and keys.OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. Based on how Code Puppy wires models today, the natural seam is the dispatch in
model_factory.py: anorcaroutertype could mirror the existingopenrouterbranch (anOpenAIChatModelover pydantic-ai), following the same env-var convention, for exampleORCAROUTER_API_KEY. Until then, users could point acustom_openaientry at OrcaRouter's base URL. None of this is implemented or tested yet; I am describing where it could fit and would welcome your read.OrcaRouter is already used across the open-source ecosystem, including RAGFlow, Dify, goose, and promptfoo. We also run an optional open-source partner program: approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. To be transparent, that is optional and not a prerequisite. If Code Puppy wants no partnership, nothing changes about this proposal, and we will follow whatever disclosure or governance rules you set.
You can see existing integrations at https://www.orcarouter.ai/built-with. I would welcome your thoughts and, with your go-ahead, am happy to open an implementation PR.