Skip to content

Limits

In short

  • Turn and wall-clock caps bound one attempt of one run. A resume or retry starts with a fresh budget.
  • Defaults: 80 turns and 24 hours per attempt, at most 5 steps per batch. A skill or a profile can set its own.
  • Waiting on a job or an open question costs no turns.
  • The tables below list every cap on messages, uploads, transcripts and packs.

Per attempt

Caps bound one attempt of one run, not a session's lifetime. A resume or retry starts a new attempt with a fresh count and clock, which is why raising a cap and retrying a capped run takes effect.

Cap Default Set by (most specific wins) When it is hit
Turns 80 skill parleml-max-turns → profile agent.max_turns → PARLEML_AGENTS_MAX_TURNS The attempt fails with runtime_limit ("turn cap of N exceeded").
Wall clock 86,400 s (24 h) profile agent.wall_clock_seconds → PARLEML_AGENTS_WALL_CLOCK_SECONDS The process is killed; runtime_limit ("wall-clock cap of Ns exceeded"). The attempt's ParleML token expires at the same moment.
Steps per run_skills batch 5 profile agent.max_concurrent_children → PARLEML_AGENTS_MAX_CONCURRENT_CHILDREN The call is refused; the orchestrator splits the batch.
Nesting 1 fixed Only the orchestrator starts steps.

The runtime counts turns itself from each CLI's stream (the CLIs' own turn flags are not used): a Claude Code message counts once however many frames it streams, and each Codex item, Gemini response or Cursor model step counts as one. A turn that only calls await_operation on a job or on the run's own deferred operation is free, so a three-hour training wait or a day-long open question costs nothing. A capped step still returns a summary of what it finished (up to 4,000 characters), and its files stay in the work directory.

The shipped skills set their own turns, from 40 (ml-release) to 300 (ml-delivery); see Skill attributes.

Waiting

Limit Value
A held ask_gate or await_operation on a deferred operation (Claude Code, Codex, Gemini CLI) PARLEML_AGENTS_MCP_TOOL_TIMEOUT_MS, 24 h
A held await_operation on server work (job:, eda:, probe:, autodoc:, call:) PARLEML_AGENTS_AWAITABLE_MAX_HOLD_SECONDS, 15 min; then pending with the wait so far and how to stop the work
Server work that makes no progress (no CPU, stack still) PARLEML_JOBS_STALL_AFTER_S, 15 min; then failed as stalled
One Cursor await_operation slice PARLEML_AGENTS_CURSOR_DEFERRED_WAIT_SECONDS, 50 s
MCP progress during a held wait every 30 s
Auto-resume sweep every 30 s; resumes 30 s after the stated reset

What people send

Item Limit
A start request or a step's instructions 100,000 characters
Ask or describe the work routing text 20,000 characters
A resume or follow-up message 20,000 characters
A queued message 4,000 characters; at most 20 waiting at once
A file attached to a session (start or question) PARLEML_AGENTS_MAX_UPLOAD_BYTES, 25 MiB, checked before anything is written; names cut to 120 characters
Files attached to one start PARLEML_AGENTS_MAX_UPLOAD_FILES, 20
A gate 20 questions; a prompt up to 4,000 characters; a text answer up to 4,000
An outcome explanation 20,000 characters (truncated, not refused)
Sessions deleted in one request 100

What the page reads

Item Limit
One transcript page (GET …/transcript) limit_bytes, 256 KiB by default, at most 1 MiB; page with after
Live updates buffered per browser tab PARLEML_AGENTS_SSE_QUEUE_SIZE, 1,000 frames; an overflow drops transcript frames (the file keeps them) and closes the stream on lifecycle events, which the page then reloads
Files tab the newest 1,000 files; the reader shows the first 1 MiB of a text file
A published document 5 MiB
A session list page 25 by default, at most 100

Packs and imports

Item Limit
A pack import upload 20 MiB; 100 MiB expanded; 2,000 files; 20 MiB per file; paths up to 240 characters
Host rules and hooks across a profile's packs 2,000 files, 100 MiB, 20 MiB per file
A template chain 16 KiB, 256 phases
Import previews kept 20 minutes

Process shape

The runtime runs inside the one backend process that owns the platform directory: host processes, open questions and live updates are local to it, and a second process on the same directory refuses to start. Run the backend with one worker. Live updates are server-sent events, so a reverse proxy in front of it may need a longer idle timeout.

Next