Access Moonshot AI Kimi K3—also searched as Moonshot K3— through EvoLink's unified chat API. Test long-context coding, tool use, structured output before integrating.
Moonshot AI·Text Generation·Available
From $2.850 / 1M input tokens$3.000 official price-5%
Production routeThis rate reflects platform-side availability — only confirmed server errors (HTTP 500 / empty response) count as failures. User-side issues (content moderation, invalid params, cancellation) plus rate limits, timeouts and auth errors are excluded. Before real traffic arrives, empty buckets may display as available.Live
A premium reasoning route for visual front-end prototyping, repository-scale coding, large evidence sets, long-running agents, and complex knowledge work that benefits from a 1.05M-token working context.
Kimi K3
Moonshot flagship reasoning model
Selected
Model ID
kimi-k3
Best for
Screenshot-to-UI and interactive prototypes, repository-wide engineering, multi-document synthesis, tool-heavy agents, and difficult tasks where fewer retries or less human correction can justify a premium route.
Input
$2.850 / 1M-5%
193.8 cr / 1M$3.000official price
Cache read
$0.286 / 1M-5%
19.4 cr / 1M$0.300official price
Output
$14.250 / 1M-5%
969 cr / 1M$15.000official price
All rates are per 1M tokens, shown in USD and credits, and reflect your account's current pricing.
Kimi K3 pricing
Estimate what one Kimi K3 request costs before you integrate. The calculator uses your account's current rates, with official pricing as a reference.
Request calculator
Enter the token mix for one request and the number of successful tool calls.
Only successful server-side calls are billed per call; failed attempts have no tool fee, but tokens still apply.
Web search$0.0050/ call·0.34 cr / call
Kimi K3 API for long-context coding and agent workflows
Access Moonshot’s 2.8-trillion-parameter flagship through EvoLink’s unified API. Kimi K3 combines visual understanding, front-end prototyping, a 1,048,576-token context window, prompt caching, always-on reasoning, structured output, and tool use for repository-scale engineering and complex knowledge work.
Kimi K3 is served on EvoLink under the model ID kimi-k3 through Chat Completions · Responses · Anthropic Messages, with the same API key and balance you use for every other model. It offers a 1.05M context window and up to 1.05M output tokens, plus long-context coding, tool use, structured output.
Kimi K3 specs and capabilities
Numbers come from the EvoLink route configuration; capabilities are what the API exposes today.
Context window
1.05M tokens
Max output
1.05M tokens
Input
Text + images
Output
Text · JSON (structured output) · tool calls
Reasoning
Always-on reasoning
Tool use
Function calling with multi-step tool sequences
Prompt caching
Automatic cache reads at a lower rate
Server-side tools
Web search, billed per successful call
Protocols
Chat Completions · Responses · Anthropic Messages
Model ID
kimi-k3
Parameters
2.8T
Why Kimi K3 can handle these workloads
K3 is most useful when long context, sustained reasoning, and reusable prompt prefixes work together. Context capacity alone does not improve an answer; the workload still needs relevant evidence, clear structure, and an output budget.
A 1M-token workspace, not a target to fill
The 1,048,576-token window can keep related code, specifications, and prior tool results available without excessive chunking. Retrieval and context compaction still matter because irrelevant input competes for attention and increases processing cost.
Sustained reasoning needs an output budget
K3 fits work that requires extended analysis, planning, and execution across multiple steps. Reasoning and final-answer tokens both contribute to usage, so treat the 1,048,576-token default output limit as capacity rather than a normal completion size.
Prompt caching pays off when prefixes stay stable
Repository instructions, system prompts, reference material, and tool schemas create the strongest cache opportunity when their ordering remains consistent. Frequent model or prompt-structure changes can force the long prefix to be processed again.
Where Kimi K3 earns a place in a production model stack
Kimi K3 should not become the default route simply because it is the newest model. Its strongest fit is work where long context, sustained reasoning, or complex tool sequences can reduce retries, handoffs, and human correction.
Kimi K3 for repository-scale coding
Use K3 when an engineering task depends on architecture documents, related services, test history, large diffs, and constraints spread across many files. Measure accepted patches and review time rather than isolated code-generation quality.
Kimi K3 for long-document analysis
Keep connected specifications, research papers, contracts, logs, or knowledge-base evidence in one working context. Retrieval and document structure still matter: a 1M-token window does not make irrelevant context useful.
Kimi K3 for tool-calling agents
K3 fits workflows with multi-step tool selection, structured outputs, code execution, or repeated external actions. Preserve complete assistant messages, reasoning content, tool-call IDs, arguments, and tool results across turns.
When a lighter model is the better route
Short chat, classification, rewriting, simple extraction, and latency-sensitive UI actions rarely need maximum reasoning or a 1M-token context. Keep these requests on a cheaper route and escalate only when task difficulty justifies K3.
What early Kimi K3 tests suggest—and what still needs proof
Launch-week community tests are useful for choosing evaluation workloads, not for declaring a universal winner. Treat the strongest demos and the sharpest complaints as hypotheses to verify on the same tasks, tools, budgets, and acceptance criteria.
The clearest early signal is visual front-end work
Early users repeatedly highlight screenshot-to-UI reconstruction, polished web prototypes, interactive pages, small games, and animation. Test Kimi K3 with your design system, responsive breakpoints, accessibility checks, and framework conventions before turning a strong demo into a production assumption.
General coding quality is not settled by front-end demos
A visually convincing page does not prove reliable backend changes, repository-wide refactors, tool execution, or multi-hour agent stability. Evaluate real issues, tests, multi-file diffs, tool failures, and accepted patches instead of extrapolating from one generated interface.
Latency and token efficiency can change the price decision
Some early reports describe long reasoning before useful output. Measure time to first usable result, total wall-clock time, reasoning and output tokens, retries, and human correction so the Kimi K3 API is judged by completed-task economics rather than list price alone.
Open weights make self-hosting possible—not lightweight
Moonshot has released the roughly 1.56 TB Kimi K3 repository under its custom license. The 2.8-trillion-parameter footprint and official 64+ accelerator recommendation still require serious storage, parallelism, throughput, and operations planning.
Two ways to use Kimi K3: EvoLink API or Agent
Use the EvoLink API for product backends and batch jobs, or call Kimi K3 from Codex, Claude, or Gemini for coding and analysis workflows. Both paths share the same EvoLink API key, balance, model ID, and request history.
Option 1
Integrate with the EvoLink API
Best for: product backends, batch jobs, automated pipelines
Send OpenAI-compatible Chat Completions (or Anthropic Messages) requests to EvoLink and control the model ID, system prompt, output budget, tools, and structured output.
1Create an EvoLink API key in the console
2Point your OpenAI or Anthropic SDK at the EvoLink base URL and select the model ID shown above
3Send one representative request and read the usage field for input, cached, and output tokens
4Set max_tokens and retries per task; keep tool-call IDs and results across turns
Best for: coding, review, and analysis tasks in Codex, Claude, and Gemini
Give the Agent the task, the inputs to include, and the acceptance criteria. It assembles the request, calls Kimi K3 through EvoLink, and returns the answer with token usage.
1Set EVOLINK_API_KEY in your local environment; never put it in code or a prompt
2Describe the task, the inputs to include, and the expected output format
3Ask the Agent to call Kimi K3 through EvoLink and show the request before sending
4Let the Agent report the answer, token usage, and any error body
Kimi K3 API code example and error handling
This example shows the shortest runnable request: an OpenAI-compatible Chat Completions call with a system prompt, a user message, and an output budget. Open the API tab for the complete parameter and response reference.
curl -X POST https://api.evolink.ai/v1/chat/completions \
-H "Authorization: Bearer $EVOLINK_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "kimi-k3",
"messages": [
{ "role": "system", "content": "You are a senior engineer reviewing a pull request." },
{ "role": "user", "content": "Review this diff and list every risky change with file and line:\n<diff>" }
],
"max_tokens": 2048,
"temperature": 0.2
}'
# The response includes choices[0].message and a usage object
# (prompt_tokens, completion_tokens, and cached tokens when a prefix is
# reused).
Invalid request or unsupported parameter
Check the model ID, the messages array, and parameter ranges against the API reference; remove fields this route does not support.
Authentication or balance issue
Check the Authorization bearer token and confirm the available balance in the console.
Context length exceeded
Prompt tokens exceed the Kimi K3 context window. Trim or retrieve only the relevant evidence and reuse cached prefixes.
Rate limited (429)
Back off and retry with jitter; batch or queue requests instead of sending parallel bursts.
Content or tool call rejected
Review sensitive content, malformed tool-call arguments, and JSON schema mismatches before retrying.
What to verify before routing production traffic to Kimi K3
A suitable workload can still fail because the integration uses the wrong identifier, assumes the wrong product limit, or drops agent state between turns. Verify the request surface and conversation contract before evaluating model quality.
01
Use the API model ID, not a Kimi Code alias
Use kimi-k3 on the EvoLink API route for both Chat Completions and Anthropic Messages.
Model ID
02
Confirm which product surface owns the context limit
EvoLink records a 1,048,576-token model context. Some coding clients or Kimi membership plans may expose a smaller default, so confirm the actual route and client configuration instead of assuming every K3 surface behaves identically.
Context
03
Replay complete assistant and tool state
Multi-turn agents should retain complete assistant messages, reasoning content, tool-call IDs, arguments, and tool results. Keeping only the final text breaks state continuity and can make later steps fail even when the context window is large enough.
Tool state
04
Start a clean session after material route changes
Changing the model or a major reasoning configuration can invalidate reusable context and prior assumptions. Start a new session after a material route change, then remeasure cache hits, completion length, and tool behavior.
Session
Prompt caching for repeated long context
Automatic cache reads use a dedicated lower rate when stable repository instructions, reference documents, and tool schemas can be reused.
1.05M-token context with a 131K default output limit
Keep connected code, specifications, documents, and agent state in one working context. Treat the limit as capacity rather than a target: retrieve relevant evidence and set task-appropriate output budgets.
Compare Kimi K3 cost per accepted task, not token price alone
Kimi K3 earns a premium route only when it reduces chunking, retries, failed tool sequences, or human rework on the same production workload. Evaluate identical task sets instead of comparing isolated prompt prices.
First-pass successAccepted deliverable rateRetry countOutput tokensCache-hit rateValid tool callsTime to accepted resultHuman correction and fallback rate
If K3 produces usable results with fewer retries and less review effort, a higher token rate can still reduce total task cost. If those gains do not appear, keep the workload on a lighter route.
Compare Kimi K3 with leading long-context models after workload testing
EvoLink
First verify whether Kimi K3 reduces retries and review effort on your tasks. Then compare price, context, caching, and workload fit to choose the production route.
Screenshot-to-UI and interactive prototypes, repository-wide engineering, multi-document synthesis, tool-heavy agents, and difficult tasks where fewer retries or less human correction can justify a premium route.
Premium baseline for long-running coding agents, complex review, and judgment-heavy professional workflows.
Long-context multimodal route for document-heavy work, visual evidence, and cross-provider fallback testing.
Kimi K3
Input / output$2.85 / $14.25
Context1.05M
CachingAutomatic cache reads
Best forScreenshot-to-UI and interactive prototypes, repository-wide engineering, multi-document synthesis, tool-heavy agents, and difficult tasks where fewer retries or less human correction can justify a premium route.
Yes. Kimi K3 is available as a production model with live backend pricing and official fallback rates.
What model ID should I use for the Kimi K3 API?
Use kimi-k3 for both Chat Completions and Anthropic Messages.
Can I keep using the OpenAI SDK or Anthropic Messages?
Yes. Use the same EvoLink API key with compatible Chat Completions or Anthropic Messages requests and select kimi-k3.
Does the Kimi K3 API support 1M context or only 256K?
The EvoLink route records 1,048,576 tokens. The 256K figure generally comes from a particular Kimi Code plan or client configuration.
How should I use the Kimi K3 1M-token context window?
Keep related code, documents, and tool results together, but use retrieval, stable cached prefixes, and context compaction instead of filling the window by default.
Is Kimi K3 good for front-end development and visual coding?
Early community tests are promising for screenshot-to-UI reconstruction, web prototypes, animation, small games, and visual interaction. Validate the advantage with your own components, responsive rules, accessibility checks, and code-quality standards.
Is the Kimi K3 API fast and token-efficient?
There is not yet a stable independent answer. Some launch-week reports describe long reasoning before useful output, so measure time to usable result, total tokens, retries, and accepted-task rate on representative workloads.
Why can Kimi K3 usage increase after switching models?
A material model or configuration change can invalidate reusable context. Start a clean session and remeasure cache-hit tokens and completion length.
How should I set the Kimi K3 output budget?
Limit output according to task complexity and monitor both reasoning and final-answer tokens. The 1,048,576-token limit is capacity, not a routine target.
Is Kimi K3 a good default for real-time or high-volume requests?
Test latency and cost first. Short chat, classification, rewriting, and lightweight extraction usually belong on a smaller route.
How should I compare Kimi K3 with GPT, Claude, GLM, or DeepSeek?
Evaluate K3 for long-context and complex-agent gains, GPT and Claude as frontier capability baselines, and GLM or DeepSeek as cost-sensitive baselines.
What should a production Kimi K3 evaluation measure?
Track first-pass success, accepted deliverables, retries, output tokens, cache hits, valid tool calls, time to accepted result, human correction, and fallback rate.
