Account

Data & credits

Two practical questions come up in every research session: what data am I running on? and what does this run cost me? The Data section answers the first; the credit estimates answer the second. Here's how to read both.

The data on the platform

The Data section lists every dataset available to your runs, with its symbols, date coverage and provenance. Two kinds of data exist:

  • Synthetic data — artificially generated market data (a demo instrument with realistic bars, volume and order-flow) used for onboarding, demos and tests. It photographs like the real thing and exercises every feature of the platform, but it carries no information about any real market. Its labeling always says so.
  • Licensed market data — real futures data (e.g. ES, NQ, MES, MNQ), sourced on demand from Databento, with per-day coverage tracking. Each dataset's coverage calendar marks days as present, partial, missing, expected, holiday or quarantined (roll boundaries) — so you can see at a glance whether your intended backtest window is fully covered before you launch.

Runs use data that is already here

Backtests run on data already on the platform. Bringing in new data is a deliberate, quoted step: the quote names the cost and any degraded days, a human approves it, and delivery is integrity-checked. Nothing you click in the Data section can spend money without that explicit approval. If a run's window has gaps, the launch dialog tells you before anything runs, and a failed run offers a Request this range shortcut.

Requesting new data on demand

When you need a range that isn't on the platform yet, the Data section's Download requests tab fetches it from Databento through a quote-first workflow — nothing is charged until a human approves:

  1. Describe the range. Pick the dataset, the symbols, the start and end dates, and the schema:
    • tbbo — top-of-book (L1) quotes and trades; the everyday choice.
    • mbp-10 — L2 order-book depth, ten levels each side. This is the heaviest schema, so a single request is capped at 31 days — narrow the window or split it.
    • definition — instrument reference data.
  2. Get a free quote. The request returns the exact cost and any degraded days, and it expires after a day so a stale quote never gets approved. Requesting a quote never spends.
  3. A human approves. Approval names the cost out loud (you type it to confirm) and must acknowledge each degraded day individually — never a blanket wave-through. Delivery is then integrity-checked before the data is usable.

You can bill a fetch to the platform budget (an admin approves) or to your own vendor account via a connection you configure, in which case you approve your own spend.

Bring your own data

You can also skip the vendor entirely and upload data you already have, from the Data section's Catalog & Upload tab:

  • CSV — OHLCV bars, trades, or L1 quotes, for futures, equities or FX (you name the symbol and, for CSV, the asset class and optional venue).
  • Databento DBN — a raw DBN file (including the compressed .dbn.zst form).

An upload is validated by the engine and written once into an isolated catalog that only you can read, ready to backtest against. Uploading calls no vendor and spends nothing — but you are responsible for the data's licensing. Behind the scenes each dataset (platform or BYO) is compiled into a fast catalog the backtest reads; depth uploads build an L2 catalog, quotes/trades an L1 one, and rebuilding identical inputs is a no-op.

What consumes credits

Credits meter the platform resources your research consumes. The rules of thumb:

  • Always free: running tests and previews. The cheap loop — edit, test, preview — never costs credits, so there is never a reason to skip testing.
  • Metered: full backtests and notebook runs (by compute time), AI-builder usage, data scanned by runs, artifact storage, and generated report bundles.
  • Your account has a monthly included allowance; if a launch would exceed your balance, the app refuses it with the exact shortfall and what to do about it (an admin top-up — or keep working in the always-free tier).

Reading the estimate

Before a metered run launches, the dialog shows Estimated cost (credits), e.g.:

~4.2 sandbox-min · 210 cpu-s · 0.84 credits (basis: recent runs of this kind, n=12)

  • sandbox-min — estimated minutes of isolated compute; this is what actually drives the credit figure for runs.
  • cpu-s — estimated processor seconds, a finer-grained signal of how heavy the run is.
  • basis / n — where the estimate came from: it is calibrated from a sample of comparable past runs. A small n means a rougher estimate.
  • The caveat is honest by design. Estimates come with a plain statement that credit cost bases are provisional and recalibrated against real usage. Your balance is always exact; the forecast of what a run will consume is an estimate and is labeled as one.

Platform spend caps

Separately from your credits, the platform's own spending (for example on data acquisition) runs under hard monthly and per-request caps, visible in the Data section's Spend tab: month-to-date used, in-flight, remaining. The cap is enforced server-side — the platform refuses to exceed it rather than warning after the fact. You'll likely never need this tab, but it's there so spend is never a mystery.