Zoo Design Studio makes CAD models plain text KCL code

Everything you model is KCL code, including the parts you point and click

Zoo Design Studio is described as a CAD application from the future, brought to you by the Zoo team, and it is the Zoo team's take on what a modern modelling experience can be.

The core commitment is stated in the README's first lesson. All artifacts, including parts and assemblies, should be represented as human-readable code, and at the end of the day your CAD project should be plain text. The claim that follows is that this makes version control, which is a solved problem in software engineering, trivial for CAD.

That claim is the whole pitch, and it is a real one. A conventional CAD file is a binary or proprietary container that a diff tool cannot read, and a team that wants to review a design change is reduced to comparing screenshots. A text model changes the review conversation entirely, and it means a design change is a pull request.

The second lesson is about how the GUI relates to that code. All GUI or point-and-click interactions should be actions performed on the code representation under the hood, which the README says unlocks a hybrid approach to modelling. Whether you point-and-click as you always have or you write your own KCL code, you are performing the same action in Design Studio.

The KCL language itself lives in a separate repository, KittyCAD/kcl-experiments, and the app's own Rust workspace includes a custom WASM language server for it. The README describes Design Studio as a hybrid user interface for CAD modelling where you can point-and-click to design parts, and soon assemblies, but everything you make is really just kcl code under the hood, and all of your CAD models can be checked into source control such as GitHub and responsibly versioned, rolled back and more.

The 3D view is a video element, and the geometry runs on a GPU

The most surprising architectural decision in the project is that the 3D viewport is not a renderer.

The README says the 3D view in Design Studio is just a video stream from the hosted geometry engine. The app sends new modeling commands to the engine via WebSockets, which returns back video frames of the view within the engine. And it invites you to check the source, because it is just a video element.

The rationale is the fourth lesson. Everything graphics has to be built for the GPU, and most CAD applications have had to retrofit support for GPUs, whereas the geometry engine here is made for GPUs, primarily Nvidia's Vulkan, getting the order of magnitude rendering performance boost with it.

That is a real engineering argument. A modern CAD kernel is a CPU-bound computational geometry problem, and a GPU-native geometry kernel is a different and much newer class of software. The reason a retrofitted application cannot simply adopt one is that its kernel was written around CPU assumptions.

The fifth lesson extends the same logic past the viewport. Make the resource-intensive pieces of an application auto-scaling, because one of the bottlenecks of today's hardware design tools is that they all rely on the local machine's resources to do the hardest parts, which include geometry rendering and analysis. The geometry engine parallelizes rendering and just sends video frames back to the app, and the API will offload analysis as it is built in.

So the app is a thin client by design, and that is a deliberate architectural bet with a clear cost. The 3D view depends on a network round trip to a hosted engine, and the analysis offload is described as something still being built. The README's own invitation to try the API, build your own applications or contribute to theirs is the clearest statement of the intent, which is a small team building a service rather than a desktop product.

React, CodeMirror, XState and a WASM language server

The technology list in the README is a map of the client architecture, and each choice has a reason.

The UI is React with Headless UI and TailwindCSS, and XState for state management. XState is the notable one. A CAD application is a complicated interaction machine, where a click can mean select, add, constrain or cancel depending on the current mode, and modelling that as a state machine rather than as ad-hoc boolean flags is what keeps the hybrid point-and-click and text editing paths consistent with each other. It is also why the application is written in TypeScript, which the repository confirms as the primary language.

The code editor is CodeMirror, with a custom WASM LSP Server for KCL. The LSP part is what makes the text side of the hybrid real, because an editor with a language server gets completion, diagnostics and go-to-definition for the modelling language rather than being a plain text box. The language server is written in Rust and lives in rust/kcl-lib/src/lsp/kcl, and the README points to a dedicated readme for KCL contributions.

Networking is WebSockets, via the KittyCAD TypeScript client, and modelling uses that same KittyCAD TypeScript client, so the protocol between the app and the engine is one API rather than two.

The repository is a monorepo with several toolchains in it. There is a packages/ directory with registry, codemirror-lang-kcl, codemirror-lsp-client and ui-components workspaces, plus a rust/ directory and a rust/kcl-language-server workspace. The app itself is Electron, with electron-builder.yml for packaging, electron-updater for updates and a forge.config.ts, and the Vite configuration is split across vite.config.ts, vite.base.config.ts, vite.main.config.ts and vite.preload.config.ts, which is the standard split for a Vite-built Electron app with a separate main and preload bundle. The download page is zoo.dev/design-studio/download, and the README says to file an issue if your platform or architecture is not supported there.

