Scheduled tasks: per-task memory limit, timeout and concurrency group

[Jamaalx]

Note

Drafted with Claude Code on behalf of @Jamaalx; I reviewed it and the numbers come from my server.

Before submitting

• I searched existing issues and discussions and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/server (scheduled tasks, process/agentScope.ts)

Problem or use case

I run about 40 recurring unattended Claude jobs (security, dependency and DB audits, a morning digest) on a 125 GB Linux server that also hosts production apps and databases. Today they run from cron through a small wrapper around claude -p. I'd like to move them into T3 scheduled tasks so every run is a thread I can read and continue, but the wrapper does four things a scheduled task can't express yet:

1. A memory limit per job. On 2026-11-05 one job's python3 grew to 72 GB and froze the server, including SSH and Tailscale, for 23 minutes. The wrapper now runs each job in its own systemd-run --scope -p MemoryMax=12G. T3 already puts agents in app-t3code-agents.slice, but that limit is shared by all agents and set to total RAM minus 4 GB (about 121 GB here), so a single runaway agent can still take everything the production services need.
2. A time limit per job (30 to 150 minutes), after which the agent is stopped and the partial report kept.
3. One heavy job at a time. Heavy audits share a lock; light read-only checks have a separate one.
4. Skipping a run when free memory is below a threshold, instead of starting it anyway.

The right limit depends on the job. A quick health check should be capped tightly; a quarterly audit on a quiet night should not be capped at all. A single service-wide limit can't express that.

Proposed solution

Optional, per-task settings, all off by default so current behaviour is unchanged:

• memoryMax (and possibly memoryHigh): on Linux, run the task's agent in its own scope under the existing agents slice with these values. The slice-wide limit stays as the outer bound.
• timeout: stop the run after this duration and record it as timed_out in last_run_status.
• concurrencyGroup: runs in the same group wait for each other (or are skipped, configurable).
• Optionally, minFreeMemory: skip the run, with a clear status, when available memory is below this.

The same fields could be set per thread when a thread is started from the CLI (t3 thread start --memory-max 12G --timeout 40m), which would also cover scripts that hand their output to an agent.

Why this matters

Unattended agents on shared or production machines are the case where a runaway process does the most damage and nobody is watching. Per-task limits let people move those jobs into T3 instead of keeping a parallel cron setup, and they fit the reliability work already done in agentScope.ts (#20329, #24048).

Alternatives considered

• Lower limit on the whole agents slice, or on the T3 service: caps every agent, including the jobs that legitimately need a lot of memory.
• Keep the cron wrapper and call t3 thread start --wait: the agent then runs inside the T3 server's slice, so the wrapper's MemoryMax and timeout no longer apply to it. Killing the waiting CLI doesn't stop the agent.
• Keep running claude -p from cron: works, but the runs never show up in T3.

Related: #31997 (scheduled tasks as files in the repo) — these fields would belong in that config too.

If the direction is acceptable, I'm happy to implement the Linux part (scope per task, timeout, concurrency group) in a focused PR.

[Guria]

Note

🤖 Claude Opus 5.5 responding on behalf of Guria

minFreeMemory is one case of the gate command proposed in #33242: a script checks available memory and exits 1 to skip the run without starting a turn.