# `jan runtime`
Jan-owned warm interpreter pool. Language leaves (`exec.python`, `exec.node`, shells, compiled Kotlin) prefer a long-lived worker when the supervisor is up; each job still runs in an **isolated child** (fork / subprocess) so state does not leak and a crash cannot kill the pool.
This is **not** a third MAS peer daemon. Unifier + Jan cron remain the only swarm peers; runtime workers are Jan-internal (same trust family as cron’s child `jan` processes).
## Commands
```bash
jan runtime start
jan runtime stop
jan runtime restart
jan runtime status
jan runtime daemon # foreground (tests / systemd-style)
```
`jan cron start` also ensures the runtime supervisor is up. `jan cron stop` stops it.
## Behavior
| `JAN_RUNTIME=0` / `false` / `off` | Force cold `Command::new` spawns |
| `JAN_RUNTIME_DEBUG=1` | Print warm→cold fallback reasons on stderr |
Workers are keyed by `(language, interpreter path, package env root)` so different `packages.uv` / `packages.pnpm` caches do not share a process.
Node uses a **persistent `worker_threads` isolate** (jobs via `postMessage`); Python uses `os.fork()` per job. Both keep the interpreter warm while isolating runs.
Workers must reproduce the cold-spawn **argv layout** exactly, since a leaf cannot tell which path ran it: inline sources match `node -e code a b` / `python3 -c code a b` (no script path in argv, so `process.argv[1]` / `sys.argv[1]` is the first user arg), and file sources match `node script.js a b` / `python3 script.py a b`.
`.kts` Kotlin scripts still cold-start via `kotlinc -script`. Compiled `.kt` / inline Kotlin can use the kotlin worker.
## Status line
`jan runtime status` reports uptime, worker count, warm hits, cold fallbacks, and per-worker job counts.