DoorDash Kimi K2.6 Code Review: What the Numbers Mean for You

Yes, DoorDash really did put Kimi K2.6 into its AI code reviewer, but only as the cheap “scout” that flags suspicious code, while Anthropic’s Claude Fable 5 does the actual verification. On DoorDash’s own 105-case benchmark, that pairing caught 65.2% of severity-weighted real issues at $3.81 per pull request. The all-Anthropic setup it was compared against caught 53.6% at $3.91. That result got DoorDash a letter from two House committees.

This guide is current as of September 25, 2026. It covers what DoorDash published, what it left out, what the congressional letter asks for, what the case says about enterprises using Chinese open-weight models, and whether you should use K2.6 or Kimi K3 for code review now. The last section is a working setup you can copy.

The timeline: from engineering blog to Congress

Most coverage starts with the politics. The engineering story came first, and it began two months before anyone mentioned Kimi.

Date (2026)	What happened	Source
April	Moonshot releases Kimi K2.6 (1T params, 32B active, 256K context, Modified MIT license)	Hugging Face
May 11	DoorDash describes its in-house code review agent: 10,000+ PRs a week, 56 repos, ~$3 per review	DoorDash Engineering
June 12	Moonshot ships Kimi K2.7 Code, a coding-tuned follow-up to K2.6	MarkTechPost
July 6	DoorDash publishes DashBench results; Andy Fang posts that K2.6 now handles lower-level review work	DoorDash Engineering, Andy Fang on X
July 16 / 27	Kimi K3 launches; weights go public on the 27th	K3 open weights
July 22	White House OSTP Director Michael Kratsios alleges Moonshot distilled Anthropic’s Fable for K3; Moonshot denies it	TechCrunch
July 31	House Homeland Security and China Select Committee chairs send DoorDash a letter	Committee letter (PDF), CNBC
Aug 14 / Aug 21	Deadlines for documents and an in-person staff briefing	Committee letter
Sept 18	Kimi K3 goes generally available on Amazon Bedrock	AWS

As of today, neither DoorDash nor the committees have said publicly whether the documents were delivered, whether the briefing happened, or what came of it.

What DoorDash built: a scout, two reviewers, and a “disprove it” pass

The May post explains the model choice. DoorDash’s reviewer is on its third version. Version 1 used separate agents for security, tests, performance and so on, and missed architectural problems. Version 2 had two generalist reviewers read the whole diff, and they spread their attention too thin. Version 3 put a “lead scout” in front. The scout verifies nothing. It reads the diff and flags leads like “this deletion looks suspicious” or “this enum case isn’t handled in the sibling file.” Two deep reviewers then check each lead, and every finding has to survive a pass that tries to disprove it before anything gets posted.

The production numbers DoorDash reported in May:

• 10,000+ PRs reviewed per week across 56 onboarded repositories (Go, iOS, Android, web, infra, data pipelines)
• 60.2% of settled high/critical findings led the engineer to change code before merge (n=2,256), up from 46% with a previous third-party tool
• ~$3 per review on average, with findings posted ~7 minutes after the PR opens
• Reviews run on remote VMs with a full repo clone, so the agent can trace callers and sibling implementations instead of reading only the diff

The post calls the architecture “deliberately model-agnostic,” with cheaper models for simpler steps. That is the opening a cheap open-weight scout needed.

The DashBench numbers, in full

DashBench started from about 1,000 historical PRs and was narrowed to 105 that could be replayed and adjudicated. The set mixes PRs with real findings, clean PRs (to catch false positives) and PRs that were later reverted or hotfixed. Labels come from three sources: the original engineers’ annotations, candidate findings, and an LLM judge. Humans re-reviewed the cases where those disagreed. Severity is weighted (critical = 4, high = 2, medium = 1, low = 0.5).

Here is DoorDash’s full configuration table from the DashBench post:

Scout + reviewer	Real findings	W. precision	W. recall	W. F1	Cost / PR	Latency / PR
Kimi K2.6 + Claude Fable 5	537	89.2%	65.2%	75.3%	$3.81	589s
Sonnet 4.6 + Opus 4.8 (production)	504	87.0%	53.6%	66.3%	$3.91	725s
Kimi K2.6 + Opus 4.8	396	82.3%	45.8%	58.9%	$2.35	264s
Sonnet 5 + Sonnet 5	321	77.3%	40.1%	52.8%	$6.55	658s
Sonnet 5 + Opus 4.8	226	80.8%	32.9%	46.8%	$5.06	565s
GPT 5.5 medium + GPT 5.5 high	276	91.5%	19.9%	32.6%	$5.95	620s
Composer 2.5 + GPT 5.5 high	267	91.1%	19.6%	32.2%	$4.68	539s
Composer 2.5 + GPT 5.5 medium	246	92.2%	18.0%	30.1%	$3.53	429s
No scout, GPT 5.5 high	164	84.1%	30.7%	45.0%	$0.75	170s
No scout, Opus 4.8 high	115	89.8%	20.2%	33.0%	$0.65	113s

