fix(update): persist LLM costs to llm_costs table during incremental updates - #108
Merged
Merged
Conversation
`repowise update` resolves an LLM provider but never attaches a CostTracker, so every call made during decision rescan and page regeneration silently bypasses persistence. As a result, the `llm_costs` table — and therefore `repowise costs` — only ever reflects the initial `repowise init` run; long-lived projects driven by CI updates report $0 forever. Mirror the wiring that `init` already does: build a DB-backed CostTracker after `resolve_provider(...)` and attach it to `provider._cost_tracker` so subsequent calls land rows in `llm_costs`. Falls back to an in-memory tracker on DB-init failure to preserve the prior no-crash behavior.
5 tasks
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
2 participants
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
repowise updateresolves an LLM provider viaresolve_provider(...)but never attaches aCostTrackerto it. BecauseCostTracker._persist()is gated onsession_factory is not None and repo_id is not None, every LLM call made during an update silently bypasses persistence — no error, no warning. As a result, thellm_coststable (and thereforerepowise costs) only ever reflects the initialrepowise initrun.For long-lived projects driven by CI-style updates, this is invisible until you go looking: the wiki keeps growing, but
repowise costsreports $0.00 indefinitely.Repro
repowise inita project — costs land inllm_costs✅repowise update— wiki pages regenerate, butllm_costsgets no new rows ❌repowise costs— only the init run shows upYou can confirm this in 0.3.1 / 0.4.0 with:
Fix
Mirror the wiring
init_cmd.pyalready does (provider._cost_tracker = cost_trackerat lines 385 and 1289) insideupdate_cmd.py, right afterresolve_provider(...). Falls back to an in-memoryCostTracker()if DB initialization fails, preserving the prior no-crash behavior.The block is intentionally identical in shape to
init's_make_cost_tracker()so the two stay in sync.Diff size
+30 / -0, all in one function. No tests added — there is no existing CostTracker-attachment test covering
init's wiring either, and the change is structurally identical to that already-working code path. Happy to add one if you'd like.Verification
make test-fast— green (15/15 intests/unit/cli/test_commands.py)ruff check— no new lint errors introduced (10 pre-existing → 10 post-change)ruff format --check— added block is format-clean