Catálogos de modelos

Use isto quando a lista de modelos estiver vazia ou tiver de controlar os modelos disponíveis. Um modelo mostrado na suo pool é suficiente para o seu primeiro pedido.

SubLane descobre IDs de modelos por conta de assinatura e deriva o catálogo de cada pool de suas contas habilitadas. Listas de allowlists de agrupamento permanecem como política de administração; a descoberta nunca as substitui. Um modelo relatado descreve suporte a montante, não permanecendo quota ou um teste de geração bem sucedido.

Catálogo de modelos de exemplo com IDs de modelos sintéticos:

Sincronização e armazenamento

Importação da conta, OAuth conclusão e reautorização iniciam a descoberta após as credenciais terem sido salvas. A reautorização limpa o catálogo antigo, mesmo que o token submetido esteja inalterado. As contas existentes descobrem vagamente quando seu catálogo ou pool é lido, ou antes de seu primeiro pedido de modelo. Re- endereçar uma conta verifica se seu catálogo salvo precisa ser refrescante. Verificar a ligação e Atualizar modelos partilhar a mesma operação de descoberta.

O esquema consolidado armazena um limite JSON snapshot do modelo e revisão do ciclo de vida em cada conta. Um snapshot contém IDs de modelo nativo ordenados e desduplicados, o último tempo de observação bem sucedido e um marcador de fonte de descoberta. O marcador inclui Codex versão do cliente e uma revisão do adaptador; a actualização do contrato actualiza instantâneos antigos ou não marcados, independentemente da sua idade. Cada conta está limitada a 512 IDs de modelo de, no máximo, 128 caracteres ASCII; não são guardadas instruções, manifestos ou credenciais a montante. Um instantâneo nulo significa suporte desconhecido. Uma lista vazia recuperada com sucesso é um catálogo vazio conhecido.

As imagens são recentes durante 15 minutos. Uma leitura defasada devolve o valor gravado e inicia uma actualização de fundo partilhada. Não existe uma sondagem periódica a montante enquanto não estiver em marcha lenta. As requisições frias também se juntam a uma actualização quando o marcador de código da descoberta muda. Uma actualização falhada poderá reter as capacidades anteriormente conhecidas, mas um catálogo obsoleto não pode provar que um modelo não está listado não é suportado. A actualização manual tem um arrefecimento de cinco segundos; as reactualizações falhadas retêm a última captura de ecrã bem sucedida e recuam por 30 segundos. As observações falhadas nunca alteram a sua hora de gravação. Após 24 horas, a captura de fotografias antiga permanece visível para os administradores, mas é excluída dos modelos anunciados e routáveis até que sejam actualizados. O estado de actualização e o recuo são locais do processo; as instantâneos bem sucedidos sobrevivem às reiniciagens.

Executam-se no máximo duas descobertas de modelos simultâneas dentro da capacidade do espaço de trabalho: 128 operações por predefinição, configuráveis com SUBLANE_GATEWAY_CAPACITY. Os leitores da mesma conta e revisão partilham uma operação com contexto do processo e prazo de 45 segundos. Desligar o navegador apenas cancela a sua espera. A descoberta inicial também tem 45 segundos no total. O encerramento cancela e aguarda os trabalhadores antes de fechar SQLite; catálogos atuais não exigem acesso remoto.

O Conditional escreve os resultados de rejeição de uma autorização obsoleta, de uma conta desactivada/ deletada ou de uma revisão anterior do ciclo de vida. Discovery captura o tempo de execução Codex Uma vez; os resultados de uma versão substituída durante a solicitação de rede são descartados, e os instantâneos mantêm a versão realmente enviada a montante. A política de versão e a sincronização automática de liberação estável são gerenciadas em configurações do sistema. Bolsas de grupo, adesão, política e instantâneos persistentes são lidos novamente em um SQLite transação antes de publicar um resultado do pool. Os modelos removidos do pool não podem vazar através de uma atualização iniciada antes da edição.

Catálogos de pool e roteamento

O catálogo do pool eficaz é a união deduplicada de instantâneos de contas utilizáveis, filtrada pela lista de permissões exatas do modelo do pool. As contas desactivadas e reautorizadas são excluídas. Arrefecer, concordar e a quota de assinatura restante permanecem preocupações de tempo de execução separadas; um modelo listado não promete uma ranhura de solicitação imediatamente disponível.

Os catálogos de contas, grupos e chaves usam ID nativos sem acrescentar prefixos. Recursos elegíveis Codex, Claude, Antigravity, Grok Build e API compatíveis com OpenAI participam segundo o encaminhamento e a alternativa do grupo. O catálogo público omite modelos ocultos. ID visíveis iguais são agrupados; owned_by é sublane quando vários fornecedores oferecem uma rota visível. Variantes de raciocínio mantêm o ID completo para permissões e usam o modelo base descoberto para verificar capacidades. O limite agregado é de 4.096 ID. Prefixos antigos de fornecedor continuam aceites e restringem os candidatos quando indicados explicitamente.

Antes da inferência, a descoberta aquece os catálogos faltantes/estábulos para os fornecedores elegíveis no pool; um prefixo legado explícito restringe a descoberta para esse provedor. Codex somente contas. O escalonador verifica novamente a política de agrupamento e instantâneos de contas em sua transação de seleção, filtra contas que não suportam o modelo solicitado, então aplica as regras de concorrência, descompressão e rotação existentes. 404 model_not_available; capacidades desconhecidas ou de sobre-idade retornam 503 model_catalog_unavailable com uma dica de repetição. Outras contas elegíveis, conhecidas, podem ainda servir um modelo quando a descoberta de um par falha.

