Skip to main content
Post-training bills for the GPUs you reserve for training, not for the tokens you process. You pay per GPU-minute from the moment a model resource becomes ready until it stops, even when there’s no session currently training on it. This page explains how billing works, how to estimate costs, and what happens when a resource fails or your credit runs out. Fine-tuning jobs bill per token processed instead. The overview compares the two.

​
How billing works

A model resource bills by the minute while its status is READY, from the moment it enters READY until the moment it leaves. You aren’t billed while it waits for capacity, starts up, or shuts down. The rate is the per-GPU-hour price of the resource’s GPU type multiplied by the number of GPUs the resource holds. GPU count depends on the base model, the GPU type, the training mode, and the number of generator replicas. A trainer-only resource (num_generator_replicas=0) costs less per minute than the same model with a generator, and a low-rank adapter (LoRA) resource can need fewer trainer GPUs than a full-weight one. Sessions are free, whether they’re training or idle. The number of sessions on a resource doesn’t change its rate, so several adapters on one resource cost the same per minute as one. A resource with no sessions still bills until it stops.
A resource keeps billing after your training script exits unless the script stops it. Cookbook recipes stop the resources they create when they exit. If you provision a resource yourself, use ModelResourcesClient as a context manager, with the session’s context manager nested inside it so the session stops first, or stop the resource when you’re done. Otherwise, an idle resource stops on its own only after an hour without an operation.

​
Per-GPU pricing

For up-to-date per-GPU pricing, visit the Together AI pricing page.

​
Estimate the cost of a resource

Call estimate_cost with the configuration you plan to provision. It returns the on-demand hourly price without creating anything:
You should see output like:
On B200-SXM, this configuration uses four trainer GPUs and four GPUs for one generator replica. At $11 per GPU-hour, the total is $88 per hour. The same resource with num_generator_replicas=0 uses four GPUs and costs half as much. Use the estimate returned by the API for the current rate. The Together AI console shows the same hourly price as Rate on each model resource’s detail page under Post-training.

​
Estimate the cost of a training run

The hourly price tells you what the resource costs per hour, not what a full run costs. To estimate a run:
  1. Work out the total number of optimizer steps. For a cookbook GRPO recipe, that’s num_steps if you set it. Otherwise, it’s the number of training examples divided by batch_size, times num_epochs, except that multi-turn GRPO recipes run one pass. For SFT, it’s the same epoch count, capped at max_steps if you set it. For DPO, it’s max_steps.
  2. Launch a short test run with the same model, GPU type, generator count, batch size, group size, and sequence lengths as the planned run.
  3. Measure later, steady-state steps and use their timing for the cost estimate. Ignore the first step’s duration because it includes one-time warm-up procedures that can take additional time. For GRPO recipes, read timing/step_total_s from the run’s metrics.jsonl. For SFT and DPO, take the difference between adjacent elapsed_s values.
  4. Multiply the steady-state step time by the step count, convert to hours, and multiply by the hourly price. Add session startup, the first step’s warm-up, validation passes, checkpoint passes, and any time the resource sits idle before you stop it. Don’t add the time before the resource is READY, which isn’t billed.
When several sessions share one resource, estimate the resource’s cost once from its total lifetime and divide it among the runs. Don’t apply the full hourly price to each session.

​
Refunds on failure

If a READY resource fails (READY → ERROR), Together AI refunds a trailing window of its runtime: the last 3 hours for a LoRA resource or the last 6 hours for a full-weight resource. The refund is capped at the time the resource was actually ready. On long runs, set the cookbook’s training_checkpoint_interval (in steps) so you save a training checkpoint at least once per refund window. The refund then covers everything since your last checkpoint. A resource that fails before reaching READY (with CAPACITY_WAIT_TIMEOUT or PROVISIONING_FAILED) was never billed, so there’s nothing to refund.

​
Minimum credit balance

Creating a model resource requires a credit balance of at least $100 on your project. If your account has a credit limit, the limit counts toward the $100. If your balance is below the minimum, the create request fails with a 400 error, project balance below minimum required to create model resources, before anything is provisioned. Add credits under Billing in the console and retry. If your balance runs out during a run, the resource stops automatically within about a minute, and its sessions end with it. Save training checkpoints on long runs so an unexpected stop costs you one checkpoint interval instead of the whole run.