Summary
Add a summarize command that answers "what did I work on?" from the sessions Auryn already discovers, grouped by time, by place, or by tool.
Auryn knows about every session across four providers, but the only way to see that as work is to read the list and count by eye. The data needed for a real answer is already in the normalized Session model: provider, project path, begin and last-used dates, message count.
Motivation
Concrete cases this covers:
- Writing a standup or a weekly update, and needing to recall Tuesday.
- Filling in a timesheet against projects rather than sessions.
- Answering "how much of this month went to client X?"
- Noticing which tool is actually getting used.
Today, all of these mean scrolling the auryn list and tallying manually.
Proposed behavior
auryn summarize # the last 7 days, by day
auryn summarize --last 30d --group-by week
auryn summarize --since 2026-08-01 --until 2026-08-28
auryn summarize --last 90d --group-by project
auryn summarize --last 30d --group-by repo
auryn summarize --last 7d --group-by provider
auryn summarize --format md --out weekly-report.md
auryn summarize --format json | jq '.totals'
Grouping dimensions: day, week, month, project, repo, provider, none. Output as text, Markdown, or JSON, to stdout or --out, matching how export already behaves.
Sample output:
Work summary
Range: since Jul 30, 2026
Grouped: by repo
Totals: 153 sessions, 6275 messages, 46 projects, 2 providers, 26 active days
/Users/dev/Projects/project1 (56 sessions, 1676 messages)
/Users/dev/Projects/projectb (12 sessions, 722 messages)
/Users/dev/Projects/projectx (9 sessions, 776 messages)
In the TUI, S and /summarize [dimension] would open a scrollable summary of whatever is currently on screen, so filtering and then summarizing composes.
The same --since, --until, --last, --project, and --provider flags would also work on list and filter, which is useful on its own.
Decisions I made
Change any of these if you disagree.
Aggregation only, no API calls. The README rules out credential management, traffic, and model routing. So this counts what is already scanned rather than sending conversations anywhere, which keeps it offline and instant.
Local time, not UTC. A 7 pm Pacific session is already the next UTC day, so bucketing in UTC files Monday's work under Tuesday. A fixed offset means bucket edges can be an hour off across a DST change, which beats carrying a time-zone database.
One bucket per session. Begun Monday, touched Tuesday: attribute by last-used, with --by began to flip it. Splitting by message timestamps is more faithful but re-reads every session file in range.
No time-worked metric. The session model has no tokens, no cost, no record of attention. So: sessions, messages, projects, providers, active days, and the span between first and last activity. A span is not time worked.
Not in this proposal
A later phase could render a brief to stdout:
auryn summarize --last 7d --brief | claude -p "Write my standup update"
Same hand-off model as resume, so the credential stays in the tool that owns it.
Notes
- No changes needed under
src/providers/. The feature works from the normalized model, so new providers get summaries for free.
- No session files are read. Aggregation uses the metadata scanning already collected, so a summary costs no more I/O than the listing.
- Worth knowing: git worktrees record
.git as a file pointing at the main repo, so --group-by repo has to follow that pointer, or every worktree becomes its own bucket. On my own sessions that split one project's 56 sessions across five buckets before I handled it.
I have a working implementation with tests, an ADR covering the decisions above, and docs. Will open it as a PR, or to rework the approach first if the aggregation-only framing is not the direction you want.
Summary
Add a
summarizecommand that answers "what did I work on?" from the sessions Auryn already discovers, grouped by time, by place, or by tool.Auryn knows about every session across four providers, but the only way to see that as work is to read the list and count by eye. The data needed for a real answer is already in the normalized
Sessionmodel: provider, project path, begin and last-used dates, message count.Motivation
Concrete cases this covers:
Today, all of these mean scrolling the
auryn listand tallying manually.Proposed behavior
Grouping dimensions:
day,week,month,project,repo,provider,none. Output as text, Markdown, or JSON, to stdout or--out, matching howexportalready behaves.Sample output:
In the TUI,
Sand/summarize [dimension]would open a scrollable summary of whatever is currently on screen, so filtering and then summarizing composes.The same
--since,--until,--last,--project, and--providerflags would also work onlistandfilter, which is useful on its own.Decisions I made
Change any of these if you disagree.
Aggregation only, no API calls. The README rules out credential management, traffic, and model routing. So this counts what is already scanned rather than sending conversations anywhere, which keeps it offline and instant.
Local time, not UTC. A 7 pm Pacific session is already the next UTC day, so bucketing in UTC files Monday's work under Tuesday. A fixed offset means bucket edges can be an hour off across a DST change, which beats carrying a time-zone database.
One bucket per session. Begun Monday, touched Tuesday: attribute by last-used, with
--by beganto flip it. Splitting by message timestamps is more faithful but re-reads every session file in range.No time-worked metric. The session model has no tokens, no cost, no record of attention. So: sessions, messages, projects, providers, active days, and the span between first and last activity. A span is not time worked.
Not in this proposal
A later phase could render a brief to stdout:
Same hand-off model as
resume, so the credential stays in the tool that owns it.Notes
src/providers/. The feature works from the normalized model, so new providers get summaries for free..gitas a file pointing at the main repo, so--group-by repohas to follow that pointer, or every worktree becomes its own bucket. On my own sessions that split one project's 56 sessions across five buckets before I handled it.I have a working implementation with tests, an ADR covering the decisions above, and docs. Will open it as a PR, or to rework the approach first if the aggregation-only framing is not the direction you want.