On October 13, 2026, developer bubbleboi announced that they had used Meta's AI agent Muse to complete place-and-route for a cryptographic circuit in the RISC-V project museRISC, and had published the design data. According to bubbleboi, the AI produced about 100 million output tokens, which works out to roughly $2,000. On October 14, records were also published showing a simulation in which Linux booted on the project's custom-designed CPU. The case is drawing attention as an example of AI-driven chip design going beyond circuit generation to include bug fixing, physical design, and OS boot verification. However, the CPU and the crypto circuit have not yet been integrated, and no chip has been manufactured, so the performance of a finished semiconductor has not been demonstrated.
The roughly $2,000 figure is an estimate based on AI output volume
In an X post on October 13, bubbleboi reported that Muse used OpenROAD to complete place-and-route for the circuit and generate design data in GDS format. Place-and-route is the process of deciding where the components of a circuit go on the chip and how they are connected. GDS is a data format that records the circuit patterns and layout information needed for semiconductor manufacturing, so reaching it means the work has moved from logic design to physical design.
As for development cost, bubbleboi estimates the work at about 100 million output tokens, equivalent to roughly $2,000. This is an estimate based on the AI's output volume, not the total cost of designing and manufacturing a chip. No detailed breakdown has been provided that includes the developer's own working time or equipment costs, so it is impossible to judge how much cost was saved compared with conventional development methods.
Muse is a personal AI agent that Meta announced in September 2026. It uses a dedicated virtual machine and browser to carry out a variety of tasks at the user's instruction. museRISC is an individual developer's project built with Muse; it is not a cryptocurrency-oriented semiconductor developed or announced by Meta itself.
Even so, the results include notable points beyond the cost estimate. museRISC's circuit source code and verification records are public, and they also show the problems found after place-and-route of the crypto circuit and how they were fixed. Rather than simply a report that an AI generated a circuit, the project lets observers trace the conditions under which verification was performed and how far the design progressed, which is an important feature of this case.
Physical design of the crypto circuit and Linux boot on the custom CPU are separate achievements
To understand museRISC's progress, it is necessary to distinguish between place-and-route of the crypto circuit, Linux boot on the custom CPU, and completion of an SoC that combines the two. Cross-referencing sections B3 and Stage 6 of the verification records published by the developer with the project README as of October 15, the milestones can be summarized as follows. Note that these are results recorded by the developer, not third-party reproduction tests or measurements on a physical chip.
| Item | Milestone recorded by the developer | Not yet demonstrated |
|---|---|---|
| Crypto circuit alone | Place-and-route completed with OpenROAD on October 13; GDS published | Physical design of the full SoC including the CPU; post-manufacturing measurements |
| Custom CPU | Linux 6.6 booted on Verilator on October 14, reaching the embedded init program | Linux on a physical chip; connection to the crypto circuit |
| CPU–crypto circuit integration | The README as of October 15 lists integration step B4 as on hold | Cryptographic processing in the integrated configuration; performance demonstration on Thru |
| Chip manufacturing | The README says manufacturing data has not yet been submitted | Performance and power evaluation of a manufactured chip |
The key point is that even if physical design of the crypto circuit is complete and the CPU can boot Linux, that does not mean the whole SoC is finished. An SoC (System on a Chip) is a system that integrates a CPU, peripheral circuits, and other components on a single chip. After confirming that each circuit works on its own, it is necessary to verify that they operate correctly when connected. Combining the crypto circuit's estimated power consumption with the CPU's instruction test results does not yield the performance of a completed SoC.
museRISC's crypto circuit is designed to support hash computation with SHA-256 and SHA-512, Keccak-f1600, and the finite-field arithmetic used in Ed25519 and secp256k1. However, the existence of these arithmetic circuits is not the same as being able to call them from the CPU and run cryptographic or signing processes to completion. Confirming the latter requires integrating the CPU and the crypto circuit and executing the full sequence of operations.
Specific verification results exist for the crypto circuit's physical design. According to the B3 record, the design using the nangate45 standard cell library has 61,590 standard cells and an estimated power consumption of 20.16 mW at 100 MHz. The final routing results are reported to have zero design rule violations, antenna violations, and violations of maximum capacitance, slew, and fanout constraints. However, 20.16 mW is an estimate from design tools, not a value measured on a manufactured semiconductor.
There are also caveats regarding timing verification. The setup timing margin, which checks whether signals arrive by the required time, was 4.52 ns, while the hold timing margin, which checks whether signals are held for the required duration, was only 0.039 ns. The development record itself notes that the latter margin is very small. A comfortable setup margin does not mean sufficient margin has been secured under all operating conditions.
Nor did the design pass every check from the start. Before fixes, the post-routing check found 51 maximum-capacitance violations, and the development side recorded that it resolved them through repeated countermeasures such as adjusting repair conditions and prohibiting the use of certain cells. The result is better understood as work that progressed by revising the design based on verification results until physical design constraints were met, rather than the AI generating a finished circuit in a single pass.
Booting Linux on the custom CPU revealed bugs that instruction tests had missed
In the October 14 verification record, a custom-designed five-stage in-order CPU successfully booted Linux 6.6 in a Verilator simulation. Linux reached the embedded initial program, /init, meaning the project moved from the third-party CPU "CVA6," which had been used for verification in the early stages, to operation on its own CPU. This shows that not only basic instruction execution but also the functions needed to boot an OS worked to a certain extent.
However, this Linux boot was limited to a simulation test using a single-core-equivalent configuration. It does not confirm that a general Linux distribution boots or that an entire system including network devices and storage works. In addition, Linux's cryptography-related self-tests were disabled in this boot test, so it cannot be treated as evidence that the crypto circuit was integrated into the CPU and worked correctly.
On the other hand, trying to boot Linux also exposed bugs that earlier instruction-level tests had not found. According to the development record, a problem occurred in which a write to a control and status register (CSR) by a subsequent instruction took effect before exception handling had completed. Another bug was found in which the clock Linux reads stopped, because a haltable cycle counter was also being used for timekeeping. The development side fixed both problems and added regression tests that can detect the same bugs if they recur.
Even if a CPU executes individual instructions correctly, exception handling and timekeeping do not necessarily function as the OS expects. Booting Linux requires many such functions to work together correctly. The verification record shows that, in evaluating progress in AI-driven semiconductor design, it matters not only how much code was generated but also whether bugs found at runtime could be identified and fixed.
The instruction test results also need to be distinguished by target. The Berkeley TestFloat mentioned in the first post was verification of the floating-point functions of CVA6, which was used early on, and those results cannot be taken directly as the custom CPU's score. Separate verification results have been published for the custom CPU: it passed 543 of 544 tests in the RISC-V Architecture Certification Test (ACT), with the remaining one treated as a known mismatch with the test environment.
For integer vector instructions, all 1,872 tests that were generated and run passed, but 43 were either not generated or not selected as test targets. It therefore cannot be said that all instructions, including those 43 untested ones, have been verified. Describing the result as "passing all RISC-V tests" while omitting these exceptions and the scope of verification would misrepresent what has actually been achieved.
Speeding up Thru will require integrating the CPU and the execution environment
One of the uses museRISC is aiming for is accelerating processing on the blockchain Thru. According to Thru's official VM specification, ThruVM, which is used to execute smart contracts, is based on RISC-V and adopts extension instructions such as multiplication and division, compressed instructions, and bit manipulation in addition to the base instructions. Because museRISC also uses RISC-V, the two share part of their instruction sets, which gives a good starting point for running ThruVM on dedicated hardware.
However, a CPU supporting the same instruction set does not necessarily mean ThruVM programs can run on it as is. ThruVM uses a 48-bit split address space and manages read-only data, account information, and other data in separate regions. It also uses a copy-on-write mechanism for writing account data and provides system calls for memory management and account operations. Running ThruVM on museRISC would therefore require not only instruction set support but also consistency with these memory management and system functions.
The goal bubbleboi set out in the post, to run Thru directly with exact memory layout, relates to this kind of execution environment integration. They also expressed the ambition of making Thru "the fastest blockchain on Earth," but for now that is a future goal, and processing performance compared with other blockchains has not been demonstrated. The public README also positions the current crypto circuit as an early implementation for verifying basic functions. It has not been completed as a production-grade private-key processing circuit with countermeasures against side-channel attacks, which is another point to keep in mind.
The key items still to be verified are whether cryptographic processing runs correctly in a configuration where the CPU and crypto circuit are connected, and whether the execution conditions ThruVM requires can be met. After that, speed and power consumption would need to be measured under real workloads, and operation would need to be confirmed after a physical chip is manufactured. If such verification proceeds, the value of semiconductor design with Muse could be assessed not only by the cost of the AI's output but also by how efficiently hardware for a specific purpose can be brought closer to practical use.