Oh My Pi vs. Pi: der Fork, die Unterschiede und welches du ausführen solltest

Oh My Pi ist ein Hard Fork von Pi und kein Konkurrent, der neben Pi entstanden ist — der Code floss von Pi → Oh My Pi, beide Projekte sind heute aktiv, und sie optimieren inzwischen für entgegengesetzte Dinge. Pi ist ein bewusst minimales Terminal-Harness, das Sie in TypeScript erweitern. Oh My Pi ist dieselbe Abstammung, als umfassende Coding-Oberfläche mit integriertem LSP, Debugger, Subagenten und Browser-Tool neu aufgebaut. Beide sind MIT-lizenziert und kosten für die Installation 0 $, daher geht es bei der Entscheidung um Workflow, Ausführungsmodell und Konfigurationsformat — nicht um eine Lizenzgebühr.

Zuerst die Namen, weil drei davon miteinander kollidieren. Pi bezeichnet hier das Agenten-Harness unter pi.dev, veröffentlicht von Earendil Works aus earendil-works/pi. Es handelt sich nicht um Pi von Inflection AI (pi.ai), nicht um die Pi-Network-Münze und nicht um Raspberry Pi. Oh My Pi bezeichnet den Agenten unter omp.sh aus can1357/oh-my-pi, dessen Binärdatei omp ist — nicht die Kuchenbäckereien, die bei einer Suche nach dieser Wortgruppe dominieren, und trotz der Namensähnlichkeit nicht Oh My Zsh oder Oh My Posh. Und pi-mono ist kein drittes Produkt: Es ist der alte Repository-Name von Pi. github.com/badlogic/pi-mono liefert jetzt eine 301-Weiterleitung zu earendil-works/pi, obwohl Dokumentationen von Drittanbietern weiterhin den alten Pfad verwenden — die offizielle Pi-Integrationsseite von DeepSeek befindet sich buchstäblich unter /agent_integrations/pi_mono/.

Die Fork-Richtung sollte eindeutig festgehalten werden, weil Suchanfragen in beide Richtungen laufen und die Antwort nicht symmetrisch ist. Die README von Oh My Pi sagt in ihrer eigenen Kopfzeile, dass es ein „Fork of Pi by @mariozechner“ ist, und verlinkt auf die URL vor der Umbenennung. GitHub meldet dafür fork: false und parent: null, weil es sich um einen Source-Fork und nicht um den Fork über die Schaltfläche handelt — die API wird es Ihnen daher nicht mitteilen. Das Repository enthält weiterhin docs/porting-from-pi-mono.md, eine Merge-Checkliste, deren aufgezeichneter Last Sync Point der Commit b21b42d vom 22. März 2026 ist. Diese Markierung ist der einzige von außen verfügbare Beleg für die Abweichung; ob später eine nicht aufgezeichnete Synchronisierung stattgefunden hat, kann diese Seite nicht bestätigen.

Oh My Pi vs. Pi: Was sollten Sie wählen?

Fünf Achsen entscheiden darüber – unabhängig davon, aus welcher Richtung Sie an die Frage herangehen – und nur eine davon betrifft die Funktionen.

