Jev did not make Claude Code cheaper. Its own benchmark says so.

A developer's code review of the jev-gateway router for Claude Code found that a single ternary in src/adapters/messages.ts forces the gateway into "hint" mode for every real Claude Code request, because thinking and caching are always on. The gateway's own jev-gateway-bench, 120 sessions across Claude Code 2.1, shows routing cut input tokens 48% and time 25% on a bugfix task but raised input tokens 61% and time 83% for Opus 5 on a feature task, and the author's logging proxy measured a 47,000-token tool roster being re-sent each turn to return a 4-token decision. The gateway's README states it should be expected to improve tool picks on large tool lists, "not lower cost or latency.

Six videos in five days wired Jev into Claude Code and called it the cheapest agentic coding loop available. I installed the gateway too. Then I did the thing none of those videos did, which is open the code. One ternary in src/adapters/messages.ts , line 99, answers the entire question: steer: thinking || cached ? "hint" : "tool choice" If thinking is on, or the conversation is cached, the gateway is only allowed to hint. Every real Claude Code request carries both. So hint mode is not a degraded fallback you hit occasionally. Inside Claude Code it is the only mode there is. So what does a hint actually buy you? Jev is TypeSafe's decision model. No text generation, just a choice, a score or a yes-no probability, in 70 to 500 ms, at $0.042 per million input tokens. jev-gateway sits in front of Claude Code, looks at your tool roster, and tells the model which tool it thinks you want. I did three things: read the gateway's adapter and launcher, read the benchmark the gateway author published alongside it, and put a logging proxy in the gateway's seat in front of my own Claude Code to count what a router would actually receive. The install is honest, by the way. bin/clients.mjs sets ANTHROPIC BASE URL and nothing else, so your Pro or Max login keeps working and no API key is involved. The gateway's own README says it plainly: "Expect better tool picks on large tool lists, not lower cost or latency." Nobody quoted that line either. In hint mode the gateway appends a block after everything the client sent, on the client's own blocks, so the cached prefix stays byte identical. The text is a <system-reminder saying a tool-routing model suggests tool X. The model is free to disagree, and the wording says so. It has to work this way. The Anthropic docs close the other doors: tool choice invalidates the messages cache. The gateway touches neither, which is the correct call. It also means there is a guard that skips the hint entirely when the last block is a system reminder, and Claude Code appends those itself. jev-gateway-bench is 120 sessions, 5 runs per cell, Claude Code 2.1, on the same subscription you use. Here is the part that never made it into a thumbnail. On chess-bugfix , routing pays. Sonnet 5 read 48% fewer input tokens and finished 25% faster. Nothing got less correct. On chess-san , adding a feature, it goes the other way: Opus 5, routing on: +61% input tokens +47% requests +83% time Sonnet 5, routing on: +16% input tokens +37% time The authors' own explanation is the sentence I keep coming back to. A hint that does not fit costs a detour, instead of being ignored for free. A forced tool call you did not want is one wasted call. A suggestion you half follow is a path. There is a correctness line in there too. One model solved the feature task five times out of five on its own and three out of five with routing on, using half the input tokens to get there. Cheaper and wrong is not a saving. And the split that explains the whole product: Jev decided 76 to 100% of Codex requests, where the gateway forces the tool, against 34 to 51% of Claude Code requests, where it can only hint. A router has to see your tools to pick one. So I counted mine. clean install: 24 tools 47,000 prefix tokens my real setup: 40 tools 57,000 prefix tokens answer: 4 tokens The gateway re-sends that roster on every call, and there is an open issue about exactly that. The bench repo has a footnote with a worse case than mine: one setup sent 285 tools and about 200,000 tokens with every Claude Code request, against 6 tools and 7,000 tokens clean. Jev's own pricing makes this survivable. That is not the point. The point is that a decision model priced at four cents per million tokens is being handed a 47,000 token question to return four tokens, every turn, so that a model with thinking on can read two sentences it is allowed to ignore. It is one benchmark, two task families, five runs per cell, on a chess engine. My proxy numbers are my machine and my plugins, not yours. If your roster is small and your tasks look like bug hunts, the bugfix column is real and you should go measure it yourself, which is what the bench repo is for. It also says nothing about the rest of the Jev surface. Compaction is a separate tool with separate tradeoffs, and Codex is where forced routing actually lands. Jev itself is cheap and fast. The detour around it is not. The video walks the adapter line by line and puts the bench table on screen next to the claims made about it, which is easier to follow than a code block in an article. Have you measured your own tool roster? If you run Claude Code with more than a handful of MCP servers, I would like to know what number you get, because mine surprised me. I use AI tools to help tighten my drafts. The runs, the numbers and the opinions are mine.