# Versions and updates

> Distinguish application, project, Station, node-package, and local-tool versions when checking compatibility, updating work, or reporting problems.

Source: https://kaitoi.io/docs/reference/versions-and-updates/
Section: Account and help
Written for: Anyone updating an integration or reporting a version-specific issue.
Last reviewed: 2026-10-24

---

Several unrelated version numbers can appear in one workflow. Keep each number
with the artifact it identifies when testing compatibility or reporting a
problem.

## Name the version you are comparing


Settings shows the client version and release history; it does not certify the deployed backend or update every local tool. A project version guards a save, a Station version freezes a published definition, and package or CLI versions describe separate installed code. Keep the identity relevant to the operation and verify changes in a copy before replacing working content.

The client-only update switches illustrative build A to build B. Project v7, frozen Station v2, package P1 and local software L1 stay unchanged; these symbolic labels are not current release numbers.

*Figure: Client releases, project saves, packages and published Stations differ.*

## Find the Studio client version

Open **Settings → General** and look for **Version**, **Released** and
**What's New** near the bottom. What's New displays authored release history;
it is not an updater.

The version identifies the bundled Studio frontend client. **App Installation**
can show the same version for the installed web app. Neither label proves the
exact backend deployment or which optional services are enabled.

Before refreshing or changing software, protect unsaved work and inspect the
current save state. Do not use repeated reloads or storage resets to resolve an
unknown write outcome.

## Match the version to its purpose

| Version                | Meaning                                                            |
| ---------------------- | ------------------------------------------------------------------ |
| Studio client          | The frontend build shown in Settings.                              |
| Project API version    | A conservative optimistic save base used by concurrency checks.    |
| Station version        | A frozen published graph, interface and captured package material. |
| Node package version   | A particular published or installed package artifact.              |
| CLI or Runtime version | Software on the machine executing that local tool or service.      |

A project version is not semantic versioning, browsable history or a backup.
Read and reconcile document changes before using a newer expected version.
Guarded in-progress or unresolved saves need [their own recovery path](/docs/core/errors-and-retries/).

Changing the live Station version is separate from updating Studio. A community
package update does not replace the frozen package in an already published
Station. The author needs to publish, test and deliberately promote an
appropriate Station version.

## Find the instructions that apply

Use [Kaitoi News](https://kaitoi.io/blog/) for public announcements and the guide
for the feature you use. A version in a development checkout does not establish
that the public package or your hosted session has it.

For local tools, follow [Install and update](/docs/cli/install/) and inspect the
installed version on the machine doing the work. Updating a local tool does not
automatically upgrade Studio, its backend or a separately running service.

Consult the generated API reference for your actual deployment when integrating
request fields, scopes and errors. Keep the version and environment with your
saved integration example.

## Test an update on a separate copy

Retain the working source and a small example with expected inputs, outputs and
errors. Check the updated interface, required provider or service, output files
and failure behavior before replacing the original.

For a Station, test the candidate version before making it live. For an
application, test the request and response contract in a separate environment.
For a local model or recipe, check its dependencies and execution host as well
as the CLI package.

When reporting a compatibility issue, include the relevant version labels,
environment, run ID and a cleaned reproduction. A client label alone cannot
identify every component that participated in the work.