Picking an agent harness and models on Cursor
Our model access has to come through Cursor. That is a company rule, not a preference. satelle runs coding agents through a workflow and does not mind which agent does each step, so the real question was which harness to run and which models to put where. This is what we tried and how it went.
What a reviewer does
In satelle, every change passes reviewers before it moves on. A reviewer reads the change and either accepts it or blocks it. A good one catches real defects and leaves valid work alone.
How we scored them
We keep a fixed set of review cases where the right answer is already known, and every reviewer runs over the same set. Ten cases ran this time, five with a real defect and five valid changes. Four more had gone out of date and are being repaired, so they sat this round out.
For each reviewer we counted defects caught, valid changes wrongly blocked, defects let through, time and cost.
Results
| Model | Harness | Caught | Wrongly blocked | Let through | Time | Cost |
|---|---|---|---|---|---|---|
| Composer 2.5 fast | pi on Cursor | 5/5 | 0 | 0 | 5m11s | in Cursor plan quota |
| Composer 2.5 fast | Cursor CLI | 5/5 | 0 | 0 | 7m28s | |
| GLM 5.3 flash | pi on OpenRouter | 5/5 | 0 | 0 | about 10m | $0.056 for 10 |
| MiniMax M3.1 flash | pi on OpenRouter | 5/5 | 0 | 0 | about 12–14m | $0.21 for 10 |
| GPT 5.6 sol fast | pi on Cursor | 5/5 | 1 | 0 | 4m27s | |
| Opus 5.5 fast | pi on Cursor | 5/5 | 2 | 0 | 3m47s | |
| Opus 5.5 fast | Cursor CLI | 5/5 | 1 | 0 | 7m25s | |
| Haiku 5.5 | Claude CLI (subscription) | 5/5 | 2 | 0 | 5m51s | $0.12 for 10 |
| GPT 5.6 sol fast | Cursor CLI | 4/5 | 0 | 1 |
Nearly every setup caught all five defects. The exception was GPT 5.6 sol fast on the Cursor CLI, which let one through and gave no answer at all on another case. Where they differed was false alarms. Opus, Haiku and GPT on pi each blocked at least one valid change. Composer, GLM and MiniMax blocked none.
GLM gave the same result over two runs, at about 0.6¢ a review.
Grok 4.7 did not make the table. On one real review of a 31KB change it ran for more than 900 seconds and 94 turns through pi on Cursor. It took 306 seconds through the Cursor CLI, and 214 seconds and 23 turns on Grok's own CLI. Opus fast did the same review in 22 seconds and 7 turns.
The harness
pi reaches Cursor through a community-built provider. The provider runs Cursor's own agent backend and hands pi's tools to the model as MCP tools. For short, read-only reviews it works well. We have not yet shown it holds up on long coding runs, and that trial is running now.
With the same model, pi on Cursor was quicker than Cursor's own CLI. On one real review, Opus fast took 22 seconds against 33, and GPT took 35 against 93.
Two fixes made pi dependable when it runs unattended. We turned off its discovery of extensions, skills and context files; before that, one reviewer stayed running for 30 minutes after it had already answered. We also put a limit on how long a stalled model stream can hang.
Cost
On the Cursor plan, Claude and GPT switch to pay-as-you-go once the included quota runs out. A single review on Opus fast cost between $0.38 and $2.20. Composer stays inside the included quota.
Where that leaves us
Composer and GLM tied for best. Both caught every defect and blocked nothing that was valid.
Planning, coding and running the work stay on Opus. Reviewing is a narrower job, and a focused, cheaper model does it well.
Our reviewers today are Opus fast and Composer, both through pi on Cursor.
Ten cases is a small sample. Next we want a bigger set built from real review decisions, results from the coding trial, and a costed comparison of taking a change from pull request to release on a local machine against doing it on a remote server.
To be continued.