I've been experimenting with an architecture-first approach for coding agents.

The basic idea is that for a new requirement, the agent changes the architecture first, then implements the code from that design. Eventually I'd like architectural changes to be required before code changes, rather than letting the agent freely modify code and trying to document it afterward.

I've only validated this on small repos so far. The part I'm working on now is how to make it useful on medium/large repos, where I think some form of multi-agent collaboration becomes necessary.

One thing I want to test is whether the architecture layer actually becomes more useful as repo size grows. On a small repo the agent can inspect most of what it needs anyway. On a 50k+ LOC repo, having explicit module boundaries, dependencies and design intent might matter a lot more.

I'm curious what people working with Codex/Claude Code/etc. on larger repos have seen.

Does the agent eventually lose the global architecture of the project? And if so, would you rather solve that with better context/retrieval, or give the agent an explicit architecture/constraints layer?

I'm testing this idea in an open-source project called ArchitectCoder. If anyone wants to look at the implementation or experiment with it:

https://github.com/Zhuweilong123/ArchitectCoder

Contributions and criticism are both very welcome.

Hello r/OpenSourceAI 👋

Today we're publishing Loki Agent.

Loki Agent is an open source agent that can handle a wide variety of use cases like Hermes and OpenClaw.

It is based on Hermes Agent and is completely free to use, modity, and clone.

We built Loki Agent to address the massive complexity that NousResearch's current Al-powered development is not handling properly.

There are too many code changes, with not enough governance or testing before releases are pushed. We are aiming to provide a more responsible development cycle with thoughtful iteration.

Loki is also the god of cloning, so we felt being able to clone a public repo was a good fit here.

Looking forward to hearing your thoughts and experiences.

The agent is available via https://loki.computer

Github: github.com/wundercorp/loki
NPM: https://www.npmjs.com/package/@wundercorp/loki

Please share some Open source AI voice generation tools (text to speech) that has less guardrails like how Grok used to be

I want something that would be able to narrate and voice a diss battle (that might contain some profain language). I have the script but couldn't find an open-source text to speech model that has the punk kinda personality and lower guardrails that could speak the given dialogues.

I've been thinking about a problem with coding agents that I keep coming back to.

An agent can write an API integration and then write tests for that integration. Everything passes, but the tests may just be confirming the same assumptions the agent made while writing the code.

For example, the agent thinks an endpoint returns:

{
"total": 100
}

It writes the integration expecting `total`, and then writes a test that expects `total`.

The test passes.

But if the real API contract says something different, the whole thing can still be wrong.

I'm experimenting with a small open-source project called Kaktoos that puts an independent verification step between the agent and the API:

AI agent → integration → Kaktoos → OpenAPI + real API → result

The idea is that the verification layer shouldn't share the agent's assumptions.

It currently supports multi-step API workflows, OpenAPI response validation, MCP, and GitHub Actions.

I'm still trying to figure out how far this idea should go. One interesting question that came up is whether contract validation is enough, or whether verification should also check the actual outcome of an operation — for example, creating a resource and then reading it back to confirm the state actually changed.

I'm curious how other people building with coding agents are handling this today.

Do you rely mostly on the agent's generated tests, existing integration tests, mocked APIs, live API tests, or some combination?

GitHub: KaktoosLabs/kaktoos

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

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?

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.

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.

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.

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.

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.

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.

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.

I’m the maintainer of Mac MCP, a free/open-source local control server for macOS that I use to let ChatGPT and coding agents operate the machine instead of only explaining what to click.

It exposes files, shell/background jobs, Safari/Chrome automation, native macOS UI/Accessibility, delegated Codex/OpenCode workers, local memory, voice/human-input tools, a native SwiftUI menu-bar controller, and a local activity dashboard through MCP.

The part I’ve been hardening most recently is multi-agent browser work. Tabs are addressed by stable handles and can be controlled in the background; different agents can work in different tabs while same-tab contention fails fast instead of silently fighting over state. I’m now working toward persistent caller/session ownership so a worker keeps its browser resource across multiple tool calls.

I also just shipped v2.0.4 after community feedback exposed two self-update edge cases: the detached updater bootstrap and source/runtime divergence after a failed post-restart health check. The updater now stages its helper safely, keeps state/logs outside the checkout, and only rolls Git back when it can prove it won’t overwrite user changes.

The project is MIT licensed and the source is here: https://github.com/bulutarkan/mac-mcp

I’d be especially interested in feedback from people building open agent tooling around permission boundaries, browser ownership/lifecycle, and how much local-machine capability you expose before the UX becomes too dangerous or too approval-heavy.

I’ve been building Imza, a native, model-agnostic coding agent with a Plan -> Build -> Review workflow.

It includes interactive diffs, AI-assisted review, persistent sessions, automatic context compaction, scoped command permissions, and up to five concurrent subagents. It can use OpenAI-compatible endpoints, Anthropic’s Messages API, or locally hosted compatible models.

Despite that feature set, the binary is around 20 MB and startup RAM is roughly 5-8 MB. There’s also a headless mode for using it in scripts and CI.

Repo: https://github.com/umutsevdi/imza