Kimi 3 API (Kimi K3): What Developers Need to Know

Searches for Kimi 3 API are rising, but the official model name is Kimi K3. That naming detail matters when you look for documentation, configure an SDK, or choose a model identifier: the API model ID is kimi-k3, not kimi-3.

As of July 23, 2026, Moonshot AI has made Kimi K3 available through the Kimi API Platform. The official documentation describes a 2.8-trillion-parameter flagship model with native visual understanding and a 1,048,576-token context window. It can be called through an OpenAI-compatible interface, and Moonshot says the full model weights will be released by July 27, 2026.

This guide separates what is confirmed from what still needs monitoring, shows the basic Kimi K3 API setup, and explains how to prepare an application for Kimi K3 and the next fast-moving model launch without rebuilding its integration every time.

Kimi 3 or Kimi K3: Which Name Is Correct?

Kimi K3 is the official name. “Kimi 3” is a natural search phrase, but Moonshot AI's launch page, API platform, documentation, and model ID all use Kimi K3.

Use these terms in the appropriate places:

• Search and educational copy: “Kimi 3 API (Kimi K3)” can help readers connect the popular query with the official product name.
• API requests: use kimi-k3 in the model field.
• Technical documentation: prefer “Kimi K3” after clarifying the naming difference once.

This avoids a common launch-week problem: copying an unofficial model name into code and assuming the resulting error means the API is unavailable.

What Is Confirmed About the Kimi K3 API?

The following details were confirmed in Moonshot AI's official materials on July 23, 2026:

Item	Confirmed information
Official model name	Kimi K3
API model ID	kimi-k3
Official API base URL	https://api.moonshot.ai/v1
API format	Compatible with the OpenAI API format
Chat endpoint	/chat/completions
Context window	1,048,576 tokens
Modalities	Text, image, and video input are documented
Reasoning	Always enabled; reasoning_effort supports low, high, and max
Direct API access	A successful top-up of at least $1 is required to unlock K3
Full model weights	Scheduled for release by July 27, 2026

Moonshot's official Kimi K3 pricing page currently lists, per one million tokens, $0.30 for cache-hit input, $3.00 for cache-miss input, and $15.00 for output, excluding applicable taxes. Treat these as time-sensitive figures and check the official pricing page again before budgeting or publishing a fixed comparison.

The official launch materials also contain benchmark and architecture claims. Those are useful starting points for evaluation, but teams should reproduce tests with their own prompts, tools, latency requirements, and output-review standards rather than treating a launch chart as a production decision.

How to Access the Kimi K3 API Directly

Moonshot documents an OpenAI-compatible setup, so developers already using the OpenAI SDK can initialize a client with a different API key and 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",
    messages=[
        {
            "role": "user",
            "content": "Summarize the main risks in this migration plan.",
        }
    ],
    reasoning_effort="low",
)

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

OpenAI-compatible does not mean every model behaves identically. Kimi K3 has model-specific rules. Its thinking mode is always enabled, several sampling parameters are fixed, and public image URLs are not supported for vision input according to the current documentation. Review the K3 parameter limits before moving an existing production workload unchanged.

Why an OpenAI-Compatible API Is Helpful—but Not the Whole Strategy

An OpenAI-compatible API reduces the mechanical work of integration. Your application can often preserve the same client library and request structure while changing the base URL, API key, and model name.

But compatibility at the transport layer does not remove operational differences between models:

• supported request parameters can differ;
• structured output behavior needs regression testing;
• tool-call schemas and tool-choice rules may vary;
• reasoning can change latency and token consumption;
• context limits do not guarantee equal long-document performance;
• rate limits and availability can change by account tier;
• multimodal input requirements may be provider-specific.

The durable approach is to separate your product code from provider-specific access. Your application should call a stable model-access layer, while routing policy, provider credentials, fallbacks, quotas, and usage reporting remain configurable outside the core feature.

Preparing Your App for Kimi K3 and the Next Model Launch

Fast model releases create two different jobs: evaluation and migration. Combining them into one emergency code change makes both harder.

1. Keep the API surface stable

Use one OpenAI-compatible client boundary in your application instead of scattering provider SDK initialization throughout the codebase. A stable base URL makes it easier to add or replace supported models without rewriting every feature.

