Using Claude for 3D Print Design — How Far Has AI CAD Come with Fable 5?

However strong the new Claude generation is, a maker asks one question: how much easier does my actual design work get? Not benchmark numbers — your own workflow. This is that field test. We ran our established code-CAD workflow on the Claude Fable 5 generation and recorded what changed and what did not, with zero embellishment.

The promises of this test — what we measured and what we did not

Our editorial policy is simple: never publish a number we did not produce. The measurements here are design generation in a Claude Fable 5 session in Claude Code on July 19, 2026, plus desk-check verification of the output — syntax and variable consistency, hole positions, and engraving interference confirmed by hand calculation. The test machine had no OpenSCAD runtime, so rendering, printing, and physical fit measurements are outside this article’s scope.

We also do not publish quantitative comparisons against older models — round-trips reduced by N, minutes saved — because we did not run controlled comparative measurements. Numbers like “feels twice as fast” without stated conditions are noise wearing a suit. Not writing them is part of the quality. AI performance talk is currently the easiest place for exaggeration to hide: models update fast, verification lags, and impressions circulate dressed as data. So we state the verification level with the same weight as the results. What we want you to take away is not “wow” but a procedure and checkpoints for confirming this in your own environment.

The starting point — code CAD as the best test bench

Why OpenSCAD? Code CAD describes shapes as programs, and its input and output are entirely text — which makes model capability differences appear in verifiable form: code correctness, parameter design quality, and adherence to revision instructions, rather than vague “looks about right.” Compare generative mesh models, where evaluation drifts toward plausible appearance and dimensions have no inspectable origin. In code CAD every dimension is a variable, every change is a diff, and every error is traceable to a line. The design conversation becomes “increase this variable by 0.2” instead of “a bit bigger” — a verifiable language.

For the subject we chose the tolerance test plate from our functional-parts series — the test piece that measures your printer’s personality, and the starting point of practical part-making. Not too simple, not too complex, and it exposes the quality of design judgment: how parameters are held, how printing is considered. It is also easy to replicate: the prompt is one sentence, the requirements are numeric, and the pass criteria are written below — so you can run the same experiment on your own model and plan and compare against our observations. If your results differ, that is a finding worth sharing. Note your plan and effort settings; first-shot quality can vary with them.

The run — asking for a tolerance test plate

The prompt: “A tolerance test plate in OpenSCAD for a 10mm shaft. Hole diameters from 9.8mm to 10.6mm in 0.1mm steps, parametric. A flat plate that prints easily.”

The prompt design is deliberate. It gives purpose (tolerance testing), reference (10mm shaft), range and step (9.8-10.6mm, 0.1mm) — and deliberately omits implementation details like plate dimensions or hole layout. Over-specify the implementation and you can no longer see the model’s design judgment. Hand over goals and constraints, leave discretion — the instruction style that fits the adaptive thinking generation.

The skeleton of the first response (the whole file was just under 20 lines including variable definitions):

clearances = [-0.2, -0.1, 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6];
pitch = 8;
margin = 10;
plate_w = margin * 2 + pitch * (len(clearances) - 1);

difference() {
    cube([plate_w, plate_d, plate_h]);
    for (i = [0 : len(clearances) - 1])
        translate([margin + i * pitch, plate_d / 2, -1])
            cylinder(h = plate_h + 2, d = shaft_d + clearances[i], $fn = 96);
}

Look at the judgments we did not ask for. Plate width is not a fixed value but computed from hole count and pitch. Clearances live in an array, so adding a hole is a one-line change. The subtracted cylinders extend 1mm beyond the plate on both faces, avoiding boundary-surface artifacts. The single word “parametric” was interpreted all the way to choosing structures that survive change. Desk checks found variables consistent and edge margins clean.

A note for readers who do not read code: this method works without programming skills. Ask the follow-up “list the things about this design that could cause problems when printed, with reasons,” then judge whether the self-review is coherent and internally consistent — the same skill as editing prose. A supervisor needs good questions and criteria, not implementation ability.

What came out in one shot, and what took a second

Was it done in one shot? No. Viewed as a printed tool, two things were missing: no chamfer on the hole entrances, so shafts catch on insertion; and no engraved clearance values, so after printing you cannot tell which hole is which. When we added these two items from our checklist, the second response integrated chamfer cones and text() engraving of clearance values without breaking the existing parametric structure. Engraving positions clear the holes by desk calculation.

The pattern is clear. Code correctness and structural quality are already high in the first response. What remains is the “circumstances of the person who will hold the print” — ease of insertion, ease of identification, your machine’s quirks — and that comes from the instructor’s knowledge. Our functional-parts design checklist worked unchanged as an instruction list for the AI. The stronger the tool, the more the orderer’s design literacy separates outcomes — a relation no generation change has touched.

