600 Lines of Python: Building a Coding Agent Runtime with Loops, Sandboxing, and Subagents

The Problem Is Usually the Runtime, Not the Model

When AI coding agents fail, most people's first instinct is to blame the model. But a developer who shared their experience on Reddit offered a different take: more often than not, the problem lies in the runtime itself, not the large language model. Acting on this insight, they wrote a framework-free coding agent runtime in roughly 600 lines of pure Python and open-sourced it.

The project has a clear focus — it's not yet another bloated agent framework, but a lean, transparent, and controllable execution kernel. It's compatible with the OpenAI standard API, so it works seamlessly with OpenRouter, local models, or the official OpenAI API. For developers who want to understand how agents work under the hood without getting locked into a heavyweight framework, this kind of minimal implementation is genuinely instructive.

Core Design: A Robust Execution Loop

The skeleton of the entire runtime is a classic agent loop: prompt → tool call → repeat. This pattern isn't new — what demonstrates real engineering craft is how it handles errors and edge cases.

One of the author's key design principles is: treat tool calls as untrusted input. This means that when the model returns malformed JSON or hallucinates a nonexistent tool name, the session doesn't crash. This matters enormously in production — LLM outputs are inherently nondeterministic, and a robust runtime must assume the model will make mistakes, then recover gracefully rather than aborting the task.

This "defensive" approach to tool handling is precisely what separates a toy demo from a usable tool. Many failed agent experiences trace directly back to a runtime with zero tolerance for unexpected model output.

Security Isolation: OS-Level Sandboxing

Letting an agent execute bash commands is a double-edged sword: it dramatically expands the agent's capabilities while introducing real security risks. This project invests meaningfully in the security layer.

For command execution, it offers allow / ask / deny three-tier permission control, with the ability to recognize compound commands to prevent privilege escalation through command chaining. It goes further by introducing OS-level sandbox isolation:

• macOS: uses Seatbelt
• Linux: uses Bubblewrap

The sandbox constraints are strict — network access is disabled, and file writes are restricted to the project directory only. This means that even if the agent executes a dangerous or erroneous command, the blast radius is contained and controllable, with no impact on the rest of the system or unauthorized outbound network requests. Compared to implementations that run shell commands completely unguarded, this is a responsible engineering trade-off.

Seatbelt is a sandboxing mechanism built into macOS (underlying interface: sandbox_init) that uses Scheme-style policy files to describe which system calls a process is allowed or denied — commonly used for macOS permission management of third-party apps. Bubblewrap (bwrap) is a low-privilege container tool on Linux, originally derived from the Flatpak project, that can create isolated namespaces without root privileges, restricting filesystem views, network access, and process capabilities. Both are OS-native mechanisms — lighter than Docker, with minimal startup overhead, making them well-suited for dynamically creating and destroying isolated environments per command execution. This also explains why the author chose not to use Docker: given that OS sandboxing already provides sufficient security, introducing containers would significantly increase deployment complexity and startup latency.

Context Window Management and the Subagent System

The context window is a core bottleneck in every agent system. The author designed a cap / strip / drop / compact combination strategy to manage information within a limited context length — truncating, stripping, dropping, and compressing in concert to preserve critical information while controlling token consumption.

One noteworthy detail is late injection: by injecting content at the right moment, prefix caching can still take effect. This is a concrete performance optimization — prefix caching significantly reduces latency and cost for repeated requests, while improper context concatenation invalidates the cache, throwing away those gains entirely.

The project also includes skills, todos, JSONL-format session logs, and disposable subagents. The subagent mechanism allows the main agent to spawn temporary, independent execution units to handle subtasks, which are destroyed upon completion. This helps isolate the context of complex tasks and prevents the main session from being polluted by irrelevant information.

Prefix caching is an optimization feature offered by major LLM inference services: when multiple requests share the same beginning (prefix), the server can reuse already-computed KV Cache, dramatically reducing TTFT (time to first token) and billable token count. OpenAI, Anthropic, Google, and other platforms all support this feature. However, prefix caching is highly sensitive to context concatenation order — if dynamic content (e.g., timestamps, real-time status) is inserted at the head of the message list on every request, cache hit rates drop to zero. The essence of "late injection" is deferring dynamic content insertion to as late a position as possible, keeping the earlier portion of the message list stable, so the caching mechanism remains effective. For long conversations or high-frequency agent tasks, this optimization can yield meaningful savings in both cost and latency.

What Was Deliberately Left Out

The author's restraint in defining the project's scope is equally worth recognizing. They explicitly list what this runtime does not include:

• Docker: no containerization, relying instead on OS-native sandboxing
• Production UI: this is a kernel, not a finished product
• Evals: no out-of-the-box evaluation framework

This "do less" philosophy is what keeps the project at 600 lines. It positions itself as a readable, modifiable, learnable reference implementation — not a universal platform trying to cover every scenario. For developers who want to deeply understand agent runtime mechanics, this codebase sits right in the sweet spot of "completable and comprehensible."

Takeaways for Developers

The most valuable thing about this project may not be the code itself, but the judgment behind it: when an agent underperforms, examine the runtime first before blaming the model. Tool fault tolerance, permission controls, sandbox isolation, context management, cache-friendliness — these engineering details collectively determine the reliability ceiling of an agent system.

The author ends the post with two open questions for the community: if it were you, what would you prioritize adding, and what would you cut? This reminds us that agent runtime design is full of trade-offs, and there's no single right answer. For teams building similar systems, this 600-line open-source implementation is worth studying as a starting point.

Repository: https://github.com/shrinidhi-mahishi/coding-harness