Anything · Lazarus or Delphi

OpenAIUsageDashboard

Usage Dashboard for OpenAI's Codex (excluding ChatGPT, as it has no limits)

Active · last change 10-30-2026
★ 1 on GitHub

Member rating

No ratings yet.

README

# OpenAI Usage Dashboard (Delphi FMX)

Native FireMonkey-Anwendung für Win64 und Android64. Das Ziel wird im selben RAD-Studio-Projekt über den Plattform-Selektor umgeschaltet; PowerShell und ein Browser werden zur Laufzeit nicht benötigt.

Funktionsumfang

Screenshot|50%

OpenAI-Organisationskosten der letzten 30 Tage sowie Kosten/Anfragen/Tokens heute und in den letzten sieben Tagen
bis zu fünf Top-Modelle in einem kompakten 2×3-Kartenraster sowie weitere API-Dienste (Bilder, Embeddings, Web-/Dateisuche, Audio, Code Interpreter, Vector Stores und Moderation)
Modellnamen etwa 25 %, Anfragen 80 % und Tokens 50 % größer als ursprünglich; die Zusatzdienste verwenden dieselbe Caption-/Wert-/Detail-Typografie wie die Codex-Kennzahlen
API-Dienste nach Nutzung sortiert, maximal sechs Karten im 2×3-Raster; weitere Dienste bleiben im Snapshot erhalten
rechts daneben eine Modellvergleichsliste mit großem Namen, Tokenpreis und Intelligence Index; Datenstand, Preisbasis und Quellen sind sichtbar
Ausgabenlimit mit Prozentbalken und Limitlinie im Kostendiagramm
14 Kalendertage einschließlich heute (UTC): grüne Kostenbalken und schmale blaue Balken für API-Modellanfragen mit eigener Skala und täglichen Zahlenwerten; ausschließlich der Hintergrund von Wochenenden ist abgesetzt
kumulierter Ist-Verbrauch und kalenderbasierte Trendberechnung; der noch unvollständige heutige Tag wird aus der Prognosesteigung ausgeschlossen
vier kompakte Prognosepunkte für +7, +14, +21 und +28 Tage; der prognostizierte Betrag steht oben, ein Abrechnungswechsel als zweite Zeile darunter
sichtbarer Neustart von Ist-/Trendlinie am konfigurierten Abrechnungstag
lokale Codex-App-Server-Daten unter Windows: Rate-Limits, Reset-Zeitpunkte, Reset-Credits und Tokenstatistiken
vergrößerte Kleinbeschriftungen für bessere Lesbarkeit auf Wand- und Tablet-Displays
Wachhalten Montag bis Freitag von 10:00 bis 18:00 Uhr Ortszeit
Vollbild- und Mehrmonitorbetrieb
Windows-Sammlermodus ohne Dashboard-Fenster, mit Vcl.ExtCtrls.TTrayIcon
scrollbare Einstellungen innerhalb der verfügbaren Bildschirmfläche, einschließlich Android-Safe-Area und Bildschirmtastatur

Projekt öffnen und Target wechseln

OpenAIUsageDashboard.dproj in RAD Studio öffnen.
Im Projektmanager unter Target Platforms entweder Win64 oder Android64 aktivieren.
Debug oder Release wählen und normal bauen/deployen.

Das Projekt wurde mit RAD Studio 37/Delphi 13 erstellt. Für Android müssen SDK, NDK, Gerät und Signierung in RAD Studio eingerichtet sein. Das Manifest fordert Internetzugriff an, verwendet die beiden Landscape-Ausrichtungen und erlaubt für den hausinternen HTTP-Sammler Klartextverkehr.

Für einen Win64-Release-Build ohne IDE ./Build-Windows.ps1 verwenden. Das Skript erzeugt vor jedem Delphi-Build die Projektressourcen aus OpenAIUsageDashboard.rc neu, einschließlich des aktuellen Icons, Manifests und der Versionsinformationen. Ein bloßer dcc64-Aufruf übernimmt dagegen eine möglicherweise veraltete .RES. Optional wählen -DelphiBin und -OutputDirectory Compiler- bzw. Ausgabeordner. Für Ressourcen wird rc.exe aus dem Windows SDK verwendet; dessen Pfad kann mit -ResourceCompiler vorgegeben werden. Das ältere brcc32 verändert bei diesen Icons die Farbtiefenangabe der Gruppe fälschlich von 32 auf 24 Bit. tests/WindowsResources.Tests.dpr prüft die fertige EXE gegen assets/OpenAIUsageDashboard.ico: alle eingebetteten MAINICON-Bilder müssen bytegenau übereinstimmen und als Windows-Icons ladbar sein.

