The dashboard's System area shows what Crew is doing to the machine, how much work the host can admit, and what sessions consume on disk.
The Tasks view lists active sessions, subagents, scheduled work, Task Runner steps, and workflow calls with their current state and resource use. Use it to find a session holding memory, distinguish queued work from running work, or confirm that the host is idle before a heavy step.
Accepted background work is recorded in the durable task queue. Queued subagents, Task Runner steps, and workflow calls survive a Gateway restart and return to scheduling when the host can admit them.
The Services tab reports Gateway components and the capacity currently in force. The subagent limit shown here reflects available host memory and CPU — it can be lower than the configured maximum when headroom is tight. The resource_status tool exposes the same operational view to an agent so it can choose a narrower path before starting a large fan-out or build.
Crew applies one aggregate ceiling across concurrent agents. When memory becomes critically low, scheduled work defers and new work remains queued or is refused according to the caller's contract, rather than pushing the host into sustained memory pressure. The header shows the current posture.
The resource_limits block in config.json sets the kernel ceilings for the processes agents spawn. Every key is optional. Unset keys use the built-in defaults described below.
| Key | Applies to | Behavior |
|---|---|---|
max_total_memory_mb | every agent together (Linux) | Memory ceiling for the whole agents slice, independent of the per-agent ceiling. Unset sizes it from the host. Not enforced on Windows or macOS. |
max_total_processes | every agent together (Linux) | Task (thread) ceiling for the whole agents slice. Unset sizes it from the host, 512 tasks for every 512 MB of the slice's memory ceiling, so load reaches max_total_memory_mb first. kirocrew doctor shows the value and its inputs. |
max_memory_mb | each agent runtime | Resident memory ceiling for one agent tree (the cgroup MemoryMax on Linux, the Job object limit on Windows). Unset sizes it from the host. Since 0.12.1 it caps resident memory only and sets no address-space limit, so Node and GraalVM tools start normally under it. |
max_address_space_mb | each spawned process | Virtual address-space cap (RLIMIT_AS), opt-in. Unset or 0 leaves the inherited limit. Node and GraalVM binaries reserve far more address space than they use and can fail to start below about 64 GiB, so prefer max_memory_mb for memory pressure. |
scope_memory_high_pct | each agent runtime (Linux) | Soft ceiling as a percent of that runtime's own max_memory_mb. Past it the runtime is throttled alone before the shared slice ceiling slows every agent. Default 90; 0 turns it off. |
max_open_files | each spawned process | Open file descriptors (RLIMIT_NOFILE). Default 1024; 0 leaves the inherited limit. |
max_processes | each spawned process | Processes for the child's user (RLIMIT_NPROC). 0 or unset leaves the inherited limit. |
max_cpu_seconds | each spawned process | CPU seconds (RLIMIT_CPU). 0 or unset leaves the inherited limit. |
cpu_weight | each agent runtime (Linux) | Relative CPU share under contention, 1-10000. Not a cap. |
max_cpu_percent | each agent runtime (Linux) | Hard CPU cap, opt-in. May exceed 100 on a multi-core host (150 is 1.5 cores). Unset or 0 sets no cap, because a hard cap slows builds. |
A value outside its accepted range, a fraction that would round to 0, or a non-number is logged and ignored, and that key falls back to its default. 0 is a real value on the per-process rows (leave the inherited limit), so a 0 is never read as "unset" there.
Crew records a redacted event trail for each chat by default. The Crew log panel folds that trail into Status, Usage, Timeline, Tools, and Approvals. Authorized agents can read their own unit and the sessions they dispatched through the Crew log tools.
The session work ledger uses this log to preserve a compact goal, phase, next step, rejected approaches, and artifact pointers across context compaction. Conductor work and Issue Radar use the same durable record.
Set KIROCREW_CREW_LOG=0 before starting the Gateway to disable recording for the whole process. Ledger writes then refuse instead of falling back to an unaudited store. Deleting or trashing a conversation removes its Crew log with it, and Storage counts both together.
Open Settings → Overview and select the Usage card to open the Usage tab. Kiro CLI reports credits but saves no token counts, so the tab estimates tokens from the sessions it can read:
- The Estimated Tokens card lists input tokens, output tokens, total tokens, and model requests for this month and last month.
- The Daily History table has an Est. tokens column with each day's estimate beside its credits.
Input counts the full context sent with each model request, cached or not. Output is roughly the reply length divided by 4 and leaves out tool calls and reasoning. Only sessions saved on this computer are included. When some sessions could not be read, the card says so and leaves them out of the numbers.
Select the credits readout in the top bar to open the Kiro Account modal. When enough usage data is available, one line under its meter says whether your credits should last until the reset or, at this cycle's pace, the day they run out before it. The pace comes from your account's whole spend this cycle, including other clients signed in to the same account. Once this Gateway's Daily History holds 14 or more days, the projection also follows your weekday pattern.
The line stays hidden while usage is still loading, when no reset date is known, when the plan is already used up, while bonus credits are still being drawn down, or before one day of the cycle has passed. If recent usage cannot be loaded, the modal says the run-out date cannot be shown.
A subagent run reports its credits beside its elapsed time, for example 2.40 credits · 1m 5s. When the provider reports no credits, only the elapsed time appears. A cron run's result row in the dashboard carries the same usage footer as a chat turn: elapsed time, credits, and model.
The Storage screen reports transcript, attachment, and per-session disk use. Move a session to trash to reclaim it from active storage, restore it when needed, or empty trash to free the bytes permanently. Idle sessions are labeled as idle rather than counted as active work.
A scheduled job that runs without a persistent session writes one transcript per run. Since 0.12.1 Crew prunes those itself: each job keeps at most its 20 newest run transcripts, and none older than 7 days. Pinned transcripts and the job's own chat tab are never pruned, and run results stay in the job's run history.
- Sessions: session lifecycle, import and export, and the work ledger
- Subagents: capacity-aware parallel work
- Cron & scheduling: scheduled runs whose results carry the usage footer
- Snapshot and restore: back up state before a large cleanup
- Running 24/7: operate an always-on Gateway
- Troubleshooting: investigate disk and memory pressure
System & storage