We launched Agentic Batch Changes this week: the very first coding agent with outcome-based pricing. You only pay when you merge a PR, not per token. Despite the innovation in other verticals—Sierra, Fin, Decagon, and more all charge per resolution—dev tools have remained firmly tied to seat- and usage-based... pricing. So why are we doing this? We’re confident in the product, and pricing on outcomes is the clearest, most tangible way to prove it. This pricing puts our incentives in lockstep with yours.show more

And read more about the Agentic Batch Changes product here

As much as I like to believe that this is the future of the industry, there is a reason we can do this while others cannot. Most coding agents were designed to be general-purpose problem solvers, just as likely to be used for vacation planning or open-ended exploration as executing a code change. That makes ROI an impossible question. Agentic Batch Changes is a special-purpose agent, scoped deliberately in its harness, its system prompt, its permissions, and its tools, to solve one concrete problem. We built it to minimize cost at scale, rather than paying for an agent to do the same job a hundred or a thousand times over.

one agent that works beat five clever ones here

bold, this is real courage

Thanks!

How do your customers forecast their spend under this model? This is the most frequent question I get on outcome based pricing topic

It's not so hard for us. The product is used for migrations (library updates, security incidents, refactoring, etc). X repos covered, Y large-scale changes planned this Q, easy to estimate. The downside is more "yet another pricing model" than hard to predict.

per-merged-pr rewards tiny prs: the cheapest fee is a one line change nobody argues with. if the goal is incentives in lockstep, the contract needs the revert and re-open rate too, otherwise the metric is merge count

Definitely will be watching revert rates (it's just hard to track this). Happy to refund reverts for any customer who runs into them. We stand behind the results.

the hard part is attribution, not willingness. a revert three weeks later rarely points back at the pr. tag every agent pr and both revert and rot become priceable, including the dead code that never gets reverted and never gets billed

tracking is a challenge for sure. But we're taking a bet. And they would have paid for those tokens anyway. Won't keep our customers long if they question the quality.

Per-resolution pricing only works if "resolved" is shared. In support that definition is contested: no-reply closes, soft handoffs, and reopen within 48h all look green until you sample them. Who owns the definition when the invoice depends on it?

What happens if clients tell your agent not to merge, then go dig up the old branch and merge it?