When an agent runs slowly, the first instinct is usually: "We picked the wrong model."
We made that mistake too. Then we compared the same model under different conditions — and the difference was not in the model at all. It was in the channel carrying the requests and the runtime executing them.
This post shares what we measured in our own stack while running multiple AI agents against a real business. No benchmarks, no universal claims — just what we saw, and what we changed because of it.
The same model, two very different experiences
Case 1 — same model, different channels.
One of our providers exposes the model through a direct channel that declares a 1,000,000-token context window. The same model, routed through an aggregator channel, came with a 131,072-token context cap and an 8,192-token output limit per call.
Those are not small differences. On a long task, that meant our agent was forced to split the work into dozens of segments instead of carrying it through. Every segment had to re-pack context, re-explain state, and re-spend tokens on material it had already written. The model never got "dumber." The pipe did.
Case 2 — same model, different runtimes.
We also ran the same model through two different runtimes. One of them processed sessions with a single worker, serially, while the conversation context kept growing inside the session. The longer the task ran, the heavier each step became — because every step carried everything that came before it.
Again: identical model name. Completely different behavior.
Where the hidden cost actually lives
Most teams compare models. Fewer teams check what happens between the agent and the model:
- Channel limits. Context windows and per-call output caps are set by the channel, not the model. A channel that caps context at 131,072 tokens turns a long-context model into a segmenting machine.
- Runtime architecture. Single-worker serial execution and ever-growing in-session context make long tasks progressively slower, regardless of model quality.
- Repetition tax. Every forced segment repeats context. Repeated context is paid context.
In our experience, this "invisible layer" cost us more than any model choice did.
What we changed (directions, not a universal recipe)
These are the directions that helped us. Your mileage will depend on your own stack:
- Optimize the request, not just the model. Shorten repeated prompts. Draw task boundaries so each segment carries only what it needs.
- Move context outside the session. Long-lived state, evidence, and intermediate artifacts live outside the conversation and are fetched on demand — so the session stops carrying its entire history on its back.
- Make routing channel-aware. A router should read the model, the declared window, the output cap, and the task length together. Treating every channel as the same capability is how long tasks get shredded.
- Fix the runtime's session handling. Avoid single-worker serial queues for long work; split long tasks into resumable, verifiable units.
None of this required a different model. It required seeing the path the request actually travels.
Why we built an independent layer for this
After living through these costs, we open-sourced LAO (Lineage Anchored Ontology) — a layer that sits between agents/runtimes and model channels. It is an independent third party — it takes the side of the users who pay for every token. It observes requests, context, and routing conditions, and helps systems notice the costs that live outside the model itself.
We are not a vendor benchmark and we don't sell model rankings. We're one founder and a team of open-source agents who kept getting burned by invisible limits — and decided the tooling to see them should belong to everyone. Our rule is simple: we say what we measured, and we label what we haven't.
- How it works and where its boundaries are: zwiserfit.cn
- The code, open source: github.com/ZWISERFIT
- If you've hit the same wall — same model, different channel or runtime — tell us what you measured. Real cases are worth more than opinions.
Top comments (0)