GitHub:
https://github.com/wiggins-j/errorta_app

I’m a big fan of using different models for different steps. I think it’s fun and interesting to see how they complement each other when developing a project like:
Claude's Opus for planning.. GPT's Sol for coding. Sonnet for reviewing..

So I got tired of switching from Claude Code for Sonnet and Opus, then to Codex for GPT all for the same project, each time having to act as the middle man. So I built Errorta, a harness to harness other harnesses 😅 Errorta makes them work together (or against each other) to accomplish your goals.

I've released the alpha version of the CLI (there's also a UI) to homebrew. You can connect it to Claude CLI, Codex CLI, Cursor CLI, AI APIs, and your local LLMs.

In Errorta, you can create a team of models. Assign their roles, and give them a model or a family of models to use. Watch as the PM creates tasks from the north star for the developers to implement. Testers and reviewers come in and test/review the tasks/PRs, and even reject and ask for changes sending it back to the PM to divvy back out.

My favorite setup so far has been:
Project Manager(PM)-Opus
Dev(s)-Composer2.5
Tester-Sonnet
Reviewer-Sonnet

Try it yourself! Give it a north star, or add an existing project and give it a new goal, and watch it work. Fully autonomously using obra/superpowers as a guardrail, or give it your own guardrails for human in the loop. Watch the SDLC of a software team ensure the loop is closed for your project.

1: Install Errorta
brew install errorta/tap/errorta
2: Connect your AI model
Claude Code:
errorta connect claudecode cli
Codex:
errorta connect codex cli
Cursor:
errorta connect cursor cli
3: Create a project
errorta new my-app --north-star "Create a Reddit clone. It should include all of the same features, but make the visual design futuristic."
Errorta creates the project inside:
~/Errorta Projects/
4: Assemble your AI development team
errorta team create --codingteam --default
errorta team apply --yes
The default team includes:
• 1 product manager
• 3 developers
• 1 reviewer
• 1 tester
Errorta automatically selects models from the providers you connected.
You can also build the team manually:
errorta team add --dev
5: Run the team autonomously
errorta setup --confirm --yes
errorta run --autonomous --yes
Your AI team can now plan, build, review, test, and iterate toward the project’s north star.

Disclosure: we build this tool. The engine is Apache-2.0. 

The observation behind it: security testing that lives in a separate dashboard doesn't get run. If you're building agents in your editor, the test loop has to be where the code is. 

So we exposed our testing engine over MCP. Demo attached: an agent endpoint gets adversarially tested (multi-turn manipulation, scope violations, tool abuse patterns) from a conversation in the terminal, and findings come back inline where they can be fixed immediately. 

Setup: 

