Slicer Plugins Arrive in OrcaSlicer 2.5 and PrusaSlicer 3.0 — What Changed in the Two Test Builds and What Is Still Open

For a long time, if you wanted to add a feature to a 3D printing slicer, you had to change the slicer’s source code and maintain a fork. As of 2026-10-20, that assumption is starting to change in two test builds. OrcaSlicer added Python plugins in v2.5.0-alpha (published 2026-10-16), and PrusaSlicer added Lua plugins in 3.0.0-alpha11 (published 2026-09-01) and 3.0.0-alpha12 (published 2026-09-21). Both are ways to add your own features without forking the slicer. And because a slicer plugin is code, you can also have AI write that code.

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

Three points up front. First, slicer plugins are not “a first for slicers”. UltiMaker Cura has distributed Python plugins through its marketplace since Cura 3.4. What is new is that they arrived in OrcaSlicer and PrusaSlicer, the two slicers descended from Slic3r. Second, the two take different approaches to safety. OrcaSlicer officially calls its approach “a permission system, not a sandbox”, while PrusaSlicer calls its own a “sandbox”. Third, comparing slice times of the old v2.4.2 and v2.5.0-alpha with the CLI on our own machine — this PC, these settings, the median of five runs each — the gap widened with heavier models, and v2.5.0-alpha was 1.14 to 2.11 times faster. Both versions are labelled “alpha” test builds, however, and the projects state that the APIs will change. We will update the numbers in this article when stable releases ship.

What slicer plugins are, and why they are moving now

In this article, “slicer plugin” means extra code that the slicer itself loads and runs internally. It is a different mechanism from “post-processing scripts”, which pass the exported G-code to an external program for rewriting. Post-processing scripts reach in from the outside after the G-code exists. Plugins run inside the slicer. We will use this distinction again later.

The benefit of building plugins into the slicer is explained by the official release notes themselves. OrcaSlicer calls it “a supported way to add your own features to the slicer without maintaining a fork”. The official PrusaSlicer blog likewise gives the reason that “the community can extend the slicer without forking it”. Keeping a fork in step with upstream updates is heavy work. With plugins, features can be distributed separately from the slicer’s own updates.

But it is not a first. Cura can extend the slicer’s functionality with Python code (“Plugins extend the functionality of Cura through python code.”), and its official wiki says the marketplace has been available since Cura 3.4. So what is new this time is not the idea of slicer plugins itself, but that an extension point has opened in two lineages whose source is Slic3r: OrcaSlicer and PrusaSlicer.

That plugins are code has one more implication. Since they are code, rather than writing everything from scratch you can have AI draft them and then fix the draft yourself. How well AI handles a freshly published API depends on how you assemble the documents you give it. As groundwork for that, this article first sorts out what the two mechanisms are.

Python plugins in OrcaSlicer 2.5.0-alpha

The project calls OrcaSlicer v2.5.0-alpha “the most feature-packed release in OrcaSlicer’s history”, “built from more than 950 pull requests by over 140 contributors”. One of its headline features is Python plugins.

A plugin is “a single .py file or a .whl package”, and because the Python runtime ships with OrcaSlicer, nothing extra needs to be installed (“Plugins run on a Python runtime that ships with OrcaSlicer, so there’s nothing extra to install.”). The official wiki explains that plugins run inside an embedded CPython interpreter.

The release notes list four kinds of plugin.

• Script: an action run from the plugin window or Speed Dial
• Slicing Pipeline: processing that runs at stages of slicing. Chosen under Process > Others > Slicing Pipeline Plugin (Advanced mode), it reads and edits the sliced layers or post-processes the exported G-code. The project calls it “experimental and aimed at plugin developers and testers”
• Pages: adds a tab to the interface
• Resource Texture: adds height-map textures to the choices in Texture Displacement

The official wiki adds one more kind that handles communication with printers (Printer Connection, work in progress) for a total of five, but this article counts by the four in the release notes. Official sample plugins (twisting, pinching and wobbling a model during slicing) are included too.

Beyond plugins, v2.5.0-alpha brings many other changes. The project lists support for belt printers, an experimental Design tab (a CAD workspace inside OrcaSlicer, off by default), support for Bambu Lab’s H2C and A2L, and printing two to four parts at once on IDEX and IQEX printers. It also warns that this is an alpha for testing, that several new features may change before the stable release, and that you should back up important projects and profiles first. One point that matters in day-to-day use: if you open a preset that uses a plugin on a PC where that plugin is not installed, the Slice button stays disabled until the problem is resolved. Easier distribution comes at a price — the receiving side also needs the plugin.

