Kimi K3 vs Claude Opus 5: Open and Closed Frontier Models Compared for Production

Two frontier models launched within eight days of each other in July 2026, and they represent opposite answers to the same question. Kimi K3 arrived July 16 with 2.8 trillion parameters, a 1 million token context window, and open weights published on July 27 under a Modified MIT license. Claude Opus 5 arrived July 24 with a 1 million token context window, a five-level effort dial, zero data retention support, and no weights at all. Both are near the top of every benchmark leaderboard. The production decision between them is not primarily about which scores higher, because they score differently depending on the benchmark and the evaluation harness. It is about whether your deployment requires open weights, and what you are willing to pay for the alternative.

• Cost: Kimi K3 is 40 percent cheaper on both input and output. K3 lists $3.00 per million input tokens and $15.00 per million output. Opus 5 lists $5.00 input and $25.00 output. Both offer 90 percent cache-hit discounts: K3 at $0.30 per million, Opus 5 at $0.50 per million.
• Benchmark leadership depends on which benchmark and which harness. Opus 5 reports 96.0 percent on SWE-bench Verified and ranks #1 in the Agentic category on BenchLM's aggregate. K3 reports 76.8 percent on SWE-bench Verified, ranks #1 on Frontend Code Arena, and #4 Agentic. Harness differences alone can move coding scores by 10 to 26 points, which makes cross-model comparison from published numbers unreliable without controlled evaluation.
• Self-hosting is possible for K3 and impossible for Opus 5. K3's open weights allow deployment on GMI Cloud dedicated GPU clusters with full data isolation. The practical cost is real: 1.56 TB of MXFP4 weights and a Moonshot recommendation of 64 or more accelerators for production throughput.
• Data residency favors Opus 5 for teams that cannot self-host. Opus 5 supports zero data retention and is available through Amazon Bedrock, Google Vertex AI, and Microsoft Foundry, giving multiple compliant deployment paths. K3's official API routes through Moonshot AI's infrastructure under Chinese data law, which rules it out for HIPAA, GDPR, and government workloads unless the open weights are self-hosted or accessed through a US-hosted third party.
• Opus 5's five-level effort control is a cost lever K3 does not have. Setting effort to medium for routine work and escalating only high-value tasks changes the effective cost per request substantially. K3's reasoning_effort parameter currently exposes only the maximum level.
• Fine-tuning is available on K3 and not on Opus 5. For teams with proprietary domain data where a fine-tuned model materially outperforms prompting, this is a binary requirement rather than a preference.

The Models at a Glance

What the Benchmarks Actually Say

Both models are near the top of the leaderboards, and the specific ranking depends on which leaderboard you read and which harness produced the numbers.

Where Opus 5 leads.

Opus 5 reports 96.0 percent on SWE-bench Verified, 43.3 percent on Frontier-Bench (agentic coding), 30.2 percent on ARC-AGI-3 (roughly three times the next-best model), and 86.7 percent on Terminal-Bench 2.1. On BenchLM's aggregate across 64 published benchmark rows, Opus 5 scores 82.8 out of 100 and ranks #3 of 225 models, with Agentic as its strongest category at #1.

Where K3 leads.

K3 ranks #1 on Frontend Code Arena, achieves 66.7 percent on Terminal-Bench Hard (the highest among open-weight models), and 56.0 percent on Humanity's Last Exam with tools enabled. On BenchLM's aggregate, K3 scores 79.9 out of 100 and ranks #5 of 215 models, with #4 in the Agentic category.

Why the SWE-bench gap is not what it appears.

Opus 5's 96.0 percent versus K3's 76.8 percent on SWE-bench Verified looks like a decisive 19-point gap. It is not directly comparable, for a specific reason: different evaluation harnesses produce score differences of 10 to 26 points on the same model. Moonshot's own K3 benchmark table mixes results from Kimi Code, Claude Code, Codex, and mini-SWE-agent harnesses across comparison models. Anthropic's Opus 5 numbers come from Anthropic's harness.

