What’s the Underlying Logic of Coding Agents and Why Do Claude Code Variants Outperform Others?

LLM, inference model, and agent layers

An LLM predicts the next token. An inference model is a fine‑tuned LLM that spends extra compute on reasoning, verification, or search. An agent sits on top of the model as a control loop: given a goal it decides which information to fetch, which tools to call, how to update its state, and when to stop.

Six core components of a coding agent

# 1) Live Repo Context -> WorkspaceContext
# 2) Prompt Shape And Cache Reuse -> build_prefix, memory_text, prompt
# 3) Structured Tools, Validation, And Permissions -> build_tools, run_tool, validate_tool, approve, parse, path, tool_*
# 4) Context Reduction And Output Management -> clip, history_text
# 5) Transcripts, Memory, And Resumption -> SessionStore, record, note_tool, ask, reset
# 6) Delegation And Bounded Subagents -> tool_delegate

1. Live repository context

The agent first recognises whether it is inside a Git repository, determines the current branch, and locates relevant documentation (e.g., AGENTS.md ). This information guides actions such as selecting the correct test command or locating the file to edit.

2. Prompt shape and cache reuse

A stable prompt prefix containing immutable instructions, tool descriptions, and a workspace summary is built once and cached. Because the prefix changes rarely, it is reused across turns, saving compute compared with rebuilding the full prompt each time. Only the dynamic parts—latest user request, short‑term memory, and recent tool outputs—are appended to the cached prefix.

3. Structured tool access and validation

Before executing any operation the runtime checks:

Is the tool known?

Are the supplied parameters valid?

Does the action require user approval?

Is the accessed path inside the workspace?

The operation is performed only after all checks pass, reducing the risk of uncontrolled actions.

4. Minimising context bloat

Long‑running sessions generate large amounts of output (file reads, tool logs, transcripts). Two strategies are applied:

Clipping : truncate overly long fragments so no single piece monopolises the token budget.

Record reduction / summarisation : compress older conversation history into a concise summary while keeping recent events detailed. Duplicate file reads are de‑duplicated.

5. Structured session memory

The runtime maintains two layers of memory:

Working memory : a small, highly refined state that records essential facts such as the current task, important files, and recent notes.

Full transcript : a complete JSON log of every user request, tool output, and model response, enabling session restoration after a crash.

6. Bounded sub‑agents for delegation

Complex tasks can be split into bounded sub‑agents that inherit just enough context to operate but are restricted (e.g., read‑only mode, limited recursion depth). Claude Code has long supported sub‑agents; Codex introduced them more recently. Proper bounding prevents duplicate work and uncontrolled file access.

Mini Coding Agent implementation

The minimal Python implementation is hosted at https://github.com/rasbt/mini-coding-agent. The repository contains the six components annotated in the source code and demonstrates the full workflow described above.

Comparison with OpenClaw

OpenClaw is a general‑purpose local agent platform that also supports coding. Its focus is on long‑lived agents across multiple workspaces, whereas coding agents are specialised for terminal‑based code manipulation. Both share prompt files, JSONL conversation logs, and sub‑agent creation, but their design goals differ.

Conclusion

The six components intertwine to form a coding‑agent harness that dramatically improves the practical utility of LLMs. The observed performance gap between systems such as Claude Code or Codex and a raw LLM stems largely from the quality of the surrounding harness—context management, caching, validation, and memory—rather than from the underlying model itself.