The Model Call Timed Out. What Do You Charge?
A Scopebase review calls the model. Then it times out before returning usage data.
Did the provider process the request? Did it charge for the work? The timeout doesn't say. If Scopebase records zero spend and retries, it may pay for two calls while accounting for one.
That is why I separate customer credits from provider spend. They sound like two versions of the same number. They're not.
Two ledgers, two questions
The customer ledger answers: how much review allowance did this account use? The internal spend ledger answers: how much model work might Scopebase have paid for?
Those numbers need different rules. A customer should not be charged twice because one retained revision needed a retry. But every model invocation still needs its own spend reservation, including retries.
Before the model call, Scopebase prepares the bounded source and computes a quote. A short admission transaction checks ownership, eligibility, entitlement, customer credits, and internal spending capacity. On first admission, it creates the customer credit receipt, updates allowance counters, reserves model spend, and creates the owned attempt together.
If the transaction can't establish those facts, the worker should not call the model and sort out the money later.
Retries shouldn't charge twice, but they aren't free
For one retained revision, Scopebase creates one customer credit receipt. A retry reuses that receipt and billing period. It does not consume the customer's allowance again.
The provider side is per invocation. Each attempt needs a separate reservation. The recorded policy allows at most two engine invocations per retained revision, each with a USD 1 guard. Those are internal limits, not measured costs or current provider prices.
The model SDK's automatic retries are disabled. Otherwise one attempt in Scopebase's records could silently trigger multiple provider requests behind the scenes. If Scopebase retries, that retry should be visible to the admission and accounting system.
The retry touches each ledger differently:
Unknown usage stays unknown
When a response contains valid usage, Scopebase can settle the reservation against it. When the call times out or returns no valid usage, the system doesn't know that the provider spent zero.
So unknown usage keeps its full reservation. Accounting distinguishes known spend, pending reservations, and settled unknown reservations. That can leave less internal budget available, even if the request never reached the provider.
I prefer that conservative result to making up a zero. If there is later an authoritative usage record, the system can reconcile from that. Until then, freeing the reservation would turn an unknown outcome into a false fact.
Deleting a review doesn't undo the bill
There's another accounting edge case hiding in deletion. Suppose Scopebase erased a private review and rebuilt allowance only from the runs that remained. The deleted run would disappear from the calculation, making its consumed allowance look unused.
Period counters therefore survive deletion of private review records. Erasure removes private review data, but it does not reverse a model call that already happened or grant the customer fresh quota.
This is one reason I don't want the billing ledger to be an accidental byproduct of review history. Private result retention and financial control have different lifetimes.
What a retry actually means
A model timeout leaves two decisions, not one:
- Reuse the customer's existing receipt for this retained revision.
- Reserve spend for a new provider invocation and check that another attempt is allowed.
That keeps customer charging idempotent while provider spend remains bounded. If the second attempt also times out, it gets its own unknown-usage treatment. The customer receipt stays the same; the internal ledger reflects another uncertain call.
The bookkeeping is more involved than a single creditsUsed counter. But when the model call disappears into a timeout, I can still answer two useful questions separately: did we charge the customer twice, and did we account for the provider spend we may have incurred?
The first answer should be no. The second may be “we don't know yet,” and the ledger should be honest enough to say so.