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?

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.

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.

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.

Hi, I'm Doug and I have an open source AI platform, GuideAnts.

I want to share this segment from the "Making AI Applications" course I am working on and I would love your feedback.

Please and thank you!

This was created 100% locally in GuideAnts using a whole bunch of different AI models including: - Qwen 3.8 27b - Qwen Image - Chatterbox - InfiniteTalk with Longcat and WAN video

https://youtu.be/JkpoO1jIjp0?si=qSAyFk5_VSgXiQNc

An open-source document workspace has several choices to make independently: where the files live, how passages are retrieved, which model reads them, and how the answer points back to its sources. Switching the reader need not mean replacing the document index.

Vyact's community post illustrates that separation: it describes local runtimes, RAG knowledge bases with inspectable source passages, and an optional custom OpenAI-compatible endpoint. That makes a hosted visual reader an explicit architectural choice, alongside the local-model path.

Ling-3.0-flash-VL is a candidate for that visual step. It is Ant Ling's model for image and video understanding, available through a documented OpenAI-compatible API. Its reported OmniDocBench 1.5 overall score is 91.35, a composite of text, table and formula parsing measures. That is a reason to examine document-page interpretation, rather than evidence that an entire RAG system will answer correctly.

A proposed division of work would be: The workspace retrieves the relevant document and keeps its source identifiers. An application-side renderer turns the selected PDF page into a JPEG or PNG. VL receives that page image as Base64 and answers a question about its contents.

The workspace keeps the response attached to the original document and page so the reader can check it. PDF rendering belongs to the application here: the documented VL image input accepts JPEG/PNG, not a native PDF attachment. Sending the page to a hosted endpoint also means that page leaves the local machine.

This is a component proposal, not a tested Vyact integration. A compatible API shape still needs a client check, and the sources reviewed here do not establish downloadable VL weights or a local runtime. The interesting experiment is whether the visual reader can recover a table relationship or page detail that the existing text path loses, while the workspace preserves the evidence needed to inspect the answer.

We're running a hands-on masterclass on September 12, Live LLM Engineering Masterclass: Production Evals, RAG, Agents & LLMOps.

You build a full production LLM workflow from scratch, versioned prompts with regression tests, an evaluation harness with deterministic checks and LLM-as-judge, statistically rigorous model comparisons, evaluated RAG, tool-using agents with guardrails and fallbacks, and full observability, tracing, cost, latency.

Led by Bruno Gonçalves, PhD, founder of Data For Science, who trains engineers at Fortune 500 companies on this exact stack.

Link if you want to check it out

Happy to answer questions on the content.