Freitag, 31. Juli 2026

added

• Neue Lib `scripts/lib/xai-radar-usage.mjs`, gebaut analog zu `xai-gate-usage.mjs`. Zählt die x_search-Läufe von `finx-x-radar-grok.mjs` an den geschriebenen Ergebnisdateien in `twitter-data/x-radar/grok-*.json` — Tag aus `generated_at`, Fallback Dateiname, dann mtime. Das funktioniert rückwirkend über die gesamte Historie, ohne das Radar-Script anzufassen.
• `openclaw-token-meter.mjs` zeigt die Radar-Lane jetzt neben Gate und Vision, dazu eine Zeile `x_search gesamt` als Summe beider Lanes. Die durable JSONL-Zeile bekommt `radar`, `radarToday`, `radarAvg7CostUsd`, `radarUsdPerCall`, `xsearchCostUsd` und `xsearchMonCostEst`.

fixed

• **Gate-Kalibrierung korrigiert: $0.245 → $0.163 pro erfolgreichem Call.** Der ursprüngliche Divisor war falsch. Aus dem Konsolen-Abgleich vom 19.06. ($1.95 Tagestotal − $0.48 Vision = $1.47) wurde durch 6 Gate-Calls geteilt. Übersehen wurde, dass am selben Tag auch der Radar dreimal lief — belegt durch `grok-2026-06-19-{06,12,18}.json` — und über denselben Hermes-x_search-Pfad auf dieselbe Rechnung ging. Korrekt ist $1.47 / (6 + 3) = ~$0.163.
• Ohne diese Korrektur hätte das Hinzufügen der Radar-Lane die xAI-Kosten um rund 50 % überschätzt, weil die Radar-Calls dann doppelt eingepreist gewesen wären.
• Der Kalibrier-Hinweis im Report sagt jetzt explizit, dass durch *Gate + Radar* zu teilen ist, nicht nur durch die Gate-Calls.
• **Vision-Wächter nachgezogen.** Das Soft-Limit stand auf $0.10/Tag und lag damit unter *jedem* der 46 gemessenen Tageswerte — der Alarm feuerte an 39 von 39 rückrechenbaren Tagen und war als Signal wertlos. Neu $0.75/Tag, hergeleitet aus der Ist-Verteilung 12.06.–31.07.: Median $0.378, p90 $0.430, p95 $0.434, Max $0.479, keine Nulltage. Das sind ~57 % Luft über dem bisherigen Maximum, also Platz für mehr Ticker im Portfolio, und entspricht ~$22/Monat statt der aktuellen ~$10.50. Spike-Floor von $0.15 auf $0.30 angehoben, Spike-Multiplikator bleibt bei 2,5×.
• Arbeitsteilung der beiden Wächter jetzt im Code dokumentiert: Der relative Spike-Alarm fängt den plötzlichen Ausreißer und wandert mit dem Normalniveau mit; das absolute Limit ist der Backstop für den Fall, dass das Normalniveau selbst schleicht — dann schlägt der relative Wächter nämlich nie an.
• Rückrechnung über 39 Tage: alte Schwelle 39 Alarme, neue Schwelle 0. Ein 3×-Normaltag ($1.02) löst beide Wächter aus, ein 2×-Tag ($0.68) noch keinen.

zahlen nach dem umbau (17.05.–31.07.)

geprüft

• `w3yh.xyz/scripts/sync-token-meter.mjs` liest aus der JSONL nur `cost` und `gateCalls`. Beide sind unverändert, die Website-Zahlen ändern sich durch den Umbau nicht.
• Dry-Run des Meters läuft sauber durch, `node --check` ohne Befund. Cron unverändert .

offen

• Die Radar-Lane zählt Dateien, kein append-only Log. Wird `twitter-data/x-radar/` irgendwann aufgeräumt, verschwindet die Historie mit. Bei einem Archiv-Job also entweder die Zählung vorher einfrieren oder den Radar ein eigenes Usage-JSONL schreiben lassen.
• Fehlläufe des Radars (16 im Log, HTTP 403 permission-denied) werden nicht gezählt. Für die Kosten ist das korrekt — gescheiterte x_search-Versuche zeigt die Konsole mit $0 — als Betriebssignal fehlen sie aber.

