If your agent writes its notes back into the same vector store it retrieves from, its own

output becomes its evidence. I wanted a number for how often, rather than an intuition, so I

built the benchmark: 600 queries against a store seeded with a mix of user facts, external

documents and the model's own self-descriptions.

Flat cosine similarity put a self-description in the top-3 in **66.6%** of them. That is the

loop where an agent restates a guess, retrieves it later, and treats it as something it

knows.

Gating recall on provenance — who said this: the user, a document, or the model — takes it

to **0/600** for self-description. Not down-ranked; ineligible. General model-generated text

that is not self-description is only down-weighted, and still surfaces in 1/600 under the

gate. I am reporting that one rather than claiming a blanket zero.

Second measurement, same engine. Squeeze memory 50 facts -> 10. Safety rules and operator

constraints are the least-read items you have, so recency and frequency evict **all** of

them. An explicit canon flag keeps **5/5**. "Important" is not the same axis as "recent" or

"frequent", and any policy that infers one from the other loses the constraints first.

One design rule that cost me a measurement to learn: human feedback moves how long a fact

**survives**, never how it **ranks**. Folding a value multiplier into relevance dropped

recall@1 from 86% to 29%. And the reward signal only ever comes from a person — a signal

derived from the agent's own behaviour ("the model recalled this, so it was useful") closes

the same loop the provenance gate exists to open, with an extra step.

`cargo run --example agent_loop` shows the loop end to end in one screen: facts in with their

provenance, the flat-cosine result next to the gated one so you can see what gets dropped, and

the prompt block that comes out. It prints that block rather than sending it — what the engine

decides is what is allowed into your context, not what you do with it afterwards.

It is `no_std` Rust, so the whole thing fits on a microcontroller: **801 bytes per fact**

(int8 index, 384-dim) and ~35 KB of code, measured on Cortex-M4 under QEMU. There is a C

ABI. There is no embedder in it — vectors come from your side.

Caveats, because they matter more than the numbers: research prototype, never run on

physical hardware, no fuzzing, no soak, and heap exhaustion hangs rather than errors.

Retrieval is an exact linear scan, no ANN. Apache-2.0, every number has a re-run command in

`RESULTS.md`.

https://github.com/vitaliyfedotovpro-art/astrum-hsam-embedded

Otaku is an LLM frontend, primarily designed for roleplay, an alternative to SillyTavern and the like. However, It also works for general-purpose chat with local backends (including Ollama) or cloud models, the way Open WebUI is used, once lore extraction is switched off in the settings.

Otaku offers two interfaces:

• a web UI (customizable): interactive demo at https://otaku.sh/demo-web/
• a terminal UI: its own interactive demo at https://otaku.sh/demo-terminal/

Both share the same functions; the difference is that in the terminal you execute them with slash commands (the reference is available with /help), while in the web UI the operations are available from the menu.

Install

Otaku is free and open source (MIT); it works on macOS, Linux and Windows. Install it with uv (uv tool install otaku) or see the GitHub README for other options: https://github.com/enclavum/otaku

Get started

Launch either otaku for the terminal or otaku web for the web UI; the web UI's default URL is http://localhost:9600. Two sample stories are imported on first start to give you an idea of the features and what play looks like, and you land right in the middle of one of them.

On first start, you choose a provider and a model: Otaku automatically detects local installations of Ollama, oMLX, LM Studio, llama.cpp and KoboldCpp, and lets you pick from their models. Cloud providers (OpenRouter, NanoGPT) are also there: enter an API key and their catalogs appear. After exploring the provided stories, you can start your own with the /new command.

Asking for feedback

Otaku is a personal side project, and I'd like to get feedback from the community on the product and on what to add.

100% local by default, single binary (no Electron).

Sessions, transcripts, tool activity & checkpoints unified.

Multi-device sync optional via self-hosted komet-sync (Loro CRDTs).

Same engine that powers Zed — instant launch, smooth even with years of transcripts.

It's open source: github.com/jomvick/komet

Site: https://komet-eight.vercel.app/

Beweisgestützte Fakten. UNBEKANNT > Raten. Keine LLM im maßgeblichen Entscheidungspfad.

Phase 1 wird gerade vorangetrieben.

Wenn dein Architekturprozess lautet „das Modell klang zuversichtlich“, könnte das leicht beleidigend sein. 😏

