Budgets and limits
Chartnaut caps how much work a script can do, so a heavy loop cannot freeze Charts or stall a study run. A soft limit shows a warning and the script keeps running. A hard limit stops the script with an error naming what it hit, the observed value and the limit.
These are processing limits. They are separate from AI credits and from your plan's usage limits on Plans and limits. The full list of limits and error codes is on Limits and errors.
Indicators and definitions on the chart
Limit | Soft | Hard |
|---|---|---|
One full calculation | 2 s | 30 s |
One | 5 s | |
Warmup walk of timeframe handlers, once per full reset | 2.5 s | 10 s |
Loop iterations in one call | 350,000 | |
Loop iterations per calculation | 10,000 per bar, between 2 million and 50 million | |
| 500,000 | |
Plotted points | 500,000 | 2,000,000 |
Emitted events | 25,000 | 100,000 |
| 256 | 1,024 |
Live and closed levels, zones and trendlines | 2,500 | 10,000 |
Rows per layer | 5,000 | 20,000 |
Bytes per layer | 4 MB | 32 MB |
Every loop is instrumented, so a runaway loop stops at the iteration cap rather than hanging the tab. while (true) and for (;;) without a visible exit warn at lint with caps/unbounded-loop.
A mode: "once" indicator runs its whole window inside one onRun call, so the per-call caps are lifted to the per-calculation ones.
Studies
Limit | Preview in the builder | Full run |
|---|---|---|
Wall clock | warn at 2 min, stop at 10 min | warn at 8 min, stop at 10 min |
One | 15 s | 15 s |
Events processed | warn at 10,000, stop at 50,000 | warn at 50,000, stop at 100,000 |
Annotations | warn at 2,500, stop at 10,000 | warn at 2,500, stop at 10,000 |
Result payload | warn at 500 KB, stop at 2 MB | warn at 10 MB, stop at 100 MB |
Forward bars | 1,000 | 5,000 |
An onEvent call over 15 seconds is skipped as an event timeout. Ten event timeouts stop the run with too_many_event_timeouts. Other stops report budget_wall_clock, budget_total_events, budget_annotations, budget_payload or budget_forward_bars.
History depth
Your plan caps how many buckets of each timeframe a script can hold. It bounds warmup(...), retain(...) and the history loaded behind timeframe handles, and w.forever() resolves to it.
Plan | Indicator memory |
|---|---|
Free | 2,500 buckets |
Starter | 5,000 buckets |
Pro | 5,000 buckets |
Ultra | 10,000 buckets |
It counts rows, not time, so it lands very differently by timeframe. At 5,000 buckets:
Timeframe | 5,000 buckets is roughly |
|---|---|
| 13 years of 24/7 bars: more than the platform's daily history |
| 2.3 years |
| 7 months |
| 17 days |
Your plan's history window can stop a script sooner. Over-declaring is clamped, reported through history.truncated with reason "cap", and warned by window/clamped-to-cap. It is never an error. For an extreme or a total over a span the cap will not reach, use ctx.summary. More on Warmup and memory and Indicator memory.
When you hit a limit
Read the error or warning in the builder. It names the limit and, for a per-bar limit, the bar.
Do less work per bar or per event: fewer series, tighter loops, narrower forward windows.
Remove dependencies you do not read.
Run the definition over a shorter range while you iterate.
Budget exceeded walks through the common cases.