Bespok3d, all the features you want, directly on the stock firmware

Maker Creations Mods & Builds
1

Bespok3d is out.

A desktop app and a small daemon that lives on your printer. Browse plugins, click install, done. Your U1 keeps running Snapmaker’s own firmware exactly as it shipped.

Your printer is a Linux box.

So you should not have to reflash the entire thing every time somebody writes a nice little feature. That is the whole idea. You can add one thing, remove another thing, change your mind, all while the firmware underneath stays stock and keeps taking Snapmaker’s own updates as if nothing happened. It also means nobody has to wait on anybody. A plugin is ready when its author says it is ready. There is no release train to catch and no build to sit through.

What is in it at launch

54 plugins. A rough map of the shelf:

  • Cameras: Hardware-accelerated streaming, plus ready-made configurations for the common setups.
  • Multi-tool: AFC lane mapping, tool-to-lane assignment, spool tracking across all four lanes.
  • Filament tags: Snapmaker’s own tags, OpenSpool, Anycubic, TigerTag, OpenTag3D, OpenPrintTag, plain JSON NDEF. It also supports Bambu and Creality if you bring your own keys. One plugin per format, so you install only the ones you actually own spools in.
  • Spoolman: Full integration, spool on the printer screen, weight deduction, per-print length.
  • Klipper tuning: TMC autotune, low current mode, adaptive bed mesh, forced levelling, upstream motion improvements, exclude objects.
  • Remote: Tailscale, ZeroTier, OctoEverywhere, the printer’s own screen mirrored into your browser and Prometheus metrics.
  • Quality of life: Timelapse, notifications, WLED, board temperature in the web UI, idle timeout, purge line placement, gcode preview colours taken from the filament actually loaded in, toolhead workarounds if one of yours is playing up.
  • Collections: One-click sets, so you do not have to pick 12 things individually to get started.

scr_2026-08-02_at_22.03.39
scr_2026-08-02_at_22.03.392784×2732 732 KB

Fluidd or Mainsail? Both.

Install both, run both, switch anytime. Both now support the multi-tool panels, giving you the flexibility to choose the interface that fits the moment. What was once a compromise is now complete freedom.

A safety net that lets you try things with confidence.

If a plugin breaks Klipper or Moonraker, the daemon automatically disables it and keeps the printer running. When the issue is fixed, you can restore it with a single click. No recovery file, no USB stick, no reflash. And it survives firmware updates.

Bespok3D Alpha was successfully tested across Snapmaker firmware versions 1.3.0 through 1.5.2 without losing anything. After an update, the app detects when the daemon is missing, offers to reinstall it, and reapplies your plugins in the correct order. Any plugin that can’t be restored stays disabled with its files untouched, ready to be fixed whenever you are.

The part that matters most

There’s already a lot of great work out there for the U1, but some of it is hard to find, some of it takes manual setup, and some of it never had a proper home. Bespok3D is built to change that. Anyone can publish a plugin. The index is open, and every entry is signed, so users can see exactly who created it.

You can also install a .b3 file directly from your disk, with no index required. We believe the tools you run should be under your control, not restricted by a system that decides what you’re allowed to use.

So if you’ve built something cool and useful for the U1, bring it in. We’d love to help you package it as a plugin and publish it in the store, where it can be installed by anyone with one click, removed with one click, and safely disabled if something goes wrong. You keep your name on it, and you keep maintaining it.

Not there yet

  • No SSH toggle, and that is intentional.
  • There’s also no web page hosted on the printer, because the desktop app handles that experience for all of your printers in one place.
10 Likes
2

someone leaked this:
https://makerworld.com/en/models/3125441-the-bespok3d-logo-badge#profileId-3526445

5 Likes
3

Seems nice to have :grinning_face_with_smiling_eyes:.
Thanks for sharing!
Have you considered submitting the project for Snapmaker Innovation Fund?

2 Likes
4

In case anyone has ideas on how to improve it let us know.

1 Like
5

Yes we did submit it

1 Like
6

Hi, . I’d like to package multiACE as a Bespok3d plugin now and have a few questions before I start:

  1. Klipper kinematics: multiACE ships a replacement for klippy/kinematics/extruder.py. klipper-extra maps to extras/ only. Is there a class for kinematics/, or is an instrument patch the intended way?
  2. Stock file replacement: today multiACE swaps three stock files (filament_feed.py, filament_switch_sensor.py, the extruder kinematics) for its own versions. Under Bespok3d I’d rather patch each stock file with a small shim that delegates to the plugin’s module. Is that acceptable to you, or would you prefer hook doors in u1-base for these files, like you did for print_task_config.py?
  3. Services: does a service run as lava, and does it start after Moonraker at boot? multiACE’s web backend needs Moonraker up.
  4. Config ownership: multiACE writes user settings back into its own ace.cfg (live settings from the web UI). If that file is a placed klipper-config fragment, does an update replace it? Should user values live in config variables or a data directory instead?
  5. USB serial: the ACE units are USB CDC/serial devices opened by the Klipper extra as lava. Stock already allows that; is there anything the plugin has to declare?
  6. Conflicts: I’d declare conflicts: ["afc-lite"]. Anything else to watch regarding the u1-base patches?

Thanks, Dirk

1 Like
7

Follow-up: I have since read b3-builder/doc, u1-base and the published manifests, and that answers most of the above myself:

- `klipper-source` names take paths under `klippy/`, so the kinematics file fits the scheme, but no plugin outside u1-base may carry such an entry; every stock file has one owner in the base layer.

- Services: `install.service`, the daemon writes the init script, runtime user is `lava` on the U1. Our backend waits for Moonraker itself, so no ordering is needed.

- Config: a placed `klipper-config` fragment is a symlink, user values go through `config` variables or an `install.data` directory. We can move our live settings into a data-dir file the fragment includes.

- USB CDC serial as `lava` needs nothing declared; `conflicts` is the field, `conflict_resolutions` is not shipped.

So only one question is left, and it is a policy one: multiACE needs registration points in three stock files that have no base plugin yet, `extras/filament_feed.py`, `extras/filament_switch_sensor.py` and `kinematics/extruder.py`. Would you accept base plugins for those three in u1-base (doors where possible, a behaviour replacement where the feed state machine has no extension point, one diff per firmware generation as in u1-base-toolhead)? If yes, we would open them as PRs there and register multiACE through the doors instead of swapping files. If no, i think a multiACE plugin is not possible under the current rules and I would rather know that before starting.

Dirk

8

That’s AWESOME

That said, I want to add a word of temporary caution:
Because the “dev tools” are currently locked behind a feature flag, the “3rd-party” index is very bugged in the current 0.7.6.
0.7.7. will fix it, and I’ll have a staging build ready in the next few days, together with a staging index, so things can be tested before going live.

Id love to have a chta if you’re up for it. Can discod rd work for you?

9

Thanks, good to know - we’ll wait for the 0.7.7 staging build and index

before testing anything.

Discord works for me, my handle is decay71