Uso, salud y equipos

Las páginas de plataforma cubren las operaciones: Uso (/space/usage, incluyendo métricas de salud y latencia), Cron (/space/cron), Notificaciones (/space/notifications), Sesiones (/space/chats) y Equipos (/space/teams).

¿Nuevo en el lado de IA? Lee primero Conceptos de IA desde cero — las métricas de esta página (tokens, latencia, coste) son exactamente la economía del bucle token a token.

Los conceptos detrás de la gobernanza

Esta página es donde se hace visible la economía de los tokens:

• Los tokens son la unidad que pagas. Cada request factura prompt tokens + completion tokens (y las variantes cacheadas/de razonamiento donde aplique). Nada de esta página es abstracto — los números salen directamente de la contabilidad de tokens por request (usage_records), así que “coste” es literalmente tokens × precio del proveedor.
• La latencia es el coste del razonamiento (y de la longitud del stream). Un P95 alto a menudo coincide con modelos de razonamiento (que piensan más tiempo) o salidas más largas. Salud y el retry handler comparten la misma telemetría, así que lo que ves aquí coincide con lo que siente el cliente.
• Los agentes multiplican el uso. La orquestación ejecuta muchos pasos (orchestrator → executors → verifiers), cada uno escribiendo su propio registro de uso — así que una sola tarea puede aparecer como muchísimas líneas. Ese es el precio de la composición.

Ver Conceptos de IA desde cero para entender por qué los tokens y el contexto impulsan todo lo que la plataforma mide.

Uso y métricas (/space/usage)

El dashboard de gobernanza (GovernanceDashboard) reporta datos de uso reales respaldados por la tabla usage_records — cada request de chat/agente/contenido escribe un registro con:

• Contabilidad de tokens: prompt tokens, completion tokens, input cacheado, input no cacheado, reasoning tokens.
• Coste: costUsd calculado por request a partir del precio del proveedor.
• Latencia: durationMs.
• Modo: chat / agent / code / workflow / tool.
• Tier: free/paid en el momento de la request.

El dashboard agrega por rango de tiempo, proveedor, modelo y modo: coste total, volúmenes de tokens y desgloses por modelo — para que veas exactamente cuánto cuesta tu uso BYOK y a dónde va.

Salud y latencia

La pestaña de Salud (HealthTab) es observabilidad real por request de API:

• Latencia P95 entre proveedores y modelos.
• Tasa de éxito y tasa de error por request.
• Nivel de riesgo por request de proveedor — surgido de src/lib/request-metrics.ts y la API de salud.

Esta es la misma telemetría que usa el panel de ops y el retry handler, así que lo que ves en salud coincide con lo que experimenta el cliente.

Automatizaciones (/space/automations)

Las automatizaciones son ejecuciones durables, no temporizadores del cliente. El núcleo vive en src/lib/automations/:

• Definición como dato. Cada automatización es un documento tipado y versionado (definition.ts), validado en el borde. El editor visual, el formulario simple y cualquier generador futuro compilan al mismo formato, así que una ejecución se puede reproducir entre superficies.
• Persistencia por paso. Cada intento sobre un nodo es su propia fila en automation_steps. Un Worker puede ser desalojado entre dos pasos; al reentrar, el motor reanuda desde la última salida persistida en vez de volver a pagarla.
• Idempotencia. Las ejecuciones se identifican por (automation_id, scheduled_time) y los pasos por (run_id, node_id, attempt), ambos únicos en Postgres. Un trigger redelivered pierde la carrera en la base de datos en lugar de arrancar una segunda ejecución.
• Horarios reales. cron.ts parsea expresiones de 5 campos y las evalúa en una zona horaria IANA explícita, de modo que el horario de verano lo resuelve la plataforma y no la configuración regional del navegador. nextFireAt es lo que el scheduler reclama con FOR UPDATE SKIP LOCKED, que es lo que hace seguros los ticks solapados.
• Reintentos con backoff. Los fallos transitorios (429, 5xx, sockets caídos) se reintentan con backoff exponencial y jitter determinista; los fallos de contrato (400, 401, clave inválida) fallan rápido en lugar de quemar presupuesto. Cada intento queda en el historial, no se sobrescribe.
• Aprobaciones. Un nodo de aprobación pausa la ejecución y la persiste. El motor nunca bloquea dentro del proceso, porque una aprobación medida en horas no sobrevive a que se desaloje el isolate.

Notificaciones (/space/notifications)

El centro de notificaciones (NotificationCenter) recoge alertas de agentes en tiempo real y configuración de webhooks:

• Alertas de ejecuciones de agentes (completado, fallo, peticiones de aprobación).
• Configuración de webhooks para reenviar alertas a sistemas externos.
• Los canales entrantes (Slack, etc.) también muestran aquí sus mensajes.

Proyectos y repositorios (Sesiones)

El dashboard de ingeniería (EngineeringDashboard) organiza el trabajo en torno a proyectos y repos:

• Los proyectos agrupan objetivos; cada proyecto puede vincular repositorios de GitHub.
• Se monitorizan PRs e issues de los repos vinculados.
• Las sesiones de chat asociadas a un proyecto/repo aparecen en el historial de sesiones etiquetadas como sesiones “code”.

Equipos (/space/teams)

Los equipos traen colaboración en tiempo real (TeamsPanel, respaldado por /api/teams):

• Modelo de equipo: un equipo tiene propietario, slug, miembros con roles (owner / member), estado de invitación (pending / accepted) y joinedAt.
• Tarjetas de estadísticas: equipos totales, miembros activos, invitaciones pendientes, equipos que posees.
• Sesiones colaborativas: múltiples usuarios en el mismo hilo, revisión de código y entrega coordinada de PRs — el mismo modelo de conversación compartido entre miembros.

Ajustes (/space/settings)

La página de ajustes (DashboardSettings en settings-panel.tsx) cubre: perfil (nombre/avatar), claves BYOK de proveedores con el vault cifrado, tokens de integraciones (GitHub, Google Drive BYOS), idioma, tema y los opt-ins de cloud sync para entradas del vault. Ver Modelos y API keys para los detalles del vault.