Mercury-3 vs GPT-6 Luna: What Does Speed Actually Buy?
Summary
A thousand tokens a second is the pitch for Mercury-3. If I am waiting for an AI to write code, that sounds like exactly what I want. The useful question is what that speed buys once the model has to build something.
I gave Mercury-3 and GPT-6 Luna the same job in Oh My Pi: make a Cookie Clicker game from scratch, use my Kagantic branding, and test it repeatedly. No subagents. Mercury generated text much faster. Luna produced the game I actually preferred, with fewer requests and a lower estimated cost.
This was not a controlled benchmark. It was one interactive coding task, with the recorded harness dashboard and the finished games as evidence. The result is still useful because it shows why generation throughput alone does not describe a coding session.
The speed claim is real, but it is not the whole loop
Mercury's headline is extraordinary generation speed. In this test I saw roughly 400 tokens per second at best. The recorded average was 325.9 tokens per second, against 64.1 for Luna. That is about five times Luna's rate, even though it is far below the thousand-token pitch.
The text-generation speed is real. But a coding agent does not wait for one big answer. It writes something, runs a tool, reads the result, and comes back to the model. Each new response also has a wait before the first token arrives.
In this dashboard, that wait averaged 3.8 seconds for Mercury and 1.1 seconds for Luna. Once the wait repeats, the number of requests starts to matter: Mercury made 49, while Luna made 27.
Mercury's average request was still shorter overall, 4.9 seconds against 6.2 seconds. But the generation rate cannot be turned into a claim that the whole coding session was five times faster.
| Recorded metric | Mercury-3 | GPT-6 Luna |
|---|---|---|
| Average generation | 325.9 tokens/s | 64.1 tokens/s |
| Best observed | ~400 tokens/s | — |
| Average time to first token | 3.8 s | 1.1 s |
| Requests | 49 | 27 |
| Average request duration | 4.9 s | 6.2 s |
| Output tokens | ~88,000 | ~16,000 |
| Estimated run cost | $0.06 | $0.02 |
| Estimated cost per request | $0.0012 | $0.0008 |
These dashboard values are estimates from my recorded runs, rounded as displayed. They are not a matched benchmark of providers or compute budgets.
What the extra output built
Mercury produced about 88,000 output tokens; Luna produced about 16,000. That is more than five times the output. If the extra text had produced a more elaborate game, there might be a reason to pay for it.
Mercury's game has the basics. You click the cookie, buy buildings, and get upgrades. It works as a starting point, but playing it kept giving me a minimum-viable-product feeling. The ingredients were there; the fun was not quite there yet.
Luna's version adds milestones, click streaks, feedback as you play, and sound effects. Those small responses make clicking feel like progress rather than just changing a number. It is the version I could genuinely see myself playing during free time in computer class.
That is a quality judgment from playing both games, not a measured feature score. The extra Mercury output did not produce the game I preferred in this test.
The public benchmarks cut both ways
Inception's launch chart would make Mercury the favourite. On SWE-Bench Atlas, it lists Mercury at 51.1 and Luna at 33.3. On DeepSWE version one, it lists 46.3 against 37.8.
Those are wins for Mercury, and I am not ignoring them. They are also Inception's own results, with the models labelled medium reasoning, not an independent rerun.
For app-building, Vals AI's Vibe Code Bench is more relevant. It asks models to build web apps from scratch and then checks whether the features work. On Vibe Code Bench v1.1, Mercury gets 60.9% and Luna gets 81.7%. Both use OpenHands.
Mercury gets credit on the same leaderboard for cost and duration: $0.63 per test and 9 minutes 27 seconds, compared with $1.35 and 37 minutes for Luna. On that test Mercury really is cheaper and faster. It just does not reach Luna's app-building score.
The settings are not identical. Inception says medium reasoning. Vals' model pages list high as Mercury's default and max for Luna, and warn that benchmark-specific parameters and providers can differ. The tasks and agent setups differ too. These results should not be merged into one universal score.
The local game and the public benchmarks tell a consistent but limited story: Mercury can be fast and cheap on some evaluations, while the finished application can still be less capable. One Cookie Clicker game does not disprove a benchmark, and one vendor chart does not decide which model is better for interactive work.
What the run cost
The harness estimated about six cents for Mercury's run and two cents for Luna's. The amounts are small, so the single bill is not the main concern. The result is that I preferred Luna's game, and it came with the lower estimate.
Mercury also cost more per request in this run: about $0.0012, compared with $0.0008 for Luna. Looking inside the cost split, output was Mercury's biggest category. For Luna, cache reads were the biggest category.
That is a cost split, not a token count. Both models mostly read cached tokens. Generating more text does not automatically mean more useful work for the money.
The Vals result is a separate record. Its listed cost and duration are not the same as my local dashboard, and the tasks differ. Both point in the same direction only when read with their own limits.
Verdict
I would not choose Mercury-3 over Luna for interactive coding. Luna gave me the richer game, with fewer requests and a lower estimated cost in my test.
The case where I would recommend Mercury is massive batch output, when you do not need a fast return and quality is not the priority. That is a different job from sitting beside an agent waiting for working software.
When a model advertises its speed, follow that claim all the way through the task: how long does it wait, how many times does it come back, what does it build, and what did the result cost? That is the comparison I would use to choose my next coding model.
Sources and scope
- Inception: Introducing Mercury-3 — vendor-reported SWE-Bench Atlas and DeepSWE v1 results, labelled medium reasoning, 19 October 2026.
- Vals AI Vibe Code Bench v1.1 — independent app-building evaluation, OpenHands, updated 24 October 2026.
- Vals: Mercury-3 model page and GPT-6 Luna model page — default settings and benchmark warnings.
This article is compiled from my recorded Oh My Pi runs and the project's source notes. The two models did not necessarily use matched providers, reasoning effort, or compute budgets. The games were judged by playing them, not by a formal entertainment score. The dashboard figures are rounded harness estimates, not invoices, and the public benchmark results are reported separately rather than combined.