Where should each class of work run?
Enter what you spend and the shape of your workload. This models where each class of work belongs across supply you own, supply you rent inside your boundary, and supply that leaves it — then prices that mix. It is a planning model built from published defaults, not a measurement of your traffic.
▸ You can model where work belongs. You cannot model what it costs you today — that part is measured.
Where each class belongs
Distribution starts by naming the work. Every task class carries a quality floor a candidate supply must clear before cost gets a vote: the floor decides which supply is eligible, and among those, cost decides. That first step is the one a cost-only model has no term for.
▸ Supply is rated by class, never by vendor, and ordinally rather than by score: each supply class declares the highest task class it clears. Bowline itself reads numeric ratings from your registry — the ordinal ceiling is this page's planning simplification. Catalog rates as of 2026-07; they are checked-in defaults, not a live registry read.
The same placement, priced
The same placement, priced. Each row sets what the class costs on the assumed $0.05 blended rate below — our published default, not a measurement of your rate — against the cheapest supply that clears its floor — restricted to in-domain supply while the keep-in-domain control below is set. Deltas carry a weaker confidence label than the figures they are drawn from — a modeled difference is never firmer than its inputs.
- declared
- a number you entered above, a published default from this page's own catalog, or arithmetic on those. Declared by you or by us — never measured from your traffic.
- unverified
- a modeled difference between two of those numbers, or a claim nothing on this page has measured. Weaker by construction: a difference is never firmer than the figures it is drawn from.
Every figure below carries one of two confidence labels. On this page they mean:
| task class | tasks / mo | assumed current | cheapest clearing | delta |
|---|---|---|---|---|
| mechanical | 300,000declared | $15,000declared | $5,400declared | $9,600unverified |
| heavy-lifting | 350,000declared | $17,500declared | $6,300declared | $11,200unverified |
| taste-sensitive | 200,000declared | $10,000declared | $8,400declared | $1,600unverified |
| judgment | 150,000declared | $7,500declared | $6,300declared | $1,200unverified |
▸ Read the direction of that result with care. The assumed blended rate is set above every rate a cost-minimising placement can select, deliberately — so the mix always lands below the assumed current cost, at every input this page accepts, and it cannot show otherwise. The size of the gap, not its existence, is what a measurement would test. Not even the keep-in-domain control below changes that: it prices two of the four classes above the assumed rate, which you can read in their negative deltas, but on every archetype offered here the two lower classes save more than the two higher classes cost, so the total still lands below. This model has no setting that makes the total worse.
What stays in your domain
The share of your tasks that stay inside your security domain under this mix. This is the one axis on this page where the cheaper answer is not automatically the better one — so the premium is quoted rather than buried, and the placement above does not pay it.
▸ Read that number as a consequence of cost minimisation, not as a recommendation. Because frontier-grade capability inside your boundary ($0.055/task) is dearer than the same capability outside it ($0.042/task), the two highest classes leave your domain unless you say otherwise — at every input this page accepts. That is a cost decision standing in for a policy decision, so the control below hands it back: keep every class inside the boundary and see what it costs on your own volume. That 31% is measured per task on the work that moves; the control below also shows it as a share of your whole mix, which is smaller. This model will not make that call for you. It is the one choice here that can price individual classes above the assumed rate — though never, on the archetypes offered here, the total.
Cost alone is deciding: $26,400/mo, with the two highest classes outside your boundary. Keeping every class inside would cost $30,950/mo — a premium of $4,550/mo, or 17%.
Quality parity
A cheaper mix is only a better mix if quality holds — and nothing on this page has tested that. Parity is established by running your own cases against candidate supply, which is what canary evidence is for.
Assumptions & how these numbers are calculated
A planning model, not a quote. You edit the inputs above; everything else uses these defaults, which a scoping call refines with your own numbers.
- Assumed blended cost / task
- $0.05
- Node capex
- $250,000
- Useful life
- 3 years
- Continuous draw
- 5.5 kW
- Power price
- $0.12/kWh
- Space + ops / year
- $24,000
- Throughput
- 3,000 tasks/hr
Why $0.05 sits above every rate a cost-minimising placement can select: a running fleet does not pay a rate card. It pays for retries, for oversized models on trivial work, and for verbosity — none of which appear in a published per-task rate. Pinning the assumed current cost to the cheapest frontier rate would model a fleet nobody operates. The consequence is disclosed rather than buried: the modeled mix total always lands below the assumed current cost — the keep-in-domain option prices two individual classes above it, but never the total, because the two lower classes save more than the two higher classes cost on every archetype offered here. Replace this default with your own measured figure and the arithmetic holds; only the size of the gap moves.
- owned hardware · clears ≤ heavy-lifting
- $0.02152/task · amortized at 20%
- open weights in your VPC · clears ≤ heavy-lifting
- $0.018/task
- VPC frontier endpoint · clears ≤ judgment
- $0.055/task
- public API · clears ≤ judgment
- $0.042/task
The owned rate above divides annual owned cost by the 5,256,000 tasks/yr your utilization figure asserts. This plan places none of its work on owned supply, so that rate is a reference for comparison, not a cost inside the mix.
- mechanical
- 30%
- heavy-lifting
- 35%
- taste-sensitive
- 20%
- judgment
- 15%
- Tasks / mo = monthly spend ÷ $0.05 blended cost per task
- Tasks per class = tasks/mo × the archetype's share for that class
- Placement = the cheapest supply whose ceiling clears the class floor
- Owned $/task = (capex ÷ 3 yrs + 5.5 kW × 8760 × $0.12 + ops) ÷ (3,000/hr × 8760 × utilization)
- Current = tasks × blended cost per task
- Cheapest clearing = tasks × the placed supply's cost per task
- Delta = current − cheapest clearing
- Every task frontier-grade = tasks/mo × the cheapest supply clearing the judgment floor
- Sovereignty ratio = tasks placed on in-domain supply ÷ tasks/mo
What this page cannot tell you.
Every cell above reads declared or unverified. Two labels never appear: observed and canary-verified. No calculator can produce them — the first comes from a recorded run, the second from matching canary evidence against your own cases. That is the difference between modeling a mix and measuring one.
Apache-2.0 · shadow-first · back to Bowline →