Configuração do sistema

Usar isto ao alterar as configurações da instância ou investigar uma Codex, Grok ou Claude problema de compatibilidade de versão. Os padrões são suficientes para iniciar o guia de configuração.

O proprietário da plataforma expande Administração → Configurações do sistema na barra lateral, em seguida, seleciona Fuso horário (/admin/settings/timezone), Codex versão do cliente (/admin/settings/codex), Grok versão do cliente (/admin/settings/grok), ou Claude versão do cliente (/admin/settings/claude). A anterior /admin/settings o endereço redireciona para Codex configurações. Estas configurações aplicam- se a toda a instância; outros administradores e membros da área de trabalho não podem alterá- las. Preferências atalho permanece pessoal: tema, idioma e senha.

Fuso horário da instância

O padrão é UTC. Introduza uma IANA fuso horário, como por exemplo Asia/Shanghai e salvá- lo para mostrar as datas nessa zona através dos espaços de trabalho. Cada margem de recursos escolhe um relógio de redefinição diário ou uma data e um relógio mensal na zona selecionada. O padrão é a meia- noite (o primeiro dia para as regras mensais). O saldo mostra a hora exata de redefinição seguinte; as mudanças de horário de verão são tratadas pelas regras do fuso horário. Limites de solicitação de minutos continuam a usar janelas fixas de sessenta segundos.

A alteração produz efeito imediatamente. O uso de licenças existentes é contado a partir da hora de início de cada pedido dentro da janela seleccionada recentemente, de modo que a alteração da zona não limpa silenciosamente a utilização actual. As revisões de alocação já programadas mantêm a sua hora de activação gravada anteriormente. Os resumos diários operacionais e a grelha de actividade horária permanecem agrupados por UTC; as suas etiquetas UTC permanecem visíveis. A configuração é guardada em settings['instance.time_zone'] e auditado com a mudança.

Codex versão do cliente

A versão efetiva é escolhida nesta ordem:

1. Uma versão manual explícita, se configurada.
2. A última versão estável sincronizada, desde que seja pelo menos o padrão embutido.
3. O padrão incorporado (0.155.1).

Utilização de versões manuais major.minor.patch sem uma v prefixo ou sufixo de pré- lançamento. Limpe a entrada para retornar à seleção automática. Um pino manual pode selecionar uma versão antiga deliberadamente; a sincronização automática nunca diminui a versão estável lembrada ou a linha de base incorporada. A página mostra a versão eficaz, sua fonte, a última versão sincronizada e os timestamps de verificação.

Siga automaticamente as versões estáveis está activado por omissão. Na inicialização, o serviço verifica se terminou e, de outro modo, retoma o calendário gravado. As verificações bem- sucedidas agendam a próxima tentativa seis horas depois. As verificações não foram bem- sucedidas e voltaram a tentar ao fim de quinze minutos, respeitando os limites de taxa a montante mais longos. A desligar as verificações automáticas cancela- se enquanto se aguarda o trabalho automático e mantém a versão conhecida. Não impede uma explícita Verifica agora. Agir ou substituir um pino manual.

As verificações manuais partilham uma operação de voo e têm um arrefecimento de 60 segundos após uma tentativa concluída; os limites de taxa de montante ou uma falha de armazenamento podem extendê- lo. Os chamadas desconectados não cancelam as verificações partilhadas. O encerramento cancela e junta- se a todas as verificações antes SQLite Fecha.

O serviço lê apenas o oficial openai/codex GitHub libera metadados. Ele aceita stable rust-v… etiquetas e exclui rascunhos e pré- lançamentos. O endpoint de última geração tem um limite de resposta de 2 MiB; se apontar para outro componente, uma página secundária é limitada a trinta versões e 16 MiB, decodificada uma versão de cada vez. Verificações têm um prazo de trinta segundos, rejeitam redirecionamentos e não enviam credenciais de assinatura ou GitHub token. Falhas de rede, respostas inválidas e falhas de persistência retêm a versão anterior eficaz. Nenhum binário é baixado ou instalado, e a dependência CLIProxiAPI está inalterada.

Exemplo Codex configurações de versão com tempos de verificação de amostra:

Grok versão do cliente

Grok tem uma política de versão independente em Administração → Configurações do sistema → Grok versão do cliente. Ele usa a mesma ordem de seleção, sobreposição manual, programação automática de seis horas, retenção de falhas, arrefecimento e comportamento de desligamento descrito acima. 1.0.50.

