How I Cut My AI API Bill by 80% in One Weekend

In February, my AI API bill hit $214. I remember staring at the invoice with the same feeling you get from a gym membership you never use. I was paying a lot, and most of it was going to waste.

The embarrassing part is that the waste wasn't the model's fault. It was mine. I was treating every API call like it needed the biggest, smartest model I could rent, and the bill was the price of that laziness.

This is the story of how I cut that bill to under $40 a month in a single weekend, without changing the quality of a single output that mattered. I'm sharing the exact process, including the numbers, because "AI is too expensive" is one of the most common reasons people give up on automation. It doesn't have to be.

Step 1: I stopped guessing and started measuring

The first mistake was not knowing where the money went. I had a vague sense that "the AI stuff" was expensive, but I couldn't tell you whether it was the summarization calls, the classification jobs, or the weekly batch jobs that were eating the budget.

So I spent Friday afternoon adding a tiny logger to every API call. Model name, task type, prompt size, output size, cost. That's it. No dashboards, no fancy tooling. Just a function that appended one JSON line per call to a file, plus a small script to total it up by task type.

One weekend of that data told me more than a month of guessing.

The numbers were brutal. About 61 percent of my tokens were going to tasks that did not need a frontier model. Summarizing a 200-word email thread. Classifying a support ticket into "billing" or "bug". Extracting a date and a name from a paragraph. Rewriting a headline three different ways.

These are simple jobs. I was paying Ferrari prices for a bicycle commute, and worse, I didn't even know I was doing it until I measured.

Step 2: I built a router instead of a default

The fix was embarrassingly simple: a router function at the top of my pipeline that looks at the task and sends it to the cheapest model that can do it well.

The rule I use now:

• Simple and structured (classify, extract, summarize short text): cheap model
• Medium (rewrite, draft an email, explain something): mid-range model
• Hard (complex code, long-form reasoning, creative work): frontier model

The router is maybe 20 lines of logic. It checks a "task_type" field that my pipeline already had, and it picks the model from a small map. The shape of it looks like this: if the task type is in the simple set, use the cheap model with a short token cap; if it's in the hard set, use the big model with a generous cap; everything else lands in the middle. No machine learning required. No cleverness. Just the discipline to ask "does this actually need the expensive brain?" before every call.

That single change did the heavy lifting. The simple tasks that made up most of my volume dropped to a fraction of the price per call, and since they were the majority of calls, the total cratered.

One detail worth stealing: I made the router the only place that chooses a model. Before, model names were scattered through the codebase, so every new integration quietly defaulted to the biggest model available. After the refactor, there is exactly one decision point, and it's easy to audit. If you take nothing else from this post, take that: one router, one place to change your mind.

Step 3: I started caching the prompts I sent twice

The second biggest leak was repetition. My batch jobs were sending nearly identical prompts every day. Same instructions, same output format, slightly different input. I was paying full price to recompute the same thing over and over.

The fix was prompt caching. Most major providers now cache a prefix of your prompt when it doesn't change between calls, and they charge a fraction of the normal rate for cached tokens. By moving my stable instructions (the system prompt, the output format, the examples) to the front of every request, those tokens became cache hits on the second call and every call after it.

The setup took one afternoon. I rearranged my prompt templates so the static part came first and the dynamic part (the actual content) came last. That ordering matters: caches work on the prefix, not the middle. Get the layout wrong and you get no savings at all.

A concrete example: my daily digest job builds a prompt with about 400 tokens of instructions and then appends the day's articles. Before caching, that job paid for 400 instruction tokens per article, every single day. After caching, the first article pays full price for the prefix and the other nineteen pay the cached rate, which is typically around 90 percent cheaper per token. Across a month of daily jobs, that alone was a double-digit percentage of my bill.

Step 4: I set max_tokens and stopped paying for silence

The third leak was the quiet one. Several of my calls had no max_tokens set, which means the model could keep generating until it decided to stop. For structured tasks that should have returned a 30-word answer, the model was sometimes generating 400 tokens of polite preamble before getting to the point. Every one of those tokens was billable.

The fix was max_tokens on every single call, sized to the task. Summaries capped at 150. Classifications capped at 40. Headlines capped at 60. This did two things. It cut cost directly, and it made the outputs tighter, because a model with a token budget stops rambling.

If you audit your own calls and see long outputs for tasks that asked for short ones, this is your cheapest fix. It's a one-line change per call and it compounds across volume.

Step 5: I batched the small stuff

The last change was batching. My pipeline had a bunch of tiny calls: checking whether a headline contained a keyword, judging whether a comment was spam, picking a category for a link. Dozens of tiny calls per hour, each with the same fixed overhead.

I grouped them into single requests where the format allowed it. Instead of asking "is this comment spam?" forty times, I sent forty comments in one request with a numbered output format and parsed the list back. Same result, one round trip, less duplicated instruction overhead.

Batching isn't right for everything. Anything where a user is waiting should stay single and streaming. But for background jobs, which is where most of my volume lived, batching cut both cost and latency.

The result, with numbers

Here's the before and after from that weekend:

Before:

• Monthly bill: $214
• Models: one frontier model for everything
• Token spend on simple tasks: about 61 percent
• Caching: none
• max_tokens: not set on most calls
• Tiny calls: every one sent individually

After:

• Monthly bill: $38
• Models: three tiers, routed by task
• Token spend on simple tasks: about 12 percent
• Caching: on, for every repeated prefix
• max_tokens: set on every call
• Small jobs: batched where the format allowed

An 82 percent cut, and I did not downgrade a single output that mattered. I tested the two most important workflows side by side, old setup versus new, and the results were indistinguishable to me and to the people using them. The visible quality stayed the same because the visible quality was never coming from the cheap jobs in the first place.

The lesson: the model is not the cost, the routing is

The thing I wish someone had told me six months earlier is that the model choice is rarely where the money should go. The money goes where you point it. Point the expensive model at simple work and you are paying a specialist to file paperwork. Point it at the hard 10 percent of your workload and it becomes cheap, because that 10 percent is where it actually changes the outcome.

Cost optimization in AI is not a hack. It's the same boring discipline as any other budget: know what you're spending on, stop spending on things that don't need the premium tier, and keep the audit running so it stays fixed instead of drifting back.

That's the other part I almost skipped: the logger is still on. Every week I glance at the totals, and whenever a new task gets added to the pipeline, it has to justify which tier it uses. The drift is what killed me before, not the initial setup.

A weekend of measurement saved me about $175 a month, every month, with no quality loss. That's the best ROI I've gotten from any AI project, and it didn't require a single new tool. Just a logger, a router, a cache-friendly prompt layout, and the willingness to admit my defaults were lazy.

---

This is the same cost discipline that keeps the Apex Nexus pipeline running at $0 per month. Free guides on the hub show the full architecture, from the router pattern to the caching layout.