Proposal
I've been using opencode-usage daily and prepared a set of additive features that I'd like to contribute as separate PRs (all are ready, tested, and pass ruff + the existing test suite):
- #?
feat/db-and-no-llm — wire the --db path override through the CLI (it was only consumed by the insights orchestrator via getattr, with no flag to set it) and add --no-llm for data-only insights reports.
- #?
feat/time-granularities — group by minute/hour/week/month in addition to day, plus --weeks N / --months N time windows.
- #?
feat/filters-and-output — row filters (--provider/--model/--agent, repeatable, plus --exclude-provider), --sort cost|calls, a monthly run-rate projection in the summary (also in JSON as run_rate_monthly), and --csv output.
- #?
feat/config-and-commands — optional ~/.config/opencode-usage/config.toml (defaults for period/grouping/sort and [insights] preferred_models for the model picker), providers / models listing commands sourced from opencode models, and a help subcommand with exhaustive documentation.
Notes on cross-PR plumbing
- The
Filters dataclass is defined identically in PRs 2 and 3 (the granularity PR forwards the future filter parameter through by_time); git deduplicates the identical hunk at merge time.
- Each PR keeps the existing tests green and adds its own tests; README is updated per PR.
Happy to rework anything to match your preferences (scope, naming, or splitting).
Proposal
I've been using opencode-usage daily and prepared a set of additive features that I'd like to contribute as separate PRs (all are ready, tested, and pass ruff + the existing test suite):
feat/db-and-no-llm— wire the--dbpath override through the CLI (it was only consumed by the insights orchestrator viagetattr, with no flag to set it) and add--no-llmfor data-only insights reports.feat/time-granularities— group byminute/hour/week/monthin addition today, plus--weeks N/--months Ntime windows.feat/filters-and-output— row filters (--provider/--model/--agent, repeatable, plus--exclude-provider),--sort cost|calls, a monthly run-rate projection in the summary (also in JSON asrun_rate_monthly), and--csvoutput.feat/config-and-commands— optional~/.config/opencode-usage/config.toml(defaults for period/grouping/sort and[insights] preferred_modelsfor the model picker),providers/modelslisting commands sourced fromopencode models, and ahelpsubcommand with exhaustive documentation.Notes on cross-PR plumbing
Filtersdataclass is defined identically in PRs 2 and 3 (the granularity PR forwards the future filter parameter throughby_time); git deduplicates the identical hunk at merge time.Happy to rework anything to match your preferences (scope, naming, or splitting).