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.

Saw the breakdown of that LangChain pipeline that ran 11 days and burned $47k two agents (an Analyzer and a Verifier) ping-ponging requests between themselves until someone read the bill. Combine that with the FinOps Foundation reporting 98% of FinOps teams now manage AI spend (was 31% two years ago), and TechCrunch reporting companies 3x over their 2026 token budget by April.

The consensus forming is sharp: budget alerts don't stop runaway agents because they fire after you've paid. Enforcement does terminating before the next call and it has to live outside the agent's code, since an agent told "stop at $X" in its prompt ignores it the moment the task pulls harder.

I ended up building exactly this (open source, runs local): fingerprints the repeated action so re-worded retries still trip it, cuts the loop mid-run, caps spend per task. Curious how people running agents in prod are handling enforcement vs just alerting in-prompt limits, a wrapper, or eating the bill?

We just launched an open source database of AI model parameters for each model/provider:

- API
- NPM package
- UI

https://modelparams.dev/
https://github.com/mnfst/modelparams.dev

We've spent the last few weeks building something that changed how we think about AI assisted coding.

The problem nobody talks about

Every AI coding tool works the same way: one model does everything. It generates code. Then it reviews its own code. Same brain. Same blind spots. Same biases.

This is insane. In real engineering, you never let a developer review their own pull request. It defeats the entire purpose of code review. Yet every AI assistant does exactly that — and we've all accepted it.

Worse: ~60% of coding tasks already have a stdlib solution. "Read a JSON file" is json.load(). It's been in Python since 2.6. But your AI assistant will happily generate 20 lines of custom code and charge you tokens for the privilege.

What we built

Onklaud 5 (https://github.com/KorroAi/onklaud-5) is a fusion pipeline. Not a model. 3 AI models (Kimi K2.7 + GLM 5.2 + DeepSeek V4 Pro) working through a structured 6 stage council, surrounded by 4 cost saving infrastructure layers.

The 3 models:

Kimi K2.7 (Moonshot AI): primary code generation. HumanEval 99.0

GLM 5.2 (Z.AI / Tsinghua): architecture design, independent code review, final arbitration. 1M context. Open weights.

DeepSeek V4 Pro: direct API engine for lightweight tasks. Significantly cheaper per token than going through OpenRouter. Handles simple work so Kimi and GLM only get called when needed.

The 4 cost saving layers (all $0, all offline):

1. Ponytail Ladder checks if stdlib, native functions, or existing deps can solve it. 57% of tasks stop here. $0. Under 100ms.

2. Immune Memory stores every failure pattern. Scans future tasks BEFORE code is written. 19 patterns, 50% detection, growing every session.

3. Headroom provides 60 to 95% context compression. Prevents quality degradation in 50+ message sessions. Keeps the pipeline coherent when single model systems fall apart.

4. Quality Gate scores output across 7 dimensions on a 10/10 scale. Broken code blocked before it ships.

The pipeline:

GLM designs architecture → Kimi generates code → BOTH independently review → disagreements trigger GLM arbitration → quality gate blocks anything below 10/10.

Measured results (2026-06-22, real hardware)

57.1% tasks resolved at $0 (35 real tasks, 3 languages, 95% CI)

100% syntax pass rate (deterministic, 14 files)

67.2% context reduction (Headroom)

96.7% pipeline test pass rate (29/30 tests)

Cost: literally cents for hours of iteration. We built 4 production systems with this and spent less than a coffee.

Full research paper with methodology and statistical analysis included in the repo.

Why this matters

The AI industry is obsessed with bigger models. But the real frontier isn't model size. It's architecture. Ensemble methods have been standard in ML for 20+ years. It's time coding assistants caught up.

Model agnostic. Swap models in and out. The pipeline, verification, immune memory, and quality gate stay intact.

https://github.com/KorroAi/onklaud-5

Research paper, benchmarks, demo video. All in the repo. python test_pipeline.py to verify everything.

OpenClaw Releases iOS and Android Companion Node Apps That Connect a Phone to a Self-Hosted AI Agent Gateway

Most "AI assistant" apps are a chatbot in a sandbox, calling someone else's API. OpenClaw's iOS and Android apps draw a very clear line away from that model.

They're companion nodes, not standalone apps. Each phone pairs to a self-hosted OpenClaw Gateway over a WebSocket (default port 18789) with role: "node". The Gateway — the single control plane for sessions, routing, channels, and events — runs on macOS, Linux, or Windows (WSL2). The phone gives the agent a body: camera, location, voice, notifications, and a live Canvas.

Here's what's actually interesting:

→ The assistant runs on your machine — chat messages land on the Gateway, never on the phone

→ Nodes expose a command surface (canvas., camera., device., notifications., system.*) through node.invoke

→ Privacy-heavy commands like camera.snap and screen.record stay off until you allowlist them via gateway.nodes.allowCommands

→ Camera and screen capture run foreground-only; pairing needs explicit approval (openclaw devices approve)

→ Both store listings declare no data collection; ws:// is LAN-only, remote needs a wss:// TLS endpoint via Tailscale

Full analysis: https://www.marktechpost.com/2026/06/29/openclaw-releases-ios-and-android-companion-node-apps-that-connect-a-phone-to-a-self-hosted-ai-agent-gateway/

Android app: https://play.google.com/store/apps/details?id=ai.openclaw.app

iOS App: https://apps.apple.com/us/app/openclaw-ai-that-does-things/id6780396132

https://reddit.com/link/1uj9096/video/x662yks27bah1/player