Extending Your Slicer — Plugins, Post-Processing Scripts or the CLI, and How to Live with Alpha Builds

When you want to add a feature to your slicer, there is more than one way in. As of 2026-10-20, OrcaSlicer 2.5.0-alpha (10-16) has Python plugins and PrusaSlicer 3.0.0-alpha11 (09-01) has Lua plugins (the source this article refers to is the subsequent alpha12). Meanwhile, post-processing scripts that rewrite exported G-code from the outside have existed for a long time, and so has the CLI for slicing large numbers of files without opening the interface. All of these can be called “extending the slicer”, but what they can do, how mature they are and which language you write them in all differ.

This article contains affiliate links. As an Amazon Associate, we earn from qualifying purchases.

This article is a reverse lookup for extending your slicer, organized by “what you want to do”. First we separate three terms, then tabulate which mechanism to choose for each goal, and finally cover how to try versions that are still alpha or beta. Plugins are code, so AI can write them. We touch on that angle in the text, but it is faster to have a map of the mechanisms before you start working. The four slicers covered are OrcaSlicer, PrusaSlicer, UltiMaker Cura and Bambu Studio, all distributed free or as open source.

First, separate three terms — plugins, post-processing scripts and the CLI

The source of confusion is that three separate mechanisms sit close to one another. Here we use them as follows.

• Plugin: extra code that the slicer loads and runs inside itself. OrcaSlicer uses Python, PrusaSlicer uses Lua, and UltiMaker Cura uses Python
• Post-processing script: a mechanism that passes the G-code written after slicing to an external program for rewriting. Any language will do
• CLI: using the slicer from commands, loading models and slicing them without opening the interface (GUI)

The three do not overlap in role. A plugin runs inside the slicer, a post-processing script works on the exported G-code from outside, and the CLI runs without opening the interface at all. From here on, this article does not mix these three terms.

Let us separate the names of the safety mechanisms too. OrcaSlicer uses a “permission system”, and its release notes state that “this is a permission system, not a sandbox”. PrusaSlicer uses a “sandbox”, and its developer documentation says the plugin runtime is “intentionally limited and sandboxed”. The defensive setups differ, so we keep these two terms distinct to the end as well.

One assumption to clear up here. Plugins as a mechanism are not new. UltiMaker Cura has long had Python plugins and the UltiMaker Marketplace to distribute them (since Cura 3.4), and since Cura 5.5 there have also been Engine Plugins that hook into the slicing process itself. What is new is that plugins arrived in OrcaSlicer and PrusaSlicer. Read it as “slicers got plugins for the first time”, and you misplace where this stands.

Which one for what — a reverse lookup for extending your slicer

Here, on one page, are the mechanisms you can use for each goal, their status and the language you write them in. A combination not listed in a cell means “not checked here”, not “impossible”. Both new plugin systems are still alpha, so always look at the status column.

The following sections unpack each row in turn: first plugins that “make shapes”, then post-processing scripts that rewrite G-code, Cura plugins that add interface features, and the CLI for batch slicing.

Making shapes and objects with code — OrcaSlicer and PrusaSlicer plugins

The easiest use to grasp is making calibration shapes and objects assembled from parameters with code. The PrusaSlicer 3.0 alpha Lua plugins start exactly here. The official release notes say, “The purpose of currently existing plugins is to create objects programmatically.” alpha11 bundles calibration shapes written in Lua (a Flow Tower and a Temperature Tower). Change the values and the tower’s steps change.

OrcaSlicer 2.5.0-alpha’s Python plugins are a bit broader. According to the official release notes, a plugin is a single .py or a .whl package, and the Python runtime ships with the app, so nothing else needs preparing. There are kinds that add pages or dock panels to the interface, the Slicing Pipeline kind that steps into slicing, the Resource Texture kind that distributes bundles of height maps, and more. Every kind shares the trait of being code that runs inside the slicer.

