Four numbers worth knowing before you hand over a card:
- Your monthly allowance resets to zero unused balance every cycle.
- Credit packs carry no expiration date at all.
- Refunds on an untouched pack are good for 14 days.
- A failed generation still burns exactly one credit's worth of work, whether you like the output or not.
Three of those are pricing-page material. The interesting one is buried in how spending actually gets ordered, and it's worth walking through because it's the difference between credits meaning something and credits being a marketing number.
Why allowance goes first
When you have both a monthly allowance and a purchased pack sitting in your account, the allowance gets spent down before the pack is touched. Nobody puts that in the headline pricing copy, but it's the mechanism that makes packs actually worth what you paid for them.
Run the alternative: if packs got drawn down first, your allowance would just sit there, unused, until the billing cycle rolled over and wiped it. A pack you bought in March to cover a busy week would be quietly subsidizing your subscription instead of adding to it — you'd be paying twice for the same unit of work, once through the plan and once through the pack, while the thing you already paid for evaporates in the background. Allowance-first flips that: the free plan money gets used first, the money you specifically handed over for extra capacity survives everything the reset would otherwise take. A pack bought in March is worth exactly the same in November as it was the day you bought it.
That asymmetry is also why the two credit types expire differently in the first place. The allowance is included usage tied to the cycle you're paying for — if it rolled over indefinitely we'd effectively be selling three months of credits for one every quarter someone doesn't log in, and the pricing page would need a lot more fine print to explain that. So it resets, plainly, instead of getting buried in a FAQ. Packs are money spent specifically to buy usage, not a subscription perk, so they behave like a balance instead of a benefit — no expiry clock counting down in the background.
I've used tools where the paid top-up quietly died alongside the subscription cycle, technically disclosed somewhere in the terms, and it always read like a trap.
Spend order is the small mechanical choice that keeps this product from becoming that.
What actually spends a credit
Anything where a model does real labor on your behalf:
- A first build
- A rebuild after changes
- A research pass reading competitor pages
- A marketing draft
- An optimization pass rewriting metadata
These aren't priced identically and shouldn't be — a full build might touch a dozen files over several minutes of model time, a headline tweak is a few seconds of focused editing. Rates by action type live on the pricing page and do move as we retune the underlying models; we'd rather adjust the number in the open than quietly throttle quality to protect a stale price.
What doesn't spend anything:
- A published site staying live — costs nothing per day
- Reading dashboards
- Checking rankings
- Browsing a past run's history
- Asking the assistant a plain question
All free, right up until the answer requires it to actually do something rather than tell you something. The rule is consistent everywhere: did a model generate or transform something, or did you just read what already existed.
And a generation you didn't like still cost you the credit, because the work happened — tokens spent, compute used, model ran to completion. That's a different case from a run that errors out on our end before producing anything, which is on us and covered below. Free retries until you're satisfied sounds generous until you notice everyone's third attempt is quietly subsidized by everyone who nailed it on the first.
Where it breaks, and what we do about it
Run out mid-build and the run pauses right there in the log, not three steps later with a half-finished page — no silent failure, no eaten balance, no guessing whether it's stuck. Top up or wait for reset, then resume where it stopped. I watched this happen live during a client demo: allowance ran dry exactly when they asked for "one more pass," the pause message said what was needed, we bought a small pack on the spot, and the run picked back up in under a minute.
| Failure type | Refunded? |
|---|---|
| Platform-side failure (our infrastructure broke) | Yes — re-credited on request, no ticket-wrestling required |
| App store rejection or a revoked API key | No — but we'll still help fix the underlying thing |
A credit refund doesn't repair a broken Search Console connection, so we treat those cases differently on purpose.
Refunds cover untouched packs and unused new cycles within that 14-day window, full stop. Consumed work doesn't come back — if the agent built the site and you changed your mind, that compute already happened, the same way a contractor doesn't refund billed hours for a draft you decided against. The full Refund Policy is short because we tried not to need the exceptions that make refund policies long.
