How can we help?

Verifying LLM token tracking by sending a test event

Uri Nativ
Uri Nativ
  • Updated
Torii AI

After installing token tracking, the fastest way to confirm it's working is to run one CLI command on the configured workstation and watch the event tail in Torii.

Where to watch in Torii

In the Torii webapp, navigate to AI → Telemetry and click the tool you just configured (Claude Code, Gemini CLI, or Codex CLI). The tool page shows three things:

  • A Status card at the top that toggles between three states (see "Reading the status card" below).
  • An Event tail table showing recent events (When / User / Model / Kind / Status).
  • A Send a test event button that opens a modal with the exact command to run.

Per-tool test commands

Run one of these on the workstation you configured. Each generates a minimal event with low token cost.

Tool Command
Claude Code echo "hello torii" | claude --print --output-format text
Gemini CLI gemini -p "hello torii"
Codex CLI codex exec "hello torii"

These are non-interactive, exit immediately after producing a short response, and trigger the same telemetry path that normal sessions use. The Send a test event modal in Torii shows the right command for the tool you're on, so you can copy it from there directly.

What to expect after running the command

  1. The CLI executes (typically < 5 seconds).
  2. The CLI's OpenTelemetry export flushes session metrics and logs to https://ai-events.toriihq.com (or to your collector if you're on the collector path).
  3. Within ~5 seconds, the event appears at the top of the event tail in Torii.
  4. The Status card transitions from Waiting for first event… (or Stale) to Connected.

The dashboard auto-polls every few seconds; you don't need to refresh.

Reading the event tail

Column What it shows
When Relative timestamp (e.g. "4s ago", "2m ago"). Hover to see the absolute UTC time.
User For Claude and Codex: the workstation user resolved by the install script (enduser.id resource attribute). For Gemini: user.email if the user is OAuth-authenticated; "anonymous" for Vertex/API-key sessions.
Model The model the CLI used for this session (e.g. claude-sonnet-4-6, gemini-2.5-pro, gpt-4o).
Kind session for CLI sessions.
Status ok (green) for success, error (red) for failed requests, rate limits, or auth issues.

Reading the status card

The Status card is the at-a-glance health indicator. It has three states:

Pending - "Waiting for first event…"

Shown on first visit, before any event has been received from any workstation. Once a single event lands, the card moves to Connected and stays there.

Connected - "Connected - N active users (24h), last event 4s ago"

At least one event has arrived in the last ~14 minutes. The line summarizes the active user count over the last 24 hours and the time since the most recent event.

Stale - "Last event 14m ago - connection may have stopped"

No event has arrived in the last ~14 minutes. This is not necessarily an error - it can mean no one happened to run the CLI lately. Click the Troubleshoot button on the Stale card, or jump to Article 12.

What if no event shows up?

The most common causes, in order of likelihood:

  1. The CLI's existing session hasn't restarted. Some CLIs read their config file at startup; opening a new terminal forces a re-read. Close the current Claude/Gemini/Codex window and run the test command in a fresh terminal.
  2. Outbound HTTPS to ai-events.toriihq.com is blocked. Try curl -v https://ai-events.toriihq.com/health from the workstation. If you get a TCP timeout, work with networking to allow the host.
  3. The wrong token is configured. Look in the relevant config file (~/.claude/settings.json, ~/.gemini/settings.json, or ~/.codex/config.toml) and confirm the token's last 4 chars match the value shown in Torii's Credentials card. The install script's summary line also prints the token's last 4 chars.
  4. The CLI was already running when you installed. Quit and reopen.
  5. You configured one tool but ran a different tool's test command. Each tool has its own page - make sure you're looking at the right one.

See troubleshooting and FAQ for the deeper troubleshooting tree (collector vs MDM specifics, exit codes).

Test events at scale

If you're verifying a fleet rollout, you don't need to run the test command everywhere - instead:

  • Pick a representative set of machines from your MDM inventory (a few per OS, a few per office).
  • Run the test command on each (over SSH, Remote Desktop, or by asking a human at the keyboard).
  • Confirm the User column in the event tail shows each of them appearing in turn.
  • Once the rollout is stable, normal CLI usage by your engineers will continuously feed the event tail - there's no need to keep running test events.

Next steps

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request