SaaS Isn't Dead. You're Just Not Paying for Tokens Yet.

Is SaaS dead? A lot of people say so, and the argument is easy to follow. Anyone can vibe-code their own tools now, so why pay a vendor, say, $30 a month for something an agent can write over a weekend?

I run coding agents every day, and I think the premise is half right. SaaS got cheaper to produce. Owning software still costs what it always did, and the tokens cost more than the seat price suggests. The price you see on a coding-agent subscription is a subsidized price, and build-versus-buy math that only works at that price is fragile.

The subsidy

I covered this in the 17x post, so I won’t re-derive it. The short version: my team’s $200 seats consume $1,800 to $3,500 of API-priced tokens per developer per month, the theoretical ceiling on that plan is around $8,000, and the discount works out to 10 to 17x in practice and up to 40x at the limit.

Those are the numbers I published for my team. Your usage will differ, and the direction will still hold. A subscription is priced against a typical user, and anyone running agents all day is far from typical.

Build versus buy at real prices

Here is an illustration, built from those published figures. It is not a record of anything I built.

Say replacing a $30 per month SaaS tool takes a week or two of one developer’s agent time, and that would cost $1,000 at API list rates. That is about 33 months of the subscription you were trying to cancel, and you have not maintained anything yet. If the vendor offers a multi-year prepaid contract, the comparison gets worse for the build, because prepaid usually comes discounted.

At $400 the payback is still over a year. The point of the exercise is to use the right price for the tokens. Most build-versus-buy spreadsheets use the seat price, because that is the number on the invoice, and the seat price is the discounted one.

In the 17x post I told teams to budget agent adoption at the seat price, and I still would. A seat you already pay for makes a small build nearly free at the margin. Replacing a vendor is a different decision because it lasts years, and you will maintain that tool at whatever the seat buys in 2028. Run the build at list rates as a stress test. If it only pays off at today’s seat price, it is thinner than it looks.

Then there is the ownership bill. Someone has to patch what got built, secure it, and keep it running after the person who prompted it moves on. I wrote down what that looks like in what I check when I inherit a vibe-coded app, which is the playbook for taking over an undocumented AI-built app after the builder walks away.

The limits already moved once

Anthropic changed its Claude Code limits in September, and the way it did it is worth reading closely.

BleepingComputer reported on August 29, 2026 that a temporary 50% weekly-limit boost on Claude Code would run until September 14. From September 14, the standard weekly limits became 25% above the original baseline. Anthropic said it was “permanently raising standard weekly limits in Claude Code by 25% for Pro, Max, Team, and seat-based Enterprise plans.” In the same announcement, Anthropic said the change “works out to a 17% reduction in weekly limits on Claude Code” compared with the boosted level.

Both are true. Against the old baseline, users got a permanent 25% raise. Against the promotion they had been living on, they got a 17% cut. People plan around the number they have been using, so the second one is the one they feel.

Shrinkflation is the closest word I have for it. The package keeps its price, the label stays the same, and the amount inside changes. The 17x post said “maybe limits tighten instead” of the discount becoming permanent. I was guessing when I wrote that, and one adjustment does not prove a trend, but it is the direction I would have bet on.

When the subsidy turns off

This part is my prediction. At some point, someone pays list price. It might be the customer, or a vendor who decides the growth bet is over. I can’t tell you when.

When it happens, the businesses hit hardest are the ones whose economics only work on today’s subsidized seats. That includes vibe-coded internal replacements that were justified by a subscription price, and products whose margins assume seat-price tokens. A tool that is already built keeps running. What gets more expensive is every fix and feature after that, and the owner doesn’t choose when.

SaaS vendors come out looking better. They spread build cost across thousands of customers and have already paid for the engineering, and I expect that gap to widen if tokens cost more.

Somebody pays the bill

Follow the money for a minute. In September 2025, NVIDIA announced that it “intends to invest up to $100 billion in OpenAI as the new NVIDIA systems are deployed”. That was a letter of intent, so the $100 billion was a plan. By March 2026, Jensen Huang said “the opportunity to invest $100 billion in OpenAI is probably not in the cards”. Still, look at the shape of the original deal. The chipmaker invests in the AI company, and the AI company buys the chipmaker’s systems. I mentioned the “loopification” critique of AI financing in my post on Nadella and token capital and set it aside there, because his essay wasn’t about it.

The spending is also reaching payroll. Microsoft is offering buyouts to about 60,000 eligible employees while planning about $175B in capital spending, and I wrote about that in Microsoft is trading salaries for data centers.

I don’t know if this is a bubble, and the bill comes due either way. The buildout will probably keep pushing per-token list prices down, as I argued in the AI tax post. Nothing obliges a vendor to pass that through to a seat. Whoever funds it expects a return, and I expect the subscriber to be where that return eventually comes from.

Squaring this with the AI tax post

In the AI tax post I wrote that the per-token cost of intelligence is still falling while the hardware underneath gets pricier. That post was about the price of a token. This one is about how many tokens a seat buys. List prices can keep falling while the weekly limit on a $200 seat shrinks, and anyone building on a seat hits the limit first. If list prices fall fast enough, the $1,000 in my example shrinks with them and the build case gets better. The maintenance line is mostly people’s time, and that doesn’t get cheaper when tokens do.

What I would do

If you run a startup or lead an engineering team, here is what I would do on Monday.

Run any replacement build at API list rates as a stress test, next to the seat-price number. Count the tokens the work used, multiply by list price, and put that number in the spreadsheet next to the vendor’s quote. Add a line for maintenance, because someone will do it.

Buy the boring SaaS. Payroll, ticketing, billing, status pages and forms are commodity, and every competitor buys the same ones. Vibe-code the parts that are actually your edge, the things a competitor can’t buy.

Prefer multi-year prepaid contracts on tools you know you will keep. That fixes the vendor’s price while the cost of building your own is the number that moves.

Read the limits pages. The $200 on the invoice tells you nothing about what it buys this month. The weekly limit, and how that number changed since you last looked, is the real price, and that is the page I would check before approving the next replacement project.

If you are weighing this for your own company, that is the kind of question I help founders work through on the consulting page.