Codex suscripciones y puerta de enlace

Con una clave personal lista, configure su cliente a continuación. Si no tienes uno, completa Primera solicitud o solicite a su administrador un inicio de sesión de miembro.

Configuración del cliente

Cree una clave personal API en Claves API. Utilice el origen de la instancia más /v1 como URL base. Configurar un ID de modelo devuelto por GET /v1/models.

Colocar SUBLANE_API_KEY en el entorno del proceso del cliente. Fusionar las siguientes configuraciones en el nivel de usuario ~/.codex/config.toml, reemplazando los valores existentes coincidentes:

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

Utilice la URL real de su instancia, con HTTPS para implementaciones de red. Para transporte HTTP/SSE, establezca supports_websockets = false. Codex La CLI y el escritorio deben leer la configuración de nivel de usuario prevista. Una aplicación de escritorio que ya se está ejecutando no hereda automáticamente las variables de entorno exportadas en otra terminal; reinícielo en un entorno donde la clave esté disponible.

La página de claves API proporciona un fragmento de configuración sin incrustar ni conservar el secreto. También ofrece una opción CC Switch importar que pasa la clave elegida a la aplicación instalada localmente después de una preparación explícita. CC Switch genera su propia Codex configuración del archivo de autenticación; no conserva la variable de entorno o la configuración WebSocket en el fragmento del manual anterior. ver el oficial configuración avanzada y autenticación orientación para la configuración del cliente y el almacenamiento de credenciales.

Los catálogos de cuentas se almacenan en caché y sobreviven a los reinicios. El descubrimiento, la agregación de grupos y la selección de cuentas basadas en modelos se describen en catálogos de modelos.

Después de la configuración: envía un mensaje y verifica la respuesta, luego continúa con uso diario. Los detalles de cuenta, cuota y protocolo que aparecen a continuación son referencias para más adelante.

Agregar una cuenta

Inicie sesión como administrador, abra Cuentasy elige Agregar cuenta. Los miembros no pueden acceder a los puntos finales ni a las credenciales de administración de suscripciones.

• Autorización del navegador: asigne un nombre a la cuenta, inicie la autorización y abra el enlace OpenAI. Después de iniciar sesión, copie el archivo completo http://localhost:1455/auth/callback?... dirección desde la barra de direcciones del navegador y péguela en SubLane. Se espera un error de conexión del host local en este punto: SubLane intencionalmente no abre otro detector de devolución de llamada. Este flujo de retorno manual funciona para implementaciones locales y remotas.
• Importar autenticación.json: elija un archivo de credenciales de suscripción Codex o pegue su JSON. Tanto el CLI anidado tokens Se aceptan la estructura y el formato de token plano Codex. Se rechazan las claves oficiales API. SubLane nunca escanea los directorios de clientes locales; solo lee el contenido enviado explícitamente por el administrador. Se descartan las configuraciones de endpoint/proxy importadas.

La autorización/importación de la cuenta inicia el descubrimiento del modelo automáticamente. Usar Verificar conexión para actualizar y conservar el catálogo de modelos de la cuenta, o abrir Modelos para inspeccionarlo. Se muestran las credenciales importadas No verificado hasta su uso exitoso. El menú de la cuenta permite habilitar/deshabilitar, reautorizar y eliminar. La reautorización debe conservar la misma identidad de cuenta ascendente. Al eliminar una cuenta, se eliminan sus credenciales almacenadas en SubLane; no revoca el inicio de sesión de ChatGPT.

Codex el descubrimiento de modelos envía la versión efectiva del cliente de la instancia en la consulta del catálogo y en los encabezados de solicitud. Los administradores pueden configurarlo en Administración → Configuración del sistema: una versión explícita tiene prioridad sobre la última versión estable oficial sincronizada, con 0.155.1 como respaldo incorporado. Las comprobaciones de liberación automática se realizan de forma predeterminada cada seis horas. Esto cambia los metadatos del protocolo sin instalar Codex ni actualizar el SDK integrado; ver Ajustes del sistema.

El catálogo ascendente depende de esa versión: una versión obsoleta puede devolver HTTP 200 con solo modelos ocultos o un catálogo visible parcial, lo que produce un catálogo vacío o incompleto. /v1/models lista después del filtrado de visibilidad. Los catálogos persistentes incluyen la versión de descubrimiento real, por lo que cambiar la versión efectiva activa la actualización en la siguiente lectura del catálogo o solicitud de modelo, incluso cuando sus marcas de tiempo permanecen actualizadas. Cambiar los permisos del grupo no resuelve este problema de compatibilidad.

