Limits and quotas

Most surprising R1-MCP behaviour is a limit doing its job. This page collects them, with what each one does when you reach it.

Timeouts

Limit	Value	On reaching it
code_mode run budget	30 seconds wall clock, shared across every API call the program makes	The run is cut off. At 20 seconds the budget snapshot on each response gains a warning — the program is expected to return partial results and continue in a fresh run
One call_r1 request	15 seconds	Surfaces as a structural error envelope; the measured time is still billed to the run budget
RUCKUS token mint	15 seconds	timeout — the R1 token endpoint didn’t respond
One Data Studio request	20 seconds	statusText: "timeout" on the ds_* response
await_request poll loop	60 seconds by default, settable 1–120; polls every 2 seconds by default (0.5–10)	Reports the last activity state it saw rather than failing outright. A wait longer than about 25 seconds is cut off by the 30-second run budget first
Write Guard confirmation	10 minutes from the preview	Confirming a stale preview returns a fresh preview instead of executing

Note

The run budget is per code_mode call, not per conversation. Every new call gets a fresh 30 seconds, which is exactly why the right response to a warning is to split the work rather than retry it. See How code mode works.

A 404 while awaiting is not a failure

await_request polls an asynchronous R1 operation to completion. R1 returns 404 for an activity it has accepted but not yet made resolvable, so a 404 is treated as not yet, not as failure — the loop keeps polling until its own timeout bounds the wait. Once any poll has returned a real activity body, a subsequent timeout is a genuine one.

Retries

call_r1 never throws on an HTTP error; it returns a response you can inspect. What it retries automatically:

Status	Behaviour
401	Exactly one refresh-and-retry
429	Auto-retried for GET, PUT, DELETE only — at most 2 retries, honouring Retry-After, with the wait capped at 5 seconds. POST and PATCH are not replayed unless you pass retryOn429: true
406	Retried once with the versioned media type R1 named. If the 406 names none, it surfaces as-is
415	A body-less request is retried once with the Content-Type R1 named

call_r1_gql requests are POSTs, so they are never auto-retried on a 429 unless you opt in — and opting in is only safe for reads, since Service Validation has real mutations.

Every response carries retried, so the retry count is always visible.

Stored artifacts

Everything R1-MCP stores for you is bounded, per user.

Artifact	Cap	Retention	At the cap
Snapshots (venue_extract, element_extract, and the working snapshot backup_create takes from a venueId — one shared cap)	20	30 days	Refuses — snapshot_limit_reached
Backups (backup_create)	50	Indefinite	Refuses — backup_limit_reached, checked before anything is extracted, and nothing frees itself
MOPs / test plans you author	50	Untouched drafts age out after 30 days	Refuses — mop_limit_reached
Copy MOPs the engine compiles	100	30 days	Evicts the oldest — except a copy MOP that still has a run on record, which is kept
Test beds	50 (100 devices each)	365 days untouched	Refuses — testbed_limit_reached; a save with more than 100 devices fails as too many devices
Endpoint notes (save_endpoint_note)	10 per endpoint, 500 in total; 5–500 characters each	Kept	Refuses — too_many_notes_for_endpoint / too_many_notes
Data Studio notes (ds_save_note)	10 per topic; 5–4,000 characters each	Kept	Refuses — too_many_notes_for_topic

Caution

Compiled copy MOPs are the one artifact that evicts rather than refuses. Refusing would block the copy workflow itself over rows you never asked to keep — but it does mean a compiled plan you care about should be mop_exported rather than left in the store. A copy MOP with a run on record is skipped by both the eviction and the 30-day sweep, so venue_copy_undo can still find what it created; once its runs age out (7 days, below) it becomes evictable, so the count can sit above 100 until then.

Sizes

Limit	Value	On exceeding it
Snapshot config	5 MB	snapshot_too_large — restrict domains and re-extract
Backup config	5 MB	backup_too_large — back up fewer domains separately
MOP steps	200, or 400 for an API-only MOP	The plan is rejected as plan_invalid; split it by domains
Runs kept per MOP	20	Oldest dropped
config_diff output	400 lines, with no paging	The diff is cut off and the response is marked truncated
Run retention	7 days for a MOP, 90 days for a test plan	Swept. A copy run’s runId stops working for venue_copy_undo and for element_copy_verify after 7 days — they answer run_not_found

A compiled copy plan gets the raised 400-step cap because it is API-only. An over-cap plan is the signal to plan each subset of domains into its own MOP.

Batches and pages

Limit	Value
device_cli commands per batch	20, run sequentially in the held session
search_endpoints results	20 by default, 50 maximum
list_endpoints_by_tag results	50 by default, 200 maximum
search_docs, and the ICX, ICX hardware, and Edge doc searches	10 by default, 20 maximum
Requests in one MCP JSON-RPC batch	20 — more is refused as batch_too_large
Autopilot wall clock	maxWallMin — 30 minutes by default, 120 maximum
Autopilot runs	One at a time, per user

A long configuration job is applied as several batches of twenty into the same held session, not as one giant push. Autopilot expiry pauses a run; it never fails it.

Device CLI

Limit	Value
Output per device_cli batch	256 KB by default
Session transcript	4 MB
Held session	Closed after 4 minutes idle, and after 13 minutes in all — reopen it to continue
Cached device login token	At most 15 minutes, so a connection you edit, disable, or delete stops opening consoles quickly

