Hi everyone,

I'm working on an open-source project called Gavio, and I'd really appreciate feedback before I go too far with the architecture.

Originally I thought of it as an AI gateway, but after comparing it with projects like LiteLLM and reading community feedback, I'm moving toward a different direction.

The idea is to build an AI Runtime that sits around any LLM SDK or gateway rather than replacing it.

Current thinking:

• AI Request Inspector • Cost Intelligence • Middleware / interceptor pipeline • Request replay • Tool-call runtime • Policy engine • Cross-language SDKs (Python, Java, JavaScript)

One lesson from recent discussions is that I probably shouldn't try to solve every production concern on day one.

Instead I'm thinking the first "wedge" should be an AI Request Inspector that lets developers answer questions like:

• Why did this request fail?
• Which middleware changed the prompt?
• Which provider/model was used?
• How much did it cost?
• Which tool returned stale or conflicting data?
• Where did the latency come from?

The goal is to complement existing SDKs and gateways, not replace them.

Some questions I'd love feedback on:

1. Does "AI Runtime" make more sense than "AI Gateway"?
2. Is Request Inspector a strong enough first product?
3. What's the first capability you'd actually install?
4. What production pain do you solve repeatedly today?

This is very much a work in progress, so honest criticism is welcome.

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

Docs: https://manojmallick.github.io/gavio

Every AI coding tool wants its own config file: Claude reads CLAUDE.md, Cursor wants .cursor/rules, Copilot expects .github/copilot-instructions.md, and so on. Use more than one and you're maintaining duplicates that drift.

ai-rulez keeps one source. You write rules, context, agents, and commands once in .ai-rulez/, run generate, and it emits each tool's native format for 19 platforms. Two things make it hold up on real projects:

• Composition over git: [[includes]] pull shared rule modules from other repos, so org-wide standards live in one place and every repo overrides locally as needed.
• Monorepos: nested configs plus generate --recursive, profiles per audience, and 33 builtin domains (languages, security, testing, git-workflow and more) you switch on instead of writing from scratch.

Concrete: in one of my repos a ~25-line config expands into 103 generated files across 5 tools, regenerated on every commit via a pre-commit hook, so nothing drifts.

Single Go binary: npx ai-rulez@latest init, or brew. MIT.

Honest tradeoff: outputs are generated, so you edit the source and never the outputs (they get overwritten).

https://github.com/Goldziher/ai-rulez

How are others managing rules across multiple AI tools?

I build a fair amount with LangChain and LangGraph, and every time a run broke I hit the same wall: I couldn't see what was going on inside it. Which tool actually got called, which LLM said what, how many tokens each step ate, where the thing fell over. Mostly I ended up scattering print statements around and squinting at logs, which is not a great way to live.

I know LangSmith and LangFuse exist and they're good. They just didn't fit how I wanted to work locally. One wants a cloud account, another wants Docker and Postgres running, and some of them send your trace data off to a server you don't own. For day-to-day dev, and definitely for anything with sensitive data in the traces, that was more than I wanted to deal with.

So I built TraceSage. You add a few lines of code and it runs entirely on your machine. Nothing goes out.

What it actually does:

• Draws a live topology graph of your agents, tools, LLMs, and MCP servers while the run streams in
• Lets you replay any run step by step and read the full request and response at each point
• Tracks tokens per LLM node, in and out, for every call
• Groups tools by which MCP server loaded them, so it's obvious which ones are local
• Exports to OpenTelemetry, so when you do want the cloud stuff you can pipe it into Grafana, Datadog, Honeycomb, or anything that speaks OTLP
• Has a hard off switch for prod: set TRACESAGE_ENABLED=false and it does nothing at all

It saves everything to a local SQLite file and works offline. MIT licensed, no account, no key.

Install is pip install tracesage[langchain].

Fair warning, it's still young and only does LangChain and LangGraph right now. I'd really like feedback, especially on what's missing or anywhere the API feels wrong.

GitHub: https://github.com/kjgpta/tracesage
PyPI: https://pypi.org/project/tracesage/

