| |

Mit APIYI-Aufrufprotokollen den Tokenverbrauch von Codex pro Gesprächsrunde prüfen: In 5 Schritten die Kosten langer Gespräche berechnen

Mit APIYI-Aufrufprotokollen den Tokenverbrauch von Codex pro Gesprächsrunde prüfen: In 5 Schritten die Kosten langer Gespräche berechnen

Anmerkung des Autors: Du siehst im Codex-Eingabefeld nicht, wie viel Kontext bereits belegt ist? Der Einstieg dafür ist /status. Dieser Artikel zeigt, wie du anhand der Aufrufprotokolle von APIYI in fünf Schritten den Token-Verbrauch und die Kosten pro Codex-Runde ermittelst. Dazu gibt es eine Entscheidungstabelle für die Frage: komprimieren oder neu anfangen?

Du hast Codex mit APIYI verbunden und mehrere Stunden in einer Unterhaltung gearbeitet. Unter dem Eingabefeld werden nur der Berechtigungsmodus und das Modell angezeigt. Wie viel Kontext bereits belegt ist, siehst du dort nicht – und du bist unsicher, ob du ein neues Fenster öffnen solltest.

Die kurze Antwort: Codex zeigt die Kontextnutzung weiterhin an, nur findest du sie jetzt unter /status. Die Daten für die Kostenberechnung stehen in den Aufrufprotokollen von APIYI / apiyi.com. Dieser Artikel erklärt in fünf Schritten, wie du den Token-Verbrauch pro Codex-Runde im APIYI-Aufrufprotokoll nachvollziehst: Welche Werte du brauchst, wie du sie zusammenrechnest und wann du den Kontext komprimieren oder eine neue Unterhaltung starten solltest.

Das ist keine weitere Einführung in die Grundlagen. Jeder Schritt beschreibt, was du auf der Oberfläche siehst und wo du klicken musst. Dazu gibt es jeweils ein Kriterium, mit dem du das Ergebnis prüfen kannst.

codex-token-usage-per-turn-apiyi-logs-de-image-0


Warum Codex den Token-Verbrauch nicht für jede Runde anzeigt

Viele glauben, Codex habe die Kontextanzeige entfernt. Tatsächlich verteilen sich die Informationen auf drei Stellen – und jede zeigt etwas anderes an.

  1. Desktop-Client / IDE-Plugin: Im Eingabefeld werden nur der Berechtigungsmodus und das Modell angezeigt. Mit /status sehen Sie die Chat-ID, die Kontextauslastung und die verbleibenden Ratenlimits.
  2. CLI: /status zeigt das aktuelle Modell, die Genehmigungsrichtlinie, beschreibbare Verzeichnisse und den aktuellen Token-Verbrauch. In der Fusszeile der CLI gibt es bereits einen Kontexthinweis. Mit /statusline können Sie Kontextstatistiken und Token-Zähler zur Fusszeile hinzufügen. Ihre Auswahl wird in config.toml unter tui.status_line gespeichert.
  3. codex exec --json: Bei der nicht interaktiven Ausführung gibt Codex bei jeder Statusänderung ein JSON-Ereignis als eigene Zeile aus. Das Ereignis turn.completed enthält usage mit fünf Feldern: input_tokens, cached_input_tokens, cache_write_input_tokens, output_tokens und reasoning_output_tokens.

Mit /usage können Sie ausserdem die Token-Aktivität auf Kontoebene einsehen – allerdings nur, wenn Sie offiziell angemeldet sind. Wenn Sie einen Schlüssel eines Drittanbieters verwenden, funktioniert dieser Befehl nicht.

Drei Möglichkeiten, den Token-Verbrauch in Codex zu erfassen

Methode Einsatzbereich Was ist sichtbar? Was ist nicht sichtbar?
APIYI-Aufrufprotokoll Desktop, IDE und CLI Eingabe, Ausgabe, Cache-Lese- und Schreibvorgänge sowie Kosten pro Anfrage Gesprächsinhalte; eine Zeile entspricht einer Anfrage, die Werte für eine Runde müssen Sie selbst addieren
Codex /status Interaktive Oberflächen auf Desktop und CLI Kontextauslastung, verbleibende Ratenlimits und aktueller Token-Verbrauch Kosten
codex exec --json Nur nicht interaktive Ausführung Eingabe-, Cache-Lese-, Cache-Schreib-, Ausgabe- und Reasoning-Token pro Runde Daten aus der interaktiven TUI und dem Desktop-Client

