FabricationLive
BuildWise
An AI slicer coach for 3D printing. Tell it your printer, your material, and what you're trying to achieve — it returns expert, hardware-aware slicer strategy instead of numbers to guess at.
The problem
Beginners guess slicer numbers.
A slicer presents a wall of knobs — walls, infill density and pattern, layer height, temperatures, speeds, supports, chamber — and almost no guidance on which ones matter for your part on your machine. So beginners copy a number off a forum, crank infill to 100% for "strength," and wonder why the part is heavy, slow, and still snaps. The advice that exists is generic, contradictory, and rarely tied to the printer in front of you.
Experts don't think in numbers. They think in intent — strong, fast, cheap, pretty, does-it-live-in-a-hot-car — and let the tradeoffs follow from the hardware and the physics. The gap between those two worlds is exactly where parts fail.
The solution
State intent. Get defensible settings.
BuildWise moves you from guessing numbers to stating intent. You give it your printer, your filament, what you're making, and optionally an STL; it returns a settings table tuned to your exact setup, with an honest "why" on every row and explicit tradeoffs when goals conflict — strength versus speed, surface versus time.
It's built on one principle: the computer handles the facts; the model handles the judgment. Anything deterministic — printer specs, physical feasibility, part geometry, which engineering principle applies — is computed in code and handed to Claude as authoritative context. The model never guesses your hotend's max temperature or whether a material can physically print; it reasons over grounded facts and communicates them well. And it refuses common-but-wrong moves — like 100% infill for strength — rather than politely obliging them.
Embeddings run locally, so the only model in the loop is Claude — retrieval adds no second API dependency, no extra latency tax, nothing to sign up for.
Anatomy
See exactly where the line falls.
Five system diagrams trace how a print intent becomes grounded slicer strategy — the core loop, the feasibility gate that refuses the impossible in code, the two knowledge stores, the hybrid retrieval that won't let the goal get drowned, and the cached, inspectable prompt. Drawn in one visual language: blue is deterministic code, amber is Claude, coral is refused.
Under the hood
What's actually running.
Deterministic feasibility gate
Whether PC can print on a stock Ender 3 is physics, not opinion: the hotend caps at 240 °C, PC needs ~260 °C, and PC requires an enclosure the machine doesn't have. A pure-code check compares material requirements against printer limits — hotend and bed temperature, enclosure need, abrasive-versus-hardened-nozzle — and returns a verdict with blockers and warnings before the model is ever called. The impossible is refused in code, with the exact reason. The coach only communicates the verdict in persona; it never has to guess the physics. This is the single most important reliability decision in the system.
STL geometry analysis
When a part is uploaded, the mesh is analyzed for objective facts — bounding box, volume, overhang fraction, watertightness — so advice is grounded in the real geometry, not a fuzzy text description. A tall thin part and a flat wide one get different orientation and support strategy because the numbers differ, not because the model imagined they might.
Facts vs. reasoning
Two kinds of knowledge live in two kinds of places. Facts — printer specs, material temperatures — are structured, sourced JSON read through typed repositories: diffable, version-controlled, never invented. Reasoning — why walls beat infill, why PLA dies in a hot car — is curated Markdown compiled into a vector store. Eleven printers across four reasoning archetypes; any unlisted machine maps to its closest archetype and still gets sane advice. Fourteen materials with sourced properties.
Local-embedding RAG
A curated corpus of engineering principles is embedded locally with a sentence-transformers model and retrieved by intent — so the model's reasoning is grounded in vetted knowledge instead of forum myths. Running embeddings locally rather than through a hosted API is a deliberate choice: retrieval adds no second model dependency, no extra cost, and no extra latency — the only API call in the loop is to Claude.
Hybrid retrieval
Plain semantic search over "goal + material + printer" let the material words drown out the intent — a strength request once surfaced material-selection docs instead of the walls-before-infill principle. So retrieval pins the canonical principle for each stated optimization axis via metadata-filtered search, then fills the remaining slots with use-case reality-checks. The principle the user's goal depends on is always present, not left to chance.
The coach
Claude assembles the facts, the feasibility verdict, the geometry, and the retrieved principles into a structured settings table, at low temperature for repeatability. Experience level (novice / intermediate / expert) sets the tone; a verbose toggle controls whether the reasoning is shown. The whole brain is one static system prompt — the engineering rules, persona, depth control, and output structure — kept static so it caches on the API. A dry-run mode assembles the entire prompt without spending a token, so it can be inspected and tuned for free.
Tested & evaluated
25 tests passing: the STL geometry analyzer and the deterministic feasibility gate pinned against the real fact tables, plus a retrieval eval harness that asserts plain-English goals surface the principles they must ("phone case that needs to flex" → use-TPU). The eval caught a missing corpus doc during development and now prevents that class of regression. Retrieval relevance is held to an eval, not to vibes.
Stack
Python · Pydantic typed models
Deterministic feasibility + geometry
Chroma · local sentence-transformers (MiniLM)
Claude · low temp · prompt caching
FastAPI backend · static dark UI (no build step)
CLI + web · Docker one-image deploy
pytest · 25 tests + retrieval eval
Local embeddings · Claude the only hosted call
Status
Live on Hugging Face.
The full engine is up and running: typed domain models, the STL geometry analyzer, sourced printer and material fact tables, the deterministic feasibility gate, local-embedding RAG over a curated principle corpus, and the coach with table output, verbosity, and goal tradeoffs — driven by a custom dark web UI on a FastAPI backend, all behind 25 passing tests and a retrieval eval. Deployed as a single Docker image on Hugging Face Spaces. Try it with your own printer and part.