What do you want to change?
Let the config file declare extra pi-format session stores, each surfacing as its own agent in the unified reports:
Rows from a named store get their own agent name, [omp] -prefixed model labels, and the usual session metadata — alongside the default pi store, which is untouched.
Why?
Tools built on pi (oh-my-pi is the one I use) write pi-format stores at their own paths. ccusage can read one pi universe at a time via --pi-path/PI_AGENT_DIR, and labels everything it reads pi. So if you use pi and a fork, there's no way to see both in one unified report: you run a second invocation against the fork's path and try to merge the output yourself — except both come back tagged pi, so you can't tell them apart, and you've paid the full load twice.
Since the file format is identical, ccusage already knows how to read these stores. This just gives them a name.
How? (optional)
Config-only (no new CLI flags; per-agent subcommands stay a closed set — named stores appear in unified reports only). Reuses the existing pi parser with the store name threaded through for labels and dedupe identity. Store names are validated (pattern, no collisions with built-in agents, no duplicate/overlapping paths, so double-counting isn't possible), and costs are always computed from the real model name — the store name never participates in pricing lookup. Without pi.stores in config, output is byte-identical to today.
I have this implemented with tests and the config schema regenerated, and can open a PR.
What do you want to change?
Let the config file declare extra pi-format session stores, each surfacing as its own agent in the unified reports:
{ "pi": { "stores": [ { "name": "omp", "path": "~/.omp/agent/sessions" } ] } }Rows from a named store get their own agent name,
[omp]-prefixed model labels, and the usual session metadata — alongside the default pi store, which is untouched.Why?
Tools built on pi (oh-my-pi is the one I use) write pi-format stores at their own paths. ccusage can read one pi universe at a time via
--pi-path/PI_AGENT_DIR, and labels everything it readspi. So if you use pi and a fork, there's no way to see both in one unified report: you run a second invocation against the fork's path and try to merge the output yourself — except both come back taggedpi, so you can't tell them apart, and you've paid the full load twice.Since the file format is identical, ccusage already knows how to read these stores. This just gives them a name.
How? (optional)
Config-only (no new CLI flags; per-agent subcommands stay a closed set — named stores appear in unified reports only). Reuses the existing pi parser with the store name threaded through for labels and dedupe identity. Store names are validated (pattern, no collisions with built-in agents, no duplicate/overlapping paths, so double-counting isn't possible), and costs are always computed from the real model name — the store name never participates in pricing lookup. Without
pi.storesin config, output is byte-identical to today.I have this implemented with tests and the config schema regenerated, and can open a PR.