Repository navigation
Fix cross-session cost display confusion (throttle starvation + header label) - #23
Merged
Merged
Conversation
The header's dollar figure is the session's own lifetime cost (cost.total_cost_usd off the payload, which can span multiple days across a --resume), rendered right above a day line that means something narrower: today's movement, summed across every session. Unlabelled, the two read as directly comparable and aren't — a long-running session's all-time total can exceed a same-day cross-session sum without either number being wrong. Labelling the header sess makes the distinction visible instead of silently confusing.
The shared usage-history.json write slot was gated on the single most-recent entry in the whole file, regardless of which session wrote it. A session rendering on a clean cadence could win that slot on nearly every tick, starving every other concurrently-running session's writes for as long as it kept rendering. Starved meant invisible: every other pane's day total reads a session's last-written cost, however old, so an indefinitely-starved session could sit tens of minutes stale in every other pane while its own live figure kept climbing — reproduced on real usage data, where two actively-spending API-key sessions went 30-40+ minutes without a write while a third, frequently-rendering session held the shared slot almost continuously. Keying the throttle on this session's own most recent entry (falling back to the shared slot only for samples with no session id at all) bounds staleness to one throttle interval per session regardless of peer activity. This also subsumes two narrow exemptions (changes_shape, hold_probe) that had been added in 1.3.2 to patch the same starvation problem for one specific case; both are now handled by the general fix and are removed along with the now-unused SubSessions::last_sample. MAX_ENTRIES_API grows from 1500 to 12,500 since write volume now scales with concurrent-session count instead of a fixed global 1/min, sized to keep supporting the full 26h lookback for several concurrently active sessions while staying well under READ_CAP_BYTES.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two related fixes to how API-key spend is displayed and persisted:
log_sample's throttle was gated on the single most-recent entry in the whole sharedusage-history.json, regardless of which session wrote it. A session rendering on a clean cadence could win that shared slot on nearly every tick, starving every other concurrently-running session's writes for as long as it kept rendering. Since each pane'sdaytotal is its own live cost plus everyone else's last-written cost, a starved session could read tens of minutes stale in every other pane while its own pane's figure kept climbing — reproduced on real usage data (two actively-spending sessions went 30-40+ minutes without a write while a third held the shared slot almost continuously). The throttle is now keyed per session, which also subsumes the narrowerchanges_shape/hold_probeexemptions added in 1.3.2 to patch the same root cause for one case; both are removed.MAX_ENTRIES_APIgrows 1500 → 12,500 to keep the day figure's 26h lookback intact now that write volume scales with concurrent-session count.--resume), shown right above adayline that means something narrower — today's movement, summed across sessions. Unlabelled, the two read as directly comparable and aren't. Now renders assess $X.Test plan
cargo fmt --check,cargo clippy --all-targets -- -D warningscleancargo test— 87 passed (release and debug)usage-history.json(not the live file)a_busy_sessions_renders_never_starve_an_unrelated_peers_writesas a direct regression test for the starvation scenario, anda_sample_with_no_session_id_falls_back_to_the_shared_slotfor the sid-less fallback path