Here is my current project status, it has become quite extensive in the meantime.

https://github.com/unikum-sol/brainstem/blob/main/Project\_Status\_2026-09-28.md

I look forward to feedback and discussions.

Here is a small excerpt:

„BrainStem is a self-learning language-understanding system designed to acquire sentence-, word-, and relation-level structure from an unsegmented text corpus purely through statistical observation, without word lists, grammars, or filters. The system’s stated design principle is that every unit of knowledge, a sentence-level hypothesis, a word boundary, a relation between two entities, a category, or a question, begins as a low-confidence, fully correctable hypothesis, and only becomes a durable fact, relation, category, or question after surviving a multi-cycle, neuromodulator-gated consolidation process modeled on biological sleep-dependent memory consolidation.”

https://github.com/unikum-sol/brainstem

Immer mehre Menschen kommunizieren mit der KI über Sprache. Die letzten Jahre haben sich die Fähigkeiten enorm verbessert bis hin zur perfekten Dialekterkennung wie dieses Video zu den Schwierigkeiten eines Sprachassistenten eindrücklich zeigt. Es gibt Software zur lokalen Spracherkennung wie z.B. Whisper, die auf dem eigenen Rechner läuft, diese kann aber mit dem im Video gezeigten Möglichkeiten nicht mithalten. Systeme, die zentral die Sprachen vieler tausend Sprecher zentral sammeln und sich ständig anpassen, sind hier im Vorteil.
Eine sehr große Herausforderung ist auch das gleichzeitige Sprechen und Zuhören so wie die Antwort in Echtzeit.

Eine weitere große Herausforderung ist die Mikrophontechnik. Sprachverständnis in Räumen mit vielen Personen, die gleichzeitig sprechen ist eine große Herausforderung. Mittlerweile gibt es hier Raummikrophone einiger Hersteller für Videokonferenzen. Diese können aber noch nicht mit der Richtungscharakteristik des menschlichen Ohrs mithalten. Ein sehr eindrückliches englischsprachiges Videos zu dieser Eigenschaft findet sich hier.

Die große Frage ist: Wie lässt sich ein sehr gutes Spracherkennungssystem entwickeln, ohne die Privatsphäre der Menschen zu verletzen.

Black Forest Labs, the lab behind the FLUX image models, just moved into robotics. They released FLUX 3 Action, a 7B world action model. It predicts future video frames and the robot's next actions in the same forward pass.

Numbers from their report and the model card:

• RoboLab-120: 42.92%, first place. Cosmos3-Nano-Policy (16B) scores 36.8% and π0.5 (3.3B) scores 28.0%.
• Size: 56% fewer parameters than Cosmos 3 Nano.
• Speed: up to 3.95x faster than Cosmos 3 Nano in FP8 (1.52x to 3.95x depending on GPU).
• Planning: each call plans 32 actions at 15 Hz, which is 2.13 s of motion. π0.5 plans 1.0 s per call.
• Real robot: a blind third-party test on a Franka arm completed 28/30 attempts. Cosmos 3 Nano got 27/30, DreamZero 20/30 and π0.5 13/30.
• Pretraining: without video pretraining, DROID-only training stayed under 1% on RoboLab.

Running it:

• It needs about 32 GB in BF16, or fits 24 GB cards with FP8 and text encoder offload.
• There are 3 checkpoints: base, guidance-distilled, and a 1-step distilled version.
• It's natively in LeRobot, with an SO-101 LoRA recipe. Their docs show an SO-101 pick-and-place task learned from about 200 demos.
• NVIDIA helped with Jetson support.

Caveats, before someone else posts them:

• License: it's open weights under the FLUX Kommunity License, not Apache or MIT. Non-commercial use is free, and companies under $5M revenue can use outputs commercially. Everyone else needs a paid license.
• Speed vs π0.5: the 1-step model beats π0.5 on real-time factor on datacenter and workstation GPUs, but is slower than π0.5 on an RTX 5090.
• Hard tasks: some tasks (ordered block stacking, pumpkins in clutter) still fail without a reasoning model in the loop. Their hybrid with GPT 6 Astra reached 90% of episodes at $8.77 per success.

The part I find most interesting is that an image and video lab reached #1 on a robotics benchmark mostly through video pretraining. Is joint video and action prediction where robot policies are heading, or will VLAs catch up once they're scaled?

