Summary
Ship pre-built CCE indexes for popular open source repos so users can try CCE instantly without cloning or indexing.
Motivation
Currently, trying CCE requires: clone a repo → run cce init → wait for indexing. Pre-built packs skip all of this. A user could run one command and immediately search FastAPI, Django, or Express without having the source locally.
This also serves as a demo tool: "see CCE in action on a repo you already know."
Approach
- Build indexes for 3-5 popular repos (FastAPI, Django, Express, chi)
- Package as compressed archives (vector store + FTS + graph, likely 3-10 MB each)
- Host on GitHub Releases or a CDN
- Add
cce demo fastapi command that downloads the pack and lets you run searches immediately
- Include the benchmark queries so users can reproduce our published numbers instantly
Considerations
- Packs are tied to a specific commit of the target repo (document which one)
- Packs are tied to the embedding model version (BAAI/bge-small-en-v1.5)
- Need a versioning scheme so packs are invalidated when the embedding model changes
- Keep packs small (index only, no source code, respect licenses)
Inspiration
jCodeMunch ships pre-built symbol indexes (e.g., React 932 MB repo → 3 MB pack). Same concept adapted to CCE's chunk-based approach.
Summary
Ship pre-built CCE indexes for popular open source repos so users can try CCE instantly without cloning or indexing.
Motivation
Currently, trying CCE requires: clone a repo → run
cce init→ wait for indexing. Pre-built packs skip all of this. A user could run one command and immediately search FastAPI, Django, or Express without having the source locally.This also serves as a demo tool: "see CCE in action on a repo you already know."
Approach
cce demo fastapicommand that downloads the pack and lets you run searches immediatelyConsiderations
Inspiration
jCodeMunch ships pre-built symbol indexes (e.g., React 932 MB repo → 3 MB pack). Same concept adapted to CCE's chunk-based approach.