Same job, thirteen completely different architectures: how today's top coding agents actually differ

Every coding agent gets pitched with the same three words: plans, uses tools, reflects. That's true of all thirteen agents a recent source-code teardown looked at, which is exactly why it explains nothing. A rigid ten-step pipeline and a full tree-search system both count as "planning and reflective," and they share almost no actual architecture. Here's where the real differences show up, organized by the decisions that actually separate these tools, with the agents most people are running (OpenCode, Gemini CLI, Codex CLI, OpenHands, Cline, Aider) getting the most airtime.

Who's actually driving the loop

The most basic architectural question isn't "does it plan," it's "who decides what happens next." Aider sits at one extreme: its LLM has zero callable tools. It can't grep, can't open a file it wasn't handed, can't decide to check a different module. A human does all of that navigation, and a PageRank-weighted map of the repo's real dependency graph (files already in the chat get a 50x relevance boost) fills in the rest as static context rather than something the model goes and fetches.

Nearly everything else in the mainstream CLI space went the opposite direction and gave the model full control over its own exploration. OpenHands, Cline, Gemini CLI, Codex CLI, and OpenCode all let the LLM decide where to look, what to run, and when it's done. That choice has a real cost: when a human picks the files, bad localization is a human mistake, but hand exploration to the model and localization becomes something the agent has to solve as part of the actual task.

Tool counts vary wildly, but everyone needs the same four things

Aider runs with zero tools. Moatless Tools, a much smaller research project, runs 37. And yet every agent that gives the model any autonomy at all converges on the same four capabilities underneath: read, search, edit, execute. Cline alone ships 27+ built-in tools flat, the largest set of any of the popular agents, while OpenCode sits close behind at 18+ and layers in a plugin system and MCP support so users can add their own on top.

Edit format tells a similar convergence story. Five independently developed agents, including OpenHands and Codex CLI, all landed on the same trick: give the model a tool that takes an exact old string and a new string and does surgical replacement, rather than making it produce a full diff or work off line numbers. That convergence happened without any of them copying each other, because models are simply more reliable at exact-match edits. OpenCode does a lighter version of Aider's approach here, switching between two edit formats (string replacement or unified diff) depending on the model, versus Aider's thirteen.

Context compaction: the one place nobody agrees

This is the most fractured dimension in the whole comparison, and it's worth spending time on because it's where the popular agents actually diverge from each other the most.

Aider, OpenHands, Gemini CLI, and Codex CLI all take the same basic approach: let the conversation grow, then trigger an LLM to summarize it once token count crosses a threshold. But the details matter a lot. OpenHands stores its entire history as an immutable stream of events and never deletes anything, even during compaction, it just inserts a marker over the condensed events, so a session can be replayed in full even after aggressive compression. It also supports nine different pluggable compaction strategies, more than anything else in the study.

OpenCode refuses to jump straight to the expensive option. It prunes mechanically first, replacing old tool outputs older than the most recent 40,000 tokens with plain truncation markers while keeping the message structure intact, and only calls in an actual LLM summary if that wasn't enough, at which point it can hand the job to a cheaper model since condensing text doesn't need the primary coding model's full capability.

Gemini CLI adds a step nobody else does: after summarizing, it runs a follow-up "Probe" turn asking the model whether the summary just threw away anything critical. Every other summarizing agent trusts its own compression and moves on.

Cline breaks the pattern entirely. Every other agent triggers compaction automatically off a token threshold, with the model having no say in it. Cline instead gives the model an actual callable tool, condense, so the LLM itself can decide when its own context has gotten unwieldy and request compaction on its own initiative. That's the only instance in the whole study of the compaction decision being handed to the model rather than imposed by the scaffold.

Codex CLI distinguishes between compacting before a turn versus mid-turn, and treats them differently: pre-turn compaction clears out reference context so the next turn starts clean, while mid-turn compaction, triggered when a tool call blows past the limit, reinserts initial context right above the last user message to match where the model expects it during training. mini-swe-agent, a deliberately minimal reference implementation, has no compaction strategy of any kind. Let a session run long enough and it just crashes with an overflow error.

Safety: containers, rules, or a second AI

Most of the SWE-bench-focused research agents rely on Docker containers as their entire safety story, keeping the host filesystem out of reach no matter what the model does. That doesn't work for a tool people run in their own terminal or editor, so the popular interactive agents each built something different.

