If you are searching for the Kimi 3 API, the official model name to use in code is Kimi K3. The distinction matters because model docs, SDK examples, pricing tables, and the API model identifier all use kimi-k3, not kimi-3.
As of September 11, 2026, Kimi's own Kimi K3 guide lists Kimi K3 as its flagship model for long-horizon coding, end-to-end knowledge work, deep reasoning, visual understanding, video understanding, and 1M-token context workflows. The Kimi API Platform exposes it through OpenAI-compatible Chat Completions, OpenAI-compatible Responses, and Anthropic-compatible Messages protocols, so developers can evaluate Kimi K3 without rebuilding every request wrapper from scratch.
This guide explains what is current about the Kimi 3 API search query, how to call Kimi K3 directly, what changed since the first K3 launch coverage, and how an indie hacker can test Kimi K3 through a direct provider route or a multi-model gateway such as Flatkey.
Kimi 3 API vs Kimi K3 API
Kimi K3 is the official name. Kimi 3 API is a useful search phrase because many developers use version-like language when a major model generation launches.
Use the terms this way:
- In article titles and educational copy, "Kimi 3 API (Kimi K3)" helps readers map the search phrase to the official model.
- In API requests, use
kimi-k3in themodelfield. - In engineering tickets and docs, prefer "Kimi K3" after the first clarification.
This avoids a simple but costly mistake: copying a popular query phrase into code and debugging a model-not-found error that has nothing to do with account access.
Current Kimi K3 API facts
The current Kimi API docs describe Kimi K3 as a 2.8-trillion-parameter model with native visual understanding and a 1,048,576-token context window. Kimi says full model weights have been released, which replaces the launch-week wording that the weights were scheduled for release by July 27, 2026.
| Field | Current developer note |
|---|---|
| Official model name | Kimi K3 |
| API model ID | kimi-k3 |
| Direct OpenAI-compatible base URL | https://api.moonshot.ai/v1 |
| Chat endpoint | /chat/completions |
| Responses endpoint | /responses |
| Anthropic-compatible base URL | https://api.moonshot.ai/anthropic |
| Context window | 1,048,576 tokens |
| Modalities | Text, image, and video input are documented |
| Reasoning | Always enabled for K3; use reasoning_effort |
| Reasoning effort values | low, high, max; default is max |
| Access requirement | Minimum $1 successful top-up unlocks API use |
| Direct Kimi pricing | $0.30 cache-hit input, $3.00 cache-miss input, $15.00 output per 1M tokens, excluding applicable taxes |
Pricing, route availability, and rate limits can change, so treat fixed numbers as a pre-deployment check item rather than a permanent contract. Kimi's own pricing and rate-limit docs should be checked before you budget a production rollout.
What changed since launch week?
If you read an older Kimi K3 article, recheck these points before you copy its advice:
- Kimi's K3 docs now say the full model weights have been released.
- Kimi's model list now positions
kimi-k3as the migration target for several retired model IDs. - The
kimi-k2.5andmoonshot-v1series were retired on August 31, 2026, and calls to those models now return model-not-found errors according to Kimi's model list and platform changelog. - The API overview now documents three compatibility surfaces: OpenAI Chat Completions, OpenAI Responses, and Anthropic Messages.
- K3-specific request behavior still matters: K3 always reasons, several sampling parameters are fixed, and public image URLs are not supported for vision input.
For an indie hacker or small AI product team, the practical takeaway is simple: if an old prototype used a Moonshot v1 or K2.x model ID, do not just swap the base URL and hope the rest works. Update the model ID, remove unsupported thinking parameters, run smoke tests, and validate costs and limits again.
How to call Kimi K3 directly with the OpenAI SDK
Kimi's OpenAI-compatible setup uses the OpenAI SDK with the Moonshot API key and Kimi base URL.
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="low",
messages=[
{
"role": "user",
"content": "Review this launch checklist and list the three riskiest gaps.",
}
],
)
print(response.choices[0].message.content)
That is enough for a basic text call. It is not enough for production migration. Kimi K3 differs from generic OpenAI-compatible models in ways your app should test explicitly.
Kimi K3 parameters you should not skip
The most important K3 parameter is reasoning_effort.
Kimi K3 always has thinking enabled. You cannot turn it off, but you can choose the reasoning effort level:
lowfor lower-latency checks, drafts, classification, or cheaper exploration.highfor harder reasoning tasks where latency is acceptable.maxfor the deepest K3 reasoning mode and the current default.
The Kimi parameter reference also says temperature, top_p, n, presence_penalty, and frequency_penalty are fixed for K3. Passing incompatible values can return errors, so omit those parameters unless the current docs say otherwise.
For multi-turn conversations and tool calls, Kimi says to pass back the complete assistant message returned by the API, including reasoning and tool-call fields. If your existing app stores only message.content, fix that before you judge K3 on agent workflows.
Vision and video input: use the supported formats
Kimi K3 supports visual understanding, but the input shape is specific.
For image messages, message.content must be an array of parts, not a JSON string. Kimi's vision docs support base64 image content and file-ID references. They currently do not support public URL-formatted images for vision input.
For video, upload the file first and reference it with the ms://<file-id> format in a video_url part. Kimi recommends keeping video resolution at or below FHD and using the token estimation API before expensive multimodal jobs.
This matters for product teams because a provider can be "OpenAI-compatible" for chat while still having provider-specific rules for images, video, file uploads, limits, and billing.
Direct Kimi API or Flatkey route?
Both approaches are valid. The right choice depends on what you are trying to learn.
Choose the direct Kimi API when:
- you want the closest path to Moonshot-specific K3 features;
- your app is primarily evaluating Kimi K3 rather than comparing many models;
- you are comfortable managing another provider account, balance, key, rate-limit profile, and invoice;
- you can keep Kimi-specific parameter handling in your application code.
Choose a multi-model gateway such as Flatkey when:
- you want one OpenAI-compatible base URL while comparing Kimi K3 with GPT, Claude, Gemini, DeepSeek, Qwen, GLM, Seedance, and other supported models;
- your app needs fallback routing, model allowlists, usage logs, quota controls, or shared billing;
- you want to move provider-specific credentials and route policy out of feature code;
- you are building with coding agents or automation jobs that may consume large token volumes across several providers.
Flatkey's public model catalog currently lists kimi-k3 as available through the OpenAI-compatible endpoint type. Flatkey's current router base URL for OpenAI-compatible requests is:
https://router.flatkey.ai/v1
The corresponding SDK setup is:
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["FLATKEY_API_KEY"],
base_url="https://router.flatkey.ai/v1",
)
response = client.chat.completions.create(
model="kimi-k3",
messages=[
{
"role": "user",
"content": "Compare these three onboarding flows and pick the lowest-risk launch path.",
}
],
)
print(response.choices[0].message.content)
Before production use, confirm whether the route supports every Kimi-specific request field your workload needs. Compatibility is an integration shortcut, not a substitute for test coverage.
A practical Kimi K3 evaluation workflow
Use this sequence before moving real users to the Kimi 3 API route:
- Confirm model ID and access. Verify
kimi-k3appears in the current provider or gateway model list, and confirm your account has the required balance or route permission. - Run a plain text smoke test. Start with a short non-streaming prompt before adding tools, JSON mode, streaming, long context, or vision.
- Test the exact workload. Use real prompts from your product: coding agent tasks, document analysis, support automation, research, structured extraction, or multimodal review.
- Measure output acceptance. Do not rely only on benchmark claims. Track whether users, reviewers, or downstream parsers accept the answer.
- Measure latency and token use. K3's long context and reasoning can be useful, but they can also change wall-clock time and output length.
- Test parameter behavior. Remove fixed sampling parameters, set
reasoning_effortdeliberately, and preserve full assistant messages in multi-turn sessions. - Check multimodal constraints. Use base64 or file uploads for images and videos, and estimate token cost before large media jobs.
- Define fallback. Pick fallback models with the same modality and response-shape requirements. Decide when to retry, fail visibly, or route elsewhere.
- Review usage logs. Confirm you can see model, status, tokens, cached tokens, cost, latency, owner, and environment.
- Roll out one workload. Start with a bounded workload, then expand after the route proves quality, reliability, and cost.
Kimi K3 migration checklist for older Kimi apps
If your code already uses older Kimi or Moonshot model IDs, check the following:
- Replace retired model IDs such as
kimi-k2.5ormoonshot-v1-*withkimi-k3or another supported current model. - Remove K2.x
thinkingconfiguration when moving to K3; use top-levelreasoning_effortinstead. - Stop passing unsupported sampling parameters.
- Preserve complete assistant messages in multi-turn and tool-call flows.
- Retest JSON schema output, tool-choice behavior, streaming parser behavior, and error handling.
- Recalculate cache-hit and cache-miss economics from the current pricing table.
- Recheck rate limits for your current recharge tier.
- Update dashboards, alerts, and runbooks so
kimi-k3is visible as its own model route.
Common mistakes with the Kimi 3 API
Using the wrong model name
Use kimi-k3, not kimi-3. Keep the "Kimi 3 API" phrase for search and user-facing explanation.
Treating OpenAI-compatible as identical
OpenAI-compatible means you can reuse a familiar request surface. It does not guarantee identical model parameters, multimodal handling, rate limits, usage fields, or output behavior.
Ignoring cache misses
Kimi K3 pricing separates cache-hit and cache-miss input. For long-context apps, a small difference in prefix stability can materially change effective cost.
Evaluating only benchmark screenshots
Kimi's launch materials include benchmark and architecture claims, but your production decision should come from your own acceptance set, latency budget, parser compatibility, and fallback behavior.
Switching a long-running agent mid-session
Kimi's technical blog warns that K3 can be sensitive to thinking history. For agent workflows, avoid switching a live session from another model to K3 without resetting and validating the conversation state.
FAQ
Is Kimi 3 the same as Kimi K3?
"Kimi 3" is a common search phrase. Kimi K3 is the official model name, and kimi-k3 is the API model ID developers should use.
Is the Kimi K3 API available now?
Yes. Kimi's current model list includes kimi-k3, and the Kimi K3 guide documents direct API access through the Kimi API Platform.
What is the Kimi K3 context window?
The current Kimi docs list a 1,048,576-token context window for Kimi K3.
What does the Kimi K3 API cost?
Kimi's current inference pricing page lists Kimi K3 at $0.30 per 1M cache-hit input tokens, $3.00 per 1M cache-miss input tokens, and $15.00 per 1M output tokens, excluding applicable taxes. Recheck the pricing page before budgeting because model prices can change.
Can I disable Kimi K3 reasoning?
No. Kimi K3 always reasons. You can set reasoning_effort to low, high, or max.
Does Kimi K3 support image URLs?
Kimi K3 supports vision input, but Kimi's current vision docs say public URL-formatted images are not supported. Use base64 image content or file uploads instead.
Can I call Kimi K3 through Flatkey?
Flatkey's public catalog currently lists kimi-k3 as available through an OpenAI-compatible endpoint type. Use Flatkey when you want one key, one router base URL, shared billing, usage visibility, and routing controls across multiple supported models.
Build for the next model change
The Kimi 3 API search trend is really about a broader developer problem: model access changes faster than application architecture.
Kimi K3 is worth evaluating for long-context coding, knowledge work, deep reasoning, and multimodal tasks. But the durable engineering move is to keep provider choice configurable, test model-specific behavior explicitly, and centralize routing, usage, fallback, and billing before model experiments spread across your codebase.
Flatkey helps with that operating model by giving teams one OpenAI-compatible router, one API key, one balance, and one dashboard across supported official models and tools. Start with the Flatkey API quickstart, then compare kimi-k3 against the workloads where K3's long context and reasoning can actually move your product metrics.
