How events are counted
How the installers, an AI agent using a Space, agent runs, teleport callers and session deliveries are counted.
How the installers, an AI agent using a Space, agent runs, teleport callers and session deliveries are counted.
Details behind some rows of Telemetry events.
The installers (install.sh, install.ps1) send three events about their
own run: installer_started, then installer_completed or
installer_failed with the part that was running and a fixed reason word.
They follow the same switches as every Cua program (DO_NOT_TRACK,
CUA_TELEMETRY, the config file, CI) and send nothing on a dry run. Before
the first one, the installer prints a short notice saying so. They create
the same anonymous install id, so the app's later events continue the same
install.
installer_failed also carries install_stage, the part that was running
(platform, manifest, cli, runtime, app, driver, sign_in, host or
other), and error_kind, a fixed reason (network, checksum, signature,
unsupported_platform, permission_denied, missing_tool, cancelled or
other), never the message. Both are none on the other two steps. The
installers send as product cli, with $lib cua-installer.
cua_agent_used_space is sent when a tool call from an AI agent (through
cua mcp or the daemon's MCP server) acts inside a Space and works: a
command, a file, the screen, a service or an agent in the Space. It carries
only the kind of tool, at most once per install per UTC day. Calls that only
list, create or share Spaces do not count.
An agent run is counted by the install that started it: once when it
starts, and once when any Cua program of that install first sees its first
turn end, fail or stop. Until then a marker with the same fixed words waits
in ~/.cua/telemetry/agent_runs/ (dropped after 7 days). Cua programs
inside an agent run (CUA_AGENT_RUN_ID set) record no agent runs, so a
Space never counts as an install. Retention counts installs with a
cua_app_active event on day 1, 7 and 30 after their first one.
caller_kind says who asked for a teleport: cua_app_signed (the Cua app or
CLI, verified by its code signature), embedded_sdk (another app that embeds
the cua SDK), unsigned (ad hoc or unsigned code) or unknown (the platform
cannot verify signatures). With caller_kind_source: broker_verified it comes
from the Keyvault broker's OS-verified caller identity; with self_reported
the calling process reported it, and an SDK process only ever reports
embedded_sdk or unknown. Paths, bundle ids and signing ids of callers are
never sent.
A modified build can remove its own telemetry. The receive-side count
(cua_spacesd_session_deliveries) is recorded by cua-spacesd inside the
sandbox, and only when the host enabled telemetry for that sandbox
(CUA_SPACESD_TELEMETRY=1, which the SDK sets on local sandboxes while
telemetry is on).