Feature: Per-agent model provider routing (e.g. local Ollama for subagents, Anthropic for orchestrator)

[berthelius]

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)

[oussama-kh]

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.

[seanbdoherty]

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.

[ksabour]

+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.

[FuturMix]

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_URL at a multi-model API hub that supports model-name-based routing. When Claude Code sends a request for claude-sonnet-4-6, the gateway routes to Anthropic. When it sends deepseek-v3 or gpt-4.1, the gateway routes to the corresponding provider.

# One endpoint, all providers
export ANTHROPIC_BASE_URL="https://your-gateway"
export ANTHROPIC_API_KEY="your-gateway-key"

Then in your CLAUDE.md or model selection, you can specify different models for different agents:

• Orchestrator: claude-opus-4-5 (via Anthropic)
• Code subagent: claude-sonnet-4-6 (via Anthropic, cheaper)
• Bulk tasks: deepseek-v3 (via DeepSeek, 10x cheaper)

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.

[loonylabs-dev]

@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?