Credits, explained
The Team plan meters cloud compute and hosted data in one simple unit: the credit. Every job has a known cost, every balance is visible in real time, and spending beyond the monthly allowance is blocked unless you opt in. This page is the whole model.
What the plan includes
Two separate monthly allowances, one for compute and one for data, both in the same unit. They are sized to cover a serious research cadence, not to be the thing you think about.
Covers cloud sweeps, Monte Carlo and walk-forward jobs, metered per second of machine time.
Covers Databento and Massive queries made through the platform, priced in credits per request.
Both allowances refill on your billing date. Unused credits do not carry over, and the allowance is sized so that they rarely need to.
How compute is metered
Compute credits buy seconds of machine time. The unit price depends on the class of machine a job runs on, and nothing else: no instance sizes, no regions, no reserved anything.
Per second, by machine class
Each job is billed for the seconds it runs, at a rate set by the machine class it lands on. GPU seconds cost more than CPU seconds; the public rate card lists every class in credits.
A small minimum per job
Every job carries a minimum of a few seconds, which covers spinning capacity up for you. Batching many tiny requests into one job is always cheaper than a loop of one-liners.
Routed to the cheapest class that fits
You do not pick machines. The planner routes each job to the cheapest class that can run it, and only reaches for GPU capacity when the workload justifies it.
Local runs never touch credits
Interactive work on your own machine runs on your Pro seat, exactly as it does today. Credits are only consumed by jobs you explicitly submit to managed capacity.
How data is metered
Data credits cover vendor queries made through the platform. The point of the model is the cache: a dataset is paid for once per team, ever.
Priced per request, in credits
A query to Databento or Massive through the platform costs a known number of credits, shown before you run it. No vendor accounts, invoices, or minimums on your side.
Your team's cache is free
Anything already served to your team is cached and never billed twice. Re-running a study on the same dataset costs zero data credits, whoever on the desk asked first.
No surprise invoices, by construction
Metered billing usually fails on trust, so the defaults do the protecting: the plan cannot spend money you did not explicitly agree to spend.
Overage is off by default
When an allowance runs out, jobs that would exceed it are blocked, not billed. Pay-as-you-go beyond the allowance is an explicit opt-in, at the same rate card.
A hard cap you set
If you do opt in to pay-as-you-go, you set a hard monthly spend cap. The platform stops before the cap does, every month, with no exceptions.
Alerts before it matters
You are alerted at 80% of each allowance, and the usage dashboard shows balances, per-job history, and an end-of-month projection in real time.
The rate card
The full rate card, credits per second for every machine class and per-request data pricing, is public and part of the plan. We are calibrating the final numbers on the production hardware with early access teams, and it will be published on this page before the plan is self-serve. Early access partners get it first, in writing.
See it against your workloads
Tell us what a typical research week looks like on your desk and we will map it to credits with you, before you commit to anything.