Preços, créditos e uso

A ReOpenly precifica computação em créditos. Consulte taxas e estimativas ao vivo em vez de copiar valores dos exemplos: preços e configurações da plataforma podem mudar sem uma nova versão do cliente.

Endpoints públicos de preços

GET  /api/v1/pricing/platform
GET  /api/v1/pricing/models
POST /api/v1/pricing/estimate

Essas rotas não exigem autenticação e têm rate limit. /platform retorna a taxa atual e o bônus de cadastro; /models traz o catálogo estreito da calculadora pública. /api/v1/base-models, autenticado, continua sendo a fonte para modelos implantáveis, capacidades e limites de treino.

Estime inferência com tokens e requisições, ou fine-tune com steps, tamanho de sequência, quantidade de conversas treináveis, exemplos separados e batch efetivo:

{
  "kind": "fine_tune",
  "model": "<catalog-model-id>",
  "workload": {
    "max_steps": 100,
    "max_seq_length": 2048,
    "messages": 5000,
    "examples": 1000,
    "eval_examples": 50,
    "effective_batch_size": 8
  }
}

No fine-tune, expected é a previsão central do tempo cobrado — somente o laço de treino — enquanto authorization_ceiling é o valor conservador de admissão e cobre a locação inteira, porque ele limita por quanto tempo uma execução pode ocupar uma GPU, não quanto ela custa. Os dois diferem por mais do que um fator de segurança: em uma execução curta, o início não cobrado pode ser a maior parte da locação. O limite pago atual está em duration_components.execution_limit_seconds. Não apresente o teto como gasto esperado nem a estimativa como garantia. O termo de preparação para corpus grande ainda é um limite de admissão aguardando validação em escala. A estimativa subtrai a densidade da calibração medida e adiciona a agenda exata de avaliação, permitindo que planos esparsos custem menos e planos densos custem mais. embedded_evaluation_seconds, scheduled_evaluation_seconds e evaluation_adjustment_seconds expõem a conta. Workloads de fine-tune podem incluir o mesmo objeto discriminado evaluation_cadence aceito na criação do job.

Os segundos cobrados do fine-tune são o tempo de treinamento na GPU, e nada dos dois lados dele. A cobrança é o intervalo training_started_at até post_processing_started_at de cada tentativa, com retorno ao fim da tentativa quando ela nunca chegou ao pós-processamento. Tudo antes do início do treinamento não é cobrado — tempo em fila, congelar sua seleção, carregar o modelo, ler e tokenizar seus dados — e tudo depois do fim do laço também não: salvar, verificar e publicar o modelo. Intervalos antes de uma nova tentativa também não são cobrados.

Uma execução que nunca começou a treinar não é cobrada. É isso que torna gratuito cancelar um job na fila ou preparando.

A cobrança final usa o intervalo medido de cada tentativa cobrada, não a duração de parede do job nem a estimativa.

examples é a quantidade de conversas treináveis selecionadas antes da divisão, enquanto messages é a quantidade de mensagens selecionadas mantida como hipótese explícita. Envie eval_examples quando souber a quantidade separada. Se os dois campos de corpus forem omitidos, a calculadora pública assume conservadoramente o máximo atual de 512 exemplos separados e retorna confiança baixa; omitir o campo não significa zero trabalho de avaliação. O wizard autenticado obtém a divisão real e o plano congelado exato por estimate-messages.

O tempo de treino é arredondado para cima em unidades de 100 ms para cada tentativa cobrada. As cobranças no extrato e os saldos mantêm seis casas decimais. A tela de treino exibe custos com quatro casas decimais; essa exibição não altera a cobrança armazenada. Por exemplo, 40,3 segundos a 0,03 créditos por minuto de GPU custam 0,020150 créditos, exibidos como 0,0202.

Saldo e extrato

GET /api/v1/credits
GET /api/v1/credits/usage?month=YYYY-MM
GET /api/v1/credits/usage?month=YYYY-MM&limit=50&cursor=<next_cursor>

/api/v1/credits retorna o saldo e apenas as 100 linhas mais recentes. /usage traz o mês UTC completo, com totais, agregados por categoria/projeto e cursor opcional de até 100 linhas. Uma linha pode ter billable_seconds, rate_credits_per_minute e surcharge_percent; ausência em linhas antigas, depósitos ou reembolsos significa “não registrado”, não zero computação. Linhas de inferência também podem incluir o endpoint_name solicitado e o base_model_name resolvido. Uma requisição de modelo base mantém o nome <catalog-model-id> no extrato.

Compra de créditos

POST /api/v1/credits/checkout
GET  /api/v1/credits/checkout/status?session_id=<stripe_session_id>

No corpo do checkout, amount é uma quantidade de créditos, não dinheiro:

{"amount": 25, "currency": "brl"}

A resposta trava e retorna credits, currency, money_amount e fx_rate, além da URL do Stripe. Envie um UUID v4 novo em Idempotency-Key por tentativa lógica. Depois do retorno do Stripe, consulte o status autenticado e considere somente fulfilled como creditado; autorização, captura e reconciliação podem ser intermediárias. Um status fulfilled também retorna purchase com os credits concedidos e o money_amount cobrado em currency (ISO 4217, em maiúsculas); em qualquer outro estado ele é null.

Não existe endpoint de cliente para conceder créditos. /api/credits/grant é uma rota de operador app-admin, e a antiga rota de depósito próprio não existe.

As entradas do extrato sempre usam cursor (50 por padrão, máximo 100). Siga entries_next_cursor para alcançar todas. Os cursores pertencem à conta e ao mês; os totais e agrupamentos mensais estão completos em cada página, sem ativar um modo.