Having AI Write OrcaSlicer 2.5 Python Plugins — How Far the Right Documents Get a Brand-New API

On 2026-10-16, OrcaSlicer gained a way to write plugins in Python. It arrived in v2.5.0-alpha, a version still in testing, and the official release says plainly that “the plugin system is new and its API may still change”. For an API only days old, the scarcity of documentation is itself the obstacle. Plugins are code, so AI can write them — but how correctly AI assembles names and arguments that were published days ago should depend heavily on the documents you give it.

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

So we had claude -p (model claude-sonnet-5-5) write OrcaSlicer plugins and compared them statically against a reference table built from the source. There were three tasks with goals that do not overlap the official samples, and three conditions for documents — “no documents”, “official wiki”, and “wiki plus official samples” — with one run each. The plugins were not executed. They were not loaded into the OrcaSlicer interface or the CLI; judgment was by Python parsing and static comparison against the reference only. All results are for the source at this tag, as of October 2026.

The results first. In this run, all three no-document plugins assumed APIs that do not exist (t1 and t3 a non-existent module, t2 a non-existent function name after importing the real orca module), wrote no metadata, and were not in a shape that could load as a plugin. With the official wiki, the errors nearly vanished, and with the wiki plus official samples, every task had zero errors. On the other hand, the wiki condition used an API that is documented in the wiki but has been removed, and the check caught it. For a freshly published API, what matters is not only whether you give documents, but whether the documents themselves have kept up with the version.

OrcaSlicer plugins are a brand-new mechanism, and without documents AI is feeling its way

OrcaSlicer v2.5.0-alpha was published on 2026-10-16 as a version still in testing (pre-release). The official release says, “This is an alpha build for testing. Several of the new features are experimental and may change before the stable release.” One of its headline features is the ability to write plugins in Python, and the project stresses about that API that “the plugin system is new and its API may still change”. So we state up front that the numbers and names in this article belong to this version at this point in time.

Because OrcaSlicer bundles the Python runtime, users do not need to install Python separately. Plugins are distributed as a single .py file or a .whl package. The bundled Python version is 3.12.13 according to the source build configuration (we did not check the version inside the released binaries). The release notes list four kinds — Script, Slicing Pipeline, Pages and Resource Texture — and the wiki adds a work-in-progress fifth, Printer Connection. Installed plugins are fenced by a “permission system” (in the project’s words, “a permission system, not a sandbox”) that asks before touching files outside the data folder, using the network or launching other programs. We do not go into the details of the permissions here.

The API visible from Python is split between a single embedded module named orca and modules under it such as host, slicing, pages, resource_texture and printer_agent. A plugin follows a fixed shape: one subclass of orca.base decorated with @orca.plugin per file, registering capabilities inside its register_capabilities. Concretely, a minimal plugin looks roughly like this (a skeleton based on the example in the official wiki’s Plugin Development page).

# /// script
# [tool.orcaslicer.plugin]
# name = "Sample"
# ///
import orca

@orca.plugin
class SamplePlugin(orca.base):
    def register_capabilities(self):
        orca.register_capability(SampleScript)

What the top of the file needs is PEP 723 metadata (an inline block written as comments) holding the name and other fields. The opening line must be exactly “# /// script” and the closing line exactly “# ///”. OrcaSlicer reads only name, description, author and version under [tool.orcaslicer.plugin], plus dependencies and requires-python at the root, and a .py installed locally fails to load if name is missing. The wiki table lists name as “recommended”, but in the source it is required. Other keys such as type are simply ignored rather than treated as errors, and they still appear in the official samples. This format — written in comments inside the .py rather than in a separate file — is the first hurdle when having AI write against a brand-new mechanism.

The timeline is what matters. PR #14530, which added Python plugins, was opened on 2026-07-02 and merged on 2026-07-17. The first explanation landed in the official wiki on 2026-07-02 as well. Meanwhile Claude Sonnet 5.5, the model we used, has a reliable knowledge cutoff of June 2026 in Anthropic’s model overview, and its own model page lists a training data cutoff of June 2026 as well. Only the month is given, so this article describes it as “a knowledge cutoff of June 2026”. In other words, this API was published after the AI’s knowledge cutoff. Indeed, in this run, without documents the AI could not assemble this API correctly (whether it was absent from training or present but not retrievable is something this experiment cannot separate). This is the same kind of question we asked in How much does AI know about the new products in the Agentic Architect exam scope? We checked all 28 items against official docs (published 2026-10-20) — “how much does AI know about a just-released product?” — with the subject swapped for a slicer plugin API.

