Why Six Companies Moved Routine AI Work to Smaller Models

Choosing an AI model by size alone can create avoidable costs and delays. Six companies described a more selective approach: use smaller models or ordinary automation for routine work, and reserve the largest models for tasks where their added reasoning ability matters. Their reasons vary, from making live calls feel less awkward to avoiding failed jobs and reducing token use.

The examples are reports from the companies themselves, rather than controlled comparisons across model providers. They still offer a practical lesson for teams deploying AI: evaluate each task on its own requirements, including response time, error costs, workload volume and access to data.

Speed matters when a model is part of a phone call

Apps2Grow builds voice assistants that handle calls for businesses in real estate, restoration, Medicare and mortgage services. Its initial choice of a large model reflected perceived capability, but the response time was a poor fit for live conversation. Callers sometimes waited for answers, and even a brief pause could make the exchange feel unnatural.

The company moved its voice assistants to a smaller, faster model running through Groq. According to marketing director Matt Smith, the change reduced delays and improved the flow of calls. Lower costs followed, since the assistants handle a high volume of conversations, but Smith said savings weren’t the main reason for the switch.

“But that was the bonus, not the reason we switched.”

Matt Smith, marketing director, Apps2Grow

Apps2Grow still uses its largest model for work that needs human judgment. Smith said simpler verification tasks are a better fit for smaller models, while using a less capable model on judgment-heavy work could create extra rework. The company’s approach treats latency as a product quality issue, not just a technical metric: a model that answers eventually may still be the wrong choice for a conversation.

First remove the AI from tasks that don’t need it

High School Reach tracks college outcomes for 34,110 U.S. high schools, processing substantial amounts of information. Founder Nick Standlea shifted research and verification tasks to a midsize model, while keeping the largest model for decisions where errors could be costly. But the biggest reduction came from rethinking which tasks needed a model at all.

Standlea found that the company was using AI for work such as gathering website information, extracting text from PDFs and sorting messages. Fixed rules and local scripts could handle some of those jobs, so the company moved them out of its model workflow. AI remained available for cases that the rules couldn’t resolve.

In one monitoring process, daily token use fell from approximately 10.1 million to 765,000, a 92% reduction, with no reported decline in output quality. The change also exposed a reliability risk in automation: a monitor reported “nothing found” for three weeks before the team discovered that its upstream source had shut down.

“One of our monitors reported ‘nothing found’ for three weeks before we discovered the upstream source had shut down.”

Nick Standlea, founder, Test Prep Gurus and High School Reach

That experience points to two separate decisions for AI teams: whether a task needs a model, and which model can handle it. Automating a process can lower usage, but teams still need checks that distinguish a valid empty result from a broken input.

Local models ease limits and keep research data on site

Aviskaar, an AI research lab, ran into both cost and access constraints while relying on large models for research and development. Its researchers sometimes had to pause work for as long as three days because of usage limits. The lab responded by developing Zorp, an open-source research tool that runs language models locally, without an internet connection.

Running Zorp on its own computers means Aviskaar no longer pays for tokens or has to wait for its access to resume, according to Arjun Jaggi, who runs the lab. It also means the team doesn’t have to send sensitive information to outside providers. Zorp is designed to provide evidence to support its findings, letting researchers inspect the material behind an answer.

Jaggi acknowledged that larger models perform better on complicated questions. For the research work Zorp was designed to support, however, the smaller model has been adequate. His conclusion was that model fit matters more than choosing the largest available option. Local deployment adds a distinct trade-off to the other cases: teams gain control over access and data handling, while taking responsibility for running the system on their own computers.

“The switch taught us that bigger was never the point, fit was.”

Arjun Jaggi, Aviskaar

Website audits reward speed, with limits on sensitive wording

Direction.com performs weekly website audits, and a new customer can add thousands of URLs to the workload. CEO Chris Kirksey said processing that volume with larger models became too expensive. The company moved almost all content auditing to smaller models; its monthly AI spending declined within the first quarter, with no noticeable drop in audit quality, according to Kirksey.

The smaller models also shortened turnaround. Direction.com can now complete large audits in a day, sometimes finding a broken page in the morning and getting it fixed by lunchtime. The company uses the savings to create more content for clients.

There is a boundary to that efficiency. Kirksey said smaller models sometimes miss wording that could raise concerns on medical websites. Content about what patients should expect after a procedure or how to manage anxiety requires careful review. Routine checks may suit a smaller model, but sensitive material still needs more scrutiny.

Reliability can outweigh raw capability

HealthWright Technologies changed models after a scheduled monthly keyword research job failed. The company used AI across five small businesses. In early July, the most powerful model was unavailable when the job began. The task stopped without reporting an error, and the company lost that month’s results until the next scheduled run in August.

On July 6, senior vice president of operations Jack Wright moved scheduled jobs and AI helpers to a less powerful model, and added alerts for failures. The change also reduced token costs: Wright said the largest model cost about five times as much per token as the model previously used for everyday reading tasks, while the replacement cost about twice as much.

HealthWright later adopted an even smaller model for file searches and log summaries. It kept the larger model for financial analysis, audits and planning. Wright also adjusted the AI helpers to spend less time on each task. In tests, usage dropped to about one-quarter to one-third of its previous level, with little change in quality. The company has kept the changes, though it still uses its main model for some quick searches.

Affordable services depend on task-level choices

OBEKS AI builds business agents that answer customer questions, manage Facebook and Instagram messages, respond to comments, and create social media content and blog posts. Founder Gabriel Kanyinsola said the company initially used frontier models, then found that costs accumulated as it built more services.

“They were powerful, capable, and seemed like the obvious choice. But the cost quickly became a problem.”

Gabriel Kanyinsola, founder, OBEKS AI

OBEKS AI tested smaller models and found that they could handle many of the same jobs at lower cost. That matters for the businesses it serves in Africa, which Kanyinsola said often can’t afford expensive AI tools. The company now assigns simpler work to smaller models and saves larger models for tasks requiring more advanced reasoning.

Taken together, these cases show that replacing a large model is only one way to reduce cost or improve a workflow. Teams can also remove AI from rule-based tasks, run models locally, shorten agent task settings, or add alerts that catch silent failures. The right division depends on what errors cost and how quickly a result is needed. A useful next step for any deployment is to measure those factors task by task, then check that quality and monitoring hold up after the change.