Every time a major AI model is released, the same question appears: which one is best?

At Smartt, we do not think that is quite the right question.

Our team actively tests and works with models from Anthropic, OpenAI, and Google because the technology is changing too quickly to rely on a single platform. We also do it because, frankly, we are geeks. We enjoy seeing what each new model can do, where it struggles, and how it changes the kinds of work we can take on.

The more we use these systems, the clearer one thing becomes: there is no universal best model.

Different models are better at different types of work. Some are excellent collaborators. Some are stronger reviewers. Some are better at long-running orchestration. Others are faster and more economical for focused execution. And benchmarks are always changing as new models, prices, and plan limits emerge.

In our opinion, the real advantage comes from understanding which model to use, when to use it, and when not to use AI at all.

We Test Models Through Real Work

Benchmarks are useful, but they do not always tell you how a model will perform inside an actual business workflow.

A model may score well on coding tests but struggle to understand a messy legacy codebase. Another may be excellent at research but produce writing that needs substantial editing. A model that appears expensive on a token basis may save money by completing a complicated task with less supervision.

That is why we prefer to evaluate models through real projects.

We use them to analyze code, plan migrations, review technical work, debug applications, draft and edit content, investigate data, and help design automations. We pay attention not only to whether the answer is correct, but also to how much guidance, correction, and review the model requires.

That gives us a more practical picture of where each model fits.

Coding and Orchestration Are Different Jobs

One of the most important distinctions we have observed is the difference between writing code and orchestrating a larger project.

Models such as Sonnet and Opus 4.8 are already capable of producing useful code. For a well-defined task, they can create a Python script, troubleshoot an error, help build a custom Drupal module or WordPress plug-in, or help implement a new feature.

The newer frontier models can do that as well, but their larger advantage may lie elsewhere.

Fable, for example, is particularly strong when the work involves planning and coordinating multiple stages. Instead of treating the assignment as one prompt followed by one answer, it can break the problem into parts, work through dependencies, review intermediate results, and manage a longer process. At the same time, the guardrails make it almost impossible to do any work related to security, or even some programming tasks in general.

That makes it well suited to planning and orchestration.

A software migration, for example, may require the model to inspect a codebase, identify affected components, create a plan, make changes, run tests, examine failures, and revise the implementation. The individual coding tasks may not be extraordinary, because the value comes from keeping the whole project organized and moving forward.

This is an important change in how we think about advanced AI. The most capable model is not necessarily the one that writes the best isolated function. It may be the one that can manage the broader assignment with the least supervision.

Opus 5 Surprised Us

Opus 5 has been one of the more interesting recent models for our team because its performance exceeded our initial expectations.

We expected it to be a stronger version of the previous Opus models. In practice, it has felt like a more substantial improvement (like “Fable-class” for the lack of a better term), particularly when reviewing work, debugging complicated issues, interpreting incomplete instructions, an debugging.

It is capable of coding, but it is also useful as a second set of eyes. So, for the past few days since it’s been released, we have asked Opus 5 to inspect code for logical flaws, missing cases, security concerns, or unnecessary complexity. It is also effective when a project has become messy and the task is less about creating something new than understanding what has already happened.

That review role is becoming increasingly valuable.

As AI makes it easier to produce code and content, the bottleneck often shifts to evaluation. Someone (or another model) still needs to determine whether the work is correct, appropriate, maintainable, and aligned with the original goal.

Opus 5 has performed particularly well for us in that part of the process.

Where GPT-5.6 Sol Fits

GPT-5.6 Sol is also strong across coding, debugging, review, analysis, and writing.

Its advantage is breadth. It can move between technical work, business reasoning, research, and finished deliverables without the workflow feeling fragmented. It is often useful when the assignment crosses several disciplines.

A project might begin with analyzing a business problem, continue into planning a workflow, require some Python or JavaScript, and finish with documentation or a client-facing explanation. Sol can operate across that full range effectively.

We have also found it valuable for review and refinement. A model may produce the first draft of an implementation, while Sol examines the assumptions, looks for edge cases, improves the structure, or translates the technical work into something a business stakeholder can understand. And because it’s much cheaper than Fable, lately it has been doing a lot of heavy lifting in our workflow.

We should mention that we still get Opus to review Sol’s work, and vice-versa. This kind of model-to-model collaboration is increasingly part of our process. We do not assume that the model that creates the first answer should also be trusted to approve it, and we’ve found that when we “pitch models against each other”, they help cover each other’s blindspots.

Gemini Remains Part of the Mix

We also continue to test and use Gemini.

Google’s models and tools are important partly because of their connection to the broader Google ecosystem, including Workspace, search, analytics, advertising, and cloud services. Many of our clients already operate heavily within those environments.

Gemini may not always be our first choice for every coding or writing task, but that is precisely why ongoing testing matters. The models are improving quickly, and the strengths of one release may be quite different from those of the next.

Staying current allows us to make informed recommendations rather than defaulting to whichever platform happens to be most familiar.

The Best Workflow May Use Several Models

A practical AI workflow can involve more than one model.

For example, we might use:

• Sonnet or Opus 4.8 to implement a clearly defined coding task
• Fable to coordinate a larger, multi-stage project
• Opus 5 to review the implementation and identify weaknesses
• Sol to debug, refine, document, or convert the work into a polished business deliverable
• Gemini where its ecosystem, context, or integration makes it the better fit

This does not mean every project should be passed through five different systems. That would create unnecessary complexity and cost.

The point is that models can serve different roles, much like specialists on a human team.

One may be the builder. Another may be the architect. Another may be the reviewer. Another may be the communicator.

Businesses will increasingly need to think about model selection in those terms rather than attempting to standardize every type of work on one AI assistant.

We Do Not Use AI for Every Step

One of the most important lessons from our automation work is that AI should not automatically control the entire process.

Many client workflows need to be reliable, repeatable, and explainable. Feeding every input into a large language model can sometimes produce inconsistent results. The same information may be interpreted differently from one run to the next, especially when the instructions are complex or the input is messy.

It can also become expensive when the system processes a large volume of data continuously.

For many automations, we therefore use AI to help us write traditional code in Python or another suitable language. That code then performs the daily work using clearly defined rules.

For example, the system might:

• Collect and normalize data
• Apply known filtering rules
• Identify specific patterns
• Categorize records according to fixed criteria
• Trigger alerts when thresholds are reached
• Store results in a structured database
• Produce a consistent daily report

This approach is often faster, cheaper, and more predictable than asking an AI model to interpret every event from scratch.

The rules can be tested, the results can be reproduced (we usually include testing tools in the build), so that if something goes wrong, we can trace the logic and fix it. That matters in a business environment.

AI Helps Build the System, Then Reviews Its Performance

Using deterministic code does not mean removing AI from the workflow.

Instead, we use AI where its strengths create the most value.

AI can help design the system, generate the initial code, review the logic, create test cases, identify edge conditions, and document how the automation works. Once the rules-based system is running, AI can also review its performance.

For example, the automation may operate predictably throughout the day, applying the same logic to every input. At the end of the day, an advanced model can examine the results and ask higher-level questions:

• Did the system miss any important cases?
• Did it produce too many false positives?
• Are new patterns appearing that the rules do not yet recognize?
• Should thresholds or parsing logic be adjusted?
• Did an unusual event expose a weakness in the workflow?
• Is there a better way to classify or prioritize the output?

A human can then review those recommendations and decide which changes should be implemented.

This creates a useful division of labour.

The rules-based system provides consistency. AI provides interpretation and improvement. Humans retain control over changes that affect the business.

Predictability Matters More Than Novelty

It can be tempting to build an automation that appears highly intelligent because a model is making every decision.

That may look impressive in a demonstration. It may be less impressive when the same workflow produces different results on Monday and Tuesday.

Enterprise systems often need boring qualities: consistency, auditability, reliability, and controlled costs.

A deterministic process may not sound as exciting as an autonomous agent, but it may be the better engineering choice.

The goal is not to insert AI into every step. The goal is to use the right technology for each part of the problem.

Sometimes that means a frontier model. Sometimes it means a small model. Sometimes it means a Python script with well-tested rules. Most often, the strongest solution combines them.

The Economics Are Better Too

Using a powerful model for every transaction can become expensive, especially when an automation processes large volumes of information.

Rules-based code can handle repetitive and predictable tasks at a very low incremental cost. AI can then be reserved for areas that require interpretation, judgment, or adaptation.

This also reduces unnecessary token usage. The model does not need to repeatedly reason through decisions that the business has already defined.

Instead, the system can escalate only the uncertain, unusual, or high-value cases.

That is similar to how an effective human team operates. Routine work follows established procedures. Exceptions receive expert attention.

Model Choice Is Becoming Part of Solution Design

The comparison between Fable, Opus 5, Sol, Gemini, and other models is useful, but only up to a point.

The more important question is how they fit into the system you are building.

A successful business workflow may use one model to plan, another to implement, a rules engine to operate, and a third model to review performance. In other cases, a single model may be entirely sufficient.

The right design depends on the complexity of the work, the volume of data, the need for consistency, the consequences of error, and the available budget.

This is why our team continues to test multiple AI platforms. We want to understand not only what each model can produce in a chat window, but also how it behaves when placed inside a real operating process.

The Best Model Is the One in the Right Role

Fable is impressive as an orchestrator of long-running and complex work. Opus 5 has surprised us with the strength of its review, debugging, coding, and writing capabilities. Sol is a highly capable generalist that can move effectively between technical and business tasks. Sonnet and earlier Opus models remain valuable for focused execution, and Gemini continues to matter as both a model family and part of the wider Google ecosystem.

None of that means every business needs to adopt every model. It means AI strategy is becoming more sophisticated than selecting a single chatbot and giving everyone a login. The better approach is to understand the work, assign the right tool to each role, and build enough review and structure around the process to make the results dependable.

That may involve several AI models AND traditional code, along with human judgement.

The near future is not going the AI replacing every system, but rather, businesses learning how to combine models, software, rules, and people into something more capable than any one of them on its own.

If you’re interested in implementing AI at your organization, feel free to reach out and have a conversation!