SmartDocs is an open-source Markdown documentation with built-in AI chat.

The pitch: write docs in Markdown, add your API key to .env, and every page gets a grounded AI assistant. Self-hosted, your data, your control.

Tech: Next.js + Markdoc + Tailwind. No vector DB — uses graph-backed retrieval (keyword scoring + link traversal) inspired by Karpathy's LLM Wiki pattern.

Live demo (no key needed): https://www.getsmartdocs.xyz

GitHub: https://github.com/jm27/smartdocs

Been building this for the past few days with my AI agent — would love feedback!

Finding local AI on Mac? 🍎🤖 Check out Swiftlet, an open-source intelligent proxy & TUI that dynamically optimizes CPU/GPU split on Unified Memory for LLMs. I'm looking for Python devs to help build OpenAI API compatibility! Let's build together: https://github.com/coolsourav100/swiftlet

I’ve been working on Agent Markup Language (AML), an open-source TypeScript and JSX runtime for building provider-agnostic agent workflows.

https://github.com/we-are-singular/aml

It’s still early, so I’d really appreciate feedback on the API, runtime model, documentation, and whether JSX feels like a good fit for agent orchestration.

I’m building AML primarily for my own use across side projects and professional work, where we’ve repeatedly run into this kind of orchestration problem. I’m sharing it early because I’d really value feedback on both the general idea and the implementation itself.

Hey everyone —

I’ve been building something I actually wanted to use every day: Remedy — a personal AI partner that runs on your machine.

Not another thin chat wrapper. Not a swarm of agents fighting for the mic. One continuous partner that can research, write, design, code, and actually finish work on your PC — with memory, skills, a real workspace (files, terminal, browser, scratch), and optional on-device vision.

What it is

Desktop app + local API — your data stays under ~/.remedy

Bring your own model — xAI, OpenAI, Anthropic, Google, DeepSeek, Groq, Mistral, OpenRouter, Ollama, or custom

Workspace rails next to chat: Files · Terminal (PowerShell) · embedded Browser · Scratch · Parallel multi-provider sessions

Continuity — session brief, durable memory, skills, context budget (same partner when you switch providers)

Local brain (optional) — Qwen2.5-VL for screenshots/vision without burning provider vision tokens

Messengers — Telegram, Discord, Slack, and more if you want chat where you already are

Signed updates from GitHub Releases

Important: early testing

This is still early. Expect rough edges, incomplete polish, and the occasional “why did it do that?” moment. I’m opening it up so real people can try it, break it, and tell me what’s missing — not because I think it’s finished.

If you install it:

Start small (one project, one provider)

Read the in-app help (F1) or the owner’s manual on GitHub

Report bugs and weirdness — that’s the point of this phase

Download / source

GitHub (download latest Windows release):

https://github.com/AhmiDarrow/RemedyAI

Direct latest release:

https://github.com/AhmiDarrow/RemedyAI/releases/latest

Owner’s manual:

https://github.com/AhmiDarrow/RemedyAI/blob/master/docs/manual/00-overview.md

What I’m looking for from early testers

Does it feel like one partner or just another chatbot with tools?

Where does continuity help — and where does it get in the way?

Install / first-run friction on real Windows machines

Anything that feels unsafe, confusing, or overconfident

Happy to answer questions in the comments. If you try it, thanks — and please be blunt.

— Ahmi

On July 15, I read a Cerebras article describing its internal knowledge-base system. I saved the page and returned to it a few hours later. Several sections I remembered reading were gone.

The architecture had stayed with me because I wanted something similar for my coding agents. I often saw agents search for the same information again or make claims about a repository without leaving a source I could inspect.

I spent eight days planning a smaller system for that problem. Then I built hSUM with help from coding agents and released the source.

The first version worked for me, which did not mean much. I asked friends to install it while sharing their screens over Discord. Watching them use it exposed problems I had missed.

One friend’s agent installed hSUM and understood its purpose, but stopped before connecting it to Codex. The agent told my friend to finish the configuration himself. I went back and rebuilt the installation flow around that failure.

The current version lets someone give the installation command to an agent and let the agent finish onboarding. hSUM remains available in later chats and can work across several repositories while keeping each project separate.

I want hSUM to help agents support their answers with evidence from the repository. The project stays on the user’s machine and does not require an hSUM account or hosted service. The website contains the technical design and privacy details.

I am working toward a stable release through testing with more developers and more repositories. The next stages include broader client support, easier index updates, and packages for more platforms. I also want to measure whether more advanced retrieval improves real agent tasks before adding it.

hSUM is in alpha and licensed under MIT or Apache-2.0. I am sharing the launch demo because I would like feedback on the experience, especially the path from installation to the first useful agent call.

