# Performance and diagnostics

> How Vato measures its own speed, where the local performance journal lives, what leaves your computer, and how to ask an agent for the performance scoreboard.

Vato times its own everyday gestures — opening a conversation, sending a message, starting the app — and gives each measurement a score. This page explains what is recorded, what stays on your computer, and how to read the result when Vato feels slow.

## What Vato measures

Each measurement has a name, a category, a duration and, when a target is defensible, a **target**. The gestures you feel most are called **journeys**, and each one has a target for the typical (75th percentile) run:

| Journey | What is timed | Target |
| --- | --- | ---: |
| `app-launch` | From the process starting to the main window and the first composer being painted | 3 s |
| `conversation-new` | Click on a new conversation to an empty, ready thread | 300 ms |
| `conversation-open` | Click in the sidebar to a reopened conversation with its history painted | 500 ms |
| `message-send` | Enter to your message bubble being painted | 100 ms |
| `message-dispatch` | Enter to your prompt being handed to the provider | 250 ms |

`first-event` and `first-token` are also measured, but they depend on the provider and are not scored.

### How the score works

- A measurement at or under its target scores **100**.
- Above the target, the score is `100 × target ÷ duration`, so a run twice as slow as its target scores 50.
- An error, a failure or a timeout scores **0**.
- A measurement without a target is recorded but never scored.

The overall score is the average of the scored measurements. It tells you where to look, not how good a single run was: check the number of samples and the failure count before drawing a conclusion.

## What stays on your computer

Vato writes a local journal, `telemetry.jsonl`, in its data folder:

| System | Installed app |
| --- | --- |
| Windows | `%APPDATA%\com.vato.ide\telemetry.jsonl` |
| macOS | `~/Library/Application Support/com.vato.ide/telemetry.jsonl` |
| Linux | `~/.local/share/com.vato.ide/telemetry.jsonl` |

The journal rotates at 32 MiB and keeps a single backup, `telemetry.jsonl.1`. It never leaves your computer.

It holds names, durations, targets, scores, counters and technical identifiers. It never holds your prompts, an agent's replies, message content, file names or paths, tool inputs or outputs, keystrokes, screenshots, tokens, cookies or passwords. The native side redacts and truncates every attribute a second time before writing it.

## What is sent to Vato

The desktop app installed from a release, while you are signed in, sends a small batch of **aggregated counters and duration histograms** to Vato's API about once a minute. The batch uses a fixed list of metric names and carries your operating system and the app version. It carries no user, machine, session, project or conversation identifier.

- Nothing is sent from a development build or from the browser-only version of the interface.
- The upload is best effort and happens in the background: no action of yours ever waits for it, and a failure is silently retried later with a growing delay, up to 15 minutes.
- The mobile app sends its own timings — boot, resuming, the realtime connection, the conversation list and detail, the keyboard, and prompt acknowledgement — through a closed list of measurements. No conversation content is accepted.

Because the aggregates are anonymous, Vato cannot count unique users or find a particular person's session from them. A missing measurement does not prove that everything is healthy: a computer that is offline, signed out, or that crashed before its first upload sends nothing.

## Ask an agent for the scoreboard

You do not have to read the journal yourself. Ask any agent — for example *"How is Vato performing? What is slowest?"* — and it can call the **`perf_scoreboard`** tool. It is read-only, so it is also available in Plan mode.

By default it reads the journal on your computer and returns:

- the overall score and the number of failures;
- each journey with its typical (P50, P75, P95) durations against its target, and the share of runs within target;
- the slowest categories and the worst scored events;
- recovered freezes, resource alerts and the Tauri commands that spent the most time.

It never returns prompts, file paths, session identifiers or the raw attributes of an event.

| Option | Values | Default |
| --- | --- | --- |
| `scope` | `local` (this computer), `fleet` (Vato's production aggregates), `both` | `local` |
| `source` | `installed` (the installed app), `dev` (a development build), `auto` (the most recently written) | `auto` |
| `sinceMinutes` | Time window, up to 10 080 (seven days) | 1 440 (24 hours) |
| `category` | One category or prefix such as `journey` or `tauri.command`; for `fleet`, a metric prefix such as `agent` | all |
| `limit` | Rows per ranking, up to 20 | 5 |

> [!NOTE]
> The `fleet` scope reads the production aggregates over SSH and only works from a computer that holds Vato's operator access. Anywhere else it reports that the aggregates are unreachable, and `local` still works. Fleet percentiles are upper bounds of fixed histogram buckets, not exact values.

The tool is not offered in a Vato Connect runner, in a Vato Cloud Bot or in Vato Design.

## If Vato still feels slow

1. Ask an agent for the scoreboard and note which journey is furthest above its target.
2. Compare like with like: a development build runs unbundled code and reads slower than a release. Use `source: "installed"` to look at the installed app only.
3. If you see recovered freezes or a very high number of calls for one command, mention them when you contact [support@vatoide.com](mailto:support@vatoide.com).
4. Free up memory and stop project services you no longer need — see [Not enough memory](not-enough-memory.md).

Source: https://vatoide.com/docs/troubleshooting/performance-and-diagnostics