Claudeware

If u can prompt it we can print it , we killed the learning curve between learning CAD softwares and printing it physically

Comment

Inspiration

Claude can write, reason, and code — but it has no hardware branch. It lives entirely in software; it can describe a phone stand, but it can't hand you one. We wanted to change that: to give Claude a way to reach out of the screen and put a real, physical object in your hands.

At the opening ceremony, the call was to go for big swings — the biggest swing at a meaningful problem. So we picked one. 3D printers are now cheap and everywhere, but adoption is still stuck, and the reason isn't the hardware. It's that the average person needs roughly 600 hours to become competent in CAD software like Blender or Fusion 360 — and most still can't produce something that prints without failing. Professional modeling costs $50–$500 per part, CAD licenses run ~$2,000/year, and even then you have to learn orientation, supports, wall thickness, tolerances, and splitting on your own. The barrier to 3D printing was never the printer. It was design expertise. So we built the thing that supplies it — and gave Claude its hardware branch in the process. We called it Claudeware.

What It Does

You describe any object in plain English — "a gear with 24 teeth," "a threaded M10 bolt," "a chubby sitting dragon" — and Claude designs it, makes it printable, shows it forming live in a 3D viewport you can orbit and drag, inspects its own render and fixes its own mistakes, and exports a print-ready file for the printer you already own. The flow is six steps, and Claude drives all of them:

  1. Describe — type, speak, or pick a prompt.
  2. Clarify — Claude asks prompt-specific questions first. A dragon gets asked about wings, scales, and pose; a bolt gets asked about thread pitch and length. No generic templates.
  3. Design — the model builds step-by-step, live, in a react-three-fiber viewport you can orbit, zoom, and drag while it's still forming. Open the native CAD app alongside (OpenSCAD, Blender, or Fusion) and the same build appears there too — dual view, web and desktop.
  4. Validate — four automatic printability checks run on the finished mesh (watertight geometry, single body, overhangs, wall thickness) and produce a 0–100 readiness score.
  5. Prepare — Claude auto-orients the model for the best print and exports real files: STL, OBJ, 3MF for a Bambu A1, and actual G-code sliced by PrusaSlicer, with real supports, real layer counts, and real filament estimates — not guesses.
  6. Print — send to the printer with one click. Too big for the bed? Claude splits it into parts joined by push-fit connectors — 5.4 mm pegs into 5.6 mm sockets, a 0.2 mm engineered clearance that snaps together without glue.

The core idea is that no single engine is right for every object, so Claudeware isn't one tool — it's five engines behind one brain, with an Auto mode that classifies the prompt and routes it:

  • OpenSCAD + BOSL2 for mechanical parts (real involute gears, real threads)
  • Blender (bpy) for organic shapes you watch sculpt live
  • Fusion 360 (adsk) for precision multi-part assemblies
  • NVIDIA NIM (TRELLIS) for full-color textured characters
  • Auto so the user never has to know the difference between parametric and organic modeling

And unlike every other text-to-3D tool that hands you a mesh and wishes you luck, Claudeware checks its own work — it renders the result, scores it for likeness with computer vision, and regenerates if it falls short, with no human in the loop.

How We Built It

The frontend is Next.js + TypeScript + Tailwind with a react-three-fiber / drei viewport. UI and backend talk through exactly one contract — a typed AgentEvent stream over Server-Sent Events — so the UI is pure (events in, JSX out) and never imports backend logic.

At the center is a single orchestrator, /api/generate, that runs the loop classify → clarify → resolve engine → generate → finish. Auto routing classifies the prompt and dispatches to one of four engines, each running as a subprocess with a timeout:

  • OpenSCAD — Claude writes staged parametric SCAD with the vendored BOSL2 library
  • Blender — Claude writes staged bpy Python, driven live over the BlenderMCP socket straight from Node (no MCP client needed), with a headless fallback
  • Fusion 360 — Claude writes adsk scripts POSTed to Fusion's own HTTP MCP
  • NVIDIA NIM — TRELLIS text-to-3D → textured GLB + STL

Crucially, Claude writes a recipe — the actual SCAD/bpy/adsk script — not a frozen mesh. That's what makes "edit it by prompt" real: each prompt patches the script and re-runs into a new, diff-able version.

The finish tail is the part nobody else builds: a Print Brain computes dimensions, supports, and split decisions from the mesh, and a Print-Readiness pipeline runs four real checks (manifold via open-edge count, floaters via connected-component analysis, overhang fraction via face normals, thin-feature heuristics), auto-orients by scoring the six axis-aligned poses, and exports 3MF/OBJ/G-code through a forked PrusaSlicer CLI. A self-inspect step renders the result and asks Claude vision to score likeness, triggering one bounded auto-fix retry.

