-
Notifications
You must be signed in to change notification settings - Fork 129
OrcaRouter provider support for InternAgent #28
Description
InternAgent gives researchers a single framework that carries a hypothesis from literature survey and idea generation through method development to automated experiment execution. Covering algorithm discovery and dry/wet-lab empirical discovery across physical, Earth, and life sciences, plus autonomous paper reproduction, it is a practical partner for AI scientists rather than a benchmark demo.
InternAgent already models providers as a pluggable layer — model_factory.py registers openai, openrouter, dsr1, and interns1, and .env.example supports any OpenAI-compatible endpoint via OPENAI_API_BASE_URL. I'm an engineer on the OrcaRouter team, and I'd like to propose OrcaRouter as an optional provider in that same abstraction, so discovery and QA pipelines can reach more models through one endpoint while existing providers stay untouched.
Proposal
I'd like to propose adding OrcaRouter as an optional provider for InternAgent. This is purely additive — it would not replace or change any existing provider, and users who prefer OpenAI, Anthropic, DeepSeek, OpenRouter, or a self-hosted endpoint configure things exactly as today.
Why it could help InternAgent users
Long-horizon discovery loops make many repeated, multi-agent model calls, so a few OrcaRouter capabilities seem especially relevant:
- Multiple chat, reasoning, and image models through one endpoint — each agent in the pipeline (generation, reflection, evolution, ranking, deep research) could use the model tier that fits the subtask, without separate SDKs or keys.
- Automatic model routing and provider failover — a failed upstream provider can retry on an alternative, which matters for experiments that run unattended for a long time.
- Usage tracking and budgets — teams running many autonomous experiments can watch spend per project.
Expected integration point
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. Based on InternAgent's existing provider abstraction — the models.default_provider setting, a provider block in the config YAML, and the factory pattern used by openrouter_model.py — the natural fit would be an orcarouter provider block with corresponding environment keys, or pointing InternAgent's OpenAI-compatible base URL at OrcaRouter, in the same way docs/openrouter.md describes for OpenRouter. I have not implemented or tested this; this issue is to gauge whether maintainers would welcome such a contribution.
OrcaRouter is already used alongside open-source projects including RAGFlow, Dify, and goose, and we keep a public list at https://www.orcarouter.ai/built-with.
Disclosure
OrcaRouter has 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 an integration, and I'm glad to follow whatever disclosure or governance rules InternAgent prefers.
Maintainers — would an OrcaRouter provider be of interest? If so, I'm happy to submit an implementation PR following the project's conventions and documentation.