SynapsCAD: an OpenSCAD-compatible editor with exact arithmetic and an AI edit loop

The gap SynapsCAD fills between a script and a viewport

OpenSCAD's model is text in, geometry out. You edit a .scad file in one program, run a separate executable, and look at the result somewhere else. SynapsCAD collapses those steps into one Rust application: the editor sits on the left, the Bevy viewport on the right, and a Compile button sits between them. The README describes the goal as "OpenSCAD editing, exact CSG, interactive visualization, and AI-assisted modeling in one Rust application." The target user is someone who already thinks in OpenSCAD syntax and wants a tighter loop, not someone looking for a mouse-driven modeler. The second audience is less obvious: the compiler is exposed as a Rust library, so a tool that needs to turn OpenSCAD text into meshes and preview images can embed it without shelling out to the OpenSCAD binary. That library path is the part with the clearest long-term value, because the parsing and evaluation work is reusable even if the desktop application changes shape.

Exact numbers instead of f64, and where the approximation happens

The design decision that separates SynapsCAD from most CAD front ends is arithmetic. According to the README, every OpenSCAD numeric literal is parsed directly into hyperreal::Real, with no intermediate f64 conversion. Decimal and scientific literals, fractions, arithmetic and math functions keep exact rational or symbolic structure. The README's example is a cube translated to [cos(60), sin(30), PI], where PI is Hyperreal's symbolic pi rather than a rounded constant. Trigonometry, roots, exponentials, logarithms, powers, rounding, vector functions, primitive dimensions, polygons, polyhedra, text metrics, affine transformations, offsets and extrusion parameters all operate on Real values. Floating point appears only at explicit boundaries: display color, mesh buffers, export, and third-party file formats. That is a real trade-off, not a slogan. Exact evaluation costs memory and comparison work, and the payoff shows up in degenerate cases (coplanar faces, tangent surfaces, boolean operations on shapes that should touch exactly) where f64 drift produces slivers or failed intersections. The README does not publish measurements of that cost, and I have not run the benchmark, so the size of the penalty is unknown from this material. The bench harness exists (cargo bench --bench compile_default, with SYNAPS_BENCH_SCENE, SYNAPS_BENCH_FILE, SYNAPS_BENCH_FN_OVERRIDE and SYNAPS_BENCH_ITERATIONS selecting the workload), which suggests the authors care about it, but caring is not a number.

The compilation pipeline, layer by layer

The README's architecture table is unusually concrete for a prototype, and it is the best guide to what the code actually does. Parsing is handled by openscad_rs::parse, which turns source into a typed syntax tree. Evaluation sits in Evaluator, Value and Shape, covering expressions, modules, primitives, transformations and CSG. Geometry comes from csgrs and the Hyper stack, providing exact profiles, meshes, booleans, offsets and tessellation. Compilation is compile_scad_code, which does mesh conversion, diagnostics and orthographic previews. The application layer is Bevy 0.15 with bevy_egui for the editor, viewport, picking, camera, persistence and export. AI is a separate layer using genai or browser HTTP for model discovery, streaming edits and verification rounds. Threading follows from that split: Bevy owns the main thread, native compilation and AI work run in background tasks over nonblocking channels, and WebAssembly uses browser-local tasks. The data flow for a compile is therefore source text into the parser, a syntax tree into the evaluator, shapes into the CSG and Hyper geometry layer, and meshes plus preview images out through compile_scad_code. The public result type is an enum with three arms: Success carrying parts, views and warnings; Error carrying a message; and Canceled. That third arm matters, because it means the library exposes cooperative cancellation rather than assuming every compile runs to completion.

Getting it running, and the dependency wrinkle in the quick start

The quick start is short but contains a constraint worth reading twice. It says to install a stable Rust toolchain, clone the repository beside the Hyper dependencies named in Cargo.toml, and run cargo run --locked. Cloning beside sibling dependencies rather than pulling them from a registry is a path-dependency setup, and it means a plain git clone into an arbitrary directory will not build until those Hyper crates are present next to it. The README does not give the clone URLs for them, so this is the first thing to check in Cargo.toml. Prebuilt Linux, macOS and Windows artifacts are on the Releases page, and unsigned macOS builds may need xattr -rd com.apple.quarantine /path/to/SynapsCAD.app after the user has verified the download. In the editor, number keys 1 through 7 select standard views, G toggles gizmos, L toggles labels, and ? opens the shortcut guide. Orbit is middle- or right-mouse drag, pan is Shift plus middle-mouse drag, and the wheel zooms. For library use, compile_scad_code takes source text, an optional global $fn override, and an optional atomic cancellation flag; the README's example passes 32 for $fn and None for cancellation. The crate is not yet published, so downstream users need a Git or path dependency. Documentation builds with cargo doc --no-deps --open, and the CI-equivalent checks are cargo fmt --all -- --check, cargo clippy --locked -- -D warnings, .github/scripts/test-ci.sh, and cargo build --locked --release. The web build needs rustup target add wasm32-unknown-unknown followed by .github/scripts/build-web.sh, which creates and validates dist/.

