OpenAI Used Astra to Design a Codex Device. Manufacturing Still Needed Review.

The case, the circuit board, the code. OpenAI says GPT-6 Astra helped design all three for a device that lets someone speak to Codex. Two employees worked on it for less than a week as a side project; a contract manufacturer produced a small prototype batch in under a month.

That is an interesting hardware experiment. The most useful part of the November 3 account is what happened between the design and the factory.

More Than an Enclosure

OpenAI attributes the requirements, enclosure and component mounts, electrical component selection, PCB layout, interface, firmware and software integrations to the model-assisted workflow. The experiment aimed to avoid direct human edits to the designs.

The company links to its prototype enclosure diagram for readers who want to inspect that design directly.

For a maker, the interesting question is how those pieces stay consistent. A case can look finished while leaving a connector inaccessible. A board can fit its outline while giving an assembler no practical way to fasten it. Software can work on a bench without resolving how someone will operate the assembled object.

Those are examples of questions to ask about any hardware design, not reported faults in this particular device. The attraction of a cross-discipline assistant is the possibility of carrying a change through several connected files. The test is whether those changes survive inspection outside the software that produced them.

A Lumen PnP v4 machine, photographed in 2025, illustrates electronics-assembly context. It is not identified as OpenAI's contractor or equipment. Photo: Sircastor, CC BY-SA 4.0; resized as WebP.

Manufacturing Was Still a Checkpoint

OpenAI says production preparation required several rounds of review and iteration. Astra did not consistently account for the manufacturer's production limits, tolerances or assembly details. Avoiding direct design edits did not remove the review process.

A sensible response is to ask for evidence at each handoff:

• Does the drawing state the dimensions that actually matter?
• Can the parts be assembled in the proposed order?
• Is there room to connect, inspect and replace components?
• When a supplier requests a change, which other files need updating?

That checklist is a way to interrogate a workflow, not an assertion that OpenAI published answers to every question. Keep the design proposal and the acceptance decision separate. A clean render is useful for discussing an object; it cannot, by itself, certify the object.

A Prototype, Not a Shopping Listing

This is OpenAI's own account, not independent testing of the device or a controlled comparison with a conventional engineering team. The short design schedule should not be read as a measured productivity advantage across arbitrary hardware projects.

The practical takeaway is narrower, and more useful: judge AI-assisted hardware by the review trail and the parts that get made, not just by how much design work can be generated. For a build with inspectable documentation, our open-source electronics project guide is a separate starting point.

What would you insist on checking before sending an AI-assisted design to a manufacturer? Share it in the comments below.