Das Windows-App-Icon liegt in assets/OpenAIUsageDashboard.ico, die bearbeitbare Vektorvorlage daneben als SVG. Es zeigt das ChatGPT-Grundsymbol mit rotem U auf transparentem Hintergrund und enthält 16, 20, 24, 32, 40, 48, 64, 128 und 256 Pixel mit 32-Bit-Farbe und Alphakanal. EXE, FMX-Fenster und Tray verwenden MAINICON. Das Tray lädt die passende kleine Größe direkt. Zusätzlich liegen eine ICNS-Datei mit Größen von 16 bis 1024 Pixeln einschließlich Retina-Varianten und transparente PNGs mit 44×44 und 150×150 Pixeln im selben Ordner. Die Projektoptionen verweisen für ICNS und Windows-Logos ebenfalls auf diese Dateien. Das Grundsymbol stammt aus den Vektor-Assets der installierten ChatGPT-App; das Blossom-Zeichen gehört OpenAI.

Die Android-Grafiken liegen in assets/android und sind für Android und Android64 in allen Konfigurationen eingetragen, einschließlich der Deployment-Pfade:

Transparente Legacy-Launcher-PNGs: 36, 48, 72, 96, 144 und 192 Pixel.
Aktiviertes adaptives Icon: Vordergrund mit dem gleichen Motiv, hellgrauer Hintergrund und eine weiße Alphamaske für monochrome/thematische Icons. Die drei Ebenen sind jeweils 432×432 Pixel groß (108 dp bei xxxhdpi); das vollständige Motiv bleibt innerhalb der geschützten 66-dp-Kreisfläche.
Weiße Benachrichtigungssymbole mit transparentem Hintergrund: 24, 36, 48, 72 und 96 Pixel. Android übernimmt die Einfärbung.
Transparente Startbilder: 426×320, 470×320, 640×480 und 960×720 Pixel mit dem eigenen Motiv anstelle des Delphi-Standardsymbols.

Nach einer externen Änderung der Projektdateien das Projekt in RAD Studio neu laden, damit die Symbol- und Bereitstellungsdialoge die neuen Pfade übernehmen.

Windows einrichten

Unter Windows läuft eine Instanz pro Benutzer und Windows-Sitzung. Die Sperre wird vor dem Anlegen von Dashboard, Tray-Symbol und Sammlern gesetzt. Gleichzeitige Starts über Aufgabenplaner, Desktop-Verknüpfung oder angehefteten Taskleisten-Link öffnen deshalb keine zusätzlichen Sammlerprozesse. Ein weiterer normaler Start fordert die laufende Instanz zum Anzeigen auf; die Anforderung bleibt auch während deren Start erhalten und wird vom Anwendungstimer spätestens beim nächsten Tick bearbeitet. Geöffnete Sammlereinstellungen samt ungespeicherten Eingaben bleiben erhalten. Ein weiterer Start mit --collector beendet sich ohne Einblenden.

Die Sperre wird nach vollständigem Beenden der Sammler freigegeben. Nach einem Absturz kann der nächste Start einen verlassenen Mutex übernehmen. Unterschiedliche Windows-Sitzungen bleiben getrennt; für das sichtbare Dashboard gehört der Aufgabenplaner-Start in die angemeldete interaktive Sitzung. Die Render-Vorschauen --render-preview und --render-settings-preview laufen unabhängig.

Beim ersten Wechsel auf diese Version müssen bereits laufende ältere EXEs beendet werden, da sie die neue Instanzsperre noch nicht verwenden.