Von diesen drei Methoden zeigt nur das Protokoll die Kosten. Voraussetzung ist, dass der verwendete Zugang überhaupt Protokolle und Nutzungsdetails bereitstellt. Bei einem offiziellen Abonnement lassen sich keine Details zu einzelnen Anfragen abrufen.


Schritt 1: Festlegen, wie der Tokenverbrauch von Codex gezählt wird

Bevor du mit der Auswertung beginnst, merk dir: Eine Anfrage ist nicht dasselbe wie eine Gesprächsrunde.

Eine Anfrage ist ein einzelner Aufruf, den Codex an das Modell sendet. Eine Runde umfasst den gesamten Ablauf von deiner Nachricht bis zu der Antwort, mit der Codex die Arbeit abschliesst. Während einer Runde liest Codex Dateien, führt Befehle aus und ändert Code. Nach jedem Tool-Aufruf muss es das Ergebnis zusammen mit dem vollständigen bisherigen Verlauf erneut an das Modell senden. Deshalb entspricht eine Gesprächsrunde im Log normalerweise mehreren Zeilen; bei komplexen Aufgaben können es Dutzende sein.

Wichtig ist auch: Das Modell selbst erinnert sich nicht daran, was vorher gesagt wurde. Die Eingabe in Runde N umfasst ungefähr den gesamten Inhalt der vorherigen N-1 Runden plus den neuen Inhalt der aktuellen Runde. Das ist der Hauptgrund, warum lange Gespräche mit der Zeit immer teurer werden.

codex-token-usage-per-turn-apiyi-logs-de-image-1

Prüfung: Wenn du mehrere Anfragen im Log siehst, kannst du erkennen, dass sie zur selben Runde gehören, und zählst nicht jede Zeile als eigene Runde.


Schritt 2: Ein eigenes Token für Codex anlegen

Die Auswertung setzt voraus, dass sich Codex-Anfragen im Protokoll isolieren lassen. Teilen sich Codex, Skripte und andere Tools denselben Schlüssel, können Sie später nicht mehr nach Token filtern.

  1. Öffnen Sie in der APIYI-Konsole die Token-Seite und klicken Sie auf „Token hinzufügen“. Wählen Sie einen Namen, den Sie leicht wiedererkennen, zum Beispiel mit „codex“ darin.
  2. Öffnen Sie die config.toml von Codex und ergänzen Sie unter model_providers einen Provider mit base_url = "https://api.apiyi.com/v1". Geben Sie über env_key die Umgebungsvariable an, aus der das Token gelesen werden soll.
  3. Setzen Sie model_provider auf diesen Provider. Desktop-App, IDE und CLI verwenden dieselbe Konfiguration – eine einmalige Änderung genügt.
  4. Verwenden Sie für alle anderen Tools separate Schlüssel und nutzen Sie das Codex-Token nicht anderweitig.

🎯 Technischer Tipp: Ein eigenes Token, die Filterung der Protokolle nach Token und der Export sind die drei Funktionen der APIYI- beziehungsweise apiyi.com-Konsole, die Ihnen bei der Auswertung helfen. Beim offiziellen Abonnement sind keine Details zu einzelnen Anfragen sichtbar. Mit einem eigenen Token lassen sich die Kosten für Codex separat berechnen.

Prüfung: Wählen Sie auf der Protokollseite nach einem Klick auf „Erweitern“ in den erweiterten Filtern unter „Token“ diesen Schlüssel aus. In der Liste sollten nur noch Anfragen von Codex erscheinen.


Schritt 3: Einzelne Anfragen im Aufrufprotokoll verstehen

Öffnen Sie api.apiyi.com/log oder wählen Sie im linken Menü „Protokoll“. Jede Zeile in der Liste steht für eine API-Anfrage.

Oben können Sie standardmäßig nach Zeitraum, Typ, Modell und Cache-Status filtern. Der Hinweis zum Cache-Status lautet: „Treffer = Cache lesen, kein Treffer = Cache erstellen“. Mit „Erweitern“ können Sie zusätzlich nach Token, Streaming, Eingabe- und Ausgabebereich, Zeit bis zum ersten Byte und weiteren Kriterien filtern.

Was die Protokollspalten bedeuten

