How Should a Long-Running Job Release Unused Reserved Balance After a Partial Cancellation?

After a partial cancellation, settle completed or contractually non-refundable work, preserve any reservation required by the surviving portion of the job, and release only the unused remainder. The release must be an atomic, idempotent ledger operation: it cannot exceed the reservation’s remaining amount, and the available balance should increase by exactly the amount released.

Ledger conventions, minimum charges, refund policies, and cancellation terms vary by system and contract. The procedure below is a general implementation pattern for long-running agent, multimodal, batch, and asynchronous workloads—not a universal accounting rule.

Short Answer: Settle Completed Work, Then Release Only the Unused Remainder

A partial cancellation changes the expected cost of a job without necessarily ending the entire job. That makes it different from a full cancellation: some work may already be billable, some usage may still be arriving, and the surviving workload may need to retain part of the original reservation.

The safest approach is to calculate the release from one authoritative reservation record rather than treating cancellation as a request to refund a percentage of the original amount.

Define posted, reserved, settled, released, and available balances

Use consistent definitions throughout the ledger, billing service, and job-control system:

• Posted balance: Finalized charges or credits recorded against the account. Depending on the ledger design, settled usage may become a posted charge immediately or through a separate posting step.
• Reserved balance: Funds held for expected future usage. A reservation reduces what the account can spend elsewhere but is not itself a finalized charge.
• Consumed or settled amount: Usage that has been accepted as billable against the reservation. Settlement may happen incrementally while the job runs.
• Released amount: The portion of a reservation returned to the available balance because it is no longer needed.
• Available balance: The amount the account can use for new work after applying posted entries and active reservations according to the ledger’s sign conventions.

These amounts should not be conflated. In particular, reserving funds is not the same as charging for usage, and releasing a hold is not necessarily the same as issuing a refund for a previously posted charge.

Store monetary values in integer minor units, such as cents, or another suitable fixed-precision representation. Floating-point arithmetic can introduce rounding differences that eventually break balance invariants.

Calculate the releasable amount without confusing holds and charges

A useful general calculation is:

releasable amount = original reservation − cumulative settled usage − prior releases − retained or non-refundable amount

Here, the retained amount can include funds required by the surviving workload and any applicable minimum or non-refundable charge that has not already been counted as settled. Do not deduct the same obligation twice. If a non-refundable amount has already been posted or included in cumulative settlement, it should not also remain in the retained field.

At cancellation time, determine four things:

1. What completed work has already been settled?
2. What completed usage has not yet been reported or finalized?
3. How much reservation does the continuing part of the job still require?
4. Do the applicable terms impose a minimum or non-refundable amount?

If late usage can arrive, move the reservation into a bounded finalization state rather than releasing the entire apparent remainder immediately. Once the final usage cutoff has passed and accepted usage has been settled, release the amount that is genuinely unused.

Enforce the conservation and non-negative balance invariants

Every write should preserve these core rules:

• A release cannot exceed the reservation’s current remaining amount.
• The reservation’s remaining amount cannot become negative.
• Available balance increases by exactly the amount successfully released—not the amount requested before validation.
• Cumulative settled usage, cumulative releases, and retained obligations cannot exceed the original reservation unless the system has an explicit overage mechanism.
• Replaying the same settlement, cancellation, or release command cannot change the ledger twice.

A practical conservation equation is:

original reservation = settled amount + released amount + retained amount + unresolved remainder

Once the reservation is terminally closed, the unresolved remainder should be zero. If the surviving job later consumes the retained amount, that value moves into settlement; if it finishes below the retained amount, the final unused portion can be released under the same controls.

Move the Reservation Through an Explicit Partial-Cancellation Lifecycle

A state-based workflow makes ownership and permitted operations clearer than a collection of loosely coordinated cancellation events. Exact state names will vary, but a useful sequence is active, cancellation requested, finalizing, partially released, and closed.

Create the reservation and record incremental consumption

Maintain an authoritative reservation record with fields such as:

• Reservation and account identifiers
• Original reserved amount
• Cumulative settled amount
• Cumulative released amount
• Retained or non-refundable amount
• Computed remaining amount
• Job and cancellation status
• Version number or equivalent concurrency token
• Creation, update, finalization, and closure timestamps

Usage should settle incrementally against this record using a unique usage-event or settlement identifier. If the same event is delivered twice, the second attempt should return the original outcome without applying another charge.

The remaining amount is best derived from authoritative components or updated atomically with them. Allowing separate services to maintain independent estimates of the reservation creates opportunities for drift.

Cancel the affected portion while preserving the surviving workload

A partial-cancellation request should identify the affected job segment, modality, task, or unit of work. The system can then stop new work for that segment while allowing the surviving portion to continue under an explicitly retained reservation.

A typical flow is:

1. Accept the cancellation idempotently. Assign or require a stable cancellation key so retries refer to the same operation.
2. Stop new work for the cancelled portion. Record the cutoff point used to decide which usage remains billable.
3. Enter finalization. Allow already completed but delayed usage reports to arrive during a short, defined reconciliation window where appropriate.
4. Settle accepted usage. Apply each usage record once and update cumulative settlement atomically.
5. Calculate the surviving reservation. Retain only the amount required for the portion that continues, plus any separately applicable obligation.
6. Release the unused remainder. Update cumulative released and available balances in the same transaction or equivalent atomic operation.
7. Close or continue. Close the reservation if no workload remains; otherwise mark it partially released and keep the surviving portion active.

A full cancellation follows similar safeguards but has no continuing workload reservation. It still should not release funds needed for completed, delayed, minimum-charge, or otherwise non-refundable work.

Serialize settlement, cancellation, and release updates

Usage reporting and cancellation can race. For example, a cancellation handler may calculate a release at the same moment that a worker reports completed usage. Without serialization, both operations can consume the same remaining reservation.

Suitable controls include an atomic database transaction, compare-and-swap using the reservation version, row-level locking, or another mechanism that provides equivalent serialization. A release transaction can follow this pattern:

1. Load the authoritative reservation and current version.
2. Confirm that the cancellation or release key has not already been applied.
3. Recompute the releasable amount from current settled, released, and retained values.
4. Reject or reduce any requested release above that amount.
5. Atomically update the reservation and available balance.
6. Record the operation key, resulting version, amount, reason, and timestamps.

If the version changed before commit, retry from the latest state rather than reusing the stale calculation.

Recover safely from retries and partial failures

Ledger correctness cannot depend solely on asynchronous event delivery. The balance update must be durable and atomic; events can then notify billing, job orchestration, reporting, and customer-facing systems.

A transactional outbox is one implementation option. The ledger transaction writes both the balance change and an outbox record. A separate publisher delivers the event with retry-safe handling. This prevents a committed release from being lost merely because event publication failed.

Reconciliation should regularly detect:

• Reservations left in finalizing beyond their expected window
• Closed jobs with unresolved reserved amounts
• Release events without corresponding ledger entries, or vice versa
• Duplicate operation keys with inconsistent payloads
• Settlement totals that conflict with accepted usage records

Corrections should use traceable adjustment entries rather than silently overwriting financial history. Record the initiating identity or service, reason, prior and resulting values, related job IDs, and idempotency keys.

Illustrative, product-agnostic calculation

Suppose a job reserves $100.00. At partial cancellation:

• Already settled usage: $36.00
• Completed but initially unreported usage: $9.00
• Reservation required by the surviving workload: $25.00
• Prior releases: $0.00
• Additional non-refundable amount: $0.00

After the finalization window, cumulative settled usage becomes $45.00. The releasable amount is:

$100.00 − $45.00 − $0.00 − $25.00 = $30.00

The system releases $30.00, increases available balance by $30.00, and retains $25.00 for the continuing work. If that work later settles for only $20.00, the remaining $5.00 can be released when the job closes.

In implementation, these values could be represented as 10000, 4500, 2500, and 3000 cents to avoid floating-point errors.

Acceptance checks for the workflow

Before using the design in production, test that:

• No transition can produce a negative remaining reservation.
• A release cannot exceed the current remaining hold.
• Duplicate cancellation, settlement, release, and cleanup requests are deterministic.
• Concurrent usage and cancellation cannot release or settle the same funds twice.
• Original funds are conserved across settled, released, retained, and unresolved amounts.
• Available balance changes only when the corresponding release commits.
• Delayed usage is handled according to a defined cutoff and finalization policy.
• Partial cancellation preserves the reservation assigned to surviving work.
• Every adjustment has a traceable reason and operation identifier.
• Timeout cleanup and reconciliation eventually close stranded reservations.

For AI workloads, these controls are especially relevant when agent runs, multimodal processing, batch enrichment, or asynchronous inference continue long enough for usage reporting and job state to become temporarily out of sync. Different workload types may also require different serving and reservation policies.

Token Forge Cloud treats latency-sensitive chat, batch enrichment, and agentic workflows as distinct serving-policy problems. Token Forge Cloud Private LLM Inference focuses on serving-layer optimization through caching, routing, batching, quantization, and GPU scheduling, while Token Forge Cloud Managed Model APIs provides API-first model access and usage data for teams validating demand before considering private deployment. The ledger lifecycle described in this guide is a general architecture pattern, not a description of a Token Forge Cloud wallet, reservation, cancellation, or balance-release feature.

Next Step

Align the reservation lifecycle with your job state model, usage-reporting delays, contractual billing terms, and chosen concurrency controls. Then validate it with duplicate delivery, stale version, delayed usage, partial failure, and timeout-recovery tests.

Contact Token Forge Cloud to discuss API access, private deployment, and LLM inference cost control.