Every few weeks a developer looks at route.tools and says, correctly, “I could build this in a weekend.” A try/catch around two search providers, a config file mapping categories to vendor preference, maybe a retry with backoff. That wrapper is maybe 200 lines, it works, and it removes the scariest single point of failure in an agent stack.
I run a tool router for a living, so you know my bias. But I want to write the honest version of this comparison, because the weekend wrapper is genuinely viable for a lot of teams, and pretending otherwise would be the kind of salesmanship I started this blog to avoid.
What the weekend version actually gets you
Let us give DIY its full due. A basic fallback wrapper buys you:
- Failover. Provider A errors, provider B answers. This is 80% of the value of the whole idea, and I mean that literally: surviving a vendor outage is the headline benefit, and 200 lines of code delivers it. (The case for why you need it at all is in why AI agents need failover.)
- A seam. Once calls go through your wrapper instead of vendor SDKs directly, swapping providers later stops being a rewrite.
- Zero margin. You pay list price. A router charges for its layer; ours is list plus 20%, published at /docs/pricing. DIY’s price advantage is real and permanent.
- Total control. Your schema, your policies, your weird edge cases, no lowest-common-denominator normalization.
If you use one or two tool categories, have engineering slack, and your provider set is stable, stop reading and build the wrapper. Sincerely.
Where the weekend version quietly ends
The gap is not the happy path. It is everything that makes the happy path trustworthy over months, and each item below is a thing I did not appreciate until running one of these in production.
Health tracking. Naive failover retries a dying provider on every request, eating its timeout each time. The fix is a circuit breaker: ours skips any provider above a 30% error rate over a five minute window, then lets it back in when it recovers. Not hard to build. Genuinely hard to tune, and it needs enough traffic to have statistics at all. Your wrapper sees your traffic; a router sees the aggregate, so a provider’s bad afternoon is often visible before your own requests start failing. The pattern deserves its own post and has one: circuit breakers for AI agents.
Time budgets. Failover multiplies worst-case latency: three providers times their timeouts can hang an agent for minutes. Our router caps every request with a per-category wall-clock budget (20 seconds for search, up to 330 for video) so the chain degrades instead of dangling. Most DIY wrappers discover this need in an incident postmortem.
Failure taxonomy. A 429 is not a 500 is not an empty-but-200 response. Rate limits should trigger failover without dinging provider health; server errors should ding health; empty scrape bodies should count as failures even though the status code smiled at you. Encoding all of this is where the weekend becomes a quarter.
Observability and billing. Per-call prices in every response, the full attempt chain alongside, failed calls never billed, spend visible per request instead of per invoice. Buildable, absolutely. Built by weekend wrappers, in my experience, approximately never.
The catalog treadmill. Providers change prices, add endpoints, deprecate models, and ship new modes. Someone has to notice. With DIY that someone is you; with a router it is the vendor’s whole job. Our catalog and quality scores are open source partly so this labor is inspectable rather than taken on faith.
One bill and one key. Five providers means five accounts, five invoices, five keys in your secret manager, five minimum spends or credit balances. Consolidation is boring value, but it is the kind of boring that compounds.
The actual decision framework
The honest split, as I see it:
Build the wrapper when: you use one or two categories; your call volume is low enough that price-tier arbitrage saves pennies; you have unusual schema or compliance needs; or the 20% margin genuinely outweighs the engineering time at your scale. Also build it if you simply want to understand the problem. It is a great weekend.
Use a router when: you are in three or more categories (the wrapper’s surface area grows linearly, its edge cases faster); you want live health data you cannot generate from your own traffic; you need budgets, caps, and per-call cost attribution without building a billing system; or provider churn is costing you real engineering days.
And there is a middle path that deserves more attention: BYOK. Bring your own provider keys, pay your negotiated rates directly, and use the router purely as the failover, routing, and observability layer at a 5% platform fee. That is the configuration for teams who did the DIY math on price and still want the operational layer; it drops the buy-side premium from 20% to 5% while keeping everything the weekend version lacks.
The part I will concede
A router is a dependency, and a meaningful one: a layer between you and every tool call. You should demand that such a layer be auditable (attempt chains in every response), priced in public, and escapable (normalized schemas plus raw passthrough mean leaving is a refactor, not a hostage negotiation). If a router does not meet that bar, the weekend wrapper is not just viable, it is the responsible choice.
If you want to compare against what you would be building, the behavior is documented in the routing docs, and the $2 in free signup credits is enough to test the failover path yourself: dashboard.