Cómo funciona
El flujo real de request detrás de un mensaje de chat y una subida de archivo — control plane frente a execution plane, quota, y el ledger.
En esta página
MasterOS separa un control plane (auth, organización, billing/ledger, catálogo de modelos, admin) de un execution plane (chat, gateway de modelos, retrieval, y — más adelante — los runtimes de agent/workflow). Esta separación existe para que los límites de seguridad y escalado se mantengan claros aunque, hoy, ambos planos corran en un único servicio de API.
Enviar un mensaje de chat
- El servidor resuelve el plan activo de su organización y verifica que el nivel de modelo solicitado esté en su lista permitida — esto se aplica del lado del servidor, no solo se oculta en la interfaz.
- Si el mensaje continúa una conversación existente, la propiedad se verifica antes de que ocurra cualquier otra cosa — un id de conversación inválido o perteneciente a otro usuario se rechaza antes de que se toque cualquier quota.
- Se reserva una idempotency key (enviada con cada request de chat). Un request reintentado con la misma clave nunca vuelve a facturarse ni a llamar al proveedor del modelo; un request duplicado en curso se rechaza de plano.
- El costo estimado se reserva contra su bucket de quota diaria antes de que se llame al modelo.
- El mensaje del usuario se guarda, el modelo transmite su respuesta token por token, y la respuesta se guarda junto con sus conteos reales de tokens y su costo — como una única transacción atómica de base de datos, de modo que un fallo nunca puede dejar un mensaje facturado sin su asiento de ledger correspondiente (o viceversa).
- La reserva de quota se liquida al costo real (o se libera por completo, si en realidad no se facturó nada), y el ledger se debita por ese mismo monto.
La facturación es un ledger — una secuencia de asientos de crédito/débito — nunca un único número de saldo que se decrementa directamente. Eso es lo que permite razonar correctamente sobre un request que falla a mitad de camino, un reembolso, o conciliar exactamente por qué se cobró a un usuario.
Subir un archivo
Upload → validate type/size → malware scan → store → extract text → available for citation in chat
Un archivo que falla en el escaneo de malware o en la extracción de texto se marca como fallido y no puede usarse en el chat. El filtrado de permisos (qué archivos tiene permitido ver) ocurre antes de que cualquier contenido llegue a un modelo — un límite de seguridad, no solo un filtro de búsqueda.