System details
Lenovo ThinkBook 14 G3 ACL, AMD Ryzen, Omarchy 4.0.1-1, Pi 0.84.3, pi-subagents 0.56.0, openai-codex provider
What's wrong?
After a Pi session is forked or cloned, the Codex usage shown in Omarchy's Agents panel includes the inherited historical usage from both the parent session file and the forked session file.
Creating the fork copies existing Pi message entries, including their already-recorded usage metadata, into a new session file. Those copied records do not represent new Codex responses. If work then continues in the fork, only the newly generated responses and their newly reported usage should be additional usage.
This can significantly inflate the local Prompt, Token, and Session statistics when multiple subagents use forked context.
Steps to reproduce
- Start a Pi session using the
openai-codex provider.
- Exchange enough messages to produce recorded token usage.
- Fork or clone the session using Pi, or launch a subagent with
context: "fork".
- Refresh the Omarchy Agents panel.
- Compare the reported local usage before and after the fork.
Expected behavior
Usage metadata attached to messages copied from the parent should be counted only once. New assistant responses generated inside the fork should still add their newly reported usage normally.
Actual behavior
The inherited assistant-message records are counted again for every forked session file.
On my machine, three forked sessions contained parent-derived historical usage totaling:
15,716,982 tokens87,744,714 tokens87,744,714 tokens
This caused approximately 191,206,410 tokens of local usage to be counted more than once.
I verified these as inherited copies by following each session header's parentSession path and comparing the copied message IDs, timestamps, content, model, and usage data with the declared parent session.
Technical observation
Pi forked-session headers contain a parentSession field. Inherited message entries retain their original IDs, timestamps, contents, and usage records.
The current collector builds its deduplication key using both the file path and message ID:
message_key = path + ":" + str(entry.get("id") or "")Because every fork has a different file path, inherited copies are treated as separate usage records. This is only a diagnostic observation; the appropriate deduplication strategy is left to the maintainers.
System details
Lenovo ThinkBook 14 G3 ACL, AMD Ryzen, Omarchy 4.0.1-1, Pi 0.84.3, pi-subagents 0.56.0,
openai-codexproviderWhat's wrong?
After a Pi session is forked or cloned, the Codex usage shown in Omarchy's Agents panel includes the inherited historical usage from both the parent session file and the forked session file.
Creating the fork copies existing Pi message entries, including their already-recorded usage metadata, into a new session file. Those copied records do not represent new Codex responses. If work then continues in the fork, only the newly generated responses and their newly reported usage should be additional usage.
This can significantly inflate the local Prompt, Token, and Session statistics when multiple subagents use forked context.
Steps to reproduce
openai-codexprovider.context: "fork".Expected behavior
Usage metadata attached to messages copied from the parent should be counted only once. New assistant responses generated inside the fork should still add their newly reported usage normally.
Actual behavior
The inherited assistant-message records are counted again for every forked session file.
On my machine, three forked sessions contained parent-derived historical usage totaling:
15,716,982tokens87,744,714tokens87,744,714tokensThis caused approximately
191,206,410tokens of local usage to be counted more than once.I verified these as inherited copies by following each session header's
parentSessionpath and comparing the copied message IDs, timestamps, content, model, and usage data with the declared parent session.Technical observation
Pi forked-session headers contain a
parentSessionfield. Inherited message entries retain their original IDs, timestamps, contents, and usage records.The current collector builds its deduplication key using both the file path and message ID:
Because every fork has a different file path, inherited copies are treated as separate usage records. This is only a diagnostic observation; the appropriate deduplication strategy is left to the maintainers.