Changelog

How Sage ships, what we consider worth announcing, and why the CLI itself is the authoritative record of what changed.

Where the authoritative list lives

The CLI is the source of truth for what changed, because it is the thing that actually changed. Run sage --version to see the build you are on, and sage update to move to the current release. The release notes that ship with an update describe that specific version — which is more reliable than any summary a web page can offer, since this page cannot know which build is installed on your machine.
We would rather point you at an accurate source than reprint a list here that drifts out of date the moment a release goes out. If you want to know exactly what changed between your build and the current one, sage update will tell you.

How Sage is released

Sage is distributed as a Python package, sage-ai-cli, and updates land continuously rather than in large seasonal releases. The pieces move at different speeds:
The CLI — versioned and installed by you. Nothing changes on your machine until you run sage update, so a release can never break a working setup without your involvement.
The web and mobile apps — updated server-side and through the app stores. These change without action on your part.
Cloud model routing — models are added and retired as the open-weight ecosystem moves. Use /models to see what is currently available to you rather than assuming a list stays fixed.
Local models — entirely under your control. A model you pulled with sage pull keeps working exactly as it did the day you downloaded it, regardless of anything we ship.

What we consider worth announcing

Not every commit deserves your attention. These categories do:
Breaking changes — anything that alters the behaviour of an existing command or requires you to change how you work.
New or retired models — additions to the 200+ open-weight models available, and removals from cloud routing.
New slash commands, or meaningful changes to existing ones such as /think, /compact, /test, or /undo.
Integration support — changes affecting VS Code, Cursor, JetBrains, Neovim, Sublime Text, Zed, GitHub CLI, Git Hooks, Godot 4, or the Unity Editor.
Security fixes — always, and always promptly.
Billing and plan changes — anything affecting output token allowances, overage rates, or the Free, Starter, Pro, and Premium tiers.
Privacy-relevant changes — anything touching what leaves your machine or how cloud requests are anonymized.

What will never appear here

This page will not carry invented entries, backdated releases, or filler written to make development look busier than it was. If a version is not listed with a real date attached to a real release, we do not list it at all. An empty section is honest; a fabricated one is not, and you would have no way to tell the difference until it cost you something.

Staying current

Run sage update periodically — it is the single most useful troubleshooting step, and a surprising share of reported bugs are already fixed in a newer build.
Run /help after updating. It reflects the exact commands available in the build you have, including anything newly added.
Run /models after updating to see whether the available model list has changed.
Check sage --version before reporting a problem, and include it in the report.

Backwards compatibility

We try hard not to break working setups. Where a change is unavoidable, it goes in the release notes for the version that introduces it, and we prefer deprecating over removing. Because you control when the CLI updates, you also control when you absorb a change — and because local models live on your disk, an update to Sage never invalidates weights you already pulled.

Reporting a regression

If an update breaks something that used to work, we want to know quickly. Email support@sageworksai.com with the output of sage --version, the version you upgraded from if you know it, the command you ran, and what happened instead of what you expected. A regression report with a version number in it is worth several without one.