Codex Subscrições e gateway

Com uma chave pessoal pronta, configure o seu cliente abaixo. Se não tiver uma, complete Primeiro pedido ou peça ao seu administrador um login de membro.

Configuração do cliente

Criar um pessoal API chave em Chaves de API. Use a origem da instância mais /v1 como URL base. Configure um ID de modelo retornado por GET /v1/models.

Definir SUBLANE_API_KEY no ambiente de processo do cliente. Mesclar as seguintes configurações no nível do usuário ~/.codex/config.toml, substituindo os valores existentes correspondentes:

model = "<model-id-from-your-account>"
model_provider = "sublane"

[model_providers.sublane]
name = "SubLane"
base_url = "http://127.0.0.1:8080/v1"
env_key = "SUBLANE_API_KEY"
wire_api = "responses"
requires_openai_auth = false
supports_websockets = true

Usar o URL real da sua instância, com HTTPS para implantação de redes. HTTP/SSE transporte, definido supports_websockets = false. Codex O CLI e a área de trabalho devem ler a configuração do nível de utilizador pretendida. Uma aplicação de ecrã já em execução não herda automaticamente as variáveis de ambiente exportadas noutro terminal; reinicie- as num ambiente onde a chave esteja disponível.

A API A página de chaves fornece um trecho de configuração sem incorporar ou manter o segredo. Ele também oferece uma opção CC Switch importação que passa a chave escolhida para a aplicação instalada localmente após a preparação explícita. CC Switch gera o seu próprio Codex configuração do arquivo de autenticação; ele não preserva a variável de ambiente ou WebSocket configurações no trecho manual acima. Veja o configuração avançada e autenticação Orientação para a configuração do cliente e armazenamento credencial.

Os catálogos de contas são guardados em cache e sobrevivem às reinicializaçãos. catálogos de modelos.

Após a configuração: enviar uma mensagem e verificar a resposta, em seguida, continuar com Uso diário. A conta, a quota e os detalhes do protocolo abaixo são referências para mais tarde.

Adicionar uma conta

Iniciar sessão como administrador, abrir Contas, e escolher Adicionar conta. Os membros não podem acessar os objetivos ou credenciais de gerenciamento de assinaturas.

• Autorização do navegador: nomeie a conta, inicie a autorização e abra o OpenAI link. Após iniciar sessão, copie o completo http://localhost:1455/auth/callback?... endereço da barra de endereços do navegador e cole-o em SubLane. Espera- se um erro de ligação localhost neste ponto: SubLane intencionalmente não abre outro ouvinte de retorno de chamada. Este fluxo de retorno manual funciona para implantações locais e remotas.
• Importar auth.json: escolher um Codex ficheiro de credencial de subscrição ou colar o seu JSONAmbos os CLI estão aninhados. tokens estrutura e o plano Codex formato do token são aceitos. Oficial API As chaves são rejeitadas. SubLane nunca verifica diretórios de clientes locais; ele lê apenas o conteúdo explicitamente enviado pelo administrador. As configurações de endpoint/proxy importadas são descartadas.

A autorização/importação da conta inicia a descoberta do modelo automaticamente. Use Verificar a ligação atualizar e persistir o catálogo do modelo da conta, ou abrir Modelos para inspeccioná- lo. As credenciais importadas mostram Não verificado até o uso bem- sucedido. O menu conta fornece habilitar/desativar, reautorizar e remover. A reautorização deve manter a mesma identidade de conta a montante. Removendo uma conta apaga suas credenciais armazenadas de SubLane; não revoga o login do ChatGPT em si.

Codex a descoberta do modelo envia a versão eficaz do cliente da instância na consulta do catálogo e nos cabeçalhos da solicitação. Os administradores podem configurá- la Administração → Configurações do sistema: uma versão explícita tem prioridade sobre a última versão estável oficial sincronizada, com 0.155.1 como o backback incorporado. Verificações automáticas por omissão a cada seis horas. Isto muda os meta- dados do protocolo sem instalar Codex ou atualizar o incorporado SDK; ver configurações do sistema.

