When we set Gravity's pricing, the published decision was simple: pay-per-use credits, one dollar for one thousand credits, charged only when an agent runs. No seats, no subscription, no minimum. This post is a reflection roughly six weeks after living with that model day to day. It is not a re-explanation of how the mechanics work; if you want the full walkthrough of credits and runs, that lives in our explainer, Gravity Pricing Explained: The Credits Model. This is the build-in-public version: what held up, what we got wrong about our own assumptions, and what usage-based billing actually feels like once it is the real thing rather than a slide.

We are pre-launch, so we are deliberately keeping specifics qualitative. We will not quote usage figures, revenue, or counts we cannot stand behind. The one hard number is the published rate, one dollar for one thousand credits, pay-per-use. Everything else here is a judgment about a pricing model, not a claim about traction. The honest summary up front: usage-based pricing fits AI agent work better than the seat model we were tempted by, and most of the friction we expected turned out to be a design problem we could solve, not a flaw in the model.

Why we picked credits over seats

The default for software is a per-seat subscription, and it is the default for a reason: it is predictable for the vendor and easy to forecast. But it fits agent work badly. A seat charges every named user the same fixed amount whether they run a hundred agents a week or none, which means you are billing people for capacity they may never touch. Agent usage is bursty. Someone runs a research agent hard for two days before a launch, then nothing for a fortnight. A seat model overcharges the quiet weeks and, perversely, makes people feel they have to "use up" the subscription to justify it.

Credits invert that. You pay when an agent runs and produces something, and you pay nothing when it sits idle. That is the core of our credits model: cost tracks work, not headcount. It also matches the underlying reality that Gravity runs the agents and carries the compute cost on every run. Charging per run keeps our price tied to the thing that actually costs us money and actually delivers value to the user. If you are weighing this against running your own stack, the same trade-off shows up in build vs buy an AI agent, where the hidden cost is the idle infrastructure you maintain whether or not it is doing work.

What worked in the first six weeks

The clearest win was the lowered bar to trying something. When the cost of a single run is small and visible, people reach for an agent to do a small task they would never have justified under a monthly fee. There is no commitment to amortize, so a one-off job, draft this, summarize that, check this batch, becomes a casual decision rather than a budget decision. That is exactly the behavior you want for a platform where the value is in an agent doing real work end to end, because trying is how people find the runs worth repeating.

The second thing that worked was conceptual honesty. Pay-per-use is easy to explain and hard to feel cheated by. You spent credits, an agent did work, you got a result. There is no awkward conversation about why you are paying for four seats when two people actually use the product, and no annual contract to renegotiate. For a pre-launch platform asking people to trust something new, a pricing model you can explain in one sentence removes a whole category of doubt. It also makes us easy to evaluate honestly against alternatives, which is the spirit of how to evaluate AI agent platforms: simple, legible pricing is itself a signal.

What surprised us

We expected the headline benefit of usage-based pricing to be cost savings for the user. The actual headline benefit was cognitive: people valued not having to think about it. With no seat to justify and no subscription clock ticking, the standing question "am I getting my money's worth this month" simply disappeared. In its place was a much smaller, per-run question that answers itself. We had modeled pay-per-use as a pricing decision. It turned out to be a psychological one too, and the psychology was the bigger effect.

The second surprise cut the other way. We assumed people would want maximum granularity, an itemized cost for every sub-step. In practice, too much granularity created anxiety, not confidence. What people actually wanted was a clear, single number for a run before they committed to it, plus a balance they could glance at. The lesson was that transparency is not the same as detail. A trustworthy "this run will cost about this much" beats a forensic breakdown that makes someone feel they are being metered on every keystroke. That reframed predictability from a reporting feature into an up-front design choice.

How credits map to outcomes

A subtle advantage of credits is that the unit means something. A credit is a unit of work. Because you spend credits when an agent runs and hands back a finished result, the cost of a run lines up with the outcome you were after: a drafted document, a researched answer, a cleaned-up batch. That makes the only comparison that matters easy to do in your head. You are not asking "is this worth a tier upgrade," you are asking "did the credits this run cost buy me something more valuable than those credits," which is a concrete, per-result judgment.

This is also why we resist dressing the model up. The temptation with any usage-based system is to add multipliers, bonus tiers, and expiring promotional credits until the unit stops meaning anything. We have kept the mapping deliberately plain because the value of credits as a concept is that they stay legible: one dollar buys one thousand credits, a run spends some, and you can always see the trade. The moment a credit stops being a steady unit of work, you lose the thing that made the model honest in the first place.

The objections, answered

