Migrating to Kimi K3 from OpenAI or Anthropic

Moving to Kimi K3 is unusually easy at the plumbing level: the API is both OpenAI-compatible and Anthropic-compatible, so most integrations need a base URL and a model string. The work is not in the code — it is in the four behavioural differences that will surprise your prompts.

The code change

  client = OpenAI(
-     api_key=OPENAI_KEY,
+     api_key=MOONSHOT_KEY,
+     base_url="https://api.moonshot.ai/v1",
  )

  resp = client.chat.completions.create(
-     model="gpt-5-6-sol",
+     model="kimi-k3",
+     reasoning_effort="high",        # default is "max"
+     max_completion_tokens=4096,     # default is 131072
  )

If your code targets the Anthropic SDK instead, an Anthropic-compatible endpoint is available and the same principle applies.

Four behavioural differences to plan for

1. Reasoning cannot be disabled. If your pipeline relies on a fast non-reasoning path for cheap calls, that path does not exist on K3. Route those requests to a different model rather than trying to configure it away.
2. reasoning_effort defaults to max. Set it explicitly on day one, or you will pay top rate on everything. Three levels — low, high, max — where you may be used to five.
3. Image URLs are rejected. Public URLs do not work; supply base64 or an uploaded ms://<file-id> reference. This breaks vision pipelines migrating from other providers.
4. The output default is large. 131,072 tokens by default, so a runaway generation is expensive. Set your own ceiling.

What to re-tune

• Delete "think step by step" instructions. Reasoning is always on and already deliberate. Explicit chain-of-thought prompts cause redundant work.
• Restructure for the cache. Provider caching semantics differ; K3's is automatic and prefix-based, so revisit prompt ordering rather than porting cache_control markers.
• Re-check your token budgets. Reasoning shares the output budget, so limits that were comfortable elsewhere may truncate here.
• Re-run your evaluation set. Same task, different model. The point of migrating is a cost or capability gain, and you cannot see either without a before-and-after measurement.

A sensible migration order

1. Pick one non-critical workload and port it. Measure cost and quality against your current model.
2. Fix the four behavioural items above — they will all show up in this first pass.
3. Get caching working and verify the hit rate in your usage figures.
4. Expand to workloads where the economics are strongest: long-context and output-heavy work.
5. Keep a cheaper model for trivial high-volume traffic. K3's always-on reasoning makes it the wrong tool there.

More on Kimi K3

Start with the complete Kimi K3 guide for the overview, or go deeper:

• K3 Max vs K3 Swarm Max: Which Variant Do You Need?
• Kimi K3 for Deep Research: Search-Heavy Work at Scale
• Kimi K3 vs ChatGPT: A Model Against a Product