Traces Open-Core

Traces are the audit trail of every AI agent request that flows through the Intutic proxy. Each trace records what happened, what enforcement action was applied, and how much it cost.

In open-core the proxy writes traces locally as daily-sharded JSONL under ~/.intutic/logs/ (traces-YYYY-MM-DD.jsonl, one record per line, capped at 64MB/day — see Local vs connected below for what that cap means for you). With no connected control plane, intutic traces list / intutic traces inspect now read that log directly — no cat/jq needed, though you're always free to do that too. The REST API shown alongside each CLI example below is the connected-mode equivalent, and connected mode is still the only way to see a trace's compliance score and enforcement action.

What's in a trace?

Each execution trace contains (field names as written to the local JSONL; connected mode camelCases them over the API):

Field	Description
trace_id	Unique identifier (a UUID minted by the proxy)
session_id	The agent session this trace belongs to
created_at	ISO 8601 timestamp of the request
model / provider	The LLM model and provider used
requested_model / actual_model_routed	The model the caller asked for vs. the one that actually served the request
raw_input_tokens / output_tokens	Token counts
raw_cost_usd / actual_cost_usd	Cost had the requested model served it, vs. the actual cost of the routed model's response
cache_hit / cache_read_input_tokens / cache_creation_input_tokens	Whether the proxy's own response cache served the request, and the provider's prompt-cache token counts
latency_ms	Request latency
verdict	The proxy's own enforcement verdict — locally, exactly one of allowed, killed, upstream_error, reasked, hijacked
harness_type	Which coding agent/IDE issued the request

Two fields you may see referenced elsewhere are connected-mode only: a compliance/quality score, and the enforcementAction the control plane's PCAS layer records. When a trace reaches a control plane, its verdict becomes the enforcement action: allowed → BYPASS, hijacked → HIJACK, reasked → REASK, killed → KILL, and upstream_error → OBSERVED (the provider failed, so nothing was enforced). ENHANCE has no local verdict.

Local vs connected

	Local (no control plane)	Connected
Data source	~/.intutic/logs/traces-*.jsonl, read directly	Control-plane API
traces list / inspect	Read the local log	Query the API
Compliance / quality score	Not available — never fabricated as a placeholder	Available
Enforcement action	verdict only (allowed/killed/upstream_error/reasked/hijacked)	BYPASS/ENHANCE/HIJACK/REASK/KILL, or OBSERVED
Filtering	--verdict	--action (BYPASS/ENHANCE/HIJACK/KILL)
History depth	Whatever's on disk, capped at 64MB/day per shard — see below	Retained per your plan
--json output shape	{traces, total, malformedLines, cappedFiles} — its own local shape	TraceListResult

The 64MB/day cap is real, and the local reader is the only place you can learn you've hit it. Past that size, the proxy silently drops further writes for the rest of that day rather than growing the file without bound — so a very high-traffic day's trace count from intutic traces list may be a floor, not a complete record. The CLI warns you explicitly when a day-file it read had already reached the cap.

Listing traces

CLI

# List last 20 traces (default)
intutic traces list

# Show 50 traces from the last 7 days
intutic traces list --limit 50 --since 7d

# Filter by enforcement action (connected mode only)
intutic traces list --action KILL

# Filter by verdict (local mode only)
intutic traces list --verdict killed

# Filter by model
intutic traces list --model claude-4-sonnet

# Output as JSON
intutic traces list --json

With no connected control plane, list reads ~/.intutic/logs/ directly — no compliance-score column (there is no local compliance score) and --action refuses to run, since BYPASS/ENHANCE/HIJACK/KILL don't exist locally; use --verdict instead. See Local vs connected.

CLI options:

Option	Description	Default
--limit <n>	Number of traces (1–100 in connected mode; the local reader applies no maximum)	20
--since <duration>	Time window: 30m, 24h, 7d	24h
--action <type>	Filter: BYPASS, ENHANCE, HIJACK, KILL — connected mode only	(all)
--verdict <type>	Filter: allowed, killed, upstream_error, reasked, hijacked — local mode only	(all)
--model <name>	Filter by model name	(all)
--json	JSON output instead of table	false
--dev	Use local control plane	false

Inspecting a trace

CLI

intutic traces inspect tr_abc123

With no connected control plane, inspect searches ~/.intutic/logs/ for a matching trace_id and prints the raw local record — token counts, costs, verdict, and everything else the proxy logged for that request, but no compliance score or corrective prompt card (both connected-mode-only). Connected mode's response additionally includes:

• Compliance scores
• Anomaly data (if any)
• Corrective prompt card (if enforcement was applied)

Understanding enforcement actions

BYPASS

The request was fully compliant with all active SOPs. No modification needed. This is the ideal state.

ENHANCE

The request was compliant but could be improved. The proxy enriched the prompt, upgraded the model, or added context. The original intent is preserved.

HIJACK

The request was rerouted — typically for cost optimization (downgrading an expensive model to an equivalent cheaper one) or capability routing (sending a coding task to a code-specialized model).

REASK

The attempt was refused and the reason handed back to the agent, which may correct course and retry. Repeated trips escalate to KILL.

KILL

The request was blocked. Common reasons:

• Budget exceeded for the user's tier
• SOP policy violation detected
• A deterministic anomaly detector fired (loop, forbidden tool, credential sweep, budget breach)
• Unauthorized tool call attempted

OBSERVED

The provider failed to answer (a 5xx or a model it could not serve), so there was no response to act on. The trace is a record of the failure, not of an enforcement.

What a trace keeps

Beyond the fields above, the proxy keeps two records that can name what an agent touched. Both are stored redacted for every secret pattern and every PII detector, email and phone included, whatever the live DLP actions:

• Change manifest — one entry per file, URL or command a tool call named: the tool, operation, target, kind, risk and size. Change manifests a connected workspace stored before 2.6.0 have their targets replaced with [WITHHELD] when its control plane upgrades; each entry keeps its tool, operation, kind, risk and size, and integrity roots sealed over those traces still verify (see Trace Integrity).
• Replay context — on a sample of requests (WASM_CONTEXT_SNAPSHOT_RATE, 5% by default), the rule-evaluation context, so a new rule can be replayed against real traffic. Each tool call keeps its name and its arguments' top-level keys and size, not the argument values (tool_arguments: "keys_only"). A connected workspace can keep the values, redacted, with the storeToolArguments setting.