Updates & channels
Two different things get newer over time: the app, and what the app knows. They arrive by different routes and you control them separately.
The app
Celeris checks for a new version shortly after launch and occasionally while it is running. When one exists, it offers Download. When the download finishes, it offers Restart, and the update installs then.
Celeris never installs an update in the background, and never restarts itself while you are working. Settings → Updates shows the version you are on, the status of the last check, and the changes in whatever is being offered.
Choosing a channel
Settings → Updates → Channel decides which builds your install follows. The choice stays on that device. It is not synced, so a laptop can sit on nightly while a desktop stays on stable.
- Stable. The default, and the right answer for almost everyone. Released deliberately, after the candidate before it has been through a beta.
- Candidate (beta). The release candidates on their way to stable. Close to finished, out early so problems are found before everyone gets them.
- Nightly. Built automatically whenever the product changes, which is most days. New things land here first, and so do new bugs. Nightly builds also carry the Labs page, where unfinished features can be switched on individually.
Moving between channels is a settings change, not a reinstall. Move to a slower channel and your install waits where it is until that channel catches up.
If you installed through Homebrew, the cask you installed selects a matching channel on first launch, and an explicit choice in settings is kept from then on. See Install.
The Android companion is different: it updates through Google Play like any other app, and nowhere else. When it falls behind the desktop it says so at the top of the screen and keeps saying so, because a phone on an old build cannot talk to a newer computer.
What arrives without a new version
Some of what makes Celeris better is not code. It is knowledge. Which connectors exist, what a particular error means, which model is worth routing a task to. Waiting for a release to deliver a sentence would be absurd, so those ship as data instead, on their own schedule.
Settings → Updates → Feeds lists your installed versions and available updates. Automatic feed downloads and updates are on by default, independently of app updates. Turn the switch off to download updates yourself; existing manual and off choices for individual feeds still apply. Celeris still checks connector release metadata so each installed row can offer a download. It does not download the connector until you choose it.
Installed connectors update through their own process without restarting Celeris. An active call delays the update until it finishes. If setup or permissions change, Celeris keeps the installed version and directs you to review in Connectors. An update you requested resumes after active calls finish, even when automatic updates are off. Switch that feed off to cancel the waiting update.
What comes down these feeds:
- Tool know-how. When to reach for a particular tool, what a failure means, which command usually needs asking about. This can only ever make Celeris more cautious. It is not allowed to turn an approval prompt into an automatic yes.
- Connector offers and updates. New connectors wait for you to install them; already-installed connectors can receive updates automatically.
- Shared skills. Procedures you can adopt. They arrive as candidates, never as proven or trusted ones, and nothing runs on arrival.
- The model list. Which models Celeris is serving, what each is good at, and which is current. These entries deliberately carry no addresses and no credentials, so a delivered entry cannot redirect where your requests or your API key are sent. That is a property of the format, not a rule we remember to follow.
Each update is versioned and checked against a published fingerprint before it is applied, and the last known-good copy is kept so Celeris works fully offline.