Optimize your costs

How cost is calculated

From backend/app/services/billing_calculator.py: every running VS accrues cost using exact decimal arithmetic.

total_cost = cost_per_hour × elapsed_hours_running

• Per-hour rate is set per VS in the cost_per_hour column (default 0.10). Larger VSs cost more per hour.
• You only pay while status = running. A stopped VS accrues no compute cost.
• Math is decimal, not float. What the UI shows is what the invoice shows.

The baseline: 70% cheaper than hyperscale cloud

Zyra's headline positioning is roughly $0.08–$0.10 per device-hour for general-purpose compute, against $0.30+ for an equivalent instance on AWS/GCP/Azure. The savings come from running on a distributed mesh of Compute Nodes instead of dedicated hyperscale racks. You don't have to do anything to access that baseline.

[VERIFY: confirm final published $/hour bracket for MVP1 GA pricing page — billing_calculator default of 0.10 is the code default, not necessarily the customer-facing list price]

Lever 1 — Right-size before you scale

The most common cause of overspend is "I picked a size on day one and never revisited it." Open Monitoring → Metrics on every VS, switch to the 7d window, and ask:

• CPU max never exceeds 40%? Drop vcpus by half.
• Memory ceiling never above 60% of memory_mb? Drop the cap by 25%.
• Disk usage flat at 15GB on a 100GB cap? Trim the disk on next deploy.

Right-sizing is the single biggest lever. A VS sized 2× too large costs 2× too much, forever.

Lever 2 — Stop what you don't use

• Dev/test VSs left on overnight. Stop them at end of day; restart on demand.
• Snapshot-and-go pipelines that finish but leave the VS running. Add a stop call to the end of your pipeline.
• Abandoned proofs of concept. Audit Virtual Servers → All every Monday and terminate what nobody owns.

Lever 3 — Off-peak scheduling

If your workload is batch or non-interactive, you can save by running it during off-peak windows. MVP1 does not ship a built-in cron scheduler on the VS itself, so this is roll-your-own: a cron job on your side calls the Zyra API to start the VS at 02:00 local, then stop at 05:00. Or your workload calls the stop endpoint on completion.

[VERIFY: confirm whether Stage 4 will ship a native scheduled-start/stop feature or whether this stays customer-driven via API in MVP1]

Lever 4 — Right-storage

Disk size is part of the per-hour rate. Use ephemeral disk for working scratch; put small permanent state on a smaller persistent volume. Don't allocate 500GB "in case" — start at 50GB, watch disk_usage_gb, grow when needed.

Lever 5 — GPU only when needed

GPUs are scarcer and more expensive. If your workload spends 90% of its time pre/post-processing and 10% on the model, split it: one CPU-only VS for prep, a GPU VS for inference, called via an internal queue.

Storage matters too

Persistent volumes outside the VS itself (snapshots, image storage, log archives older than 30 days) have their own line items on the invoice. Audit them quarterly via Settings → Storage. [VERIFY: storage cost surface in UI vs invoice-line-only at launch]

The unit-economics view

Open Billing → Cost Analytics and look at $/VS-hour rolling 7d, $/job (if you tag jobs), and Idle hours (time VSs ran with <5% CPU — pure waste).

What just happened

You have five concrete levers and a baseline expectation of being ~70% under hyperscale cloud. Next chapter zooms out to the people side: who gets to do all of this in your organisation.

Troubleshooting

• Bill higher than expected. First check Idle hours — odds are something is running you forgot about.
• Cost-per-hour shown ≠ what I quoted. Decimal precision is to 6 places; round-trip through the invoice PDF for the authoritative figure.
• Stopped VS still accruing. Should not happen — file a ticket with the VS UUID. The calculator filters strictly on status == "running".