By the end of this chapter you can run real volume without a surprise bill or hitting a wall: you understand the two kinds of limit, the levers that cut cost, and why you check the live numbers instead of trusting any you were once told.
AVATAR OPENER · ~90s
Watch: the same workload run carelessly, then run with the cost levers on
HeyGen avatar · generated, consistent presenter
Everything gets cheerful in AI content until the bill arrives, or until you hit a wall mid-task and cannot understand why. This chapter is the unglamorous half that decides whether any of the systems you have built survive contact with real volume. It is about limits and cost, and it is deliberately free of numbers, because the numbers change constantly and a course that printed them would be lying to you within a month.
So this is a chapter about method, not figures. You will learn the shapes of the limits, the levers that bring cost down, and the one habit that keeps you honest: check the live numbers, today, for your real workload, and never run volume on a price you half-remember.
Do not memorise the prices. Learn the levers, and always check the live numbers.
Every specific number here goes stale fast. The method does not. Learn the levers, then read today's figures off the official page before you commit real volume.
THE TWO KINDS OF LIMIT
There are two different ways you can hit a wall, and they behave differently, so it helps to know which one you are up against.
A usage limit
How much you can do in a window of time. Some plans carry more than one: a general ceiling across everything, plus a separate cap tied to one particular model. They reset on a fixed schedule.
Result: you stop until the window resets. Plan heavy work around it.
VS
A length limit
How much fits in one request: the working memory. Overfill it and the request simply fails. This is context management, and you control it with the four patterns below.
Result: the request fails until you make it fit. Fixable by you.
The first, a usage limit, is about volume over time. On some plans there is more than one at once: a broad ceiling across all your activity, and a second, separate cap tied to one specific model, so you can exhaust your allowance of the most capable model while still having room on the others. These reset on a fixed schedule assigned to your account. The practical move is to know your reset rhythm and not burn your heaviest allowance early in the window on work a cheaper model could have done.
The second, a length limit, is about one request being too big. It is the context rot problem from earlier, at its hard edge: overfill the working memory and the request does not degrade, it fails outright. The good news is this one is entirely in your hands, and the four patterns below are how you manage it.
THE LEVERS THAT CUT COST
Cost is not fixed. There are concrete levers, and pulling them can change what a workload costs by a lot without changing what it delivers. Four are worth knowing.
The model ladder
The biggest lever, from earlier: run each task on the cheapest model whose output you would actually ship. Most volume does not need the top tier.
Batch the patient work
Work that does not need an answer this second can often be sent as a batch for a large discount. If it can wait, batching it is close to free money.
Cache the stable parts
When you send the same big instructions or documents over and over, mark them stable so they are reused at a fraction of the cost instead of paid for each time.
Send only what is needed
Do not stuff the whole codebook into every request. Load what this task needs and let tools pull the rest on demand. Smaller requests cost less and fail less.
The last two point at the same skill from the other direction: managing the working memory, which is both a cost lever and the fix for the length limit. There are four patterns for this, and you layer them. Load just what the task needs now and let tools fetch the rest. Let old turns be automatically summarised once a conversation grows long. Cache the stable parts so you are not re-paying for the same instructions. And, for work that must remember across sessions, use a memory the model reads at the start and writes at the end. Layer all four and a workload that would have failed or cost a fortune runs lean.
THE HABIT: A COST WORKSHEET
Before you turn on any real-volume workload, you do a small, honest sum. Not a guess, a worksheet: what model does each part actually need, can any of it be batched, what is stable enough to cache, and what does that come to at today's live prices. Doing this once before you scale saves you from the two classic surprises, the bill you did not expect and the wall you did not see coming.
Build a cost worksheet for one workload
I am about to run this at real volume: [describe the workload, e.g.
"summarise every incoming support email, all day, every day"].
Help me build a cost worksheet before I turn it on:
1. Which parts genuinely need a top model, and which could run on
a cheaper one? Push me to justify each top-tier choice.
2. Which parts could be batched because they are not urgent?
3. What is stable enough across runs to cache, so I stop paying for
it every time?
4. What is the smallest amount of context each request actually
needs?
Then tell me exactly which live numbers I should look up today, and
where, to turn this into a real estimate. Do not quote me prices
from memory; they change. Point me at the current official page.
Most of your volume is routine summarising, so it drops to the cheap
model. Only the weekly judgment call needs the top tier.
Half of it is not urgent and can be batched for a large discount.
Your long standing instructions are identical every run, so caching
them cuts a big repeated cost.
Look up today's per-use rates and your plan's limits on the official
page, then plug them in. The shape says this is very affordable. The
live numbers confirm it, and are the only figures you should trust.
Notice the worksheet never ends with a number this course gave you. It ends with you looking up today's real figures and doing the sum yourself. That is not a dodge, it is the only honest way, because a price printed in a lesson is a price that will be wrong. The lesson is the method; the current page is the source of truth.
NOW YOU TRY · ANALYZE
Cost-worksheet one real workload
Take one workload you either run at volume or want to. Use the worksheet prompt to break it down: which parts need which model, what can be batched, what can be cached, and how lean each request can be. Then actually look up today's live prices and limits on the official page and turn your worksheet into a rough real number. The win is seeing how much the levers move the total, and knowing your real limits before you hit them.
Right if you have a worksheet for one workload grounded in today's live numbers, and you can name which lever cut the most and where your real usage limit sits.
Show the worked solution
The drill works when the levers visibly move the total and the number you trust came from the live page, not from anywhere else. Say the workload is "classify and tag every incoming message so my inbox sorts itself." Run it naively on the top model with full context every time and it looks expensive, maybe expensive enough to abandon. Now apply the levers. Classification is not a hard reasoning task, so it drops to the cheapest model, the single biggest cut. It is not time-critical, so it can be batched for a further discount. The instructions that tell it how to classify are identical every run, so you cache them instead of re-paying. And each message needs only itself plus the short rules, not your whole history, so the context stays tiny. Those four moves together can turn a workload that looked unaffordable into one that costs very little, and the only way you know the real figure is that you opened the current official pricing page and did the sum with today's numbers. That is also where you learn your limits: you see whether this volume fits inside your plan's ceiling, and whether it would eat the separate cap on the top model, which is exactly the wall you want to discover on a worksheet rather than at 4pm on a Tuesday when everything stops. The habit is the deliverable: shape it with the levers, price it on live numbers, check it against your real limits, then turn it on.
WATCH FOR
✗You run volume on prices you half-remember. Every number goes stale. Look up today’s live figures on the official page before you scale anything. The method is memorable; the prices are not.
✗You run everything on the top model. The model ladder is the biggest cost lever. Push each task down to the cheapest model whose output you would ship.
✗You pay full price for urgent-feeling work that could wait. If it does not need an answer this second, batch it for the discount. Most background volume is more patient than it feels.
✗You hit a wall mid-task and do not know which limit. Learn your two limits: a usage ceiling that resets on a schedule, and a length limit you fix by managing context. Different walls, different fixes.
WHAT YOU LEARNED
The takeaways
This chapter is method, not numbers. Every specific price and limit goes stale fast, so you learn the levers and read today’s figures off the official page.
Two kinds of limit: a usage ceiling over time (sometimes a general one plus a separate cap on one model, reset on a schedule) and a length limit per request that fails if you overfill it.
The cost levers: run the model ladder, batch work that can wait, cache the stable parts, and send only the context each request needs.
Managing working memory is both a cost lever and the fix for the length limit: load just-in-time, let long threads compact, cache stable parts, and use a memory for what must persist.
The habit is a cost worksheet: shape the workload with the levers, then price it on live numbers and check it against your real limits before you turn it on.
Your project · price your workload
Build a cost worksheet for one real workload in your thread project, grounded in today\u2019s live numbers, and find where your real limits sit. You can now run volume without a surprise. Next chapter is the top of the ladder: when a loop needs to run longer or survive a hiccup, you let it run on hosted infrastructure as a managed agent.
The exciting part of AI is the demo. The part that decides whether it survives is the bill and the wall, and both are manageable once you stop guessing. Learn the levers, price it on today\u2019s real numbers, and volume stops being the thing that quietly breaks you.