I thought eight projects at once was a question of discipline. It turned out to be a question of maths.
I have eight active projects and one five-hour window on a powerful AI model per day. Not “plenty of tokens”, not “as much as needed” — a specific window that runs out.
What didn’t work
For a long time I treated it as an ordinary task queue: take the most important thing, do it well, move to the next. That’s a perfectly normal way to work when you are the one doing the work: finish one, start another.
With a limited window it breaks. One complex architectural task or a deep refactor eats the whole window — and the remaining seven projects wait until tomorrow. Not because they matter less, but because the resource ran out on the first one.
The worst part is that it looks like proper work. You spent all day on the most important thing. Seven directions simply didn’t move that day.
The rule
No task for the advanced model takes more than 10–20% of the window.
This isn’t about saving money. It’s about more than one thing moving by the end of the day.
The consequence is inconvenient: I can no longer just “take a task and do it”. First it has to be cut into phases — and each phase assigned a model matched to its difficulty. Simple and mechanical goes to a cheaper model. A hard decision goes to the expensive one, but only on the specific piece where it’s genuinely needed.
It sounds like unnecessary bureaucracy around working with AI. In practice it’s the same principle I ran teams by for eleven years: not “the best engineer takes the task”, but “how hard is the task — and who is sufficient for it”. The only difference is that now one of the performers is a model rather than a person.
What it looks like on a real day
Here’s the distribution from one day this week — four tasks running in parallel.
An audit of materials for a client — the most expensive model. Not because the text is complex, but because of the cost of a mistake: the materials are already with the client, and a missed slip costs a deal. Here I’m paying for attentiveness.
An audit of a product page — mid-tier model. The same work in form, but the cost of a mistake is lower: it’s our own site, a mistake is visible and fixed in a minute.
Technical work on the site — mid-tier model. Mechanics with a clear criterion: either the markup is in place and the build is green, or it isn’t.
Triaging unmerged branches — mid-tier model. Reading history and comparing, no decisions.
The numbers from that day I can state precisely: four tasks took between 5 and 12 minutes each, and about 480 thousand tokens in total. The longest was twelve minutes.
But the point isn’t the tokens. While they ran, I wasn’t waiting — I was writing the things that don’t get delegated at all. By the end of the day four directions had moved instead of one, and none of them was bottlenecked on me as a performer.
The second thing visible in those numbers: the most expensive model didn’t take the most time. The audit of client materials wasn’t the longest task — but it was the one where I didn’t want to economise. The allocation follows the cost of a mistake, not the volume of work.
What I never hand to a model
The 20% rule covers production: code, texts, reviews, routine. But there’s a category that doesn’t split into phases and isn’t assigned by difficulty.
Decisions. What to do, for how much, what to call it, who to turn down. A model will give a well-argued answer to any of those — and that’s exactly why asking is dangerous: being well-argued isn’t the same as being right.
Trust. Sales, negotiations, a conversation with an unhappy client. That doesn’t scale with a tool.
The practical consequence worth accepting honestly: AI gives you more done, but not more sold. The bottleneck moves from production to acceptance — what’s short now isn’t hands, it’s my time to check the result. And that bottleneck doesn’t widen by adding another model.
Where the rule doesn’t work
A task that won’t split. Sometimes a decision genuinely is indivisible: either you hold the whole context in your head or you understand nothing. Then the rule is broken deliberately — and the day is planned as “today one direction moves”.
Work where context costs more than execution. If explaining the task takes longer than doing it, splitting makes no sense.
First steps into something unfamiliar. Until you understand the shape of a task you can’t cut it into phases — you don’t know where the boundaries are. Reconnaissance first, slicing after.
What to take from this
A limited resource changes not the speed of work but the way it’s planned. While there’s one performer and it’s you, a task queue works. The moment a shared resource appears that all directions draw on, you need an allocation rule — otherwise whoever is first in the queue takes everything.
And separately: if you’re running several AI tools across several projects, the question isn’t “which one is smartest”, it’s “how hard is this specific phase and what is sufficient for it”.