Define pricing model for compute

[scotwells]

Parent Issue

Tracked by datum-cloud/enhancements#682 (Launch Workload Compute Service — "UFOs")

Summary

Before the compute service can launch, the pricing model needs to be decided: which dimensions drive billing, what the rates are, what is included per tier, and what the default quota values are. This decision gates several other workstreams — compute#90 (quota integration) has open questions on default quota values that require GTM input, and the metering implementation in unikraft-provider#5 needs to know which dimensions matter.

Goals

• Decide which billing dimensions to use at launch (e.g. vCPU-seconds, instance-seconds, memory-GiB-seconds, or some combination)
• Define rates for each billable dimension
• Define what is included per tier (free tier, starter, growth, enterprise)
• Provide default quota values per tier to unblock compute#90 implementation
• Confirm which dimensions are deferred to a later phase (e.g. GPU, egress)

Non-Goals

• Implementing the billing or metering pipeline (tracked in unikraft-provider#5 and enhancements#681)
• Quota enforcement implementation (tracked in compute#90)

Open Questions

• Do we bill by allocated resources (reserved vCPUs/memory) or consumed resources (actual CPU-seconds)?
• Is there a minimum billing unit (e.g. per-minute rounding) or true second-granularity?
• How do we handle instances that fail to start — is there any charge?
• What is the free tier allowance, if any?

[drewr]

@bmertens-datum @zsmithnyc @jacobsmith928 Where did we land on the questions here?

[zsmithnyc]

I'd like to punt until we can see a bit of usage patterns and traffic in the system, seeing how the scale to zero performance patterns work out. My gut tells me:

• bill for actual usage, rounded to nearest second
• don't SLA boot time as sufficient resources may be unavailable and cause delay in a launch. Fall back should be nearby region where capacity is available.
• for free tier i am thinking it will be a certain number of seconds / minutes per period.

The main outstanding issue i think we need to solve is registry / image storage allotment and charges along with guarantee SLA on local cache amount size of those images in regions.

[jacobsmith928]

I think we need to codify a thesis to validate @zsmithnyc even if it is free to users. I would ask first: what is compelling in the market we can design backwards from? The ikea model.

[bmertens-datum]

https://github.com/datum-cloud/engineering/wiki/TEMP-UFO-Pricing

[bmertens-datum]

https://docs.google.com/spreadsheets/d/1VgFJJjK72suPGdUyS4kw9jPbtD7A07qd/edit?gid=833709894#gid=833709894

What this is
A bottom-up economic model for the UFO compute platform. It ties real infrastructure costs (Servers.com hardware + Unikraft licensing) to a demand curve and three representative use cases, producing gross margin estimates at ~$100K/month of revenue.

Tab structure (13 tabs)
Business model — front of the book

Summary— One-page portfolio view: all three use cases side by side with gross revenue, net billed revenue, COGS, gross profit, and gross margin %. Includes a blended portfolio total.
Assumptions— Central rate card. Sell prices and COGS rates in one place. All use case tabs pull from here. COGS rates are live-linked to the infrastructure model — change a server spec and margins update automatically.
1 · Beacon Processing— High-frequency WAF/beaconing traffic. 50B requests/month, tiny payloads. ~$43.6K revenue, ~90% GM.
2 · Document Processing API— Law firm compliance gateway with large document payloads. 50M requests/month. ~$28.2K revenue, ~23% GM (transfer-cost heavy — flagged for pricing review).
3 · Agent Intelligence— Ephemeral worker agents + always-on persistent agents. 500M worker requests + 200 persistent agents/month. ~$31K revenue, ~59% GM.
Infrastructure cost model — back of the book

• COGS— Bottom-up cost build: server CPU, memory, and transfer costs divided across actual demand hours (peak, 95th percentile, mean, median). Unikraft licensing added as a variable cost. Outputs cost per vCPU-hour at each utilization level, plus sell-price targets at 50/60/70/80% gross margin.
• Peak— 24-hour demand curve for continental US, four timezones (follow-the-sun). Shows Business Hours and Entertainment Hours traffic patterns. Key stats: peak utilization 87%, mean 46.3%, median 62.8% of provisioned capacity — 333 effective demand hours/month at mean.
• Slots— Server capacity model. Translates hardware specs into billable compute and memory slots. Fleet sizing input (currently 10 servers).
• Servers.com— Hardware spec inputs: 32-core EPYC, 64 vCPU (2× hyperthreading), 128 GB DDR5, 20 TB transfer included, $500/server/month.
• Unicraft— Unikraft licensing: $0.011985/vCPU-hr compute + $0.002397/vCPU-hr support.
• Time— Time unit constants (hour through year in seconds). Referenced by the COGS demand-hour calculations.
• Competitor Rates / Competitor Comparison— Market pricing reference.

Key numbers
BeaconDoc ProcessingAgent IntelPortfolioGross Revenue$43.6K$28.2K$31.0K$102.9KCOGS$4.4K$21.7K$15.2K$41.2KGross Margin90%23%51%60%
Important caveats for finance

1. Use case volumes are illustrative — request counts and transaction sizes are representative, not measured. The model structure is correct; inputs need calibration to real traffic forecasts.
2. Doc Processing margin is a flag — the 23% GM reflects real transfer costs ($0.008130/GBT from Servers.com) against a $0.01/GBT sell price. This use case needs a pricing conversation before it's commercially viable at scale.
3. Unikraft is 79% of compute cost — of the $0.022/vCPU-hr compute COGS, only $0.008 is hardware; $0.014 is Unikraft licensing. At volume, the Unikraft contract is the primary cost lever.
4. COGS is at mean utilization (46%) — the model prices off average demand, not peak. If sustained utilization rises toward the 87% peak, effective COGS per unit improves significantly.
5. No transfer breakage modeled yet — the 20 TB/server/month included transfer is treated as fully consumed. Unused transfer capacity would improve margins; this is deferred to a later phase.