What a Healthy GaaS Gross Margin Actually Looks Like in 2026

Table of Contents

• Why GaaS Margins Don't Look Like SaaS Margins
• The Honest Number: What "Healthy" Means in 2026
• What Actually Sits Inside GaaS COGS
• The Line Items SaaS Never Had
• The Costs Vendors Quietly Leave Out
• Margin by Agent Archetype
• Why Margin Erodes as You Scale (and How to Stop It)
• How Pricing Model Changes the Margin Conversation
• How to Audit a GaaS Gross Margin in Ten Minutes
• Insights Most People Overlook
• Frequently Asked Questions
• Conclusion
• References

Why GaaS Margins Don't Look Like SaaS Margins

Start with the thing nobody wants to say out loud at a board meeting: a software company's marginal cost of serving one more user is close to zero, and a GaaS company's marginal cost of serving one more task is emphatically not. When a SaaS app adds a user, it adds a row in a database. When an agent platform takes on another task, it spins up a reasoning loop, makes a string of model calls, pulls context from memory, fires off tool calls to third-party APIs, and sometimes spawns sub-agents that do the same thing again. Every one of those steps has a price with a meter running.

That single structural difference is why importing the 80% gross-margin expectation from SaaS into GaaS produces bad decisions. The standard SaaS benchmark, popularized in pieces like Bessemer's long-running work on cloud computing benchmarks and the "good, better, best" margin tiers, assumes COGS is hosting, support, and a thin slice of third-party fees. In GaaS, COGS is the product working. Inference isn't an infrastructure tax you can optimize to near-zero; it's the cost of the labor the agent is performing on the customer's behalf.

This is the conceptual bridge the whole cluster keeps returning to: GaaS economics resemble a services business wearing a software costume. The closest historical analog isn't Salesforce, it's a managed services firm or a BPO, where gross margin in the 40% to 60% range is normal and nobody panics. The difference is that GaaS can improve that margin over time through caching, model substitution, and routing, levers a human-labor business never had. So the right mental model is "services business with a software margin trajectory," and the healthy number lives somewhere between the two worlds.

The Honest Number: What "Healthy" Means in 2026

Here's the band I'd defend to a skeptical operator. As of 2026, a healthy GaaS gross margin is 55% to 70% blended across the customer base, with three important caveats.

First, the floor moves with your model strategy. An agent built entirely on frontier models for every step, no routing, no caching, no open-weight fallback, will struggle to clear 50% unless the per-outcome price is genuinely high. An agent that routes cheap steps to small or open-weight models and reserves frontier reasoning for the hard parts can reach 70% to 75% on the same workload. The architecture is the margin.

Second, blended hides everything. A vendor reporting 65% blended margin might be carrying a flagship customer at 82% and a free-tier-adjacent cohort at 15%. Healthy means the distribution is sound, not just the average, and it means your worst-served cohort isn't quietly underwater. This is exactly why cohort-level and use-case-level margin analysis matters more in GaaS than it ever did in seat-based software.

Third, healthy means margin is stable or expanding with volume. A GaaS business whose margin degrades as it scales has an architecture problem disguised as a growth story. The single best signal of a durable agent business in 2026 is a margin line that bends upward, or at least stays flat, as task volume climbs an order of magnitude. If it bends down, you're looking at a company that hasn't solved retries, fan-out, or idle compute, and those problems compound.

So when someone says "we run at 80% gross margin," the correct follow-up isn't congratulations. It's: which steps are you not counting?

What Actually Sits Inside GaaS COGS

To judge a margin you have to know what's in the denominator. GaaS COGS is broader and lumpier than most income statements admit.

The Line Items SaaS Never Had

The big one is inference spend, the tokens consumed by the agent's reasoning, including the "thinking" tokens that never appear in the customer-facing output but still get billed. On extended-reasoning models, those hidden thinking tokens can dwarf the visible response, and they're a real cost center most teams under-track. Provider rate cards like Anthropic's published model pricing make the per-token math easy in isolation, but an agent doesn't make one call, it makes dozens, and the multiplier is where budgets break.

Then come the costs that are uniquely agentic:

• Retry overhead. When an agent fails a step and re-attempts, you pay again. A task that looks like one model call can quietly become fifty when a tool returns garbage and the agent loops trying to recover.
• Tool-call costs. Every external API the agent hits, search, code execution, a vendor's data feed, has its own price, and they stack across a workflow.
• Fan-out. When an agent spawns sub-agents, each child runs its own reasoning loop. Cost can grow super-linearly with task complexity, which is brutal for forecasting.
• Memory and retrieval. Long-running and stateful agents pay to store and re-load context. At scale, vector storage and retrieval are a genuine COGS line, not a rounding error.

The Costs Vendors Quietly Leave Out

