Eliza 2026: Wird aus dem KI-Framework ein Betriebssystem?
Der Token ist tot, doch das Eliza-Framework nennt sich jetzt Betriebssystem und gewinnt erste zahlende Kunden. Was hinter dem Post-Token-Pivot steckt und ob er trägt.
Der Token ist tot, das Etikett ist neu
„The token is dead. Completely.“ Mit diesem Satz beendete Gründer Shaw Walters am 5. August 2026 auf X die Marktgeschichte eines Coins, der Anfang 2025 rund 2,4 Milliarden US-Dollar (gut zwei Milliarden Euro) wert gewesen war. Die Eliza Foundation löste sich auf, das verbliebene Treasury floss in einen Vergleich mit der Kanzlei Burwick Law. CoinDesk nannte es das Ende eines der bekanntesten KI-Agenten-Projekte der letzten zwei Jahre.
Wer danach das Verschwinden der Software erwartet hatte, irrt. Einen Monat später beschreibt sich das Repository elizaOS/eliza auf GitHub nicht mehr als Framework, sondern als „Your agentic operating system“, ein quelloffenes agentisches Betriebssystem. Der Code ist quicklebendig: rund 19.200 Sterne, ein Release-Schub bis in den 23. August, dokumentierte Aktivität im Hauptzweig noch am 29. August 2026. Das GitHub-Repository trägt die MIT-Lizenz und ist in TypeScript geschrieben.
Parallel meldete ein börsennotierter Partner Bewegung: Secure Blockchain verkündete über die Tochter Agentic Solutions Anfang August seinen ersten zahlenden Unternehmenskunden für eine private Agentenumgebung. Der Auftrag markiert den Übergang von der Entwicklung zum kommerziellen Betrieb.
Damit stellt sich die Frage, um die es hier geht: Ist „agentisches Betriebssystem“ eine echte Produktkategorie, oder ist es das Etikett, mit dem ein Projekt seiner toten Währung entkommt? Der Kurs erzählt das eine, der Quellcode das andere. Dass Frameworkqualität und Tokenkurs zwei getrennte Dinge sind, war bei Eliza immer der Kern der Geschichte. Jetzt wird dieser Satz zur Geschäftsstrategie.
Was ein agentisches Betriebssystem sein soll
Ein Betriebssystem verwaltet Ressourcen, plant Prozesse, vermittelt zwischen Software und Hardware und stellt eine stabile Schnittstelle bereit, damit Programme nicht jedes Mal das Rad neu erfinden müssen. Überträgt man dieses Bild auf autonome KI-Agenten, ergibt sich die Metapher, die elizaOS für sich beansprucht: Die Laufzeitumgebung (Runtime) ist der Kernel, Plugins sind Treiber und Systemaufrufe, ein Agent ist ein Prozess, der Speicher funktioniert wie ein Dateisystem, und das Sprachmodell ist die austauschbare Rechenhardware.
Konkret läuft jede Nachricht durch eine dreistufige Pipeline. Sogenannte Providers reichern den Kontext an, den das Modell sieht; das Modell wählt daraufhin aus einer Menge von Actions, also ausführbaren Fähigkeiten wie einem Token-Swap oder einem API-Aufruf; anschließend laufen Evaluators, die das Ergebnis bewerten und den dauerhaften Speicher aktualisieren. Dieses Muster ist der Grund, warum das Projekt sich nicht mehr nur als Bibliothek versteht, sondern als Umgebung, in der Agenten leben.
Die Idee ist nicht exotisch. In der Forschung kursiert das Konzept eines Agenten-Betriebssystems für Sprachmodelle seit 2024, etwa im vielzitierten AIOS-Papier, das einen Scheduler und eine Speicherverwaltung für Agenten skizziert. Der Unterschied bei elizaOS ist der Anspruch, das Ganze quelloffen, chain-fähig und selbst betreibbar zu liefern statt als geschlossenen Cloud-Dienst. Ob das die Bezeichnung Betriebssystem rechtfertigt oder ob es ein besonders ehrgeiziges Framework bleibt, ist genau die strittige Frage.
Was tatsächlich in der Box steckt
Zwischen Anspruch und Auslieferung lohnt der nüchterne Blick. Der Kern liegt in einem Monorepo, das mehr bündelt als eine reine Agentenbibliothek: die Runtime, eine App-Schicht, ein Kommandozeilen-Werkzeug (CLI), eine Cloud-Komponente, Brücken zu nativen Plattformen und eine Reihe von Erstanbieter-Plugins. Die Versionslinie v2.0.x wurde über das Jahr 2026 stabilisiert; die Entwicklung lief bis in den Spätsommer ohne Unterbrechung weiter, mit hunderten offenen Issues und Pull Requests als Zeichen eines aktiven, aber auch unfertigen Projekts.
Wörtlich als Betriebssystem gemeint ist ein zweites, separates Repository namens elizaOS/os. Es beschreibt sich als agentisches Betriebssystem auf Basis von elizaOS, Android Open Source und Debian Linux, also als Linux-Distribution mit Agenten im Zentrum. Der Realitätscheck: Dieses Repository zählt bislang gerade einmal rund 15 Sterne. Es ist eine Absichtserklärung, kein ausgeliefertes Produkt. Wer heute von einem agentischen Betriebssystem spricht, meint praktisch das Framework mit OS-Ambition, nicht ein installierbares OS für den Massenmarkt.
Diese Ehrlichkeit ist wichtig, weil die Kluft zwischen Marketing und Codebasis bei Eliza schon einmal teuer war. Der Vorwurf der Sammelklage lautete im Kern, dass die versprochene Autonomie nie existierte. Beim OS-Label sollte man denselben Maßstab anlegen: Was ist ausgeliefert, was ist Roadmap?
Framework, Plattform oder Betriebssystem? Wo die Rivalen stehen
Um die Kategorie zu verstehen, hilft der Vergleich mit den Nachbarn. Nicht jedes Agentenprojekt will dasselbe sein. Einige bleiben bewusst Werkzeugkasten, andere bauen einen Marktplatz, wieder andere ein Betriebssystem.
| Projekt | Selbstverständnis | Monetarisierung | Token |
|---|---|---|---|
| elizaOS | Agentisches Betriebssystem | Dienstleistungen, White-Label-Produkte, Forks | tot (August 2026) |
| Virtuals Protocol | Launchpad und Plattform | Ausgabe- und Handelsgebühren | VIRTUAL (~463 Mio. USD) |
| Olas (Autonolas) | Netzwerk für Agenten-Dienste | Marktplatzgebühr, Governance | OLAS |
| LangChain | Framework und SDK | kommerzielle SaaS-Schicht, Enterprise | kein Token |
| CrewAI | Multi-Agenten-Framework | Enterprise-SaaS, Cloud | kein Token |
LangChain und CrewAI verdienen Geld mit kommerziellen Schichten über einem offenen Kern (Beobachtbarkeit, Hosting, Enterprise-Support), ohne je einen Token ausgegeben zu haben. Virtuals Protocol ist im Kern ein Launchpad, das an Ausgabe und Handel von Agenten-Token verdient; sein VIRTUAL-Token bringt laut CoinGecko noch rund 463 Millionen US-Dollar auf die Waage. Olas betreibt einen Marktplatz für Agenten-Dienste mit einer Protokollgebühr. elizaOS ist der Sonderfall: Es hatte einen Token, hat ihn verloren und setzt nun ausschließlich auf Software und Dienstleistungen. Genau deshalb ist die OS-Frage für Eliza existenzieller als für die anderen.
Warum das OS-Label nach dem Token-Tod wichtiger wird
Solange ein Token existiert, hat ein Projekt einen Spekulations-Motor. Aufmerksamkeit lässt sich in Kurs übersetzen, Kurs in Schlagzeilen, Schlagzeilen in Entwickler. Fällt dieser Motor weg, muss die Software aus eigener Kraft relevant bleiben. Das OS-Label ist der Versuch, genau diese Relevanz zu behaupten: nicht „kauf den Token“, sondern „bau auf der Plattform“.
Die Zahlen zeigen, wie tief der Fall war und wie klein die verbliebene Marktrelevanz des Tokens ist.
| Kennzahl | Stand 30. August 2026 |
|---|---|
| ELIZAOS-Kurs | ~0,00018 EUR (~0,00021 USD) |
| Marktkapitalisierung ELIZAOS | ~1,3 Mio. EUR (Rang ~2.500) |
| Abstand zum Hoch (Januar 2025) | mehr als 99,9 Prozent |
| GitHub-Sterne (elizaOS/eliza) | ~19.200 |
| Sektor KI-Agenten gesamt | ~2,7 Mrd. EUR (~3,09 Mrd. USD) |
| OS-Distribution (elizaOS/os) | ~15 Sterne (frühe Phase) |
Der ELIZAOS-Token notiert laut CoinGecko bei rund 0,00018 Euro und bringt gut 1,3 Millionen Euro Marktkapitalisierung auf die Waage, Rang jenseits der 2.500. Vom Hoch Anfang 2025 trennen ihn mehr als 99,9 Prozent. Der breitere Sektor der KI-Agenten-Token steht bei rund 2,7 Milliarden Euro und damit unter dem Niveau vom Jahresanfang. Der Kontrast ist der eigentliche Befund: Während die Token schrumpfen, wächst die Codebasis. Diese Divergenz, Infrastruktur wächst und Spekulationsobjekt stirbt, ist das Leitmotiv des Sektors 2026 und der Grund, warum manche Teams offen sagen, sie wollten nie wieder einen Token in die Nähe ihres Produkts lassen.
Wer wirklich darauf baut
Ein Betriebssystem ist nur so viel wert wie das, was darauf läuft. Hier hat Eliza nach dem Hype-Ende paradoxerweise die interessanteste Phase: Der laute Teil der Community ist weg, der leise, kommerzielle Teil bleibt.
| Akteur | Was er tut | Bezug zu Eliza | Signal |
|---|---|---|---|
| Secure Blockchain / Agentic Solutions | White-Label-Produkt Agentic SME für KMU; erster Enterprise-Auftrag (August 2026) | Entwicklungsvertrag mit der Eliza Foundation, Produkt auf offenem elizaOS | Kommerzialisierung |
| Nethermind | eigener Fork der Plugin-Registry | Ethereum-Infrastrukturteam pflegt Registry | Ernstnahme durch Infra-Teams |
| Automata Network | Registry-Fork plus DCAP-Plugin (TEE-Attestierung) | Proof-of-Agent via Intel DCAP | Vertrauens- und Sicherheitslayer |
| Shaw Walters / Eliza Labs | Weiterentwicklung des Kern-Stacks, kein Token | IP-Eigentümer, Hauptmaintainer | Kontinuität trotz Foundation-Ende |
Am konkretesten ist Agentic SME, ein Produkt der börsennotierten Secure Blockchain und ihrer Tochter Agentic Solutions. Der Entwicklungsvertrag mit der Eliza Foundation sieht ein weiß etikettiertes Agentenprodukt für kleine und mittlere Unternehmen vor, gebaut auf dem offenen elizaOS, kundenseitig betreibbar; das Eigentum am fertigen Produkt liegt bei Agentic, nicht am Framework. Anfang August meldete das Unternehmen seinen ersten zahlenden Auftrag, eine private Agentenumgebung für einen australischen Großhändler. Geschäftsführer Steven Bryson-Haynes sagte, Unternehmen suchten zunehmend praktische Wege, KI sicher mit den eigenen Daten zu nutzen; der Auftrag sei bewusst eng gefasst, aber als Fundament für den Ausbau gedacht.
Wichtig ist die Präzision: Die Mitteilung zum Auftrag sprach allgemein von quelloffenen und kommerziell lizenzierten Agententechnologien und nannte elizaOS nicht ausdrücklich. Man sollte den Vertrag also nicht als reines Eliza-Referenzprojekt verkaufen. Er zeigt aber, dass der Akteur, der Agentic SME auf elizaOS baut, echte Umsätze macht.
Auf der Infrastrukturseite ist das Signal älter, aber belastbar. Das Ethereum-Team Nethermind pflegt einen eigenen Fork der Plugin-Registry, und Automata Network betreibt neben einem Registry-Fork ein DCAP-Plugin für Intel-basierte TEE-Attestierung, mit dem sich beweisen lässt, in welcher Umgebung ein Agent läuft. Wenn seriöse Infrastrukturteams ihre eigenen Registries betreiben, ist das ein stärkeres Vertrauenssignal als jeder Kurssprung.
Das Geschäftsmodell ohne Token
Bleibt die unbequeme Frage: Wenn die Foundation aufgelöst und das Treasury verbraucht ist, wer bezahlt dann die Wartung eines Projekts mit fast 20.000 Sternen? Open-Source-Infrastruktur ohne tragfähiges Finanzierungsmodell ist ein bekanntes Risiko; die Softwarewelt hat mit Vorfällen wie der xz-Hintertür 2024 schmerzhaft gelernt, wie fragil kritische Bausteine sein können, wenn sie an wenigen unbezahlten Schultern hängen.
Für Eliza zeichnen sich drei Finanzierungspfade ab, die sich nicht ausschließen. Erstens Walters selbst als IP-Eigentümer und Hauptentwickler: Er hat angekündigt, weiterzumachen, ausdrücklich ohne neuen Token. Zweitens kommerzielle Adoptierer wie Secure Blockchain, Nethermind und Automata, die aus Eigeninteresse Code beisteuern und Registries pflegen. Drittens die klassische Mischung aus Unternehmenssponsoring, Auftragsentwicklung und Fördergeldern, wie sie andere Open-Core-Projekte trägt.
In seiner Abschiedsnotiz zum Token formulierte Walters die Haltung deutlich: „I own the IP, and I am never letting a token come close to Eliza again.“ Und er werde weiterbauen, egal was komme, bis zu einer Welt, in der, wie er schrieb, „we each own our data and we don’t have to pay to be smart“ (Decrypt). Das ist mehr als Trotz. Es ist die Umdeutung des Projekts von einem Spekulationsobjekt zu einem Werkzeug für digitale Selbstbestimmung, und damit die Brücke zum eigentlichen Verkaufsargument des OS.
Local-first: der eigentliche Pitch
Der überzeugendste Grund, ein agentisches Betriebssystem quelloffen und selbst betreibbar zu bauen, ist Kontrolle. Ein Agent mit Zugriff auf Kalender, Postfach, interne Dokumente und womöglich eine Wallet ist genau das, was man nicht bedenkenlos an einen fremden Cloud-Dienst auslagert. Genau hier setzt der Local-first-Gedanke an: Modell-Inferenz lokal, Daten lokal, alles in einer Sandbox.
Diese Linie deckt sich mit einem einflussreichen Text von Ethereum-Mitgründer Vitalik Buterin, der im April 2026 für sichere KI-Systeme plädierte: „All LLM inference local first. All files hosted locally. Sandbox everything“ (vitalik.eth.limo). Buterin führte sein Setup mit einem lokal laufenden Modell auf einer einzelnen Grafikkarte vor und schlug harte Obergrenzen für autonome Ausgaben sowie eine menschliche Bestätigung als zweiten Faktor vor. Ein selbst gehostetes Agenten-OS ist die praktische Umsetzung dieser Philosophie.
Für den deutschsprachigen Raum ist das kein Nischenargument. Datenhoheit, DSGVO-Konformität und die Frage, wo Daten physisch liegen, sind für viele Unternehmen Ausschlusskriterien gegen reine US-Cloud-Lösungen. Ein lokal betreibbares Agenten-OS adressiert dieses Bedürfnis direkt. Zugleich gilt die Vorsicht, die HOGE Wire schon bei dezentraler Inferenz beschrieben hat: Selbst betreiben heißt auch, selbst für Verfügbarkeit, Modellqualität und Sicherheit geradezustehen.
Der Haken: ein Betriebssystem mit Wallet-Zugriff
Die Kehrseite der Autonomie ist das Risiko. Ein OS, das Transaktionen signieren kann, verschiebt die Vertrauensfrage von „kann die Software abstürzen“ zu „kann die Software mein Geld verschieben“. Ein Agent mit Wallet, der etwa Renditestrategien in der DeFi fährt (woher solche Renditen kommen und was sie kosten, ordnet die BTCFi-Analyse ein), ist ein lohnendes Angriffsziel. Und die bittere Erkenntnis der letzten Monate lautet: KI-Agenten lassen sich nicht nur über Befehle angreifen, sondern über ihre Erinnerung.
Ein Forschungsteam der Princeton University zeigte mit dem Benchmark CrAIBench, dass Web3-Agenten anfälliger für manipulierte Speichereinträge (Memory Injection) sind als für klassische Prompt-Injection; ist der gespeicherte Kontext erst vergiftet, greifen viele Schutzmaßnahmen nicht mehr (arXiv 2503.16248). elizaOS diente in der Studie als repräsentatives Framework. Praktisch wurde die Angriffsklasse im Mai 2026 beim Grok/Bankr-Vorfall, bei dem eine versteckte Anweisung einen Agenten dazu brachte, Tokens im Wert von rund 175.000 US-Dollar zu verschieben.
Verifizierbare Rechenverfahren wie die TEE-Attestierung (das erwähnte Automata-DCAP-Plugin) helfen, beweisen aber nur, in welcher Umgebung ein Agent läuft, nicht, dass seine Eingaben sauber sind. Buterins Obergrenzen und das Prinzip Mensch plus Modell als Zwei-Faktor-Bestätigung bleiben deshalb die pragmatischste Verteidigung. Wer tiefer einsteigen will, findet die Sicherheitsmechanik im HOGE-Wire-Dossier zur Frage, wie sicher ein KI-Agent mit Wallet wirklich ist.
Was das für deutsche Unternehmen bedeutet: BaFin, MiCA, AI Act
Für ein deutsches Unternehmen, das einen Eliza-Agenten produktiv einsetzt, gilt zuerst die Entwarnung: Das Framework selbst ist kein reguliertes Finanzprodukt. BaFin und MiCA beaufsichtigen Dienstleister und Emittenten von Kryptowerten, nicht ein quelloffenes Stück Software. Die einschlägige Orientierung liefert das BaFin-Merkblatt zu Kryptowerte-Dienstleistungen.
Regulatorisch relevant wird es erst durch das, was der Agent tut. Verwahrt, tauscht oder überweist er Kryptowerte für Dritte, kann eine CASP-Erlaubnis unter MiCA nötig werden. Gibt er Anlageempfehlungen oder verwaltet Portfolios, greift nicht MiCA, sondern MiFID II; die ESMA hat 2024 eigens klargestellt, dass Wohlverhaltens-, Transparenz- und Aufsichtspflichten auch dann gelten, wenn KI im Spiel ist (ESMA). Wie hart die US-Seite parallel an einem eigenen Rahmen arbeitet, zeigt die HOGE-Wire-Analyse zur Regulation Crypto Assets.
Neu und oft übersehen ist die zweite Achse: der EU AI Act. Er betrifft nicht das Krypto-, sondern das KI-System. Seit dem 2. August 2026 greifen die Transparenzpflichten aus Artikel 50; Nutzer müssen wissen, dass sie mit einem KI-System interagieren, und KI-generierte Inhalte müssen maschinenlesbar gekennzeichnet werden. Die schärferen Pflichten für Hochrisiko-Systeme wurden auf Dezember 2027 verschoben, doch die nationalen KI-Aufsichtsbehörden sind seit 2026 handlungsfähig (Europäische Kommission). Wer einen Kundenservice-Agenten betreibt, fällt praktisch sofort unter die Offenlegungspflicht.
Kommt Geldbewegung ins Spiel, rücken zudem Geldwäschepflichten in den Blick; was Überwachung leistet und was sie kostet, hat HOGE Wire in der Analyse zur Krypto-AML 2026 aufgeschlüsselt.
Die Steuerfrage für den Betreiber
Steuerlich gilt ein einfacher Grundsatz: Ein Agent hat keine Rechtspersönlichkeit, also werden seine Gewinne dem Menschen oder dem Unternehmen zugerechnet, dem die Wallet gehört. Für Privatpersonen behandelt das deutsche Recht Kryptowerte als anderes Wirtschaftsgut nach Paragraf 23 EStG: Nach einem Jahr Haltefrist sind Veräußerungsgewinne steuerfrei, darunter gilt der persönliche Steuersatz, es existiert eine Freigrenze von 1.000 Euro pro Jahr, und die Zuordnung erfolgt nach FIFO. Die Linie stammt aus dem BMF-Schreiben vom 6. März 2025.
Der Haken für autonome Agenten: Ein Programm, das rund um die Uhr hochfrequent handelt, kann die Grenze zum Gewerbebetrieb überschreiten. Dann entfällt das Jahresprivileg, es fällt Gewerbesteuer an, und Gewinne sind unabhängig von der Haltedauer steuerpflichtig. Für ein Unternehmen, das einen Agenten kommerziell betreibt, sind die Erträge ohnehin Betriebseinnahmen. Der Vergleich mit anderen Ertragsquellen, etwa der Realrendite von Validatoren, zeigt, wie unterschiedlich Steuer- und Risikoprofile am Ende ausfallen.
Und die Haftung? Sie folgt der Kontrolle. Verursacht ein Agent Schaden, haftet in aller Regel der Prinzipal, also der Betreiber, der die Autonomie eingeräumt und die Grenzen gesetzt hat. Das ist der stille, aber entscheidende Grund, warum Obergrenzen und menschliche Freigaben kein Autonomie-Killer, sondern eine betriebswirtschaftliche Notwendigkeit sind.
Kann die Wette aufgehen? Risiken und Wettbewerb
Gegen die OS-Erzählung sprechen mehrere harte Faktoren. Erstens der Wettbewerb von oben: Die großen KI-Anbieter bauen eigene Agenten-Plattformen, und selbst Kryptobörsen betreiben inzwischen eigene Agenten-Betriebssysteme für den Handel. Wer „Betriebssystem für Agenten“ sagt, konkurriert damit nicht mehr nur mit anderen Open-Source-Frameworks, sondern mit Konzernen, die Vertrieb, Rechenzentren und Nutzerbasis mitbringen.
Zweitens die Kluft zwischen Metapher und Substanz. elizaOS bleibt technisch ein TypeScript-Stack, kein Kernel; die eigentliche OS-Distribution ist mit ihren rund 15 Sternen ein Frühstadium. Drittens die Reputationslast: Der tote Token, die Sammelklage und der nie eingelöste Autonomieanspruch hängen dem Namen an. Ein neuer Enterprise-Kunde wird zweimal hinsehen, bevor er sein Kerngeschäft auf eine Marke setzt, die gerade ihre Stiftung abgewickelt hat.
Viertens die Finanzierung. Ohne Token und ohne Stiftung hängt die Weiterentwicklung an kommerziellen Partnern und am Gründer. Das kann funktionieren, wie bei vielen Open-Core-Projekten, oder es kann austrocknen, wenn ein zentraler Beitragender die Lust verliert. Die nächsten zwölf Monate, in denen sich zeigt, ob aus einzelnen Aufträgen ein wiederkehrendes Geschäft wird, sind für diese Frage entscheidender als jede Kursbewegung.
Ausblick: warum das Framework den Token überlebt
Der eigentliche Lehrsatz von Eliza ist unspektakulär und wichtig zugleich: Ein Token kann sterben, ohne dass die Software stirbt, und Software kann überleben, ohne je einen Token gebraucht zu haben. Der Sektor der KI-Agenten-Token hat 2026 viel Kapital verbrannt, doch die brauchbaren Bausteine, also Frameworks, Registries und Bezahlprotokolle, sind geblieben und werden weiterentwickelt.
Ob agentisches Betriebssystem zu einer echten Kategorie wird oder ein ehrgeiziges Etikett bleibt, entscheidet sich nicht an der Wortwahl, sondern an drei beobachtbaren Größen: Wachsen die zahlenden Unternehmenskunden über Einzelfälle hinaus? Reift das Plugin-Ökosystem zu etwas, das sich wie eine Plattform anfühlt? Und wird aus der elizaOS/os-Distribution mehr als eine Absichtserklärung? Solange diese drei Linien nach oben zeigen, ist die OS-Erzählung mehr als Marketing.
Walters selbst gibt sich langfristig. Er wolle in zehn Jahren noch da sein und dorthin gehen, wohin die großen Konzerne nicht gehen. „Eliza is dead. Long live Eliza“, schrieb er zum Abschied vom Token. Der Satz ist als Grabrede gemeint, klingt aber wie ein Startsignal, und er verschiebt den Maßstab, an dem man das Projekt misst: weg vom Kurs, hin zum Code und zu den Kunden.
Häufig gestellte Fragen (FAQ)
Ist das Eliza-Framework nach dem Token-Tod noch nutzbar?
Ja. Der Code liegt quelloffen unter MIT-Lizenz auf GitHub, wird aktiv weiterentwickelt (rund 19.200 Sterne, Aktivität bis Ende August 2026) und lässt sich ohne jeden Token selbst betreiben. Tot ist der ELIZAOS-Token, nicht die Software.
Was bedeutet ein agentisches Betriebssystem bei elizaOS?
Es ist die Selbstbeschreibung des Projekts: eine Laufzeitumgebung, in der KI-Agenten wie Prozesse leben, Plugins wie Treiber Fähigkeiten hinzufügen und ein Speicher Zustand hält. Praktisch ist elizaOS heute ein TypeScript-Stack mit OS-Ambition; eine installierbare OS-Distribution (elizaOS/os) existiert erst im Frühstadium.
Kostet elizaOS Geld, wenn es keinen Token mehr gibt?
Das Framework selbst ist kostenlos. Kosten entstehen beim Betrieb, vor allem für Modell-Inferenz und Infrastruktur, sowie beim Einkauf fertiger Lösungen. Geld verdienen inzwischen Dritte, etwa mit White-Label-Produkten wie Agentic SME oder mit Auftragsentwicklung.
Braucht ein deutsches Unternehmen für einen Eliza-Agenten eine BaFin-Lizenz?
Für das Framework nicht. Eine Erlaubnis kann nötig werden, wenn der Agent Kryptowerte für Dritte verwahrt oder tauscht (CASP unter MiCA) oder Anlageberatung leistet (MiFID II). Unabhängig davon gelten seit August 2026 Transparenzpflichten des EU AI Act sowie die DSGVO.
Ist Eliza dasselbe wie ai16z?
Nicht ganz. ai16z war 2024 der KI-Fonds samt Token auf Solana; im Januar 2025 folgte die Umbenennung in ElizaOS. Eliza ist das darunterliegende Agenten-Framework. Der Token wurde im August 2026 für tot erklärt, das Framework wird weitergeführt.
Von Marcus Okafor, HOGE Wire. Kurs- und Marktdaten Stand 30. August 2026; Kryptowerte sind hochvolatil, dieser Text ist keine Anlageberatung.