cctally 1.20.4 → 1.21.1

package/CHANGELOG.md

@@ -5,6 +5,16 @@ based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## [Unreleased]
 
+## [1.21.1] - 2026-05-28
+
+### Fixed
+- **`cctally statusline` now shows the correct 7d percentage after an Anthropic mid-week reset (or in-place credit) instead of staying pinned to the pre-reset peak.** The statusline's 7d number is monotonic-clamped against a high-water mark read from `weekly_usage_snapshots`, but the clamp keyed only on `week_start_date` — `SELECT MAX(weekly_percent) WHERE week_start_date = ?`. When Anthropic resets a 7d window mid-cycle, the post-reset snapshots keep the *same* `week_start_date` (and `week_end_at`) as the pre-reset ramp, so the bucket-wide `MAX` returned the stale pre-reset peak (e.g. 41%) and clamped the true post-reset value (e.g. 2%) back up to it; the statusline read e.g. `7d 41%` while `cctally report`/`forecast` and the dashboard — which segment the week at the reset via `week_reset_events` — correctly showed 2%. The 5h segment was never affected because a 5h reset mints a new `five_hour_window_key` that naturally scopes its `MAX`. The clamp now mirrors the CLI/dashboard segmentation (`_apply_reset_events_to_subweeks`: the post-reset window's `start_ts` becomes `effective_reset_at_utc`) by flooring the `MAX` to snapshots captured at/after the latest reset effective within the current window — `... AND unixepoch(captured_at_utc) >= unixepoch(<floor>)`, with `unixepoch()` on both sides because reset rows carry mixed offset spellings (`+00:00` and legacy `+03:00`) while `captured_at_utc` uses `Z`, so a lexical comparison would misorder them (the same rule the 5h-block cross-reset flag follows). Weeks with no reset event take the unchanged legacy query, so the normal monotonic-within-window behavior is byte-identical. Regression: new `extensions-hwm-7d-post-reset` fixture in `bin/cctally-statusline-test` (33 scenarios) seeds a pre-reset peak + post-reset row sharing one `week_start_date` plus a `week_reset_events` row and asserts the rendered line reads `7d 2%`, not `7d 41%`.
+
+## [1.21.0] - 2026-05-28
+
+### Added
+- **Claude Opus 4.8 pricing.** `claude-opus-4-8` is now in the embedded `CLAUDE_MODEL_PRICING` table at the standard Opus 4.x rates ($5/MTok input · $6.25/MTok 5-minute cache write · $0.50/MTok cache read · $25/MTok output — identical to Opus 4.5/4.6/4.7), so every cost-computing command (`daily`, `weekly`, `session`, `blocks`, `report`, …) prices Opus 4.8 sessions correctly instead of warning "unknown model, treating cost as $0". The 1M-context variant `claude-opus-4-8[1m]` is added to `CLAUDE_MODEL_CONTEXT_WINDOWS` so `cctally statusline`'s 🧠 context-% segment measures against the real 1,000,000-token window rather than silently falling through to the 200K "opus" family default. Only the bare model id is added (matching how Opus 4.6/4.7 appear in real session JSONL); no dated `claude-opus-4-8-YYYYMMDD` twin is included since Anthropic's published id for this model is the bare alias.
+
 ## [1.20.4] - 2026-05-28
 
 ### Changed

package/bin/_lib_pricing.py

@@ -194,6 +194,12 @@ CLAUDE_MODEL_PRICING: dict[str, dict[str, Any]] = {
         "cache_creation_input_token_cost": 6.25e-06,
         "cache_read_input_token_cost": 5e-07,
     },