Full analysis: https://www.marktechpost.com/2026/09/24/black-forest-labs-releases-flux-3-action-a-7b-open-weights-world-action-model-that-tops-robolab-120/

Report: https://bfl.ai/models/flux-3-action

Weights: https://huggingface.co/collections/black-forest-labs/flux-3-action

Besonders wichtig sind Kraftsensoren für die Robotik. Insbesondere in Roboterhänden ermöglicht das stark verbessertes Greifen. Ein Beispiel sind die Roboterhände von PaXini die auf der Erfassung von Magnetfeldern mit Hall-Sensoren basieren.
Hier gibt es ein recht ausführliches Video von Leonard Schmedding zum Thema.
Video zur Anwendung von Kraftsensoren in der humanoiden Robotik

Die humanoiden Roboter sind eines der großen Zukunftsfelder. Es fließen Milliarden an Investorengeldern in diesen Bereich und jetzt starten verschiedene Firmen die Massenproduktion. Ganz vorne ist China, aber auch Tesla hat in Fermont eine Teslafabrik für die Produktion ihres Optimus-Roboters umgerüstet.

Unternehmen	Geplante/Jährliche Produktion	Standort / Hinweis
UBTECH Robotics	> 10.000 Einheiten/Jahr	Liuzhou (Guangxi) – Taktung: 1 Roboter alle 10 Min.
Figure AI	Bis zu 12.000 Roboter/Jahr	USA – BotQ-Fabrik
AgiBot	Mehrere Tausend (bereits erreicht)	Shanghai – Start-up
XPENG Motors	Nicht spezifiziert	Guangzhou – 110.000 m² Fabrik für volle Produktionskette
Tesla	Nicht spezifiziert	USA/China – Fokus auf Kostensenkung auf 20.000 $
Bosch	Ca. 100 Roboter	Bühl (DE) – Serienlinie in Planung
Agibot	Nicht spezifiziert	Serbien – Logistiktor für den europäischen Markt

Nachdem 2024 das Konnektom (Verbindungsplan der Neuronen) bekannt war, kommt man nun auf allerlei kreative Ideen, was man damit machen könnte.
Besonders interessant ist dabei die Steuerung eines Schachspiels. Wer es ausprobieren will, kann das online tun:
https://flychess-hq.vercel.app/

• Oktober 2024 (Das weibliche Gehirn): Das internationale FlyWire-Konsortium veröffentlichte nach jahrelanger Arbeit das erste vollständige Konnektom eines adulten (weiblichen) Fruchtfliegengehirns. Es umfasst rund 139.255 Neuronen und circa 54,5 Millionen Synapsen. [1, 2]
• September 2026 (Das männliche Zentralnervensystem): Forschende des HHMI Janelia Research Campus sowie von Google Research machten den nächsten riesigen Schritt. Sie kartierten das komplette Zentralnervensystem einer männlichen Fruchtfliege (BANC-Datensatz) mit über 166.000 Neuronen. Dieses enthält neben dem Gehirn auch das Bauchmark – das Insekten-Äquivalent zum menschlichen Rückenmark. [1, 2, 3, 4]

TLDR: huggingface_hub ships a hidden agent detection module that fingerprints which AI coding tool is driving your session (Cursor, Copilot, Claude Code, etc.) by scanning your environment variables against a cached registry of 26 known agents. It sends the result as a telemetry header on every Hub API call — so any library that touches HF (faster-whisper, transformers, etc.) silently reports your toolchain. Found it while tracing an unauthorized network connection from a local ASR model. Block it with HF_HUB_OFFLINE=1 or by using local file paths instead of model names.

I run a local AI project with several models (TTS, ASR, vision) and recently built a Python-level network firewall to lock down all outbound traffic. During the audit, I found something I wasn't expecting.

The discovery

While tracing an unauthorized HTTPS connection to huggingface.co, I found a file in my HF cache directory I'd never seen before:

~/.cache/huggingface/.agent_harnesses.json

It's a 6 KB JSON file containing a registry of 26 AI coding agents — Claude Code, Cowork, Cursor, Copilot, Gemini CLI, Devin, Cline, Goose, Codex, and many others. Each entry lists the environment variables that agent sets when it's running:

json

