Skip to main content

Fair use & automation

Slothbox is built so that everyday work just runs, without you ever thinking about quotas. This page is the friendly explainer of the one rule that shapes the plans: seats are for people; the API plan is for unattended automation. It's the policy the API points you to when it returns a 429 or turns down a box, and the one the web app points to when it prompts you to upgrade.

info

This page is the plain-English explainer. The binding version is the fair-use and automation clause in the Terms of Service, which is the enforceable term and governs in case of any difference. This page describes the same policy in friendlier language.

What your seats cover​

Your subscription includes one or more seats. A seat grants a named person interactive access to Slothbox — the web app, the command-line interface (CLI), and the Model Context Protocol (MCP) integration — driven by a human who is signed in. Alongside that, every seat comes with a personal, low-throughput API key for light, occasional scripting by that person.

That's the everyday picture: a person at the keyboard, a handful of boxes, and a small script on the side. Seats are sized exactly for that, and you'll never have to think about limits to do it.

What needs the API plan​

Unattended and programmatic automation at scale belongs on the API plan. That means continuous-integration (CI) pipelines, autonomous agents, backend services, and headless scripts that run with no person present — the kind of workload that fans out boxes and calls the API in volume on its own. The API plan provides organisation-level service-account keys built for exactly this: long-lived credentials that belong to the organisation rather than to any one individual.

Where the line is​

The dividing line isn't whether you call the API — seats call it too, through the CLI and MCP. The line is who holds the credential:

  • A seat credential (an interactive sign-in session, or that seat's personal low-throughput key) is for a person doing hands-on work.
  • An organisation service-account key is for automation that runs on its own.

Both can reach the same Slothbox API; what differs is who's behind the call. So the question to ask is never "am I calling the API?" but "is a person driving this, or is it running unattended at scale?"

How we keep interactive access fair​

To keep interactive access fair for everyone and to protect the platform, Slothbox applies two guardrails to its interactive surfaces (the web app, CLI, and MCP, plus the personal seat key):

  • Human-paced rate limits — generous headroom sized for a person working hands-on, comfortably above what interactive use ever needs.
  • A per-seat ceiling on concurrently active boxes — because a person works with a small, bounded set of live boxes at once. It caps only how many run at the same time, not how many you create over time.

Both of these are raised or removed for organisations on the API plan, which is where scaled automation belongs. The concrete per-caller numbers, the 429 response, and the Retry-After header live on Rate limiting; the box ceiling and its response are on Errors.

We reserve the right to throttle, suspend, or deny access, or to require an organisation to adopt the API plan, where usage exceeds these limits or is designed to circumvent the seat/API boundary — for example, by driving automated or high-volume workloads through interactive seat credentials rather than through service-account keys on the API plan.

Flat-rate, no usage billing​

Both the seat plan and the API plan are flat-rate. We don't charge for usage under these plans, and there's nothing to true up: usage may be measured for capacity planning and to inform future plans, but it isn't billed. Moving a workload onto the API plan is about getting it onto the supported tier with the headroom it needs — not about a meter.

Where to go next​

  • API plan — what the plan unlocks, and how an owner turns it on.
  • Rate limits & fair use — the same boundary, framed around the limits you might bump into.
  • Authentication — the credential model: seat keys versus organisation service-account keys.