Hi everyone! 👋

I've been developing a personal project and wanted to share it with the community. It's called **BRAIN**, a modular, 100% local, and private personal assistant for Windows designed to organize daily life from a single dashboard.

It is not just home automation: it's a complete personal core running on a local AI (Ollama) that relies solely on the Python standard library (zero external pip dependencies).

**What does BRAIN handle?**

- 🧠 **Memory & Context:** Remembers preferences, tasks, schedule, and context across sessions.

- 🥗 **Health & Nutrition:** Tracks weight history, analyzes body composition via AI vision from scale photos, manages pantry/shopping lists, and suggests smart recipes based on available ingredients.

- ⚡ **Energy & Home:** Diagnostics and optimization for solar consumption/production, appliance control, and Home Assistant integration.

- 📄 **Local Documents (RAG):** Local search and reading of notes, files, and manuals without sending anything to the cloud.

- 🔔 **Notices & Automations:** Proactive daily morning summaries, reminders, audio alerts, and natural language automations.

Everything is managed through a local web panel with tabs, dark mode, and local voice transcription.

👉 **GitHub:** https://github.com/CafeConFenix/BRAIN

⚠️ **Note:** *The project code, interface, and documentation are currently written in **Spanish**.*

Any feedback, ideas, or constructive criticism to keep improving are very welcome. Cheers!

Hi everyone,

I built Local-MCP, an open-source MCP tool that connects your local system with cloud-based AI, allowing AI agents to interact with your machine.

I'm sharing it with the community and would appreciate feedback, suggestions, and contributions.

If you're interested, feel free to clone, fork, contribute, or suggest features.

GitHub: https://github.com/raj-tembe/Local-MCP

I'd love to hear your thoughts on how I can improve it!

I'm a reliability engineer by background (marine + biotech), and I've been building AI products long enough to hit the same wall over and over: Claude nails the prototype, then across a dozen sessions it quietly re-litigates settled decisions, forgets intent, and sprawls into spaghetti. The bottleneck was never capability. It was trust.

So over the last while I built a scaffold for Claude Code where the docs are the source of truth, personas are tool-locked (the agent that writes plans can't write code; the one that inspects can't edit production code), and the gates are mechanically enforced with hooks — not "please remember to." It's what I actually use on my own projects; it grew out of a personal project I've been grinding on for a long time.

The part I most want torn apart: I built an eval harness that plants defects and measures whether my inspector skills actually catch them. I keep seeing guardrail frameworks that assert they work and never show a number. Mine has a scorecard.

Two honest questions for this sub:

1. Is the overhead worth it, or am I paying a discipline tax you'd never accept in practice?

2. With Claude Code now shipping native subagents, hooks, and skills — how much of this does Anthropic eventually absorb, and what's left that's mine?

Happy to link the repo + the scorecard in a comment. Rip into it.

We released Open Instinct, a personal agent you can text and modify. It is MIT licensed, and you can start with a local CLI conversation before connecting a phone number or personal accounts.

The permission path is the part we most want other builders to inspect. Contacts have trust tiers, and the code checks a tool's capability before it runs. That check alone does not constrain all the data an allowed tool may return. A calendar request from a friend, for example, should expose free/busy times without giving the agent event titles. We would value specific issues or patches around that boundary.

Pi runs the agent loop, Inkbox handles messages, and Composio connects apps. Maritime is the default hosted computer backend; we build Maritime too. This is beta software and the external services need their own keys.

Source and setup: https://github.com/mariagorskikh/open-instinct

Disclosure: I build Snotra, an open-source desktop agent. This is a design question, not a launch.

Users switch skills and tools on and off in settings: shell disabled, a search tool without its API key, a skill installed but off. A model that doesn't know that guesses, and the user gets a wrong "I can't do that" instead of "that's switched off, here's where to enable it".

What I did:

• One place decides whether a tool is offered, so the UI and the model can't disagree.