Beim ersten Start öffnet sich die Einstellungskarte. Die Beschriftungen sind für den dunklen Hintergrund fest auf helle Schrift gesetzt; Eingabefelder behalten ihren hellen FMX-Standardstil mit dunkler Schrift. Edit- und Button-Schrift ist für Touchbedienung um 80 % vergrößert. Später öffnet ein Klick oder Fingertipp auf den Statusblock oben rechts (Aktuell / Stand) die Karte; F2 bleibt als Tastaturkürzel erhalten. Über App beenden lässt sich die Anwendung auch auf einem Touch-Gerät vollständig schließen.

Einen OpenAI Organization Admin Key eingeben.
Falls das gewünschte Periodenlimit nicht über die API verfügbar ist, das Limit in USD manuell eintragen.
Abrechnungstag (1 bis 28) und den Dashboard-Monitor in der beschrifteten Auswahlliste setzen. Automatisch wählt bevorzugt den ersten nicht primären Monitor; Auflösung und Hauptbildschirm sind direkt in der Liste erkennbar.
Für einen Android-Viewer einen ausreichend langen, zufälligen Viewer-Token setzen. Ohne Token lauscht der Snapshot-Server nur auf 127.0.0.1; mit Token auf allen lokalen Adressen, standardmäßig TCP-Port 8787.

Der Viewer-Token ist ein selbst gewähltes gemeinsames Kennwort für den Statistikabruf. Bei reinem Windows-Betrieb kann das Feld leer bleiben. Bei einem Android-Viewer auf beiden Geräten denselben Wert eintragen, beispielsweise eine mit dem Passwortmanager erzeugte Zeichenfolge mit 32 Zeichen. Es ist kein OpenAI-API-Key und wird nicht von OpenAI vergeben.

Der Admin-Key wird nicht in der INI gespeichert. Die Speicherung erfolgt in der vereinbarten Kette:

API-Key → AES-256-GCM mit Programmschlüssel → CryptProtectData (aktueller Windows-Nutzer) → CredWrite

Credential-Target: OpenAIUsageDashboard/AdminKey/v1. Temporäre Klartext- und Schlüssel-Bytepuffer werden nach Gebrauch überschrieben. Der eingebettete Programmschlüssel ist eine zusätzliche interne Schicht; die eigentliche Nutzerbindung liefert DPAPI.

Delphi 13 projiziert das WinRT-OUT-Array von CopyToByteArray unter Win64 nicht ABI-sicher. Die Anwendung liest die AES-GCM-Puffer deshalb über das native IBufferByteAccess-Interface aus; der geliehene Zeiger wird sofort kopiert und nicht freigegeben. Damit wird insbesondere der frühere Schreibzugriff auf Adresse 0x000C beim 12-Byte-Nonce vermieden.

Für Codex muss die lokale Codex-CLI installiert und angemeldet sein. Die App sucht auch die mit der Desktop-App ausgelieferte CLI unter %LOCALAPPDATA%\OpenAI\Codex\bin\<Version>\codex.exe, sodass ein Start aus dem Explorer ohne Codex im PATH funktioniert. Sie startet codex app-server unsichtbar und hält den Prozess für spätere Aktualisierungen offen. Ein Codex-Fehler verhindert nicht die Anzeige der OpenAI-API-Daten.

Die Codex-Limits und Tokenstatistiken benötigen eine ChatGPT-Anmeldung. Ein OpenAI-Admin-Key für die Kostenabfrage oder eine per API-Key angemeldete Codex-CLI kann diese Kontowerte nicht liefern. Codex-ChatGPT-Anmeldung.ps1 startet die Browseranmeldung für ein eigenes Dashboard-Profil unter %LOCALAPPDATA%\OpenAIUsageDashboard\Codex; mit -DeviceAuth wird stattdessen ein Gerätecode angezeigt. Nach erfolgreicher Anmeldung verwendet das Dashboard dieses Profil. Wurde die Anmeldung aus der Codex-Desktop-App gestartet, wird auch deren von Windows umgeleiteter MSIX-Datenordner gefunden. Damit verwenden Starts aus dem Explorer dieselbe Dashboard-Anmeldung. Die bisherige CLI-Anmeldung bleibt erhalten. Solange im Dashboard-Profil keine auth.json vorhanden ist, verwendet das Dashboard weiterhin das bisherige Codex-Profil. Das separate Profil enthält die lokale Codex-Anmeldung und zugehörige CLI-Daten; der OpenAI-Admin-Key bleibt im Windows-Credential-Store.

