If you use coding agents heavily, you have probably run into the same annoying pattern I did.
One provider is rate-limited. Another still has quota left. A third is cheaper for simple tasks but not what your current workflow is wired to use. In practice, that means your session stops anyway, even though you still have perfectly usable model capacity somewhere else.
I built @mrrlin-dev/external-agents to fix that problem.
It is an MCP server that lets tools like Codex and Claude Code route work across multiple LLM providers through one interface. The main value is not “AI magic.” It is much more boring and useful than that:
- better cost efficiency
- a larger effective token budget
- fewer rate-limit interruptions
- less custom fallback logic glued into every workflow
The actual problem
Most agent setups still assume one provider at a time.
That is fine until you start doing real work:
- long review sessions
- multi-file edits
- repeated reviewer passes
- large-context analysis
- parallel agent runs
Then the weak point becomes obvious. Your workflow is only as durable as the quota and latency profile of one provider.
That creates two bad outcomes:
- You overpay, because you keep stronger or more expensive models in the loop for tasks that do not need them.
- You lose flow, because one provider getting busy or rate-limited pauses everything.
The frustrating part is that many of us already have usable capacity spread across multiple providers: Anthropic, OpenAI, Gemini, Groq, OpenRouter, DeepSeek, and others. The capacity exists, but it is fragmented.
The idea
Instead of treating each provider as a separate workflow, treat them as one shared execution pool.
That is what external-agents does.
Your agent talks to one MCP server. Under the hood, that server can dispatch requests across many configured providers. That turns isolated quota buckets into one larger working token budget.
I am deliberately saying effective token budget, not “unlimited tokens” and not “bypass rate limits.”
Nothing magical happens here. You are not escaping provider limits. You are just using the capacity you already have more intelligently.
Why MCP is a good fit
MCP is useful here because it gives the agent one stable interface.
Codex or Claude Code does not need custom provider-specific fallback logic every time you want to experiment with routing. You configure the MCP server once, then iterate on policy behind that interface.
That matters more than it sounds.
Without a layer like this, multi-provider setups usually become one of these:
- hardcoded scripts no one wants to maintain
- ad hoc retries that are invisible until they break
- manual API-key switching when a session stalls
- separate tools for separate providers, which defeats the point of agent flow
An MCP server is not just a transport choice here. It is the control plane.
What gets better in practice
1. Cost efficiency
Not every task needs your most expensive model.
A practical setup can reserve stronger models for harder reasoning, and let cheaper or free-tier capacity absorb simpler work. Over time, that means more useful output per dollar and less waste from using premium models as the default for everything.
2. Fewer interruptions
The best routing system is the one you barely notice.
If one provider is busy, exhausted, or temporarily constrained, the session can continue through another route instead of dumping the problem back on the human. That is the real UX win.
3. Better use of fragmented quotas
A lot of developers already have partial capacity everywhere:
- a paid plan in one place
- free-tier credits in another
- low-cost overflow through a router
- one provider that is better for long context
- another that is better for speed
A shared dispatcher turns that from scattered leftovers into something operationally useful.
4. Cleaner reviewer workflows
This was especially relevant for me because I wanted reviewer-panel and consensus-style flows to stop depending on a single vendor path. If you are doing multi-model review, a dispatcher layer is much easier to reason about than wiring every reviewer directly into the outer toolchain.
Where it fits well
I think this pattern is especially useful for people who:
- use Codex or Claude Code daily
- run long coding sessions
- care about spend discipline
- already have accounts across several model providers
- want resilience without rewriting their agent stack
It is also a nice fit for experimentation. You can compare routing strategies and provider mixes without changing the client surface every time.
Where I would not oversell it
There are a few things I do not think this should be pitched as.
First, it is not a guarantee of identical outputs. Different providers and models behave differently.
Second, it is not a substitute for good judgment about task-model matching. If you route everything everywhere without policy, you just create chaos with extra steps.
Third, it is not about pretending cost disappears. If anything, the point is the opposite: make spend visible, deliberate, and better allocated.
Why I built this as one MCP server for many LLMs
The design goal was simple:
one MCP server, many LLMs, one steadier workflow
I wanted one place to define routing, one place to expose tools, and one place to absorb rate-limit pain before it hits the coding session.
That makes the whole setup easier to run, easier to tweak, and easier to explain to other developers.
If you want to try it
The package is here:
- GitHub: https://github.com/mrrlin-dev/external-agents
- npm: https://www.npmjs.com/package/@mrrlin-dev/external-agents
If you are already using Codex or Claude Code and have capacity spread across multiple providers, this is the exact use case it was built for.
The short version is:
You probably do not need more provider accounts.
You may just need a better way to turn the ones you already have into one reliable working budget.
답글 남기기