Feature: Per-agent model provider routing (e.g. local Ollama for subagents, Anthropic for orchestrator)
Problem
Currently, ANTHROPIC_BASE_URL and model provider configuration is session-wide. There's no way to route individual subagents to different providers within the same session.
The model parameter in agent definitions only accepts sonnet, opus, haiku — all pointing to the same provider endpoint.
Use case
As a power user running Claude Code with Opus as orchestrator, I'd like to delegate mechanical/repetitive subagent tasks (bulk edits, i18n key extraction, file moves, simple searches) to a local model via Ollama while keeping the orchestrator and complex reasoning agents on Anthropic's API.
This would:
- Reduce API costs for high-volume agent workflows (GSD, parallel agents, etc.)
- Reduce latency for simple tasks (local inference is instant for small models)
- Enable offline capability for a subset of agent work
- Give users control over the cost/quality tradeoff per agent
Proposed solution
Allow a provider or base_url field in agent definitions (both .md frontmatter and --agents JSON), plus a corresponding entry in modelOverrides or a new providerOverrides setting:
# ~/.claude/agents/my-bulk-editor.md
---
name: bulk-editor
model: llama3.3:70b
provider: ollama
base_url: http://localhost:11434/v1
---Or in settings:
{
"providerOverrides": {
"ollama": {
"baseUrl": "http://localhost:11434/v1",
"format": "openai"
}
}
}Then in agent definitions: provider: ollama routes to that endpoint.
Current workaround
Run separate terminal sessions with different ANTHROPIC_BASE_URL values. This loses the orchestrator→subagent delegation model entirely.
Environment
- Claude Code v2.1.83
- macOS Apple Silicon
- Heavy user of parallel subagents (GSD, team agents, custom agents)
11 Comments
Could this solve your issue? https://github.com/oussama-kh/mcp-llama-swap
Currently works for local llm models only, and is not meant for subagents, but maybe you can fork and adapt it to your case.
I'd also love this. Exactly what I'm trying to do. Maybe someone has solved this with a different provider than Ollama? I'm falling back to having to use a ticketing system like GitHub issues as a middle ground between orchestration and implementation teams.
+1
Data sovereignty is not a preference, it is a non-negotiable requirement in many professional contexts. The session-wide provider lock that forces all inference through Anthropic's servers is a hard blocker, regardless of how capable Claude Code is as a tool.
Per-agent provider routing would change this entirely. Claude handles reasoning and planning. Local inference handles everything that touches protected data. Both within the same session, under a single coherent workflow.
Without this feature, developers with legitimate data protection requirements are being pushed toward alternative tools that already support this separation. That is not where we want to be, and it should not be where Anthropic wants us to be either.
Strongly support this feature.
This is doable today with an API gateway approach, even though Claude Code doesn't natively support per-agent routing.
The trick: point
ANTHROPIC_BASE_URLat a multi-model API hub that supports model-name-based routing. When Claude Code sends a request forclaude-sonnet-4-6, the gateway routes to Anthropic. When it sendsdeepseek-v3orgpt-4.1, the gateway routes to the corresponding provider.Then in your
CLAUDE.mdor model selection, you can specify different models for different agents:The gateway handles which backend each request goes to based on the model name. No per-agent endpoint override needed.
LiteLLM (open source) and hosted hubs like OpenRouter/FuturMix support this pattern. The key is: all models accessible through one endpoint, routing happens transparently.
@FuturMix what you mentioned is not working for most of us since we are using the subscription and not the expensive api
did I miss something because I cannot see the solution for the main user base with subscription usage?
+1 on this
This is a must have.
+1 on this
+1 on this
+1 on this
If you use API or provider credentials, you can keep one Claude Code endpoint
and route an Opus orchestrator and Haiku subagents to different backends. If you
only use a Claude subscription, this workaround does not apply: the hosted
route still needs its own API or provider credentials.
In Swobu, create a
claude-codeworkspace with two routes:| Route | Backend | Backend model | Protocol |
|---|---|---|---|
|
orchestrator| Anthropic or another hosted target | your orchestrator model | Messages ||
local-subagent| Ollama or another local target | your local model | Chat Completions |Point Claude Code at the workspace and make its model aliases select those
routes:
Then set
model: haikuin the subagent definition. Claude Code resolves themain Opus request to
orchestratorand the Haiku subagent request tolocal-subagent; Swobu routes each name to its configured backend.The client-side API key is only a placeholder. Configure real credentials on
the hosted Swobu target. Both backends still need to support the Claude Code
semantics used by their workloads.
I tested the model selection and both Swobu request paths with current Claude
Code. The original report used 2.1.83, so I would be interested to hear whether
the same alias overrides work there.
Disclosure: I maintain Swobu. If you try this, please share the result. For a
Swobu-specific failure, include the error and backend setup at
github.com/swobuforge/swobu, and I will help investigate.