Rate limits

Sentisec limits how much traffic a workspace sends per minute. The limits come from your plan, so there is nothing to configure. When a request goes over a limit, Sentisec refuses it the way your provider would, so your SDK waits and retries without any code from you.

The limits

• Requests are counted per API key and for the whole workspace. Both counts use the number above. Every request that carries a workspace key counts.
• Tokens are counted for the whole workspace, on model calls: Messages, Chat Completions, Responses, Embeddings and Bedrock Converse.
• The window is one minute, and fixed. It starts with the first request and resets 60 seconds later. It does not slide.

On a self-managed install, your operator can set different limits for each plan. Need more than your plan allows? Get in touch.

How a request is counted

Nobody knows how many tokens a call uses until the provider answers. So Sentisec holds an estimate before the call and settles it afterwards.

For example, an agent call with a 7.7 KB body and max_tokens: 64000 holds about 6,000 tokens while it runs, then settles at what it actually used.

When a limit is reached

The request is refused with HTTP 429. Your provider is not called.

The body, by API:

Sentisec's other endpoints answer {"error": "request_limit_exceeded"} with the same headers.

Your SDK retries on its own

The Anthropic and OpenAI SDKs raise their own rate-limit error for this 429 and retry it after Retry-After. The AWS SDKs retry a ThrottlingException, and the Vercel AI SDK retries a 429. You need no retry code of your own. If you write some anyway, wait for Retry-After: retrying sooner is refused again.

A request larger than the whole budget

A request whose estimate is larger than your plan's tokens per minute can never fit, so waiting does not help. It gets the same 429 with token_budget_exceeded, and the message says that this request alone needs more than the workspace's tokens per minute. Your SDK may retry it a few times before it gives up. Send a smaller request instead: less conversation history, smaller attachments, or a max_tokens below 4,096. Or move to a larger plan.

503: the limits could not be checked

A 503 with X-Sentisec-Limit: limits_unavailable means Sentisec could not check the workspace's limits at that moment, on a deployment set to refuse traffic it cannot check. It says nothing about your usage. The body is your provider's error for an unavailable service, and Retry-After is 1. Retry shortly.

Repeated failed authentication

After 10 rejected credentials from one address within a minute, further requests from that address get a 429 with X-Sentisec-Limit: auth_backoff and Retry-After: 60, whatever key they carry. Fix the key rather than retrying. A correctly keyed client never meets this.

See how often it happens

Sentisec counts each refused request for the workspace. Read the count, with the current minute's usage and your plan's limits, here:

Any workspace member can read it, with the session token from Sentisec sign-in. An abridged response:

{
  "tier": "free",
  "limits": {
    "window_seconds": 60,
    "caps": { "key_rpm": 60, "workspace_rpm": 60, "tokens_per_minute": 100000 },
    "workspace_requests": 12,
    "tokens_used": 31840,
    "tokens_reserved": 6037,
    "refusals": {
      "window_seconds": 86400,
      "request_limit_exceeded": 0,
      "token_budget_exceeded": 3
    },
    "available": true
  }
}

• refusals counts the refused requests in a one-day window, which starts with the first refusal.
• tokens_reserved is what calls still in flight hold.
• available: false means the counts could not be read at that moment. It never means zero.

Related

• Errors and limits — every error Sentisec raises itself
• Audit and metrics — the other metrics endpoints
• Workspace controls — what a workspace lets you configure