A plugin starts as a single Python file. To read and fix an AI draft, a solid grasp of Python basics centred on file handling is reassuring.

Automate the Boring Stuff with Python, 3rd Edition

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

Amazon

ポチップ

Checking the AI’s code without running it, against a reference table built from the source

The yardstick was the set of names exposed to Python under src/slic3r/plugin at the OrcaSlicer v2.5.0-alpha tag (commit 3880f2c, published 2026-10-16). In this article we call it the reference table. We parsed the pybind11 definitions mechanically (def_submodule for adding modules, py::class_ for classes, py::enum_ for enums, .def for functions and methods, .attr for constants) and extracted 726 names exposed to Python (modules, classes, enums, functions, methods, properties and so on). There are 11 modules counting the top-level orca and its 10 submodules (the deepest, orca.host.preset.bundles, is four levels). Counting names by hand inevitably drops or duplicates some, so we extracted them mechanically from the source, pinned to the same commit so they can be regenerated any number of times. The reliability of the reference table directly determines the reliability of the article’s conclusions.

The checking script does not run the plugin. It reads the code with Python’s parser (ast) and checks six things. First, whether every name starting with orca is among the 726. Second, whether the keyword arguments passed exist in the pybind11 declarations (py::arg). Third, whether the PEP 723 [tool.orcaslicer.plugin] metadata is present. Fourth, whether the attributes of the Slicing Pipeline ctx actually exist. Fifth, whether the @orca.plugin and register_capability structure is in order. Sixth, whether the code imports external modules not listed in the metadata’s dependencies. If parsing fails, that counts as one error and no further comparison is done.

Of the six, the name and argument checks look at “whether things that exist are being called correctly”. The metadata and structure checks look at “whether it takes the shape of a plugin at all”. A locally installed .py fails to load just because name is missing from its PEP 723 metadata, and without a subclass of orca.base decorated with @orca.plugin, OrcaSlicer does not recognize it as a plugin no matter how correct its contents are. With a brand-new API, whether the AI follows these container rules — before function names even come into it — makes the biggest difference to the result.

We first checked with two controls that the check itself works. As a negative control, we ran six official samples through it and got zero errors. As a positive control, we prepared one plugin with six deliberately planted errors, and the check caught all six. Only after confirming that it does not call correct code wrong and does not miss planted errors did we proceed to scoring. Fixing the scoring criteria first and backing up the check with controls is the foundation for trusting measured results.

That said, the check only looks at “whether the API is used correctly”, not at whether the meaning is correct. Whether a cross-section area is computed with the right formula, or whether a unit conversion of coordinates is right, cannot be judged by comparing names and arguments. Attributes whose type cannot be determined statically (which member of some object was called) and functions whose argument count cannot be fixed without reading headers were also excluded from scoring. So “zero errors” below means “no errors found in how the API is used”, not “it works correctly as a plugin”.

Three tasks, written with no documents, the official wiki, and the wiki plus official samples

We prepared three tasks, each chosen so that its goal overlaps none of the seven official samples. t1 is a Slicing Pipeline plugin that computes the cross-section area of each layer right after slicing and reports the largest and smallest layers. t2 is a Script plugin that lists every object on the plate. t3 is a plugin that shows the selected preset and three setting values (settings such as layer_height, sparse_infill_density and nozzle_temperature) in a dock panel. A dock panel can be opened from Pages, which adds a tab to the main window, but also from the Script kind via create_dock_panel; which to use was left to the AI. The goals do not overlap, but some of the APIs do. t2 lists objects on the plate, which is close to the official dock_panel sample, and t3 overlaps dock_panel and inspector in its dock panel and preset-reading APIs. Post-processing that rewrites exported G-code was not part of these tasks.

The entry point and timing of the code differ by capability kind. Script is run by hand from the Plugins window and runs on the UI thread. Slicing Pipeline is called on a background thread during slicing and can modify layer outlines, but the project positions it as an experimental feature. Pages adds its own tab to the main window and talks to an HTML page. The tasks were chosen to hit kinds with different entry points and timing, because we wanted to see whether the AI writes the right entry point for each kind (execute for Script, execute(ctx) for Slicing Pipeline) and the overrides each kind requires. Get the entry point’s name or arguments wrong, and the plugin does not load at all. As it happened, for t3’s dock panel the AI chose to open it with create_dock_panel from a Script’s execute in every condition, so the kinds actually written in this run were two: Script (t2, t3) and Slicing Pipeline (t1).

