POST /v1/messages uses one endpoint, header set and SDK configuration. Keys have no product modes. The capabilities below depend on the family, model and actual application of a Claude server prompt.
| Capability | Claude without a server prompt | Claude with an applied prompt | OpenAI endpoints |
|---|---|---|---|
| Streaming | Native Anthropic SSE, including thinking and citation deltas | Text and client functions; no thinking/signature/citation deltas | Chat Completions and Responses use their own streaming events with and without a server prompt |
| Client functions | Native tool_use → tool_result | The same client cycle, including rich tool_result; the client executes the function | Chat and Responses support client function calls; server tools do not run |
| Thinking / effort | Native thinking blocks and signatures; output_config.effort | thinking and output_config.effort are accepted and control depth; explicit thinking takes priority; separate signed thinking blocks/signatures are not returned | Native thinking blocks are outside the Chat/Responses contract |
cache_control | Explicit breakpoints, 5m/1h, and cache tiers | Explicit breakpoints, 5m/1h, and public cache tiers; a hit is not guaranteed | Explicit cache_control is unsupported in Chat/Responses; automatic caching remains |
| Sampling | top_k, top_p, temperature on Opus 4.6, Sonnet 4.6 and Haiku 4.5. Opus 5, Opus 4.8, Opus 4.7, Sonnet 5, Fable 5 and Fable 5.1 do not accept these fields at all, so Guard removes them from the request | Depend on the model and thinking compatibility; disabling thinking alone does not guarantee sampling | top_p and temperature depend on the model and thinking; top_k is unsupported |
| PDF / documents | Native PDFs and text/content documents | Base64 PDFs and text/content documents in a user message or tool_result | Chat/Responses do not accept PDFs; use Messages |
| Citations | Native document citations and citations_delta | Unsupported | Unsupported |
| Vision | Base64 and direct public URLs | Base64 in Messages; URL support is not promised | Chat accepts base64; Responses input_image is unsupported |
| Structured outputs | Messages: output_config.format | Messages: output_config.format; explicit thinking keeps format while conflicting effort is not applied | Responses structured text.format is unsupported |
| Web search / Web fetch | Native Anthropic server tools | The same native server tools in Anthropic Messages | Outside the Chat/Responses contract |
| Models | Including Fable 5/5.1, Opus 4.5 and Sonnet 4.5 | Fable 5/5.1, Opus 4.5 and Sonnet 4.5 with an applicable prompt are rejected before billing | Fable 5/5.1 are available without actual server-prompt application |
import anthropic
client = anthropic.Anthropic(
api_key=KEY,
base_url="https://api.guardrelay.ai",
)
msg = client.messages.create(
model="claude-opus-5",
max_tokens=512,
system="You are a concise assistant.",
messages=[{"role": "user", "content": "Explain recursion in two sentences."}],
)
print(msg.content[0].text)Kimi works here and answers in the ordinary Anthropic shape. The address and the key are the ones every family uses: https://api.guardrelay.ai and the Authorization: Bearer gd-… header. The gateway picks the family from the exact id in the model field: k3, k3-256k, kimi-for-coding or kimi-for-coding-highspeed. Kimi needs no separate key and no separate address.
| Field | What happens to it |
|---|---|
model | the exact id of one of the four Kimi models |
messages | the conversation in the Anthropic shape, roles user and assistant |
max_tokens | required, a positive integer; it also sets the output part of the money reserve |
system | a string or an array of content blocks |
stream | true turns on streaming |
stop_sequences, temperature, top_p, top_k | accepted and passed upstream as sent |
tools, tool_choice | client functions: the model returns a call, your code runs it |
thinking | the Anthropic-shaped switch: exactly {"type": "enabled"}, optionally with budget_tokens; it works on all four models |
output_config | takes effort and format inside |
context_management | accepted and passed upstream |
The answer is an ordinary Anthropic object: id, the content array, stop_reason and usage. On k3 the content array carries a signed thinking block next to the text. A token pre-count works for Kimi too: this surface has its own count_tokens path, it answers with the input token count and takes the same fields except max_tokens, stream and the sampling parameters stop_sequences, temperature, top_p, top_k.
Claude Code speaks exactly this protocol, so it runs on Kimi as well. Install it the usual way with npm i -g @anthropic-ai/claude-code, put the address and the key into environment variables, and name the model by its exact id at launch. Mac / Linux:
export ANTHROPIC_BASE_URL="https://api.guardrelay.ai"
export ANTHROPIC_AUTH_TOKEN="gd-your-key-from-bot"
claude --model k3$env:ANTHROPIC_BASE_URL = "https://api.guardrelay.ai"
$env:ANTHROPIC_AUTH_TOKEN = "gd-your-key-from-bot"
claude --model k3Windows PowerShell:
$env:ANTHROPIC_BASE_URL = "https://api.guardrelay.ai"
$env:ANTHROPIC_AUTH_TOKEN = "gd-your-key-from-bot"
claude --model k3Kimi does serve this surface: the answer is an ordinary Anthropic one, and on k3 it carries a signed thinking block as well. Composer and Grok accept it too, but their contract is shorter than the Anthropic one.
| Capability | Composer | Grok |
|---|---|---|
| Request fields | model, messages, system, max_tokens, stream, tools; automatic tool_choice, output_config with effort only (ignored) | same |
Roles in messages | user and assistant only | same |
| System text | top-level system only; a system role inside messages is rejected | same |
| Content block | type and text; an additional cache_control is accepted and ignored | same |
| Images | no, 400 cursor_image_input_unavailable | yes, inline base64 |
| Client tools | yes | yes |
thinking, temperature, top_k, top_p, metadata, cache_control | Accepted and ignored; cache_control is block-level | same |
| PDF, documents, citations | no | no |
| A typed Anthropic tool — computer use, text editor, web search | 400 cursor_parameter_unavailable before any charge | same |
| Context window | 200K, estimate | 500K, measured |
max_tokens | up to 32,000; without the field the full 32,000 is reserved | same |
The response is the ordinary Anthropic shape: a text block in content and stop_reason: "end_turn". If the model called one of your tools, tool_use blocks are added to content and stop_reason is tool_use — a turn you answer with a tool_result block. usage carries input_tokens, output_tokens and cache_read_input_tokens, while cache_creation_input_tokens is always 0: these models are not charged for cache writes.
curl https://api.guardrelay.ai/v1/messages \
-H "x-api-key: $GUARD_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "cursor-grok-4.6-high",
"max_tokens": 256,
"system": "Answer briefly.",
"messages": [{"role": "user", "content": "Connection check"}]
}'Tools are described the Anthropic way: a name, a description and an input_schema. The model returns a tool_use block and stop_reason: "tool_use", your client runs the function, and the result goes back as a tool_result block in a new message with the user role.
{
"model": "cursor-grok-4.6-high",
"max_tokens": 1024,
"messages": [{"role": "user", "content": [{"type": "text", "text": "What is the weather in Moscow?"}]}],
"tools": [{
"name": "get_weather",
"description": "Current weather in a city",
"input_schema": {
"type": "object",
"properties": {"city": {"type": "string"}},
"required": ["city"]
}
}]
}{
"role": "user",
"content": [{
"type": "tool_result",
"tool_use_id": "toolu_01...",
"content": "+7, clear"
}]
}