Reporting, logs and replay
With AEL, the Agent Engineering Language, you see what your agents did and what it cost. Time and token usage is reported by default on every channel, structured logs go to the sinks you choose, and you record runs and replay them.
Time and token reports
Time and token usage is reported by default on every channel: the command line, HTTP, gRPC, WebSocket and sockets. Each operation reports:
- its elapsed time;
- input tokens, output tokens and total tokens.
| Channel | Where the report goes |
|---|---|
| Command line and console programs | A summary on standard error, so the answer on standard output stays unchanged for pipes and scripts. |
| HTTP | Response metadata; a streamed response sends a final report when it ends. |
| gRPC, WebSocket and sockets | The channel's own metadata or final message, per operation. |
A server package adds its channel's report only when you add that server: a console program carries no server code for reporting.
Honest numbers
- Every model call counts once: retries, fallbacks, parallel branches, repairs, verifiers and child agents are each counted, and never twice.
- A count is marked as reported by the provider, estimated or unknown. An unknown count is never shown as zero, and an estimate is never shown as exact.
- A count is reported as a known zero only when AEL can tell that no model work happened. When it cannot, for example because an outside program you started may have called a model, the count is unknown.
- A report shows tokens used, not tokens reserved for work that has not happened.
- Times are measured with a clock that only moves forward. Durations of work that ran in parallel are never added up to claim a longer total.
Turning reports off
You can turn off each field without disabling the limits behind it:
- all reporting at once;
- time alone, or tokens alone;
- input, output or total tokens, one at a time;
- one channel.
Settings come from, in order: an authorized override for one operation, a named deployment environment setting, the deployment's configuration, your project, then the defaults. The settings an operation starts with stay fixed until it ends. You can show times in automatic units, or in nanoseconds, microseconds, milliseconds, seconds, minutes or hours.
- Turning reporting off never turns off budgets, limits or required audit records.
- A total can reveal a hidden count: to keep output tokens private, hide the total as well.
Structured logs
Structured logs go to the console, a file, or custom or remote sinks, with redaction, rotation and retention.
- Events. Every log event carries the tenant, the run, the agent and node, the prompt and configuration versions, a severity and a timestamp. Events cover prompt fallbacks, model attempts, retrieval, tool and delegation calls, verification decisions, retry waits, budget exhaustion and each run's outcome.
- Sinks. You send events to the console, to files as JSON lines, to a remote collector or to a sink you write in AEL, and route them by severity or by agent.
- Rotation and retention. Files roll over by size or time, and old files are removed by your retention rules.
- Redaction. By default, logs record metadata and redacted errors. Recording prompts, inputs or outputs is a separate choice, with its own access and retention rules. Credentials are never logged.
- Bounded. A slow or failing sink never holds up your agents indefinitely: its buffer is bounded, and a failure is reported through a fallback route.
- Audit apart. The program's own audit records are kept apart from your application's logs, and your code cannot erase them.
Console and logging describes events, sinks and redaction in detail, and Logging and monitoring where logs go on each kind of target.
Record and replay
You record control and orchestration runs and replay them to find the first point where behaviour diverged.
- A recording holds what came from outside the run: inputs, timing, scheduling choices, random seeds and the responses of models, tools and services, with the identity of the build, prompts and configuration.
- Replay feeds the recorded responses back in, and never makes a live call or a real side effect.
- A divergence report shows the first event that differs, the source and prompt involved, and the expected and observed typed values.
- An exact replay needs the same build and target. Replaying across a changed build, prompt or machine is a separate, best-effort mode, and says so.
- A recording with gaps is marked incomplete rather than treated as whole. Recordings have size limits, redaction and retention rules like logs.
- Replay never needs a model's hidden reasoning, and it does not make a live model's output reproducible.
The Command-line reference lists recording and replaying runs among the capabilities without a command name.