Skip to main content
Trace Kiro CLI agent turns, tool calls, and credit usage in Arize AX for full observability.
Kiro is AWS’s agentic IDE and CLI for spec-driven development. The Arize Coding Harness Tracing registers hooks on a Kiro agent and exports OpenInference spans to Arize AX. Each agent turn is captured as an LLM span with tool calls, model info, credit cost, and turn duration.

Launch Arize AX

To get started, sign up for a free Arize AX account and get your Space ID and API Key:
  1. Log in at app.arize.com
  2. Click Settings and copy the Space ID
  3. Open the API Keys tab and create or copy an API key

Install

Curl installer

macOS / Linux:
Windows (PowerShell):

Local clone

Kiro asks two questions of its own before the shared setup below:
  1. Agent name — the Kiro agent to install hooks into (default: arize-traced). Also settable as ARIZE_KIRO_AGENT.
  2. Set as default — whether to run kiro-cli agent set-default <name> so that agent is used by default. Also settable as ARIZE_KIRO_SET_DEFAULT.
The installer runs a short interactive setup. Every harness in the Arize Coding Harness Tracing repo asks the same questions, in the same order.

Setup walkthrough

1. Backend selection

Choose where spans are sent:
  • Phoenix — your own Phoenix instance.
  • Arize AX — the hosted Arize platform.

2. Credentials

The prompts depend on the backend you picked.
  • API key — create one on the API keys tab.
  • Space ID — shown on the same settings tab as your API keys.
  • OTLP endpoint — defaults to otlp.arize.com:443. Override it only for a hosted or dedicated instance.
If you have already configured another harness against the same backend, the installer offers a copy-from menu so you can reuse those credentials instead of retyping them.

3. Project name

The project that this harness’s spans are grouped under. Defaults to the harness name.

4. User ID (optional)

A free-form identifier attached to every span as user.id. Useful when teammates share one backend. Leave it blank to skip.

5. Content logging

Three [Y/n] opt-outs that apply to every harness, not only the one you are installing:
  • Log user prompts?
  • Log what tools were asked to do (commands, file paths, URLs)?
  • Log what tools returned (file contents, command output)?
You are asked these only the first time you install any harness. Later installs reuse the existing logging block in ~/.arize/harness/config.json, which you can edit at any time.

Install flags

Non-interactive install

Pass --non-interactive (or -y) to skip every prompt above and take each value from the environment instead. Nothing is asked, and a missing required value is an error rather than a prompt, which makes this the mode to use from a script, from CI, or when a coding agent is driving the install itself. Values come from the environment, or from a dotenv file named explicitly with ARIZE_ENV_FILE. Naming a file keeps the API key out of the command line and your shell history.
A named ARIZE_ENV_FILE outranks the environment, and there is deliberately no automatic ./.env search. Reading the working directory would let a cloned repository’s dotenv choose ARIZE_OTLP_ENDPOINT or PHOENIX_ENDPOINT while your real credentials came from the environment, installing a config that ships spans and a bearer API key to an endpoint the repo picked, for every later session on that machine. Name the file you mean.
Content logging is off by default in this mode, unlike the interactive wizard where each question defaults to yes. A [Y/n] default is a person declining to change an answer they were shown; the same default unattended would capture prompts, commands, and file contents that nobody agreed to. Set the ARIZE_LOG_* variables you want to true.
The API key is never echoed. The installer reports only that it found one and where it came from, and every resolved value is reported with its source, so a wrong-credentials install stays diagnosable:

Check what’s installed

status reports which harnesses are configured and whether their hooks are actually wired into each harness’s own settings file. Both have to be true for traces to appear.
hooks: NOT registered means credentials are saved but the harness was never wired up, or something removed the hooks. Re-run the install for that harness. Use --json from a script or a coding agent to gate on the exit code without parsing output: 0 means every configured harness is wired up, 1 means nothing is configured, and 2 means at least one harness’s hooks are missing. The payload contains no secrets — an API key appears only as "api_key_present": true — so it is safe to paste into a bug report.

Keep it up to date

update pulls the latest code and re-registers every harness already in config.json.
Re-registering runs each harness’s installer, so in a terminal it still asks for each project name. With no terminal to answer on, in CI or a cron job, it takes the stored values instead of failing: credentials are not re-read on that path, and the project name keeps whatever is in config.json. Once installed, run Kiro as usual. If you set the traced agent as the default during install:
Otherwise, point Kiro at the traced agent explicitly:

Configuration

Credentials live under harnesses.kiro in ~/.arize/harness/config.json (written by the installer). Environment variables override values in config.json and can be set in your shell profile so they apply to every Kiro session.

Redaction controls

Each ARIZE_LOG_* flag accepts "true" or "false" and defaults to "true". Set to "false" to opt out per category:
The same flags can be set in config.json under harnesses.kiro.logging as log_prompts, log_tool_details, and log_tool_content — env vars take precedence.

Observe

Once tracing is enabled, Kiro activity is streamed to Arize AX. You’ll see:
  • Turn traces — each agent turn (user prompt to assistant response) as a parent LLM span
  • Tool call spans — one per pre/post tool event pair, parented to the LLM turn
  • Session grouping — all turns from the same Kiro session grouped by session.id
  • Credit cost — Kiro meters in credits rather than tokens; cost is captured as kiro.cost.credits
  • Model and durationllm.model_name, kiro.turn_duration_ms, and kiro.context_usage_percentage from the session sidecar

Hooks Captured

Span attributes

LLM spans are enriched from the session sidecar at ~/.kiro/sessions/cli/<session_id>.json with model name, cost in credits, metering usage, and turn duration. Enrichment is fail-soft — if the sidecar is unavailable, the span is emitted with basic attributes only.

Known limitations

  • Token counts are 0. Kiro CLI does not report prompt or completion token counts in current versions and meters in credits instead. Token count attributes are omitted when 0; see kiro.cost.credits.
  • FIFO tool matching. Kiro does not expose a tool-call ID, so pre/post tool events are matched using a FIFO stack. This assumes serial tool execution within a session.
  • Per-workspace agents not supported. Only global agents under ~/.kiro/agents/ are instrumented.

Reference

For the full list of environment variables, default file paths, and troubleshooting steps, see the Kiro tracing README.

Uninstall

Uninstall removes hook entries from every Kiro agent file. If the arize-traced agent was created by the installer, that agent file is deleted; pre-existing agents are preserved.

Resources

Arize Coding Harness Tracing

OpenInference

Kiro Documentation