Parametric parts, joints, clearances, and fabrication exports from one shared brief.
0.00sACTUAL FORCE TELEMETRY0.00s
Math executedPhysics passedFirmware matched
A completed STeLar result: the generated gripper grasped, lifted 30.3 mm, lowered, and released the egg while staying below its force limit.
Describe a home-scale machine. Get CAD, parts, firmware, and a physics proof.
From idea to proof
Geometry, electronics, and proof, sharing one brief
CAD, parts lists, and firmware usually drift apart: the motor might not have the torque, the PWM might not match, and contact force is often a guess. STeLar keeps them on the same spec so the pieces stay in conversation with each other.
Named components and flashable firmware written to that same contract.
The firmware drives the machine in MuJoCo so you get measured telemetry, not vibes.
Verified builds
Machines that cleared every gate
Ten distinct geometries. Open a run, or load the prompt into the console.GPT-5.6 · STL Architecture
How the models show up in the stack
Terra shapes your request into a clear brief, Sol sizes it with Programmatic Tool Calling, then Mechanical, Electronics, Firmware, and Systems work through the build together while Luna reads the evidence and keeps Design Review grounded.
YouPlain language
TerraFunctional spec
SolPTC math
AgentsMech · Elec · FW
MuJoCoFirmware in loop
LunaReview + gates
PackageCAD · BOM · code
Turns everyday language into a functional spec: degrees of freedom, loads, limits, and acceptance criteria the rest of the stack can share.
- Measurable requirements
- One brief for every agent
Writes a small program that calls material, actuator, and geometry tools in OpenAI’s hosted V8 sandbox, so the math is executed rather than narrated.
- Force, torque, and current checks
- Margins clear before CAD moves on
Mechanical, Electronics, and Firmware work in parallel, with Systems Integration watching for pin-map, power, and force mismatches.
- Native multi-agent responses
- One assembly, not three drafts
Design Review stays grounded in this run’s evidence, and any change becomes a linked revision that has to re-clear the gates.
- Passing parents stay untouched
- Honest recovery when a stage fails
Observed on the live stack
A few numbers from real runs
These come from completed designs on this deployment, handy context for how long a full pass usually takes.
Why STeLar
Files you can actually trust
Plenty of tools stop at a sketch or a hopeful parts list. STeLar waits until the design clears the same kinds of checks an engineer would care about, then you download.
Sol’s PTC margins need to clear 1.0, with the math executed in a sandbox instead of dressed up as a spreadsheet.
AST-audited build123d exports STEP, STL, and a named-part GLB, checked against the same contract as the BOM.
MicroPython on a virtual RP2040 drives MuJoCo so contact force, motion, and current are measured before anything ships.