Every external service — Deepgram, Redis, Browserbase, The Token Company, Arize, Sentry, InsForge — sits behind a key-gated interface with a working fallback, so the whole app boots with zero keys. We TDD'd the pure logic throughout: 216 tests across 40 files, a clean production build, and cached fixtures as a wifi-death safety net.

Challenges We Ran Into

  • The LLM is a subprocess that can time out. Complex prompts made Claude reason past the claude -p time limit mid-write, so a threaded jar or an L-bracket would silently fall back to a generic block. We root-caused it with systematic debugging (the failed build's clock landed exactly on the timeout) and fixed it by pinning the script writers to Sonnet, which writes good CAD roughly twice as fast and finishes under the limit.
  • A hidden concurrency starve. The bug's tell was "it always fails when starting a new session, then works after." The cause: classify, clarify, and generate each fire their own claude -p at once and starve the shared CLI — tipping an already-slow call over the edge. Non-obvious, and only findable by tracing the timing.
  • BOSL2 dropping geometry silently. A bolt rendered as just its hex head because BOSL2's part libraries (threads, gears, bearings) are separate files from the core — so threaded_rod() was an unknown module that OpenSCAD drops with a warning, not an error. We had to re-prepend the full library set on every stage and start treating render warnings as signal.
  • NVIDIA's endpoints fighting back. The hosted TRELLIS text-to-3D endpoint intermittently 500s and sometimes returns an empty/queued artifact under load; we built retry-with-polling to lift the success rate from ~1-in-3 to ~90%. The image-to-3D endpoint 500s server-side even with the correct upload flow, so we pivoted: Claude vision describes the reference image in text and we feed that into the working text-to-3D path.
  • Driving real CAD apps live. Blender's MCP is a Claude Desktop extension, not a Claude Code server, so we drove the addon's localhost socket directly from the backend; Fusion we drove over its own HTTP MCP. Both had sharp edges (scope-poisoning imports, units in cm vs mm) to file down.
  • Keeping a frozen design intact. A hard rule of the project was not to touch the frozen UI, so the entire print-readiness and assembly backend had to be built additively behind the AgentEvent contract until a deliberate "change the design" go-ahead.

Accomplishments That We're Proud Of

  • We gave Claude a hardware branch. It can now turn a sentence into a physical object you can hold.
  • Five engines, one brain — a genuine multi-engine system with Auto routing, not a one-trick demo. Mechanical parts, organic figures, precision assemblies, and textured characters all from one prompt box.
  • AI that checks its own work — the render → vision-score → auto-fix loop is the differentiator, and it runs with no human in the loop.
  • A real manufacturing pipeline, not a toy. Actual G-code from PrusaSlicer, real BOSL2 involute threads, and engineered 0.2 mm push-fit tolerances that snap together without glue.
  • Zero-key boot. The entire app runs and demos with no API keys at all — every integration degrades gracefully instead of breaking.
  • Production-grade under hackathon time — 216 tests across 40 files, a clean build, and 8 sponsor integrations each doing real work behind a fallback.

What We Learned

  • The biggest model isn't always the right one. Under a latency budget, faster mid-size models (Sonnet, Haiku for classification) beat the largest model that reasons past the timeout. Right-sizing the model to the task is an engineering decision, not a default.
  • Treat the LLM like any other subprocess — bound it with timeouts and retries, and assume it can fail or hang. One bad generation must never hang the loop.
  • Generation isn't the hard part; printability is. Every other text-to-3D tool stops at the mesh. The real value — and the real engineering — lives in the orientation, checks, splitting, and slicing that turn a shape into something that actually prints.
  • Honest fallbacks beat silent ones. Surfacing the real failure reason ("Claude ran past the limit → generic shape," "Blender isn't connected") makes the product trustworthy; a silently faked result destroys trust the moment it's caught.
  • The "recipe, not a mesh" abstraction is what makes edit-by-prompt real — and it's worth designing for up front rather than retrofitting.

What's Next for Claudeware

  • True likeness via image-to-3D — a self-hosted TRELLIS or an image-accepting provider (Rodin/Tripo/Meshy) so a reference photo reproduces an accurate model, not just a loose guide.
  • Staged complex builds — stage the Fusion and OpenSCAD builds the way Blender already is, to beat the single-shot ceiling on multi-feature parts and assemblies.
  • Serialize the generate route so classify/clarify/generate stop share-starving the shared model at session start.
  • Real auto-repair transforms — auto-thicken thin legs, and decompose complex models into separate printable parts nested on a single plate with library connectors.
  • Close the loop to the printer — OrcaSlicer G-code and a real one-click send to a Bambu over LAN, plus a printer cam to watch it print.
  • A fuller voice agent (Deepgram end-to-end) and broader model-repo search with authenticated downloads.

Built With

Share this project:

Updates