MiniMax Anthropic-Compatible API: Messages, Tools, and Caching

Last verified: July 18, 2026.

The MiniMax Anthropic-compatible API lets an application written for the Anthropic Messages format call MiniMax M3 with a changed base URL and MiniMax credential. This is useful when an SDK, agent framework, or coding tool already expects Anthropic-style messages, content blocks, tool calls, and server-sent events.

Compatibility does not mean that every Anthropic parameter behaves identically. MiniMax documents a defined subset, ignores several fields, and applies model-specific rules to thinking and multimodal input. This guide shows the supported path and makes those boundaries explicit.

Quick answer

Setting	Value
SDK base URL	https://api.minimax.io/anthropic
Direct Messages endpoint	POST https://api.minimax.io/anthropic/v1/messages
Recommended model for this guide	MiniMax-M3
Authentication	MiniMax API key; keep it on the server
Non-streaming	stream: false or omit the field
Streaming	stream: true
M3 thinking default	Off when thinking is omitted
Enable M3 thinking	{"type":"adaptive"}
Keep M3 thinking off	{"type":"disabled"}

If you need the OpenAI format instead, begin with our MiniMax API hub. Use this page when the consuming library specifically expects Anthropic Messages semantics.

Prerequisites and secure setup

1. Create a MiniMax API key in the official platform console.
2. Store the key in a server-side environment variable. Do not expose it in browser JavaScript, a mobile bundle, a public repository, or a WordPress page.
3. Install the Anthropic SDK for your language.
4. Use the MiniMax Anthropic base URL, not Anthropic’s default host.
5. Set request budgets and log response status, stop reason, latency, and token usage without logging sensitive prompt content.

# Python
python -m pip install anthropic

# Node.js
npm install @anthropic-ai/sdk

# Store this in your shell or secret manager
export MINIMAX_API_KEY="replace-with-a-server-side-key"

MiniMax offers pay-as-you-go API keys and Token Plan Subscription Keys for different billing paths. Do not assume that one key automatically uses the other resource pool. Check our MiniMax pricing guide before selecting a key and service tier.

Python: send a Messages request

This example sends a text request, explicitly keeps M3 thinking off, and prints only text blocks. Supplying thinking={"type":"disabled"} makes the intended behavior visible during review even though omission also leaves M3 thinking off.

import os
import anthropic

client = anthropic.Anthropic(
    api_key=os.environ["MINIMAX_API_KEY"],
    base_url="https://api.minimax.io/anthropic",
)

message = client.messages.create(
    model="MiniMax-M3",
    system="Answer as a concise technical editor.",
    messages=[
        {
            "role": "user",
            "content": "Explain idempotency in one paragraph and give one example.",
        }
    ],
    max_tokens=700,
    thinking={"type": "disabled"},
)

text_parts = [
    block.text
    for block in message.content
    if block.type == "text"
]

print("\n".join(text_parts))
print({
    "stop_reason": message.stop_reason,
    "input_tokens": message.usage.input_tokens,
    "output_tokens": message.usage.output_tokens,
})

Do not assume that content[0] is text. A response can contain thinking, text, or tool-use blocks, and their order depends on the request. Filter by each block’s type.

Node.js: send the same request

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic({
  apiKey: process.env.MINIMAX_API_KEY,
  baseURL: "https://api.minimax.io/anthropic",
});

const message = await client.messages.create({
  model: "MiniMax-M3",
  system: "Answer as a concise technical editor.",
  messages: [
    {
      role: "user",
      content: "Explain idempotency in one paragraph and give one example.",
    },
  ],
  max_tokens: 700,
  thinking: { type: "disabled" },
});

const answer = message.content
  .filter((block) => block.type === "text")
  .map((block) => block.text)
  .join("\n");

console.log(answer);
console.log({
  stopReason: message.stop_reason,
  inputTokens: message.usage.input_tokens,
  outputTokens: message.usage.output_tokens,
});

