Reserve Spend at the Planning Boundary
Reserve spend at the planning boundary
If a job's cost depends on a plan the system has to derive first, the right place to reserve budget is the moment that plan becomes concrete.
Not at request start, when the cost is still fuzzy. Not at execution time, when concurrent work can already have spent the same budget. In the middle.
The rule
Do a cheap admissibility check up front, then reserve the exact spend immediately after planning and immediately before execution.
That split matters:
- the early check answers "is this flow worth starting at all?"
- the later reservation answers "can this exact job still run now that we know what it really costs?"
Trying to make one step do both jobs usually goes wrong.
Why reserving too early is bad
If you reserve before the plan exists, you have to guess. Guesses create awkward failure modes:
- over-reserve and you block work that should have been allowed
- under-reserve and concurrent jobs can still oversubscribe the same budget
- reserve one flat fee and you quietly teach the product the wrong unit
The cost model becomes a fiction the code has to keep compensating for.
Why reserving too late is bad
If you wait until execution, every concurrent job can look at the same unspent balance and decide it is safe to proceed. By the time the expensive phase begins, the system has already promised the same money, quota, or inventory slot to multiple jobs.
That bug does not feel like a billing bug when users hit it. It feels like randomness.
Design shape
The healthy shape is usually:
- lightweight preflight
- derive the real plan
- reserve exact spend
- execute against the reservation
- settle, release, or partially refund
I like this because it keeps product semantics honest. The user pays for the thing the system actually decided to do, not for the vague intention that kicked the workflow off.
Easydeck example
In Easydeck, the cost of a presentation depends on the final slide count, which the system only knows after outline generation and parsing.
The current flow gets the boundary right:
- kickoff checks whether the user can afford at least one slide on the chosen model
- outline generation parses the real slide list
- exact credits are reserved from that parsed count
- slide creation later settles the reservation into a real spend
That is much better than charging "one credit to start a deck" or trying to reserve from a hand-wavy estimate.
Where this generalizes
- batch image generation
- shipping labels after packing logic determines box count
- AI agent runs that only know tool usage after planning
- imports whose cost depends on parsed row count
- deployment systems that reserve capacity after the rollout plan is calculated
Any workflow where planning discovers the real unit count has this shape.