Contabilidade das alocações de uso

Iniciar com Alocações de uso para configuração. Uma regra pertence a uma conta dedicada numa área de trabalho. A sua conta permanece fixa enquanto a regra existe. Os membros precisam de uma subvenção directa e de uma chave pessoal ligada à regra; uma chave normal não é convertida automaticamente. Todas as chaves de um membro para a partilha de regras um livro de registos.

Parte de um orçamento total

Por proporção aceita um total diário/mensal ou até 8 janelas de duração com um total próprio em cada uma. As mesmas percentagens, cuja soma é no máximo 100%, aplicam-se a todas as janelas. A base pode ser tokens ou USD internos:

• Por partilha de fichas: insira o total em M tokens. Entrada relatada mais tokens de saída contam com a ação de cada membro; a entrada em cache faz parte da entrada e não é contada duas vezes.
• Por parcela de montante: inserir um interno USD total. Cada entrada de pedido, entrada em cache e saída são convertidos usando os preços do modelo salvos com essa revisão de regra. Estes preços não indicam a fórmula de cobrança da assinatura do provedor.

Em cada janela, o limite individual é o total multiplicado pela percentagem, arredondado para baixo à unidade mínima. Por exemplo, 25% de 1 M tokens são 0,25 M. Percentagens positivas que resultem em zero são recusadas. Partes não atribuídas e sobras de arredondamento não são emprestadas automaticamente. A admissão verifica o membro e o total do grupo, incluindo consumo de antigos membros. O saldo não reinicia separadamente por conta de subscrição.

Estes são... Orçamento interno. Um total de token configurado não revela a capacidade real da assinatura, e interna USD Não é um saldo ou uma factura em dinheiro. SubLane Verifica ainda a quota a montante disponível; o prestador pode rejeitar os pedidos antes do esgotamento do orçamento interno.

Limites de quantidade de janela temporal

Por janela de tempo é um tipo separado. Aceita até 8 condições de horas/dias inteiros, de 1 hora a 365 dias, e um limite interno em USD comum por predefinição. Cada membro tem registo independente e pode substituir condições. Um limite vazio torna essa condição ilimitada: a utilização é registada sem quota ou reserva provisória de risco. Cada pedido liquidado é valorizado uma vez aos preços guardados e conta em todas as janelas. Uma condição finita esgotada ou sem margem de reserva impede novos pedidos.

As janelas começam na ativação e renovam-se independentemente por durações fixas. Renovar as cinco horas não apaga o consumo semanal. Não são janelas móveis retrospetivas nem acompanham os reinícios do fornecedor. O fuso da instância altera apenas a apresentação.

Alterações de membros e agendamento

Editar membros atuais altera proporções ou limites individuais imediatamente, mantendo consumo e reservas de pedidos admitidos. Aumentos têm de caber em todos os orçamentos partilhados atuais; remover e voltar a adicionar não limpa a utilização. Num total de 100 com A já tendo consumido 40, atribuir 33 a A/B/C exige 106 e é recusado; 40/30/30 cabe. Após renovar, todas as janelas são novamente verificadas; agendar não contorna uma falta de orçamento.

Orçamentos, limites predefinidos e preços entram em vigor na hora já agendada ou no próximo limite do plano atual. Com várias janelas, usa-se a duração atual mais longa. Preservam-se a âncora e o uso; uma janela curta pode estar em curso e uma redução deixá-la esgotada. Novos preços não recalculam pedidos antigos.

Edições normais de orçamento/preço mantêm exatamente os membros guardados, mesmo se alguém já não consta da lista autorizada. Manter a configuração não restaura o acesso. Novos destinatários e um novo período estrutural exigem permissão atual do grupo.

Um plano independente de membros na próxima versão impede a propagação da alteração imediata e devolve conflito. Reveja ou cancele explicitamente essa instrução; outros parâmetros compatíveis são mantidos. Atualizações em segundo plano não ligam versões novas a rascunhos antigos. Após conflito, use Atualizar e revisar.

Mudar unidade, tipo ou plano de reinício exige confirmar uma substituição estrutural real. Os ID de regra, grupo e Key são mantidos; a ativação agendada torna-se a nova âncora contabilística. Alterar só membros ou preços não cria um novo período.