The cleanest cross-model comparisons come from third parties that run all models on the same harness under the same conditions. GMI's own internal evaluation, which drives GMI Router's model selection across 12 benchmarks and 21 models, ranks Claude Opus 5 first and Kimi K3 second in its overall model leaderboard. BenchLM, using a different methodology across 64 rows, places Opus 5 at #3 and K3 at #5.

The consistent finding across methodologies: Opus 5 ranks higher on aggregate, K3 ranks close behind, and the gap is smaller than headline benchmark differences suggest. As covered in GMI Cloud's guide to choosing the right model for each prompt, task-specific benchmark performance predicts production quality more reliably than aggregate rankings, which makes the category-level breakdown more useful than the overall rank.

One nuance worth reading carefully.

On BenchLM's category breakdown, Opus 5's lowest eligible category is Coding at #5, while Agentic ranks #1. K3 leads Frontend Code Arena and ranks #4 Agentic. For teams whose workload is specifically frontend code generation rather than general agentic execution, the ranking that matters may favor K3 despite Opus 5's higher aggregate.

The Cost Comparison in Practice

Headline per-token rates understate the difference because both models offer additional cost controls.

Base rates. K3 at $3.00 input and $15.00 output is 40 percent cheaper than Opus 5 at $5.00 and $25.00.

With prompt caching. Both offer 90 percent cache-hit discounts. K3 cache hits cost $0.30 per million; Opus 5 cache hits cost $0.50 per million. For workloads with large stable prefixes, the effective input cost gap remains 40 percent in K3's favor.

With Opus 5's effort control. This is where the comparison shifts. Opus 5's five-level effort dial allows setting effort to medium for routine work and escalating to high or maximum only for tasks that need it. Because thinking tokens count toward output, reducing effort on routine requests reduces output token consumption substantially. A workload where 80 percent of requests run at medium effort and 20 percent at high effort has a materially lower effective output cost than the headline $25.00 rate suggests.

K3's reasoning_effort parameter currently exposes only the maximum level in V1, which means all requests pay the full thinking token cost. Additional levels are planned but not available.

With Opus 5's batch and fast modes. The Batch API offers a 50 percent discount for async workloads. Fast mode runs at approximately 2.5 times throughput for twice the base price ($10.00 input, $50.00 output), which for latency-sensitive workloads can be the correct tradeoff.

A worked comparison. For 10,000 daily requests at 4,000 input tokens (3,000 in a cacheable prefix, 85 percent hit rate) and 800 output tokens including thinking:

K3: cache-hit input 8,500 × (1,000 × $3.00/M + 3,000 × $0.30/M) = $16.15. Cache-miss input 1,500 × 4,000 × $3.00/M = $18.00. Output 10,000 × 800 × $15.00/M = $120.00. Total: $154.15/day.

Opus 5 at high effort: cache-hit input 8,500 × (1,000 × $5.00/M + 3,000 × $0.50/M) = $55.25. Cache-miss input 1,500 × 4,000 × $5.00/M = $30.00. Output 10,000 × 800 × $25.00/M = $200.00. Total: $285.25/day.

Opus 5 at medium effort with 400 output tokens instead of 800: output cost drops to $100.00, total $185.25/day.

The effort dial closes most of the cost gap for workloads that do not require maximum reasoning depth on every request.

Data Residency: The Decision That Overrides Everything Else

For regulated workloads, the data residency question determines the choice before cost or benchmarks enter the discussion.

Claude Opus 5's compliance posture.

Opus 5 supports zero data retention, which is a meaningful upgrade over Claude Fable 5's 30-day retention requirement. It is available through Amazon Bedrock, Google Vertex AI, and Microsoft Foundry in addition to Anthropic's own API, which means enterprise teams can consume it through cloud providers with whom they already have data processing agreements, BAAs, and regional deployment options.

For a healthcare organization with a signed BAA covering AWS, accessing Opus 5 through Amazon Bedrock brings the model within an existing compliance framework rather than requiring a new vendor assessment.