The SDK base URL ends at /anthropic. The SDK adds /v1/messages. A raw HTTP client instead sends the request directly to https://api.minimax.io/anthropic/v1/messages with JSON content and bearer authentication.

M3 thinking control is not a depth slider

MiniMax M3 uses three relevant states in the Anthropic-compatible interface:

• Omitted: thinking is off, so no thinking blocks should be returned.
• {"type":"adaptive"}: thinking is enabled.
• {"type":"disabled"}: thinking remains off.

For M2.x models, thinking cannot be disabled. The compatibility layer may accept disabled, but the model still reasons. Do not write application logic that assumes M2.x will return text-only content after receiving that setting.

When thinking is enabled and a conversation continues across tool calls, append the complete assistant content list to history. That includes thinking, text, and tool_use blocks. Removing or editing thinking blocks can break the documented reasoning continuity.

Stream text without assuming one event type

Streaming returns Anthropic-style events. Handle thinking_delta only if thinking is enabled, and handle text_delta separately. The following Python example prints text while safely ignoring other event types.

stream = client.messages.create(
    model="MiniMax-M3",
    messages=[
        {"role": "user", "content": "Give three retry rules for an API client."}
    ],
    max_tokens=600,
    thinking={"type": "disabled"},
    stream=True,
)

for event in stream:
    if event.type != "content_block_delta":
        continue

    delta = getattr(event, "delta", None)
    if delta and delta.type == "text_delta":
        print(delta.text, end="", flush=True)

print()

In production, also capture the final stop reason and usage event, set connection and read timeouts, and treat a dropped stream as an incomplete response. Do not concatenate thinking text into the user-visible answer unless your product deliberately exposes it and your policy allows that behavior.

Supported and ignored parameters

Group	Parameters	Important boundary
Supported	model, max_tokens, stream, system, temperature, top_p, tools, tool_choice, metadata, thinking, service_tier	M3 temperature range is documented as 0–2; M3 top_p defaults to 0.95.
Partially supported	messages	M3 accepts text, image, video, thinking, tool-use, and tool-result blocks. M2.x accepts text and tool-call content, not image or video input.
Ignored	top_k, stop_sequences, mcp_servers, context_management, container	Sending an ignored field does not make its feature effective. Remove dependencies on it or use a supported MiniMax route.

service_tier accepts standard and priority. Standard is used when the field is omitted. MiniMax documents priority admission at 1.5 times the standard price; it improves request admission priority but should not be presented as a guarantee of a specific latency.

Tool calls: preserve the complete assistant turn

Tool definitions use the Anthropic-style tools array, while tool_choice supports auto and none. A correct application loop is:

1. Send tool names, descriptions, and strict input schemas with the user request.
2. Inspect every response content block for tool_use.
3. Validate the generated arguments before executing any function.
4. Append the complete assistant content list to conversation history.
5. Append a user turn containing the matching tool_result.
6. Call Messages again until the model returns a final text answer or the loop reaches your safety limit.

Use an allowlist, timeouts, least-privilege credentials, and human confirmation for destructive or high-impact actions. Our dedicated MiniMax function-calling guide covers schemas, tool loops, interleaved thinking, validation, and failure handling without duplicating that implementation here.

Caching: automatic for M3, explicit for documented M2.x models

MiniMax’s passive-caching reference shows automatic prefix caching with MiniMax-M3 through the Anthropic SDK. It requires at least 512 input tokens and works best when stable tools, system instructions, and history precede dynamic user content. Measure it through the cache fields in usage; no cache_control marker is required for this mode.

The separate explicit-caching reference documents cache_control for M2.7, M2.5, M2.1, and M2-series models; its supported-model table does not list M3 on the verification date. Explicit entries have a documented five-minute lifetime that refreshes when hit. Do not assume that Anthropic format alone makes explicit markers valid for M3. See the MiniMax prompt-caching guide for the model matrix, prefix order, invalidation, measurement, and billing distinction.

M3 image and video boundaries