Adiar até o próximo limite move apenas para a primeira fronteira natural estritamente posterior à ativação guardada, usando o plano atual ou o plano inicial antes da primeira ativação. Reveja e confirme a hora do servidor; condições expiradas ou alteradas devolvem conflito.

Cancelar alteração agendada exige uma versão atual efetiva. Uma regra apenas com agendamento inicial pode ser pausada ou adiada. O adiamento inicial substitui a versão atomicamente. Pausar não remove a configuração legível nem cancela ou adia a ativação; o acesso continua bloqueado mesmo depois da ativação inicial.

Correções iniciais de membros usam o editor completo (PATCH /api/allocations/{id}). Exigem o par de versões e a hora revistos, mantêm ativação e âncora guardadas e voltam a verificar as permissões de grupo dos destinatários. Só são permitidas sem versão atual e sem pedidos registados. Versão, metadados e auditoria são gravados na mesma transação; falhas ou ultrapassar a ativação revertem tudo. O cancelamento inicial continua proibido.

Se a próxima versão aprovada tiver estrutura realmente diferente da atual, a confirmação existente de novo período fica disponível mesmo que o rascunho mantenha a estrutura agendada. Reconfirmar permite editar os seus membros. Edições normais de orçamento/preço mantêm membros e âncora sem reconfirmar. Retirar esta confirmação opcional mostra e envia o plano de membros guardado. A substituição continua a exigir uma diferença estrutural real face à versão atual.

Para as licenças de emissão de preços (Por quantidade, Por parcela de montante, Por janela de tempo), SubLane lê os modelos suportados pelo conjunto dedicado e preenche os seus preços de catálogo ao gravar uma revisão. Os preços fornecidos pelo utilizador não sobrepõem este instantâneo. Se um modelo não tiver nenhum preço de catálogo actual, a sua taxa previamente guardada é reutilizada quando disponível. Um modelo recentemente descoberto sem preço é omitido do instantâneo, pelo que os pedidos para ele permanecem bloqueados até que uma revisão com preços produza efeito. Os avisos de cobertura de preços são calculados quando uma regra é lida, não armazenada na sua revisão: um preço de catálogo restaurado limpa automaticamente o aviso de catálogo, enquanto um modelo ausente do instantâneo de preços gravados permanece marcado até que uma nova revisão o inclua. Os catálogos de contas não disponíveis conservam as taxas previamente guardadas e mostram um aviso até que a descoberta recupere. A poupança só falha se não existir um preço utilizável. Sem um catálogo de preços carregado ou uma cache de preços guardado, não é possível criar uma nova margem de preço; actualizar o catálogo ou fornecer uma redução de preço antes de tentar novamente.

Para modelos sem preço guardado, o aviso indica quando uma correção guardada agora entraria em vigor. Janelas usam o próximo limite da duração atual mais longa; guardar repetidamente não disponibiliza o preço de imediato. Uma versão já agendada mostra a sua própria hora e avisa que o modelo continuará bloqueado se não for substituída por uma versão corrigida.

Limites diretos e utilização pendente

Por fichas define o limite de token de um membro diretamente. Por quantidade define um interno directo USD limite usando os preços salvos do modelo. Ambos usam a mesma contagem de valor ou o mesmo valor que a base de ações correspondente.

Utilização final fiável é liquidada sem esperar percentagens do fornecedor. Um pedido sem totais fiáveis fica pendente de correção; observações parciais são visíveis, mas não são encargos nem reservas. Cada pedido ativo reserva 10% do limite individual capturado na admissão, no mínimo uma unidade, em cada janela finita; edições posteriores não alteram a reserva. Cada janela finita permite até quatro pedidos simultâneos desse membro iniciados nela; o orçamento partilhado verifica também a exposição do grupo. A reserva é libertada no fim. Pedidos grandes podem ultrapassar limites e uso desconhecido deixa exposição incompleta: são limites flexíveis. Mostram-se primeiro os 256 pendentes mais recentes. A atribuição usa a admissão após a fila; o tempo diagnóstico começa na chegada.

