Catálogos de modelos

Úselo cuando la lista de modelos esté vacía o necesite controlar los modelos disponibles. Un modelo mostrado en su pool es suficiente para tu primera petición.

SubLane descubre los ID de modelo por cuenta de suscripción y deriva el catálogo de cada grupo a partir de sus cuentas habilitadas. Las listas permitidas de grupos siguen siendo una política propiedad del administrador; el descubrimiento nunca los reemplaza. Un modelo informado describe el soporte ascendente, no la cuota restante ni una prueba de generación exitosa.

Ejemplo de catálogo de modelos con ID de modelos sintéticos:

Sincronización y almacenamiento

La importación de cuentas, la finalización OAuth y la reautorización inician el descubrimiento después de que se hayan guardado las credenciales. La reautorización borra el catálogo anterior incluso si el token enviado no se modifica. Las cuentas existentes descubren con pereza cuando se lee su catálogo o grupo, o antes de su primera solicitud de modelo. Al volver a habilitar una cuenta se comprueba si es necesario actualizar el catálogo guardado. Verificar conexión y Actualizar modelos comparten la misma operación de descubrimiento.

El esquema consolidado almacena una instantánea del modelo JSON limitada y una revisión del ciclo de vida en cada cuenta. Una instantánea contiene ID de modelo nativo ordenados y deduplicados, el último momento de observación exitoso y un marcador de fuente de descubrimiento. El marcador incluye la versión del cliente Codex y una revisión del adaptador; La actualización de ese contrato actualiza las instantáneas más antiguas o sin marcar, independientemente de su antigüedad. Cada cuenta está limitada a 512 ID de modelo de como máximo 128 caracteres ASCII; no se almacenan instrucciones, manifiestos o credenciales ascendentes. Una instantánea nula significa soporte desconocido. Una lista vacía recuperada correctamente es un catálogo vacío conocido.

Las instantáneas se mantienen actualizadas durante 15 minutos. Una lectura obsoleta devuelve el valor guardado e inicia una actualización en segundo plano compartida. No hay sondeos ascendentes periódicos mientras está inactivo. Las solicitudes en frío también se unen a una actualización cuando cambia el marcador de fuente de descubrimiento. Una actualización de actualización fallida puede conservar capacidades conocidas anteriormente, pero un catálogo obsoleto no puede demostrar que un modelo no listado no sea compatible. La actualización manual tiene un tiempo de reutilización de cinco segundos; las actualizaciones fallidas conservan la última instantánea exitosa y retroceden durante 30 segundos. Las observaciones fallidas nunca cambian su marca de tiempo. Después de 24 horas, la instantánea anterior permanece visible para los administradores, pero se excluye de los modelos publicitados y enrutables hasta que se actualice. El estado de actualización y el retroceso son procesos locales; las instantáneas exitosas sobreviven a los reinicios.

Se ejecutan como máximo dos descubrimientos simultáneos, dentro de la capacidad del espacio de trabajo: 128 operaciones por defecto, configurable con SUBLANE_GATEWAY_CAPACITY. Los lectores de la misma cuenta y revisión comparten la operación, con contexto del proceso y plazo de 45 segundos. Desconectar el navegador solo cancela su espera. El descubrimiento inicial también tiene un presupuesto total de 45 segundos. Al cerrar, se cancelan y esperan los trabajadores antes de cerrar SQLite; un catálogo vigente no requiere consulta remota.

Las escrituras condicionales rechazan los resultados de una autorización obsoleta, una cuenta deshabilitada/eliminada o una revisión anterior del ciclo de vida. Discovery captura la versión del tiempo de ejecución Codex una vez; Los resultados de una versión reemplazada durante la solicitud de red se descartan y las instantáneas conservan la versión realmente enviada ascendente. La política de versiones y la sincronización automática de versiones estables se gestionan en Ajustes del sistema. Las subvenciones del grupo, la membresía, la política y las instantáneas persistentes se leen nuevamente en una SQLite transacción antes de publicar el resultado del grupo. Los modelos eliminados del grupo no pueden filtrarse a través de una actualización iniciada antes de la edición.

