Represent the job’s operational status as canceled, but preserve any metered usage and chargeable amount separately. If the system requires one financial label, use a clearly defined local state such as canceled with incurred charges or partially billable rather than treating plain canceled as proof that nothing is due. The exact label and financial treatment depend on the provider’s billing taxonomy, metering rules, failure policy, and contract terms.
The Short Answer: Record the Job as Canceled Without Erasing Incurred Charges
Cancellation and billability are separate dimensions. A job can be canceled successfully even though resource allocation, execution, or output generation occurred before the stop took effect.
A practical state model therefore records two different conclusions:
- Operational conclusion: The job was canceled and will perform no further work.
- Financial conclusion: Usage recorded before the effective stop is evaluated under the applicable pricing and adjustment rules.
This distinction does not mean every canceled job should be charged. Cancellation before execution may produce no measurable usage, while cancellation during execution may leave a nonzero meter. Provider-caused failures, minimum-charge provisions, credits, and rounding rules can also affect the final amount.
Avoid using refunded as the immediate state unless a charge was actually reversed. Likewise, avoid using settled until the related financial transaction has reached that stage. State names should report what happened, not anticipate a later billing action.
Why Job Status and Billing Status Must Remain Separate
A job lifecycle answers questions such as whether the job is queued, running, completed, failed, or canceled. A financial lifecycle answers different questions: how much usage was measured, what amount was calculated, whether it was invoiced or settled, and whether a credit or refund was later issued.
Combining these lifecycles into one field creates ambiguity. For example, canceled cannot tell an operations team whether execution stopped before it started. It also cannot tell finance whether usage was recorded or whether an adjustment is pending.
A clearer conceptual sequence is:
cancellation requested → execution stopped → usage finalized → bill calculated → invoice handled → credit or refund handled, if applicable
Each step can succeed at a different time. A user might request cancellation while a worker is already processing the job. The system may acknowledge the request immediately, stop execution several seconds later, and finalize usage only after receiving the last meter event. The bill should be based on the documented meter and pricing method—not merely on the time the cancellation button was pressed.
Separating the states also helps teams investigate disputes without changing historical facts. A later credit can be recorded as an adjustment while retaining the original cancellation event, final usage measurement, and initial bill calculation.
The Events and Fields an Implementable State Model Should Preserve
An implementation should preserve enough information to reconstruct both the operational sequence and the financial treatment. The following names are illustrative rather than universal API fields:
| Illustrative field | Purpose | Example value |
|---|---|---|
operational_status | Final job outcome | canceled |
cancellation_requested_at | When the request was accepted | Timestamp |
execution_stopped_at | When resource-consuming work actually stopped | Timestamp |
metered_usage | Final measured consumption through the stop boundary | Structured usage record |
billable_amount | Amount calculated under documented pricing rules | Currency amount |
invoice_status | Whether the amount is pending, invoiced, or settled | Locally defined state |
credit_or_refund_status | Tracks later financial adjustments | none, pending, or local equivalent |
This model avoids forcing one overloaded status to represent execution, metering, invoicing, and adjustments simultaneously.
Cancellation request time and effective stop time
Record both timestamps when cancellation is asynchronous. The request time proves when the user asked the system to stop; the effective stop time identifies the operational boundary after which no additional work should be attributed to that execution.
If the job stops immediately, the timestamps may be close or identical. If a worker must finish an atomic operation or acknowledge the cancellation signal, they may differ. The system should document which event controls meter finalization.
Cancellation handling should also be idempotent. Repeating the same request should not stop the job twice, create duplicate usage entries, or trigger duplicate credits. The original request and resulting state transition should remain available in the event history.
Metered usage and calculated billable amount
Provider cost and customer-billable amount are not necessarily the same value. The usage meter records what happened; the pricing logic determines how that usage is treated commercially.
Keep the raw or normalized usage record distinct from the calculated amount. That allows pricing, minimums, free allowances, credits, or rounding to be applied without rewriting the underlying execution history. Meter finalization should also have a defined boundary so that delayed events cannot silently alter a previously issued amount without an explicit adjustment.
Invoice, settlement, refund, and credit status
An incurred amount may still be pending calculation, awaiting invoicing, settled, credited, or refunded. These are later financial stages, not job outcomes.
A credit and a refund should also remain distinguishable where the commercial system treats them differently. The important design principle is to append or link adjustments to the original record rather than replacing canceled with a financial label that obscures what happened operationally.
When Provider Cost Becomes Measurable
The measurable-cost checkpoint depends on the workload and the provider’s documented rules. Possible checkpoints include resource reservation, worker or GPU allocation, execution start, generated tokens, completed processing units, or another defined meter event. None is universally correct.
For cost-bearing LLM inference, work may occur between request acceptance and effective termination. Routing, batching, GPU scheduling, cache handling, and generation can all influence resource consumption, but the existence of resource activity does not automatically determine what is billable. The billing rule must identify the accepted meter and how canceled or failed work is treated.
A scenario-based decision model can make those rules easier to apply:
| Scenario | Operational treatment | Financial question to resolve |
|---|---|---|
| Cancellation before execution | Mark the job canceled | Was any chargeable reservation or minimum triggered? |
| Cancellation during execution | Mark the job canceled after work stops | What usage was finalized before the effective stop? |
| Provider-caused failure | Record failure separately from user cancellation | Does the documented failure policy produce a charge, waiver, or credit? |
| Duplicate cancellation request | Return the existing outcome without repeating actions | Can the same request create duplicate adjustments? It should not. |
| Minimum-charge rule applies | Preserve actual metered usage | How is the minimum disclosed and calculated? |
| Credit issued after invoicing | Retain the original job and invoice history | Is the adjustment represented as a linked credit or refund? |
| Meter requires rounding | Preserve unrounded usage where practical | At which stage and by which documented rule is rounding applied? |
For each scenario, the amount due—if any—should follow documented pricing and commercial terms rather than a universal assumption about canceled jobs.
For usage-based AI infrastructure, use the following checklist:
- Separate execution status from metering and settlement status.
- Distinguish cancellation request time from effective termination.
- Explain exactly when usage becomes measurable and when the meter is final.
- Handle repeated cancellation requests without duplicate work or adjustments.
- Preserve the original usage record alongside invoices, credits, and refunds.
- Document failure treatment, minimum charges, free allowances, and rounding.
- Reconcile job identifiers across operational telemetry and financial records.
At Token Forge Cloud, we focus on LLM inference cost control at the serving layer. Token Forge Cloud Private LLM Inference supports private deployment and serving-layer optimization across areas such as caching, routing, batching, quantization, and GPU scheduling. Token Forge Cloud Managed Model APIs provide an API-first path to model access and usage data for teams validating demand before considering private deployment. When assessing either managed or private inference economics, teams should define cancellation, metering, and settlement boundaries as part of their broader workload and cost-control design.
Next Step
Contact Token Forge Cloud to discuss API access, private deployment, and LLM inference cost control.