• Workflow. Wählen Sie Pi, wenn Sie einen kleinen Kern wünschen und die fehlenden Teile selbst schreiben möchten. Bis zur Aktualisierung der Dokumentation am 22. September 2026 hieß es in der eigenen Nutzungsdokumentation, dass es „absichtlich kein integriertes MCP, keine Sub-Agents, Berechtigungs-Popups, keinen Planmodus, keine To-dos und keine Hintergrund-Bash“ enthält, und verwies stattdessen auf Erweiterungen, Pakete, Container und tmux. Durch die Aktualisierung wurde dieser Satz entfernt, und v0.99.0 machte MCP anschließend zu einer standardmäßig geladenen integrierten Erweiterung; Sub-Agents, Planmodus, To-dos und Genehmigungsaufforderungen sind in v0.99.2 weiterhin Erweiterungen. Wählen Sie Oh My Pi, wenn Sie all das vom ersten Tag an integriert haben möchten und keine Erweiterung warten wollen.
• Berechtigungen und Ausführungsmodell. Keine der Standardeinstellungen ist die sichere Wahl; entscheiden Sie daher, mit welchem Fehlermodus Sie leben können. Pi verfügt über kein Berechtigungssystem und sagt das ausdrücklich. Oh My Pi hat ein echtes dreistufiges System und wird standardmäßig auf yolo gesetzt. Wenn Sie Aufforderungen pro Tool benötigen, kann Oh My Pi diese nach einer Konfigurationszeile anzeigen; Pi kann das ohne Erweiterung überhaupt nicht.
• Protokoll- und Planlimits. Wenn Ihre Modellroute ein OpenAI- oder Anthropic-kompatibler Drittanbieter-Endpunkt ist, können beide ihn erreichen, aber Oh My Pi dokumentiert neun Wire-Dialekte, während Pi bis zur Aktualisierung seiner Dokumentation am 22. September 2026 vier dokumentierte, und bietet zusätzlich eine Umgebungsvariablen-Route, die Pi nicht hat. Der Dialektunterschied ist im Code kleiner als auf dem Papier: Pis Quellcode in v0.99.2 leitet api eines benutzerdefinierten Providers an eine von zehn integrierten Implementierungen weiter, von denen sechs nie für diese Verwendung dokumentiert wurden. Wenn Ihre Route ein OAuth-Abonnement ist – Claude Pro/Max, Codex, GitHub Copilot –, binden beide Clients es über /login ein und speichern ein Anbieter-Token, das ein dazwischengeschaltetes Gateway ablehnen würde; die Provider-Dokumentation von Oh My Pi nennt genau das als Grund dafür, dass ein models.yml-Schlüssel absichtlich Vorrang vor gespeichertem OAuth hat. Ordnen Sie die chinesischen Coding-Pläne nicht dieser Gruppe zu: Pi führt ZAI/GLM, Kimi For Coding und die Qwen Token Plans in seiner API-Key-Tabelle (ZAI_API_KEY, KIMI_API_KEY, QWEN_TOKEN_PLAN_API_KEY) auf, und Oh My Pi kennzeichnet sie als plan statt als oauth; somit sind sie bei beiden gewöhnliche schlüsselbasierte Provider.
• Kostenpfad. Der Client ist auf beiden Seiten kostenlos, und keiner verändert Ihren Preis pro Token. Die Asymmetrie besteht darin, dass Pi ein kostenpflichtiges Gateway des Erstherstellers (Radius, betrieben vom selben Unternehmen) hat, das in sein eigenes /login eingebunden ist, während Oh My Pi keinerlei gehostete Route anbietet – der einzige Server, den es betreibt, ist das Relay hinter /collab-Sitzungslinks, das nichts berechnet.
• Migrationskosten. Grob ein Provider-Block, neu eingetragen. Konfigurationsformate und Verzeichnisse unterscheiden sich – JSON unter ~/.pi, YAML unter ~/.omp –, und in keinem der beiden Repositories ist ein Importtool dokumentiert. Einige Umgebungsvariablen-Namen sind identisch, mit den unten genannten Einschränkungen.

Was nicht darüber entscheiden sollte: die Versionsnummern. Oh My Pi hat beim Fork neu nummeriert, daher sind 18.2.7 und Pis 0.86.1 unterschiedliche Schemata und nicht achtzehn Versionen zusätzlicher Reife.

Was sich tatsächlich zwischen ihnen unterscheidet

Aus der eigenen Dokumentation beider Repositories am 19. September 2026 gelesen: Pis Übersicht-, Sicherheits- und Modellseiten sowie Oh My Pis README-, Approval-Mode- und Provider-Seiten. Pis Zeilen zu Design, MCP, Berechtigungsmodell und Dialekten wurden am 1. Oktober 2026 anhand der aktualisierten Dokumentation, README und des Quellcodes in v0.99.2 erneut geprüft. Die Funktionszahlen in der Oh-My-Pi-Zeile sind eigene Angaben des Projekts; eine Methodik wird dafür nicht veröffentlicht, und auch die Benchmark-Tabelle in der README ist eine Anbieterangabe, die diese Seite nicht wiedergibt.

Beide sind aktiv. Keine der beiden Metriken beantwortet die Frage, „welches größer ist“.

Der häufigste Fehler bei diesem Paar besteht darin, eines der beiden Projekte als aufgegeben oder abgelöst zu betrachten. Beide haben am Tag dieser Prüfung Code veröffentlicht.

