Post-training

Post-training lets you write your own training loop and run it against Together AI GPUs. Your code builds each batch and chooses the loss function and learning rate, while the GPUs you provision run the forward and backward passes, optimizer steps, and sampling. It bills per GPU-minute.

Write a loop with the Python SDK (together.post_training, version 2.41.0 or later), or start from a recipe in the post-training cookbook.

What’s included:

• Three training methods: Supervised fine-tuning (SFT), direct preference optimization (DPO), and reinforcement learning with group relative policy optimization (GRPO). Each method trains a low-rank adapter (LoRA) or the full model weights.
• Custom loss functions: Train with any objective you compute in PyTorch from the model’s log-probabilities.
• Multi-turn environments: Train tool-use agents with GRPO over whole episodes.
• Several adapters on one base model: Attach several LoRA sessions to one model resource, so a hyperparameter sweep costs one base model’s GPU time.
• Multi-LoRA deployment: Attach trained adapters to one dedicated deployment of their base model, then name an adapter in each request to compare them.
• Prepare for FP4 inference: Merge a LoRA adapter into GLM-5.3 or Kimi-K3 and quantize the result to FP4 for dedicated model inference.
• Tinker compatibility: Run a Tinker training script on post-training by changing its import line and, if needed, its base model.
• CLI commands: Together CLI 2.41.0 adds tg training to list model resources, sessions, and checkpoints and to run FP4 preparation jobs. tg beta endpoints deploy adds --attach-adapter and --merge for deploying a trained adapter.

See Post-training for details.

New provisioned throughput models

The following models are now available on provisioned throughput:

• zai-org/GLM-5.3.
• zai-org/GLM-5.3-Flash.
• deepseek-ai/DeepSeek-V4.1-Flash.

Dynamic rate limits for serverless retired

Serverless no longer applies dynamic rate limits that scale with your recent traffic. Most users will no longer encounter rate limits, though requests can still be limited during periods of high demand. If you get a 429 Too Many Requests response, reduce your request rate and spread out bursts. If you get a 503 Service Unavailable response, wait briefly before retrying. Retry both with exponential backoff.

See Rate limits.

Together Link beta

Together Link runs six coding agents on models hosted by Together AI: Claude Code, Codex, OpenCode, and Pi Code in the terminal, plus Claude Desktop (including Cowork) and ChatGPT Desktop. Install it with one command, launch your agent through it, and your normal agent configuration stays untouched. It’s now in beta on macOS and Linux.

# Install Together Link
curl -fsSL https://link.together.ai/install | bash

# Open the interactive launcher
togetherlink

# Or launch an agent directly, pinned to one model
togetherlink --main moonshotai/Kimi-K3 claude

What’s included

• Six agents: Launch Claude Code (tclaude), Codex (tcodex), OpenCode (topencode), or Pi Code (tpi) in your terminal, or switch Claude Desktop and ChatGPT Desktop to a reversible Together Link profile. OpenCode requires OpenCode 2, and Pi Code requires version 0.80.8 or newer.
• Auto router: Sessions default to the auto model, which picks a Together AI model for each request. In Claude Code and Claude Desktop sessions with an Anthropic API key, it sends the most difficult requests to Claude Opus.
• Models: moonshotai/Kimi-K3, zai-org/GLM-5.3, zai-org/GLM-5.3-Flash, and deepseek-ai/DeepSeek-V4.1-Flash, all with 1M context, billed at standard serverless rates. Pin one with --main, or switch with your agent’s /model command.
• Cost tracking: A session receipt on exit, an estimated spend in Claude Code’s status line, and togetherlink usage for spend across sessions.
• Image generation: Claude Code, Claude Desktop, and ChatGPT Desktop sessions include a skill that generates and edits images with Together AI image models.
• Headless mode: Each agent’s own non-interactive flags pass through, so scripts can drive tclaude -p, tcodex exec, topencode run, and tpi -p.

See Together Link for details.

Code sandbox SDK and CLI

The new together-sandbox SDK runs commands and code in isolated runtime environments built from Docker-image snapshots. It ships as a Python SDK, a TypeScript SDK, and a standalone CLI, and is available to organizations on an allowlist (contact us to request access).

What’s changed from the legacy SDK (@codesandbox/sdk)

• Together-native authentication: Clients authenticate with your Together API key (TOGETHER_API_KEY) instead of a CodeSandbox API token.
• Python support: The legacy SDK was TypeScript-only. The new SDK is published on both PyPI and npm, and the CLI installs as a self-contained binary.
• Docker-defined environments: Sandboxes boot from snapshots built from a Docker image or Dockerfile by Together’s remote image builder, replacing templates built with the CodeSandbox CLI. No local Docker is required.
• Snapshot-based persistence: Sandboxes are ephemeral by default and termination is permanent. To maintain state, snapshot the filesystem on termination and start a new sandbox from it. This replaces the legacy hibernate and resume model.

See Code sandbox for the new workflow.

New dedicated endpoint models

The following models are now available for deployment on dedicated endpoints:

• hexgrad/Kokoro-82M (text-to-speech).
• Qwen/Qwen3-TTS-12Hz-1.7B-CustomVoice (text-to-speech).

