Rate-limit tiers

⚠️

Preview — this feature is being built; the design below is the spec.

Rate limits decide how fast you can send work: how many requests, and how many tokens, per minute. Under the tier system, limits grow automatically as your organization builds a payment history with Syntic, and are set per model so a heavy job on one model does not starve another.

Today every API key has one flat cap of 600 requests a minute, with no token-based limit, as described on Limits. The tiers below replace that once they ship. Plan windows, spend limits and the credit balance are separate controls and do not change.

Three limits per model

For each model, three buckets are checked on every request. Running out of any one returns 429.

Limit	Abbreviation	Counts
Requests per minute	RPM	Every request to a model endpoint.
Input tokens per minute	ITPM	Prompt tokens, including images and documents. Cached prompt tokens are not counted, so well-cached prompts get far more throughput.
Output tokens per minute	OTPM	Generated tokens, including reasoning tokens. Reserved from `max_tokens` when the request starts, then corrected to the real count.

Buckets refill continuously. A limit of 1,000 RPM means roughly one more request becomes available every 60 ms, not 1,000 at the top of each minute. Short bursts above the average are fine as long as the bucket has room.

Tiers

Your organization moves up a tier automatically once it has paid the cumulative amount shown and the waiting period has passed since its first payment. Plan subscriptions and credit purchases both count.

Tier	Paid to date	Waiting period	Max single credit purchase
Start	$0 (free plan)
1	$5		$100
2	$50	7 days	$500
3	$250	7 days	$1,000
4	$1,000	14 days	$5,000
Custom	By agreement		By agreement

Tiers never go down because spending drops. They can be lowered after a chargeback or an abuse finding.

Limits by tier

Per organization, per model. Workspaces share the organization’s limits unless an administrator sets workspace limits.

Model	Tier	RPM	ITPM	OTPM
`Amara S1.2`	Start	50	30,000	8,000
	1	600	200,000	40,000
	2	1,000	400,000	80,000
	3	2,000	1,000,000	160,000
	4	4,000	2,400,000	400,000
`Amara Quick`	Start	50	50,000	10,000
	1	600	400,000	80,000
	2	1,500	800,000	160,000
	3	3,000	2,000,000	320,000
	4	6,000	4,500,000	800,000
`Amara Deep`	Start	20	20,000	8,000
	1	300	150,000	30,000
	2	600	300,000	60,000
	3	1,200	600,000	120,000
	4	2,500	1,200,000	300,000

Tier 1 keeps the 600 requests per minute everyone has today, so no existing customer gets a lower request limit when tiers launch.

Other endpoints

Endpoint group	Limit
Token counting	2,000 RPM per organization, separate from model limits
Files, batches, models list	1,000 RPM per organization
Agents API (definitions, sessions, executions and related)	600 reads and 60 writes per minute per workspace
Admin API	300 RPM per organization
Batches	Queued requests do not count against RPM, ITPM or OTPM; see Batches

Workspace limits

Administrators can cap any workspace below the organization’s limits, for example to stop a test workspace from using production’s throughput. Workspace limits are set per model, in the Console under Settings → Limits or with the Admin API (rate-limit info). A workspace limit can never be higher than the organization’s.

See your limits

Console: Settings → Limits shows the current tier, the next tier’s requirements and each model’s limits.
On a 429: the rate-limit headers give the cap and the wait. Successful responses carry none.
Admin API: GET /v1/organizations/rate_limits lists everything for scripts and dashboards.

curl -sS https://app.syntic.ai/v1/organizations/rate_limits \
  -H "Authorization: Bearer $SYNTIC_ADMIN_KEY" \
  -H "syntic-beta: admin-2026-11-01"

const res = await fetch('https://app.syntic.ai/v1/organizations/rate_limits', {
  headers: { Authorization: `Bearer ${process.env.SYNTIC_ADMIN_KEY}`, 'syntic-beta': 'admin-2026-11-01' },
})
const { tier, data } = await res.json()
console.log(tier, data.map((m) => `${m.model}: ${m.requests_per_minute} RPM`))

import os, requests
 
r = requests.get(
    "https://app.syntic.ai/v1/organizations/rate_limits",
    headers={"Authorization": f"Bearer {os.environ['SYNTIC_ADMIN_KEY']}", "syntic-beta": "admin-2026-11-01"},
)
body = r.json()
print(body["tier"])
for m in body["data"]:
    print(m["model"], m["requests_per_minute"], m["input_tokens_per_minute"], m["output_tokens_per_minute"])

Getting more throughput

Cache prompts. Cached input tokens are not counted against ITPM. See Prompt caching.
Set max_tokens close to what you need. OTPM is reserved from it at the start of each request.
Use Batches for jobs where an answer within 24 hours is fine: it runs outside your per-minute limits.
Spread across models where a lighter model is good enough; each model has its own buckets.
Ask for a custom tier from the Console’s Settings → Limits page if you have a known launch or steady high volume.

Errors

Status	`type`	`code`	`details.limit`
429	`rate_limit`	`rate_limited`	`requests`, `input_tokens` or `output_tokens`
429	`rate_limit`	`workspace_rate_limited`	Same, when a workspace limit (not the organization’s) ran out

Build notes for the platform team

Token buckets keyed by organization + model (and workspace + model where overridden) in the shared store; the existing per-key request counter becomes the RPM bucket.
Tier is computed nightly from paid totals and stored on the organization; a manual override column supports custom tiers.
Fall back to a local per-instance limiter when the shared store is unreachable, as the request limiter does today.

Rate-limit headers
Limits: plan windows, spend limits and request size
Pricing
Handle usage limits

Limits Deprecations

Was this page helpful?