Chain-of-thought trace formatter
Chain-of-thought output is invaluable for debugging a model’s reasoning, but raw CoT is a wall of prose with inconsistent step markers — sometimes numbered, sometimes “First… then… finally”, sometimes just paragraphs. This tool detects whatever structure is there, normalises it into a clean numbered trace with step IDs, and separates the final answer so you can scan the logic at a glance.
How it works
The formatter scans the text for step boundaries using a priority of marker
styles: explicit numbering (1., Step 2:), letters (a), B.), bullets
(-, *, •), and prose transitions (First, Next, Then, Finally). It
splits the text at those boundaries into discrete steps and renumbers them
sequentially with S1, S2, S3 IDs. It then searches the tail for a
conclusion marker — Final answer, Answer:, Therefore, In conclusion — and
lifts that segment into a dedicated final-answer panel. When no markers exist at
all, it falls back to splitting on blank lines so even unstructured reasoning
becomes a readable list. Nothing is paraphrased; every character of input is
preserved in its new home.
Why chain-of-thought traces are hard to read raw
When you prompt a model with chain-of-thought instructions, the output is verbose by design. A single reasoning trace for a multi-step problem might span 600–2,000 tokens of dense prose where the model works through considerations, revises earlier assumptions, and arrives at a conclusion. Reading that linearly is slow, and spotting where the reasoning went wrong requires holding the whole trace in working memory.
The specific problems a formatter solves:
- Inconsistent markers. The same model may number steps with “1.”, “Step 1:”, “First,”, or ”-” across different responses, making programmatic parsing unreliable without normalization.
- Mixed reasoning and conclusion. The final answer often gets buried at the end of a long paragraph rather than standing apart. Separating it makes it immediately findable.
- Inconsistent granularity. Some steps in the same trace are a sentence; others are a paragraph. Normalising to a step-per-boundary structure makes comparison across traces easier.
- Copy-paste awkwardness. Raw CoT has no clean copy target — the formatter gives you a single “copy trace” action.
Using formatted traces for evaluation
Formatted CoT traces are particularly useful in LLM evaluation workflows:
Reviewing model reasoning on hard cases. When a model gives a wrong answer, the trace shows where the reasoning diverged. With numbered steps and an isolated conclusion, you can identify specifically at step S3 where a wrong assumption entered, rather than re-reading the whole output.
Comparing traces across models or prompts. Normalized step numbering makes it easier to align traces from two different model configurations and see where they diverged.
Spotting sycophancy and revision patterns. Some CoT traces include self-correction steps where the model revises an earlier answer. These are easy to miss in raw prose but visible when the trace is step-numbered and you can see “S4: revising my earlier conclusion from S2”.
Prompt debugging. If a model is skipping a reasoning step you expected, a clean trace makes the gap obvious in a way that raw output does not.
Tips and notes
- Great for eval review. A clean numbered trace makes it obvious where a model’s reasoning diverged, which is hard to spot in raw prose.
- Prose-style works too. “First I considered… then I checked…” is detected even without numbers.
- The final answer is highlighted. Use it to confirm the conclusion actually follows from the listed steps.
- Everything is local. No network calls; copy the formatted trace with one button.