Hard ceilings before provider work
Limits and cost controls
Design clients around organization quotas, rate and concurrency limits, bounded retries, response ceilings, and disabled billing or overage states.
Read limits; do not guess
Limits can vary by product, organization enrollment, and beta configuration. Use service capability responses and documented data-plane limits. A missing measurement is unavailable, not zero.
- Check organization usage and capacity before creating work.
- Respect per-user, per-organization, per-second, per-hour, concurrency, payload, and output bounds.
- Keep retries finite, exponential, jittered, and aware of
Retry-Afterwhen present. - Treat pending and uncertain work as consuming capacity until the service says otherwise.
- Billing disabled means no charge is active; it does not mean provider resources are free or unlimited.
Default client bounds
- Management client timeout: 15 seconds.
- Developer client result ceiling: 512 KiB.
- MCP inbound JSON-RPC frame ceiling: 64 KiB.
- MCP encoded result ceiling: 512 KiB.
- Structured mutation bodies are intentionally small; use product data planes for object bytes and source transport.
Prevent multiplied work and spend
- Use stable idempotency keys for one logical request.
- Do not fan out builds, diagnostics, deployments, or provisioning to discover what works.
- Poll with bounded backoff instead of repeatedly resubmitting.
- Stop on capability unavailable, scope denied, stale version, uncertainty, or recovery required.
- Keep budget and usage warnings visible even when an agent proposes the work.