Option 1: Action Recorder (Built In, Single Session)
AutoCAD's Action Recorder captures a sequence of commands as a replayable macro. It's genuinely useful for what it is: standardizing a repetitive sequence you perform inside one drawing, shareable with teammates who trigger it manually.
What it is not is a batch tool. There's no native mechanism to run an action macro across a folder of drawings, no error handling, and recorded macros break when a prompt sequence changes. Teams sometimes chain it with scripts to fake a batch, but at that point you're better served going straight to a real script.
Verdict: use it to standardize in-session sequences; look elsewhere the moment the word "folder" enters the requirement.
Option 2: ScriptPro (Legacy, Avoid for New Work)
ScriptPro is Autodesk's old free utility that applies a .scr script to a list of drawings: point it at a script and a file list, and it opens each drawing in AutoCAD and runs the script. If you search "AutoCAD batch processing," decade-old forum threads recommending it still rank, which is why it makes this list.
The honest status in 2026: ScriptPro is unsupported legacy software from a different era of AutoCAD. It drives full AutoCAD sessions (so you pay GUI overhead per drawing), it predates modern licensing and security models, and when it fails mid-list it fails opaquely. Everything it did, AcCoreConsole plus a ten-line wrapper does faster and more controllably.
Verdict: if you have a working ScriptPro setup, plan its retirement; don't build anything new on it.
Option 3: AcCoreConsole (The Default Answer)
AcCoreConsole is the headless AutoCAD engine that ships free with every installation since 2013: the full drawing engine, no GUI, driven entirely by scripts and command-line switches. For unattended, on-premises batch work it is the tool the other options get measured against:
- Speed: sub-second startup, under 100MB RAM, roughly 5x faster than full AutoCAD on real batches (145 drawings: 11 minutes vs 58).
- Parallelism: one process per drawing means you can run several instances at once and a corrupt drawing kills one process, not the batch.
- Ceiling: scripts handle uniform operations; .NET plugins raise the ceiling to full conditional logic and ERP/PLM integration.
- Costs to respect: no dialogs, no vertical-product commands, no COM/VLA LISP layer, and no official Autodesk support. Our script recipes and troubleshooting guide cover the practical side of both.
Verdict: the default choice for on-premises batch processing when you have AutoCAD licenses. Start here; leave only when you hit one of its hard walls.
Option 4: In-Session Automation (Full AutoCAD, Scripted)
Running the batch inside full AutoCAD, driven by the SCRIPT command, a LISP loop, or an external program automating AutoCAD through COM or a .NET plugin. You pay GUI overhead per drawing and you generally can't parallelize (full AutoCAD is effectively single-instance), but everything works: dialogs can be scripted around, vertical products (Mechanical, Electrical, Plant 3D) keep their commands, Express Tools exist, and legacy LISP that leans on the COM layer runs unmodified.
This is the right tool more often than automation purists admit. If your batch depends on AutoCAD Electrical commands, or on a 4,000-line LISP library nobody wants to port this quarter, a slower batch that works tonight beats a faster architecture that works next quarter.
Verdict: the fallback when the job needs capabilities the core engine doesn't have. Accept the 5x runtime penalty; schedule it overnight.
Option 5: APS Design Automation (The Cloud Engine)
The Autodesk Platform Services Design Automation API runs essentially the AcCoreConsole engine on Autodesk's cloud: you upload work items, your plugin code runs against drawings in Autodesk's infrastructure, results come back via web APIs. No local AutoCAD required.
- Where it wins: web applications and product configurators whose end users don't own CAD software; elastic scale (a thousand drawings in parallel without owning a render farm); no batch machines to maintain.
- Where it loses: per-transaction cost (Flex tokens) on high-volume internal batches that a licensed machine would process for free; drawings must leave your network, which data-sensitive industries can't accept; development requires the same .NET skills as a core console plugin plus cloud plumbing.
Verdict: right when the consumer of the automation is outside your CAD department: customers, dealers, a web portal. Rarely the economical answer for internal library maintenance.
Side-by-Side Comparison
| Criterion | Action Recorder | ScriptPro | AcCoreConsoleDefault pick | In-Session | APS (Cloud) |
|---|---|---|---|---|---|
| Multi-drawing batch | No | Yes | Yes | Yes | Yes |
| Relative speed | n/a | Slow (GUI) | Fast (5x) | Slow (GUI) | Elastic |
| Parallel processing | No | No | Yes | No | Managed |
| Dialog/GUI commands | Yes | Partly | No | Yes | No |
| Vertical products (Mech/Elec/Plant) | Yes | Partly | No | Yes | No |
| COM/VLA LISP | Yes | Yes | No | Yes | No |
| Data stays on-premises | Yes | Yes | Yes | Yes | No |
| Extra licensing cost | None | None | None | None | Metered |
| Supported by Autodesk | Yes | No | Unofficial | Yes | Yes |
| Skill required | None | Low | Low to high | Low to high | High |
Green = strength · Red = hard limitation · Amber = works with caveats · Grey = neutral fact. The highlighted column is the default recommendation for on-premises batch work; the sections above explain when to deviate from it.
Which One Should You Use?
Walk the questions in order; stop at the first yes.
- Do end users without AutoCAD need to trigger the automation (customers configuring products, a sales portal generating drawings)? Then it's APS Design Automation, and the real project is the application around it.
- Does the operation need vertical-product commands, Express Tools, dialogs, or COM-dependent LISP you won't port? Then batch inside full AutoCAD in-session and schedule around the runtime.
- Is it a uniform operation across many drawings on your network? AcCoreConsole with scripts. This is the bucket most batch jobs land in: plotting, purging, format conversion, title block stamps, xref surgery.
- Does the operation vary by drawing content, or feed from ERP/PLM data? AcCoreConsole with a custom .NET plugin: same engine, real logic.
- Is it a sequence you repeat inside one drawing at a time? Action Recorder or a simple script; you don't have a batch problem yet.
The pattern across our client base: mature engineering teams end up with AcCoreConsole for internal batch work and APS for anything customer-facing, with a shared .NET codebase behind both, since the two engines expose the same managed API. That shared-codebase architecture is usually the difference between maintaining one automation platform and maintaining three.
If you're sizing up a batch processing project and want a second opinion on the architecture, or you have the architecture and need the plugin built, talk to us. We build on all five of these, so you'll get the recommendation that fits the job rather than the tool we happen to sell. For the wider landscape beyond batch work, see our guide to drawing automation software.