Limits
What limits a run - sessions, memory, waits, steps, request rate and size of results.
These numbers may change
The numbers on this page are read from the code today. Plans, defaults and deployments can change them. The API reports your organization's own limits: GET /v1/tenant returns the quotas that apply to you and what you use now.
Sessions and memory
Each organization has a limit on open sessions and on browser memory. Each session reserves a fixed amount of memory. When a new session would go over a limit, the call fails with capacity_exceeded and a plain message. error.details.quota says which limit it was: concurrency or memory. Stop a session or wait for one to end, then try again. When the organization is within its quotas but every browser is busy, the same code comes back unless you ask to wait or queue: see Sessions.
| Plan | Open sessions | Browser memory for the organization | Memory per session |
|---|---|---|---|
free | 3 | 3 GB | 1 GB |
starter | 4 | 4 GB | 1 GB |
pro | 8 | 8 GB | 2 GB |
enterprise | 16 | 16 GB | 2 GB |
New organizations run with the free limits. An organization can have its own memory quota set by Lookover. Concurrency never goes above the plan.
capacity_exceeded is also what you get when:
- a monthly budget set for the organization is reached (
details.quotaisbudget). Raise the budget to continue. - an organization that has credit enforcement switched on has no credits left (
details.quotaiscredits). A running session finishes. New sessions are refused.
High demand and requesting more sessions
When demand on the platform is high, Lookover can switch on a throttle. An organization without an approved limit then runs 1 session at a time, whatever its plan says. You see it in three places:
- A banner in the dashboard: "Demand is high right now, so your organization can run 1 session at a time." It has a Request more sessions button.
- A
capacity_exceedederror witherror.details.quota: "concurrency",error.details.throttled: trueanderror.details.requestUrl, the dashboard page where you ask for more. The dashboard shows this message with a pointer to the Billing page. GET /v1/tenant: thecapacityobject hasplanLimit,approvedLimit(nullwhen none),effectiveLimit(what applies now),throttledandopenRequest(idandstatusof your waiting request, if any).
An organization with an approved limit is not throttled. A session that would go over the limit fails at once with capacity_exceeded. It is not queued: stop a session you no longer need, or request more sessions.
Request more sessions
Request more from the dashboard, under Billing, with Request more sessions (also reached from the banner). An organization admin sends the request. Any member can see its status. The form asks:
- Sessions at once: how many browser sessions you want to run at the same time.
- What you build: one line.
- Optional: sessions per day, when you need it, and whether you would pay for dedicated capacity.
The same request is POST /v1/capacity-requests (admin role). GET /v1/capacity-requests lists your requests, newest first.
What happens next:
| Status | Meaning |
|---|---|
pending | Waiting for review. Shown as "Pending review" on the Billing page. A second request while one is pending is refused with conflict |
approved | Lookover set a new limit. approvedLimit holds it, and the Billing page reads "Approved: N sessions at once" |
declined | Not approved. decisionNote holds the reason, shown on the Billing page |
cancelled | The request was cancelled |
A Lookover admin reviews each request. There is no email yet: the answer shows on the Billing page.
Session time
| Limit | Default | Range |
|---|---|---|
| Idle time before the session closes | 5 minutes | 10 seconds to 24 hours |
| Maximum age | 1 hour | 10 seconds to 24 hours |
Set them with idleTimeoutMs and maxDurationMs on create_session.
Waits in MCP
One MCP call returns one reply. A proxy in front of the API closes a reply that sends nothing for 100 seconds, so a call never waits longer than 90 seconds for a task.
| Tool | Default wait | Maximum |
|---|---|---|
run_task | 90 seconds | 90 seconds |
get_task | 30 seconds | 90 seconds |
smoke_test | 60 seconds | 90 seconds |
get_report | 30 seconds | 90 seconds |
skill_<name> | 30 seconds | 120 seconds |
get_skill_run | 0 (does not wait) | 120 seconds |
A job that is still going when the wait ends keeps running. That is not an error. The reply says running. Read the result with get_report, get_task or get_skill_run. For get_task, a larger waitSeconds is lowered to the maximum. For run_task, smoke_test and get_report, a value above the maximum is refused with invalid_input.
Tasks
| Limit | Value |
|---|---|
| Goal length | 2000 characters |
maxSteps | 1 to 50. Default 25 |
| A question that gets no answer | The task stops after 10 minutes with unanswered |
| Cost per task | A cost cap stops the task with budget and limit: "maxCostUsd" |
Quick actions
| Action | Limit |
|---|---|
scrape, screenshot, pdf | timeoutMs 1 to 120 seconds. Default 30 seconds |
crawl | maxPages up to 100 (default 25). maxDepth up to 5 (default 2). maxMs up to 600 seconds (default 300) |
Request rate
Each API key may send 600 requests per minute. REST and MCP share the count. Over the limit, the API answers 429 with rate_limited and a Retry-After header.
Size of results
Tool results are cut to fit an agent's context. A string longer than 2000 characters is cut with a note. A skill result keeps the last 50 log lines. When it is larger than 100 000 bytes, each step is reduced to one line. Screenshots and video are never inline. See Tools.
Where targets are limited
Every navigation passes the guard. Private, loopback, link-local and cloud-metadata addresses are blocked. See Test a local app.