Contabilidad de asignación de recursos

Empezar con Asignaciones de recursos para la configuración. Una regla pertenece a un grupo de recursos dedicado en un espacio de trabajo. La membresía de su cuenta permanece fija mientras exista la regla. Los miembros necesitan una subvención conjunta directa y una clave personal vinculada a la regla; una clave normal no se convierte automáticamente. Todas las claves de un miembro para la regla comparten un libro mayor.

Participación del presupuesto total

Por porcentaje acepta un total diario/mensual o hasta 8 ventanas de duración con un total distinto para cada una. Los mismos porcentajes, cuya suma es como máximo el 100%, se aplican a todas las ventanas. La base puede ser tokens o USD internos:

• Por participación simbólica: ingrese el total en M tokens. Los tokens de entrada y salida reportados cuentan contra la participación de cada miembro; la entrada almacenada en caché es parte de la entrada y no se cuenta dos veces.
• Por cantidad de participación: introduzca un total interno USD. La entrada de cada solicitud, la entrada almacenada en caché y la salida se convierten utilizando los precios del modelo guardados con esa revisión de regla. Estos precios no indican la fórmula de cobro de la suscripción del proveedor.

En cada ventana, el límite de un miembro es el total multiplicado por su porcentaje y redondeado hacia abajo a la unidad mínima. El 25% de 1 M tokens equivale a 0,25 M. Se rechazan porcentajes positivos que den cero al redondear. Los porcentajes sin asignar y los restos no se prestan automáticamente. La admisión comprueba tanto el límite individual como el presupuesto del grupo, incluido el consumo de antiguos miembros. El saldo no se reinicia por cuenta de suscripción.

Estos son presupuestos internos. Un total de token configurado no revela la capacidad real de la suscripción y el USD interno no es un saldo de efectivo ni una factura. SubLane todavía verifica la cuota ascendente disponible; el proveedor podrá rechazar las solicitudes antes de que se agote el presupuesto interno.

Límites de monto por ventana de tiempo

Por ventana de tiempo es un tipo independiente. Admite hasta 8 condiciones con horas o días enteros, de 1 hora a 365 días, y un límite interno en USD común como valor predeterminado. Cada miembro tiene su propio registro y puede sobrescribir condiciones. Un límite vacío significa ilimitado para esa condición: el uso se registra, pero no aplica cuota ni reserva provisional. Cada solicitud liquidada se valora una vez con los precios guardados y cuenta en todas las ventanas. Si una condición finita se agota o no admite más reserva, se detienen las solicitudes nuevas.

Las ventanas parten de la activación y se renuevan de forma independiente con duraciones fijas. Reiniciar la ventana de cinco horas no borra el consumo semanal. No son ventanas móviles retrospectivas ni siguen los reinicios del proveedor. La zona horaria de la instancia solo cambia la visualización.

Cambios de miembros y programación

Editar miembros actuales modifica porcentajes o límites individuales inmediatamente. Conserva el consumo y las reservas de solicitudes admitidas. Cualquier aumento debe caber en todos los presupuestos compartidos actuales; salir y volver a entrar no borra el uso. Con total 100 y A habiendo consumido 40, asignar 33 a A/B/C requiere 106 y se rechaza; 40/30/30 sí cabe. Tras renovar, se vuelven a comprobar todas las ventanas; programar no evita un déficit.

Los cambios de presupuesto, límites predeterminados y precios entran en vigor en la hora ya programada o en el siguiente límite del calendario actual. Con varias ventanas se usa la siguiente frontera de la duración actual más larga. Se conservan el anclaje y el uso: una ventana corta puede seguir en curso y una reducción puede dejarla agotada. Los precios nuevos no recalculan solicitudes anteriores.

Las ediciones ordinarias de presupuesto/precio conservan exactamente los miembros guardados, aunque alguno ya no figure en la lista autorizada. Esto no restaura el acceso. Los nuevos destinatarios y un nuevo período estructural requieren permiso actual del grupo.

Si la próxima versión tiene un plan independiente de miembros, se rechaza la propagación del cambio inmediato por conflicto. Revisa o cancela esa instrucción expresamente; las otras condiciones compatibles de presupuesto/precio se conservan. Una actualización en segundo plano no añade versiones nuevas a un borrador antiguo. Ante un conflicto, usa Actualizar y revisar.

Cambiar unidad, tipo o plan de reinicio exige confirmar una sustitución estructural real. Mantiene los ID de regla, grupo y Key y fija el nuevo anclaje en la activación programada. Cambiar solo miembros o precios no permite crear un período nuevo.

