Own the capacity and understand the economics
Agentic engineering requires more than tokens. With the right workload mix, a one-off investment in customer-owned compute can replace much of the recurring execution-compute cost of hosted services. We can design and commission the complete system on your hardware, in the cloud, or both.
The economics depend on utilisation, workload mix, performance needs and operating costs. Here's how to evaluate them.
Fit guidance
Start with the direction of the decision
| Situation | Direction to assess | Main condition |
|---|---|---|
| Sustained suitable work and operating capacity | Existing or owned compute | Measured utilisation and operating overhead justify ownership |
| Bursty or uncertain demand | Cloud or hosted capacity | Elasticity and reduced hardware operations outweigh unit-cost differences |
| Existing hardware plus occasional peaks | Hybrid | Integration and burst handling are justified by the measured mix |
| Strict data or location requirements | Customer-controlled placement, with explicit provider boundaries | Model access, telemetry and other external dependencies also satisfy the requirement |
Whichever direction fits, the dominant benefit is the same: useful engineering work and attention recovered. Quantifying it for your organisation requires measurement — the method at the end of this page explains how a pilot does that.
Capability phases
Two capability phases, one shared execution foundation
Phase 1 establishes the execution infrastructure, durable workflows and verification. Phase 2, if added, uses that foundation and introduces event integrations, context processing, planning workflows and ongoing connection operations. Upstream tasks are often lighter than coding or build workers, but their model inference, connectors, storage, security and operational support still have costs — we size and price the extension against actual event volumes and required response times. Phase 1 stands on its own; there is no implicit phase-2 bill.
The business case
The case has two separate parts
Value of engineering capability
Additional useful work completed, less human supervision on suitable workflows, shorter queues, greater continuity, reduced integration friction and better ability to address backlog. This is usually the dominant benefit — but it can't be assumed or quantified without customer-specific data.
Cost of operating the capability
Execution compute, inference, integration and operations, hardware depreciation, electricity, storage, networking and support. That is what this page models — transparently.
The delivery-value conversation starts at the business overview.
The two bills
Inference and execution are different cost centres
Model inference
LLM token or subscription charges — billed by the model provider, independent of where your workers run.
Execution infrastructure
CPU, memory, storage, network, electricity and the environments used for builds, tests, documents and research.
Running tasks consume compute even when inference comes from an external API — and local execution environments do not imply free LLM inference.
CAPEX versus OPEX
Buy execution capacity once; use it continuously
Owned
One-time hardware CAPEX — which can be small with refurbished servers — plus electricity and ongoing operations.
Hosted / managed
Little or no customer server CAPEX, but repeated charges for active compute minutes, provisioned capacity and potentially service fees.
Hybrid is a genuine option, not an afterthought: baseline loads on owned hardware, peaks in hosted capacity. For sustained loads the shift is from a variable per-minute bill toward owned, reusable capacity. These comparisons describe execution compute — not whole-of-factory cost unless every overhead is included.
Workload-aware sizing
Not every worker needs the same machine
The right answer depends on workload shape, existing assets and operational capacity — we recommend after assessing, not before.
Active workers claim resources; queued work waits. Resource requirements depend on the real task — the profile is set by the work, not by whether an LLM participates.
Measure representative builds and full verification runs: build and test intensity determine CPU, peak memory, storage and I/O needs. Work volume and job duration shape concurrent demand and queue times. Benchmark that mix under contention, with headroom for test services, the platform, bursts and recovery. Remeasure after adding tests or changing environments.
These profiles describe execution compute. Model inference has separate costs and limits; running models locally needs its own accelerator and memory assessment. Validate readiness for the intended workflow and use measured demand before recommending capacity.
Plan your readiness and profiling journey.
Heavyweight: coding/build worker
Example: 16 GB / ~1 CPU core-equivalent
Code changes, builds, tests, browser UAT, dependency installation.
Lightweight: reasoning worker
Example: 2 GB / ~0.25 CPU core
Research, documentation, planning, review text, issue triage, specification drafting.
Illustrative host capacity
256 GB / 32 cores
15 coding workers maximum (RAM-limited)
124 lightweight workers maximum (CPU-limited)
Example mixed placement: 10 coding + 24 lightweight = 34 simultaneous scheduler placements under the stated budgets
384 GB / 32 cores
23 coding workers maximum (RAM-limited)
124 lightweight workers maximum (CPU-limited)
Example mixed placement: 14 coding + 56 lightweight = 70 simultaneous scheduler placements under the stated budgets
384 GB / 16 cores
15 coding workers maximum (CPU-limited)
60 lightweight workers maximum (CPU-limited)
Example mixed placement: 8 coding + 16 lightweight = 24 simultaneous scheduler placements under the stated budgets
- Budgets reserve 6 GB RAM and 1 CPU core-equivalent for the OS, orchestration and operational headroom; no CPU oversubscription in the conservative allocation.
- These are simultaneous scheduler placements, not measured production capacity — and mixed placements are not concurrent full-scale code builds: only 10 or 14 of those slots are coding workers in the illustrated mixes.
- Larger builds and tests may need additional CPU bursts, and many concurrent lightweight workers compete for network and remote model quotas.
Not just servers
Existing laptops, desktops and rack servers may contribute useful execution capacity. The profiles above are illustrative allocations; available RAM after system reserves, CPU performance, storage and measured build and test demand determine what fits. Check each machine and the combined workload before assigning concurrent workers.
Real-world refurbished server prices
Small one-offs are genuinely available
Advertised prices viewed 2 November 2026 in Australia — illustrative, not procurement quotations; refresh availability before launch. Prices may exclude freight, service, power, SSD upgrades, cooling and other costs.
Dell R630, dual E5-2698 v3
256 GB RAM · 32 physical cores
A$2,699
RecomputeIncludes 2 × 960 GB SSD; older processor generation. Listing has inconsistent stock messaging: verify availability directly.
Cisco C240 M5SX, dual Xeon Gold 6130
384 GB RAM · 32 physical cores
A$3,300
Australian Computer TradersIncludes SAS drives; SSD capacity/performance may need upgrading.
Treat these as examples of the price band — not recommendations without a fit-for-purpose assessment.
You don't necessarily need the largest server. What matters is the measured work: suitable machines contribute capacity within the design's resource limits, network boundaries and provider quotas, and each worker must fit a machine it can actually run on.
A one-off purchase versus recurring hosted minutes
One clear scenario, assumptions included
The 256 GB Dell example, mixed workload. An illustration — not a parity benchmark of complete agent platforms.
Context, not a payback claim: the purchase price happens to equal roughly 2.6 months of the hosted runner reference below at this utilisation. Hardware performance, supported execution duration, service levels, included allowances, operational labour, actual demand and the runtime model differ.
The cited GitHub runners are CI machines — a CI runner service, not an end-to-end managed software factory. ubuntu-slim has a 15-minute job limit and runs in constrained containers, so it may be unsuitable for long-lived research agents. Comparing published compute-minute pricing is not a like-for-like performance benchmark.
One-time CAPEX
A$2,699 one-off
Dell R630, dual E5-2698 v3, 256 GB / 32 cores, advertised at Recompute.
Direct recurring (illustrative)
- Electricity: A$86.40/month at 400 W average (unmeasured) and A$0.30/kWh
- Maintenance / spares allowance: A$50/month, excluding full operating labour
- Direct recurring total: A$136.40/month, plus omitted operational costs
- Amortised acquisition: A$74.97/month over a 36-month book life
- Illustrative carrying amount: A$211.37/month before staff and other exclusions
Mixed placement and active work
- Placement: 10 coding + 24 lightweight worker slots
- Uses 208 GB and 16 core-equivalents, within 250 GB / 31 cores available after reserves
- Occupancy: 10% of each class across a 30-day month
- Active coding minutes: 43,200
- Active lightweight minutes: 103,680
- Total active worker-minutes: 146,880
- Blended self-hosted carrying cost: A$0.00144 per active worker-minute
Hosted published-rate reference
- Coding reference: GitHub Actions 4-vCPU / 16-GB Linux runner, US$0.012/min
- Lightweight reference: GitHub Actions ubuntu-slim 1-vCPU / 5-GB runner, US$0.002/min
- Indicative hosted spend: US$725.76 ≈ A$1,032.03 at the assumed US$1 = A$1.422 display conversion
Sensitivity and choice
Utilisation decides how the numbers fall
| Utilisation | Active worker-min / month | Carrying cost / active min | Hosted reference / month (AUD) |
|---|---|---|---|
| 5% | 73,440 | A$0.00288 | A$516.02 |
| 10% | 146,880 | A$0.00144 | A$1,032.03 |
| 25% | 367,200 | A$0.00058 | A$2,580.08 |
Greater utilisation amortises owned capacity across more active minutes.
When cloud makes better sense
- Bursty workloads or low, uncertain utilisation
- High availability requirements
- Need for more modern compute performance
- No local operational staff or facilities
And the middle paths
- Existing assets already on site, upgraded where needed
- Hybrid: baseline on-prem, overflow in hosted capacity
Assumptions and method
What stands behind every figure on this page
One small model produces the figures: dated acquisition prices, direct recurring assumptions, amortisation over a fixed book life, utilisation and worker mix — each shown beside the number it produces. The model and its tests live in this site's repository, so the arithmetic can be checked end to end. Prices and the display FX rate are dated; they are worth a refresh before any procurement decision.
Exclusions
- cloud discounts and plan-included minutes
- taxes / GST treatment
- storage
- networking
- rack / UPS
- cooling
- downtime and hardware replacement
- set-up labour and supervision
- model inference and AI subscriptions
- substantial platform operations
CPU performance on older Xeon processors can be materially slower than hosted alternatives, so it's worth comparing a customer-owned server slot against a hosted runner with real measurements rather than assumptions.
Measure the outcome that matters
A pilot is how the numbers on this page get replaced with your numbers. Before comparing approaches, agree the acceptance definition and the task mix — then measure, per accepted task or change:
- Completion time against the agreed acceptance criteria
- Failure and retry rate, including where checks blocked promotion
- Review and rework effort on the human side
- Model inference usage, by tokens or subscription draw
- Full execution cost: power, hosting or depreciation, storage and network
This page publishes a method, not benchmark results — measured figures belong to a customer's own pilot.
Next step