record_llm_call
Record a single LLM call event, including the prompt sent, the response received, token usage, and any metadata you want to attach.
Parameters
Model name, for example
"gpt-4" or "claude-3-opus". Required.Prompt sent to the model. Accepts a string, dict, or list (e.g. a chat messages array).
Model response. Accepts the same types as
prompt.Token usage dictionary. Expected keys:
prompt_tokens, completion_tokens, total_tokens.Freeform metadata such as step labels, experiment tags, or any key-value pairs you want visible in the timeline.
Provider name:
"openai", "anthropic", "local", etc.Sampling temperature used for this call.
Why the model stopped generating:
"stop", "length", etc."ok" for a successful call, "error" if the call failed.Error details when
status="error". Accepts an exception, a string message, or a dict.record_tool_call
Record a tool call event: the tool name, its inputs, and either a result or an error. Typically called immediately after your tool function returns.
error:
Parameters
Tool name as it appears in your agent code. Required.
Arguments passed to the tool. Accepts any serialisable type.
Return value from the tool.
Freeform metadata. Useful for tagging calls with step numbers, environment labels, or experiment identifiers.
"ok" for a successful call, "error" if the tool raised.Error details when
status="error".record_state
Record a state-update event — a snapshot of your agent’s internal state at a point in time. This is useful for capturing message history length, memory contents, or any structured data that helps you understand where the agent is in its reasoning.
Parameters
State snapshot. Accepts any object or string that describes the agent’s current state.
Freeform metadata.
Optional diff from the previous state, if you want to record only what changed.
record_state does not increment the LLM or tool call counters used by guardrails. It is safe to call it as often as you like without affecting guardrail thresholds.Full example: ReAct-style agent loop
The following example shows all three recording functions working together inside a ReAct-style loop that alternates between LLM reasoning and tool execution.agentdbg view shows every LLM call, tool call, and state update in the order they occurred — making it straightforward to see where the agent went wrong or got stuck in a loop.
Redaction and truncation
All threerecord_* functions apply the same data-safety rules before writing events to disk:
- Redaction: Dict keys matching configured patterns (such as
api_key,token, orpassword) have their values replaced with__REDACTED__. This is applied recursively up to a depth of 10. - Truncation: Strings longer than
AGENTDBG_MAX_FIELD_BYTES(default: 20 000 bytes) are truncated and suffixed with__TRUNCATED__.
| Setting | Environment variable | YAML key |
|---|---|---|
| Redacted field names | AGENTDBG_REDACT_KEYS | redact_keys |
| Enable/disable redaction | AGENTDBG_REDACT | redact |
| Max field size (bytes) | AGENTDBG_MAX_FIELD_BYTES | max_field_bytes |