The fair objection to usage-based billing is predictability. Seats are easy to budget; metered usage carries the fear of a surprise bill. We take that seriously, and the answer is design, not a return to subscriptions. Three controls do most of the work. First, show the expected cost of a run before it starts, so nobody is metered blind. Second, keep a running balance in view, so spend is never a mystery you reconcile at month end. Third, credits are prepaid rather than billed in arrears, which caps exposure by construction: you cannot overspend credits you have not bought.

Put together, those turn "unpredictable" into "bounded." Your spend lives inside an envelope you set when you buy credits, and you can see it draw down in real time. For a team, that is arguably more controllable than a stack of seats that silently renews. The other common objection, that pay-per-use punishes heavy use, has the opposite shape in practice: heavy use is exactly when an agent is delivering the most work, so paying in proportion to that work is the fair case, not the painful one. Predictability was the objection we worried about most, and it became the part we are most confident we got right.

Why pay-per-use aligns incentives

The part of this model we have come to value most is what it does to incentives. Gravity runs the agents and carries the compute cost on every run, and we only earn when an agent does work a user judged worth running. There is no revenue from idle seats, no money in someone forgetting to cancel. That ties what we charge directly to work delivered, and it points the whole company at the right goal: make agents reliable, useful, and worth re-running.

That alignment is not a slogan, it is a constraint we chose on purpose. Because builders build and maintain agents for Gravity and we are responsible for running them, the pricing only works if the agents are good enough that people come back. A seat model can hide a mediocre product behind an annual contract; pay-per-use cannot. If a run is not worth its credits, it does not get repeated, and we feel it immediately. We would rather have that honest feedback loop than the comfortable lag of a subscription. It is the same reason we keep writing about the work openly, including in our June 2026 monthly retro: the model only earns trust if we are candid about how it is going.

What we are still tuning

Six weeks is enough to validate a direction, not to declare it finished. A few things are still open. We are refining how clearly we communicate per-run cost for longer, multi-step agents, where the estimate matters most and is hardest to pin down. We are thinking about sensible defaults for ceilings and alerts so that the controls protect people without nagging them. And we are watching how the model feels for genuinely heavy, repeated workloads, where the question of volume-friendly pricing will eventually come up. None of these are reasons to reconsider the model; they are the ordinary tuning of a model we are increasingly sure about.

The takeaway after six weeks is plain. Pay-per-use credits fit AI agent work because agent work is bursty, outcome-shaped, and best billed by the run. The fears we had, mostly about predictability, turned out to be solvable with up-front design rather than fundamental flaws. And the model does something a subscription cannot: it keeps our incentive pinned to delivering work worth paying for. That is the version of pricing we want to launch on, and the six weeks made us more confident in it, not less.

Frequently asked questions

How does Gravity's credit pricing work?

Gravity uses pay-per-use credit pricing. You buy credits at a published rate of one dollar for one thousand credits, and a run spends credits only when an agent actually does work. There is no seat fee and no monthly subscription. If you do not run an agent in a given period, you spend nothing. For a full walkthrough of how credits map to runs, see our explainer, Gravity Pricing Explained: The Credits Model.

Why did Gravity choose usage-based billing instead of seats?

Agent work is bursty and uneven, so a per-seat subscription charges people for capacity they are not using. Usage-based billing ties the price to the work done: you pay when an agent runs and produces a result, and nothing when it sits idle. That matches how teams actually use agents, and it keeps the incentive on delivering useful runs rather than selling seats.

What surprised the team six weeks into credit pricing?

The biggest surprise was how much people valued not thinking about it. With no seat to justify and no subscription clock running, the question shifted from is this worth the monthly fee to is this run worth a few credits, which is a much easier yes. The second surprise was that clear per-run cost made people more willing to try an agent for a small task, because the downside was visibly small.

Is usage-based pricing predictable enough for budgeting?

Yes, with the right controls. The fair concern with usage-based billing is a surprise bill. The answer is to make per-run cost visible before a run, keep a running balance, and let people set their own ceilings. When cost is shown up front and credits are prepaid rather than billed in arrears, spend stays inside a known envelope and budgeting becomes straightforward.

How do credits map to real outcomes?

A credit is a unit of work, not an abstract token. Because you spend credits when an agent runs and returns a finished result, the cost lines up with the outcome you wanted: a drafted document, a researched answer, a processed batch. That makes it easy to compare the credits a run costs against the value of the result, which is the comparison that actually matters.

Does pay-per-use align Gravity's incentives with users?

It does. Gravity runs the agents and carries the compute cost, so the platform only earns when an agent does work a user found worth running. There is no revenue from idle seats. That ties what Gravity charges to the work delivered, and it pushes the platform to make agents reliable and worth re-running rather than to lock people into a subscription.

The short version