Die Solver-Stufe erzeugt langen Python-Code plus Reasoning. Bei komplexen
Aufgaben (Portfoliomanagement: 4× je ~26k Reasoning-Tokens am 32k-Limit
abgeschnitten, $0,28 für nichts) reichte das globale Limit nicht. DeepSeek
V4.1 Flash unterstützt bis 393k Output-Tokens (OpenRouter).
Neu: LLM_MAX_TOKENS_SOLVER (Default 65536, 0 = globales Limit gilt auch
für den Solver). Wirkt nur für die Stufen 'Solver-Code' und 'Solver-Reparatur'.
CLI-Option --max-tokens-solver. 438 Tests grün.
Grundlinie 20260918-191400: 9 von 22 Läufen hatten Aufrufe, die an LLM_MAX_TOKENS abgeschnitten
wurden (Venice 4/28, Makora 2/43, übrige 0/54); hard_portfolio_kardinalitaet brach nach vier
Abschneidungen ab, Kosten gingen verloren.
- Abschneiden: sofort neu versuchen, Anbieter per provider.ignore meiden (_avoid_provider,
gemeinsam mit „zu langsam“)
- nach allen Wiederholungen LLMUnavailable (Stufe + Ursache); fatale Fehler bleiben unverpackt
- Solver-Stufe behält Modell und Prüfbericht (Solver-Fehler), Gegenprobe behält erstes Ergebnis,
davor Ergebnis ohne Spezifikation mit Kosten („LLM-Fehler“, Report „Lauf abgebrochen“)
- Benchmark: Status „LLM-Fehler“ statt ABBRUCH, zählt nicht als ehrliches Scheitern
- TextToModel.py: Shebang
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- discarded_completions: an LLM_MAX_TOKENS abgeschnittene oder am Schema gescheiterte
Antworten sind bezahlt und zählen jetzt als Stufe „<Stufe> (verworfen)“ in Kosten,
Tokens und Aufrufen (wagner_whitin_dijkstra: ~32.000 Tokens fehlten).
- OPENROUTER_SWITCH_BELOW (Default = OPENROUTER_MIN_THROUGHPUT, 75): liefert ein Aufruf
ab 1000 Tokens weniger Tokens/s, wird der Anbieter per provider.ignore für den Rest
des Laufs gemieden (höchstens 3) und eine neue session_id vergeben; „No endpoints
found“ hebt die Sperrliste auf. Anlass: Sticky Routing hielt einen Lauf 1575 s bei
~65 Tokens/s (Median über 1012 Aufrufe: 156). provider.ignore mit echtem Aufruf geprüft.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- CallRecord.responded_model / LLMUsage.responded_models: tatsächlich antwortendes
Modell (beim Alias ~deepseek/deepseek-flash-latest) in Log, Report und Benchmark
- normalize_number: führende Null ist nie Tausender (0.040 wurde als 40 gelesen)
- numbers_in: LaTeX-Dezimalkomma 0{,}08 als eine Zahl
- question_ids_in: '### Teil N' als Teilfrage; ausdrückliche Marker haben Vorrang
vor nummerierten Listen
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Eingebettete Base64-Bilder und Bilddateien werden aus dem Aufgabentext gelöst und nur
der Verstehensstufe als Bild übergeben; sie überträgt jede Abbildung in Text. Eine
zweite, unabhängige Lesung wird Zahl für Zahl verglichen (bei Abweichung entscheidet
eine dritte, sonst reliable=False). Alle weiteren Stufen rechnen mit der Übertragung,
der Report zeigt Original und Übertragung nebeneinander. LLM_MODEL_UNDERSTANDING
wählt das Bildmodell.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
OpenRouter-Aufrufe eines Laufs tragen eine gemeinsame session_id (Sticky Routing,
damit der Anbieter-Cache greifen kann); Cache-Treffer werden je Aufruf und Stufe
erfasst und im Log als Anteil ausgewiesen. docs/Konzeptionelle_Fragen_und_Antworten.md
hält Pipeline-Stufen und die Abwägung ein Aufruf vs. Kette mit Messdaten und Quellen fest.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Im Wurzelverzeichnis liegt nur noch TextToModel.py (Ablauf und CLI).
Jede Stufe liegt mit Code und Prompt in einem eigenen Ordner: core,
understanding, modeling, checks, solving, reporting, data, benchmark;
Tests unter tests/, Aufgaben unter tasks/. understand_task,
text_to_model/revise_model und review_assumptions/needs_work/select_best
sind aus TextToModel.py zu ihren Prompts gewandert, inhaltlich
unveraendert. Prompt-Kennung des Benchmarks bleibt 93744636095a.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
