How to Check Amp, Droid, and Goose Token Usage

Amp, Droid, and Goose represent a new wave of AI coding agents that focus on autonomous task execution and multi-step workflows rather than pure chat. Because they are newer tools, none of them has shipped a polished usage dashboard yet — so if you want to know how many tokens your last Goose run consumed, or how much Amp has spent this month across all your Sourcegraph sessions, the only way to find out is to read the logs directly. That's exactly what npx whoburnedmore does, using the ccusage data sources for each agent.

Where do Amp, Droid, and Goose store their logs?

Each agent writes logs to a different location. whoburnedmore scans all of them automatically, but knowing the paths is useful for manual inspection or debugging:

Amp (by Sourcegraph)

Amp is the AI coding agent from Sourcegraph, designed to work across your entire repository with deep code-search context. It writes session logs to:

# macOS~/Library/Application Support/amp/sessions/ # Linux (XDG base dir)~/.local/share/amp/sessions/ # Check session count$ ls ~/Library/Application\ Support/amp/sessions/ | wc -l     23

Each Amp session file is a JSON document containing the model used (typically Claude 3.5 Sonnet via the Anthropic API), input and output token counts per turn, and the timestamp. Amp's deep code-search features tend to generate large input contexts — a single repository-scan session can consume 500K+ input tokens — so Amp users often find their token counts climbing faster than with chat-only agents.

Droid (by Factory)

Droid is Factory's autonomous coding agent, built for multi-step refactors and large-scale automated tasks that run without continuous human oversight. Its logs live at:

# macOS / Linux~/.factory/droid/sessions/ # Or check the Factory config for a custom path:$ cat ~/.factory/config.json | grep dataDir  "dataDir": "/Users/you/.factory"

Droid's autonomous mode can chain many tool calls in a single session — file reads, test runs, code edits — each of which adds tokens to the session total. The log captures each tool-call round trip separately, so the per-session cost breakdown in whoburnedmore accurately reflects what long autonomous runs actually consume.

Goose (by Block)

Goose is Block's open-source AI agent for developer automation tasks. It follows the XDG Base Directory spec:

# macOS / Linux~/.config/goose/sessions/ # Each session:~/.config/goose/sessions/2026-06-14_session.jsonl # Goose uses JSONL (one JSON object per line per turn)$ wc -l ~/.config/goose/sessions/*.jsonl | tail -1  312 total

Goose writes JSONL rather than a single JSON object per file — each line is one turn. The ccusage adapter handles this format natively, so whoburnedmore parses it correctly without any extra configuration.

How do I run the check for all three agents?

A single command covers all three. whoburnedmore automatically detects which agents have logs on your machine and includes only those that have data:

$ npx whoburnedmore↳ scanning local usage logs…  amp: 23 sessions found  droid: 9 sessions found  goose: 14 sessions found   TOOL          TOKENS      PRIMARY MODEL       EST. COST  amp            8.3M        claude-3-5-sonnet   $24.80  goose          5.7M        claude-3-5-haiku    $12.40  droid          3.2M        claude-3-5-sonnet    $9.60  ─────────────────────────────────────────────────────  subtotal      17.2M                           $46.80

How is the cost calculated across agents?

Because Amp, Droid, and Goose can each use different underlying models, the cost formula must account for per-model pricing across the board:

In practice, Amp defaults to Claude 3.5 Sonnet ($3/M input, $15/M output), Goose often uses Claude 3.5 Haiku for lightweight tasks ($0.80/M input, $4/M output), and Droid's choice of model depends on your Factory configuration. The cost difference between Sonnet and Haiku is 3-4x per token, so an agent that uses a lighter model for routine tasks can look much cheaper per-session even if it runs more sessions.

Input vs output token ratio matters

Autonomous agents like Droid and Goose tend to have a high input-to-output ratio because each step involves reading files, running tools, and feeding results back into the context. A Droid session that refactors 20 files might consume 2M input tokens (reading files + prior turns) but only 400K output tokens (the actual edits). At Sonnet prices, that 5:1 ratio costs roughly $6.00 + $6.00 = $12.00 — output tokens are 5x more expensive per token but there are far fewer of them in autonomous workflows.

How do these agents compare to each other?

All three agents are built for autonomous, multi-step work — but they differ in design focus, default model, and how much context they pull per task:

Can I put my Amp / Droid / Goose usage on the leaderboard?

Yes — the leaderboard counts tokens from all supported tools, not just the mainstream ones. If your Amp repo-scan sessions have been burning 8M tokens a week, that total rolls up into your leaderboard score alongside any Claude Code, Codex, or Gemini CLI usage you also have. The leaderboard is a unified count of every token you've consumed across all the tools whoburnedmore supports:

1. 1

   Run the command

   npx whoburnedmore — it scans for Amp, Droid, and Goose logs alongside all other supported agents automatically.
2. 2

   Review the breakdown

   Check that the session counts look right for each agent. If any show zero, run with --debug to inspect which paths were scanned.
3. 3

   Submit to the leaderboard

   When prompted, confirm the submit. Only your username and aggregate token totals are sent — never your prompts, code, or session content.
4. 4

   View your public dashboard

   Your leaderboard entry links to a per-tool breakdown so visitors can see which agents you run, not just your grand total. It's a useful signal for the community about which tools developers are actually using in practice.

For the full picture of how newer terminal agents fit into the broader AI coding landscape, see the AI coding token leaderboard guide, which shows the aggregate token burn across all supported tools and how the community's usage is distributed. If you also use opencode, the opencode token usage guide covers the same one-command workflow with opencode-specific session log details. 🔥