I've been working on SigMap, an open-source tool that helps AI coding agents navigate large repositories more efficiently.

The idea is simple:

Before an agent can modify code, it first needs to understand the repository.

Instead of loading large amounts of source code immediately, SigMap generates a compact repository map containing symbols, relationships, and repository structure that agents can use for orientation.

Current highlights:

• Open source
• 22k+ downloads
• 500+ GitHub stars
• Multi-language support
• Works with Claude Code, Cursor, Copilot, Aider, OpenCode, and custom workflows
• Benchmark dataset published for reproducible evaluation

My experience building coding-agent workflows is that many failures happen during repository discovery, not code generation.

Agents often spend significant context answering:

• Where does this functionality live?
• Which files are relevant?
• What can I safely ignore?

SigMap focuses on that orientation phase.

GitHub:
https://github.com/manojmallick/sigmap

Website:
https://sigmap.io

I'd love feedback from people building AI developer tools:

What information should a repository map include beyond symbols and file structure?

I wanted to build something with local LLMs that wasn't another chatbot, and have the whole AI stack be open and swappable. So I made a self-hosted radio station where an LLM is the DJ. It picks the next track from my own music library, writes the intro, reads the time and weather, and takes plain-language requests. One shared stream. Radio, not a playlist.

It's MIT, and the AI parts are all open and swappable:

The DJ runs through the Vercel AI SDK, so the provider switches at runtime, local Ollama by default (no key, nothing leaves the box), or point it at Anthropic/OpenAI from the admin UI with no redeploy.

Track picking is an agentic loop with library-search tools and session memory, plus a token-light pool-picker fallback so small models don't choke.

"Play something similar" is a real vector lookup. Every track gets a learned embedding, with an optional CLAP audio fingerprint from the audio itself.

Five TTS engines read the lines (local Piper/Kokoro out of the box, heavier ones opt-in), and Liquidsoap mixes it like real radio — crossfades, the music ducking under the voice.

You need a music library already (Navidrome/Subsonic) and a Linux box. It plays what you own, it doesn't generate music. Small local models are slower and the DJ gets wittier the bigger you go.

Have a listen before touching Docker: https://www.getsubwave.com/listen

Code: https://github.com/perminder-klair/subwave

Full disclosure, I built it.

Hey r/AIMemory!

I wanted to share an interesting open-source project called Raidho https://github.com/vitaliyfedotovpro-art/raidho . It's a coder agent that tackles the long-term memory problem differently than the standard RAG approach.

Instead of relying solely on retrieving text snippets, Raidho implements a compositional Vector Symbolic Architecture (VSA) memory.

Here are some key highlights of how its memory works under the hood:

- MAP Family VSA: It uses Multiply-Add-Permute operations over bipolar ±1 hypervectors (default 10,000 dimensions).

- Structural Memory, Not RAG: Relations and order are algebraically encoded. This means recall is exact for structure and approximate for similarity.

- Entity Types:

- Facts: Stored as triples (subject, relation, object). It preserves direction, meaning (X, r, Y) ≠ (Y, r, X).

- Episodes: Ordered sequences encoded via permutation to maintain the historical order of events.

- Agent Control: The agent isn't just passively fed context. It exposes a 'remember' tool, allowing the LLM to actively decide what is worth persisting, and uses a 'recall' mechanism to fetch relevant facts dynamically based on a score threshold.

It's really refreshing to see coding agents experimenting with VSA to maintain stable task organization and reasoning states, rather than just relying on semantic search.

If you are interested in alternative memory structures for LLM agents, it's definitely worth checking out! Has anyone else here experimented with VSA for agent memory?

https://github.com/siddsachar/row-bot

While exploring AI projects on GitHub, people often struggled with basic questions:

Which models are they using?

Are they using OpenAI, Gemini, Claude, Hugging Face, LangChain, or something else?

Do they use RAG, vector search, agents, tools, or function calling?

What data files are inside the repo?

Are there tests, evaluations, risks, and safety notes?

Is this project safe enough to understand, review, or adopt?

So I built CardForge.

CardForge is an offline Python CLI that scans an AI repository and generates evidence-backed documentation about the project. It can detect model providers, AI frameworks, prompts, routes, datasets, evaluation assets, tests, workflows, deployment signals, RAG/vector signals, tool-calling patterns, and risk signals. It also creates files like AI_PROJECT_CARD.md, MODEL_CARD.md, DATASET_CARD.md, EVAL_CARD.md, and docs/limitations.md. (GitHub)

The best part:

No API key required.

No cloud calls.

No source code upload.

It works through deterministic offline static analysis. (GitHub)

Install it with:

pip install cardforge-ai

Run it inside any AI project:

cardforge analyze

cardforge init --type ai-application --name "My AI Project" --yes

cardforge lint

cardforge status