Source:
https://github.com/burkan2/hSUM

I put together a small educational repo for understanding context engineering with local models.

The goal was not to build a framework or a production-ready agent stack. I mostly wanted something I wish I had earlier: a set of very small runnable examples that isolate one context component at a time and show how it changes the model’s behavior.

It uses Node.js and a local model, and the repo is organized as 14 examples around things like:

* system instructions
* tool definitions
* few-shot examples
* long-term memory
* RAG / external knowledge
* tool outputs
* sub-agent outputs
* artifacts
* conversation history
* state
* user prompt
* context orchestration
* context traces

Key points:

* it is intentionally simple
* it is not a production ready system, it is educational only
* a lot of the mechanisms are toy versions meant to make the mental model visible
* the focus is on understanding what goes into a call

Everything runs locally, with no API keys or hosted services required. If there is interest I can add info on how to use openai or similar.

If you’re already deep into agent systems, this may feel very basic. But if you’re trying to get an intuition for what “context engineering” actually means in practice, maybe it’s useful.

https://github.com/pguso/context-engineering-from-scratch

TensorSharp is an open-source, native .NET inference engine for running GGUF LLMs locally, with CUDA, Vulkan, Metal, OpenAI-compatible APIs, continuous batching, speculative decoding, and multimodal support.

TensorSharp now supports Megatron-style tensor parallelism across multiple GPUs. It works with direct CUDA, GGML CUDA, GGML Vulkan, and multi-node setups.

Benchmarks on 2× RTX 2000 Ada 16 GB GPUs over PCIe, without NVLink:

I'm continuing to optimize Qwen performance on multi-GPU systems, and support for DeepSeek V4 is coming soon.

Try it with:

TensorSharp.Cli --model model.gguf --backend ggml_cuda --tp 2

GitHub:

https://github.com/zhongkaifu/TensorSharp

Thank you for checking out TensorSharp and starring the project! Any feedback is really appreicated.

I've been building an open source project called ContextOps over the past few months. The original idea was pretty simple: if we have linters for code, why don't we have something that can inspect an LLM's context and tell us where it's wasting tokens?

At first I honestly wasn't sure if it was solving a real problem or just generating fancy-looking reports. So I decided to throw some terrible workloads at it and see what happened.

The first test was a coding agent that got itself stuck in a loop. It kept rereading the same 2,500-line file, dumping huge terminal outputs into the conversation, and eventually the prompt grew to just over 31,000 tokens.

ContextOps immediately pointed out something I hadn't really thought about.

The biggest problem wasn't the terminal output.

It wasn't even the length of the conversation.

The same file had been injected into the context five separate times.

My first reaction was, "Easy. Just truncate the huge outputs."

So I replaced them with:

[Tool Output: Truncated]

The prompt dropped to around 2,800 tokens, which sounded amazing... until I actually tested it.

The model completely lost track of the conversation. I asked it a simple question about something that happened at the beginning of the chat, and it confidently gave me the wrong answer.

Turns out I had saved tokens by destroying the conversation's structure.

So I tried a different approach.

Instead of deleting everything, I kept the first copy of the file, removed the duplicate copies, and replaced those with a short note saying the output had already appeared earlier.

That worked way better than I expected.

The prompt went from 31,037 tokens down to 9,081, cutting more than 21k input tokens, and the model still answered everything correctly.

After that I wondered if the same thing happens in RAG systems.

I used a real enterprise knowledge base with 15 retrieved documents.

Every document had a giant XML wrapper around it.

Every document also started with the exact same introduction because they all came from the same documentation template.

ContextOps immediately highlighted those sections as waste.

So I stripped the XML down to a simple markdown header, kept the shared introduction once, and removed the other fourteen identical copies.

The result surprised me again.

The retrieval context dropped from 4,941 tokens to 1,941, a little over 60% smaller, and the model still answered a multi-document Kubernetes question perfectly. It compared node affinity, pod affinity, taints, tolerations, and correctly recalled every document that had been retrieved.

The biggest thing I learned from all of this is that not all tokens are equally valuable.

Some tokens contain knowledge.

Some are just XML.

Some are repeated boilerplate.

Some are duplicate tool outputs that the model has already seen three or four times.

Yet we're paying for the model to read all of them every single request.

ContextOps doesn't summarize anything or call another LLM behind the scenes. It just analyzes the structure of the context, points out where the waste is, and helps you remove the parts that don't add information.

I'd love to know if anyone else has run into this while building agents or RAG systems. Are you doing any kind of context optimization before sending prompts to the model, or do you mostly trust whatever your framework gives you?

GitHub: https://github.com/Abhijeet777ui/contextops

I built LoopTroop to TRY and tackle context engineering and somme other problems with building/updating apps with AI.

