DOCS / SWITCHBOARD
Switchboard: the router
Switchboard is Yeetful's routing engine. You ask for something in plain English; it weighs every MCP route that can answer, picks the cheapest proven route under your cap, patches the call, and pays for it per call in USDC on Base — no keys, no per-service integrations. See it move on the Switchboard page.
The front door: one ask, plain English
You never name an endpoint or fill a parameter. Send a request the way you'd say it — "live ETH price", "scrape this pricing page", "cheapest flight SFO→JFK" — from the Yeetful chat or through the yeetful SDK. Switchboard does the rest.
How it weighs routes
A directory service exposes many x402 endpoints. Switchboard only considers the ones it can actually construct a valid, bounded call for — an endpoint is plannable when it has a published parameter schema, an exact (non-upto) price, and that price sits at or under the $0.05 auto-call ceiling. From the plannable set it ranks on the two levers that matter:
- Price. Cheaper wins. Among endpoints that fit your need, the lower per-call price is preferred — so routing is structurally a hunt for best execution.
- Proven.A route that has actually settled before (real receipts in the ledger) is trusted over an untested one. This keeps a route that's a fraction of a cent cheaper but has never answered from winning on price alone.
The pick: cheapest proven route under your cap
Switchboard's choice is the cheapest route with a settlement history, falling back to the cheapest overall only when nothing in that category has been proven yet (a cold-start guard, so new routes still get a chance). You can preview exactly this on the Switchboard page — pick a need and watch the candidate routes rank, with the winner marked PICK.
Over the cap? Dropped, not paid
Your expense account sets the budget — an allowlist plus per-call, per-day, and lifetime USD caps. If the best route for a request is still priced over your cap, Switchboard drops the call: it is refused before any payment is signed, $0 is spent, and the denial is recorded. The guardrail saves money by not spending it. For chats Yeetful runs, this is a server-side hard refusal; for SDK agents paying their own wallet it is enforced in the SDK.
Every routed call is a receipt
Each settlement writes a row to your hosted ledger — the service, the amount, and the on-chain txHash. Routed spend is witnessed on Base, not self-reported: the public activity feedand the "engine at work" strip on the Switchboard page link every settled call straight to Basescan.
Preview the lever — no spend
A read-only endpoint exposes the ranking over the live catalog without paying or running any inference, so you can see how a category's routes stack up:
GET /api/route/preview → 200
{
"cap": 0.05,
"categories": [
{
"category": "Data",
"candidates": [
{ "service": "Yeetful · Snapshot", "price": 0.004, "proven": 18 },
{ "service": "CoinGecko", "price": 0.01, "proven": 0 }
],
"pick": "yeetful-snapshot", // cheapest PROVEN route
"pickProven": true,
"saved": 0.0455 // vs the priciest fitting route
}
]
}What the engine is, exactly
Under the hood the router is lib/endpoint-planner.tsplus a single planning inference call in the chat orchestrator, executing through Yeetful's version-aware x402 client. The price/proven ranking above is deterministic; matching your exact words to the right endpoint and filling its parameters is the planning model's job, and the request is built so a missing-required or unresolved path token refuses rather than pays for a guaranteed error.
Want to point your own agent at it? Start with the quickstart, or give every connected app a daily budget so routing stays inside the lines.