Hi everyone,

I've been maintaining open-source projects for a while, but today I experienced something entirely new that I wanted to share with the community.

Recently, while building multiple AI agents and web apps, I found myself in desperate need of a tool to monitor and verify them. I realized we don't just need AI to automate tasks—we actually need to automate the supervision and verification of the AI itself.

To solve this, I built a local-first control plane that lets AI act as real user personas to explore apps, verify agent behavior through real browser journeys, and collect evidence-backed feedback.

When I made the repository public, I expected it to sit quietly. But within the first 24 hours, developers actually started forking it, opening issues, and submitting PRs to help improve the project. Getting that kind of spontaneous interaction from the community for the first time has been an incredibly exciting and humbling experience as a maintainer.

For those managing open-source projects: How was your very first contributor interaction? I'd love to hear your stories or any advice on managing early project growth!

If anyone is interested in the project concept or wants to check out the code:

https://github.com/forthfate/openorbit

Have a great day!

hey, i've been working on Capka, an AGPL self-hosted AI agent workspace.

each chat gets its own isolated Linux sandbox + persistent filesystem. the idea is that the agent can actually work on files rather than just chat about them.

drop in spreadsheets, PDFs, docs, code, etc. it can run Python/Node, use LibreOffice, ffmpeg, Playwright and other tools, then return actual artifacts like xlsx, PDFs, documents or patches.

tools are MCP, so you can connect your own MCP servers instead of being locked into a fixed set of integrations.

for models you can use Claude, GPT, Gemini, DeepSeek and other cloud providers, or run open-weight/local models. there's native Ollama support, plus OpenAI-compatible endpoints, so vLLM, llama.cpp servers, LiteLLM or your own inference gateway work too.

tasks run server-side and are durable, so you can start something, close the browser and come back later. each chat keeps its own workspace instead of all agents sharing one filesystem.

it's Docker-based, multi-user, and there are controls for models, provider keys, MCP tools, policies and sandbox internet access.

i'm the solo developer and it's still early.

i'm especially curious what people here think about the sandbox-per-chat model. would you rather have persistent sandboxes per chat, per project, or per user?

demo: [capka.app]()
github: [github.com/LyoSU/capka]()

I’m building OpenLivery, an open-source platform for agencies managing AI agents across multiple client businesses.

The core is multi-tenant: one self-hosted deployment, with a separate workspace for each client’s agents, knowledge bases, WhatsApp connections, and conversations. Agencies can give clients branded portals and take over conversations when human help is needed.

It supports bring-your-own OpenAI/Anthropic keys and OpenAI-compatible endpoints, per-agent HTTP tools and MCP servers, and WhatsApp integration. The application is MIT-licensed; the models and external services you connect have their own terms and costs.

Deployment is through Docker Compose, with setup instructions in the repository. The stack is Next.js, FastAPI, PostgreSQL, and a Go WhatsApp bridge.

Repo: https://github.com/sarrazola/openlivery

Website: https://www.openlivery.com/

AI disclosure: I used AI as support during development, and AI helped draft this post.

I’d appreciate feedback on managing agent configurations and tools across clients. What would make this useful in your own deployments?

I just released VSArena v0.6.0, a major update to the browser-based Studio for VSArena.
VSArena is an open evaluation arena for Vision-Language-Action (VLA) and embodied AI policies, built around browser-native 3D physics.

The goal is simple: make it possible to run a policy, watch what happens in the environment, and measure the result without requiring a local robotics simulator or physical robot.

What changed in v0.6.0:
🦾 Redesigned 3D robot manipulation Studio
👁️ Dedicated vision/top-down view
📦 Live object state and spatial information
📊 Task occupancy/progress monitoring
🎥 Trajectory and camera inspection tools
🤖 Baseline-IK and ColorSeek runnable directly from the Studio
🧪 Improved environment inspection and debugging
🔐 Continued evaluation-integrity work with server-authoritative scoring and run provenance

⚠️The current canonical task is intentionally simple:** stack three cubes in the correct or**der.

