Pricing for Partial Completion and Graceful Degradation: The GaaS Billing Problem Nobody Solved Cleanly

Table of Contents

• The problem outcome pricing pretends doesn't exist
• What "partial" actually means in an agent run
• Four ways vendors are pricing the messy middle
• Graceful degradation is a pricing tier, not just an engineering goal
• Designing a partial-completion rubric customers will accept
• The margin math: why partial credit can bleed you dry
• Contracts, disputes, and the auditability trap
• Insights Most People Overlook
• References

The problem outcome pricing pretends doesn't exist

Outcome-based pricing is the headline pitch of the agentic AI-as-a-service world. "We only charge when it works." It sounds clean, it aligns incentives, and it's catnip for buyers burned by per-seat SaaS they never fully used. The trouble is that the pitch assumes a binary that doesn't exist in autonomous work.

A human contractor who frames a house and runs out of money before the roof goes on hasn't delivered "no house." They've delivered a framed house. You'd never accept "we only pay when it's fully done, otherwise nothing" as the contract term, you'd negotiate progress payments tied to milestones. Yet a huge share of GaaS pricing pages today still imply that an agent run is pass/fail.

Real agent runs degrade in a hundred partial ways. A sales-research agent enriches 800 of 1,000 leads before hitting a rate limit. A support agent resolves the billing question but escalates the refund. A coding agent writes the function and tests but can't get the integration test green. A data-migration agent moves 94% of records cleanly and flags 6% as ambiguous. In every case, the customer got something with real value, and in every case, a naive "did it succeed? Y/N" billing rule produces an absurd outcome: either the vendor eats the cost of substantial delivered work, or the customer pays full freight for a job that wasn't finished. Both erode the relationship.

This is the gap between the marketing of outcome-based pricing and the operational reality of running agents at scale. The vendors who win Beat 2 of GaaS economics aren't the ones with the cleanest slogan. They're the ones who built a defensible answer to "what happens when it's almost done."

What "partial" actually means in an agent run

Before you can price partial completion, you have to decide what you're measuring. "Partial" collapses several genuinely different situations that deserve different pricing treatment.

Quantitative partial is the easiest. The task is a batch of identical units, leads enriched, invoices processed, images tagged, and the agent completed some fraction. Per-unit pricing solves this almost automatically. You charge for 800 enriched leads, not for the 1,000 you were asked to do. No drama, because the unit of value is countable.

Qualitative partial is harder. The deliverable is singular, a contract draft, a deployed feature, a resolved ticket, and the agent produced something that's 70% of the way to the goal. There's no clean denominator. A draft contract that's missing the indemnification clause isn't "70% of a contract"; it might be 95% of the words and 0% of the usability, or vice versa.

Degraded-but-complete is the sneaky one. The agent finished the whole task, but via a worse path: it used a cheaper fallback model, it took a slower manual route, it produced a lower-confidence answer, or it hit a guardrail and delivered a safe-but-generic result. The task is "done." The quality isn't what was promised. Should that cost the same as a clean run?

Useful-but-wrong-scope is the one that destroys trust. The agent confidently completed a task, but the wrong one, or with a flawed assumption baked in. Partial completion at least delivered real value; this delivered negative value, because someone now has to detect and unwind it. Pricing has to treat this category separately, and usually means no charge plus a remediation path.

If your pricing model doesn't distinguish these, your billing disputes will. Customers intuitively feel the difference between "you did 80% of a clear job" and "you did 100% of a worse job," and they'll fight you when you charge them the same for both.

Four ways vendors are pricing the messy middle

Across the GaaS market, four patterns are emerging for handling incomplete work. None is universally right; the fit depends on whether your value is countable, how expensive your failures are to detect, and how much your buyer trusts you.

1. Pro-rated per-unit

Where the task decomposes into units, charge for completed units only. Clean, auditable, and customers love it. The catch: it only works when units are genuinely independent and roughly equal in value. If completing the last 5% of leads (the hard, ambiguous ones) costs you 40% of the compute, flat per-unit pricing quietly inverts your margin on exactly the customers who push volume. This connects directly to the margin-safety questions covered in #63 (passing through volatile inference costs).

2. Milestone / checkpoint billing

