Every "best AI coding agent" list ranks the same six tools in a different order, and they are all defensible. We have run our own work through most of them and cannot reliably tell them apart on ordinary tasks - which suggests ranking is measuring the wrong dimension.
What actually differs is how they fail. Pick the failure you can tolerate and the choice makes itself.
The five ways an agent fails you
| Failure | What it looks like | Who it hurts |
|---|---|---|
| Runs out of context | Forgets what it decided ten steps ago; re-reads what it already read | Large repositories, long tasks |
| Confidently wrong | Finishes, reports success, and the change is subtly incorrect | Anyone without tests |
| Asks too much | Stops for approval on every command until you stop reading them | Flow, and eventually safety |
| Asks too little | Does something destructive you would have refused | Everyone, once |
| Costs unpredictably | A routine task produces an unexplainable bill | Anyone on a budget |
Which of these have you actually hit?
Most people who say a tool is "bad" have hit exactly one of these and generalised. That is fair enough as a personal verdict and useless as a recommendation, because the next person's binding constraint is a different row.
If you have hit none of them yet, you have not used one long enough to have an opinion worth acting on - which is fine. Use the free tier of two and find out which row you land on.
Matching the tool to the failure
If you keep hitting context limits
You want a harness that summarises and re-reads carefully, not a bigger context window. A bigger window delays the problem and multiplies the cost of every turn while it does.
If it is confidently wrong
You want an agent that runs your checks and reports honestly - and you need something for it to run. No agent can verify work in a project that cannot verify itself.
If the permissions annoy you
Look for granular, memorable permissions rather than an all-or-nothing switch. The tools that only offer "ask always" or "allow everything" push everyone to the second one.
If the bill is the problem
Measure input tokens per task, not the model's list price. This is where the money goes, and it is a harness property, not a model one.
The twenty-minute evaluation
Do not read another list. Do this instead.
- Pick one task from your real backlog that you can verify - it has a test, a build, or an obvious visual result.
- Run it on two candidate tools, each from a fresh session, with no special preparation.
- Record: did it finish, was it correct, how many input tokens, how many times did it stop to ask.
- Then run a second task that is deliberately vague. Watch what each one does when the goal is underspecified - that is the behaviour you will live with.
Where we land on our own list
We build W1, so here is the same treatment applied to us. On unpredictable cost we are strong, because that is the row the whole product is built around. On asking too much and asking too little we are reasonable - permissions are granular and remembered.
On running out of context we are better than we were and not finished: our own changelog is largely a record of fixing that row, which should tell you it needed fixing. And on confidently wrong, nobody has solved it - we run your checks and report what actually passed, which is mitigation rather than a cure.
If your binding row is model quality on genuinely hard problems, Claude Code is the stronger tool and we say so on that page too.
Did that land?
Three questions.
Why are "best agent" rankings weakly useful?
A single ordering hides the dimension that actually decides it for you. Two people can be right about opposite rankings because they hit different failure modes.
You keep running out of context on a large repo. What helps most?
A bigger window postpones the wall and makes every turn more expensive on the way there. Deciding what not to resend is the actual fix.
What is the most revealing test in an evaluation?
Well-specified tasks make everything look competent. Ambiguity separates them, and ambiguity is most of real work.
Sources
- The failure taxonomy here is drawn from our own dogfooding logs and user reports while building W1, September 2026. It is a practitioner's list rather than a study.
Run the twenty-minute test on us
Free during beta, no card. If a different agent does your real task in fewer tokens, use that one.
Download free beta