Three Days a Week: What a Rate Limit Actually Costs
In July I wrote that monthly plans beat paying by the token for my development work. I also mentioned getting only three or four working days before hitting the weekly limit. What I understated was how much that limit would start deciding my schedule, and which model reviewed my code.
A $20 monthly plan sounds like a month of work. In practice the weekly limit decides how much of that month you actually get, and for me the answer was about three working days. Then I waited. Not for an hour, not until midnight, but for the reset, which is most of a week away when you hit the wall on a Wednesday.
Three Days, Then Waiting
The plan was Ollama Pro, monthly. Twenty dollars, and on paper that is a bargain next to what the same work costs through an API key. The weekly ceiling is what broke it. I would get through roughly three days of real work and spend the rest of the week unable to do the thing I was paying for.
Waiting is worse than it sounds, because the work does not pause politely. A bug I was halfway through debugging on Wednesday was still a bug on Thursday. The choice was not "work now or work later." It was "work now on a different plan, or do not work."
So I bought ChatGPT Plus again. That put me at three concurrent subscriptions, which is not a decision I made so much as one I backed into. I also wanted to try the new Kimi model around then, and I deliberately did not, because I was not going to evaluate a fourth thing while paying for three. I waited for the Ollama month to run out first.
It ran out, and I ended it. Three plans was not something I could justify, and by then Opus 5.0 had taken over most of my daily coding anyway. I will say this for 5.0 over 4.8: it is more willing to admit its predecessor was wrong. It found bugs in branches that came out of 4.8 sprints and said plainly that the earlier reasoning was bad, instead of defending it.
Codex is not immune either. With 5.6 Sol I burn through the weekly rate fast, and then it is the same wait, just on a different vendor's schedule.
The Limit Picks Your Reviewer
Here is the part I did not see coming, and it is the reason I wanted to write this post rather than another one about price.
When I ran that big evaluation pass over a codebase I thought was solid, Sol turned up a pile of issues and I wanted a second opinion from a different vendor before I believed any of them. The model I wanted for that job was Fable. Fable was no longer available in my weekly limit. So Opus 4.8 did the validation instead.
That worked out. Opus confirmed the findings, and I wrote up that workflow in Executor Model, Reviewer Model. But look at what actually happened: a quota, not a judgment, chose the model that decided which of those bug reports were real. I did not sit down and reason about which reviewer suited the task. I took what was left.
A rate limit does not politely stop you at the door. It quietly reassigns your work to whatever tier you still have, and you find out afterward whether that mattered.
Budget Rules, Written Down
In August I added a model tiering table to my AGENTS.md. I described it then as a quality rule, and it is, but the honest reason I wrote it was that I had been running the most expensive model available for everything, including renaming variables, and then wondering why I hit the weekly limit midweek.
The Codex side of that policy is more explicit than the Claude side, because I could put numbers on it. Here is the section as it actually sits in the file, with the longer bullet lists trimmed:
# Codex Model Usage Policy
Optimize for **correctness per token**, not maximum model capability on every
task. Use the least expensive model that can reliably complete the work, and
escalate only when complexity warrants it.
## Default Model Selection
- **Terra Medium - default**
- Normal feature development
- Typical bug fixes
- Moderate refactoring
- **Luna Medium - mechanical / low-risk work**
- Small UI changes, straightforward CRUD, renames
- Formatting and lint fixes, documentation
- **Sol Medium - difficult reasoning**
- Architecture or design decisions
- Bugs with unclear root causes
- Concurrency, synchronization, or lifecycle bugs
- Work where Terra has already made a credible attempt and failed
- **Sol High - exceptional escalation only**
- Use only when Sol Medium is insufficient for a genuinely difficult
problem. Do not use routinely.
## Escalation Policy
Do not escalate preemptively.
Preferred progression:
`Luna Medium -> Terra Medium -> Sol Medium -> Sol High`
If escalating because another model failed:
1. Preserve the useful work already completed.
2. Clearly summarize the remaining problem and observed failures.
3. Do not repeat broad repository exploration unless necessary.
## Model Budget Target
- **~70% Terra Medium**
- **~20% Sol Medium**
- **~10% Luna Medium**
This is a guideline, not a quota. Task complexity should determine model
choice.
Two things in there are doing most of the work. The first is point three under escalation. When a cheaper model fails and you hand the problem up, the expensive model's instinct is to re-read the entire repository before touching anything, and that re-exploration is where a surprising amount of my budget went. The second is the percentage target. It is a guideline and task complexity still decides, but having a number in the file changes the conversation. Without one, every task feels like it deserves the best model.
When I published the shorter AGENTS.md I said I did not know yet whether it was working and to ask me in a month. It has been about four weeks. On the instruction-following question I still do not have a clean answer. On the token question, with the current mix of plans and model choices, I am no longer stopping on Wednesday. I cannot yet separate how much of that came from tiering and how much came from spreading the work across subscriptions.
The Trap Inside the Budget Rule
There is a catch, and I want to state it because the tiering table does not.
Rate limits push you down the tiers. That is the whole point. But they push you down at exactly the moment you can least afford it, because the work you do when you are running low is usually triage: which of these reported bugs are real, which are noise, what do I fix first.
Triage is not mechanical work, and I learned that the expensive way. I closed nine issues after a source-only review. A second pass ran the reported inputs and reversed four verdicts. I changed both the model and the instructions for that second pass, so I cannot credit the model alone. I went through what flipped and why in A Convincing Review of the Wrong Path.
The budget lesson survives either explanation: leave room for verification before dismissing a bug report. A cheap pass that clears your queue is not a saving if the queue was right.
So my own rule now has an exception attached: drop tiers for implementation, not for judgment. If the budget is tight, spend what is left on deciding what to work on, and let the cheap model type.
That turned into how I split the work generally. Fable and Sol reason and plan. Terra and Opus implement against those plans. The scarce, expensive tokens buy thinking, not keystrokes.
A Week of This in Practice
To make it concrete, here is a real entry from this month.
9/9 - Started using GPT-6 Astra for reviews and analysis. It reported 20 new bugs, some rated critical. I ran those past Claude, which confirmed them. Then I had Claude implement the fixes and sent the resulting pull request back for review, where Astra caught regressions in the fix itself.
Four stages for one batch of bugs. Cross-vendor review is worth it, and I made that case in Executor Model, Reviewer Model. I just think it is worth saying out loud that the workflow I recommend is a workflow that consumes two budgets instead of one.
The budgets are not even the same shape anymore. Noticing a problem and writing it up as a real work item has drifted onto my phone, and that half draws down a different plan than the one doing the implementing.
The $15 I Did Not Mean to Spend
One more, because it belongs to the same story from the other direction.
I had left an OpenAI API key configured for a model in VSCode and forgot about it. One short coding session later I had burned $15 without realizing I was not going through the monthly plan I was already paying for. Nothing about the experience tells you which one you are on. The editor looks the same either way.
I made the case in GLM Plans, Fable Validates, and API Keys Are Not for Development that API keys are the wrong default for development work. This is the smaller, dumber version of that argument: the plan only protects you when the traffic actually goes through it.
Where I Landed, For Now
Model tiering written into the file the agents read, with a rough percentage target. High-reasoning models for planning and review, cheaper ones for implementation, and never the cheap tier for deciding what is real.
And Ollama is back, which puts me at three plans again: ChatGPT Plus, Claude on the $200 annual plan, and Ollama Pro monthly. The difference is that I chose this one. They introduced an annual plan, which is the kind of thing that makes you reconsider a decision you were fairly confident about, so I re-subscribed monthly first. Not because I changed my mind, but because I wanted to answer the question properly this time. I am running DeepSeek v4 Pro and GLM 5.3 on the less critical paths and watching what happens to the weekly ceiling.
That is the actual test, and it is not a price test. I already pay for one of these a year at a time, so I am not against annual commitments. Committing to a year of Claude was easy, because by then I knew exactly what a week on it looked like. I do not know that about Ollama yet, and I cancelled it once already. What I need to learn before signing up for twelve months is whether this configuration gives me the flexibility I did not have the first time around, and there is no way to get that from a pricing page. I have to spend a month either running into the limit or not running into it.
Kimi, the model I put off trying because I would not evaluate a fourth thing while paying for three, is still sitting there unevaluated. I am aware of the irony.
The thing I would tell anyone comparing plans is to stop comparing the monthly numbers first. Ask how many days of work the weekly limit actually buys, because that is the number that determines whether you are working on Thursday.
Comments