Labsco
stippi logo

Code Assistant

★ 173

from stippi

A Rust-based CLI tool for code-related tasks, operating as an MCP server.

🔥🔥🔥🔥✓ VerifiedFreeAdvanced setup
#automation#browser#database#git#search#maps#finance#security

Code Assistant

Trust Score

An AI coding assistant built in Rust that provides both command-line and graphical interfaces for autonomous code analysis and modification.

Key Features

Multi-Modal Tool Execution: Adapts to different LLM capabilities with pluggable tool invocation modes - native function calling, XML-style tags, and triple-caret blocks - ensuring compatibility across various AI providers.

Real-Time Streaming Interface: Advanced streaming processors parse and display tool invocations as they stream from the LLM, with smart filtering to prevent unsafe tool combinations.

Session-Based Project Management: Each chat session is tied to a specific project and maintains persistent state, working memory, and draft messages with attachment support.

Multiple Interface Options: Choose between a modern GUI built on Zed's GPUI framework, traditional terminal interface, or headless MCP server mode for integration with MCP clients such as Claude Desktop.

Agent Client Protocol (ACP) Support: Full compatibility with the Agent Client Protocol standard, enabling seamless integration with ACP-compatible editors like Zed. See Zed's documentation on adding custom agents for setup instructions.

Session Compaction: Before running out of context space, the agent generates a session summary and continues work.

Auto-Loaded Repository Guidance: Automatically includes AGENTS.md (or CLAUDE.md fallback) from the project root in the assistant's system context to align behavior with repo-specific instructions.

Architecture Highlights

The code-assistant features several innovative architectural decisions:

Adaptive Tool Syntax: Automatically generates different system prompts and streaming processors based on the target LLM's capabilities, allowing the same core logic to work across providers with varying function calling support.

Smart Tool Filtering: Real-time analysis of tool invocation patterns prevents logical errors like attempting to edit files before reading them, with the ability to truncate responses mid-stream when unsafe combinations are detected.

Multi-Threaded Streaming: Sophisticated async architecture that handles real-time parsing of tool invocations while maintaining responsive UI updates and proper state management across multiple chat sessions.

Roadmap

This section is not really a roadmap, as the items are in no particular order. Below are some topics that are likely the next focus.

  • Block Replacing in Changed Files: When streaming a tool use block, we already know the LLM attempts to use replace_in_file and we know in which file quite early. If we also know this file has changed since the LLM last read it, we can block the attempt with an appropriate error message.
  • Compact Tool Use Failures: When the LLM produces an invalid tool call, or a mismatching search block, we should be able to strip the failed attempt from the message history, saving tokens.
  • Improve UI: There are various ways in which the UI can be improved.
  • Add Memory Tools: Add tools that facilitate building up a knowledge base useful work working in a given project.
  • Security: Ideally, the execution for all tools would run in some sort of sandbox that restricts access to the files in the project tracked by git. Currently, the tools reject absolute paths, but do not check whether the relative paths point outside the project or try to access git-ignored files. The execute_command tool runs a shell with the provided command line, which at the moment is completely unchecked.
  • Fuzzy matching search blocks: Investigate the benefit of fuzzy matching search blocks. Currently, files are normalized (always \n line endings, no trailing white space). This increases the success rate of matching search blocks quite a bit, but certain ways of fuzzy matching might increase the success even more. Failed matches introduce quite a bit of inefficiency, since they almost always trigger the LLM to re-read a file. Even when the error output of the replace_in_file tool includes the complete file and tells the LLM not to re-read the file.