Netflix cut AI coding agent token costs 20–65% with JetBrains
If you run AI coding agents against a Java or Kotlin codebase, your agents are probably wasting tokens navigating compiled libraries. Netflix quantified exactly how bad that problem is, then fixed it using JetBrains’ headless code intelligence engine. The results are concrete: 20 to 65% efficiency gains depending on the model, with correctness holding steady or improving across every run.
This is a case study worth reading if you build on the JVM, run agentic workflows in CI, or are simply trying to squeeze more output per dollar from Claude Code or Codex.
The Problem: JAR Boundaries Kill Agent Efficiency
JVM projects typically ship libraries as compiled JAR files with no source code attached. When a coding agent needs to understand a library, it has to unzip the JAR, guess which class files are relevant, potentially decompile them, and then grep through an incomplete view of the codebase.
Paul Bakker, Staff Software Engineer at Netflix, described it directly:
“Coding agents like Claude Code are slow and unreliable at navigating Java/Kotlin code, especially across library (JAR) boundaries. We integrated a headless JetBrains IDE’s code engine to give agents IntelliJ IDE-grade code intelligence in headless environments, with no IDE running.”
The fix Netflix pursued: plug JetBrains’ code intelligence engine, the same deterministic index that powers IntelliJ IDEA, into their agents headlessly, with no IDE process running.
️ The Architecture: A Warm Daemon, Not Cold Starts
JetBrains exposes its code intelligence via an LSP (Language Server Protocol) and ships it inside the Java and Kotlin by IntelliJ IDEA extension for VS Code-compatible editors. But an LSP server alone isn’t agent-ready. It’s a protocol with no built-in process management, and no easy way for an agent to call it between steps without incurring a cold-start penalty each time.
Building a fresh index for a large project takes real time, comparable to opening a big project in IntelliJ IDEA for the first time. A realistic agentic task requires many fine-grained LSP calls. If each one launched a fresh server, every call would hit that multi-second startup cost.
Netflix solved this with a custom daemon. JetBrains is working on delivering its own daemon, but none was available at evaluation time, so Netflix built one for their needs. Here’s how it works:
- Each tool call is short-lived and stateless. It shells out to a CLI.
- The daemon stays running. Its session manager routes each call by project root to the matching server process, which holds that project’s index in memory.
- A second call against the same project skips indexing entirely and hits a warm server over stdio.
- Both the daemon and CLI are written in Java and distributed as a GraalVM native executable, eliminating JVM startup and runtime overhead.
The result: agents get IntelliJ-grade symbol resolution across JAR boundaries without paying cold-start costs on every tool call.
The Benchmark Results
Netflix ran same-model, same-task, same-codebase comparisons. The only variable was whether the agent could call the JetBrains code engine. Efficiency is reported as the combined average of token savings and time savings.
| Configuration | Code Navigation | End-to-End |
|---|---|---|
| Strongest model, high effort | ~65% | ~24% |
| Mid model, high effort | ~29% | ~30% |
| Mid model, medium effort | ~24% | ~22% |
| Lighter configuration, high effort | ~17%* | ~21% |
| *Tokens only. Batched search calls made the time comparison unrepresentative for this configuration. | ||
A few things stand out in these numbers. First, correctness held steady or improved in every single run. There was no accuracy trade-off for the efficiency gains. Second, the strongest model at high effort saw the largest gains (up to ~65% on code navigation tasks). That matters because the strongest models are the most expensive per token, so the efficiency improvement has a higher dollar value per run. Third, even lighter configurations gained 17 to 21%.
Code navigation tasks
Across every model and effort level, agents used fewer tokens with JetBrains code intelligence available. No exceptions. Token savings ranged from roughly 15% to 60%, with the largest gains coming from the strongest model configuration.
One configuration batches multiple search calls into a single command by default, so it already makes only one tool call regardless of whether code intelligence is available. For that specific case, calling the JetBrains engine added a small amount of latency compared to the batched search, which is why the time comparison was flagged as unrepresentative. Token savings still applied.
End-to-end tasks
On the broader end-to-end task suite, every model and agent combination came in 10 to 30% more efficient on both time to completion and token spend. The explanation is simple: agents needed fewer tool calls to reach the same conclusions, because the code intelligence answered structural questions directly instead of forcing the agent to piece together the answer from raw grep and decompile operations.
What Netflix Ruled Out First
Before building the daemon approach, Netflix evaluated two alternatives and rejected both.
The first was an internal CLI that connected to a running IntelliJ IDEA instance for project index access. The process was similar, but it required an IDE to be running, which ruled it out for headless environments like their Otto and Bitbot agents, distributed refactoring tooling, and CI pipelines.
The second was the Eclipse LSP used for Java support in VS Code. For Netflix’s Gradle-based build system, it simply did not work.
What JetBrains Says Comes Next
JetBrains’ IDE Division Lead, Aleksey Stukalov, made a pointed observation about the LSP approach itself:
“Build agent tooling as if the agent were a tiny human at an editor, and you force it to speak in cursor coordinates. Agents need a code engine, not a virtual editor.”
The LSP’s fundamental primitive is a position in a text document. That’s a natural abstraction for a human at a keyboard. It’s not a natural abstraction for an agent that wants to ask “Which tests cover this method?” or “Why is this call inside createUser() unresolved?”
JetBrains’ stated direction is toward a layer that answers questions in terms of symbols, diagnostics, test relations, and runtime behavior, and returns enough context for an agent to reason about the result, not just a location in a file. The LSP is described as one step, not the final destination.
On the Netflix side, the team plans to run the same benchmark methodology against Python, TypeScript/JavaScript, and Go. Coding agents for those languages face similar navigation problems, though the library distribution mechanics differ by language. JetBrains plans to continue the collaboration and support that evaluation.
The Takeaway for JVM Teams
If your AI coding workflows touch Java or Kotlin, the JAR navigation problem is real and measurable. Netflix’s benchmark shows the cost in tokens and time, and their daemon architecture demonstrates one working solution. The approach requires running a custom daemon process, which is not a turnkey install, but the efficiency numbers make it worth evaluating for teams running agents at any meaningful scale.
JetBrains notes that these figures are a snapshot. New model releases shift how agents search and reason, so exact percentages will keep moving. What held across all of Netflix’s runs is the directional result: every model tested got more efficient, and none got less accurate.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
