Qwen 3.8 Max Benchmark: How It Compares With Kimi K3

Benchmark results compare Qwen 3.8 Max vs Kimi K3 across software architecture, tool use, latency, and token efficiency

Qwen3.8 Max Preview and Kimi K3 inspected 269 files in a matched StackPerf test, reached the same integration design, and finished three points apart after blind review.

The task went well beyond writing a short coding answer. Each model received frozen copies of two unfamiliar projects and had to decide how they should divide planning, storyboarding, video generation, regeneration, provenance, and final assembly. Every important claim needed an exact repository citation. The final report also needed a data contract, migration plan, tests, risks, and an evidence ledger.

Kimi scored 83 out of 100 after factual penalties. Qwen scored 80. The small gap says less than the shape of the two reports. Qwen defined a cleaner boundary between the systems and captured stronger replay metadata. Kimi handled revisions, regeneration, and scene history more completely. Their shared recommendation was stronger than either proposed contract on its own.

I covered Kimi’s specifications, pricing, independent evaluations, and open-weight plans in Kimi K3 Is Live: Pricing, Benchmarks, and the Wait for Open Source.

This comparison focuses on software intelligence: how each model explored real code, reasoned about ownership, and supported its answer with evidence.

What Qwen 3.8 Max Preview Is

Alibaba announced Qwen3.8 as a 2.4-trillion-parameter model and released qwen3.8-max-preview through Token Plan, Qoder, and QoderWork. Alibaba says the model will go open-weight soon and describes it as comparable with leading frontier systems, second only to Claude Fable 5.

That ranking remains a vendor claim. Alibaba has not published the benchmark names, scores, prompts, harnesses, or methodology behind it. As of July 19, there was no Qwen3.8 technical report, model card, Artificial Analysis entry, OpenRouter listing, Hugging Face checkpoint, ordinary per-token price, or announced weight-release date.

The missing architecture details matter for a 2.4T model. Alibaba has not disclosed the active parameter count, mixture-of-experts configuration, context limit, maximum output, training recipe, or serving requirements. Total parameters indicate checkpoint scale. Active parameters, caching, and provider execution determine most of the inference bill.

The hosted model is also a moving target. Alibaba’s Personal Token Plan documentation says the preview will receive continuous upgrades and will later be removed or replaced by a formal model. A test against qwen3.8-max-preview therefore needs a date, endpoint, harness, and reasoning configuration.

The live international endpoint supplied two useful facts beyond the launch post. Its model catalog returned the exact qwen3.8-max-preview ID, and a small image probe confirmed visual input with separate image, reasoning, and answer-token accounting. The software benchmark added sustained function-tool use and long-context repository analysis.

How We Benchmarked Qwen 3.8 Max and Kimi K3

The benchmark used two projects with overlapping responsibilities.

TTV Pipeline started as a text-to-video system for prompt decomposition, keyframes, short clip generation, fallback, and stitching. Media Tooling handles media inventory, analysis, editorial storyboards, edit decision lists, rendering, subtitles, and verification.

Longer video generators create an ownership problem. A provider that can generate 15 or 30 seconds at once changes shot boundaries and reduces the need to stitch several clips inside one scene. The systems still need to coordinate narrative intent, continuity, retries, alternate takes, final editing, and provenance. Both projects used the word storyboard, though they meant different things by it.

The task required each model to:

• map both systems with exact path:line evidence

• separate editorial planning from provider-specific shot planning

• analyze the effect of 15-second and 30-second generation

• compare three ownership models

• recommend one design and reject the alternatives

• define a typed or JSON contract

• trace the full data flow into concrete files and symbols

• provide migration phases, tests, risks, and unresolved questions

• finish with an evidence ledger

Each model received a read-only snapshot with identical SHA-256 hashes. The packet contained 269 files, including current tracked modifications and relevant untracked code. Generated media, caches, virtual environments, and repository internals were excluded.

Both sessions used OpenCode 1.17.13 with the same task card, permissions, 60-minute wall-clock limit, and 65,536-token completion ceiling. Read, search, listing, and safe inspection commands were available. Editing, web access, source-writing commands, plugins, and subagents were disabled.