Plugins are code, so AI can write them. That is why this topic connects with “AI × 3D printing”. Even with a just-published API, when we gave AI the official wiki and bundled samples and compared its code against a list of functions extracted from the source, it avoided mistakes such as calling non-existent functions. Conversely, with no material at all, it invented plausible-sounding function names. And when the material given was stale and included already-removed functions, the AI wrote those removed functions as is. In other words, what you have it read before it writes determines how correct the code that comes out is. The trend of AI entering slicing itself was covered in AI slicer revolution 2026 — the era of neural networks rewriting G-code (published 2026-04-02), but plugins sit one step before that, at the layer where users add features with code.

PrusaSlicer’s Lua was the same: given the API reference, the AI wrote code that generates shapes using functions as defined. There is a caveat, though. As the project says, “the purpose of currently existing plugins is to create objects programmatically” — for now, PrusaSlicer plugins only come in the object-creating kind. And both OrcaSlicer’s Python and PrusaSlicer’s Lua are officially labelled “experimental, and may still change”. OrcaSlicer writes that “the plugin system is new and its API may still change”, and PrusaSlicer that it “will probably do a breaking change every now and then, it will most likely never be completely stable”. There is no guarantee that a plugin written today will run unchanged on the next version.

If you have AI write plugin code, how you prepare the documents and rules you give it decides the result.

Prompt Engineering for LLMs

USD 54.51 on Amazon.com (as of 2026/09/22)

Amazon

ポチップ

Rewriting exported G-code mechanically — post-processing scripts

If you want to insert fixed rewrites mechanically — “pause at layer N”, “change temperature from layer M”, “change the fan from layer K” — post-processing scripts are more straightforward than plugins. A post-processing script passes the G-code the slicer wrote to an external program and rewrites it in place; any language works, whether Perl, Python or Ruby.

PrusaSlicer’s official help (for the stable 2.9.6) explains this mechanism most carefully. The setting is under Print settings, Output options, Post-processing scripts. The absolute path of a temporary G-code file created by PrusaSlicer is passed to the script as its argument (the help calls it the only argument; if the script has arguments of its own, the path is appended after them as the last one), and the script rewrites its contents. Settings are available as environment variables, with names in all upper case. Two more are passed: SLIC3R_PP_HOST, for the output host, and SLIC3R_PP_OUTPUT_NAME, for the output file name including its path. Note that the G-code preview shows the state before rewriting, so the script’s results do not appear in the preview.

Here we repeat the caution from the table. The PrusaSlicer 3.0 alpha does not have post-processing scripts yet. The official alpha11 release notes list important parts of 2.9.6 not yet ported, and “Post processing scripts” is on that list. So if you depend on post-processing scripts, you will use the stable 2.9.6 for the time being.

OrcaSlicer and Bambu Studio have the same setting. Both have a Post-processing Scripts field on the Others page of Process (print settings), and the description text in OrcaSlicer’s source says the script is passed the absolute path of the G-code file as the first argument and can read settings through environment variables. According to OrcaSlicer’s official wiki, on Bambu Lab printers the script runs right after slicing, so the result appears in the preview; on other printers it runs only when exporting G-code or sending to a network printer. This difference in timing matters when you check whether a change landed on the intended layer.

You can have AI write the rewrite too. There is a pitfall, though. When we had AI write a per-layer rewrite and applied that rewriting function to real G-code, it landed as intended on the output dialect we had shown it (how layer boundaries are written), but on a different dialect it drifted from the intended layer. G-code changes how a layer’s start is written depending on which slicer wrote it with which settings. A rewrite written without looking at the dialect lands one layer off, or misses entirely, when applied to other output. We also saw, in Having AI catch slicer setting mix-ups — testing material, temperature and plate combinations against official profiles (published 2026-10-14), how the form of the material you give AI changes its slicer-related judgments.

A post-processing script can be a small program that just reads a file and rewrites it. An introductory book on automating everyday tasks with Python applies directly.

Automate the Boring Stuff with Python, 3rd Edition

Paperback, 3rd edition (No Starch Press, May 2025) on Amazon.com

