Meterless im Test 2026: Ist der Context Layer für KI-Agenten produktionsreif?

Die virale Version lautet: Ein ehemaliger Anthropic Engineer habe Claude Cowork als Meterless open source veröffentlicht. Die öffentlich prüfbaren Fakten ergeben ein anderes, nützlicheres Bild. Meterless ist kein Open-Source-Klon von Cowork. Auch die Ex-Anthropic-Zuschreibung konnten wir bis 22. Juli 2026 weder im Repository noch auf der Projektseite oder in namentlich zuordenbaren Maintainer-Angaben belegen.

Meterless ist eine neu veröffentlichte Kontextarchitektur für KI-Agenten. Darunter liegen offene Spezifikationen, minimale Referenzimplementierungen und Conformance-Tests. Darüber liegen proprietäre Anwendungen. Genau diese Grenze entscheidet darüber, was ein CTO übernehmen kann und was das eigene Team noch bauen muss.

Was ist Meterless?

Meterless ist ein local-first Context Stack für KI-Agenten. Vier Engines trennen dauerhaftes Memory, gemeinsamen Weltzustand, begrenztes Reasoning für lange Aufgaben und Intent-Routing: H-MEM, World Model, Markovian und Scout Intent. Relevanter Kontext soll bestehen bleiben, während der Kontext pro Schritt begrenzt bleibt.

Das ist enger und interessanter als ein weiterer Agent-Framework-Claim. Meterless will die Schicht zwischen Modell und Arbeit strukturieren: Was erinnert der Agent? Was gilt aktuell als wahr? Welche Information braucht der nächste Schritt? Darf dieser Schritt überhaupt ausgeführt werden?

Meterless auf einen Blick

Ist Meterless Open Source?

Teilweise, mit einer klar beschriebenen Grenze. Das Meterless Context Repository steht unter Apache 2.0. Es enthält Spezifikationen, Referenzen, Beispiele, Dokumentation und Conformance-Material. Laut Repository bleiben die Anwendungs-Binaries von Gaia, Relay und Swarms proprietär.

Praktisch bedeutet das: Dein Team darf die Engine-Unterlagen verwenden, um eine eigene Implementierung zu bauen. Die vollständige Produkt-UX, Desktop-Automatisierung, Installer, Support und zukünftige Roadmap sind damit nicht automatisch unter Apache 2.0 verfügbar. Prüfe jedes Artefakt, das tatsächlich in Produktion gehen soll.

Wie funktioniert der Meterless Context Layer?

1. H-MEM entscheidet, was bleibt

Meterless H-MEM trennt Short-Term, Working und Long-Term Memory. Jeder Record kann Quelle, Confidence, Provenienz, Entitäten, Beziehungen und Ersetzungs-Linien tragen. Das Ranking kombiniert semantische Ähnlichkeit mit Keywords, Tags, Domain, Entitäten, Aktualität, Layer und Confidence. Änderungen landen in einem Trust Ledger.

Das adressiert die echten Produktionsfehler: Eine alte Aussage schlägt die Korrektur. Eine Zusammenfassung verliert die Quelle. Eine Löschung erreicht abgeleitete Erinnerungen nicht. Eine semantisch ähnliche Erinnerung ist für die aktuelle Entscheidung trotzdem falsch.

Wichtig für Suchmaschinen und LLM-Zitate ist die Namenskollision: Meterless H-MEM steht für die Hierarchical-Memory-Engine des Projekts. Ein separates Paper vom Mai 2026 namens H-Mem kombiniert einen temporal-semantischen Baum mit einem Knowledge Graph. Wir fanden keine öffentliche Aussage, dass dieses Paper Meterless validiert oder mit dem Projekt verbunden ist. Es ist kein unabhängiger Produktbeleg.

2. Das World Model hält gemeinsamen Zustand

Memory beantwortet: Was haben wir gelernt? Ein World Model beantwortet: Welche Personen, Dokumente, Aufgaben, Events, Beziehungen und Constraints existieren jetzt? Meterless spezifiziert stabile IDs, idempotenten Ingest, Provenienz-Prüfung, versionierte Speicherung, neu aufbaubare Views und eine Operator-Oberfläche.

Das kann verhindern, dass zwei Agenten für denselben Kunden oder Task unterschiedliche Wahrheiten erfinden. Der Preis ist Schema-Arbeit. Ohne Regeln für Identität, Merge, zeitliche Gültigkeit, Berechtigungen und Reparatur wird ein allgemeiner Graph zum Datenfriedhof.

3. Markovian hält den nächsten Schritt klein

Die Markovian Engine hängt nicht bei jedem Schritt den ganzen bisherigen Verlauf an. Sie übergibt konstantes Framing, Ziel, aktuellen Input und einen begrenzten Carryover. Im Projektmodell wächst der naive Input über lange Runs quadratisch, der begrenzte Carryover linear.

Das kann Token sparen. Es kann aber auch genau jenes Detail wegkomprimieren, das die nächste Entscheidung korrekt macht. Die richtige KPI lautet daher nicht kleinere Context Window. Sie lautet geringere Kosten pro erfolgreicher Aktion bei mindestens gleicher Task-Qualität, Konsistenz, Policy-Compliance und Wiederherstellbarkeit.

4. Scout entscheidet vor der Ausführung

Scout Intent zieht Intent, Ambiguität, Injection-Prüfung, Policy, Tool-Wahl und Modell-Routing vor die Ausführung. Der signierte Execution Contract ist interessant, weil nachgelagerte Schritte gegen den vereinbarten Scope geprüft werden können. Der Haken steht offen im Repository: Scout ist derzeit eine Implementierungsspezifikation mit Eval-Harness, kein installierbares npm-Paket.

