Thanks @ALan
I don’t use cached media.
I certainly never orange dot a cache in batch.
I use openclips for everything.
I’m not seeing the same behaviour at all.
If I need to cache something for playback i’m using the per object ‘Cache all versions’ options for open clip on a timeline.
I installed 2026.2 and migrated my current problematic project via the project manager (converting the project as a copy).
Initial launch of Flame and loading Workspace (59sec - premature elation).
Did some work in BatchGroup, save project, exit Flame.
Launch Flame, loading workspace (13min21sec).
Will keep testing, but it seems back to 2025 it is.
Do you have a support case going? This definitely seems worth their time.
Case 25056692 - slow library operations
None of which applies to the discussed issue.
To the contrary: all of which applies to the discussion: the directory slowdowns that you are experiencing are not what I’m experiencing. so there’s that.
Trying to parse this thread: is 2026.2 slow from freshly started projects, or projects moved up from earlier versions?
I can not confirm this though. Will have to roll the dice on that one. What I experienced in 2026.1 is that at a point in the project (late stages) the slow down is triggered. It is not gradual and there are no specific actions associated with the event. The two projects that I have done thus far are vastly different. One not that complex. 30% comp work with subs for social media versions and SM versioning.
Second project is a proper heavy comp job with background environment replacements. Heavier shots have pre-renders as BFX clips to speed things up.
My default workflow on both shows are BFX with connected segments for versioning between all edits and this is possibly where the bloat starts. Once again the issue only surfaces very late stage after most of the actual work is at 90% and final polish and finesse starts.
I have not tried a BatchGroup approuch yet from a fresh project to test if the timeline BFX workflow is the problem.
At this point I’m very hesitant to even try a new project in 2026.x as there is no rollback as a safety net if and when this problem reoccurs.
I have a project that I’m working on that has only one sequence in 3kx3k. 16 segments each with a distinct BFX. Each of those BFX contain light color and comp on RGB exr comps from Nuke. There are some alphas for these color moves being created from cryptomattes generated from the original/uncomped CG renders.
Everything worked great until it just wasn’t anymore. I hit render after updating a few of the comps 4 frames rendered and then it all came to a crawl. Complete and utter standstill.
Canceled and restarted Flame and same issue. Reboot solved it for about an hour or so and then the out of no where unuseable.
I never use BFX. Maybe for graphics prep in the timeline but otherwise never. This was just meant to be some quick, session style CC on full cg and a total one off but it has totally bitten me in the ass.
Is this related? Sounds like it. Otherwise like @philm said, in my normal workflow I haven’t had a single issue working unmanaged and anti-establishment in 2026.x
Case number
25059348
very very very long shot and probably not related but I had very slow save times until I flicked the PROTECTION MODE switch in Flame General Prefs. Not sure how it came on but when I turned it off my system was snappy again.
Probably unrelated, but this has memories from a year or so ago when I was battling VRAM memory leaks on a fairly basic 20min timeline with just color in TLFX. Started off well, and for no good reason turned into molasses. Eventually I had to render the timeline in short segments and concatenate in Resolve just to make it through.
Eventually a memory leak was confirmed and a case created. But I haven’t heard anything since.
Initial tests seems very promising. Saving across the board seems much faster. Will keep testing and report back.
I vaguely remember a discussion with @Slabrie either at NAB or in a Logik Live about this option. We should get an explanation what it does. It may lock everything while the auto save is in progress? Wasn’t there something that this matters in multi-user settings, but if you’re single user, it doesn’t make much of a difference and is safe to disable?
This has definitely made an improvement for me. The long term repercussions, we’ll have to see. For now it is a solve as a single seat user.
A quick search has returned the following:
Protection Mode in Autodesk Flame (as shown in your screenshot under General → Autosave) is a safeguard feature designed to prevent accidental overwrites, destructive changes, or unintended modifications to your project’s media, setups, and metadata. It is mainly intended for long-form, multi-artist, or facility environments where asset integrity is critical.
Below is a detailed, practical explanation of what Protection Mode does and how it affects everyday Flame workflows.
What “Protection Mode” Does in Autodesk FlameProtection Mode places Flame into a restricted-editing state. When enabled, it changes how Flame handles saves, overwrites, and structural modifications to help protect your work. It does not stop you from working—rather, it prevents actions that could accidentally damage existing material.
Key Behaviours of Protection ModeFlame will block or warn you before:
This reduces the risk of losing a working version.
With Protection Mode ON, Flame introduces extra steps before:
This prevents accidental overwrites—especially common when switching rapidly between shots or versions.
In multi-artist environments (shared storage / shared libraries):
While Protection Mode is ON:
Protection Mode reduces the risk of:
It is especially useful on:
Why Flame Has Protection ModeBecause Flame is designed for high-end finishing with complex node graphs and interlinked media, a single overwrite or mis-save can:
Protection Mode exists to reduce this risk.
Typical Usage Scenarios
You’re working on long-form shows with many interconnected BFX
Multiple artists are sharing the same project or library
You want to prevent accidental overwriting of versions
Large saves slow the project and you want to minimize risk
Doing rapid iteration and saving dozens of versions quickly
You’re the only person working in the project and prefer faster saves
You’re in a “sandbox” session without risk
This information needs to be officially confirmed from ADSK side.
Here is a more digestible version of the above as a pdf.
Protection Mode in Autodesk Flame.pdf (248.8 KB)
As before this information needs to be confirmed by @Slabrie as this is a quick chatGPT search, but from my understanding of this feature the information seems correct.
As a side note (off topic), now that 2026.2 is some what workable and behaving with ‘Protection Mode’ off, the new Automatte seems very promising and initial tests are very impressive and is producing even better results in some cases as Sammie-Roto.
Make sure to watch @Jeff’s learning channel video for some helpful workflow tips on AutoMattw.
Yip, been through those already.
Thanks to @Jeff for the ongoing great work on that front.