{
  "standardEnvVars": ["AI_AGENT", "AGENT"],
  "harnesses": {
    "cursor": {
      "prettyLabel": "Cursor",
      "envVars": {"CURSOR_TRACE_ID": "*"}
    },
    "claude-code": {
      "prettyLabel": "Claude Code",
      "envVars": {"CLAUDECODE": "*", "CLAUDE_CODE": "*"}
    },
    "github-copilot": {
      "prettyLabel": "GitHub Copilot",
      "envVars": {"COPILOT_MODEL": "*", "COPILOT_GITHUB_TOKEN": "*"}
    }
    // ... 23 more agents
  }
}

What it does

The huggingface_hub library (the Python package, not the website) has a module called _detect_agent.py. Here's the flow:

1. It fetches the agent registry from {HF_ENDPOINT}/api/agent-harnesses and caches it as .agent_harnesses.json
2. The cache refreshes every 24 hours
3. On every Hub API call, detect_agent() scans your environment variables against the registry to identify which AI coding tool is running
4. The detected agent name is sent as a telemetry header on the API request
5. This feeds Hugging Face's public agent usage dataset

So if you're using Cursor and it calls any HF library that goes through huggingface_hub — downloading a model, checking for updates, loading a tokenizer — HF knows it was Cursor making that call, not you directly. Same for Claude Code, Copilot, Devin, or any of the other 26 agents in the registry.

How I found it

I was investigating why my ASR module (faster-whisper) was phoning home to huggingface.co on import. The call chain turned out to be:

my_code → WhisperModel("base.en") → faster_whisper → huggingface_hub.snapshot_download → HTTPS to huggingface.co

The trigger: passing a model name instead of a local file path. When you give faster-whisper a name like "base.en", it calls huggingface_hub to check for updates — even if the model is already cached locally. And during that check, it also sends the agent fingerprint.

The .agent_harnesses.json file was the agent registry cached from that call. Modified today, before I built the firewall.

How to block it

Option 1: Environment variables

bash

export HF_HUB_OFFLINE=1
export TRANSFORMERS_OFFLINE=1
export HF_HUB_DISABLE_TELEMETRY=1

The first two prevent any network calls. The third specifically targets telemetry but may not cover the agent detection header.

Option 2: Use local paths, not model names Instead of:

python

model = WhisperModel("base.en")

Use:

python

model = WhisperModel("/path/to/local/model/")

When you pass a directory path, faster-whisper (and most HF-backed libraries) skip the Hub entirely.

Option 3: Network-level blocking I built a Python-level firewall that wraps socket.connect, socket.connect_ex, socket.create_connection, and getaddrinfo. It activates via a sitecustomize hook before any imports, so the phone-home attempt is caught before the library even finishes loading. Any connection to a host not on the allowlist raises ConnectionRefusedError.

What's in the cached file

No credentials. No API keys. Just the registry of agent names and their environment variable signatures. The file itself is harmless — it's the use of it as a fingerprinting mechanism that's the issue.

You can safely delete it:

bash

rm ~/.cache/huggingface/.agent_harnesses.json

It won't come back if you set HF_HUB_OFFLINE=1.

Why this matters

If you're running local models specifically to keep things private, you should know that the library layer between you and those models may be reporting metadata about your toolchain back to Hugging Face. This isn't about model weights or your data — it's about which AI tools you use and when, aggregated into a public dataset.

The agent registry is maintained in the u/huggingface/tasks npm package and served via the Hub API. New agents register by PR. It's not hidden — but it's also not something most users know is happening when they pip install a model-loading library.

To be clear, I don't think this is malicious. HF is probably tracking agent ecosystem adoption for business intelligence. But silent fingerprinting of your dev tools without an opt-in prompt is exactly the kind of thing that erodes trust in the ecosystem, especially for people who chose local models for privacy reasons.

https://github.com/paulknysh/raggy

A lightweight CLI tool for Retrieval-Augmented Generation (RAG) over local documents built with Ollama. Hybrid database (vector + BM25 index) and embedding generation run fully locally. Answer generation can run either via a local LLM or remotely using an API key. raggy supports most common document formats and handles images/scans automatically via OCR.

Eine Idee mit humanoiden Robotern Geld zu verdienen, ist Bewegungsabläufe zu verkaufen (vielleicht so ähnlich wie früher Klingeltöne).
Wie die Roboter trainiert werden, sieht man hier:
https://www.youtube.com/watch?v=_uav5s18CwQ

Es gibt den Petoi Padle Mini Roboterhund als Crowdsourcing Projekt.
Es gibt ein Video.

======== Hardeware ==========

ESP32-S3FN8 Motion Core Wi-Fi Bluetooth