Provider-native reasoning settings remained intact. Qwen ran with enable_thinking: true and no fixed thinking budget. Kimi ran with reasoning_effort: max and no separate thinking budget.

StackPerf registered both sessions, collected request and tool metrics, and exported the results for review. The final reports and tool ledgers were renamed Report A and Report B before scoring. A separate factual pass checked repository references and unsupported claims. The identities were revealed after both reviews were complete.

Qwen 3.8 Max vs. Kimi K3 Benchmark Results

Both sessions completed with visible reports and no provider errors, retries, or HTTP 429 responses. The infographic summarizes their quality, speed, token use, and execution behavior:

Kimi held a three-point lead after factual penalties and completed the task with lower latency and fewer tokens on its tested route. Qwen produced the longer report with fewer requests and tool calls, and every Qwen tool call succeeded. Both providers cached more than 90 percent of repeated prompt traffic.

These numbers measure two complete service paths. Qwen ran through Alibaba’s international Token Plan endpoint, while Kimi ran through the Kimi Code subscription endpoint. Route capacity, provider caching, API implementation, and launch-day traffic all contribute to latency and token behavior. One matched run cannot isolate the model from its serving route.

The prompt totals also require context. They sum the growing OpenCode conversation across every request. Neither model received a single 1.8-million-token prompt. High cache-hit rates covered most of the repeated agent history.

Both Models Reached the Same Core Decision

Qwen and Kimi independently found the same architectural boundary: one system should own global planning and final assembly, while the other handles provider-specific generation, retries, and provenance. Both connected those responsibilities through a versioned contract.

They also chose the same durable abstraction for longer video generation. The editorial scene remains stable while the generation layer decides whether to use one long take or several shorter clips. This convergence shows that both models could separate long-lived product responsibilities from changing provider constraints.

Where Qwen 3.8 Max Was Stronger

Qwen proposed two immutable directional documents.

GenerationManifest carries scene intent from Media Tooling to TTV. GenerationResult returns provider-bound plans, takes, capabilities, and provenance. Each document has one writer, which gives the transport and ownership model a clean direction.

Qwen’s replay record was also stronger. It included model, seed, prompt, references, provider request ID, generated media URI, duration, and cost. Those fields matter when a team needs to reproduce a take, investigate a provider change, or explain why one scene cost more than another.

Its tool behavior was efficient. Qwen needed 22 gateway requests and 44 tool calls to produce the longer report. None of its tool calls failed. The tool-use category in blind review gave Qwen 9 out of 10, compared with 8 for Kimi.

The report’s main weakness was lifecycle state. Its draft contract did not fully model scene order, revision, supersession, retry history, or take invalidation. It also placed selected_take_id in TTV’s result, even though both the broader recommendation and current Media Tooling design assign take selection to the editorial side.

Qwen supported the report with 354 repository citation occurrences. The verifier found no invented path or symbol. Two citations for one claim pointed to the wrong lines. Seven claim groups extended beyond what the code proved, including assumptions about later per-segment regeneration, billing units, per-take artifact URLs, and how an existing storyboard archive could be consumed.

Where Kimi K3 Was Stronger

Kimi modeled the editing lifecycle more completely. Its proposed scene manifest included revision, supersession, generation status, immutable takes, attempts, fallback history, artifact hashes, cost estimates, invalidation, editorial selection, and trim.

That structure fits partial regeneration. A failed or rejected take becomes part of the scene’s history. A new take can supersede it without losing the provider request, cost, prompt, or artifact record. Per-scene capability fields also allow one project to use different video providers without changing the editorial model.

Kimi scored one point higher on responsibility and ownership, two points higher on contract and data flow, and one point higher on long-clip and regeneration design. Those differences produced its three-point lead before and after penalties.

Its single shared manifest introduced a harder write-ownership problem. The report divided the document into editorial and generation subtrees, though it did not fully define revision authority, merge rules, or canonical storage. Its replay record also omitted the seed, exact model or profile version, and complete generation parameter snapshot that Qwen captured.

Kimi made 53 tool calls. Two compound shell commands were denied by the benchmark policy, and the model recovered with permitted read and search tools. Its report contained 274 repository citation occurrences, with no nonexistent paths or symbols. The verifier still found seven unsupported claim groups, including assumptions about idempotency, worker metadata, and transitions the current edit-decision-list renderer cannot execute.

