Ricochet coding - Open-source AI coding agent for IDE, CLI & messengers

by
Ricochet is an open-source, local-first AI coding agent for VS Code-compatible editors, CLI/TUI, and Ether Live Mode. Ether lets you start and control coding sessions from Discord, Telegram, and other messengers. Unlike editor-only assistants, Ricochet keeps a reviewable task timeline with approvals, checkpoints, pending diffs, MCP/skills, and routing across BYOK or Grik-hosted models. Swarm workers handle recurring checks and remote follow-ups while you keep repo control.

Add a comment

Replies

Best
Maker
📌
Hey Product Hunt 👋 I’m Igor, the solo builder behind Ricochet. I created Ricochet because AI coding agents should not be locked to one editor, one cloud, or one chat window. Ricochet is an open-source, local-first AI coding agent for VS Code-compatible editors and the terminal. It keeps work reviewable with task timelines, approvals, checkpoints, pending diffs, MCP tools, skills, and flexible model routing. The core workflow can run for free with BYOK, local models, or free routes. If you don’t want to manage provider keys, Ricochet can also use Grik-hosted models through controlled credits. The feature I’m most excited about is Ether Live Mode. It lets you start or continue a coding-agent session from Discord, Telegram, or other messengers when you are away from your laptop. Ricochet also includes Swarm workers for recurring checks, remote follow-ups, and multi-agent workflows — while you keep control of your repo. This is still a new open-source project, so feedback would mean a lot. If something feels unclear, broken, unsafe, or not useful enough yet, please tell me. I’m actively improving the product with community feedback.

Adding a visual diff overlay directly in the Ether chat thread would be huge, so I could review pending changes without bouncing back to the editor mid-conversation.

 Hello! Thank you! Agree.

Ricochet now supports pending change review directly in the Ether chat flow. Instead of forcing users back into the editor for every review, the chat can show a visual diff review surface with files, additions/deletions, hunks, conflict states, large/truncated states, binary/no-preview states, and editor-required fallbacks.

From that overlay, users can accept or reject a whole file, accept or reject individual hunks, open the change in the editor when needed, or accept/reject all pending changes. The editor review flow still exists, but it is no longer the only path. The goal is to keep the approval and review loop inside the conversation when that is where the user already is.

How does the approval and checkpoint timeline actually hold up when you have multiple swarm workers running checks in parallel — do you review each diff separately or bundle them somehow?