Design a credit tracking service for user token balances

Mid February, 2026

Late December, 2025

Credits You're building a system to track balances for the OpenAl API credit purchasing system. API users can purchase credit grants, specified by an ID, that are active at a timestamp and that let them use the API. Unused credit grant balances expire at a certain time. However, there's a kink in our system: requests can arrive out of order because our system is built on a really unstable network. For example, a request to subtract credits can arrive at the system before the request to add credits, even though the request to add credits has a lower timestamp. Your task is to implement the Credits class, which should support the following operations: • Granting credits, subtracting credits, and getting the credit balance for a user • The ability to handle requests that arrive out of order Some guidelines/hints: • Do NOT worry about memory or performance concerns. Write simple, working code. No fancy data structures are needed here. timestamp). • Subtract from grants expiring soonest first. • All timestamps can be represented as ints for simplicity and are unique (no two actions will happen at the same

Late November, 2025

Operations: Add credit: At time t, add x credits, which will expire at time t_expire. Expire credit: Credits added earlier should automatically expire when their expiration time is reached. Cost: At time t, deduct x credits if available. If insufficient credits exist at that time, return False. Requirements: Maintain all events (add, expire, cost) in chronological order. When processing a cost event: First check if the current balance is sufficient. If not, return False. If yes, deduct credits by adjusting the future expire entries accordingly (consume the oldest credits first). The system should support multiple adds, expires, and costs interleaved at different timestamps. Example: Add(10, 5, expire=20) # at timestamp=10, add 5 credits, which expire at 20 Cost(15, 3) # at timestamp=15, consume 3 credits → valid After this operation, the future expire at (20, 5) should be updated to (20, 2).