Catálogos de pools y enrutamiento

El catálogo de grupo efectivo es la unión deduplicada de instantáneas de cuentas utilizables, filtradas por la lista de modelos permitidos exactos del grupo. Se excluyen las cuentas deshabilitadas y que requieren reautorización. El tiempo de reutilización, la simultaneidad y la cuota de suscripción restante siguen siendo preocupaciones de tiempo de ejecución independientes; un modelo listado no promete un espacio de solicitud disponible de inmediato.

Los catálogos de cuentas, grupos y claves usan ID nativos sin prefijos adicionales. Participan recursos aptos de Codex, Claude, Antigravity, Grok Build y API compatibles con OpenAI según el enrutamiento y respaldo del grupo. El catálogo público omite modelos ocultos. Los ID visibles idénticos se fusionan; owned_by es sublane cuando varios proveedores ofrecen una ruta visible. Las variantes de razonamiento conservan el ID completo para permisos y usan el modelo base descubierto para comprobar capacidades. El límite agregado es de 4.096 ID. Los prefijos de proveedor heredados siguen admitidos y restringen los candidatos al indicarlos explícitamente.

Antes de la inferencia, el descubrimiento calienta los catálogos faltantes o obsoletos para los proveedores elegibles en el grupo; un prefijo heredado explícito limita el descubrimiento a ese proveedor. La compactación calienta y selecciona Codex cuentas únicamente. El programador vuelve a verificar la política del grupo y las instantáneas de las cuentas en su transacción de selección, filtra las cuentas que no admiten el modelo solicitado y luego aplica las reglas existentes de concurrencia, enfriamiento y rotación. Vuelve un modelo conocido no compatible 404 model_not_available; Vuelven las capacidades desconocidas o superadas 503 model_catalog_unavailable con una sugerencia de reintento. Otras cuentas conocidas y elegibles aún pueden servir como modelo cuando falla el descubrimiento de un par.

Las solicitudes nativas seleccionan entre las cuentas disponibles permitidas que informan el modelo. La selección y reserva de cuenta comparten la transacción existente y el bloqueo del proceso. Las conversaciones nativas existentes mantienen una única cuenta vinculante entre proveedores. Cuando el cliente cambia explícitamente los modelos y envía el historial portátil completo, una cuenta que no admita el nuevo modelo puede ser reemplazada por una cuenta elegible en el mismo grupo. Si la cuenta actual admite el nuevo modelo, permanece seleccionada. La saturación, el tiempo de reutilización, la eliminación, la desactivación y la pérdida de soporte para un modelo sin cambios nunca provocan una conmutación por error automática.

Las continuaciones del proveedor conservan su cuenta: las referencias de respuestas anteriores o conversaciones almacenadas, las referencias de elementos, el razonamiento/compactación cifrados, el pensamiento firmado Claude y el contenido/firmas Gemini almacenados en caché no pueden autorizar un cambio de modelo. Los giros incrementales WebSocket no pueden cambiar el modelo; enviar un historial completo independiente response.create girar en su lugar. HTTP previous_response_id sigue siendo rechazado; enviar entrada completa sin esa referencia. Devolución de solicitudes vinculadas no admitidas conversation_account_unavailable.

El existente account_affinity La tabla almacena el enrutamiento nativo bajo un auto alcance y registra el modelo normalizado a través de una migración aditiva. Los enlaces actualizados con metadatos de modelos desconocidos permanecen fijados hasta que una solicitud admitida registre el modelo; inicie una nueva conversación si no está disponible. Se adopta un único enlace de proveedor heredado sin cambiar la cuenta o el hash de la sesión ascendente; múltiples enlaces heredados en la misma sesión siguen siendo ambiguos. Las solicitudes explícitas de prefijo heredado conservan sus enlaces específicos del proveedor solo cuando ese proveedor está activo. No se agrega ningún enlace permanente entre clave API y cuenta.

API de interfaz de usuario y navegador

