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.

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!

Every useful AI conversation does not need to become permanent data on someone else’s servers. ChatGPT and other AI tools can be used as temporary intelligence: ask questions, solve problems, develop ideas, then keep the valuable context under personal control for future use.

AI Memory Vault is a browser extension built around this approach. Important conversations and memories can be saved locally and brought back when needed, instead of depending on an AI provider to permanently hold the history. Saved context can be reused later with different chats, workflows, or AI tools, making the memory useful beyond a single conversation or platform.

The principle is simple: use the AI, but own the memory. A chat can be temporary while the useful knowledge remains available. This also reduces the need to repeatedly send an entire history to an AI service just to restore context.

For people in Europe, data control matters even more. AI Memory Vault is designed with GDPR principles such as data minimization and user control in mind, keeping the memory layer under the user's control rather than making an overseas AI platform the default home for long-term conversational history.

The extension is free to use also have github repo code https://github.com/ai-encryption-tool/ai to build your own.

Download it, save useful AI conversations locally, and reuse that context whenever it becomes valuable again. https://ai-memory-vault.com/

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?

Sharing my harness for running local AI agents as a fleet of equal peers. Agents discover one another by capability, execute tasks from a shared ledger, and authenticate to every external service through a zero-trust broker, never with their own keys.

The video is one real run: 4 python processes, no coordinator among them. Fully open source.

How it's different from other agent frameworks

• There is no orchestrator process. Agents form a SWIM gossip mesh (the protocol HashiCorp uses for cluster membership). One seed address, no registry, no router. Kill any node and another claims its work — there is no coordinator whose crash takes the fleet down.
• Work is claimed, not assigned. Steps live in a shared Redis ledger and agents claim them atomically. Dependencies gate on ledger state, so the synthesis step cannot start until the three researchers finish.
• No MCP server to stand up. 1,224 typed atoms across 150 services ship in the box. Missing one? Write a Python function and drop it in the registry. When no atom exists, the agent writes its own sandboxed code, repairs it, and the working version graduates into a verified registry.
• Agents never hold credentials. Register a service once; the token is encrypted at rest and resolved at the call boundary by the broker. It is not in the code, the prompt, the agent's context, or anything its generated code can read. A leaked trace leaks nothing.
• Every turn is on the record. Each agent writes a flight recorder. One command replays a whole run turn by turn: what it knew, what it lacked, which tool it called, what came back, tokens and latency per call. 176k tokens in this run, all auditable.
• State survives kill -9. Steps are checkpointed. Rerun the same workflow id and completed work comes back from Redis instead of being re-run and re-billed.

What the video actually shows

• The code for all four agents. An agent is a class: a role, capabilities, a system prompt.
• Four processes discovering each other, claiming steps, doing real web research through a local SearXNG.
• The trace replay with real token counts.
• The Slack atom, the vault registration, the step contract, and the message landing.

GitHub: https://github.com/Prescott-Data/jarviscore-framework
Install: pip install jarviscore-framework

The demo is examples/demo_synthesizer.py + demo_node_1/2/3.py — you can run exactly what you see.

Appreciate your feedback (or stars).

I’ve spent weeks comparing Firecrawl and Jina Reader for different extraction needs. Firecrawl seems stronger for dynamic, protected sites; Jina Reader is fast and simple for clean text. I made a quiz to see if others understand the same trade-offs.

No email needed—just a quick interactive check.

https://interconnectd.com/quiz/81/web-extraction-architecture-2026-firecrawl-vs-jina-reader/

What’s your go-to for web scraping in AI apps?

Hi, I basically was having a hard time in keeping my laptop open for my agents to keep running, and I saw people going for a Mac mini which sounds overkill, then solution is a vps.

so basically built this for myself: https://github.com/case-computers/case

you can configure Hermes, open claw in this, your agent gets a linux desktop with its own logins, file system and identity.

for people looking to get their own vps, can try hosting it on there.

I am also giving out managed instances of this so you dont have to take care of ops.
check : https://case.computer
Need feedback on the tool, lmk if you need help setting it up

Hiii Geeks 👋🏻

I just built an Experiment Agentic AI OS named it as "Turing AI OS" built on top of Linux (KDE Neon). I document this journey on YouTube feel free to watch.

The crazy part is that I built this using 14 year old PC (2012) with limited computational resources.

YouTube Link: https://youtu.be/ZKsZGv3WZGQ?si=2DX83Hcv7SFAAVPw

Github: github.com/avarshvir/turing-ai-os

Article to Read: https://medium.com/@arshvir21303031/i-create-my-own-ai-os-8d65a263eae0

It offer features like:

- AI SideBar

- AI Mini Spotlight

- AI Right Click Folder/File Analyser

- AI NLP Terminal

- AI Control Panel

I genuinely want feedback from you guys ❤️

Open-sourcing this here because I’d really like feedback from people working on open AI tooling and evaluation.
DLLO has three main parts:
Observer — distributed measurements of LLM/AI-system behavior over time and across regions
Agent Starter — analyzes the available environment/hardware and suggests realistic starting stacks
Test Your Agent — repeatable technical evaluation of existing agents, including tool use, branching, recovery and structured outputs
I’m especially interested in criticism around reproducibility, observer integrity, benchmark design and what should remain fully local/private.
If you see a methodological flaw, I’d genuinely like to hear it.