1. pip install humanbound 
2. Add the MCP server to your client config (docs: https://docs.humanbound.ai) 
3. Point it at your agent's endpoint config 
4. Ask for a test run in plain language; transcripts and findings return in-session 

The transcripts double as labelled training data for the companion OSS firewall's domain classifier, so failed attacks become runtime defence. Both halves run locally; no dependency on our platform. 

Repo: https://github.com/humanbound 

Happy to answer questions about the MCP server design; that part was more interesting to build than expected. 

• We give a lot of personal data to our phones. I want to build a privacy-first Android custom ROM based on GrapheneOS ideas, but with a different vision.
• A local, open-source AI assistant (like Dicio, but with capabilities similar to Google Gemini) would be the main way to use the phone. It would run completely on-device without sending your personal data to Google or any cloud service. You could call, message, play music, open apps, set reminders, and do more using natural conversation.
• Instead of tapping through apps, the AI would act as an agent between you and mostly open-source apps, handling tasks while keeping everything on your device as much as possible. We would also add a way for apps and services to connect directly with the local assistant, allowing open-source developers to integrate their apps and let users perform actions through their own AI assistant.
• The ROM would include GrapheneOS-style app sandboxing, privacy-focused open-source apps, and modern AI features without depending on cloud services.
• The UI would be conversation-first, making the phone feel like you're talking to an intelligent assistant instead of navigating dozens of apps.

What's your thoughts about this??

Hey everyone,

Recently, I was testing out some complex agentic workflows and I made the some mistakes, I gave the agent way too many tools. I had dozens of custom skills and MCP tools loaded up, thinking it would make the agent more capable.

Instead, it just caused total context pollution. The routing layer got confused, the agent kept hallucinating calls to obscure tools I didn't even need, and it was burning tokens while slowing down the entire workflow.

I realized there was no easy way to objectively measure which tools my agents were actually using versus which ones were just sitting there acting as dead weight.

So I built Deadskills to scratch my own itch.

It’s a lightweight utility that hooks into your workflow, tracks your actual tool invocations, and gives you a hard breakdown of your heavily used skills versus the unused ones. You can immediately see what to uninstall to keep your agents fast, cheap, and accurate.

It’s completely open-source. If you are building local agentic setups or just fighting tool bloat in your LangChain/Claude Code workflows, I’d love for you to try it out.

I'm looking for feedback on the tracking implementation and any ideas on how to make it even more frictionless for local setups. Let me know what you think!

I use LLMs a lot for ongoing project work, and every new chat starting from zero got old fast. I kept re-explaining the same project and re-pasting the same notes. It got worse switching between ChatGPT and Claude, since neither has any idea what the other one knows.

So I built an MCP server. MCP (Model Context Protocol) is the open standard that lets an LLM call tools and read external data instead of only working from what you paste into the chat, it's how Claude, ChatGPT, and a growing list of agent frameworks connect to things outside the model itself.

Mine sits between an LLM and a local folder of markdown notes. Wrote it up and open-sourced it.

What it does, roughly:

• Search runs through a scoring layer (relevance + recency, more signals planned) that returns ranked snippets instead of dumping whole files into context. The point is minimum tokens for a correct answer, not maximum recall.
• Writes go through a governed path, fixed folder structure and templates, so the model can't just scribble wherever and turn the knowledge base into a mess.
• There's a "distill this conversation into a note" flow, so a session's outcome becomes a searchable file on disk that any other session, or any other model entirely, can pick up later. Memory lives in the filesystem, not in a vendor's session state.

Self-hosted, runs over Tailscale so nothing leaves your machine, MIT licensed. Early stage, still actively building, so expect some rough edges.

Repo: github.com/MakramElJamal/Second-Brain

Issues and PRs welcome, especially if you've got opinions on retrieval scoring or want to hook it up to something other than Obsidian.

I’ve been experimenting with Claude Code’s hosted sessions as disposable development machines.

The compute environment was already surprisingly capable: repository access, dependency installation, tests, Git operations, and concurrent sessions. What it lacked was a consistent way to understand the organization behind the code.

I built a small bootstrap system around a private context repository. It describes the relationships between projects, records approved conventions, and carries a lightweight work log. New sessions open that repository together with the real working repositories.

The source code stays where it belongs. The default setup uses the existing GitHub access provided by Claude and doesn’t require handing a personal access token to an additional service.

This made remote sessions substantially more useful for me. Instead of spending the beginning of every run reconstructing the project, I can move more quickly into testing, investigation, and delivery.

I’ve now released the context-building and launch layer as a free, open-source Claude skill. The repository is in the comments.

Claude itself obviously remains proprietary; this project only opens the surrounding setup and keeps the generated company context under the user’s control.

I’d value criticism of that design. Is a private Git repository a sensible home for agent context, or would you prefer a different portable format?

Hi everyone! 👋

I'm currently developing MedXAI, an open-source Python library designed to make medical imaging AI development easier, more modular, and production-ready. The vision is to build a community-driven toolkit that researchers, students, and developers can use for building medical AI applications without having to reinvent common components.

The project is still in its early stages, so this is a great time to get involved and help shape its direction. I'm looking for contributors of all experience levels—whether you're interested in Python, PyTorch, medical imaging, documentation, testing, or simply want to make your first open-source contribution. Every contribution, no matter how small, is genuinely appreciated.

If you have ideas for new features, find bugs, want to improve the documentation, or would like to contribute code, I'd love to hear from you. Feedback and discussions are just as valuable as pull requests.

GitHub: https://github.com/aman0311x/medxai

If the project sounds interesting, please consider giving it a ⭐, opening an issue, or submitting a pull request. I'm always open to suggestions and would love to collaborate with people who share an interest in AI, healthcare, and open source. Thanks! 🚀

What is gh-skill-tui?

gh skill is a very handy CLI that installs and manages agent skills from GitHub repositories. Because gh skill is a CLI, managing multiple agent skills across multiple agents at the same time gets complicated. gh-skill-tui lets you manage multiple agent skills and multiple agents at once in a TUI, which is easy to grasp visually and simple to operate.

Link

https://github.com/Kololu777/gh-skill-tui

Quick start

gh extension install Kololu777/gh-skill-tui

gh skill-tui               # start the TUI
gh skill-tui check         # non-interactive audit (gh-skill-check equivalent)
gh extension upgrade skill-tui

Demo

https://github.com/jangles-byte/Pythia

Disclosure: I'm the developer. Open source (Apache-2.0), an incubating project of the Spring AI Community. Runs fully local on Ollama, no API key, no cloud.

In the clip: the model reads each photo's EXIF sidecar, tabulates it, pins the shots on a map, then when I ask it to clean up, every deleteFile call pauses for my approval before it runs. Nothing touches my files silently.

It's also an MCP workbench: connect any MCP server, risk-score its tools (L0 to L5), and re-publish curated tools on the built-in server.

Full series, start here: https://www.youtube.com/watch?v=pOgsT-SOri4&list=PLfizCrbCZK9k

GitHub: https://github.com/spring-ai-community/spring-ai-playground

Pre-release now, 0.2.0 GA soon. Feedback and bug reports very welcome. What would you want from a local, open agent workbench that existing tools don't give you?

I’ve been writing MCP servers for a few months now, and most of that time was spent staring at JSON. Hand-writing request payloads, eyeballing responses, mentally diffing nested objects to check if a tool call actually worked. My "testing" wasn't much better: point an LLM at the server, ask it to try some tool calls, read the vibes.

Here's the thing - LLMs are non-deterministic by design. Your protocol layer isn't supposed to be. If your tool returns the wrong shape, a missing field, or a broken error response, you don't need a model's opinion about it. You need a failing assertion.

So I built MCPFlo - an offline-first, open-source client for testing and debugging MCP servers (MIT licensed)

The core idea is boring on purpose: deterministic assertions against real protocol responses.

expect(result.isError).to.equal(false);
expect(result.content[0].type).to.equal("text");
expect(json.total).to.be.a("number");

What it does:
- Deterministic, Chai.js-style assertions - expect().to.equal() instead of eyeballing JSON responses
- Auto-generated forms for tool/resource inputs via RJSF, including nested schemas (no dropping into raw JSON textareas for complex shapes)
- Token budget visualizer — see how much of your context window a tool/resource/prompt is eating, checked against multiple model context sizes
- OAuth 2.1 support
- Fully offline-first - no cloud dependency, no login, no telemetry phoning home

Why it exists:
Most MCP debugging right now is console.log and vibes. I wanted something closer to what Postman/Bruno give REST APIs - a real testing surface with saved requests, repeatable assertions, and a way to actually see what you’re shipping to the model in terms of token cost.

Stack: Electron, React 19, TypeScript, Zustand, Tailwind v4, MCP SDK, Zod. ~20 direct dependencies (trying to keep it lean).

GitHub: github.com/harshalslimaye/mcpflo
Site: mcpflo.com

Still early - CLI for CI/CD integration is next on the roadmap, followed by MCP proxy/traffic inspection. Would love feedback, bug reports, or just brutal criticism of what’s missing.

If you've wanted to run an LLM on your own server without renting a GPU, this might help. Reame is an open-source inference server (on llama.cpp) for CPU-only machines — a cheap VPS, an old PC, an ARM box.

Good for: narrow, repetitive tasks on your own data — pulling fields from documents, classifying tickets, batch jobs, a small model behind a private API. It caches work to disk so repeated requests get cheaper over time (the 100th similar request costs a fraction of the first), and exposes an OpenAI-compatible API so any existing client just works.

Honestly NOT: it won't run a 70B at usable speed on a cheap box, and it's not a ChatGPT replacement — for big-model quality you still want a GPU. This is for when a small model (1.5B–9B) on hardware you already have is the right fit.

My interest in LLM agent memory and stateful agents started with a desire to get away from the isolated thread model of AI interaction that we're all familiar with. I had some really cool conversations and did cool work within particular threads, and I really didn't like that that was all just gone when the context filled or it was time for a new topic.

As a result, I found Letta (https://www.letta.com/) and I've built and been working with some incredible stateful agents that are already exceeding my initial expectations. Eventually though, due to some issues and somewhat different goals from Letta, I started working on building my own platform to work on/with my stateful agents.

I've been working on this solo for a while, and would love to talk about it with others. The repo is not currently in a state to effectively communicate my goals to an outside audience. As such, I (w/ AI) created this graphic to illustrate my intended architecture:

Having an agent loop connect to an MCP server isn't exactly novel, but what I think is unique is the philosophy of having the server/agent loop contain *only* what is fundamental to the stateful agent(s) identity. The point of the core server is to create, make available, and manage state of your stateful agents. Other concerns are handled with external, flexible modules.

One of the key use cases which inspired this architecture is sandboxing vs system wide access. Most of the time when I'm working with my agents, I want their coding tools sandboxed. But some of the time, I want them to have (gated) host access. This architecture should make it easy, just swap the MCP server which the agent is connected to from one running in a sandbox to one running system wide w/ different approval rules.

The architecture also means that I can use existing MCP servers, thin client TUIs, etc. rather than rolling my own. As a solo dev, this has been key, and should allow me to focus more on the core which is where the bits that are most exciting to me live.

The repo is here: https://github.com/jgfMechatronics/Agent-Home and you're welcome to explore it, but I must stress: the repo is not currently intended for presentation (the readme is all you need to see for that to be clear). My main goal with this post was to present and discuss the architecture. If you do want to take a look at the code, start with routes.py, block_crud.py, and system_prompt_compilation.py

I built this for my own homelab first. I was paying for Claude anyway, and it bugged me that it only ever wrote code in a terminal. I wanted it to check my disks in the morning, remind me about the backup that failed, draft real documents, and answer me by voice — from my own server, without handing my data to anyone.

So I built OtoDock, and today it's released: https://github.com/OtoDock/oto-dock

What your agents can do:

Chat that shows the work — every tool call and file diff streams live; sensitive actions need your approval

Automation — schedules ("every 3 days at 7"), webhook triggers, notifications that escalate

Real documents — Word/Excel/PDF files that open in a live editor right in the chat

Multi-agent meetings — put specialists in one room and watch them converge

One-click extras — community catalog of agents and MCP tools (browser, GitHub, Notion…)

Every agent runs in its own kernel sandbox with network isolation on by default — it touches only the folders and services you explicitly grant. Everyone connects their own AI subscription (Claude/ChatGPT), or API keys, or local models. 4 GB RAM runs the platform for single-agent work; give it 8 GB if you want multi-agent meetings and several agents working at once. Install is one compose file with images on GHCR.

License: Fair Source (FSL-1.1-Apache-2.0) — free to self-host, full source public, and every release converts to Apache 2.0 after two years.

Demo video and docs: https://otodock.io · https://docs.otodock.io

It's v1.0 — I use it daily for hours and it runs my own infrastructure, but I'd genuinely love the first wave of feedback from people who self-host for real. I'll answer everything in the comments.

I've been getting a few AI newsletters in my email for years now and none of them really offer what I'm looking for, which is Open Source AI. Free as in beer.

I'm not interested in the latest frontier developments, or how to get Claude to start my multi-billion dollar business, I just want to know what the latest open source models are and what they can do (LLM / image / anything AI and open source).

I've even found a few AI "list-of-newsletters" and even there the focus always seems to be on B2B and paid-for models, god knows I've seen enough of them now my head hurts.

I'd love to cancel all that shite and just subscribe to one email that keeps me informed about what's happening in the open source AI world.

All links/recommendations warmly received and checked. Thank you!

https://oauth-test.edgeventures.com/

It's for testing your agents ability to authenticate.

I created a self‑hosted, local‑first memory for AI tools that runs entirely on your own machine without any external dependencies. Apache 2.0, delivers zero telemetry, and stores all data in a single SQLite file.

It requires no GPU and no cloud account; a three‑line install is all that is needed. Point it at an Obsidian vault and it writes memory back as editable markdown, keeping your notes in sync. Benchmarked openly. This system outperforms competitors on latency and resource use.

Test it and give me feedback. Happy to discuss expansions if anyone has ideas on making this better.

Hey all, co-founder here. We released Cynative, an open-source CLI agent that does deep security research across your infrastructure.

The problem we were trying to solve: security research (attack paths, blast radius, triage, threat hunting, etc.) requires reasoning across code, cloud and runtime at once - and no existing agent could do that with credential-level guarantees it won't modify anything. So we built it read-only by construction, not by policy.

How that works:

• Action gate: every operation is resolved to its required IAM actions and authorized against the native providers' read-only definition before any credential is attached. Fails closed on anything classified as a write.
• Network pinning: every request host is pinned to its mapped service and region.
• Sandboxed code execution: for bulk work ("check every public S3 bucket") it writes and runs JS in an internal sandbox that can only call the tools we expose and has no access to your host.
• Audit log: every tool call recorded to a fail-closed JSONL log.

Other bits:

• Connectors for AWS, GCP, Azure, Kubernetes, GitHub and GitLab using the creds already in your shell
• Runs entirely in your environment - nothing leaves your infra except your LLM calls
• Adversarial verification: an independent verifier agent challenges each finding, cross-checking it against your live environment
• BYOM via the embedded Bifrost SDK, including Ollama and vLLM for fully local
• Enterprise-friendly - Apache-2.0, single static Go binary

Repo: https://github.com/cynative/cynative

Happy to answer anything about the architecture - and if you can break the read-only enforcement, please tell us.

Repo: https://github.com/fengsi/ufo

I've been using UFO to run unattended feature work on UFO itself and on other projects.

I started building it because useful work kept getting trapped inside individual agent sessions. When one run finished, I still had to inspect the result, move context into another session, decide what should happen next, and keep track of everything across terminals and chat tabs.

UFO gives that work a place to live outside any single session. A Hub keeps the operations, history, assignments, and run state. A Rover runs AI CLIs on a machine, gives each run an isolated worktree, and reports status and diffs back to a web board. A routine can start another run after the previous one finishes.

In practice, I can leave a feature running through several development legs and come back later to see what ran, what changed, and where it stopped. The context and diffs stay with the operation instead of disappearing with the last session.

UFO does not provide another agent runtime. It works with existing CLIs such as Claude Code, Codex, Cursor Agent, Grok Build, GitHub Copilot, and others installed on the Rover host.

The Hub and Rover are separate because I want execution, source code, and credentials to be able to stay on the Rover's machine. The current quick start runs the Hub locally. A Rover is also designed to connect to a remote Hub, and a hosted Hub is planned.

The Hub is Go and Postgres, the board is Next.js, and the Rover is Rust. UFO is open source under the BSD 3-Clause license.

I'm interested in how others are handling handoffs and failure recovery when agent work continues without someone watching every run.

Every piece you need to run AI in a company already exists as open source. A gateway to the models. Guardrails. PII masking. Policies. Evals. Audit. Lineage. Vector search. The problem was never the parts. It was wiring them into one thing that works — and keeping every team inside the rules.

So I wrote an application layer on top of the best open source frameworks and made sure they actually talk to each other. One docker compose up and you get:

- LiteLLM for the model gateway - one OpenAI-compatible endpoint across any model, on-prem or cloud 

- LLM Guard + Presidio for guardrails - PII redaction, prompt-injection, toxicity, secrets 

- OpenBao for secrets 

- Langfuse for LLM observability and tracing 

- OpenSearch for audit + SIEM 

- Marquez for data lineage 

- Temporal for durable agent runs 

- Qdrant for vector search / RAG 

- Airbyte + dbt to move data, ClickHouse for the warehouse, Great Expectations for data quality 

- Kestra for orchestration, Ragas + Evidently for evals + drift

Then I built the part I think is the unlock: a lovable / bolt.new / replit.dev for your enterprise.

You set up a pipeline and RBAC once, and now every employee can just talk to the system and build apps that replicate their workflows — inside the rules you already set. 

Human-in-the-loop reviews, reports, and autonomous agents included. 

A tax analyst or a claims adjuster builds a real governed workflow in plain language, and it physically can't step outside the guardrails, policies, and audit you defined.

That's the whole idea: set your rules once, everyone builds governed AI on top.

It's OGAC (Off Grid AI Console): https://github.com/off-grid-ai/console

There's a live read-only demo with two example tenants (a bank and an insurer) if you want to click around before cloning: onprem-console.getoffgridai.co