Files

T

retoor af080fe68e Strict goal verification, approval hardening, retrieval eval, work limits, sandbox caps (1.38.0)

- Approval: re-prompt unknown answers (max 3), shell-only affirmative
  guidance recovery; destructive actions stay strict
- GoalVerifier subagent with strict JSON verdicts, bounded follow-up
  rounds, nonzero exit plus open turn on unverified one-shots
- Retrieval eval (Hit@K/MRR/nDCG/Context Precision), FTS cascade with
  title weighting, query/read event logging, --eval-retrieval CLI
- Supervisor caps (8 parallel, 64 records) and scheduler hardening
  (4 fires/tick, per-schedule lease, stated misfire policy)
- Sandbox box resource trio: 2g/2.0/256 at create, best-effort
  update for existing boxes, rm -f recovery pointer
- Research archive: 12 subjects, 667 sources, 27 conclusions;
  suites 979 + 16 green

2026-10-18 12:13:24 +02:00

2.7 KiB

Raw Blame History

Resource constraints

Metadata

Field	Value
Institute	Molodetz Institute — Research & Retrieval Division
Subject	sandbox-resource-caps
Document type	Source Dossier
Tier	1
Source title	Resource constraints
Source URL	https://docs.docker.com/engine/containers/resource_constraints/
Source publisher / author	Docker
Source type	vendor docs
Source date (published)	Unknown, not stated (living documentation page)
Date researched	2026-10-18
Researched by	tai (agent), model: Muse Spark, on behalf of retoor
Research method	direct page fetch
Confidence	High
Status	Active

Summary

Docker's resource-constraint reference: containers default to no limits and can use whatever the host scheduler allows; an uncapped container can trigger host-wide OOM kills against unrelated processes. Memory gets hard limits, CPU gets the --cpus ceiling as the convenient CFS quota form, and swap needs explicit attention alongside memory.

Key findings

"By default, a container has no resource constraints and can use as much of a given resource as the host's kernel scheduler allows."
"On Linux hosts, if the kernel detects that there isn't enough memory to perform important system functions, it throws an OOME, or Out Of Memory Exception, and starts killing processes to free up memory. Any process is subject to killing, including Docker and other important applications."
"--cpus=<value>: Specify how much of the available CPU resources a container can use... This is the equivalent of setting --cpu-period=\"100000\" and --cpu-quota=\"150000\"."
"For most use-cases, --cpus is a more convenient alternative" to raw period/quota knobs.
Mitigations listed: test memory requirements, run on adequate hosts, limit container memory, be mindful of swap configuration.

Pros / strengths

Authoritative statement of the default (unlimited) and the failure mode (host OOM), which is exactly tai's pre-cap exposure.
Blesses --cpus as the standard CPU ceiling form both engines accept.

Cons / limitations / caveats

Docker-authored; flag parity with podman verified separately in the podman-run dossier, not here.
Swap semantics (memory-plus-swap totals) need care; tai sets memory only and accepts the documented roughly-2x-with-swap worst case as still bounded.

Relevance to tai

Justifies capping the agent sandbox on all three axes: the box runs arbitrary agent shell commands, so an uncapped box is one buggy loop from host OOM. tai takes memory plus cpus from this page and pids-limit from the CIS baseline card.

Changelog

Date	Change
2026-10-18	Initial dossier created.

2.7 KiB Raw Blame History