Spalte Was Sie sehen So verstehen Sie die Angabe
Zeit Zeitpunkt, zu dem die Anfrage abgeschlossen wurde Standardmäßig UTC+0, 8 Stunden später als Pekinger Zeit
Modell Zum Beispiel gpt-5.6-terra Bei einem Modellwechsel wird der Cache nicht gemeinsam genutzt
Info Streaming/Nicht-Streaming, Zeit bis zum ersten Byte, Eingabe-/Ausgabe-Token, Betrag Die gesamte Anfrage auf einen Blick
Eingabe / Ausgabe Zwei Zahlen Eingabe = Eingabe-Token, Ausgabe = Ausgabe-Token; Denk-Token zählen normalerweise zur Ausgabe
Kosten Betrag in US-Dollar Betrag vor Rabatt, einschließlich des Gruppenmultiplikators
Details Einzelne Multiplikatoren, in den Cache geschriebene und aus dem Cache gelesene Token Cache-Treffer und -Schreibvorgänge sind hier separat aufgeführt – Sie müssen nicht raten

Bei Anfragen mit Cache zeigt die Spalte „Info“ sowohl die Anzahl der Cache-Treffer als auch die der Schreibvorgänge. Zeilen ohne Cache-Details zeigen nur eine Kombination wie „Nicht-Streaming Erstes Byte: N Sekunden Eingabe/Ausgabe Betrag“. Auch bei Bild- und Videomodellen, die pro Aufruf abgerechnet werden, erscheinen Eingabe und Ausgabe. Ihre Kosten werden aber nicht nach Token berechnet – verwenden Sie dafür also nicht die Berechnungsmethode aus diesem Artikel.

codex-token-usage-per-turn-apiyi-logs-de-image-2

Prüfung: Zeigen Sie auf eine beliebige Zeile. Sie sollten erklären können, wie viele Eingabe- und Ausgabe-Token die Anfrage hatte, wie viele Token aus dem Cache kamen und wie viel sie gekostet hat.


Schritt 4: Mehrere Log-Einträge zum Token-Verbrauch einer Codex-Runde zusammenfassen

Eine einzelne Zeile zeigt nur eine Anfrage. Um den Verbrauch einer Gesprächsrunde zu ermitteln, müssen die Werte addiert werden.

Die Regel: Addieren Sie alle Anfragen mit demselben Token und demselben Modell, die innerhalb von etwa fünf Minuten nach Ihrer Anweisung anfallen. Das Zeitfenster können Sie an Ihre Situation anpassen.

  1. Direkt auf der Seite nachsehen: Filtern Sie nach Token, Modell und Zeitraum und prüfen Sie die Prompt- und Completion-Werte Zeile für Zeile. Das eignet sich für gelegentliche Abfragen.
  2. Exportieren und nachrechnen: Klicken Sie oben rechts in der Liste auf „Exportieren“ und laden Sie die Daten als Excel- oder CSV-Datei herunter. Gruppieren und summieren Sie die Werte anschließend nach Zeit.
  3. API zur Log-Abfrage nutzen: Rufen Sie GET /api/log/self auf. Für die Authentifizierung benötigen Sie einen persönlichen Zugriffstoken, der mit nap_ beginnt. Ein API-Schlüssel mit dem Präfix sk_ führt zu einem 401-Fehler. Übergeben Sie die Parameter type=2 (nur Verbrauch), token_name, start_timestamp und end_timestamp (Unix-Zeit in Sekunden). Beachten Sie, dass der Paginierungsparameter in Camel Case geschrieben wird: pageSize. Die Schreibweise page_size wird ohne Fehlermeldung ignoriert.
  4. In einen Betrag umrechnen: Der von der Schnittstelle zurückgegebene Wert wird mit quota ÷ 500.000 = US-Dollar umgerechnet. Das Feld other ist ein JSON-String und muss separat geparst werden, um Details wie usage auszulesen.

Geben Sie bei der Log-Abfrage unbedingt ein Zeitfenster an. Empfohlen wird ein Zeitraum von höchstens einem Tag. Ohne Zeitfenster durchsucht die Schnittstelle den gesamten Verlauf; bei Konten mit vielen Daten kann das zu einem Timeout führen. Die Log-Abfrage selbst verbraucht kein Guthaben.

Was kostet eine Codex-Runde?