O catálogo upstream depende dessa versão: uma versão obsoleta pode retornar HTTP 200 com apenas modelos ocultos ou um catálogo parcial visível, produzindo um vazio ou incompleto /v1/models lista após filtragem de visibilidade. Os catálogos persistentes incluem a versão de descoberta real, de modo que mudar a versão eficaz ativa a atualização na próxima leitura do catálogo ou solicitação do modelo, mesmo quando suas datas permanecem frescas. Mudando as permissões do pool não resolve este problema de compatibilidade.

OAuth tentativas de utilização PKCE, estado aleatório de 256 bits, uma expiração de dez minutos, uma tentativa ativa por sessão do navegador administrador e um máximo de oito tentativas pendentes. O retorno de chamada está ligado à sessão que o iniciou e consumiu antes de trocar seu código. Fechando o formulário solicita o cancelamento; expirar é o retorno após uma conexão perdida. Pendente OAuth O estado é mantido apenas na memória.

Utilização da assinatura

A página de contas mostra janelas de quota, percentagem restante, contagem para reposição e hora de observação das contas Codex ativas, incluindo limites adicionais reportados. A quantidade de cartões é separada: desconhecido e zero explícito são diferentes. Consulte Cartões de reposição para a lista e uso opcional. Dados ausentes continuam desconhecidos; falhas mantêm o instantâneo anterior com aviso. Chegar à hora de reposição não confirma recuperação: atualize o uso.

O adaptador de uso lê https://chatgpt.com/backend-api/wham/usage e o separado https://chatgpt.com/backend-api/wham/rate-limit-reset-credits endpoint, correspondente à oficial Codex cliente de infraestrutura. Ambos os pedidos usam a credencial da conta selecionada, o proprietário de atualização/retenta existente, a admissão de gateway limitada, um prazo de 20 segundos compartilhado e um limite de 128 KiB por resposta. Se a requisição de detalhes de reset-card falhar ou omitir uma contagem, a quota permanece disponível e qualquer contagem válida da resposta de uso é mantida. Somente os campos de quota normalizados e a contagem são retornados; metadados brutos a montante, IDs de cartões e credenciais são excluídos. Este contrato de infraestrutura pode evoluir independentemente de SubLane.

O esquema consolidado armazena uma quota limitada, normalizada e o instantâneo do cartão de reset por conta em SQLite. Os instantâneos incluem o último tempo de observação bem- sucedido e o processo de sobrevivência reinicia; apagando uma cascata de conta para o seu instantâneo. O processo mantém no máximo 100 entradas de instantâneo na memória e os recarrega vagamente de SQLite. Nenhuma credencial ou respostas de provedor bruto são armazenadas nesta tabela.

GET /api/accounts/{id}/usage retorna uma nova captura de tela por até dois minutos (ou até que uma próxima redefinição seja reportada, se for mais cedo). Um instantâneo expirado é retornado imediatamente com stale e refreshing sinaliza enquanto uma atualização de fundo é executada. Uma primeira captura sem um instantâneo espera pelo resultado. POST /api/accounts/{id}/usage/refresh ignora a frescura e espera pela atualização compartilhada, enquanto honra uma atualização de cinco segundos. Ambas as rotas requerem uma sessão de administrador habilitado; POST também requer a origem existente/JSON Verificações.

Chamadas simultâneas para a mesma conta partilham uma operação a montante. Actualiza- se usar a capacidade configurada do espaço de trabalho (128 por predefinição, via SUBLANE_GATEWAY_CAPACITY) e um prazo global de 45 segundos, sobrevive a uma desconexão individual do navegador e são canceladas/ aguardadas durante o encerramento do processo. Uma actualização falhada preserva os valores e a hora anteriores, marca- os paralisa e recua por 30 segundos (ou uma mais válida a montante, após a repetição, até uma hora). A saturação da admissão usa um atraso de cinco segundos. A 'cache' atinge ainda a verificação da existência e da activação da conta. A falha transitória/regressão do estado é local do processo; a última imagem bem sucedida é durável.

