Kimi K3 API Access Guide (2026): Pricing, Setup & Routing

Moonshot AI's Kimi K3 landed this week as one of the more interesting model releases of July 2026. The official Kimi blog introduces Kimi K3 as a 2.8-trillion-parameter model with native vision, a 1-million-token context window, and OpenAI-compatible API access. The company says full weights are planned for release by July 27, 2026, while the API is already available through the Kimi platform.

That's the headline. The practical question is narrower: should developers actually route production workloads to Kimi K3, and if so, how? My take: K3 is worth testing for long-context coding, repo-level analysis, and document-heavy knowledge work. It is not the cheap default model for every chat request. At $3 per million uncached input tokens and $15 per million output tokens, you need routing discipline.

Kimi K3 Pricing and Context Window

The most important API detail is the cache split. K3's list price is not just input/output; cache-hit input is priced separately. That matters because a 1M-context model can get expensive fast if you keep resending the same repository map, policy file, or documentation pack without taking advantage of context caching.

For long jobs, the rough math is simple. A request with 800K fresh input tokens and 20K output tokens costs about $2.40 in input plus $0.30 in output, or $2.70 total before tax. If most of that input becomes a cache hit on later turns, the same 800K input section drops from $2.40 to $0.24. That's the difference between “usable in an agent loop” and “why is the bill on fire?”

Kimi K3 vs K2.7 Code vs GPT-5.6 Luna

K3 should not replace your whole stack. It should sit in a router next to cheaper models. Use it when the task needs both long context and strong reasoning. Use K2.7 Code when the task is mostly coding and fits inside 256K. Use a cheap general model when the task is summarization, classification, or small prompt transformation.

Basic Kimi K3 API Setup

Kimi's API is OpenAI-compatible, which is good news. You can keep most of your OpenAI SDK plumbing and swap the base URL and model name.

cURL

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3",
    "messages": [
      {"role": "user", "content": "Explain Kimi K3 in one paragraph for an API developer."}
    ]
  }'

Python

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.ai/v1",
)

response = client.chat.completions.create(
    model="kimi-k3",
    reasoning_effort="max",
    messages=[
        {"role": "user", "content": "Review this architecture plan and list the top risks."}
    ],
)

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

Node.js

import OpenAI from "openai";

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

const response = await client.chat.completions.create({
  model: "kimi-k3",
  reasoning_effort: "max",
  messages: [
    { role: "user", content: "Turn this product spec into an implementation checklist." }
  ],
});

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

Important Migration Notes

The trap is assuming “OpenAI-compatible” means every parameter behaves like every other model. It doesn't. Kimi's docs say K3 always reasons and uses the top-level reasoning_effort field. At launch, only max is supported. If you're migrating from Kimi K2.x, don't send the older thinking object to K3.

Also watch sampling parameters. The Kimi parameter reference says temperature, top_p, n, presence_penalty, and frequency_penalty cannot be modified for K3. If your generic model gateway injects these by default, remove them for kimi-k3. This is exactly the sort of small compatibility detail that breaks otherwise clean model routers.

Vision Input Example

K3 supports native visual understanding. For OpenAI-style vision messages, send content as an array of typed parts. Don't serialize the image and text into one giant string.

import base64
from pathlib import Path
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.ai/v1",
)

image_b64 = base64.b64encode(Path("screenshot.png").read_bytes()).decode()

response = client.chat.completions.create(
    model="kimi-k3",
    messages=[{
        "role": "user",
        "content": [
            {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{image_b64}"}},
            {"type": "text", "text": "Find the UI bug in this screenshot and suggest a fix."}
        ]
    }]
)

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

Routing Pattern: Don't Send Everything to K3

A good production setup routes by context size, task risk, and expected output length. Here's a practical starting point:

• Use Kimi K3 for requests above 200K input tokens, long-horizon coding tasks, screenshot-heavy debugging, and research jobs that need a lot of source material in one prompt.
• Use Kimi K2.7 Code for normal coding-agent tasks that fit under 256K and don't need K3's frontier reasoning.
• Use cheaper general models for classification, title generation, short summaries, and JSON extraction from small inputs.
• Cache stable context aggressively: repo maps, coding rules, product docs, and evaluation rubrics should not be paid as fresh input on every turn.

If you run a multi-model gateway, KissAPI can be useful as the operational layer around this pattern: one API key, OpenAI-compatible requests, and room to fall back when a provider is slow or too expensive for the current task. Don't hard-code your app to one fresh launch. New models are arriving too quickly for that.

Cost Control Checklist

1. Strip unsupported parameters. For K3, don't send generic temperature or penalty fields from a shared client wrapper.
2. Estimate tokens before long requests. A 900K-token prompt should be an explicit decision, not an accident.
3. Log cache-hit and cache-miss spend separately. K3's economics depend on caching.
4. Cap output tokens. Output is $15 per million tokens, so runaway answers hurt.
5. Keep a cheaper fallback. K2.7 Code or another coding model is usually enough for smaller jobs.

FAQ

When was Kimi K3 released?

Moonshot AI released Kimi K3 in July 2026. The official Kimi K3 documentation describes it as a 2.8-trillion-parameter flagship model with native vision and a 1,048,576-token context window.

How much does Kimi K3 cost?

Kimi K3 costs $0.30 per million cache-hit input tokens, $3.00 per million cache-miss input tokens, and $15.00 per million output tokens through the Kimi API pricing page.

What is the correct Kimi K3 model name?

The model name for Kimi K3 API calls is kimi-k3. Use the base URL https://api.moonshot.ai/v1 with an OpenAI-compatible client.