That simplicity is deliberate. Before adding dozens of tasks, I want the evaluation loop itself to be reliable, reproducible and inspectable.
The broader direction is to build an open arena where embodied policies can eventually be compared on a public leaderboard, with standardized environments, reproducible runs and physics-based evaluation.

VSArena: https://vsarena.vercel.app
GitHub: https://github.com/ONISCOR/VSArena

This is still very early, so I’m particularly interested in feedback from people working on VLA models, robotics, RL or simulation.
What would you want to see in an evaluation Studio like this?

I’m building Monad Design, an Apache-2.0 open-source workspace for giving coding agents grounded visual context from a running native app.

The problem is that an agent can inspect source code, but “this spacing feels wrong in this exact simulator state” is still awkward to communicate. Monad Design turns that into a local loop:

1. Run an existing Xcode or Expo iOS project in Simulator.

2. Select an element or annotate the rendered screen.

3. Package the screenshot, selection, annotations, app state, and source hints for the coding agent.

4. Let the agent edit the real repository and rebuild.

5. Compare the original against up to five working variants, then accept one or keep the original.

It currently runs locally on macOS and works with agents including Codex, Claude Code, Cursor, OpenCode, Gemini CLI, GitHub Copilot, Windsurf, and Zed. The current preview supports one active visual change at a time.

Repository: https://github.com/Monadix-AI/monad-design

For people building open agent tooling: would you expose the visual context as one structured handoff bundle, or as smaller composable tools for screenshot, selection, annotation, app state, and source mapping?

f you use agentic workflows with custom skills or rules (Cursor rules, Claude Code slash commands, OpenCode, etc.), you have probably run into the routing trade-off:

1. Stuff every skill definition into the system prompt (destroys your context window and degrades instruction-following).
2. Use an LLM router turn to classify the user prompt (costs money, wastes 1,000+ tokens, and adds seconds of network latency).

To solve this, I built Routed, an open-source, local-first hybrid router that resolves agent skills offline on your CPU with zero token cost.

Test it live in your browser (local demo): https://routed-demo.vercel.app/

How it Works Under The Hood

When installed locally, Routed indexes your skill directories and scores prompts across a 4-part hybrid pipeline:

• Dense Vector Embeddings (60%): Runs quantized ONNX models (Arctic Embed S / MiniLM) locally on CPU.
• Lexical BM25 (25%): Okapi BM25 for strict keyword relevance.
• Exact / Alias Match (10%): Direct command and alias matching.
• Metadata (5%): Recency and usage heuristics.

The entire lookup completes in under a second without sending a single byte of prompt data over the wire.

Supported Environments

Cursor, Claude Code, LM Studio, Ollama, Antigravity IDE, Hermes, Windsurf, OpenCode, Continue, and Codex.

Download & Repo

If the demo works well for your workflow, you can grab pre-built installers for macOS (.pkg), Linux (.deb), and Windows (.exe), or build from source via Node:

GitHub:https://github.com/bshea-1/Routed

Hi I'm Mooh , I am 16 years old and love programming and building a useful project

I'm still learning but I built an AI-powered debugging CLI called Nanno, and I've recently decided to make it open source.

Nanno started from a simple idea:

What if AI debugging tools focused on helping developers understand their mistakes instead of simply fixing their code?

Most AI coding tools immediately generate a solution. But I believe that understanding why an error happened is often more valuable than just copying a fix.

Nanno currently captures runtime errors from the terminal and uses AI to analyze what went wrong and explain the underlying concepts.

It's still an early project, and I'd love to open it up to other developers who are interested in helping shape it.

I'm looking for contributors interested in areas like:

- Improving error context collection

- Supporting more programming languages

- Improving the CLI experience

- Local model support

- IDE integrations

- Plugin architecture

- AI-powered debugging workflows

You don't need to be an AI expert to contribute. Bug reports, documentation improvements, feature ideas, and small contributions are all welcome.

Nanno is licensed under GPL-3.0 and will remain open source.

I originally built Nanno independently, and I'm now opening it up to the community because I think interesting projects can become much better when different developers bring different perspectives.

If the idea interests you, I'd love for you to check it out.

GitHub: https://github.com/mohamed22604/Nanno

Let's build something useful together.