befund

• Das `🌙 Daily Decision Briefing` meldete seit dem **02.06.2026** durchgehend „Keine Items mit Tyrone-Meinung". Letzte inhaltlich volle Ausgabe: 01.06. Von 83 Snapshots in `ceo-inbox/_briefings/` sind 59 leer.
• Ursache: `daily-decision-briefing.py` liest aus `~/.hermes/ceo-outbox/`. Jüngste Datei dort ist vom 26.05., seit der Hermes-Stilllegung am 12.06. wird nichts mehr nachgelegt. Zusammen mit `DEFAULT_MAX_AGE_DAYS = 7` erklärt das das Kippdatum exakt: ab 02.06. war auch die jüngste Datei zu alt.
• Kostenrelevanz war null. Ohne Items entstehen keine LLM-Calls, das Script rendert nur Dateien. Es war kein Geldleck, sondern ein totes Feature mit täglicher Leernachricht.

fixed

• Vier Crons auskommentiert: `ceo:setup-snapshot` (17:00), `ceo:outbox-reader` (alle 5 Min, 288×/Tag auf ein unverändertes Verzeichnis), `ceo:tyrone-opinion-writer` (17:15), `ceo:daily-decision-briefing` (17:30). Aktive Crontab-Zeilen 100 → 96. Backup unter `backups/crontab-before-ceo-chain-disable-20260731T091218Z.txt`.
• Dieselben vier Jobs in `scripts/qwen-cron-watchdog-inventory.json` auf `cadence: "disabled"` gesetzt, sonst hätte der Watchdog ab heute Abend Fehlalarme geschickt. Dry-Run danach: `status ok, issue_count 0`.

api-kostenanalyse (gleicher durchgang)

• Laufrate **44–59 $/Monat**, davon 85 % xAI. Bisher geflossen seit Mai ~143 $. Hart belegt: OpenRouter 28,74 $ lifetime (2,98 $/Monat), X-API-Posting 3,54 $ bei 354 Posts, xAI Vision 15,71 $. Der Rest — x_search — ist geschätzt.
• X-API läuft auf Pay-per-use, nicht mehr auf dem 200-$-Basic-Tier (X hat Legacy-Abos am 01.06. auto-migriert). Vom 2-Mio-Read-Kontingent sind 1 genutzt.
• **Alibaba lohnt nicht.** Die Ops-Lane, wo Qwen greifen würde, kostet 2,98 $/Monat. Der teure Posten (x_search) hängt an X-Echtzeitdaten, die kein anderer Anbieter liefert. Bei Vision wäre Gemini Flash-Lite (1,44 $/Monat) günstiger als Qwen3-VL (2,54 $) — Vision bleibt aber vorerst auf Grok, Neubewertung später gegen aktuelle OpenRouter-Vision-Modelle.
• `finx-x-radar-grok` läuft im Token-Meter unsichtbar (~37 $ unerfasst seit Mai). Erste Einschätzung „2 von 3 Läufen wertlos" war **falsch** und wurde von Dominik korrigiert: Konsument ist `finx-briefing-builder.mjs` via `twitter:finx-briefing-refill`, alle 3 h, mit 12-h-Frischefenster. Bei 3 Radar-Läufen im 6-h-Takt hat jeder der 8 Builder-Läufe frische Daten, bei 1×/Tag wären 4 von 8 leer. Der parallele Playwright-`x_radar` liefert `[]` — Grok ist derzeit die einzige funktionierende X-Trend-Quelle. Radar bleibt unverändert.
• Die Gate-Kalibrierung 0,245 $/Call vom 19.06. hat die 3 Radar-Calls jenes Tages den 6 Gate-Calls zugeschlagen. Realistischer sind ~0,163 $/Call — der Gate-Posten im Token-Meter ist um rund ein Drittel zu hoch, dafür fehlt der Radar ganz.

offen