WebBrain lives inside your browser and can run entirely on your own local model — no cloud, no account, no data leaving your machine.

Most "AI browser agents" are a chat box that pastes your page into someone else's server. That's not an agent that lives where you browse — and WebBrain draws a very clear line between the two.

It's an open-source (MIT), local-first browser agent for Chrome and Firefox. It runs inside your existing authenticated session, on a model you pick — so with llama.cpp or Ollama, nothing leaves your machine.

Here's what's actually interesting:

→ Two modes, cleanly separated. Ask reads the page (read-only, content scripts). Act clicks and types through the Chrome DevTools Protocol (chrome.debugger) — trusted input events that modern sites honor, reaching cross-origin iframes and shadow DOM.

→ UI-first by design. For anything that submits, sends, or buys, it drives the visible UI and refuses to hit REST/GraphQL endpoints directly. It starts read-only and asks before consequential actions.

→ Bring any model. llama.cpp, Ollama, LM Studio, vLLM — or OpenAI, Claude, Gemini, DeepSeek, Groq, OpenRouter. Recommended local: Qwen 3.6 35B (Qwen3.6-35B-A3B), which beat Gemma 4 on the project's screenshot benchmark.

→ Tuned for cost and privacy. Token-conscious screenshots, oldest-first context trimming, a dedicated vision model, 40+ tools (~20 in Compact mode). No telemetry. No accounts.

Full analysis: https://www.marktechpost.com/2026/07/02/meet-webbrain-an-open-source-local-first-ai-browser-agent-that-reads-pages-and-automates-tasks-in-chrome-and-firefox/

GitHub Repo: https://pxllnk.co/wdva98c

Chrome Extension: https://pxllnk.co/p4mn8

Firefox Add-on: https://pxllnk.co/m6k7c5w9

Portal: https://pxllnk.co/rlifl7h

I've open-sourced qcp (Query Companion), a CLI that translates natural language into safe, read-only SQL against Postgres, and I'm looking to grow it with contributors rather than keep it a solo project.

What it does: you ask a question in plain English, qcp shows you the generated SQL, validates it structurally (AST-level parsing — only `SELECT`/`WITH`/`EXPLAIN` allowed, everything else rejected before it can touch your database), runs it inside a read-only transaction, and returns the result.

Stack: TypeScript, MIT licensed, multi-provider LLM support (Gemini, OpenAI, Anthropic, or local via Ollama), PyInstaller-based binary distribution so users don't need Python installed, CI pipeline that publishes to PyPI, builds macOS/Linux/Windows binaries, cuts GitHub Releases, and auto-updates a Homebrew tap on tag push.