Modell Eingabe Cache-Lesezugriff Ausgabe Kontextfenster Rechenbeispiel: Kosten pro Runde
gpt-5.6-sol $4 $0,4 $20 1.000.000 ca. $0,214
gpt-5.6-terra $2 $0,2 $12 1.000.000 ca. $0,107
gpt-5.6-luna $0,2 $0,02 $1,2 1.000.000 ca. $0,011

Alle Preise gelten pro Million Tokens und wurden am 28.10.2026 abgerufen. Überschreitet die Eingabe einer einzelnen Anfrage 272.000 Tokens, verdoppelt sich der Eingabepreis.

💰 Hinweis zu den Preisen: Massgeblich sind die Modelle und Preise in der Modellliste von APIYI / apiyi.com. Das Rechenbeispiel geht von insgesamt 120.000 Eingabe-Tokens pro Runde aus, davon 96.000 aus dem Cache, sowie 4.000 Ausgabe-Tokens. Am Beispiel von sol: 24.000 ohne Cache-Treffer × $4 + 96.000 mit Cache-Treffer × $0,4 + 4.000 Ausgabe-Tokens × $20, geteilt durch eine Million, ergibt insgesamt rund $0,214.

Diese Zahlen zeigen zwei Dinge. Erstens: Die 96.000 Tokens aus dem Cache kosteten nur etwa $0,038 – Caching ist also entscheidend für die Kosten langer Gespräche. Zweitens: Mit luna kostet dieselbe Runde fast nur ein Zwanzigstel von sol. Allerdings weist die offizielle Seite von luna darauf hin, dass das Modell bei besonders langen Kontexten über 256K schwächer abschneidet.

codex-token-usage-per-turn-apiyi-logs-de-image-3

Prüfung: Du kannst berechnen, wie viele Eingabe-Tokens diese Runde mehr hatte als die vorherige, und angeben, wie viele davon aus dem Cache kamen.


Schritt 5: Anhand der Codex-Token-Daten entscheiden, ob Sie komprimieren oder ein neues Fenster öffnen

Mit den Daten jeder Runde lässt sich die Entscheidung anhand konkreter Zahlen treffen. Achten Sie vor allem auf drei Signale:

  • Wachstum der Eingabe: Wenn die Eingabe von Runde zu Runde immer stärker wächst, sammeln sich Tool-Ausgaben und Gesprächsverlauf schnell an.
  • Anteil der Cache-Lesezugriffe: Sinkt der in der Spalte „Erläuterung“ angegebene Anteil der Cache-Lesezugriffe an der Eingabe deutlich, hat sich das Präfix geändert. Neue Eingaben werden dann meist zum vollen Preis berechnet.
  • Eingabe pro Anfrage: Nähert sie sich 272.000 Token, überschreitet die nächste Anfrage die Preisstufe.

Entscheidungstabelle: komprimieren oder neues Fenster öffnen

Beobachtung im Log Empfohlene Aktion Grund
Die Eingabe pro Anfrage nähert sich 272.000 Token, die Aufgabe ist noch nicht erledigt Zuerst manuell /compact ausführen So vermeiden Sie, dass sich der Eingabepreis beim Überschreiten der Preisstufe verdoppelt
Die Eingabe pro Anfrage nähert sich 272.000 Token, die Aufgabe ist vorerst abgeschlossen Neues Fenster öffnen Ein Neustart ist sauberer als eine Komprimierung
Der Anteil der Cache-Lesezugriffe sinkt mehrere Runden hintereinander Neues Fenster für ein neues Thema öffnen Der Cache wird nicht mehr genutzt; bei einem weiteren Gespräch fällt meist der volle Preis an
Der Eingabezuwachs pro Runde steigt plötzlich stark an Tool-Ausgaben prüfen und bei Bedarf tool_output_token_limit senken Umfangreiche Befehlsausgaben wurden in den Verlauf geschrieben
Die Eingabe bleibt stabil, der Anteil der Cache-Lesezugriffe ist hoch Das aktuelle Gespräch fortsetzen Unter diesen Bedingungen bieten lange Gespräche das beste Preis-Leistungs-Verhältnis
Es wurde bereits einmal komprimiert und der Kontext ist schon wieder fast voll Neues Fenster öffnen Durch mehrfaches Komprimieren wird die Zusammenfassung immer gröber

codex-token-usage-per-turn-apiyi-logs-de-image-4


