Claude Fable 5 Builds a CAD Editor and Designs in It

1. What the demo actually shows

At first glance, the Fable 5 CAD demo looks like “Claude made something in a CAD program.” But the more you look at the architecture, the more remarkable the structure becomes. Claude Fable 5 was not given an existing CAD editor and told to use it. It wrote the CAD editor itself — a full browser-based 3D modeling application. Then, within that editor, it built an AI copilot feature. And then it used that copilot to design a complete 3D-printable object.

The result is a three-layer system, each layer produced by the same model: Claude at the top orchestrating the process, the CAD editor as the middle-layer tool, and the AI copilot inside the editor as the mechanism through which Claude manipulates geometry. This is not a model using a pre-built tool. It is a model that identified what tool it needed, built that tool, embedded itself into the tool as a capability, and then used that capability to accomplish a design goal.

This kind of recursive tool construction is qualitatively different from anything demonstrated by previous generations of language models. Earlier models could write code for tools when explicitly asked, and they could use pre-existing tools when provided. What Fable 5 demonstrated is the capacity to close the loop spontaneously: to recognize a gap, produce the infrastructure to fill it, and then leverage that infrastructure — all within a single session without human scaffolding between the steps.

2. Meta-tool creation: a qualitative shift

There is a meaningful difference between an AI that uses tools and an AI that builds the tools it then uses. Tool use is relatively well understood: a model is given a set of pre-defined capabilities and calls them in the right order to accomplish a task. This is useful but fundamentally limited by the library of tools that already exists.

Meta-tool creation — an AI identifying what tool it needs, building it, and then using it — operates at a higher level of abstraction. The model must understand its own task well enough to recognize which capabilities would help it succeed, design those capabilities into a piece of working software, and then operate through that software as a user would. Each of these steps requires a different kind of competence: task decomposition, software architecture, implementation, and UI/UX reasoning.

The CAD demo is a clear case of all four working together. The task (design a 3D-printable object) made the need for a CAD environment apparent. The software architecture (browser-based, WebGL rendering, parametric geometry API) was chosen to match the task constraints and the execution environment. The implementation produced working code. And the AI copilot design allowed Fable 5 to operate the tool through a natural-language interface rather than imperative API calls — which is arguably the most elegant part, since it means the model can use its own strengths (language and reasoning) to drive the tool rather than generating raw geometry coordinates directly.

This pattern — “if the right tool does not exist, build it, then use it” — has profound implications for autonomous agents. It means capable agents are no longer limited to the tool ecosystems that humans have pre-assembled for them. They can extend their own tooling on demand. The practical ceiling on what an agent can accomplish rises significantly when it can build as well as use.

3. What Claude had to understand about 3D modeling

Producing a valid 3D-printable model is not trivial. It requires understanding a specific set of physical and geometric constraints that do not come up in ordinary text or coding tasks. Fable 5 had to engage with all of them to produce a design that could actually be sent to a printer.

Parametric modeling is the first concept. Rather than specifying absolute coordinates for every vertex, parametric models define shapes in terms of relationships and variables: a cylinder with diameter d and height h, a rectangular prism with corners inferred from width and depth parameters. This allows designs to be resized and adjusted without manually updating hundreds of numbers. Understanding parametricism means understanding that a CAD model is a program, not a static mesh.

Mesh geometry is the underlying representation: a 3D surface described by a set of vertices connected by edges to form faces (typically triangles or quads). Valid meshes must be manifold — every edge must be shared by exactly two faces, there can be no holes, and the surface must form a closed volume. Non-manifold geometry is a common error in generated 3D models and will cause slicers (software that prepares models for printing) to reject the file or produce bad prints.

Printability constraints go further. Overhangs — surfaces that extend horizontally past a certain angle — require support structures during printing or will droop and fail. Wall thickness must exceed a minimum (typically 1–2mm depending on material) or the printed wall will be too fragile. And the model must sit stably on the print bed, which means considering its base geometry and center of mass. Fable 5 had to reason about all of these constraints to produce a design that would survive the physical printing process.

4. The “build a tool, then use it” pattern in practice

The meta-tool pattern is not limited to CAD. It appears anywhere that a task would benefit from a specialized interface or intermediate representation that does not already exist. Consider a data pipeline: rather than writing a single monolithic script, a capable agent might first build a small DSL (domain-specific language) for describing data transformations, then write the pipeline in that DSL. The DSL becomes a tool that makes subsequent modifications clearer and less error-prone.

The same pattern applies to custom UIs: an agent building a dashboard for a specific data set might first write a charting component tailored to that data’s structure, then use the component to compose the full dashboard. Or to agent orchestration itself: an agent building a complex multi-step workflow might first write a task-queue manager, then orchestrate its subtasks through that manager. In each case, the investment in building the tool pays off in the quality and reliability of the work done through it.

What makes this pattern powerful is the feedback loop. When an AI builds the tool it uses, it designs the tool’s interface with its own strengths and limitations in mind. Fable 5 built a natural-language copilot for the CAD editor rather than a raw coordinate API — almost certainly because it knew it could drive a natural-language interface more reliably than it could generate precise floating-point coordinates. The tool is designed to be used by the builder, which tends to produce tools that are well-matched to the task.

Build me a [tool name] as a single HTML file that I can open in a browser.
Requirements:
- All logic in one file (no external dependencies)
- Clean, usable interface
- [describe your specific requirements]

Do not explain the code — just produce the file.

Here is the tool you built: [paste the HTML]

Extend it to also support [new capability]. Keep everything in one file.

Using the tool logic you built, calculate/generate/process [specific input].
Walk through what the tool would produce step by step.

Looking at what we just did: you built a tool, then used it.
In what other situations in my work would this pattern — build a specialized
tool first, then use it — produce better results than trying to do everything
in one pass?