Limits reference

Every ceiling a wrun indicator runs under on the chart, in one place: the declaration caps Run checks when it derives the sheet, the runtime ceilings the browser sandbox enforces on every run, the data bounds, and the publish bounds.

Each row gives the exact number, what it protects, the shape that hits it, and the message it produces. Most of them are counts of declarations, because a wrun indicator declares almost everything once.

Plans

Free and Plus differ in how much you keep on your charts and in your account:

At the saved-script limit, saving a new script stops with "Saved-script limit reached (100 on your plan). Delete a script or upgrade to save new ones."

Declaration caps

Checked by Run in your browser when it derives the sheet from your declarations, before anything reaches the chart. A declaration over a cap is refused in the editor's Console, anchored on the declaration that breaks it and naming the field (boxes.0.top, renderers.2.size).

What the chart trims when it draws

These limits never refuse a run. The chart applies them when it draws, so one indicator can't bury another, hide the chart's own buttons, or draw more rows than a screen can show.

Names share one namespace across outputs, boxes, segments, renderers, and drawings; color_by, width_by, and shape_where cannot name their own output; each ladder half without the other is refused by name. The full validation list is at the end of Declarations and the sheet.

Runtime ceilings

Enforced on every run by the sandbox your browser runs the module in. A breach refuses the WHOLE run by name and the editor's Console says why; nothing is truncated, clamped, or silently dropped. An indicator that already drew keeps its last good render, and its legend offers a retry.

The module contract is checked by Run before any of this: the four engine functions the build adds around onBar() with exact signatures (a file that exports them itself is checked the same way, The four-function form), exported memory when the cell, string, or polyline channel is imported, every present draw import with its exact signature, and an import set limited to the contract's allowlist. Before a module runs, the chart checks its bytes against the sheet's wasm_sha256 and refuses a mismatch. Those messages are in Common errors.

Data bounds

Publish bounds

The module runs sandboxed: no filesystem, no network, no order capability. Each wrun indicator on a chart, a draft from Run included, counts against the chart's indicator limit. Publishing has the dialog.

Other bounds

Bounds that are not a number in the tables above.

Notes that save debugging time

• max_cells is a contract, not a hint. The build sizes one buffer per celled input from it (in_<input>_capacity f64s, tuples x width) when the module starts, and in_<input>_view() reads it in place; size a book input for the chart's depth: at most 500 levels a side, so 1000 tuples.
• Strings never truncate. Pick max_bytes for the longest line the slot will ever carry; the generated builder counts the bytes a line REQUIRES, so an oversize line refuses by name instead of clipping.
• Most caps are counts of declarations. You meet them when you press Run, in the editor's Console, anchored on the declaration. A repeating shape is one declaration gated per bar with when, never one declaration per occurrence.
• Segments count as drawings. A segment drawn on every bar of a long window is the shape that reaches 2,000 drawings per run; gate it with when or narrow its span.
• The render cap counts expanded bytes. Sixty-four text renderers over a long history with long strings is the shape that reaches 8 MiB; leave slots unwritten on quiet bars so those rows select nothing.
• Delete what you no longer draw. A handle stays alive until delete(); the per-kind cap is met by the tracker that creates a zone on every pivot and never frees one. Keep a bounded pool of ids and delete the oldest before reusing its id, and re-send only the handles that changed on a bar (the calls-per-bar cap counts every setter).
• Allocate once. Buffers are sized at module start or in onStart() from a param's max; per-bar allocation is the one pattern that both slows a long history and trips the no-growth rule.

Example: the caps as contracts

A book-imbalance indicator that sizes everything from what the chart delivers: the chart's order book carries at most 500 levels a side, so max_cells is 1000; the cell buffer is the build's own, sized from that cap and read in place; and the readout slot is sized for its longest line:

input("close", ohlcv.close);
// The chart's order book carries at most 500 levels a side, so a bar never holds more than 1000 tuples:
// max_cells is a contract, and a bigger block would refuse the whole run.
// block_size is required by the declaration; the chart keeps its own price grouping.
input("book", book.cells, { max_cells: 1000, block_size: 10 });
output("imbalance", line, lower, { unit: "ratio" });
// The longest line is "500 bids / 500 asks" (19 bytes); 32 leaves room and stays under the 4096 cap.
string("depth", { max_bytes: 32 });
render.text("depth_mark", { y: "imbalance", text: "depth", size: 10 });

function onBar(): void {
  const n = in_book_cells();
  if (n <= 0) return;
  // The build's own buffer, sized once at module start: max_cells x 3 cells per [price, size, side] tuple.
  const cells = in_book_view();
  let bidSize = 0.0;
  let askSize = 0.0;
  let bids: i32 = 0;
  let asks: i32 = 0;
  for (let i = 0; i + 2 < n; i += 3) {
    if (cells[i + 2] > 0.0) {
      bidSize += cells[i + 1];
      bids += 1;
    } else {
      askSize += cells[i + 1];
      asks += 1;
    }
  }
  const total = bidSize + askSize;
  const imbalance = total > 0.0 ? (bidSize - askSize) / total : NaN;
  if (isNaN(imbalance)) return;
  out_imbalance(imbalance);
  sb_clear();
  sb_int(bids);
  sb_text(" bids / ");
  sb_int(asks);
  sb_text(" asks");
  str_depth_sb();
}

The scan branches on each tuple's side, never on its position: the chart lists the bids best first, then the asks from the farthest to the best.