Project Info

Winner

Crater: Play-Do Prize

Curserve

Inspiration

We recently read about Cognition’s latest models, SWE-grep and SWE-grep-mini (https://cognition.ai/blog/swe-grep) and were really excited by the sheer throughput the team was able to achieve on these new fine-tuned LLMs (over 2000 tps!). It made us naturally envision a future where we’ve optimized inference to be so fast that agentic coding isn’t bottlenecked by LLM throughput, but rather, by the system and network latency overhead the is inherited with the current system architecture. We determined that the modern agentic coding paradigm, where user’s codebases exist locally on as a client and the LLM inference is served remotely on a server, concedes vast amounts of performance due to high network latency overhead incurred from the frequent back-and-forth communication they perform, In an ideal world, all users could own their own H100s and host their own coding models locally. However, this is impractical, and uneconomical. What we need to do is create a fast and scalable framework for models to still be served on servers, but also allow users to experience most of the performance benefits of having their own datacenter class GPUs locally. We identify two key insights that inform the design of our system: 1) To eliminate network latency overhead, we must co-locate both the codebases and our compute 2) Having only a single user on a remote server is a poor utilization of compute resources. An ideal system should, similar to vLLM, be able to effortlessly scale multiplexing compute resources (memory, GPUs, etc.) to new users. 3) As the number of coding agents per machine increases, the number of tool calls made will also further increase. Rather than spinning up new processes with each call a more scalable solution is to create a persistent background service that receives requests from client processes to do grep, ls, etc. and handle the functionality of the common commands without actually needing new processes For those familiar with operating systems concepts, making tool calls (aka creating a new grep, ls, find process) is akin to making a syscall. It forces the currently running process to preempt itself, causing a context switch to a new process flushing the TLB and losing a lot of Addressing #1: IPC.We perform interprocess communication (IPC) between our (potentially many) qwen-code-ipc clients, and our mem_search_service, in order to eliminate process creation overhead associated with each shell command an agent may make. We created a custom daemon (background process) to run on a server. Our service uses a custom library we created, where we developed pseudo-shell commands that operate directly on memory mapped files. For the purposes of the hackathon, we implemented ripgrep one of the more time consuming, and frequently used shell commands.

What it does

Curserve essentially is a high-performance serving engine that enables hundreds of users to run coding agents simultaneously with near-zero latency for file operations. Instead of the traditional architecture where code lives on laptops and LLMs run remotely (causing constant network round trips for every grep/ls/cat command), Curserve co-locates everything: codebases, LLM inference, and search operations all live on the same server. Users SSH in and run a single command to start an AI coding session. Behind the scenes, a memory-mapped search service keeps all active codebases in RAM, allowing instant file operations without spawning shell processes. The system transparently intercepts the coding agent's filesystem calls and routes them through IPC to this blazing-fast in-memory service.

How we built it

mem-search-service (Rust daemon) Uses ripgrep's core libraries (grep-searcher, grep-regex) for proven search performance memmap2 for zero-copy memory-mapped file access Rayon for parallel search across CPU cores notify crate for real-time file change detection and auto-reload Simple API: alloc_pid(), ripgrep(), close() IPC Layer Unix domain sockets for sub-millisecond communication (~0.1ms vs network latency) JSON protocol for simplicity and debuggability Shared request socket + per-client response sockets Modified Qwen-Code-CLI Forked Qwen-Code-CLI and modified its tool layer to route calls to our daemon instead of spawning subprocesses Integration is easy for any Python-based agent. Could be done with minimum effort for other tools like Gemini CLI vLLM + Infrastructure Deployed Qwen2.5-Coder-32B-Instruct via vLLM for LLM serving Rented an A100 GPU from vast.ai (~$0.63/hr) Co-located vLLM, mem-search-service, and user codebases on the same server, eliminating network latency entirely Users SSH in and run their own Qwen-Code-CLI instances, all sharing the same daemon Multi-tenant: one daemon serves many concurrent users

Challenges we ran into

We had countless challenges trying to wrangle designing and implementing this system, but here are some notable ones: We had to fit the best open source coding agent we could into an affordable GPU. After settling on renting an A100, we found we would be able to fit a Qwen 30B coding model in the GPU’s 80gb of VRAM. However, we forgot to anticipate the model’s limits on the context window and had to settle on testing on medium size codebases with our model’s 64k tokens of context (though it was flaky, with the system crashing several times). Future iterations could serve better GPUs and models. We had to reverse engineer Qwen Code (which itself was based on gemini-cli) in order to replace grep tool calls with calls to our specialized searching process, and replace calls to the Chinese API to our hosted server. We faced numerous problems with syncing and hangs, but were able to work through them with the help of Cursor. Memory-mapped file invalidation: originally, we expected code modifications to be reflected in the file we memory-mapped because we had a pointer to the shared memory. However for VSCode and other editors, they don’t update files in place but actually overwrite the file, leaving a new copy, making our old file descriptor and memory-mapped file to now be invalid and stale. We implemented a service that watched for file system changes and remapped a file whenever a file was written to. We initially prototyped in Python with mmap + regex for the in-memory search operations, but for sparse queries on large repositories, our implementation underperformed compared to ripgrep. We wanted to match ripgrep's speed, so we rewrote it in Rust using ripgrep's internals to use ripgrep with in-memory files instead of using the filesystem API, which has unneeded overhead. The wifi at the event was terrible, so we went around SF to various public libraries and cafes. Wifi was a huge challenge at this event

Accomplishments we're proud of

Our in-memory ripgrep implementation is up to 5-30x faster than the normal ripgrep implementation (requiring a process to spin up). The speedup varies widely based on the repository size and the specific query being made, but across all experiments it is more performant than the original approach. This is exacerbated even more when considering rollout generations with many tool calls because the memory mapping of the repository is only done once while every search operation after has quick access. We’re proud of making a system that works reliably even when the user has spotty network access (like this hackathon). By having the code and LLM in the cloud, once the user prompts the agent, the agent does not have any dependencies on the user’s computer. Unlike cursor which needs to run commands locally, our system reduces points of failure and security risks of running code on user’s devices. We designed a flexible full architecture that allows us to minimally modify any open source coding agent framework (like Qwen-Code CLI or Gemini CLI) to work with our server-side framework.

What we learned

We learned a lot from this project. Here are a few mentions: We also learned how to serve open source coding agents like qwen with modern tools like vLLM (popular LLM serving framework) and Vast.ai (GPU cloud aggregator for spot instances). We learned how to get the model to be deterministic for profiling, changing temperature to 0 and removing top-K sampling. We learned how to queue tool use tasks from hundreds of users on the server to a single specialized code-searching process. We learned how to use sockets for asynchronous interprocess communication.

What's next

Our next steps is to do system optimization. We want to speed up file reading by doing copyless reads. Client requests service to mmap file (pinned in physical memory) to the client’s virtual address space, rather than the client needing to copy the file contents. We want to Implement codebase paging and eviction policies when RAM limits are reached + Add speculative codebase prefetching (once RAM is full) based on and also optimize memory layout for common search patterns. In the future we also want to Support for distributed codebases across multiple servers as well as copy-on-write if a server is dedicated to many users working on the same repo (e.g. PyTorch team on Meta can use this to do fast coding on PyTorch with copies existing where git diffs diverge). We want to track how “hot” specific files are. If files are frequently being written to. We don’t reconstruct the suffix tree, we just do boyer moore fast search.

Curserve: High-Performance Multi-Tenant Coding Agent Infrastructure

Scale coding agents from 1 user to 100+ users on a single server

Eliminate the subprocess bottleneck. Co-locate codebases with inference. Memory-map everything.

🎯 The Problem

Traditional coding agent architectures suffer from fundamental performance bottlenecks:

┌──────────────────────────────────────────────────────────────┐
│              TRADITIONAL ARCHITECTURE                        │
└──────────────────────────────────────────────────────────────┘

┌─────────────┐                         ┌──────────────────┐
│   Client    │ ◄─────────────────────► │   LLM Server     │
│  (Laptop)   │    Network Latency      │   (vLLM/GPU)     │
└─────────────┘                         └──────────────────┘
      │
      │  Local file system
      │  
      ▼
┌─────────────┐
│  Codebase   │
│   (Disk)    │
└─────────────┘

Problems:

Network Overhead: Every tool call (grep, ls, read) requires a round-trip to the client
Process Spawn Overhead: Each grep spawns a subprocess (~10-15ms overhead)
No Multi-Tenancy: Can't efficiently serve 100+ users on one GPU server
Poor Locality: Code is on client, inference is on server

Example: A single agent turn with 10 tool calls

LLM → grep    → 15ms process spawn + network RTT
LLM → grep    → 15ms process spawn + network RTT
LLM → read    → network RTT
LLM → grep    → 15ms process spawn + network RTT
...
Total: 150-300ms overhead per turn (just for tooling!)

💡 The Solution: Curserve

Curserve inverts the traditional architecture by co-locating codebases with inference and eliminating subprocess overhead through memory-mapped in-process operations.

┌───────────────────────────────────────────────────────────────┐
│                  CURSERVE ARCHITECTURE                        │
│                                                               │
│  ┌────────────────────────────────────────────────────────┐  │
│  │              vLLM Process (GPU)                        │  │
│  │  ┌────────────┐  ┌────────────┐  ┌────────────┐       │  │
│  │  │  Request 1 │  │  Request 2 │  │  Request N │       │  │
│  │  │  (User A)  │  │  (User B)  │  │  (User C)  │       │  │
│  │  └─────┬──────┘  └─────┬──────┘  └─────┬──────┘       │  │
│  └────────┼───────────────┼───────────────┼──────────────┘  │
│           │               │               │                 │
│           │  Unix Domain  │  Unix Domain  │                 │
│           │  Socket IPC   │  Socket IPC   │                 │
│           ▼               ▼               ▼                 │
│  ┌────────────────────────────────────────────────────────┐ │
│  │        Memory Search Service (Rust Daemon)            │ │
│  │                                                        │ │
│  │  ┌──────────────┐  ┌──────────────┐  ┌─────────────┐ │ │
│  │  │ Codebase A   │  │ Codebase B   │  │ Codebase C  │ │ │
│  │  │ (mmap'd RAM) │  │ (mmap'd RAM) │  │ (mmap'd RAM)│ │ │
│  │  │              │  │              │  │             │ │ │
│  │  │ • In-memory  │  │ • In-memory  │  │ • In-memory │ │ │
│  │  │   grep       │  │   grep       │  │   grep      │ │ │
│  │  │ • 0.5-3ms    │  │ • 0.5-3ms    │  │ • 0.5-3ms   │ │ │
│  │  └──────────────┘  └──────────────┘  └─────────────┘ │ │
│  └────────────────────────────────────────────────────────┘ │
│                                                             │
└─────────────────────────────────────────────────────────────┘
                       ▲
                       │ SSH + Binary Invocation
                       │
              ┌────────┴────────┐
              │   curserve      │
              │   [workspace]   │
              │   [prompt]      │
              └─────────────────┘
                     Clients

Benefits:

✅ No process spawn overhead: grep/ls/read execute in-process
✅ Memory-mapped I/O: 10-50x faster than subprocess ripgrep
✅ Multi-tenant ready: One daemon serves 100+ concurrent agent sessions
✅ Zero network latency: Tools run in the same datacenter as LLM
✅ Scales to hundreds of users: Share GPU + storage infrastructure

🏗️ System Architecture

High-Level Data Flow

┌─────────────────────────────────────────────────────────────────┐
│ 1. Client SSH Connection                                        │
└─────────────────────────────────────────────────────────────────┘

ssh user@curserve-server
$ curserve ~/my-codebase "fix the authentication bug"

┌─────────────────────────────────────────────────────────────────┐
│ 2. qwen-code-ipc Initialization                                 │
└─────────────────────────────────────────────────────────────────┘

qwen-code-ipc starts
├─ Connects to /tmp/mem_search_service_requests.sock
├─ Sends: {"type": "alloc_pid", "pid": 12345, "repo_dir_path": "..."}
└─ Memory Search Service memory-maps entire codebase into RAM

┌─────────────────────────────────────────────────────────────────┐
│ 3. Agent Execution Loop                                         │
└─────────────────────────────────────────────────────────────────┘

                    ┌──────────────────┐
                    │  vLLM (Qwen3)   │
                    └────────┬─────────┘
                             │
                    ┌────────▼──────────┐
                    │ "grep for         │
                    │  authentication   │
                    │  functions"       │
                    └────────┬──────────┘
                             │
              ┌──────────────▼──────────────┐
              │   qwen-code-ipc Tool Layer  │
              │                             │
              │ grep() intercepts process   │
              │ spawn, calls IPC instead    │
              └──────────────┬──────────────┘
                             │ IPC Request
              ┌──────────────▼──────────────┐
              │ Memory Search Service       │
              │                             │
              │ Searches in-memory files    │
              │ Returns: "auth.py:42:..."   │
              └──────────────┬──────────────┘
                             │ 0.5-3ms
              ┌──────────────▼──────────────┐
              │     qwen-code-ipc           │
              │                             │
              │  Formats response for LLM   │
              └──────────────┬──────────────┘
                             │
                    ┌────────▼──────────┐
                    │    vLLM           │
                    │ "Found auth bug   │
                    │  on line 42..."   │
                    └───────────────────┘

Repeat for 10-20 tool calls per agent turn
Total overhead: ~10-30ms (vs 150-300ms traditional)

Component Breakdown

curserve/
│
├── mem-search-service/          # Rust daemon for in-memory operations
│   ├── src/
│   │   ├── lib.rs              # MmapCache: memory-mapped file management
│   │   ├── service.rs          # Unix socket IPC server
│   │   └── benchmark.rs        # Performance comparison tools
│   ├── Cargo.toml              # Dependencies: ripgrep, memmap2, etc.
│   └── target/release/
│       └── mem-search-service  # Compiled daemon binary
│
└── qwen-code-ipc/              # Modified qwen-code framework
    ├── packages/
    │   ├── core/
    │   │   └── src/
    │   │       ├── tools/
    │   │       │   └── ripGrep.ts     # Intercepted grep tool
    │   │       └── utils/
    │   │           └── ipcClient.ts   # Unix socket IPC client
    │   └── cli/
    │       └── src/
    │           └── index.ts           # Entry point
    └── dist/
        └── cli.js                     # Compiled qwen-code binary

🔧 Key Innovations

1. Memory-Mapped Codebases

Traditional coding agents spawn ripgrep subprocesses that read from disk on every search.

// mem-search-service/src/lib.rs

pub struct MmapCache {
    pub files: Vec<MmappedFile>,
}

impl MmapCache {
    pub fn new(root_path: &Path) -> Result<Self> {
        // Walk directory tree (respecting .gitignore)
        // Memory-map EVERY text file into RAM
        // ~10-20MB for typical codebases
    }
    
    pub fn search(&self, pattern: &str) -> Vec<Match> {
        // Search directly in RAM using ripgrep internals
        // No subprocess spawn, no disk I/O
        // 0.5-3ms vs 10-15ms subprocess
    }
}

Performance Impact:

Codebase Size	Subprocess grep	In-Memory grep	Speedup
Small (100 files)	~10ms	~0.5ms	20x
Medium (500 files)	~15ms	~1ms	15x
Large (1000+ files)	~20ms	~3ms	7x

2. IPC-Based Tool Interception

We forked qwen-code and modified the tool layer to use IPC instead of spawning processes.

Before (qwen-code):

// Spawns new process for every grep call
async function grep(pattern: string) {
  const child = spawn('rg', [pattern, ...args]);
  return await collectOutput(child); // ~10-15ms overhead
}

After (qwen-code-ipc):

// packages/core/src/tools/ripGrep.ts

async function performRipgrepSearch(options) {
  try {
    // Try IPC first
    const output = await requestGrepIPC(
      workspacePath,
      pattern,
      [absolutePath],
      ipcOptions
    );
    return parseRipgrepOutput(output); // ~0.5-3ms
  } catch (error) {
    // Graceful fallback to subprocess if IPC unavailable
    return performRipgrepSearchDirect(options);
  }
}

IPC Protocol (Unix Domain Sockets):

Client                              Memory Search Service
  │                                          │
  ├─ Connect to /tmp/mem_search_...         │
  │                                          │
  ├─ Send: {"type": "alloc_pid", ...} ────► │
  │                                          ├─ mmap codebase
  │                                          ├─ create /tmp/qwen_code_response_12345.sock
  │ ◄──── {"response_status": 1} ───────────┤
  │                                          │
  ├─ Send: {"type": "request_ripgrep",...}─►│
  │                                          ├─ search in-memory files
  │ ◄──── {"text": "file.py:42:..."} ───────┤
  │                                          │

3. Multi-Tenant Architecture

One mem-search-service daemon handles requests from 100+ concurrent qwen-code-ipc instances.

// mem-search-service/src/service.rs

struct ServiceState {
    codebases: HashMap<u32, MmapCache>,      // PID → memory-mapped codebase
    response_sockets: HashMap<u32, UnixStream>, // PID → response channel
}

// Three-threaded architecture:
// 1. Request listener: Accepts new connections
// 2. Connection acceptor: Manages per-client response sockets
// 3. Request worker: Executes searches in-memory

fn request_worker(rx: Receiver<Request>, state: Arc<Mutex<ServiceState>>) {
    loop {
        let (request, stream) = rx.recv().unwrap();
        
        match request {
            Request::AllocPid { pid, repo_dir_path } => {
                // Memory-map entire codebase
                let cache = MmapCache::new(&repo_dir_path)?;
                state.codebases.insert(pid, cache);
            }
            Request::RequestRipgrep { pid, pattern, .. } => {
                // Search in-memory, no I/O
                let results = state.codebases[&pid].search(&pattern)?;
                send_response(results);
            }
        }
    }
}

Resource Usage:

Memory: ~15-30MB per codebase (text files only, binaries skipped)
CPU: Shared across all users (ripgrep is already parallelized)
Storage: All codebases on fast NVMe (or network-attached if needed)

📊 Performance Benchmarks

Tool Call Latency

$ ./target/release/benchmark ~/linux-kernel "static inline" 100

Results:

================================================================================
Memory-Mapped Search (Curserve)
================================================================================
Average: 2.1ms
Min:     1.8ms
Max:     3.4ms
Matches: 1,247

================================================================================
Subprocess Ripgrep (Traditional)
================================================================================
Average: 14.3ms
Min:     12.1ms
Max:     18.7ms
Matches: 1,247

================================================================================
SPEEDUP: 6.8x faster
TIME SAVED: 12.2ms per search
================================================================================

Agent Turn Latency

Scenario: Fix a bug (10 grep calls, 3 file reads)

Architecture	Tool Overhead	LLM Inference	Total Turn Time
Traditional (laptop + remote LLM)	150ms (10×15ms)	500ms	650ms
Curserve (co-located)	10ms (10×1ms)	500ms	510ms
Improvement	93% faster	-	22% faster

Multi-Tenant Scalability

Setup: Single server with 1x H100 GPU, 100 concurrent users

Metric	Traditional	Curserve
Supported users	~10-20 (network bottleneck)	100+
GPU utilization	40-60% (waiting on I/O)	85-95%
Tool latency (p50)	15ms	2ms
Tool latency (p99)	80ms	8ms

🚀 Getting Started

Prerequisites

Rust (1.70+): For building mem-search-service
Node.js (20+): For building qwen-code-ipc
Git submodules: Both components are in this repo

1. Clone and Initialize

git clone https://github.com/your-org/curserve.git
cd curserve
git submodule update --init --recursive

2. Build Memory Search Service

cd mem-search-service
cargo build --release

Binary will be at: ./target/release/mem-search-service

3. Build qwen-code-ipc

cd ../qwen-code-ipc
npm install
npm run build

Binary will be at: ./dist/cli.js

4. Start the Memory Search Service

./mem-search-service/target/release/mem-search-service

Output:

================================================================================
CURSERVE Memory Search Service
================================================================================

Request listener started on /tmp/mem_search_service_requests.sock
Worker thread started
Service running. Press Ctrl+C to stop.

5. Run a Coding Agent Session

node qwen-code-ipc/dist/cli.js ~/my-codebase

Or create a shell alias:

alias curserve='node /path/to/curserve/qwen-code-ipc/dist/cli.js'

Then:

curserve ~/my-project
> Find all TODO comments and prioritize them by importance

🧪 Testing and Validation

Test IPC Communication

cd mem-search-service
cargo test

Benchmark Grep Performance

./target/release/benchmark /path/to/codebase "search pattern" 100

Integration Test

# Terminal 1: Start daemon
./target/release/mem-search-service

# Terminal 2: Run qwen-code-ipc
cd ../qwen-code-ipc
npm test

📖 IPC Protocol Specification

Socket Paths

Request socket (shared): /tmp/mem_search_service_requests.sock
Response sockets (per-client): /tmp/qwen_code_response_{pid}.sock

Request Types

1. Allocate PID

Request:

{
  "type": "alloc_pid",
  "pid": 12345,
  "repo_dir_path": "/home/user/my-codebase"
}

Response:

{
  "response_status": 1,
  "text": "Allocated 347 files"
}

2. Ripgrep Search

Request:

{
  "type": "request_ripgrep",
  "pid": 12345,
  "pattern": "fn\\s+\\w+",
  "paths": ["/home/user/my-codebase/src"],
  "options": {
    "line_number": true,
    "ignore_case": false,
    "threads": 4
  }
}

Response:

{
  "response_status": 1,
  "text": "src/main.rs:42:fn main() {\nsrc/lib.rs:10:fn search() {"
}

Error Responses

{
  "response_status": 0,
  "error": "PID 12345 has no allocated codebase. Call alloc_pid first."
}

🔒 Security Considerations

Isolation

Per-user codebases: Each client gets an isolated memory-mapped view
Unix permissions: Socket access controlled by filesystem permissions
Process isolation: qwen-code-ipc runs as the user's process (SSH session)

Resource Limits

// Future work: Implement codebase eviction
// When RAM > threshold:
//   - Evict least-recently-used codebases
//   - Re-allocate on next grep request

Recommended Deployment

┌─────────────────────────────────────────────┐
│         Curserve Server                     │
│                                             │
│  ┌───────────────────────────────────────┐ │
│  │  mem-search-service (privileged)      │ │
│  │  • Runs as root or dedicated user     │ │
│  │  • Socket permissions: 0770           │ │
│  └───────────────────────────────────────┘ │
│                                             │
│  ┌───────────────────────────────────────┐ │
│  │  SSH Access (per-user)                │ │
│  │  • Users SSH in                       │ │
│  │  • Run: curserve [workspace] [prompt] │ │
│  │  • qwen-code-ipc runs as their user   │ │
│  └───────────────────────────────────────┘ │
│                                             │
│  ┌───────────────────────────────────────┐ │
│  │  vLLM (GPU inference)                 │ │
│  │  • Shared across all users            │ │
│  │  • Rate limiting per user/team        │ │
│  └───────────────────────────────────────┘ │
└─────────────────────────────────────────────┘

🛠️ Troubleshooting

Socket Already Exists

$ ./mem-search-service
Error: Address already in use

Solution:

rm /tmp/mem_search_service_requests.sock
./mem-search-service

IPC Connection Failed

qwen-code-ipc: Failed to connect to socket

Check:

Is mem-search-service running?
Socket permissions: ls -l /tmp/mem_search_service_requests.sock
Firewall/SELinux blocking Unix sockets?

High Memory Usage

$ ps aux | grep mem-search-service
user     12345  2.5  8.3  8472192 ...

Analysis:

Each codebase uses ~15-30MB (text files only)
100 codebases = ~2-3GB RAM (very manageable)
Future: Implement LRU eviction for 1000+ users

🗺️ Roadmap

Phase 1: Core Infrastructure ✅

Memory-mapped grep in Rust
Unix domain socket IPC
qwen-code fork with IPC integration
Basic multi-tenancy support

Phase 2: Production Readiness (Q2 2025)

File watching & auto-reload on changes
Codebase eviction/LRU caching
Rate limiting per user/team
Monitoring & telemetry (Prometheus/Grafana)
Docker deployment support

Phase 3: Advanced Features (Q3 2025)

Distributed codebases (multi-node)
Copy-on-write sharing (same codebase, multiple users)
Incremental updates (git pull without full reload)
Advanced tools: find, tree, analyze via IPC

Phase 4: Optimization (Q4 2025)

Suffix tree indexing for hot files
Predictive codebase loading
GPU-accelerated search (cuDF/RAPIDS)
Zero-copy IPC (shared memory)

📚 Documentation

Memory Search Service: See mem-search-service/README.md
qwen-code-ipc: See qwen-code-ipc/README.md
IPC Protocol: See docs/ipc-protocol.md (coming soon)
Deployment Guide: See docs/deployment.md (coming soon)

🤝 Contributing

We welcome contributions! Key areas:

Performance: Optimize search algorithms, memory usage
Reliability: Error handling, crash recovery
Scalability: Better multi-tenancy, distributed support
Tools: Add more IPC-backed tools (find, tree, etc.)

See CONTRIBUTING.md for guidelines.

📄 License

MIT License - see LICENSE for details.

🙏 Acknowledgments

ripgrep by BurntSushi: Core search engine
qwen-code by QwenLM: Base agent framework
vLLM: High-performance inference engine

📧 Contact

Issues: GitHub Issues
Discussions: GitHub Discussions
Email: team@curserve.ai (coming soon)

Built with ❤️ for the coding agent community

Star ⭐ this repo if you find it useful!

Analysis

Compare with all teams

View

Metric

Alex Kranias
7

Figures cover GitHub contributors during the hackathon window. A co-authored commit counts in full for each author, so per-member totals add up to more than the whole-team figures.

Technology

Found in codeClaimed only

PythonClaimed
RustClaimed
TypeScriptClaimed

0 of 3 appear in the indexed code. 3 claimed on Devpost could not be matched to code, which may simply mean the tool leaves no trace in the repository.

AI coding agents

No AI coding agent signals were found in this repository.

Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.

Codebase size

Source size

25 KB

Source files

Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.

Feature verification

9 Blocked

File system watching and mmap auto-reload on changeBlocked
Uses the notify crate for real-time file change detection and remaps memory-mapped files when they are overwritten (e.g. by VSCode)
Claimed on Devposthigh confidence
Modified Qwen-Code-CLI (qwen-code-ipc) routing tool calls through IPCBlocked
Forked Qwen-Code-CLI and modified its tool layer (ripGrep.ts, ipcClient.ts) to route grep calls to the daemon instead of spawning subprocesses, with fallback to subprocess
Claimed on readmehigh confidence
Multi-tenant daemon (alloc_pid/close API, PID-keyed codebase map)Blocked
Simple API of alloc_pid(), ripgrep(), close(); one daemon serves many concurrent users via a PID to MmapCache HashMap
Claimed on readmehigh confidence
Parallel search across CPU cores via RayonBlocked
Uses Rayon for parallel search across CPU cores
Claimed on Devposthigh confidence
Performance benchmarking tool comparing in-memory vs subprocess ripgrepBlocked
benchmark.rs / target/release/benchmark tool reports in-memory search is 5-30x (or 6.8x in the sample run) faster than subprocess ripgrep
Claimed on readmehigh confidence
Rust mem-search-service daemon with in-memory ripgrepBlocked
A custom Rust daemon (mem-search-service) uses ripgrep's core libraries (grep-searcher, grep-regex) and memmap2 to perform in-memory searches
Claimed on Devposthigh confidence
SSH-based single-command session start (curserve CLI)Blocked
Users SSH into the server and run a single command (curserve [workspace] [prompt]) to start an AI coding session
Claimed on readmehigh confidence
Unix domain socket IPC protocolBlocked
IPC layer using Unix domain sockets with a shared request socket and per-client response sockets, JSON protocol, sub-millisecond communication
Claimed on readmehigh confidence
vLLM-served Qwen2.5-Coder-32B-Instruct on a rented A100Blocked
Deployed Qwen2.5-Coder-32B-Instruct via vLLM on an A100 GPU rented from vast.ai, co-located with the mem-search-service and user codebases
Claimed on Devposthigh confidence

An AI agent derived these features from the project’s Devpost page and readme, then searched the code for each one. Verified features are backed by cited code; claimed-only features had no supporting code, which is not by itself proof a feature is missing.