---
title: "Chat Output Validation"
id: "579"
type: "page"
slug: "chat-output"
published_at: "2026-06-03T14:29:15+00:00"
modified_at: "2026-06-11T14:02:26+00:00"
url: "https://xedant.com/code/docs/validation/chat-output"
markdown_url: "https://xedant.com/code/docs/validation/chat-output.md"
excerpt: "Chat output validation is the first and most immediate layer of validation in Xedant Code.…"
---

# Chat Output Validation

[https://xedant.com/code/docs/validation/chat-output.md](https://xedant.com/code/docs/validation/chat-output.md)

Chat output validation is the first and most immediate layer of validation in Xedant Code. Every tool call the AI makes is fully inspectable — file contents, diffs, write operations, and bash command outputs all appear as structured, clickable elements in the chat. Unlike the raw Claude Code CLI where you see a text stream, Xedant Code renders each operation as a dedicated UI component you can expand, review, and verify.

![Chat output validation](https://xedant.com/wp-content/uploads/2026/06/chat-output-validation.png)## Inspecting Tool Calls

Each tool call the model makes generates a message in the chat. In full display mode, successful file reads and edits are collapsed by default to keep the conversation clean, but you can expand any tool message to see exactly what happened.

### File Reads

When the model reads a file, a tool-read message appears showing the file path. Click it to expand and see the full file contents that were returned to the model. This lets you verify that the model is reading the correct file and that its decisions are based on the right information.

### File Edits and Diffs

File edit messages display a **unified diff** comparing the original and modified content. The diff is rendered side-by-side with removed lines (red, `-` prefix) and added lines (green, `+` prefix). Each edit includes hunk headers with line numbers. Expand the diff to verify exactly what the model changed — catch unwanted modifications, unnecessary additions, or incorrect fixes before they accumulate.

### Compact Mode

In compact display mode, tool calls and their results are combined into single collapsible items. Each shows a status icon (spinning while processing, green checkmark on success, red exclamation on error). Click any compact message to expand it and see the full diff or output. This mode is useful for reviewing many operations at a glance.

### Error Messages

When a tool call fails, the error is highlighted with a red border and destructive styling. In full display mode, the error content is expanded so you can immediately see what went wrong. In compact mode, errors follow the same collapse behavior as other messages — click to expand the full error output. If you see repeated tool call errors, **don’t ignore them** — this is not normal. Always investigate what’s going wrong and ask the model to update either `CLAUDE.md` (for project-specific issues) or the current skill (for general patterns). It typically takes only 5–10 such iterations to reach 99% accuracy even on complex tasks. Never take errors for granted.

## Per-Message Statistics

Every message carries detailed usage metadata. Hover over any message to see its stats, or look at the page header for aggregate totals.

- **Processing Time** — How long the model spent generating that particular output (formatted as seconds, e.g. “1.2s”)
- **Input Tokens** — Prompt tokens sent to the model for that turn
- **Output Tokens** — Completion tokens the model generated
- **Cache Read Tokens** — Tokens served from prompt cache (cheaper and faster)
- **Cost** — Calculated cost based on the environment’s pricing model (input, output, and cache token rates). To see accurate dollar amounts, configure the correct model pricing in your [environment settings](/code/docs/environments) — cost figures are meaningless without it.

In compact mode, tool messages and their result messages are combined — so the displayed stats show the total for both the tool call and its response together.

**Keep in mind**: providers often report cumulative stats for several messages in a row, mostly when assistant messages arrive. These stats come with a 1–2 second lag because they are extracted from the log — so you’ll see the final correct stats only when the chat has finished, or when more than 10 seconds have passed since the message arrived.

## Live Header Stats

A floating badge below the header displays real-time aggregate statistics while the model is working. In non-hovered mode it shows three metrics:

- **Message count** — Total messages in the current chat (e.g. “5 msg”)
- **Total cost** — Cumulative cost for the entire chat session (e.g. “$0.15”)
- **Tokens/second** — Processing speed calculated from output tokens and processing time

When the chat has active subagents, each metric switches to a **main/agentic** combined format (e.g. “5/12 msg • $0.15/$0.30 • 45/60 tps”), where the first value is the main chat and the second is the aggregate of all subagent chats. Hovering reveals a full breakdown: without subagents it adds cache read, input, and output token totals; with subagents it shows two separate lines — one for the main chat and one for the combined subagent stats — each with message count, cost, tps, cache, input, and output tokens. A **timer** showing cumulative processing time (mm:ss) is displayed separately in the header bar.

When the model spawns subagent chats, a badge appears to the left of the timer showing the subagent count. Click it to open a dropdown listing all subagent chats with their stats (message count, cost, tokens/sec, cache ratio). Click any subagent to switch to its view, and click the back-arrow badge to return to the main chat.

## Message Controls

### Continue from Message

Hover over any non-tool message to see a play icon button. Click it to inject a continuation prompt that tells the model to go back to that point in the conversation, forgetting everything said and done after it. The continuation prompt includes a truncated preview of the original message. This is useful for re-validating: if the model went down a wrong path, you can continue from the last good message instead of starting a new chat.

### Copy Message

Hover over any message to see a copy button. Use it to copy the message content to clipboard — useful for sharing specific outputs or pasting them into other tools for further analysis.

### Stop Processing

A stop button appears in the header while the model is actively processing. Click it to immediately cancel the current request. The model receives a cancellation signal and stops generating. An error message is added to the chat noting that processing was manually stopped. Use this when you can see the model is going in the wrong direction — no need to wait for it to finish a bad response. It’s perfectly fine to stop and correct the model when you notice it making mistakes or struggling to find what it needs. In fact, if you see the model repeatedly failing at something, ask it to add the relevant information to `CLAUDE.md` or the current skill — even a single line with the right direction can save hours across future sessions, not to mention costs.

**Note**: stopping the main chat automatically stops all its subagent chats. There is no way to control individual subagent chats — they are managed entirely by background agents.

## Message Queue

When you send multiple messages quickly, they enter a message queue visible above the input area. Each queued message shows as an editable card with a green gradient (active) or orange gradient (paused). You can:

- **Edit** — Click a queued message to modify its text before it’s sent
- **Pause** — Pause a queued message to prevent it from being sent until you’re ready
- **Delete** — Remove a queued message entirely

The queue’s purpose is to let you **send ideas ahead of the current response** — you don’t need to wait for the model to finish before typing your next correction or request. Enqueue several messages in quick succession and they’ll fire automatically in sequence, letting you work in a “fire-and-forget” mode. The queue also acts as a buffer: queued messages are always processed before any [AutoFix](/code/docs/validation/autofix)
 prompts fire, preventing AutoFix from entering the chat while your manual messages are still pending.

## Effective Validation Patterns

- **Fix the root cause, not the symptom** — When the model makes a mistake or can’t find what it needs, don’t just provide your feedback. Ask the model to update `CLAUDE.md` (project-specific knowledge) or the current skill (general patterns). Even a single line of correct guidance prevents the same error across all future sessions.
- **Iterate until error-free** — Seeing repeat tool call errors means the model lacks context. It takes roughly 5–10 iterations of adding missing information to `CLAUDE.md` or skills to achieve 99% accuracy, even on complex tasks. The author of this product runs models for hours unattended — but only after investing several dozen iterations in building the right `CLAUDE.md` and skill files. It’s a good idea to restart the whole chat from scratch several times to achieve flawless execution by correcting `CLAUDE.md` and skills along the way — especially when entering new kinds of tasks where models are weak out of the box.
- **Inspect output in broad strokes** — Expand diffs and check results periodically, not obsessively. The goal is to quickly identify patterns of mistakes and fix them at the source by updating `CLAUDE.md` or skills — not to manually verify every line the model produces.
- **Watch for bloated context** — As a chat grows, each turn gets slower and more expensive because the model must process the entire history. Starting a fresh chat is often faster and cheaper than continuing an outgrown one — even rebuilding context from scratch is quick with an empty input window.
- **Monitor unusually high chat costs** — A sudden spike in per-turn cost usually means a low cache hit rate — the model is re-processing most of its input from scratch instead of using cached tokens. This is often a sign that something is wrong on the client or provider side. Working in this mode for extended periods can trigger preventive actions from the provider. Stop and investigate by digging into [analytics](/code/docs/validation/analytics-observability) and comparing costs with previous periods. Report your findings to the provider — the issue may be on their side, or they can advise what to fix on yours.
- **Prefer fresh chats over continue-from-message** — If the model went down a wrong path, start a new chat rather than continuing from an earlier message. Fresh chats start with a clean, focused context and are cheaper per turn than dragging along the baggage of an outgrown conversation. Typing “plz fix” in the same chat over and over again is wasteful: more often than not, starting fresh leads to an immediate solution, while staying in the same chat often leads to the model going in cycles.
- **Stop bad responses early** — If the header stats show the model has been processing for a long time with high token output, check what it’s doing. Stop it if it’s generating unnecessary content or going off-track. Models can get into self-reflective cycles — you may not be able to help it break out even if you point to the problem. Starting fresh is usually the most effective practical answer.

For broader performance analysis, see [Analytics & Observability](/code/docs/validation/analytics-observability)
. For monitoring how much context the model is using, see [Context Utilization](/code/docs/context-utilization)
. For the complete chat feature reference, see [Chat Features](/code/docs/chat)
.

## Learn from Painful Chats

After solving a particularly nasty bug or issue that took hundreds of messages, always ask the model to learn from the experience — update `CLAUDE.md`, create or improve a skill, and capture whatever context was missing that caused the struggle. If you do this, you ensure you won’t get stuck in the same pain again. If you skip it, you will almost certainly face the same problem soon — the model will make the same mistakes and you’ll burn through the same messages again. The few minutes spent capturing the lesson save hours across future sessions.

## Sound Feedback

Xedant Code plays a distinct sound for each event type, so you can run long tasks without watching the screen:

- **Message** — Plays for every arriving message, confirming the model is still working.
- **Complete** — Plays when the chat finishes processing.
- **Notification** — Plays when the chat is waiting for your decision or approval (e.g. an `AskUserQuestion` prompt).
- **Error** — Plays when the chat encounters a failure.

Each sound type has its own volume control in **Settings → Sounds**, and you can mute everything with the speaker icon in the header. You can replace any built-in sound by placing an MP3 file with the same name into the `.xedant/sounds/` folder in your project — for example, `message.mp3`, `complete.mp3`, `error.mp3`, etc. The server serves custom files first, falling back to the built-in defaults when no override exists. Over time, you develop an intuitive sense of the workflow from the frequency and sequence of sounds alone — a steady rhythm of message pings means everything is running smoothly, while a sudden silence, notification or error sound signals you to look at the screen. The author uses Bluetooth headphones to stay untethered from the computer while waiting for tasks — with a good Bluetooth adapter you can walk around the house without being tied to a working room. For detailed sound configuration and the full sound catalog, see [Sound Feedback Validation](/code/docs/validation/sound-feedback)
.

**[← Validation](/code/docs/validation)**

**[Git Change Validation →](/code/docs/validation/git-change)**