Repository-, Release- und Star-Zahlen aus der GitHub API, abgerufen am 21. September 2026; Downloadzahlen aus der npm-Downloads-API für die am 16. September 2026 endende Woche. Wandeln Sie keine der beiden Spalten in ein Adoptionsurteil um. Insbesondere ist der npm-Vergleich nicht gleichwertig: Pis eigene Dokumentation beginnt mit npm install -g, während Oh My Pis README curl-to-shell, Homebrew, Bun, Nix, PowerShell und mise dokumentiert und überhaupt keinen npm-Befehl enthält; npm unterschätzt Oh My Pi daher erheblich, in einem Ausmaß, das hier niemand messen kann. Die Stars sprechen für Pi; die Veröffentlichungsfrequenz spricht für Oh My Pi; jeder Satz über Popularität, der nur eine Metrik verwendet, wird in mindestens eine Richtung falsch sein.

Neutrale Belege von Drittanbietern dafür, dass beide aktuell sind, falls Sie das ohne Metriken möchten: Ollama veröffentlicht eine Integrationsseite für Oh My Pi und für Pi, und DeepSeek veröffentlicht ebenfalls einen Leitfaden zur Agent-Integration für beide – Pis Leitfaden ist weiterhin unter dem alten Pfad pi_mono abgelegt. Alle vier Seiten antworteten am 21. September 2026.

Einen der beiden auf den eigenen Endpunkt verweisen

Hier ist der Fork am deutlichsten sichtbar, und hier kostet Sie ein falscher /v1 einen Nachmittag. Beide Clients können einen OpenAI- oder Anthropic-kompatiblen Drittanbieter-Endpunkt erreichen, jedoch über unterschiedliche Mechanismen und entgegengesetzte URL-Konventionen.

Oh My Pi hat eine Umgebungsvariablen-Route, die Pi nicht besitzt. Sein Anthropic-Provider ermittelt die Basis-URL über normalizeAnthropicBaseUrl($env.ANTHROPIC_BASE_URL), vor dem offiziellen Standardwert, und dieser Normalisierer entfernt ein abschließendes /v1 – daher landen sowohl https://api.kunavo.com als auch https://api.kunavo.com/v1 beim selben Host. Gelesen aus packages/ai/src/providers/anthropic-state.ts, wo resolveDirectAnthropicBaseUrl() und der Normalisierer am 19. September 2026 definiert waren – aus dem Quellcode, nicht aus einer von uns gestellten Anfrage.

# Oh My Pi honours ANTHROPIC_BASE_URL for its built-in anthropic provider.
# normalizeAnthropicBaseUrl() strips a trailing /v1, so both forms resolve
# to the same host here. Pi ships no equivalent gateway base-URL variable.
export ANTHROPIC_API_KEY="$KUNAVO_API_KEY"
export ANTHROPIC_BASE_URL="https://api.kunavo.com"
omp

Diese Route bringt eine Vorrangfalle mit sich. Die dokumentierte Reihenfolge von Oh My Pi setzt einen models.yml apiKey auf Position 2, vor gespeichertes OAuth auf Position 3, aber eine Provider-Umgebungsvariable auf Position 5, darunter. Wenn Sie also bereits über /login bei Anthropic angemeldet sind, gewinnt das Subscription-Token gegenüber ANTHROPIC_API_KEY, und Ihr Gateway-Schlüssel wird nie verwendet. Hinterlegen Sie den Schlüssel in der Konfiguration oder melden Sie sich zuerst bei diesem Provider ab.

Für einen benannten Provider verwendet Oh My Pi YAML – und hier wird das /v1 wieder angehängt, weil sein OpenAI-Pfad /chat/completions unverändert an die gekürzte Basis-URL anhängt.

providers:
  kunavo:
    baseUrl: https://api.kunavo.com/v1   # /v1 REQUIRED: omp appends /chat/completions
    api: openai-completions              # use anthropic-messages, and then drop /v1
    apiKey: KUNAVO_API_KEY               # env var name, a literal, or "!cmd"
    authHeader: true                     # send Authorization: Bearer <key>
    models:
      - id: claude-sonnet-5
        contextWindow: 200000
        maxTokens: 64000

Um Pi auf ein Gateway zu verweisen, haben Sie eine Route: ~/.pi/agent/models.json. Pi liest kein ANTHROPIC_BASE_URL – eine Codesuche im Repository am 19. September 2026 liefert zwei Treffer für diese exakte Zeichenfolge, beide ohne Override (eine Cloudflare-AI-Gateway-Konstante und ein Skript zur Modellgenerierung) – und es gibt auch kein bloßes OPENAI_BASE_URL. Eine Variable für die Basis-URL existiert, ist aber kein allgemeiner Ausweg: AZURE_OPENAI_BASE_URL, in Pis Provider-Dokumentation aufgeführt, verweist den Azure-OpenAI-Provider auf Ihre eigene Azure-Ressource und auf nichts anderes.

