Harnesses: Eager vs. Just-in-Time

Last Updated on July 20, 2026 by Editorial Team Author(s): Jordan Carson Originally published on Towards AI. Harnesses: Eager vs. Just-in-Time Read the article for free here. Created using matplotlib, more on this later. I’ve been building my own coding harness, and the thing I kept obsessing over was the first turn, time to first byte, and maximizing cache reads while minimizing everything else (input, output, cache creation tokens, server latency, etc.). Those numbers sent me down a rabbit hole comparing every harness I could get my hands on. Essentially, every coding agent makes a bet before the first tool call fires. How much of your workspace should the model see before it starts reasoning, and how much should it have to go find? That one decision drives almost everything people argue about with these tools. Token bills. Latency. Whether the agent’s picture of your repo is current or twenty minutes old. Whether it behaves the same on a weekend project and a monorepo. I’ve boiled this down into two camps. Eager Hydration: Cline’s Bet Open a task in Cline and before the model has thought about your request at all, it’s holding a recursive listing of every file path in your working directory. This lives in a block called environment_details. Technically that’s injected context riding alongside the system prompt rather than part of it, though for cost purposes the distinction barely matters. Cline refreshes it as the session goes. The team is upfront about the philosophy here. The directory structure exists so the model never has to rediscover your project’s shape. They’ve described the system prompt as a constitution, tools, environment, preferences, all bundled into one brief before any work starts. I actually respect how legible the bet is. Pay a tax at the start of every task, sized to your workspace, and in exchange the agent never opens with “so what’s in this repo?” The catch, of course, is that the map starts rotting the moment someone adds or deletes a file. Hence the refreshing. More on why that matters later, because it’s not the token cost that gets you. A Second Flavor of Eager: Aider’s Curated Map Aider is eager too, but it looked at Cline’s phone-book approach and decided to send an org chart instead. Tree-sitter parses the repo. Aider builds a graph of which files define and reference which symbols, then runs PageRank over it, weighted toward files already in the conversation. Out comes a “repo map”, the most-referenced classes and functions in your codebase, as elided snippets, binary-searched down to fit about 1,024 tokens. Ships with every request. (look up graphiffy in github) Same philosophy as Cline but the map goes out before the agent asks for anything. Radically different bill. Whether a ranked summary actually beats a complete listing is a genuinely open question, and I suspect the answer depends on how weird your codebase is. PageRank rewards what’s popular. Your bug is usually somewhere unpopular. Just-In-Time Search: The Claude Code / Codex / Gemini Bet Claude Code didn’t arrive at just-in-time search by accident. It got there by reversal, which makes it even more interesting. Anthropic built RAG and vector indexing into early versions, ran it head-to-head against live agentic search, and ripped it out. Boris Cherny, Claude Code’s creator, has said agentic search won by a wide margin in their testing. Not “we preferred it.” Just won. What’s left is almost embarrassingly simple. Glob for path patterns. Grep for content. Read to pull a file in once it’s confirmed relevant. The agent finds structure by looking for it, the way you’d find and grep your way around an unfamiliar repo yourself. When exploration needs to go deep, Claude Code spawns a read-only Explore sub-agent in a separate context window that comes back with just a summary, so the wandering never pollutes the main session. There’s a small eager component. CLAUDE.md goes in up front, unconditionally. Conventions, build commands, all that curated stuff. Anthropic calls the whole thing a hybrid, which is fair, and multiple users working on the same repo would still prefix match. Codex CLI and Gemini CLI made the same call, with AGENTS.md and GEMINI.md. There's no pre-built tree. All discovery through search, cost spread across turns. Where the Tokens Actually Land Do the totals converge? Somewhat, but cost matters more than the sum. Cline pays once, at the front, proportional to workspace size. Ten files, basically free. Tens of thousands of paths? Real money, every single task, before any reasoning happens. The search camp pays in installments. A Glob here, a Grep there, a Read when a candidate is confirmed. Total scales with how many wrong turns the search takes. Notice what it doesn’t scale with is repo size. Grep doesn’t care how big the haystack is. It cares how good your pattern is. So the curves cross. On a small flat project eager wins, and JIT is paying round-trip latency to learn what one listing would’ve handed over instantly. On a big deep repo it flips. But here’s the cost that raw token counts miss, and honestly the thing that made me want to write this post is cache economics. Context loading philosophy (eager left, JIT right). The y-axis is a rough estimate. Cline and Terminus 2 have long lines because their cost scales with repo size. The JIT cluster has short, nearly flat lines because Glob/Grep cost doesn’t scale with repo size, only with search quality. JIT tools have large dots (org-wide cache sharing possible). Eager tools have small dots (session-scoped, volatile content breaks cache sharing). Not mentioned, Roo Code, as it was a Cline fork, the now Zoo Code. The Cache Problem Nobody Puts in Their README Go look at what actually rides inside a real environment_details block sometime. The current time, down to the second. The developer’s open editor tabs. Visible vscode files. A running context-window usage counter. None of that repeats across sessions. It definitely doesn’t repeat across people. Two engineers, same […]