I built a coding agent in six hours. It argues with me the way I argue with myself.

When I write code well, it's because I argued with myself first. One half of me writes it. Another half attacks it. A third decides whether it ships.

Every AI coding tool I tried gave me the first half. So I built mew, a harness that runs all three, and it took six hours.

It's now how I write code. Against Claude Code and Pi, it has been better for me. That's my experience from using it every day, on my own work, and I'll be careful about what it does and doesn't prove at the end.

Decision 1: split the writer from the critic and the judge

mew doesn't wait to be asked for feedback. While I work, other agents run alongside me and push back on my decisions. They aren't a list of if-this-then-that rules. They read what I'm doing and challenge it, which is what I'd be doing to myself in my head.

The critic and the judge are separate on purpose. When a run changes files, your checks run first, and a failure goes back to the model as a repair request. Then a second model, a different one, reads the real diff. My reasoning is that a model reviewing its own work tends to agree with itself, and a different one has different blind spots. I haven't measured that.

Here's a real run on tunyt's web app. The checks passed and the review passed. The final answer still opened with "Partly correct. I wouldn't ship it as is", and said it had read the code and never run it.

That's the part I care about. Typecheck tells you the types still line up and lint tells you the code follows the rules. Neither runs the change. Confirming this fix means liking an event, coming back hours later, and looking at the count and whether the like is still selected. mew said exactly that, in the output, without me asking.

Every run ends in one of five statuses: verified, unverified, verification_failed, failed or done_no_changes. None of them is a bare "done".

Decision 2: I set the budget before the work starts

I like to decide how many tokens a kind of task deserves, and I want the tool to respect that. So mew sorts each request by difficulty without spending a model call on it. Easy requests go to a fast chain of models, hard ones to a strong chain.

There's also a hard ceiling. At 70% of the budget mew warns me, and when the budget is gone it makes one last call with no tools, so the work done so far becomes an answer and not a bare failure.

I also use it to divide a task and rethink how I'd approach it before any code gets written. Having to say how much a task is worth turns out to change how I plan it.

Decision 3: run on the cheapest models and make the context do the work

Most of this runs on small, cheap models, DeepSeek V4 Flash and GPT-5.6 Luna among them. The aim is the best output the cheapest models can give. My bet is that a cheap model given a tight, clean context does well, and that a lot of what looks like a model's weakness is really a context problem. It's a bet. I haven't isolated it.

So most of mew is about the context. The surprising part is where the tokens go. A long run sends the whole conversation again on every call, so a tool result isn't paid for once, it's paid for on every call after it. In the run above, one file read cost 1,922 tokens and was re-sent 15 times, which is 28,830. Half of that run's input, 52%, was earlier tool results travelling along again. A file's real cost is its size times the number of calls that follow it.

So mew keeps a map of which lines of each file are already in context. Ask again and you get only what's new, or a diff if the file changed. It finds code with search and outlines before reading anything, and a read-only scout on a cheap model goes first, so the main model starts from findings. A cold index of a large repo takes 13.7 seconds and a warm one 1.2.

Caching works on the start of the conversation, so one early change re-bills everything after it. That run re-billed 25,381 tokens because the prefix changed. The Codex backend only caches when you send session_id and prompt_cache_key, so mew sends both and warns if a model isn't caching. I also cut the system prompt from about 3k tokens to about 0.7k. That run: 21 calls, 418.8k tokens in, 85% cached.

Decision 4: any provider, and say so when it switches

mew runs Claude, GPT and Codex, DeepSeek, and anything behind an OpenAI-style API. I pick which model fills which role: fast, strong, review, summarise.

The run in the screenshot was routed to the strong model, which hit a 429 rate limit. mew said so and finished the work on GPT-5.6 Luna. Nothing fails over silently.

Decision 5: the rules are code

"Please don't touch my SSH keys" is a request, and a model can forget a request. Editing a file the agent hasn't read this session is refused, and so is editing one that changed on disk after it was read. File tools can't leave the folder you started in. Shell commands are scanned for paths before they run, and on macOS an OS sandbox sits under all of it.

Every path:line in the final answer is checked against your real tree too. A file that doesn't exist goes back for one correction, and anything still unverified shows up as a warning. That's the sentence in an answer people believe fastest, so it's the one worth checking.

What I haven't proven

I built this for one person, and I'm that person. Six hours of work that suits how I think doesn't mean it suits everyone, and "better than Claude Code" is my daily experience, not a result. Nobody has run a head-to-head benchmark against other harnesses. There's a bench you can aim at your own tasks and models, and 224 offline tests.

It also has gaps. There's no plan mode, no image input and no structured JSON output for CI, and the kernel-level sandbox is macOS only.

Six hours was enough because I already knew what I wanted it to argue about.