Concept
Replace read_file, edit_file, and write_file with a single nvim tool. The model sends vim keystrokes, nvim executes them in a tmux pane, capture-pane returns what the screen shows. One tool, three capabilities.
Token savings: :%s/old/new/g = 15 tokens. Equivalent edit_file with oldText/newText context = 180+ tokens. 12x reduction on renames, 50x on method deletions.
tmux IS the truncation — capture-pane returns exactly one screen. No truncation logic needed. The model scrolls to what it needs with vim motions.
Prior art: Nobody has tried this. All existing approaches (Aider, Claude Code, pi-mono) use text-generation paradigms (search/replace, udiff, whole-file). This is the opposite: generate commands, not text.
Same architecture as ShellSession (#468): tmux pane + send-keys + capture-pane. Different program.
Full exploration: thoughts/shared/notes/2026-05-02/nvim-tool-vim-motions-as-edit-interface.md
Concept
Replace
read_file,edit_file, andwrite_filewith a singlenvimtool. The model sends vim keystrokes, nvim executes them in a tmux pane,capture-panereturns what the screen shows. One tool, three capabilities.Token savings:
:%s/old/new/g= 15 tokens. Equivalentedit_filewith oldText/newText context = 180+ tokens. 12x reduction on renames, 50x on method deletions.tmux IS the truncation — capture-pane returns exactly one screen. No truncation logic needed. The model scrolls to what it needs with vim motions.
Prior art: Nobody has tried this. All existing approaches (Aider, Claude Code, pi-mono) use text-generation paradigms (search/replace, udiff, whole-file). This is the opposite: generate commands, not text.
Same architecture as ShellSession (#468): tmux pane + send-keys + capture-pane. Different program.
Full exploration:
thoughts/shared/notes/2026-05-02/nvim-tool-vim-motions-as-edit-interface.md