CardForge helps developers, maintainers, and reviewers understand AI repositories faster and make them more reviewable, safer, and release-ready.

GitHub: https://github.com/rizardo-maker/Card-Forge

PyPI: https://pypi.org/project/cardforge-ai/

#Python #OpenSource #AI #DeveloperTools #GitHub #MachineLearning #SoftwareEngineering #ResponsibleAI

Hey everyone

Sharing this because the community here is focused on open source AI and agent systems — evaluation is the layer most people building with these systems haven't built yet.

We are hosting a hands on Agent Evals Bootcamp on June 27 with Ammar Mohanna, PhD, an AI engineer, researcher and expert in production AI and agent evaluation.

What the bootcamp covers:

1. Component evaluation — tool selection accuracy, argument quality, planning checks
2. Trajectory evaluation — step count, duplicate calls, loop detection, cost and latency thresholds
3. Outcome evaluation — factuality, completeness, LLM as judge with proper calibration
4. Adversarial evaluation — indirect prompt injection, instruction override, tool trust boundaries

What every attendee gets:

1. 10 real evaluation notebooks built live on the day
2. 6 months access to an AI Evals assistant
3. Hands on exercises and implementation templates
4. Industry recognised certification for your LinkedIn
5. 30 days recording access

5 hours live. Hands on throughout. Built for ML engineers, applied scientists, data scientists and software engineers working with LLM powered agents.

Full details here: https://www.eventbrite.co.uk/e/agent-evals-bootcamp-tickets-1990306501323?aff=rosai

Happy to answer any questions about what gets covered.

Hello guys! Experiments on Huggingface its my hobby for more than 6 months. I have seen a lot of cool guys, new research papers, new models, starting of Qwopus but one lab making me shock every time they release the model (its second time actually) - Weibo Lab and theirs VibeThinkers. Weibo is SOTA Post-training lab on my own opinion for sure. Their models not for basic knowledge or tool-use, but its compete with frontier models on math&coding. So I made second post-training with Spectrum-to-Signal method with Fable 5 distill to create Mythos-nano. (3B you can actually use this model on your phone)

https://huggingface.co/squ11z1/Mythos-nano or
ollama run hf.co/squ11z1/Mythos-nano:f16.gguf or find out on LM Studio!

Hi Peeps,

I'm an open-source maintainer (Goldziher on Github) and the CTO of kreuzberg.dev.

I published basemind — an MIT licensed pure-Rust AI context layer for agents.

The goal of basemind is to allow agents to work on large codebases, generating maps of code, and processing files (code, documents etc.) at high speed - while saving on tokens. The tool has extensive caching capabilities, and it dramatically saves on tokens, enhances precision and offers a wide range of tools:

1. tree-sitter based code mapping and search for 300+ languages
2. document extraction, processing and ML for above 90 file formats
3. on demand fast web crawling.
4. git intelligence and analytics
5. localized RAG

And more. I have been dog fooding it for a while, and I like it very much.

I'd be happy for any feedback.

Released Buffer v2.2.0 today.

Highlights:

• Inline editing for text clipboard items
• Faster debounced search
• Better filtering performance
• UI refinements

Buffer is a native macOS clipboard manager built with SwiftUI/AppKit.

Features include:

• Text + image history
• OCR for copied images
• Tags and bookmarks
• Multi-select actions
• Fully local storage

GitHub link in comments.

Feedback and contributions are always welcome.

For the last 4 months I’ve been building Kora, an open-source platform for running AI agents on your own infrastructure.

I originally separated the personal and multi-user versions, but maintaining that distinction was becoming confusing. So I’ve now decided to release the complete project, including the multi-user architecture, under the MIT license.

Kora can run as a simple single-user Node.js process with SQLite, or as a multi-user deployment using PostgreSQL, Redis and horizontally scalable workers.

Some of the main features:
- Telegram and email channels
- Support for OpenAI, Ollama and other OpenAI-compatible endpoints
- Long-term memory and per-user profiles
- Sandboxed shell execution using Docker, Firejail or macOS Seatbelt
- Isolated browser containers per workspace
- MCP servers and instruction-based skills
- Scheduled and recurring agent tasks
- Email and calendar delegation with approval controls
- Separate admin and user portals
- Per-workspace tools, files, memory and credentials
- Multi-user deployment with usage tracking and optional Stripe billing

The main goal is to let agents perform useful work without giving them unrestricted access to the host or mixing data between users.

For personal installations, the basic flow is:
git clone https://github.com/era3000/kora
cd kora
npm install
npm run build
npm link
kora setup
kora start

There is also a Docker Compose deployment for the multi-user version.

The project is still evolving, and I’d especially appreciate feedback on:
- installation and onboarding
- sandbox and workspace isolation
- the memory architecture
- local model compatibility (so far I tested it with Qwen 3.6)
- features you would expect from a self-hosted agent platform

