Team plan

Credits, explained

The Team plan meters cloud compute and hosted data in one simple unit, the credit, drawn from one monthly allowance. Every job has a known cost, the balance is visible in real time, and spending beyond the allowance is blocked unless you opt in. This page is the whole model.

What the plan includes

One monthly allowance, spent on compute or on data as the month goes. It is sized to cover a serious research cadence, not to be the thing you think about.

5,000
credits / month

One allowance, spent on whatever the month needs: cloud sweeps, Monte Carlo, walk-forward, and the market data those studies run on.

Either way
compute or data

No split to plan around. A month spent sweeping and a month spent building a dataset draw on the same balance, and the dashboard shows where it went.

Monthly
reset, no rollover

The allowance refills on your billing date. Unused credits do not carry over, and it 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.

per-secondmachine classpublic rate card

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.

per-job minimumspin-upbatch-friendly

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.

auto-routingno instance picking

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.

local = freeexplicit submit

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 on the request, before you run it

A query through the platform is priced from what the vendor charges for exactly that request, and the number is shown before anything is fetched. No vendor account, invoice or minimum on your side for anything your cloud jobs read.

DatabentoMassiveprice shown upfront

Credits cover what your cloud jobs read

Hosted data lives on the platform and feeds the jobs you submit; what comes back to you is the result. Pulling raw market data onto your own machines stays what it is today: your vendor key, in your own library, on your own account.

cloud jobsresults come backlocal stays BYO key

Your team's cache is free

Anything already served to your team is cached and never billed twice. Asking for a range you already have costs nothing and calls no vendor, whoever on the desk asked first. Ask for a wider range and only the missing part is fetched.

team cachebilled once

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 the allowance runs out, jobs that would exceed it are blocked, not billed. Pay-as-you-go beyond it is an explicit opt-in, and it carries no markup: past the allowance you pay what the work costs.

blocked, not billedPAYG opt-in

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.

hard capyour number

Alerts before it matters

You are alerted at 80% of the allowance, and the usage dashboard shows the balance, where it went between compute and data, per-job history, and an end-of-month projection in real time.

80% alertlive balanceprojection

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.