Why No CAD/PLM Vendor Has a CLI — And What That Tells You
Autodesk archived theirs. PTC, Dassault, Siemens never built one. Zero CLI tools across $200B+ of market cap. The absence is the signal.
TL;DR: $200 billion in combined market cap. Four of the largest engineering software companies on Earth. Not one of them ships a CLI💻CLIText-based interface for running commands.View in glossary for their platform APIs. This is not an oversight. It is a tell.
The Landscape: Four Giants, Zero CLIs
Every major platform outside of engineering software has a CLI. AWS has aws. Azure has az. Google Cloud has gcloud. GitHub has gh. Vercel, Netlify, Fly, Railway — they all ship CLIs on day one, because they understand that developers automate things.
Now look at the engineering software industry: Autodesk, PTC, Dassault, Siemens. Combined market capitalization north of $200 billion. REST🌐RESTWeb service architecture style using HTTP.View in glossary APIs across the board. And not a single maintained CLI tool between them.
Let that sink in. Every one of these companies has a REST API. Every one of them has a developer program. Not one of them ships a CLI.
The Evidence, Vendor by Vendor
Autodesk: Built One, Then Killed It
Autodesk is the most interesting case because they actually tried. forge-cli existed. It could scaffold projects and manage some API interactions. Then Autodesk rebranded Forge to APS (Autodesk Platform Services☁️APSAutodesk Platform Services - cloud APIs for CAD/BIM automation.View in glossary), and forge-cli was quietly archived. Last commit: years ago. README: “archived.”
The community tried to fill the gap. aps-cli prototypes appeared on GitHub. They were abandoned too. Without official backing, maintaining a CLI against a moving API surface is a losing proposition.
And here is the number that should haunt every developer advocate at Autodesk: 4,078 apps on the Autodesk App Store. Zero CLI tools. Zero auth helpers. Zero MCP🧠MCPProtocol for AI assistant tool integration.View in glossary integrations. We documented this in our ACC forum analysis. The App Store is a graveyard of GUI plugins. Developer tooling simply does not exist in their ecosystem.
PTC Onshape: The API Without Automation
Onshape has one of the more developer-friendly REST APIs in the CAD📐CADSoftware for creating technical drawings and 3D models.View in glossary world. Full OpenAPI spec. Decent documentation. And absolutely no CLI.
Developer forum requests for automation🤖AutomationReplacing manual processes with software.View in glossary tooling go unanswered. Community Python scripts are scattered across GitHub repositories — unmaintained, version-pinned to specific API revisions, and breaking regularly. PTC has the foundation for great developer tooling and has built none of it.
Dassault 3DEXPERIENCE: The Platform That Forgot Developers
Dassault’s 3DEXPERIENCE platform is web-first, which should theoretically make it more API-friendly. In practice, the “API Framework” documentation reads like an afterthought. The developer community is fractured across SOLIDWORKS, CATIA, and ENOVIA ecosystems, each with its own authentication model, its own API surface, and its own set of frustrations.
A CLI that could unify these? Never considered. The mental model at Dassault is that users interact through a browser. Full stop.
Siemens Teamcenter: Java Clients or Nothing
Teamcenter exposes SOA services and, more recently, REST APIs. But automation requires building custom Java or C++ SOA clients. Even basic operations — creating a folder, uploading a file, checking user permissions — require either a GUI or a thick client.
The barrier to entry for any kind of scripting is enormous. You do not “quickly automate” anything in the Teamcenter ecosystem.
Why This Matters: A CLI Is a Statement of Values
A CLI is not just a developer tool. It is a declaration of how a company views its developer community.
- + You treat developers as first-class users
- + You believe in automation and scriptability
- + You invest in CI/CD🔁CI/CDAutomated build, test, and deployment pipelines.View in glossary, DevOps, and reproducible workflows
- + You see your API as a product, not a checkbox
- + You enable power users to compose, automate, and extend
- - APIs are an afterthought, not a product
- - You expect users to click, not code
- - Automation is someone else’s problem
- - Scripting, testing, and CI/CD are unsupported use cases
- - Your developer ecosystem cannot grow
The absence reveals the vendor’s mental model. Their users click. They do not code. And if they do code, they are on their own.
The Deeper Signal: No CLI Means No Ecosystem
Here is where the absence gets expensive. A CLI is not just convenient — it is foundational infrastructure for everything else developers want to build.
CLIs enable:
- CI/CD pipelines — upload a model, trigger translation⚙️Translation JobBackground process converting CAD files to viewable formats.View in glossary, validate output, all in a GitHub Action
- Scripting and batch operations — rename 500 files, update permissions across 30 projects, export all RFIs
- Testing — automated integration tests against live APIs
- AI integration — MCP servers, LLM tool-calling, agent workflows
- Composability — pipe output from one command▶️CommandInstruction executed by a CLI tool.View in glossary to the next, build workflows from primitives
Without a CLI, developers build throwaway scripts. They curl endpoints by hand. They hardcode tokens. They write Python wrappers that break on every API change. There is no foundation to build on.
The App Store gap we documented — 4,078 apps and zero developer tools — is not a coincidence. It is a direct consequence of the missing CLI. You cannot build developer tooling on a platform that does not treat developers as users. The ecosystem never forms because the foundation was never laid.
What RAPS Built
RAPS🌼RAPSRust CLI for Autodesk Platform Services.View in glossary exists because this gap is unacceptable. The CLI that Autodesk archived covered a handful of scaffolding commands. RAPS replaced it with 50x the scope.
What every vendor should ship but none do:
# List your hubs
raps hub list
# List projects
raps project list --hub-id "b.account-id"
# Pipe folder contents through jq
raps folder contents "project-id" "folder-id" --format json | jq '.data[].attributes.name'
# Manage users from the command line
raps admin user add "$ACCOUNT" "user@company.com" --role project_admin
# Trigger model translation
raps translate start "urn:..." --output svf2
# Chain multi-step workflows in a single YAML file
raps pipeline run upload-translate.yaml
Shell completions for bash, zsh, fish, and PowerShell. JSON📋JSONStandard data interchange format.View in glossary, table, and CSV📊CSVTabular data format for spreadsheets.View in glossary output for scripting. A pipeline system for multi-step🔧STEPISO standard for 3D CAD data exchange.View in glossary workflows that would take hours of clicking through web UIs.
This is not revolutionary technology. It is table stakes. Every other developer platform figured this out a decade ago. The CAD/PLM industry simply never bothered.
The Absence Is the Signal
When four companies worth a combined $200 billion all make the same decision — no CLI, no developer tooling, no scriptable interface — it tells you something about the industry’s relationship with developers.
They do not see developers as their users. They see developers as a necessary inconvenience: people who need API access occasionally, who can figure it out themselves, and who do not warrant the investment of a maintained CLI.
That mental model is why the AEC tech ecosystem is a decade behind cloud infrastructure, why CI/CD for construction data is essentially nonexistent, and why the Autodesk App Store has 4,078 apps and zero developer tools.
The gap is the signal. And RAPS is the response.
Next in series: 4,078 Apps and Zero Developer Tools — The App Store gap is even worse than the CLI gap.