The underlying issue here is that OAuth credential reuse is different from API key scraping, and Anthropic hasn't really made that distinction clear. CLI-style usage that respects rate limits and uses official libraries is, architecturally, the same thing Max subscribers do in the web app, same auth, same endpoints. The problem isn't the use case. It's that companies get nervous about anything that looks like it could scale past what they priced in.

It'd be a lot cleaner if they just published explicit rate limits for each subscription tier instead of these vague policy statements.

yeah rate limits are the way to go. I don't see how this is not really simple: A human can only type or tts the text in and read responses only so fast, anthropic can use this as a baseline. They can create a client that can back off(rate limit) and wait, like for something like when a user says something like "spawn 10 processes with claude -p to do X" this client can calculate the rate limit and place an event in a queue and developers can use this client's rate-limit and build workflows around it: e.g. a client queue that has a timer event that expires the rate limit that was set can wake up a daemon. There are a million ways to implement the queue <> daemon thingy, its just software at that point.

Since the subscription is hard linked to an OAuth token this should be easy to track too. What am i missing?