Kontextkomprimierung in Codex konfigurieren

Bei der Komprimierung werden frühere Gesprächsrunden durch eine kurze Zusammenfassung ersetzt. So entsteht wieder Platz im Kontextfenster. Codex unterstützt manuelle und automatische Komprimierung.

  1. Manuelle Komprimierung: Sowohl in der Desktop-App als auch in der CLI können Sie /compact eingeben.
  2. Automatische Komprimierung: model_auto_compact_token_limit legt den Schwellenwert fest. Ohne Angabe gilt der Standardwert des Modells.
  3. Berechnungsbereich des Schwellenwerts: Für model_auto_compact_token_limit_scope stehen total (der gesamte aktive Kontext) und body_after_prefix (nur der nach dem Präfix hinzugefügte Teil) zur Auswahl.
  4. Bei Verwendung einer base_url eines Drittanbieters: Ist der Modellname nicht in der integrierten Codex-Tabelle enthalten, sollten Sie model_context_window und den Schwellenwert für die automatische Komprimierung manuell festlegen. Soll die Komprimierung vor Erreichen der nächsten Preisstufe ausgelöst werden, setzen Sie den Schwellenwert unter 272.000.
  5. remote_compaction nicht ohne Weiteres aktivieren: Bei der Einstellung v2 muss der Upstream-Anbieter das Komprimierungsprotokoll der Responses-API unterstützen. Sicherer ist es, die Einstellung auf unsupported zu belassen und die lokale Komprimierung zu verwenden.

Die Kosten der Komprimierung

Komprimierung ist nicht kostenlos. Sie schreibt das bisherige Präfix um, wodurch der Cache ungültig wird. Die Eingabe der Anfrage nach der Komprimierung wird deshalb nahezu zum vollen Preis berechnet. Am besten beginnen Sie danach direkt mit einem neuen Thema, statt frühere Aufgaben zu wiederholen. Außerdem gehen bei der Komprimierung Details verloren: Die Zusammenfassung bewahrt nicht zwangsläufig alle Informationen.


Häufige Fragen (FAQ)

Q1: Ein Request ist im Log nicht zu finden. Wurde er nicht erfasst?

Das Log erfasst nur erfolgreich abgerechnete Aufrufe. Requests, die etwa wegen Netzwerk-, Authentifizierungs- oder Parameterfehlern scheitern, erreichen den Upstream-Anbieter nicht. Sie werden weder berechnet noch im Log angezeigt. Steht umgekehrt ein Eintrag im Log, sind für den Request tatsächlich Kosten angefallen. Prüfen Sie außerdem, ob der richtige Token-Filter und Zeitraum ausgewählt sind.

Q2: Warum ist der Betrag niedriger als meine Schätzung anhand der Token-Zahl?

Der häufigste Grund ist Caching. Der OpenAI-Kanal nutzt automatisches Präfix-Caching: Ist der Präfix mindestens 1024 Tokens lang und bleibt unverändert, greift der Cache. Für den zwischengespeicherten Teil werden 10 % des Eingabepreises berechnet. In der Spalte „Beschreibung“ der Logs von APIYI / apiyi.com sehen Sie, wie viele Tokens aus dem Cache gelesen wurden. Das Log zeigt außerdem den Betrag vor dem Rabatt. Die tatsächlichen Kosten betragen ungefähr: Log-Betrag ÷ (1 + Bonusanteil).

Q3: Warum stimmt die Zeit im Log nicht mit dem Zeitpunkt meiner Aktion überein?

Das Log zeigt die Zeit standardmäßig in UTC+0 an. Die Pekinger Zeit liegt bei UTC+8, also acht Stunden voraus. Wenn Sie nach der „Runde um drei Uhr nachmittags“ in Pekinger Zeit filtern, kann es deshalb so aussehen, als würden Daten fehlen. Rechnen Sie die Zeit vor dem Filtern einfach um.

Q4: Wie lange werden die Logs aufbewahrt?

Planen Sie damit, dass etwa die letzten 30 Tage abrufbar sind. Die tatsächliche Aufbewahrungsdauer kann länger sein, die Plattform gibt dafür aber keine Garantie. Auch die Löschrichtlinien können sich ändern. Wenn Sie Daten länger für den Abgleich benötigen, sichern Sie sie regelmäßig über „Exportieren“ oder die Log-Abfrage-API.