Three Playwright configurations for end-to-end, performance and Electron

The testing setup is where a project of this size usually shows its discipline, and this one has three separate Playwright configurations.

There is playwright.config.ts, playwright.electron.config.ts and playwright.performance.config.ts, with a playwrightProcess.mjs helper and an e2e/ directory. Three configurations for three different questions: a general end-to-end suite, a suite that drives the packaged Electron application rather than a browser, and a performance suite that measures something explicitly.

The performance configuration matters for this project in a way it would not for a typical application. The claim in the README is an order of magnitude rendering performance gain from a GPU-native geometry engine, and a performance test suite is how you would keep that claim honest across releases. There is also a separate release-notes.md and a pr-description-visitor-refactor.md at the root, which suggests the release notes are maintained with some care.

The Makefile shows the build in terms of source categories, and the categories are the project's own structure. CARGO_SOURCES covers the Rust workspaces, KCL_SOURCES covers the sample .kcl files under public/kcl-samples, RUST_SOURCES globs the Rust sources at four directory levels, REACT_SOURCES globs the tsx files, E2E_SOURCES the Playwright specs, TYPESCRIPT_SOURCES the tsconfig files and the TypeScript sources, and VITE_SOURCES the env files and the vite configs. Making the build depend on each of those separately means a change to a KCL sample triggers a rebuild, which is the sort of detail that matters when the samples are part of the product.

The default target is all: check test-unit, so the default action is a check plus unit tests rather than a build.

The bootstrap target sets up the toolchain with asdf, installing the just, nodejs and python plugins before running asdf install and npm run install:rust, and the wasm-pack binary is a Makefile target of its own, since it is needed to build the WASM parts of the language tooling. The Windows path is handled separately, using a different install script and a PowerShell export.

MIT licensed, with the KCL language versioned alongside the app

The licence is MIT, with the LICENSE file in the repository as the authoritative text, and this is a licensing statement rather than legal advice. The package.json records the license as MIT and the author as Zoo Corporation.

The release numbering is the detail that tells you how the project is structured. The recent releases are v1.5.1 on 2026-10-14, kcl-0.2.192 on 2026-10-14 and v1.5.0 on 2026-10-07. The app has its own version, and the KCL language has its own version, released independently and on the same day. That is a strong signal that the language is treated as a separate artefact with its own compatibility promise, which is what you would expect for something intended to be versioned and shared independently of the application.

The repository root has a lot of governance files for a project of this size. There is AGENTS.md, CONTRIBUTING.md, PRINCIPLES.md, GLOSSARY.md, INSTALL.md, a .helix/ directory for the Helix editor configuration, a .tool-versions file and a .nvmrc, plus a flake.nix and flake.lock, so there are two ways to pin the toolchain. The PRINCIPLES.md and GLOSSARY.md are the two that are unusual, and both suggest a project that is trying to be legible to people joining it.

The glossary matters for a domain-specific project. CAD has a large vocabulary of established terms, and a project that is inventing a hybrid workflow needs to say which existing words it uses in which sense, otherwise a contributor will assume the standard meaning and get it wrong. The principles file is the place where the design commitments in the README would be recorded more permanently, which is how a project stops a design decision from being an accident of whoever implemented it.

The package.json version field reads 0.0.0 and the package is private, which is the usual Electron convention where the app's real version comes from the release pipeline rather than from the manifest.

Editorial conclusion

Adopt Zoo Design Studio if you want CAD models as text files in version control and you are willing to have the geometry engine run remotely, since the 3D view is a video stream from a hosted engine rather than a local renderer. Do not adopt it if you need offline work, because the rendering and future analysis offload are server-side. Before you install, check that your platform and architecture are on the download list and file an issue if they are not, and read INSTALL.md, since the contributor path needs wasm-pack, a Rust toolchain and the asdf-managed Node, Python and just.

Frequently asked questions

Official sources

1. KittyCAD/modeling-app on GitHub
2. License: MIT
3. Project website
4. README
5. Releases