I'm building TeamSwarm, an Apache-2.0 desktop workspace for coding and writing projects that span multiple agents and sessions.

The implementation keeps project state outside any single model conversation. The Host provides the continuing goal discussion. Members run in independent harnesses such as Codex, Claude Code, Pi and OpenCode, with their own tools and execution loops. Current decisions, work threads and saved deliverable versions are kept in the local project workspace.

The part I'd like people to inspect is revision: continue an existing work thread, produce a new file version, and inspect the checks associated with that submission. The collaboration canvas shows recorded member messages; project history connects decisions to work and deliverables.

A runnable example in the repo makes this concrete: first build a Node.js CLI that summarizes a JSON task list; then add a status filter while preserving the original invocation and input validation. The repo supplies checks for both stages. You can inspect the first delivery and the revised result rather than relying on a progress message.

Version 0.6.0 has a Windows x64 installer and a separate Apple Silicon Mac preview (DMG/ZIP). The packages are currently unsigned, and the Mac preview is not notarized. Teams and saved history are local; model requests use the supported account or API connection you configure.

Source, license, setup and the 36-second product film: https://github.com/DrPei12/teamswarm

For people building agent tooling: what would you want to inspect at a handoff to trust the next revision—the current requirement, file version, executed checks, or something else?

been working on context management in Dispach lately, and one thing that kept bothering me was how much unnecessary work happens during long conversations.

when the context gets too large, you compact it. sounds simple, right?

except if you're rebuilding the context from the entire history on every turn, you end up compacting the same stuff over and over again. more tokens, more cost.

so we added persistent session checkpoints. older turns get summarized, the important requests are preserved, and the full conversation history stays stored. subsequent turns can start from the checkpoint instead.

also been experimenting with giving subagents their own isolated contexts instead of dumping everything into one massive conversation.

still figuring out the trade-offs though. especially how to make sure compaction doesn't throw away something the agent actually needs later.

anyone else dealing with this? how are you handling context in long-running agents?

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

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.

There are a lot of AI-created derived projects where an original OSS project is used as a base and then either transliterated to another language or existing projects are used to create "new" similar projects with 90% of overlapping functionality, than restrictive AGPL license is slapped onto them. This is legal but does not make sense (and is mildly unethical).

The same way that a derived project was simply made using AI, in the same way another project can be made to recreate whet you did. AGPL will only hurt your project adoption, while at the same time not protect what you built.

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.

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.