What to do when tokens run out

A few days ago I read one of those stories we’re all familiar with by now: a guy in a consultancy company ran out of tokens for the day, went to his manager asking for more and got back an answer along the lines of “That’s what we give everyone, you’ll have to make do”. Clearly the guy was the classical cog software developer moving tasks on a board, reading the post and his answers to people. He admitted he had (or thought so) nothing else to do for the day, or anyway until the limit reset.

First of all, let me address just one of the most common comments under the post: “you should’ve been able to pick up the work midway”.
Let’s be very pragmatic: when you have a handful of (sub)agents running in parallel, especially with models that don’t even show their reasoning beyond short occasional summaries, you’d spend hours just to figure out the simplest or most approachable of these workstreams. You try to understand something, do a bit of manual work, and hope you don’t break the internal consistency the agent was following. Then you briefly document what you’ve done and hand it back to the LLM when the limit resets, so it can finish the work, possibly deleting work that you took hours, only to recreate it in seconds. Either that, or you just wait and do something more useful, if you have any of course.

Thinking output on Claude Fable 5 and Claude Mythos 5
On Claude Fable 5 and Claude Mythos 5, the raw chain of thought is never returned.
(as of Aug 16th 2026)

I won’t go down the rabbit hole here of what’s happening to software engineers and their alienation from their work, it’s outside the scope.
Regardless of the specific case of the post, we know there are different roles in a company, some of which, by their nature, include a larger part of agents orchestration. In other roles, there’s much more to do: coordination of people and processes, reading and writing docs, or any other intellectual or manual activity. But this is not for everyone, not today at least it seems.
The existing model, in many forms, and depending on country-specific regulations, couples work and pay to time spent, for employees, freelancers, consultants and some b2b services.
At the same time though, for good reasons, many companies work with objectives, rather than time allocation, plus a deadline (or the satisfaction of regulatory/quality/quantity constraints in other fields, where the release isn’t time-bounded). But still, the reality is that companies have specific working hours and the expectation isn’t that you do your planned work until you can and are available for reactive work (meetings, incidents, customer support tickets and call).
You’re supposed fill as much time as possible to the end of the day with work, any work.
Considering this as the most common setup (and it looks to me like it isn’t changing much, but please let me know otherwise), what should happen to the roles that currently by design have little to do when they see at screen the feared 5h:100% 7d:100%? Are they allowed to pick up a book and study something? Go and learn what they colleagues do? This is what many people already do, which is absolutely noble, it should be probably encouraged and established at team level or more structurally in the companies nowadays.
Is this being accepted and normalized? What’s happening where the culture isn’t notoriously the best? What are the incentives? Are companies and their leaders ok with that?
Or maybe do they prefer to give even more generous AI plans to their employees hoping for the best? Beyond mere economical considerations, I think it’s just pushing the problem forward, or actually making it worse. With double the tokens, and so even fewer constraints, you can be even more sloppy in producing double the output with less turning the brain on, and have the agents cleaning things up later on. Engineering, in many companies, isn’t even the bottleneck (anymore).
On the other side, if the things will move in such a way the incentive push to just use the agents at a speed compatible with the contracted hours, “you won’t be using AI as much as expected to squeeze the most of the value out of it, you won’t be maximizing your productivity and you’ll be slowing everyone down”, you know the drill.

The Uber case, where they burned the year’s token budget as early as april, tells us that (guess what) engineering hasn’t freed itself from constraint management.
If in the ‘80s we fought to squeeze a program into a few kilobytes, we now have to squeeze the most useful LLM work into the tokens we can afford. You ready?