There were three conditions: “no documents” with nothing given at all; “official wiki”, giving the plugin pages among the Markdown files of OrcaSlicer_WIKI at commit 0dc4b48 (2026-10-19); and “wiki plus official samples”, adding the official samples. The wiki given comprised Plugin Types, Plugin Development, and eight API reference pages excluding Printer Agent (Host, Host UI, Slicing, Lifecycle Events, Pages and so on) — ten files in all. The official samples were six of the seven examples in the repository’s sandboxes folder (excluding reload_local_bundle_demo). The volume of material is shown in the table below; the plugin-related Markdown totals 17 files and about 194 KB, and the official samples 7 files and about 135 KB. The public wiki keeps being updated, so the experiment pinned the Markdown to this commit.

The AI ran as claude -p. The model was specified with –model, and the model ID recorded in the output was claude-sonnet-5-5. We used a minimal configuration that loads no tools, MCP servers or settings files, and called it from a working folder outside the home directory so it would not pull in parent-folder settings. The nine calls cost $1.889 in total (the sum of the recorded total_cost_usd). The unit price is $2 input and $10 output (per million tokens, as of October 2026), but the cost is the recorded value, not a calculation from unit prices. Billing depends on the plan you use, so treat it as a rough guide.

One trap lay in how a task was framed. t1 asks to “report the largest and smallest layers”, but Slicing Pipeline’s execute runs on the slicing worker thread, and calling the interface API (orca.host.ui) from there can deadlock, according to the official explanation. In other words, taking the task text literally pulls you toward a call the project forbids. The correct way is to compute and store results in execute, and report them on a lifecycle event delivered on the UI thread (SlicingJobComplete, when slicing completes). Which approach the generated code took, however, was not among the items scored by this static check.

Feeding a model the right documents is a craft of its own, and the gap between the three conditions here is largely a gap in context. This book goes deep on that.

Prompt Engineering for LLMs

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

Amazon

ポチップ

No documents meant guessing non-existent modules; the wiki nearly eliminated errors

Reading the results — every count is from a single run per condition.

All three no-document plugins (t1, t2, t3) were in a shape that could not load as a plugin. All three used non-existent modules (a module named orcaslicer the AI invented) or functions on a guess, and none wrote PEP 723 metadata. Each also had two structural errors: no subclass inheriting orca.base, and no capability registered with orca.register_capability. The AI did state its assumption — “please check the API” — but the assumption was wrong. Since the API was published after the knowledge cutoff (June 2026), the no-document condition is a control the AI could not have known about, and it is not the kind of thing to blame as “getting it wrong”.

With the official wiki, errors nearly vanished. t1 and t3 reached zero errors with the wiki alone, and only t2 kept one (examined in the next section). Adding the official samples to the wiki brought all three tasks to zero. The number of references starting with orca that the check counted (including both correct names and references to non-existent ones) also rose from 0–3 with no documents to 10–16 with the wiki and 10–17 with the wiki plus samples. The more material we gave, the more the AI reached for the freshly published names and arguments — and most of them were right.

The difference between no documents and the wiki is a difference in input, not in model intelligence. Give the same model the same task without the just-published specification at hand, and it fills names in by guessing and breaks the structural rules too. Conversely, just handing over the pages made non-existent modules such as orcaslicer disappear and put the @orca.plugin and orca.base shape in order. With this model, the more material we gave, the fewer errors the check found (we did not compare models of different strength, so this is as far as we can go). When having AI handle a brand-new API, it means a lot to first collect the published documentation and hand it over. What we handed over was not a summary of search results but the primary documents themselves at a pinned commit, which likely helped too.

One addition. Processing during slicing, as in t1, can require names the official wiki does not explain. The wiki covers neither the Print, PrintObject and Layer types used during slicing, nor unscale, which converts coordinates to mm (checked with grep as of October 2026). Meanwhile, t3’s Pages has an example in the wiki (a sample page that shows the slicing log), so in the wiki condition it may benefit from being able to copy something close to a model. Even so, in this run the wiki condition reached zero errors for both t1 and t3, and the AI built the tasks with names within the range it was given. Names missing from the wiki could be a weakness of the wiki condition, but this time it did not surface as an error.

The AI copied a removed API that is still in the official wiki

The one error left in t2’s wiki condition was the name orca.host.ui.show_dialog. This is not a non-existent function the AI made up. The Host UI page of the official wiki still shows it as an example, as a function that opens a modal HTML dialog. But the v2.5.0-alpha source has no show_dialog. A commit on 2026-07-17 removed show_dialog and replaced it with arguments to create_window (style and on_submit). The wiki is not split by version and still carries the pre-removal description, so the AI copied it as is.

