dsh-token-dashboard

LIMITATIONS

Known limitations

- **Records forward only.** See the accounting choices above. - **The day boundary is a fixed offset, not your system timezone.** It defaults to UTC+8 and is configurable, but it will not follow a laptop across time zones. This is deliberate: a moving boundary would silently split or merge already-recorded days. - **No cost, budget or alerting.** Tokens only. - **Usage is whatever the provider reported.** Providers that do not report usage produce requests with zero tokens; the dashboard shows them as requests and does not invent numbers. - **A superseded attempt counts as its own request, and is not counted as an error.** `llm/stream` is entered once per provider attempt, and DSH retries a failed attempt as a fresh attempt inside the same step. An attempt that ends without reporting usage therefore contributes one `requests` and no tokens, and lands in the recent-calls table as a zero-token row marked `ok`. Measured against the session logs, its fingerprint is unmistakable: `ttftMs === durationMs` (the only chunk arrives as the stream ends, so the first-token sample equals the total duration), `usageReported: false`, a `llm/retry` event inside its span on the same session, and a transport failure. The consequence is that `requests` counts *attempts*, tracking but slightly exceeding the number of billed calls, and that `errors` does not reflect retries. Token totals are unaffected: a superseded attempt reports no usage, so it adds none. In a measured day the plugin's token total reconciled with the logs to within 0.06%, and 294 of 295 calls matched field for field. - **Desktop profile is what this was developed and tested against.** It should work in any profile whose composition provides `llm` and a `connection` carrier, but only the Desktop composition has been exercised.