Provider

Cursor

Budi reads Cursor's local SQLite database for per-message token counts and model info. The Cursor Usage API supplements this with dollar-level reconciliation.

Live since v8.2.0

Data sources

Local SQLite database (primary)

Cursor stores conversation history in a local SQLite database. Budi's daemon tails this database for per-message token counts, model attribution, and conversation metadata. This source provides real-time data with no API dependency.

Path: ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb

Cursor Usage API (supplementary)

The Cursor Usage API provides dollar-level cost data that budi uses for reconciliation. This gives you exact-dollar billing alignment rather than token-estimated cost.

What's parsed

Input and output token counts per message
Model name and version (e.g. claude-sonnet-4-5-20250514, gpt-4o)
Dollar cost (from Usage API reconciliation)
Conversation timestamps and session boundaries
Repo and branch context (from workspace metadata)

Caveats

Usage API lag

Cost data from the Cursor Usage API can lag by approximately 10 minutes. During this window, budi shows token-estimated cost from the local SQLite database. Once the Usage API catches up, budi reconciles to the exact dollar amount.

The SQLite database path varies slightly across Cursor versions — budi auto-discovers the active one.
If Cursor's database is locked (e.g. during a Cursor update), tailing pauses and resumes automatically.

How to verify

After installing budi, open Cursor and send a few messages. Then run:

budi doctor

Look for the Cursor tailer in the output. A healthy check looks like:

✓ Daemon running (pid 12345, port 7878)
✓ Cursor tailer: active
  DB: ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb
  Last event: 4s ago
✓ All checks passed.

To see today's Cursor spend specifically:

budi stats projects --filter cursor