Which AI Model for Work in 2026? Choose by Task, Not Ranking

👁 117 reads

Which AI model for work would we choose now? We’d test Astra first for code and strict instructions, Gemini 3.8 Flash for searching documents and cheap drafts, and Claude Opus 5 as a starting point in the Claude environment. We’d save Fable 5.1 for problems a cheaper model couldn’t solve. This isn’t a career ranking or a promise of flawless work. It’s a testing sequence we can back up with data or documentation.

We checked the state of providers on September 11, 2026. We mark our own results with measurement dates. We don’t have a separate test for every office task, so we distinguish measured differences from application proposals. When we don’t have a measurement, we write which model we’d test and what it would need to do for us to stick with it.

Our Task-Based Selection Map

We start with the result that needs to be produced. Text must preserve facts, code must pass tests, and answers from documents must cite sources. Only after meeting that condition do we compare time and cost. The cheapest result we can’t use doesn’t solve our problem.

Writing: Draft, Correction and Finished Material

For drafts we start with Gemini because we have a concrete measurement of its cost. In an article test from September 10, 2026, Gemini 3.8 Flash delivered 1,032 words for $0.01207. Astra wrote 906 words for $0.11228, and Fable 886 words for $0.18913. Source: our article cost measurement, checked September 11, 2026. We ran this test in Polish, a heavily inflected language, so this is a non-English writing test.

We’re not claiming a cheaper draft automatically has the same quality. We check whether facts are correct, whether the model followed instructions, and how much we need to rewrite. For text with extensive sources, we’d first commission organizing the material. Then we’d write or commission a section based on that. We don’t ask the model to simultaneously invent structure and guess missing data.

For language correction we also consider Astra and Fable. In a test from September 9, 2026, both scored 6/6 points, Gemini 5/6. Verification: September 11, 2026. Gemini lacked an answer to the task. We don’t present this as proof the model didn’t know the correct form. This test was conducted in Polish, a useful proxy for non-English, heavily inflected languages.

The practical condition is simple: correction cannot change meaning. We primarily compare negations, names, causal relationships and degree of certainty. The sentence “may help” cannot mean “solves the problem” after editing. If a model constantly strengthens claims, we change the instruction or tool, regardless of its grammatical result.

This choice stops making sense when we need text ready to publish without reading. Our measurements don’t provide that guarantee. We also haven’t measured which model best adopts an author’s personal style. For that we’d prepare our own examples and an editorial task with clearly described prohibitions.

Code: Astra to Start, But We Verify Results Outside the Chat

In a mixed test from September 9, 2026, Astra scored 9/9 points at a cost of $0.04955 and time of 35.3 seconds. Fable and Gemini each scored 8/9. We checked the data on September 11, 2026. This is our basis for a first try, not proof of superiority on every programming task.

In actual work we start with a description of the error and how to reproduce it. We separate task conditions from assumptions about what broke. If we impose a wrong diagnosis on the model, we may get a convincing fix for a problem that doesn’t exist. In our test, the evaluating automaton itself required correction, which is why we don’t skip reading the justification.

For fixes we ask for the smallest change solving the indicated problem. Then we run verification. If the model didn’t have access to an execution environment, the statement “tests pass” is not a result. We need the name of the executed command or information that verification remains to be done.

In the Claude environment we’d start with Opus. Anthropic indicates it as the starting point for most tasks, and directs to Fable for demanding cases and situations where attempts with Opus aren’t sufficient. Source: Fable documentation, September 11, 2026. We don’t have our own Opus result in the cited set, so we don’t assign it points.

We’d switch to Fable when we can name the error left by Opus and can verify its removal. We don’t pay extra for just a longer answer. If both solutions pass identical tests, we also compare readability of the change and scope of manual correction.

Long Documents: Gemini for Finding, Separate Test for Interpretation

In a measurement from September 10, 2026, Gemini found a hidden sentence in 3/3 attempts for $0.05889, with an average time of 3.3 seconds. Astra also had 3/3, cost $1.00205 and average time 2.0 seconds. Source: context test, checked September 11, 2026. Costs apply to the entire set, and times are per individual response averaged in that set.

For finding a number, condition or fragment, we therefore start with Gemini. We ask for a quote and location, if the file allows it to be determined. We compare the answer with the original. If PDF reading loses a table or fragment order, we change the document preparation method before we change the model.

With a contract archive we’d also need a test of combining information. The base document may have a rule, and an addendum an exception. Finding both places doesn’t yet prove their correct application. In such a task we require separation of quotes from interpretation and indication of ambiguities.

We don’t transfer the search result to legal assessment of the document. We didn’t test that service in the cited measurement. If incorrect interpretation has significant consequences, we treat the answer as material for further verification, not a decision.

Data Analysis: We Choose the Ability to Reproduce Results

For spreadsheets we’d choose Astra to start, in an environment with a tool executing calculations. OpenAI documentation, checked September 11, 2026, confirms support for tools such as code interpreter in Responses API. This is information about integration capability. We’re not claiming every conversation with Astra has the same tools.

First we ask which columns were read. Then we establish the meaning of an empty cell, units and date range. When comparing periods, we check whether both cover the same category of events. We don’t correct a chart before checking what it’s actually counting.

