Skip to main content
flash train --cost prints a pre-flight estimate before you submit a run:
Use it before any non-trivial run. The estimate is catalog-deterministic and runs locally: it validates the config, estimates the training loop, prints the quoted USD cost, and exits without submitting. SFT configs require positive max_examples; use the full row count for an uncapped run. The submit-time quote is the amount Flash checks against your prepaid org balance. Successful runs are billed at the quoted Flash cost. Cancelled runs are repriced to the training progress they reached.

​
How cost is calculated

flash train --cost reprices a run the same way the platform bills it:
Billable training time is the training loop only — derived optimizer steps times per-step time. Setup (container boot, dependency install, model load, and, for GRPO/OPD, inference-engine warmup) is reported as wall-clock time but is not billed. Per-step time reflects the work in a step: a GRPO step samples a group of completions, grades them with your reward, and updates the policy, so it scales with how many and how long those completions are (batch_size × group_size × max_completion_tokens); an SFT step is one forward/backward pass, priced on the training tokens counted from your environment; an OPD step samples the model’s completions and has the managed teacher grade them before updating. OPD is priced on GPU time like the others, and teacher tokens are not billed to you. The estimator prices the cheapest eligible GPU automatically. If you set [gpu] provider or exact_type, the estimate uses those same constraints, and they persist across submissions and retries. Serving is priced separately, per token: (prompt − cached) × input + completion × output + cached × cached, at the per-model rates in Supported models.

​
What affects training cost

You control the main levers in the config:
  • Base model. Smaller models are cheaper and faster for smoke tests.
  • Algorithm. SFT usually costs least. GRPO and OPD both sample and score the model’s own completions before each update, so they cost more per step. Every algorithm is billed on GPU time; OPD’s managed teacher is not billed to you.
  • Epochs and exact step horizons. More epochs increases cost when Flash derives the update count. For SFT, GRPO, and OPD, positive max_steps sets the exact optimizer-update horizon.
  • Required saves. save_at_steps adds the synchronous upload work for each required deployable adapter and full resume checkpoint to the estimate.
  • Sequence length. Larger max_context_tokens and max_completion_tokens increase work per example. Keep them large enough for your prompt and answer, but do not oversize them by default.
  • Batch size and dataset size. For SFT, cost scales with the number of examples trained over and the batch/epoch settings.
  • On-policy sample count. For GRPO and OPD, group_size controls how many completions are sampled per prompt. Larger groups cost more.
  • Reward latency. If your GRPO reward calls an external model or service, slow grading can increase wall-clock time.
Setup and cold start time are shown for observability, but the training charge is based on the billable training loop.

​
Reading the preview

A preview includes the model, algorithm, setup estimate, training estimate, billable training time, and total:
Treat the preview as the quote for the config you submit. If you edit the environment, dataset, model, algorithm, or [train] settings, run --cost again. When max_steps is positive, the preview uses it as the exact update count for SFT, GRPO, or OPD. Otherwise the count is derived from epochs, retained examples, batch size, and the recipe.

​
Charges and cancellations

  • A run that completes successfully is billed at the submitted quote.
  • A run cancelled before training starts is not charged for training.
  • A run cancelled after training starts is repriced to the steps it reached.
  • Setup time is reported separately and is not billed as training time.
  • flash status <run-id> shows the current or final cost record.

​
Serving billing

Serving is billed per token after deployment. Prompt, completion, and cached prompt token rates are listed in Supported models. Serving a base model with no adapter (a base-model id in the model field) is billed the same way, to the org whose API key made the request — not to an adapter owner. Prefix caching is automatic; the cached prompt-token rate applies to a reused prefix. See Billing for how it works. Tear down deployments you are done using:

​
Lowering cost

  • Start with a smaller base model while validating the environment and reward.
  • Run short smoke tests before scaling epochs, positive max_steps, or the retained dataset size.
  • For SFT, keep a held-out split and avoid extra epochs once held-out quality stops improving.
  • For GRPO and OPD, lower group_size and max_completion_tokens until the reward/data or teacher-distillation wiring is proven.
  • For thinking runs, raise max_completion_tokens only enough for reasoning plus the final answer.
  • Use flash checkpoints <run-id> and deploy a good intermediate checkpoint instead of assuming the final step is always best.

​
Why a later quote can change

The quote can change when you edit the config, publish different environment contents, change the dataset size, or submit after catalog/pricing updates. The authoritative number is the quote returned for the run you submit.

​
Next steps

Supported models

Training and serving prices per model.

Deploy & chat

How per-token serving is billed.