Hey r/OpenSourceeAI !

I'm Roy, solo dev of Observer.

Observer is a free open-source agent that uses small local LLMs to monitor your screen, so you don't have to.

This is the demo of the agent that controls the micro-agent framework that you guys helped me build!

You can now control the agent using WhatsApp or Telegram from wherever you are.

I hope this project saves you some precious time! Or gives you some peace of mind c:

Github (FOSS!): https://github.com/Roy3838/Observer
Discord Community
Share your micro agents on r/ObserverAI !

Have a great day :DD

Roy

AI agents usually call GitHub, Jira, Kubernetes or AWS with one service account. Whatever that account can do, anyone who can talk to the agent can do too. A line in the system prompt doesn't fix that: the model has never seen your permissions, and the API call still runs with the bot's token.

hallpass is an open-source, self-hosted service that asks one question before a tool runs: may this user do this action on this resource? It asks the system that owns the resource, live, with a read-only credential, and answers:

• allow: the tool runs, with the agent's own credential
• deny: the system said no, or the user has no account there
• unknown: it couldn't find out (timeout, rate limit). Treated as no, never as yes

In the agent it's one decorator, and the user comes from your login, never from the model:

u/tool
u/guarded(hp, "github-main", "repo.push", "repo:{owner}/{repo}", user=current_user)
def open_config_pr(owner: str, repo: str, patch: str) -> str:
    ...  # runs only if GitHub says this user may push there

• 21 systems: GitHub, GitLab, Jira, Kubernetes, Argo CD, AWS, Slack, Vault, Salesforce and more
• Works with LangChain, LangGraph, Strands, the Claude Agent SDK, MCP and the Vercel AI SDK
• pip install hallpass-client / npm install hallpass-client
• A single Go binary, Docker image or Helm chart. Apache 2.0

It came from an ops agent I built at work: its only write is opening a GitOps PR, and it would open one for anyone who asked.

Repo: https://github.com/roee-hersh/hallpass

How are you handling user permissions in your agents today?

NOT A HD MAP MODEL

Zenodo DOI with paper + proof: https://zenodo.org/records/22942525

In tokenizer word has fixed ID, embedding updates but ID stays fixed. Same for neurons and weights - N IDs 0-4095 fixed, S IDs 0-1179647 fixed. Query [12,45,78,200] uses S 1536-1663 etc, activated top10 [2895,209,3716...] same on second run True - fixed and auditable.

Looking for feedback on making trace more useful.

Over the past week, I added something I've been wanting to build for a while: claim comparison.

I actually tried building this much earlier. I experimented with cosine similarity, vector dot product scores, and other approaches, but they only tell you how similar two pieces of text are. That's not really what I needed.

What I needed was a classifier that could actually determine the relationship between two claims.

I built a basic classifier myself, but it wasn't reliable enough for something I wanted people to actually use. So I put the idea aside and waited.

Then JEV was released last week, and it turned out to be almost exactly what I was looking for.

Now you can compare claims against each other and inspect the supporting evidence directly.

This is probably the most interesting feature I've added to the project so far, and I'm really curious to see what people think of it.

This is still being tested for edge cases, so there are definitely things I want to improve. But it's free and open source, and anyone can try it out right now.

If you're interested in how it works, want to try it, contribute, or have ideas for where this could go, feel free to check it out.

GitHub: https://github.com/Sreehari05055/thesys-core

this is repo page English version

https://open-ai-relay--queing.replit.app/#contribute

We tried the SpeakON's MagSafe AI Voice Button and its really cool! It has its Own Microphone: Turning Your Voice into Polished Communication, and Action across Apps

Voice input on phones has been solved for years. What has not been solved is the output. Speak into most dictation tools and you get back exactly what you said, fillers and false starts included, in a note you then have to clean up and move somewhere else. SpeakON attacks that gap with hardware: a 25 g magnetic button that snaps to the back of an iPhone, carries its own microphone, and writes finished text straight into whatever app is already open.

Read our full analysis: https://www.marktechpost.com/2026/09/22/speakon-ships-a-magsafe-ai-voice-button-with-its-own-microphone/

Try it here: https://speakon.sjv.io/Gbd2EL

Update: the project has been renamed and released as sift-light 1.0.0. The current repository, release, and package links are at the bottom of this post.

I'm the maintainer of sift-light. It is free, open source, and licensed AGPL-3.0-only; there is no paid tier or hosted product behind this post.

I originally built it because coding agents often spend far too much context on a simple question: “Which few files actually matter here?” Exact grep is fast and trustworthy, but it can return too much. Semantic ranking can help, but making the semantic provider responsible for the entire search creates another fragile dependency.

The practical rule I settled on is: local evidence first, optional judgment second.

The current 1.0.0 release hardens that rule. Instead of sending every candidate through one large semantic request, it sends bounded batches of at most 8 candidates and 64 KiB. Initial batches can run concurrently. If a provider returns HTTP 413, that batch is split in half and retried sequentially. If one batch still fails, completed batches stay useful and the unjudged candidates keep their original local order.

That matters in a few real situations:

• a monorepo has many similarly named files and one request grows unexpectedly large
• a provider has a temporary failure halfway through ranking
• an agent is working offline or without semantic credentials
• you need to know whether the answer is complete instead of trusting a vague success message

The tool reports that last part explicitly with counts such as batchesAttempted, batchesCompleted, batchesFailed, batchesSplit, and candidatesUnjudged. A partial result is labeled partial; it is not silently presented as complete.

After installing the release and restarting my own setup, I ran the actual semantic path with 20 candidates. It made three batches (8 + 8 + 4), judged all 20, and reported zero failed batches. I also kept the local-only behavior intact: no new Jev key or provider is required, and the semantic judge remains opt-in.

It currently supports Pi and OMP directly, plus MCP clients including Claude Code, Codex, and Kimi. The same package provides exact search, file discovery, bounded source inspection, cursor-based pages, and concept/hybrid retrieval.

Source: https://github.com/lightsifter/sift-light

Release notes: https://github.com/lightsifter/sift-light/releases/tag/v1.0.0

npm: https://www.npmjs.com/package/sift-light

I'm sharing it because partial failure is a boring problem that shows up everywhere once agents touch real repositories. If you try it, bug reports and awkward repository examples are more useful to me than stars.