+    "claude-opus-4-8": {
+        "input_cost_per_token": 5e-06,
+        "output_cost_per_token": 2.5e-05,
+        "cache_creation_input_token_cost": 6.25e-06,
+        "cache_read_input_token_cost": 5e-07,
+    },
     "claude-sonnet-4-20250514": {
         "input_cost_per_token": 3e-06,
         "output_cost_per_token": 1.5e-05,

package/bin/cctally

@@ -281,6 +281,7 @@ _short_model_name = _lib_pricing._short_model_name
 # Unknown model id → segment renders `🧠 N/A` + one-shot stderr warn.
 CLAUDE_MODEL_CONTEXT_WINDOWS = {
     # 1M-token variants (explicit IDs override the family default).
+    "claude-opus-4-8[1m]": 1_000_000,
     "claude-opus-4-7[1m]": 1_000_000,
     "claude-sonnet-4-5[1m]": 1_000_000,
     # Default 200K for every other Sonnet/Opus/Haiku family member.
@@ -4952,17 +4953,56 @@ def _build_statusline_injections(warn_once):
                     pass
             if seven_resets is not None:
                 try:
-                    # Seven-day window: derive week_start_date from the
-                    # resets_at epoch (reset - 7 days, UTC date).
-                    week_start_date = dt.datetime.fromtimestamp(
-                        int(seven_resets) - 7 * 86400, tz=dt.timezone.utc,
-                    ).date().isoformat()
-                    row = conn.execute(
-                        "SELECT MAX(weekly_percent) "
-                        "FROM weekly_usage_snapshots "
-                        "WHERE week_start_date = ?",
-                        (week_start_date,),
+                    # Seven-day window bounds from the resets_at epoch:
+                    # week_end = reset; week_start = reset - 7 days. The
+                    # date form is the snapshot lookup key (week_start_date
+                    # is deliberately NOT re-anchored across a mid-week
+                    # reset — see _apply_reset_events_to_subweeks).
+                    week_end_dt = dt.datetime.fromtimestamp(
+                        int(seven_resets), tz=dt.timezone.utc,
+                    )
+                    week_start_dt = week_end_dt - dt.timedelta(days=7)
+                    week_start_date = week_start_dt.date().isoformat()
+                    # Reset-aware floor. An Anthropic mid-week reset / in-
+                    # place credit leaves the pre-reset peak snapshots in
+                    # this SAME week_start_date bucket (the boundary the
+                    # snapshots carry does not change). A naive bucket-wide
+                    # MAX(weekly_percent) would clamp the post-reset value
+                    # UP to that stale peak — the statusline would show the
+                    # pre-reset 7d %. Mirror the CLI/dashboard segmentation
+                    # (_apply_reset_events_to_subweeks: post-reset window
+                    # start_ts := effective_reset_at_utc) by flooring the
+                    # MAX to snapshots captured at/after the latest reset
+                    # effective WITHIN this window. unixepoch() on both
+                    # sides — reset rows carry mixed offset spellings
+                    # (+00:00 / +03:00) while captured_at_utc uses 'Z', so a
+                    # lexical compare would misorder them (same rule as the
+                    # 5h-block cross-reset flag).
+                    floor_row = conn.execute(
+                        "SELECT MAX(effective_reset_at_utc) "
+                        "FROM week_reset_events "
+                        "WHERE unixepoch(effective_reset_at_utc) >= unixepoch(?) "
+                        "  AND unixepoch(effective_reset_at_utc) <  unixepoch(?)",
+                        (week_start_dt.isoformat(), week_end_dt.isoformat()),
                     ).fetchone()
+                    floor_iso = (
+                        floor_row[0] if floor_row and floor_row[0] else None
+                    )
+                    if floor_iso is not None:
+                        row = conn.execute(
+                            "SELECT MAX(weekly_percent) "
+                            "FROM weekly_usage_snapshots "
+                            "WHERE week_start_date = ? "
+                            "  AND unixepoch(captured_at_utc) >= unixepoch(?)",
+                            (week_start_date, floor_iso),
+                        ).fetchone()
+                    else:
+                        row = conn.execute(
+                            "SELECT MAX(weekly_percent) "
+                            "FROM weekly_usage_snapshots "
+                            "WHERE week_start_date = ?",
+                            (week_start_date,),
+                        ).fetchone()
                     if row and row[0] is not None:
                         seven_hwm = float(row[0])
                 except Exception:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cctally",
-  "version": "1.20.4",
+  "version": "1.21.1",
   "description": "Claude Code usage tracker and local dashboard for Pro/Max subscription limits - weekly cost-per-percent trend, quota forecasts, threshold alerts. ccusage-compatible.",
   "homepage": "https://github.com/omrikais/cctally",
   "repository": {