• Token-Meter erfasst die Radar-Lane nicht. Solange das so bleibt, ist jede xAI-Zahl im Tagesreport unvollständig.
• Nächster xAI-Konsolen-Abgleich: Tagestotal minus Vision, geteilt durch *Gate + Radar*, nicht nur Gate.
• `ceo:outbox-reader` steht weiterhin in der `DEFAULT_FOCUS`-Liste von `scripts/cron-audit-report.mjs`. Harmlos, das Script läuft nicht per Cron und alarmiert nicht — beim nächsten Anfassen mitnehmen.
• Vision-Alternative bei OpenRouter prüfen, wenn dort neuere Vision-Modelle auftauchen.

added

• Neue geschützte Unterseite `/hub/health/renpho`, erreichbar über den Button „Renpho-Werte“ im bestehenden Health-Hub.
• Alle 13 Renpho-Messfelder als eigene Verlaufsgrafiken ergänzt: Gewicht, BMI, Körperfett, Skelettmuskel, fettfreie Körpermasse, subkutanes Fett, Viszeralfett, Körperwasser, Muskelmasse, Knochenmasse, Eiweiß, Grundumsatz und Stoffwechselalter.
• Gewicht zusätzlich mit geglättetem 7-Tage-Schnitt; Kopfbereich mit Messzeitraum, Messtagen und zentralen Veränderungen.

changed

• Der private Health-Datenservice liest die bereits importierten Renpho-Reihen direkt aus `health-live.db` und hängt nur die kuratierte Projektion an den geschützten Payload. Rohdaten und Datenbank bleiben auf dem VPS und gelangen weder ins Git-Repo noch in den Vercel-Build.
• BIA-Werte in der UI ausdrücklich als trendtaugliche Schätzwerte eingeordnet, die auf Hydration, Tageszeit und Messbedingungen reagieren.

verification

• Privater Service-Payload bestätigt: 39 Messtage vom 14.06. bis 28.07.2026, 13 Messfelder und 99,5 kg als letzter Gewichtswert.
• Gezieltes ESLint, TypeScript und direkter Next.js-Produktions-Build mit der dynamischen Route `/hub/health/renpho` grün.

fixed

• Ursache des Alarms vom 30.07. (`rc=1`) geklärt: `asts-pod-hub.vercel.app` lieferte auf die Root-URL einen HTTP 404 durch alle drei Abrufversuche in `fetch()` hindurch. Die Seite antwortet inzwischen wieder mit 200, die Crawl-Logik (`/?page=N`) war nie betroffen. Manueller Nachlauf um grün: 175 Episoden, 175 Transkripte, keine Waisen; Claim-Ledger, Watch-Items und Angle-Candidates neu gebaut.

added

• `asts-podcast-sync.sh` kennt jetzt `--retry`. Ein erster Fehlschlag setzt nur den Marker `logs/.asts-podcast-sync.failed` und schweigt; der Retry-Lauf arbeitet ausschließlich diesen Marker ab und alarmiert erst, wenn auch der zweite Versuch scheitert. Jeder Erfolg räumt den Marker. Vorher legte ein einzelner transienter Fehler das Archiv 24 Stunden still, weil erst der Folgetag wieder synchronisierte.
• Zweiter Cron-Eintrag `20 7 * * *` mit `--retry`, eine Stunde nach dem Hauptlauf um . Crontab-Sicherung unter `backups/crontab-before-asts-retry[id].txt`, Script-Sicherung als `asts-podcast-sync.sh.bak.[id]`.
• Alle fünf Pfade isoliert getestet (Retry ohne Marker steigt still aus, erster Fehlschlag schweigt und markiert, Retry-Fehlschlag alarmiert und räumt, Erfolg räumt) plus ein End-to-End-Lauf gegen den echten Hub.

open

• Die Folge „Why This Selloff Isn't About Fundamentals" (Spacanpanman) fehlt im Archiv, weil der Pod-Hub selbst noch auf dem 27.07. steht. Kein Eingriff nötig, der Cron zieht sie nach, sobald der Mirror sie listet.