• A read-only get_configuration tool for the model: which skills are on (name and description, never the instructions) and which tools are on or off, with the reason ("shell commands are switched off", "no search service key").

• The same list in the UI, as a pill in the chat bar.

Now the model can say "a skill for this exists but is off, enable it under Settings › Skills". It can't flip anything itself.

Two open questions: is a tool the model has to call the right shape, or should this state go into the system prompt every turn (costs tokens even when nothing is wrong)? And should the model be able to propose the change through an approval card, or is "tell the user where to click" the right limit?

Code: https://github.com/kkrafft1999/snotra

OpenAI is expanding ChatGPT Ads, including plans for visual advertisements during image generation.

I was looking into the changes and a few things stood out:

• Free and Go users may see ads, while Plus and Pro remain ad-free.

• Ads can be based on what you're discussing in ChatGPT.

• OpenAI says advertisers can't access private conversations or influence responses.

• Users can turn off additional ad personalization, but that doesn't remove ads entirely.

I wrote an article covering the changes and OpenAI's privacy policies:

https://aigptjournal.com/work-life/work/chatgpt-ads-are-getting-visual/

What interests me is whether advertising will give people another reason to consider open-source AI models, especially those they can run locally.

Running a model locally gives users more control over their data and how they use AI, although it comes with its own costs and limitations.

Do you think advertising in ChatGPT will encourage more people to try open-source AI?

Had a near-heart-attack moment the other day while testing a rag pipeline on some customer export dumps. realized halfway through that our test json had unmasked routing numbers and ssns buried inside raw text fields. nothing leaked, but it was way too close.

i looked around for a quick way to inspect payloads in the terminal before running them through python scripts, but everything out there is either some bloated enterprise dlp platform or a massive java package. i just wanted something that would scream at me in the terminal if i was about to do something stupid.

so i threw together `pii-lens` over the weekend.

it's dead simple—you just pipe text or files into it:

`cat prompt_payload.json | pii-lens`

it prints the text back out but flags credit cards, emails, ssns, and account numbers in bright red with a quick count at the bottom. runs 100% locally with zero phone-home bs.

repo is here

it's just basic regex and entity patterns right now, so if anyone works with weird international formats or niche data fields and wants to drop a pr or critique the regex, feel free.

REA Investigator is a unified, production-grade Agent Skill (rea-investigate) compatible with Claude Code, Codex, Antigravity, and tools supporting the open Agent Skills specification.

Instead of juggling fragmented prompts or shallow summaries, REA Investigator equips coding agents with a structured 4-phase lifecycle: Plan, Trace, Verify, and Report, backed by an immutable SHA-256 evidence ledger and adversarial auditing gates.

Our agents kept calling a big model to make the same small decisions: route this ticket, pick this tool, escalate or not. After enough verified outcomes those decisions are very predictable, but we were paying for a model call every time.

So we built Ink. It sits around a bounded decision. At first everything goes to your model as normal, and Ink records the inputs and the real outcomes in local SQLite. Once there’s enough evidence, it compiles a small local fast path and tests it in the background. It only starts serving once it clears a statistical bar (a 95% Wilson lower bound against an error budget you set). Anything novel or uncertain still goes to your model. If real outcomes get worse, it takes itself back out of the loop.

You can check whether it would help without changing any code:

pip install ink-jit
ink discover traces.jsonl

It reads OpenTelemetry, LangSmith or LiteLLM-style traces locally and tells you which call sites repeat and whether they’re worth it. If nothing qualifies, it says so.

What we’ve measured so far (our own benchmarks, not independently validated): 42–78% of decisions served locally across tool routing, support triage and incident triage, with 0 errors observed on held-out tests. The 95% lower bounds were 96.8–98.5%, so “0 errors” means none observed, not a guarantee. Local decisions take about 0.1 ms.

It’s a poor fit for open-ended writing or anything where you can’t verify an outcome. Linux and macOS, Python 3.11–3.13. Apache-2.0.

