Token Rationing Is Here: What It Means for SL Builders
Companies are now rationing AI tokens after a year of letting employees spend freely. Here's what token rationing means if you build on a small budget in Sri Lanka.
Token rationing is the new corporate reflex, and it arrived faster than almost anyone expected. According to a TechCrunch report, companies are scrambling to stop employees from maxing out AI budgets with small tasks. The framing in that piece stuck with me: the "tokenmaxxing" era was brief, and we now seem to be entering the era of token rationing.
I want to read past the headline. The interesting part isn't that big companies are tightening AI spend. It's why the small tasks are the problem, and what that tells a Sri Lankan engineer or small-team builder who never had a fat AI budget to begin with.
🔍 Why small tasks are the expensive ones
The counter-intuitive bit is that the budget damage comes from tiny, casual requests, not the big flashy ones. A team that runs one heavy nightly analysis pipeline is easy to see and easy to cap. A hundred people each asking an AI to "fix this sentence" or "rename these variables" forty times a day is invisible until the invoice lands.
Each of those calls looks free. None of them are. Most AI APIs bill per token on both sides of the conversation:
| Cost driver | What it actually charges for |
|---|---|
| Input tokens | Everything you send: prompt, pasted code, chat history, system instructions |
| Output tokens | Everything the model generates back |
| Hidden context | Re-sending the whole conversation on every follow-up message |
That third row is the silent killer. When you keep a long chat going and fire off ten "small" follow-ups, you are re-paying for the entire prior conversation each time.
Key takeaway: A "small task" is small in your head, not in the token count. The bill scales with how much text moves through the model, not with how trivial the request feels.
📊 The math nobody runs before they click send
Here is a rough illustration, using round numbers purely to show the shape of the problem rather than any real pricing. Imagine a single casual request that ships a chunk of pasted code plus chat history:
| Scenario | Approx. tokens per request | Requests/day | Daily token load |
|---|---|---|---|
| "Tidy this 50-line file" | ~2,000 | 30 | 60,000 |
| Same task inside a long chat | ~8,000 | 30 | 240,000 |
| Whole team of 20 doing this | ~8,000 | 600 | 4,800,000 |
Nothing here is a quote from any provider. It is just arithmetic. The point is that the jump from a clean prompt to a bloated one is roughly 4x, and then you multiply by headcount. That is how a department blows its allowance on work that genuinely felt minor.
If you have never looked at what your prompts actually weigh, you can paste text into our free AI token counter and see the number before you spend anything. Knowing the count is the cheapest habit you can build.
⚡ Why this is good news if you build in Sri Lanka
Most of us here never had the corporate-card "spend whatever" phase. We were rationing from day one. So while large companies are now retrofitting discipline they skipped, the constraints we already work under turn out to be the correct defaults.
A few habits that were forced on us, now validated:
- Short, scoped prompts. Send the function, not the whole repo.
- Local-first tools. Formatting, regex, JSON tidy-ups, encoding — these do not need a language model at all.
- Batching. One well-structured request beats ten chatty follow-ups.
- Cheaper models for cheap tasks. Reserve the expensive model for reasoning, not for renaming variables.
The companies "scrambling" are learning a lesson that a freelancer in Galle paying out of pocket learned in week one: every token is real money, so you only spend it where a model genuinely beats a deterministic tool.
🛠️ Stop sending model requests for non-model work
A surprising share of "AI tasks" are not AI tasks. They are string manipulation wearing a trench coat. If the job has one correct answer that a script could produce, a model is the wrong tool — slower, pricier, and occasionally wrong.
Things I would never burn tokens on:
- Formatting JSON, SQL, or HTML — use a deterministic formatter.
- Encoding/decoding Base64, URLs, or JWTs — fixed transforms, zero ambiguity.
- Case changes, find-and-replace, sorting lines — your editor already does this.
- Counting words or characters in a draft — no inference required.
- Generating UUIDs, hashes, or QR codes — pure computation.
We built free, browser-side versions of most of these precisely so you do not reach for a paid model out of habit. Reserve your tokens for the genuinely fuzzy work: summarizing a messy thread, drafting unfamiliar code, explaining an error you cannot parse.
Key takeaway: Before any AI call, ask one question — "could a deterministic tool give the exact same answer?" If yes, you are about to pay for nothing.
💡 What this means for you
The token rationing story is being told as a corporate cost-control headache. I read it as a quiet endorsement of how budget-constrained builders already work. The era of treating AI as free electricity is closing, and the people best positioned for what comes next are the ones who never believed it was free.
Concretely, this week:
- Audit one workflow. Find the task you fire at a model most often and check whether it even needs one.
- Measure before you send. Run your typical prompt through a token counter so the number stops being abstract.
- Move trivial jobs off the model. Formatting, encoding, counting, and conversion all have free deterministic tools.
- Keep chats short. Start a fresh context for a fresh task instead of dragging a 40-message history into every follow-up.
If a Fortune 500 finance team is panicking about token spend on small tasks, the lesson for a one-person studio in Sri Lanka is reassuring: the discipline they are scrambling to install is the discipline you already had. Keep it. It was never a limitation. It was a head start.