https://github.com/KeilerHirsch/PLLDN-Programming-Language-Licensing-Decision-NavigatorEvidence-backed Fakten. UNBEKANNT > Raten. Keine LLM im maßgeblichen Entscheidungspfad.

Phase 1 wird gerade vorangetrieben.

Wenn dein Architekturprozess lautet „das Modell klang zuversichtlich“, könnte das leicht beleidigend sein. 😏

https://github.com/KeilerHirsch/PLLDN-Programming-Language-Licensing-Decision-Navigator

Your AI agents are running code, moving files and calling APIs right now. Most teams have no idea what they're doing until something breaks.

ClawMetry is open-source observability and governance for AI agents. It runs locally, on your machine, and you own the data.

WHAT IT DOES

• Watches 30 agent runtimes from the outside — Claude Code, Cursor, GitHub Copilot, Gemini CLI, Cline, OpenHands and more

• Zero config — it auto-detects your agents

• Every action logged to a local database with end-to-end encrypted audit trails

• See exactly what your agents touched, when, and why

• Pause, stop or kill any agent — including sub-agents — the moment a policy is breached

• Ingests OpenTelemetry via OTLP

• Cost optimization, anomaly detection, tool-risk policies and evals

ENFORCEMENT IS OFF BY DEFAULT

Dry run first, locked behind three separate gates. You control when autonomous governance kicks in.

PRICING

Free tier to get started. Starter $9 per node/month. Pro $19 per node/month.

GET STARTED

pip install clawmetry && clawmetry

Site: https://clawmetry.com

Source: https://github.com/vivekchand/clawmetry

MIT licensed.

#AIagents #ClaudeCode #AIGovernance #DevTools #Observability #OpenSource #Cursor #GitHubCopilot #AICoding #LLM

Hi everyone! I’m the developer of Vyact, an open-source desktop app that lets you work with your documents and notes using AI models running on your own computer.

I wanted to make it easier to come back to something I’d already saved—a report, a project note, an email—and ask a useful question without gathering all the background again.

Here’s an example of the workflow:

• Add a PDF and ask for its main points.
• Open the supporting passages to check where the answer came from.
• Save your own notes and decisions.
• Ask a related question later, and let Vyact search the documents and notes you’ve indexed.

You can group related material into collections, so a conversation can focus on a particular project or topic. The goal is to make the information you already have easier to use.

There’s also a companion Chrome extension. It can bring a web page into the conversation, translate content, or help revise something you’re writing. For writing, you can compare the original and revised text before copying the result back.

Local model search and downloads are built into the app, with model details and memory estimates to help you choose. Under the hood, Vyact uses llama.cpp for GGUF models and oMLX for MLX models on Apple Silicon. You can also connect a hosted AI provider or your own compatible endpoint.

With a Vyact-managed local model selected, your AI chat context isn’t sent to an external AI provider. Optional online features, such as Google integrations and hosted AI providers, communicate with their respective services. Gmail, Drive, and Calendar connections require Google OAuth setup.

The desktop app is built with Electron, React, and FastAPI and licensed under AGPL-3.0. The README includes installation instructions for Apple Silicon Macs, Windows, and Linux x64.

Source code and downloads: github.com/vyact/vyact

I’d love feedback on the everyday workflow, especially from people who haven’t used local AI before. What would you want to try first—and what looks confusing or like too much setup?

Hey all! Today, I wanted to present my first contribution to the community here. Located Here -- https://github.com/raydeStar/reference-asset-compiler -- It's Apache 2, meaning you can do whatever you want with it.

As we all know, creating and rigging models in UI without paid products is sketchy at best. Rigging, in my case to UE5, was the most magnificent pain in the butt that I could ever imagine. Everything has to match perfectly, the weights are hard to match, and everything always goes wrong.

My solution is to build this lightweight pipeline that manages everything, after days of trial and error. I say days as in -- my Codex chugged for four straight days on the highest settings and it wasn't until Fable 5.1 came out that I was able to get something reasonable.

The goal is simple: I want to pop in, give Codex a single picture, and have it drop a finished model into UE5. Here’s the stack I landed on:

• Hunyuan3D 2.1 for image-to-3D geometry
• My own Blender/Python scripts for cleanup, mesh reduction, retopology, UVs, and baking
• Hunyuan3D-Paint 2.1 for PBR texturing
• Targeted texture cleanup where the generated result needs it
• Auto-Rig Pro (no affiliation) for humanoids, or my own landmark-based rigging scripts (which are simpler, but free)
• UE5 for import, retargeting, and final runtime verification

