Verified against source: 2026-08-01

Author: "Cadex is an experimental side project, far from production software. I've always liked Blender's interface and UX more than those of traditional CAD softwares, and even plenty of unrelated software. I also love its flexibility, extensibility, and massive range of capability. The biggest downfall for me was always the inability to do constraint based modeling easily, and the limitations of the armature based rigging system instead of proper linkages and simulation. Since both Blender and FreeCAD are open source, I figured why not try to mash them together and greedily try to achieve the best of both worlds. Also making the whole thing be drivable by an agent seemed like an obvious value add, since they are so capable now. I make no claims towards its reliability nor robustness, though anecdotally I have been quite satisfied. This project will forever be free and open source. If you are looking for a more serious project with similar themes, I highly recommend checking out VibeCAD or Smith"

AI: Cadex is an AI-native CAD application. You describe the part; the AI authors a declarative xscript Python program; the program runs in a sandboxed headless worker, and only validated geometry reaches your model. The script is the model — parameters surface as sliders you can drag without the AI in the loop, and the model is rebuildable from the script at any time.

There are no modeling toolbars and no workbench concept to learn. Chat, sliders, model tree, script, viewport.

Cadex has dynamics and control built in. The mechanism you designed falls, collides and is actuated on MuJoCo; assembly.mjcf exports it with exact OCCT inertias rather than the convex-hull guesses standard MJCF authoring settles for; assembly.task states the control problem as data; a trainer you copy to a GPU box solves it; and assembly.rollout plays the result back in the viewport. "Design me a quadruped and teach it to walk" is a sequence of chat turns. See docs/MUJOCO.md.

This lived on a branch called MJC until 2026-08-01. It was merged once the cost was measured rather than assumed: 53.5 MB on a 3.3 GB application, and nothing at all at runtime for anyone who never calls it (ADR-102).

Status: under active development, pre-release.

Requires pixi and git-lfs, plus a host toolchain for the shell — on macOS that is the Xcode command line tools and brew install cmake ninja git-lfs.

Install git-lfs before cloning. The shell tree keeps binary assets in LFS (~790 MB, mostly shell/tests/files/, but also shell/release/datafiles/icons/ which the build installs and the application reads). Clone without it and you get pointer text files where those should be.

git lfs install
git clone <this repo> && cd cadex
pixi run setup      # check out the shell's prebuilt libraries (~1.3 GB)
pixi run app        # build the engine, the payload and the shell, then launch

The first build compiles two large C++ projects. On a machine with a cold compiler cache that takes hours; measured end to end on an M-series Mac with a warm ccache it is about 21 minutes (clone 9 s, setup 43 s, engine 5 min 27 s, payload 42 s, shell 14 min). After that it is incremental. pixi run app re-runs each step, so it is also the everyday "build what changed and launch it" command.

If you want the steps separately:

pixi run build-engine   # the headless engine (BUILD_GUI=OFF)
pixi run stage-engine   # -> build/engine/cadex-engine-<version>-<os>-<arch>/
pixi run build-shell    # the shell, with that engine installed into the bundle
pixi run gate           # the product gate against the built bundle

Two halves in one repository, separated by a process boundary:

• the engine (repo root, a FreeCAD fork) — cadexd, a per-project headless service speaking newline-delimited JSON over stdio. It runs xscript programs in sandboxed workers, produces BREP, and streams tessellation with face and edge ID maps back.
• the shell (shell/, a Blender fork) — the application. It carries the engine inside its own bundle and finds it by reading a cadex-engine.json manifest, so a built application needs no configuration at all.

And one directory that is deliberately neither:

• training/ — the offboard PPO trainer. It is not part of the product: CMake never installs it, no payload carries it, and it cannot import Cadex. You copy it to a machine with a GPU, run it, and copy one .cxpolicy file back. There is no train button and nothing to press — training needs JAX on a GPU, so the engine verifies a policy and never produces one. training/README.md.

The protocol between them is pinned by tests on both the request and the response side (docs/INTEGRATION.md), which is what keeps either half replaceable.

The AI is the Claude Code CLI — driven from inside the shell, or by cli/ below. There is no API-key configuration either way.

cli/ is a second front end and a third client of the same protocol — no Blender, no display, no shell code (docs/CLI.md). It needs a built engine and nothing else.

./cadex -p "a mounting bracket for a NEMA17, 4 mm wall" --project ./b --out ./b/out
./cadex params --project ./b --set wall=6 --out ./b/wall6   # no AI, no tokens
./cadex -p "make the fins 20% thinner" --project ./b --resume

One expensive turn writes a parametric script; after that a loop sweeps its parameters and re-exports STEP/STL for the price of a rebuild, so an external simulator can drive the design and the model is asked only when the shape must change.

1. Create or open a file and save it — the assistant needs a durable project home; conversations and the model script live with the project.
2. Describe the part: dimensions, interfaces, material, constraints. Attach reference images or the current view if useful.
3. Send. Click a face in the viewport to pin it; pins attach to your next message as ground truth for which face you mean.
4. Drag parameter sliders to explore the design space — sliders re-run the script through the engine directly, with no AI turn.

pixi run test-engine                                  # engine suite, no build needed
                                                      # (the MJX-gated skips are by design)
pixi run python -m pytest cli/tests                   # the CLI suite
pixi run test-release                                 # ctest (diff against
                                                      # build/ctest_baseline_failures.txt)
pixi run gate                                         # CADEX-BLENDER-GATE, the product gate

Start with CLAUDE.md (repo map, commands, change policy) and the doc set under docs/: VISION · ARCHITECTURE · XSCRIPT · MUJOCO · INTEGRATION · BLENDER · CLI · FREECAD · BLENDER-TREE · PROVENANCE · ROADMAP · DECISIONS. The trainer: training/README.md. Packaging: docs/cadex-release-packaging.md. Policies: PRIVACY_POLICY · SECURITY.

Cadex is a derivative work of two projects, and keeps importing from neither's release stream — we delete from these trees rather than track them. It also depends on two kernels it does not fork, because we intend to keep them.

• The geometry kernel is OCCT (LGPL-2.1), reached through a fork of the FreeCAD project and built on the work of the wider FreeCAD community.
• The application shell is a fork of Blender (GPL-2.0+).
• The dynamics kernel is MuJoCo (Apache-2.0), kept upstream and unmodified and redistributed inside the engine payload on this branch. Cadex is not affiliated with or endorsed by the MuJoCo project.
• The CadexLight and CadexDark themes are based on OpenTheme by Obelisk79.

Cadex is not affiliated with or endorsed by either project. Which code came from where, under which licence, and what we changed is spelled out in docs/PROVENANCE.md.