4× Servos

Gyroscope

PIR Sensor

4× Touchpads

4× RGB LEDs

2× Microphones

Buzzer

Raspberry Pi UART Port

BL10C Battery, 1800 mAh

USB Type-C Port

Optional Raspberry Pi Zero

Wesentlich weniger bekannt als Neura Robitcs ist die Firma Agile Robots, die aber mit 1.5 Milliarden Euro eingesammeltem Kapital ähnlich gut finanziert ist.

Gegründet wurde die Firma 2018 mit einigen Forschern des Zentrums für Luft und Raumfahrt und hat mittlerweile weltweit 3500 Mitarbeiter. Der Hauptsitz ist in München. Das wesentliche Ziel sind humanoide Roboter für die Automatisierung In der Industrie.

Ich bin Software Entwickler und Unternehmer und ich hasse Steuererklärungen.

Ich hab hin und her mit GPT-6-Astra geschrieben um einen vernünftigen weg zu finden, dass GPT mir meine Steuererklärungen anfertigen kann. Das hat besser geklappt als gedacht.

Die Finanzverwaltung veröffentlicht jährlich den ERiC Client, das ist quasi die Schnittstelle die alle Steuerprogramme benutzen um Steuererklärungen zu erstellen. Das ganze ist aber nur eine Schnittstelle und benötigt einen Wrapper drumherum zum bedienen.

Eine graphische Benutzeroberfläche ist quatsch zur Bedienung mit KI (obwohl frontier-llms das ebenfalls extrem gut können), daher hat GPT-6 im ersten schritt eine agentenfreundliche CLI drumherum erstellt. Das heißt, GPT tippt die befehle in mein Mac terminal und im Hintergrund werden die Erklärungen über die Schnittstelle geprüft, erstellt und versendet.

Damit in zukünftigen Chats die CLI besser verwendet werden kann, hab ich einen SKILL erstellen lassen, der jedem Agenten eine Anleitung gibt wie man sie am besten verwendet. Das macht das ganze effizienter, schneller und kostengünstiger, weil Rückfragen und Recherche der KI zur Bedienung eingespart werden.

Da ich mit Lexoffice arbeite, hab ich meine Daten exportiert und ihm zur Verfügung gestellt, anbei der prompt, seine Antwort, und die Vorschau der Erklärung:

https://imgur.com/a/yYSoWOk

Nach einigen rückfragen, vielen tool calls und Recherche hatte ich innerhalb von 30 Minuten meine vollständig geprüften und plausiblen Körperschaftsteuer-, Umsatzsteuer-, Gewerbesteuererklärungen und die e-Bilanz versendet.

Wir leben in großartigen Zeiten.

Come check it out yourself

Training code: https://github.com/franciscocarloserra/ttslibre

Weights & Training sets: https://huggingface.co/FranciscoCarlosErra/ttslibre-poc-en

It's still glitchy and robotic but I'm mind blown about the PoC

Es hat eine gewisse Ästhetik, die offene Mechanik eines humanoiden Roboters zu sehen.
In diesem Video mit gut unterlegtem Synthesizer-Beat erzählt Figure-AI vom Ausbau seiner neuen Rechenkapazitäten.

In diesem Video wird AlbertPro vorgestellt. Der Roboter ist mit einem ESP32 ausgestattet und wurde im Schwarm trainiert.

Das GitHub Repository für den Roboter findet sich hier.

The idea: Agents keep the conversation history as part of their input while they reason. SKILL.state proposes to replace that with a structured representation of the current state, and the latest observation.

While the agent reasons through the problem, it writes information it deems useful for future steps into the state. Then it discards the conversation history. So the input size remains roughly the same as the session goes.

They ran a 100-step benchmark with Gemini-3-Flash:

• SKILL.state: 0.94 accuracy using 65k tokens
• LangGraph-style stateful baseline: 0.91 accuracy using 1.1m tokens

Caveat: This works best if the agent can understand what it will need in the future steps, otherwise that information will not be written, so it'll have to retrieve it again.

Link to the paper: https://arxiv.org/abs/2608.26263

Der hörenswerte Beitrag Deutschlandfunk Podcast "Wirtschaft trifft Geschichte" analysiert in seinem Beitrag Führt uns die KI in eine Job-Apokalypse? die Auswirkungen der KI-Technologie auf den Arbeitsmarkt.

