Track and reduce plugin performance latency across hosts

[tanglearncode]

Summary

Track and reduce the latency gap between the NeatContext pi, Claude Code, and Kimi Code plugins.

The current analysis indicates that the main difference is host integration and model-turn count—not the shared plugin core. Pi executes commands in-process, while Claude Code and Kimi often use the model as an RPC transport to invoke the CLI and relay its output.

Current observations

• The shared src/core/ logic is effectively byte-identical across the plugins.
• Pi commands execute with zero model turns and zero CLI process spawns.
• Claude Code commands generally require at least one model turn; use can require 2–3 turns.
• Kimi command flows can require three turns because commands load a Skill before invoking Bash.
• Claude Code's MCP bridge polls for list_changed every 1.5 seconds, adding up to 1.5 seconds after a context switch and causing unnecessary companion traffic.
• CLI cold-start overhead is secondary to model-turn latency, but lazy imports may still provide a low-risk improvement.

Proposed work

1. Measure baseline wall-clock latency and model-turn counts for representative commands on pi, Claude Code, and Kimi.
2. Inline the Kimi skill instructions into command files to remove an avoidable Skill-tool turn.
3. Investigate whether Kimi supports safe pre-execution equivalent to Claude Code's ! mechanism.
4. Replace or reduce Claude Code's list_changed polling with fs.watch on the selection file plus a slower backstop poll.
5. Evaluate lazy imports in neatcontext-cli.mjs.
6. Verify whether Claude Code renders pre-execution output in the transcript; if so, reduce relay-turn output.
7. Investigate per-turn/session grounding hooks, accounting for process-spawn and prompt-cache costs.
8. Do not add pre-execution to argument-taking commands until shell escaping of arguments is verified.

Non-goals

• Do not duplicate the pi neatcontext_tool proxy in Claude Code or Kimi as a default performance fix; it would trade tool schemas for cache stability.
• Do not change shared core behavior without evidence that core logic is the bottleneck.
• Do not claim improvements without before/after measurements.

Acceptance criteria

• Baseline and post-change measurements are recorded for each supported host.
• The highest-value safe optimization is implemented without reducing command correctness or security.
• Context switching does not add avoidable polling delay or unnecessary model turns.
• Argument-taking commands remain protected against shell injection.
• Tests cover the changed host integration paths.

References

• plugins/pi/neatcontext/extensions/neatcontext.js
• plugins/claude-code/neatcontext/commands/
• plugins/claude-code/neatcontext/src/claude/mcp-bridge.mjs
• plugins/kimi-code/neatcontext/commands/
• plugins/kimi-code/neatcontext/skills/
• plugins/*/neatcontext/src/core/