Os controlos devem ser lidos como oficiais @xai-official/grok pacote npm's latest dist-tag. As tags alfa e as strings de versão pré-lançamento estão excluídas. A resposta é limitada a 64 KiB, com um prazo de trinta segundos e redirecionamentos rejeitados. Nenhuma credencial de assinatura é enviada e nenhum binário CLI ou SDK a dependência está instalada.

A versão eficaz controla x-grok-client-version e a correspondência User-Agent ligado Grok pedidos de inferência de assinatura e faturamento. As versões mais antigas do cliente podem ser rejeitadas pelo Grok 'proxy' de chat com HTTP 426 mesmo enquanto a descoberta do modelo ou as leituras de quota são bem sucedidas. Se as verificações de versão não chegarem ao npm, use Verifica agora. depois que a conectividade recupera ou define uma versão estável verificada manualmente. Um pino manual tem prioridade sobre resultados automáticos posteriores.

Claude versão do cliente

Claude tem um separado Claude versão do cliente página at /admin/settings/claude, com os mesmos comandos manuais, verificações de seis horas, arrefecimento, retenção de falhas e reinício do comportamento. 2.1.287.

Os controlos devem ser lidos como oficiais @anthropic-ai/claude-code pacote npm's estável Dist- tag. latest e next canais podem ser mais novos; eles não são substitutos quando stable não está disponível. As verificações têm o mesmo limite de resposta 64 KiB e o prazo de trinta segundos que Grok e não instalar executáveis.

Cada pedido de inferência captura uma versão. O público SDK gera seu Agente de Usuário, faturamento de corpo cc_version e assinatura CCH de uma configuração imutável para essa versão. Atualizar a política afeta novas solicitações, enquanto uma solicitação já em execução mantém sua versão original. As pesquisas de modelos e quotas também usam a identidade selecionada do cliente. SDK A loja credencial permanece vazia e os ouvintes bootstrap da versão são fechados imediatamente.

O Opus 5.5 e o Sonnet 5.5 usam seus controles de pensamento e esforço adaptativos suportados. Chat Completions e Responses preservar limites explícitos de saída. OpenAI reasoning_effort: none seleciona low esforço em Opus 5.5, cujo pensamento está sempre em; no Sonnet 5.5 seleciona between_tools, sem pensar na frente. orçamentos de pensamento manual nativos e escolhas de ferramentas forçadas que esses modelos não suportam são rejeitados antes do provedor IO. Pedidos adaptativos nativos mantêm sua intenção de exibição. Sincronização de versões atualiza metadados do cliente; futuras alterações de protocolo ainda podem exigir alterações de adaptador.

Comportamento de persistência e solicitação

Limites independentes JSON valores em settings['codex.version'], settings['grok.version'], settings['claude.version'] Armazenar a configuração de cada provedor, última versão bem sucedida e tentativa de cronometragem. Codex as configurações retêm a sua chave e comportamento originais. Não é necessária nenhuma nova tabela ou migração. As alterações de configuração bem- sucedidas e as suas settings.update evento de auditoria em conjunto. As observações de lançamento automático não criam eventos de auditoria de administrador. A versão em tempo de execução é publicada apenas após a persistência ter sucesso.

Codex A descoberta do modelo, metadados de quota e encaminhamento usam a versão eficaz. Cada requisição de descoberta captura- a uma vez para a consulta, cabeçalhos e marcador de origem persistente. A alteração da versão invalida a frescura do catálogo: a próxima requisição de catálogo ou modelo desencadeia a redescoberta. Um resultado em voo de uma versão substituída é descartado. Outros provedores e listas de allowlists de modelos de administrador são inalterados. Veja catálogos de modelos para o comportamento de dados obsoletos e de encaminhamento.

Navegador API

Todos os terminais requerem a sessão do proprietário da plataforma. Mutações também requerem a origem exata. As versões inválidas retornam 400; check-return 429 com Retry-After; falhas de lançamento ou persistência retornam erros 503 higienizados. Uma versão de lançamento relatada é metadados de compatibilidade, não prova de que cada conta suporta cada modelo nessa versão.

Métricas Prometheus

Um SUBLANE_METRICS_TOKEN aleatório separado de 32–128 caracteres ASCII visíveis ativa /metrics. Envie Authorization: Bearer <token>; sessões, chaves do gateway e parâmetros URL não autenticam. Sem configuração retorna 404.

Contadores globais por resultado fixo, histogramas de duração/primeira saída conhecida, concessões de inferência e fila. Latência desconhecida omitida. Contadores sobrevivem à reciclagem do runtime e zeram no reinício; entradas anônimas sem observação são excluídas. Apenas memória, sem SQL, IO de provedor, nomes, conteúdo ou segredos. Desativado na demonstração.