Panel de administración Web
El panel de administración web es la UI de APX basada en navegador. Corre enteramente en tu navegador, habla con el daemon sobre su API HTTP y no requiere ningún servidor público. Cualquier navegador en la misma máquina — o en la misma LAN tras la vinculación — puede usarlo.
Abrir en la máquina local
Sección titulada «Abrir en la máquina local»El daemon sirve el panel compilado en http://127.0.0.1:7430/. Arrancá el daemon
y abrí esa URL:
apx status # boots the daemon if it isn't running yet# then open http://127.0.0.1:7430 in your browserEn la primera carga el panel obtiene su token de autenticación automáticamente desde
/api/admin/web-token (endpoint solo loopback). No necesitás copiar un token
a mano cuando lo abrís desde la misma máquina.
Abrir desde otro dispositivo (vinculación por LAN)
Sección titulada «Abrir desde otro dispositivo (vinculación por LAN)»Para abrir el panel en tu teléfono u otra computadora en la misma LAN, usá
apx pair web. El comando imprime un código QR y una URL directa:
apx pair web# Prints:# http://192.168.1.42:7430/#token=<token># [QR code for scanning with a phone camera]Escaneá el QR con la cámara de tu teléfono (no hace falta ninguna app) o compartí la URL. El
fragmento #token=… lleva el token bearer — el panel lo usa automáticamente.
$ apx pair web APX pairing (web) · expires in 90s █▀▀▀▀▀█ ▀▄█▀▄ █▀▀▀▀▀█ █ ███ █ ▀█▄▀ █ ███ █ █ ▀▀▀ █ █▄▀█▀ █ ▀▀▀ █ ▀▀▀▀▀▀▀ █ ▀ █ ▀▀▀▀▀▀▀ ██▀▄ ▀▀▄▀█▄▀▄█▀ ▄█▀▄█ ▀ ▀▀▀▀▀ █▄▀ ▄██▀▀▄ ▄▀ █▀▀▀▀▀█ ▄▀█▄▀▀█▄▀ █▄█ █ ███ █ ▀█▄ ▀▄█▀▄▀▀▀▀ █ ▀▀▀ █ ▀▄█▀█ ▄▀▄█▄ ▄ ▀▀▀▀▀▀▀ ▀▀ ▀▀▀▀ ▀ ▀▀▀ escaneá con la cámara del teléfono — abre la web ya vinculada link: http://192.168.1.42:7430/#token=8f3a…d10c code: pr_7QF2K (o pegalo en la pantalla de vinculación de la web)
Para ver todos los clientes vinculados actualmente o revocar uno:
apx pair listapx pair revoke <id>Compilar el bundle web
Sección titulada «Compilar el bundle web»El panel es una app de Vite + React + TypeScript bajo src/interfaces/web/. La
salida compilada cae en src/interfaces/web/dist/ y es servida por el daemon.
# Build once (from repo root)node scripts/build-web.js
# Or rebuild manuallycd src/interfaces/webpnpm installpnpm build
# Development with hot reload (proxies API calls to :7430)pnpm devEl script npm build:web y el hook prepack llaman ambos a
node scripts/build-web.js, así que un npm install -g . global siempre envía un
bundle fresco. Configurá APX_SKIP_WEB_BUILD=1 para saltearlo durante flujos de dev que
no tocan la UI.
Modelo de navegación
Sección titulada «Modelo de navegación»El panel tiene dos niveles de navegación:
- Base (
/p/0/…) — el espacio global del daemon: workspaces, modelos, sesiones, logs y configuración global. El chat en Base habla con el super-agente. - Proyecto (
/p/:pid/…) — un único workspace de proyecto: agentes, chat, tareas, rutinas, MCPs, memorias y configuración.
Un riel izquierdo muestra todos los proyectos registrados más accesos directos a los módulos (Voces, Desktop, Deck, Code). Debajo del riel hay un botón Roby que abre una hoja flotante de chat conectada al super-agente.
Hay otros dos espacios de URL además de los de proyecto. Los módulos del panel
son rutas de primer nivel — /inbox, /code, /desktop — y /m/… es
enteramente la superficie del celular: /m/chat, /m/tasks, /m/commitments.
La dirección vieja del celular, /mobile, sigue funcionando: redirige a /m/…
para que los links que ya andan dando vueltas (QR impresos, la app Android) no
se rompan.
Actualización en vivo
Sección titulada «Actualización en vivo»Cada pantalla que muestra una conversación se actualiza sola. El panel mantiene
un WebSocket abierto contra el daemon (/api/events/ws, autenticado con el
mismo token que la API HTTP), y el daemon avisa por ahí cada vez que una
conversación se mueve, sin importar en qué superficie se produjo el turno.
Así, un mensaje que llega por Telegram aparece en la bandeja de la notebook y en el teléfono al mismo tiempo, sin recargar, y tres dispositivos abiertos en el mismo hilo quedan sincronizados. El socket lleva una señal, nunca contenido: dice qué hilo se movió, y cada pantalla vuelve a leer ese hilo por la misma API que ya usaba.
Se repara solo. Un teléfono que suspende la pestaña, una notebook que se duerme, un tailnet que se cae: al volver, el panel se reconecta y revalida una vez, así no se pierde nada de lo que pasó mientras estuvo afuera. Si el socket no se puede abrir (un proxy que rechaza upgrades), las listas vuelven a su refresco de 15 segundos y el panel sigue funcionando, sólo que menos inmediato.
Los turnos activos y mensajes encolados también sobreviven la navegación dentro del panel. Si salís de un chat y volvés, se recuperan respuesta parcial y tarjetas de tools terminadas en orden original; luego continúa streaming. Todas listas chats usan mismo indicador compacto junto badge agente: spinner mientras agente escribe y punto azul cuando respuesta termina fuera chat abierto. Abrir chat limpia punto. Cambio chat limpia historial anterior enseguida; turno viejo sigue daemon, pero no puede escribir chat nuevo.
El punto es compartido, no de cada dispositivo. Lo leído vive en el daemon
(~/.apx/read-marks.json), así que leer una conversación en la laptop lo apaga
en el teléfono en el mismo segundo — las demás superficies se enteran por el
mismo socket. Antes era la memoria de cada navegador, y por eso una tarde de
lectura en un aparato dejaba cuarenta filas azules en el otro, todas ya leídas.
Una instalación que ya venía andando toma su línea de base la primera vez que se
le pregunta: todo lo dicho antes de ese momento cuenta como leído, y sólo lo que
llega después levanta un punto.
Notificaciones y qué canales te llegan
Sección titulada «Notificaciones y qué canales te llegan»El panel puede avisarte cuando un agente escribe y vos no estás mirando: una
notificación por conversación, a través del service worker, y tocarla abre ese
chat. Se activa en Settings → Notificaciones (o desde la hoja de
preferencias del celular). Necesita https — apx panel tailscale on — y necesita
que la app esté corriendo, aunque sea en segundo plano; despertar una app
cerrada del todo es web push, que APX todavía no hace.
Lo que dispara una es la respuesta de un agente, y nada más. Tu propio mensaje no, y el trabajo del medio tampoco: un turno puede correr dos docenas de herramientas y cada una mueve la conversación, que es por qué un mismo turno llegaba como una pila de notificaciones. Una respuesta que se transmite de a pedazos suena una vez y después actualiza el mismo cartel en silencio.
Qué canales pueden sonar se responde por dispositivo. En el celular tenés
Telegram instalado, así que una notificación de APX sobre una respuesta de
Telegram es la misma noticia dos veces: ahí arranca apagado. En la compu es la
única forma de enterarte, así que ahí arranca todo prendido. Los chips de
Settings → Notificaciones prenden y apagan cada canal en el dispositivo
donde estás; la elección vive en ese navegador (localStorage) y no sale de ahí.
Lo mismo vale para las listas. La bandeja y /m/chat muestran todos los
canales donde puede pasar una conversación, y un solo picker plegado — “Canales ·
6 de 11” — apaga y prende cada uno para ese dispositivo, de nuevo con Telegram
apagado por defecto en el celu. Un canal apagado conserva su switch (y su
contador), así que la vuelta está donde estaba la ida, y una lista vacía por un
filtro dice qué filtro la vació en vez de hacerte creer que no hay nada. Las dos
listas son planas y ordenadas por lo más reciente, así que cada fila lleva su
canal como etiqueta.
De qué proyecto viene una conversación
Sección titulada «De qué proyecto viene una conversación»La bandeja cruza todos los proyectos a la vez, y eso abre una segunda pregunta que el canal no contesta: dos proyectos pueden tener cada uno una agente Zoya, y “Zoya · Web” no dice de quién es. Por eso la procedencia tiene badge propio — el nombre del proyecto, al lado de la etiqueta de canal y nunca metido adentro de ella — en la fila de la lista y en el encabezado de la conversación que abre, tanto en la compu como en el celular.
Solo se marcan los agentes de otro proyecto. En el proyecto default vive el super-agente y ahí cae toda conversación que no tiene proyecto propio, así que ponerle badge sería etiquetar casi toda la lista con el único lugar que se da por sentado.
Al lado del picker de canales hay uno de Proyectos con la misma forma, con un contador por proyecto, para leer las conversaciones de un proyecto solo. Como el de canales, es una elección por dispositivo que queda en ese navegador.
Adentro del tab Chat de un proyecto (/p/:pid/chat) no aparece ni el badge ni
el filtro: la respuesta es la pantalla donde ya estás parado.
Workspace de proyecto
Sección titulada «Workspace de proyecto»Abrir un proyecto te lleva a su Resumen — un “mission control” con tarjetas de conteo en vivo (agentes, tareas abiertas, rutinas activas, artifacts), una franja de flujo de tareas desglosada por estado, el roster de agentes (orquestadores vs. especialistas) y las tareas abiertas más recientes. Cada pestaña de abajo mapea a un namespace de la API del daemon.
apx web, luego abrí cualquier proyecto (su pestaña de aterrizaje) La pestaña Chat habla con el super-agente (Roby) y con cada agente del proyecto. La barra lateral es channel-first, agrupada como Web, Telegram, Desktop, Voice, Agent ↔ Agent, Schedule, Other — en ese orden. Además de tus propias conversaciones web, también muestra los hilos por día del super-agente de cualquier otro canal (Telegram, Desktop, Deck), así una conversación que pasó por Telegram queda visible desde la web — y se puede seguir ahí, en una sesión aparte.
El botón ”+ New” abre un selector de agente (super-agente o cualquier agente del proyecto) e inicia una sesión nueva que recién se materializa bajo el grupo Web cuando mandás el primer mensaje. Cada conversación abierta tiene una acción “New session” (reinicia en el lugar) y una acción “Delete” (detrás de un diálogo de confirmación) que elimina permanentemente el archivo de conversación o el hilo del canal.
Debajo del nombre del agente, el título del hilo es un selector: lista las otras sesiones de la conversación que estás leyendo — el mismo canal y, en un canal donde escriben varias personas (WhatsApp), la misma persona, una fila por día. No todos los hilos que tiene APX: abrir el WhatsApp de un contacto ofrece sus días, no el día de Telegram ni la conversación de otra persona. Alguien que escribió desde dos números sigue siendo una sola persona ahí, porque lo dice la agenda. Un par agente-a-agente y una sala de grupo son una conversación cada uno, así que ninguno de los dos lleva selector.
Un turno de varios pasos no se imprime como un log. Todas las herramientas que corrió el agente se colapsan en una fila N acciones — abierta mientras trabaja, cerrada cuando termina, un clic para ver argumentos y resultados, y cualquier error nombrado en la fila misma. Lo que queda a la vista es el mensaje de cierre: la respuesta para la que existía el turno. Si volvés a abrir la conversación más tarde ves lo mismo: los pasos quedan guardados con el turno, no solo streameados y olvidados. Prosa progreso sigue visible, pero no vuelve al prompt siguiente; sólo respuesta final entra historial conversación.
Invitar a alguien convierte el chat en grupo
Sección titulada «Invitar a alguien convierte el chat en grupo»Una conversación nunca se abandona para empezar otra. Sumar un agente a un 1:1 convierte ese chat: la transcripción pasa a una sala de grupo, el agente que entra puede leer todo lo que se dijo antes de que llegara, y el 1:1 queda archivado con un puntero a dónde sigue.
Un par agente-a-agente también es una sala — dos agentes hablando — así que se dibuja como tal, con cada hablante nombrado arriba de su burbuja en vez de etiquetado abajo. No tiene asiento para vos hasta que lo quieras: apenas escribís en un par, también se convierte, sentando a los que sean agentes de este proyecto (el asiento del super-agente pasa a ser el tuyo), y tu línea es lo primero que se dice en la sala nueva.
Un par que está trabajando lo dice
Sección titulada «Un par que está trabajando lo dice»Un turno agente-a-agente es un loop de herramientas completo que puede durar
minutos. Sin importar cómo arrancó — por HTTP, o porque un agente llamó a
send_to_agent / call_agent, incluido el trabajo que quedó corriendo de
fondo — el par muestra la misma narración en vivo que cualquier otro chat: dice
que alguien está respondiendo antes del primer token, las herramientas aparecen
mientras corren, y Stop llega al trabajo. Cancelar un job de fondo frena a su
peer por la misma razón.
Un chat que arrancás dentro de un proyecto queda listado en ese proyecto. El workspace Base sigue mostrando todos los hilos de todos los canales; un proyecto muestra los que se abrieron desde él, más los hilos de canal (Telegram, Desktop) que no pertenecen a ningún proyecto en particular.
Reenviar un mensaje a otra sesión
Sección titulada «Reenviar un mensaje a otra sesión»Cualquier mensaje de cualquier conversación —tuyo o de un agente— tiene una acción Reenviar al lado de Copiar. Pregunta dos cosas: a quién le llega y en qué parte de su historia cae. La sesión más reciente de quien elijas viene preseleccionada, así seguir una charla que ya venías teniendo es un solo clic; Sesión nueva es siempre la primera opción para el otro caso. Lo que escribas va debajo de la cita, y podés dejarlo vacío: “mirá esto” es un mensaje completo, y el agente responde al mensaje reenviado.
La lista no se limita a este proyecto. Para vos la instalación es un solo
conjunto de agentes, así que el selector cruza todos los proyectos registrados,
agrupados por el nombre de cada uno, con un buscador que matchea el nombre de la
persona, su slug o el proyecto donde está (lo sirve GET /api/agents). Reenviar a otro proyecto te lleva ahí y la charla sigue
en el chat de ese proyecto — la cita guarda de qué proyecto SALIÓ, así el link
de la tarjeta sigue abriendo la conversación correcta.
Del otro lado llega como una tarjeta que dice de dónde salió, quién lo dijo y cuándo, con un link de vuelta a esa sesión — así el reenvío se lee como una cita y no como un texto pegado sin autor. El agente lee los mismos tres datos: la cita viaja en el prompt, marcada como palabras de otro.
Hay conversaciones que no pueden recibir un reenvío, y quedan fuera de la lista
en vez de ofrecerse para después rebotar: los hilos de Telegram y WhatsApp (el
mensaje está en el teléfono de alguien; un turno escrito acá sale por web), los
transcripts entre agentes, los grupos, y cualquier hilo del super-agente que no
sea el de hoy en esta superficie — el super-agente no tiene archivo de
conversación, sus turnos se escriben con el reloj, y un mensaje puesto en el de
ayer se vería en un hilo y quedaría registrado en otro.
Responder dentro de un hilo de Telegram o WhatsApp
Sección titulada «Responder dentro de un hilo de Telegram o WhatsApp»Esos hilos se leen acá y no se pueden escribir: el mensaje se entregó en la plataforma de otro, y APX no puede retirarlo ni agregarle nada. El composer lo dice arriba del campo, y después hace lo honesto — lo que escribas sigue en una sesión nueva con el super-agente, con el último mensaje del hilo citado arriba del tuyo, y el panel se mueve ahí mientras manda. Antes la respuesta parecía caer en el hilo de Telegram y desaparecía en la siguiente recarga.
La pestaña Tasks es el backlog del proyecto. Además de los campos clásicos de
id/título/tags/fecha de vencimiento/agente asignado, las tareas ahora llevan un
estado de flujo de trabajo — pending, running, in_review o blocked mientras
están abiertas, y done/dropped una vez cerradas — mostrado con un ícono y color de
estado. Al abrir una tarea aparece un panel de detalle con estado y cuerpo editables,
y un enlace “View thread” cuando la tarea está vinculada a un hilo de chat. La lista
tiene paginación de servidor (ver más abajo) y se puede filtrar por estado (open / done
/ dropped).
Routines
Sección titulada «Routines»La pestaña Routines programa trabajo recurrente — un prompt del super-agente, un comando de shell, un mensaje de Telegram, o un heartbeat — en una expresión cron.
La pestaña MCPs lista los servidores Model Context Protocol disponibles para el proyecto en los tres scopes (shared, runtime, global), con un panel de logs en vivo. Los valores de header/config en el editor de MCP soportan el selector de tokens de variables — mirá Variables más abajo.
Memories
Sección titulada «Memories»La pestaña Memories muestra el contexto de larga vida que leen los agentes, un archivo
por fila. Un proyecto tiene dos. Memoria interna
(~/.apx/projects/<id>/memory.md) va primera y es la que abre: la escribe la tool remember
del super-agente y git no la ve nunca, así un dato levantado en medio de una charla no te mete
una credencial pegada en el historial. Memoria del proyecto (.apc/memory.md) es la curada,
la que viaja con el repo. Promover una línea de la interna a la committeada es una edición
manual acá. Abajo va la memoria propia de cada agente. La libreta
del super-agente (~/.apx/memory.md) es global, no de un proyecto, así que aparece solamente
en Base.
La pestaña Skills incrusta el mismo gestor de skills que se usa en Settings (mirá Skills), fijado al scope de este proyecto — habilitar, deshabilitar, agregar e inspeccionar skills sin salir del proyecto.
Structure Proyectos de empresa
Sección titulada «Structure »Para proyectos con kind: "company", aparece una pestaña Structure para gestionar
el modelo organizacional detrás de la asignación de agentes: Areas (por ejemplo
“Engineering”, “Sales”) y Roles dentro o fuera de un área. Las áreas y roles se
pueden crear, editar y eliminar acá, y están respaldados por .apc/organization.json.
Los mismos diálogos de creación rápida son accesibles desde los selectores de Area/Role
del editor de agentes.
apx web, luego abrí un proyecto de empresa → Structure Docs y Files
Sección titulada «Docs y Files»Dos pestañas navegan los archivos del proyecto con el mismo componente visor:
- Docs — editable. Enraizado en la carpeta de docs configurada del proyecto
(
docs.root, defaultdocs/). Soporta crear, editar (un editor de markdown split sin dependencias con preview en vivo) y eliminar archivos. - Files — de solo lectura. Navega todo el árbol del proyecto. Consciente del tipo: Markdown se renderiza, el código se muestra con números de línea, las imágenes se previsualizan inline.
apx web, luego abrí un proyecto → Docs → creá o abrí un archivo Artifacts
Sección titulada «Artifacts»La pestaña Artifacts lista los artifacts guardados bajo <project>/artifacts/ —
la misma lista que usa el panel lateral del módulo Code, ahora accesible desde la
navegación propia del proyecto. Run y Edit delegan al módulo Code
para que puedas pasar argumentos (por ejemplo una URL) en la terminal o editar el
archivo directamente, en lugar de ejecutar sin cabeza en el lugar.
La pestaña Config muestra la configuración efectiva del proyecto fusionada desde los
archivos .apc/ del proyecto y los defaults globales.
Variables
Sección titulada «Variables»La pestaña Variables (vars) gestiona valores secretos/de config nombrados y
enmascarados, en scope de proyecto o global (por ejemplo MY_API_KEY). Los valores
están ocultos por default con un toggle de revelar por fila y uno global. Donde sea
que un valor pueda referenciar una variable — por ejemplo los headers de un servidor
MCP — un selector de tokens (el botón ”+” junto al campo) te deja buscar e
insertar ${var.NAME}, renderizado inline como un badge $NAME para que la
referencia se lea como parte de la línea en vez de un string de template crudo.
apx web, luego abrí un proyecto → Variables, y MCPs → campo de header Módulos del riel
Sección titulada «Módulos del riel»Projects
Sección titulada «Projects»La pestaña Projects (Base → Workspaces) lista todos los proyectos registrados como tarjetas.
Hacé clic en una tarjeta para entrar a ese proyecto. El botón “New project” abre un diálogo
inline (?action=add-project).
Cada proyecto tiene una pestaña Agents. Podés crear, editar y eliminar agentes; ver
y editar el memory.md de cada agente; y asignar skills. En el espacio Base la
pestaña Agents muestra la configuración del super-agente (resumen de solo lectura).
Abrí un agente para inspeccionar su memoria, skills, herramientas, sub-agentes y grafo cerebral.
El editor también define un emoji (que se muestra junto al agente en toda la UI, incluido
el roster del Resumen), un nivel de autonomy — un selector de tres opciones para los mismos
modos de permiso que la CLI/config (total, automatico, permiso, etiquetados Total / Auto /
Permission) — y, para proyectos de tipo empresa, un Area y Role tomados de
Structure, con botones de creación rápida junto a cada selector.
Sessions
Sección titulada «Sessions»La pestaña Base Sessions (/p/0/sessions) lista todas las sesiones grabadas a través de
los engines. Un buscador (coincidencia por título por default, con un toggle “Deep” para
escanear el contenido de la transcripción) reutiliza la misma lógica de matching que
apx session find, más un filtro de engine y un botón Clear. Cada fila expone cuatro
acciones: copiar el comando apx session resume <id> --continue, pedirle al asistente que
continúe esa sesión desde una burbuja de chat rápido, abrir la carpeta de trabajo de la
sesión, y copiar su ruta.
El módulo Voices (/m/voice) configura TTS y STT globalmente. Muestra el
estado en vivo de cada motor TTS configurado (Piper, ElevenLabs, OpenAI, Gemini,
mock), te deja elegir un default o un modo de cadena-con-fallback, reordenar la cadena,
configurar credenciales por motor y correr una reproducción de prueba en vivo. La sección STT
configura el modelo y el idioma de Whisper para la entrada de micrófono.
Mirá Voz para la referencia completa de la CLI.
Desktop
Sección titulada «Desktop»El módulo Desktop (/desktop) muestra si la ventana flotante de Electron está
corriendo (clientes WebSocket conectados), te deja editar el atajo global y
alternar si el daemon responde a los mensajes de desktop. No podés iniciar ni detener
el proceso de Electron desde el panel web — usá apx desktop start / stop.
Mirá Desktop para la referencia completa de la CLI.
Deck Vista previa
Sección titulada «Deck »El módulo Deck (/m/deck) expondrá el payload de GET /api/deck/manifest: salud del daemon,
proyecto activo, plugins registrados y la grilla de widgets/desktop, y te dejará
habilitar o deshabilitar widgets individuales desde esta vista.
Mirá Deck para la referencia de la CLI de vinculación.
El módulo Code (/code) es la superficie de administración del asistente de codificación de
APX. Trabaja sobre una sesión de código: una transcripción persistente con su propio
baseline de git, modo plan/build y, opcionalmente, un agente del proyecto.
Abre con las sesiones de todos los proyectos, las más recientes primero — el selector de proyecto arriba del riel filtra la lista en vez de definirla. Importa porque una sesión pertenece al proyecto que resolvió su directorio de trabajo, así que una corrida arrancada en otro lado quedaría invisible acá. Cada fila dice de qué proyecto es y, si tiene uno, qué agente responde.
Nueva sesión hace las dos preguntas que son decisiones: en qué proyecto corre (archivos, terminal y diff quedan acotados a él) y qué agente responde — el super-agente, o cualquier agente de ese proyecto. Las dos quedan a la vista después en el panel Contexto, donde además se puede cambiar el agente de esa sesión.
La terminal comparte las mismas sesiones:
apx exec --code "refactorizá el middleware de auth"corre un turno en una sesión nueva titulada con tu prompt, imprime la respuesta por stdout e
imprime el id de la sesión por stderr para que puedas abrirla en el panel. Pasá
--session <id> para continuar una existente.
Si lo corrés desde una carpeta que no es un proyecto registrado, la sesión trabaja en esa carpeta.
En modo build el asistente lee el AGENTS.md del proyecto, lleva una checklist en trabajos de varios
pasos, edita con patches (apply_patch) o reemplazos exactos, corre los tests o checks del propio
proyecto antes de dar el cambio por hecho y termina con el diff. Arranca sólo con las tools de código;
lo demás (navegador, calendario, mensajería) lo activa cuando lo necesita. Cada turno nuevo de una
sesión sabe qué archivos leyeron y cambiaron los turnos anteriores.
La configuración global vive bajo Settings (/settings/*), agrupada en secciones.
Sub-secciones:
| Ruta | Sección | Qué edita |
|---|---|---|
/settings/identity | Account | Nombre del asistente, persona, zona horaria |
/settings/super-agent | Agents | Nombre, avatar, personalidad y prompt extra; modelo propio, modo de permisos, guardas (riesgo por acción, detección de loops, freno de gasto) y límite de pasos por canal |
/settings/engines | Agents | Proveedores de modelos (agregar, editar, alternar) |
/settings/memory | Agents | Memory (RAG) — config de embeddings y retrieval |
/settings/skills | Agents | Gestor de skills + RAG (Skill Inspector) — mirá Skills |
/settings/telegram | Channels | Token del bot de Telegram y canales |
/settings/devices | Channels | Lista de dispositivos vinculados |
/settings/voice | Modules | TTS/STT — igual que el módulo Voices del riel |
/settings/desktop | Modules | Configuración de la ventana Desktop |
/settings/deck | Modules | Configuración del companion Deck |
/settings/web | Modules | Web — tema, idioma y (vía Identity) zona horaria propios del panel |
/settings/advanced | Advanced | Editor crudo de ~/.apx/config.json |
La vieja ruta /settings/appearance sigue funcionando — ahora abre /settings/web.
El panel Super-agent define el modo de permisos de Roby, su personalidad y su system prompt; el modelo activo y la cadena de fallback se configuran en el router de modelos.
El panel Web controla la UX propia del panel en vez de la identidad del agente: elegí Light, Dark o System (sigue el esquema de color del sistema operativo) para el tema, y cambiá el idioma de la UI — la página se recarga una vez para que todos los strings renderizados tomen el nuevo locale.
apx web, luego Settings → Modules → Web El panel Telegram gestiona los canales del bot, los contactos y los permisos de herramientas por rol.
El panel Devices lista cada navegador o teléfono vinculado y te deja revocar un token.
Vistas de lista: paginación y layout de altura completa
Sección titulada «Vistas de lista: paginación y layout de altura completa»Las listas de Sessions, Tasks globales y Tasks por proyecto usan paginación real de
servidor: el daemon pagina por ?limit y ?offset y devuelve el conteo total de filas
en un header X-Total-Count, así el panel solo trae la página actual y muestra un rango
real (“1–20 of 485”) y un conteo de páginas en vez de estar topeado a un tamaño de fetch
fijo. El tamaño de página es seleccionable (10/20/50/100, default 20). Estas pestañas de
lista también usan un layout de altura completa: la lista scrollea internamente mientras
el paginador queda fijo abajo, así toda la vista entra en una pantalla.
Arquitectura
Sección titulada «Arquitectura»El panel es un cliente liviano: no tiene estado local más allá de la sesión actual. Cada lectura es un GET contra la API HTTP del daemon; cada escritura es un PATCH o POST. El daemon es la única fuente de verdad.
Browser → GET/POST → http://127.0.0.1:7430/<route> ↓ APX daemon (host/daemon/) ↓ core/ (logic, memory, agents…)El bundle web es servido por src/host/daemon/api/web.js. Las rutas de la API siempre
tienen prioridad sobre el catch-all de la SPA, así que una petición a /api/projects/1/agents pega
en el endpoint real, no en index.html.