cepstrum9
Joined 1 year ago
Joined 1 year ago
i.e
from raglet import RAGlet rag = RAGlet.from_files(["docs/", "notes.md"]) results = rag.search("what did we decide about the API design?", top_k=5) rag.save("my-notes")
Load it anywhere rag = RAGlet.load("my-notes")
Local embeddings (sentence-transformers, no API keys), saves to a plain directory you can git commit.
The benchmark numbers were more interesting than I expected: 1 MB (~262K tokens) | 3.5s build | 3.7ms search 10 MB (~2.6M tokens) | 35s build | 6.3ms search 100 MB (~26M tokens) | 6min build | 10.4ms search Honest limitations: .txt and .md only right now (PDF/DOCX is next), no file change detection, ~100 MB practical ceiling before build time gets unwieldy.
What would make this useful for your workflow? Would love to get your feedback.
GitHub Copilot Reviews is much more integrated into the GitHub platform and can access richer context like the full diff, surrounding files, and maybe repo history. It’s probably more sophisticated behind the scenes.
That said, Codii is:
• Easy to install (just a GitHub app)
• Fast to iterate on (I can tweak the prompts based on feedback)
• Customizable (it’s mine, so I can steer it toward indie dev use cases like onboarding help or documenting design choices)
In terms of requests and pricing, I believe GitHub Copilot free is going to offer 2k completions and 50 chats per month per user starting May 2025, and offers a Pro plan @19$ per user I think where you actually get access to much more than just reviews just to be clear, whereas Codii for now will be free until I gather feedback, but will be limited to 200 scans per month per user. Planning to offer a paid plan soon around the ~10$ mark
TL;DR: Codii is like a minimalistic, customizable code review assistant powered by GPT — not as powerful as Copilot Reviews yet, but very easy to set up and iterate on
Also, there is context that’s not just code but documentation/guidelines etc, plenty of experimentation to be done there.
Customisable rules? YES - i ve got a lot of plans currently on this. I see two layers of customisation: - allow the user to customise when and how often reviews happen, and how they re triggered (i.e every commit/every x mins etc, avoid running prs on specific files I.e package.json changes etc) - pass in custom rules to the reviewer that work well for you(or team in the future). This will allow the tool to be more dynamic in nature as opposed to just LLM + your code.
Hope this answers your questions, thank you for the support!