Pela Codex córregos, SubLane pode continuar a ler a montante durante até 3 segundos após a desconexão do cliente para capturar o uso final confiável. Um evento terminal falhado que inclui o uso completo também pode ser carregado. Falhas de a montante repetidas arrefecem temporariamente a conta afetada; uma resposta bem- sucedida sem o uso final permanece pendente sem arrefecer a conta. Se uma gravação de contabilidade falhar temporariamente, SubLane Reitera esse pedido antes de admitir mais trabalho apoiado por subsídios para o membro afetado; outros membros podem continuar.

Regras diárias/mensais mantêm data e hora no fuso da instância; dias mensais inexistentes usam o último dia do mês. As predefinições são 00:00 diariamente ou dia 1 às 00:00. Edições normais preservam a âncora. Pausar ou revogar acesso bloqueia novos pedidos e turnos WebSocket sem apagar histórico. Atualizar quotas, usar cartões de reposição, reautorizar ou reiniciar não repõe orçamentos locais.

Escolhendo Iniciar o próximo período ao criar uma regra de janela temporal inicia-a após a maior duração configurada.

Leia e corrija os balanços

Os membros vêem o seu próprio subsídio Utilização. Administradores do espaço de trabalho abertos Alocações de uso → Ver uso para a regra completa. Todas as janelas de tempo configuradas aparecem sob um membro com o seu próprio limite, quantidade usada, quantidade restante, exposição ao risco e reset instantâneo; o estado do membro reflete a condição mais restritiva. Os saldos de quantia mostram USD ao lado dos tokens reportados; os saldos dos tokens usam o M, onde 1 M = 1,000,000 tokens. Relatórios pessoais não expõem identidades de conta de assinatura.

O saldo é separado utilizado (uso definido) a partir de pedidos de voo e utilização pendente no ciclo atual. As reservas temporárias refletem apenas os pedidos de voo; a utilização pendente permanece visível para correção e não conta como subsídio usado ou capacidade de reserva. A sala de entrada inclui o buffer automático de risco; não é subsídio extra gastável. Novas solicitações temporariamente pausadas quando outra solicitação precisa de mais reserva do que a sala de comando atual, ou quatro solicitações ainda estão em voo. O status segue a mesma verificação de risco do ciclo atual como entrada de gateway. É um instantâneo e pode mudar conforme as solicitações terminarem. Registros pendentes fora do ciclo atual permanecem visíveis para correção, mas não pausam sua admissão.

Quando um item pendente não puder ser resolvido automaticamente, um administrador poderá introduzir os totais de entrada, saída e entrada em 'cache' suportados por provas fidedignas. A correcção usa a regra de contabilidade gravada da requisição e escreve um evento de auditoria. Não trate o uso em falta como zero ou insira os totais inventados.

Administradores de espaço de trabalho gerenciam regras em /api/allocations; os membros lêem os seus próprios saldos em /api/me/allocations. As chaves ligam-se a uma regra com scheme_id. Ver espaços de trabalho e pessoal API chaves.

Condições de escrita da API

As leituras mantêm o formato e acrescentam write_conditions, com expected_current_revision_id e expected_next_revision_id que aceitam null. Ambos são obrigatórios para modificar regras existentes: PATCH completo, membros, cancelamento/adiamento e substituição. Condições ausentes ou antigas devolvem HTTP 409 sem alterações. Reveja o conteúdo; não obtenha novos ID para reenviar automaticamente um rascunho antigo. Ativação/pausa explícita e correção por pedido mantêm os seus contratos.

Versões futuras exigem expected_effective_at, em segundos UTC confirmados pelo servidor; substituições estruturais exigem também confirm_replacement=true. POST /api/allocations/{id}/preview aceita schedule, reschedule ou replace. Membros usam POST /api/allocations/{id}/members; ações agendadas usam POST /api/allocations/{id}/cancel e POST /api/allocations/{id}/reschedule. Guardar a configuração completa não muda a ativação: use POST /api/allocations/{id}/enabled.

A primeira criação sem condição temporal mantém o início imediato/adiado anterior. Enviar expected_effective_at exige start_next=true: o início por calendário coincide com a próxima fronteira; o início por duração continua futuro e a não mais de uma duração máxima desde a hora atual do servidor. Null explícito devolve 409 por condição obrigatória, formato inválido 400 e hora expirada/alterada 409. POST /api/allocations/preview apenas propõe o início, sem criar a regra; uma confirmação falhada não volta a criação incondicional.