Fehlende Codex-Werte erscheinen als –; ein tatsächlich gemeldeter Nullwert bleibt 0. Gesamttokens und Tagesstatistiken können unabhängig verfügbar sein. Die konkrete Fehlermeldung steht unten in den Einstellungen (bei Bedarf scrollen). Der Header unterscheidet eine teilweise von einer vollständig fehlgeschlagenen Codex-Abfrage.

API-Kosten, Tagesbuckets und Abrechnungsgrenzen werden konsistent in UTC ausgewertet. Liefert die API für heute noch keinen Kostenbetrag, steht dort – mit entsprechendem Hinweis. Kosten können später als Anfragen eintreffen. Das Tagesdiagramm zeigt deshalb zusätzlich die Anzahl der API-Modellanfragen. Die blauen Balken bleiben auch an Tagen ohne gemeldeten Kostenbetrag sichtbar. Beide Balkenreihen werden unabhängig skaliert; gleiche Höhe bedeutet keinen gleichen Geldwert. Fehlende Tageswerte erscheinen als –, ausdrücklich gemeldete Nullwerte als 0. Die täglichen Modellanfragen und Tokens werden für 14 Tage abgerufen; die Sieben-Tage-Kennzahlen und Modellrangliste umfassen weiterhin nur die letzten sieben UTC-Kalendertage einschließlich heute. Die Codex-Nutzung aus dem ChatGPT-Abonnement ist in diesen API-Balken nicht enthalten. Für die neue Tagesansicht müssen Sammler und Viewer aktualisiert werden. Ältere Snapshots bleiben lesbar; ohne Tagesnutzung zeigen sie weiterhin die Kosten. Codex-Tokenstatistiken verwenden weiterhin den lokalen Kalendertag. Codex-Limitkarten benennen die tatsächlich gemeldete Fensterdauer, etwa 7 Tage oder 5 Stunden. Nur bei fehlender oder nichtpositiver Dauer bleibt die Beschriftung Primär beziehungsweise Sekundär; Prozente und Resetzeiten werden unverändert übernommen. Hat das Dashboard am selben Tag bereits einen Kosten- oder Codex-Tageswert empfangen, bleibt dieser bei einer vorübergehend unvollständigen Folgeantwort sichtbar. Beim UTC-Tageswechsel der Kosten beziehungsweise lokalen Tageswechsel der Codex-Nutzung werden keine alten Tageswerte übernommen. Eine vorhandene Codex-Bucket-Liste ohne Eintrag für den aktuellen Tag gilt nicht mehr als gemeldeter Nullwert. Nur ein ausdrücklich gelieferter heutiger Bucket mit null Tokens wird als 0 angezeigt; andernfalls erscheint – mit dem Hinweis, dass der heutige Wert noch nicht gemeldet wurde.

Die Modellrangliste heißt bewusst Top API-Modelle, da die API Platform eine Gruppierung nach Modell liefert, die Codex-Kontonutzung jedoch keine Modellnamen enthält.

Im Android-Settingsdialog werden Texte in Eingabefeldern, der Bildschirm- ComboBox einschließlich ihrer Listeneinträge und allen Schaltflächen unabhängig vom aktiven Android-/FMX-Style weiß dargestellt.

Android mit Windows-Sammler

Android enthält absichtlich keinen OpenAI-Admin-Key. In der Android-App werden eingetragen:

Sammler: http://<LAN-IP-des-Windows-PCs>:8787/snapshot
derselbe Viewer-Token wie unter Windows

Sowohl die API- als auch die lokalen Codex-Statistiken kommen vom Windows-Sammler. Android fragt OpenAI nicht selbst ab. Der Windows-PC muss deshalb eingeschaltet und der Sammler gestartet sein.

Gegebenenfalls muss TCP 8787 in der Windows-Firewall für das private Netz freigegeben werden. Der Snapshot enthält ausschließlich aufbereitete Statistik, nicht den Admin-Key. HTTP ist für ein vertrauenswürdiges internes LAN gedacht; für andere Netze sollte davor ein HTTPS-Reverse-Proxy eingesetzt werden.

