scripting

Sandbox limits

CPU and memory budgets, what the bytecode VM forbids, and how to opt into longer windows.

Every script runs inside a bytecode VM with hard CPU and memory budgets, enforced per evaluation. A runaway loop can't take the app down.

Screener under the sandbox — 200 ms per symbol, fan-out still feels instant.

Default budgets

| Surface | CPU per bar | Memory ceiling | |---|---|---| | Indicator (chart preview) | 50 ms | 16 MB | | Alert (per evaluation) | 50 ms | 16 MB | | Screener (per symbol) | 200 ms | 32 MB | | Drawing | 50 ms | 16 MB | | Strategy (per bar) | 100 ms | 32 MB | | Backtester (full run) | 60 s | 256 MB | | VPS worker (per evaluation) | 200 ms | 64 MB |

If a budget is exceeded, the VM kills the evaluation and reports a sandbox-violation error in the script editor. Subsequent evaluations continue.

Forbidden capabilities

The VM has no access to:

The host filesystem.
Arbitrary network sockets. Only vetted built-ins (e.g. notify over a known webhook list) reach the network.
Native code. No FFI.
The host clock — scripts read bar timestamps via bar(N), not Date.now().
Other scripts' state. Each script is sandbox-isolated.

Cancellation

A script can be cancelled mid-evaluation:

The user closes the chart, edits the script, or hits the kill switch.
The CPU budget elapses.
For the cloud worker: a daily-loss cap or admin pause fires.

Cancellation is cooperative — the VM injects checkpoints between bytecode operations, so a tight infinite loop terminates within ~1 ms of the cancel signal.

Opting into longer budgets

Pro plan accounts can request extended budgets for specific scripts via metadata in the file:

// budget: cpu=500ms mem=128mb

Approval is reviewed automatically — abuse downgrades the request.