O navegador mantém o seu período de frescura de uma consulta de um minuto. Ele pesquisa o ponto final do instantâneo local apenas uma vez por segundo, enquanto uma atualização está ativa, parando após a conclusão ou um erro de rede. A página não pesquisa periodicamente o provedor enquanto estiver inativo. Atribuições de acções usar o token configurado ou interno USD orçamentos e cobrança de uso de requisição reportada diretamente. Horários de observação e tempo do servidor de resposta são separados para que um instantâneo restaurado não reinicie a contagem regressiva. Contas desabilitadas não são consultadas. O tráfego do modelo também aquece a cache de quotas compartilhadas sem esperar. O esgotamento do limite principal recente exclui uma conta de uma nova seleção; conversas vinculadas retornam uma rejeição específica da quota. Limites de uso de upstream descrevem a assinatura, não a permissão de recursos de um membro. Veja a seção Selecção consciente dos contingentes.

Cartões de reposição

Os administradores do espaço de trabalho podem consultar e usar cartões de contas Codex ativas que não precisem de nova autorização. Os membros não podem geri-los. O uso agendado e o uso ao esgotar a quota estão desativados por predefinição. Consultar ou atualizar a lista não consome cartões.

Configurar e usar

1. Abra Contas e as definições de reposição no cartão da conta Codex. Verifique lista, quantidade disponível e hora de observação. Uma quantidade desconhecida não é zero.
2. Ative o uso agendado, o uso ao esgotar a quota ou ambos. Para uma execução única, escolha uma data e hora futuras; para execução diária, uma hora; para semanal, um dia e uma hora. Confirme o fuso horário da instância apresentado.
3. Guarde o limite diário partilhado (1–100, predefinição 1). Confirme a mensagem de gravação e, se houver agendamento, a próxima execução.
4. Para uso manual, guarde primeiro as alterações e escolha usar um cartão agora. Cada tentativa usa no máximo um cartão. Veja o resultado no histórico; abrir as definições não inicia um resgate.

Lista e prioridade de validade

A lista mostra nome, estado, atribuição e validade. Distingue cartões disponíveis, em resgate, usados, expirados, desconhecidos e não suportados, sem apresentar IDs brutos. A marca do próximo cartão descreve a seleção automática; não existe seleção manual e a marca fica oculta enquanto houver resultado pendente. Uma quantidade positiva não garante cartões elegíveis.

Cada nova tentativa manual, agendada ou por esgotamento relê o inventário e envia credit_id explicitamente. Apenas cartões disponíveis, suportados e não expirados são elegíveis. A validade mais próxima tem prioridade; cartões sem validade ficam no fim. Empates usam a atribuição mais antiga e depois uma ordem estável de ID. Sem cartão elegível ou inventário confirmado, o resgate é ignorado sem recorrer à seleção predefinida do fornecedor. Uma falha inicial é distinta de lista vazia. Se a atualização falhar, mantém a lista anterior com aviso; volte a atualizar os cartões.

Agendamento e limites

O esgotamento é verificado em segundo plano aproximadamente a cada minuto. Exige dados recentes, quantidade de cartões conhecida e positiva e recusa explícita da quota principal. Uma indicação de 100%, dados desconhecidos ou erro de rede não bastam. O uso manual e agendado também exige dados recentes e uma quantidade conhecida e positiva.

Todos os modos partilham o limite diário pela data local da instância; tentativas bem-sucedidas e pendentes reservam capacidade. Contas desativadas ou a precisar de nova autorização são ignoradas. Execuções atrasadas mais de cinco minutos não são recuperadas. Horas inexistentes pela mudança de hora são ignoradas; horas repetidas geram uma execução por data local. Mudar o fuso recalcula execuções futuras. Fechar o navegador não interrompe os processos. A demonstração não permite automação nem resgates.

