{"version":"2.1.242","anchor":"rate-limit-telemetry-records-every-window-not-just-the-tight","canonical_anchor":"rate-limit-telemetry-records-every-window-not-just-the-tight","heading":"Rate-limit telemetry records every window, not just the tightest one","tier":"internal","area":"Rate Limits","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.242\/e\/rate-limit-telemetry-records-every-window-not-just-the-tight","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.242","markdown":"### Rate-limit telemetry records every window, not just the tightest one\n\nUsage telemetry now records every rate-limit window separately, including seven-day and overage figures.\n\n**What**\n\nSession telemetry now carries a per-window utilization breakdown with optional `five_hour`, `seven_day` and `seven_day_overage_included` entries, each holding a utilization number and a reset time, taken from the rate-limit headers on responses.\n\n**Details**\n\n- Utilization can exceed 1, for example when a lower-priority episode runs past the 5-hour limit.\n- Events fire when a window's rounded percentage or its reset time moves, not only when the overall status changes.\n- The field is always absent for API-key, Bedrock and Vertex sessions, and only appears once a response carrying the headers has been seen.\n- The existing overall overage status is unchanged.\n\n**Evidence**\n\n`unifiedWindows`\n\n- Area: Rate Limits\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 3\/5"}