Intelligence Usage

Growth OS Phase 5 (2026-08-04) -- devrel view over the Intelligence API's real usage, joining three tables that were each built for a narrower purpose and never had a combined admin view before: api_keys (admin-issued), self_serve_api_keys (automated free-tier signup, services/api_key_service.py), and intelligence_api_usage (per-key per-day weighted-call counter, services/ intelligence_quota_service.py). No new table -- purely a read-side join for visibility, same "packaging, not new infrastructure" posture as api/intelligence.py itself.

Per-key last_used_at and issuance metadata come from whichever of the two key tables issued it; usage counts come from intelligence_api_usage keyed by the raw key string, matching how api/intelligence.py's _check_and_spend_quota() already writes to it.

2026-09-07 (security review: hash keys at rest -- see services/ api_key_service.py's verify_key() docstring for the full story): api_keys.key/self_serve_api_keys.key now hold a HASH for every migrated/freshly-issued row, not the raw key -- so this view's join against intelligence_api_usage (still raw-key-keyed; that table is an ephemeral per-day counter, not a persistent credential store, and was deliberately left out of the hashing migration) can no longer match on the key value directly. Fixed by hashing each usage row's raw api_key here instead, so the join happens hash-to-hash -- intelligence_api_usage itself is untouched, this endpoint just reads it differently.