Launching Standard Machines

Advancement in AI relies on chips. Transformers won in part because they mapped well to GPUs. The frontier labs are now co-designing their own chips, trying to maximize intelligence-per-joule.

But chip design has not gotten faster. It still takes years and hundreds of experts to bring a chip from architecture through tape-out. The models improve on a cadence of months; the silicon they run on improves on a cadence of years.

Our goal as a company is to close that gap: to push the frontier of AI capability on chip design tasks, so that advanced chips can be taped out by small teams in months.

Today, we are launching the first piece:
RL Environments For Long-Horizon Chip Design

Why environments

RL on language models comes in two shapes.

In the first, the episode is a single completion: the model emits an answer, a verifier checks it, a scalar reward comes back. The environment is degenerate; nothing exists outside the model's own text. This is the recipe behind the reasoning-model wave, and its scarce input is data: pools of problems with checkable answers.

In the second shape, the model acts in a world. It calls tools, edits files, runs programs; state changes outside its context and observations come back. The trajectory is a genuine loop, hours long, and the reward depends on what the model actually did to that world. The scarce input here is not data. It is environments: worlds with tools, state, isolation, and a grader that survives adversarial pressure.

Frontier labs train agents by letting them attempt a task thousands of times and reinforcing whatever earns reward. Compute is abundant. But RL is an adversarial optimizer: it maximizes the reward that was written, not the reward that was meant, and a million rollouts will find every gap between the two. A weak grader does not merely mismeasure. It actively teaches the model to cheat, inside a training run.

So the value of an environment is set by the trustworthiness of its reward.
Everything we build follows from that sentence.

What exists today

Chip design should be a perfect domain for this kind of RL. Correctness has executable referents, the tools are programmatic, and the economic value per task is enormous. Instead, the existing instruments have collapsed, in three ways.

Saturation. The academic Verilog benchmarks are one-shot puzzles of roughly a hundred lines, and they are in every training set. The field's de facto standard, NVIDIA's CVDP, went from 34% to 97% in two years once agents could iterate against the grader. A 97% score discriminates nothing: the benchmark now measures scaffolding, not capability.

Weak oracles. Almost everything is graded by running testbenches, and testbenches only cover what their authors thought to try. In one study, designs that passed their bundled testbenches 95 to 97% of the time were only about 20% correct under formal equivalence checking. Passing tests is not the same as being correct, and the gap is not small: a testbench-graded score can overstate correctness by a factor of four or five.

Wrong shape. Published tasks are short-horizon: one completion against a unit test. Real chip design is months of work with tools in the loop, and its difficulty lives in trade-offs that these benchmarks never see. A real block must be correct and meet timing and fit an area budget and hit a power target, and improving one of these usually costs another. No existing benchmark grades that tension.

None of this resembles the real loop: months of work, tools in the loop, and hard trade-offs between latency, throughput, area, and power.

What we build

Our environment runs the complete chip design loop.

A task is an executable contract. For example: implement a matrix-multiply engine that sustains 1024×1024 INT8 GEMMs at 2 TOPS, under 1 W, in under 1 mm², under a particular PDK. The contract fixes what the design must compute (down to rounding behavior), how it must talk to the world (ports, clock, handshakes), and the physical budgets it must fit. The implementation is entirely the agent's to choose: any microarchitecture that satisfies the contract is valid.

The episode is the real engineering loop. The agent works in a sandboxed workspace holding the spec and its own files, with real EDA tools installed and nothing else: no reference solution, no grader to peek at, no network. It writes SystemVerilog, runs the simulator, reads the errors, fixes, synthesizes, and iterates. It can spend a bounded budget on place-and-route previews of its current design, seeing real area, timing, and power numbers mid-episode so it can discover it is missing timing and revise the architecture before committing.

When the agent decides it is done, it submits: its exact design files are frozen, and everything after that happens where the agent cannot see.

Grading is sealed and layered. The submission is compiled to a structural form, stimulated with hidden test cases prepared by independent checkers, and compared bit-for-bit against expectations the agent never sees; then the physical flow (real synthesis and place-and-route) measures what the design actually costs. Every stage runs in an isolated runtime, and evidence is accepted only after the runtime that produced it has been torn down, so nothing live can retroactively alter a result.

The reward is gated, then measured. Reward composes in a fixed order that no scalarization can rearrange:

1. Admission: is this a legal, synthesizable design with the contracted interface?
2. Correctness: does it pass every obligation against the hidden checkers?
3. Feasibility: does it meet timing and fit its resource budgets?
4. Only then, performance: the measured latency, throughput, area, power.

A fast, small, wrong chip earns zero. The common alternative, folding correctness into a weighted sum, is a reward-hacking surface: at some weight, a large enough performance term buys off a correctness penalty. Performance objectives are then recorded as an unreduced vector rather than collapsed into one number, because real chips are trade-offs and the weighting between area and power belongs to whoever is training, not to us. The scalarization is fixed before each run and cannot change after a submission is seen.

The signal is dense in training, pure in evaluation. Hard gates raise an obvious objection: a policy stuck at zero has no gradient to follow. So training and development tasks pay a fixed milestone for each stage a submission fully clears: verified admission, verified correctness, verified feasibility. Only verification pays; a claim the grader cannot confirm is a failed gate, not partial credit, so milestones are no easier to game than the gates themselves. Held-out evaluation pays no milestones: the reported number is the terminal score alone, never inflated by partial progress. Tasks are then calibrated so frontier models succeed rarely but not never, with a smooth spread of verified progress in between: dense enough to learn from, hard enough to mean something.

Everything replays. Budgets are deterministic resource limits, never wall-clock, and every graded result replays bit-identically on another machine. That determinism is engineered, not assumed: EDA tools are not deterministic out of the box, so the flow is pinned, seeded, and run in fixed containers. A score that cannot be reproduced does not count.

Physics as the yardstick

The distinctive piece of grading is what performance scores are measured against.

Every task fixes exact arithmetic, interface widths, a clock target, and a physical library. From those parameters alone, before any implementation exists, you can compute a lower bound on what the task costs: every input bit must enter and every output bit must leave at least once, so port widths bound latency; covering the arithmetic requires a minimum amount of silicon-time, so the operation count and the library's characterized operator costs bound area and energy; the longest dependency chain bounds latency regardless of parallelism. These are counting arguments, in the same family as roofline analysis and classical I/O lower bounds, and where they apply they hold for every admissible implementation.

We call the composite the task's speed-of-light bound, and where a scope-covering proof exists, scores are reported as a fraction of it.

This buys three things at once. Scores become comparable across tasks: 60% of physics on one task means the same thing as 60% on another, in a way that raw TOPS never can. Headroom becomes measurable: the gap between the best known design and the bound says how much room a task actually has. And the bound doubles as a tripwire: a measured result that beats a counting bound is not a brilliant design, it is a broken harness, and the grader treats it as one automatically.

Evaluations: the same machine, run cold

An environment and an evaluation are the same artifact used two ways. If a grader can score a rollout for training, it can score a held-out task identically, so a training environment carries its own evaluation.

Our tasks divide into training, development, and private held-out sets whose separation is checked mechanically, by lineage rather than by instance: tasks sharing a source, a specification, or a generator are one correlated family, and no family straddles the boundary. Parameter sweeps of one generator are one lineage, not a thousand independent tasks. Held-out sets stay private under access control, and what a customer trains against never appears in what evaluates them.

Evaluation runs freeze everything before execution: the task plan, seeds, budgets, model identity, scaffold, scoring policy. Results are reported as a set, never one number: pass rates at k attempts, the stage where failures occur, reward distributions, cost, and latency, with uncertainty clustered by family lineage.

Why now

Three things are true at once.

The labs crossed the line first: they are all designing their own inference silicon, and at least one is publicly hiring chip-design RL engineers to build exactly these environments in-house. The capability is on the roadmap; the question is who supplies the substrate.

The environments market matured around exactly our shape. Labs reportedly discussed nine-figure annual budgets for RL environments, delivery has converged on containerized tasks with verifiable graders, and the procurement bar is soundness first: high reward must mean the task was actually solved. That is a bar most domains struggle to meet and chip design can exceed, because here correctness has an executable referent and quality is physically measurable rather than judgeable.

And the yardstick seat is empty. Chip design is becoming a capability labs will want to report, the way agentic coding became one, and every existing benchmark is saturated, contaminated, or graded by oracles that overstate correctness several-fold. When a category becomes reportable, the instrument that exists owns it for years. We intend to be that instrument, and to earn it the only way it can be earned: by publishing the methodology, the calibration evidence, and the limits, and by letting an external red team try to break the grader before anyone is asked to trust it.

Who we are

I was the first intern and youngest hire into GPU Architecture at Apple. I worked alongside the industry's leading architects. I saw how leading-edge chips are designed: what the loop looks like, how the power, performance, and area trade-offs actually get graded. Our environments run that same loop and formalize that grading.

If you are on an RL, post-training, or data team at a frontier lab, we would like to talk.

Reach out.

The hard questions

Here are the common questions.

What stops reward hacking? The sandbox contains nothing to hack: no grader code, no hidden tests, no network. There is nothing to read, spoof, or escape to, so the usual exploit surface is absent. The checkers are executable and hidden, mounted only at grading time, in runtimes the agent never touches; the gates compose conjunctively, so no performance number can buy back a failed check; and a measurement that beats a proven physical bound voids itself as a broken harness instead of posting as a score.

Aren't EDA tools too slow for RL? Tasks are sized so the real tools complete in minutes at module scale, and feedback is layered so no loop waits on anything slower than it needs: simulation and synthesis run in the sandbox in minutes.

Module scale is not a ceiling on difficulty. Difficulty comes from both how tight the budgets sit against the physical bound and how large the design is. A block asked for a comfortable fraction of what physics allows is a clean first implementation; the same block asked for most of it is where real engineering lives: restructured pipelines, retimed critical paths, numerics chosen operator by operator, every register and memory bank fighting for its power budget. That last stretch is what expert teams spend months on.

We are working on accelerated tools to allow expansion to larger many-module tasks.

Doesn't the grader bottleneck training throughput? Grading sits off the episode's critical path: an episode ends at submission, and the sealed evaluation runs afterward, in parallel across submissions. Its two halves also cost differently: the semantic checks are cheap; the physical flow is the expensive stage, and the gates run in cost order, so only a submission that has already passed admission and correctness ever reaches the expensive stage.

Do performance numbers from your flow transfer to a commercial node? The development flow is a pinned, reproducible open flow; its job is exact comparability, ranking designs under identical conditions. A lab can bind its own qualified physical flow and cell libraries under the identical task contracts.