Baseten Loops: Serverless SFT and RL Training, Billed Per Token (What the Docs Confirm)

Baseten Loops lets you train an open-weight model with supervised fine-tuning or reinforcement learning from a short Python script, and pay per token instead of per GPU hour. A secondhand report says Baseten planned to make Loops generally available on November 6, 2026. We could not find an official announcement, so this article is built from Baseten's own documentation: what the product does, which models it supports, and how it bills.

Sources: the Baseten docs on availability modes, concepts, supported models and the quickstart.

TL;DR

How does a Loops run work?

The concepts page describes a run as the training state for a base model and its LoRA adapter. Your Python process, local or remote, sends forward, backward and optimizer operations to the trainer, then publishes weights for a sampler to generate from.

The parts:

• Session: groups runs, samplers and checkpoints under a training project. Creating a ServiceClient creates a session.
• Trainer: owns the adapter and optimizer state, applies steps and saves checkpoints.
• Sampler: generates from a base model or published checkpoint. A paired sampler belongs to a run; a standalone sampler is independent.
• Checkpoints: paths of the form bt://loops:<run_id>/.... Use save_state() for recovery and save_weights_for_sampler() to publish weights for sampling and inference deployment.
• Weight sync: in serverless mode the sampling client is pinned to the published checkpoint; in dedicated mode it sets a minimum policy version and the sampler loads later weights without restarting.

For debugging, setting LOOPS_REQUEST_LOG makes the SDK append one JSON line per request and response so you can replay a failed run.

What does the quickstart show?

The quickstart trains a LoRA adapter on Qwen3.6-35B-A3B with RL on serverless Loops, samples from the published weights, saves resumable state and deploys the tuned model. The toy task is a one-answer question: "I am thinking of either Doom or Quake. Name it. Reply with the title only." A reply of Quake scores 1.0, anything else 0.0.

Each step samples 16 replies. A reply's advantage is its reward minus the mean of the 16, so correct replies become more likely. If all 16 score the same, advantages are zero and the step samples again. The script runs five steps at LoRA rank 8 and a learning rate of 2e-5, and prints mean reward per step.

The point of the toy task is mechanics: you write the reward function, build datums with target tokens, sampler logprobs and advantages, and Loops handles the GPUs. For a real job, the docs example is a support-ticket classifier where the reward is the correct category.

Which models can you train?

The supported models page says every model trains in dedicated mode and three also train serverless.

That is a partial list; the page shows 31 entries. One caveat from the page: GLM-5.3's long-context configuration does not support the cross_entropy or dpo losses. Your workspace may not have every model enabled. The docs show a capabilities endpoint (loops/capabilities?use_case=rl or sft) that returns the models and sequence lengths your workspace can use.

What should you watch for in the reward design?

RL jobs fail more often on the reward than on the infrastructure, and the quickstart hints at why. Its group-relative setup only learns when the 16 sampled replies differ in score. If all replies are right or all are wrong, every advantage is zero and the step samples again. The script even caps this: after 20 unusable groups in a row it stops with an error instead of burning tokens.

That cap matters for billing. On serverless you pay for sampled tokens, so a reward that is too hard (nothing scores) or too easy (everything scores) wastes money without teaching anything. Test your reward on a few samples from the base model first. Aim for a mix of passes and fails. If you see none, simplify the task or add partial credit.

Two further habits follow from the docs. Keep the maximum reply length small while you iterate, as the quickstart does with 16 tokens. And evaluate saved checkpoints with a standalone sampler, which serves a base model or saved checkpoint without an active trainer, so you do not keep a trainer running just to score results.

Serverless or dedicated: which should you pick?

A small shape reaching for a green token at the end of a path, showing reward-driven reinforcement learning in Baseten Loops

The docs say serverless fits experimentation: "time spent reading results or revising a reward function between steps costs nothing." Dedicated fits scaling out a run, especially asynchronous RL, models serverless does not support, and planned sustained runs.

By default a run uses serverless when it supports the model, LoRA rank and sequence length; otherwise it uses dedicated. If you want to avoid surprise GPU billing, set scope="serverless". The request then fails instead of falling back. The scope values are default, serverless and deployment.

What does serverless bill for?

Per the serverless page, runs bill for prefill, cached prefill, sample and train tokens at per-model rates listed under "Serverless Loops token pricing." Those rates are separate from Model API token rates for the same base model. We did not extract the rate table, so we give no prices here. Two details to know: baseten loops usage reports dedicated GPU allocations but not serverless token usage or spend, so track spend elsewhere, and saved checkpoints remain available to download, deploy or restart from.

What is the GA claim, and what is verified?

The Digg-style summary we saw says Loops had been in public preview and that Baseten said it planned to make it generally available on November 6. That is a plan reported by an aggregator. Before you build a project on it, check Baseten's changelog.

How does Loops compare with other training services?

Serverless training for open models is a crowded space now. See our coverage of Snowflake Cortex Training, Together's post-training platform and Tinker migration, and our basic explainer on what fine-tuning is. The differences we can state from docs alone:

• Baseten: per-token billing on three models, GPU billing on the rest; training SDK with explicit forward, backward and optimizer calls, so you control the loop.
• Others: see the linked posts for their pricing and limits; we do not compare numbers across vendors without a shared source.

For more on Baseten's other recent products, see its Grid router claim and Sandboxes.

Should you try it?

A green fitted collar around a cream core, a picture of a LoRA adapter on a base model for Baseten Loops

Try it if you already have a task with a measurable reward, such as classification, tool-call correctness or a unit-test pass rate, and want to run RL on an open model without renting a cluster. A sensible first run:

1. Pick a serverless model: Qwen3.6-35B-A3B if you need vision, GLM-5.3-Flash for a lighter text and vision option.
2. Set scope="serverless" so a config mismatch fails loudly.
3. Start with the quickstart's five-step loop to confirm rewards rise.
4. Replace the toy reward with your own and keep group size at 16 or more so advantages are not all zero.
5. Save state regularly with save_state() and deploy the checkpoint only after you have evaluated it.

Do not use it if you need a model outside the three serverless ones and cannot afford idle dedicated GPUs. Dedicated billing continues between operations until you deactivate the run or the 15-minute inactivity timeout ends it.

Bottom line

Loops gives a clean answer to a real problem: RL on open models is hard to run, and token billing makes experiments cheap to stop and restart. The docs back that up for three models. The GA date and the price table are the two things to confirm with Baseten before you plan around them.

Details come from Baseten docs read on November 6, 2026 and may change.

Related reading

• Snowflake Cortex Training: serverless SFT and RL
• Together post-training and Tinker migration
• What is fine-tuning? A complete guide
• Baseten Grid router claim
• Baseten Sandboxes for agents
• Nous Research Arete-27B, a Qwen3.8 fine-tune