Distribution goes through Orca Cloud. You browse plugins the community has published, subscribe with an Orca Cloud account, and if you publish your own, anyone can use it (“Publish it on Orca Cloud and anyone can use it.”). Subscribing requires signing in. The Orca Cloud plugin list page is rendered with JavaScript and we could not retrieve its content, so this article does not cover the number of published plugins, whether there is a review process, or pricing.

A note on download size as well. The Windows x64 portable build grew from 171,367,668 bytes in v2.4.2 to 221,507,287 bytes in v2.5.0-alpha. On the other hand, the project says that compressing bundled files makes OrcaSlicer about 74 MB smaller on disk. The size of the file you download and the size on disk after installation are separate matters. We do not speculate here about why the download grew.

An OrcaSlicer plugin can be a single .py file. Even if AI drafts it, knowing the Python basics of opening, reading and writing files lets you read and fix the code it produces.

Automate the Boring Stuff with Python, 3rd Edition

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

Amazon

ポチップ

Lua plugins in the PrusaSlicer 3.0 alpha

PrusaSlicer 3.0 is a rebuild of the internals, and the project describes the first public alpha, 3.0.0-alpha11, as “expected to be unstable and not polished”. The second, 3.0.0-alpha12, is mainly bug fixes. Prusa’s official blog announced the same 3.0 on the same day under the name “preview”, so the GitHub “alpha” and the blog’s “preview” refer to the same thing.

The plugin language is Lua. Prusa explains, “This is why we chose Lua – the system is more or less designed to be sandboxed”. By default plugins run inside a sandbox and cannot use network communication such as HTTP or sockets. Reading the source, only four standard libraries are opened to Lua — base, table, math and string — and dofile, loadfile and load are removed (we leave the details to a separate article).

What Lua plugins can do today is limited. Both the official blog and the API documentation say that, for now, the only kind of plugin creates new objects in the project (project.plugin) (“This is first version of Slice Plugin API, providing minimal operations to create new objects in Slicer project.”). In other words, PrusaSlicer’s Lua plugins currently do not rewrite G-code or sliced layers. A concrete example is the two calibration shapes bundled with 3.0.0-alpha11. Both the Temperature Tower and the Flow Tower are distributed as Lua plugins (source: temp_tower.lua and flow_tower.lua in resources/lua/com.prusa3d.slicer.calibration/, type “project.plugin”). Built-in calibration shapes did not originate with PrusaSlicer, by the way. The project itself writes, “Built-in calibration prints were added into SuperSlicer long ago, and they had propagated to many other forks.”

Distribution is still being prepared. There is a mechanism and tooling for distributing plugins as signed zips (the CLI commands plugin init, keygen and sign), and the marketplace is described as “in testing and it will be launched in the near future”. Submissions are said to be reviewed, but the 3.0.0-alpha12 release notes say nothing about the marketplace launching. So this article describes it as “in preparation”.

One clarification about post-processing scripts. Post-processing scripts, which rewrite exported G-code with an external program, existed in PrusaSlicer 2.x, but in the 3.0 alpha they are on the list of things “not yet included” and cannot be used for now. This is a separate mechanism from plugins, so do not confuse the two.

The operating assumptions are worth noting too. The project states that PrusaSlicer 3.x can still run CLI-only, without opening the interface (“PrusaSlicer 3.x is still capable of CLI-only operation”). 3MF files made in other slicers (Bambu Studio, OrcaSlicer) are imported as shapes only, not with their settings (“Third-party 3MF (Bambu Studio, OrcaSlicer): imported as geometry.”). The alpha still contains profiles for Prusa printers only, with other brands’ profiles promised to return later. In other words, the people who can try it right now are limited to those with a Prusa printer or those who can build their own profile.

If you want to try the bundled temperature tower, start by printing one in an easy-to-handle PLA. Differences in stringing and surface finish between the steps are easy to compare.

ELEGOO PLA Plus Filament 1.75 mm, Black 2 kg

USD 26.98 on Amazon.com (as of 2026/09/21)

Amazon

ポチップ

Permission system vs sandbox — the two test builds split on safety

Compare OrcaSlicer and PrusaSlicer and their approaches to plugin safety are clearly different.

OrcaSlicer uses a “permission system”. The project writes, “This is a permission system, not a sandbox, so only install plugins from sources you trust.” When a plugin tries to touch files outside OrcaSlicer’s data folder, connect to the network, or launch another program, it first asks the user for permission. Conversely, it cannot read OrcaSlicer’s own config file or the Orca Cloud login token.

PrusaSlicer uses a “sandbox”. Plugins run inside a sandbox by default, cannot connect to the network, and cannot touch the disk in general (they can only read files in the same folder as the plugin). The project writes that in the future it may let users explicitly grant permissions to trusted authors or plugins.

