Sandbox & Security

Worker code runs in a restricted Python environment. This page covers the security model at a high level — what to expect, what works, and what doesn't.

Execution Model

• Each worker is isolated: it cannot read other workers' code, state, or secrets.
• tick() runs on a schedule. Long ticks are killed automatically.
• The ctx object is the only sanctioned way to reach the outside world. Anything not exposed through ctx is not available.

What's Available

A trusted subset of the Python standard library is available, including the usual data manipulation toolkit:

• Math, statistics, datetime, regex, JSON
• Collections (defaultdict, Counter, ...), iterators, decimal
• Hashing & HMAC (hashlib, hmac, base64)
• Random, copy, functools
• numpy and pandas are available for numerical work

What's Blocked

System and I/O access is intentionally not available to worker code. Use the corresponding ctx adapter instead:

You'd reach for...	Use this instead
open(), pathlib, shutil	ctx.files
socket, urllib, requests, http	ctx.http
os, sys, subprocess, threading	not available — design tasks around tick()
eval, exec, __import__	not available

If you import a blocked module, the import raises an error explaining the restriction.

Resource Limits

• Tick timeout: 60 s — if your tick exceeds it, it's killed and on_error() (if defined) is called.
• Logs: messages are batched and truncated to a reasonable size. Use ctx.log.info/warn/error rather than print() for structured log output.
• HTTP requests: 30 s timeout per request.
• File storage: 100 MB per workspace, 50 KB per file read.
• State values: persisted in Redis — keep individual values reasonably small (under a few hundred KB).

Best Practices

1. Keep ticks fast. Split heavy work across multiple ticks using ctx.state to track progress.
2. Persist via ctx.state. Module-level globals reset whenever the worker restarts.
3. Check return values. Most adapters return dicts — look for an "error" key before consuming the data.
4. Log meaningfully. ctx.log.info for milestones, ctx.log.error for failures, ctx.log.debug for noisy diagnostics.
5. Trim collections. Don't accumulate unbounded history — slice down to a window (e.g. last 100 entries) before saving back to state.

Outbound Networking

All outbound HTTP traffic from ctx.http and the trading/messenger adapters is routed through an AiSpinner-managed European egress proxy with rotating IPs. This protects your API keys against exchange-side IP-concentration rate limits and keeps third-party providers happy when many users share the platform. You don't need to configure anything — it's automatic.