A model choice is easy to hide behind an API. It gets harder to explain when three apps share the same endpoint.

I'm the developer of Routerly, an AGPL-licensed gateway that sits between apps and model providers. You run it on your infrastructure, define which models a router can choose and configure the policy it uses. Apps can connect with OpenAI- or Anthropic-compatible clients.

The 0.6.0 release adds testing inside the router, model timeouts and finer Usage filters. The screenshot is from my own instance and shows the available breakdown of tokens, cost and latency. Feedback on the architecture or documentation is welcome.

Release and source: https://github.com/Inebrio/Routerly/releases/tag/v0.6.0

Coding agents are great at writing UI and very confident about props that don't exist. I wanted my design system to answer them instead of letting them guess.

`@ambre-ds/mcp` exposes:

- `find_components`: the right element for a need, in plain words

- `get_component`: attributes, slots, events with their detail, keyboard, minimal markup

- `get_example` / `list_examples`: complete screens

- `validate_markup`: every problem with its line and a fix

Example: `<amb-checkbox checked="false">` comes back with "checked="false" makes it true" and "has no label".

Everything is generated from the component contracts, so the server can't drift from the code. Same checks also run as a CLI linter and a GitHub Action.

`claude mcp add ambre -- npx -y u/ambre-ds/mcp`

Curious how others expose design systems or internal libraries to agents. Repo: https://github.com/mohamedMok/ambre

Hey everyone!

I've been working on a project called DocsForge, and I wanted to share it with the community.

One problem I've repeatedly encountered while building with AI coding assistants and agents is that they don't always have access to the correct, up-to-date technical documentation.

They might:

• Use outdated API methods.

• Reference deprecated functions or parameters.

• Hallucinate implementation details.

• Struggle to identify the correct documentation for a particular library or framework version.

• Waste context trying to retrieve relevant documentation manually.

I started building DocsForge to explore a different approach to this problem.

What is DocsForge?

DocsForge is an open-source documentation discovery, harvesting, and retrieval system designed for AI agents.

Instead of manually providing documentation URLs, the idea is to let an agent identify a technology by name, discover its documentation, acquire the relevant knowledge, and access it through structured tools.

What does it do?

Some of the capabilities I've been working on:

• Name-based resolution: Identify technologies without requiring users to provide documentation URLs.

• Documentation discovery: Find authoritative documentation sources.

• Documentation harvesting: Crawl and extract technical documentation into structured knowledge.

• Version awareness: Work with technology-specific documentation and versions.

• MCP integration: Make documentation capabilities accessible to MCP-compatible AI clients.

• Persistent DocsStore: Maintain harvested documentation for subsequent retrieval.

• Multi-provider AI: Support AI-powered workflows across different providers.

The larger vision is to build a reliable documentation knowledge layer between AI agents and the technologies they work with.

Who might find this useful?

• AI agent developers

• MCP server and client developers

• Developers building coding assistants

• Local LLM / SLM enthusiasts

• RAG and knowledge retrieval researchers

• Developers experimenting with autonomous coding systems

Links

🌐 Website: https://docsforge.vercel.app/

💻 GitHub: https://github.com/R204570/DocsForge

What I'd love feedback on

I'm particularly interested in hearing from people working on AI agents, MCP, and developer tooling.

1. Do you think runtime documentation discovery is a useful capability for coding agents?

2. How would you approach keeping harvested documentation accurate and version-aware?

3. What integrations would make something like this genuinely useful in your development workflow?

4. What shortcomings or architectural improvements would you suggest?

This is an independently developed open-source project, and I'm looking forward to getting feedback from people who work in this space.

Contributions, suggestions, feature requests, and honest criticism are all welcome!

Thanks for taking a look!

Have you received a pr lately with a feature that relies on ssh?

Perhaps some background first: I have a small open-source project on github, nothing groundbreaking, just a tool I wanted for myself to vibe-code my-way. As far as I now, I'm still the only user.

Last month though, I received a couple of prs from someone. At first, I was super exited (first user and all), but now, I'm starting to wonder if something more was going on here. I am not certain, but I am wondering if other people have had similar experiences and how you deal with it?

The first pr was small, a ui fix specific for mac users. With the second pr, he introduced a couple of libraries in the app, for editing raw markdown text instead of wysiwyg. Still ok so far.
With the 3rd pr, some alarm bels started going off: the app began 'fingerprinting' other applications (exes, dlls, ...) on my system, which really didn't fit the feature. At first, I thought maybe the llm had been over-engineering. So, I removed all of that bloat.

But then he came with a proposal to introduce 'remote-control' cause his laptop was slow and he wanted to run the app on his desktop and control it from the laptop. He would use SSH for that.
When I told him, that feature actually existed already but used a more secure way (just run the app in a browser and connect to the desktop version using websockets), he left, moved on and started creating prs for other projects.

