What changed
On October 13, 2026, Together AI introduced a programmable post-training service through its Python SDK (2.41.0 or later) and CLI. Instead of submitting a fixed fine-tuning dataset and waiting for a managed job, developers can provision a model resource on remote GPUs, open sessions and drive individual sampling, forward/backward, optimizer and weight-synchronization steps from their own code. The service supports supervised fine-tuning (SFT), direct preference optimization (DPO) and group relative policy optimization (GRPO), including custom PyTorch losses and multi-turn tool-use environments. It supports multiple LoRA sessions against a shared base model and deployment of checkpoints or adapters to dedicated inference endpoints. This is a new training-control surface, not a newly released model.
Why it matters
For teams training coding agents or task-specific models, a fixed job API can prevent experiments that require step-by-step rewards, custom curricula or multi-turn environments. Together now supplies the expensive distributed trainer and sampling infrastructure while leaving control of the training algorithm to developer code. The trade-off is operational and economic: the resource bills by GPU-minute while READY even between sessions, so inefficient loops, idle resources or forgotten shutdowns can dominate the bill. Builders must choose between easier token-billed standard fine-tuning and more flexible, higher-risk resource-billed post-training.
Developer code controls each training step
The post-training SDK exposes model-resource and training-session objects. SFT and DPO loops call forward_backward and optim_step; GRPO can also sample candidate completions, score them and sync new weights to generation replicas. Developers can change data selection, learning rates, reward functions and loss calculations between steps. Together operates the sharded trainers and remote GPU samplers, so the orchestration script can run locally without owning a GPU cluster.
Resource billing is not token billing
Post-training bills per GPU-minute once a model resource reaches READY, whether or not a session is actively training. The billing page gives an illustrative B200 configuration with four trainer and four generator GPUs at $11 per GPU-hour, or $88/hour; a trainer-only configuration with four GPUs costs half that. Those are configuration-specific examples, not a universal post-training price. A resource left running without a session continues billing until stopped, with an idle auto-stop only after an hour without operations. Project credit balance must be at least $100 to create a resource, and balances that run out cause the resource to stop. Teams should call the estimate_cost API and explicitly stop resources.
Shared adapters reduce experiment duplication
Multiple LoRA sessions can train independent adapters on one frozen base-model resource, so parallel or sequential adapter experiments need not load the base model separately for each run. The service supports checkpoint downloads, continued training and dedicated-endpoint deployments; eligible models allow multiple adapters on one inference deployment. Together documents FP4 preparation for GLM-5.3 and Kimi-K3. The practical savings depend on GPU occupancy, number of sessions and whether the chosen model supports multi-LoRA serving.
Early model and hardware limits matter
The current public catalog lists Qwen3.6 35B A3B, Qwen3.8 27B, Kimi K3, GLM 5.3 and MiniMax M3, with model-specific LoRA/full-weight support and context limits. B200-SXM is currently the only supported GPU type; B300/GB300 are planned, not available. The service currently supports text models, not image fine-tuning. These boundaries prevent assuming the API can train arbitrary checkpoints or run cheaply on smaller GPUs.
What independent evidence does and does not show
The API documentation and examples establish the announced capabilities, pricing contract and implementation shape. Release trackers repeat the October 13 announcement, but there is not yet a credible independent benchmark of model-quality improvements, GPU utilisation or end-to-end costs. The new service should be judged by reproducible agent-training results and completed-training cost, not vendor claims of convenience alone.