As solicitações nativas selecionam entre as contas disponíveis permitidas que reportam o modelo. A seleção da conta e a reserva compartilham a transação existente e o bloqueio do processo. As conversas nativas existentes mantêm uma única conta vinculada entre os provedores. Quando o cliente altera explicitamente os modelos e envia o histórico portátil completo, uma conta que não suporte o novo modelo pode ser substituída por uma conta elegível no mesmo pool. Se a conta atual suportar o novo modelo, ela permanece selecionada. Saturação, resfriamento, remoção, desativação e suporte perdido para um modelo inalterado nunca causa falha automática.

Provider continuações manter sua conta: anterior-resposta ou armazenado-conversa referências, referências de item, raciocínio/compação criptografado, assinado Claude pensando e Gemini O conteúdo/assinaturas em cache não pode autorizar uma mudança de modelo. Incremental WebSocket voltas não podem alterar o modelo; envie uma história completa independente response.create Vira em vez disso. HTTP previous_response_id permanece rejeitado; envie a entrada completa sem essa referência. Requisitos vinculados não suportados retornam conversation_account_unavailable.

A existência account_affinity table stores roteamento nativo sob um auto escopo e registra o modelo normalizado através de uma migração aditiva. As ligações atualizadas com metadados desconhecidos do modelo permanecem presas até que uma solicitação suportada registre o modelo; inicie uma nova conversa se isso não estiver disponível. Uma única vinculação do provedor legado é adotada sem alterar a conta ou o hash de sessão a montante; várias vinculações legados sob a mesma sessão permanecem ambíguas. As solicitações legend- prefix explícitas mantêm suas vinculações específicas do provedor apenas quando esse provedor estiver ativo. API- chave/ligação de conta é adicionado.

IU e APIs de navegador

• Contas → Modelos mostra os últimos IDs de modelo reportados de uma conta, tempo de observação e estado de sincronização, com atualização manual.
• Grupos de recursos → Modelos mostra o catálogo de pools automaticamente derivado, filtrado por políticas. O editor de pools continua a gerenciar a lista de permissões separadamente.
• API chaves → Modelos mostra o catálogo de agrupamento autorizado da chave atual. Importar para CC Switch fornece um seletor de modelo pesquisável usando esse mesmo catálogo.

O acesso ao catálogo pessoal verifica de novo a activação da chave, a expiração, a revogação e o acesso ao conjunto. Os administradores não podem usar o endpoint pessoal para inspeccionar a chave de outro proprietário. Responses contém metadados do modelo e contagens de frescura agregadas, não IDs de contas de subscrição, nomes ou credenciais. Uma resposta parcial do pool expõe que alguns catálogos de contas permanecem desconhecidos em vez de tratá- los como suportando todos os modelos.

Limite de verificação

Os testes automatizados usam contas sintéticas e upstreams falsos locais. Eles cobrem a persistência do reinício, catálogos vazios autoritários, retenção/backoff de atualização falhada, autorizações e corridas de revogação do pool, cancelamento/shutdown, roteamento de contas mistas, listas de permissões de pool, variantes de pensamento, afinidade de conversação, propriedade de endpoint e persistência de novo- schema. Os testes frontend cobrem estados de catálogo, seleção de modelos de teclado e respostas antigas após alterações de identidade. A descoberta não permite a geração de modelos de sondas, e catálogos upstream podem mudar entre sincronização e uma solicitação real.

Modelo de diagnóstico de disponibilidade

As janelas de conjuntos e modelos de chaves pessoais permitem- lhe inspecionar um ID de modelo nativo. Os resultados mostram elegibilidade local para uma nova solicitação, razões de exclusão, tempo de observação e tempos de repetição conhecidos. Os administradores podem inspecionar os detalhes de nível de conta; as chaves pessoais recebem agregados sem identidades de assinatura. As verificações não executam inferências, atualizam metadados, reservam slots ou criam ligações de conversação. Dados desconhecidos/stale permanecem desconhecidos. A elegibilidade não garante o sucesso a montante; os limites de chave, membro e licença ainda se aplicam e as conversas existentes mantêm a sua conta.

Testes manuais de modelos

Os administradores podem abrir a lista de modelos de uma conta ou canal de API e selecionar Testar ao lado de um modelo. Cada teste envia uma solicitação real de geração, consome a cota do provedor e ocupa capacidade, com tempo limite de 30 segundos. O resultado mostra sucesso ou um erro sem dados sensíveis e a duração em milissegundos para esse recurso no momento do teste. Não verifica o acesso de uma chave pessoal ao grupo nem sua alocação de uso. O diagnóstico local de disponibilidade acima não envia solicitações de geração.

A visibilidade definida pelo provedor e o suporte ao roteamento são independentes: modelos ocultos não aparecem nos catálogos do navegador nem em GET /v1/models, mas uma solicitação que informe explicitamente o ID pode ser roteada se a conta oferecer suporte e a política atual permitir. Permissões, cotas e limites de capacidade continuam valendo.

Visibilidade de modelos internos

Os modelos Antigravity com isInternal e Grok Build com hidden ou _meta.hidden continuam disponíveis para chamadas. Os diálogos autenticados de contas, grupos de recursos e chaves pessoais mostram-nos depois dos modelos visíveis, com uma indicação de modelo oculto e ordem alfabética em cada grupo. GET /v1/models e o seletor CC Switch omitem-nos. Os pedidos explícitos continuam sujeitos a políticas, permissões, quotas, alocações, capacidade, períodos de espera e estado da conta. Grok lê o catálogo da assinatura autenticada e normaliza os aliases para ID nativos de encaminhamento. Catálogos antigos são atualizados automaticamente para obter metadados de visibilidade.