“You’re approaching your usage limit.”
D’oh! What day of the month is it again?
We had recently joked that AI tokens might become something employees barter through some black market system or negotiate as part of their benefits.
Funny. Also, apparently, not that far-fetched.
The warning arrived after I spent a bit of time (and tokens, apparently) exploring how to make recurring work faster, more consistent, and less painful—not just asking AI to summarize an email or rewrite a sentence, but testing whether it could support parts of a real production process.
My first reaction was, “Ooooh, crap.” Facepalm. Next, frustration—we were given no information about the limits. But then, a less comfortable question: Did I create this work for myself?
Some of it, yes. No one assigned every experiment. Or any, really. I kept following possibilities because I was curious, because I could see inefficiencies, and because each useful result revealed another part of the process that might be improved. AI can make it surprisingly easy to turn one question into twelve—and then spend real time pursuing all twelve.
That does not make the exploration pointless. Some of it has produced genuinely useful ideas and capabilities. But it does make the boundary between assigned work, professional development, experimentation, and self-created workload much harder to see.
The warning raised a broader question too: how are usage allocations determined, and do they reflect what different employees are being asked to accomplish? There may be perfectly sensible answers. Employees need enough visibility to plan their work accordingly.
Because the closer AI gets to work people are actually responsible for delivering, the less a usage limit feels like a minor product inconvenience.
It starts to feel like an operational dependency nobody has fully planned for.
From helpful tool to production dependency
If I use AI to explore an idea and hit a limit, I can stop. It may be annoying, but nothing critical has broken.
If I redesign a recurring workflow around it, the situation changes.
Now there may be data to reconcile, exceptions to investigate, a narrative to draft, several outputs to keep consistent, and a deadline that does not move because the tool became unavailable. A client waiting for decision-critical information does not care whether the delay came from a token allowance, a degraded model release, a license restriction, or a service interruption. The person responsible for the deliverable still owns the outcome.
What is more anxiety-inducing than being on an extremely tight turnaround for data people depend on and wondering whether the assistance built into the process is about to disappear?
This is not an entirely new problem. Earlier in my career, access constraints showed up as limited Tableau licenses assigned to designated office computers—if you go back far enough—or as essential Wall Street Journal coverage paywalled and copyrighted during a fast-moving crisis.
The technology changes. The operational question does not:
Can the person responsible for the outcome reliably access the tools and information required to produce it?
If the answer is “probably, unless they use too much,” that is important process information.
An AI demonstration can succeed once. Ever done something cool with AI and blown yourself away, only to try it again and get completely different results? Who hasn’t?
A production process has to work again, under deadline, with the next batch of inputs and the weird exception nobody remembered until it returned three months, fifteen months, or three years later. It needs quality checks, documentation, knowledgeable review, and a fallback.
Otherwise the supposedly automated process and the original manual process have to coexist. Someone still needs to know both.
That is not irrational resistance to AI. It is experienced people noticing a reliability problem.
Nobody knows the optimal way to use something that changes every day
There is an assumption buried inside usage limits: that people know how to spend their allocation wisely.
But what does “wisely” mean when the models, interfaces, features, limits, and recommended practices keep changing? A method that worked well last month (or even yesterday!) may now be unnecessary, inefficient, or less reliable. People are still learning which tasks benefit from AI, which require a different tool, which are faster to do manually, and which consume enormous amounts of capacity without producing much value (so annoying).
I have spent enough time experimenting to develop a few instincts about that—and I am still learning every day. Others have had less time, access, or reason to build those instincts. Many colleagues may be simultaneously learning the underlying job, the organization’s processes, and how to evaluate an AI system that can produce a confident answer to almost anything.
That is a lot to ask without training.
AI is often very good at providing instructions. That does not mean the instructions are correct. If no one with the relevant subject-matter knowledge has reviewed the method, the system may be teaching a plausible-looking shortcut, omitting an important exception, or confidently describing a process that does not apply to the actual data, client, tool, or organization.
This is where “just ask AI” becomes risky. A person needs enough grounding to recognize when the answer is wrong—or access to someone who does.
Any AI-assisted work needs quality control appropriate to its consequences. A low-stakes brainstorm does not need the same review as a calculation, research finding, client recommendation, or production workflow. But the obligation to check does not disappear because the output is polished. Sources, calculations, logic, completeness, formatting, and fitness for purpose may all need review.
Usage policy without training and QC standards solves only the easiest part of the problem: how much access people receive. It does not tell them where AI adds value, how to use it efficiently, or how to know when it has failed.
The cost session and the anxiety session are the same session
I laughed recently when I saw three conference topics in a row:
- demonstrating AI ROI while managing the exploding cost of tokens and compute;
- building a credible AI strategy and budget;
- moving employees from AI anxiety to ownership and productivity.
LOL.
Those are not three separate conversations.
If people are being asked to invest time in building AI-dependent workflows, anxiety about cost, access, service reliability, model changes, and staffing is not a cultural obstacle to overcome. It is part of the business case.
Why would someone invest hours learning how to automate a process if they do not know whether the organization will continue paying for enough capacity to run it? Why remove a manual route before the automated one is dependable? Why promise additional output if the resource required to produce it can be throttled without warning?
And why call those concerns resistance rather than evidence that employees understand what production actually requires?
What would make this feel less precarious?
Not unlimited tokens. A real operating model.
That means answering some fairly unglamorous questions:
- Which uses are optional experiments, and which have become production dependencies?
- What level of access does each role actually need?
- How are allocations determined, and can employees see what remains?
- What happens when someone reaches a limit during deadline-critical work?
- Which processes still need a tested manual fallback?
- What training helps employees decide when AI is appropriate—and when it is not?
- Who has the subject-matter knowledge to vet AI-generated instructions and methods?
- What level of quality control is required for each type of AI-assisted output?
- Who owns and maintains a workflow after the curious person who built it gets busy or moves on?
- Is the time spent mapping, testing, validating, documenting, and teaching recognized as work?
- Most importantly, what comes off people’s plates when AI adoption is added to the job?
AI access does not have to be infinite. But if organizations want people to build real work around it, access has to be intentional, understandable, and reasonably dependable.
Otherwise, the employee who reaches a limit has two problems: the tool may not be available, and the deadline still is.
Maybe AI tokens do not belong in the benefits package after all.
Maybe they belong in the operating budget.
Until then, I’ll keep cautiously exploring—with one eye on the possibilities and the other on the tokens.