Show HN: CodeRLM – Tree-sitter-backed code indexing for LLM agents

AI code map drops, devs debate: LSP déjà vu and Claude lock-in vibes

TLDR: CodeRLM offers a new code map for AI helpers, but the crowd questions if it just replays what existing editor tools (LSP) already do. Debate centers on Claude-only setup, automation, and language support, with fans pushing Opencode and skeptics asking for proof it actually improves agent performance.

CodeRLM just hit Show HN promising a tree-sitter–powered map of your code so AI helpers can actually find stuff. Think: sessions, file trees, and symbol lists to help bots navigate your project. Sounds neat—until the comments lit up. The loudest chorus? “Isn’t this already solved by LSP?” LSP (Language Server Protocol) is what editors use to understand your code, and esafak bluntly asked what CodeRLM adds beyond that. Meanwhile, aghilmort wanted receipts: does tree-sitter indexing really change agent planning, or is it fancy grepping?

Then came the platform drama. skybrian asked if it’s useful outside Claude, suggesting it should be installable like a normal tool, not a plugin locked to one AI. esafak piled on with automation gripes: if Claude doesn’t trigger it automatically, do users manually summon the “skill”? And where’s support for JVM (Java world) languages?

But it wasn’t all side-eye. ozozozd loved the idea and dropped a spicy brand swap: configure it for Opencode, comparing the switch from Claude Code to Opencode to going from Windows to Mac—you can practically hear the OS fanboys warming up. The vibe: promising tech, but prove it’s not LSP 2.0 and don’t lock it to one AI. Also, make it just work, everywhere, preferably yesterday.

Key Points

  • The API maps CodeRLM REPL operations to /api/v1 HTTP endpoints; most requests require an X-Session-Id tied to a specific project.
  • Session management includes listing, creating (with cwd indexing), checking, and ending sessions; evicted projects return 410 Gone and require re-indexing.
  • Structure endpoints provide a tree view of the codebase with depth control, file annotations (define/redefine), and file marking (documentation, ignore, test, config, generated, custom).
  • Symbols endpoints support listing and filtering by kind and file, substring search, and annotation of symbols with descriptions shared across project sessions.
  • Responses include structured metadata such as file_count, language_breakdown (e.g., rust, toml), symbol line ranges, signatures, and parent relationships.

Hottest takes

“I see a lot of overlap with LSPs… What does this add?” — esafak
“Would this be useful to people who aren’t using Claude?” — skybrian
“Going from Claude Code to Opencode was like going from Windows to Mac” — ozozozd
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.