Bei einem eigenständigen USB-C-/HDMI-Anzeigegerät verwendet Android eine Presentation: Das Dashboard erscheint auf dem externen Display, während das Tablet schwarz bleibt. Ein Tippen beziehungsweise Eingabe auf dem Tablet blendet die App-Steuerung ein; nach der eingestellten Inaktivitätszeit (Standard zehn Minuten) wird sie wieder schwarz. Bei reinem Display-Mirroring kann Android die beiden Bildschirme technisch nicht unterschiedlich darstellen.

Die Bildschirmauswahl bietet auf Android Automatisch, den integrierten Tablet-Bildschirm und jedes aktuell angeschlossene Presentation-Display mit Name und Auflösung an. Bei mehreren externen Displays erhält nur das ausgewählte das Dashboard; alle übrigen bleiben schwarz. Ist ein ausdrücklich gewähltes externes Display nicht angeschlossen, fällt die Anzeige sicher auf das Tablet zurück.

Die App kann auf Android nur ihre eigene Activity schwärzen beziehungsweise anzeigen; fremde Apps oder die Android-Systemoberfläche werden nicht global überlagert.

Windows nur als Sammler / Tray

In den Einstellungen wechselt Nur Sammler / Tray sofort in den Hintergrund. Der Snapshot-Server und die regelmäßigen Abfragen laufen unverändert weiter. Beim Start nur Sammler (Tray-Symbol) ist eine separate, mit Speichern gesicherte Startoption. Alternativ kann eine Verknüpfung OpenAIUsageDashboard.exe --collector verwenden. Ohne gespeicherten Admin-Key öffnet sich zunächst die Einrichtung; bei einem fehlgeschlagenen Tray-Start wird das Fenster nicht versteckt.

Ein linker Doppelklick auf das Tray-Symbol blendet das Dashboard abwechselnd ein und aus. Das Kontextmenü bietet je nach Zustand Dashboard anzeigen oder Dashboard ausblenden sowie Einstellungen, Nur Sammler und Beenden. Solange das Tray-Symbol verfügbar ist, erscheint auch bei sichtbarem Dashboard oder geöffneten Einstellungen kein zusätzlicher App-Button in der Taskleiste. Einstellungen lassen sich im Sammlermodus in einem normalen Fenster bearbeiten; Speichern, Abbrechen und das Schließen dieses Fensters kehren zum Tray zurück. App beenden bzw. Beenden stoppt auch den Sammler.

Im Sammlermodus gibt es keine schwarzen Abdeckfenster und keine Anforderung, die Monitore wachzuhalten. Montag bis Freitag zwischen 10 und 18 Uhr verhindert ES_SYSTEM_REQUIRED lediglich den automatischen Standby des PCs, damit Android weiter Daten abrufen kann. Außerhalb dieses Zeitfensters gelten wieder die normalen Energieeinstellungen. Manuell ausgelöster Standby wird nicht verhindert.

Das ist bewusst kein Windows-Systemdienst: Die Anwendung läuft im angemeldeten Benutzerkonto, damit der mit DPAPI geschützte API-Key und die dort angemeldete Codex-CLI verfügbar bleiben. Ein Start vor der Benutzeranmeldung wird nicht eingerichtet. Die Tray-Unit bindet die VCL-Komponente ausschließlich für Windows ein; Android bleibt eine FMX-Anwendung ohne diese Abhängigkeit.

Die Einstellungen passen sich auch flachen Landscape-Fenstern an. Sie bleiben innerhalb der nutzbaren Fläche; weitere Inhalte sind vertikal erreichbar. Auf schmalen Bildschirmen werden Felder und Buttons untereinander angeordnet, ohne die Touchflächen oder Schrift zu verkleinern.

Mehrmonitor- und Wachhalteverhalten

Für das Android-Wanddisplay die Bildschirmsperre auf Keine setzen und das Dashboard geöffnet lassen. Weckzeit erlauben in den App-Einstellungen öffnet bei Bedarf Androids Freigabe Wecker und Erinnerungen. Ohne diese Freigabe kann Android den Termin verzögert zustellen; die App zeigt das an. Eine PIN oder ein Passwort wird nicht automatisch entsperrt. App beenden löscht die Wecktermine; beim nächsten App-Start werden sie wieder eingerichtet.