• Cuentas → Modelos muestra los últimos ID de modelo informados de una cuenta, el tiempo de observación y el estado de sincronización, con actualización manual.
• Grupos de recursos → Modelos muestra el catálogo de grupos filtrado por políticas y derivado automáticamente. El editor de grupos continúa administrando la lista de permitidos por separado.
• API claves → Modelos muestra el catálogo de pool autorizado de la clave actual. Importar a CC Switch proporciona un selector de modelos con capacidad de búsqueda utilizando ese mismo catálogo.

El acceso al catálogo personal vuelve a verificar la habilitación, caducidad, revocación y acceso al grupo de claves. Los administradores no pueden utilizar el punto final personal para inspeccionar la clave de otro propietario. Responses contiene metadatos del modelo y recuentos de actualización agregados, no ID, nombres o credenciales de cuentas de suscripción. Una respuesta parcial del grupo expone que algunos catálogos de cuentas siguen siendo desconocidos en lugar de tratarlos como compatibles con todos los modelos.

Límite de verificación

Las pruebas automatizadas utilizan cuentas sintéticas y upstreams locales falsos. Cubren la persistencia del reinicio, la autorización de catálogos vacíos, la retención/retraso de actualización fallida, las carreras de autorización y revocación de grupos, la cancelación/cierre, el enrutamiento de cuentas mixtas, las listas permitidas de grupos, las variantes de pensamiento, la afinidad de conversación, la propiedad de endpoints y la persistencia de esquemas nuevos. Las pruebas de frontend cubren los estados del catálogo, la selección del modelo de teclado y las respuestas obsoletas después de cambios de identidad. Discovery no analiza la generación de modelos y los catálogos ascendentes pueden cambiar entre la sincronización y una solicitud real.

Diagnóstico de disponibilidad del modelo.

Los cuadros de diálogo de modelo de clave personal y de grupo le permiten inspeccionar una identificación de modelo nativo. Los resultados muestran la elegibilidad local para una nueva solicitud, los motivos de exclusión, el tiempo de observación y los tiempos de reintento conocidos. Los administradores pueden inspeccionar los detalles a nivel de cuenta; Las claves personales reciben agregados sin identidades de suscripción. Las comprobaciones no ejecutan inferencias, actualizan metadatos, reservan espacios ni crean enlaces de conversación. Los datos desconocidos/obsoletos permanecen desconocidos. La elegibilidad no garantiza el éxito ascendente; Los límites de claves, miembros y asignaciones aún se aplican y las conversaciones existentes mantienen su cuenta.

Pruebas manuales de modelos

Los administradores pueden abrir la lista de modelos de una cuenta o un canal API y seleccionar Probar junto a un modelo. Cada prueba envía una solicitud de generación real, consume cuota del proveedor y ocupa capacidad, con un tiempo de espera de 30 segundos. El resultado muestra el éxito o un error sin datos sensibles y la duración en milisegundos para ese recurso en ese momento. No comprueba el acceso de una clave personal al grupo ni su asignación de uso. El diagnóstico local de disponibilidad descrito arriba no envía solicitudes de generación.

La visibilidad del proveedor y la capacidad de enrutamiento son independientes: los modelos ocultos no aparecen en los catálogos del navegador ni en GET /v1/models, pero una solicitud que indique explícitamente su ID puede enviarse si la cuenta los admite y la política actual lo permite. Los modelos ocultos también están sujetos a permisos, cuota y límites de capacidad.

Visibilidad de modelos internos

Los modelos de Antigravity con isInternal y los de Grok Build con hidden o _meta.hidden siguen siendo invocables. Los diálogos autenticados de cuentas, grupos de recursos y claves personales los muestran después de los modelos visibles, con una etiqueta de modelo oculto y orden alfabético en cada grupo. GET /v1/models y el selector de CC Switch los omiten. Las llamadas explícitas siguen comprobando políticas, permisos, cuotas, asignaciones, capacidad, enfriamiento y estado de la cuenta. Grok lee el catálogo de la suscripción autenticada y normaliza los alias a los ID nativos de enrutamiento. Los catálogos antiguos se actualizan automáticamente para obtener los metadatos de visibilidad.