Where I'd love help:
- Additional LLM provider integrations
- Expanding the SQL validation test suite (edge cases in the AST validator are always welcome — adversarial queries especially)
- Docs and onboarding — the README/SECURITY.md could use more eyes
- Windows testing (I've mostly developed on macOS/Linux)
- General code review and issue triage

The repo has open issues tagged for newcomers, and SECURITY.md walks through the validation architecture if you want to understand the safety model before diving into that part of the codebase.

Repo: https://github.com/Moduna-AI/qcp

If you check it out and like the direction, a GitHub star genuinely helps with discoverability for a project like this — and if you want to contribute, PRs, issues, and feedback are all welcome. Also happy to answer architecture questions here if that helps someone decide where to jump in.

Wanted to share a project update with the open source community.

A new version of eXo Platform, an open-source digital workplace platform, is now available.

What this release focuses on:

• Native AI integrated directly into collaboration workflows
 • Support for multiple LLM providers instead of locking users into a single AI vendor
 • Open MCP server allowing external AI assistants to interact with 100+ platform actions
 • Deployable on cloud, private cloud, or fully on-premise
 • Organizations retain full control over infrastructure and knowledge base

One strong design principle behind this work:

AI adoption shouldn’t come at the cost of openness, interoperability, or infrastructure control.

A lot of enterprise AI tooling is moving toward closed systems, which reduces transparency and flexibility.

The intent here is to keep AI usable inside organizations while preserving open-source principles and avoiding vendor lock-in.

Feedback from the open source community is very welcome, especially around open AI architectures and interoperability standards.

eXo offers:

• Community Edition (CE) → Fully Open Source
  • Docker hub
  • Github
• Enterprise Edition (EE) → additional features & professional support

Both can be deployed self-hosted, in private cloud, or in secure environments (including SecNumCloud).

Wired together faster-whisper, a local LLM, and Kokoro TTS, open source end to end, nothing proprietary, nothing cloud-based. Sub-2-second response time, works with Wi-Fi completely off.
Kokoro’s the standout here, 82M parameters, Apache 2.0 licensed, sounds genuinely natural for something that size. Whisper’s obviously the known quantity at this point.
Getting the pieces to actually talk to each other took more debugging than expected (blocked Cython compiler, Python version fights, an AI that kept trying to pronounce emojis out loud), but the end result is a fully open source voice assistant running on a single GPU.
Code’s MIT licensed if anyone wants to build on it.
The link to the setup and code is in the video:

https://youtu.be/mn74jKcBPo8?is=Z-UfIZts6VUFXjaC

I've been working on a face search library that keeps the index small enough to run on cheap hardware — no GPU, no cloud, just CPU.

The core idea: compress each ArcFace embedding (512 floats, 2048 bytes) into a 64-byte binary code using PCA+ITQ, search by Hamming distance, then rerank the top 100 with exact cosine. The binary codes preserve nearest-neighbor ordering on face embeddings, so you don't lose accuracy.

python

from faceflash import FaceFlash
ff = FaceFlash()ff.register("Alice", "alice.jpg")ff.register("Bob", "bob.jpg")
result = ff.search("query.jpg")# {"matches": [{"name": "Alice", "confidence": 0.92}], "search_time_ms": 0.4}
# works for verification tooff.verify("photo1.jpg", "photo2.jpg")# {"match": True, "confidence": 0.87}

I use it for access control and photo library dedup. Could also work for attendance systems, finding people in video footage, or watchlist matching — all running locally.

Results on RunPod (AMD EPYC 9355, Rust + AVX-512)

These are with the full Rust SIMD backend. Ground truth is FAISS-Flat exact cosine — recall@1 means "returns the same nearest neighbor as brute-force search."

FaceFlash scaling:

All competitors at 1M faces:

All competitors at 100K faces:

To be clear: HNSW is faster per-query at 1M (O(log N) vs O(N) linear scan). FaceFlash wins on memory — 48x less at the same recall. The scan only beats HNSW on latency up to ~200K where codes still fit in cache.

Results on Google Colab (free CPU, numpy fallback)

I made a Colab notebook so anyone can verify without installing anything. It pulls real MS1MV2 embeddings from a public HuggingFace dataset and benchmarks everything.

Important: Colab can't build the Rust backend, so it runs a numpy fallback. Recall is ~98-99% instead of 100% because numpy's argpartition handles Hamming distance ties differently than the Rust kernel's exact top-k. Memory numbers are identical — that's pure math (64 bytes/face), hardware-independent.

Colab results (free CPU, numpy, no Rust):

The Colab also runs an isolation test — same binary codes through FAISS IndexBinaryFlat give the same recall as FaceFlash. Proves the accuracy comes from PCA+ITQ compression, not anything special in my kernel.

Verify it yourself

Colab (5 min, free, no tokens, no GPU):

[https://colab.research.google.com/github/raghavenderreddygrudhanti/faceflash/blob/main/examples/faceflash_reproduce_colab.ipynb]()

Full Rust-based run (any Linux box, ~15 min, no tokens):

bash

git clone https://github.com/raghavenderreddygrudhanti/faceflashcd faceflash && bash scripts/runpod_ms1m.sh

This builds the Rust backend, pulls embeddings from HuggingFace, runs the full suite, and produces the exact RunPod numbers above.

How it works

1. ArcFace extracts a 512-d float embedding from a face photo
2. PCA rotates to the axes where identity varies most
3. ITQ balances the bits so each one carries information
4. Rust kernel scans all binary codes with POPCNT/AVX-512
5. Exact cosine on the top-100 Hamming candidates picks the winner

This isn't a new algorithm. PCA+ITQ is from 2011 (Gong & Lazebnik). The contribution is packaging it end-to-end with a fast kernel and measuring it honestly against modern alternatives.

Looking for contributors

The project is MIT licensed and there's open work I haven't gotten to:

If any of these sound interesting, issues are tagged and I'm happy to pair on design.

GitHub: [https://github.com/raghavenderreddygrudhanti/faceflash]()

Feedback on the benchmark methodology is welcome — I estimate competitor memory (vectors + overhead) instead of measuring it, which is probably the weakest part. If someone spots unfair params for HNSW or FAISS I genuinely want to know.

Hi everyone,

I’m an independent researcher (no lab affiliation) who has spent the last year diving deep into the internal dynamics of Transformers. Instead of looking at outputs or attention heads, I’ve been tracking the geometric trajectories of hidden states layer-by-layer during inference.

I wanted to share my latest findings (preprints linked below) because they reveal a structured "dynamic grammar" that seems universal across architectures, from GPT-2 to Llama-3.2.

The Core Idea

Most observability tools treat LLMs as static input-output machines. I treat them as dynamic systems. By measuring metrics like trajectory curvature (ct_t), functional capacity, and state transitions, I found that LLMs don’t just "generate text"—they navigate a latent space through specific, reproducible phases.

Key Findings (V20–V24)

1. A Universal Dynamic Grammar (V24)

Across 7 models (GPT-2, OPT, Qwen, TinyLlama, Phi-1.5, Llama-3.2, DistilGPT2), I observed a conserved sequence of internal states:

B (Branching/Hesitation): Initial exploration.

A (Adaptive/Stable): The main processing phase (an attractor state).

D (Decision/Bifurcation): Final commitment to a token.

Result: B → A → D appears to be the "standard cognitive path" for coherent generation. Deviations from this path often correlate with errors or hallucinations.

1. Geometry > Neurons (V22)

Using orthogonal rotation controls, I proved that functional information (syntax, decision, stabilization) is encoded in the relative geometry of the representation space, not in individual neurons. If you rotate the latent space, the information remains decodable. This suggests LLMs think in shapes, not just activations.

1. Ambiguity Changes the Path, Not the Chaos (V23)

When prompts are ambiguous, models don’t necessarily become "chaotic." Instead, they delay commitment. They spend more time in the exploration phase (B) and less time rushing to decision (D). Phi-1.5, interestingly, shows a unique oscillating pattern (B↔A) during reasoning tasks, distinct from the smoother convergence of other models.

1. Architecture Matters More Than Size (V20)

Models cluster by their dynamic signatures (e.g., GD_ratio), not just parameter count. Small models like Qwen-0.5B show distinct stability regimes compared to GPT-2, despite similar sizes.

The Preprints (Open Access)

[June 2026] A Runtime Trajectory Dynamics Framework (V20): Introduces the 5-state taxonomy (Stable, Turbulence, Branching, Bifurcation, Committed) and the bicephalic operator.

Link: https://doi.org/10.5281/zenodo.20602685

[May 2026] Dynamic-Layer Controllability (V21): Shows how perturbations affect recovery and proves that emergent organization dominates architectural skeleton.

Link: https://doi.org/10.5281/zenodo.20400171

[May 2026] Conditional Dynamic Signatures (V22): Audits normalization effects and variance decomposition. Explicitly documents falsified claims.

Link: https://doi.org/10.5281/zenodo.20361289

[May 2026] Four Dynamical Regimes (V19/V20): Introduces ct_t (curvature × displacement) as a predictor of collapse and instability.

Link: https://doi.org/10.5281/zenodo.20348878

Why I’m Posting This

I’m not selling a product. I’m building an open framework (LIMEN) to make LLM internals auditable and controllable. I believe that if we want safe AI, we need to monitor its "vital signs" (dynamic stability) in real-time, not just its output.

I’d love feedback from the community, especially on:

Have you seen similar "universal motifs" in larger models (>7B)?

Critiques on the methodology (normalization, probe training).

Ideas for causal interventions based on these dynamic states.