Q5: Zeigt das Log, welche Dateien Codex gelesen und welche Inhalte es gesendet hat?

Nein. Das Log enthält nur die für die Abrechnung benötigten Basisdaten, etwa Token-Zahl, Betrag und Multiplikator. Ein- und Ausgabeinhalte werden nicht aufgezeichnet. Was in einer bestimmten Runde passiert ist, können Sie direkt in der Codex-Unterhaltung nachsehen.

Q6: Gibt es eine einfachere Möglichkeit, den Verbrauch jeder Runde automatisch zu erfassen?

Bei der Ausführung per Skript können Sie `codex exec –json` verwenden und die Verbrauchsdaten aus dem Ereignis `turn.completed` auslesen. Bei interaktiver Nutzung können Sie die Daten über die Log-Abfrage-API regelmäßig anhand eines eigens dafür verwendeten Tokens und eines Zeitfensters abrufen und zusammenführen. Neue Nutzer können zunächst bei APIYI / apiyi.com kostenloses Testguthaben erhalten und den gesamten Ablauf ausprobieren.


Codex-Tokenverbrauch pro Gesprächsrunde: Das Wichtigste auf einen Blick

  • Die Anzeige ist noch da: Die Kontextauslastung finden Sie unter /status. In der CLI lässt sie sich mit /statusline auch in der Fusszeile anzeigen.
  • Anfrage ≠ Gesprächsrunde: Eine Gesprächsrunde umfasst mehrere Tool-Aufrufe und entspricht damit mehreren Zeilen im Log. Für die Gesamtkosten müssen Sie die Einträge im jeweiligen Zeitfenster addieren.
  • Dedizierter API-Schlüssel: Erstellen Sie für Codex einen eigenen Schlüssel, damit sich die Einträge im Log gezielt herausfiltern lassen.
  • Auf die Spalte mit den Details achten: Cache-Lese- und Schreibzugriffe werden separat aufgeführt. Cache-Treffer werden zu 10 % des regulären Preises berechnet.
  • 272K-Schwelle: Bei mehr als 272.000 Eingabe-Tokens in einer einzelnen Anfrage verdoppelt sich der Eingabepreis.
  • Komprimierung hat ihren Preis: Nach der Komprimierung wird der Cache ungültig. Die Eingabe dieser Anfrage wird dadurch fast vollständig zum regulären Preis berechnet. Danach lohnt es sich, direkt zu einem neuen Thema zu wechseln.

Fazit

Wenn Sie die Kontextauslastung in Codex nicht sehen, liegt das nicht daran, dass die Funktion entfernt wurde – sie ist nur an anderer Stelle zu finden. /status zeigt, wie viel Kontext noch verfügbar ist; das Aufrufprotokoll zeigt, was jede Gesprächsrunde kostet. Zusammen liefern beide die Zahlen für die Entscheidung, ob Sie ein neues Fenster öffnen sollten.

Probieren Sie es gleich aus: Erstellen Sie einen dedizierten API-Schlüssel für Codex, öffnen Sie die Logseite von APIYI / apiyi.com und addieren Sie die Anfragezeilen Ihrer letzten Gesprächsrunde.


📚 Referenzen

  1. Offizielles OpenAI-Codex-Repository: CLI-Quellcode und Ereignisdefinitionen
  2. Link: github.com/openai/codex
  3. Hinweis: In codex-rs/exec/src/exec_events.rs ist das Feld usage von turn.completed definiert.

  4. Offizielle Codex-Dokumentation: Referenz zu Slash-Befehlen und Konfiguration

  5. Link: developers.openai.com/codex
  6. Hinweis: Erläuterungen zu /status, /compact, /statusline und den Konfigurationsoptionen für die Komprimierung.

  7. APIYI-Hilfedokumentation: Aufrufprotokolle, Cache-Abrechnung und API zur Protokollabfrage

  8. Link: docs.apiyi.com
  9. Hinweis: Definitionen der Protokollfelder, Abrechnung von Cache-Treffern zu 10 % des regulären Preises und Umrechnung von quota.

Autor: APIYI-Technikteam
Technischer Austausch: Kontaktieren Sie uns über die APIYI-Startseite. Weitere Hinweise zur Konfiguration finden Sie im Dokumentationszentrum.

Weiterführende Artikel

Ähnliche Beiträge