MiniMax M3 accepts images by URL or base64 in JPEG, PNG, GIF, and WebP formats, with a documented 10 MB image limit. It accepts video by URL, base64, or an mm_file://{file_id} reference in MP4, AVI, MOV, and MKV formats. URL or base64 video is limited to 50 MB, the full request body is limited to 64 MB, and Files API video can be up to 512 MB.

Those are transport limits, not a promise that every frame or detail will be interpreted correctly. Estimate input usage with POST /anthropic/v1/messages/count_tokens, validate output against the source media, and avoid sending sensitive media without an appropriate data review. Use MiniMax’s Messages reference in the source list below for the exact content-block schema, then add test cases for every media format your application accepts.

Read the response as blocks, stop reason, and usage

A non-streaming Messages response includes an ID, the fixed message type, the assistant role, the model used, a content array, stop_reason, and token usage. The content array is the primary result. A plain answer usually contains a text block; a reasoning-enabled answer can also contain thinking; a tool request contains tool_use. Your parser should reject unknown block types safely rather than casting every block to text.

The documented stop reasons carry operational meaning. end_turn means the model ended its answer naturally. max_tokens means the output cap was reached, so the text may be incomplete. tool_use means the model requested one or more functions and the application must decide whether to execute them. A tool-use turn is not a final user answer.

Usage includes ordinary input and output tokens and can include cache creation and cache read counts. Store these numeric fields with request ID, model ID, latency, and application route. Do not log full prompts, media URLs, thinking blocks, or tool results by default. Redacted measurements are enough for cost analysis and debugging in most applications.

Regression tests before switching an existing client

A base-URL change proves connectivity, not behavioral equivalence. Build a small fixture set that checks text-only output, explicit M3 thinking on and off, maximum-output handling, a tool request and result, a stream that closes cleanly, and any image or video format your product accepts. Add a negative test for each ignored parameter on which the old integration depended.

• Compare block types and stop reasons, not only rendered text.
• Verify that tool arguments pass the same schema and authorization rules.
• Confirm that cache reads appear in usage before estimating savings.
• Test both standard and priority admission only if your billing plan permits them.
• Re-run safety, privacy, and retention reviews because the API provider and processing path changed.

Troubleshooting checklist

• 404 or wrong host: give the SDK https://api.minimax.io/anthropic; give raw HTTP the full /anthropic/v1/messages path.
• 401 authentication error: confirm the key belongs to the intended MiniMax billing path and was loaded on the server.
• No thinking blocks: this is expected for M3 unless thinking is set to adaptive.
• Thinking remains with M2.x: those models cannot disable it through this compatibility setting.
• Tool loop loses context: preserve the entire assistant content list and match every tool result to its tool-use ID.
• Ignored setting appears ineffective: check the compatibility table; several Anthropic fields are accepted but ignored.
• Output ends early: inspect stop_reason. Increase max_tokens only after checking context and cost limits.

Frequently asked questions

Is this an Anthropic-hosted model?

No. The request format and SDK are Anthropic-compatible, but the endpoint, key, model, billing, and processing are provided by MiniMax.

Can I switch an existing Anthropic SDK application by changing only the base URL?

A simple text application may need only the base URL, key, and model name changed. Applications that rely on ignored parameters, model-specific content blocks, tool-choice modes beyond auto/none, or Anthropic-specific platform behavior need code changes and regression tests.

Does M3 always return reasoning?

No. Thinking is off by default for MiniMax M3. Set thinking to adaptive when the task and product policy justify it.

Official sources used

• MiniMax Anthropic SDK compatibility guide
• MiniMax Messages API reference
• MiniMax automatic prompt-caching reference
• MiniMax explicit prompt-caching reference

Conclusion: Use the Anthropic-compatible route when your application benefits from Messages content blocks or an Anthropic SDK integration. Treat it as a documented compatibility layer, test the exact parameters your application uses, and keep model-specific thinking and multimodal behavior explicit in code.