Amazon

ポチップ

Adding features to the interface — Cura plugins

If you want to add features through the interface, UltiMaker Cura’s plugins are the oldest hand. Cura plugins are written in Python, and the official wiki explains that “Plugins extend the functionality of Cura through python code.” The UltiMaker Marketplace, the distribution channel, has been available since Cura 3.4, and both plugins and packages can be installed from it. Besides installing from the Marketplace, you can also drag a .curapackage file onto the window (confirmed in the source). According to UltiMaker’s support article, installing from the Marketplace inside Cura does not require an account.

Cura’s post-processing is also provided as a bundled plugin. Open Post Processing from the Extensions menu and choose Modify G-Code, and you can apply bundled scripts to the G-code. They include Pause at height (pause at a given height) and ChangeAtZ (change settings at a given Z), plus others named FilamentChange, InsertAtLayerChange, SearchAndReplace, TimeLapse and TweakAtZ. In other words, many of the “per-layer pause, temperature and fan changes” described in the previous section are provided out of the box by Cura’s bundled scripts.

As a deeper extension, Cura 5.5 introduced Engine Plugins. The official release notes say “Plugin developers can now hook into and change the actual slice process”, and give examples of hook points such as post-processing generated G-code per layer and modifying extrusion paths. Like OrcaSlicer’s Slicing Pipeline, this is a kind that steps into slicing. So writing that “only the new OrcaSlicer can step into slicing” is not correct. Cura has had this entry point for some time.

One thing to make clear. This article does not write that Cura has “no” permission system or sandbox for plugins. We simply did not find, in official materials, a description of a mechanism that restricts plugin execution. Proving absence is hard, so we compensate by checking the source (two sections down).

Batch-slicing large numbers of files — the CLI

If you want to slice dozens or hundreds of files with the same settings, the CLI is faster than opening them one by one in the interface. OrcaSlicer’s official wiki says you can load, transform and slice models from the command line without opening the GUI, and lists automation, batch processing and CI pipelines as uses. Plates to slice are chosen by number: 0 for all plates, i for the i-th plate. The normative (specification) check is enabled by default. The settings directory can be specified with –datadir, so you can use a folder separate from the default user settings location.

Bambu Studio has a CLI too. According to its official wiki, you choose a plate by number, load machine and print settings from specified files, and set the output directory. PrusaSlicer can also run CLI-only. The project writes that “PrusaSlicer 3.x is still capable of CLI-only operation”, but argument handling was rebuilt in 3.x, so scripts written for 2.x may need adjusting. In the 3.0.0-alpha12 source there are options to slice and export G-code and to load settings files (specified several times to layer several files). The product page says you can batch-slice hundreds of files with the CLI or build it into your own manufacturing pipeline.

Now to the table row “Also rewrite G-code produced by batch slicing”. Reading the OrcaSlicer and Bambu Studio source, these CLIs do not run post-processing scripts. In both, the code that calls post-processing scripts is commented out in the source, and if post_process is set while the normative check is enabled, the CLI exits with the message “post_process is not supported under CLI.” So if you want to further rewrite G-code batch-sliced with the CLI, the straightforward flow is not to rely on the slicer’s post-processing field, but to apply your own post-processing script separately after export. We did not check here whether plugins run under OrcaSlicer’s CLI, or whether PrusaSlicer’s CLI runs post-processing scripts. We make no claim either way.

This article did not confirm whether Cura itself can batch-slice from the CLI, so we do not write about it. What we can say is that CuraEngine, the slicing engine, is published as a standalone console application whose README calls it a “C++ console application for 3D printing GCode generation”.

Before installing distributed code — permission system, sandbox and source

Plugins and post-processing scripts that others distribute run code on your PC. So before installing, check “where it came from” and “what it can do”. The thinking differs by mechanism.

