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.