Plugin: Autosave Control – Delay automatic saves, keep manual saves immediate

Hi all,

I’ve built a small plugin called Autosave Control.

By default, Obsidian automatically saves files about two seconds after the start of user input, and then saves every two seconds until no more changes are detected. This is convenient, but in some workflows it can be distracting — for example when using external sync tools, version control, or when you just want to reduce the frequency of writes to disk.

This plugin introduces a way to delay autosaves while keeping manual saves (Ctrl/Cmd+S) immediate:

  • Autosaves are detected and deferred for a user-defined interval (default: 10 seconds).
  • Manual saves (using the normal shortcut or the command palette) still write to disk immediately.
  • A small status indicator in the status bar shows whether changes are pending (blue) or everything is saved (green).
  • On quit/close or tab switch, pending changes are flushed automatically.

The goal is not to disable autosaving, but simply to add a buffer before automatic writes. This makes autosave behavior more predictable, while leaving manual saves fully under your control.

You can find the source and releases here:

:backhand_index_pointing_right: GitHub – mihasm/obsidian-autosave-control

I have created a new version 0.0.4, released today on github, which i have also put into the plugin review process, where I hope we will find a way to include the plugin into the community plugin list.

Feedback and cautious testing are very welcome!

5 Likes

A note from the team on the prior version (which was not submitted for review):

Make sure you have a backup system in place (a good idea even when not testing plugins): Back up your Obsidian files - Obsidian Help.

2 Likes

Thank you for this! Trying out this plugin (with caution), and seems to be mostly working as expected so far. CPU usage of Obsidian Helper (Renderer) process is down from 120% to ~15% while actively typing a note. I’m also seeing a massive decrease in power consumption on my Mac (18W → 9W) while typing long notes, as a result of the sync not happening on every keystroke.

Personally, I’m happy to take the risk (and some time to make extra Vault backups) if it means I can double the battery life of my Mac while using Obsidian.

Just a some comments:

  1. Maybe it’s my eyes, but it’s hard to distinguish between blue and green for the indicator. Perhaps orange and green would be clearer?
  2. Pending changes not being synced when closing/quitting Obsidian on MacOS (using Cmd+W, Cmd+Q, or closing the window). My current workarounds are to wait until the sync interval, Cmd+S to save, close tab, or switch to different note before closing the Obsidian window.
  3. I noticed that headings don’t appear on the headings pane (right side) until the autosave occurs. I’m guessing this kind of behaviour will happen with a lot of Obsidian features and community plugins while using this plugin, and might result in unexpected issues.
  4. I’m curious to see how this works on iOS/Android. I have no way of measuring power consumption on my iPhone but suspect that the power savings while typing a note might be as dramatic as they are on my Mac.
2 Likes

Hi, thank you for testing!

Interesting, I haven’t even thought about the potential for energy savings, that is good to note, and a huge bonus!

As per your comment, I took a look at the quitting/tab closing behaviour. I think I fixed this as of today (new version of plugin, 0.0.5).

I have also added a custom color changer to the settings pane, so one can set their own preferred colors for the indicator.

As for the header list on the right side - they seem to be only refreshed only when the file is saved, but there is no easy way to fix this, because it is core Obsidian code…

If you find out any other bugs or errors, please do let me know, and thanks for using the plugin!

2 Likes

Firstly, thank you for this plugin, it works very well for me after I experienced issues with syncing my vault to iCloud drive on Windows.

I noticed in the release notes that you mentioned a color picker was added to the settings pane, however after updating to v0.0.5, I do not see this option in the settings pane, only the Save Interval control. Am I looking in the right place?

Hi, I’m glad it works well!

The color picker options should be there in v0.0.5, I have just double-checked on Mac and Windows. They are in Obsidian Settings/Community plugins/Autosave Control/Options gear icon.

My presumption is that it was probably an issue with updating the plugin.

Make sure that you completely remove the previous version plugin folder before installing v0.0.5. Afterwards, in Obsidian, go to Options/Community plugins and use the “Reload plugins” button (alternatively, completely close and restart Obsidian as it will reload the plugins from the disk).

If the issue persists, feel free to submit an issue report on Github, so we can take a closer look:
Github - Obsidian Autosave Control - Submit Issue

1 Like

I deleted the plugin folder and re-added it, then reloaded the plugins, but the color options still did not appear in the settings page. However, after I closed Obsidian and restarted it, I was able to see the color options in there. Thanks for the help!

2 Likes

The fact that this plugin is even needed is down to a massive failing in Obsidian itself. The 2 second sync frequency causes Obsidian Sync to fail – I have a file which is use constantly for day to day work which is about 3kb in size (not that big) and I edit it all the time. This results in literally tens of thousands of file versions in obsidian sync which rapidly (from this single file) causes my entire 10gB data allowance to be consumed. To make matters worse there is no way top purge these versions, and the only solution is to delete the entire sync every 8 weeks or so and start again.

Not letting me decide how often to save of to Sync is a fundamental failing. It completely messes up all Sync methods including Obsidian Sync itself, and destroys hardware.

2 Likes

+1, auto-save and obsidian sync are both designed for a system of extremely-small notes that are not edited often. I find myself having to delete and re-create my remote vaults every week because editing a ~1MB text file a couple of times fills the vault with a bloated version history that i do not want (see: option-to-disable-version-history-for-large-markdown-files, enable-the-purge-process-to-also-remove-old-versions-of-notes-and-other-files on the forums), nor need, but cannot disable.

