Repository navigation
Why toard
AI coding tools make it easy to experiment across providers, models, and machines. They can also make usage difficult to understand: data is spread across local sessions, costs are calculated differently by each tool, and a team has no shared place to inspect the result.
toard is a self-hosted dashboard for bringing that usage into one organization-owned service. It supports Claude Code, Codex, Gemini, Qwen, and other providers through a common usage-event model.
The default collector is a small local shim. It reads usage from local session files, normalizes it, and sends authenticated usage events to your toard server. Because collection is file-based, it does not require telemetry environment variables or restarting an AI tool; a first scan can also backfill existing usage.
An ingest token identifies the receiving user. The server, not the client, determines user attribution and calculates cost from its pricing data before storing events. This gives the dashboard one cost-calculation path even when the underlying tools report usage differently.
toard provides personal, team, and organization views. The shim can attach a device label so a user can distinguish their own machines; users can set a label or disable that label when a hostname is sensitive.
Start with Docker Compose, or use Kubernetes or Helm when your platform already uses them. Postgres is the default storage backend; ClickHouse is an optional backend for event and aggregation workloads while account and authentication metadata remain in Postgres.
Default collection is usage metadata used to describe and price activity, such as provider, model, token counts, timestamps, and an optional device label. It does not enable prompt or response-content collection.
Content collection is a separate choice. It requires server-side encryption configuration and is off by default, so the normal install flow is individual opt-in. An organization can deliberately use CONTENT_COLLECTION_DEFAULT=on to offer an opt-out policy during installation; that policy should be reviewed and clearly communicated before enabling it for anyone. See Privacy-and-security.
Local session-file pull is the supported default path. OTLP push remains available only as an experimental path. Do not enable it for a normal rollout: it requires the experimental setting and compatible server-side provider configuration, and is kept separate from pull collection to avoid duplicate events.
- Need the data flow first? Read How-it-works.
- Ready to run a first server? Follow Quickstart.
- Planning an organization rollout? Start with Roll-out-your-team.
- Choosing an operating platform? Read Deploying-toard.