Repository navigation
feat(usage): read Devin usage from the Devin CLI's session history - #12
Merged
Merged
Conversation
Devin usage came only from T3's own event logs, which missed sessions run outside T3 and captured roughly one usage event per turn instead of one per model request. Read per-request metrics from the Devin CLI's sessions.db instead, following the OpenCode reader, and fall back to the event logs only when that database is missing. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Devin usage only came from T3's own provider event logs. That missed every Devin session run outside T3, and even for T3-run sessions it captured roughly one usage event per turn instead of one per model request. On one real session, the event logs recorded about 2–5% of the tokens Devin itself recorded (for example 4,153 vs 1.80M uncached input tokens).
Fix
Upstream's new Cursor, OpenCode and Antigravity readers (pingdotgg#10409 upstream) read each provider's own local history store. Devin keeps an equivalent SQLite store at
~/.local/share/devin/cli/sessions.db, and every assistant message records its request'sinput_tokens(uncached),output_tokens,cache_read_tokens,cache_creation_tokensandgeneration_model.devinUsageReader.ts, modeled onopencodeUsageReader.ts: opens the database read-only with a shortbusy_timeout, and extracts only the usage fields in SQL so large tool outputs never load into memory.message_id, because forked sessions copy nodes (67,698 assistant rows vs 20,283 distinct messages locally). Records use each message's own timestamp, so a fork's later copy can't pull an old message into a recent date range.HOME, as the Cursor path already did, so tests read their fixtures instead of the real machine's history.docs/user/usage.md, and fixed an existing Devin test whose expected record was missing thefastfield added in the upstream sync.Against a snapshot of real data, a 30-day read took about 0.6 s: 8,024 requests across 80 sessions.
compactor(Devin's context compaction) and someglm-*requests are counted but unpriced unless a custom price is set.Verified with
vp test run src/usage/(125 passing), plus lint and a typecheck of the server package.Co-Authored-By: Claude Opus 5.5 (1M context) noreply@anthropic.com
🤖 Generated with Claude Code