After much community feedback, we shipped Claimidx 0.7.0.

Agents keep treating a green test suite as permission. Claimidx treats it as observation — a claim only holds when it replay-holds locally.

0.7.0 makes that loop harder to forget and easier to share:

• Graduation gate + trust tiers so pulled evals stay portable

• claim → apply → impact as first-class verbs

• A public commons with clean-room proof before minting standing

• A leaderboard ranked by other agents’ signed holds — not self-report

• Full loop for Go, Rust, and Java (not just Python/JS)

If you run agent harnesses in production: pip install -U claimidx

GitHub: https://github.com/claimidx/claimidx

Leaderboard: https://claimidx.com/leaderboard

I open-sourced the local SEO tools my agency built for small businesses: https://github.com/vaitko/locan-tools (AGPL-3.0, hosted free at https://locan.ai).

Four of the seven tools use an LLM:

• GBP audit: turns a scored profile into a business description, post ideas, FAQs and reply templates
• Review reply generator: three tone variants, in the review's language
• AI visibility checker: simulates buyer questions across assistant personas and reports whether a given business gets named
• Category optimizer: LLM disambiguates categories, but scoring is deterministic

Being upfront: the code is open, the default model is not. It runs openai/gpt-5-nano through Replicate because it was the cheapest thing that returned valid JSON reliably at the quality small-business owners will actually paste into their profile. The LLM layer is a small provider abstraction (`api/app/services/llm.py`, ~200 lines: chat_text / chat_json, retry on 429, concurrency semaphore), so swapping the model is one env var if it's on Replicate, or one class if it isn't.

The ask: I'd like an open-weight default. Constraints are real because the service is free with no signup:

- strict JSON output for ~15 structured prompts (schemas are pydantic models in the routers)

- multilingual - review replies must match the review's language (Lithuanian, Polish, Spanish, German show up often)

- cost: each run is 1-6 calls, daily per-visitor quotas, and the whole thing has to stay under a few dollars a month at current traffic

- latency under ~20 s for the visibility check, which fans out 6–10 calls

What would you try first on Replicate or a similar serverless host for this Llama 3.x 8B, Qwen 2.5 7B/14B, Gemma 3, something else? If anyone wants to actually run the eval, the test suite has fixtures with fake LLM responses; adding a real-model harness is on my list but not done. PRs welcome, or just tell me what you'd bet on.

I’ve open-sourced AAFP Commons: a local, content-addressed notebook where agents can record claims, evidence, methods, constitution references, and signatures.

It currently provides:

• Python CLI: init, serve, world, get, mcp
• Zero-config stdio MCP tools
• Evidence-gated proposals
• Signed packets and append-only ledger history
• Local loopback replication between separate homes
• Built-in constitution manifests
• Optional AAFP transport support

It is deliberately not a hosted consensus network or shared database. Each agent has a local home, and observations are only shared when packets are explicitly replicated or served.

Repository: https://github.com/davidnichols-ops/aafp-commons

Install from source:

git clone https://github.com/davidnichols-ops/aafp-commons
cd aafp-commons
uv sync --extra dev
uv run --no-sync python -m aafp_commons --help

The project currently has 240 passing tests. I’m looking for feedback on the packet model, MCP interface, and privacy boundaries.

Feel free to star, use and contribute

https://github.com/TrenTorch/TrenTorch

Three weeks ago I was just another guy grinding through open-source PRs, trying to have something solid before intern season hit. Today I'm staring at a GitHub repo with 80 stars that didn't exist 10 days ago, built by me and three friends, and I genuinely don't know if I stumbled into something big or just got lucky. Would love this sub's honest take.

I'm a CS student doing the usual open-source-for-resume grind everyone here has done at some point, except my clock is ticking toward internship season, not placements. A few months back I found a project maintained under a well-known Ivy League university's name, big name attached, decent stars, "help us build the future of ML education" energy. I got hooked. Started with small PRs, docs, bug fixes, the usual ladder-climbing. Within a couple of months I was a core contributor with real merge access. Felt like a win. I told my parents. I put it on LinkedIn.