The severity split matters more than the headline. DoorDash’s union of real findings contains 40 critical, 136 high, 271 medium and 385 low clusters:

Recall by severity	K2.6 + Fable 5	Sonnet 4.6 + Opus 4.8	K2.6 + Opus 4.8	GPT 5.5 high (no scout)
Critical (40)	80.0%	62.5%	72.5%	37.5%
High (136)	77.9%	50.0%	46.3%	55.9%
Medium (271)	56.8%	53.5%	43.2%	20.3%
Low (385)	46.8%	51.4%	26.8%	4.2%

Put simply, the K2.6-scouted setup caught 32 of 40 critical issues. The production setup caught 25.

What the data proves, and what it doesn’t

The results are detailed and more transparent than most vendor benchmarks, but they support a narrower claim than the headlines.

The quality gain mostly comes from Fable 5, not K2.6. Keep the K2.6 scout and swap the reviewer to Opus 4.8, and weighted recall falls from 65.2% to 45.8%, below the all-Anthropic baseline. What K2.6 does show is that it can scout well enough for a strong reviewer to win, at a lower cost than Sonnet 4.6 in that seat. That still matters, but “a Chinese model beat Claude” is the wrong reading.

The cost saving is small at the top. $3.81 vs $3.91 per PR is 2.6%. The bigger difference is latency: 589 seconds vs 725. The cheaper option is K2.6 + Opus 4.8 at $2.35 and 264 seconds, which is also 40% cheaper than production, with lower recall.

It is one company’s codebase. 105 cases, weighted toward tests (86% of cases) and config/build changes (81%), with the consumer feed as the largest product area. DoorDash says itself that “no single configuration dominates,” and that LLM runs vary enough that single runs understate coverage.

Production status is unclear. The July 6 post still calls Sonnet 4.6 + Opus 4.8 the “production code reviewer.” Fang’s post says DashBench lets DoorDash “confidently introduce” open-weight models. The congressional letter treats the Kimi setup as deployed. DoorDash has not published traffic volume for it.

Hosting is undisclosed. Nothing public says whether DoorDash calls Moonshot’s API, a US inference provider, or self-hosted weights. The committees asked for exactly that.

Why K2.6 fits the scout job

A scout reads the whole diff plus surrounding context on every PR, and at 10,000+ PRs a week that is the biggest token bill in the pipeline. Its false alarms get dropped by the reviewer, so a scout can afford to be noisier as long as it doesn’t miss much. That is the case for cheap open weights. List prices per million tokens on Moonshot’s pricing page:

Model	Cache-hit input	Input	Output	Context
kimi-k2.6	$0.16	$0.95	$4.00	256K
kimi-k2.7-code	$0.19	$0.95	$4.00	256K
kimi-k2.7-code-highspeed	$0.38	$1.90	$8.00	256K
kimi-k3	$0.30	$3.00	$15.00	1M

On OpenRouter, K2.6 is served by about 20 providers, from $0.45 input / $1.90 output (fp4 quantized) up to Moonshot’s list price, per its live endpoint listing. Artificial Analysis measures K2.6 at 49.1 tokens/s with a 2.89s time to first token and a blended $0.70 per million tokens.

For a rough sense of scale, take an illustrative scout pass of 150K input tokens (60% cache hits) and 8K output tokens. These are our assumptions, not DoorDash figures. That works out to about $0.10 on K2.6 and $0.33 on K3 at list prices. Across 10,000 PRs a week, the gap is roughly $2,200 a week for one pipeline stage.

The letter: what Congress actually asked for

Quartz and some aggregators used the word “subpoena.” The letter is a request, signed by Chairmen Andrew Garbarino and John Moolenaar and addressed to CEO Tony Xu. It follows April 28 letters to Airbnb and Anysphere (Cursor’s maker) in the same investigation. It asks for seven things by August 14:

1. An inventory of every PRC-developed model evaluated or used since January 1, 2025, including version, quantization, hosting environment, whether it ran as a hosted service or self-deployed weights, and artifact hashes
2. DashBench methodology, test sets and results, including contamination and overfitting analysis
3. Security testing: artifact integrity, trigger-dependent behavior, insecure code generation, data exfiltration, prompt injection, tool misuse
4. Risk assessments and internal communications on selecting K2.6, including any re-evaluation after July 22
5. Monthly request volume, token volume and costs by business function, plus a replacement plan
6. AI model governance policies
7. When DoorDash learned of the distillation allegations and what it changed