Topology and reconcile

Limit	Value
diagram_topology graph	2,000 nodes, 4,000 edges
diagram_topology L1 AP LLDP lookups	60 APs
diagram_topology L3 static-route reads	60 switches
probe_reconcile inventory	5,000 cloud devices
probe_reconcile rogue rows returned	25 by default, 200 maximum (totals are always included)

Data Studio

Limit	Value
One Data Studio request	20 seconds (see Timeouts)
ds_diagnose_charts sweep	15 charts by default, 60 maximum
ds_list_charts / ds_list_dashboards rows	100 by default, 500 maximum

RUCKUS also enforces its own guardrails on every Data Studio chart and dashboard — these are platform limits, not R1-MCP ones:

Guardrail	Value
Dimensions per chart	6 (3–4 performs best); more fails as DATASTUDIO-20010
Time range	31 days. A longer relative range is capped to 31 days; a longer custom range is rejected
Unpaginated table	500 rows, whatever row_limit says — turn on server pagination for more
Charts per dashboard	40 across all tabs (20 recommended)

Images and floorplans

Any tool that returns a picture — today, floorplan_map — sends it as an image block Claude can see, within these caps. An image over a cap is refused, not trimmed, with a note to ask for the map link instead.

Limit	Value	On exceeding it
Image blocks per response	4	too_many_images
One image block	1.5 MB	image_too_large
All image blocks in one response	4 MB	total_image_budget_exceeded
Floorplan map image	800,000 pixels, ≤ 900 KB encoded; widths 1000, 760, 560, then 400 px are tried in turn	Rendered again at the next smaller width
Inline SVG map	60 KB	Refused rather than trimmed — use the map link
ASCII floor grid	160 × 80 characters	—
Source floorplan image from R1	20 MB	image_too_large
PNG decode	30 megapixels	image_too_large
Mirrored floorplan images	50 per user per connection	The oldest are evicted
Cached image metadata	30 days	Re-read
Client snapshot cache	15 minutes	Re-queried from R1
Roam arrows / co-channel pairs drawn	80 / 40, busiest first	The rest are counted, not drawn
Client roster rows	1,500	—
Floor Map launch link	15 minutes, one venue, read-only; it cannot renew itself	Mint a new one

VLAN probe runs

The VLAN probe puts a real SSID on the air, so its limits are about getting it off again.

Limit	Value
Rows (VLANs) per run	15
Run deadline	Three times the estimate, never under 15 or over 60 minutes — at the deadline the run is torn down
Waiting for the Service Validation test to appear	3 minutes
Test polling per row	Every 15 seconds, 24 times (about 6 minutes)
Confirmation after preflight	10 minutes
Progress stream	Re-opened every 10 minutes (a bye frame tells the client to reconnect)
Cleanup request	Up to 50 named ids
Run record	30 days, and kept longer while anything it created is not yet deleted

Webhook event retention

The webhooks feature stores what it receives, per user, with retention that varies by event class. This is why a month-old client event is gone while a month-old incident is not.

Event class	Kept	Row cap
Client stream (event), including admin login events	7 days	20,000
AP infrastructure (ap_event)	30 days	5,000
RADIUS / auth (radius)	30 days	4,000
Activity — “what changed before the outage”	90 days	2,000
Admin audit (admin actions other than logins)	90 days	2,000
Incidents	365 days	1,000
Test / unknown	7 days	400
Any other type	30 days	4,000

Purging happens on insert, scoped to the class that just arrived — and an hourly sweep also enforces the time windows for every user — and each class purges against its own budget. The high-volume client stream therefore cannot evict a rare incident or admin-audit row to make room for itself. Admin login events are the exception: they ride the client stream, so they share its 7-day window and 20,000-row budget.

Anything you ask about outside these windows isn’t missing data; it is data that was never retained. Derived stores have their own windows: the client registry keeps 180 days (up to 100,000 devices), roam pairs 90 days (up to 40,000 pairs), event counters 120 days (up to 20,000 counters).

The webhook receiver accepts a payload of up to 64 KB; a larger one is answered 413 payload_too_large.

Watches

Limit	Value
Watch expiry	24 hours by default, set in whole hours
Maximum	168 hours (7 days)
Active watches	100 per user — more is refused as watch_limit_reached
Watch notices	1,000 per user; delivered ones kept 7 days, undelivered 30 days
Live Console watch started from the page	2 hours by default, 24 hours maximum

Expiry is mandatory — there is no permanent watch.

Sign-in and access

Limit	Value	On reaching it
Claude connector access token	1 day	Claude refreshes it automatically
Claude connector refresh token	90 days, renewed each time it is used	Reconnect the connector if it sits unused that long
Dashboard sign-in session	30 days	Sign in again
Early Access password attempts	10 per 15 minutes	429 too_many_attempts — wait and retry
Connector registrations	5 per minute	Retry shortly

Feature gates are a kind of limit too

A tool you cannot see is not a broken tool. R1-MCP exposes a single MCP tool — code_mode — and inside it the r1 object carries 13 always-on tools. Everything else appears only when its feature is enabled. get_reference itself appears only once you have at least one feature on.

After enabling a feature, reconnect the connector in Claude so it picks up the new tool list.

Next steps

How code mode works The run budget in context — why broad requests come back in stages.

Features and feature flags Which tools each feature adds, and what is Early Access.

Troubleshooting Errors you may hit, and which limit each one comes from.