Wish:
Chutes API should report when the quota resets in a documented UTC datetime format like limit resets at: 2025-09-11T10:13:01+0000
Problem:
I may have a recurring plan that includes some "free" tokens, or there is some of daily limit, and I exceed the hourly or daily or monthly quota. Currently, there is no clear way to tell when the limit resets. So often I would repteadly and blindly re-try your API, and each time I’d do some fall back strategy if I get a refusal.
Suggestion:
When we hit a 429 rate limit or other such quota limit, your API should say when (in UTC datetime) the quota will be reset, and then I could parse that, and not blindly re-try before that time. The format in which your API reports that datetime-based reset should be documented. For example the API response (typically 429) could include the string:
limit resets at: 2025-09-11T10:13:01+0000
Why is this useful?
I'd like to incorporate a fallback to another provider or billing model if I exceed the quota. The blind re-trying is not very healthy and puts a strain on my app and on your API.
Wish:
Chutes API should report when the quota resets in a documented UTC datetime format like
limit resets at: 2025-09-11T10:13:01+0000Problem:
I may have a recurring plan that includes some "free" tokens, or there is some of daily limit, and I exceed the hourly or daily or monthly quota. Currently, there is no clear way to tell when the limit resets. So often I would repteadly and blindly re-try your API, and each time I’d do some fall back strategy if I get a refusal.
Suggestion:
When we hit a 429 rate limit or other such quota limit, your API should say when (in UTC datetime) the quota will be reset, and then I could parse that, and not blindly re-try before that time. The format in which your API reports that datetime-based reset should be documented. For example the API response (typically 429) could include the string:
limit resets at: 2025-09-11T10:13:01+0000Why is this useful?
I'd like to incorporate a fallback to another provider or billing model if I exceed the quota. The blind re-trying is not very healthy and puts a strain on my app and on your API.