scripting

Sandbox-Limits

CPU- und Speicherbudgets, was die Bytecode-VM verbietet und wie du längere Fenster opt-in.

Jedes Skript läuft in einer Bytecode-VM mit harten CPU- und Speicherbudgets, durchgesetzt pro Auswertung. Eine Endlosschleife reißt die App nicht runter.

Screener unter der Sandbox — 200 ms pro Symbol, Fan-out fühlt sich trotzdem sofort an.

Standardbudgets

| Oberfläche | CPU pro Bar | Speicher-Decke | |---|---|---| | Indicator (Chart-Vorschau) | 50 ms | 16 MB | | Alert (pro Auswertung) | 50 ms | 16 MB | | Screener (pro Symbol) | 200 ms | 32 MB | | Drawing | 50 ms | 16 MB | | Strategy (pro Bar) | 100 ms | 32 MB | | Backtester (kompletter Lauf) | 60 s | 256 MB | | VPS-Worker (pro Auswertung) | 200 ms | 64 MB |

Wird ein Budget überschritten, killt die VM die Auswertung und meldet einen Sandbox-Verletzungsfehler im Skript-Editor. Folgeauswertungen laufen weiter.

Verbotene Fähigkeiten

Die VM hat keinen Zugriff auf:

Das Host-Dateisystem.
Beliebige Netzwerk-Sockets. Nur geprüfte Built-ins (z. B. notify über eine bekannte Webhook-Liste) erreichen das Netz.
Native Code. Kein FFI.
Die Host-Uhr — Skripte lesen Bar-Timestamps via bar(N), nicht Date.now().
Den Status anderer Skripte. Jedes Skript ist isoliert.

Abbruch

Ein Skript kann mid-evaluation abgebrochen werden:

Der Nutzer schließt den Chart, bearbeitet das Skript oder drückt den Kill-Switch.
Das CPU-Budget ist aufgebraucht.
Für den Cloud-Worker: eine Tagesverlustgrenze oder Admin-Pause feuert.

Der Abbruch ist kooperativ — die VM injiziert Checkpoints zwischen Bytecode-Operationen, sodass eine enge Endlosschleife innerhalb von ~1 ms nach dem Abbruchsignal terminiert.

Opt-in für längere Budgets

Pro-Konten können erweiterte Budgets für bestimmte Skripte über Metadaten in der Datei anfordern:

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

Die Genehmigung wird automatisch geprüft — Missbrauch stuft die Anfrage herab.