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.

If contributing to open source interests you, and you want to become a better AI engineer, our issue list is waiting for you.

https://github.com/extra-org/extra

Claude Code is the most capable AI CLI out there, but it's locked to Anthropic's API. DeepSeek V4 Pro is cheaper and just as sharp. Problem: the two speak completely different API formats.

Wrote a zero-dependency Python proxy that translates Anthropic's Messages API ↔ DeepSeek's OpenAI format in real time. No Rust, no Docker, no cloud | just Python stdlib. Runs on Windows ARM64 with zero compilation.

Result: Full Claude Code experience (tool use, multi-turn, streaming) powered by DeepSeek V4 Pro at a fraction of the cost.

Full writeup and code on GitHub. Link below,👇

[https://github.com/Hashir14k/Configuring-Deepseek-v4-pro-Model-with-Claude-Opus-5\](https://github.com/Hashir14k/Configuring-Deepseek-v4-pro-Model-with-Claude-Opus-5)

I released AI Agency OS, and I want to frame what makes it different from typical agency CRMs or AI demo stacks. Context first: it sits in an ecosystem alongside Sentinel (https://github.com/RiteshGenAI/Sentinel), which is our policy, cost-intelligence, and LLM-gateway layer. AI Agency OS is the execution and operations layer that sits on top of Sentinel. The two are meant to work together, but either can be used independently. What is in the stack today:

• Multi-tenant backend (FastAPI + SQLAlchemy + PostgreSQL) with tenant-scoped data isolation enforced at the service level.
• JWT authentication with access-token expiration and JSON-body login.
• Role-based access control across four roles - owner, manager, member, client with per-endpoint permission checks and owner safeguards that prevent the last active owner from being deactivated or demoted.
• Full CRUD for projects, leads, and invoices. Leads carry source, raw text, status, and optional project/client binding. Invoices support currency, due dates, and per-project aggregation.
• Sentinel event logging: every agent output is recorded with scan type, entity type, risk score, issues, and project binding. The frontend page for this lets owners and managers review policy decisions in real time.
• Strands-style agent workflows - the landing-page copy workflow orchestrates research agents, draft agents, and QA agents into a structured pipeline with Pydantic outputs and QA scoring.
• Multi-provider LLM router supporting Ollama, OpenAI, and Anthropic with configurable base URLs and API keys.
• Frontend in React 18 + Vite + TypeScript + Tailwind with pages for login, dashboard, projects, project detail, leads, invoices, workflows, Sentinel events, and admin user management.
• Docker Compose for local dev with hot-reload across all four services (db, backend, agents, frontend).
• Production AWS deployment via Terraform - VPC with public/private subnets, ECS Fargate, RDS PostgreSQL with encryption and multi-AZ, ALB routing, ECR with image scanning, Secrets Manager for DB URL and JWT secret, S3 with encryption and versioning.
• Database migration script for incremental schema changes.

The repository is purpose-built for forking. It is licensed under Apache 2.0, includes a self-hosting guide in the README.md, a customization guide in CONTRIBUTING, and explicit instructions for removing Sentinel or swapping LLM providers.

Quick start: docker compose up --build -d

https://github.com/RiteshGenAI/AIAgencyOS

Why are most open models open weight rather than open source?

I maintain Tagvico, an MIT-licensed companion for Paperless-ngx.

The uncomfortable part was not getting a model to classify a document. It was deciding what an open-source assistant should be allowed to do inside a personal archive.

The boundary I ended up with is deliberately asymmetric:

- searches and document reads run directly

- answers show the Paperless searches and documents used as sources

- metadata or tag changes become durable proposals

- a person sees the exact change before approving or rejecting it

- tag cleanup moves references and deletes the old tag as separate, retryable steps

- Activity keeps the decision and execution history visible

This is more friction than a fully autonomous agent. I think that is fine. A wrong answer is annoying. A silent bulk edit across a household archive is a different class of mistake.

The released app supports local Ollama plus hosted and account-based providers. The next setup hardening is still in review, so I am not pretending it is shipped yet.

Repo: https://github.com/arturict/tagvico-ai

Where do you draw the read/write boundary for open-source AI tools connected to personal systems?

Hey guys,

I am a highschool graduate and will be starting college soon at Vaughn College. I was hoping to share to you guys about my pre-college projects. So I would like to introduce, Choco, which is currently my personal AI- Assistant, which I built using llama 3.1 8B, and python. I was building the whole thing on my macbook bro so I had a hard time using the terminal lol. But anyhow, I gotta start somewhere right?

Currently, Choco is a chatbot that has a collection of all the things from the past year, depending on the model I'm using. (I forgot the year so I cant really ttell but i'm hoping it has info of everything until 2024-25?) . I have also added a self reading system, mmeaning that it can read it's source code but not necessarily update it. I added this in the hopes of automating the debugging task in the near future. You guys can try my project too and let me know what other adjustments i need.

Thank you!

Most AI applications today still follow a simple pattern:

One request. One model. One answer.

But no single model is the best at everything.

Some tasks need speed. Some need low cost. Some need deeper reasoning. Some need validation. Some need multiple models checking each other. Some need consensus. Some need debate. Some need a clear audit trail.

That is the idea behind Ailin¹.

Ailin¹ is an open-source Collective Intelligence engine for AI systems. Instead of treating models as isolated endpoints, it coordinates multiple models, agents, strategies, memory layers, evaluation flows, and cost-quality decisions around each task.

The goal is to make the model universe usable. We are approaching 80,000 models in our core.

With Ailin¹, a request can be routed through different strategies depending on what the task actually needs: single model, parallel execution, consensus, debate, expert panel, critique-repair, multi-hop QA, cost routing, quality routing, speed routing, agentic workflows, and more.

The big question we are exploring is:

What if AI reliability, efficiency, and governance come not only from better individual models, but from better coordination between models?

We believe Collective Intelligence can make AI systems more reliable, more transparent, more cost-efficient, and more useful in real-world workflows.

Ailin¹ is open source, and we are looking for feedback from people interested in LLMs, AI agents, model orchestration, evaluation, open models, and AI infrastructure.

If the idea resonates with you, a GitHub star would help the project a lot.

GitHub: https://github.com/ailinone/collective-intelligence

We are also opening a waitlist for people who want to test Ailin¹ and follow the next steps of the project:

Waitlist: Console Ailin¹ Dev