Kimi K3's compliance posture.

The official Kimi API routes traffic through Moonshot AI's infrastructure. Moonshot AI is a Chinese company, and the API is subject to Chinese data law including mandatory government access provisions under the Cybersecurity Law and Data Security Law. For workloads involving EU personal data under GDPR, protected health information under HIPAA, financial data under SOX, or any government and defense application, the official API is not viable.

The open weights resolve this. K3 deployed on US or EU infrastructure removes the Chinese jurisdiction exposure entirely. Three paths exist: US-hosted third-party managed APIs (OpenRouter, OrcaRouter, and others adding K3 as weights availability enables deployment), self-hosted on dedicated GPU clusters, or in-region deployment on a provider with the geographic footprint the compliance framework requires.

The practical asymmetry.

Opus 5 offers compliant deployment paths that require no infrastructure work: sign the agreement with AWS, Google, or Microsoft, and consume the model through an existing compliance framework. K3 offers a compliant path that requires either trusting a third-party host or operating a 64-plus accelerator cluster. For teams without existing GPU infrastructure, Opus 5's compliance story is significantly less work.

Self-Hosting K3: What It Actually Requires

The open weights are the reason to choose K3, and the hardware requirement is the reason most teams will not self-host it.

The numbers. The full MXFP4 weight file is 1.56 TB across 96 shards. Moonshot recommends supernode configurations of 64 or more accelerators for production deployment, driven by KV cache headroom for the 1M token context window and by Stable LatentMoE expert-parallel routing efficiency.

At GMI Cloud's H200 rate of $2.60 per hour, a 64-GPU cluster costs approximately $166 per hour, or roughly $120,000 per month at continuous operation. That cost is only justified by very high sustained token volume, or by a data governance requirement that no managed option satisfies.

The software requirement. K3 uses Kimi Delta Attention, a hybrid linear attention mechanism that enables the 1M context window. KDA's attention patterns differ from standard softmax attention, and conventional vLLM prefix caching does not work correctly with it. Moonshot contributed a KDA-compatible prefill caching implementation to the vLLM community alongside the weights. Teams self-hosting K3 must use this build; the standard vLLM release either produces incorrect attention outputs or forfeits prefix cache reuse entirely.

When self-hosting K3 makes sense. Three conditions, in combination rather than individually: a data governance requirement that no managed API satisfies, sustained token volume high enough to justify the cluster cost, and existing GPU infrastructure operations capability. Teams meeting all three should evaluate self-hosting. Teams meeting one or two should use a US-hosted managed endpoint.

When Opus 5 is the practical answer for compliance-constrained teams. If the requirement is compliant frontier-model access without operating GPU infrastructure, Opus 5 through Bedrock, Vertex, or Foundry is the shorter path. The cost premium over K3 is real, and it buys an infrastructure operations burden that does not exist.

Fine-Tuning: The Capability Gap That Cost Cannot Close

Opus 5 does not support fine-tuning. K3's open weights do.

For most production workloads, this does not matter: prompting and retrieval-augmented generation cover the customization requirement, and fine-tuning a 2.8 trillion parameter MoE model is impractical for most teams regardless of license.

For a specific set of workloads, it is decisive. Teams with substantial proprietary domain data (legal corpora, clinical documentation, specialized technical documentation, domain-specific code) where a fine-tuned model measurably outperforms prompting on the target task have a requirement that no amount of prompt engineering on a closed model satisfies.

The practical caveat: fine-tuning K3 at full scale requires the same cluster infrastructure as serving it, plus training compute. Most teams that want fine-tuning on open weights fine-tune a smaller model (Qwen3-32B, Llama 3.3 70B) rather than a 2.8T MoE, because the cost difference is two orders of magnitude and the quality difference on a narrow domain task is often small.

Vendor Concentration and Portability

