Pricing posture

This page sets out our pricing principles: methodology, never a price list - no currency figures, no projected uplift, no percentages framed as pricing. The three pillars are ROI and payback methodology, the cloud-versus-in-network comparison, and GPU-sizing guidance for your private infrastructure.

Diagram of a measured decision scale weighing evidence before any capital commits

The three methods

Each of the three tables below carries methodology only. The numerics are sizing ranges, multipliers, confidence bands, and payback cadences - the dimension each gate or decision is measured against, never a price. Read each table in the order it appears: first the ROI and payback methodology every phased commitment is gated against; then the cloud-versus-in-network comparison the residency posture forces; last the GPU-sizing guidance the in-network footprint installs.

How the cost model works

You invest in two things: hardware you buy once and own, and a delivery billed in gated phases. A phase opens only when the one before it produced working evidence. There are no per-token charges and no per-seat subscriptions for the system we build - extra usage is return on what you own, not a bigger invoice. This is the model we recommend - and if your organization needs cloud models for some workloads, the same stack runs them, with every call visible in one place.

If you want reference points on cloud pricing versus owned hardware, the Insights article on capacity and control lays out the published third-party numbers with their as-of dates.

Owned capacity steps up once at purchase and holds flat through the gated delivery, while metered usage resets every billing period and climbs again as usage grows.

ROI and payback methodology

Four method dimensions - every phased gate measured against the Assessment baseline.

Gate dimension	What it measures	How it is taken against the Assessment baseline
Expected return	A phased artifact's measured return multiplier - throughput, cycle-time, or avoided-cost gain - set against the unit Assessment documented before any code was written.	Phase artifact measured against the 1.0× baseline Assessment set; capital re-commits only when the artifact clears the gate's projected band.
Confidence range	Low-to-high band reported around the expected-return multiple, forced wider at gates far from production and tightened as in-network evidence accumulates.	Opening band of 0.40 to 0.60 at the first gated phase; narrowed gate-to-gate as the validated prototype supplants planning assumption.
Go/No-Go gate	Phase-boundary decision rendered against the artifact each phase produces - advance, rescope, or retire - never an open-ended workstream.	Gate opens only when the artifact's measured return clears its band; a phase that misses its gate is retired, not absorbed into a later quarter.
Re-pricing cadence	Every active commitment re-measured against the live Assessment baseline on the delivery's report rhythm, so drift resets the economics before the next phase ships.	Triggered on baseline drift of 0.10× or more since the prior report, and at every phase boundary regardless of drift.

Cloud versus in-network infrastructure

Five dimensions a buyer weighs - control, residency, latency, throughput, operations.

Dimension	Generic cloud-tenant	In-network infrastructure
Control posture	Shared-responsibility boundary - the provider patches and deprecates features and interfaces on its cadence.	Operator-owned boundary - the delivery installs, patches, and retires features and interfaces inside the customer network.
Data residency	Request and response path traverses the provider's region edge by default.	Request and response path held inside the customer-chosen jurisdiction; no inference call leaves your network.
Round-trip latency	WAN hop measured in the tens to low hundreds of milliseconds against the provider region.	LAN hop measured in single-digit milliseconds against the in-network inferencer.
Throughput ceiling	Capped by tenant quota and degraded by noisy neighbours sharing the provider fleet.	Sized to the delivery's validated concurrency; no neighbour contention inside the customer's footprint.
Operational telemetry	Vendor-managed upgrades and opaque telemetry streams emitted back to the provider.	Operator-managed upgrades and telemetry held inside your network; no signal leaves the customer's footprint.

GPU-sizing guidance

Three governing inputs - model class, concurrent load, max context - mapped to hardware stack.

Model class	Concurrency	Max context	Suggested hardware stack
Retrieval and embedding	Up to 256 parallel queries	32K tokens	Single in-network accelerator; shard to two accelerators for cross-region redundancy.
30B to 100B models	5 to 10 parallel requests	256K tokens	Single in-network accelerator; shard to two accelerators for increased concurrency and availability.
100B to 200B models	10 to 20 parallel requests	512K tokens	Two in-network accelerators with batched inference; shard to three accelerators for increased quality of service.
200B to 500B models	20 to 100 parallel requests	1M tokens	Multi-accelerator pool, tensor-parallel sharded across four to eight accelerators.
Custom fine-tuned	Sized per the validated Building and Validation prototype	Sized to the project's own parameters	Sized only after the Building and Validation gate clears; never guessed from a sizing table.

Sizing ranges validated on our RTX Pro class bench in our GPU lab. Building and Validation GPU Lab

Take it forward

Every number on this page has a source. The gates above are set by a roadmap, and the sizing ranges are proven on real hardware. See both stages below, or book a meeting to talk it through.