OpenAI Used Its Own LLMs to Design the Jalapeño Chip, RTL to Tapeout in Nine Months

TL;DR

OpenAI used its own models to design Jalapeño, the inference ASIC it co-developed with Broadcom, and IEEE Spectrum now has the timeline: architecture concept in October 2024, RTL to tapeout in nine months, first silicon back from the foundry in May 2026. The hardware team averaged fewer than 100 people, Broadcom staff not included.

The method matters more than the schedule. OpenAI did not point a chatbot at Verilog. It routed the front end through XLS, Google's open-source high-level synthesis toolchain, so designers wrote Rust-like DSLX and C++ and let the tool emit the hardware description. Two AI-guided results carry hard numbers from Hot Chips 2026: a DeepSeek multi-head latent attention kernel climbed from 0.31% to 88.94% of theoretical peak in roughly 40 hours, and the matrix multiplication units came out 10% smaller than an optimized human baseline.

If you were hoping the takeaway is "Codex can tape out your accelerator," OpenAI's own VP of hardware would like a word.

What was actually disclosed

Jalapeño itself is not new. OpenAI and Broadcom unveiled it on August 25 at Hot Chips 2026, with Richard Ho, Ravi Narayanaswami and Chris Leary presenting. What landed this week is the design-process account, built on interviews with that team, and it is the part a builder can learn from.

The schedule is the headline claim. Architecture work started in October 2024. RTL freeze to tapeout took about nine months. Concept to functional silicon took under 20 months, with the first chips arriving from the foundry in May 2026 and running Codex shortly after. For a from-scratch frontier inference accelerator, that is fast, and the team that did it stayed under 100 people the whole way.

The trick: make silicon look like software

Here is the design decision everything else hangs on. Models are good at code. They are much less good at Verilog, which describes structure rather than sequence and which exists in a fraction of the volume on the open internet. So OpenAI moved the work to where the model was already strong.

The front-end flow was built on XLS, an Apache 2.0 high-level synthesis framework originally from Google. Designers write DSLX, a hardware-oriented DSL that mimics Rust, or plain C++. XLS compiles that down to synthesizable Verilog and SystemVerilog. The model never has to be a great Verilog author, because it is writing something that reads like software and letting a compiler handle the translation.

Chris Leary, on OpenAI's technical staff, put the reasoning plainly: "We were thinking about how to leverage AI to make the project faster, and the AI was much better at software-looking things. XLS in some ways looks like software, so it got that benefit."

The analogy: it is the difference between asking a well-read polyglot to write in a language they have read a million pages of versus one they have seen a few hundred. Same model, same talent, wildly different hit rate, and the only thing that changed was the format you handed them.

The models themselves moved during the project. Early work leaned on o3. Later work used precursors to GPT-6 Astra, which could operate directly in Verilog without the XLS translation step and was approaching the ability to drive proprietary EDA tools on its own. OpenAI also used internal models fine-tuned specifically for chip design that it has not released.

Where the AI moved the needle

Two numbers from the Hot Chips presentation are worth writing down, because they are measured against real baselines rather than vibes.

The first is a software optimization result. A DeepSeek multi-head latent attention kernel started at 0.31% of the theoretical ceiling on the new hardware, which is roughly what "it runs, technically" looks like on day one of a fresh architecture. AI-guided optimization took it to 88.94% in about 40 hours. Ho's read on that is the operationally interesting part: "All our schedule assumptions are going to be based on the fact we have this capability now."

The second is physical. AI-guided optimization produced matrix multiplication units 10% smaller in area than an optimized human baseline, and a 56% efficiency gain on a BF16 multiply. Area is the currency of a chip: 10% back on the largest repeated block is yield, power and cost, not a demo.

There is also a workflow detail that says more about confidence than any benchmark. Per the Hot Chips deck, major changes landed up to the day of the RTL freeze. Teams that cannot verify quickly do not touch RTL in the final week; they freeze early and pray. AI-assisted verification and automated waveform inspection are what buy you the nerve to keep editing.

The chip it produced

Jalapeño is a blank-slate design for modern LLM inference rather than a training accelerator with the serial numbers filed off. Per chip: 13.4 PFLOP/s of MXFP4 matrix compute, 216 GiB of HBM4, and 15.4 TB/s of memory bandwidth, in a 700 W package running around 1.70 GHz. A 2,048-chip system reaches 27 EFLOP/s and 432 TiB, with 600 GB/s across the local 128-ASIC domain and 200 GB/s across the global one.

