Cheaper models change which automations are worth building.
A year or two ago, most teams that looked at automating their inbox did the math and walked away. Reading every incoming message with a capable AI model cost real money per message, and when the job was just deciding which folder an email belonged in, the numbers rarely worked. That math has changed. The smaller models from the major providers now handle plain sorting and tagging well, and they cost a small fraction of what the largest models charge for the same volume of text.
The jobs you ruled out deserve a second look.
Most organizations have a short list of automations they considered and dropped. Routing support tickets to the right person, tagging invoices by department, pulling the dates and names out of intake forms, flagging which permit applications are missing a document. None of these were hard. They were high-volume, and volume made them expensive when every item went through a large model.
A town office that gets a few hundred resident emails a week is a good example. Say the clerk spends part of every morning deciding which ones go to public works, which go to the tax collector and which need a reply from the town manager. A large model could always do that sorting, but paying top rates to read hundreds of short emails about potholes and parking permits was hard to justify. A small model does the same sort quickly and cheaply, and the clerk's morning goes back to the cases that need a person.
So the first step is to dig out that old list. Look for work that is repetitive, judged against clear rules and done many times a day or week. Those are the jobs where the drop in cost moves an idea from "not worth it" to "worth a pilot."
Match the model to the size of the job.
The habit we see most often is reaching for the most capable model available for every task. It feels safe, since the biggest model is the one that does best on hard questions. For routine work it mostly means paying more and waiting longer for the same answer.
Paying for the largest model to sort your inbox is like hiring a senior attorney to open the mail.
Large models earn their price on work that needs reasoning across a lot of context: drafting a grant narrative from a stack of program reports, comparing two contracts clause by clause, writing a first pass at a policy. Sorting an email into one of six buckets doesn't need any of that. A small model told clearly what the six buckets are, with a few examples of each, will usually get the same answer, and it will get it in a fraction of the time.
Split the job before you pick the model.
Many workflows that look like one job are really two. Processing a vendor invoice involves reading the document, pulling out the amount and the account code, and checking it against the purchase order. Then, occasionally, it involves working out why the numbers don't match and writing a note to the vendor. The first part is routine. The second part takes judgment.
Treating the whole thing as one task usually means running every invoice through the most expensive model to cover the rare hard case. A better design sends every invoice through a small model for extraction and matching, and passes only the mismatches to a larger model or, more often, straight to a person. The cheap model handles volume, and the larger model or the person handles the exceptions where the judgment lives. A person can then review the exceptions each day without wading through the routine ones.
Watch the costs that don't shrink.
A cheaper model lowers the cost of running an automation. It does nothing for the cost of building it, testing it and keeping it working. Someone still has to write the instructions, gather the examples, decide what happens when the model is unsure and check its output for the first few weeks. Someone also has to notice when a new form version arrives and the model starts guessing.
That means the low running price can tempt a team into building more automations than it can look after. Before starting one, ask who will check its results and how often. If nobody has the time, the job isn't worth automating yet at any price per message.
It also pays to test. Small models differ from each other, and a model that does well on general measures may still stumble on your particular forms or your team's shorthand. Run a sample of real items through it and compare the results with what a person on the team would have decided before you switch anything on.
Big model or small model, a decision guide.
Run each candidate job through these questions in order. The first one that clearly applies points to the answer.
- Does the task follow rules a new employee could learn in an afternoon? Start with a small model.
- Does it run more than a few dozen times a day, or does someone wait on the result? Volume and speed favor a small model, as long as quality holds on a real sample.
- Does it need the model to weigh a long document, reconcile conflicting sources or write something a client will read? Use a larger model, and keep a person reviewing the output.
- Is it a mix of routine steps and occasional judgment? Split it. Let a small model handle the routine pass, and send the exceptions to a larger model or a person.
- Would a wrong answer be expensive, public or hard to undo? Model size doesn't settle this one. Put a person in the loop before anything goes out, whichever model does the first pass.
- Can you name who will check the results each week? If not, wait, and come back to the job when someone can.
Once a job passes the guide, try the small model first on a real sample of a hundred or so items. Move up to a larger model only for the cases where the small one falls short, and write down why, so the next person to look at the automation knows the reason it costs what it does.