Model Diversity Produced the Better Answer

The strongest recommendation combined both reports. Qwen defined the cleaner system boundary and stronger replay record. Kimi supplied the better treatment of revisions, regeneration, and scene history.

Combining those insights produced a stronger architecture than either model reached alone. This is a practical case for model diversity in high-value analysis: independent models can converge on the main decision while exposing different omissions in each other’s work.

The same approach can improve architecture reviews, migration plans, and other decisions where a plausible first answer may hide a weak assumption. Run more than one capable model against the same evidence, compare where their reasoning diverges, and verify the combined recommendation against the source material.

Qwen Pricing and Token Plan Economics

Alibaba has not published an ordinary per-million-token rate for Qwen3.8 Max Preview. Access currently runs through subscriptions and Credits.

Alibaba’s international Team Token Plan lists $30, $100, and $200 monthly seats. Credits depend on tokens, caching, thinking mode, and tool use. The Team FAQ limits access to interactive coding and agent tools. Its terms promise no training use and dedicated throughput, although the documented model allowlist had not yet caught up with the live Qwen3.8 endpoint when this test ran.

Kimi has a conventional API rate: $3 per million fresh input tokens and $15 per million output tokens, with cached input at $0.30. Its launch configuration always reasons at maximum effort. The Kimi K3 launch analysis covers the broader pricing and independent benchmark picture.

Qwen’s unpublished Credits conversion prevents a direct dollar comparison. On the tested routes, Kimi used fewer tokens and returned sooner, while Qwen used fewer requests and tools. Both providers cached more than 90 percent of repeated prompt traffic. Completed-task cost also depends on reasoning length, cache reuse, retries, tool discipline, rate limits, and factual review.

Open Weights, API Access, and Provider Availability

Qwen3.8 Max Preview is available now through Alibaba’s Token Plan endpoint. The international quickstart documents an OpenAI-compatible API for supported agent tools. Qoder and QoderWork provide Alibaba’s first-party coding and knowledge-work surfaces.

Alibaba says Qwen3.8 will go open-weight soon. The announcement does not establish whether the exact 2.4T Max checkpoint will be released, which license it will use, or when files will appear. The eventual model card should also settle active parameters, context length, quantization, and serving requirements.

Kimi K3 is already available through Moonshot, Kimi Code, and OpenRouter. Moonshot set July 27 for its full-weight release in an official company WeChat announcement. Its 2.8T architecture and recommended 64-accelerator deployment will make independent serving a substantial infrastructure project.

Open weights will improve the comparison in two ways. A versioned checkpoint makes model behavior reproducible. Independent providers create competing services with different throughput, caching, retention, reliability, and prices.

The Qwen result in this article belongs to the hosted preview served on July 19. A changed preview, formal API version, or released checkpoint deserves a new run.

What One Architecture Benchmark Can Tell Us

This experiment contains one full session per model and provider. It cannot establish a universal winner or separate every model characteristic from route behavior. It can answer narrower questions with useful evidence.

Qwen3.8 Max Preview handled sustained repository exploration, function tools, and a long architectural report without a failed tool or provider request. Its directional contract and replay record were the best parts of either report.

Kimi K3 completed the task sooner, used fewer tokens, and modeled scene revisions and regeneration more fully. Its slightly higher score came from contract completeness rather than a different architectural conclusion.

Both reports required factual correction. Neither invented repository paths or symbols, yet each produced seven groups of claims that outran the code. A model can cite hundreds of correct lines and still draw an unsafe conclusion from them. Repository evidence and claim verification need separate checks.

Qwen3.8 Max Preview and Kimi K3 finished three points apart and revealed different strengths. Qwen was sharper about system boundaries and used fewer tools. Kimi’s tested route was faster and more token-efficient, while its report handled lifecycle state more completely. Their agreement established the core design, and their disagreements exposed the assumptions that needed review. For high-stakes architecture work, model diversity can be an evaluation method: give capable models the same evidence, compare their blind spots, and verify the synthesis before implementation. Qwen3.8 Max and Kimi K3 emerge as complementary architecture models, with Qwen strongest at system boundaries and Kimi strongest at lifecycle reasoning.