Kimi K3 + Grok 4.5 Built the Same Database as Claude Opus 5 at 1/25th the Price

Kimi K3 + Grok 4.5 Built the Same Database as Claude Opus 5 at 1/25th the Price 图片 1
Kimi K3 + Grok 4.5 Built the Same Database as Claude Opus 5 at 1/25th the Price 图片 2
Kimi K3 + Grok 4.5 Built the Same Database as Claude Opus 5 at 1/25th the Price 图片 3
Kimi K3 + Grok 4.5 Built the Same Database as Claude Opus 5 at 1/25th the Price 图片 4

Moonshot AI published the full weights for Kimi K3 on July 27. It is the largest open-weight model ever released, inference providers started serving it within a day, and it has been available in Kilo since day one. We wanted to see how close a combo of Kimi K3 for planning and Grok 4.5 for implementation can get to Claude Opus 5 doing both jobs itself. We gave both setups the same two-phase job. Each one had to design an embedded database from a spec, then build it. We crash-tested both results with a harness we wrote before either model ran, and then we read both codebases.

TL;DR: Both setups passed 64 of the same 65 conformance checks, survived every crash-recovery test, and shipped the same single critical bug. Claude Opus 5 scored 98/100, the Kimi K3 + Grok 4.5 setup scored 93/100 and ran at 4% of the cost ($1.27 against $31.71).

Pricing

Per token, Kimi K3 costs 60% of Claude Opus 5, and Grok 4.5 costs 24% on output. This setup puts the open-weight model on planning, where the design decisions get made, and the more affordable model on implementation, where the decisions are already written down. Our earlier planning comparison found that frontier models implement a good plan almost interchangeably. This test asks whether that holds when neither model in the setup is a frontier flagship.

What We Asked Them to Build

We wrote a spec for kvd, an embedded key-value store in Go. It is a lighter version of something like Redis, with one binary and a small text protocol over TCP, except data is persisted to disk. We picked it because everything in the spec can be checked. Either the database loses data when you kill it, or it does not. The spec requires:

  • A single Go binary serving a Redis-style text protocol over TCP, with commands for reading, writing, deleting, batching, stats, and compaction
  • A durability rule: the server must not acknowledge a write until the data is flushed to disk, and every acknowledged write must survive kill -9 arriving at any moment
  • Atomic batches:…
添加评论
点赞收藏
点踩分享查看原文
评论
?
参与讨论