Kimi (Moonshot) API access, OpenAI-compatible — and its thinking default

Kimi's long context is great for large-file and repo-scale prompts, and via DaoXE it shares the same key as GPT, Claude and DeepSeek — no separate Moonshot signup. Call /v1/chat/completions with a Kimi ID. See the cheapest APIs guide for cost routing.

Call Kimi (Moonshot) through DaoXE#

Use /v1/chat/completions with an exact Kimi model ID. Reasoning is controlled differently across the current family: K2.6 keeps the thinking field (ON by default, disable it for plain output), the K2.7-code builds lock thinking ON with no opt-out, and K3 replaces the field entirely with a top-level reasoning_effort (low/high/max, default max).

# Kimi's reasoning contract differs by generation: K2.6 keeps the thinking
# field (ON by default - send disabled for plain output), K2.7-code locks it
# on, and K3 drops the field for a top-level reasoning_effort instead.
curl --fail-with-body --show-error --silent \
  https://daoxe.com/v1/chat/completions \
  -H "Authorization: Bearer ${DAOXE_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "YOUR_EXACT_MODEL_ID",
    "max_tokens": 64,
    "messages": [{"role": "user", "content": "Reply with OK."}],
    "thinking": {"type": "disabled"}
  }'

How Kimi exposes reasoning#

Kimi's reasoning contract split three ways as the family evolved. K2.6 keeps the K2.x thinking object (enabled by default, disabled to opt out) — a K2.x-only field the OpenAI SDK has no native slot for, so it rides in extra-body. K2.7-code locks it: thinking is always on, {"type": "disabled"} errors, and only {"type": "enabled", "keep": "all"} is accepted. K3 drops the field for a top-level reasoning_effort (low/high/max, default max) and always reasons with Preserved Thinking enabled — the trace still lands in reasoning_content, which must be passed back as-is in multi-turn tool use. Two cost traps: changing effort mid-conversation invalidates prefix-cache hits, and K3 is the only tier whose docs promise tool_choice: required. Whether a given relay path forwards these per-family fields is exactly the kind of thing to verify — one test call before you commit a client.

Kimi (Moonshot)-specific notes#

• Three behaviors, one family. K2.6: thinking defaults ON — send {"type": "disabled"} for plain output. K2.7-code: thinking is always on and passing disabled errors. K3 has no thinking field at all — it takes a top-level reasoning_effort instead. Check which ID you pinned before shipping a client.
• Sampling is locked on reasoning IDs. K2.6 fixes temperature at 1.0 (thinking) / 0.6 (non-thinking), K2.7-code and K3 at 1.0; top_p 0.95, n 1 and the penalty settings are fixed too — the vendor documents that other values return an error. Don't pass temperature explicitly on these IDs.
• K3's effort switch costs cache. Switching reasoning_effort mid-conversation invalidates prefix-cache hits — decide the level before the conversation starts and keep it. K3 also spans a 1M-token context window versus 256K for the K2.x tiers.
• The reasoning_content round-trip. With thinking on, echo the previous assistant message back as-is — including reasoning_content — in multi-turn tool use, or the request fails. Exact IDs always come from GET /v1/models.

What it costs#

Verify you actually get the model#

Prove the endpoint works before blaming the client — if this fails, no setting will fix it:

export DAOXE_API_KEY="your_api_key"

# List the exact model IDs your account can call
curl --fail-with-body --show-error --silent \
  https://daoxe.com/v1/models \
  -H "Authorization: Bearer ${DAOXE_API_KEY}"

Confirm connectivity, then diff a long-context prompt against the official Moonshot API at temperature 0 to check recall:

Frequently asked questions#