Why variable pricing at all
Most AI actions have a stable price: a document analysis costs X credits, an initial assessment Y. For some actions, though — above all contract revisions with many requested changes — the effort involved varies enormously. We could ignore that and charge a very high flat price. For 80% of users, that would be a bad deal.
How the preflight works
Before every potentially variable action, a quote request runs in the background:
- You click "Generate revision".
- The server calculates the price using the rules in the
action_cost_rulestable — e.g. "base price 2 credits + 0.2 per change item, rounded". - We show you the exact price and your current balance.
- Only your click on "Confirm" starts the charge.
What you will never see
- Surprise deductions. Nothing is charged without your having seen and confirmed the amount beforehand.
- Silent price increases. Price changes update
action_cost_rules— the preflight reads live and always shows the current figure. - Money lost to errors. If generation fails on the server side (e.g. a rendering error in the PDF), the amount is refunded automatically — the same mechanism as with classic contract charges.
Where you can already see this today
- Contract revisions — the price depends on the number and type of requested changes.
- Coming soon: the plausibility check — the price depends on the complexity of the wizard.
For all other fixed-price actions, the familiar flat rate still applies.
For the sceptics: why not a "flat rate"
A flat rate would mean that we subsidise heavy users while light users overpay. That is exactly the opposite of the model we want. We want a simple rent-reduction hearing to be genuinely cheap and a complex data-processing-agreement (DPA) revision under the GDPR to cost what it actually costs — with no cross-subsidisation.
