…#498) * feat(usage): self-service usage and limit status endpoint Add GET /v1/usage so callers can read their own usage, budget, and rate limit status without admin access (ENTERPILOT#466). The response is scoped to the caller's effective user path: the path bound to the managed API key, or the X-GoModel-User-Path header for master-key callers. - usage summary over a date window (start_date/end_date/days, default last 30 days UTC), null when no storage backend records usage - status of every budget covering the path (spent/remaining/period/ exceeded), including budgets inherited from ancestor paths - live counters for every user-path rate limit rule covering the path; provider/model rules are excluded as shared infrastructure - polling the endpoint does not consume rate limit quota New non-enforcing service methods back the endpoint: budget.Service.StatusesForPath evaluates all matching budgets without stopping at the first exceeded one, and ratelimit.Service.StatusesForUserPath reports user-path rules by subtree. The server reaches them through optional type-assertion upgrades of the existing enforcement interfaces. Shared plumbing: the date-range parser moved from admin to usage.BuildDateRange, and the usage reader is created once in app wiring and shared by the server and admin handlers. Swagger regen also picks up the admin rate-limit endpoints (ENTERPILOT#482) that were never regenerated into the checked-in docs. Closes ENTERPILOT#466 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(usage): add dedicated Usage API page with request/response example Full GET /v1/usage walkthrough (quick example, path selection, field reference, date window, errors) under Advanced, linked from the endpoint reference and the user-path page, whose inline section now defers to it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(usage): enforce the 365-day window cap and address review findings Review follow-ups on ENTERPILOT#498: - BuildDateRange now rejects explicit start_date/end_date ranges longer than 365 days (Greptile P1: the documented cap only clamped the days param, so any key could request unbounded historical scans). AddDate keeps the check correct across DST transitions. - A malformed or non-positive days value returns 400 instead of silently falling back to the default window, matching the start_date/end_date validation on the same endpoint. - app wiring resets the usage reader to nil on constructor errors so a typed-nil can never reach the UsageSummarizer nil check. - budget.StatusesForPath returns partial results alongside the error, matching its sibling CheckWithResults. - Table-driven tests for the shared date-range helper, handler tests for the cap and days validation, docs and swagger updated. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(usage): derived usage ratios and relative resets on GET /v1/usage Ecosystem research showed the one idiom every consumer-facing limits surface converged on (Codex, Claude Code, OpenCode) is percent-of-window plus time-to-reset. Expose both as derived fields so status displays need no client-side math or clock-skew handling: - budgets: usage_ratio (spent/amount, unclamped like the admin API) and resets_in_seconds counting down to period_end - rate limits: requests_usage_ratio / tokens_usage_ratio per limited dimension (in-flight feeds the concurrent ratio), an exhausted flag mirroring admission, and resets_in_seconds to window_end (omitted for concurrent rules) Relative resets are computed against server_time, so clients can render countdowns without trusting their own clocks. Also covers the error branches of StatusesForPath/StatusesForUserPath flagged by codecov. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

Endpoint so users can get their own usage (limit/status) #466

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions