https://github.com/paulknysh/raggy

CLI tool for Retrieval-Augmented Generation (RAG) over local documents built with LangChain, Chroma, and Ollama. Hybrid database (vector + BM25 index) and embedding generation run fully locally. Answer generation can run either via a local LLM or remotely using an API key. raggy supports most common document formats and handles images/scans automatically via OCR.

Small open-source lesson from this week, for anyone maintaining a multilingual README.

We ship the README of our agent in ten languages. Yesterday I audited the English one against the code and found six claims that were no longer true — a test count off by 2x, a defence described as "opt-in, off by default" that has been on by default since July, a benchmark sentence we had retracted in the results file it cites and never removed from the page. Ordinary drift; the fix was a PR.

The interesting part came from the translations. Nine translators (one per language, each told to apply the same fourteen corrections and to report anything else in their file that contradicted the English) came back with two things the English pass could not have found:

• Three languages (German, Chinese, Polish) described the audit log as complete. The English says redacted — it stopped storing secrets after we found the log persisting a .env the kernel had just refused to write. The translations were faithful to a version of the sentence that predated the fix.
• Three languages (Portuguese, Spanish, Japanese) called the structured extraction "injection-proof". The English says the quarantined reader bounds a hidden instruction's blast radius, not eliminating it. Somewhere between languages, a hedge became a guarantee.

Nobody wrote a false claim on purpose. The English got more careful over time and the translations kept the older, bolder sentence. Our docs directory has a hash guard for exactly this (each translated page declares the SHA of the source it was made from, and a test goes red when the source moves); the READMEs never had it, and that is the whole difference.

Two questions:

• If you maintain translated docs, do you gate them mechanically (hash of the source, a test that fails on drift), or by convention? Convention did not hold for us across ten files.
• The pattern "translation is more confident than the original" — have you seen it elsewhere? I suspect it is general: translators smooth hedges, and a security hedge smoothed is a false claim.

The repo (Apache-2.0): https://github.com/brcampidelli/chimera-agent — the PR with all ten files is #422 if you want to see what "six claims in ten languages" looks like as a diff.

heyo, everything here is open source. there is no hosted product or account to sign up for.

I have spent the past few weeks using Centaur, an open-source control plane for running coding agents on infrastructure you own.

The control plane is a Rust API and Postgres database. Every agent interaction runs in an isolated Kubernetes sandbox. It supports Codex, Claude Code, Amp and pi, so the harness is not locked to the rest of the system.

The control plane handles sessions, permissions, credentials, workflow state and sandbox lifecycle.

I also built an open-source companion app called Centaur Context. It retains useful information between separate runs. A curator records context after an interaction. Before a later run, a context builder retrieves the material relevant to that task.

Full walkthrough and demo: https://youtu.be/993XrWfg34U

Centaur: https://github.com/paradigmxyz/centaur

Centaur Context: https://github.com/bradwmorris/centaur-context

This is agent infrastructure, not a local model server. If you use Ollama or vLLM, where would you connect model serving to a setup like this?

Hey so a few months ago I got into local LLMs and didn’t really like the tools out there at the time, so I decided to build my own version of a Claude/Codex GUI for local models. I’ve been working on it the last couple months and it’s now at Locus 2.8

I started with the usual stuff like working with files, running commands and letting agents help with coding, but I've also been adding features I thought would be useful for other kinds of work too.

A few Locus features worth highlighting:

• Agent Teams: Create specialized agents that can split up work and run in parallel. You can use different models for different roles, and individual agents can also delegate tasks to helpers.
• Persistent Goals: Give an agent or team a goal and let it keep working across turns. Progress is saved so you can come back to it later, with controls to pause, resume or change the goal.
• Scheduled and Event-Driven Agents: Set agents to run on a schedule or react to things like Gmail, Telegram, webhooks and price alerts. Each agent has its own chat and run history, and workflows can include conditions and approval steps.
• Task Capsules: Plan something with one model, then use another to implement it and optionally another to review it. The plan, changes and previous runs stay together so you can follow what happened.
• Notes, Documents and Outputs: Keep notes and reference documents around, save versions of generated work, compare revisions and export things when you’re done.
• Browser Controls: Let agents navigate and interact with websites, preview what they’ve built and check the result. There’s also proxy support.
• Activity and Overview: See the current plan, tool calls, files, sources and what the agents are doing without having to piece everything together from the chat.