The letter is more balanced than the coverage suggested. It says open weights running on infrastructure the company chooses “may mitigate certain data governance and vendor dependency risks.” It also says distillation allegations “would not, on its own, establish” that a model is compromised. Its concern is provenance, supply chain, and whether a company can swap the model out quickly. DoorDash’s reply to CNBC was that it “looks forward to engaging with the Committees” on using both American frontier models and open-weight models.

What this signals for enterprise use of Chinese open-weight models

Governance paperwork now matters as much as benchmark scores. DoorDash showed that a Chinese open-weight model can improve cost and quality in a real engineering workflow. The letter showed that saying so in public brings scrutiny. Both lessons apply to your team.

Three trends are visible as of late September:

• The hyperscaler gap has closed. In August we wrote that no US hyperscaler carried Kimi. That is out of date. Microsoft Foundry has offered Kimi K2.7 Code since July 1 ($0.95 / $4.00 / $0.19 cached), and K3 through Fireworks since late July, per TechNode. Amazon Bedrock made K3 generally available on September 18 at $3 / $15 (global) or $3.30 / $16.50 (US-only routing). For many compliance teams, that makes Kimi an approved vendor inside an existing cloud contract.
• Mixing models is now normal practice. Nobody serious is running only K2.6. The pattern is cheap open weights for volume and a frontier model for judgment, with your own benchmark deciding the split.
• You need an exit plan. The letter’s fifth request, a plan to replace the model if access is restricted, is the one to copy. A model-agnostic pipeline like DoorDash’s makes swapping a config change instead of a rewrite.

Caveat: politics moves faster than benchmarks. Treasury has floated sanctions over the distillation claims, which remain unproven in public. If you sell to the US government or work in a regulated industry, get legal sign-off before production.

K2.6 vs K3 for code review today

	Kimi K2.6	Kimi K2.7 Code	Kimi K3
Size	1T total / 32B active	1T / 32B active	2.8T / 104B active
Context	256K	256K	1M
API price (in / out)	$0.95 / $4.00	$0.95 / $4.00	$3.00 / $15.00
Speed (Artificial Analysis)	49.1 tok/s, 2.89s TTFT	n/a	35.2 tok/s, 3.81s TTFT
AA Intelligence Index	27	n/a	44 (#3 of 114)
Kimi Code Bench v2 (Moonshot)	50.9	62.0	72.9
MLS-Bench-Lite (Moonshot)	26.7	35.1	48.3
License	Modified MIT	Modified MIT	Kimi K3 License
Hyperscaler	Third-party providers	Microsoft Foundry	Bedrock, Foundry (via Fireworks)
Tested by DoorDash	Yes (scout)	No	No

K2.6/K2.7 scores come from Moonshot’s June comparison table; K3’s from its July model card. The frontier-model columns in those two tables don’t always match, so treat cross-table gaps as directional. On Moonshot’s own numbers, K3 (72.9) sits between Claude Opus 4.8 (71.7) and Claude Fable 5 (76.9) on Kimi Code Bench 2.0.

Which should you pick?

• Scout / first-pass triage: K2.6 or K2.7 Code. This is the only role with public, third-party-published evidence (DoorDash’s). K2.7 Code claims 30% fewer reasoning tokens than K2.6 at the same price, but its thinking mode can’t be switched off. Benchmark both on your own PRs.
• Verifying reviewer, open-weight only: K3. It is the only Kimi model near frontier level on coding benchmarks, and 1M context lets it read a large diff plus its dependents in one call. Cache heavily; code review re-reads the same files constantly.
• Maximum recall, budget allows: DoorDash’s actual winner, a cheap scout plus a frontier reviewer. See our K3 vs Claude Fable 5 comparison if you’re weighing K3 for the reviewer seat.
• Solo developer or small team: one K3 pass per PR is simpler than a two-stage pipeline and costs cents at small volume. Staging pays off once you’re reviewing hundreds of PRs a week.
• Regulated enterprise: use Bedrock, Foundry, a US zero-retention provider (see our provider guide) or self-hosting, and document the decision. Assume someone will eventually ask for it.

How to set up an AI code review pipeline with Kimi

A minimal version of DoorDash’s design, using Moonshot’s OpenAI-compatible API (https://api.moonshot.ai/v1):

1. Trigger on pull_request in CI and fetch the diff plus the full files it touches.
2. Scout with kimi-k2.6: ask for a JSON list of leads (file, line, suspicion, severity guess). Tell it not to verify anything.
3. Review with kimi-k3 or a frontier model: one call per lead or batch, with repo context, asking it to confirm or reject each lead with evidence.
4. Disprove pass: a final call that tries to falsify every confirmed finding. Drop anything that doesn’t hold up.
5. Post only findings anchored to a changed line, with a concrete fix direction.

from openai import OpenAI
client = OpenAI(api_key=KIMI_KEY, base_url="https://api.moonshot.ai/v1")

leads = client.chat.completions.create(
    model="kimi-k2.6",
    messages=[{"role": "system", "content": SCOUT_PROMPT},
              {"role": "user", "content": diff_and_context}],
).choices[0].message.content

verdicts = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "system", "content": REVIEWER_PROMPT},
              {"role": "user", "content": leads + "\n\n" + diff_and_context}],
).choices[0].message.content