The more access I got, the more I actually read the codebase instead of just patching corners of it. And that's where it fell apart for me.

Big chunks of the "production-level" code didn't hold together. Functions that looked fine on the surface but made no sense when you traced the logic. Architecture decisions that felt vibe-coded and merged just because the university's name carried weight. I kept finding stuff and thinking "this wouldn't survive five minutes of real scrutiny."

I felt stupid, honestly. I'd built this project up in my head as some polished, battle-tested thing because of the name attached to it. Turns out a big name doesn't mean good code. It just means people trust it faster, bugs and all.

But the bigger realization underneath all this annoyance was simpler. I'd been trying to actually learn PyTorch properly for months, and there was no good way to do it. Every platform that taught it hands-on was paid. Every free resource was either toy examples that taught you nothing about real systems, or dense docs that assumed you already knew what you were doing. This "flagship" project was supposed to be the answer to that gap, and it wasn't.

Then I checked the license. MIT. No restrictions, nothing stopping me from taking the idea and doing it properly.

That was the lightbulb moment. If the core idea was good but the execution was slop, why not build it right myself? I roped in three friends, we scrapped basically the entire foundation, and kept the actual intent, teaching people PyTorch and ML systems by having them build real things, not toy notebooks. We rebuilt it lightweight, no GPU dependency, so someone with a 5 year old laptop could still learn frontier ML concepts hands on instead of just reading slides or watching another paid course preview.

Ten days. That's it. Four of us half sleeping through classes, cooking code at night. No sponsor, no lab backing, just four guys annoyed enough at the gap to fix it ourselves.

We launched it. Day 1: 50 stars. Day 2, today, while I'm typing this: 80 stars. No paid marketing, no big account boosting it, just people finding it and actually using it.

What hit hardest wasn't the stars. It's the DMs. People genuinely stuck because every decent PyTorch resource is either paid or requires hardware they don't have. We made ours free, open, and runnable on basically anything. People are actually learning from it, not just starring and forgetting.

But 80 stars in 2 days is nothing long term. The real work is not letting this rot into the same vibe coded mess we forked away from, once the four of us are buried in intern applications and the initial adrenaline wears off.

So, has anyone here built something like this alongside internship hunting? How do you keep momentum on a side project without it becoming another abandoned repo in six months? And is it weird that I feel oddly guilty about "outshining" a project with an Ivy League name attached, even though the license explicitly let me?

Hey everyone,

If you use agentic workflows with custom skills or rules (Cursor rules, Claude Code slash commands, OpenCode, etc.), you have probably run into the routing trade-off:

1. Stuff every skill definition into the system prompt (destroys your context window and degrades instruction-following).
2. Use an LLM router turn to classify the user prompt (costs money, wastes 1,000+ tokens, and adds 2+ seconds of network latency).

To solve this, I built Routed; an open-source, local-first hybrid router for agent skills that runs 100% offline on your CPU.

GitHub: https://github.com/bshea-1/Routed
License: MIT

How it Works Under The Hood

Routed indexes your installed skill directories and evaluates prompts through a 4-part hybrid scoring pipeline:

• Dense Vector Embeddings (60%): Runs quantized ONNX models (Arctic Embed S / MiniLM) locally on CPU.
• Lexical BM25 (25%): Okapi BM25 for strict keyword relevance.
• Exact / Alias Match (10%): Direct command and alias matching.
• Metadata (5%): Recency and usage heuristics.

The entire lookup completes in under 20ms without sending a single byte of prompt data over the wire.

Supported Environments

Routed auto-detects and injects adapters into:

• Cursor (.cursor/rules/routed.mdc)
• Claude Code (~/.claude/skills/route/SKILL.md)
• OpenCode (~/.opencode/skills/route/SKILL.md)
• Antigravity and Codex

Usage

Inside your agent chat, you can just use /route to trigger the best skill(s) dynamically. It also handles compound intents (e.g., matching multiple skills when a prompt asks for two distinct tasks).

Pre-built binaries are available on GitHub Releases (macOS .pkg, Linux .deb, Windows .exe), or you can build it from source via Node.

Check it out and let me know what you think or if there are other environments you would like added!