OAuth los intentos utilizan PKCE, estado aleatorio de 256 bits, una caducidad de diez minutos, un intento activo por sesión del navegador del administrador y un máximo de ocho intentos pendientes. La devolución de llamada está vinculada a la sesión que la inició y consumió antes de intercambiar su código. Cerrar el formulario solicita la cancelación; La caducidad es el recurso alternativo después de una conexión perdida. El estado pendiente OAuth se mantiene solo en la memoria.

Uso de suscripción

La página de cuentas muestra ventanas de cuota, porcentaje restante, cuenta atrás y hora de observación para cuentas Codex habilitadas, además de límites adicionales cuando se notifican. La cantidad de tarjetas es independiente: desconocido y 0 explícito son distintos. Consulte Tarjetas de reinicio para la lista y el uso opcional. Los datos ausentes siguen siendo desconocidos; un fallo conserva la instantánea anterior con aviso. Llegar a la hora de reinicio no confirma la recuperación: actualice el uso.

El adaptador de uso lee https://chatgpt.com/backend-api/wham/usage y el separado https://chatgpt.com/backend-api/wham/rate-limit-reset-credits endpoint, matching the funcionario Codex cliente backend. Ambas solicitudes utilizan la credencial de la cuenta seleccionada, el propietario existente de refresco/retry, la admisión de puerta cerrada, un plazo compartido de 20 segundos, y un límite de 128 KiB por respuesta. Si la solicitud de detalles de la tarjeta de reinicio falla o o omite un recuento, la cuota permanece disponible y cualquier recuento válido de la respuesta del uso se mantiene. SubLane.

El esquema consolidado almacena una cuota fija, normalizada y la instantánea de la tarjeta de reset por cuenta en SQLite. Las instantáneas incluyen el último tiempo de observación exitoso y sobrevivir el proceso se reinicia; eliminar una cuenta cascadas a su instantánea. El proceso mantiene a la mayoría de 100 entradas instantáneas en la memoria y lazily las recarga de SQLite. No se almacenan credenciales ni respuestas de proveedores en bruto en esta tabla.

GET /api/accounts/{id}/usage devuelve una instantánea fresca por hasta dos minutos (o hasta que se reporte un próximo reinicio, si es antes). Una instantánea caducada se devuelve inmediatamente con stale y refreshing banderas mientras un refresco de fondo corre. Una primera embrague sin una instantánea espera el resultado. POST /api/accounts/{id}/usage/refresh evita la frescura y espera el refresco compartido, al tiempo que honra una refrigeración de cinco segundos. Ambas rutas requieren una sesión de administrador habilitada; POST también requiere el origen existente /JSON cheques.

Los calladores actuales de la misma cuenta comparten una operación aguas arriba. Las referencias utilizan la capacidad configurada del espacio de trabajo (128 por defecto, mediante SUBLANE_GATEWAY_CAPACITY) y un plazo de 45 segundos, sobreviven una desconexión del navegador individual, y se cancelan/esperan durante el cierre del proceso. Un refrescante fallido preserva los valores y tiempos anteriores, los marcan el estancamiento y se retroceden durante 30 segundos (o un fallo de entrada más largo, hasta una hora).

El navegador conserva su período de frescura de una hora de duración. Explica el punto final de instantánea local una vez por segundo, mientras que un refresco es activo, parando la terminación o un error de red. La página no encuesta periódicamente al proveedor mientras que ocio. Asignaciones de participación uso configurado token o interno USD presupuestos y cargo reportados uso de la solicitud directamente. Tiempos de observación y tiempo del servidor de respuesta son separados por lo que una instantánea restaurada no reinicia la cuenta atrás de reset. Las cuentas de discapacidad no se queried. El tráfico modelo también calienta la caché de cuota compartida sin esperar. El agotamiento de los límites primarios frescos excluye una cuenta de la nueva selección; conversaciones atadas devuelven un rechazo específico de cuota. selección de cuotas.

Tarjetas de reinicio

Los administradores del espacio de trabajo pueden consultar y usar tarjetas de cuentas Codex habilitadas que no requieran nueva autorización. Los miembros no pueden gestionarlas. El uso programado y el uso al agotar la cuota están desactivados por defecto. Consultar o actualizar la lista no consume tarjetas.

Configurar y usar

1. Abra Cuentas y seleccione la configuración de tarjetas en la tarjeta de la cuenta Codex. Revise la lista, la cantidad disponible y la hora de observación. Una cantidad desconocida no equivale a cero.
2. Active el uso programado, el uso al agotar la cuota o ambos. Para una sola ejecución, elija una fecha y hora futuras; para uso diario, una hora; para uso semanal, un día y una hora. Compruebe la zona horaria de la instancia.
3. Guarde el límite diario compartido (1–100, por defecto 1). Confirme el mensaje de guardado y, si hay programación, la próxima ejecución.
4. Para el uso manual, guarde primero los cambios y elija usar una tarjeta ahora. Cada intento usa como máximo una tarjeta; consulte el resultado en el historial. Abrir la configuración no inicia un canje.

