Wishlist · what would you build into Reasonix next?

[esengine]

0.18.1 is out. The TUI rewrite landed, the kernel event-log shipped in 0.14, sessions are per-workspace, the dashboard mockup is drafted. What is next?

This thread is the home for feature suggestions — anything from "make the spinner less annoying" to "treat the agent loop as a graph and let multiple agents collaborate."

Already on the maintainer's queue

(comment on these to upvote or shape — but new posts welcome too)

• Auto-commit per edit — Cursor-style internal checkpoints, not git commits, so undo is cheap
• Session /diff — show every file the agent touched in the current session as one unified diff
• Architect mode — strict plan-then-execute mode where the model can't dispatch tools without an approved plan
• /cost — slash command for session breakdown (per-tool, per-turn cost attribution)
• reasonix init — project scaffolding CLI (gitignore, hooks, CLAUDE.md template)
• Repo map — deferred; uncertain shape — what would you actually want from it?

Open questions where input changes the answer

• Light theme for the TUI? Currently dark-only. Theme parity costs ~1 week.
• Mobile-friendly dashboard? Currently desktop-only. Only matters if Reasonix runs as a hosted service.
• i18n — which languages would actually be used? Currently English UI / English commits / English issues.
• Hosted service? Reasonix is CLI-first. Should it ever ship a managed instance?
• Multi-agent / sub-agent collaboration — currently subagents are single-shot. Would persistent worker agents be useful, or premature complexity?
• Voice input for the composer? (Whisper or platform-native)
• Plugin system — should hooks be the only extension surface, or do we need first-class plugins?

Format I find useful for posts

• One-line title
• 2-3 sentences on the use case (who, what, why)
• (if relevant) link to a similar tool's implementation that you liked

Don't worry about overlapping — comments on existing posts > new posts. Vote with 👍 reactions on the post head and on individual comments.

Replies in English or 中文 都行.

[wo120]

Plugin 系统，最好能兼容 Claude：.claude-plugin/plugin.json
最新想在Reasonix里做多agent协作:调用codex来设计项目代码方案，deepseek进行讨论，然后编码。用到的是openai/codex-plugin-cc 这个项目，但是当前Reasonix没有Plugin系统，就让codex写了一个，本地改了一下codex-plugin-cc 让支持codex方案讨论

[esengine]

@wo120 Two separate things here:

On the plugin system — Reasonix already has three extension surfaces:

