Afregning pr. sekund forklaret: derfor koster en sandbox på 20 sekunder $0.00055

„Afregnes pr. sekund“ er en af de sætninger, der lyder fuldstændige, men ikke er det. Bag den ligger flere beslutninger, der ændrer, hvad du betaler: hvad der måles, hvornår uret starter og stopper, om der er et minimum, hvordan brøkdele af en cent håndteres, og hvornår pengene faktisk forlader din saldo.

Dette indlæg skriver vores svar ned, med udregninger, for kodesandboxe. Målet er, at du kan forudsige en regning på centen, før du kører noget, og genkende det punkt, hvor afregning pr. sekund er den forkerte model for din arbejdsbyrde.

Enheden: reserveret vCPU og RAM

Prisen på en sandbox er prisen på de ressourcer, dens tarif reserverer:

• $0.040 pr. vCPU-time
• $0.013 pr. GiB RAM pr. time

Tariffen small (0.5 vCPU, 1 GB) koster altså 0.5 × 0.040 + 1 × 0.013 = $0.033 i timen, cirka $0.0000092 pr. sekund. Den største, max (8 vCPU, 16 GB), koster $0.528 i timen.

Vi måler reservation, ikke forbrug. En sandbox, der venter på næste kommando, koster det samme pr. sekund som en, der kompilerer et projekt. At måle faktisk CPU ville se mere fair ud på papiret, men gør prisen umulig at kende på forhånd, og kapaciteten holdes til dig under alle omstændigheder. Udgående trafik afregnes ikke.

Uret: fra oprettelse til sletning

En midlertidig sandbox afregnes fra det øjeblik, den oprettes, til den slettes. Det inkluderer tiden i tomgang, før inaktivitets-timeouten fjerner den, som standard 300 sekunder.

Det er her, de fleste overraskelser kommer fra. Et script på to minutter i en sandbox, som ingen sletter, afregnes for syv: to med arbejde og fem med at vente på timeouten. Løsningen er kedelig: slet sandboxen, når du er færdig (SDK'ets with-blok gør det for dig), eller sænk inaktivitets-timeouten.

Minimummet: 60 sekunder pr. sandbox

Hver midlertidig sandbox afregnes for mindst 60 sekunder af sin levetid. At starte en microVM, tilkoble disk og netværk og så nedlægge det hele koster det samme, uanset om koden i den kører et sekund eller halvtreds.

Minimummet anvendes én gang, når sandboxen slutter, og kun hvis hele dens levetid var kortere end 60 sekunder. Der er intet ekstra minimum pr. time eller pr. kommando.

Opsamling og træk: mikrodollar og hele cent

Her er den del, som „pr. sekund“ som regel ikke fortæller. Sandbox-værten registrerer forbruget i timeintervaller, ét pr. sandbox. Én gang i minuttet henter afregningsjobbet de lukkede intervaller, prissætter dem og trækker saldoen.

Prissætningen sker i milliontedele af en dollar. Trækket i hele cent. Det, der er tilbage under en cent, bliver på din konto og lægges til næste træk; intet rundes op, hverken pr. sandbox eller pr. time.

I lille skala betyder det noget. Hundrede sandboxe på 20 sekunder opsamler 100 × $0.00055 = $0.055. Du trækkes fem cent, og en halv cent venter på næste omgang. Hvis hver sandbox blev rundet op til en cent, ville det samme arbejde koste en dollar.

To andre egenskaber er værd at kende:

• Hvert interval trækkes præcis én gang. Forbrugsposten og trækket skrives i én databasetransaktion med sandbox og time som nøgle. En genkørsel eller en tabt bekræftelse kan ikke trække to gange.
• Udfald forsinker træk, de taber eller fordobler dem ikke. Hvis afregningen ikke kan nå sandbox-værten, bekræftes intet, intervallerne venter og trækkes, når forbindelsen er tilbage.

Konsekvensen er, at panelet kan halte op til en time efter det aktuelle tal. Det aktuelle tal giver GET /sandboxes/{id}/usage med billed_usd og et estimated_total_usd for sandboxen indtil nu.

Persistente sandboxe: pr. påbegyndt time, med et loft

Persistente sandboxe beholder deres disk mellem sessioner, i op til 30 dage. De afregnes pr. påbegyndt time: 61 minutter er to timer. Til gengæld koster en kalendermåned (UTC) aldrig mere end 730 timer minus 25 %.

For tariffen standard er loftet $36.14 om måneden i stedet for $48.18. Så længe en persistent sandbox er sat på pause, afregnes den slet ikke.

Når saldoen slipper op

Saldoen går aldrig under nul. Nye sandboxe afvises med 402 insufficient_balance. Midlertidige sandboxe, der allerede kører, slutter ved deres inaktivitets-timeout eller TTL. Persistente sættes på pause efter 24 timer uden optankning og fortsætter af sig selv, når du tilføjer penge. Snapshots af sandboxes på pause gemmes i 14 dage. Derefter slettes sandboxen, og dens id svarer 410 sandbox_deleted.

Hvis en AI-agent opretter sandboxe for dig, så sæt en dags- og månedsgrænse. Når den nås, returneres 429 budget_exceeded med tidspunktet for nulstilling, noget et program kan handle på.

Hvor afregning pr. sekund taber

Afregning pr. sekund er fremragende til arbejde, der måles i sekunder og minutter. Jo længere arbejdet varer, desto dårligere bliver den.

Skæringspunktet ligger omtrent der, hvor en arbejdsbyrde kører mere end et par timer om dagen. Derefter betaler du for fleksibilitet, du ikke bruger, og en server lejet pr. måned er markant billigere pr. time. Den ærlige måde at se på afregning pr. sekund er som prisen for ikke at skulle planlægge kapacitet, ikke som en rabat.

Et hurtigt skøn

Tariffens timepris × de sekunder, sandboxen vil eksistere ÷ 3600, med 60 sekunder som gulv. Læg inaktivitets-timeouten til, hvis du ikke sletter den selv. For persistente sandboxe runder du hver session op til hele timer og stopper ved månedsloftet.

Alle regler, kvoter og budget-API'et findes under grænser og afregning for sandboxe; kaldene ovenfor i SDK-referencen. Hvis du undrer dig over, hvad du egentlig lejer pr. sekund, forklarer Firecracker-microVM'er på almindeligt dansk det, og hvad AI-agenter virkelig har brug for fra infrastruktur viser, hvorfor afregningsmodellen betyder så meget, når det er software og ikke mennesker, der opretter maskinerne.