Lessons DoorDash paid for, so you don’t have to:

• Use per-agent soft and hard timeouts, not just a turn limit. DoorDash saw a stuck agent burn 20 minutes of tokens without advancing the turn counter.
• Track cost per successful review, not per token. Weaker models sometimes produced invalid JSON and retried until they cost more than a stronger model.
• Write review profiles, not a pasted AGENTS.md. Pull review-relevant rules from past PR comments and incidents, and drop anything CI already catches.
• Build a small eval set from real misses before changing models. It beats any public leaderboard for your codebase.

If you would rather not build this yourself, community GitHub Actions such as Kimi Code Review cover the single-pass version, and Kimi Code handles interactive reviews from the terminal.

FAQ

Does DoorDash use Kimi K2.6 for code review? DoorDash has said it does, in a limited role. Co-founder Andy Fang posted on July 6, 2026 that the company’s AI code reviewer hands lower-level work to Kimi K2.6 and the hardest work to Anthropic’s Claude Fable 5. DoorDash’s engineering blog the same day published benchmark results for that pairing. It has not published how K2.6 is hosted or how much traffic it handles.

How well did Kimi K2.6 perform in DoorDash’s benchmark? On DashBench, DoorDash’s 105-case benchmark built from its own past pull requests, the Kimi K2.6 scout plus Claude Fable 5 reviewer found 537 real issues with 65.2% weighted recall, 89.2% weighted precision and 75.3% weighted F1, at $3.81 per PR. The Claude Sonnet 4.6 plus Opus 4.8 production setup scored 53.6% recall at $3.91 per PR.

Did Kimi K2.6 beat Claude on its own? No. K2.6 only acted as the scout that flags suspicious code. The heavy verification was done by Claude Fable 5. When DoorDash paired the same K2.6 scout with Claude Opus 4.8 instead, weighted recall fell to 45.8%, below the all-Anthropic production setup, though cost dropped to $2.35 per PR.

Why is Congress investigating DoorDash over Kimi? On July 31, 2026 the House Homeland Security Committee and the House Select Committee on the CCP sent DoorDash CEO Tony Xu a letter requesting an inventory of Chinese-developed models, hosting details, security testing records, DashBench methodology and cost data by August 14, plus a staff briefing by August 21. It is a request for information, not a subpoena or a ban. No outcome had been made public as of September 25, 2026.

Should I use Kimi K2.6 or Kimi K3 for code review? Use K2.6 (or the newer K2.7 Code) for the high-volume scout or first-pass step, where price and speed matter most: $0.95 input and $4 output per million tokens on Moonshot’s API. Use K3 ($3 input, $15 output) as the verifying reviewer if you want an open-weight model in that seat, or for very large diffs that need its 1M-token context.

Is Kimi K2.6 being deprecated? Not on Moonshot’s platform as of September 25, 2026. The kimi-k2.6 model ID is still listed as active, while kimi-k2.5 and the moonshot-v1 series were discontinued on August 31, 2026. Artificial Analysis marks K2.6 as superseded by K3 in its tracking, so budget for a migration eventually.

Can I run a Kimi-based code reviewer without sending code to China? Yes. The weights are open, so you can self-host, or use a US or EU provider. Kimi K3 is on Amazon Bedrock since September 18, 2026, and on Microsoft Foundry through Fireworks AI. Kimi K2.7 Code is in Microsoft Foundry’s catalog, and K2.6 is served by roughly 20 third-party providers on OpenRouter. Check each provider’s region and retention terms in writing.

The bottom line

DoorDash didn’t show that a Chinese model beats Claude. It showed that a cheap open-weight scout plus a strong reviewer beats an expensive all-in-one setup, and that you only find this out with your own benchmark. K2.6 earned its place in the cheap, high-volume seat. Fable 5 did the hard part. Congress then made model provenance something your company needs to document.

For your own pipeline, use K2.6 or K2.7 Code to scout, K3 or a frontier model to verify, host it wherever your compliance team can sign off (now including Bedrock and Foundry), and write down why. For the generational differences, read Kimi K3 vs Kimi K2. For the licensing that changes between K2.6 and K3, see the Kimi K3 license breakdown.