Could you please tell me when KiroAi's quota resets?

[awjdoiajdi]

Could you please tell me when KiroAi's quota resets?

[diegosouzapw]

Hey @awjdoiajdi! Kiro's free quota resets on a monthly cycle (the free tier is roughly 50 credits/month on the AWS Builder ID side), not a daily/5-hour window.

The catch is the exact reset moment is per-account and controlled by AWS, not by OmniRoute -- so rather than guess, OmniRoute reads the real reset timestamp straight from Kiro's usage API (GetUsageLimits) and shows it for each Kiro connection. To see your exact reset time:

• Dashboard -> Providers -> your Kiro connection -> the usage/quota panel shows used / total plus the reset date for that account.

If your account returns no per-resource breakdown (some IAM / Builder ID accounts don't expose it), the panel will say so and the reset date won't be available -- in that case the practical answer is "start of your next monthly cycle." Related thread: #1809.

If you tell me what the usage panel shows for your Kiro account, I can help interpret it.

[awjdoiajdi]

forgot about the quota—I also wanted to ask if that’s normal or not?

[diegosouzapw]

Thanks for the screenshots @awjdoiajdi -- yes, what you're seeing is expected behavior for a free Kiro account, not a bug. Two separate things are happening:

1. The 400 UPSTREAM rows (opus-4.6/4.7/4.8, sonnet-4.6, and kr/claude-sonnet-4.5)

Those 400s come straight from Kiro upstream as Improperly formed request, which is Kiro's signal for "this model isn't available on your account tier." Kiro's model entitlement is per-account / per-tier on the AWS Builder ID side: the free tier serves claude-sonnet-4.5, claude-haiku-4.5, and glm-5 (exactly the ones returning 200 for you), while claude-opus-4.6/4.7/4.8 and claude-sonnet-4.6 require a higher Kiro plan (Pro / Pro+ / Power). OmniRoute lists all of them in the Kiro catalog, but the actual availability is decided by AWS per account -- so on a free account the Opus/4.6 models will 400.

When that 400 happens, OmniRoute's resilience layer locks just that model for that connection and moves on to a working one -- which is why you see the 400 rows interleaved with successful 200 rows. Nothing is broken; the combo is doing its job.

2. The kr/claude-sonnet-4.5 400 specifically

This one is different from the plain claude-sonnet-4.5 (which succeeds). Look at the resolved column in your screenshot: it shows kiro/kr/claude-sonnet-4.5 -- the kr/ got baked into the model name sent to Kiro, and Kiro has no model literally named kr/claude-sonnet-4.5, so it 400s. kr/ is OmniRoute's provider alias for Kiro (it's meant for the top-level model selector, to force the request onto Kiro). It should not be part of the model id inside a combo target that's already pinned to Kiro. Fix: in that combo/config, use just claude-sonnet-4.5 (no kr/ prefix). If you typed kr/claude-sonnet-4.5 as a top-level model and OmniRoute itself double-prefixed it, tell me exactly where you set it (combo target list? client model string?) and I'll trace whether that's a stripping bug.

3. The slow / tiny-output requests (81s for 17 tokens, "1m 27s / 3 tokens")

That's not a Kiro pathology. The 400 rows are fast skips; the slow successful one is a large agentic prompt (43,331 input tokens) where the model produced a short turn -- a tool call or an early finish returns very few output tokens even though the upstream spent real time on it. Combo fallback re-tries (skipping the locked Opus/4.6 models before landing on a free one) also add a bit of wall-clock. For a free Kiro account on a big prompt, those durations are within normal range.

Recommendation: pin your Kiro combo to the free-tier models only -- claude-sonnet-4.5, claude-haiku-4.5, glm-5 -- and drop the kr/ prefix from any combo entries. That removes the 400 noise entirely. If you want the Opus / Sonnet-4.6 models, you'd need a paid Kiro plan on the AWS side.