I no longer think the best AI model is the one sitting at the top of this week's benchmark chart. The best model is the one I trust to finish the work in front of me, in a reasonable time, without creating a larger problem for me to clean up.
In short: benchmarks can tell me whether a model is capable under controlled conditions. Trust tells me whether a particular model, inside a particular agent product, will understand my real objective, respect the boundaries of the job, verify its work and use my time and subscription sensibly. For the cross-context work I do every day, that has become the more useful metric.
Benchmarks answer a smaller question
AI model comparisons often begin with a leaderboard. Coding models get measured against tests such as SWE-bench, which asks an agent to resolve real GitHub issues in existing repositories. That is far more useful than a toy programming quiz, but the original SWE-bench paper still describes a bounded task: take an issue, edit a codebase and produce a patch.
My work rarely arrives in that shape. A typical job might begin with reading an email from a client, continue with interpreting what they really need, move into a WordPress website and perhaps a hosting account, then finish with a billing entry and a drafted reply. The agent has to carry intent across several systems while knowing which actions I authorised and which ones I did not.
A model can be excellent at generating a patch and poor at managing that workflow. It can solve the technical problem while missing the commercial one. It can also produce a correct result so slowly, or with so much unnecessary exploration, that using it costs more of my day than doing the work another way.
That does not make benchmarks useless. They are evidence of capability. They just do not measure the whole working relationship, and the companies publishing them naturally select the comparisons that make their latest release look strongest.
The real test is whether the agent understands the job
Cross-context work tests judgement more than code generation. If a client asks for a website change, I need an agent to work out what belongs in scope, find the right implementation path, preserve unrelated work, test the visible result and leave correspondence as a draft unless I asked it to send. None of those requirements can be reduced to whether a unit test passes.
The hardest failures are often not obvious errors. They are changes that technically work but use the wrong architecture, duplicate an existing source of truth, alter something outside the request or stop after editing a file without checking the rendered page. I explored the same gap in my article about what changed when coding agents began handling real client work.
This is why I distinguish between a model and the product wrapped around it. GPT-5.6 through an API is not the same working experience as GPT-5.6 inside Codex. The desktop agent adds tools, instructions, context management, approval rules and its own way of recovering from errors.
Antigravity and Claude Code do the same. I am not really choosing a model name. I am choosing a model, an agent harness and a commercial plan as one working system.
Mythos proves why spectacular capability can be irrelevant
Recent coverage of Anthropic's Mythos model is a good example. The dramatic version of the story is that an AI hacked a website. I initially suspected that the headline was doing most of the work, but the underlying research is more substantial than that suspicion allows.
Anthropic reports that Claude Mythos Preview can find previously unknown vulnerabilities and develop working exploits in authorised research settings. Its published Mythos assessment describes serious cybersecurity capability and explains why access remains restricted to selected partners. That is impressive work, not something I can fairly dismiss as a staged trick.
It still tells me almost nothing about which agent should handle my next client job. Mythos was tested for vulnerability discovery and exploitation, with a specialist harness, access and objective. It was not tested on the combination of client interpretation, website architecture, billing accuracy, restraint and correspondence that I need.
The problem is not that the security result is false. The problem is the leap from "this model did something spectacular in one domain" to "this is now the best AI model". Capability needs context before it becomes useful evidence.
Trust is reliability in the context that matters
Trust can sound like a vague emotional preference, but it does not have to be. The NIST AI Risk Management Framework puts validity and reliability at the base of trustworthy AI and says the criteria must reflect the system's context of use. That is close to what I have learned through daily use.
For my work, trust accumulates when an agent repeatedly demonstrates five behaviours:
- It understands the actual outcome. It reads between the lines without inventing a different job.
- It chooses sound architecture. It finds the existing source of truth and avoids unnecessary duplication.
- It respects scope and authority. It knows the difference between drafting, changing, deploying and sending.
- It verifies completion. It checks the real result, including the browser or external system when that is where success lives.
- It uses time and tokens sensibly. It reaches a dependable result without endless detours or repeated prompting.
Trust is not blind confidence. I still review consequential work, and I expect an agent to show evidence. Properly calibrated trust means I know where I can let a tool proceed and where I need tighter supervision.
The models I trust now earn it in different ways
At the moment, I trust OpenAI's GPT-5.6 models most for complex, cross-context work. The GPT-5.6 family spans Sol, Terra and Luna, but my preference is not based on OpenAI's launch chart. It comes from watching these models repeatedly identify the right high-level architecture, infer what I am trying to achieve and carry the work through with fewer corrective loops.
That trust has a practical value. I spend less time waiting for the model to emerge from an unhelpful detail, less time restating the objective and less time checking whether it quietly solved a different problem. The models have also been cost-effective across subscription and API use, which matters when agents work through large codebases and several connected systems.
Claude Code remains capable, but I currently trust it less for these workflows. In my experience it is overly verbose, becomes absorbed in detail, and takes much longer to reach the result. Its five-hour usage window compounds that problem. A slow agent is not merely inconvenient when the subscription meter also resets in blocks that do not match an eight-hour working day.
Gemini 3.7 Flash in Antigravity has earned a narrower but very strong kind of trust. Google describes Gemini 3.7 Flash as a workhorse for coding and agents, and that matches how I use it. For a discrete feature, a contained client request or a small change with clear boundaries, it is extraordinarily fast.
My observed speed difference is not a laboratory benchmark, but it is large enough to shape my work. Gemini Flash can feel about five times faster than Codex and close to ten times faster than Claude Code on the small jobs I give it. I do not automatically trust it with the most architectural work, but I do trust it to move quickly when the path is already clear.
I have also used Grok models, particularly Grok 4.2, in both product and API contexts. They produced useful results at the time, but availability and product fit changed. Trust decays when I can no longer build a repeatable workflow around a tool, however capable it looked in a previous release.
Subscription design is part of trust
I sometimes open an AI tool simply because I have subscription tokens left and feel anxious before I assign the task. That reaction is revealing. It means my experience has already taught me that the apparent saving may turn into wasted time, unfinished work or another five-hour window consumed without a dependable result.
Quota design changes frequently, which makes precise comparisons age quickly. I recently valued Codex partly because my account experience appeared to prioritise a flexible weekly allowance. OpenAI's current help material now refers to both five-hour and weekly limits. I would rather correct that detail than preserve a convenient comparison that is no longer accurate.
The broader point survives the change. A professional does not work in neat five-hour bursts. The commercial product needs to let me distribute demanding work across a day and a week, and it needs to make the limits understandable. A generous token count has little value if the agent burns through it slowly or unpredictably.
This is also why API and subscription value cannot be collapsed into a single price. API use gives me explicit per-token costs and control inside applications. A desktop subscription gives me the agent harness, local tools and bundled usage. I judge each combination by the completed result, not the advertised allowance.
A personal trust score is more useful than a leaderboard
I now assess models against my own repeated work rather than trying to crown a universal winner. The method is simple: group jobs by type, use more than one suitable agent, and record what happens after the prompt.
- Completion rate: Did the agent finish the whole job, not just the code edit?
- Intervention count: How many times did I need to redirect or restate the request?
- Elapsed time: How long until I had a verified result?
- Review burden: How much checking and cleanup did the output create?
- Total cost: What did the finished outcome consume in subscription allowance, API cost and my own attention?
That produces a task-specific routing decision, not a fan club. I can give complex architecture and multi-system work to the model I trust most, send well-defined implementation jobs to the fastest reliable model, and keep higher-risk actions behind explicit review. It is the same practical discipline I use when reducing context switching across client workflows.
Trust also remains reversible. A new model can earn more responsibility through repeated success, and a familiar model can lose it after changes to capability, speed, pricing or limits. My article on moving beyond Copilot after its pricing changes is a reminder that the commercial relationship can alter the decision even when the underlying technology remains capable.
The best model is the one that reliably finishes your work
There may never be one best AI model for every person and every task. Models will keep leapfrogging each other, benchmark charts will keep changing, and dramatic demonstrations will keep winning headlines.
My current answer is more grounded. I trust GPT-5.6 most for complex, cross-context work, and Gemini 3.7 Flash for fast, discrete implementation.
I use Claude Code more cautiously because its speed, verbosity and usage pattern have repeatedly cost me time. Those are conclusions from my work, not universal rankings.
The metric that matters is whether I can assign a real job, let the agent work, and reasonably expect a correct, verified result without excessive supervision or wasted allowance. Benchmarks can help me decide what to test next. Trust decides what I use when the work actually matters.
