You Canceled Training. Tokens Still Bill.

1. A cancel and a failure are not the same zero

The training and deployment billing page splits a stopped job into two sentences. Do not collapse them into “unfinished means free.” After you cancel, tokens already used are still pushed for billing. The training fee is estimated from those tokens, and the bill is final. An interruption for any other reason is not charged as training. Cancel stops the rest of the run. It does not erase the part that already ran. A platform interruption, or a job that fails because the data set is too small, follows the second sentence.

The status API keeps the two paths apart. The training API lists queued, running, succeeded, failed, canceling, and canceled. usage is the token count for that fine-tune, and the field is documented as returned when status is SUCCEEDED or CANCELED. Failure is not in that condition. If the integer is absent, do not invent a charge by replaying the estimate you typed at create time. On a cancel, usage is the slice already consumed. The bill follows that slice, not the full epoch count you originally requested.

The console uses “failed” for a second, different thing. Its tuning guide says a falling training loss with a rising validation loss means overfitting: training may have failed in the quality sense, and you should tune and train again. That note does not say the tokens already used are refunded. The status failure is the other case. SFT drops any row longer than max_length. Set that cap too high and too many rows are discarded, so the job fails for insufficient data. That failure is an interruption, so the billing page does not charge training, and you also do not get a model. The log reason decides which path you are on. An ugly curve does not zero the bill.

2. The estimate already multiplied epochs

For Qwen text models the formula is (dataset tokens + mixed-training tokens) times epochs times the training unit price, with a minimum unit of one token. The console estimate can be expanded to show the token total, the epoch count, and the unit price. Mixed-training tokens are the term people drop. Counting only the main file, then multiplying by epochs, undershoots both the estimate and the bill.

batch_size is not in that expression. The Qwen image section says it outright: batch_size does not enter billing and does not change the token total. The video section defines steps = n_epochs × ceil(dataset size / batch_size), and the billed quantity still uses n_epochs, not steps. Raising the batch size shortens the step count for a fixed epoch count. It does not discount the tokens, and it does not inflate them. The reverse mistake is to treat steps as the billed unit and then multiply by epochs again, so the same pass is counted twice. The text estimate has already multiplied epochs. usage on the status API is the consumed total, and the bill follows it. Do not multiply usage by epochs a second time.

The tuning overview also splits how you pay. The console offers token billing, prepaid training units, and postpaid training units. A job created through the API supports token billing only. A leftover training-unit balance does not explain a token line on an API job. Training units and inference prepaid packs are different ledgers. Whether an unused API pack can be refunded or moved to another account is a separate question, and that answer does not erase usage on a cancel.

3. Image and video jobs do not use the text formula

The same billing page defines four totals: text, Wan image, Qwen image, and video. Unit-price tables do not transfer across them. Wan image is max_steps × L_step, and L_step is approximately an L_max from a table. Text-to-image at 1k and image-to-image at 2k are not the same cell. Estimating an image job with “dataset tokens times epochs” lands on the wrong order of magnitude.

Qwen image is n_epochs × image count × (max_pixels / compression) × a GPU coefficient. The page fixes compression at 1024. The GPU coefficient moves with scheduling. The 8 used in the worked example is there to show the arithmetic. Actual tokens are usage from the status API, and the fee is the bill. Treating the demo table as a quote goes stale as soon as the job is scheduled.

Video total is the sum of billed durations, times max_pixels / 1024, times epochs. Each clip’s billed duration is the length in seconds, rounded, then capped. wan2.7 and wan2.5 cap at 10 seconds. wan2.2 caps at 5. A 30-second clip does not enter the formula as 30 seconds. Rounding happens before the cap: 10.4 seconds becomes 10, then the cap takes the minimum. Epochs equal steps only when the data set has one row and batch_size is 1. That identity does not rewrite n_epochs in the video formula.

4. Success still waits on the deploy clock

The billing page says the same thing for text, image, and video: the new model has to be deployed before you can evaluate or call it. Deployment fees start when status becomes running. Deploying, arrears, and a failed deploy do not bill. A monthly prepaid term also starts to be consumed only after the model is running. If the train is SUCCEEDED and the call returns not found, look at deployment status before you search the training product for that call.

What the deploy charges is three paths, not one sentence. The console FAQ says a tuned model, once deployed, bills the deployment and not the calls, and evaluation is free. The billing page says token billing for calls exists only after efficient SFT on a listed base model, with the deploy plan set to lora. Wan image SFT-LoRA says deployment is free and calls bill at the base model’s standard price. All three sentences are in the docs. Each one matches a different deploy. Idle hours on a model unit are the other clock, covered in the dedicated-deployment article. The handoff here is narrower: training stops when the job ends or is interrupted, deployment starts only at running, and the two amounts do not share a product name.

The bill query guide keeps training off the inference clock. Inference usually posts in 2 to 10 minutes. Training posts hourly, and a peak can post later. A posted line is not the same as a debit. Pay-as-you-go is a hold plus a monthly settlement. The fee overview says it shows inference charges only. Training and the knowledge base are in bill details. A training instance id is separated by !, commonly workspace, region, then the training task id. Inference bills use a semicolon. The product name is Model Studio large-model training. If the task id is ambiguous, match the bill month to the submit time on the tuning page. Do not read the inference channel field onto this line. When no training job is running, no new training fee is produced. That sentence stops the next charge. It does not reverse usage already pushed on a cancel.

5. A top-up does not move the cancel line

Reconcile in five columns. Status first: a cancel is read from usage, a failure is read from the log reason, and the loss curve does not set the amount by itself. Formula family second: text, Wan image, Qwen image, and video do not multiply into each other. Third, check that usage was not multiplied by epochs again, and that batch_size was not treated as a discount. Fourth, check whether deployment is already running, and whether this deploy is a model unit, lora token billing, or per-image calls on an image LoRA. Fifth, product name and separator: training is the exclamation mark and the training product, not the inference total on the fee overview.

Topping up the Model Studio balance happens before the debit. Swapping a stablecoin into an asset you can deposit does not refund tokens already used on a cancel, does not start a training charge on a failed job, and does not start the hourly deploy clock while status is still deploying. When you need that swap, AllSwap does it without an account and without custody. A completed swap only means the asset changed hands. usage on the canceled job still posts to the training product.