Field notes: which LLM drives the flow — and why Vibe-IC defaults to Claude

The news that made me stop and check

Today a widely shared report said Kimi K3 had "completed a chip design in 48 hours." Around the same window, Cadence and Synopsys shares fell about 9% — a market reaction, not a measured verdict on those tools. Let me be careful here: I have not verified the "48-hour" claim, and I am not endorsing it. And let me be honest about where I stand: I'd been building an AI-native, end-to-end IC-design flow of my own well before today's announcement, so this news wasn't my starting gun — it just put a question I already care about into the spotlight, and that's a good thing. How far can an AI-driven flow actually take a chip today? For a field that has quietly worked on this for years, having it move into daylight is genuinely welcome.

My honest position: I test what I actually use

I don't want to write from the sidelines, so I'll put my cards on the table: about three weeks ago — well before any of this IC-design news — I'd already added Kimi as a second LLM source, subscribed to Kimi Code, and pushed real work through it, not toy prompts. So this isn't a reaction to today's headline; it's what I'd been finding all along, running the work I do every day through more than one model. Today's announcement is just what prompted me to write it down.

One caveat I'll state once and mean: this is one person, one project, a few weeks — a snapshot, not a verdict, and a fair comparison next quarter could read differently. I will pin down three identities so nothing is fuzzy. On the Kimi side, my hands-on ran through Kimi Code, and the earlier benchmark figure below is against Kimi K3. On the Claude side, nearly all of the day-to-day work — the code, the flow — I did with Opus 4.8; Fable 5 I brought in only for the earlier benchmark. On the GPT side, the 2026-08-16 benchmark update is GPT-5.6-Sol through Codex with Vibe-IC plugin v1.10.45. Daily-use observations and benchmark datapoints are therefore separate claims.

What I found in daily use

Two things stood out.

Token economics. I didn't run a controlled token study, so take this as lived experience rather than a number: on comparable tasks, Kimi burned through my quota noticeably faster than Claude.

Output quality — on RTL, on prose, and on video. The most concrete example is this very blog. The first pass — about 15 articles drafted on Kimi — didn't clear my bar, so I had Claude rewrite the set, and that's the series you see now. That isn't "Kimi can't write"; it's that on my material, to my standard, Claude cleared a bar Kimi didn't — and the same held on the actual RTL work. Video too: for the tutorial videos I make, and the User Guide walkthroughs, Claude is markedly more consistent. I have tried Kimi on those a few times and always ended up switching back.

For something more objective than my own hands, there's the Vibe-IC Evaluation page — independent blind runs established by each benchmark's official scorer, with current attributable cells in the public benchmark-data repository. In that July campaign snapshot, on VerilogEval-v2, the Claude model I ran for RTL authoring — Fable 5 — scored 98.08% (153/156) against Kimi K3's 94.23% (147/156), a lead of about four points, single-shot. The two were near-parity on combinational and single-register problems; the gap opened on hard, multi-state FSM depth. That was useful evidence from those recorded runs, not a permanent model-only ranking across every model and plugin version.

But there is an update owed to Kimi here, and it overturns my original conclusion. Those numbers are single-shot (pass@1) — one attempt, no retry. I have since re-run it the way Vibe-IC actually works: program-first, failures closed back in a loop, still fully blind. Kimi K3 reaches 154/156 = 98.72% on VerilogEval-v2 — and every repair came from reasoning over the prompt, with no external sources consulted.

To be clear, that cannot be set against Claude’s 153/156 head-to-head — one is single-shot, the other multi-round; a fair comparison would give Claude the same round budget, and I have not run that. So the right reading is not “Kimi won” but this: in that recorded July flow, Kimi K3’s close-loop result showed that the single-shot gap could be repaired. It overturned the stronger conclusion I had originally drawn from two single-shot scores. GPT/Codex now adds a third datapoint whose plugin identity is pinned; I treat all three as run records rather than a universal ranking.

Evidence note: the scored artifacts from that historical re-run have not yet landed in the separate public benchmark-data repository; the previously shown path was not present after the repository split.

The July Kimi run remains a historical run record, but it does not bind the authoring model to one immutable Vibe-IC plugin version. It is therefore not presented as a canonical model + plugin cell in the current benchmark-data layout.

2026-08-16 update: GPT-5.6-Sol on Vibe-IC v1.10.45

I have now put a third authoring setup through the flow: GPT-5.6-Sol through Codex, paired with Vibe-IC plugin v1.10.45. The measured read-out was VerilogEval-v2: 153/156 single-shot; VerilogEval-Human: 153/156 single-shot, then 154/156 after one close-loop repair round; and RTLLM: 48/50 single-shot, then 49/50 after one close-loop repair round.

