Interactive work
1M input + 200k output tokens per UTC day, 60 RPM, and 2 concurrent requests.
Fair use & limits
Heavy legitimate development and exploitative automation are not the same workload. Newton’s publishes the practical boundaries that protect capacity, accounts, and customer balances.
Six distinct boundaries
Newton’s separates commercial inclusion, operational capacity, and abuse protection instead of hiding all three behind one generic error.
| Boundary | What it means | What happens next |
|---|---|---|
| Funded balance | The wallet cannot cover the next authorization. | The request stops before creating spend beyond the available balance. |
| Rate limit | Too many requests entered the current time window. | Newton’s returns 429 with retry guidance. |
| Concurrency | Too many requests are active at once for the access class. | Reduce parallelism and retry after the active work completes. |
| Route availability | The requested published route is not currently verifiable or available. | Refresh the catalog; Newton’s does not silently substitute another model. |
| Protection state | Safety, fraud, or abuse signals require temporary intervention. | Traffic may be limited, suspended, or sent to review with a reason code. |
| Membership envelope | Solo includes 1M input + 200k output tokens/day. Team pools 6M input + 1M output/day. | The visible threshold resets at 00:00 UTC. Continuous automation moves to Agents. |
Human vs automated
Continuous agents can create a radically different cost and capacity profile from an individual developer. Newton’s does not hide that difference.
1M input + 200k output tokens per UTC day, 60 RPM, and 2 concurrent requests.
Five seats share 6M input + 1M output tokens per UTC day, 120 RPM, and 4 concurrent requests.
Loops and background execution use scoped keys, 60 RPM, 4 concurrent requests, and a prepaid balance ceiling.
If a request is blocked, the reason should help you decide what to do next.