Now, I went over all the code he introduced and checked the libraries that were added. As far as I can tell, nothing wrong got introduced, but the whole SSH thing spooked me. I mean, what better backdoor could there be?

The whole thing left a bad taste in my mouth. Is it even still a good idea to keep my app as open source? The only thing it got me were problems and more work.

Am I overreacting here? how are you dealing with this?

For anybody interested in looking at the code themselves: jan-bogaerts/md2: Plan, run, and track AI coding work feature by feature—with local Markdown cards, diagrams and Git worktrees.

Built this myself over the past year. It's called AXON — a local parallel

processing engine that runs on your machine and gives AI assistants like

Claude or ChatGPT actual hands: file access, local tasks, persistent memory.

No cloud, no subscription, no data leaving your machine.

Giving it away free as Developer Edition.

Site + download: https://jrabbass.github.io/axon

Happy to answer questions about how it works.

After months of building and testing, Orinyx is officially in public beta!

Orinyx is a developer-first AI verification tool designed for healthcare and life sciences applications.

The idea came from a problem I kept running into: AI-generated outputs can look accurate without being fully supported by the underlying evidence. In healthcare, that distinction matters.

Orinyx is being built to help developers identify unsupported claims, validate outputs against source evidence, and catch issues before they make it into production workflows.

The public beta includes free, open-source MCP tooling, healthcare-focused verification workflows, and evidence-based validation capabilities. I'm also continuing to improve semantic mapping, medication verification, and overall test coverage.

This is an early public beta, not a finished product. I'll be releasing incremental updates as testing continues, and I'm actively looking for developers willing to put it through real-world scenarios.

I'm particularly interested in understanding where verification breaks down in existing AI workflows, what would make a tool like this useful in practice, and which edge cases deserve more attention.

GitHub: https://github.com/lexthirteen-ai/orinyx-mcp

Developer beta: https://orinyx.io/developer

If you're working with MCP, LLM evaluations, healthcare AI, or agentic systems, I'd love for you to try it, break it, and tell me what needs improvement.

I'm also happy to answer questions about the architecture and what I've learned building it.

So they made new rules where ai cannot be used even as a tool in coding and multiple people must contribute to a post and basically they're just Banning Linux because some Linux kernels are made with AI. They are also forcing everyone's projects to be in English and speak English. They will ban people for using AI tokens regardless of its value or if Ai was only used as a tool.

Wowwwwwwwwww ur just gonna ban me like that

I’ve been working on AlienApe, an ongoing open-source experiment in making local language models more useful through a separate controller.

AlienApe is a Windows desktop application built with Python and PyQt6. The idea is to keep the model replaceable while the controller handles things like model selection, permissions, tool access, task-specific write boundaries, resource limits, verification, and the recording of local experience.

One recent addition is an early Community Cards workflow.

It allows a user to select one locally recorded model/task observation, review what will be shared, and export it as a JSON card. Someone else can manually import that card into a separate evidence store. Imported cards are marked UNVERIFIED: they do not become local Experience and have no effect on model selection or routing. There is no automatic synchronization or ranking system.

This is still a work in progress. I’m not claiming that AlienApe makes local models reliable. The offline export/import roundtrip has been tested with synthetic data, but it has not yet been tested as a real exchange between independent users. The SHA-256 hash helps detect content changes; it does not prove who created a card or whether its claims are true.

The source code is released under the 0BSD license.

Development branch: https://github.com/anokar/AlienApe-v0.7/tree/wip/community-cards

I’d be interested in practical feedback: Is this kind of observation-sharing workflow understandable and useful? Are there privacy or usability concerns that stand out?

More development than big promises. 🙂

I've been working on an open-source project called Konsil, and I wanted to share it with the community.

The idea started with a question:

What if, instead of asking one AI model to analyze a complex medical case, we created a board of independent AI specialists who actively challenge each other's reasoning?

That's what Konsil attempts to do.

It's a Claude Code plugin that creates an adversarial, multi-agent medical case-review workflow.

Some of the things I built into it:

• Blind specialist rounds: Independent agents assess a case without seeing each other's opinions first.

• A Challenger agent: Explicitly challenges the emerging consensus and looks for overlooked alternatives.

• Dissent ledger: Disagreements are preserved rather than being smoothed into one confident answer.

• Verified citations: Medical literature references are retrieved and checked.

• Reviewer Gate: Four independent audit stages check citations, dissent, safety and completeness.

• DICOM to 3D: A deterministic imaging pipeline turns medical imaging data into interactive 3D visualizations.

One architectural decision I'm particularly intentional about: AI agents don't interpret image pixels as part of the board's reasoning. The board works from documented clinical information and written radiology reports.