Borrowed straight from professional services. Define checkpoints inside the workflow, "data gathered," "draft produced," "review passed," "deployed", and bill as each clears. The agent that frames the house gets paid for framing. This is the most honest model for qualitative, single-deliverable work, and it pairs naturally with floor-and-ceiling structures (#67) to cap customer exposure. The cost is design overhead: you have to instrument your agent to emit verifiable checkpoint signals, which is real engineering.

3. Tiered partial credit

A rubric maps completion bands to charge percentages: 0-30% complete bills nothing, 30-70% bills at half, 70-99% bills at 80%, full completion bills full. Simple to communicate, but only as good as your scoring function, and a scoring function customers don't trust is worse than no rubric at all.

4. Charge-on-acceptance

Shift the judgment to the customer. The agent delivers; the customer accepts or rejects; you bill only accepted work. This is the cleanest trust story and the riskiest revenue story, you've handed your top-line to the buyer's mood. It works when acceptance is low-friction and disputes are rare, and it pairs well with the credit-pool model (#66) so customers aren't writing a check every time they click "accept."

Graceful degradation is a pricing tier, not just an engineering goal

Here's the move most teams miss. Graceful degradation, the system's ability to deliver a reduced-but-useful result instead of failing outright, is usually treated as a pure reliability concern. The site-reliability world has talked about it for years; Google's Site Reliability Engineering material on graceful degradation and load shedding is the canonical reference. But in GaaS, degradation isn't just an engineering behavior. It's a billable state, and pricing it explicitly is a competitive advantage.

Think about what degradation looks like to an agent buyer. The premium path uses your best model, full tool access, and multiple verification passes. The degraded path, triggered by cost ceilings, rate limits, low-confidence inputs, or guardrail trips, uses a cheaper model, skips a verification step, or returns a confidence-flagged result. Both can "complete the task." They are not the same product.

If you charge full price for degraded output, you're overcharging and you'll get caught the first time a customer compares two runs. If you silently absorb the cost of every degraded run, your margin evaporates on exactly the hard inputs that trigger degradation most. The answer is to make the degraded path a named, lower-priced tier, and to tell the customer, at delivery, which path ran and what it cost them.

This is where pricing and engineering stop being separate disciplines. The same model-routing logic that decides "use the cheap model when possible" (the margin-expansion play in #87) is also the signal that should drive what you bill. If the router dropped to a fallback model, that fact should flow straight into the invoice as a discount. Vendors who wire routing decisions directly into billing get two things at once: protected margin and a transparency story competitors can't easily match. McKinsey's analysis of how generative AI is reshaping cost and value structures underscores that the economics of these systems live in exactly these per-run cost decisions, not in headline subscription prices.

Designing a partial-completion rubric customers will accept

A rubric is only worth building if buyers trust it. A scoring function the vendor controls, that the vendor also profits from, is a conflict of interest in plain sight, and sophisticated procurement teams will treat it as one. Three principles keep a rubric defensible.

Make the bands observable, not interpretive. "Task 70% complete" invites argument. "Agent completed steps 1-4 of 6 and produced a draft; steps 5-6 require human input" is a fact the customer can verify. Tie billing bands to concrete artifacts and checkpoints, not to a hidden quality score. The closer your bands map to things the customer can see in the output, the fewer disputes you'll fight.

Pre-register the rubric in the contract. The completion bands and their corresponding charges should be agreed before the work runs, not asserted after. This is the difference between a pricing policy and a billing surprise. It also forces a useful conversation up front about what "done" means, the same definitional fight that #57 (who defines and audits the outcome) covers in depth, and it's better to have it during the sale than during a dispute.

Build in an asymmetry that favors the customer. Round partial credit down on what you charge and up on what you credit back. A vendor who occasionally undercharges on a borderline run buys enormous goodwill for pennies; a vendor who fights for the last 8% of a contested partial charge wins the invoice and loses the renewal. In a market where switching costs are still low and trust is the scarce asset, generosity on partial completion is one of the cheapest retention tools you have.

One more practical note: log everything the rubric uses. When a customer disputes a partial charge, your defense is a replayable trace showing exactly what the agent did, where it stopped, and why. Without that, every dispute becomes your word against theirs, and you'll concede most of them.

The margin math: why partial credit can bleed you dry

Generous partial-completion pricing has a failure mode that doesn't show up until you're at volume: your costs are largely not partial even when your revenue is.

Consider an agent run that gets 60% of the way before stalling. Under a fair partial model, you bill 60% (or less). But your inference cost is often 80-100% of a full run, the agent burned tokens on the planning, retries, and tool calls that led up to the stall, and a stall frequently comes after the expensive exploration, not before. So on partial runs, you can easily collect 50% of the revenue against 90% of the cost. A few percent of partial runs is fine. If 25% of your runs go partial, that's a margin structure that looks healthy in the demo and loses money in production.

This is the trap behind "we only charge when it works" as a blanket policy. The runs that don't fully work are disproportionately your most expensive, hard inputs cause both the high cost and the partial outcome. They're correlated, and the correlation runs the wrong way for your P&L. The minimum-viable-margin discipline from #95 is non-negotiable here: you have to model partial-run economics separately, not assume they average out against clean runs.

The defenses are concrete. Fail fast and cheap: detect unrecoverable runs early so you abort before the expensive verification stages, not after. Charge a floor on substantial-but-incomplete runs that at least covers your variable cost, a partial-completion price of zero on a run that cost you real money is charity, not pricing. Cap retries so a single hard input can't burn unbounded compute chasing a completion you'll have to discount anyway. And price the degraded tier above its marginal cost, not as a courtesy, graceful degradation that loses money on every invocation is a liability dressed up as a feature.

Contracts, disputes, and the auditability trap

The moment you introduce partial pricing, you've introduced a new surface for disputes, and disputes are where GaaS contracts get tested. The vendors who handle this well treat the audit trail as a first-class product feature, not an afterthought.

The core requirement is a replayable, customer-legible record of what happened in each run: which steps completed, which artifacts were produced, what the agent's own confidence was, whether it ran the premium or degraded path, and where and why it stopped. This record does double duty. It's your evidence in a billing dispute, and it's the substrate for the SLA and refund mechanics covered in #98 (refunds and SLAs when an agent fails the task). Partial-completion pricing and SLA design are two faces of the same problem, both ask "how much did the agent actually deliver, and what does the customer owe or get back?"

There's a regulatory dimension too. In audited and regulated industries (#93), partial completion isn't just a billing question, it's a compliance one. If an agent partially processed a financial reconciliation and stopped, the customer may have a legal obligation to demonstrate exactly what was and wasn't touched. Your run trace becomes part of their audit, which means your logging granularity is now a procurement requirement, not a nice-to-have. Vendors selling into these markets should expect partial-completion auditability to show up in the security questionnaire.

The contract language that ages well does three things: it defines completion bands in observable terms, it specifies the charge (or credit) for each band, and it commits the vendor to providing the run trace on request. That's it. Vendors who try to keep the rubric vague to preserve "flexibility" are really preserving the right to surprise customers, and that right is worth far less than the trust they spend acquiring it.

Insights Most People Overlook

Partial completion is a leading indicator of your real failure rate, instrument it as a metric, not just a billing event. Most teams treat a partial run as a one-off to be priced and forgotten. But the rate and distribution of partial completions is the single best early-warning signal you have about agent reliability degrading. A creeping increase in 60-80% completions usually means an upstream tool got flakier or a model update shifted behavior, weeks before it shows up as outright failures. The billing system is accidentally the best monitoring system you have. Wire it into your reliability dashboards.

"Graceful degradation" can be a feature you sell, not just a cost you eat. Counterintuitively, some buyers will pay more for an agent that degrades predictably than one that occasionally nails the premium result but sometimes hard-fails. A support agent that always returns something useful, even a confidence-flagged partial, is more valuable in a customer-facing context than one that's brilliant 95% of the time and silent 5%. Predictable degradation is a reliability product. Price it as one, and sell the floor, not just the ceiling.

The customer's switching cost is lowest exactly at the moment of a partial charge. A disputed partial-completion invoice is the highest-churn-risk event in the entire GaaS relationship, higher than an outright failure, because a failure is unambiguous and a partial feels like nickel-and-diming. Treat partial-charge disputes as retention emergencies, not collections problems. The cheapest renewal insurance you can buy is reflexive generosity on contested partials.

Per-unit pricing secretly punishes you on the hardest inputs, and your best customers send the hardest inputs. The 5% of units an agent can't complete are almost never random, they're the ambiguous, malformed, edge-case inputs that also cost the most compute. High-volume power users send proportionally more edge cases, so flat per-unit pricing quietly transfers margin away from exactly the accounts you most want to keep. This is the same dynamic #97 flags about metered pricing punishing growth, viewed from the cost side. Tiered per-unit pricing that charges more for low-confidence inputs is fairer than it sounds.

A partial-completion rubric forces you to define "done", and that definition is more valuable than the rubric. Most agent products never rigorously specify what success looks like until a dispute forces it. Building the partial-pricing bands compels that definition up front, in writing, agreed by both sides. The rubric might rarely trigger. The shared definition of done it produces will prevent ten disputes the rubric never had to adjudicate.

References

• a16z, AI App Pricing and the Shift to Outcome-Based Models
• Google SRE Book, Handling Overload, Graceful Degradation, and Load Shedding
• McKinsey, The Economic Potential of Generative AI: The Next Productivity Frontier