We do not generalize about which is safer. The details of the permissions, and what each mechanism fails to catch, need a separate check by reading the source. What we can say here is the difference in direction: OrcaSlicer is designed to “ask the user before use”, and PrusaSlicer is designed to “never let it touch the outside to begin with”.

What other slicers are doing (Cura, Bambu Studio, color mixing)

Stepping away from plugins for a moment, here is what other slicers did in the same period.

UltiMaker Cura added painting regions to control supports (Paint-on-Support) in 5.14.0-beta.1 (published 2026-10-15, a beta test build). The project notes that making the tabbed settings panel the default originally came from a community plugin. A small but telling change in the same release: exported G-code now records which CuraEngine plugins were used in its header, so you can trace afterwards what produced a given G-code. As mentioned above, Cura has long had Python plugins and a marketplace, and installing from the marketplace inside Cura does not require an account. The latest stable release is 5.13.0 (published 2026-05-28).

Bambu Studio 2.8.4 Public Beta (published 2026-09-22, a beta test build) improved texture import and shortened the paths of monotonic line infill on top surfaces. A mechanism for loading user-written plugins appears neither in the 2.8.4 release notes nor in the file list of the tagged source. There is, however, a setting for G-code post-processing scripts (post_process). Note that Bambu Studio’s “networking plugin” is a separate component for communication and not the kind of plugin system discussed here. The latest official release is 2.8.2.61 (published 2026-08-21).

Color mixing arrived in three slicers within the past year: Bambu Studio 2.5.3 (published 2026-04, an experimental feature the project does not recommend for single-nozzle printers), PrusaSlicer 2.9.6 (published 2026-06, ColorMix), and OrcaSlicer 2.5.0-alpha (ported from Bambu Studio). All three trace back to an idea from a community fork, OrcaSlicer-FullSpectrum.

To try color mixing you need a printer that can switch between several filaments automatically.

Bambu Lab P2S Combo (with AMS 2 Pro)

USD 769.00 on Amazon.com (as of 2026/09/21)

Amazon

ポチップ

The official notes say “much faster” — numbers from the release notes (the authors’ tests)

The OrcaSlicer v2.5.0-alpha release notes say it has “much faster startup, slicing and G-code export”. The figures below all appear in the official release notes and come from the authors’ own or independent tests. They are separate from our own measurements.

• Startup takes about half the time (“OrcaSlicer opens in about half the time.”)
• Slicing time down by about 35% (40% in an independent run)
• A 3DBenchy slices up to 3.7 times faster
• G-code export gets six separate speedups; in the author’s tests the first four together cut export time by 37.7% (the last two save up to another 8% and 6%)
• Gyroid infill is up to about 2 times faster for regular Gyroid on models with many small islands, and up to about 10 times faster with the Z-buckling optimization. The regular Gyroid pattern itself does not change
• Official Windows builds (x64 and ARM64) moved from MSVC to clang-cl; in the author’s tests this cut slicing and export time by 11–12% on small and medium projects and 29% on a large one

The 3DBenchy mentioned here is a sample model bundled with OrcaSlicer, licensed under CC0 1.0 (source: 3DBenchy.com). The project also says, “Slicing the same model with the same settings now gives the same G-code every time.” Output is essentially the same, with only organic tree supports possibly differing slightly.

Comparing slice times of 2.4.2 and 2.5.0-alpha with the CLI on our own machine

Since the project says it got “much faster”, we checked for ourselves. Using OrcaSlicer’s CLI (the mode that runs without opening the interface), we compared run times of the old v2.4.2 and v2.5.0-alpha. What we measured is not “slicing only” but the wall-clock time of one CLI run — process startup, loading settings, slicing and writing the G-code. Since the project’s speedups include faster startup, we compared wall-clock time including startup. Plugins were not used; they are an interface-side mechanism and were not active in this comparison.

Test conditions

• The PC runs Windows 11 Pro. This processing runs on the CPU; no GPU is used
• Both versions are the official GitHub portable builds, extracted. For both, we confirmed that the SHA-256 of the downloaded zip matches the value on GitHub
• Settings were identical for both. From the Bambu Lab profiles bundled with v2.4.2, we flattened the inheritance into a P1S setup with no inherits (machine=Bambu Lab P1S 0.4 nozzle, process=0.20mm Standard @BBL X1C, filament=Generic PLA) and passed the same JSON to both versions
• The default for auto-arrange rotation differs between versions (enabled in v2.4.2, disabled in v2.5), so we passed –arrange 0 (already arranged) to both explicitly
• Models were boxes made with trimesh (60×60×40 mm and 150×150×100 mm) and a sphere (120 mm diameter), with the same STL given to both. Instead of the 3DBenchy the project uses as evidence, we used shapes we made ourselves with clear distribution terms
• Each condition was run five times, alternating versions on every run

