In Sextas Ímpares #149, recorded at the end of July 2026, I showed how I look at performance tables and technical cost when making these decisions in my company. Model names change almost every week, but the criteria for choosing between them stay fairly stable. Without your own yardstick, you risk paying for capabilities you'll never actually use day to day.
Define what counts as a good answer before opening any tools
An acceptable answer in a business needs objective criteria: it must respect the requested format, preserve the facts, and not invent information. Before testing any model, define the task requirements and gather a small set of representative data. Without that starting point, you risk being dazzled by well-written answers that are useless in your actual workflow.
Pick at least three real variations of the work you want to speed up. If, hypothetically, the goal is to summarize customer messages, include one message with complete data, another with missing information, and a third with contradictory data. Testing only on easy cases gives a false sense of security that tends to fail once the workload increases.
In the lecture, I argued that the choice depends on the concrete task. A model with modest results on general reasoning tests can be very good at extracting dates from invoices or categorizing terms. If it follows your internal rules without forcing the team to rewrite the text, it has more practical value than another model that gets more attention in the news.
If you want to go deeper into how teams integrate these tools into ongoing processes, also check how to use AI in business beyond chatbot questions. Tools should fit into routines that already exist, not create yet another scattered focus of manual attention.
Use comparison tables to narrow down the options
Independent evaluation tables help you go from dozens of alternatives to two or three viable options per task type. Instead of following every launch, check indexes that combine several tests of general capability, reasoning, code, or multimedia. This saves time and filters out the noise from each vendor's marketing campaigns.
Platforms like Artificial Analysis combine several independent tests into a weighted general performance index. Others, like LMSYS Chatbot Arena, organize blind comparisons using the Elo scoring system, the same one used in chess to measure head-to-head matches. If a model repeatedly beats known benchmarks in anonymous community votes, it's worth putting on your testing shortlist.
When checking these tables, look for the right metric for your specific difficulty:
- General capability: indexes that combine broad knowledge and reasoning tests;
- Code generation: indicators focused on terminal environments and agentic programming;
- Multimedia: tables dedicated to text-to-image, image editing, or image-to-video;
- Cost: the relationship between score achieved and price per million input and output tokens.
This screening only serves to eliminate what's clearly below industry standard. The final decision always comes down to testing the finalists with your own examples and the same instructions.
Before comparing models, check whether the step needs AI or whether rules are sufficient.
Distinguish personal subscription from API consumption
A fixed monthly subscription works well for personal work, but connecting a model to a system, a form on your website, or a database requires API consumption, where you pay according to volume processed. Understanding this difference avoids wasting money when the company starts growing and using AI more intensively.
If you use the web interface to ask questions or write texts, paying a fixed subscription makes sense. The problem appears when you want to connect that model to a form, a training platform, or internal data: then you need a technical connection whose cost depends on the volume of text exchanged.
In the training session, I mentioned the example of an internal assistant created to support participants in practical Claude Code training sessions. That assistant had the course documentation and instructions on how to explain concepts using simple analogies. For a task like this, it made no sense to use the most powerful and expensive model on the market just to respond to a greeting or a simple syntax question.
Using an aggregator like OpenRouter, which charges a small intermediation fee, lets you keep a single balance and choose the model with the right price and context window for each task, without opening an account with every vendor. To structure this kind of project more solidly, it's worth looking at how to plan an application with Claude Code before starting to code.
Evaluate the review cost, not just the tool's price
The total cost of a model combines the technical invoice value with the human review hours until the work is ready for delivery. Saving cents on a fast tool doesn't pay off if the output forces someone to rewrite entire paragraphs or redo formats. What matters is the total effort until the work is actually finished.
In the lecture, I talked about using economical options for well-defined tasks. Tasks with rigid instructions and limited context tend to work well on cheaper models, which frees up the more expensive models for work that requires complex reasoning or extensive code. If two options deliver the right result on the first try, the deciding factor becomes response time and price.
| Task type | Typical complexity | Reasoning demand | Practical decision criteria |
|---|---|---|---|
| Classification and triage | Low | Low | Cost per million tokens and answer stability |
| Chatbot with closed context | Medium | Medium | Strict adherence to provided documentation |
| Analytical writing | High | High | Factual coherence and absence of omissions |
| Agentic programming in terminal | Very high | Very high | Ability to fix errors without constant session |
| Advertising video from image | High | Specific | Visual consistency across reference shots |
When the volume of data processed per month grows a lot, the temptation appears to install open models on your own computers, through platforms like Hugging Face. This avoids monthly fees and keeps data within the company's network, but there are hidden hardware costs that need to be calculated before moving forward.
In the lecture, I mentioned an analysis done in my company about the hypothesis of setting up a dedicated workstation to generate advertising videos from reference images. The machine would require industrial graphics cards costing several thousand euros, and the return compared to the cost of using an API would take years to pay off, by which point the equipment would already be outdated. This kind of comparison between investment and operational return is explored further in growing an online business: what I learned about margin, team, and AI.
Review production models on a regular basis
A model that leads your field today can fall behind cheaper alternatives within a few months. To avoid continuing to pay for performance that's already been surpassed, it's worth periodically reassessing the company's most important automated processes, without this requiring daily attention.
Keep a folder with your reference test set: system instructions, input data, and the answer the team considers good. When a competitor shows up with a good position on public tables or with a significantly lower price, run the same test on that new model. If it matches the quality of the current solution at lower cost or response time, make the transition on the API with controlled risk, without cutting everything over at once.
In the follow-up work I do through my training and mentoring, I work on this practical approach with people looking for operational stability when using these tools. Knowing when to keep a model and when to switch is what gives the team time to focus on client work, instead of testing tools every day.
If you're deciding right now which model to use for a concrete task in your company, start by putting together three real examples of that task and test the two or three top-rated options from the tables I mentioned. Only after you have that practical answer is it worth looking at the price.