Lucid: Unfolding and Editing the Model’s Reasoning Process

A developer built a web tool called Lucid that lets you view and directly edit a model’s chain of thought before it produces the final answer. Reasoning debugging is shifting from “reading logs” to “modifying intermediate states.”
Someone Turned a Model’s “Scratch Paper” Into an Editable Interface
Yesterday, Hacker News featured something called Lucid on its front page. It was built by an indie developer, and the one-line pitch is brutally simple: a web tool that lets you see and edit what an AI is thinking before it answers.
That sounds like a gimmick at first, but once you click in, you realize it hits a shared pain point for nearly everyone who has spent the past year building Agents, RAG systems, or complex prompts: reasoning models’ Chain-of-Thought is getting longer and more important, but the tools for debugging it have barely evolved at all.
Most people are still debugging CoT the same way they did in 2023: tweak the prompt, run it once, copy the contents of the <thinking> tag and read through it, decide something looks wrong, go back and change the prompt, then run it again. Each iteration takes anywhere from tens of seconds to several minutes, and even then you’re still gambling on whether the model will “think correctly” this time. What Lucid wants to do is replace the indirect loop of “look at output → guess the cause → modify input” with “directly edit the intermediate state and immediately see the consequences.”

How It Actually Works
From the demo, Lucid’s core interaction looks like this:
- You give the model a prompt, it runs through a reasoning pass, and splits the chain of thought into individual steps displayed as cards in the UI
- Every step is directly editable — you can reword it, delete it, insert new steps, or rearrange the order
- After editing, the model “continues running” from the modified step onward, treating the earlier steps as fixed context while regenerating everything after
- The final answer updates in real time as you edit
Put simply, this interaction model treats the model’s reasoning process as an interactive draft, rather than a one-time printed log. Anyone who has used Jupyter Notebook will instantly understand the feeling. Notebooks are more usable than scripts because you can stop at some intermediate cell, tweak something, and continue execution from there. Lucid applies that same idea to LLM reasoning.
The underlying technology is not mysterious. Any model that supports streaming output and continuation from intermediate text (which is basically all mainstream models) can do this:
- Capture the complete reasoning trace
- Split it into structured segments in the UI
- After user edits, treat the “modified prefix” as fixed assistant output and request a continuation
The hard part isn’t the technology. The hard part is that nobody seriously turned it into a product before.
Why Is This Only Appearing Now?
There’s an important bit of context here: before 2024, Chain-of-Thought was mostly just a “prompting trick.” You told the model “Let’s think step by step,” and it generated a bit more reasoning text. Those intermediate thoughts didn’t really have any special status; editing them didn’t matter much.
The real turning point came after the o1 series launched. Reasoning models began separating “thinking” and “answering” into two independent stages, with thinking tokens billed separately, rate-limited separately, and optimized separately. By 2025, Claude, Gemini, DeepSeek, and Qwen all had their own reasoning modes. Chain-of-Thought evolved from a supporting mechanism into a core asset — it determines answer quality and consumes the majority of tokens.
At that point, if you look back at the developer tooling ecosystem, there’s an awkward mismatch:
- On the model side: reasoning chains are getting longer and longer. o1, DeepSeek-R1, and Claude’s extended thinking can easily produce thousands or even tens of thousands of reasoning tokens
- On the debugging side: people are still dumping thoughts into the terminal with
print
It’s like frontend development in the 2010s becoming complex enough to require React, while you’re still debugging with alert(). Lucid emerging at this moment is fundamentally a natural response to tooling trying to catch up with model capabilities.
What Problem Does It Actually Solve?
A few concrete examples make this obvious:
Scenario 1: An Agent Goes Off Track at Some Step
Suppose you’re building a tool-using agent. The model reasons through seven or eight steps, gets the first six right, and suddenly picks the wrong tool on step seven. Traditionally, you go back and modify the system prompt, add a few lines like “under XX circumstances, use YY tool,” and hope for the best. With Lucid, you directly edit step seven to the correct choice and see whether the later reasoning recovers smoothly. This immediately tells you whether the problem is that the model doesn’t know what to do, or that it knows but failed to do it. Those are completely different classes of problems with completely different fixes.
Scenario 2: A Prompt Constraint Isn’t Being Followed
You specify “answer in under 100 words,” and the model writes 300. Did it fail to notice the instruction? Or did it notice and decide to ignore it? Open the reasoning chain. If the model never mentions the length constraint at all, then the constraint likely didn’t carry enough attention weight. If it explicitly says, “the user wants 100 words, but I think this requires more explanation,” that’s a different issue entirely. Only by seeing the reasoning chain do you know what actually needs to be changed.
Scenario 3: Debugging a RAG System
The model picked the wrong document from five retrieved results. Why? In Lucid, you can edit the reasoning to say “if I consider document 3 more relevant...” and observe how the rest of the reasoning unfolds. That’s much faster than repeatedly tweaking embedding parameters.
But There Are Some Problems You Can’t Ignore
A reality check first. If tools like Lucid want to become mainstream developer tooling, they still have several hurdles to clear:
First, model providers may not cooperate. OpenAI’s o-series still does not expose complete reasoning traces, only summaries. Anthropic is more open, but parts of extended thinking are still encrypted. That means Lucid’s capabilities are naturally limited on top-tier closed-source models — it’s better suited for open-source reasoning models like DeepSeek-R1, QwQ, or GLM-Z1.
Second, “editing a reasoning chain” is not the same thing as “the reasoning chain produced during training.” A reasoning model’s thinking path is learned during training. If you manually alter one step, the continuation can become awkward or stylistically inconsistent. This issue is especially noticeable in smaller models. Lucid’s current approach is to encourage minimal edits that resemble the model’s own writing style, but that itself is a compromise.
Third, the interaction complexity will scare some people away. Most application developers don’t actually want to inspect reasoning chains; they just want API outputs that work. Lucid is more of a tool for heavy prompt engineers and agent-system developers. That’s not a huge audience, but it’s a deeply technical one.
A Bigger Signal
Stepping back from the product itself, Lucid represents a broader direction: LLM application development is moving from “black-box input/output” toward “intervenable processes.”
For the past two years, the dominant development paradigm has been: write prompts, tune parameters, and rewrite prompts if the output is wrong. The model is a black box, and developers stand outside turning knobs.
But reasoning models partially opened the box — Chain-of-Thought is internal state that the model voluntarily exposes. Once that state is exposed, there’s no reason to only “look at it” instead of also “editing it.” Lucid is simply the first wave of productizing this idea. What we’ll probably see next includes:
- IDE-style reasoning-chain editors integrated into VS Code or Cursor
- “Reasoning-chain version control” for team collaboration, managing prompts and reasoning paths like Git
- Automated tools that infer how prompts should change based on batches of failure cases
- Training-side applications where manually corrected reasoning chains become SFT or DPO data
That last point is the most interesting. If human-corrected reasoning chains can feed back into training, then tools like Lucid are not just debuggers — they become data engines. That may ultimately be more valuable than they currently appear.
By the Way
If you want to compare different reasoning models inside Lucid or similar tools, OpenAI Hub currently lets you access Claude’s extended thinking, DeepSeek-R1, and Gemini 2.5 thinking mode with a single API key. It supports direct connections from mainland China and is compatible with the OpenAI API format — switching models only requires changing the model field. Cross-model comparison is extremely important when debugging reasoning chains; otherwise, it’s hard to tell whether a problem comes from the model itself or from the prompt.
References
- Related Hacker News discussion — Original Show HN post for Lucid and community discussion
- Hugging Face reasoning model resources — Access to open-source reasoning models like DeepSeek-R1 and QwQ for local deployment and reasoning-chain debugging experiments
- Reddit r/LocalLLaMA — An active discussion community around reasoning-model Chain-of-Thought applications and prompt-debugging practices



