# FAQ

## Allocation and base load

### How does the allocation model work — is it first-come, first-served, or guaranteed reservations?

Neither: it's **price-ordered**. Every auction tick (roughly 10
seconds) re-runs the market over all demand, and capacity goes to the
highest-value bids. Arrival order matters only as a tie-break — at
equal bids, the older demand wins — and there is no queue to hold a
place in. What plays the role of a guarantee is the
[minimum-duration protection window](https://docs.nationalcompute.com/market.md#minimum-duration-protection):
a freshly granted node cannot be taken by any competing bid while
its window (currently one hour on VM clusters, two hours on Kubernetes
clusters) is open. Beyond that window, you keep capacity by keeping
your ceiling at or above the going rate. The one guaranteed product is a
[base load block](https://docs.nationalcompute.com/market.md#base-load-capacity): a fixed block of nodes for a fixed
term at a fixed rate, outside the auction.

### Can a reservation be secured within ~36 hours of a request?

For burst capacity, faster than that: declared capacity is granted at
the **next auction tick** in which supply exists and your ceiling
clears — seconds to minutes when the market has room. For a committed
[base load block](https://docs.nationalcompute.com/market.md#base-load-capacity), any member of your
organization buys it on the Burst capacity page where buying is open. Elsewhere your
account team arranges it. A block starts as soon as it is sold and its
nodes are delivered ahead of every bid on the island.

### Is this on-demand — do we specify a time length?

For burst capacity, no fixed term in either direction. You hold
capacity as long as you want it and release it whenever you want
(scale-down is immediate; a Kubernetes node still bills its
[one-hour minimum](https://docs.nationalcompute.com/market.md#minimum-duration-protection)). The only
time-shaped elements are the protection window and the one-hour minimum
hold on fresh grants. If you want a committed term, a
[base load block](https://docs.nationalcompute.com/market.md#base-load-capacity) is sold for the posted terms at a
fixed rate.

### How do we do capacity planning under this system?

Three instruments: the [market feed](https://docs.nationalcompute.com/api/market-feed.md) gives you the
going rate per tick and up to a year of history, so you can see what a
given ceiling would have held historically; the capacity read echoes
your own position (declared, granted, pending, and whether a standing
bid can still clear); and your worst-case spend is arithmetic — held
GPUs × your ceiling. The
practical loop is to pick the ceiling that clears at the rate you can
see, then watch `pending` — persistent pending capacity means your
ceiling is under the market or supply is short.

### What are the SLAs?

Base load capacity carries the published
[Base Load Capacity SLA](https://docs.nationalcompute.com/sla.md). Preemptible burst capacity has no
formal SLA; what the mechanism itself guarantees there: the protection
window on fresh grants, billing at the clearing rate and never above your
declared ceiling, and
[unrecorded gaps are never billed](https://docs.nationalcompute.com/billing.md#what-is-never-billed).
For other contractual availability or support commitments, contact us.

## Pay for what you use

### Are we only charged for compute that's running jobs?

You're charged for capacity you **hold**, metered at market-record
boundaries — see [Billing](https://docs.nationalcompute.com/billing.md). For Kubernetes clusters that
converges on "charged when running work, plus a five-minute tail"
automatically: nodes join only when a queued job pulls them and, once
the job ends, shed after a five-minute idle grace billed at that job's
rate unless another job takes the node — so the meter tracks the queue.
For VM clusters you pay for nodes while you hold them, working or idle
— holding is your choice, and lowering `max_gpus` stops the meter.

### If unused reserved capacity is pushed back into the pool, do we get paid even if nobody bids on it?

For burst capacity the situation can't arise: you never own capacity
you have to resell. Released capacity (or a Kubernetes node shed for
idleness) simply returns to the platform pool and **your billing stops
at that moment** — whether anyone else bids on it afterward is the
platform's problem, not yours. A [base load block](https://docs.nationalcompute.com/market.md#base-load-capacity)
is different by design: you pay the fixed rate for the block whether the
nodes are busy or idle, and there is no rebate for idle nodes in the
block — the fixed rate and the no-preemption guarantee are the trade.

## Pricing index

### How are prices set — is there an index?

Pricing here is not computed from an external index at all. Prices are
**set by the auction**: what you pay is determined by the demand
competing with yours, never above your own ceiling. The platform's
price index is its own
[market feed](https://docs.nationalcompute.com/api/market-feed.md) — the actual volume-weighted clearing
rates, published per tick and as a long-run series. Other providers'
list prices are not an input to the price.

### Does any external price feed the index?

No — see above. No external price feeds into what you pay.

### Is the strike price the minimum across available providers?

There is no strike price. Each tick's clearing outcome is set by
competing demand, capped by your own declared ceiling. The
[market feed](https://docs.nationalcompute.com/api/market-feed.md) publishes what actually clears.

## Pricing and auction mechanics

### What is the exact auction structure — generalized second price, VCG, something else?

A repeated sealed-bid **combinatorial auction**, roughly every 10
seconds. Winner determination maximizes total value across all demand
in whole-node units (multi-node groups are atomic — granted whole or
not at all). Payments are second-price in nature: a winner pays for the
demand it displaces — a VCG-style payment with a core adjustment — and
your own cluster's losing demand never sets your price. A bid too low
to ever clear the market is refused on write (`bid-too-low`); the
[price to win ladder](https://docs.nationalcompute.com/api/k8s-market.md) says what clears. Practical
consequences: bidding your true
ceiling is the safe strategy, you never pay above it, and prices are
per cluster rather than uniform — which is why the
[market feed](https://docs.nationalcompute.com/api/market-feed.md) publishes a volume-weighted mean with
a min/max spread rather than a single quote.

### My limit price seems reasonable — why is nothing clearing?

On Kubernetes, read the request's reason before guessing —
`kubectl describe job`, or the console's Workloads page
([queue events](https://docs.nationalcompute.com/api/k8s-bid.md#queue-events)): `Outbid` names the limit
price that wins right now, `BidTooLow` means the request's limit
price — the job's label if set, else the cluster's limit price — can
never clear the market as it stands (the market moved, or the label
undercuts the cluster's price), `BalanceTooLow`
means the org's balance cannot fund two hours of the request,
`PendingSupply` means
protected nodes hold the supply your gang needs. The
other causes are the mundane ones. When the site is genuinely out of
capacity, no bid clears it: the console's Workloads page shows
**capacity unavailable**, raising the limit price does not start the job
sooner, and the queue clears on its own when capacity returns
([when the site has no capacity](https://docs.nationalcompute.com/kubernetes.md#when-the-site-has-no-capacity)).
Market-wide, the [feed](https://docs.nationalcompute.com/api/market-feed.md)'s ticks show `null` when
nothing clears. The last mundane cause is no limit price set at all: no
bid means $0, which never clears.

### We already hold capacity — how do we flex up on short notice?

Raise `max_gpus` (VM) or submit more GPU jobs (Kubernetes). The new
demand competes at the next tick and grants land **in your existing
cluster**, next to what you already hold. Short notice is the norm
here: there's no procurement step, just the market clearing.

### How do we get money back for burst compute sitting idle over a weekend?

You don't get money back — you **stop spending**. Scale to zero (or
just down) on Friday and billing stops with the release; re-declare on
Monday and you re-enter the market at Monday's price. Two caveats to
weigh: released nodes are destroyed (anything on local disk is gone),
and re-entry is at market conditions, not a held price. Kubernetes
clusters do the weekend version automatically — an empty queue sheds
nodes after the idle grace. A [base load block](https://docs.nationalcompute.com/market.md#base-load-capacity)
bills through the weekend: its fixed rate covers the block for the whole
term, used or not.

### Is burst capacity won at auction guaranteed to land on the same cluster as our existing reservation?

Yes. Capacity is granted to the cluster that declared the demand — a
grant is never "somewhere else." A cluster trades in a single market
(its site), so growth lands beside what you hold.

### Isn't preemption disruptive? We can't instantly drain a node.

The mechanism gives you five layers before disruption, and visibility
when it comes:

1. **The protection window** — a fresh grant can't be preempted for
   its first hour (VM node) or first two hours (Kubernetes node), no
   matter what the market does.
2. **Your ceiling is the lever** — you are only reclaimed when the
   market clears *above your declared ceiling*. Work that must not be
   interrupted gets a ceiling above the going rate, which you can watch
   on the [market feed](https://docs.nationalcompute.com/api/market-feed.md).
3. **You pick the victims** — on scale-down, `release` nominations
   choose which nodes go first, and `planned_release` on every read
   shows exactly what a shrink would destroy before you commit it.
4. **Kubernetes requeues itself** — a reclaimed job is suspended with
   its whole gang and requeued as a new request at your current limit
   price; it resumes when granted again, and with the
   [retry-budget spec](https://docs.nationalcompute.com/kubernetes.md#when-the-market-reclaims-a-node)
   in place a reclaim never fails the Job.
5. **A faulty node is replaced** — if our health checks take one of
   your nodes out of service, billing for it stops, the market grants a
   replacement that inherits the remaining protection window, and the
   pods on the faulty node are evicted after a short grace so they
   reschedule. The node's tile reads **Node Fix In Progress** and the
   request shows **Replacement Pending** until the new node joins
   ([details](https://docs.nationalcompute.com/kubernetes.md#when-we-take-a-node-out-of-service)).

Beyond that, this is genuinely preemptible capacity and the honest
advice applies: checkpoint long-running work and keep durable state off
node-local disk.

## Access model

### How do I get an account?

Sign in at [nationalcompute.com](https://nationalcompute.com) with Google
or with an email address that receives a sign-in link. A `.edu`, `.mil` or
`.gov` address gets its own public research organization on the spot, with
$100 of credits to get started, which requests whole GPU nodes from Marshall
through [Public Research](https://docs.nationalcompute.com/public-research.md); an address an existing
organization's rules admit joins that organization;
anything else is placed on the waitlist and emailed when a spot opens —
early access for public users is available in waves
([Sign in and create an account](https://docs.nationalcompute.com/sign-in.md#the-waitlist)).

### Do we submit containers or jobs that you run, or do we get machines we operate ourselves?

You operate it yourself, in both models. A **Kubernetes tenancy** is a
dedicated cluster — you hold the kubeconfig and deploy your own
workloads; the platform only moves nodes in and out as the market
clears ([Kubernetes clusters](https://docs.nationalcompute.com/kubernetes.md)). A **VM tenancy** gives
you nodes over ssh with your registered keys installed
([VM capacity API](https://docs.nationalcompute.com/api/vm-capacity.md)). There is no "submit us a job
and we run it" surface.

### Are VM access and Kubernetes priced differently?

No — same market, same unit. VM and Kubernetes demand clear in the
same per-site auction, both priced in USD per GPU-hour against your
declared ceiling. What differs is the interface: VM capacity is
declared explicitly, Kubernetes demand derives from your jobs.

### How does the bare-metal offering compare to Kubernetes and VM access?

The Kubernetes offering **is** the bare-metal offering: cluster nodes
run the Kubernetes agent directly on the metal, with no hypervisor
layer, dedicated to your cluster while you hold them. The VM offering
runs virtual machines on the same class of GPU hosts and trades that
layer for ssh-level, operate-it-yourself access. Pick by how you want
to drive the hardware, not by price — both clear in the same market.

## Ancillary costs and storage

### Are there fees for logging, monitoring, or ingress/egress on Kubernetes jobs?

No. Billing today is GPU capacity only — the clearing rate for nodes
you hold ([Billing](https://docs.nationalcompute.com/billing.md)). Monitoring dashboards, metrics, and
logs come with the tenancy at no separate charge, and network traffic
is not currently metered or billed.

### How much storage does a Marshall workspace come with?

Two pieces, both included with the tenancy. Each member's workspace has
its own 50 GiB disk, mounted at `/data`: home directory, Marshall's notes,
uploads, anything you want to keep between restarts. An organization with
a workspace hub of its own also has a shared folder at `/org`, visible to
every member, capped at 200 GB. Over the cap, the folder stays readable
and members can delete to free space, but new writes fail until the
organization is back under it; writes return on their own a few minutes
later. Nothing is deleted by the platform. Public research organizations
are single-member and have no shared folder.

### Can you support multi-petabyte storage, and is storage priced off the same index?

Storage is per-site: where a shared filesystem is provisioned, your
capacity read's `environment` field carries the paths and onboarding
facts, and it is not priced off the market — GPU capacity is the only
market-priced resource today. For multi-petabyte requirements, talk to
us about the specific site — large storage is a provisioning
conversation, not a self-serve knob.