Gemini CLI and OpenCode use rule-based permission systems, where a configurable policy decides which tool categories always need a human's confirmation before running. Aider just leans on the human being present and reviewing every change before it lands, treating the person as the actual safety boundary. Cline goes furthest among these, offering per-tool, per-scope approval settings ranging from full autonomous "YOLO" mode down to per-command-pattern confirmation, alongside a permission controller that specifically blocks dangerous shell operators.

Codex CLI does something structurally different from all of them. It layers OS-level sandboxing (Bubblewrap and Landlock on Linux, Seatbelt on macOS) with a second model, entirely separate from the one writing code, that scores every proposed tool call for risk on a 0-100 scale and blocks anything over 80 before it runs. That means a single tool call in a Codex CLI session costs at least two inference calls minimum: one to decide the action, one to police it. It's the only agent in the study using an LLM specifically to judge another LLM's safety rather than its quality, buying real nuance (a scratch-directory %%INLINECODE1%% and %%INLINECODE2%% get scored differently) at the cost of an extra call on every action and whatever the safety model itself gets wrong.

Memory: writing your own notes versus a background pipeline

Cline and Gemini CLI share the same basic pattern here: the model writes its own persistent notes directly as files, %%INLINECODE3%% for Cline and %%INLINECODE4%% for Gemini CLI, both loaded back into the system prompt on future runs. It's straightforward and it's the model consciously deciding what's worth keeping.

OpenCode does something different. Instead of curated notes, it persists the entire session, every message, tool output, token count, and dollar cost, to a real SQLite database, so a killed session resumes later with full fidelity rather than a vague sense of what happened.

Codex CLI's memory system inverts the usual assumption entirely. Rather than the model consciously deciding "I should remember this," it runs memory formation as a background pipeline: a cheap model sweeps over recent session transcripts in parallel pulling out candidate facts, and a more capable model later consolidates and deduplicates those into the persistent store, with usage-based ranking so stale entries get pruned automatically. Memory here looks a lot more like an ETL job than a deliberate choice by the agent.

OpenHands, despite being one of the most widely used tools in this study outside of pure benchmarking, has none of this. Every run starts from nothing beyond static, human-written project instructions it can read but never update.

Routing: almost always about cost, except once

Most multi-model agents route for the obvious reason: save money by sending mechanical work to a cheap model and reasoning to an expensive one. Aider hands off summarization and commit messages to a "weak model" while keeping the main model for actual coding.

Gemini CLI takes this furthest with a seven-layer routing chain, each layer a progressively more expensive way to decide which model handles a request, stopping at the first layer confident enough to make the call. Its standout layer runs a small Gemma model locally on the user's own machine, so routing never touches the API at all, the only client-side model selection in the whole study.

Codex CLI is the one clear exception to "routing is about cost." Its Guardian model exists purely for safety, and its two memory-pipeline models exist purely for extraction and consolidation, none of it driven by trying to save money.

The smaller, stranger agents worth knowing about

A few research-focused agents outside the mainstream CLI world are doing things worth a quick mention. Agentless skips the agent loop entirely, running ten scripts connected by JSON files on disk and picking a winning patch by majority vote across independently generated candidates, no feedback loop at all. Moatless Tools runs actual Monte Carlo Tree Search, the algorithm behind AlphaGo, complete with reward backpropagation up the search tree. AutoCodeRover is the only agent using spectrum-based fault localization, a statistical bug-finding technique from before LLMs existed, to rank suspicious code before the model even starts looking. Prometheus, despite being built purely for benchmark evaluation, carries a three-tier memory stack (a 20-language knowledge graph, a semantic memory service, and Postgres checkpointing) that's more elaborate than most of the everyday tools bother building.

What it all adds up to

Some questions in this space are settled. Every agent with real autonomy needs the same four capabilities, whether that's spread across dozens of tools or crammed into one bash command, and string-replacement editing won out everywhere independently because models are just better at exact matches than diffs. Other questions aren't settled at all. Seven genuinely different compaction strategies across thirteen agents, memory that ranges from nonexistent to a three-service architecture, and no agreement yet on how much say a model should get over managing its own context. That spread isn't noise. It's a field that hasn't converged on an answer yet.

Acknowledgment

This piece draws on the source-code taxonomy and findings from Inside the Scaffold: A Source-Code Taxonomy of Coding Agent Architectures by Benjamin Rombaut (arXiv:2604.03515). All architectural details, comparisons, and evidence cited here trace back to that paper's analysis of 13 open-source coding agent scaffolds. Full credit for the underlying research goes to the author.