I’m more interested in where a model fits in an agent system than where it sits on a universal leaderboard.
A reviewer checking a proposed change has a different job from the agent making that change. A short request differs from a task that needs several decisions, tool calls and corrections.
Flint and Mercury are interesting to me in that context. I want to work out which parts of the fleet they might make better, without pretending that either has already earned every role. Flint is a candidate, not something I’ve deployed. Direct Inception is the intended primary route for Mercury. That is the direction of the plan, rather than a claim that the whole setup has already been tested and settled.
The useful comparison is the work I can hand over, the result I can accept, and what happens in between.
What I have actually used
I’ve used Nemotron Ultra in Hermes a bunch as a reviewer in Fugu. That has given me a more specific view of it than a model card can. It has been useful in that reviewer role, while failing at more complex tasks in my experience.
I want to keep both parts of that sentence. If I only say it has worked as a reviewer, it sounds like an endorsement for jobs I haven’t seen it handle well. If I only say it has failed at complex tasks, I lose the reason I kept using it in a narrower role.
That is personal experience inside a particular workflow. It isn’t a controlled benchmark, and it doesn’t establish what every other person will see from the same model. The harness, task, instructions and available context are part of the experience. NVIDIA has separately documented a Nemotron Ultra pagination failure in a LangChain Deep Agents test and a middleware change that improved that particular test. That is a useful example of harness-specific behavior, not an explanation or a demonstrated fix for my Fugu failures. NVIDIA’s harness example
Using MiniMax and Spacebunny also felt almost seamless as a transition. MiniMax’s M3.1 Flash announcement identifies Space Bunny as an early version of that model, which gives the experience some useful context. It doesn’t turn the feeling into a benchmark. I haven’t established identical reliability or economics across the transition. MiniMax’s announcement
Selective Mistral use as a reviewer is something I’m considering. Mistral documents a read-only audit-agent configuration with editing tools disabled, although bash permissions need separate attention. Qwen Code documents a /review workflow with adjustable effort and support for other models. These are harness options, not evidence that a particular Mistral or Qwen model is an effective reviewer in my setup. Qwen usage in the account is known; its reviewer role isn’t established. Mistral’s agent configuration, Qwen Code review workflow
Give each role a job it can finish
The reviewer experience is the clearest reason I’m thinking about a mixed-model fleet.
A reviewer can be given a bounded question: does this proposed change satisfy the request, and what evidence supports that answer? There is already something concrete to inspect. A builder may have to decide what to change, gather the missing context, make the change and recover when the first attempt fails. Those are different assignments, even when both happen in the same repository.
Each role needs an acceptance condition. A review should identify a real problem or explain why the evidence supports acceptance. A build task should produce the requested change and the checks needed to trust it.
To try a candidate, I want a defined workload, a stable acceptance condition and a record of what it does. Repairs and failures belong in that record.
Flint still needs to earn its place through that process. Recursive describes Flint as a mixture-of-experts model with 40 billion total parameters and 2.5 billion active per token. OpenRouter lists a rate-limited free route, recursive/flint-v1.0:free. That makes it a concrete candidate to investigate, not a free production-capacity assumption. Recursive’s announcement, OpenRouter’s listing
Recursive also publishes local throughput and agentic evaluation results. Its local throughput protocol excludes prefill and uses specified hardware; its agentic evaluations name particular harnesses and time limits. I can use those details to design a test. I can’t put the local speed figure beside a hosted API figure and call that a fair comparison. Recursive’s methodology
Mercury and the route to the model
As of October 28, 2026, Mercury 3 is Inception’s diffusion language model, and direct Inception is the intended primary route for it in this plan. Inception’s launch material lists a one-million-token context window and standard prices of $0.20 per million input tokens and $0.70 per million output tokens. Its launch announcement separately advertises $0.10 and $0.35, respectively. Those are launch prices, not an assumption about the rate a request will receive now. Inception’s Mercury 3 announcement
The same announcement reports 1,068 tokens per second on NVIDIA GPUs. That is a vendor-reported throughput result. It doesn’t establish the latency of my tool calls, the quality of a review, or how long a complete Fugu task will take. It is a reason to try Mercury on suitable work and measure the whole loop. Inception’s performance claim
Keep the route and version in the record
DeepSeek’s October 17 changelog says deepseek-flash resolves to V4.1-Flash-1017, with retired V4 Flash aliases temporarily routed to V4.1 Flash. An alias alone doesn’t identify a stable experiment. I would record the resolved model and date, rather than reuse older benchmark results as evidence for the replacement. DeepSeek’s changelog
GLM needs a different caution. NVIDIA’s current API index lists GLM-5.3, but I haven’t verified the current status of its free endpoint or an official retirement notice. I wouldn’t turn an unverified free-access deprecation into a claim that the model, all deployments, or the separate Flash variant has disappeared. NVIDIA’s model index
The cost of getting something accepted
The price of a token is a starting point for a cost discussion. My decision needs to cover the whole task.
If a cheaper attempt needs another model, review or manual correction, those costs belong to that attempt.
The measure I want is time to an accepted result, alongside the total spend required to get there. That means recording the initial request, tool calls, retries, reviews and escalations. It also means keeping the acceptance standard the same. A faster result that leaves work for me to discover later hasn’t met the same standard.
Caching belongs in that comparison too. An agent workflow can repeatedly send context, but I need to know whether a particular route actually caches that context, what qualifies for a hit, and what the provider charges. I shouldn’t price every request as a cold request if the real workload gets cache hits. I also shouldn’t assume a cache discount just because the conversation contains repeated text.
Reasoning effort needs the same care. Where it is configurable, it is part of the experiment rather than a detail to omit. Comparing a low-effort run against a higher-effort run without saying so would make the outcome harder to interpret. The question is which setting meets the role’s acceptance standard at a useful cost and latency.
For a concrete example, Inception advertises cached input at 90% off its input price. Terra’s API documentation instead separates cache reads from writes: writes cost $1.25 per million tokens for 30 minutes or $2.50 for 12 hours. Prompts with more than 272,000 input tokens have a long-context pricing multiplier applying to the full request. “Cached” needs to mean the actual provider’s billing behavior, not one discount I apply across the fleet. Inception’s caching terms, Terra’s API documentation
Where Terra 6.1 fits in the comparison
Terra 6.1 has public intelligence, cost and task-speed claims worth discussing. OpenAI reports that, at medium reasoning effort, it improves on the previous Terra by 15 percentage points on Agents’ Last Exam at roughly one-third of the task cost. That is a result on a named evaluation, not a measured advantage over every model in this fleet. OpenAI’s Terra announcement
Its standard API list price is $1 per million input tokens, $0.05 per million cached-input tokens and $5 per million output tokens. The model documentation also lists reasoning-effort settings from none through max. Those prices and settings give me a basis for an experiment; the total bill still depends on the workload, generated tokens, caching, long-context conditions and retries. They also shouldn’t be confused with the economics of a private plan or allowance. Terra’s API documentation
For speed, OpenAI reports that Terra at max effort completes Agents’ Last Exam tasks more than three times faster than Astra and Sol. That is task completion under the stated conditions, rather than a fixed tokens-per-second number. It cannot be compared directly with Mercury’s GPU throughput or Flint’s local decoding measurement. OpenAI’s reported task-speed result
I don’t yet have a like-for-like fleet benchmark that supports a universal intelligence, cost or speed ranking. These public results help decide what to test. The comparison I need would identify the exact model and route, keep the workload and acceptance standard stable, and record the settings alongside the outcome.
The public fleet model explorer is a separate external chart, not a benchmark of my local fleet. The overview lists Flint, Mercury 3 and Terra 6.1 without comparable intelligence or task-cost coordinates in its current revision.
| Standard API list price per million tokens | Input | Output |
|---|---|---|
| Mercury 3, direct Inception | $0.20 | $0.70 |
| GPT-6.1 Terra API | $1.00 | $5.00 |
These are the standard prices stated in the reviewed article, not a measurement of task cost; launch rates, cache terms, context length and retries can change the calculation. Throughput, task completion time and intelligence are different metrics and are not ranked here.
The fleet I want to evaluate
The next useful step is a small set of repeatable tasks for each role, with the model, route, settings and acceptance evidence recorded. I’d keep review tasks separate from build tasks, then include a few that require escalation so I can see whether the handoff helps or just adds another round.
I’d want cold and repeated-context runs where the provider supports that distinction. I’d track failures and repairs as carefully as successful first attempts. I’d also keep my observations about the feel of a workflow separate from measured results, so a smooth transition doesn’t accidentally become a performance claim.
That is the direction behind Flint and Mercury for me: a fleet with deliberate assignments and an understandable path when one of them gets stuck. Nemotron Ultra has already given me a useful example of a model having value in a narrower role. MiniMax and Spacebunny have given me a transition that felt easy. Those experiences are enough to shape what I test next, without claiming they settle the comparison.
I want each model to earn the work I give it. The result I care about is something I can accept, at a cost and a pace that make sense for that job.