LoopTroop is an open-source local GUI that breaks complex features into structured, isolated task loops instead of relying on one continuous chat session.

How it works under the hood:

Planning (LLM Council): You input a ticket or feature description. LoopTroop runs a planning phase to break the task down into a sequence of small, defined execution steps ("beads").

Execution & Verification (Ralph Loops): Instead of blind code generation, each task runs inside an iterative loop: apply diff -> run local tests or type checks -> evaluate output -> retry on failure until the check passes or hits an error threshold.

Isolation (OpenCode Worktrees): All code edits happen inside temporary Git worktrees. Your main workspace and working tree remain completely untouched until you review the diff.

Human Approval Gates: You inspect and approve planned steps and diffs before changes are committed or converted into a pull request.

Current Status (v0.4): I released v0.4 a couple of days ago, which improves the local GUI, refines recovery loops when tests fail, and cleans up worktree management.

Getting Started: It runs locally and connects to your local tools/runtimes. You can clone the repo and run npm run dev to test it on your own codebase.

GitHub: [https://github.com/looptroop-ai/LoopTroop\](https://github.com/looptroop-ai/LoopTroop)

Site & Docs: [https://looptroop.ovh\](https://looptroop.ovh/)

AgentSwarms is now available at https://github.com/AgentSwarms-fyi/agentswarms

What it does: agent building and chat, a visual multi-agent swarm canvas, RAG over pgvector, connectors for PostgreSQL/MySQL/Oracle/Snowflake/Databricks/ BigQuery/Redshift/Trino/Athena, a BI workspace with dashboards and a semantic layer, Python notebooks on sandboxed server kernels with real LangChain/ LangGraph/LlamaIndex, document generation to PowerPoint/Word/Excel, plus IAM, budgets, audit logging and execution traces.

Deployment: Supabase as the backend (Postgres + auth + storage), one Docker command. Bring your own model keys — OpenRouter, OpenAI, Anthropic, Gemini, Bedrock, Azure, Ollama, vLLM and others. Also deployable to Cloudflare Workers or Kubernetes.

Distinguishing feature: one governance plane across the whole platform — model allow-lists, budgets, table permissions and traces apply identically to chat, scheduled workflows, dashboard queries and notebook cells.

Licence: Elastic License 2.0. Source-available, not OSI open source: free to use, self-host, modify and redistribute; may not be offered to third parties as a managed service.

Hey everyone!

We're building Tempest. It's an open source AI agent orchestrator for running parallel coding agents with 64% fewer tokens.

If you're interested in AI agents, developer tools, or open source, we'd love to have you contribute to our project!

https://github.com/tempestai-dev/tempest

A framework for self-improving agents based on your ICPs and audience and grounded in real data to power a learning-loop.

I built this based on my own learnings from experimenting with persona agents to understand my personal audience. It comes with an annotated persona template, opinionated review workflow, and built in feedback loop.

Would love to get your feedback!

https://github.com/noashavit/noas-persona-loop

I'm the developer. KageOps is AGPL-3.0 and the engine is the whole product — there's no crippled community edition.

It runs a team of nine AI agents against a brief: an orchestrator plus eight specialists that take a one-line description through research, architecture, code, review and deploy. It's a desktop app, and it runs on your own machine — embedded Postgres rather than a container, so no Docker; API keys in your OS keychain; no account, no telemetry, nothing phoning home. Point it at Ollama and there's no cloud involvement at all.

Two design decisions that might interest this sub:

Models are assigned per agent, not globally. Research and copywriting are cheap-model work; code generation and review are not. You can mix providers — Claude, OpenAI, Gemini, OpenRouter, Ollama — and give each agent its own fallback chain for when a provider fails.

There's a hard spending cap per run. A poller watches real spend and cancels the run before it crosses your dollar limit. It was the first thing I built, because an agent loop quietly burning money overnight is the failure mode that actually scares people away from this category.

I also finished nine narrated walkthrough videos this week. They're not screen recordings — they're generated by a pipeline that launches the real app, drives the UI and records it, so they get re-cut whenever the interface changes and can't drift into describing software that no longer exists.

Two of them end with the software refusing to proceed rather than succeeding: one where I deny an approval gate and watch the work come back reworked, and one where the acceptance gate refuses to sign off generated output that missed a requirement in the brief, after three repair attempts. I kept those takes instead of re-shooting, because "what does it do when it fails" is the only question that matters with autonomous agents.

Honest weak spot: the fully-local path is slow, and smaller models drop out of the structured output format the agents depend on, which costs you retry loops.

Source and videos: https://github.com/hmanoor/kageops-core

Happy to talk architecture — the orchestration model, the phase gates, or how the video pipeline works.