AI editing: the model rewrites source, then the compiler checks it

The AI layer is not a mesh generator. The README states that SynapsCAD can ask local or hosted language models to revise the current design, and the architecture table describes the AI layer as doing model discovery, streaming edits and verification rounds. The loop is therefore textual: the model proposes changes to the OpenSCAD source, and the existing compile pipeline evaluates them. That is a defensible design because the compiler is the arbiter, and a bad suggestion fails as a compile error rather than as a plausible-looking mesh. Ollama runs locally without a key. Desktop cloud providers read environment variables including ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY, GROQ_API_KEY, DEEPSEEK_API_KEY, COHERE_API_KEY, FIREWORKS_API_KEY, TOGETHER_API_KEY, XAI_API_KEY and ZAI_API_KEY, and can also be configured in the AI Settings panel. The browser target sends requests directly, so a provider must permit browser CORS or be reached through a proxy. The README does not describe how verification rounds decide that an edit is acceptable, nor how many rounds run, nor what happens when a round produces a compile error. That is the thinnest part of the documentation, and it is the part a prospective user should probe first, because an edit loop that cannot recover from a failed compile is a demo rather than a tool.

Compatibility, the web target, and the licence question

The README opens with a warning: SynapsCAD is an early prototype and OpenSCAD compatibility is incomplete, with concise bug reports containing a reproducing source file invited. The compatibility corpus lives under tests/openscad_examples and originates from OpenSCAD, and tests/generate_references.sh uses an installed OpenSCAD CLI to regenerate the bounding-box and mesh-count references the corpus tests compare against. That is a sensible way to measure compatibility, but it also tells you the compatibility target is bounded by whatever that corpus covers. Language constructs outside it may parse, may fail, or may evaluate differently, and the README does not enumerate known gaps. The web target has its own boundaries: it omits native persistence, clipboard-image capture and model export, and it relies on browser-local tasks instead of the native background task model. So the web demo is a way to try the editor and the AI loop, not a way to produce files. The licence is the least settled item. The repository metadata reports NOASSERTION, and the README does not state terms. That is not a reason to avoid the project, but it is a reason to read the licence file before you build anything on the library, and it is a question worth raising with the maintainer if you intend to depend on it.

Where SynapsCAD is the wrong tool, and what to use instead

If you need reliable OpenSCAD compatibility today, the OpenSCAD executable plus openscad-rs is the safer combination. The README lists openscad-rs as a reference and uses it for parsing, but the difference in approach is what matters: SynapsCAD reimplements evaluation and CSG on top of Hyperreal and csgrs, while the OpenSCAD CLI is the reference implementation the corpus is generated from. Using the CLI means your geometry matches the reference by construction; using SynapsCAD means you accept an independent evaluator whose divergences are exactly what the corpus tests are there to catch. If your work is mesh-first (sculpting, remeshing, organic forms), the text-to-CSG model is a poor fit regardless of implementation quality, because every operation has to be expressed as a primitive and a boolean. And if you need a browser tool that exports models, the web target's omissions rule it out. The honest framing is that SynapsCAD competes with the OpenSCAD CLI on developer experience and exactness, not on coverage. It also competes with nothing in particular on the AI side, because the README does not name a comparable project, and I will not invent one.

Maintenance cost and what to verify before you depend on it

The release cadence visible in the supplied material is v0.9.1, v0.9.2 and v0.10.0 between March 9 and March 26, 2026, with the last push to main in July 2026. That is a fast-moving prototype, and fast movement has a specific cost for anyone embedding the library: the README already flags that the crate is unpublished and that downstream users need a Git or path dependency, which means version pinning is manual and API churn lands directly in your build. The path-dependency arrangement for the Hyper crates compounds this, because your checkout depends on sibling directories rather than on resolved registry versions. On the application side, the compatibility corpus is the maintenance surface: when OpenSCAD changes behaviour, tests/generate_references.sh has to be rerun against an installed CLI and the corpus tests re-baselined. Before adopting, verify four things in this order. First, read Cargo.toml to see which Hyper dependencies are expected as siblings and whether that is workable in your environment. Second, run your own .scad files through the editor and note which ones fail, since the README gives no gap list. Third, read the licence file, because NOASSERTION is not a licence. Fourth, if you plan to use the AI loop, test what a verification round does when the model's edit does not compile, since the README describes the rounds but not the recovery behaviour.

Editorial conclusion

Adopt SynapsCAD if you already write OpenSCAD and want a native editor plus a callable Rust compiler, or if you are prototyping generative 3D workflows and want the model to edit text rather than meshes. Do not adopt it as a drop-in replacement for the OpenSCAD CLI: the README calls compatibility incomplete, the crate is unpublished, and the web target drops persistence, clipboard capture and model export. Before committing, run your own .scad files through the editor, check whether the missing web features matter to you, and read the licence file, because the repository reports NOASSERTION and the README does not state terms.

Official sources

1. Issues
2. README
3. Releases
4. timschmidt/synaps-cad on GitHub