We said our gateway used 10× less context. We measured the whole bill.
Every MCP server in your client config injects its entire tool schema into every turn, whether you use it or not. A gateway replaces all of them with a handful of meta-tools and loads a server's schema only when you connect. We published the comparison and it was flattering: 2,644 tokens against 25,900 for ten servers, about 10× less.
That number is correct and it is not what a conversation costs. We finally measured the whole thing, and the honest figure at ten servers is closer to 3× — with a range at the bottom where you should not use a gateway at all.
What the 10× was actually counting
Standing overhead: the schema that sits in the window every turn. Real, easy to measure, and incomplete, because a gateway does not only change what sits there. It also changes how many turns you take.
To use a server through a gateway the model must find it, connect to it, and only then call it. Every one of those turns re-sends the entire transcript. And the output of a registry search — ten candidates with slugs, scores and descriptions — stays in that transcript for the rest of the conversation.
None of that appears in a standing-overhead figure. All of it appears on the bill.
The measurement
Same task, same model, two paths. gemma-4-31B on vLLM, counted with the server's own tokenizer rather than an estimate:
| tokens | turns | |
|---|---|---|
| Gateway, cold — discover a server, connect, call a tool | 17,904 | 5 |
| Static config — that server already attached, just call the tool | 6,605 | 2 |
With one server, the gateway costs 2.7× more than simply configuring it. That is the part a standing-overhead comparison hides completely, and it is the case a first-time user is most likely to be in.
Where it turns
The gateway's cost is roughly flat in the number of servers you have configured, because it only loads what you connect to. The static config's cost is linear. So there is a crossing point.
N servers configured, one of them actually used, after ten turns of real work:
| servers | static | gateway | |
|---|---|---|---|
| 1 | 25,870 | 70,524 | static wins 2.7× |
| 2 | 51,740 | 70,524 | static wins 1.4× |
| 3 | 77,610 | 70,524 | gateway wins 1.1× |
| 4 | 103,480 | 70,524 | gateway wins 1.5× |
| 10 | 258,700 | 70,524 | gateway wins 3.7× |
| 20 | 517,400 | 70,524 | gateway wins 7.3× |
Break-even is three to five servers, depending on how long the conversation runs. Shorter conversations push it higher, because the setup cost has fewer turns to amortise across.
So the advice that falls out of our own numbers is:
- One or two servers: don't use a gateway. Write the config. It is cheaper and simpler and we are not going to pretend otherwise.
- Four or more: it pays, and keeps paying as you add servers.
- Ten: about 3× on total tokens, which is a smaller and more defensible claim than the one we were making.
Why we got it wrong the first time
Not because the 10× was fabricated — it was measured, and it is still the right number for the thing it measures. We got it wrong by picking the metric that flattered us and not asking what a user would actually be billed.
Standing overhead is the natural thing to measure if you are building a gateway, because it is the thing a gateway obviously improves. Total conversation cost is the natural thing to measure if you are paying for one. We were doing the first and publishing it as though it were the second.
The tell was available the whole time: our own README already said "connecting to a server still pays that server's schema cost at connect time." We wrote the caveat and then did not follow it to its conclusion.
What we don't claim
- Not a benchmark. One model, one task shape, one tokenizer. The shape of the curve should generalise; the exact crossing point will move.
- Not a claim about your servers. The static side assumes a 2,587-token median drawn from 91 servers we have connected to and introspected. If your ten servers are lighter than the median, break-even moves up; heavier, it moves down.
- Not a measurement of a real ten-server config. We measured one server attached and modelled the rest from the corpus median. A real config of ten would be the better experiment and we have not run it.
- Not an argument that tokens are the only cost. The gateway exists mainly to stop a server reading your environment. Context was always the secondary argument; this post is about being accurate on the secondary argument.
- We are not neutral. We build the gateway this post is about, and the effect of the correction is to make our own headline number smaller.
Reproduce it
# gateway cold — must discover and connect before it can call anything
OLLAMA_HOST=http://your-host:8000/v1 node demo/ollama-probe.mjs your-model
# baseline — server already attached, as a hand-written config would have it
PRECONNECT=everything-slim OLLAMA_HOST=http://your-host:8000/v1 \
node demo/ollama-probe.mjs your-model
Both print a per-turn prompt breakdown and a total. The script works against Ollama or anything OpenAI-compatible.
A gateway is worth it when you have more servers than you use. That was always the real claim — we just published the version of it that sounded better.