Why a chat panel, not a chat window
A CAD engineer's context is the open document. Copying properties into a browser tab and pasting code back is slow and error-prone. Both plugins therefore dock a chat panel inside the host — a FreeCAD workbench panel, an AutoCAD ribbon tab with a dockable palette — and give the model tools that read and change the document directly.
What the model gets to see
On every turn the agent sends a compact snapshot of the document: in FreeCAD the object tree with properties, sketch constraints and spreadsheet cells; in AutoCAD the layers, layouts, block inventory and schedule text. Snapshots are kept small and stable so prompt caching works — most of the prompt is identical between turns.
Beyond the snapshot the model calls read tools on demand: FreeGAD exposes every property and can measure geometry; AutoGAD has query_entities, get_block_inventory, get_layers, get_tables and get_context over the live DWG database.
Vision closes the loop. FreeGAD's take_screenshot renders the 3D view and sends it to the model, so after a change it can check whether the part looks right, not just whether the API call succeeded. That single tool removed most of the "it says done but it is wrong" cases.
Writes are gated, always
Every write tool — run_python, set_property, set_expression, delete_object in FreeCAD; replace_text, set_text, create_text, set_layer_state, set_custom_property, run_command in AutoCAD — opens a confirmation dialog showing the exact code or change, and each confirmed edit is one undo step. An auto-approve toggle exists for the times you trust the session. This is the difference between a demo and something you let near a drawing due tomorrow.
Memory that survives restarts
Both keep notes per user and per document — keyed by the FreeCAD document Uid, or by a fingerprint GUID stored in the drawing — plus a chat history per document. The model can write and read them (remember / forget), so decisions like "the PCB is 86.9 × 14.3 × 1.6 mm and sits on the base" stay attached to the file.
Providers, keys and cost
Both clients speak the Anthropic Messages API and any OpenAI-compatible endpoint, translating tool_use to tool_calls and mapping effort/reasoning settings across providers, with adaptive thinking on Claude. They are written on raw HTTP (Python stdlib; .NET HttpClient), no SDK. API keys are encrypted with Windows DPAPI. AutoGAD reports the token cost of every answer and of the session; FreeGAD has an opt-out anonymous telemetry backend (FastAPI + SQLite + SvelteKit dashboard) that records latency, token usage and GUI hangs.
Packaging
FreeGAD ships with a FreeCAD package.xml, an Inno Setup installer and an AGPL licence. AutoGAD has two installers: a per-user Inno Setup EXE with registry demand-load, and a per-machine WiX MSI carrying an Autodesk Autoloader bundle. AutoGAD is at version 1.0.5 and is what I use daily for electrical and lighting design documentation — its persona knows Russian working-documentation conventions (loads, breaker sizing, cable checks).
What I would do differently
Ship the screenshot tool first. Everything else is plumbing; the moment the model could see its own result, the quality of edits changed. And keep write tools narrow: a generic run_python is powerful, but the specific tools (set_property, replace_text) are what users actually approve without reading three times.