Opus 5 concentrates dependency on Anthropic. Pricing, availability, deprecation timing, rate limits, and model behavior are all determined by one vendor. Anthropic's release cadence in 2026 was rapid: Opus 4.6 in February, Opus 4.7 seventy days later, Opus 4.8, then Fable 5, Mythos 5, and Sonnet 5 in June, then Opus 5 in July. That cadence delivers capability improvements quickly and also means production deployments face model version changes on the vendor's schedule.

The mitigation is multi-provider access: Opus 5 through Bedrock, Vertex, and Foundry provides redundancy against Anthropic API outages, though not against Anthropic's pricing or deprecation decisions.

K3's open weights provide portability. A team running K3 on self-hosted infrastructure controls the deployment lifecycle: no forced version migration, no pricing change, no deprecation timeline. The tradeoff is that the team also owns the operations.

For teams that prioritize eliminating single-vendor dependency, the open weights are the point, and the infrastructure cost is what it costs to have that property.

The Decision Framework

Choose Claude Opus 5 when:

• Compliance requires a documented data processing path and the team cannot operate GPU infrastructure. Bedrock, Vertex, and Foundry availability plus zero data retention provide compliant access without infrastructure work.
• The workload benefits from effort-level cost control. Setting medium effort for routine requests and escalating selectively is a meaningful cost lever that closes much of the per-token gap.
• Agentic execution quality is the primary requirement. Opus 5 ranks #1 Agentic on BenchLM's aggregate and leads on Frontier-Bench and Terminal-Bench 2.1.
• Operational simplicity is valued over cost minimization. One API, multiple cloud channels, no serving stack to maintain.

Choose Kimi K3 when:

• Data sovereignty requires that no third party process the data, and the team can operate the infrastructure. Open weights on self-hosted clusters are the only path that satisfies this.
• Fine-tuning on proprietary data is a requirement rather than a preference.
• Cost per token at high volume is the dominant constraint and effort-level control is not needed. K3's 40 percent lower base rates compound at scale.
• Vendor independence is a strategic requirement. Open weights eliminate the version migration and pricing dependency that closed models carry.
• The workload is specifically frontend code generation, where K3 leads Frontend Code Arena.

Run both when:

Most production teams at scale do not choose one. Routing between models based on task type captures each model's category strengths: agentic execution to Opus 5, frontend code generation to K3, and lower-complexity tasks to smaller models entirely. As covered in GMI Cloud's model routing guide, no single model leads across all task categories, which is the structural reason routing outperforms any fixed choice.

Deployment Paths on GMI Cloud

Both models are accessible through GMI Cloud, with different deployment characteristics.

Managed access through the model library. Both K3 and Opus 5 are available through GMI's unified OpenAI-compatible API alongside 170-plus other models. For teams evaluating both, this eliminates the need for separate provider integrations to run comparison tests.

Routing between them. GMI Router's internal leaderboard ranks Claude Opus 5 first and Kimi K3 second across its 12-benchmark evaluation. In Quality mode, routing selects the category leader for the detected task type, which for most workloads means Opus 5 on agentic tasks and K3 or another model where it leads. The Allowed Model Pool control restricts routing to organizationally approved models, so teams that have cleared only one of the two through security review can constrain the pool accordingly.

Self-hosted K3 on dedicated infrastructure. For teams with the data governance requirement and the volume to justify it, Prime Inference dedicated clusters provide H200 SXM at $2.60 per hour with NVLink 4.0 (900 GB/s per GPU) for the expert-parallel routing that Stable LatentMoE requires, plus region-pinned endpoints across APAC, North America, and Europe for data residency compliance.

Benchmarking both before committing. GMI Cloud's on-demand infrastructure provides hourly billing with no minimum commitment, which makes it practical to run the same evaluation set through both models under the same harness and compare results directly rather than relying on vendor-published benchmark numbers from different harnesses.

Conclusion

Kimi K3 and Claude Opus 5 are close enough in capability that the production decision rarely comes down to benchmark scores. Opus 5 ranks higher on aggregate across multiple independent methodologies. K3 ranks close behind and leads in specific categories. Harness differences of 10 to 26 points make vendor-published coding benchmark comparisons unreliable without controlled evaluation on your own tasks.