The actual command looked like this. Nothing was printed; we measured the wall-clock time of one CLI run (from startup to export) and the slicer’s own estimates.

orca-slicer.exe --load-settings "machine.json;process_<pattern>.json" --load-filaments filament.json --arrange 0 --slice 0 --outputdir DIR model.stl

Results (median of five runs each)

The ratio of medians (2.4.2 ÷ 2.5.0-alpha) was 1.14 for the 60 mm box with crosshatch, 1.78 for the 150 mm box with crosshatch, 2.11 for the 150 mm box with gyroid, and 2.03 for the 120 mm sphere with gyroid. The heavier the model (gyroid, larger size), the wider the gap. Filament use and the slicer’s time estimate, on the other hand, were nearly identical between versions (only the last digits differ). What got faster was processing time; the results — material use and estimates — barely changed. We did not compare the G-code command sequences themselves, though (our measurement script kept only the statistics and deleted the G-code; even on the first run of the 60 mm crosshatch box, the file sizes were 2,654,474 and 2,652,922 bytes), so we cannot claim the output is completely identical. The project also says “the same version with the same settings gives the same G-code every time”, but that is about reproducibility within one version, not a guarantee of identical output across versions.

Looking a little closer, the gap was widest when the infill was gyroid and the model was large. On the small crosshatch box, the medians were 0.42 s and 0.37 s, a slight difference. On the 150 mm gyroid box, the gap opened to 9.24 s versus 4.37 s. That direction matches the project’s statement that gyroid infill is “up to about 2× faster” (the project’s figure is for models with many small islands, a different condition from our large box and sphere). Rather than everything getting uniformly faster, the reading is that the gain shows up where computation is heavy. Conversely, if you slice a very small model once, the difference is unlikely to be noticeable.

The settings used for this comparison were the Bambu Lab P1S profile. With the same printer, you can compare the estimates in this article against your own prints.

Bambu Lab P1S Combo (with AMS)

USD 499.99 on Amazon.com (as of 2026/09/21)

Amazon

ポチップ

How to read this measurement, and what it cannot say

These seconds are “this PC, these settings, the median of five runs each”. Please do not read them as a general speed-up factor. We also have not pinned the difference on a single cause. The project cites both faster slicing code and the switch of the Windows compiler from MSVC to clang-cl. Our v2.5.0-alpha is that clang-cl build, so the measured gap mixes code changes and compiler changes. We did not separate them.

This comparison also did not check whether plugins run under the CLI (we measured without plugins). We found no mention of plugins in the source of OrcaSlicer’s CLI entry point, but this article does not state either way whether they work.

What is still undecided — living with alpha builds

Read everything so far as the state of things on 2026-10-20. In both OrcaSlicer and PrusaSlicer, the plugin systems have only just entered test builds (alpha), and both projects state that “the API may still change”. OrcaSlicer writes that “the plugin system is new and its API may still change”, and PrusaSlicer writes that the Lua API is experimental and that they “will probably do a breaking change every now and then”. When stable releases ship, we will update the numbers and status in this article.

Here are three cautions for trying them, taken from the official notes.

• Back up important projects and profiles first (the OrcaSlicer alpha asks you to). The PrusaSlicer alpha uses a separate config folder from 2.x (PrusaSlicer3-dev) and includes only Prusa printer profiles
• Install plugins only from trusted sources. OrcaSlicer’s “permission system” asks before use, but it is not a sandbox
• Pin and record versions. Both are test builds, and the same feature can behave differently between versions

Slicer plugins are a feature whose specification is still in motion. Even so, the fact that an extension point has opened in OrcaSlicer and PrusaSlicer — a way to add features without forking — changes how slicers get extended. And since plugins are code, the next question is “how much of that code can AI write?” Our earlier article recommending OrcaSlicer as a free slicer (Orca Slicer: the best free 3D printer slicer in 2026 (published 2026-01-29)) was also written before plugins arrived. With the extension point now open, what to add there is the next question.

Sources

• OrcaSlicer v2.5.0-alpha release notes
• OrcaSlicer 2.5.0-alpha full release notes (official wiki, source of the speed figures)
• OrcaSlicer wiki: Plugin Types
• OrcaSlicer v2.4.2 release
• PrusaSlicer 3.0.0-alpha11 release
• PrusaSlicer 3.0.0-alpha12 release
• Prusa blog: PrusaSlicer 3.0 Preview
• UltiMaker Cura 5.14.0-beta.1 release
• Cura wiki: Plugins And Packages
• Bambu Studio 2.8.4 Public Beta release
• Bambu Studio 2.5.3 Public Release
• PrusaSlicer 2.9.6 release
• 3DBenchy license (CC0 1.0)

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