---
title: Exo
description: How ClawMetry observes Exo — where its data lives, the environment variables that move it, what cost data is real, and the traps in its store.
eyebrow: Runtime reference
---

# Exo

Exo is a recursive self-improving harness whose state directory is workspace-relative rather than home-anchored — the only runtime in the matrix that works that way, which is why discovery scans instead of resolving a single path.

| | |
|---|---|
| **Runtime id** | `exo` |
| **Category** | Self-improving agent harness |
| **Vendor** | Exo Harness |
| **Tier** | Paid tier (Starter and up) |
| **Upstream** | [github.com/exoharness/exo](https://github.com/exoharness/exo) |

## Where the data comes from

ClawMetry reads these locations, in order, and never writes to any of them.

- `<workspace>/.exo/exoharness/agents/<agent-uuid7>/record.json`
- `<workspace>/.exo/exoharness/agents/<id>/conversations/<conv-uuid7>/events/<event-uuid7>.json`

**Format.** One pretty-printed JSON file per event. Filenames are UUIDv7, so lexical order is chronological order.

## Environment variables

| Variable | Effect |
|---|---|
| `CLAWMETRY_EXO_ROOTS` | path-separated workspaces or .exo dirs to scan |

See [Environment variables](/docs/config/environment/) for the variables that apply to every runtime.

## Tokens and cost

**Tokens.** On the `usage` record attached to a `messages` event, with the full split.

**Cost.** Straight from Exo's own `usage.cost_usd`, computed at call time. When Exo's price-table fetch failed, tokens persist without cost and ClawMetry marks the session `partial` or `tokens_only`.

:::note Why this section exists
Runtimes differ enormously in what they persist. Rather than showing a plausible number everywhere, ClawMetry reports what the store actually contains and marks the rest unknown. A cost of `$0.00` and a cost of *unknown* mean different things, and the dashboard keeps them different.
:::

## Sub-agents and delegation

`thread_forked` events carry fork lineage.

## Things worth knowing

- A ClawMetry session is the Exo *conversation*, because that is the durable unit that owns the event log. Exo's own `session_id` field is a sub-conversation marker and is not surfaced.
- Discovery results are TTL-cached so a page load does not rescan your disk.

## Verify it is being read

```bash
# Is this runtime detected, and would this install unlock it?
clawmetry runtimes --json | jq '.runtimes[] | select(.id=="exo")'

# Why is it locked, if it is?
clawmetry runtimes --why exo

# Any sessions ingested yet?
curl -s 'http://localhost:8900/api/local/sessions?limit=5' \
  | jq '.rows[] | {session_id, agent_id, events, cost_usd}'
```

If detection succeeds but no sessions appear, work through [Troubleshooting](/docs/ops/troubleshooting/) — the usual causes are a relocated data directory (set the override above), a session limit that is hiding older runs, or a runtime that simply has not written anything yet.