My MSI Claw had a controller problem. I gave Mercury 3 SSH access and described it. About 20 seconds later, it had a diagnosis. Another 20 seconds, and I noticed the device was already rebooting. It came back and the controller worked. That caught my attention.
I first tried Mercury when Inception was just getting started. In my 2025 test of Mercury Coder Small, I measured around 370 tokens per second. That was fast, though below the advertised 737. The model was less impressive at following a chess game: it averaged about ten moves before breaking the game loop.
I was intrigued by diffusion models and hoped the intelligence would catch up with the speed. Mercury 3 feels like a substantial step in that direction. I put it through my LLM Chess and is-prime evaluations and brought it into a much larger Home Assistant engineering project alongside two other models.
Inception's approach uses diffusion: roughly speaking, it refines groups of tokens in parallel rather than generating the whole response strictly one token at a time. The company advertises 1,068 output tokens per second on NVIDIA GPUs, a million-token context, and benchmark performance competitive with speed-oriented models such as GPT-6 Luna and Claude Haiku 5.5.
As of October 2026, the standard API price is $0.20 per million input tokens and $0.70 per million output tokens, with a 50% launch discount - this per token price directly targets OpenAI's blockbuster Luna.
A controller fix in about 40 seconds
The MSI Claw is a handheld gaming PC running Linux/Bazzite setup never intended by the manufacturer. I keep a repository for its configuration and have a history of giving agents SSH access to fight the bugs that crop up.
After boot, the built-in controller was showing up as an Xbox controller instead of the Steam Controller I had configured. My Steam Controller shortcuts no longer worked. Switching to desktop mode and back to Steam Big Picture temporarily fixed it. The handheld assistant, which I used to change how the controller identified itself through a long press on the quick-access button, wasn't working in Big Picture either. Something in that stack had gone wrong.
I explained the symptoms to Mercury in pi. It moved through the investigation so quickly that I could watch each step without losing the thread. It waited for the device to come back and checked the result. I suspect Luna would still have been looking through logs at that point given my past experience.
My first impression was close to the advertised 1,000 tokens per second. Later, though I lost that light speed sensation - today OpenRouter stats showed around 230 tokens per second - that's not far from other smaller models and kills the experience. I suspect capacity not matching the high load happened.
With slower agents, I often give them a substantial job, switch to something else, and come back to review what they did. That works, but I have to get the problem back into my head. The Claw session offered a glimpse of a different rhythm: ask, watch, correct, and continue while I'm still thinking about the same problem.
Three models, one real Home Assistant project
My apartment runs on a Home Assistant setup that has grown into a substantial engineering project: lighting automation, device integrations, UI, supporting scripts, and tests for the infrastructure around them. The test suite had 86 modules, around 37,500 lines, and 1,138 collected cases. Some tests needed a Home Assistant sandbox; others exercised timing, cleanup, and interactions between components. The challenge was to make the suite leaner and faster without removing the checks that keep the system trustworthy.
I used the persistent agent-team setup I described in an earlier article. In short: named Pi sessions communicate with each other, and I can follow and direct them in Herdr. The coordinator split the work, integrated the results, and kept notes; a separate QA agent checked the work. Both used GPT-6.1 Sol. The three developer sessions used Luna, Mercury, and Haiku:
| Developer | Original assignment | Collected test cases |
|---|---|---|
| GPT-6 Luna | 31 modules | 574 |
| Mercury 3 High | 22 modules | 302 |
| Claude Haiku 5.5 | 33 modules | 262 |
I asked the coordinator to keep track of their work and be ready to assess it. This was a real shared project, with different assignments and some work later redistributed, rather than three models racing on identical tasks. The detailed project records and the assessment aren't public yet.
Mercury found that tests were repeatedly regenerating lighting configuration when they didn't need to. The team removed that repeated work while keeping checks for the full pipeline.
The team brought the ordinary test run's median wall time from 206.18 seconds to 110.13 seconds, measured over three serial runs at each point. Collected cases went from 1,138 to 1,131. Across 67 production Python modules in the measured scope, the exact covered and missing line and branch sets stayed the same. A separate full run against isolated Home Assistant and Docker passed all 1,131 cases in 56 minutes and 44 seconds, with captured state restored. These are team results; I can't attribute the entire speedup to Mercury's investigation.
What the review caught
In a shared exercise, Luna and Haiku spotted a test that could pass even if a session timeout interrupted work too early. Mercury missed it, then added a check after the gap was pointed out. Its first patch dropped another assertion, which review restored. Mercury also claimed an exhaustive review while missing a five-function module.
The coordinator's final assessment nevertheless chose Mercury as its preferred developer among the three sessions for small, specified tasks, with QA reviewing the actual diffs. It credited Mercury's validation-cost work and its willingness to make precise corrections. It considered Sol QA the strongest assurance role. Luna had the largest original assignment and made valuable findings; Haiku contributed useful UI work. All three needed corrections. The recommendation is the coordinator's judgment based on this project, and the notes give it something more concrete to judge than a few impressive answers.
The team later reviewed whether the lighting tests reflected what I actually wanted the lights to do, and updated tests and documentation.
My chess and prime evaluations
I've maintained LLM Chess for years. Models play multiple-turn games through a set of actions, and the evaluation tracks how they follow instructions as well as how well they play. Early models often couldn't get through a game. Mercury 3 was different.
On October 28, Mercury 3 High reached an estimated 1,308 Elo over 62 games. Look at the company it keeps on the leaderboard:
| Model and setting | Estimated Elo | Completion tokens per move | Estimated cost per game |
|---|---|---|---|
| GPT-6 Sol High | 1,311 | 1,379 | $1.405 |
| Mercury 3 High | 1,308 | 15,613 | $0.483 |
| GPT-5.6 Terra XHigh | 1,293 | 2,660 | $3.324 |
| Claude Opus 5 Adaptive High | 1,285 | 4,079 | $7.561 |
| GPT-6 Luna Max | 1,219 | 5,612 | $0.252 |
| Claude Haiku 5.5 High | 1,143 | 1,808 | $0.081 |
Mercury is sitting next to much more expensive models, while its game costs less. That is a fascinating result for a model whose predecessor struggled to finish. Its rating has an uncertainty of about 126 Elo points, so I wouldn't make much of a few points' difference in the table.
Then look at the tokens: 15,613 per move, more than eleven times Sol's figure. The low token price makes a big difference to the bill, but Mercury can generate an awful lot of those tokens. It completed every game under the benchmark's duration metric, though the runner also recorded 265 wrong actions and 33 wrong moves that it could recover from.
My other synthetic evaluation, is-prime-eval, asks a model without tools whether a number is prime or composite, then checks the answer deterministically. In Mercury's provider-default run across 360 numbers of 4-15 digits, it got 247 correct (68.6%). Of the 113 failures, 105 were truncated responses and eight were wrong labels. I didn't set an evaluator completion cap; I don't know what caused the truncations.
That run used about 8.26 million completion tokens and the provider reported $2.89 in cost. In a separate 270-case, 7-15-digit slice, Mercury used about 8.15 million total tokens, versus 0.99 million for Luna High and 0.43 million for Haiku High. This is a different task and setup from chess, but the appetite for tokens shows up again.
I noticed the overthinking much more clearly in these synthetic tasks than in the coding work. A model can draw an SVG of a bird riding a bicycle in a single prompt; I want to see it handle an ongoing chess game or a messy engineering task, with rules, consequences, and corrections. Neither evaluation is a universal intelligence meter, but each gives me more to look at than a polished first answer.
What gets slow next?
When model generation gets faster, everything between calls becomes more visible: starting tools, copying files, waiting for tests, and reviewing the result. The Home Assistant sandbox run took 56 minutes. Faster output doesn't make that run finish sooner.
I wonder how much attention will shift to the stack around agents. If an agent keeps waiting for Python startup, shell scripts, or tests, fast tokens won't make the whole loop instant.
Speed itself is becoming a product choice beyond Mercury: Anthropic's fast mode offers higher output throughput for supported models at premium pricing. I care about how quickly I can get a useful, checked result, including the time spent on tools, tests, and corrections.
These days I find it hard to tell models apart from experience alone. One session fascinates me; the next disappoints. That goes for expensive models too: today I found myself disappointed more often while using GPT-6.1 Terra, a substantially more capable and expensive model.
If the differences in output are hard to judge, speed and cost become compelling reasons to pick one over another. I'm still discovering Mercury, but that Claw fix showed me what a fast loop can feel like when it works.
I would like to try Mercury in GitHub Copilot or Cursor too: in practice, your choice is often limited to whatever is in the model picker.
Top comments (1)
The throughput drop from ~1000 to ~230 tok/s is the part that would worry me most — diffusion latency feels magical until shared capacity shows up. Was that OpenRouter routing variance, or did you check against Inception's own endpoint?
Also on the 56-minute Home Assistant run: how much of that was Mercury tokens vs wall-clock on tests and tool calls? If most of it was the loop overhead, that's actually the strongest argument you make — even 5x token speedup barely moves total time when the loop is test-bound.