{
  "providers": {
    "kunavo": {
      "baseUrl": "https://api.kunavo.com",
      "api": "anthropic-messages",
      "apiKey": "$KUNAVO_API_KEY",
      "models": [
        {
          "id": "claude-sonnet-5",
          "contextWindow": 200000,
          "maxTokens": 64000
        }
      ]
    }
  }
}

Beim Suffix hat Pis eigene Dokumentation nie eine eindeutige Entscheidung getroffen; das sollten Sie wissen, statt einem einzelnen Beispiel zu vertrauen. Bis zur Aktualisierung der Dokumentation am 22. September 2026 zeigte Pis Modellseite einen anthropic-messages-Proxy an einer Stelle als https://proxy.example.com/v1 und an einer anderen als https://proxy.example.com ohne Suffix; durch die Aktualisierung wurden beide Angaben entfernt, ohne die Frage zu klären. Die Form ohne Suffix ist die richtige, und die Begründung ist aus dem Quellcode abgeleitet, nicht zur Laufzeit getestet: Pi enthält im anthropic-messages-Pfad nichts, was dem Suffix-entfernenden Normalisierer von Oh My Pi (/v1) entspricht – die einzige in der Dokumentation beschriebene Normalisierung ist Azure-spezifisch: Ressourcen-Root-URLs unter den eigenen Azure-Domains „werden auf den OpenAI-API-Pfad normalisiert“ – sein integrierter Anthropic-Standardwert ist https://api.anthropic.com ohne /v1, während sein OpenAI-Standardwert https://api.openai.com/v1 ist, und bei anthropic-messages übergibt es model.baseUrl direkt an das offizielle Anthropic SDK, das /v1/messages selbst anhängt. Ein /v1 würde dort /v1/v1/messages ergeben. Kunavo dokumentiert dieselbe Konvention auf seiner Basis-URL-Seite: nur die Origin für Clients im Anthropic-Stil, /v1 für Clients im OpenAI-Stil.

Zwei weitere Grenzen, um die herum Sie planen sollten. Bis zur Aktualisierung der Dokumentation am 22. September 2026 führte Pis dokumentierte Tabelle vier Dialekte für benutzerdefinierte Provider auf, obwohl das Repository zusätzliche Handler enthält; durch die Aktualisierung wurde die Tabelle entfernt, ohne eine Ersatzliste zu nennen, sodass diese vier weiterhin die einzige von Pi dokumentierte Oberfläche für benutzerdefinierte Provider sind. Die zusätzlichen Handler sind jedoch nicht für integrierte Provider reserviert: Pis Quellcode in v0.99.2 typisiert einen models.json api als freie Zeichenfolge und leitet ihn an diejenige von zehn registrierten Implementierungen weiter, die passt (BUILTIN_APIS in packages/ai/src/compat.ts); ein benutzerdefinierter Provider kann daher bedrock-converse-stream oder google-vertex angeben – ob eines davon gegenüber einem Drittanbieter-Endpunkt funktioniert, ist hier undokumentiert und ungetestet. Bei Oh My Pi wird disabledProviders vor den Anmeldedaten geprüft – eine von dieser Liste erfasste Provider-ID verschwindet unabhängig vom bereitgestellten Schlüssel stillschweigend –, während Einstellungsarrays von der höher priorisierten Ebene vollständig ersetzt und nicht zusammengeführt werden; eine projektbezogene Liste verwirft daher stillschweigend die globale. Beide Projekte bieten außerdem Kompatibilitätsauswege, die Sie an einem Gateway tatsächlich benötigen könnten: Oh My Pis disableStrictTools, Pis supportsEagerToolInputStreaming und allowEmptySignature. Ob Kunavo die standardmäßigen strikten Schemas, Cache-Markierungen oder das eifrige Streamen von Tool-Eingaben beider Clients akzeptiert, wurde hier nicht getestet.

Was der Wechsel tatsächlich kostet