Higher LoRA rank limit for fine-tuning

You can now train low-rank adapters (LoRA) with a rank of up to 128 for the majority of models, up from 64. The default rank for these models stays at 64, so set lora_r to use a higher one.

The model limits response has a new lora_training.default_rank field next to lora_training.max_rank. Run tg fine-tuning model-limits to see both values for a model.

Version 2.36.0 of the Together CLI and Python SDK uses the default rank when you don’t set lora_r. Earlier versions, including the 1.x SDK, use the model’s maximum rank instead, which is now 128 on these models. Upgrade to 2.36.0 or set lora_r yourself, especially if you continue training from a rank-64 adapter, where the rank has to match.

In the console, the rank field now starts at the model’s default rank (64 on most models) instead of 8.

See Supported models for each model’s default and maximum rank.

Longer fine-tuning context for Qwen 27B models

Qwen/Qwen3.8-27B, Qwen/Qwen3.6-27B, and Qwen/Qwen3.5-27B now support a 131,072-token context for SFT (up from 32,768) and 65,536 for DPO (up from 16,384), for both LoRA and full fine-tuning. Batch size limits have also changed: LoRA jobs on these models run at a batch size of 2, down from 16, and the maximum DPO batch size for full fine-tuning drops from 16 to 8.

See Supported models for each model’s limits.

Batch API files are now retained for 7 days

The input file you upload for a batch job, along with the output and error files the job produces, are now retained for 7 days. After that the files are no longer accessible, so download your results before the window closes. Reusing an uploaded input file across batch jobs also works only within that window.

See Batch inference.

Deprecations

Serverless model deprecations

The following models are no longer available on serverless:

• openai/gpt-oss-20b. Recommended replacement: Qwen/Qwen3.5-9B. Supported by on-demand dedicated endpoints.
• google/gemma-4-31B-it. Recommended replacement: zai-org/GLM-5.3-Flash. Supported by on-demand dedicated endpoints.
• thinkingmachines/Inkling-Small. Recommended replacement: zai-org/GLM-5.3-Flash. Supported by on-demand dedicated endpoints.
• intfloat/multilingual-e5-large-instruct. Not available as an on-demand dedicated endpoint.

See Deprecations for migration guidance.

New releases

Rollouts for dedicated model inference

Rollouts shift live traffic from one deployment to another under the same endpoint, without changing the endpoint URL. Pick a canary, blue-green, or rolling strategy to determine how traffic moves, and optionally gate a canary rollout on live metrics so it pauses automatically if the new deployment regresses.

Start a rollout with the tg beta endpoints rollout CLI command or from the endpoint’s Rollouts tab in the console, then pause, resume, promote, or cancel it at any point while it runs.

Together CLI v2.34.0

Version 2.34.0 of the Together CLI and Python SDK carries the rollouts release above (the SDK surface is client.beta.endpoints.rollouts) and also adds:

HIPAA placement:

tg beta endpoints deploy accepts --placement.hipaa to restrict a deployment to HIPAA-attested clusters. The Python SDK takes the same policy as compliance_policy on inline placement.

tg files check now rejects Parquet files larger than the maximum supported file size instead of passing them through format validation.

See the CLI reference.

Model deprecations

The following models have been deprecated and are no longer available on serverless:

• openai/gpt-oss-20b. Recommended replacement: Qwen/Qwen3.5-9B. Supported by on-demand dedicated endpoints.
• google/gemma-4-31B-it. Recommended replacement: zai-org/GLM-5.3-Flash. Supported by on-demand dedicated endpoints.
• thinkingmachines/Inkling-Small. Recommended replacement: zai-org/GLM-5.3-Flash. Supported by on-demand dedicated endpoints.
• intfloat/multilingual-e5-large-instruct. Not available as an on-demand dedicated endpoint.

See Deprecations for migration guidance.

Together CLI v2.33.2

Version 2.33.2 of the Together CLI improves error reporting and upload feedback:

Endpoint, fine-tuning, and model commands now print the API’s error message when a request fails, rather than a generic failure notice. The same goes for a missing API key or command argument.

tg evals create and tg batches submit now show a progress bar while uploading files, matching tg files upload.

tg fine-tuning list-events no longer fails on jobs with more than 20 events.

The --scale-to-zero-window flag has been removed from tg beta endpoints deploy and tg beta endpoints update.

See the CLI reference.

Preemptible compute for GPU clusters

Preemptible compute is now in public preview for Kubernetes GPU clusters. Alongside standard nodes, you can set a preemptible GPU target, and Together provisions toward it as spare capacity becomes available, at a flat discounted rate relative to on-demand.

What’s new:

• Preemptible GPU targets: Set num_preemptible_gpus at cluster create or update from the console, CLI, or API. Together automatically provisions replacements toward the target after nodes are reclaimed.
• Five-minute drain window: Reclaimed nodes are cordoned and emit a TogetherPreemptionNotified Kubernetes event, and pods receive SIGTERM with up to 300 seconds of grace to checkpoint and exit.
• Sub-hourly billing: Usage is metered every one to two minutes, so you pay only for the time a node is live.

See Preemptible compute for the preemption contract, scheduling guidance, and checkpoint examples.