The seat most drafting offices actually pay for
AutoCAD LT gained AutoLISP in the 2024 release. For a version whose entire identity for thirty years was “the one you cannot customise”, that was a genuinely big change, and it went past most people without a ripple.
It matters now for a reason nobody planned. Ask a chatbot for an AutoLISP routine and it will happily reach for vlax-ename->vla-object and vla-get-Name, because decades of published forum code does exactly that, and that code is what these models learned from. Whether the result runs on your LT seat depends on details most of the internet gets wrong — in both directions.
So here is what Autodesk actually documents, quoted rather than summarised, and a way to tell at a glance whether a generated routine will run.
The claim you can stop repeating
You will read, often, that AutoCAD LT has no ActiveX and that anything starting vla- or vlax- is off the table. That was true once. It has not been true since the 2024 release.
From Autodesk’s own “What’s New or Changed with AutoLISP” page in the AutoCAD LT 2024 AutoLISP Developer’s Guide:
Most VL*, VLA*, VLAX*, and VLR* functions are supported, but the use of third-party automation libraries is not supported in to AutoCAD LT.
(The “in to” is Autodesk’s typo. Quoted as found.)
“Most”, not “none”. What LT actually excludes is a short, named list, and it is worth memorising because it is smaller than you would guess:
vlax-create-objectvlax-get-objectvlax-get-or-create-objectvlax-import-type-libraryvla-GetInterfaceObject
Look at what those five have in common. Every one of them is about reaching outside AutoCAD — instantiating or grabbing an external automation object. That is the actual boundary: LT will talk to the drawing through ActiveX perfectly well, but it will not drive Excel.
Autodesk names three more limits in the same list:
VLA* functions related to creating and modifying 3D solid and surface, helix, material, multiline objects among others that can only be created in AutoCAD
entmake, entmakex, and entmod functions only allow for the creation and modification of objects supported in AutoCAD LT
AutoLISP functions exposed by custom ObjectARX and Managed .NET programs can’t be used
And one oddity that reads like a footnote but will bite anyone writing profile-handling code: “PreferencesProfiles object exists as part of the ActiveX implementation, but all of its methods and properties have been removed since profiles are not supported in AutoCAD LT for Windows.” The object is there. It does nothing.
What is genuinely missing from LT
The exclusions above are about what code can do. These are about how you work on it — and this is where LT users get caught out following a tutorial written for full AutoCAD.
| Thing | In AutoCAD LT for Windows? |
|---|---|
| AutoLISP and DCL | Yes, from the 2024 release |
| Visual LISP IDE (VLIDE / VLISP commands) | No |
| Debugging with the AutoLISP Extension for VS Code | No |
| Running compiled LSP files | Yes |
| Compiling LSP files | No — full AutoCAD only |
| MNL auto-loaded with a matching CUIx | No — load it explicitly with load |
Express Tools (acet- functions) |
No — not part of LT at all |
Autodesk on the editor, verbatim: “The Visual LISP integrated development environment (IDE) is not available in AutoCAD LT for Windows or on Mac OS.”
That one deserves a moment, because it changes the argument of this whole series. On full AutoCAD you at least have an IDE to load code into. On LT you have Notepad and the command line. A generated routine that calls a function which does not exist will load silently and sit there until the branch that calls it runs. There is no editor to catch it and, as ever, no linter and no compile step. The case for reading generated code carefully is strongest exactly where the tooling is thinnest.
Express Tools is the quiet one. Those acet- functions — acet-str-replace, acet-ss-drag-move and the rest — sit in the same alphabetical index as assoc and angtos in Autodesk’s AutoLISP Reference, with nothing separating them. A model that learned from that index has no reason to treat them differently. They are a separate install, and they are not in LT.
The line that actually matters: the operating system
Here is the thing most discussions of LT get backwards. The sharp portability boundary is not LT versus full AutoCAD. It is Windows versus everything else.
Autodesk’s vl-load-com reference page states its supported platforms as: “Windows only; not available on Mac OS or Web”.
ActiveX is loaded by vl-load-com. So every vla-, vlax- and vlr- function in existence is Windows-only, on any product. Meanwhile command-s is documented as “Windows, Mac OS, and Web”, and plain command, entget, ssget and the rest of core AutoLISP have no such restriction.
Which gives a rule of thumb worth more than the exclusion list:
A generated routine that reaches for ActiveX is a Windows routine. It will probably run on LT for Windows. It will not run on a Mac or in the browser.
Take the undo group as the worked example. Both of these do the same job:
; portable - command is core AutoLISP, no extensions required
(command "._UNDO" "_Begin")
;; ... your work ...
(command "._UNDO" "_End")
; Windows only - ActiveX, requires (vl-load-com)
(vl-load-com)
(setq doc (vla-get-ActiveDocument (vlax-get-acad-object)))
(vla-StartUndoMark doc)
;; ... your work ...
(vla-EndUndoMark doc)
Models emit the second form regularly, because a great deal of forum code uses it. The first form does the same work and runs everywhere. That is a sourced reason to prefer it rather than a matter of taste.
One honest caveat on this, since being precise is the point of the article. Autodesk says “Most” VLA* functions are supported in LT and does not name vla-StartUndoMark either way. It is not on the exclusion list, so there is every reason to expect it works on LT for Windows 2024+ — but Autodesk has not said so in as many words, and we are not going to put words in their mouth.
How to check, in the routine itself
Autodesk documents the guard, and it is one line. From the same LT page:
Programs that utilize functions and commands that are limited to AutoCAD should check which product they are being loaded into to avoid compatibility problems. This can be done using the PROGRAM system variable, a value of acadlt is returned for AutoCAD LT.
Their expression:
(if (/= (strcase (getvar "PROGRAM") T) "acadlt")
Wrapped into something you would actually ship:
(defun c:MYTOOL ( / lt )
(setq lt (= (strcase (getvar "PROGRAM") t) "acadlt"))
(if lt
(progn
(prompt "\nRunning in AutoCAD LT - using the portable path.")
;; core AutoLISP only: command, entget, ssget, tblsearch
)
(progn
(vl-load-com)
;; full AutoCAD: third-party automation, 3D solids, ObjectARX-exposed functions
)
)
(princ)
)
If you are handing a routine to an office running mixed seats, that check costs one line and saves the support call.
A short review pass for LT users
Before a generated routine goes near a live drawing on an LT seat, read it for these:
| Look for | Verdict on LT for Windows 2024+ |
|---|---|
vlax-create-object, vlax-get-object, vlax-get-or-create-object, vlax-import-type-library, vla-GetInterfaceObject |
Will not work. Named exclusions. |
| Anything driving Excel, Word or another application | Will not work. Third-party automation is excluded. |
acet- anything |
Will not work. Express Tools is not in LT. |
| 3D solids, surfaces, helix, material, multiline creation | Will not work. |
entmake / entmakex / entmod on an object type LT cannot create |
Will not work. |
Other vla- / vlax- / vlr- calls |
Expected to work — but only on Windows, and only with (vl-load-com) present. |
Missing (vl-load-com) before any vla- call |
May work by luck this session. Fix it. |
Core AutoLISP: command, entget, ssget, tblsearch, setvar |
Fine, and portable beyond Windows. |
The short version: most generated AutoLISP will run on a modern LT seat, and the failures are concentrated in a list you can hold in your head. The bigger risk on LT is not what the language cannot do — it is that you have no IDE to catch a made-up function name before it fires.
For that, see the paste-in function allowlist, which labels the Express Tools and LT-excluded names explicitly. The wider pattern is in what actually breaks in AI-generated AutoLISP, and there is a worked line-by-line review of a generated routine. We also covered LT’s arrival into the AutoLISP world, and what it means for driving AutoCAD from a model, in Claude + AutoCAD via MCP.
References
- What’s New or Changed with AutoLISP — Autodesk, AutoCAD LT 2024 AutoLISP Developer’s Guide. LT gains AutoLISP and DCL; the “Most VL*, VLA*, VLAX*, and VLR*” statement; the named exclusion list; PreferencesProfiles; compiled LSP; MNL loading; the PROGRAM guard.
- Visual LISP IDE availability — Autodesk, AutoCAD LT 2024 Help. “not available in AutoCAD LT for Windows or on Mac OS”.
- About Using the VLA- Functions With ActiveX Methods — Autodesk, AutoCAD LT 2024 Help. ActiveX limited to Windows; no third-party automation libraries.
- vl-load-com (AutoLISP/ActiveX) — Autodesk AutoLISP Reference, AutoCAD 2024. “Windows only; not available on Mac OS or Web”.
- command-s (AutoLISP) — Autodesk AutoLISP Reference, AutoCAD 2024. Supported platforms: Windows, Mac OS, and Web.
- About Undoing Changes Made by a Routine (AutoLISP) — Autodesk AutoLISP Developer’s Guide, AutoCAD 2024. The
._UNDOBegin/End form. - StartUndoMark Method (ActiveX) — Autodesk ActiveX Reference Guide, AutoCAD 2024. “Supported platforms: Windows only”.
- A Functions Reference — Autodesk AutoLISP Reference, AutoCAD 2026. Where the
acet-Express Tools functions sit alongside core functions. - Claude + AutoCAD via MCP: AI Drafting on AutoLISP (2026 Guide) — blog.draftsperson.net.
- AutoLISP for AutoCAD: Tutorials and 139 Free Routines — blog.draftsperson.net.