Weniger, als der Abstand der Versionsnummern vermuten lässt, und mehr als das Kopieren einer Datei. In den Dokumentationsverzeichnissen beider Repositories gibt es keinen dokumentierten Importbefehl, Sitzungs-Konverter oder Konfigurations-Migrator. Planen Sie daher ein, den Provider-Block im jeweils anderen Format neu einzutragen – JSON in YAML oder umgekehrt. Auch Anmeldedaten werden nicht übertragen: Pi speichert sie in ~/.pi/agent/auth.json, während Oh My Pi einen SQLite-Authentifizierungsspeicher unter ~/.omp/agent/agent.db verwendet.

Umgebungsvariablen reichen weniger weit, als die gemeinsame Abstammung vermuten lässt; lesen Sie diesen Abschnitt daher sorgfältig. Oh My Pi liest weiterhin die mit PI_ präfigierten Namen – darunter PI_CONFIG_DIR und PI_CODING_AGENT_DIR –, aber sie verschieben die Verzeichnisse von Oh My Pi. Wenn Sie eine davon in einem Shell-Profil exportieren, das Sie mit Pi teilen, verweisen beide Clients auf denselben Pfad, anstatt eine portable Konfiguration zu erzeugen. Die in seiner Referenz zu Umgebungsvariablen beschriebene Spiegelung von OMP_ nach PI_ ist noch eingeschränkter: Die Dokumentation sagt, dass diese Regel innerhalb jeder geparsten .env-Datei gilt und ausdrücklich „nicht für beliebige vom übergeordneten Prozess geerbte Variablen“. Überhaupt nicht übertragen wird etwas, das auf dem Harness aufbaut: Eine TypeScript-Erweiterung für Pi wird gegen Pis API geschrieben, und ungefähr sechs Monate separat gepflegter Entwicklung seit dem Synchronisationsmarker vom 22. März 2026 sind genau der Zeitraum, in dem diese APIs auseinanderlaufen. Testen Sie eine Erweiterung, statt von einer Portierbarkeit auszugehen.

Das Geld ist auf beiden Seiten gleich

Keiner der beiden Clients berechnet Ihnen etwas; der Wechsel zwischen ihnen verändert Ihre Modellausgaben also um null. Entscheidend ist, über welche Route Sie Tokens kaufen, und darin unterscheiden sich die beiden auf eine Weise: Pi hat ein kostenpflichtiges Gateway des Erstherstellers, Oh My Pi nicht. Radius wird von Earendil betrieben, ist Closed Source, wird über Pis eigenes /login erreicht, und in der FAQ heißt es, dass „die Gebühren, die wir an unseren Zahlungsabwickler zahlen, zusätzlich zu den Listenpreisen“ berechnet werden – einen Prozentsatz veröffentlicht das Unternehmen nicht, daher lässt sich ein Radius-Gesamtbetrag von außen nicht berechnen. Das einzige Gateway von Oh My Pi ist omp auth-gateway serve, eine von Ihnen gehostete Software, wobei die Transportsicherheit an den Betreiber delegiert wird.

Eine Sache sollten Sie aus einem Budget streichen, bevor sie darin landet: Ein Claude-Pro- oder -Max-Abonnement, bei dem Sie sich in einem der beiden Harnesses angemeldet haben, bedeutet keine kostenlose Nutzung. Bis zur Aktualisierung der Dokumentation am 22. September 2026, durch die dieser Satz entfernt wurde, hieß es in Pis Provider-Dokumentation, dass die Nutzung durch Drittanbieter-Harnesses „zusätzliche Nutzung aufbraucht und pro Token abgerechnet wird, nicht gegen die Limits des Claude-Plans“; die Warnung, die Pi ausgibt, wenn ein Anthropic-Modell mit Abonnement-Authentifizierung ausgeführt wird, lautet weiterhin: „zusätzliche Nutzung wird aufgebraucht und pro Token abgerechnet, nicht gegen die Limits Ihres Claude-Plans“ (Quelle, v0.99.2). In der Dokumentation von Oh My Pi wurde keine gleichwertige Aussage gefunden. Gehen Sie daher nicht davon aus, dass es sich anders verhält – prüfen Sie Ihr eigenes Konto.

Für die Gateway-Route folgt hier die Rechnung für die Arbeitslast, nicht für den Client. Nehmen Sie einen Monat kontinuierlicher Agent-Arbeit an: 5,000,000 nicht gecachte Eingabe-Tokens und 400,000 Ausgabe-Tokens, keine Cache-Lese- oder -Schreibvorgänge, keine Bild- oder Tool-Gebühren. Die Preise stammen live aus dem Kunavo-Katalog und gelten pro Million Tokens.