Resultados e recuperação

O fornecedor determina a elegibilidade e as janelas repostas. O resgate usa POST /backend-api/wham/rate-limit-reset-credits/consume, com resultados reconhecidos reset, already_redeemed, nothing_to_reset e no_credit. O sucesso atualiza quota e quantidade sem remover outras restrições do gateway nem garantir a remoção de todas.

Antes do envio, são guardados redeem_request_id e o ID do cartão escolhido. Um tempo limite ou resposta desconhecida deixa o resultado pendente. A confirmação repete ambos mesmo se inventário ou validade mudarem; uma alteração da quantidade não prova sucesso. Pedidos pendentes antigos preservam a omissão original de credit_id. Após um resultado definitivo, o ID escolhido é apagado e não entra nos instantâneos de quota, histórico público ou saída de auditoria. Credenciais, respostas brutas e perfis do fornecedor não são registados. Eliminar a conta remove definições e histórico.

As API de navegador para administradores são GET /api/accounts/{id}/resets (definições e histórico), GET /api/accounts/{id}/resets/cards (lista normalizada), PUT /api/accounts/{id}/resets (guardar) e POST /api/accounts/{id}/resets/consume ou POST /api/accounts/{id}/resets/retry (usar ou confirmar). Exigem sessão de navegador e funções do espaço; chaves de gateway não autorizam acesso. A leitura reutiliza verificações de credenciais, proxy e ciclo de vida e exclui identificadores de perfil, avatares e respostas brutas. O contrato interno pode mudar; testes sintéticos não validam elegibilidade real nem resgates em produção.

Alterações e usos manuais bem-sucedidos são auditados; resultados automáticos ficam num histórico limitado.

Armazenamento e atualização de credenciais

O esquema consolidado cria contas de assinatura com área de trabalho e registros de afinidade de conta limitados. Os tokens de acesso, atualização e ID são criptografados com AES-256-GCM e dados autenticados com a conta. A instância cria um privado de 32-byte credentials.key ficheiro ao lado da sua base de dados. A chave não é uma senha de configuração e não necessita de uma entrada manual.

Faça backup da base de dados e credentials.key Juntos após parar a instância. Um banco de dados de contas existente não começará com uma chave em falta, inválida ou descomprometida. Não substitua a chave para recuperar o acesso. A criptografia protege o conteúdo credencial em uma cópia somente de banco de dados; o acesso ao banco de dados e a chave permite a descriptografia.

SubLane é o único proprietário de atualização. Ele serializa a atualização credencial com alterações de administrador e persiste em rotacionar os tokens antes de publicá- los para requisições. Os itens perto da atualização de expiração antes da utilização. Um 401 inicial permite uma atualização e uma reautorização na mesma conta; as rejeições simultâneas de um token antigo reutilizam a credencial já atualizada. Os resultados mais antigos no voo não podem invalidar uma atualização ou reautorização posterior.

Contrato de passagem

Todas as rotas de gateway requerem uma SubLane chave do portador, independentemente dos cookies do navegador:

HTTP Os pedidos devem incluir a entrada completa. HTTP previous_response_id é rejeitado em vez de silenciosamente perder o contexto porque o Codex HTTP O backend é apátrida. WebSocket as continuações usam o histórico local de conexão limitado; IDs de continuação desconhecidos requerem a entrada completa da transcrição. WebSocket A vez verifica de novo a chave e a activação dos membros. Uma chave revogada não pode iniciar uma nova mudança numa ligação existente.

