The best Kimi API model is the one that passes your workload’s acceptance test at an acceptable latency and cost. Do not choose from a static “best model” table alone. First fetch the live model inventory available to your account, then compare a small candidate set using the same prompts, tools, data, and scoring rules.
This page owns model routing and evaluation. It intentionally does not reproduce exact token prices, hard-code a changing list of public API model IDs, explain API-key creation, or repeat the first-request tutorial. Kimi Code uses a separate product endpoint and model-ID catalog, covered below only where that distinction prevents routing mistakes.
Start With the Live Model Inventory
Kimi provides an official endpoint that lists the models currently available to the authenticated Open Platform account. Use that response—not an old screenshot, copied code sample, or search-result snippet—as the starting inventory for direct API deployment decisions.
curl --request GET \
--url https://api.moonshot.ai/v1/models \
--header "Authorization: Bearer $MOONSHOT_API_KEY"The response can include each available model identifier and related metadata. Save the returned identifiers in your evaluation record, but keep the final production choice in configuration rather than application code.
Public API model IDs are different from Kimi Code model IDs
Do not mix the Open Platform inventory with Kimi Code. The public Kimi API currently presents models such as K3, K2.7 Code and K2.6 through the Open Platform and the api.moonshot.ai base URL. Kimi Code is a separate coding product with its own endpoint and IDs. In Kimi Code, kimi-for-coding now runs K2.8 Preview with up to 1M context, while kimi-for-coding-highspeed remains K2.7 Code HighSpeed.
This means a developer should not add kimi-for-coding to an Open Platform request or conclude that K2.8 Preview is a new public API model merely because it is available in Kimi Code. For direct API work, query GET /v1/models and use an identifier returned to that account. For Kimi Code, use the current Kimi Code model configuration and the Kimi Code endpoint documented for the client.
Discover Models With Python
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.ai/v1",
)
for item in client.models.list().data:
print(item.id)This script prints the account’s live Open Platform identifiers without hard-coding a model name. If the request fails, fix authentication with How to Get a Kimi API Key before comparing behavior.
Group Candidates by Job Before Testing
Do not compare every returned identifier against every prompt. Build a short list by operational role. The labels below are workload roles created for this guide; map them to the current models and capabilities returned by the official platform.
| Candidate role | Include it when the workload needs | Exclude it when |
|---|---|---|
| Capability-first default | High-quality reasoning, difficult knowledge work, complex agent plans, or multimodal analysis | The workload is simple and latency or cost dominates |
| Coding specialist | Repository navigation, code edits, tests, debugging, or programming-agent loops | Most requests are ordinary support, extraction, or non-code content |
| General-purpose route | Mixed chat, structured extraction, visual inputs, tools, and routine reasoning | A specialist consistently wins on the production task |
| Speed-optimized route | Interactive coding or chat where output latency has a measurable user cost | The speed premium does not improve conversion, completion, or operator time |
| Fallback route | Continuity when the primary route is unavailable or fails an agreed retry condition | Its output format, tools, context, or safety behavior is incompatible with the task |
Write the Acceptance Test Before Comparing Models
A model comparison without pass/fail criteria becomes a preference contest. Define the production requirement before seeing results.
- Input contract: representative prompt, system instruction, file type, image type, tool schema, and maximum expected context.
- Output contract: required JSON fields, citation format, code patch, tone, language, or decision structure.
- Quality threshold: facts that must be correct, forbidden hallucinations, and examples of an acceptable answer.
- Operational threshold: maximum median latency, tail latency, error rate, retries, and cost per successful task.
- Human-review rule: which failures are automatically rejected and which outputs require an operator.
- Test set: enough normal, difficult, ambiguous, and adversarial examples to expose failure modes rather than one showcase prompt.
Run a Five-Test Bake-Off
1. Golden-answer quality
Use a set of tasks with independently verified answers or review criteria. Score correctness at the field or requirement level. Do not reward fluency when the underlying answer is wrong.
2. Structured-output and tool reliability
Run the exact schema and tools used in production. Measure valid arguments, correct tool choice, unnecessary calls, recovery after tool errors, and whether the final answer reflects the tool result.
3. Long-input retention
Place answerable facts at the beginning, middle, and end of representative inputs. Test retrieval, instruction priority, and contradiction handling. A documented context capacity does not guarantee equal use of every token.
4. Latency and stability
Measure time to first token, completion time, timeout rate, retry rate, and high-percentile latency under realistic concurrency. Run more than once; a single fast response is not a service-level result.
5. Cost per successful task
Calculate the cost of all attempts required to produce one accepted result, including retries, tool loops, cached and uncached input, and rejected outputs. Exact token prices belong on Kimi API Pricing.
Score the Results With a Workload-Weighted Matrix
This sample matrix is an editorial evaluation framework from Kimi-AI.free, not an official Kimi benchmark. Change the weights before testing so that they reflect the product—not the model you expect to win.
| Dimension | Sample weight | How to measure |
|---|---|---|
| Task quality | 40% | Percentage of required facts, fields, or review criteria satisfied |
| Reliability | 25% | Valid format, correct tool use, low retry rate, and stable behavior |
| Latency | 15% | Median and tail latency against the product threshold |
| Cost efficiency | 15% | Cost per accepted task, including failed and retried attempts |
| Operational fit | 5% | Logging, parameter compatibility, fallback behavior, and maintainability |
Convert each dimension to a 0–100 score and calculate:
weighted_score = (quality * 0.40) + (reliability * 0.25) + (latency * 0.15) + (cost * 0.15) + (operations * 0.05)Keep the raw measurements beside the final score. Two models can have similar totals while failing for different reasons; the failure profile often matters more than a one-point ranking difference.
Route by Workload
| Workload | Primary evaluation priority | Required test |
|---|---|---|
| Customer-support drafting | Policy adherence, grounded facts, latency, and consistent tone | Hidden policy traps, missing account data, escalation cases, and structured handoff |
| Document extraction | Field accuracy, omission rate, layout robustness, and valid JSON | Scanned pages, repeated labels, missing fields, and conflicting values |
| Coding agent | Patch correctness, repository awareness, test success, and tool-loop efficiency | Real repositories, failing tests, multi-file edits, rollback, and incomplete specifications |
| Multimodal review | Correct use of visual evidence and refusal to invent unseen detail | Low-quality images, charts, text in images, and intentionally absent information |
| Interactive assistant | Time to first token, concise answers, and conversation consistency | Short turns, corrections, interruptions, and simultaneous users |
| Long analysis | Instruction retention, evidence tracking, reasoning quality, and cost per accepted report | Facts distributed across the input, conflicting sources, and required citations |
Keep the Selected Model Out of Application Code
A model identifier changes more easily when it lives in deployment configuration. Read it from an environment variable, feature flag, or controlled routing service.
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.ai/v1",
)
selected_model = os.environ["KIMI_DEFAULT_MODEL"]
response = client.chat.completions.create(
model=selected_model,
messages=[{"role": "user", "content": "Return only: routing check passed"}],
)The deployment secret or configuration should contain an identifier returned by the live Open Platform inventory. Keep a separate evaluation record explaining why that identifier was approved and which test-set revision it passed.
Define Default, Escalation, and Fallback Rules
- Default: the least expensive and fastest candidate that still passes every mandatory acceptance criterion.
- Escalation: a stronger or specialist route triggered by measurable conditions such as input type, repository task, context size, tool requirement, or low confidence—not by random retries.
- Fallback: a compatible route used for availability failures, supported error classes, or a circuit-breaker condition.
- No silent fallback: when a different route changes safety, context, tool support, output format, or cost, log the change and surface it to the controlling system.
- Human handoff: safety-critical, regulated, financial, legal, medical, or high-impact decisions should not be automatically “fixed” by trying more models until one answers.
Make the Integration Deprecation-Safe
- Call the Open Platform model-list endpoint during deployment validation and alert when the configured identifier is missing.
- Keep a tested replacement route rather than selecting an unknown model during an incident.
- Store evaluation date, dataset revision, parameters, provider, region, and model identifier with every approval.
- Repeat the acceptance tests after a model change, parameter change, prompt change, tool-schema change, or material platform update.
- Monitor production quality and cost; a model that passed a launch test can become unsuitable when the workload changes.
- Remove obsolete identifiers from configuration only after all jobs, queues, scheduled tasks, and rollback paths are checked.
If your application uses Kimi Code rather than the public Open Platform, perform the same validation against Kimi Code’s own model configuration. A Kimi Code alias can be upgraded in place—as happened when kimi-for-coding moved to K2.8 Preview—without becoming a new Open Platform model ID.
Parameters Are Part of Model Selection
Kimi model families can differ in supported inputs, reasoning controls, defaults, and parameter rules. A request that works for one candidate may be rejected or behave differently for another. Treat the full request configuration as part of the evaluated route.
Before approving a candidate, compare its current documentation with the official API overview and the model parameter reference linked there. Record every non-default parameter in the test report.
What This Page Intentionally Does Not Duplicate
| Question | Owner page |
|---|---|
| How do I create and secure the credential? | How to Get a Kimi API Key |
| How do I send my first complete request? | Kimi API Quickstart |
| What are the current token prices? | Kimi API Pricing |
| How do OpenAI-format clients connect? | Kimi OpenAI-Compatible API |
| What does a specific model do in depth? | Kimi Models |
| Which IDs belong to Kimi Code? | Kimi Code Model Configuration |
Frequently Asked Questions
Which Kimi API model should a new application use?
Fetch the live Open Platform inventory, choose candidates by workload role, and run the acceptance test. A general recommendation cannot replace your latency, cost, tool, context, and quality requirements.
Why does this guide not publish a permanent model-ID comparison table?
Identifiers, access, prices, and capabilities can change. A permanent table also overlaps the pricing and individual model pages. This guide provides a repeatable selection method and uses the official inventory endpoint as the live source for Open Platform deployments.
Is K2.8 Preview a public Kimi Open Platform API model?
K2.8 Preview is currently documented as a Kimi Code model served through the kimi-for-coding ID. Do not assume that ID belongs to the public Open Platform or insert it into api.moonshot.ai requests. For Open Platform applications, query GET /v1/models and use an identifier returned to your account. For Kimi Code, use the separate Kimi Code endpoint and model catalog.
Why can K2.7 Code appear in the public API while Kimi Code standard now uses K2.8 Preview?
They are different product catalogs. The public API still exposes K2.7 Code for direct API workloads, while Kimi Code upgraded its standard kimi-for-coding alias to K2.8 Preview. A change to one product route does not automatically rename or remove the other.
Is the newest or largest model always the best choice?
No. A higher-capability route can lose on latency, cost, format reliability, or operational fit. The best production route is the least costly candidate that passes every mandatory criterion with acceptable reliability.
Can I route every request to one model?
You can, but mixed workloads often benefit from an explicit default plus specialist or escalation routes. Add routing only when tests show a measurable gain; unnecessary routing creates complexity and harder debugging.
How often should model selection be retested?
Retest after any material change to the model, prompt, parameters, tools, input distribution, provider, region, or business requirement. Also schedule periodic production-quality checks.
Can the application automatically choose any available fallback?
Avoid untested fallbacks. A returned model may have different capabilities, formats, safety behavior, context, parameters, or pricing. Use only candidates that passed the same required tests.
Official Sources and Verification
- Kimi API Platform: List Models
- Kimi API Platform: Quickstart and current model documentation
- Kimi API Platform: API overview and parameter-reference links
- Kimi Code: Model Configuration
- Kimi Code: What’s New
Last verified: September 13, 2026. Open Platform model availability, identifiers, capabilities, parameters, access, prices, and rate limits can change. Kimi Code uses a separate model catalog that can also change independently. Query the correct live inventory or product documentation and rerun workload tests before a production change.