Aufwecken testen setzt einen separaten Termin in 30 Sekunden. Danach das Display mit der Ein/Aus-Taste ausschalten. Der reguläre Werktagstermin bleibt bestehen. In den Einstellungen stehen der nächste Termin und das Ergebnis des letzten Einschaltversuchs. Der kurze Bildschirm-Wake-Lock läuft nach 15 Sekunden ab; innerhalb der Anzeigezeit hält anschließend die sichtbare Activity den Bildschirm weiter eingeschaltet. Außerhalb der Anzeigezeit gilt wieder das normale Android-Displaytimeout. Das Starten einer inzwischen vom System beendeten App und Einschalten auf anderen Android-Versionen unterliegt den jeweiligen Hintergrund- und Gerätebeschränkungen.

Die Java-Anbindung wird durch android/DashboardWake.targets automatisch mit dem in RAD Studio konfigurierten JDK/Android-SDK gebaut und als JAR in die APK aufgenommen. Es ist kein zusätzlicher manueller JAR-Import notwendig.

Die Protokolle vom 7./8. Oktober 2026 zeigen nach jedem Einschaltbefehl nur etwa eine Sekunde on, dann wieder off. Dadurch startete die bisherige Logik ständig erneut mit retry=1; die vorgesehene Minutenpause wurde nie erreicht. Die neue Stabilitätsprüfung verhindert diese Schleife. Der zusätzliche Aktivitätsimpuls adressiert den beobachteten Unterschied zum erfolgreichen Aufwecken per Maus oder Tastatur. Die physische Wirkung muss auf dem betroffenen PC geprüft werden; Windows-Meldungen allein bestätigen weiterhin kein sichtbares Monitorsignal.

Windows-API-Referenzen: SetThreadExecutionState, SC_MONITORPOWER, SendInput, WM_DISPLAYCHANGE, Monitor-Gerätekennung, Displayzustandsmeldungen, Benachrichtigungen und Vollbildregel.

Zum Prüfen auf dem Ziel-PC: Die neue EXE anstelle der bisherigen starten, das Windows-Monitortimeout unverändert lassen und das nächste Zeitfenster abwarten (oder die vorhandenen KeepAwakeStartHour/KeepAwakeEndHour in der INI für einen kurzen Test anpassen und neu starten). Nach Rückkehr des Monitors sollte das Dashboard innerhalb weniger Sekunden wieder auf ihm liegen. Im Log müssen beim Eintritt ins Zeitfenster KeepAwake=True, flags=$80000003 und anschließend Display power-on requested erscheinen; außerhalb flags=$80000001. Ein vorheriges Windows suspend notification bzw. späteres Resume=True weist auf einen zusätzlichen PC-Standby hin. Fehlende 10-Uhr-Einträge allein beweisen dessen Ursache nicht; dann auch Prozesslaufzeit und Windows-Ereignisprotokoll prüfen.

Einstellungen

Der erste Abruf beginnt direkt beim Start, auch im Sammlermodus. Kosten und Anfragezahlen werden angezeigt, sobald diese Abfragen fertig sind; Codex und weitere Dienstdetails folgen. Währenddessen zeigt die Statuszeile den laufenden Abruf an. Nach Abschluss wartet das Dashboard standardmäßig fünf Minuten bis zur nächsten Runde (RefreshSeconds=300). In den Einstellungen lässt sich das Intervall als Sekundenwert frei eingeben (10–3600 Sekunden) oder über 30s, 1m, 5m, 15m auswählen. Speichern übernimmt die Auswahl; „Jetzt aktualisieren“ bleibt für einen sofortigen Abruf verfügbar.

Unkritische Einstellungen liegen pro Nutzer in Dokumente\OpenAIUsageDashboard.ini. Dort können bei Bedarf auch diese Werte angepasst werden:

ini

[Network]
ListenPort=8787

[Usage]
RefreshSeconds=300
UseDemoWhenUnavailable=1

[Display]
StartInTray=0
KeepAwakeStartHour=10
KeepAwakeEndHour=18
OtherDisplayIdleMinutes=10

Verifikation

Eine Android-APK wird anschließend von RAD Studio mit der lokal konfigurierten SDK-/NDK-Toolchain und Signierung erzeugt.

