Logs

Hive Agent logs show every workspace Hive Agent run in one table and let you inspect the run’s trace, nodes, sources, budget ledger, and final response.

​

How do I open Hive Agent logs?

Open Hive Agents in the sidebar. Click Logs in the secondary navigation. Hive Agent logs use a workspace-wide run table and include Source navigation for All Sources, Dashboard, and API runs.

​

How do I filter logs?

Use the date-range control, pagination, column visibility, and table filters. Hive Agent logs support:

• Hive Agent
• Status
• Source navigation for All Sources, Dashboard, and API
• Text search by Hive Agent name, objective, or request ID

The table includes Hive Agent, Objective, Status, Pass, Nodes, Sources, Total Tokens, Total Cost, Duration, API Key, and Collaborator. Hover the tokens, tasks, or cost totals to open the stage usage breakdown: one Plan row aggregates planner validation retries with nested Attempt #1, Attempt #2, and so on, while execute/verify node attempts keep their pass labels.

​

What is the difference between pass and attempt?

A pass is one full execute-and-verify round for the run. If one or more nodes are rejected, Hive Agents can start another pass for the work that still needs fixing. An attempt is a specific execute or verify try for an individual node. A node can show multiple attempts when it is executed, checked, rejected, and retried. In the Run Console, a node can show Pending verification after its execute attempt has completed but before the verifier has started. Retried nodes also move out of Failed while the run is actively executing or verifying them again on a later pass, using live attempt and pass data rather than the last stored failure row. Compose attempts are separate from node attempts. Compose attempts rebuild and check the final response after the required node work has already been verified. Example: if Pass 1 verifies two nodes and rejects one node, Pass 2 retries the rejected node. That retried node may show several attempts because each execute or verify try is recorded.

​

Status glossary

​

How do I cancel a running Hive Agent?

While a run is active, open the Run Console from Hive Agent logs or open the run from request detail (global search, experiments, or the technical trace sheet). Click Cancel run in the sheet header and choose how to stop:

• Stop now — stops immediately and marks remaining work cancelled
• Stop and keep verified work — stops scheduling new work, lets in-flight steps finish, and keeps verified node output

The status moves to cancelling while the run drains, then cancelled when finished. See Troubleshooting — cancelled for hard-stop vs partial-result behavior.

​

How do I read the detail sheet?

Click a run row. The root run overview keeps the final response, source list, node overview, budget ledger, and run config together. The final response prefers the accepted composed response when one is available. Verified node outputs remain available as supporting detail. In best-effort mode, unverified nodes stay flagged so you can see what did not pass. Node details can show output, rejection reasons, verification checks, pass number, cost, tokens, and linked child AgentRun details. The Run Console shows separate banners for awaiting approval (you can approve to continue) versus stopped on budget (the run is finished). The stopped banner uses the blocking gate event when available: it distinguishes spend that already hit the cap from blocks where the next step’s projected cost would exceed the cap, and it uses the cap recorded at block time rather than a later blueprint value. Budget spend in the console uses cumulative_cost_usd — the same figure BudgetGate enforces — not the plan-time projected_cost_usd estimate.

​

How do traces work?

Hive Agent traces show the loop as a waterfall:

• Source preparation
• Planning
• Execution
• Verification
• Repeat decisions
• Compose attempts
• Budget checks and budget events
• Retryable stage errors
• Final completion, failure, or cancellation

Compose spans appear as soon as composition starts, not only after the composer finishes. While a compose attempt is running, the run status is composing and run_config.composition.status is running. Execute and verify spans also appear while each node stage is running (status: running), then complete on the same span row when the stage finishes. Execute, verify, compose, and compose verify are sibling root-level spans; imported child AgentRun details stay nested under their own stage anchor. The waterfall orders spans by lifecycle phase and pass (order_pass, order_phase, node position, execute-before-verify), not wall-clock start time alone — so prepare, pre-plan budget gates, plan, per-pass budget gates, execute nodes, verify nodes, compose, compose verify, and terminal spans stay readable even when child traces finish at different times. Compose stage spans keep the full attempt envelope while imported composer child spans are scaled to fill that window. Budget spans (agent_task.budget_gate_check, agent_task.budget_step_cost, agent_task.budget_threshold_crossed) are semantic markers anchored to stage start or end — not separate work units. Per-node execute gates nest under their execute_node row; step costs and threshold crossings appear at the end of the stage envelope. Pass-level gates stay at the root but align to the earliest execute in that pass. When verify fails before semantic checks (for example failure_reason: no_execute_attempt), the verify span input includes wired_execute_attempt_id from the workflow handoff for debugging. Execute and verify stage span metadata also carries stage_pair_key ({node_id}-p{pass}-a{attempt}), paired_span_id (the counterpart span id), and verify_attempt_id on the execute row after verify finishes. Older traces can backfill these fields via agent_tasks:repair_trace_lifecycle. Select a stage to see its Input, Output, and Metadata. Failed, blocked, or retryable stages show an issue alert. Budget spans show budget settings in the span header, and repeat spans show repeat settings there. A run-level failure message appears on the run overview and terminal spans, while allowed budget checks stay informational. Planner, executor, verifier, and composer calls can expand to show their child AgentRun trace inline, including model reasoning, LLM responses, and tool input and response panels. Use the child request link when you need to open that exact run separately.

​

What happens after partial-result cancellation?

A partial-result cancellation stops new node work, lets already-started node work drain, and stores verified node output in the run details. The run status is still cancelled, but the verified partial result remains available from the detail sheet. See also: Log History and Troubleshooting.