Aplazar al siguiente límite mueve la versión únicamente a la primera frontera natural estrictamente posterior a la hora guardada, usando el plan actual o el inicial antes de la primera activación. Revisa y confirma la hora del servidor; condiciones cambiadas o caducadas producen un conflicto.

Cancelar cambio programado exige una versión actual efectiva. Si solo existe el inicio pendiente, pausa o aplaza la regla. El aplazamiento inicial sustituye la versión de forma atómica. Pausar no elimina la configuración ni cancela o retrasa su activación; después de activarse, la regla sigue negando acceso mientras esté pausada.

Las correcciones iniciales de miembros usan el editor completo (PATCH /api/allocations/{id}). Exigen las versiones revisadas y la hora de activación, conservan la hora y el anclaje guardados y vuelven a comprobar los permisos de grupo de los destinatarios. Solo están disponibles sin versión actual y sin solicitudes registradas. Versión, metadatos y auditoría se guardan en una transacción; un fallo o cruzar la activación revierte todo. La cancelación inicial sigue prohibida.

Si la próxima versión aprobada tiene una estructura realmente distinta de la actual, se ofrece la confirmación existente de nuevo período aunque el borrador mantenga la estructura pendiente. Confirmar otra vez permite editar sus miembros. Los cambios ordinarios de presupuesto/precio conservan miembros y anclaje sin reconfirmar. Retirar esta confirmación opcional muestra y envía el plan de miembros guardado. La sustitución sigue exigiendo una diferencia estructural real respecto a la versión actual.

Para asignaciones tarifadas (Por cantidad, Por cantidad de participación, y Por ventana de tiempo), SubLane lee los modelos admitidos por el grupo dedicado y completa sus precios de catálogo al guardar una revisión. Los precios proporcionados por el usuario no anulan esta instantánea. Si un modelo no tiene precio de catálogo actual, su tarifa previamente guardada se reutiliza cuando esté disponible. Un modelo recién descubierto sin precio se omite de la instantánea, por lo que las solicitudes permanecen bloqueadas hasta que entre en vigor una revisión del precio. Las advertencias de cobertura de precio se calculan cuando se lee una regla, no se almacena en su revisión: un precio de catálogo restaurado borra la advertencia de catálogo automáticamente, mientras que un modelo ausente de la instantánea de precio guardada permanece marcado hasta que una nueva revisión lo incluya. Los catálogos de cuentas no disponibles conservan las tarifas guardadas previamente y muestran una advertencia hasta que se recupera el descubrimiento. El ahorro sólo falla si no queda ningún precio utilizable. Sin un catálogo de precios cargado o un caché de precios guardado, no se puede crear una nueva asignación de precios; actualice el catálogo o proporcione un precio alternativo antes de volver a intentarlo.

Para un modelo ausente de los precios guardados, el aviso muestra cuándo surtiría efecto una corrección guardada ahora. Las ventanas usan la siguiente frontera de la duración actual más larga; guardar repetidamente no habilita el precio inmediatamente. Una versión ya programada muestra su propia hora y advierte que el modelo seguirá bloqueado si no se sustituye por una versión corregida.

Límites directos y uso pendiente

Por fichas establece el límite de tokens de un miembro directamente. Por cantidad establece un límite interno directo USD utilizando precios de modelo guardados. Ambos utilizan el mismo token o contabilidad de precios como base de acciones correspondiente.

El uso final fiable se liquida sin esperar porcentajes del proveedor. Una solicitud sin totales fiables queda pendiente de corrección; sus datos parciales se ven, pero no son cargos ni reservas. Cada solicitud activa reserva provisionalmente el 10% del límite individual capturado al admitirse, al menos una unidad, en cada ventana finita. Editar después no cambia esa reserva. Cada ventana finita admite hasta cuatro solicitudes simultáneas de ese miembro iniciadas en ella; el presupuesto compartido comprueba también la exposición del grupo. Al finalizar se libera la reserva. Una solicitud grande puede exceder el límite y el uso desconocido deja exposición incompleta: son límites flexibles. Se muestran primero los 256 pendientes más recientes. La atribución contable usa la admisión tras la cola; la duración diagnóstica empieza en la llegada.

