openclaw - 💡(How to fix) Fix [Feature]: Per-Tool Model Routing — route specific tool calls to different models

Problem

Currently, all tool calls within a session share the same model. When a model excels at reasoning but struggles with structured file operations (e.g., edit, write), the user is forced to accept degraded performance or switch the primary model globally—losing the strengths of the original model for reasoning.

Real-world case

• Model A (kimi-for-coding): strong at long-context reasoning, chat
• Model B (deepseek-v4-pro): strong at structured output, file edits, regex matching

Using Model A as primary → edit/write operations repeatedly fail (oldText mismatch, loop blocks, 10+ retries). Using Model B as primary → lose Model A's reasoning advantages.

The only workaround is a blunt global model switch in agents.defaults.model.primary.

Proposed Feature

Support per-tool model routing in the Gateway, allowing specific tools to be routed to a designated model:

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "kimi/kimi-for-coding",
        "fallbacks": ["deepseek/deepseek-v4-flash"],
        "toolRouting": {
          "edit": { "primary": "deepseek/deepseek-v4-pro" },
          "write": { "primary": "deepseek/deepseek-v4-pro" },
          "exec": { "primary": "deepseek/deepseek-v4-pro" }
        }
      }
    }
  }
}

Or alternatively, pattern-based routing:

{
  "toolRouting": [
    { "tools": ["edit", "write"], "model": "deepseek/deepseek-v4-pro" },
    { "tools": ["exec", "process"], "model": "deepseek/deepseek-v4-pro" }
  ]
}

Expected Behavior

1. When the agent issues an edit or write tool call, the Gateway intercepts and routes to deepseek-v4-pro
2. The tool result is returned normally
3. Subsequent reasoning turns continue on the primary model (kimi-for-coding)
4. Tool routing is transparent to the agent (tool results appear as if from the same model)
5. Fallback chain applies per routing rule

Alternatives Considered

1. Multi-agent workaround: spawn sub-agents with different models for specific tasks — works but breaks session continuity and context
2. Heartbeat-style routing: already supports separate models for heartbeat runs — extend this pattern to tool calls
3. session_status dynamic model switch: can switch model mid-session, but requires agent self-awareness to switch before each tool call (fragile, error-prone)

Scope & Edge Cases

• Tool routing should respect fallbacks chain
• Should work with imageModel and pdfModel patterns (already per-tool routing examples in OpenClaw)
• Streaming tool calls (tool_stream) should respect routing
• Per-agent overrides (agents.list[].model.toolRouting) should inherit/merge with defaults
• Tool name matching: exact match vs prefix match vs glob

Related

• models.imageModel / models.pdfModel — existing per-capability model routing patterns in OpenClaw that could serve as prior art
• #7468 Dynamic Model Selection — broader model routing feature request
• Community workaround: openclaw-model-routing (mizoz) experimental repo