OpenAI's published benchmarks run SemiAnalysis's public InferenceX suite across GPT-OSS 120B, DeepSeek R1 670B and Kimi K2.5 1T. Against Nvidia GB200 and GB300 rack systems, it claims 1.5x to 1.9x more throughput per kilowatt and 1.7x to 3.6x lower end-to-end latency. The power column is doing real work in those ratios.

What this is not

Four caveats, and each one changes how you should read the headline.

• The benchmarks are OpenAI's own. InferenceX is a public suite, but the runs, the configurations and the comparisons are vendor-supplied and have not been independently reproduced.
• Broadcom did the hard back end. OpenAI owned system design, the accelerator, memory hierarchy, networking and front-end design through RTL verification. Broadcom handled physical design from the gates onward: routing, clock and power, foundry coordination, using its own internal flow and, notably, only OpenAI's public commercial models. Somewhere in that arrangement is a very funny procurement conversation.
• The back end stayed human. AI gains clustered in high-level synthesis, front-end design, kernel optimization and debugging. Backend work remained largely human-guided, which several outside reviewers read as a conservative choice for a 2025 schedule rather than a limit of the tools.
• The team says so explicitly. Ho: "We're not saying that anyone can come and just build state-of-the-art, frontier AI/ML accelerator chips using just Codex. We are saying some very specific things about how to be better at Codex and how we are focusing on a small team and fast timelines to reach quality results."

Outside reads track that. David Chin of Verkor.io called the schedule "quite credible" but argued Broadcom's role was essential: "If you have somebody else start from scratch, it won't be possible." Andrew Kahng at UC San Diego called the speed "likely best in class today" and said the XLS-centered workflow "has legs going into the future."

What to take from it if you do not build chips

The transferable idea is not "AI designs hardware now." It is that the team got its leverage by changing the representation of the problem until it landed inside the model's strongest domain, then let a deterministic compiler cover the gap to the domain the model was weak in.

That pattern generalizes cleanly. If your models keep failing at a task, before you fine-tune or bolt on a bigger agent loop, ask whether there is a software-shaped representation of the same work, with a trustworthy compiler or transpiler on the far side. A DSL the model can write fluently plus a verified lowering step beats a model struggling in the target language, and you get to keep the correctness guarantees of the compiler instead of hoping the model got the structure right.

The second lesson is about verification throughput. The reason OpenAI could accept changes up to RTL freeze is that checking a change got cheap. Fast, automated verification is what converts a fast generator into a fast project. Without it, all a faster model buys you is a longer queue of unreviewed work.

Key Takeaways

• OpenAI took Jalapeño from architecture concept in October 2024 to first silicon in May 2026, under 20 months total, with RTL freeze to tapeout in about nine, using a hardware team that averaged fewer than 100 people.
• The enabling choice was XLS, Google's Apache 2.0 open-source high-level synthesis toolchain, letting designers and models write Rust-like DSLX and C++ that compiles to Verilog and SystemVerilog.
• Measured AI gains: a DeepSeek MLA kernel went from 0.31% to 88.94% of theoretical peak in roughly 40 hours, matmul unit area dropped 10% against an optimized human baseline, and a BF16 multiply gained 56% efficiency.
• The chip is 13.4 PFLOP/s MXFP4, 216 GiB HBM4, 15.4 TB/s, at 700 W, claiming 1.5x to 1.9x throughput per kilowatt and 1.7x to 3.6x lower end-to-end latency than Nvidia GB200 and GB300 racks on SemiAnalysis's InferenceX. Those figures are OpenAI's own and unverified by third parties.
• Broadcom still did physical design from the gates onward, and OpenAI's VP of hardware is explicit that this is not a recipe a small team can run with Codex alone.
• The reusable idea for everyone else: reshape the problem into the representation your model is fluent in, then use a deterministic compiler to cross the last gap, and invest in verification throughput so fast generation turns into fast delivery.

Sources: IEEE Spectrum, OpenAI, Broadcom, ServeTheHome, Tom's Hardware, Google XLS, DeepSeek-V2 (MLA), Hot Chips 2026