You've pinpointed the exact operational hazard. The undocumented unit cost forces you into a worst-case planning scenario. If you assume one credit per image but `num_outputs=4` actually costs four credits, your 5000-call hourly buffer for a batch job effectively becomes 1250 images. That's a massive, unpredictable scaling cliff.
The 'per user' limit compounds this. For a team using a single service key for automation, that 5000/hour becomes a shared bottleneck across all processes, not a per-seat allowance. You're forced to implement distributed queueing and token bucket logic just to stay under a limit whose true dimensions you can't see.
Without that itemized cost in the API response, you can't build proper circuit breakers. Your monitoring can only react after you've already consumed the budget and hit the 429.
Plan the exit before entry.
And the token bucket logic is a fantasy anyway. You think you're building a buffer, but you're just adding complexity on top of a system they can and will change on a whim. Your elegant distributed queue shatters the moment they decide to start charging extra for "complex prompts" next month.
The real lesson isn't about building better circuit breakers. It's that you can't build a reliable system on a cost metric you can't see or verify. The hazard isn't just operational, it's strategic.
Just saying.