OrcaSlicer uses a permission system. The release notes say “This is a permission system, not a sandbox, so only install plugins from sources you trust.” A permission system asks the user before a plugin goes outside the data folder, onto the network, or starts another program. Put differently, once permission is granted, it can go out. PrusaSlicer, by contrast, uses a sandbox: it cites safety as the reason for choosing Lua, and its developer documentation says a plugin can access only files in the same folder. The layer of defence differs; neither is simply better.

Both setups, though, have places where audits and restrictions reach poorly. When reading distributed code, watch for processing that runs when settings are loaded, processing inside separate threads, and processing that calls native code directly. These run outside “normal operations” and are easy to miss. When you have AI read distributed code to look for dangerous behaviour, whether it can look at these places changes the result. It is worth checking them yourself before installing.

Checking the source is essential too. OrcaSlicer’s official sites are just two, www.orcaslicer.com and cloud.orcaslicer.com, and the project warns “Do not download installers from third-party websites” and to beware of fake sites. We do not name the fake sites here. The Windows app itself is code-signed, but that is a signature of the app, not of plugins — do not confuse the two. Downloads from Orca Cloud check the server’s certificate.

PrusaSlicer is built to distribute plugins as signed zips, with keys created by a CLI subcommand (keygen). The mechanism lets users verify the author and keep a list of trusted authors. However, the marketplace, the distribution channel, is still in testing and not yet launched. Meanwhile, the UltiMaker Marketplace has submission requirements, and UltiMaker says it may ask for changes to submissions, but do not read that as “reviewed, therefore safe”. Note also that checking signatures on Cura plugins and post-processing scripts happens only in the Enterprise edition; in the general edition the bundled scripts are treated as trusted and no signature is required. To sum up, among the versions for general users, PrusaSlicer is the one that, as far as we checked, makes author signatures a premise of distribution.

For Bambu Studio, a plugin mechanism that loads user code does not appear within the official materials and the source of the official release v02.08.02.61 that we checked. We do not assert that it does not exist. The “networking plugin” in the Bambu Studio and OrcaSlicer READMEs is a non-free library used for network communication, not an extension mechanism for users to add features. The names are similar, so do not mix them up.

Living with alpha builds — backups, pinned versions and config folders

Both OrcaSlicer 2.5.0-alpha and the PrusaSlicer 3.0 alpha are still at the trial stage. OrcaSlicer’s release notes say experimental features may change before the stable release and that you should back up projects and profiles you care about. PrusaSlicer calls its alpha “an actual alpha, which is expected to be unstable and not polished”, and its product page presents it as a trial (experimental) and does not recommend it for production. If you try them, start with backing up your data.

Next, pin versions. Both projects state that their APIs will change, so a plugin breaks if you drift from the version it assumes. In OrcaSlicer, a preset remembers “which plugin it uses”, and on a PC without that plugin the Slice button stays disabled. In Cura too, if the Cura opening a saved project lacks a plugin the project needs, you get a warning. So if you use plugins, keep a copy of the version you confirmed works. PrusaSlicer Lua plugins declare the minimum supported version and the API version they use in their manifest, which is another handle for pinning versions.

Finally, the two alphas handle config folders in opposite ways, and this is the most important caution.

• The PrusaSlicer 3.0 alpha saves settings in a separate folder, PrusaSlicer3-dev. Since it is separate from 2.x, running it alongside 2.x does not cause conflicts. However, if you open a project saved in 3.x with 2.x, only the shape (geometry) is loaded, not the settings. Also know before trying that the alpha includes only Prusa printer profiles
• OrcaSlicer 2.5.0-alpha uses the same config folder as the stable release by default (reading the source, the app key that decides the config folder name is “OrcaSlicer”, the same as stable). So if you do nothing, it writes to the same place as the stable settings. To separate them, place a folder named data_dir next to the executable — for example with the Windows portable zip — and OrcaSlicer uses it as the config folder. With the CLI, specify the location with –datadir

If you install the OrcaSlicer alpha without knowing this difference, the alpha touches your stable settings. The advice that “installing several versions side by side is safe” applies as is to PrusaSlicer, but for OrcaSlicer it only holds together with the step of separating config folders. Trying alphas is welcome, but put in the extra step that protects your stable environment first.

