Skip to main content

Kimi K3 is Moonshot AI's long-context agent model behind an OpenAI-compatible chat call. It reads 1,000,000 tokens, replies up to 1,048,576, with reasoning effort low, high or max, up to 128 tools and image input.

Input $2.70Output $13.50per 1 million tokens10% below the publisher's list priceCached input $0.30Moonshot AI official priceInput $3Output $15

Workbench

Kimi K3

What can Kimi K3 help with?

Related models and next tasks

Missing the model you need?

Tell us what to add and where you would use it. Requests go to the people who decide what gets onboarded next.

Build stable message flows for complex reasoning, coding, migrations, and constraint-heavy agents

K3 is the reasoning-oriented Kimi model in this catalog. Give it explicit state, dependencies, reversibility, and a definition of done; do not assume controls absent from its public schema.

Open the chat playground
Build stable message flows for complex reasoning, coding, migrations, and constraint-heavy agents
Model
Kimi K3
Good for
complex reasoning, coding, migrations, and constraint-heavy agents
Message shape
System rules → evidence and state → current task → output contract
Fact boundary
Capabilities, controls, and price come from the live schema

Integration principle

Validate with the smallest message set, then add necessary context. Separate facts, assumptions, and constraints, and design interruption, retry, settlement, and review paths.

Build repeatable workflows for complex reasoning, coding, migrations, and constraint-heavy agents

K3 is the reasoning-oriented Kimi model in this catalog. Give it explicit state, dependencies, reversibility, and a definition of done; do not assume controls absent from its public schema.

  • Constraint graph

    Treat dependencies as part of the answer

    Show prerequisites, assumptions, order, and what can be rolled back.

  • Reasoning effort

    Three dials, and no off switch

    temperature (0-2), top_p (0.01-1) and reasoning_effort (low to xhigh) are all exposed; what does not exist is a setting that turns reasoning off.

  • Execution safety

    Separate planning from authorization

    The product must pause for approval at real irreversible or external action boundaries.

Where Kimi K3 wins on task cost and interaction shape

Test one real task for quality, verifiability, latency, and sale-price fit instead of relying on a general leaderboard.

  1. Choose K3

    One missed dependency invalidates the plan

    Use it for migrations, architecture transitions, investigations, and stateful agents.

  2. Choose K2.6

    Work is frequent, bounded, and cost-sensitive

    Routine assistants, role play, and ordinary coding may not need a reasoning-oriented model.

  3. Compare peers

    Evaluate failure handling, not polish

    Compare dependency coverage, verification, rollback, latency, and commercial fit.

Turn Kimi K3 into concrete work, not generic labels

Every scenario needs input boundaries, verification, and recovery; official capabilities, benchmarks, and tool support are never invented.

  • Zero-downtime transition plans

    Migration

    Zero-downtime transition plans

    Model current state, target, dual run, compatibility, cutover, failure signals, and rollback.

  • Long tasks with resumable state

    Agents

    Long tasks with resumable state

    Define checkpoints, evidence, retry semantics, budgets, and approval boundaries.

  • Cross-repository planning

    Coding

    Cross-repository planning

    Map contracts, owners, release order, compatibility windows, tests, and observability.

  • Multi-stage root-cause analysis

    Investigation

    Multi-stage root-cause analysis

    Maintain hypotheses, tests, evidence, confidence, and next actions without premature certainty.

Organize context into an inspectable Kimi K3 input

Objective, evidence, state, constraints, and output contract need distinct jobs so requests can be compressed, debugged, and reproduced.

  1. State

    Describe current and target reality

    Include owners, dependencies, live traffic, data shape, and outcome.

  2. Constraints

    Mark invariants and irreversible actions

    Call out uptime, compatibility, security, budget, deadline, and approvals.

  3. Plan

    Use phases with entry and exit checks

    Each phase needs prerequisites, actions, evidence, failure signals, and rollback.

  4. Done

    Require verification after change

    Specify monitoring, acceptance tests, cleanup, documentation, and owner.

Prove a repeatable Kimi K3 case before product integration

Confirm live schema, quote, streaming, and error behavior before reusing the normalized request.

  1. 01 · Baseline

    Validate the smallest request in Playground

    Check message layers, output shape, streaming, and current controls.

  2. 02 · Boundaries

    Exercise failure, cancellation, and retry

    Verify timeouts, interrupted streams, oversized input, regeneration, and duplicate submission.

  3. 03 · Integrate

    Copy the normalized API request

    Use the public model id and messages contract; read model controls from the live schema.

  4. 04 · Operate

    Meter usage and keep evaluating

    Store state, final usage, failure reasons, and quality feedback; quote expensive calls first.

Bring Kimi K3 into a clear API contract

Playground, API examples, request states, and usage records stay aligned from evaluation through production integration.

  • Unified contract

    One shape for messages, streams, and errors

    Keep request structure, state handling, and error recovery consistent when changing models.

  • Live schema

    Use the current endpoint controls

    Playground and API examples expose available fields, limits, and default behavior together.

  • Observable lifecycle

    Every request has a clear state

    Submission, streaming, failure, cancellation, and usage use inspectable public semantics.

  • Portable integration

    Reduce work when models evolve

    A clear contract keeps product code focused on inputs, results, and user experience.

Kimi K3 API boundaries to confirm before integration