"Move all agents onto a single host to save infrastructure cost" — the numbers
"Move all agents onto a single host to save infrastructure cost" — the numbers
Short answer: consolidating agents saves ~A$0/month, because the agents are not what costs money. Measured this morning, every figure below probed, not estimated.
1. The three hosts, and which ones bill
| Host | Machine | Monthly cost | What it exists for |
|---|---|---|---|
| LAB | HP EliteBook 6 G1i (owned laptop) | $0 — sunk | Brain agents, dev, vault |
| Pulse laptop | 192.168.4.34 (owned, Tam's) | $0 — sunk | Pulse agents, Kanban |
| prod | Oracle ARM A1.Flex 4 OCPU/24G | the only billed node | docs.youngle.au + pulse.youngle.au (public sites) |
Two of three hosts cost nothing to run. They are owned hardware — moving agents off them saves nothing, because there is no bill to reduce.
2. The agents themselves cost almost nothing
| Component | Measured footprint |
|---|---|
prod Heart worker (v3-heart-prod) | 16.8 MB RAM, 1 task, CPU 3h38m over 4 days (≈1.9% of one core) |
| LAB Hermes gateway (3 agents: min/mira/sol) | 686 MB for the whole gateway |
| prod free RAM right now | 21 GB of 23 GB |
| LAB free RAM right now | 25 GB of 30 GB |
| Load average | LAB 0.00, prod 0.04 |
Both hosts are idle. The agents use ~16 MB each. Consolidating them onto one host relocates a rounding error.
3. Why prod cannot be retired by moving agents
prod's real job is the public websites, not the agents:
solos-docs.service → docs.youngle.au (8091) active
pulse-site.service → pulse.youngle.au (8092) active
v3-heart-prod → 16.8 MB, the only agent there
Move every agent off prod and prod still has to run, because it serves the two public sites. The infrastructure cost does not change by one cent.
4. What consolidation would actually cost us
| Cost | Why it matters |
|---|---|
| Lose the portability proof | "Heart can run on any host" is now demonstrated (prod has run one 4 days). Collapsing to one host turns a proven property back into an untested claim. |
| Single point of failure | One host down = whole fleet down, including the public sites. Today an agent host failure is survivable. |
| Weaken the E5 key boundary | The boundary works because each host's executor refuses provider keys (UnsetEnvironment). One host holding every agent's credentials is a bigger blast radius — and prod already stores Console creds. |
| Against Sol's design | agents-anywhere-design.md is built on "one process per host, registry-issued packs, move A→B by re-registering". Consolidation contradicts the architecture Sol just verified. |
5. Where the money actually is (my lane — the real lever)
The infrastructure is not the cost centre. Measured:
| Line | Amount | Note |
|---|---|---|
| Oracle ARM node | ? — Young's billing check | Always Free covers 2 OCPU/12G; we run 4/24 → excess billable |
| Model spend | $22.38 lifetime | qwen3.8-flash $11.37 + deepseek-v4-flash $7.57 = 85% of all spend on two models |
| Per-tenant stack (future) | A$6.87–9.42/tenant/mo | the commerce plan's variable cost |
The saving worth chasing is the $11.37 on qwen3.8-flash, not a 16 MB agent process. Free models did 8.8× the tokens at $0.00 in the same period — that is a real number with a real lever, and it is already my lane's work.
6. What I would recommend instead
- Leave the topology as-is. It is already the cheap shape: owned hardware for agents, one billed node for public services.
- Close the A2A gap (Sol/Tam, in flight) — that is the actual blocker Young named, and it is a wiring defect, not a cost problem.
- Confirm the Oracle burn (Young's console check) — that is the only infra number that can move, and it is still open.
- Attack model spend — the free-first ladder and cache ratio (91.8% today) are where the money is.
Honest limits
- I did not measure the Pulse laptop's specs (it is not reachable for a shell from here — ping only). Its cost is $0 as owned hardware either way.
- Oracle billing remains unconfirmed — my two-row infra table still collapses to one row when Young's number lands.
- "Save infrastructure cost" may mean something I have not measured (e.g. retiring prod entirely and hosting the sites elsewhere). If so, that is a different question and I would need to price the alternative.
SolOS V3 — host topology and roles (authoritative)
Young, 2026-10-16:
Prod capacity under Young's new stated load (2026-10-17)
Young, 2026-10-17: prod hosts 2 live websites + e-commerce tenants (Mercury V2 + POS + EVE) + Hermes agents + EVE. That is a heavier prod than my earlier numbers assumed, so I re-ran the capacity maths. All figures measured or from Tam's live-measured tenant sizing — nothing estimated.

