runtime zmeny

skills/usage/SKILL.md

@@ -1,10 +1,9 @@
 ---
 name: usage
 description: >
-  Show Ollama Cloud credit/usage spent via the ollama.com usage API, and
-  report continuously sampled usage history. Triggers on: "/usage",
-  "ollama usage", "how much credit", "how much have I used up",
-  "credits left", "quota", "usage report", "usage history".
+  How much of the Ollama Cloud plan has been spent — current session and weekly
+  usage per model, and reports over the continuously sampled history.
+  Triggers on: "ollama usage", "usage history".
 ---
 
 # Usage
@@ -27,9 +26,9 @@ Format (script prints it, present it to the user as-is — same lines, same
 order; translate the labels into the user's language, keep the numbers
 exact; no extra model info on the Session/Weekly lines):
 
-```
+```text
 Ollama Cloud usage
-Session: <pct> %, resets in X hours
+Session: <pct> %, resets HH:MM TZ (in H h M min)
 Weekly:  <pct> %, resets in Y days
 Models (request count, weekly window):
   <model>: <count>
@@ -38,14 +37,53 @@ Models (request count, weekly window):
 The per-model breakdown lives only in the "Models" section — never inline
 on the Session/Weekly lines.
 
-## Reset times — derived, not from the API
+Times are printed in the **server's local zone** (`Europe/Prague`), taken from
+the system — no zone is hardcoded. The session line loses its reset clause when
+the history holds no rollover to anchor the window; that is correct output,
+not a failure.
 
-`/api/usage` contains **no reset timestamps** (they exist only in the HTML
-UI). The script computes them: session = until the next full hour UTC (the
-dashboard shows "Resets in 1 hour"), weekly = until the next Monday 00:00
-UTC. Rationale: session usage climbed in real time during testing (rolling
-window), weekly changes slowly — consistent with hourly/weekly windows.
-If the window turns out not to be calendar-based, fix `until_next_*`.
+## Reset times
+
+`/api/usage` carries **no reset timestamps**, neither in the body nor in the
+response headers (re-checked 2026-09-15). Both are derived.
+
+**Weekly:** next Monday 00:00 UTC, `until_next_monday()`. Matches the dashboard.
+
+**Session: a 5-hour window anchored by the first request after the previous one
+ran out** — not a fixed grid. The length comes from
+[ollama.com/blog/transparent-pricing](https://ollama.com/blog/transparent-pricing):
+the new plans dropped the "5-hour or weekly limits" this key still has.
+
+How the anchoring was established on 2026-09-15: usage sat unchanged at
+0.077/21 requests through 05:00 UTC — a fixed grid would have zeroed it there
+and the poller would have recorded it — and only reset when a request arrived
+at 06:00, after a 93-minute pause. Reconstructing the agent's activity gives a
+consistent chain: window 00:00–05:00, then 06:00–11:00, each opened by the
+first request after the previous expiry. A fixed grid would additionally
+require that request to land exactly on a boundary by chance.
+
+So `session_window_end()` takes the **newest rollover in `samples`** and adds
+5 h. A rollover sample marks the start of a new window, not a boundary that was
+due anyway, which is why nothing is ever extrapolated past it: once the window
+runs out, the output says the next one starts with the next request rather than
+naming a time.
+
+That it is a window and not a rolling counter was measured too — usage dropped
+from 0.077/21 to 0.0/`{}` at once; a rolling counter decays gradually.
+
+**The reset is never guessed.** An earlier version assumed a calendar hour and
+printed "resets in 31 minutes" while the dashboard said "Resets in 2 hours" —
+a confident wrong number is worse than none. With no rollover in the history,
+the Session line carries the percentage alone.
+
+Do not compare our countdown against the dashboard's to the hour: the dashboard
+rounds an unknown way (it showed "4 hours" and "3 hours" seven minutes apart),
+which is why the output prints the wall-clock time too.
+
+**If the model is wrong, the report shows it.** `Rollover gap:` lines compare
+consecutive rollovers against the 5 h window — gaps longer than the block
+confirm request-anchoring, a gap exactly equal to it across a long idle stretch
+would point back to a fixed grid.
 
 ## Continuous sampling
 
@@ -63,6 +101,10 @@ Default window is the last 24 hours. Per-model **request counts** are the exact
 figure there — `limits.*.usage` has a resolution of 0.1 %, so short-interval
 percentage deltas are noise.
 
+The report ends with `Rollover gap:` lines and a `Session window:` line —
+when the window in progress started, when it ends, and how the observed
+rollovers line up against the 5 h length.
+
 ## Notes
 
 - Endpoint: `GET https://ollama.com/api/usage`, header