Loading benchmark data…
EyesInAI·Loading live benchmark data
Switchyard sits between your assistant and the models. For every request it picks the least-expensive model that still passes the task — measured against a live benchmark, not a hand-written rule. Model-agnostic, provider-agnostic, and fast enough to sit right in the request path. You change one line: your base URL.
client = OpenAI(
base_url="https://gateway.eyesinai.com/v1", # ← the one line
api_key=YOUR_SWITCHYARD_KEY,
)
client.chat.completions.create(
model="auto", # ← let Switchyard choose
messages=[...],
)Keep model="auto" to let Switchyard route, or name a model any time to pass straight through. It speaks the API you already use.
One line changes in your existing OpenAI-compatible client. Send model:"auto" and Switchyard chooses; send a specific model and it passes straight through. No rewrite, no SDK lock-in.
Each request is matched to the task it belongs to and sent to the least-expensive model that still clears your quality bar — read from a live benchmark of the candidates, not a static rule.
Switchyard shadow-tests alternatives in the background and re-routes as models change. Every real request it sees makes the next routing decision sharper. You watch the savings, not the plumbing.
Adding a router usually means adding another model call — and its latency — to every request. Switchyard doesn't. Most decisions never touch a model:
The decision returns from an exact-match cache. No model, no wait.
A semantic match — "how much is a scissor lift" vs "scissor lift price" — reuses the earlier decision. Still no model call.
One quick classification call matches it to a task in your taxonomy, then the answer comes from your compiled routing table. That decision feeds both caches, so its whole family of paraphrases is free from now on.
The consequence: routing cost scales with how many kinds of questions you get, not how many questions. Real business traffic repeats itself — so at volume, the marginal routing decision is an in-memory lookup that costs nothing and adds no perceptible latency.
Because every request already funnels through the gateway, it's the natural place to catch a secret before it leaves. Shieldyard is a security layer inside Switchyard that watches both directions of a turn for leaked credentials — the prompt going out to the model, and the model's answer streaming back.
The question a security layer always has to answer is how much it slows you down. We measured it: about 0.8 µs added per turn — roughly four to five orders of magnitude below a model-based guard, and invisible next to a normal model round-trip.
See the timing run, method, and how to reproduce itHonest scope, today: Shieldyard detects vendor secrets (not general personal data), and defaults to observing— auditing findings without altering your traffic — until you turn on blocking for an assistant, which today applies to the prompt going out. Redacting mid-stream on the way back, enforcement everywhere, a broader data-class layer, and an inbound prompt-injection classifier are what we're building on top of it.
The same gateway that catches a leaking secret is also the one place that can stop a single runaway prompt from quietly running up a bill. Limits sets a per-assistant ceiling on how many tokens a turn may cost — the length of the reply, the size of the input, and a sane default when a caller forgets to set one — and enforces it before the model provider is ever called.
Honest scope, today: caps are set per assistant and default to observing — recording what a cap would have done on your own traffic, changing nothing — until you switch one to enforce (clamp the request down, or refuse it). It bounds the tokens in and out of a turn; it does not meter wall-clock time mid-stream. The measured audit of what your real traffic would have hit is what you size a cap from.
Switchyard only ever picks a model that clears the quality bar you set for a task. If nothing beats what you run today, it tells you — and routes nothing. Savings that cost you accuracy are worth nothing, so we never make that trade.
For a request it has seen the shape of before, the routing decision is an in-memory lookup — not another model call added to your latency. It is built to be invisible.
Provider keys are passed through per request and never stored. Prompt data is held only if you want it held — for tuning — and can live in your own database. What we learn is which models are better, never your content.
The objection every automatic router earns: "what if it quietly downgrades me?" Ours can't. Every change to your routing follows the same evidence path:
The same measured routing, wrapped in a complete assistant for your business — drafted from your own website, live in one embedded line, improving from its real conversations.
The routing engine behind Switchyard already runs on a real support chatbot, where a per-action routing table cut model cost 31% with no measurable accuracy loss. Switchyard is that engine, made a product. Read the case study →
The numbers, measured on live production turns (not a rate card): our blended serving cost is $0.56 per 1,000 answered turns, and our recurring head-to-head against a popular router's autopilot mode shows equal quality, 2–5× faster answers across runs— with the cost lead trading hands between runs, which is exactly why we re-run it and publish whichever number comes back. Chat platforms' recommended tiers run 5–27× our cost for the same conversations. See the comparison →
Already run LiteLLM, Portkey, OpenRouter, or Vercel AI Gateway? We’re building exports that render your measured routing straight into the config those pipes already read. Keep your gateway — it just starts routing on evidence.
Streaming responses through the routed path, with the same spend controls in front of every token.
The live savings receipt already ships — hosted-assistant clients see it in their portal today. Next: the monthly emailed statement, per task, against your single-model baseline — the number your CFO actually wants.
Not sure routing would help you yet? Start with a one-time benchmark of your use case — we measure the savings first, honestly, before you wire anything in. Switchyard is what implements that routing table live once you're ready.
Tell us what you're running — whether you want the routing gateway in front of your existing chatbot, or the whole assistant built and hosted for you. We'll scope it to your workload and show you the measured savings before you commit.