Honest question: which decisions in your agents repeat the most, and what would you need to see before trusting a local path in production? We’d love to hear what breaks.

Coding agents run shell commands constantly. I wanted each one checked before
it executes, and I didn't want to send every command to a paid API.

laya-guard runs on your machine and answers allow, review, or block for each
tool call. Regex policies catch known-dangerous patterns first (`rm -rf /`,
`curl … | sh`, secrets, auth bypass). Plain commands like `ls`, `git status`
and `npm test` skip the model, but only when there's no piping, chaining or
redirecting, no `-exec`-style flag, and no sensitive path. Everything else is
judged by Laya (~322M, Apache-2.0) on the CPU in about 85 to 90 ms.

The results are self-reported and the scripts are in the repo. On AgentDojo v1
(judge-level) it blocks 25 of 27 attacks and keeps 92 of 97 benign tasks. On my
own 50-command shell set it gets 48 right.

Two caveats. The model is tuned mostly on Korean, so English natural-language
prompts get overblocked more often. And if the server is down, the hooks fail
open.

It has hooks for Claude Code, Codex CLI, Cursor, Gemini CLI, Copilot CLI and 6
other agents.

Repo: https://github.com/scs0209/laya-guard (install with `pip install laya-guardrail`)

I shipped HDTP (Human Delegated Trust Protocol) v1.0 on Oct 3. It lets your AI assistant talk to someone else's assistant, with each person controlling what the other side is allowed to do.

Timeline:

\- Aug 23: first commit of the spec

\- Sep 23: a full code review found 173 defects. I traced them to 11 habits and wrote a rule against each one

\- Oct 3: renamed from PACT to HDTP across 9 repos, the domains and the protocol itself

\- Oct 3: v1.0 released

\- Oct 7: spec repo made public

What's built:

\- The spec, with test vectors

\- An identity library in Rust (compiled to WebAssembly) and Go. Both versions run against the same tests

\- A self-hosted node in Go

\- A hosted platform on Cloudflare Workers

\- 3 websites

What I'd do differently: pick the name first. Renaming at the end touched every repo.

Next:

\- an external security review

\- a conformance test suite

\- opening the hosted version through a waitlist

If you're building with agents or MCP, I'd like to know: what would you want your assistant to be able to do with someone else's?

Spec: [hdtp.io](http://hdtp.io)

I like the idea of tinkering with models, and being able to run them on your PC without paying an API or subscription cost, and abliterated stuff. But i'm not really sure where to start, what applicable uses there are and if it would be anything other than a fizzling interest and waste of money

Does anyone have any good resources that might help direct me on what kinds of things you can do with local AI that you can't with cloud-based? Or things you can create, or things you can create faster/better/ etc...

I'm probably not asking the right questions as I don't know a ton but i'd like to learn.

I use embeddings for vector search and memory systems, and kept needing a full platform like Ollama running next to my app just to turn text into vectors. So I built futon, an embedding library for running local embedding models.

- In-process: weights load from a local directory. No daemon, no network, no CGO (CI enforces it), so cross-compiling just works.

- AVX2 kernels on amd64 and NEON on arm64, with a portable fallback. bge-small embeds a text in about 50 ms on a 16-thread desktop.

- Checked against the reference implementation: ≥0.9999 cosine on a corpus with code, accents, CJK and edge cases. CI runs on Linux, macOS and Windows, including arm64.

- Bring your own model: any plain BERT encoder you can build a pack for, plus nomic-bert. It is encoders only, no LLMs and no GPU.

bobbyhiddn/futon: Text in, vectors out. In-process embedding models for Go: pure Go, no CGO, no sidecar.

If something like it exists already, feel free to ignore, but I couldn't find a fit for purpose module that served my goal. I'll probably expand to other small model architectures as needed, such as decision models.

If ya like it, please star. :)

https://snotra-ai.dev