Limits and data

These are the Private Beta default limits. Values may change during the Beta, and raising limits is not supported in the Beta. You can only lower them. Check openapi.json and rate_limits in the Deployment detail for current values.

Call rates

Class	Limit	Requests it covers
Accept	10 per minute	Creating a Session, Turn, or Run, and POST /v1/files
Read	60 per minute	Every other request (reads, cancel, close, delete, and download included)

• The limits apply separately per key, Project, and Deployment, and the lowest one hits first. You can set lower limits on a key or a Deployment.
• When exceeded you get 429 RATE_LIMITED with Retry-After (seconds) and details.reset_at.
• Poll at 2 to 5 second intervals, and use SSE or webhooks where you can.

Concurrent executions

• A Project runs 2 executions at a time. Executions already accepted wait within the limit, and an acceptance that goes over the limit returns 429 CONCURRENCY_LIMIT.
• A Session runs only one Turn at a time. (Sessions and Turns)

SU budgets

Scope	Default limit
One Turn	100 SU
One Run (child Turns summed)	100 SU
Project per day	1,000 SU
Project per month	30,000 SU

• You can set a lower cap for one Turn or Run with limits.max_su in the request. Above 100 returns 422 LIMIT_OUT_OF_RANGE.
• The Project daily and monthly limits are counted in UTC windows. Going over returns 402 PROJECT_BUDGET_EXCEEDED.
• Model, search, execution environment, and file storage and transfer costs are all summed. Retries and sub-task costs are added only once each.
• Cost is reserved before a call and settled afterward. Before settlement usage.status is PENDING.
• File upload and download can start when the account balance is at least 50 SU. 50 SU is not charged as a fixed fee. Only actual usage is consumed.

Input and output sizes

Item	Limit
JSON request body	64KiB
metadata	16 keys, key 1 to 64 characters, string value 512 characters
Idempotency-Key	1 to 256 bytes
TEXT result	64KiB. Larger is delivered as a file
JSON result	Inline up to 64KiB and 100 array elements in total. Larger is delivered as a file. Overall 10MiB, 10,000 array elements, depth 16
Input files	20MiB each, 20 per input
File types	.txt, .md, .markdown, .csv, .json, .pdf, .png, .jpg, .jpeg, .webp, .docx, .xlsx, .pptx. The extension and MIME type must match. A Deployment can narrow the accepted types further.
Result files	10MiB each, 10 per execution
Files of one execution in total	100MiB
Project file storage	500MiB (the organization’s remaining storage also applies)
List responses	At most 100 items and 256KiB. Default 50
Webhook body	4KiB
Download URL lifetime	At most 60 seconds
Result file preparation	At most 300 seconds after the execution ends

A value over a limit is rejected with an error, never silently truncated.

Retention

Target	Period
Idempotency receipt	At least 24 hours, and kept until the Turn ends. The exact time is in idempotency_expires_at.
Session	30 days idle (Beta default). Deleting a Session also deletes its Events, Items, and files.
Files uploaded to the Project ahead (POST /v1/files)	24 hours after upload. They expire unless used as Turn or Run input within that time.
Session files	30 days from upload or creation. A file uploaded ahead and used as Turn input gets 30 days from that point. Using the Session does not extend it, so a file can expire before its Session.
Run files	Until the Run deadline and the end of the Run content retention. A file uploaded ahead and used as Run input follows this period.
Event and Item content	At most 30 days
Run content	30 days after the Run ends by default. You can shorten it with retention_days (1 to 30) in the request.
Webhook dedup IDs	At most 30 days (the replay horizon)

Reading does not extend retention. Expired content is hidden at read time, so it is not visible even if the cleanup job is late. After expiry you get 410 (SESSION_EXPIRED, EVENT_CURSOR_EXPIRED, FILE_EXPIRED, and so on). The exact expiry time of a file is in expires_at of the file response. Move results you need into your own storage before they expire.

Deletion

• DELETE /v1/sessions/{session_id} and DELETE /v1/runs/{run_id} are acceptances of a delete (202). As soon as you get the response, the content read paths are blocked and a running execution is canceled.
• Physical reclamation of stored inputs, outputs, files, and conversation records proceeds asynchronously afterward. In the Private Beta the completion time is not guaranteed.
• Resending a delete with the same Idempotency-Key returns only a delete receipt with no content.
• The minimum identifiers needed for billing and security audit (IDs, times, amounts, reasons) are kept separately, without content.
• Requesting a delete does not undo external effects that already happened.

Security and data boundaries

• Isolation: Execution is separated by Project, Deployment, and Session. The memory, files, and search index of one Session are not copied into another Session or the original employee.
• Frozen publication: A Deployment freezes the instructions, skills, tools, and model tier at publication. Editing the original employee has no effect, and a new version takes effect only when you publish again.
• The caller is not the owner. An execution called through the API does not use the organization owner’s personal memory (owner memory), stored secrets (vault), or logged-in browser. Key scopes alone never widen this.
• Risky tools blocked: A tool that is not allowed cannot be called (CAPABILITY_DENIED), and arbitrary risky tools are blocked by default. Publication is rejected if the content contains secret values.
• Sanitized public responses: Events and results do not include internal reasoning, raw tool arguments and results, or owner information. Contact details and credential patterns in free text are masked. This is not a device that identifies arbitrary private information, so do not put unnecessary personal data in inputs.
• Webhooks: They send neither raw results nor file addresses, and they never send to internal network addresses.
• Key storage: Keep keys and webhook secrets only in your servers’ secret store.