Dependencies & limits
On this page
Dependencies & limits
Locked packages#
The sandbox includes this scientific-computing stack. A project may also declare public PyPI packages in requirements.in and resolve them to opr.lock.json before freezing:
Dependency resolution accepts ordinary package specifiers only, downloads binary wheels from public PyPI, records exact versions and SHA-256 hashes, and builds a read-only environment without importing wheel code. Source distributions, URLs, VCS and runtime pip are rejected. Backtests and Notebook Jobs remain offline.
scikit-learn>=1.8,<2 seaborn==0.13.2
Resource limits#
| Validation dry run | 5 / 10 / 20 / 30 min (8 / 16 / 32 / 64 GiB) |
| Processes | 256 |
| Network | none (--network=none) |
strategy_memory_gb selects one complete machine profile shared by Backtest, Study, Paper and Live. STANDARD/VIP1 can use 8 GiB; VIP2 can use 8 or 16; VIP3 and ADMIN can cumulatively use 8, 16, 32 or 64. New requests default to 8. Existing legacy Paper/Live deployments without the field keep their 2 GiB / 1 CPU runtime fallback; a new Live derived from such a Paper defaults to 8. Profile selection does not change concurrency. MCP Agents must show the permitted choices and ask before submission.
CPU applies to every Strategy sandbox. For Backtest/Study, the profile also freezes the full-run wall clock, total result-output size and a cumulative Context response budget for each isolated pass (dry run and full run separately). Preflight uses the same profile for estimated memory, CPU seconds and output, and records the complete contract in strategy_machine_profile. Study aggregate CPU/output capacity is the per-sandbox profile multiplied by physical trial-fold attempts, still capped by the absolute platform envelope. Validation starts after prefetch and includes initialization: 5/10/20/30 minutes for 8/16/32/64 GiB, separate from the full-run allowance. Paper/Live callbacks keep their latency-oriented deadline instead of inheriting a multi-hour Backtest deadline. Per-call Context method limits stay unchanged.
Agents can call research.limits before creating a project or submitting work. It returns all machine profiles, your allowed choices, shared account submission limits and the selected machine's personal admission policy. profiles[].backtest_dry_run_wall_clock_seconds lists validation budgets; semantics.dry_run_wall_clock_seconds reports the selected Backtest/Study budget, or null for standalone Factor Evaluation. Artifact organization overrides, Study totals and remaining daily usage are resolved by preflight/admission. Standalone Factor Evaluation currently uses the 8 GiB profile.
| strategy_memory_gb | CPU | Full-run wall clock | Result output | Cumulative Context rows | Cumulative serialized responses | Context calls |
|---|---|---|---|---|---|---|
| 8 GiB | 2 | 4 h | 2 GiB | 500,000,000 | 32 GiB | 4,000,000 |
| 16 GiB | 4 | 8 h | 4 GiB | 2,000,000,000 | 128 GiB | 16,000,000 |
| 32 GiB | 8 | 16 h | 8 GiB | 8,000,000,000 | 512 GiB | 64,000,000 |
| 64 GiB | 16 | 24 h | 16 GiB | 20,000,000,000 | 1024 GiB | 128,000,000 |
These are cumulative work and transfer ceilings, not memory reservations or throughput guarantees. Repeated histories count again toward logical rows; response bytes reflect encoded successful Context responses and delta transport, not ClickHouse scan bytes. Successful backtest.result.stats.strategy_context_usage reports the existing counters. Per callback: at most 4,096 calls, 1M rows and 128 MiB of responses; each protocol frame is limited to 64 MiB.
Administrator research controls#
Administrators configure AI allowances and research-compute admission independently. These settings are limits, not reserved capacity; the selected model, role policy and platform safety limits may further reduce what is available.
AI MODEL QUOTAS
| Field | Value / unit | Meaning |
|---|---|---|
| scope / subject_key | PLATFORM / default ROLE / MEMBER ORGANIZATION / <id> USER / <id> | Quota target: PLATFORM/default is global; ROLE is a per-user fallback for that role, while ORGANIZATION is a shared organization bucket and USER targets one numeric user ID. A USER policy replaces its ROLE fallback; effective limits then take the lowest applicable ceiling. |
| model_key | one built-in model | Policies are model-specific. The key must identify an enabled model deployment. |
| daily_token_limit | tokens / UTC day; blank = unlimited | Built-in-model input + output allowance for this target, model, and UTC day. Leave blank for no daily ceiling; zero blocks the allowance. BYOK usage is excluded, and provider or platform hard limits still apply. |
| max_input_tokens | tokens / request | Positive integer maximum input tokens per request for this target. Effective input is capped again by the selected model and provider connection. |
| max_output_tokens | tokens / request | Positive integer maximum generated tokens per request for this target. Effective output is the lowest applicable quota, deployment, model, and provider limit. |
| max_concurrent | active requests | Positive integer maximum active AI requests for this target and model. It is combined with platform and provider concurrency limits. |
| requests_per_minute | RPM | Positive integer maximum accepted requests in a UTC-aligned fixed minute bucket for this target and model, further bounded by platform and provider limits. |
Default sponsored allowance: 10,000,000 tokens per user, model and UTC day. Kimi K3 also has a 50,000,000-token platform total; DeepSeek and GLM have no platform daily-token ceiling. Administrators may override a user or role policy.
WORKLOAD ADMISSION
JSON override for automatic, maximum and daily work units plus peak-memory, cache, output, trial and fold caps. Values are non-negative integers capped by system ceilings. Daily usage is counted per user, organization, UTC day and workload kind; approval can cross the automatic threshold, never the hard or daily limit.
A workload policy is scoped independently to BACKTEST, STUDY or FACTOR_EVALUATION. Use SYSTEM / default, ROLE / <role>, ORGANIZATION / <id>, or USER / <id>. Resolution proceeds from system to role, organization and user; a more specific record replaces the same JSON key from an earlier scope.
| Policy field | MEMBER base | System ceiling | Admission effect |
|---|---|---|---|
| automatic_work_units | 50,000,000 | 2,000,000,000 | At or below this value, a workload may enter the queue without manual approval when every other limit also passes. |
| maximum_work_units | 250,000,000 | 10,000,000,000 | Above automatic but at or below maximum requires an administrator approval bound to the exact request. Above maximum is denied. |
| daily_work_units | 500,000,000 | 20,000,000,000 | UTC-day budget per user, organization and workload kind. Reserved plus settled actual units count against the remaining allowance. |
| maximum_peak_memory_mb | 6,144 MiB | 65,536 MiB | Absolute estimated peak-memory ceiling; the selected strategy_memory_gb profile remains the effective per-sandbox limit. |
| maximum_cpu_seconds | 14,400 s | 1,382,400 s | Maximum estimated aggregate CPU time. The selected machine profile applies CPU cores × full-run wall clock as the effective ceiling. |
| maximum_cache_bytes | 50,000,000,000 B | 1,000,000,000,000 B | Maximum estimated immutable dataset cache required by the workload. |
| maximum_output_bytes | 536,870,912 B | 17,179,869,184 B | Maximum estimated result and evidence output. The selected 8/16/32/64 GiB machine applies 2/4/8/16 GiB as the effective ceiling. |
| maximum_trials | 512 | 10,000 | Maximum parameter or scenario trials in one Study. |
| maximum_folds | 64 | 512 | Maximum walk-forward folds in one Study. |
Role defaults can be refined for an organization or user. Leaving a field out keeps the value inherited from the broader scope; review the effective limits in administrator settings before saving.
{
"automatic_work_units": 50000000,
"maximum_work_units": 250000000,
"daily_work_units": 500000000
}A work unit estimates research workload; it is not a duration, token count or currency amount. The estimate reflects the requested dates, instruments and data. Studies also include trials and folds, while Factor Evaluation accounts for its forward horizons. Review the estimate before queueing the workload.