The decision comes down to three structural properties. Cost: K3 is 40 percent cheaper on base rates, though Opus 5's effort dial closes much of that gap for workloads that do not need maximum reasoning on every request. Compliance: Opus 5 offers compliant access through Bedrock, Vertex, and Foundry with zero data retention and no infrastructure work; K3's compliant path requires self-hosting a 64-plus accelerator cluster or trusting a third-party host. Portability: K3's open weights eliminate vendor dependency and enable fine-tuning; Opus 5 offers neither.

For most teams, the practical answer is not one model but routing between them based on task category, because neither leads everywhere and the category-level differences are where the actual production quality gains are.

FAQs

Which model is cheaper for production inference, Kimi K3 or Claude Opus 5? K3 is 40 percent cheaper on base rates: $3.00 per million input tokens and $15.00 output versus Opus 5's $5.00 and $25.00. Both offer 90 percent cache-hit discounts ($0.30/M for K3, $0.50/M for Opus 5). The gap narrows for workloads that can use Opus 5's five-level effort control: setting medium effort on routine requests reduces thinking token output substantially, and thinking tokens are billed as output. A workload running 80 percent of requests at medium effort has a materially lower effective cost than the headline rate suggests. K3's reasoning_effort parameter currently exposes only the maximum level.

Why is Opus 5's 96.0 percent SWE-bench score not directly comparable to K3's 76.8 percent? Different evaluation harnesses produce score differences of 10 to 26 points on the same model. Moonshot's K3 benchmark table mixes results from Kimi Code, Claude Code, Codex, and mini-SWE-agent harnesses across comparison models; Anthropic's numbers come from Anthropic's harness. Cross-model comparison requires running both models on the same harness under the same conditions. Independent aggregate rankings that do this consistently place Opus 5 ahead of K3 but by a smaller margin than the headline benchmark gap: BenchLM ranks Opus 5 #3 of 225 and K3 #5 of 215, and GMI's internal 12-benchmark evaluation ranks Opus 5 first and K3 second.

What does self-hosting Kimi K3 actually cost and require? The full MXFP4 weight file is 1.56 TB across 96 shards, and Moonshot recommends 64 or more accelerators for production throughput. At GMI Cloud's H200 rate of $2.60 per hour, a 64-GPU cluster costs approximately $166 per hour, or roughly $120,000 per month at continuous operation. Self-hosting also requires the KDA-compatible vLLM build that Moonshot contributed alongside the weights, because Kimi Delta Attention's patterns break conventional prefix caching. Self-hosting makes sense when three conditions hold together: a data governance requirement no managed API satisfies, sustained volume justifying the cluster cost, and existing GPU operations capability.

Which model is the right choice for HIPAA or GDPR-regulated workloads? Claude Opus 5 is the shorter path. It supports zero data retention and is available through Amazon Bedrock, Google Vertex AI, and Microsoft Foundry, which means teams can consume it under data processing agreements and BAAs they already have with those cloud providers. Kimi K3's official API routes through Moonshot AI's infrastructure under Chinese data law, which rules it out for HIPAA, GDPR, and government workloads. K3's open weights do resolve this if the model is self-hosted on US or EU infrastructure or accessed through a US-hosted third party, but that requires either operating a 64-plus accelerator cluster or vetting a third-party host.

Should production teams choose one model or route between both? Most teams at scale route rather than choose. Neither model leads across all task categories: Opus 5 ranks #1 Agentic on BenchLM's aggregate while its lowest eligible category is Coding at #5, and K3 leads Frontend Code Arena while ranking #4 Agentic. Routing each request to the category leader for its detected task type outperforms any fixed choice, which is the structural finding behind GMI's internal evaluation showing that Quality-mode routing produced higher quality at lower cost than always using a single frontier model. The Allowed Model Pool control lets teams that have cleared only one model through security review constrain routing accordingly.