Field notes on AI coding agents: what they cost, where they break, and what shipped. Figures without a traceable source were cut.
Written with AI assistance. Figures without a traceable source were cut before publishing.
Pi’s system prompt and its 4 tool descriptions come to under 1,000 tokens, which is the whole reason to like it. The tools are read, write, edit, and bash. That is the entire set, and the fourth one is why this article exists.
Pi ships with no sandbox. The bash tool executes with exactly the file, process, network, and credential access of the account that launched it, which on a normal developer machine means everything you can reach, the agent can reach.
Here is what the 4 tools actually touch, how to wall them off without giving back the context savings, and where the minimalism stops paying for itself.
Most agent frameworks arrive heavy. Multi-megabyte system prompts and long tool schemas consume a meaningful slice of the context window before you have typed anything, and on a small model that slice is the difference between the agent seeing your codebase and seeing part of it.
Pi’s answer is to ship almost nothing. Under 1,000 tokens for the prompt and all 4 tool descriptions is roughly the length of this section, and every token you save there is a token available for the actual problem.
The 4 tools are chosen well. read gets file contents, write creates or overwrites, edit modifies strings in place, and bash runs shell commands. Three of those are narrow. The fourth is not a tool so much as an escape hatch to the entire operating system, and it is doing the work that 20 tools would do in a larger framework, which is exactly why the total comes in under 1,000 tokens.
That is the trade, stated honestly. Pi is small because bash is general, and bash is general because it is unbounded.
Out of the box, Pi does not run in an isolated partition. It inherits the same permissions as the host user, which is a sentence that reads as a footnote and behaves as the main event.
Consider what the account running your editor can reach right now. Your SSH keys. Your shell history, which probably contains at least one command with a token in it. Your cloud CLI configuration, already authenticated. Every repository on the machine, including the ones belonging to clients. Whatever is mounted. The agent has all of it, not because it was granted anything, but because nothing was withheld.
The failure mode people imagine is a malicious agent. That is probably the least likely one.
The realistic failure is an agent with a working directory set one level too high, or a generated command whose glob matches more than the model expected, or a cleanup step that runs before a check that was supposed to gate it. None of those require bad intent from anyone. They require one prompt to be slightly ambiguous, which is the normal condition of prompts.
Speed compounds this. The agentOS runtime cold-starts in 4.8 milliseconds, so there is no interval in which you notice something is wrong and intervene. The gap between pressing Enter and the command completing is shorter than the gap between reading the output and understanding it.
I think this is why unsandboxed agents feel safe for a long time and then do not. Nothing accumulates gradually. The environment is fine until one command, and then it is not fine, and the recovery cost is measured in how good your backups were rather than in how carefully you were watching.
The good news is that the fix costs almost nothing in the currency Pi cares about. A container does not consume context.
Lightweight virtual kernels cold-start in about 4.8 milliseconds and hold memory between 22 and 131 megabytes, which is close enough to native that the isolation is effectively free at the timescale a human works at. Compared to a traditional VM this is not a compromise, and compared to running Pi directly on your user account it costs you a startup delay you cannot perceive.
Mount narrowly. The container should see the project directory and nothing above it, because the entire benefit disappears the moment someone mounts a home directory for convenience. If the agent needs a file outside the project, that is a decision worth making explicitly rather than a permission worth granting permanently.
Credentials go through a pluggable secret source rather than a file in the project. A password manager integration or an equivalent external interface keeps plaintext tokens out of local configuration entirely, which matters more with an agent than without one, since an agent that reads files to build context will eventually read the file where you left a key during a rapid prototyping session.
Validation belongs in code rather than in judgment. Deterministic scoring checks are the cheap version of this: verify that the expected tools were called with the expected parameters, inspect the contents of generated files, match keywords in the output. Those checks are boring and they run in milliseconds, and they catch the class of error that a language model is structurally bad at catching in itself, which is a confident wrong answer.
For anything that has to be verified against a real environment, agent-device gives Codex, Claude Code, and Cursor agents CLI access to open applications, click controls, and assert on state, while saving screenshots, logs, and performance traces as evidence. The evidence is the part that matters. An agent reporting success is a claim, and a screenshot with a trace behind it is closer to a fact.
Pi is not a general-purpose production runtime, and treating it as one is the mistake that its pleasant minimalism invites.
Multi-step quality pipelines hit the wall quickly. If your workflow needs automated linting, test execution, and pull request generation wired in, 4 tools means you write the glue yourself, and the time you spend on integration is time not spent on the product. Tools like no-mistakes exist for that shape of problem, with fork routing and automatic pull requests handling the parts you would otherwise assemble by hand.
Skill discovery is a similar gap. skill-mcp ships 5 tools plus a prompt mechanism that actively guides an agent toward finding and using the right skill, which is a capability Pi does not attempt. That is arguably the correct decision for Pi, since guided discovery is exactly the kind of thing that costs tokens in the system prompt, and the whole premise here is that the prompt stays under 1,000 tokens.
Decide by asking what fraction of your work is orchestration. If the answer is most of it, a bare engine will cost more than it saves. If the answer is that you mostly want a model that can read and change files in a project you already understand, Pi is close to ideal, and the 4-tool surface is a feature rather than a limitation.
The dangerous belief is that a small tool is a safe tool. Those are unrelated properties, and Pi is a clean demonstration of the gap.
Its lack of sandboxing is not an oversight to be patched in a later release. It is a design position, and a defensible one, because a sandbox is a choice about your environment rather than about the agent, and Pi has taken the view that this choice belongs to you. Accepting that view means actually making the choice instead of inheriting the default, which is no wall at all.
Keep the prompt small and the toolset tight. Put a wall between bash and your file system before you run anything twice.
Also readable on Telegraph.
Read next
Part of ai-coding-field-notes — field notes on AI coding agents. Found something wrong, or shipped something similar? Open an issue — corrections are the point.