OrcaRouter provider support for Jumping Agent
Jumping Agent turns agent-building into a game: on a tablet, beginners assemble workflows by making a character hop between steps instead of wiring flat diagrams full of lines and arrows, then bind the finished agent to WeChat with a QR scan and chat with it from their messaging app. A builder that produces genuinely runnable workspaces makes that spatial, beginner-first idea tangible.
Model choice is already a config, not code, in Jumping Agent: back_agent/config/model_config.toml pairs an OpenAI-compatible base_url with an API-key environment variable. OrcaRouter follows the same pattern: an OpenAI-compatible API with standard API-key authentication. Self-hosting users could add it as an optional provider and reach several chat and reasoning models through one endpoint, with automatic routing and failover when one provider stumbles.
Proposal
I'd like to propose OrcaRouter as an additional, optional model provider for Jumping Agent. This would not replace or alter any existing provider, the default DeepSeek setup, or the way generated workspaces are configured. It gives people who self-host another endpoint they can point model_config.toml at by choosing OrcaRouter for the base_url and setting an OrcaRouter API key as the key source. Because OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, it should fit the abstraction Jumping Agent already uses without changes to agent code. Please note this is a proposal only; nothing is implemented or tested yet.
For Jumping Agent's users, the most relevant OrcaRouter capabilities are:
- Several chat and reasoning models behind one endpoint, so a builder's agent and the
back_agent helper can pick a stronger model for hard steps and a cheaper one for simple calls without maintaining multiple keys.
- Automatic model routing and provider failover, which helps keep agent runs moving when a single upstream provider is slow or unavailable.
- Usage tracking and per-team budgets, so small groups running agents can see and cap model spend.
OrcaRouter is already finding its way into the open-source ecosystem, with projects such as Dify, goose, and RAGFlow integrating it as a provider. That suggests the integration style is well understood.
Disclosure
I'm an engineer on the OrcaRouter team. 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. Participating is not a prerequisite for this proposal, and I'm happy to follow any disclosure or governance requirements Jumping Agent wants to set.
If you'd be open to this, I'd be glad to hear your thoughts here and, with your go-ahead, to submit an implementation PR adding OrcaRouter as a documented provider option. You can see other OSS integrations on our built-with page.
OrcaRouter provider support for Jumping Agent
Jumping Agent turns agent-building into a game: on a tablet, beginners assemble workflows by making a character hop between steps instead of wiring flat diagrams full of lines and arrows, then bind the finished agent to WeChat with a QR scan and chat with it from their messaging app. A builder that produces genuinely runnable workspaces makes that spatial, beginner-first idea tangible.
Model choice is already a config, not code, in Jumping Agent:
back_agent/config/model_config.tomlpairs an OpenAI-compatiblebase_urlwith an API-key environment variable. OrcaRouter follows the same pattern: an OpenAI-compatible API with standard API-key authentication. Self-hosting users could add it as an optional provider and reach several chat and reasoning models through one endpoint, with automatic routing and failover when one provider stumbles.Proposal
I'd like to propose OrcaRouter as an additional, optional model provider for Jumping Agent. This would not replace or alter any existing provider, the default DeepSeek setup, or the way generated workspaces are configured. It gives people who self-host another endpoint they can point
model_config.tomlat by choosing OrcaRouter for thebase_urland setting an OrcaRouter API key as the key source. Because OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, it should fit the abstraction Jumping Agent already uses without changes to agent code. Please note this is a proposal only; nothing is implemented or tested yet.For Jumping Agent's users, the most relevant OrcaRouter capabilities are:
back_agenthelper can pick a stronger model for hard steps and a cheaper one for simple calls without maintaining multiple keys.OrcaRouter is already finding its way into the open-source ecosystem, with projects such as Dify, goose, and RAGFlow integrating it as a provider. That suggests the integration style is well understood.
Disclosure
I'm an engineer on the OrcaRouter team. 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. Participating is not a prerequisite for this proposal, and I'm happy to follow any disclosure or governance requirements Jumping Agent wants to set.
If you'd be open to this, I'd be glad to hear your thoughts here and, with your go-ahead, to submit an implementation PR adding OrcaRouter as a documented provider option. You can see other OSS integrations on our built-with page.