The boundary matters: the new GPT results are model-plus-plugin datapoints, not a model-only A/B test. The Claude reference has a pinned plugin identity; the archived Kimi run has recorded run context but no immutable plugin-version binding. I therefore cannot subtract these scores and assign the difference to the model alone. What I can say from my own runs is narrower and useful: GPT/Codex is now a practical selectable path, and one repair round recovered one additional case on both VerilogEval-Human and RTLLM. That is measured recovery, not a claim that either campaign fully converged.

Why the plugin defaults to Claude — yet stays model-pluggable

Vibe-IC is program-first, AI-backup: the deterministic programs do the heavy lifting, and the LLM only fills the stretches a program explicitly hands off. Because of that, any of several capable LLMs can drive the flow — the design isn't hostage to one vendor; you can select Claude, GPT/Codex, GLM, or Kimi.

So why still default to Claude? After these updates, I no longer turn the earlier Fable 5 datapoint into a universal single-shot ranking. I keep Claude as the default because it is the workflow I have personally built and repeated the most: Opus 4.8 did nearly all of Vibe-IC's day-to-day building, and in my hands Claude has been steadier across RTL, prose, tutorial videos, and User Guide walkthroughs, with more favorable token use than I experienced with Kimi. The benchmark record now supports several workable model-plus-plugin combinations, not one universal winner. Kimi has its archived close-loop result; GPT/Codex now has a v1.10.45 record across three benchmarks. The default is an operational preference, not a claim of model supremacy — users can choose GPT/Codex or Kimi today, and I can change the default without re-architecting the flow.

Two fair distinctions about Kimi

It's easy to turn a comparison into a hit piece; I don't intend to. Two distinctions, stated as principles, not as verdicts on work I can't see.

Announced is not the same as open-sourced. Kimi has announced results but, to my knowledge, has not open-sourced the flow behind them. That's a perfectly normal place for a company to be; I only note that an announcement and a reproducible artifact are different things.

A one-shot demo is not the same as a production flow. Any single, end-to-end demo — however polished — is a different object from a reproducible, benchmarked, fully-open flow, which is what Vibe-IC is trying to be. I'm stating the general distinction, not grading Kimi's specific result, which I haven't seen. The two are measured on different rulers, and I'd rather be precise than dismissive.

A word on the market reaction

The news moved some share prices. Reading that as "the EDA tools just got hurt" is too quick: sign-off still happens inside those tools, and lowering the barrier to design tends to bring more chips into existence that need signing off, not fewer — EDA and an AI-driven flow can co-prosper, not cancel out.

And the party actually affected may not be the EDA vendors at all. The sharper question is what an end-to-end, AI-driven flow does to the IC-design business itself — especially companies about to commit to an ASIC. Better or worse? That's for the market to read, not me — I'll report what I see and deliberately not forecast where it goes.

To be clear: this is not anti-commercial-EDA

One thing I never want this piece to imply. Commercial EDA — Cadence, Synopsys — remains the gold standard, full stop; Vibe-IC exists to coexist with it, not to beat it, and I don't read a market wobble as a verdict on those tools. The deeper version of that argument is in the open + commercial coexistence post. This piece is narrowly about LLMs — how the model-plus-plugin combinations I have actually run behave in this flow right now — and says nothing about the EDA tools themselves.

An open invitation — to every model

And this was never only about Kimi. Every LLM is welcome here — GPT/Codex, GLM, Kimi, and the ones not yet released. The welcome is concrete: if anyone's future work wants to reference or build on the Vibe-IC plugin or the forked EDA tools, the door is open, no reservations. And if some model ships something that runs ahead of what I've published so far, that's a good outcome, not a threat — mutual sharpening, not a zero-sum game. What I care about is that the end-to-end idea — a complete set of design documents becoming silicon with no hand-offs in between — becomes real in the industry and changes how chips actually get made. On that, everyone's working the same open problem.

A close, honestly

So these are field notes, not a verdict — one project, one pair of hands, a few weeks. The models will move; when they do, the honest thing is to move with them and say so here. I'd rather revise this next quarter than have overclaimed it today. And if I've read the evidence wrong, tell me — an open bench is exactly what that's for.

In the next post — the last in the series — I want to step back to the world all of this is pointed at: a complete set of design documents to silicon with no human hand-offs in the middle, and how, if you'd like to, we build it together.

Further reading: the RTL-authoring numbers on the Evaluation page, and why open and commercial are partners rather than rivals in Open + commercial coexistence.