We want to receive code or formula, result, and description of omitted records. When the result doesn’t match, we can then return to a specific step. A mere statement about sales growth, even accompanied by an elegant table, doesn’t allow reproducing the analysis.

Gemini would be our alternative if data combines a table with image material. Its model card, checked September 11, 2026, confirms multimodal input and code execution. However, we don’t have our own comparative spreadsheet test of these models. We make the final choice dependent on reproducing the calculation on our file.

Customer Service: Gemini for Pilot, Without Pretending Ready Deployment

We’d test Gemini for preparing responses from a company knowledge base. The basis is the information-finding result and lower cost of that measurement. This is a narrow hint. We didn’t study customer conversations, resistance to conflicting instructions, or handling exceptional complaints in it.

We’d start the pilot with responses approved by us. The model gets a product description, company policies and customer message. It must indicate the fragment justifying the response. If conditions are missing from materials, it should describe the gap instead of inventing a discount, deadline or commitment.

We’d add ambiguous questions to the control set, and ones the base doesn’t answer. Proper escalation to a human we’d then consider success. We don’t want a system that always generates an answer, but a system whose answer we can justify.

We’d test Astra as an alternative for more complex rules, because we have its instruction test result. We’d include Fable only after demonstrating concrete advantage on our cases. We don’t call any of these choices a verified customer service bot. Between the model and such a service are still integration, control and a procedure for handling gaps.

Learning: Astra for Leading Exercises, Without Promise of Effectiveness

For exercises with clearly defined rules we’d start with Astra. The instruction test result gives us reason to test it in a conversation where the model should ask questions and not reveal the solution too early. It doesn’t prove we learn faster with it. We haven’t performed such a measurement.

We provide material, knowledge level and goal. We ask for a task, solve it ourselves, then expect indication of the first wrong step. If the model just provides a ready result, we change the instruction. In learning we don’t only count correct tool answers, but also whether we can later explain the solution independently.

We’d test Gemini for learning from our own documents, using the same condition of indicating source. We’d treat Claude as an alternative conversation partner for explaining a difficult passage. We don’t award points here for empathy, teacher style or memorizing material. Without measurement those would be our impressions, not test results.

How Much This Choice Costs

For automation we compare standard API rates. For manual work we check subscription and availability of the specific model. We don’t convert a bill from a single test into certain monthly work cost.

The table omits discounts, caching and additional tools. Google rates are valid until December 31, 2026 according to pricing checked September 11, 2026. Astra has higher rates for input over 272,000 tokens, as described in the model card, checked September 11, 2026. We account for this before working on extensive material.

In subscriptions we check not only the limit but also the workplace. Access to Astra in Work is not the same as access to GPT-6 Pro in chat. Fable has separate rules for using credits. We detailed these differences in our ChatGPT and Claude comparison, and in our comparison with Gemini. We check amounts and conditions again directly before purchase.

Ready Prompts: How We Test Fit

We paste the following prompts into the conversation after adding material. They don’t require entering model names or completing a template. They give us a result that can be compared with input.

Read the material added to this conversation. Indicate information needed to perform my task, unnecessary information and gaps. Don't fill gaps from memory. Before proposing a result, explain how its correctness can be verified.

Perform the task described in this conversation based on the attached data. Preserve names, numbers and caveats. If you use tools, state what you actually executed. Separate the finished result from steps that couldn't be verified.

Check the last result from this conversation against my instruction. List unmet requirements and places where you added information absent from the source. Don't assume correctness of your own earlier answer. Propose a correction only where you can justify an error.

What Not to Expect

We don’t expect the model to figure out on its own what we didn’t include. We don’t consider long reasoning a guarantee of correctness. We don’t assume a version change will preserve the calculation and behavior of an earlier integration. If we update a model, we repeat the attempt on saved material instead of comparing today’s result with memory of the previous one.

The most important boundary of our recommendations concerns untested applications. We have measurements of short tasks, writing and finding information. We don’t have a comparative study of learning effectiveness or customer service deployment. We described them as a pilot to conduct. Only that description is honest with the data.

Google · Your sourcesQuantslant higher in your Google - one clickAdd to preferred sources →

Which Model We Stick With

After a trial we also record the reason for rejection. “Doesn’t suit me” is too imprecise to help with the next update. The record “skipped exception from addendum” allows repeating verification. The record “delivered draft instead of file” indicates an execution problem. The record “didn’t have access to data” requires correcting work conditions before we accuse the model of lacking capability.

We keep such a task card together with input and output. We separate waiting time for an answer from time of our own corrections. When we later test another version, we know what we’re comparing. We don’t need an elaborate table of all models for this. We need a repeatable example of work we actually perform, and a criterion we won’t change only after seeing the answer.

We stick with a model that performs our task and allows verifying the result. For code we make the first attempt with Astra, for searching with Gemini, and in the Claude environment we start with Opus and only then justify paying extra for Fable. For writing we separate draft from correction. For analysis, customer service and learning, we first test operation on our own material. The model name opens the attempt, but staying with it is decided by work performed.

Kinetyra