All of this forces the usage of external editors without auto-save, and make Obsidian Sync unusable for relatively long text files

2 Likes

Hi all,

Quick update on this plugin — there’s been a significant release since the original post.

Version 0.0.9 is now available on GitHub and introduces a major new capability:

→ Option to completely disable autosave

This goes beyond the original delayed autosave approach and gives full control over when writes to disk actually happen.

What’s new since 0.0.4

  • Option to fully disable autosave mode
    • No automatic writes at all
    • Files are saved only via manual save (Cmd/Ctrl + S or command palette)
    • Popup confirmation if files are not saved before tab/window close
  • Improved handling of save states and behavior consistency
  • Continued support for delayed autosave (now more stable and predictable)
  • Color pickers for status bar icon
  • Size setting for status bar icon

Important clarification

This new mode is intentionally opt-in and geared toward advanced workflows. It will likely interfere with features that rely on continuous disk writes (including Obsidian Sync behavior), so it should be used with awareness.

If you rely on autosave-dependent features, the delayed autosave mode remains the recommended option.

Reminder

  • Unsaved changes live in memory until written to disk
  • Crashes before manual save can result in data loss
  • External backup/versioning is strongly recommended

Link

GitHub (latest release):

Feedback is very welcome, especially around edge cases or workflows where this new mode either helps or breaks expected behavior.

Thanks to everyone who tested earlier versions and reported issues — that input directly shaped this release.

1 Like

Hey mihasm, thank you for the plugin. If I may ask, is there any reason to not send the plugin for review and inclusion in the directory?

1 Like

Hi all,

Small update: Autosave Control v1.0.0 is now available in the official Obsidian Community Plugins directory.

This is the first full release of the plugin and, importantly, it can now be installed through Obsidian’s normal Community Plugins flow instead of requiring BRAT or manual installation.

You can find it here:

Or inside Obsidian:

Settings → Community plugins → Browse → Autosave Control

Thanks to everyone who commented, tested, posted issues on GitHub, questioned the approach, or requested new features.

2 Likes

We still believe that this plugin is doing something dangerous (monkey patching core functionality). We will work in the following months to add automated checks to surface this behavior in all plugins.

1 Like

I have a couple of questions.
-Who is “we“? Did you talk with the whole team or is this your opinion, WhiteNoise?
-Please define exactly what is “dangerous“. There is no other way for me to implement this plugin than to monkey-patch. If I would have a way to do this in another way, or if you could implement a native solution for disabling autosave, that would be mucho bueno for me :slight_smile:

And other than that, I guess what I can gather from this response is that you will probably not allow this plugin in the future to be listed in the community plugin directory? So I will be forced to only have it on GitHub again? Maybe it really is time for another note-taking app, so I can finally stop wasting my time developing something that is so dangerous…

2 Likes

@mihasm , I found your response in the other thread to be a great overview of the situation, why the plugin could be dangerous, why it still has merit, and why it would be best if Obsidian itself implemented it instead.

However that response seems to have disappeared, and Obsidian seems happy with keeping official explanations close to 0, which is less than helpful. So I wanted to suggest that it’d be great to keep your response in the plugin’s README, so that the context isn’t lost.

2 Likes

Hi @hmijail,

I am posting a copy of my reply here. I hope @WhiteNoise will agree to let this information to stay on this thread.

The feature request has been open since 2021, and the underlying need still seems valid: some users want Obsidian to provide a built-in way to disable autosave, delay autosave, or configure save frequency. In my view, that is still the best long-term solution. Save behavior is core application behavior, and it would be safer and cleaner if Obsidian handled it natively.

The plugin I made, Autosave Control, is not meant to replace this feature request. It is a community workaround because the feature has not been implemented in Obsidian itself.

There has also been discussion here about whether solving this through a plugin is safe. I think that concern is fair.

No plugin can honestly guarantee that data loss is impossible. In this case especially, the plugin interacts with save behavior, so it necessarily carries more inherent risk than a purely visual or cosmetic plugin. That is exactly why I still think this belongs in Obsidian core in the long run.

Obsidian itself can implement this with better knowledge of its internal save pipeline, editor state, metadata handling, sync assumptions, and workspace behavior than a community plugin can. Also, because Obsidian itself is closed-source, plugin authors necessarily work from the public API and observable behavior rather than full knowledge of the internal implementation.

The plugin is open source, so anyone can inspect what it does and how it does it. Users should still understand the tradeoff before using it: if autosave is delayed or disabled, unsaved changes can remain in memory until written to disk, and a crash before saving can lose them. That is the tradeoff of this kind of workflow.

Also, because the plugin wraps around core Obsidian functions, it could introduce bugs in other parts of Obsidian that rely on those functions. I am doing my best to fix bugs as they are found, but the risk is still there.

All that being said, the plugin is now available in the official Community Plugins directory:

I would kindly invite everyone to keep plugin-specific support, bug reports, release notes, implementation details, and implementation-specific risk discussion in [this thread], so this feature-request thread can remain focused on the native Obsidian feature request.

But I do want to be clear: I still think this should be handled by Obsidian itself. The plugin exists because the native option does not.

2 Likes