Flatkey provides one API key and the OpenAI-compatible base URL https://router.flatkey.ai/v1 for supported models. Its live public catalog listed kimi-k3 as available when checked on July 23, 2026.

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": "Review this implementation plan."}
    ],
)

Always confirm the current model catalog and parameter support before deployment. Availability, route configuration, and pricing can change after a launch.

2. Route by workload, not by model hype

Do not send all traffic to a newly released model on day one. Define evaluation classes such as:

• repository-scale coding;
• document analysis;
• tool-using agents;
• structured data extraction;
• image or video understanding;
• low-latency customer chat.

Then test quality, latency, token consumption, and failure behavior for each class. A model can be excellent for long-horizon coding while remaining unnecessary for short classification calls.

3. Define model fallback before production traffic

A model fallback policy should answer more than “what runs if Kimi K3 is down?” It should define:

1. which backup models support the same input modality;
2. which request parameters must be removed or translated;
3. whether the backup preserves structured output and tool calls;
4. the maximum acceptable cost and latency;
5. when to fail visibly instead of returning a lower-confidence answer.

Flatkey's routing and automatic switching capabilities let teams manage supported upstream routes behind one integration. The application keeps a stable API boundary while the routing policy can evolve as model availability changes.

4. Track usage and enforce quotas centrally

A new model can change both average token consumption and output length. Centralized usage tracking helps engineering and finance see whether an experiment is improving the product or simply increasing spend.

Flatkey combines usage visibility, unified billing, API-key management, and quota controls in one dashboard. This is particularly useful when several teams are testing Kimi K3 alongside GPT, Claude, Gemini, DeepSeek, Qwen, or other supported models.

Direct Kimi API or a Multi-Model AI Gateway?

Both approaches can be valid.

Choose the direct Kimi AI API when you want the shortest path to Moonshot-specific capabilities, are comfortable managing another provider account, and plan to optimize closely around Kimi's current API behavior.

Choose a multi-model AI gateway when your application needs to compare models, switch routes without broad code changes, configure fallback, consolidate usage reporting, or control team quotas across providers.

The choice is not necessarily permanent. A clean OpenAI-compatible boundary lets teams test direct and gateway routes while keeping the application layer relatively stable.

For implementation details, read Flatkey's OpenAI-compatible API gateway migration checklist, then review the broader AI API gateway architecture guide.

Kimi K3 Evaluation Checklist

Before routing production traffic to Kimi K3, verify:

• the exact model ID and route are available;
• current input, output, and cache pricing;
• account-tier rate limits and concurrency;
• required reasoning_effort behavior;
• tool calling and structured-output compatibility;
• multimodal file and URL restrictions;
• latency at realistic context sizes;
• fallback behavior under rate limits or provider errors;
• usage, billing, and quota visibility;
• output quality on your own acceptance set.

A million-token context window is an important capability, but it is not a substitute for workload-specific testing, observability, and cost controls.

FAQ

Is Kimi 3 the same as Kimi K3?

“Kimi 3” is a common search phrase, while Kimi K3 is the official model name. Use kimi-k3 as the API model ID.

Is the Kimi K3 API available now?

Yes. As of July 23, 2026, Kimi K3 is documented and available through the official Kimi API Platform. Flatkey's live public model catalog also listed kimi-k3 as available on that date.

Is the Kimi K3 API OpenAI-compatible?

Moonshot states that the Kimi API uses an OpenAI-compatible format. Developers can use the OpenAI SDK with the Moonshot base URL and API key, while accounting for K3-specific parameter rules.

What is the Kimi K3 context window?

The official documentation lists a context window of 1,048,576 tokens, commonly described as one million tokens.

Can I disable reasoning in Kimi K3?

No. The current documentation says Kimi K3 always has thinking enabled. You can adjust reasoning_effort to low, high, or max.

Why use an AI API gateway for Kimi K3?

An AI API gateway can keep one application-facing API boundary while centralizing supported-model access, routing, fallback, usage tracking, billing, and quota controls. This reduces operational work when models and availability change quickly.

Build for Model Change, Not Just One Model

Kimi K3 is a significant new option for developers evaluating long-context, multimodal, coding, and knowledge-work workloads. The bigger architectural lesson is that model access will keep changing.

Flatkey helps teams access supported models through one API key, one OpenAI-compatible base URL, and one dashboard for routing, usage, billing, and quotas. Review the current model catalog and pricing before your next model evaluation.