Generalizing the two gaps, the checkpoints form three bundles. Insertability and assembly: chamfers, reliefs, tool clearances — everything about the moment of touch. Identifiability: engravings and orientation marks that matter in use after printing. And machine-specific correction: your printer’s shrinkage and habits, which no one can write without measured values. As the AI’s first shot gets stronger, these three bundles are what remain — purified — as the human role.

What giant context brings to AI CAD

This small run needed none of Fable 5’s headline 1M-token context; a part this size fits comfortably inside the default Sonnet 5. So where does giant context matter? Session lifespan. Real design work does not end at one part. Picture replicating a discontinued appliance part: observing the broken piece, measuring, checking mating parts, choosing material, reinforcing weak points, test-printing, revising — each stage builds numbers and decisions that later stages depend on. A case leads to a lid, bosses, board reliefs, cable paths, every decision constraining the next. Holding that history without dropping it is what large context means in practice.

So Fable 5-class context earns its keep in project-scale design dialogue, not single-part generation — which yields the healthy inverse: daily small prints do not need the top model. And whatever the window size, keep the design ledger habit: a short text file of decided dimensions, materials, and measured values pasted at the top of each session. The ledger travels across sessions, models, and outages. Large context is not a replacement for the ledger; it is an amplifier for the long conversations the ledger anchors.

Why we skip old-versus-new comparisons — and how to run your own

Instead of comparison numbers, here is the method. Dig three past design tasks that went badly with AI — structure collapsed mid-way, instructions would not land. Resubmit the same prompts to the current model and record: the initial prompt, round-trips to completion, and what knowledge you had to supply. That third item is the one to watch — how “what the AI could not reach” changes across generations is a record no public benchmark will ever hold, because public benchmarks are someone else’s problem set. Your failure archive is the only benchmark that reliably speaks for your workload.

The maker’s wallet — do you need Fable 5?

Face the costs. Fable 5 runs on usage credits under subscriptions and $10/$50 on the API. Meanwhile Sonnet 5, now the Pro default, carries 1M context at no extra cost, and Opus 4.8 is $5/$25. This run showed part-level code CAD sits entirely inside the default models’ range. The rational maker setup: run daily design on Sonnet 5 and Opus 4.8, and hold Fable 5 credits for the long design sessions where you want one conversation to carry a whole project.

Plan choice follows. A weekend maker printing small items and single functional parts will rarely feel a gap on Pro’s default setup. Someone running multi-part projects continuously, or working AI across design, firmware, and writing, fits a higher plan with Opus 4.8 as the daily driver and credits saved for a few decisive sessions a month. Either way, measure for one month on your current plan before moving — wallet answers come from measurements too. Like pay-per-use CAD platforms, premium tools pay off only with designated use cases. And remember the supply lesson: keep design prompts and code assets in your own repository. Text assets survive every model change and every stoppage — the two artifacts from this run became model-independent design assets the moment they entered the ledger.

What AI does not change — calipers and the measuring culture

Finally, the stage no model generation touches. The generated test plate means nothing until printed and measured. Do your printer’s holes shrink from nominal, and in which orientation? That answer lives in your machine, not in any AI. The measuring culture matters more in the AI era, not less: the faster generation gets, the more verification becomes the rate-limiting step. AI can carry the design, but the supplier of measured reality is always human. The moment you bring a caliper-measured 0.2mm into the conversation, the output turns from generic advice into design for your machine.

There is a pattern for handing over measurements: declare once — “on this machine, PLA holes at 10mm nominal measured X; use this correction as default from now on” — write it into the design ledger, and pass the ledger into every session. The correction stops being something you remember per-prompt and becomes a precondition that compounds. The unprinted test plate is exactly the tool for writing that first ledger line: print it, insert the shaft into nine holes, read the engraving on the one that fits best. From that one line, your AI design environment becomes genuinely yours — the first ritual of teaching a general intelligence your specific machine.

Closing — tools advance, principles hold

Three conclusions from the run. First-shot quality in code CAD is high, including parametric structuring — practical from response one. The remaining delta is the user’s circumstances, which raises, not lowers, the value of a design checklist. And giant context pays in project-length dialogue while daily part work fits the defaults. The principles from our functional-parts series — measure tolerances on your machine, back numbers with measurements, keep assets in text — have not aged a day. Three actions for today: reproduce this prompt and print the plate; write the fit measurement as ledger line one; and pick three old failures to start your own model-evaluation archive. Under an hour each, and none loses value however many generations pass.

Field test record: July 19, 2026, Claude Fable 5 session in Claude Code. Generated code desk-checked; printing and fit measurement left as the reader’s reproduction procedure.

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.