Idea: tool routing through providers (web search as a starting point)

[East-rayyy]

Background

This came up while looking at #276 — Claude Code's web search was failing because the combo routed it to a provider that couldn't handle it. The immediate format detection and schema bugs are fixed in #397, but it got me thinking about a bigger question.

Right now, when an agent sends a built-in tool call (like web_search_20250305), 9router passes it through to whatever provider is handling the request. If that provider is Claude, it works — Claude knows how to handle its own tools. But if the combo falls through to Copilot, NVIDIA NIM, or any non-Claude provider, the tool call either fails silently or errors out.

The idea

What if 9router could route tool calls the same way it already routes chat completions?

The concept: when an agent requests a tool like web search, 9router intercepts it and translates it into the native tool call for whichever provider is configured to handle it. So if web search comes in and the user has Antigravity set as the tool provider, 9router translates the tool call into Antigravity's format — Antigravity processes it thinking it came from its own client, and 9router translates the response back. Same pattern 9router already uses for chat, just extended to tools.

The provider list wouldn't be limited to third-party search APIs — it would include the actual model providers too. Antigravity, Copilot, Kiro, Claude, etc. Each already has its own way of handling web search natively. 9router would just do the translation between formats, which it's already built to do.

Configuration could work like the existing Providers page — an ordered list of providers for each tool type, with fallback if the first one fails.

Where I'm stuck

The part I haven't figured out is the flow. Specifically:

• How do we keep this simple enough that it doesn't confuse users? Adding a whole new page for tool configuration could be overkill, or it could be exactly right — I'm not sure.
• Should tool routing be its own concept, or should it piggyback on the existing combo/provider system somehow?
• When should 9router intercept vs pass through? If the request is going to Claude and it's a Claude-native tool, intercepting is pointless overhead. But if it's going to Copilot, interception is the only way it works.
• How do we minimize complexity in the routing logic while still covering the common cases?

About me

I vibecode — Claude writes it, I review the approach and test everything on an isolated VM before pushing. My PRs on this repo so far have been small targeted fixes. This would be a bigger feature so I want to make sure the approach makes sense before writing anything.

@decolua — what do you think?

I wanted to get your take on this before going any further. Does this concept even make sense for 9router's direction? Is there a simpler way to solve the underlying problem that I'm overcomplicating? Would love to hear how you'd approach it — or if you think this isn't worth pursuing, that's useful to know too.

Open to ideas from anyone else who's run into this.

[DarKWinGTM]

One practical intermediate path here might be to support optional companion tooling, not just core tool translation.

While investigating #276, I built a companion project for this exact gap:

• https://github.com/DarKWinGTM/claude-code-web-hooks

Important clarification: this is not a replacement for Anthropic web_search_20250305. It is a client-side compatibility path / workaround for Claude Code setups that run against non-Claude or custom-provider paths where Anthropic’s server-side web search is not available.

This companion approach works at the Claude Code hook layer instead:

• intercept WebSearch client-side
• call external search providers
• preserve native fallback behavior when appropriate
• keep the workaround outside 9router core

Current provider support:

• WebSearchAPI.ai
• Tavily
• Exa

So maybe the direction could be:

• long-term: richer tool translation / tool routing inside 9router
• short-term / practical: document or optionally integrate a client-side compatibility path for users who need WebSearch-like behavior today on non-Claude providers

That gives users a real path now, while keeping the architecture honest about what Claude-native server-side tools can and cannot do outside Claude.

[decolua]

Thanks for the detailed proposal and the companion project, @East-rayyy and @DarKWinGTM.

I'm planning to take a similar approach:

1. Maintain a list of models that don't support web_search/web_fetch natively
2. Intercept requests at the CLI tool layer (Claude Code, Cursor, etc.)
3. Route through intermediate services that provide web search/fetch capabilities

This aligns well with @DarKWinGTM's short-term path — keeping the interception client-side while we figure out the right long-term architecture.

I'm currently swamped with other work, so progress will be slower than I'd like. But I'll get to this when I can. Really appreciate both of your contributions and ideas on this.

[East-rayyy]

@decolua started on the foundation for this. #437 adds a tool capability map so 9router knows which providers support which built-in tools. Instead of silently stripping web_search for non-Claude providers, it tells the model what's unavailable. Went through all 40+ providers and documented their native search formats too, for whenever the actual translation gets built.

Also, #400 adds 96 unit tests and a CI workflow that runs on every PR (Node 20 + 22, build check, ESLint with inline annotations). Contributors can see if their changes break things before you even look at the PR.

[decolua]

Sorry for the delay — too many issues to handle in time. Auto-closing issues inactive for more than 10 days. Feel free to reopen if this is still relevant. Thanks for your understanding!

[decolua]

Sorry for the delay — too many issues to handle in time. Auto-closing issues inactive for more than 10 days. Feel free to reopen if this is still relevant. Thanks for your understanding!