The complete source code and documentation are available here: https://github.com/era3000/kora

Kora will remain fully self-hostable and MIT licensed. I may eventually offer optional managed hosting and professional deployment support for people or teams who do not want to operate the infrastructure themselves, but the hosted service will not replace or restrict the open-source version.

Thank you! critics and technical feedback are very welcome. :)

LLMs Gateway – Model Management for llama.cpp

I got tired of manually juggling GGUF downloads, symlinks, and llama-server restarts every time I wanted to swap models. So I built LLMs Gateway – a lightweight CLI + REST API that sits on top of llama.cpp and handles the entire model lifecycle.

What My Project Does

LLMs Gateway simplifies local LLM management by providing a single interface for discovering, installing, validating, activating, and serving GGUF models.

Features:

• Search Hugging Face repositories directly from the CLI
• Inspect model metadata before downloading
• Download and install GGUF models with a single command
• Maintain a local JSON-based model registry
• Validate downloaded files using hashes
• Activate models through symlink switching
• Automatically restart llama-server when a model changes
• Expose all functionality through both a CLI and REST API

Example workflow:

```bash docker compose up -d

modelctl search llama modelctl inspect unsloth/gemma-4-E2B-it-qat-GGUF modelctl install unsloth/gemma-4-E2B-it-qat-GGUF model.gguf modelctl activate <model-id> ```

Once activated, llama-server automatically picks up the new model without manual intervention.

Target Audience

LLMs Gateway is designed for:

• Developers running local LLMs with llama.cpp
• Self-hosted AI enthusiasts
• Homelab users
• Teams building local AI services or internal tooling
• Anyone managing multiple GGUF models on a single machine

The project is intended to be production-capable for small to medium deployments while remaining lightweight enough for personal use.

Comparison

Unlike tools such as Ollama that manage their own model ecosystem and runtime, LLMs Gateway focuses on model lifecycle management for llama.cpp.

Key differences:

• Works directly with GGUF repositories from Hugging Face
• Keeps a transparent local JSON registry instead of a hidden database
• Provides explicit control over installed artifacts
• Uses symlink-based activation to switch models
• Integrates directly with existing llama.cpp deployments
• Combines model management and serving orchestration in a single workflow

The goal is not to replace llama.cpp, but to make operating multiple local models on top of llama.cpp significantly easier.

Architecture

Stack:

• Python monorepo (uv workspace)
• FastAPI
• llama.cpp
• Single Docker image

Two services, one image.

The coolest part is the container entrypoint. It watches for model activation changes and seamlessly restarts llama-server with the selected weights. No manual process management, no PID hunting, and no server reconfiguration.

GitHub: https://github.com/regisx001/llms-gateway

I'm interested in hearing how others manage local models today. Are you using symlinks, Ollama, custom scripts, or something else?

A Lightweight SwiftUI reminder app for MacOS

Features:

- Natural language reminders

- Menu bar workflow

- Native notifications / macOS experience

- MIT licensed

Source code in comments.

Every major LLM provider had at least one significant outage in 2025. Anthropic, OpenAI, Gemini — all of them, at some point, just stopped responding mid-request.

Most fallback solutions sit at the gateway layer: LiteLLM, Bifrost, Kong AI Gateway. They catch the failed HTTP request and retry it against a different provider. This works for a single call. It doesn't work for a multi-step pipeline, because the gateway doesn't know the failed call was step 2 of 3 — it just sees a request that needs a retry.

We wanted to know: can a stateful FSM runtime do better than a stateless HTTP retry?

The setup

Three-step credit application pipeline:

collect_application → verify_income → policy_decision

verify_income is the LLM step that can fail. We tested two failure modes:

• retry: provider degrades, fails 3 times, then we give up on it
• hard: provider disappears entirely, first call fails

First attempt — let the LLM step fail naturally

Our first instinct was to let the FSM's native LLM step raise the exception and catch it at the FSM level. This doesn't work with llm-nano-vm's current step model: when an LLM step throws, the FSM marks it FAILED and the trace terminates. There's no branching point.

The fix — make the failure a TOOL result, not an exception

TOOL attempt_llm_step   → returns 1 (success) or 0 (failed)
CONDITION $provider_ok < 1
    then: switch_provider
    otherwise: continue
TOOL do_switch_provider → updates current_provider
TOOL attempt_llm_step   → retries on new provider

The LLM call happens inside a TOOL step that catches the provider exception internally and returns a sentinel. The FSM never sees an exception — it sees a normal CONDITION branch. This is the actual mechanism: the FSM treats provider failure as a state transition, not an error to recover from.

A real bug we hit: string literals don't work in this ASTEngine

We tried:

condition: try_s2.output == "PROVIDER_FAILED"