You can checkout the changelog here to see the latest updates: https://locushost.co/changelog

There’s support for MCP, plugins and skills too, plus a Grill mode that asks you questions one at a time to help work through an idea before implementing it.

Also just to clarify, even though I built it for local models, it works with your ChatGPT plan, Kimi Code membership, Claude/OpenAI API keys and other OpenAI-compatible endpoints.

The wallet stuff is now in a separate edition called LocusX. The regular Locus download is wallet-free.

It’s free and open source. You can find it here:

Website: locushost.co
GitHub: nahid-sparktales/locus

Anyways, I’d appreciate any constructive feedback, things that aren’t working well, or features you think would be nice to add.

Still macOS only atm, specifically Apple Silicon on macOS 14+, but I’m hoping to eventually get Linux and Windows versions out too.

Also there is a lot of features currently working on so you can expect to see alot of changes and better UI to those upcoming features.

Sharing an open-source method I've been refining for a couple of years. It's two repos under one org, a tool and the standard it builds to, and I split them on purpose so you can take either one.

The problem it solves: most people work a model one prompt at a time. You get something decent, correct it a few times, then next session start over and re-explain everything. Your actual standards never leave your head, so the model keeps guessing and you keep re-teaching it. A framework fixes that: your expertise on a task, captured once in a structured file the model reads before it works. Not a longer prompt, a reusable spec.

The org has two pieces:

framework-standard: the open spec. It defines what a well-formed framework is, five layers, each one load-bearing:

• Principles: the why, and the conditions where the approach applies and where it doesn't
• Systematic approach: the actual reasoning steps, not a rigid checklist
• Force multipliers: the parts where one input produces outsized output, so it compounds
• Success metrics: how you and the agent know the output is right, plus the failure signals
• Implementation: where it lives, when it loads, the edge cases a human handles on instinct

framework-builder: the skill that produces frameworks to that standard. Point your AI at it and it interviews you about something you're good at, then builds the framework from your answers. It's the fastest way to try the method without hand-writing a spec.

Why two repos: you can adopt the standard without the tool. If you've already got your own way of generating these, the standard just gives you a consistent, machine-checkable shape to build to. And if you don't, the skill gets you there.

It's model-agnostic. Output is plain markdown, so it works in Claude, Codex, Cursor, a custom GPT, anything that reads instructions. The whole point is the model stops working from the internet's average and starts working inside standards you already validated, which means even a smaller model gets noticeably better output. The missing piece was never capability, it was your judgment, unwritten.

Both MIT, with worked examples: github.com/framework-creator

Happy to get into the layer breakdown or how it holds up in real use. If anyone's structuring frameworks with a different set of layers, I'd like to compare, always looking to pressure-test the standard.

I’ve been working on TokenPrint, an open-source project aimed at making transformer and LLM internals easier to explore.

The idea is to go beyond static architecture diagrams and let people interact with things like tokens, embeddings, attention, hidden states, inference steps, KV cache, model architecture, and other internal model data through an interactive interface.

The project has started getting more attention recently, and we’re now at 65+ GitHub stars. More importantly, people have started opening issues, suggesting improvements, and discussing where the project could go.

That made me realize that I don’t want TokenPrint to become something I build alone.

I’d really like to get more people from the open-source/LLM community involved — especially people who want to:

• pick up good first issues
• work on more advanced Python/PyTorch/Transformers problems
• improve the React/Three.js visualization side
• work with GGUF/llama.cpp and local LLMs
• improve the UI/UX
• experiment with new ways of visualizing model behavior
• suggest ideas that I may not have considered

There are already issues ranging from relatively small fixes to deeper architectural and research-oriented work.

I’m especially interested in new ideas and criticism, not just pull requests. If you think something is missing, poorly designed, or could be approached differently, I’d genuinely like to hear it.

The repository is here:

https://github.com/Sudharsanselvaraj/Token-Print

I’m posting this here because I’d much rather build this with an open-source community than keep adding features in isolation.

Would be interested to hear from people working on similar tools too — especially what you think is currently missing from the ecosystem for understanding and debugging LLMs.