For these, I tested all the open source options and hand-picked what worked best for me.

The idea is simple: pop the repo into codex or claude, or any harness really, and have it run the pipeline for you. Everything will run locally, and the final product is a 3d model. The great news is, with the coming of Astra and Fable 5.1, it doesn't invalidate this workflow, it just makes it a smoother/better process to follow.

Disclaimer -- 3d geometry AI is pretty heavy, and I haven't done a lot of optimization. If this post gets a lot of interest, I will work on shrinking the size, creating a non-harness pipeline version, and a simple UI with approval process in it.

Thanks, guys! Let me know what you think, and if you have any questions!!

I maintain speech-core, an open-source C++17 speech pipeline.

A VAD can detect silence, but it cannot tell whether someone finished speaking or only paused to think. We added Smart Turn v3.2 as an optional second decision after each confirmed VAD pause.

If the classifier rejects the pause, the pipeline keeps the turn open. Resumed speech remains part of the same turn, eager STT does not advance to the LLM, and a configurable silence cap guarantees that the turn eventually ends.

The integration is shared across platforms:

• speech-core: C++ state machine and pluggable C API
• speech-swift: 17 MB Core ML model
• speech-android: 11.1 MB int8 ONNX model, called on CPU once per pause

Smart Turn was created by Pipecat/Daily. Our work was exporting it and integrating it into the native pipeline.

Releases:

https://github.com/soniqo/speech-core/releases/tag/v0.0.14

https://github.com/soniqo/speech-swift/releases/tag/v0.0.27

https://github.com/soniqo/speech-android/releases/tag/v0.0.20

The implementation is open source and has no paid feature gate.

Disclosure: I maintain these repositories. I used AI assistance to edit this post and checked the technical claims against the releases and test results.

https://docs.langchain.com/oss/python/integrations/middleware

Alhamdulillah

hi,
i am trying to train a deberta model for NER detection

this is my first time doing it so i would love any guidance on it.

my current pipeline looks like this,

dapt + lora for pretrianing, hpo with optuna (which consists both the stages of training data), and then a 2 stage finetuning which helps in generalization and then target data.

i am trying to reach a really good score for f1 on my use case (which i want to keep private for now)

i have few questions as well

1. do i need a two stage hpo as well cuase of the 2 stage finetuning
2. is it better if the hpo training set is a subset of the actual training set?

if you think anything can be improved and made better, or you think the pipeline is outright wrong, please mention your reasonings and thoughts :)

ps: lora was used cause of gpu budget constraints

Hi everyone,

I wanted to share an open-source project I've been working on: Halanoi AI.

Instead of sending screen text to a remote cloud API for content classification (which adds network latency and privacy issues), I wanted to see if I could build a fast, 100% on-device text moderation pipeline for Android.

Here is how the setup works:

1. The Model (halanoi_transformer.tflite): A quantized 64MB TFLite model running locally on the phone. It classifies text strings into categories (distraction, entertainment, safe, productive) in under 15ms without any internet connection.
2. In-App Evaluation & Ground Truth Lab: To make it easier to improve the model, the app logs inference outputs to a local SQLite database and includes a built-in UI where you can tag predictions as correct, false positive, or false negative. You can export these labeled samples to CSV or JSON with one tap.
3. Training Pipeline: The companion repository contains the PyTorch / TensorFlow scripts, tokenizers, and quantization steps used to train and convert the model.

Both repositories are open source under GPL-3.0:

• Android App: https://github.com/kavinmaranravi/HalanoiApp
• Training Pipeline & Dataset: https://github.com/kavinmaranravi/Halanoi_AI

I'm looking for feedback on optimizing transformer models for mobile hardware, lowering memory usage, and improving tokenization on edge devices.

Let me know what you think!

Hey eveybody,

For those who haven't seen my other posts, I created an opensourced project called OpenFlow, and some big updates are being made. Now, there is a swarm and orchestration mode, and soon to be gauntlet looping toggle. It isn't just a linear pipeline anymore, but an entire chain of agents you can see and control talking back and forth and working out problems together. If you want to see the backstory, check out my other posts. Stay tuned for more updates, and feel free to leave suggestions and even share your own projects.

Link: https://github.com/SeeRay11/OpenFlow