Doppelklick auf das Dashboard (Windows)

Ein linker Doppelklick auf die Dashboard-Fläche aktiviert den vorhandenen Sammler-/Tray-Modus. Das Fenster wird ausgeblendet, die Abfragen laufen weiter. Per Tray-Doppelklick oder Tray-Menü lässt sich das Dashboard ein- und ausblenden. Das Einstellungssymbol und das geöffnete Einstellungsfenster sind von dieser Aktion ausgenommen.

Limitwarnungen im Hintergrund (Windows)

Der Tray-Hint zeigt den höchsten verfügbaren Prozentverbrauch der Codex-Limits und eines konfigurierten API-Ausgabenlimits, etwa OpenAI-Nutzung · 93 % verbraucht. Nur Sammler und der fehlerfreie Status Aktuell entfallen; Fehlermeldungen bleiben sichtbar. Bei mehr als 90 % Verbrauch zeigt ausschließlich das Tray einen roten Knoten mit schwarzem U. Bei 90 % oder weniger kehrt das normale Symbol zurück. Fehlende oder ungültige Limits werden nicht als 0 % ausgegeben. Das Warnsymbol liegt als SVG/ICO in assets/OpenAIUsageDashboard-Warning.* und als separate Ressource in Dashboard.TrayIcons.res, damit ein IDE-Build der Hauptressource es nicht überschreibt. Build-Windows.ps1 baut beide Ressourcen.

Bei minimiertem oder im Tray ausgeblendetem Dashboard erscheint ein kurzer Balloon auf dem Bildschirm des Mauszeigers, sobald das verbleibende Codex-Budget 20 %, 10 %, 9 % bis 1 % oder schließlich 0 % erreicht/unterschreitet. Der Hinweis nennt Limit, Zeitfenster, Restbudget und – sofern geliefert – die Zurücksetzungszeit. Er bleibt ungefähr sieben Sekunden sichtbar und spielt einmal den Windows-Warnton (abhängig von den Windows-Toneinstellungen). Der Tastaturfokus bleibt erhalten.

Voraussetzung sind eine aktive, entsperrte Sitzung, ein nicht ausgeschalteter oder gedimmter Bildschirm und eine Eingabe innerhalb der letzten zwei Minuten. Ist der Bildschirmstatus noch unbekannt, gelten die Sitzungs- und Eingabeprüfung. Die Warnung weckt keine Monitore auf. Das normale Abfrageintervall bestimmt, wann ein neuer Verbrauch erkannt wird; zusätzliche API-Abfragen gibt es nicht.

Je Limitfenster wird eine Schwelle während eines Anwendungslaufs nur einmal gemeldet. Bei übersprungenen Schwellen zählt der aktuelle Restwert. Mehrere betroffene Limits erscheinen nacheinander mit mindestens zehn Sekunden Abstand. Während Inaktivität bleibt die aktuelle Warnung vorgemerkt; fehlende, ungültige, abgelaufene oder veraltete Daten und Demodaten bleiben still. Daten gelten nach zwei Abfrageintervallen, mindestens zwei Minuten, als veraltet. Ein neues Limitfenster oder eine deutliche Budgeterholung (mindestens 20 Prozentpunkte) aktiviert die Schwellen erneut. Nach einem Programmneustart kann der bereits niedrige aktuelle Restwert einmal erneut gemeldet werden.

Modellpreise und Intelligence Index

Der rechte Teil der bisherigen Dienstekarten zeigt jetzt einen Modellvergleich. Die Datenzeile zeigt die Standard-API-Preise für Eingabe und Ausgabe getrennt, jeweils in USD pro Million Tokens und ohne Cache. Sie ist eine Tariforientierung; Tokenverbrauch und Kosten pro Anfrage können je Modell und Reasoning-Stufe unterschiedlich ausfallen. Die Intelligence-Werte stammen von Artificial Analysis (v5.0, jeweils max). Fehlende vergleichbare Bewertungen erscheinen als –.

Die Referenzwerte sind mit Standdatum eingebunden und werden nicht automatisch aktualisiert. Preisbasis, vollständige Liste, Quellen und Prüfergebnisse stehen in docs/ModelReference.md.

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

OOpenAIUsageDashboard