JFrog's CTO tells LDS why AI agents burn tokens on noise

JFrog co-founder and CTO Yoav Landman told Lets Data Science that AI coding agents waste tokens on terminal noise, citing a test where an agent received an 847-line log when only 9 lines were needed. JFrog's Boost product applies dynamic CLI filters and a BoostGraph search prioritizer to cut token waste by 30 to 40 percent per command, up to 80 percent in best cases, though the company-reported figures are unverified. The problem is independently documented: per-token prices fell about 98 percent while enterprise AI bills rose roughly 320 percent.

JFrog's CTO tells LDS why AI agents burn tokens on noise Yoav Landman, co-founder and chief technology officer of JFrog, answered Lets Data Science on why AI coding agents consume so many tokens and what its Boost product does about it. In one measured test an agent was handed an 847-line log when only 9 lines were needed to diagnose the failure. Landman says typical workflows see a 30 to 40 percent reduction per command, with up to 80 percent in the best cases, and that filters can be bypassed by the agent when they cut something it needs. The claims are company-reported, but the underlying problem is independently documented: per-token prices have fallen about 98 percent while enterprise AI bills have risen roughly 320 percent. An AI agent is asked to diagnose a failing test. It runs the test, and the terminal returns 847 lines: progress bars, ANSI colour codes, dependency chatter, and somewhere inside it, the actual error. All 847 lines go into the model's context. According to JFrog's own measurement, 9 of them were needed . That gap is the entire business case for JFrog Boost, and Yoav Landman , the company's co-founder and chief technology officer, laid out the mechanism behind it in written answers to Lets Data Science. Why the bill grows while prices fall The context worth having before evaluating any vendor's claim here is that the problem is real and independently documented. Per-token prices have collapsed by roughly 98 percent, with GPT-4-equivalent performance falling from about $20 per million tokens in late 2022 to around $0.40. Over the same stretch, enterprise AI bills rose an estimated 320 percent, with average annual budgets climbing from $1.2 million in 2024 to $7 million in 2026, and per-developer consumption up about 18.6 times in nine months, according to reporting by The Next Web citing Jellyfish. Uber burned through its entire 2026 AI coding budget by April. Microsoft revoked its developers' Claude Code licences six months after granting them, with individual engineers spending between $500 and $2,000 a month on tokens. Landman's account of why is mechanical rather than rhetorical. "Because these agents operate in continuous loops, they retain prior conversation history to preserve their reasoning chain, meaning any terminal noise compounds with every single turn," he told Lets Data Science. Run an ordinary npm install or docker build inside an agent loop and the context window fills with hundreds of lines of progress bars and status updates, and you pay for them again on every subsequent step. He puts agentic coding at a thousand times the token consumption of standard code chat, a company figure we could not independently verify. What Boost actually does Two mechanisms, by Landman's description. At the terminal, Boost sits as a local wrapper applying "dynamic CLI filters that strip out progress bars, ANSI noise, and redundant chat logs so the agent focuses strictly on critical outputs." Teams with internal tooling can write custom TOML filters to compress their own output formats locally. For codebase search, a component called BoostGraph "intercepts the search results and prioritizes only the most relevant files and snippets for the model," rather than letting an agent pull in large volumes of loosely related code. The number worth holding onto is not the headline. Combining both mechanisms, Landman says typical developer workflows see a 30 to 40 percent reduction in token waste per CLI command , with savings reaching 80 percent in cases like the 847-line log. The 80 percent is the ceiling, not the average, and to the company's credit the answer said so without being pushed. The part that suggests real engineering The most reassuring detail is the escape hatch. Filtering an agent's inputs is a dangerous idea if done naively, because a filter that strips something load-bearing turns a solvable task into a confidently wrong answer. Landman addressed it directly: if a filter removes something the agent decides it actually needs, "agents can easily bypass filters to retrieve full raw outputs, or automatically disable filters that prove too aggressive." That is the correct design. The agent, not the filter author, gets the final say about what it needs, and an over-aggressive rule degrades to a slower correct answer rather than a fast wrong one. A category, defined by a company selling into it Landman calls this emerging layer "Agentic Token Efficiency", and it is worth being clear-eyed that the phrase comes from a vendor with a product in the space. The underlying argument, though, does not depend on the branding. "More tokens do not equal better output," he said. "In fact, passing a certain threshold of retrieved context actually degrades an LLM's response quality." That effect is well established in the research literature, and it changes what the tooling is for. The goal, in his framing, "isn't simply to enforce a budget", it is to have agents "maintain identical success rates on complex tasks while delivering faster average runtimes and significantly lower costs per session." That is the claim on which the category should be judged, and it is also the one JFrog has not yet published evidence for. A token reduction is easy to measure. Holding task success rates flat while cutting context is the harder result, and it is the one that would need a published benchmark before anyone takes it on trust. What this means if you are running agents today Strip the vendor framing and the practical lesson survives intact, because it is about where the waste is rather than whose product removes it. The expensive tokens in an agentic workflow are usually not the ones you wrote. They are the ones your tools emitted: build output, test logs, dependency resolution, search results. Because the agent resends its history each turn, a noisy command early in a session is not paid for once, it is paid for repeatedly, for the rest of that session. That points at cheap, vendor-neutral wins available to any team this week. Look at what your agent actually ingests after each command rather than only what it produces. Quieten your own tooling at the source, since most build and test runners have flags that suppress progress output. And treat retrieval breadth as a cost and a quality decision at once, because past a point more context makes the answer worse as well as dearer. Key Points - 1In a JFrog test, an agent debugging a test failure was fed an 847-line log when only 9 lines mattered , which is where the up-to-80 percent reduction figure comes from. Typical workflows see 30 to 40 percent per command, a company-reported range. - 2The cost compounds because agents resend their entire conversation history every step to preserve their reasoning chain, so terminal noise is paid for again on every turn. Landman says agentic coding consumes far more tokens than ordinary code chat. - 3The problem is independently documented: per-token prices fell about 98 percent while enterprise AI bills rose roughly 320 percent , with per-developer consumption up 18.6 times in nine months . Uber exhausted its 2026 AI coding budget by April and Microsoft withdrew Claude Code licences after six months. Scoring Rationale Written answers provided directly to Lets Data Science by the co-founder and CTO of JFrog on where coding agents actually waste tokens, with a concrete measured example and an honest typical-versus-best-case range. Lands against independently reported evidence that enterprise AI bills tripled while token prices collapsed, which is exactly the problem our practitioner audience is managing right now. Sources Original reporting, with the public references used alongside it. LDS Exclusive Reporting based on written answers given directly to Let's Data Science by Yoav Landman, co-founder and CTO, JFrog . View 1 more source Practice interview problems based on real data 1,625 SQL & Python problems across 15 industry datasets — the exact type of data you work with. Try 250 free problems /problems