Errors & refusals/Violation fees & limits

Violation Handling Fees & Restrictions

A request the upstream judges to violate its usage policy puts the model account that served it at risk of a ban. Wokey charges a violation handling fee for such requests, and repeated violations restrict the model or the account.

On this pageexpand_more

Summarylink

  • Only requests the upstream explicitly rejects under its usage policy are charged, such as Claude refusals and content moderation rejections. Ordinary errors, timeouts, rate limits, and invalid parameters are never charged.
  • Each one costs a fixed violation handling fee with a base amount of $0.10. Any model usage the request already produced is billed as usual.
  • An occasional violation is only charged and does not affect your access. Repeated violations on one model within a short time limit or pause that model; several paused models pause model calls for the whole account.

When the fee applieslink

CaseResponse you receiveCounts toward limits
Claude model refusalHTTP 200 with stop_reason "refusal" (finish_reason "content_filter" in Chat Completions)Yes
Upstream content moderation rejection (Volcengine Ark, xAI, and others)HTTP 4xx with an error code such as InputTextSensitiveContentDetected or SensitiveContentDetectedYes
OpenAI cyber policy blockError code cyber_policyNo, fee only
Claude output blocked by content filteringHTTP 400, Output blocked by content filtering policyNo, fee only

How the fee is chargedlink

  • The base amount is $0.10 per request. Like model usage, it follows your account's price adjustment (markup or discount); your call records show the exact amount.
  • If the request produced input or output tokens before it was rejected, those are billed at the normal price, and the violation handling fee is charged on top.
  • Accounts with 30 or more violations on GPT models in the past 30 days pay twice the fee (base $0.20) on every model. The list updates daily, and the normal fee returns once the count drops.
  • In Call Records in the console these requests show as failed. Hover over the failure icon to see "A $x violation handling fee was charged", and expand the amount for the fee breakdown.

Restrictions after repeated violationslink

  1. 1

    A single violation

    Only the violation handling fee. Later requests are unaffected.

  2. 2

    Repeated violations on one model within a short time

    That model is temporarily rate limited: your account gets at most 1 concurrent request and 10 requests per minute on it, and anything beyond returns HTTP 429 rate_limit_exceeded. Other models are unaffected. The limit lifts automatically once violations stop, usually within 1–2 hours.

  3. 3

    More violations while rate limited

    That model is paused for 24 hours. Requests return HTTP 403 model_denylisted and you get an in-app notification. It resumes automatically after 24 hours; another violation restricts it again.

  4. 4

    Several models paused within 30 days

    All model calls on the account are paused. Requests return HTTP 403 account_restricted and you get an in-app notification. This does not lift automatically; contact support.

For serious violations or deliberate attempts to evade risk controls, the platform may ban the account outright under the Acceptable Use Policy.

Multi-user platforms: restrictions per end userlink

If one account or one API key serves many of your own end users, send the X-End-User-Id header on every request to say which end user it belongs to. When one end user keeps violating, Wokey restricts only that end user, your other users keep working, and an in-app notice tells you which one it was.

curl
curl https://api.wokey.ai/v1/messages \
  -H "x-api-key: YOUR_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "X-End-User-Id: u_3f8a2c1e9b7d" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-5-5",
    "max_tokens": 1024,
    "messages": [
      { "role": "user", "content": "Hello" }
    ]
  }'
  • The value is your own end-user ID: 1 to 128 visible ASCII characters (letters, digits and symbols; no spaces or non-ASCII characters). Use a UUID, an internal ID, or a hash of one, never an email address, phone number or other personal information. The value you already send as OpenAI safety_identifier or Anthropic metadata.user_id works as is. For signed-out users send a session ID or leave the header out; a fixed value such as anonymous or guest makes many people one end user, restricted together.
  • Chat Completions, Responses and Messages all accept it. The header is for Wokey only and is never forwarded upstream. With an SDK, add it for the whole client with default_headers (Python) or defaultHeaders (Node.js), or per request with extra_headers.
  • The rules match the previous section but apply to that end user alone: repeated violations by one end user on one model within a short time first rate limit it on that model (1 concurrent request, 10 requests per minute); continued violations pause that model for the end user for 24 hours, after which it returns automatically; several paused models within 30 days pause all model calls for the end user until support restores them.
  • Requests beyond an end user's rate limit, or from a paused end user, return HTTP 429 rate_limit_exceeded, never reach the upstream, and are not charged. When an end user is paused you get an in-app notice with the end-user ID, the model and when access returns; notices within an hour are merged into one.
  • The header never loosens the limits on your account: violations count toward your account with or without it, as described in the previous section. Requests from a paused end user no longer reach the upstream, so they stop counting toward your account. Requests that do trigger a violation are charged the violation handling fee as usual.
  • An invalid value (too long, containing spaces or non-ASCII characters, or the header sent twice in one request) is treated as if the header were absent: the request completes normally, and each API key gets one in-app reminder per day.

When no fee is chargedlink

  • API keys with Self-hosted enabled, whose requests use only your own hosted credentials.
  • Requests made with a purchase order's API key.
  • Requests rejected at the Wokey gateway before reaching the upstream, such as 401, 402, 403, and 429.
  • Ordinary failures: dropped connections, timeouts, upstream overload or rate limits, invalid parameters, and the like.

What to dolink

  • Do not resend a refused request unchanged. The same content will most likely be refused again and quickly trigger a rate limit. Change the request first.
  • Check whether automation scripts, batch jobs, or agents are looping on the same kind of rejected request.
  • If you serve your own users, filter content before sending it to Wokey, detect refusals as described in Detecting Model Refusals, limit end users who trigger them often, and send X-End-User-Id so Wokey can also restrict them one by one.
  • If you think a decision is wrong, or model calls on your account are paused, contact support with the request ID from your call records.
Detecting Model Refusalsarrow_forwardContact supportarrow_forward