Lista y prioridad de caducidad

La lista muestra nombre, estado, fecha de concesión y caducidad. Distingue tarjetas disponibles, en canje, canjeadas, caducadas, desconocidas y no compatibles; no muestra los ID originales. La marca de próxima tarjeta describe la selección automática, no permite elegir manualmente y se oculta mientras hay un resultado pendiente. Una cantidad positiva no garantiza tarjetas aptas.

Cada nuevo intento manual, programado o por agotamiento vuelve a leer el inventario e incluye credit_id. Solo admite tarjetas disponibles, compatibles y no caducadas. Prioriza la caducidad más próxima y deja las tarjetas sin caducidad para el final. Los empates se resuelven por concesión más antigua y después por orden estable de ID. Si no hay tarjetas aptas o no se puede confirmar el inventario, omite el canje sin delegar la selección al proveedor. Un error inicial se distingue de una lista vacía. Si falla una actualización, conserva la lista anterior con un aviso; vuelva a actualizar las tarjetas.

Programación y límites

El agotamiento se comprueba en segundo plano aproximadamente cada minuto. Requiere datos recientes, una cantidad de tarjetas conocida y positiva y una denegación explícita de la cuota principal. Un 100%, datos desconocidos o un error de red no bastan. Los intentos manuales y programados también requieren datos recientes y una cantidad conocida y positiva.

Todos los modos comparten el límite diario según la fecha local de la instancia; los intentos correctos y pendientes reservan capacidad. Se omiten cuentas deshabilitadas o que requieren autorización. No se recuperan ejecuciones atrasadas más de cinco minutos. Se omiten horas inexistentes por cambio horario; una hora repetida genera una ejecución por fecha local. Cambiar la zona recalcula las futuras ejecuciones. Cerrar el navegador no detiene los procesos. La demo no permite automatización ni canjes.

Resultados y recuperación

El proveedor decide la elegibilidad y las ventanas reiniciadas. El canje usa POST /backend-api/wham/rate-limit-reset-credits/consume, con resultados reconocidos reset, already_redeemed, nothing_to_reset y no_credit. El éxito actualiza cuota y cantidad sin eliminar otras restricciones de la puerta de enlace ni garantizar que desaparezcan todas.

Antes del envío se guardan redeem_request_id y el ID seleccionado. Un tiempo de espera o una respuesta desconocida deja el resultado pendiente. La comprobación repite ambos valores aunque cambien inventario o caducidad; un cambio de cantidad no demuestra éxito. Las solicitudes pendientes antiguas conservan la omisión original de credit_id. Tras un resultado definitivo se borra el ID seleccionado; no aparece en instantáneas de cuota ni en historiales públicos o auditorías. No se guardan credenciales, respuestas originales ni perfiles del proveedor. Eliminar la cuenta elimina configuración e historial.

Las API del navegador para administradores son GET /api/accounts/{id}/resets (configuración e historial), GET /api/accounts/{id}/resets/cards (lista normalizada), PUT /api/accounts/{id}/resets (guardar) y POST /api/accounts/{id}/resets/consume o POST /api/accounts/{id}/resets/retry (usar o confirmar). Exigen sesión del navegador y roles del espacio; las claves de la puerta de enlace no sirven. La lectura reutiliza controles de credenciales, proxy y ciclo de vida, y excluye identificadores de perfil, avatares y respuestas originales. El contrato interno puede cambiar; las pruebas sintéticas no validan la elegibilidad real ni el canje en producción.

Los cambios y usos manuales correctos se auditan; los resultados automáticos quedan en un historial acotado.

Almacenamiento y refresco de credenciales

El esquema consolidado crea cuentas de suscripción en el espacio de trabajo y registros de afinidad de cuentas encuadernados. El acceso, refrescos y fichas de identificación están cifrados con AES-256-GCM y datos autenticados con cuentas. credentials.key archivo junto a su base de datos. La clave no es una contraseña de configuración y no requiere entrada manual.

Retrocede la base de datos y credentials.key Una base de datos de cuenta existente no comenzará con una clave faltante, inválida o desajustada. No sustituya la clave para recuperar el acceso. Encryption protege el contenido credencial en una copia única de la base de datos; el acceso a la base de datos y la clave permite el desciframiento.

SubLane Es el único propietario de refrescos. Se serializa refrescante credencial con cambios de administrador y persiste tokens rotados antes de publicarlos a peticiones. Tokens cerca de la actualización de vencimiento antes de usar. Un upstream 401 permite un refresco y una reingreso en la misma cuenta; rechazos concurrentes de un viejo token reutiliza el ya refrescado credential.

Contrato de puerta de entrada

Todas las rutas de entrada requieren un SubLane llave del portador, independientemente de las cookies del navegador:

HTTP las solicitudes deben incluir una aportación completa. HTTP previous_response_id es rechazado en lugar de perder silenciosamente el contexto porque el Codex HTTP backend es apátridas. WebSocket las continuaciones utilizan la historia ligada, de conexión local; IDs de continuación desconocidas requieren la entrada completa de la transcripción. WebSocket turn vuelve a comprobar la habilitación clave y miembro. Una clave revocada no puede iniciar un nuevo giro en una conexión existente.

La afinidad de la cuenta tiene como alcance la clave de caché de aviso/sesión del miembro, el grupo y el cliente, se retiene durante 24 horas de actividad y tiene un límite de 4096 enlaces. Las solicitudes nativas utilizan un enlace entre proveedores; Las solicitudes explícitas de prefijo heredado conservan enlaces específicos del proveedor. Las nuevas sesiones se distribuyen entre cuentas elegibles que informan el modelo solicitado dentro de su grupo, respetando la simultaneidad y el tiempo de reutilización por cuenta. Las solicitudes sin sesión se seleccionan de forma independiente sin crear afinidad. Las sesiones existentes fallan cuando su cuenta se desactiva o elimina en lugar de cambiar la identidad ascendente. Para un cambio de modelo intencional, el historial portátil completo puede seleccionar una cuenta de respaldo si la cuenta original no puede servir al nuevo modelo; las continuaciones del proveedor permanecen fijadas. Ver enrutamiento del modelo. Reinicie la conversación después de otros cambios intencionales en la cuenta. Reintentar una solicitud nunca la mueve automáticamente a otra cuenta.

Cada espacio de trabajo tiene por defecto capacidad para 128 operaciones, incluidas las solicitudes en espera y los metadatos compartidos, ocho conexiones WebSocket, un plazo total de 30 minutos por solicitud o turno y cinco minutos para cabeceras de inferencia. Las solicitudes y el contexto reconstruido admiten 128 MiB; respuestas y eventos, 8 MiB cada uno. La lectura del cuerpo tiene un plazo de 30 segundos y el descubrimiento compartido, de 45 segundos. Son límites de recursos, no garantías de rendimiento. Consulta despliegue y funcionamiento de los grupos. Límites de miembros: controles del equipo.

Las credenciales del proveedor, las cookies del navegador, los encabezados de cliente arbitrarios y los cuerpos de error del proveedor sin procesar no se reenvían a los miembros. Las claves de portador del cliente se reemplazan por la credencial ascendente seleccionada. La aplicación no registra mensajes, respuestas, tokens de acceso, tokens de actualización ni OAuth URL de devolución de llamada.

Límite de verificación

Las pruebas automatizadas utilizan bases de datos temporales, credenciales sintéticas y datos ascendentes locales falsos. Cubren OAuth propiedad/vencimiento/reproducción, cifrado y discrepancia de claves, serialización de actualización, identidad inmutable, afinidad de cuenta, aislamiento de rol/propiedad, cancelación de transmisión, SSE reparación completa y WebSocket revocación entre turnos.

Una prueba de integración voluntaria ejecuta una CLI Codex instalada con un inicio de proceso secundario nuevo, sin credenciales heredadas y una respuesta de modelo sintético local:

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

Codex CLI 0.152.1 pasó los modos HTTP/SSE y WebSocket contra el flujo ascendente sintético. La autorización de suscripción real y las solicitudes de modelos en vivo requieren una cuenta de prueba autorizada explícitamente. La aplicación de escritorio real aún no ha sido validada; Las pruebas de protocolo y configuración compartida por sí solas no establecen la compatibilidad con el escritorio en vivo.

Antes de la actualización v7, una vista previa local de macOS arm64 (CLIProxyAPI v6.10.9, Go 1.26.0, binario de producción, una cuenta sintética cifrada) midió 23.376 KiB RSS, aproximadamente 22,8 MiB, después de unos doce minutos de inactividad el 19 de septiembre de 2026. Ésta es sólo una observación ociosa; Los modelos reales, la simultaneidad, el tamaño de la carga útil y la plataforma cambian el uso de memoria. La configuración Docker Compose se validó localmente, pero el demonio Docker no estaba disponible para la creación de una imagen local.

Referencia de ejecución

SubLane utiliza los traductores y ejecutores públicos de CLIProxyAPI v8.0.35 detrás internal/upstream. SubLane posee la autorización, el almacenamiento de credenciales cifradas, la actualización, la selección de cuentas y la puerta de enlace pública. SDK se ejecuta como un registro de ejecutor privado sin credenciales activas, un observador no operativo, rutas de loopback bloqueadas y actualización automática deshabilitada. Ver arquitectura para el límite de ejecución y Configuración del proveedor para conocer los pasos de conexión del proveedor. Los detalles de autorización y cuota de esta guía describen Codex.