Facturarea la secundă, explicată: de ce un sandbox de 20 de secunde costă $0.00055

„Facturat la secundă” e una dintre acele expresii care sună complet și nu sunt. În spatele ei stau câteva decizii care schimbă cât plătești: ce se măsoară, când pornește și când se oprește ceasul, dacă există un minim, cum sunt tratate fracțiunile de cent și când pleacă de fapt banii din sold.

Articolul ăsta scrie răspunsurile noastre, cu tot cu aritmetică, pentru sandboxurile de cod. Scopul e să poți prezice o factură la cent înainte să rulezi ceva și să recunoști punctul în care facturarea la secundă e modelul greșit pentru sarcina ta.

Unitatea: vCPU și RAM rezervate

Prețul unui sandbox e prețul resurselor pe care le rezervă tariful lui:

• $0.040 pe oră de vCPU
• $0.013 pe GiB de RAM pe oră

Tariful small (0,5 vCPU, 1 GB) costă deci 0,5 × 0.040 + 1 × 0.013 = $0.033 pe oră, adică aproximativ $0.0000092 pe secundă. Cel mai mare, max (8 vCPU, 16 GB), costă $0.528 pe oră.

Măsurăm rezervarea, nu consumul. Un sandbox care își așteaptă următoarea comandă costă pe secundă cât unul care compilează un proiect. Măsurarea CPU-ului efectiv ar arăta mai corect pe hârtie, dar face prețul imposibil de știut dinainte, iar capacitatea e ținută pentru tine oricum. Traficul spre exterior nu se facturează.

Ceasul: de la creare la ștergere

Un sandbox efemer e facturat din momentul în care e creat până când e șters. Asta include timpul în care stă inactiv până îl elimină timeoutul de inactivitate, implicit 300 de secunde.

De aici vin cele mai multe surprize. Un script care durează două minute, într-un sandbox pe care nu-l șterge nimeni, e facturat pentru șapte: două de muncă și cinci de așteptare a timeoutului. Soluția e plictisitoare: șterge sandboxul când ai terminat (blocul with din SDK face asta pentru tine) sau scade timeoutul de inactivitate.

Minimul: 60 de secunde pe sandbox

Fiecare sandbox efemer e facturat pentru cel puțin 60 de secunde din viața lui. Pornirea unui microVM, atașarea discului și a rețelei și desființarea lor costă la fel, fie că acel cod rulează o secundă, fie cincizeci.

Minimul se aplică o singură dată, când sandboxul se încheie, și doar dacă durata lui totală de viață a fost sub 60 de secunde. Nu există în plus un minim pe oră sau pe comandă.

Acumularea și debitarea: micro-dolari și cenți întregi

Iată partea pe care „la secundă” de obicei nu ți-o spune. Hostul sandboxurilor înregistrează consumul în intervale orare, câte unul pentru fiecare sandbox. O dată pe minut, sarcina de facturare adună intervalele care s-au închis, le calculează prețul și debitează soldul.

Calculul prețului se face în milionimi de dolar. Debitarea se face în cenți întregi. Ce rămâne sub un cent stă în contul tău și se adaugă la următoarea debitare; nu e rotunjit în sus pe sandbox sau pe oră.

La scară mică, asta contează. O sută de sandboxuri de 20 de secunde adună 100 × $0.00055 = $0.055. Ești debitat cu cinci cenți, iar o jumătate de cent așteaptă următorul lot. Dacă fiecare sandbox ar fi rotunjit în sus la un cent, aceeași muncă ar costa un dolar.

Încă două proprietăți merită știute:

• Fiecare interval e taxat exact o dată. Înregistrarea consumului și debitarea sunt scrise într-o singură tranzacție de bază de date, cu cheia sandbox și oră. O rulare reîncercată sau o confirmare pierdută nu poate taxa de două ori.
• Căderile întârzie taxările, nu le pierd și nu le dublează. Dacă partea de facturare nu poate ajunge la hostul sandboxurilor, nimic nu e confirmat, intervalele așteaptă și sunt taxate când revine conexiunea.

Consecința e că panoul poate rămâne în urma cifrei live cu până la o oră. Pentru cifra live, GET /sandboxes/{id}/usage returnează billed_usd și un estimated_total_usd pentru sandbox până în acel moment.

Sandboxurile persistente: pe oră începută, cu un plafon

Sandboxurile persistente își păstrează discul între sesiuni, până la 30 de zile. Sunt facturate pe oră începută: 61 de minute înseamnă două ore. În schimb, o lună calendaristică (UTC) nu costă niciodată mai mult de 730 de ore minus 25%.

Pentru tariful standard, plafonul e $36.14 pe lună în loc de $48.18. Cât un sandbox persistent e pus pe pauză, nu e facturat deloc.

Când se termină soldul

Soldul nu scade niciodată sub zero. Sandboxurile noi sunt refuzate cu 402 insufficient_balance. Sandboxurile efemere care rulează deja se încheie la timeoutul de inactivitate sau la TTL. Cele persistente sunt puse pe pauză după 24 de ore fără alimentare și își reiau singure activitatea când adaugi fonduri. Starea sandboxurilor puse pe pauză se păstrează 14 zile. După asta, sandboxul e șters, iar id-ul lui returnează 410 sandbox_deleted.

Dacă un agent AI creează sandboxuri pentru tine, setează un plafon zilnic și unul lunar. Atingerea unui plafon returnează 429 budget_exceeded, cu momentul în care se resetează, după care un program poate acționa.

Unde pierde facturarea la secundă

Facturarea la secundă e excelentă pentru munca măsurată în secunde și minute. Devine mai proastă cu cât munca durează mai mult.

Punctul de trecere e aproximativ acolo unde o sarcină rulează mai mult de câteva ore pe zi. Dincolo de el, plătești pentru o flexibilitate pe care nu o folosești, iar un server închiriat cu luna e mult mai ieftin pe oră. Felul corect de a privi facturarea la secundă e ca preț pentru faptul că nu trebuie să-ți planifici capacitatea, nu ca reducere.

O cale rapidă de estimare

Prețul pe oră al tarifului × secundele în care va exista sandboxul ÷ 3600, cu 60 de secunde ca prag minim. Adaugă timeoutul de inactivitate dacă nu-l vei șterge singur. Pentru sandboxurile persistente, rotunjește fiecare sesiune în sus la ore întregi și oprește-te la plafonul lunar.

Regulile complete, cotele și API-ul de buget sunt în limitele și facturarea sandboxurilor; apelurile folosite mai sus sunt în referința SDK. Dacă te întrebi ce închiriezi de fapt la secundă, microVM-urile Firecracker, explicate acoperă asta, iar de ce au nevoie agenții AI de la infrastructură arată de ce modelul de facturare contează atât de mult odată ce software-ul, nu oamenii, creează mașinile.