There is another mismatch of the same type. The wiki’s Host page has an example of a function called orca.host.app_language(), but it too was deleted in a commit on 2026-10-10 and replaced by app_info. Only show_dialog actually appeared in t2’s wiki condition this time, but even when you hand over official documents, if those documents have not kept up with the version, the AI copies old names. This is a different kind of error from the no-document condition’s “guessing names it does not know”, so we counted it separately as a “wiki-derived error”. The check caught show_dialog mechanically as a name absent from the 726-name reference table.

Two practical cautions follow. First, even code an AI wrote on the basis of official documents can slip in removed APIs if those documents are stale. Handing over documents is not a guarantee. Second, that is exactly why comparing against a reference table built from the source works. A person who only reads the wiki falls into the same trap, but mechanically matching against the list of published names makes removed names surface on the spot. The newer the API, the more likely documents and source drift apart. As the project says, APIs in the alpha may change, and removals and replacements of names follow one another in short order.

Scoring AI output mechanically against a known-correct reference is the same idea that underpins evaluating any application built on foundation models.

AI Engineering: Building Applications with Foundation Models

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

Amazon

ポチップ

What this check of OrcaSlicer plugins cannot tell you

Here are the limits to keep in mind when reading the results.

• One run per condition: we had the AI write three tasks under three conditions, once each. We did not measure how much the answers vary when the same task is repeated. Every number is “what happened in this run”, not something to generalize
• Not executed: the plugins were not loaded in the OrcaSlicer interface or the CLI. Judgment was Python parsing and static comparison against a reference built from the source only. We confirmed nothing about “it ran”, “it loaded” or “it sliced”
• Meaning not checked: the check stops at whether the API is used correctly; it does not judge whether cross-section area calculations or coordinate unit conversions are right. Zero errors means “no errors found in API usage”, not a guarantee that the plugin works correctly
• One model, minimal setup: we ran claude-sonnet-5-5 in a configuration with no tools and no search. We did not try other models or configurations with web search
• APIs that start slicing or export: within the names exposed to Python in the v2.5.0-alpha source, we found no function a plugin can use to start slicing or G-code export (there is export_3mf_copy, which writes a copy of the 3MF). This is not proof that none exists, only that none was on the list of published names
• Not confirmed: we did not check the Python version inside the released binaries, whether the official samples ship with the app, or whether AGPL obligations extend to plugins themselves, so we do not write about them
• It is an alpha: the project states the API may change. When a stable release ships, the names and arguments here may move. These results apply only to the source at this tag as of October 2026

Summary — if you have AI write OrcaSlicer plugins, give it documents first, then check

The Python plugins in OrcaSlicer v2.5.0-alpha (published 2026-10-16) are an API released after the AI’s knowledge cutoff (June 2026). In this run, without documents the AI could not assemble this API correctly.

In this run, all three no-document plugins assumed APIs that do not exist (t1 and t3 a non-existent module, t2 a non-existent function name after importing the real orca), wrote no metadata, and could not load. With the official wiki the errors nearly vanished, and with the wiki plus official samples every task reached zero errors.

However, the wiki condition used show_dialog, which is in the official wiki but absent from the v2.5.0-alpha source. Even when you hand over official documents, removed APIs slip in if those documents have not kept up with the version.

So if you have AI write OrcaSlicer plugins, give it the just-published official documents and then compare the result mechanically against a reference table built from the source. Drift between the documents you gave and the names actually published is hard for a person to notice just by reading. We covered having AI catch mix-ups in the setting values themselves in Having AI catch slicer setting mix-ups — testing material, temperature and plate combinations against official profiles (published 2026-10-14). Whether it is plugin code or setting values, rather than leaving everything to AI, keep a way on your side to hold the output up against the published correct answer.

Sources

• OrcaSlicer v2.5.0-alpha release
• OrcaSlicer PR #14530 “feat: Python Plugins”
• OrcaSlicer wiki — Plugin Development
• OrcaSlicer wiki — Getting Started (plugins)
• OrcaSlicer wiki — Plugin Types
• OrcaSlicer wiki — Host UI
• PythonPluginBridge.cpp (the orca module, commit 3880f2c)
• PluginFsUtils.cpp (reading PEP 723 metadata)
• Commit that removed show_dialog (2026-07-17)
• Commit that removed app_language (2026-10-10)
• OrcaSlicer LICENSE.txt (GNU AGPL v3)
• PEP 723 — Inline script metadata
• Anthropic Models overview
• Anthropic Claude Sonnet 5.5 model page
• Anthropic Pricing
• Claude Code CLI reference
• Claude Code headless (non-interactive) mode

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