Die vielleicht interessanteste Aussage ist, dass die momentane Zurückhaltung der Einstellung von Berufseinsteigern in Deutschland nicht der KI-Technolgie geschuldet ist, sondern der allgemeinen schlechten wirtschaftlichen Lage.

Der Beitrag ist etwas umfangreich, deshalb hier die Zusammenfassung (mit Hilfe des kleinen, lokalen Gemm4-E4B Modells erstellt):

**10 Wichtigste Aussagen zur Debatte "KI und Arbeitsmarkt"**

1. **Historischer Zyklus statt Apokalypse:** Die Angst vor technologischer Entmachtung ist nicht neu. Während die *Technologie* (von der Dampfmaschine bis zur KI) neu ist, ist die *Angst* vor der Verdrängung von Arbeit durch Maschinen ein uraltes menschliches Phänomenon.

2. **KI als Werkzeug, nicht als Ersatz:** Die Technologie ist kein "Alleskönner", sondern ein Werkzeug. KI kann Aufgaben (z.B. Datenauswertung, Code-Schreiben) übernehmen, aber die Interpretation, das Urteil und die Entscheidung (die "Soft Skills") bleiben der menschlichen Arbeitskraft vorbehalten.

3. **Die "Lump of Labor Fallacy" (Fehlschluss der Arbeitsmenge):** Es gibt keine universelle Annahme, dass technologische Neuerung *immer* zu Arbeitsplatzverlust führen wird. Historisch gesehen haben Technologien meist mehr Arbeitsplätze geschaffen, als sie vernichtet haben.

4. **Die Natur des Wandels:** Der technologische Wandel ist ein Prozess, der langsamer verläuft, als oft befürchtet wird. Während die *Geschwindigkeit* der Technologie zunimmt, sind die *Vorgänge* oft noch nicht vollständig durchgeplant.

5. **Der Unterschied zwischen "Tätigkeit" und "Job":** Während bestimmte *Tätigkeiten* (z.B. bestimmte Buchhaltungsaufgaben) automatisiert werden, ist nicht immer der *Job* komplett verschwunden. Es verschieben sich oft die Anforderungen und die Tätigkeitsfelder.

6. **Die "Human-Factor"-These:** Die Zukunft der Arbeit liegt in der Kombination von Technologie und menschlichen Fähigkeiten. Fähigkeiten wie Urteilsvermögen, Empathie, soziale Kompetenzen oder Kreativität sind besonders wertvoll, da diese nicht von Maschinen repliziert werden können.

7. **Die Rolle von KI-Unternehmen:** Kritische Betrachtung der "Job-Apokalypse": KI-Unternehmen nutzen manchmal die Angst vor Jobverlusten, um die eigenen Produkte und Geschäftsmodelle zu verkaufen. Das ist ein ökonomisches Interesse.

8. **Vom Schock zur Anpassung:** Die historische Erfahrung zeigt, dass Technologie nicht primär Arbeitsplätze *vernichtet*, sondern *transformiert*. Dies erfordert jedoch eine ständige Anpassung der Gesellschaft an neue Berufsfelder (z.B. von der Textproduktion zum Prompt-Engineer).

9. **Die Kluft der "Entry-Level" Jobs:** Ein zentraler Kritikpunkt ist, dass die Arbeitsmarktstatistiken die Situation von Berufsanfängern (Entry-Level) nicht korrekt abbilden. Schwierigkeiten bei der Jobsuche können hier durch strukturelle Probleme und nicht durch KI allein verursacht werden.

10. **Die notwendige Reaktion:** Stattdessen ist die Reaktion auf den technologischen Wandel die aktive Neugestaltung von Arbeit und die Förderung von *lernender* Arbeitskraft – statt der Verweigerung ("Luddites").

Schon länger bekannt ist der Roboter Reachy-Mini von Pollen Robotics.

Die Firma hat jetzt den Roboter Microduck (Video) herausgebracht.

Hardware Spec:

Motorik: 15 degrees of freedom

Front Kamera

8x8 LiDAR,

2xIMUs,

Microphone

Lautsprecher

NFC

Wi-Fi

Bluetooth

Im Gegensatz zu Sony mit dem Roboterhund Aibo vor einigen Jahren sind die Roboter von Pollen Robotics Open-Source, so dass viele kreative ihre Ideen einfließen lassen können.

Eine Vorreiterin der Roboter mit Entenwattschelgang war Maria mit ihrem FlapFlap Roboter.