Your engineers are running Claude Code, Gemini CLI, and Codex CLI directly on their laptops - making API calls, burning tokens, and producing usage your finance and security teams cannot see. This article explains what Torii's LLM token tracking captures, why admins want it, and what stays private.

What the AI Telemetry feature does

From the AI → Telemetry screen in Torii, you set up real-time ingestion from local AI command-line tools running on your engineers' workstations. Once configured, each tool reports usage to Torii every time someone runs it.

Three CLIs are supported today:

• Claude Code - Anthropic's terminal coding agent
• Gemini CLI - Google's terminal coding agent
• Codex CLI - OpenAI's terminal coding agent

All three are supported on macOS, Linux, and Windows.

What gets captured

For every CLI session and tool invocation:

• Session metadata - who ran the CLI (user email), on which machine (host name + machine ID), against which model (e.g. claude-sonnet-4-6, gemini-2.5-pro, gpt-4o).
• Token usage - input and output token counts per request, so you can attribute spend per user and per team.
• Tool calls (Claude Code only, today) - which tools ran and with what input arguments in truncated form (e.g. the shell command line and file paths), which MCP servers and tools got invoked, and which skills and subagents were spawned. Useful for spotting unexpected tool-chain behavior and approving an MCP catalog.
• Errors - failed requests, rate limits, and protocol-level problems. Useful for spotting misconfigured workstations.

What is NOT captured

This is the question security partners always ask first. The defaults are conservative:

• Prompt contents are off by default. The Claude Code installer sets OTEL_LOG_USER_PROMPTS=0; the Gemini installer sets logPrompts: false; the Codex installer sets log_user_prompt = false. Prompt text never leaves the workstation unless an admin explicitly opts in.
• Model responses are never captured. Token counts are reported, the text the model returned is not.
• Full file contents and tool outputs are never captured. When Claude Code edits a file, the event records the tool name, the file path, and the tool's input arguments in truncated form (512 characters per value, ~4 KB per event) - never the full file and never the command's output. Codex and Gemini report tool usage without argument detail.
• No keystroke logging, no screen capture, no shell history. The CLI emits OpenTelemetry signals about itself; nothing else on the machine is observed.

How it works (at a glance)

Every supported CLI already has built-in OpenTelemetry support. Torii's install scripts configure each tool to emit those signals over HTTPS to a Torii ingest endpoint (https://ai-events.toriihq.com) with an authenticated bearer token. The workstation talks directly to Torii - there is no Torii agent running in the background, no extra daemon, and no kernel extension.

workstation (CLI process)
    │
    │ OTLP/HTTP over TLS
    │ Authorization: Bearer <your-token>
    ▼
https://ai-events.toriihq.com  ──→  Torii AI dashboard

Three deployment paths are available, depending on how your fleet is managed:

• MDM rollout - push an install script via Jamf, Kandji, Intune, JumpCloud, Workspace ONE, Mosyle, SCCM, or any other MDM that can run shell or PowerShell. Best for fleets.
• Existing OpenTelemetry collector - if you already run otelcol-contrib, Grafana Alloy, the Datadog Agent, Splunk OTel, ADOT, or Elastic Agent, add Torii as a second exporter on your collector. Workstation config stays untouched.
• One-liner install - a single curl | bash (or PowerShell iwr) for piloting on a few machines or letting individual power users self-install.

The next article in this series walks through how to pick between them: Choosing how to roll it out.

Why admins want this

• Cost attribution. Anthropic, Google, and OpenAI bill at the API key or account level. Without per-user telemetry, you can see "the engineering org spent $42k on Claude last month" but not "this team spent $18k of it." Torii ties every token back to a workstation and a user identity so finance can chargeback or budget by team.
• Adoption visibility. Did the rollout actually land? Which teams have a power user pattern emerging? Which licenses are unused? You cannot answer any of this from the vendors' admin consoles alone.
• Security oversight. Which MCP servers and tools are engineers wiring into Claude Code? Are subagents being spawned that admins haven't reviewed? Live telemetry lets the security team see the surface area before an incident.
• License rightsizing. When a workstation has stopped reporting events for 30 days, that's a candidate seat to reclaim.

What you need to get started

• A Torii account with admin access to the AI → Telemetry page.
• The ingest token from your AI Telemetry page (it shows up under Credentials - treat it like an API key).
• One of:
  • An MDM that can run shell or PowerShell scripts against your fleet, or
  • An already-running OpenTelemetry collector you can edit, or
  • SSH/RDP access to a single workstation for piloting.
• Outbound HTTPS to ai-events.toriihq.com from each workstation (or from your collector host, if you're using the collector path).

Next steps

• Choosing how to roll it out: MDM, OTEL collector, or one-liner
• Quick install on a single workstation (one-liner)
• Rolling out via MDM - overview and shared steps