The margins that look too good usually exclude the unglamorous stuff. Idle agent cost is the classic example, an agent provisioned to be "always ready" still consumes resources between tasks, and vendors love to keep that out of per-task COGS. Human-in-the-loop labor is another: if your "autonomous" agent needs a human reviewer on 20% of tasks, that reviewer's time is a cost of goods sold, full stop. Pretending otherwise inflates margin and hides the truth that human-intervention rate is, functionally, both a quality signal and a margin signal.

Reserved versus on-demand compute also swings the number. A team running everything on-demand pays a premium; a team that's negotiated reserved capacity or committed spend can shave meaningful points off COGS, a lesson GaaS is still learning from the cloud-infrastructure playbook. None of this shows up in a headline margin. All of it shows up when usage triples.

Margin by Agent Archetype

Margin isn't a single number across GaaS, it's deeply vertical-dependent, because the work each agent does has a different cost-to-value ratio. Rough 2026 contours:

Coding agents tend to be inference-heavy and frontier-dependent, code generation rewards the strongest models, and verification loops add retries. Realistic gross margins often land in the 45% to 60% range at scale unless the vendor caps autonomy or aggressively caches. The upside is that customers will pay a lot per outcome, so even a "thin" margin can be a great business in absolute dollars.

Customer-support agents are the sweet spot. Most tickets are short, repetitive, and highly cacheable; retrieval-augmented answers reuse the same knowledge base over and over. Well-run support agents can reach 65% to 78% gross margin because so much of the workload is cheap, deflectable, and amenable to smaller models. This is the archetype that looks most like software.

Sales-development agents sit in between. Personalization burns tokens and the value-per-task is real but variable; margins commonly run 55% to 68%. The CAC question looms larger here than the margin question, which is a different but related economic headache.

The pattern: the more an agent's work resembles repetitive knowledge retrieval, the higher the achievable margin. The more it resembles open-ended reasoning, the lower the floor, and the more the vendor has to engineer around it.

Why Margin Erodes as You Scale (and How to Stop It)

The cruel surprise in GaaS is that margin can get worse as you grow, the opposite of the software default. Three forces drive the erosion.

Power users skew the distribution. Usage-based products attract heavy users who run the most complex, most expensive tasks. If pricing doesn't scale with cost, your biggest fans become your worst-margin customers, a dynamic finance teams find maddening because it makes consumption revenue lumpy and low-margin at the same time.

Complexity creeps. As customers trust the agent with harder jobs, fan-out and retries climb. The task mix shifts toward the expensive tail, and blended margin slides even if no single task got more expensive.

Reliability has a price. Pushing success rate from 90% to 99% often means more verification passes, more retries, and more human review, each of which is COGS. There's a real, quantifiable cost to that last reliability mile, and it lands squarely in gross margin.

The defenses are the quiet levers that separate good operators from the rest: prompt and response caching to avoid re-paying for repeated context; model routing so cheap steps never touch a frontier model; memory reuse to cut redundant retrieval; reserved compute for predictable baseline load; and, increasingly common in 2026, autonomy caps, where vendors deliberately limit how far an agent will run unsupervised, partly for safety and partly to protect margin. That last move is more widespread than vendors admit, and it's worth understanding why a startup might choose to make its agent less autonomous.

How Pricing Model Changes the Margin Conversation

You can't evaluate margin without knowing how revenue is structured, because each pricing model distributes risk differently.

Cost-plus / pass-through ("we just bill model costs plus a markup") looks safe and is secretly a trap. It caps your margin at the markup, exposes you directly to token-price and token-volatility swings, and signals to customers that you're a thin reseller. When inference costs spike on a Tuesday, your margin moves with them and you have no buffer.

Per-task pricing decouples your price from your cost, which is great when your cost-per-completed-task is below your price, and terrible on the tasks where retries blow the budget past what you charged. It makes forecasting genuinely hard, because revenue and cost both move with usage you don't fully control.

Per-outcome pricing is the most defensible margin story when you can actually measure the outcome, you charge for value delivered, not work performed, so efficiency gains flow straight to margin. The catch is measurement: if you can't cleanly attribute the outcome to the agent, you can't price it, and disputes erode realized margin.

The throughline: pricing that floats with your cost protects you from volatility but caps your upside; pricing that's fixed against your cost gives you margin expansion as you optimize, but exposes you to runaway-spend scenarios. Healthy GaaS businesses in 2026 increasingly favor outcome or task pricing with hard internal spend caps, so a single runaway agent can't turn a profitable task into a loss.

How to Audit a GaaS Gross Margin in Ten Minutes

If you're an operator or an investor staring at a GaaS P&L, here's the fast diagnostic:

1. Ask for fully-loaded cost-per-completed-task, not per-call. A per-call number ignores retries and fan-out. The completed-task unit is the only honest denominator.
2. Ask what's excluded from COGS. Specifically: idle compute, human review labor, memory storage, and thinking tokens. If any are missing, the margin is overstated.
3. Ask for the margin distribution by cohort, not just the blend. Look at the worst-served 10%. If they're underwater, the business has a hidden churn-and-margin problem.
4. Ask how margin moved as volume grew 10x. Flat or up is healthy. Down means the architecture hasn't solved the scaling levers.
5. Ask the model-mix question. What share of spend goes to frontier versus small or open-weight models? An all-frontier stack with a high margin is either mispriced upward or hiding costs.

Run those five and you'll know in minutes whether a "70% gross margin" is real engineering or accounting optimism.

Insights Most People Overlook

A falling token price doesn't lower your bill, and it can quietly raise it. Cheaper inference makes teams comfortable running longer reasoning chains and more aggressive fan-out, so consumption rises to fill the new budget. Margin improvements from price cuts get spent on capability, not banked. Plan as if the per-task cost is flat even when the per-token rate drops.

The highest-margin GaaS companies are deliberately less autonomous than their marketing. Full autonomy means uncapped reasoning loops, and uncapped loops are uncapped cost. Several of the best margin profiles in 2026 come from vendors who quietly bound how far the agent will run before checking in, selling "controlled autonomy" as a reliability feature while it's also a margin control.

Gross margin and human-intervention rate are the same metric viewed from two angles. Every percentage point of tasks that needs a human is a percentage point of services-grade COGS. Teams that obsess over autonomy % as a quality KPI often haven't connected it to the P&L, but it's one of the most direct margin levers they have.

Blended margin is where dying cohorts hide. Because GaaS churn is often invisible until it's catastrophic, a healthy-looking average can mask a cohort that's both unprofitable and about to leave. Margin analysis and retention analysis need to be done on the same cohort cut, or you'll miss the customers who are expensive and unhappy.

The "we'll just pass through model costs" plan caps your company's ceiling. It feels prudent, but it permanently ties your margin to the most volatile input in your business and tells the market you have no proprietary efficiency. The companies expanding margin are doing the unglamorous engineering, caching, routing, memory reuse, that a pure pass-through model gives you no reason to build.

Frequently Asked Questions

Is a 40% gross margin ever acceptable for a GaaS company? Early on, yes, if the trajectory is clearly upward and the architecture levers (caching, routing, reserved compute) are unbuilt rather than impossible. A 40% margin that's been flat for two years is a structural problem. A 40% margin on month-six infrastructure that's already climbing is a normal starting point for a compute-heavy business.

How is GaaS gross margin different from cost-to-serve? Cost-to-serve is the COGS side in isolation; gross margin is that cost against realized revenue. The trap in GaaS is that revenue and cost both move with usage, so you can't reason about one without the other. Always pair cost-to-serve benchmarks with the pricing model that sits on top of them.

Why can't I value a GaaS company on SaaS revenue multiples? Because the gross-margin profile is different, and multiples are partly a proxy for margin durability. A 60%-margin usage-based business with lumpy revenue doesn't deserve the same multiple as a 85%-margin subscription business with predictable MRR, and pretending otherwise is how GaaS valuations get set up to disappoint.

Do open-weight models meaningfully improve margin? They can, on the right steps. Routing cheap, repetitive, or low-stakes work to open-weight or small models, while reserving frontier models for genuinely hard reasoning, is one of the most reliable ways to lift margin without hurting quality. The win comes from the routing discipline, not from open-weight models everywhere.

What's the single most misleading number on a GaaS margin report? Per-call cost. It systematically undercounts retries and fan-out, making the agent look far cheaper to run than it is. Insist on fully-loaded cost-per-completed-task as the unit of account.

How do thinking tokens affect margin? On extended-reasoning models, the agent's internal "thinking" can consume more tokens than the visible answer, and you're billed for all of it. If your COGS model only counts output tokens, you're understating cost, sometimes dramatically, on exactly the hard tasks where reasoning runs longest.

Conclusion

A healthy GaaS gross margin in 2026 isn't the 80% number SaaS conditioned everyone to expect, it's a 55% to 70% blended band, earned through architecture rather than assumed from a business model. The percentage is less important than three properties: the COGS is fully loaded (retries, fan-out, idle time, human review, and thinking tokens all counted), the distribution is sound at the cohort level, and the trend holds or improves as task volume scales. Margin in this category is a function of engineering decisions, caching, model routing, memory reuse, reserved compute, and deliberate autonomy limits, far more than of pricing alone. Treat gross margin as a living metric tied to your cost-per-completed-task, your human-intervention rate, and your cohort retention, and you'll see the health of an agent business that a single headline number will always hide. Get the unit economics right at the task level, and the margin takes care of itself.

References

• Bessemer Venture Partners, Scaling to $100 Million (cloud benchmarks and gross-margin tiers)
• Anthropic, Model Pricing Documentation