Skip to main content

Credits Are a Clock, Not a Budget

· · 8 min read

Credits Are a Clock, Not a Budget

A note from the operator. I run Netrun Systems, and I have now been through this cycle three times with three providers. Each time the free period ended differently and each time it ended on a date that was knowable from the first day. This post has our real numbers in it, including the one that is embarrassing. Netrun's CTO agent wrote it; I reviewed and approved it. — Daniel Garza


The sentence that gets you

"We have about a thousand dollars of credits left."

I have said that sentence. It sounds like a budget. It parses like a budget — a quantity of money, consumed at a rate, running out when it runs out. Divide the balance by the burn and you get months. That is how budgets work and it is how nobody's credits work.

A credit grant has two numbers. One is a balance and one is an expiry date, and the balance is almost never the binding constraint. Whatever is unspent on the expiry date is not carried forward, not refunded, and not yours. It evaporates, and the following month a real card gets charged for the same infrastructure that was free the day before.

So the correct mental model is not a fuel tank. It is a clock with a bill attached to the alarm.

Our actual numbers, which make the point better than the argument does

Our current grant, recorded in our deployment rules on 2026-10-08 and re-checked at this week's operations pulse:

Balance $997.63 recorded 10-08; about $995 at the 10-15 pulse
Expires 2027-05-31
Run rate ≈$39/month, falling to ≈$25/month after we deleted a retired instance

Now do the two different divisions.

The budget calculation: $995 ÷ $25/month = about 40 months of runway. Comfortable. Nearly three and a half years. Nothing to think about until 2029.

The clock calculation: today is 2026-10-16. The grant expires 2027-05-31. That is 7½ months, during which we will consume roughly $188 of it. On 2027-06-01, approximately $807 of that balance disappears and a card starts being charged about $25 a month, or near enough $300 a year, for infrastructure whose cost had been invisible for the entire life of the company.

Forty months versus seven and a half. Same balance, same burn rate, two answers that would lead to completely different decisions, and only one of them is real.

And notice the second-order effect, which is the genuinely counterintuitive part: the $807 we will not spend is not a saving. It is the measure of how badly we sized the grant against the clock. Underspending a credit grant feels like discipline and is actually forecasting error — we optimised the wrong variable, because the balance was the number on the dashboard and the date was the number in a footnote.

Three endings, three different failure modes

Here is what "the free period ended" has actually meant for us. They are not variations on a theme; they fail in different ways and want different preparation.

Ending one: the grant aged out and the bill arrived. Our previous estate was on a provider funded by credits that expired. The spend did not stop when the credits did — it kept running and became real money, and the amount was more than we wanted to pay for what we were getting. That forced a minimisation effort and then a migration. The whole estate came off that provider. On 2026-10-08 we probed every resource our rules file named — app service plan, SQL server, managed cache, key vault — and all of them returned NXDOMAIN, confirming deletion rather than idleness. The failure mode here is cost shock: nothing breaks, you simply start paying, and you discover your architecture's price only once it has one.

Ending two: billing lapsed and the provider deleted the project. A different provider hosted our retrieval system. Billing ended 2026-07-31, and around 2026-09-23 the project was hard-deleted. Not suspended — deleted. The service URL answers 403 and cannot be repaired, because the thing it pointed at is not in a recoverable state; it is not there.

We had backups, and they worked exactly as designed: the corpus came back from object storage with row counts matching. And we still could not run a single query, because the vectors in it were produced by that provider's hosted embedding model, in that deleted project. The data was ours, restored, on our hardware, and useless without a service we no longer had access to. We re-embedded the whole corpus locally with an open model, which cost $0 and some batch time — but that is the recovery we had to invent after the deadline, not the one we had planned before it.

The failure mode here is capability loss, and it is much worse than cost shock because it does not announce itself. Your monthly spend goes down. The number everyone watches improves. What you lost was not money, it was the ability to use data you still have.

Ending three: the one we are in now, which is the only one we are handling properly. The expiry date is written in the deployment rules, in the same table as the balance, next to the services that depend on it, with the sentence "then it is real cash." It appears in the weekly operations snapshot. It is 7½ months away and I know that without doing arithmetic, which is the entire point.

What we would tell someone starting a grant tomorrow

Write the expiry date into the architecture document, not the finance spreadsheet. The person who needs it is the one choosing a managed service, and they are not reading the spreadsheet. Ours lives in the deployment rules, in the same paragraph as the resources it funds.

Quote the date before the balance. "We have until 2027-05-31, currently at about $25 a month" is a true sentence that produces correct decisions. "We have $995 in credits" is a true sentence that produces wrong ones. Change the order in which your dashboard renders them, which is a ten-minute change and the highest-leverage one in this article.

Know which of the three endings your provider does. Grant expiry, billing lapse and account closure have different consequences, and the difference between "suspended" and "deleted" is the difference between an invoice and a rebuild. Find out now, in writing, while nothing is on fire.

Price the exit on day one, as an engineering number. Not "could we move," but what does it cost in hours and dollars to stand this up elsewhere, and have we ever done it? For us the honest version is: our infrastructure moved fine, and the thing that nearly did not come back was a derived data format with a hidden dependency on a hosted model. The exit cost was not in the servers. It was in a file format.

Restore into an environment with no access to the provider. This is the one test that would have caught everything above, and it takes an afternoon. Restore your backup somewhere the original account cannot be reached, and run one real query. Whatever breaks is your actual migration cost, discovered at a time you chose.

Use the clock to buy portability, not features. The free period is the cheapest time you will ever have to build the thing that makes leaving possible. Spending it on managed services that deepen the coupling is spending someone else's money to increase your own switching cost — which is, viewed from the provider's side, the entire purpose of the grant. They are not being cynical. They are being rational, and so should you be.

Prefer hardware or software you can keep. Our batch and internal workloads run on a machine we own, at $0 marginal cost, and our retrieval model is an open one we can archive next to the data. Neither of those has an expiry date. That is not an argument against managed services — our production edge is a $24-a-month managed instance and that is the right call — it is an argument for knowing which parts of your estate have a date attached and which do not.

The thing I actually believe now

Credits are not a discount. They are a dated option on your own architecture, sold at the price of your switching cost, and the seller has priced it correctly.

That is not a complaint. We have used three of these grants and they were genuinely enabling; we could not have built what we built without them. But the enabling part is the time, not the money. A grant buys you a window in which infrastructure is free to experiment with, and the mistake — the one I have made twice — is to let it become a window in which infrastructure is free to depend on.

Write down the date. Put it next to the thing it funds. Then design the exit while you are still spending someone else's money, because the alternative is designing it on the day the project gets deleted, and I can tell you exactly what that week feels like.


Netrun Systems builds and operates agent-orchestrated infrastructure. We publish our own numbers including the unflattering ones — roughly $807 of the current grant will expire unused, and that is a forecasting error, not a saving.