Use-Cases
01
SELECT YOUR SECTOR
Choose an industry sector or GBS function
Choose an industry sector to load the top 15 pre-configured AI use cases. All fields are fully editable to match your organisation's workload.
Use-Cases
02
AGENT ARCHETYPES
Six agentic patterns, their characteristics and their token amplification factors
Every workload resolves to one of six patterns. The pattern determines how many model calls a single user request actually makes, how much context is re-sent between agents, and how much reasoning is generated but never shown.
That is what token amplification measures. It has two parts, because they behave differently: input amplification covers context re-sent to every agent in a fan-out, and output amplification covers planning, verification and hidden chain-of-thought.
Calibrate before you size
The factors below are calibrated estimates, not measured traces. The ordering is defensible; the values are not validated.
If you have measured token traces, replace them. Every use case, cost and fleet figure downstream recalculates from these numbers.
Pattern Topology
How agents, sub-agents, orchestrators and MCP tools are wired in the selected archetype
Token Amplification by Complexity
Every workload in this sector plotted against the factors above — updates when you apply changes
Use-Cases
03
USE CASE VOLUMES
Set interaction volumes and token counts per use case
Edit use case names, daily agentic interaction volumes, and average token counts per interaction. Click Estimate tokens → on any row to open the token estimator and calculate avg input / output tokens from 5 interaction parameters.
—
All fields editable · Click "Estimate tokens" to auto-calculate input & output tokens| Use Case | Agentic Interactions /Day ? |
Avg Input Tokens /Interaction ? |
Avg Output Tokens /Interaction ? |
Architecture Archetype ? |
Token Amplification Factor ? |
Est. Total Tokens /Day ? |
|---|---|---|---|---|---|---|
| TOTAL (ALL USE CASES) | — | — | — | |||
Workload Intelligence
04
TOKEN INTENSITY MAP
Quantify AI consumption and inference intensity
Every use case is scored across five parameters that drive token consumption, each mirroring an input from the token estimator. Use the checkboxes to include or exclude workloads from all downstream calculations.
—
High
Medium
Low
| In | Use Case | Agent Action |
Data & Context |
Workflow Hops |
Thinking Depth |
Output Volume |
Est. Total Tokens/Day |
Overall Token Intensity |
|---|
01
Intensity describes one call. Volume decides the bill.
Tokens per day = interactions × tokens per call × amplification. Intensity scores the middle term only.
02
Same bill, opposite structure.
A large number of trivial calls and a handful of expensive ones can cost identically today — and need opposite engineering.
03
Intensity is the price of growth.
Total tokens is today's bill. Intensity is what the next thousand users cost. A High-intensity workload that is small today is not small — it simply has not scaled yet.
Reading the Heat Map
How each score is calculated and what the thresholds mean
Intensity Levels
High score > 1.25
Will dominate your token bill
Medium 0.65 – 1.25
Significant at scale, manageable alone
Low score < 0.65
Light per call — watch daily volume
Factor Thresholds
⚡
Agent Action
≤6K · >6K · >18K total
📦
Data & Context
≤4K · >4K · >15K input
🔗
Workflow Hops
single · chain · in>10K + out>2K
🧠
Thinking Depth
≤1.2K · >1.2K · >4K output
📤
Output Volume
≤800 · >800 · >3K output
Scoring Formula
Agent Action0.25
Data & Context0.25
Workflow Hops0.20
Thinking Depth0.20
Output Volume0.10
Each factor scores 0 / 1 / 2. Token values take priority over name keywords.
Multi-Agent Flag
1Workflow hops score High
OR
2Action + Thinking both High
OR
3Orchestration keywords + hops ≥ Med
Needs more than one model — a fast classifier plus a deep reasoner. Prime candidate for a model router.
Volume versus Cost per Call
Where each workload's consumption comes from — and what happens to it as adoption grows
Tokens per call
cost of a single interaction
High
Low
Low
High
Interactions per day
how often the workload runs
Architect’s Considerations
What this portfolio tells you, and what to do about it
Workload Intelligence
05
WORKLOAD PLACEMENT FRAMEWORK
Determine Cloud / On-Prem / Hybrid fit
Set demand and control for each workload below — both default to the value derived from your token profile and the workload's characteristics. The matrix updates live.
Use Case
Tokens/day
Demand ?
Control ?
Affinity
Agentic AI Workload Placement Matrix
Given workload demand and required control & locality — where should this workload run?
Control & Locality
Data sensitivity · Sovereignty · Latency · Enterprise control
High
Medium
Low
Low
Medium
High
Workload Demand
Total tokens per day · interaction volume · sustained throughput
Deployment Affinity
Cloud APILow control needs, variable demand — pay-per-use wins
HybridSplit workload — route sensitive or steady traffic on-prem, burst to cloud
Private AI FactoryHigh control + sustained demand — dedicated on-prem inference
Bubble Size = Token Intensity
Low
Medium
High
Bubble size reflects per-interaction token intensity from the heat map above. Larger bubbles consume more tokens per call — these carry the strongest on-prem economics at scale.
Purple ringMulti-agent workflow — needs a model router
How Axes Are Scored
Workload Demand (X)
Derived from total tokens/day: Low <10M · Medium 10M–100M · High >100M
Derived from total tokens/day: Low <10M · Medium 10M–100M · High >100M
Control & Locality (Y)
Composite of four signals detected per use case: regulated data, PII / customer data, real-time latency dependency, and proprietary IP exposure.
Composite of four signals detected per use case: regulated data, PII / customer data, real-time latency dependency, and proprietary IP exposure.
Overriding a placement
Both axes can be set per use case in the Demand and Control columns of the heat map above. The small dot under a letter marks the value the tool auto-detected. Bubbles you have moved manually carry a dashed outline.
Both axes can be set per use case in the Demand and Control columns of the heat map above. The small dot under a letter marks the value the tool auto-detected. Bubbles you have moved manually carry a dashed outline.
This is an initial architecture decision framework, not an absolute rule. Placement here indicates deployment affinity based on demand and control characteristics. Validate every placement against the TCO analysis in Step 6 and formal infrastructure sizing before committing to an architecture.
Workload Intelligence
06
ADOPTION ROADMAP
Stagger use case onboarding and derive platform utilisation
Use cases rarely go live at once. Stagger onboarding across your investment horizon and see how GPU demand actually ramps — each workload contributes tokens only from its go-live month onward.
Business volume growth
?
15%
per year, compounding
Apply a pattern
Onboarding Schedule
Set the go-live month for each use case — drag the slider or type a month number
Use Case
Tokens/day
Go-Live Month
Month
Becomes
?
Token Volume Over Time
What the organisation will actually consume under this onboarding plan — updates as you move the sliders
Total Token Estimate
What this portfolio consumes across the horizon, and where the consumption comes from
Why this matters for sizing. A cluster provisioned for full portfolio volume sits largely idle in Year 1 if only a third of use cases are live. The roadmap feeds the recommendation in Step 7 — peak demand determines the tier, but the ramp determines when that capacity is actually needed and how long you pay for headroom before using it.
TCO & Recommendations
07
TOKEN PRICING
Set model rates and enterprise committed-use discount
Select a benchmark model to set both input and output rates together, or enter custom values. Apply your enterprise discount below for a fair comparison.
Select Benchmark Model
Choosing a model sets input and output rates together
No model selected — using custom rates
Select a model to see its rates, tier and pricing notes.
Rates for 26 current models across Anthropic, OpenAI, Google and Mistral, last verified 30 September 2026 against provider pricing pages. Rates change frequently — verify against your provider's current price sheet before use in a formal proposal.
📥
Input Token Cost
Range: $0.10 (GPT-6 Luna / Ministral 3 3B) → $10.00 (GPT-6 Astra / Claude Fable 5.1)
📤
Output Token Cost
Output runs 3–6× input on most models; Mistral’s Ministral tiers are symmetric
Token Usage Cost Preview — Based on Current Volumes
Enterprise / Committed-Use Cloud Discount
?
0%10%20%30%40%50%60%70%
0%
Effective input: —
Effective output: —
⚠️ Why this matters for the TCO conclusion
The default comparison uses published list prices — the same rates a startup pays for their first API call. Enterprises operating at the token volumes that justify a $480K–$2M GPU cluster have invariably negotiated committed-use discounts. At 50% off list price, a scenario that shows on-prem saving $1.2M over 3 years often inverts to cloud being $800K cheaper. Always obtain your cloud account team's enterprise rate before drawing a final conclusion.
Monthly Cloud Infra & Connectivity Cost ($)
?
Includes: compute instances · private networking · VPCs · load balancers · storage · data egress
Total Monthly Cost
(Tokens + Infra)
(Tokens + Infra)
—
Total Annual Cost
(Tokens + Infra)
(Tokens + Infra)
—
TCO & Recommendations
08
BREAKEVEN WINDOW
Investment horizon, deployment ramp and Year 1 utilisation
Define the investment horizon for comparing cloud vs. on-premises economics.
Investment Horizon
1 Year
2 Years
3 Years
4 Years
5 Years
Selected: 3 Years (36 months)
Deployment Realism Adjustments
Deployment Ramp-Up Period
?
Both cloud and on-prem costs accumulate for 6 months before any workloads migrate.
Year 1 Platform Utilisation
?
Volume above Year 1 capacity continues to cloud at effective API rates — adding to on-prem cost.
Year 2+ Utilisation (steady state)
Steady-state utilisation assumption once platform is fully adopted. Default 70% follows standard GPU cluster benchmarking.
⚠️ Why standard breakeven calculations tend to be optimistic
Most TCO analyses assume the on-prem system handles 100% of workloads from day one. In practice: hardware procurement takes 3–6 months, installation and security certification add another 2–4 months, and Year 1 utilisation rarely exceeds 30–40% as use cases onboard. A scenario that looks like breakeven at month 18 often realistically breaks even at month 28–34 — sometimes beyond a 3-year window entirely, which can reverse the recommendation.
The chart on the next page shows the adjusted breakeven curve accounting for your ramp-up period and Year 1 utilisation. The shaded zone marks the ramp period where both cost streams run simultaneously with no on-prem production.
Token Volume Summary
Selected Sector—
Total Interactions / Day—
Total Tokens / Day—
Total Tokens / Month—
Input Token Share—
Output Token Share—
Cloud Economics Over Window
Input Rate—
Output Rate—
Monthly Cloud Cost—
Total Cloud Cost (window)—
Investment Horizon—
TCO & Recommendations
09
RECOMMENDATION & ANALYSIS
Cloud versus rented GPU versus on-premises
📋 Model Assumptions
Rented GPU Option
Capacity economics without the capital commitment — sized from your workload profile
Breakeven Analysis — Cumulative Cost Over Time
On-Prem
Cloud API
TCO & Recommendations
10
HYBRID STRATEGY
Routed hybrid architecture and workload split
Your workload portfolio split by placement affinity — and what a routed hybrid architecture costs versus committing fully to cloud or fully to on-premises.
Three-Way TCO Comparison
Full cloud · Full on-premises · Routed hybrid — over your selected investment horizon
Breakeven Analysis — Cumulative Cost by Architecture
Full Cloud
Full On-Prem
Routed Hybrid
Workload Split & Routing Plan
Where each use case runs, and why
Why Hybrid Beats Either Extreme
The structural cost advantages of routing rather than committing
Size for the baseline, not the peak
Full on-prem must provision for peak demand, leaving expensive GPUs idle most of the month. Hybrid sizes the cluster to steady-state load and bursts overflow to cloud — you stop paying for capacity you use a few hours a week.
—
Sovereignty without over-buying
Only workloads that genuinely require data residency or latency control need to sit on-prem. Routing the rest to cloud means the CapEx covers the regulated subset, not the entire portfolio — a materially smaller cluster.
—
Frontier capability stays available
On-prem runs open-weight models. Full commitment locks you out of frontier model capability for the cases that need it. Hybrid keeps a cloud endpoint open for complex reasoning while high-volume routine work runs on owned hardware.
—
Shorter payback, lower downside
A smaller cluster means less CapEx at risk and faster breakeven. If volumes grow slower than forecast, the exposure is a fraction of a full build-out — and the cloud endpoint absorbs the difference without stranded hardware.
—
What this requires architecturally
1
A model router / AI gateway sitting in front of both endpoints, routing by use case, data classification, and current load. This is the single most important design decision — retrofitting it later is expensive.
2
A shared observability layer so token spend, latency and quality are measured consistently across both endpoints. Without it you cannot tell whether routing decisions are working.
3
Data classification at ingest — the router needs to know whether a payload is regulated before it decides where to send it. This usually means tagging at the source system, not at the gateway.
4
Prompt and evaluation parity across models. The same workflow may hit an open-weight model on-prem and a frontier model in cloud; output quality must be validated for both paths.
Directional, as with the rest of this tool. The hybrid figure assumes clean routing with no duplicated infrastructure and excludes the cost of the gateway layer itself, which typically adds 3–8% to total run cost. Treat the split as an architecture starting point and validate the sizing with infrastructure specialists.
Model Selection & Optimization
11
MODEL SELECTION
Which model and hardware combination should run each workload
Which model and hardware combination should run each workload?
Characterise each workload across nine execution dimensions, then get a primary and alternate model recommendation. Values marked auto are derived from the token estimate, placement and the archetype assigned in Section B — override any of them.
This section is in beta. Scoring runs locally in this tool — it is not connected to InferenceX or any live benchmark service. Cloud model pricing is current, but the open-weight model entries, their capability tiers and GPU mappings are estimates. Treat the shortlist as a starting point for evaluation, and validate throughput and hardware sizing against measured benchmarks before committing to a model or a cluster.
1
Model Vendor Constraints
Switch a vendor off to remove its models from consideration — open weights for on-premises, hosted models for cloud
On-premises · open weights
Cloud API · hosted models
2
Workload Scope
Filter by deployment placement from Section 02
3
Per-Workload Recommendation
Expand a workload to review its archetype, execution profile and model shortlist
How these recommendations are produced. Scoring runs locally in this tool using the same logic InferenceX applies — matching workload characteristics against model capability, context limits, latency profile and cost per token. It is a directional shortlist, not a benchmark result. Validate the shortlisted models against live throughput data on InferenceX before committing to hardware.
Model Selection & Optimization
12
INFERENCE OPTIMIZATION
Token amplification and NVIDIA inference optimisation levers
This section is in beta. Token amplification factors are calibrated estimates rather than measured traces, and the NVIDIA optimisation multipliers are derived from published vendor claims — not from benchmarks run on your workloads. Use the output to size the opportunity and decide whether a proof of concept is worth running. Do not carry these figures into a business case without validating them against measured throughput on representative traffic.
1
Portfolio Token Summary
Total consumption across every workload in scope
Token share by archetype
Tokens per day — baseline versus archetype-amplified
2
NVIDIA Inference Optimisation
Five levers across the NVIDIA inference stack — toggle each to see its effect
Switch the lens on to compare your baseline on-premises cost against the same architecture with NVIDIA optimisation levers applied. Savings appear here at portfolio level and per workload in Section 4.
3
Workload Detail
Characteristics and NIM savings for a single workload