Status
What can go down, what cannot, and how to tell in under a minute which one you are looking at.
Most of Sage does not depend on us
This is worth stating before anything else, because it changes what an outage means. Sage is local-first: when you run a local model through the CLI, the work happens entirely on your machine. If every server we operate went dark right now, sage would still start, your local models would still answer, your files would still be edited, and your shell escapes would still run. An outage on our side degrades Sage — it does not stop it.
What can actually go down
These are the components that depend on our infrastructure. If something is wrong, it is one of these:
•
Authentication — sage login and web sign-in through Google or Apple. If this is down, new sign-ins fail; sessions already authenticated on the CLI keep working.
•
Cloud model routing — requests to cloud-hosted models, including anonymization before they leave your machine. If this is down, switch to a local model with /model and keep working.
•
Web app — the chat interface, model picker, and account pages at sageworksai.com.
•
Mobile apps — the iOS and Android clients, which depend on the same APIs as the web app.
•
SMS bridge — the relay that accepts tasks from iMessage, Google Messages, and email and routes them to your registered computers.
•
Usage metering and billing — output token accounting, plan enforcement, and payment processing through PayPal, Apple Pay, and Google Pay.
•
Model distribution — the endpoint sage pull downloads weights from, and the one sage update checks for new CLI releases.
Checking whether it is you or us
Before assuming an outage, it is worth ruling out the ordinary causes, which are far more common:
•
Run /status inside a session. It reports your plan, your output token usage for the period, and the active model. If it answers at all, your CLI is talking to us successfully.
•
Run sage update. A surprising share of "it broke" reports are an old build meeting a changed API.
•
Switch to a local model with /model. If local works and cloud does not, the problem is in cloud routing rather than in your installation.
•
Check whether you have exhausted your plan's output token allowance. Hitting a limit looks a lot like a failure but is not one — the Usage page will tell you immediately.
•
Try the web app in a browser. If the CLI fails but the web app is fine, the issue is local to your machine or network.
How incidents are handled
When a component we run is degraded or unavailable, we investigate, fix it, and communicate what happened. For anything that materially affects paid plans, we say what broke, how long it lasted, and what we changed so it does not recur. Extended outages that prevent you from using a plan you paid for are grounds for a refund or credit under our Refund Policy — you should not pay for a period you could not use.
Reporting a problem
If you believe something is down, email support@sageworksai.com. The report that gets fixed fastest includes the output of sage --version, whether you were using a local or cloud model, the approximate time it started, and the exact error text. If you can tell us whether the web app is also affected, that narrows it down considerably.
On uptime numbers
We are not going to print a reassuring availability percentage on this page. A number without an audited measurement window behind it is decoration, and you deserve better than decoration on a page you are reading because something might be broken. What we will tell you is which components exist, how to determine which one is failing, and how to reach a human who can do something about it.
Designing around the dependency
If uninterrupted availability matters to your work, pull the models you rely on to local weights with sage pull while things are healthy. A local model on your own disk has no dependency on our infrastructure, our network, or anyone else's — which is the entire reason Sage is built this way.