The end of per-seat pricing: agents don't have seats.

The thesis

Per-seat pricing is a poor fit for agent-driven, artifact-shaped work, and the market is starting to price that in. The argument is simple: a seat is a proxy for a person, and a person is a proxy for the work and value a customer gets. When agents do a growing share of the work, that chain snaps. The seat count no longer predicts how much a customer uses or gets, so charging by it measures the wrong thing.

This is not a claim that per-seat is wrong for every product, and it is not a claim that any one vendor is bad. It is a claim about direction. The clearest evidence sits in a category we know well, static hosting, where one vendor just dropped per-seat pricing outright. We pulled the current numbers ourselves from each vendor's pricing page, and the table below is the citable centerpiece of this post.

Why agents break the seat assumption

The common argument runs like this: per-seat pricing assumes one human per seat, and each seated human does about one person's worth of work. That held when software was something a person sat down and operated. It holds less well now. When one person plus an AI agent does the work of several people, the value produced per seat climbs far above what a single seat implies. When an agent fleet runs thousands of tasks without ever logging in, there is no seat to count at all. The phrase that has stuck is that agents "do not need a seat."

That breaks the proxy in two directions. Underneath one paid seat, output can balloon, so the customer gets far more than they pay for and the vendor leaves money on the table. Above it, a workload that never authenticates as a user generates load, bandwidth, and storage that the seat meter cannot see at all. Either way, the number of seats stops correlating with either the value delivered or the cost incurred. A pricing model whose unit no longer tracks value or cost is a model under pressure, which is roughly what is happening across SaaS.

What static hosts charge per seat (June 2026)

We checked each vendor's own pricing page on June 7, 2026 and recorded what their paid entry tier costs and whether it charges per seat. Pricing changes often, so treat this as a dated snapshot, accurate as of June 2026, and verify against the linked sources before relying on it.

The proof point is Netlify. On April 14, 2026 Netlify removed per-seat pricing, moving Pro to a flat $20 per month with free unlimited team members and a shared credit pool, and explained the reasoning in a post titled "The end of seats: pricing Netlify for 3 billion builders." That is a vendor in this exact category deciding seats no longer fit a world where agents and automation, not just seated humans, drive the work. Vercel, by contrast, is still per-seat as of June 2026 at $20 per developer seat (with $20 of usage credit per seat), per its pricing page, though that too could change.

Disclosure: Stacktree is our product. It has been flat ($0 / $8 / $19 per month) and never per-seat since launch, with a free tier and an anonymous 24-hour first publish that needs no account. We are including it because it is the through-line of the post: Stacktree was flat before the category started to turn, not because it is the only sensible option. The honest framing is that the category is moving this way and Stacktree happens to have been built flat.

The wider shift to flat and usage pricing

The move away from seats is not confined to hosting. Gartner predicts that at least 40% of enterprise SaaS spend will shift to usage-, agent-, or outcome-based pricing by 2030, a figure widely reported across the industry. Beyond that, a run of SaaS-pricing analyses over the past year describe the same direction: per-seat's share of new deals shrinking, and hybrid models (a base fee plus usage) becoming the most common shape. Those analyses are blog and vendor write-ups rather than a single authoritative dataset, so we treat them as a direction of travel, not a precise measurement, and have left out the specific percentages they cite.

Outcome-based pricing is the sharper end of the same trend, and a few companies make it concrete. Intercom charges about $0.99 per resolved conversation, and HubSpot's customer agent moved to about $0.50 per resolution in 2026, according to the companies' own pricing. Those are customer-support products, a different category from hosting, so they do not tell you anything about what hosting should cost, and Stacktree does not do outcome pricing. They are useful only as evidence that the unit of pricing is moving away from headcount toward work done and results delivered.

Where per-seat still makes sense

Per-seat is not a mistake everywhere, and it would be dishonest to pretend otherwise. The model fits genuinely human, collaborative, seat-shaped products well. A shared design canvas, a team inbox, a document editor, a CRM where each salesperson logs in daily: in these, a seat really does map to a person who shows up and uses the thing, and seat count tracks both value and cost reasonably closely. For that kind of work, per-seat is honest and easy to reason about.

The problem is specific, not universal. Per-seat fits poorly when the work is agent-driven or artifact-shaped, where one human plus agents produces the output of several, or where automated workloads generate load without ever taking a seat. Hosting an agent's output is squarely in that second bucket: the thing being paid for is pages and builds and bandwidth, not human logins. So the right read is not "per-seat is dead," it is "per-seat is the wrong unit for agent and artifact workloads," which is the part of the market shifting fastest.

Where this leaves teams running agents

If you run agents that produce artifacts, pick a pricing model whose meter is on the artifacts, not on seats. For hosting specifically, that means flat or usage-based pricing, because an agent that publishes a page or runs a build never authenticates as a seated user. Counting seats undercounts what an agent-heavy team actually does, and a per-seat bill can feel arbitrary when most of your output never logged in.

Disclosure again, since this is our product: Stacktree is a flat-priced publish primitive for agent-made HTML, exposed over MCP, and we built it that way on purpose. But it is narrow, and the limits matter for this decision. Stacktree hosts static HTML only: there is no server-side logic and no application database. If your agents need to ship a full app with persistence, Stacktree is the wrong tool, and a per-seat or usage-priced application host (Vercel, Netlify, and others) may serve you better. The point of this post is not that Stacktree wins, it is that seats are a fading way to price agent and artifact work, and you should choose by what your workload actually produces.