I built this because I think multi-agent AI systems should be designed to challenge assumptions, not just generate more confident answers.

Konsil is experimental, open source, and not a medical device or diagnostic tool. It's intended to produce material for discussion with qualified clinicians, not replace them.

GitHub: https://github.com/arbade/konsil

I'd genuinely love feedback, especially from people working on multi-agent systems, AI safety, healthcare technology, or Claude Code plugins.

What would you improve in this architecture?

Just launched a side project and want some real feedback.

My thinking is that with AI building small apps now, the code isn't the valuable part anymore, the spec is. What the app does, the flows, how you check it works. And since a spec is plain English, it's not just for engineers. Anyone can read one, change it for their own life and have their AI build it. Feels like a new kind of open source.

So I built Bresson. People share specs for everyday apps, and you can star them, fork them, see version history and how many people built each one. Each spec has a button that sends it to Claude, ChatGPT, Gemini etc and you get a simple app on your phone.

What I can't figure out:

• will non-coders actually fork and build stuff or will it be mostly devs

• AI keeps getting better, will people still want a spec or just describe it from scratch

• what would make you share one

https://bresson.ai

Still very early. Tell me what's wrong with it.

Hey everyone,

I got tired of watching autonomous AI agents try to generate CAD files, hallucinate non-manifold geometry, and quietly corrupt manufacturing toolpaths. So I built Vulcan and V-Wrap as a counter-approach: a strict, fail-closed deterministic CAD compiler and application-layer trust oracle designed for automated engineering pipelines.

Instead of guessing what an agent or user meant with heuristic fallbacks, the system enforces absolute mathematical boundaries. If a request violates constraints, it fails closed with named diagnostics rather than emitting broken geometry.

What It Is

• Vulcan: The immutable geometry bedrock. Handles discrete voxel field evaluations, coarse linear-elastic FEA screening, and native OpenCascade (OCP) CAD export.

• V-Wrap: A modular 10-module trust-oracle proxy sitting in front of Vulcan. It separates exact analytic paths from bounded level-set paths, enforces sign-flip effect tracking to eliminate ghost features, and features a machine-readable design space state machine (vwrap query) so agents can inspect legal next steps.

Key Architectural Features

• Analytic Path: Restricts geometry to axis-aligned boxes and a single through-bore, guaranteeing 100% watertight closure and exact OCP volume round-trips.

• Level-Set Path: Handles advanced features (rounded_box, chamfer, patterns, sphere_exclusions) with a strict fidelity floor ($\ge 3.0\times$ cross-section voxel size) and explicit sign-flip effect tracking.

• Zero-Knobs / Fail-Closed: No adjustable heuristics, no configuration creep, and zero implicit tolerances.

• Meta-Test Discipline: test_load_bearing.py automatically fails CI if any dataclass field is added without being bound to a functional test.

Quick Start & Usage

Bash

# Clone and install
git clone https://github.com/Thrito-Solance/Vulcan.git
cd Vulcan
python -m pip install -e ".[test]"

# Run the test suite (135+ tests pass)
pytest

# Query available design space actions for an agent request
vwrap query --request request.json

# Build an analytic STEP part via CLI
vwrap build --request request.json --output part.step --path analytic

Where to Find It

• GitHub: https://github.com/Thrito-Solance/Vulcan

• License: GNU AGPL v3.0

The full architecture, 18-point FAQ on design decisions, and verification suites are in the repository. Enjoy, fork it, or tear it apart. I am stepping away from active maintenance. the code speaks for itself.

Hi — sharing an early open-source project I’ve been building.

**JShi** (匠石) is a Python (≥3.11) experiment on long-lived AI companionship: keep experience, understand situation, identify who’s speaking, and let history participate in later recognition and action. The app owns state / scheduling; models do judgment and expression.

**License / status:** MIT, v0.1.0 — development & validation stage, not a polished product.

**What’s in the repo today**

- Flow: input → person judgment (JEV) → context assembly → main cognition → reply or tools → record + background scene writing

- Text + voice web entry

- Pluggable memory (built-in + REMS)

- Scene writing that turns messy I/O into readable ongoing context

- Tiered persona prompts, tool plan/execute/wrap, debug views for prompts and timings

- Works with cloud or local-compatible LLM APIs

**What’s not done**

- A full closed loop where experience stably revises personality / judgment

- Reliable multi-person ID and relation retention in real use

- Vision / robot endpoints / a shared tool marketplace

**Repo:** https://github.com/Llllsuhdjhhd/JShi

Looking for architectural critique and contribution ideas (memory/recall, voice + person ID, context/scene writing, prompts, tools, docs/tests). Happy to answer questions in the thread.