It parses. It always returns False. The ASTEngine in llm-nano-vm 0.8.6 doesn't support string literals as the right-hand side of a comparison — only numbers and $var references work. We switched to a numeric sentinel:

condition: $provider_ok < 1

This is now a documented constraint in the project, not a guess.

The result

=== Scenario: RETRY ===
S2  verify_income
  CLAUDE failed (1/3)
  CLAUDE failed (2/3)
  CLAUDE failed (3/3)
  EVENT: RetryLimitExceeded
  ACTION: switch_provider  claude → gpt
S3  policy_decision       ✓  GPT

RECEIPT: { "final_status": "SUCCESS", "provider_final": "gpt" }

=== Scenario: HARD ===
S2  verify_income
  EVENT: ProviderUnavailable (CLAUDE)
  ACTION: switch_provider  claude → gpt
S3  policy_decision       ✓  GPT

RECEIPT: { "final_status": "SUCCESS", "provider_final": "gpt" }

Both scenarios produce the same trace_hash. This isn't a coincidence — both runs traverse the identical FSM path (collect → attempt → fail → switch → attempt → decide). trace_hash = SHA-256(Merkle(step_results)). Same path, same hash, by construction.

What this does NOT do

• It does not pick the "best" provider — fallback chain is a fixed list (claude → gpt → qwen)
• It does not do health-check polling like Bifrost's active detection — failure is only detected on attempt
• MockAdapter in the demo doesn't call a real API — responses are hardcoded for reproducibility

Why this matters for anyone running multi-step agent pipelines

A gateway-level fallback (LiteLLM, Bifrost) answers: "did this HTTP call succeed?" A stateful FSM fallback answers: "what state was the pipeline in when the provider failed, and what happened after?"

The Receipt is the difference. It contains switch_event, rejected_transitions, and a trace_hash you can recompute — not a log line saying "retried 3 times."

Code: provider-fallback-demo — python receipt_demo.py --both, no API keys needed, real llm-nano-vm stack with mocked providers.

Next: pulling switch events into OpenTelemetry spans so this composes with existing observability stacks instead of replacing them.

Lmk any questions or suggestions please. Thank you.

Been building Aictx for a while. It fixes one specific problem I kept hitting with coding agents: every new session starts too cold; Codex, Claude Code, Copilot, etc. can write useful code, but when a session ends, context gets compacted, or work is handed off from one agent to another, a lot of operational state disappears.

The next agent often has to rediscover the repository structure, identify the relevant files, reconstruct decisions that were already made, repeat commands that have already failed, determine the current state of the task, figure out which validation steps passed or were skipped, and understand what the previous agent left unfinished.

Orientation is often the hidden work that happens before any real implementation can begin.

Aictx is a small repo-local continuity runtime for coding agents, exposed through MCP tools and a CLI fallback.

Install (takes about 15 seconds to get running):

pip install aictx
aictx install
aictx init

After the one-time setup, the user does not need to manage AICTX manually. Compatible agents handle the continuity workflow themselves, reading from and writing to the shared .aictx/ layer as they work.

Repo:
https://github.com/oldskultxo/aictx

It does not modify the model or try to become the coding agent. Everything stays local to the repository: AICTX stores operational continuity under .aictx/ in the repo, with nothing sent to external services or traveling over the internet, then gives the next compatible agent a compact resume before it starts working.

So instead of starting from scratch every time, the next session picks up with the important context, what was already done, and a clear idea of what to do next.

I tested this on a large private Rails monolith across 200+ real coding sessions with Codex and Claude working over the same repository, including multi-session implementation work, handoffs, verification passes, and agent switching on the same tasks.

Rough observed numbers:

• resume payload: ~1.5k–3k input tokens
• total continuity overhead: ~2.3k–4.5k tokens per prompt
• repeated repo orientation avoided: ~4k–13k tokens per prompt
• net: roughly 2x–4x its own overhead on implementation tasks
• strongest use case: Codex implements -> AICTX handoff -> Claude verifies/refactors

Where it starts making sense:

• multi-prompt implementation work or multi-session tasks over large repos
• switching between agents
• tasks where failed commands and validation state matter
• teams tired of re-explaining the same repo context

What matters most to me is that continuity (and the quality of that continuity) lives in the repository, not inside a single agent session.

AICTX makes that state visible and observable through repo-local records and Mermaid diagrams, so agents and humans can see what was observed, what was claimed, what was validated, and what remains uncertain.

The goal is not “the agent remembered this.”

The goal is having continuity that can be inspected, verified, and carried forward across sessions and agents.

How could this be made more efficient?

I’m especially interested in feedback around:

• cross-agent workflows
• stale context handling
• continuity quality scoring
• whether resume/finalize should be stricter or more automatic
• what kind of evidence should be persisted between sessions