> ## Documentation Index > Fetch the complete documentation index at: https://docs.fetchhive.com/llms.txt > Use this file to discover all available pages before exploring further. # Registros > Inspecciona historial, estados, trazas, nodos, costes, fuentes y resultados parciales de Hive Agents Los logs de Hive Agents muestran todas las ejecuciones del workspace en una tabla y permiten revisar traza, nodos, fuentes, ledger de presupuesto y respuesta final. ## ¿Cómo abro los logs de Hive Agents? Abre **Hive Agents** en la barra lateral. Haz clic en **Logs**. ## ¿Cómo filtro logs? Usa rango de fechas, paginacion, columnas, filtros y la navegacion de **Source** para **All Sources**, **Dashboard** y **API**. Los logs admiten **Hive Agent**, **Status**, navegacion de origen para **All Sources**, **Dashboard** y **API**, y busqueda por nombre, objetivo o request ID. ## ¿Cuál es la diferencia entre pase e intento? Un **pase** es una ronda completa de ejecucion y verificacion de la ejecucion. Si uno o mas nodos son rechazados, Hive Agents puede iniciar otro pase para el trabajo que todavia necesita correccion. Un **intento** es una ejecucion o verificacion especifica de un nodo individual. Un nodo puede mostrar varios intentos cuando se ejecuta, se revisa, se rechaza y se vuelve a intentar. En la consola de ejecucion, un nodo puede mostrar **Pendiente de verificacion** despues de que termine su intento de ejecucion y antes de que empiece el verifier. Es un estado visual para leer el progreso en vivo, no un estado guardado de la ejecucion. Los **Compose attempts** son distintos de los intentos de nodo. Reconstruyen y revisan la respuesta final despues de que el trabajo de nodos requerido ya fue verificado. Ejemplo: si el pase 1 verifica dos nodos y rechaza uno, el pase 2 reintenta el nodo rechazado. Ese nodo puede mostrar varios intentos porque se registra cada intento de ejecucion o verificacion. ## Glosario de estados | Estado | Significado | | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `pending` | La ejecucion fue creada y espera iniciar | | `preparing_sources` | Fetch Hive procesa fuentes antes de planificar | | `planning` | El planner crea nodos y criterios | | `executing` | Los executors trabajan en nodos | | `verifying` | El verifier revisa salidas | | `retrying` | Los nodos rechazados vuelven a otro pase | | `composing` | El composer arma y verifica la respuesta final | | `blocked` | La ejecucion llego a un gate de presupuesto. Usa `budget_block_state` para diferenciar pausas: `awaiting_approval` significa que el workflow espera aprobacion por magic link (`ended_at` es null); `stopped` significa que la ejecucion termino por presupuesto (hard cap, aprobacion rechazada o aprobacion expirada) y `ended_at` esta definido | | `completed` | La ejecucion termino correctamente o en best effort | | `failed` | La ejecucion no pudo terminar | | `cancelling` | Se pidio cancelacion | | `cancelled` | La ejecucion fue cancelada | ## ¿Cómo leo la hoja de detalle? Haz clic en una fila. La vista principal muestra respuesta final, fuentes, nodos, presupuesto y configuracion de ejecucion. La respuesta final usa la composicion aceptada cuando existe; las salidas verificadas siguen disponibles como detalle de soporte. La Run Console muestra banners separados para **awaiting approval** (puedes aprobar para continuar) y **stopped on budget** (la ejecucion ya termino). El banner de stop usa el evento de presupuesto que bloqueo la ejecucion cuando esta disponible: distingue gasto que ya llego al cap de bloqueos donde el coste proyectado del siguiente paso excederia el cap, y usa el cap registrado al bloquear, no un valor posterior del blueprint. El gasto de presupuesto en la consola usa `cumulative_cost_usd`, la misma cifra que aplica `BudgetGate`, no la estimacion `projected_cost_usd` del plan. ## ¿Cómo funcionan las trazas? La traza muestra preparacion de fuentes, planning, execution, verification, repeat decisions, compose attempts, budget checks, reintentos y finalizacion. Los spans de compose aparecen en cuanto empieza la composicion, no solo cuando el composer termina. Mientras un intento de compose esta en curso, el estado de la ejecucion es `composing` y `run_config.composition.status` es `running`. Los spans de execute y verify tambien aparecen mientras cada etapa de nodo esta en curso (`status: running`) y se completan en la misma fila cuando la etapa termina. La cascada agrupa execute y luego verify por nodo y pass usando orden semantico (`pass_number`, posicion del nodo, execute antes que verify), no solo la hora de inicio — asi el trabajo paralelo sigue siendo legible aunque los child traces terminen en momentos distintos. Selecciona una etapa para ver **Input**, **Output** y **Metadata**. Las etapas fallidas, bloqueadas o reintentables muestran una alerta de incidencia. Los spans de presupuesto muestran la configuracion de presupuesto en el encabezado del span, y los spans de repeticion muestran ahi la configuracion de repeticion. El mensaje de fallo de la ejecucion aparece en el overview y en las etapas terminales, mientras que los budget checks permitidos se mantienen como informacion. Las llamadas de planner, executor, verifier y composer pueden expandirse con su AgentRun hijo, incluyendo razonamiento del modelo, respuestas LLM y paneles de entrada y respuesta de herramientas. ## ¿Qué ocurre después de cancelar con resultado parcial? La cancelacion con resultado parcial detiene trabajo nuevo, deja terminar trabajo ya iniciado y conserva salida verificada. El estado final sigue siendo `cancelled`. Ver también: [Log History](../monitoring/log-history) and [Troubleshooting](./troubleshooting).