Everyone Told Me to Use AI to Route My AI Calls. I Used a Spreadsheet.
I route tasks across four AI models. Everyone assumes I trained a fancy classifier to decide which model handles what. I didn't. Here's why that's the right call.
At a meetup last fall, someone asked me how I route tasks across four different AI models.
“You built a classifier, right? Some kind of meta-model that analyzes each task and decides which model handles it?”
“I use a config file,” I said. “Basically a spreadsheet.”
The look on his face was the same one you’d give someone who told you they track their budget on paper. In 2026.
“But… how do you handle edge cases?” he asked. “I change one line,” I said. He looked like I’d told him my car runs on hopes.
But that config file has been running in production for over a year. It’s never woken me up at 3 AM. I can’t say the same about the “smart” approaches — or the state machine that crashed at 2:47 AM before I got it right.
The spreadsheet
It looks like this:
reminder formatting → laptop model
calendar sync → laptop model
simple sorting → laptop model
writing content → paid cloud model
complex analysis → paid cloud model
hard reasoning → expensive modelA task comes in. The system looks it up. Sends it to the right model. Done.
No machine learning. No training data. No neural network. A list.
What “smarter” would cost
To build the classifier everyone assumes I have, I’d need to:
Manually label hundreds of tasks with the “correct” model for each one. Train the classifier on those labels. Test it. Fine-tune it. Deploy it. Set up monitoring to catch routing mistakes. Retrain it every time my task types change.
All of that to solve a problem that twenty lines of config already solve perfectly.
It’s like building a robot to flip your light switch. You can. But the switch is right there.
When it’s wrong
It happens. I add a new task type, guess which model can handle it, and guess wrong. The laptop model tries something too hard for it and produces garbage.
I change one line. Move that task from “laptop” to “cloud.” Deploy. Done. Ten seconds.
Now imagine the same mistake with a classifier. Why did it route wrong? I’d need to investigate the classifier’s decision. Collect more training examples. Retrain the model. Test the new version. Test it against saved examples. Redeploy.
That’s hours of work for a ten-second problem.
When a classifier actually makes sense
I’ll be fair. If you have thousands of wildly different task types that change every day, and the line between “too hard” and “just right” is blurry — a classifier might be worth the complexity.
That’s not my situation. I have about 20 task types. They change maybe once a month.
I know exactly what each one needs. If I ever hit 200 task types that change daily, I’d reconsider. That day hasn’t come.
And honestly? Most people who think they need a classifier are in the same boat. Manageable number of task types. Predictable requirements. A lookup table would work fine.
Why we reach for complexity
This is the part that interests me.
The guy at the meetup wasn’t wrong to assume I’d built a classifier. Building a classifier is the interesting solution. It’s the solution you’d talk about at a conference. It’s the solution that signals competence.
“I route AI tasks using a config file” doesn’t get you invited to speak anywhere. “I built a meta-classifier that dynamically routes tasks across a heterogeneous model fleet” does.
We reach for complexity because simple answers feel like cheating. “I use a config file” sounds like you skipped the hard part. But the hard part was figuring out that the config file was enough — and having the nerve to stop there.
My config file is boring. It’s also the only part of my system that’s never broken in production. I’ll take that trade every time.
Think I’m wrong about this? I’m genuinely curious to hear the counterargument — mo@fadaly.net.