The trouble with API keys that never expire
A key issued years ago, never rotated, and still valid today is not a convenience. It is a liability nobody has actually looked at in years.
The real cost of a provider's free tier changing overnight
A free tier gets treated, correctly or not, as a stable foundation. A developer builds a small tool, a hobby project, or an early prototype of a real product on top of a provider's free allowance, and that allowance quietly becomes load-bearing: the assumption baked into decisions about architecture, about whether to add a payment step at all, about how much the project is worth investing further time into. When a provider cuts that free tier overnight, tightens it substantially, or replaces it with a much smaller allowance, everything built on the old assumption breaks at once, with no warning and often no path to fix it except an unplanned, immediate purchase decision.
This kind of change is usually defensible from the provider's side: free tiers cost real money to run, usage patterns shift, and a company reserves the right to adjust terms. The cost of that change, though, does not land evenly. The provider absorbs a policy adjustment. The customer absorbs a broken integration, sometimes in production, sometimes affecting their own customers downstream, with no notice period to plan around.
We think a provider offering a free tier takes on an implicit obligation that goes beyond the legal terms of service: if that allowance is going to change substantially, customers relying on it deserve enough notice to adjust before the change takes effect, not after. This is part of why our free allowance, 2,500 requests a day from any address plus 2,500 more per key, counted per network, is not something we treat as a temporary promotional hook subject to being pulled once it has served its marketing purpose. It is a stated part of the pricing model, not bait for an eventual bait and switch.
There is a broader pattern worth naming here: a free tier used purely as an acquisition tactic tends to get adjusted once the acquisition goal has been met, because its only job was ever to attract signups, and once a critical mass of signups has occurred, the incentive to keep it generous weakens. A free tier treated as a permanent part of the pricing structure, sized based on what a provider can sustainably offer indefinitely rather than what looks maximally attractive on a landing page, does not carry that same incentive to shrink later, because it was never sized past what the provider intended to keep offering.
None of this is a promise that no pricing detail will ever change. It is a statement about what kind of change is fair to make without warning and what kind is not. A price increase on paid usage, announced in advance, is a normal business decision. Quietly gutting the free allowance that hobby projects and early prototypes were built on, without warning, treats those projects as expendable, which is a strange way to treat the exact users most likely to become tomorrow's paying customers if the free tier had just stayed put long enough for that project to grow into one.