While we are at it, a note on something outside slicers. The print server OctoPrint is not a slicer, but it can be extended with plugins and has an official distribution channel (the Plugin Repository). However, 2.0 is still an RC (release candidate), and the project writes, “It is not a stable release: severe bugs can occur.” 2.0 removes old APIs, so plugins that have not caught up break. If you use OctoPrint plugins in your printing workflow, update to 2.0 only after preparing to roll back manually.

Summary — choose how to extend your slicer by “what you want to do”

When you start extending your slicer, begin from what you want to do rather than from tool names, and you will not get lost. Here is the picture as of 2026-10-20.

• To make shapes or objects from values: OrcaSlicer’s Python plugins or the PrusaSlicer 3.0 alpha’s Lua plugins. Both are alpha and their APIs may change. They are code, so AI can write them, but if the material you give is stale, it uses removed functions as is
• To rewrite exported G-code mechanically: post-processing scripts, available in the fields of PrusaSlicer 2.9.6, OrcaSlicer and Bambu Studio, and Cura’s bundled Post Processing. The PrusaSlicer 3.0 alpha does not have them yet. If AI writes them, show it the dialect of the G-code it will be applied to
• To add features to the interface: UltiMaker Cura plugins — long established, with the Marketplace since Cura 3.4 and Engine Plugins that hook into slicing since Cura 5.5
• To batch-slice with the same settings: the CLI, in OrcaSlicer, Bambu Studio and PrusaSlicer. Reading the source, the OrcaSlicer and Bambu Studio CLIs do not run post-processing scripts, so apply them separately after export
• Before installing distributed code: understand the difference in defence — a permission system in OrcaSlicer, a sandbox in PrusaSlicer — and limit sources to official ones. Also look at places audits reach poorly (load time, separate threads, native code)

That two tools you can get for free, and extend with code, appeared at the same time is no small thing. How choosing not to rely on paid slicers became realistic was covered in Orca Slicer: the best free 3D printer slicer in 2026 (published 2026-01-29). Now a layer of extension — plugins — is building on top of that. Every mechanism includes alpha or experimental stages, so the best approach is to protect your stable environment first and try small, from the entry point closest to what you want to do.

Sources

• OrcaSlicer v2.5.0-alpha release notes (GitHub)
• OrcaSlicer official wiki: Plugins — Getting Started
• OrcaSlicer official wiki: Post-Processing Scripts
• OrcaSlicer official wiki: CLI Mode
• OrcaSlicer official wiki: How to Build (Portable User Configuration)
• OrcaSlicer official site
• OrcaSlicer version.inc (commit 3880f2c)
• OrcaSlicer src/OrcaSlicer.cpp (commit 3880f2c)
• PrusaSlicer 3.0.0-alpha11 release notes (GitHub)
• PrusaSlicer 3.0.0-alpha12 release notes (GitHub)
• PrusaSlicer doc/Plugin_API.md (commit 30ef591)
• PrusaSlicer product page (prusa3d.com)
• Prusa Knowledge Base: Post-processing scripts
• UltiMaker Cura 5.5.0 release notes (GitHub)
• UltiMaker Cura 5.13.0 release (GitHub)
• Cura official wiki: Plugins And Packages
• UltiMaker Support: installing Marketplace plugins and accounts
• Cura plugins/README_plugins.txt (commit 1fb8a76)
• Cura cura/CuraApplication.py (commit 1fb8a76)
• UltiMaker Cura product page
• Bambu Studio v02.08.02.61 (GitHub)
• Bambu Studio README (commit 926a719)
• Bambu Studio official wiki: Command Line Usage
• CuraEngine README (commit 636f960)
• OctoPrint 2.0.0rc6 release notes (GitHub)
• OctoPrint 2.0.0rc1 release notes (GitHub)

ブラウザだけでできる本格的な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.