Para las transmisiones Codex, SubLane puede seguir leyendo en sentido ascendente durante hasta 3 segundos después de que el cliente se desconecte para capturar el uso final confiable. También se puede cobrar un evento de terminal fallido que incluye el uso completo. Los fallos ascendentes repetidos enfrían temporalmente la cuenta afectada; una respuesta exitosa sin uso final queda pendiente sin enfriar la cuenta. Si una escritura contable falla temporalmente, SubLane vuelve a intentar esa solicitud antes de admitir más trabajo respaldado por subsidios para el miembro afectado; otros miembros pueden continuar.

Las reglas diarias/mensuales mantienen fecha y hora en la zona de la instancia; un día mensual inexistente se ajusta al último del mes. Por defecto son las 00:00 diarias o el día 1 a las 00:00. Las ediciones ordinarias conservan el anclaje. Pausar o revocar acceso bloquea nuevas solicitudes y turnos WebSocket sin borrar historial. Actualizar la cuota, usar tarjetas de reinicio, reautorizar o reiniciar el proceso no repone presupuestos locales.

Eligiendo Iniciar el próximo periodo al crear una regla de ventana de tiempo, se inicia después de la duración más larga configurada.

Leer y corregir saldos

Los miembros ven su propia asignación en Uso. Los administradores del espacio de trabajo abren Asignaciones de recursos → Ver uso para la regla completa. Todas las ventanas de tiempo configuradas aparecen bajo un miembro con su propio límite, cantidad utilizada, cantidad restante, exposición al riesgo y reinicio instantáneo; el estatus de miembro refleja la condición más restrictiva. Los saldos de importes muestran USD interno junto con los tokens informados; los saldos de tokens usan M, donde 1 M = 1,000,000 tokens. Los informes personales no exponen las identidades de las cuentas de suscripción.

La balanza se separa usado (uso liquidado) de solicitudes en curso y uso pendiente en el ciclo actual. Las reservas temporales reflejan únicamente solicitudes durante el vuelo; El uso pendiente permanece visible para su corrección y no cuenta como capacidad de reserva o asignación utilizada. El margen de admisión incluye el colchón de riesgo automático; no es una asignación extra para gastar. Por lo tanto, una provisión restante positiva puede coincidir con Nuevas solicitudes pausadas temporalmente cuando otra solicitud necesita más reserva que el margen actual, o cuatro solicitudes aún están en proceso. El estado sigue la misma verificación de riesgo del ciclo actual que la admisión de la puerta de enlace. Es una instantánea y puede cambiar a medida que finalizan las solicitudes. Los registros pendientes fuera del ciclo actual permanecen visibles para su corrección pero no pausan su admisión.

Cuando una entrada pendiente no se puede resolver automáticamente, un administrador puede ingresar totales de entrada, salida y entrada en caché respaldados por evidencia confiable. La corrección utiliza la regla contable guardada de la solicitud y escribe un evento de auditoría. No trate el uso faltante como cero ni ingrese totales inventados.

Los administradores del espacio de trabajo administran reglas en /api/allocations; los miembros leen sus propios saldos en /api/me/allocations. Las claves se unen a una regla con scheme_id. Ver espacios de trabajo y claves personales API.

Condiciones de escritura de la API

Las lecturas conservan su formato y añaden write_conditions con expected_current_revision_id y expected_next_revision_id, que admiten null. Ambos son obligatorios al modificar reglas existentes: PATCH completo, miembros, cancelación/aplazamiento y sustitución. Si faltan o están desactualizados, se devuelve HTTP 409 sin cambios. Revisa los datos; no obtengas ID nuevos para reenviar automáticamente un borrador antiguo. La activación/pausa explícita y la corrección por solicitud mantienen sus contratos.

Una versión futura exige expected_effective_at, en segundos UTC y confirmado por el servidor; la sustitución estructural exige también confirm_replacement=true. POST /api/allocations/{id}/preview acepta schedule, reschedule o replace. Los miembros usan POST /api/allocations/{id}/members; las acciones programadas usan POST /api/allocations/{id}/cancel y POST /api/allocations/{id}/reschedule. El guardado completo no cambia la activación: usa POST /api/allocations/{id}/enabled.

La primera creación sin condición temporal mantiene el inicio inmediato/diferido anterior. Si se envía expected_effective_at, se requiere start_next=true: el inicio de calendario coincide con la siguiente frontera; el de duración sigue siendo futuro y no supera una duración máxima desde la hora actual del servidor. Null explícito devuelve 409 por condición requerida, formato inválido 400 y hora caducada/cambiada 409. POST /api/allocations/preview solo propone el inicio, sin crear reglas; un fallo no permite volver a una creación incondicional.