Forgive the length, but this is really two posts in one: an answer to your filament-management frustration, and a larger criticism of Bambu Lab for falling short of the standards it set for itself.
TL;DR Version:
-
Your expectation is reasonable: a calibrated filament should be defined once and then persist cleanly across AMS use and projects.
-
Bambu’s larger problem is that its software and increasingly closed ecosystem often conflict with the simplicity and openness it benefited from and publicly aspired to.
1. Your filament-management frustration is legitimate
What you’re describing is exactly how a well-designed filament system should work: define a filament once, calibrate it once, and reuse it without repeatedly rebuilding the relationship between the spool, AMS, calibration data, and slicer profile.
Click here for expanded post of the filament challenge and why it failed user expectations
I noticed you’re a Mac user, which is useful context because Bambu has long positioned itself around the kind of integrated experience Apple made familiar: the complexity should stay underneath, while the product behaves as one coherent system.
Going back to 2022, Dr. Tao, Bambu Lab’s CEO, repeatedly described that vision in interviews and in his Spaghetti Monster blog posts.
To Bambu’s credit, they have probably come closer to delivering that experience than anyone else in consumer FDM printing.
But Studio still falls short in exactly the area you’re describing.
A calibrated filament should be a persistent, reusable object. I should be able to create “Overture Gold PETG,” calibrate it, put that material in an AMS slot, select it, and have Studio understand what I mean.
The user should not have to understand that the Device page, AMS material definition, Project Filaments, filament presets, and calibration data are separate concepts that happen to intersect.
Those are implementation details. Good software hides implementation details.
So no, I don’t think you’re missing something obvious or failing to read the documentation. You’re running into a software architecture and user-interface problem that Bambu has not resolved cleanly.
The printers have moved much closer to appliance-like operation. The software, particularly filament management, still too often reflects Bambu’s internal architecture rather than the user’s task.
2. The larger problem is Bambu’s increasingly adversarial attitude toward openness and control and its chilling impact on our community
Click here for expanded comments on how community open-source efforts that could address the larger issue have been met with threats by Bambu Legal
This is where I think the arrogance becomes harder to ignore, and where at least one community developer who extended Bambu functionality was met with a legal threat.
Bambu built heavily on an open-source software ecosystem. Bambu Studio is licensed under the AGPLv3 and is itself derived from PrusaSlicer, which in turn is derived from Slic3r. Bambu Studio can therefore be forked, modified, and redistributed under the terms of that license.
At the same time, Bambu has tightened access to portions of its networking and cloud interface and, in 2026, sent a cease-and-desist demand to Polish developer Paweł Jarczak over his OrcaSlicer-BambuLab fork. His modifications allowed OrcaSlicer to communicate with Bambu’s server-side components despite changes Bambu had made to its authorization system.
Bambu’s position was that the issue was not the open-source fork itself, but how the software interacted with Bambu’s private cloud infrastructure. Specifically, Bambu alleged that the fork identified itself to its servers as an official Bambu Studio client.
That distinction may matter legally. It did little to improve the optics.
A large part of the open-source community saw the contradiction immediately: Bambu was comfortable benefiting from open development while building its platform, but became much less comfortable when independent developers extended or worked around parts of Bambu’s own ecosystem.
Louis Rossmann, GamersNexus, and others pushed back hard, and the dispute quickly became a larger argument about interoperability, control, and whether Bambu was trying to close the door behind itself after benefiting from open development.
The Software Freedom Conservancy (SFC) has now thrown down the gauntlet, challenging Bambu on both the technical and licensing fronts:
https://sfconservancy.org/news/2026/may/18/bambu-studio-3d-printer-agpl-violation-response/
SFC states that its investigation has confirmed two AGPLv3 violations, has launched a project to reverse-engineer Bambu’s proprietary networking libraries, is actively recruiting volunteers, and says it will attempt to step in if Bambu makes legal threats against volunteers working on its behalf. Bambu disputes SFC’s interpretation of the licensing and cloud-access issues.
The sarcastic shorthand for that criticism was essentially:
“How dare you steal what I stole first.”
That is not a literal description of the licensing situation, but it captures why Bambu’s response landed so badly with much of the community.
And that larger attitude connects directly back to the smaller usability problem you’re describing.
In both cases, Bambu too often seems to expect users and outside developers to adapt themselves to Bambu’s internal architecture, instead of asking the more important question:
What is the person actually trying to accomplish?
Dr. Tao has spent years talking about a simpler, more integrated 3D-printing experience. Bambu has made substantial progress toward that goal on the hardware side.
The software still has work to do.
