Back in March, I showed off a process that turned a photo into a Revit family. Upload an image, answer a few questions, and get a working family in the Family Editor. I called it a proof of concept and promised I’d come back and break down the thinking behind it.
It’s no longer a proof of concept. It’s now an open-source Revit add-in called Family Fabricator, or FamFab for short. You can download and install it today and start making families from images. So here’s the part I promised: how it actually works, and why I built it the way I did.
Watch the demo, and you’ll see it usually takes a couple of refinement passes to get close. That back-and-forth isn’t the tool failing. It’s part of the design, which I’ll explain in the next few sections.
Why not just point AI at Revit?
There are two obvious ways to solve the “I need a family that matches this image” problem.
The first is a content library. Go to BIMobject, manufacturer downloads, Revit City, wherever you find Revit content. But we all know the issue with this. Maybe you can’t find the exact model, or the dimensions don’t quite match. Sometimes you have an image but can’t find anything that matches it even somewhat closely.
The second is to hand an AI live access to Revit and let it build. This is the MCP server route, and I’ve written about it before. It’s impressive in a demo. But when the model drives the API directly, you’re trusting a result you can’t inspect. If it gets the geometry wrong, you find out after it’s already in your model, and you can’t easily see where the logic went sideways. It’s a black box that happens to produce Revit elements.
FamFab takes a third path. It splits the work into three stages, and each stage produces something you can review before moving on.
Three stages, all inspectable
Stage one: the model reads the image. You feed it a photo, a catalog screenshot, or a sketch. It identifies the object, picks a Revit category, and decomposes it into parts. A bookshelf becomes side panels, shelves, a top, a bottom, and a back. It estimates proportions and asks a few targeted questions to fill the gaps.
Stage two, the model writes JSON. This is the important part. It doesn’t produce an RFA file. It produces a structured data file that defines every extrusion, sweep, blend, reference plane, and subcategory, conforming to a schema I designed for this exact purpose. Because it’s just data, I can open it, read it, and check it. FamFab renders it in an interactive 3D viewer right in the add-in, so you rotate the model and adjust parameters before anything touches Revit.
Stage three, the add-in builds the family. Inside Revit, an executor reads the JSON and constructs the geometry, reference planes, and subcategories. Here’s the part I like: the executor doesn’t know or care that AI wrote the file. It reads the schema and builds. You could write the JSON by hand, and it would work just as well.
Three checkpoints, each one a place to catch a problem. If the model misreads the image, it shows up in the JSON. If the JSON has bad geometry, you catch it in the viewer. If something’s off in Revit, you trace it back to the data. Nothing happens that you can’t inspect first.
What changed since the demo
The March version was rough. Blends were defined in the schema but not actually implemented, so A-frame bench legs got approximated as rectangles. That’s fixed. The executor now handles extrusions, sweeps, and blends.
The 3D preview is new and genuinely useful. You rotate the model, adjust the parameters the model generated, and run a refinement pass, all before anything touches Revit. There’s also a Refine feature, so if the first result is close but not right, you send a follow-up prompt, and it takes another pass instead of starting over. The installer covers Revit 2025 through 2027, but you can build the code yourself for earlier versions.
Bring your own key
Here’s one design decision I think matters more than the geometry. This is one I expect to see a lot more of in the future.
To use FamFab, you need to provide your own Anthropic API key. There’s no backend or subscription. You don’t need to create an account with me. Your API key is stored locally on your machine, and your image and prompt go directly to the API, not anywhere else. The bench in my demo ran about 60 cents over a few refinement passes, roughly 20 cents per pass. Call it under a dollar to rough out a family in ten minutes.
Bring your own key, or BYOK, fits this kind of work better than a subscription. AEC tool usage happens in bursts. You might generate 20 families one week and none the next. Paying per use beats paying a flat monthly fee for a tool you touch occasionally. And for an open-source project, it’s close to the only honest option, because I can’t very well ship you a free tool that quietly burns through my own API budget every time you click a button.
It’s not friction-free, and I won’t pretend otherwise. You have to create an Anthropic account, generate a key, and accept a variable bill rather than a predictable one. For less technical users, that’s a real hurdle, and it means I can’t hand you a polished “just works” free tier. That’s the tradeoff, and naming it is the point.
The same logic applies to how FamFab handles models. Models change frequently, so the model list lives in an external config file rather than the source code. I’d been testing with Fable 5, which gave excellent results, right up until Anthropic suspended access to it under an export control directive. Rather than touch the code, I edited a text file to drop the model and kept working. Worth noting: Fable 5 cost more per run than the model I use now (Opus 4.8), but it usually nailed the family on the first try, so I ran fewer passes. Cheaper per call isn’t always cheaper per family. Your key, your model list, your call.
What’s still in the works
There are a few things I haven’t solved. FamFab takes one image, so it’s working from a single view. Multiple reference images, front, side, and top, would produce more accurate geometry, and that’s on the list. Families also come out without materials. And while the model generates parameters and the executor lays in reference planes, the dimensions that would let those parameters actually flex the geometry aren’t wired up yet, so the family is effectively static until you map them by hand. I tried full parametric early and pulled it because the constraints broke when you flexed the family, and inconsistent results are worse than limited ones. Doing it properly is the next real piece of work.
Go get it!
FamFab is available on GitHub under an MIT license, with an MSI installer so you don’t have to build from source. Bring an Anthropic API key, and you’re generating families in a few minutes.
If you want to contribute, the two highest-value places are the skill prompt, since better prompts make better families, and new geometry types like revolves. Both are right there in the source for you to fork and fine-tune.
Give it a try and let me know what you think.
Get the Thursday Top 5
My weekly email with five interesting and useful links on BIM, design, and technology, plus a few laughs along the way. I send it every Thursday. Join the over 8,000 AEC professionals who already get it.
