I run seven AI agents. They handle research, writing, image generation, SEO, design review, code verification, and release checks. For a while, every one of them ran on the most expensive model available, because that was the default and I never questioned it.
The bill got my attention before the logic did. I was paying frontier-model prices for tasks that did not need frontier-model judgment. A release verifier that checks HTTP status codes does not need the same model as a researcher synthesizing five sources into a brief. But that is what I had: one tier for everything, like hiring a senior consultant to do data entry.
What I actually built
The setup runs across three tools: Claude Code for most agent work, Codex for async tasks I hand off overnight, and a GLM launcher that routes Claude Code through z.ai's GLM-5.2 endpoint. The GLM launcher is not a separate product. It is a settings file that redirects every model slot in Claude Code to a cheaper endpoint. Starting Claude Code from that folder means you are running on GLM instead of Anthropic's direct API.
The routing decision is not per-prompt. It is per-agent, pinned in each agent's config file. I have seven agents, and each one has a model tier assigned based on what the job actually requires:
Opus (the expensive tier) goes to judgment work. Three agents run here: the researcher who synthesizes sources and spots weak claims, the blog writer who has to match a specific voice, and the design reviewer who decides whether a visual change breaks the brand. These are the jobs where a cheaper model produces output that looks fine until you read it twice and realize it missed something that matters. A researcher on a fast model will summarize sources fluently and skip the contradiction between them. That is worse than no research, because it ships with confidence.
Sonnet (mid-tier) goes to prescriptive work. Two agents: the image creator who fills a strict prompt template and runs a checklist, and the SEO optimizer who applies known rules to metadata. These jobs have clear right answers. The agent is not making judgment calls about tone or trustworthiness. It is following a spec. Sonnet handles specs reliably and costs less.
Haiku (cheapest) goes to evidence-gathering. One agent: the release verifier. Its entire job is mechanical. Run the build. Fetch URLs. Check status codes. Report what happened, verbatim. It does not interpret, summarize, or advise. Haiku does this flawlessly because the task needs compliance, not creativity.
Then there is the GLM launcher, which is the blunt instrument. When I start Claude Code from the GLM folder, every model slot redirects to glm-5.2, regardless of what the agent config says. This is the cheapest option and it works well for bulk mechanical work: file cleanup, simple refactors, anything where I am going to verify the output line by line anyway.
What went wrong
The GLM launcher was the problem. Because it overrides every model slot, it does not care what tier an agent is supposed to run on. I ran the blog writer through GLM once without thinking about it. The draft came back. It was fluent, structured, and completely off-voice. The sentences were generic where they needed to be specific. The failure example was soft where it needed to be honest. It read like a capable stranger had written it after skimming my other posts, which is roughly what happened. A cheaper model doing judgment work produces output that is the hardest kind of wrong: wrong in ways that look right on a skim and only show when a real reader hits the page.
I caught it in review and rewrote from scratch. That cost me about ninety minutes I would not have spent if I had just run the writer on Opus. The savings from the cheap model were real, maybe a dollar or two on that run. The rework cost was my Saturday morning.
After that, I added a line to my project instructions: never run writing or review agents under the GLM launcher, because it overrides quality tiers. The rule is one sentence and it has prevented the same mistake from repeating. The best guardrail I have found for model routing is not a smart routing algorithm. It is a written rule that says which jobs are too important to route cheap, kept where every tool reads it before starting.
Where it stands
I have not fabricated a percentage for the savings because I do not have clean before-and-after billing numbers to compare. What I can say concretely: the release verifier runs dozens of checks per deploy on the cheapest model available, the SEO and image agents run mid-tier, and only three agents use the expensive tier. Before this setup, all of them used the expensive tier. The cost difference between Haiku and Opus per task is large enough that even a few agents moved down changes the bill meaningfully.
More importantly, the routing map forced me to answer a question I had been avoiding: which of these jobs actually require judgment, and which ones just need to follow instructions? That question is useful even if you never change a model setting. It tells you where to spend your review time and where to trust the checklist.
The takeaway
If you are running AI tools on more than one kind of task, draw two columns this week. Left column: tasks where the AI is making judgment calls, choosing between options, matching a voice, deciding what matters. Right column: tasks where the AI is following a spec, running a checklist, reporting facts. Route the right column cheap. Protect the left column from cost cuts. The money is real, but the bigger win is knowing which work you can trust at speed and which work needs your eyes on every output.