1# Product usage data
2
3The T3 Code server sends product usage events to T3 Code's own endpoint at `ingest.t3.codes`,
4associated with a hashed account or installation identifier. To count how many installations one person
5uses, the server also sends hashed account identifiers: your T3 Connect account, your OpenAI and
6Claude accounts when you are signed in, and a random identifier for each device that connects. The endpoint keeps a copy of each
7event and forwards events to PostHog. Events include the provider, model, reasoning effort,
8permission mode, turn and request results, duration, release channel, and token counts when
9available. Child-agent token counts are reported separately from the main agent's. Model names
10are sent only when they appear in a provider's public model list.
11
12Product events do not include prompts, responses, file contents, authentication tokens, conversation IDs,
13raw provider events, or child-agent output.
14
15## Relay connection diagnostics
16
17T3 Code sends relay connection traces to Axiom to diagnose T3 Connect connectivity. These are
18separate from product events. Depending on the client version, traces can include connection
19timings, environment identifiers and the connected machine's name. Failed spans can include error
20messages and stack traces; error text can quote a value the app was handling.
21
22To disable product events and relay tracing from the server, set
23`T3CODE_TELEMETRY_ENABLED=false` in its environment before starting it. Relay tracing also stops
24when `T3CODE_OTEL_SDK_DISABLED` or `OTEL_SDK_DISABLED` turns OpenTelemetry export off.
25
26An administrator can turn product events and relay tracing off in the server and desktop app with
27a [managed policy](./managed-policy.md#other-capabilities). This does not control traces sent by
28separate browser or mobile clients.
29
30The desktop app reads `T3CODE_TELEMETRY_ENABLED` from your shell profile (for example `~/.zshrc`) on macOS and
31Linux, so export it there and restart the app. On Windows, set it as a user environment variable.
32
33The web app in a browser, including one the `t3` CLI opens, does not read these environment
34variables. When its build has relay tracing configured, it sends its own connection traces even
35if the server has opted out. The browser app has no relay tracing toggle.
36
37## Mobile app diagnostics
38
39When the iOS or Android app crashes or hits an error, it sends a report to T3 Code: the error
40message, the stack trace, the app version, and the device model and OS version. Each launch also
41sends startup timings, and every report carries a random ID for the install. Reports go through
42the T3 Connect relay to Axiom. They do not include your threads, prompts, or connection details,
43but an error message can quote a value the app was handling.
44
45To stop sending them, turn off **Send crash reports** in **Settings > About T3 Code > Diagnostics**.
46
47The mobile app also sends relay connection traces when its build has tracing configured. These
48carry an identifier for the current app session. **Send crash reports** does not control these
49traces, and the mobile app has no separate relay tracing toggle. Server environment variables and
50managed policy do not disable mobile tracing.
51
52## Agent activity for mobile notifications
53
54When **Publish agent activity** is enabled on a host, it sends project and thread titles, model
55names, activity status, and environment and thread identifiers to the T3 Connect relay for
56[mobile notifications and live activities](./mobile-notifications.md). This is separate from
57product events and relay diagnostics. The telemetry opt-out does not disable it.
58
59To stop publishing, turn off **Publish agent activity** under **Settings > Sharing & access** on
60the host. Turning off notifications on a phone controls that phone's alerts, not the host's
61publishing setting.
62
63## Export diagnostics to your own receiver
64
65To send traces, metrics, or logs to an OpenTelemetry receiver, open
66**Settings > Maintenance > Diagnostics**, select an environment, and enter each signal's OTLP HTTP
67endpoint under **OpenTelemetry export** (for example `http://localhost:4318/v1/traces`). Save, then
68restart that environment's server. The receiver must be reachable from the server's machine.
69**Test** sends an empty export from the server to check an endpoint before or after you save it;
70saved endpoints are checked when the section opens. Checks send authentication headers only to
71the signal's currently running endpoint and do not follow redirects. To check a new endpoint
72that requires authentication, save it and restart the server first.
73
74`T3CODE_OTLP_*_URL` and standard `OTEL_EXPORTER_OTLP_*` environment variables override the saved
75settings. An overridden signal shows **Set by environment** and names the variable that set it, and its
76**Test** checks the running endpoint instead of the field. For endpoints saved here or set with `T3CODE_OTLP_*_URL`, set `T3CODE_OTLP_HEADERS` for
77receivers that need authentication and `T3CODE_OTLP_PROTOCOL=http/protobuf` for receivers that do
78not accept JSON. An endpoint set with `OTEL_EXPORTER_OTLP_*` takes its headers and protocol from
79`OTEL_EXPORTER_OTLP_HEADERS` and `OTEL_EXPORTER_OTLP_PROTOCOL` instead.