There is a very old theory that I learned about in my high school science class many years ago, and as we see AI become even more mainstream, I keep thinking about it. It's a theory known as Occam's razor.
Occam's razor says that when two explanations account for the same facts, you should prefer the one that makes fewer assumptions. The classic example is when you hear hoofbeats outside: imagine the sound is from horses before you imagine it's from zebras. Both explain the sound, but one is a lot more likely.
Why is this important in learning systems?
You show a learning system some examples, and you want it to figure out the general patterns so it can handle new cases it hasn't seen before. You usually start with some test data or a limited scope of data to handle a single case. Then you expand outward with new cases it hasn't seen before, and as you slowly expand out, you start to run into a problem called overfitting.
Overfitting is when you have tuned your model so much to do one very specific thing that it falls apart the moment you show it something new. Instead of learning the lesson, it memorized the answers. It's like a student who crams the exact questions from last year's test. They score perfectly on that test, but change one question, and they're lost.
The fix is almost always the same: make the model simpler. Give it less room to memorize, and it's forced to actually learn the pattern. That's Occam's razor doing real work in AI. The simpler explanation of the data usually holds up better than the complicated one that fits every little detail.
The same idea applies when picking a model
This doesn't just apply to building AI. It applies to using it, too.
Anyone working with AI today gets a menu of models. Some are small, fast, and cheap. Some are big, powerful, and expensive. The instinct is to always grab the biggest one, because bigger must be better, right?
Occam's razor says to ask a different question. Not "which model is the most powerful?" but "which model is enough?" If the small, fast model does the job at the quality you need, the big one isn't giving you a bonus. It's just extra cost and extra wait time for no reason.
There's one catch, and it matters: this only works if both options actually do the job well. Picking the cheap model when it can't hit your quality bar isn't smart simplicity, it's just cutting corners. So test first, figure out what "good enough" looks like for your task, and then pick the simplest thing that gets there.
What this looks like on AWS
If you work in the AWS world as I do, this plays out every day with Amazon Bedrock, which is basically a menu of AI models you can call through a single API. The menu runs from very cheap and very fast to very powerful and very expensive, and the price gaps are not small.
On the fast and affordable end, you have models like Claude Haiku and Amazon's Nova family. Haiku runs about $1 per million input tokens. Nova Pro is around 80 cents. Nova Lite and Nova Micro cost pennies. These models are quick, and they are more than enough for a huge amount of real work: sorting support tickets, pulling fields out of documents, summarizing text, routing requests, answering straightforward questions.
At the other end, you have the heavyweights like Claude Opus and the new frontier models above it. They're impressive, and for genuinely hard problems, they earn their price. But that price is real. The most expensive models can cost 10 to 100 times as much per token as the cheapest ones for the same request.
Here's the part most people miss: in my experience, a big chunk of everyday AI workloads doesn't need the heavyweight at all. Teams default to the largest model, pay the premium on every request, and never stop to check whether the small, fast model would have done the job just fine. That's the hoofbeats problem all over again. They're assuming zebras when horses would explain everything.
The Occam's razor approach on Bedrock is simple: start with the cheapest, fastest model that might plausibly work. Test it against real examples of your task. If it hits your quality bar, you're done, and you just saved a pile of money and cut your response times. Only step up to the bigger model when the small one demonstrably falls short. Bedrock even makes this easy, since switching models is usually a one-line change.
I learned this one the hands-on way
Last year at the AWS LA Summit, I co-presented with the Amazon Database team on an Agentic database migration tool that I created that will migrate a database from one technology to Amazon DSQL, and this tool taught me this lesson firsthand.
The tool does the whole job end to end. It looks at your currently running database and figures out what it costs you today. It projects the cost of the same workload on the new technology. It estimates how long the migration will take and flags the technical challenges it sees. Then it actually runs the migration, unit tests the data on the other side to confirm everything moved over correctly, and writes up a summary with the projected costs and the challenges it hit.
With a mid-sized model doing the analysis and the write-up, the output was exactly what I wanted. A clean synopsis: here's what you're paying now, here's what you'll pay after, here's how long it takes, here's what to watch out for. The kind of thing you could hand to a decision maker as-is.
Then I did what everyone does. I bumped it up to a more expensive, more powerful model, assuming the summary would get even better.
It got worse. The bigger model gave me too much. Instead of a tight synopsis, I got walls of detail nobody asked for. Every edge case explored, every caveat expanded, the signal buried in thoroughness. Technically impressive, practically less useful. I found myself scrolling through the output, looking for the answer the smaller model had simply handed me.
That's Occam's razor showing up in real life. The more powerful model wasn't better for this job. It was more than the job needed, and the excess didn't just cost more money; it actively made the result harder to use. The right model was the sufficient one, not the strongest one.
The takeaway
An idea from a 14th-century friar, one that most of us got in a five-minute aside in tenth-grade science, turns out to sit at the center of modern AI. When in doubt, bet on the simpler answer. It was good advice 700 years ago, it was good advice when I was picking models for my migration tool, and it's good advice now.
Top comments (0)