OpenAI compatibility

​

Drop-in client setup

import os
import openai

client = openai.OpenAI(
    api_key=os.environ.get("TOGETHER_API_KEY"),
    base_url="https://api.together.ai/v1",
)

response = client.chat.completions.create(
    model="MiniMaxAI/MiniMax-M3",
    messages=[{"role": "user", "content": "Hello!"}],
)

print(response.choices[0].message.content)

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.TOGETHER_API_KEY,
  baseURL: "https://api.together.ai/v1",
});

const response = await client.chat.completions.create({
  model: "MiniMaxAI/MiniMax-M3",
  messages: [{ role: "user", content: "Hello!" }],
});

console.log(response.choices[0].message.content);

curl https://api.together.ai/v1/chat/completions \
  -H "Authorization: Bearer $TOGETHER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MiniMaxAI/MiniMax-M3",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

​

Geo-specific inference

​

Endpoint compatibility matrix

• Video generation.
• Image edits and inpainting beyond images.generate.
• Reasoning controls and reasoning_content.
• Logprobs surface.

​

Drop-in compatibility

​

Known incompatibilities

​

Model identifiers

​

Endpoints not implemented

• Assistants, Threads, and Runs are not implemented. Build the agent loop yourself with function calling.
• The OpenAI-shaped Batch API and Files API are not exposed through /v1. Together has its own batch API and files API.
• moderations.create is not implemented and returns a 404. No moderation models are available, so prompt a chat model to classify content instead.

​

Parameter quirks

• logprobs returns Together’s own shape, which is richer than OpenAI’s.
• seed is best-effort. Determinism is not guaranteed across replicas, model versions, or load conditions.
• n (multiple completions per request) is supported on most chat models but not on every model. Loop client-side if a model rejects it.
• logit_bias is not supported on most models.
• service_tier, store, metadata, and prediction are accepted but ignored.
• reasoning_effort works on GPT-OSS models ("low", "medium", "high"). Other reasoning controls (Together’s reasoning={"enabled": ...} toggle, chat_template_kwargs) are not part of OpenAI’s API surface.
• Vision models accept image_url with both remote URLs and base64 data URIs. The detail field is accepted but ignored.

​

Response shape differences

• usage always includes prompt_tokens, completion_tokens, and total_tokens. Extra token counts vary in location by model, so read both shapes defensively:
  • Reasoning models (for example zai-org/GLM-5.2, deepseek-ai/DeepSeek-V4-Pro-0813, Qwen/Qwen3.6-Plus) nest them OpenAI-style: cached prompt tokens under usage.prompt_tokens_details.cached_tokens and reasoning tokens under usage.completion_tokens_details.reasoning_tokens.
  • Some non-reasoning models return cached_tokens flat at the top level of usage, with no *_details objects.
  A client configured for only one shape will return 0 for all others (with no error message). Fall back across both locations, for example (usage.prompt_tokens_details or {}).get("cached_tokens") or usage.get("cached_tokens", 0).
• Reasoning models return the chain of thought in a reasoning or reasoning_content field on the assistant message (not OpenAI’s nested reasoning object). The field name depends on the model. Pass it back under the same key when you send a prior turn to the API for preserved thinking or multi-turn tool calling.
• id and system_fingerprint are present but use Together’s formats. Don’t parse them as OpenAI IDs.
• images.generate returns url or b64_json per the response_format param, matching OpenAI. Some image models also return Together-specific metadata fields (for example seed).

​

Errors

​

Community libraries