{"version":"2.1.246","anchor":"cost-is-stored-per-session-rather-than-only-for-the-most-rec","canonical_anchor":"cost-is-stored-per-session-rather-than-only-for-the-most-rec","heading":"Cost is stored per session rather than only for the most recent one","tier":"internal","area":"Cost Tracking","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246\/e\/cost-is-stored-per-session-rather-than-only-for-the-most-rec","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246","markdown":"### Cost is stored per session rather than only for the most recent one\n\nCost is stored per session id, so more than just the last session's spend can be restored.\n\n**What**\n\nCost is now written to the session store as its own record keyed by session id, replacing global scratch fields that were keyed on the last session id and could therefore only restore the cost of whichever session ran most recently.\n\n**Details**\n\n- The record is schema-checked and holds the session id, total cost in USD, API and tool durations, lines added and removed, per-model usage and a flag for models with unknown pricing.\n- Written on exit, read back per session on resume, merged last-wins, and kept with \"always\" retention so it is not pruned.\n- Whether the record gets emitted at all depends on a guard whose definition is renamed across modules and does not resolve; the merge and retention behaviour is unconditional.\n\n**Evidence**\n\n`cost-state`\n\n- Area: Cost Tracking\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}