llm-coding-agent 0.1a0 — Simon Willison's Coding Agent Built on His LLM Framework

The First Coding Agent That Ships as an llm Plugin

Simon Willison released llm-coding-agent 0.1a0 yesterday — an experimental coding agent built on his LLM library. It's an alpha release described as a "Fable 5 experiment," and it marks the moment Simon's CLI tool for querying LLMs officially becomes an agent framework.

Install it and you get an llm code command that works like Claude Code or Aider — but running entirely through LLM's plugin system, with all the logging, model-agnostic plumbing, and SQLite-backed conversation history that implies.

This is the first thing that's genuinely interesting in the "personal coding agent" space from someone outside the VC-backed tooling boom. Here's why it matters.

What It Actually Does

The tool suite is familiar if you've used Claude Code or Aider:

• edit_file — Exact string replacement with unified diff output for verification
• write_file — Create or overwrite files with parent directory creation
• read_file — Text file reading with numbered lines, offset, and limit for paging
• search_files — Regex search using ripgrep (when installed) with pure-Python fallback
• execute_command — Shell commands with 120s default timeout (600s max), process tree kill on timeout
• list_files — Glob pattern file listing, newest first, respects .gitignore

The implementation is clean. Each tool is a method on a CodingTools class that subclasses llm.Toolbox — the same mechanism any LLM plugin uses to register tools. The tools are path-confined to the session root directory, with .. traversal, absolute paths, and symlink escapes returning errors instead of exposing files.

The Meta Origin Story Is the Most Interesting Part

Here's the part that makes this worth paying attention to: llm-coding-agent was built by Claude Code itself.

Simon gave Claude Code exactly two prompts:

Prompt 1: "Write a spec.md for this project - it will depend on the latest 'llm' alpha from PyPI and implement a Claude code style coding agent complete with tools for reading and editing files and executing commands"

Prompt 2: "Commit the spec, then build it using red/green TDD in a series of sensible commits (each with passing tests and updated docs) - occasionally manually test it using the OpenAI API key in your environment"

Claude wrote the spec, built the library with TDD, committed it, and published the package to PyPI. The first working alpha of a coding agent — built by a coding agent, following spec-first TDD, using the library it was extending.

This is the kind of recursive demonstration that Simon has been working toward with his LLM library for years. The library has always been a plugin system first — tool registration, model-agnostic routing, structured logging to SQLite — and llm-coding-agent proves that those primitives were already agent-framework-grade.

The Python API Is a Surprise Bonus

Simon was particularly pleased that Claude Code implemented a Python API without being asked:

from llm_coding_agent import CodingAgent

agent = CodingAgent(
    model="gpt-5.5",
    root="/path/to/project",
    approve=None  # Pause for manual review
)
result = agent.run("Fix the failing test in tests/test_parser.py")

The approve parameter has four modes:

The chain_limit (default: 25) bounds how many tool-execution rounds a single run() can go through before stopping. When paused, result.pending_tool_calls gives you the queued calls, and agent.resume(approved=True) picks up where it left off.

This matters because it makes llm-coding-agent embeddable. You can wrap it in a CI pipeline, a PR review bot, or a custom workflow — the same CodingAgent class handles all of it.

Session Commands and the Approval Flow

Inside an llm code session, there are a few session-level commands:

• !quit — Exit the session
• !yolo — Toggle auto-approval on/off mid-session
• !model MODEL — Switch models mid-conversation
• !tokens — Report current token usage

The approval flow is the standard one: read-only tools execute freely; mutating tools prompt y (approve once), a (approve similar for the rest of the session), or anything else (decline, and the model retries). Sessions are logged to LLM's SQLite database — the same one llm logs queries — and can be resumed.

Where It Fits in the Coding Agent Landscape

The coding agent space has three distinct camps right now:

Claude Code — Anthropic's official agent, deeply integrated with Claude models, strongest tool sophistication. Has IDE integrations, MCP support, and a growing plugin ecosystem. The gold standard for capability but tied to Anthropic.

Aider — Open-source, model-agnostic, deep Git integration (auto-commit, multi-file refactors, repo map). The most battle-tested open option, but its architecture is purpose-built for code — you can't easily repurpose it for non-coding tasks.

Codex — OpenAI's CLI agent, fast iteration, strong Python/Cursor integration. Still early relative to the others.

llm-coding-agent — The new entrant. Its differentiator is that it inherits LLM's entire plugin ecosystem. Any model LLM supports (OpenAI, Anthropic, Google, Ollama, Llama via plugins) can be used. Any plugin that registers tools gets folded into the toolbox. The SQLite logging means every session, every tool call, every approval decision is queryable.

The most significant design difference: llm-coding-agent treats the coding problem as a general agent-loop problem. It doesn't have Git integration built in (unlike Aider's auto-commit workflow). It doesn't have MCP support (Claude Code does). What it has is a clean, minimal agent loop that any tool-capable model can drive, with a plugin architecture that lets you extend the toolbox without forking the repo.

Why This Matters for the LLM Ecosystem

Simon has been building toward this for months. His LLM library has quietly evolved from a CLI tool for running prompts into a general-purpose agent framework:

1. Plugin system — register_tools() hook for adding toolboxes
2. Toolbox abstraction — llm.Toolbox class with model-agnostic tool routing
3. Chain loop — The model.chain() API that drives multi-turn tool execution
4. Logging — Every interaction logged to queryable SQLite

llm-coding-agent is the first plugin that treats these primitives as an agent framework rather than just a prompt runner. The subtext here is that LLM has been an agent framework for a while — nobody noticed because nobody had built an agent on top of it yet.

The implications for the plugin ecosystem are interesting. If LLM becomes a viable agent runtime, then every plugin that registers tools automatically extends the coding agent's capabilities. A llm-web-browser plugin adds web search tools. An llm-sql plugin adds database query tools. The coding agent doesn't need to know about them in advance — they just show up in the toolbox.

Getting Started

# Install the plugin (needs --pre for the LLM alpha dependency)
pip install --pre llm-coding-agent

# Or with uvx — no install required
uvx --prerelease=allow --with llm-coding-agent llm code

# Run with auto-approval
uvx --prerelease=allow --with llm-coding-agent llm code --yolo

# Approve only specific command patterns
uvx --prerelease=allow --with llm-coding-agent llm code \
  --allow "pytest*" \
  --allow "git diff*"

The agent runs in your current directory and works with any tool-capable model LLM knows about — gpt-5.5, Claude Opus, Gemini 2.5 Pro, even local models via llm-ollama or llm-llama-cpp.

The Bottom Line

llm-coding-agent 0.1a0 is an alpha. Simon calls it "slop-alpha." It's not ready to replace your existing coding agent workflow. The tool suite is minimal compared to Claude Code's MCP integrations or Aider's Git-aware refactoring. There's no multi-file editing, no repo map, no automated test-and-fix loop.

But the direction is right. The design philosophy — model-agnostic agent loop, plugin-extensible toolbox, queryable conversation history — is the same approach that made LLM itself successful. The question is whether the plugin ecosystem rallies around it. If tool authors start shipping LLM toolboxes alongside their existing integrations, the coding agent gets richer without any core changes.

For now, it's worth installing and testing. Run it against a small project with a local model. Watch how the approval flow works. Query the logs after to see what it did. The experiment is the point — and Simon, true to form, shipped the experiment publicly on day one.

Links

• Blog post: llm-coding-agent 0.1a0
• GitHub: simonw/llm-coding-agent
• PyPI: llm-coding-agent
• LLM library documentation