An Accidental Allowance Is Not A Plan

If your workflow is only affordable because of a quirk in how a tool is metered, you don't have a workflow, you have a loophole. Loopholes get closed, usually without notice, and usually on a day you were relying on them. Enjoy the quirk by all means. Just don't let it into your budget, your habits or your team's definition of "normal".

I've been thinking about this because AI subscriptions are in a particularly slippery phase. Plans are being reshaped, products are being merged, and the line between "the chat window" and "the thing that does real work" is being redrawn in public. In the middle of that, people discover that one door in the building seems to be unmetered while the one next to it drains the allowance. Word spreads quickly. Within days a sensible-sounding folk wisdom forms: use this model, avoid that one, stick with the older interface, check on the phone app because it still behaves the old way.

None of that is stupid. It's what intelligent people do when the rules aren't written down. But it's worth noticing what has happened. A team has quietly started building habits on top of behaviour that nobody has promised them.

The documentation said one thing, the product did another

The tell is usually a disagreement between the published terms and what you can observe. The usage page says conversations aren't counted. The meter, tested a few times, appears to count them for some models and not others. The mobile app behaves differently from the desktop app. A refresh brings back an interface you thought was gone.

When that happens, the question that matters is which of the two will eventually be corrected. Almost never is it the documentation. Documentation describes intent, and behaviour that contradicts intent is a bug, an experiment or a rollout in progress. Any of the three will be resolved in the provider's favour, because they run the meter and you don't.

That doesn't make the provider the villain. Pricing for this kind of product is genuinely hard to get right, the costs behind a "chat" and an "agent doing work for an hour" are wildly different, and I have a lot of sympathy for anyone trying to put one simple price over both. But sympathy for their problem is not the same as building your plan on their unresolved answer.

What an accidental allowance costs you

The direct cost is obvious: the day it closes, your effective price goes up, or your capacity goes down, and you find out by hitting a wall in the middle of something.

The indirect costs are more interesting. The first is that your habits drift. If casual questions are free and serious work is metered, people start routing work by cost rather than by fit. They use the model that doesn't count rather than the one that's best for the job, and nobody notices the quality trade because the invoice looks fine.

The second is that you stop being able to forecast. A team that can't say what its tooling will cost next quarter isn't running a technology budget, it's running a hope. I've seen the same thing with cloud credits, free tiers and promotional pricing on integration services. The shape is always the same: a decision made on a price that was never the real price.

The third is quieter. A shared folk wisdom, "just use that one, it's fine", is a kind of undocumented dependency. It lives in people's heads and chat threads, it's partly wrong already, and it will be wholly wrong at some point. Nobody owns updating it.

A more boring way to do it

I've come to prefer a plain test. Ask what you would do, and what you would pay, if the generous behaviour disappeared tomorrow. If the answer is "we'd carry on, it would just cost a bit more", you're fine. Use the quirk, be grateful, keep going. If the answer is "that tool would stop being worth it", then the decision was never about the tool. It was about the quirk, and you should decide whether you want to bet on it with your eyes open.

In practice that means a few unglamorous things. Budget against the published terms, not the observed behaviour. Pick the model or tier for the job in front of you, and let the cheap path be a pleasant surprise rather than the routing rule. Write down, somewhere shared, what you believe about the limits and when you last checked. And when a provider's behaviour and documentation disagree, say so out loud to the team instead of letting the workaround spread by word of mouth.

None of this is cynicism. I like that these tools are getting cheaper and more capable, and I'd happily see the generous quirks stay forever. But commercial viability is a principle I take seriously for my own work, and it applies in both directions. Providers need a sustainable model to keep building the thing I'm using. They will close gaps to get there, and that's fair. My job is to make sure that when they do, the only thing that changes is my invoice, not my plan.

There's also a human side worth a mention. Watching a group of capable people compare notes on which button still works is oddly endearing, a bit like neighbours swapping tips on which supermarket checkout has the shortest queue this week. It's a very natural response. It just isn't a strategy, and the sooner we stop mistaking one for the other, the less surprised we'll be.

So enjoy the free lane while it lasts. Just don't schedule anything important to arrive by it.