v2.9.0

Added

• Account selection now drains free quota before spending money. An account is kept last in the pool, regardless of selection strategy, only when serving it would bill right now — overage (paid usage past the included quota) is enabled AND its included quota is already spent. An overage account that still has free credits ranks alongside every other account and is used normally, so an account with overage on but credits left is preferred over one whose quota is gone. A billing account never 429s on a spent quota — it keeps serving and charging — so it is selected only once no other account is usable: every free bank spent, or rate-limit waits too long for the selector to wait out. A short 429 leaves an account in the running and is retried there first. The overage flag is read from getUsageLimits' overageStatus, persisted per account (nullable overage_enabled — NULL means "not yet learned from a usage sync", distinct from a confirmed free account), and carried forward from the fresher usage reading so turning overage off in Kiro takes effect on the next sync. Until an account's first usage sync the quota figure is the per-process request counter, not credits, so a billing decision waits for the sync and the account counts as free until then. The startup usage summary now marks each account's state ([overage: billing] / [overage: enabled, free credits left]).

Fixed

• A quota-exhausted account is no longer stuck "unhealthy" forever after its monthly quota resets. When an account hit "You have reached the limit." it was marked unhealthy with a recovery time, but the startup usage sync skipped every unhealthy account (if (!acc.isHealthy) continue) and so never re-read it — leaving its stored quota and health frozen at the moment it ran out, long past the reset and its own recovery time. The startup sync now re-fetches usage for an unhealthy account whose recovery window has passed (keeping only the genuinely dead — revoked/expired credential, missing profileArn — and the still-resting skipped), so the fresh quota revives the account and its overage status is finally read.
• A transient failure Kiro delivers inside an already-open stream (MODEL_TEMPORARILY_UNAVAILABLE, "service is temporarily unavailable", throttling) is now backed off and retried on the same account instead of surfacing as a raw "Connection lost while reading the response". It only retries before the first chunk is emitted; once output has started the stream ends without a replay, per the Smithy rule that a started stream cannot be retried.
• A server-side 500 or 503 no longer switches account after the retry budget — it backs off on the same account and fails there. Switching mid-session abandoned the conversationId and the warm server-side prompt cache, re-billing the rest of the session at full input rate. Account rotation is now reserved for failures where the account itself cannot continue (quota, dead or suspended credential).