• Hooks (shell commands wired up in .reasonix/settings.json, same shape as Claude Code's hooks)
• Skills (.reasonix/skills/<name>.md — markdown playbooks with frontmatter runAs: subagent + allowed-tools; 0.30.5 added a /skill new <name> scaffold)
• MCP (standard protocol — stdio / SSE / Streamable HTTP all supported)

For .claude-plugin/plugin.json, I'd rather consume Claude's plugin manifest format directly than invent a Reasonix-specific one. Everything a Claude plugin bundle can ship (commands / agents / MCP / hooks / skills) maps 1:1 onto the three surfaces above — a reasonix plugin install <path> that translates the manifest is enough. That way packages like codex-plugin-cc work without a fork. Want to open an issue? I'll tag it enhancement and queue it for 0.32.

On multi-agent / cross-provider collaboration — different layer, unrelated to plugins. Today every Reasonix subagent runs through the same DeepSeek loop, so codex can't be a subagent. Doing that properly means abstracting a provider interface (loop, tool dispatch, cache all have to go generic) — an order of magnitude bigger than the plugin work.

Short-term workaround: if you just want codex to design and DeepSeek to code, paste codex's plan in as a user prompt; or wrap codex as an MCP server that exposes a design_plan tool (codex runs its own server, Reasonix calls it via MCP). That gets you the same shape without touching the Reasonix core.

[j4ger]

经常会需要切换工作设备，想要一种能够同步 context 的方法，不然新开一个 session 缓存又浪费了。其他的 coding agent 有些有 sync 插件，有些直接同步 context.md 就行，希望这边也能提供类似的方法！除此之外体验很棒👍

[esengine]

@j4ger Thanks for the feedback — this already works, it's just not documented.

All Reasonix sessions live in ~/.reasonix/sessions/<name>.jsonl plus matching .meta.json and .events.jsonl sidecars. Sync that directory by any means you like (Syncthing / iCloud / Dropbox / a git repo / rsync...) and you can resume on any device, because:

• The message log is byte-identical across devices → prefixHash stays the same → DeepSeek's server-side cache still hits (the cache lives on the server, not locally)
• /sessions picks the session and you're back in
• The meta fields fixed in 0.30.4 (totalCostUsd, turnCount, …) sync along with it

I'll add a "syncing sessions across devices" section to the README and /doctor so this is discoverable.

A deeper sync service / cloud account binding is not on the roadmap — Reasonix is CLI-first, and keeping every piece of state in the local filesystem is what lets users plug in any sync tool they already trust. Adding a cloud layer would break that property. Synchronising what you already have is enough.

If you want to nail down the workflow, tell me where it currently breaks (can't find the session dir? worried about conflicts? want session-level selective sync?) and I'll add docs / small tooling around the specific pain point.

[weifenghuang3364]

有考虑添加vscode 插件么？我目前是在vscode + cc extension， 可以很方便的引用文件和代码片段到对话框中， 也方便在vscode中查看代码。

[esengine]

@weifenghuang3364 Two layers here:

"Reference files / code snippets in the composer" — already works, no VSCode extension required

Type @ in the composer and a fuzzy file picker pops up (src/cli/ui/AtMentionSuggestions.tsx). Pick a file and the path stays in your input as @path; on submit, at-mentions.ts expands it inline as file content for the model. 64 KB cap per file by default — anything larger leaves a skip note instead of blowing out context.

• Directories work too (expand into a listing)
• Honors .gitignore plus a default node_modules / dist / .git blacklist
• Multiple @paths on one line are fine

What's missing today is referencing specific lines (e.g. @path:start-end). That's a small piece of work — open an issue and I'll add it.

"Viewing code in VSCode" — just use VSCode's integrated terminal

Run Reasonix inside VSCode's integrated terminal: when the agent edits files, VSCode picks up diffs, gutter marks, and the problems panel immediately. That's the recommended workflow today, no extension needed.

A VSCode extension itself — not on the short-term queue

A genuinely useful extension would need editor-selection → composer, diff preview, and tool-result line jumping. That's a separate product's worth of work, and once you do it for VSCode you owe the same for JetBrains / Cursor / Zed. For a CLI-first project, the ROI doesn't justify it. Reasonix's extension surfaces are hooks / skills / MCP; editor integration is covered by the integrated terminal.

If you want to push back: which one of those CC-extension actions are you actually leaning on most — selection-to-prompt, line-number jumping, or inline diff? Knowing the specific friction point, a small reasonix send-selection CLI plus a VSCode keybinding might cover it without a full extension.

[dacec354]

我的感觉是，现在的reasonix，plan模式存在感是不是有点低？或许可以做一个更智能的模式，让agent做事前能更主动的制定计划然后实行。现在的模式更像是一个直接的执行者？

[esengine]

@dacec354 The signal is fair and I agree the discoverability is weak today. A bit of context on the design, then what I'm doing about it.

Why plan mode is opt-in rather than always-on

Reasonix's positioning is cheapness — the whole project is built around DeepSeek's prefix cache so an agent loop costs ~1/10th what equivalent Claude / GPT-4 usage costs. Forcing a plan-then-execute round on every task burns tokens on small jobs ("rename this variable", "add a console.log") where the model already knows what to do. So the default is: model executes directly, but for genuinely large tasks it can call submit_plan autonomously, and the user can flip /plan on to make planning mandatory regardless. That's the lever — not a smarter auto-detector, just a clearer one.

Where the current design under-delivers

When plan mode is engaged, the UI swallows what the model produces:

• The plan body is capped at 24 preview lines and hidden entirely once the model returns structured steps.
• The "open questions / risks" banner fires but never shows the actual questions — picking refine opens a blank prompt with no context, so the user has to re-ask the model what it wanted to know.

That's #477. Fixing it is a small lever on the broader "plan mode feels passive" perception you're pointing at — when the model raises a real planning question, the user actually sees it and answers in place, instead of plan mode looking like a checkpoint with nothing to add.

On a more proactive planner

What I won't do: any auto-plan trigger that adds an LLM round to every task — that breaks the cheapness positioning. What I'm open to: heuristics already on the input side (multi-file edits, presence of words like "refactor" / "redesign" / "migrate", over-N-step ambiguity) that nudge the model toward plan-first without a separate planner call. If that's the shape you were thinking, open an issue with a concrete trigger list and I'll scope it.

Tracking the immediate UX fix in #477.

[xlingyun8-maker]

我发现 @文件功能都没有彻底做好，根本没法用。 现在@后没有任何文件可以选择。这是最紧迫的。我这边如果有5000个文件，@功能彻底没用了，opencode，或者其他的都可以用。就你的不行。

[esengine]

@xlingyun8-maker You're right — I reproduced it on a similar-sized tree and the picker is unusable as designed. Diagnosis matches the symptom you're seeing:

• The picker walks the repo once on mount with a hard 500-file cap, so on a 5,000-file repo ~90% of paths are evicted before ranking ever sees them, and what survives is whatever order the walker happened to visit (usually deep src/ paths, not the file you actually want).
• The walk is blocking-then-atomic — the popup is empty for the entire scan window with no progress indicator, and if the walk errors it stays empty silently. So "@ shows nothing" is the visible failure mode for two completely different states (scanning / nothing-matched), which makes it look broken even when it isn't.
• Folders aren't selectable at all. Submit-time directory expansion already works internally, the picker just never offers a folder as a candidate.

This needs a redesign, not a tuning pass. Tracking it as #478. The shape: VSCode-style two-mode picker — show the immediate directory listing (folders + files) when there's no query so it never recurses upfront, and switch to a cancelable streaming walk with a searching… N scanned footer the moment you start typing, results filling in as the walker finds them. Drop the 500-file cap entirely — the streaming + cancellation is what bounds work.

Bumping #478 to the front of the queue. Thanks for the push.

[yhf-cmyk]

根据任务自动切换模型，大脑是 V4-Pro，写代码和其它工具调用用 V4-Flash，最好本地跑的Flash也能用上。

[esengine]

@yhf-cmyk That's what the auto preset already does — every turn starts on v4-flash and escalates to v4-pro automatically when the per-turn repair-signal counter hits the threshold (default 3, tunable via --escalate-after). "Brain = pro, hands = flash" is exactly the behaviour, just gated by signals from the loop rather than a separate router round (an upfront routing call would burn the cheapness positioning).

Local Flash isn't on the roadmap — DeepSeek doesn't ship local weights, and abstracting the client + cache layer for a non-API provider is the same shape problem as the cross-provider asks higher in this thread. If you want a local model in the loop today, wrap it behind an MCP server with a chat tool — you lose the prefix cache but you can compose it with Reasonix.

[yhf-cmyk]

行。阈值约束效果不好，未来会优化嘛

[jokerjames]

目前所有cli，如claude code，codex，opencode等等这些cli，都有一个问题就是核心开发功能定义黑盒化和独立化。
逻辑如下：用这些cli工具的人绝对都是用来搞类似程序开发的。如果不是，哪这种命令行工具的形式他们天然就不会使用。我相信普通非程序人员很难接受这种工作形式。所以现阶段最大的问题是，开发完全黑盒化，大模型后台跑了哪些代码，新建了几个文件，你完全不清楚。所有的skill功能都是独立的，各干各的，兼容配合并不好。举例claude-mem，类似这种记忆工具，天然就不是针对项目的，是针对会话的。但是你这个工具本身是用来开发项目的，所以所有一切的前提都应该是围绕项目程序开发来的，并且可视化。
我自己在claude code里面使用了claude-mem，claude-ex和entroly，它们3个来维护项目，但是项目还是太复杂，庞大，并且这个项目天然就是一个需要不断测试修改的工程。导致claude 200k上下文完全不够用。这只是问题一，问题二是版本跌倒到了v11，项目目录一堆乱七八糟的test文件，各种命名不规范等等，md文件几千行，没有项目文件的历史记录，每次归档非常浪费tokens。这绝对是现在cli开发的根本问题。这也是最近anthropics为什么最近说他们和ai都不喜欢维护md文件的原因。
我目前是调用了一个本地小模型进行项目开发日历的摘要历史归档操作，让大模型维护一个项目结构进度可视化dashboard页面。这个页面后台的json文件是一个规范化的文件，大模型其实在plan的最后阶段就应该定义好这个json文件，subagent应该是按照这个文件进行开发，大模型监控执行，并实时维护这个dashboard页面。只有这样，才能将黑盒开发全部可视化。
claude-mem，claude-ex和entroly这些MCP工具应该天然组合在一起，然后在大模型的调用下配合json文件，指挥subagent进行开发，本地小模型进行实时的开发历史摘要归档等操作。
我觉得这才是如今cli开发应该具备的基础且必要的功能。

[victorygod]

赞同。其实我觉得SDD的根本矛盾就是：文档没人读，人和AI都不乐意看文档。让AI读文档还不如直接让AI读代码。
文档目前看来只有两个用处：1. plan的时候方便和人类交互，以及对抗程序崩溃；2. cc执行完毕以后让它自己review下文档是否完整实现当初的需求（相当于短中期记忆重新加载）
所以其实我觉得你提的这一点，在更高一个层面上就是coding场景的内置记忆处理。

[esengine]

@jokerjames Fair critique on the black-box concern. The dashboard (http://localhost:<port>, auto-launches with every session unless --no-dashboard) covers part of it — live tool calls, cost, MCP state, sessions — but not the project-progress board you're sketching. The pieces are there: submit_plan emits structured steps + checkpoints, and subagents already dispatch against them. What's missing is a dashboard tab that renders the plan as a live progress board instead of inline TUI cards. Open a separate issue with the layout you want and I'll queue it for the next dashboard pass.

@victorygod on doc-rot: that's exactly why memory is scoped (project / user / global) with priorities and expires: project_end instead of one flat MD — small structured records the loop pulls only when relevant. The "AI won't re-read its own docs" problem is what the memory tool is built to dodge, not feed into.

[victorygod]

大段文本删除方面能否做一些优化？我发现claude code和deep seek在删除大段文本的时候（比如删除某个长函数），由于search的内容很长，llm犯错概率会很大。
但是我觉得在文件内加>>>>> to delete
和<<<<<< end of delete这种可靠性就会大大提升。

[Wu-H-Y]

目前缺少:

1. skill 兼容多种不同agent的格式(主流claude code | codex)
2. .reasonix/agents 定义
3. hooks覆盖度
4. /.reasonix 的支持度不够(目前全局定义的mcp会加载但是项目的不会, 不知道是不是我的问题还是bug)
5. 内置强大的减少token使用的工具, 例如直接内置rtk, context-mode等等
6. lsp 是否需要呢

[0bl1]

我觉得给一些初始化模板config对入门的萌新会很有帮助，比如python项目模板配套对应的memory.md，常用的mcp和skills；写AI小说又有新的config。给一些常用的应用场景，让用户快速上手是非常有必要的。

[0bl1]

后续的社区构建其中一块也可以围绕鼓励用户分享好用的config展开

[Wu-H-Y]

能否支持 anthropic的api接口格式, 我认为这个更好一些

[gaohuanxu]

我希望微信截图能直接贴到对话中

[weyenrooney]

我是专业做编程开发的，我最希望的是强制使用code知识库和ast +lsp代码编辑规范，能够处理超大型代码库，拒绝使用文本阅读read grep sed 等指令，拒绝文本编辑模式，这样能然ai编程减少巨量的错误和无效的迭代循环。为了实现这个目标我自己也在研究实现自己的定制化编程工具