Cobrança por segundo explicada: por que uma sandbox de 20 segundos custa $0.00055

“Cobrado por segundo” é uma daquelas frases que parecem completas e não são. Por trás dela há várias decisões que mudam o que você paga: o que é medido, quando o relógio começa e para, se existe um mínimo, como as frações de centavo são tratadas e quando o dinheiro sai de fato do seu saldo.

Este post registra nossas respostas, com as contas, para as sandboxes de código. O objetivo é que você consiga prever uma fatura ao centavo antes de rodar qualquer coisa, e reconhecer o ponto em que pagar por segundo é o modelo errado para a sua carga.

A unidade: vCPU e RAM reservados

O preço de uma sandbox é o preço dos recursos que o plano reserva:

• $0.040 por vCPU-hora
• $0.013 por GiB de RAM por hora

O plano small (0.5 vCPU, 1 GB) custa, portanto, 0.5 × 0.040 + 1 × 0.013 = $0.033 por hora, ou cerca de $0.0000092 por segundo. O maior, max (8 vCPU, 16 GB), custa $0.528 por hora.

Medimos a reserva, não o consumo. Uma sandbox esperando o próximo comando custa por segundo o mesmo que uma compilando um projeto. Medir a CPU real pareceria mais justo no papel, mas tornaria o preço impossível de saber com antecedência, e a capacidade fica reservada para você de qualquer forma. Tráfego de saída não é cobrado.

O relógio: da criação à exclusão

Uma sandbox efêmera é cobrada do momento em que é criada até ser excluída. Isso inclui o tempo ociosa antes que o tempo limite de inatividade a remova, 300 segundos por padrão.

É daí que vem a maioria das surpresas. Um script de dois minutos, numa sandbox que ninguém exclui, é cobrado por sete: dois de trabalho e cinco esperando o tempo limite. A solução é sem graça: exclua a sandbox quando terminar (o bloco with do SDK faz isso por você) ou reduza o tempo limite de inatividade.

O mínimo: 60 segundos por sandbox

Toda sandbox efêmera é cobrada por pelo menos 60 segundos de vida. Iniciar uma microVM, conectar disco e rede e desmontar tudo depois custa o mesmo, quer o código dentro rode um segundo ou cinquenta.

O mínimo é aplicado uma vez, quando a sandbox termina, e só se a vida total dela foi menor que 60 segundos. Não há mínimo adicional por hora nem por comando.

Acúmulo e débito: microdólares e centavos inteiros

Aqui está a parte que “por segundo” geralmente não conta. O host das sandboxes registra o uso em faixas de uma hora, uma por sandbox. Uma vez por minuto, a tarefa de cobrança coleta as faixas fechadas, calcula o valor e debita o saldo.

O cálculo é feito em milionésimos de dólar. O débito, em centavos inteiros. O que sobra abaixo de um centavo permanece na sua conta e entra no débito seguinte; nada é arredondado para cima, nem por sandbox nem por hora.

Em pequena escala, isso importa. Cem sandboxes de 20 segundos acumulam 100 × $0.00055 = $0.055. Você é debitado em cinco centavos, e meio centavo espera o próximo lote. Se cada sandbox fosse arredondada para um centavo, o mesmo trabalho custaria um dólar.

Duas outras propriedades valem a pena conhecer:

• Cada faixa é cobrada exatamente uma vez. O registro de uso e o débito são gravados numa única transação de banco de dados, com a sandbox e a hora como chave. Uma nova tentativa ou uma confirmação perdida não consegue cobrar duas vezes.
• Quedas atrasam os débitos, não os perdem nem os duplicam. Se a cobrança não consegue falar com o host das sandboxes, nada é confirmado, as faixas esperam e são debitadas quando a conexão volta.

A consequência é que o painel pode ficar até uma hora atrás do número ao vivo. Para o número ao vivo, GET /sandboxes/{id}/usage retorna billed_usd e um estimated_total_usd da sandbox até agora.

Sandboxes persistentes: por hora iniciada, com teto

Sandboxes persistentes mantêm o disco entre sessões, por até 30 dias. São cobradas por hora iniciada: 61 minutos são duas horas. Em troca, um mês do calendário (UTC) nunca custa mais que 730 horas menos 25%.

Para o plano standard, esse teto é de $36.14 por mês em vez de $48.18. Enquanto uma sandbox persistente está pausada, ela não é cobrada.

Quando o saldo acaba

O saldo nunca fica negativo. Novas sandboxes são recusadas com 402 insufficient_balance. As efêmeras já em execução terminam no seu tempo limite de inatividade ou TTL. As persistentes são pausadas após 24 horas sem recarga e voltam sozinhas quando você adiciona fundos. Snapshots pausados ficam guardados por 14 dias. Depois disso a sandbox é apagada e o id dela responde 410 sandbox_deleted.

Se um agente de IA cria sandboxes por você, defina um limite diário e mensal. Ao atingi-lo, volta 429 budget_exceeded com o horário de reinício, algo sobre o que um programa consegue agir.

Onde a cobrança por segundo perde

Pagar por segundo é ótimo para trabalho medido em segundos e minutos. Fica pior quanto mais longo o trabalho.

O ponto de virada fica mais ou menos onde uma carga roda mais que algumas horas por dia. Depois disso, você paga por uma flexibilidade que não usa, e um servidor alugado por mês sai bem mais barato por hora. A forma honesta de ver a cobrança por segundo é como o preço de não precisar planejar capacidade, não como um desconto.

Uma estimativa rápida

Preço por hora do plano × segundos que a sandbox vai existir ÷ 3600, com 60 segundos como piso. Some o tempo limite de inatividade se você não for excluí-la. Para as persistentes, arredonde cada sessão para horas inteiras e pare no teto mensal.

Todas as regras, cotas e a API de orçamento estão em limites e cobrança das sandboxes; as chamadas usadas acima, na referência do SDK. Se você quer saber o que exatamente está alugando por segundo, microVMs Firecracker explicadas responde, e o que agentes de IA realmente precisam da infraestrutura explica por que o modelo de cobrança importa tanto quando são programas, e não pessoas, que criam as máquinas.