Dies sind anschauliche Token-Schätzungen unter den obigen Annahmen, keine gemessenen Aufgabenkosten und keine Obergrenze für eine Rechnung. Die Spalte ist für beide Clients identisch, weil der Client keine Preisvariable ist – die Arbeitslast kann es jedoch sein: Das task-Tool von Oh My Pi teilt Subagents parallel auf, und parallele Agents bringen jeweils ihren eigenen Kontext mit, was einen Eingabe-Token-Multiplikator darstellt, den keine Tabelle hier für Sie bemessen kann. Messen Sie ihn an einer begrenzten Änderung, bevor Sie die Schätzung hochskalieren.

Zwei Hinweise von Kunavo gehören in dieselbe Zahl. Der Katalogbetrag ist eine Abrechnungsuntergrenze, keine Obergrenze: Wenn der Upstream seine Gebühr meldet, entspricht die Rechnung dem höheren Wert aus den Katalogkosten und den Upstream-Kosten multipliziert mit dem anwendbaren Aufschlag, wie der Abrechnungsleitfaden erklärt. Und die minimale Aufladung beträgt $10 an vorausbezahltem Guthaben – das Geld, das zur Finanzierung eines Kontos benötigt wird, keine Aufgabengebühr und kein Abonnement.

Kunavo veröffentlicht für jeden Client eine Einrichtungsanleitung – Pi und Oh My Pi –, hat jedoch keinen der beiden gegen seinen Endpunkt zur Laufzeit getestet; eine Einrichtungsanleitung ist eine Konfigurationsreferenz und kein Kompatibilitätstest. Beide obigen Konfigurationen wurden anhand veröffentlichter Dokumentation und des Quellcodes erstellt und sollten auf Ihrem eigenen Rechner überprüft werden. Halten Sie eine funktionierende Route verfügbar, während Sie eine davon ausprobieren. Wenn Sie eine reale Aufgabe statt eines Modells bepreisen möchten, erstellen Sie ein Kunavo-Konto, laden Sie Guthaben auf und führen Sie eine begrenzte Änderung mit dem von Ihnen ausgewählten Modell aus. Wenn Sie noch ein Harness statt eines Providers auswählen, schlüsselt Pi-Coding-Agent-Preise Pis vier Abrechnungsrouten auf, und Pi vs. OpenCode vergleicht Pi mit einem anderen Client, für den es eine veröffentlichte Kunavo-Einrichtungsanleitung gibt.

Häufig gestellte Fragen

Die Dokumentationsverzeichnisse und npm-Pakete beider Repositories wurden am 19. September 2026 geprüft; die Aussagen zu Basis-URL und Anmeldedaten-Reihenfolge wurden am selben Datum aus den inline genannten Quelldateien gelesen. Repository-Metriken und Release-Historien wurden am 21. September 2026 erneut gelesen. Nach Pis Aktualisierung der Dokumentation am 22. September 2026 wurden seine anthropic-messages-Basis-URL-Beispiele, der Azure-Normalisierungssatz, die dokumentierten api-Werte und die Reihenfolge der Anmeldedaten am 1. Oktober 2026 anhand der aktualisierten Dokumentation und des Quellcodes in v0.99.2 erneut geprüft. Am selben Tag wurden nach der Einführung des integrierten MCP in Pi v0.99.0 die Liste der ausgelassenen Funktionen, die Formulierung zum Projektvertrauen und das angegebene Design anhand seiner Nutzungs-, MCP-, Einstellungs- und Sicherheitsseiten sowie der README erneut geprüft; ebenso die api-Werte, die der Quellcode verarbeitet, die Zeile zur zusätzlichen Nutzung anhand der Terminalwarnung in diesem Quellcode und der Integrationsindex dieser Website. Ebenfalls am 1. Oktober 2026 wurden die dokumentierten api-Werte von Oh My Pi anhand seines docs/models.md- und models.yml-Schemas in v18.4.8 erneut geprüft. Kunavo-Preise werden aus dem Live-Katalog dargestellt, und jeder Dollarbetrag hier ist eine beispielhafte Token-Rechnung. Keiner der beiden Clients wurde zur Laufzeit gegen Kunavo getestet, und es wird kein Performance- oder Benchmark-Vergleich zwischen den beiden Projekten impliziert – es gibt keinen, den diese Seite zitieren könnte.