A afinidade da conta é explorada com a chave membro, grupo e cliente sessão/cache-prompt, mantida durante 24 horas de atividade, e limitada a 4.096 ligações. Os pedidos nativos usam uma ligação entre fornecedores; os pedidos legendários/prefixos explícitos mantêm as ligações específicas do provedor. Novas sessões distribuem através de contas elegíveis, relatando o modelo solicitado dentro do seu pool, respeitando a concorrência por conta e o arrefecimento. Os pedidos sem sessão seleccionam independentemente sem criar afinidade. As sessões existentes falham quando a sua conta é desactivada ou removida em vez de mudarem de identidade. Para uma alteração intencional do modelo, o histórico portátil completo pode seleccionar uma conta de suporte se a conta original não puder servir o novo modelo; as continuações do provedor permanecem fixas. Veja a opção Veja a opção. roteamento do modelo. Reinicie a conversa após outras alterações intencionais da conta. Repetir um pedido nunca a move para outra conta automaticamente.

Cada espaço de trabalho permite por predefinição 128 operações, incluindo pedidos em espera e metadados partilhados, oito ligações WebSocket, 30 minutos por pedido ou turno e cinco minutos para cabeçalhos de inferência. Pedidos e contexto reconstruído têm limite de 128 MiB; respostas e eventos, 8 MiB cada. A leitura do corpo tem prazo de 30 segundos e a descoberta partilhada, 45 segundos. São limites de recursos, não garantias de desempenho. Consulte implementação e funcionamento dos grupos. Limites dos membros: controlos da equipa.

As credenciais do fornecedor, os cookies do navegador, os cabeçalhos arbitrários dos clientes e os corpos de erro brutos do provedor não são encaminhados para os membros. As chaves do portador do cliente são substituídas pela credencial inicial seleccionada. A aplicação não regista as chamadas, respostas, tokens de acesso, tokens de atualização, ou OAuth URLs de retorno de chamadas.

Limite de verificação

Testes automatizados usam bases de dados temporárias, credenciais sintéticas e upstreams falsos locais. Eles cobrem OAuth propriedade/expiração/repetição, criptografia e falta de correspondência de chaves, atualização da serialização, identidade imutável, afinidade da conta, isolamento de papel/proprietário, cancelamento de streaming, SSE reparação da conclusão, e WebSocket revogação entre turnos.

Um teste de integração opt-in executa um instalado Codex CLI com um novo lar de processo infantil, sem credenciais herdadas, e uma resposta de modelo sintético local:

SUBLANE_TEST_CODEX=1 go test ./internal/server -run TestCodexCLIProtocol -count=1 -v

Codex CLI 0.152.1 passou ambos HTTP/SSE e WebSocket os modos contra o montante sintético. A autorização de subscrição real e as solicitações de modelos ao vivo requerem uma conta de teste explicitamente autorizada. A aplicação real do ambiente de trabalho ainda não foi validada; os testes de configuração e protocolo partilhados por si só não estabelecem a compatibilidade do ambiente de trabalho ao vivo.

Antes da atualização v7, uma visualização local do arm64 do macOS (CLIProxiAPI v6.10.9, Go 1.26.0, binário de produção, uma conta sintética criptografada) mediu 23.376 KiB RSS, aproximadamente 22,8 MiB, após cerca de doze minutos inativos em 2026-09-19. Esta é uma observação ociosa; modelos reais, concurrância, tamanho de carga útil e uso de memória de mudança de plataforma. Docker Compose configuração validada localmente, mas o Docker o daemon não estava disponível para uma compilação de imagens local.

Referência da execução

SubLane utiliza executores públicos e tradutores da CLIProxiAPI v8.0.35 internal/upstream. SubLane possui autorização, armazenamento credencial criptografado, atualização, seleção de conta e gateway público. SDK roda como um registro executor privado sem credenciais ao vivo, um observador sem operação, rotas loopback bloqueadas e atualização automática desabilitada. Veja arquitetura para o limite de execução e configuração do provedor para as etapas de conexão do provedor. Este guia de autorização e detalhes de cota descrever Codex.