Was beweisen 814, 86 Prozent und 97 Prozent Token-Ersparnis?

Das Meterless Effizienzmodell benennt die Grenzen fair: Die Zahlen sind modelliert, Kompression ist nicht kostenlos, Tool-Resultate variieren und echte Runs sollen nach Möglichkeit Provider-Usage verwenden. Diese Transparenz macht die Architektur glaubwürdiger. Sie ersetzt keinen unabhängigen Benchmark.

Ist Meterless eine Open-Source-Alternative zu Claude Cowork?

Nicht als direkt austauschbares Produkt. Anthropic beschreibt Cowork Projects als Desktop-Workspaces mit Dateien, Anweisungen, geplanten Tasks, Kontext und projektbezogenem Memory. Meterless veröffentlicht Kontext-Engine-Spezifikationen und bietet getrennte Produktoberflächen. Beide wollen Arbeit über Sessions fortsetzen, lösen aber nicht denselben Beschaffungsfall.

Ist Meterless produktionsreif?

Meterless ist bereit zum Studieren und Pilotieren, nicht zur ungeprüften Übernahme als Produktions-SDK. Drei Engines haben lauffähige Referenzen. Scout hat Spezifikation und Eval-Harness. Dazu kommen Conformance-Tests. Gleichzeitig sagt das Projekt klar, dass die Referenzen minimal sind und Teams die Produktionsengine im eigenen Stack bauen.

Für Produktion fehlen noch deine Belege zu Zugriffskontrolle, Tenant-Isolation, Verschlüsselung, Aufbewahrung, Löschung, Backup, Migration, Parallelität, Latenz, Observability, Recovery und Operator-Review. Memory muss direkt evaluiert werden. MEMPROBE zeigt, warum Task-Erfolg allein nicht reicht: Ein Agent kann Aufgaben lösen und trotzdem einen unvollständigen oder falschen Nutzerzustand hinterlassen.

Ein Zwei-Wochen-Pilot für Meterless

1. Wähle einen wiederholten Workflow mit 8 bis 20 Schritten. Zum Beispiel Support-Recherche, Account Research, Compliance-Evidenz oder Repository-Triage.
2. Frieren den Ausgangswert ein. Miss Task-Erfolg, Token, Latenz, Retries, Korrekturzeit und Tool-Fehler des bestehenden Agenten.
3. Beginne mit einer Engine. H-MEM bei Vergessen über Sessions. Markovian bei zu großer Historie. Nicht alles gleichzeitig integrieren.
4. Baue adversariale Memory-Fälle. Korrekturen, abgelaufene Fakten, Konflikte, Rechteentzug, Löschung und vergiftete Erinnerungen.
5. Bewerte blind. Reviewer kennen nicht, ob Baseline oder Meterless das Ergebnis erzeugt hat.
6. Prüfe Trace und gespeicherten Zustand. Was wurde warum abgerufen, was komprimiert, blieb die Quelle erhalten?
7. Entscheide anhand messbarer Wirkung. Nur weitermachen, wenn Kosten pro erfolgreicher Aktion, Reliability oder Kontrolle den zusätzlichen Betrieb rechtfertigen.

Wann lohnt sich ein Build auf Meterless?

Die Spezifikationen passen, wenn Kontext bereits ein messbarer Engpass ist, lokaler oder portabler Zustand wichtig wird, dein Team ein Memory- und Graph-System besitzen kann und der Workflow wertvoll genug für Evals und Operator-Tools ist. Für einen frühen Prototyp mit wenigen kurzen Interaktionen ist das meist zu viel Architektur.

Bei Agenten mit Kundendaten, Freigaben, Geld oder regulierten Abläufen wird Memory zu einem Governance-Datensystem. Unsere Entwicklung von KI-Agenten und KI-Produkten beginnt deshalb mit einer messbaren Geschäftsaktion. Die Hyperstate-AI-Fallstudie zeigt unseren Architekturansatz. Der Leitfaden zur Discovery Phase erklärt, wie die riskantesten Annahmen vor dem Build geprüft werden.

Kommerzielle Offenlegung: Wavect verkauft AI-Architektur und Implementierung. Darum interessiert uns diese Kategorie. Darum legen wir auch Ablehnungskriterien offen. Wenn der Pilot keinen messbaren Wert zeigt, solltest du weder Meterless noch unsere Leistung kaufen.

Fazit

Meterless hat die richtige These: Dauerhaftes Memory, geteilter Zustand, begrenztes Reasoning und Routing vor der Ausführung sind oft wichtiger als ein immer größerer Prompt. Das Repository ist substanzieller als eine Landingpage, weil es Specs, Referenzen, Beispiele, Conformance-Material und ehrliche Benchmark-Grenzen enthält.

Das Projekt ist trotzdem jung. Der virale Claim übertreibt Cowork-Bezug und Open-Source-Umfang. Die Token-Zahlen erklären ein Effizienzmodell und eine deterministische Demo, nicht unabhängige Produktionsergebnisse. Behandle Meterless als prüfbare Architektur, messbaren Pilot und mögliche Grundlage, die dein Team noch produktionsreif bauen muss.

Primärquellen und Recherchedatum

Stand 22. Juli 2026. Geprüft wurden das Meterless Repository, die Engine-Dokumentation für H-MEM, World Model, Markovian und Scout Intent, das Memory-Beispiel, die Apache-2.0-Lizenz, Anthropic zu Cowork Projects und das unabhängige MEMPROBE-Paper. Vor einer Beschaffung erneut prüfen.