iris-claude-exec: claude vom Iris-Proxy entkoppeln (eigener Proxy-Prozess) #175
Labels
No labels
herkunft/alpha-feedback
status/blockiert
status/zu-testen
typ/bug
typ/docs
typ/enhancement
typ/feature
typ/idea
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
alf/2ndbrain#175
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Warum
iris-claude-execfragt Iris nach dem Agent-LLM und setztANTHROPIC_BASE_URLauf den Anthropic↔OpenAI-Proxy, der als Swift-Code im Iris-Prozess läuft (AnthropicProxyManager, Ports 18093–18095). Wird Iris beendet oder dort ein anderes LLM gewählt, ist der Proxy weg bzw. zeigt auf das neue Backend (start()ruftkillAnyProcessOnPort) — ein laufendesclaudebricht mit Connection Refused ab.Ziel
claudeläuft nach dem Start in genau der gestarteten Konfiguration weiter, unabhängig von Iris.Umsetzung
tools/iris-anthropic-proxy: eigenständiger Anthropic→OpenAI-Proxy (Python, nur Standardbibliothek), Portierung der Swift-Übersetzung; freier Port,--detach(fork/setsid), beendet sich, wenn der--watch-pid(dasclaude) endet.tools/iris-claude-exec: bei ollama/lmstudio/openaicompat diesen Proxy starten undANTHROPIC_BASE_URLdarauf setzen. Iris wird nur beim Start gefragt.Grenzen
iris-agent-common.shsetzt die Base-URL direkt auf die Cloud (Iris nutzt dort einen Proxy mit Key) — nicht Teil dieses Issues.splashkenntiris-agent-common.shnicht.num_ctxaus Iris wird nicht übernommen.PR #176 gemergt: feat(tools): iris-claude-exec entkoppelt claude von Iris durch eigenen Proxy (#175)
http://docker:3000/alf/2ndbrain/pulls/176
Commits:
Befund: Bei ollama/lmstudio/openaicompat hing
claudeam Anthropic↔OpenAI-Proxy im Iris-Prozess (Ports 18093–18095). Iris beenden oder LLM wechseln ließ ihn sterben bzw. umziehen; Iris killt beim Proxy-Start zudem alles auf dem festen Port.Geändert:
tools/iris-anthropic-proxy(neu): eigenständiger Proxy, Python/stdlib, Portierung der Übersetzung ausAnthropicProxyManager.swift; freier Port,--detach, beendet sich mit dem--watch-pid.tools/iris-claude-exec: startet bei ollama/lmstudio/openaicompat diesen Proxy und setztANTHROPIC_BASE_URLdarauf; Iris wird nur beim Start gefragt.Geprüft: Proxy gegen ein Fake-OpenAI-Backend: Nicht-Streaming, Streaming mit Text und Tool-Call (stop_reason, usage),
stream_options/Tool-Schema im Backend-Request, Modellwahl bei genau einem Backend-Modell,--detach, Selbstbeendigung nach Ende der überwachten PID. Syntax voniris-claude-exec(bash -n).Nicht geprüft: kompletter Lauf mit echtem Iris, vLLM/Strata und
claude; ob/configbei openaicompat das Modell unteragent.modelliefert; LM Studio und Ollama; Verhalten nach Iris-Beenden/LLM-Wechsel in der Praxis.Grenzen: openai/openrouter bleiben beim direkten Cloud-Base-URL von
iris-agent-common.sh;splashunbekannt dort; Ollamanum_ctxnicht übernommen. Anders als die Swift-Version reicht der Proxy Backend-HTTP-Fehler anclaudedurch statt eines leeren Streams.Offen: Praxistest durch Alf (daher
status/zu-testen).PR #177 gemergt: docs: session-kontext — Entkopplung von Iris (#175)
http://docker:3000/alf/2ndbrain/pulls/177
Commits:
PR #188 gemergt: fix(tools): iris-claude-exec pinnt das Agent-LLM je Projektordner, Splash als Backend (#175)
http://docker:3000/alf/2ndbrain/pulls/188
Commits:
Befund (Fehlerbild von Alf, 2026-11-11 20:24): Nach dem Umstellen des Agent-LLM in Iris auf Splash scheiterte der laufende Craft-Anything-Auftrag sofort mit „Unbekanntes Agent-LLM-Backend 'splash'“. Zwei Ursachen: (1)
iris-agent-common.shkanntesplashnicht; (2) Craft Anything startetclaudefür jeden Schritt neu (claude -p … --resume), und jeder Start voniris-claude-execlas das aktuelle Agent-LLM aus Iris. Die Entkopplung aus diesem Issue galt nur für einen schon laufendenclaude-Prozess, nicht zwischen den Schritten.Geändert:
~/.config/iris/claude-exec-pins/<hash>.json): Der erste Start liest das Agent-LLM aus Iris und hält Backend, Modell und Server-Adressen fest; jeder weitere Start nimmt den Pin und fragt Iris nicht mehr (Iris darf beendet sein). Lösen:iris-claude-exec --iris-unpinim Projektordner, oderIRIS_CLAUDE_EXEC_REPIN=1.--version/--helpgehen direkt anclaude(Craft Anything prüft damit nur, ob das Programm startet; dafür braucht es weder Iris noch ein Agent-LLM).splashals Backend: Claude Code spricht Splash direkt an (http://127.0.0.1:18100, Tokensplash, Modellaliase auf das eine Modell, Fenster 262144, Komprimieren ab 220000), wie inAgentJob.swift/splashClaudeTerminalCommand; Ausgabe auf 32000 begrenzt,CRAFT_ANYTHING_MCP_LEAN_TOOLS=1wie bei den anderen lokalen Backends.Geprüft (mit einem falschen
claude, einem Fake-Backend und einem temporären Projektordner, Iris absichtlich nicht erreichbar):--versionohne Iris; ohne Pin und ohne Iris → klare Fehlermeldung; mit Pin (openaicompat) → Start ohne Iris-Anfrage, eigener Proxy, Umgebung korrekt, Proxy beendet sich nach demclaude; Pin Splash → Umgebung wie in Iris; gepinntes Backend tot → Abbruch mit Hinweis;--iris-unpinundIRIS_CLAUDE_EXEC_REPIN=1.Nicht geprüft: ein echter Craft-Anything-Lauf mit Umstellen des LLM mitten im Auftrag; Splash gegen den echten Server (auf dem Test-Rechner lauschte auf 18100 bereits ein echter Prozess, mein Fake konnte dort nicht binden); LM Studio und Ollama; ob der Splash-Server nach einem Iris-Neustart noch läuft (ohne Iris startet ihn kein Pin).
Grenzen: Der Pin gilt je Arbeitsverzeichnis, nicht je Craft-Anything-Projekt-ID. Ein gepinntes Modell, das auf dem Server inzwischen entladen wurde, meldet der Start nicht (nur die Erreichbarkeit). Der Pin wird nicht von selbst erneuert: wer das Agent-LLM bewusst wechseln will, löst ihn.
Offen: Praxistest durch Alf (
status/zu-testen).PR #353 gemergt: fix(terminal-scripts): Bundle-Kopie von iris-agent-common.sh — Splash und Pin-Funktionen (alf/2ndbrain#175)
http://docker:3000/iris/Iris/pulls/353
Commits:
Befund (Fehlerbild von Alf, 2026-11-11 20:24): Nach dem Umstellen des Agent-LLM in Iris auf Splash scheiterte der laufende Craft-Anything-Auftrag sofort mit „Unbekanntes Agent-LLM-Backend 'splash'“. Zwei Ursachen: (1)
iris-agent-common.shkanntesplashnicht; (2) Craft Anything startetclaudefür jeden Schritt neu (claude -p … --resume), und jeder Start voniris-claude-execlas das aktuelle Agent-LLM aus Iris. Die Entkopplung aus diesem Issue galt nur für einen schon laufendenclaude-Prozess, nicht zwischen den Schritten.Geändert:
~/.config/iris/claude-exec-pins/<hash>.json): Der erste Start liest das Agent-LLM aus Iris und hält Backend, Modell und Server-Adressen fest; jeder weitere Start nimmt den Pin und fragt Iris nicht mehr (Iris darf beendet sein). Lösen:iris-claude-exec --iris-unpinim Projektordner, oderIRIS_CLAUDE_EXEC_REPIN=1.--version/--helpgehen direkt anclaude(Craft Anything prüft damit nur, ob das Programm startet; dafür braucht es weder Iris noch ein Agent-LLM).splashals Backend: Claude Code spricht Splash direkt an (http://127.0.0.1:18100, Tokensplash, Modellaliase auf das eine Modell, Fenster 262144, Komprimieren ab 220000), wie inAgentJob.swift/splashClaudeTerminalCommand; Ausgabe auf 32000 begrenzt,CRAFT_ANYTHING_MCP_LEAN_TOOLS=1wie bei den anderen lokalen Backends.Geprüft (mit einem falschen
claude, einem Fake-Backend und einem temporären Projektordner, Iris absichtlich nicht erreichbar):--versionohne Iris; ohne Pin und ohne Iris → klare Fehlermeldung; mit Pin (openaicompat) → Start ohne Iris-Anfrage, eigener Proxy, Umgebung korrekt, Proxy beendet sich nach demclaude; Pin Splash → Umgebung wie in Iris; gepinntes Backend tot → Abbruch mit Hinweis;--iris-unpinundIRIS_CLAUDE_EXEC_REPIN=1.Nicht geprüft: ein echter Craft-Anything-Lauf mit Umstellen des LLM mitten im Auftrag; Splash gegen den echten Server (auf dem Test-Rechner lauschte auf 18100 bereits ein echter Prozess, mein Fake konnte dort nicht binden); LM Studio und Ollama; ob der Splash-Server nach einem Iris-Neustart noch läuft (ohne Iris startet ihn kein Pin).
Grenzen: Der Pin gilt je Arbeitsverzeichnis, nicht je Craft-Anything-Projekt-ID. Ein gepinntes Modell, das auf dem Server inzwischen entladen wurde, meldet der Start nicht (nur die Erreichbarkeit). Der Pin wird nicht von selbst erneuert: wer das Agent-LLM bewusst wechseln will, löst ihn.
Offen: Praxistest durch Alf (
status/zu-testen).PR #189 gemergt: fix(tools): Proxy auch für iris-claude.sh, Pin nur für Fortsetzungen (#175)
http://docker:3000/alf/2ndbrain/pulls/189
Commits:
Befund (Rückfrage Alf, 2026-11-11): Erwartet war: Beim Start einmal nachsehen, welches Agent-LLM Iris hat, dann
claudedamit starten und unabhängig von Iris weiterlaufen lassen. Zwei Abweichungen: (1) Das interaktiveiris-claude.shbenutzte weiter den Proxy im Iris-Prozess und war nicht entkoppelt (nuriris-claude-exechatte den eigenen Proxy). (2) Der Pin aus dem vorigen Stand galt pauschal je Arbeitsverzeichnis und nicht ab dem Start einer Sitzung. Zur Ursache des Fehlerbilds: Auf den laufendenclaudehatte der Wechsel keinen Einfluss; scheitern konnte nur ein neuer Start, und Craft Anything startetclaudefür jeden Schritt neu (claude -p … --resume).Geändert:
iris-agent-common.sh(iris_agent_common_backend_url,iris_agent_common_start_own_proxy);iris-claude.shundiris-claude-execnutzen sie. Fehlt der Proxy neben der Kopie des Scripts (App-Bundle), bleibt es beim Iris-Proxy.iris-claude-exec: Eine neue Sitzung (kein--resume/--continue) liest Iris und pinnt das Agent-LLM; eine Fortsetzung nimmt den Pin und fragt Iris nicht. Lösen:--iris-unpinoderIRIS_CLAUDE_EXEC_REPIN=1.Geprüft (falsches Iris per HTTPS, falsches Backend, falsches
claude): neue Sitzung liest Iris (/health,/config,ensure-proxy) und pinnt; nach Beenden des falschen Iris nimmt eine Fortsetzung den Pin (0 Iris-Anfragen); eine neue Sitzung ohne Iris meldet den Fehler;iris-claude.shstartetclaudehinter einem eigenen Proxy auf freiem Port, der sich mit demclaudebeendet.Nicht geprüft: echter Lauf in Craft Anything und mit echtem Iris; LM Studio, Ollama, Splash gegen den echten Server; die Bundle-Kopie in der App (ohne
iris-anthropic-proxy).Grenzen: Im Craft-Anything-Projekt setzt jeder Schritt nach dem ersten fort, daher gilt der Pin über mehrere Builds im selben Projektordner hinweg, bis er gelöst wird. Wer das LLM für ein Projekt bewusst wechseln will, löst ihn.
Offen: Praxistest durch Alf (
status/zu-testensteht).PR #354 gemergt: fix(terminal-scripts): Bundle-Kopien von iris-agent-common.sh und iris-claude.sh — eigener Proxy (alf/2ndbrain#175)
http://docker:3000/iris/Iris/pulls/354
Commits:
Befund (Rückfrage Alf, 2026-11-11): Erwartet war: Beim Start einmal nachsehen, welches Agent-LLM Iris hat, dann
claudedamit starten und unabhängig von Iris weiterlaufen lassen. Zwei Abweichungen: (1) Das interaktiveiris-claude.shbenutzte weiter den Proxy im Iris-Prozess und war nicht entkoppelt (nuriris-claude-exechatte den eigenen Proxy). (2) Der Pin aus dem vorigen Stand galt pauschal je Arbeitsverzeichnis und nicht ab dem Start einer Sitzung. Zur Ursache des Fehlerbilds: Auf den laufendenclaudehatte der Wechsel keinen Einfluss; scheitern konnte nur ein neuer Start, und Craft Anything startetclaudefür jeden Schritt neu (claude -p … --resume).Geändert:
iris-agent-common.sh(iris_agent_common_backend_url,iris_agent_common_start_own_proxy);iris-claude.shundiris-claude-execnutzen sie. Fehlt der Proxy neben der Kopie des Scripts (App-Bundle), bleibt es beim Iris-Proxy.iris-claude-exec: Eine neue Sitzung (kein--resume/--continue) liest Iris und pinnt das Agent-LLM; eine Fortsetzung nimmt den Pin und fragt Iris nicht. Lösen:--iris-unpinoderIRIS_CLAUDE_EXEC_REPIN=1.Geprüft (falsches Iris per HTTPS, falsches Backend, falsches
claude): neue Sitzung liest Iris (/health,/config,ensure-proxy) und pinnt; nach Beenden des falschen Iris nimmt eine Fortsetzung den Pin (0 Iris-Anfragen); eine neue Sitzung ohne Iris meldet den Fehler;iris-claude.shstartetclaudehinter einem eigenen Proxy auf freiem Port, der sich mit demclaudebeendet.Nicht geprüft: echter Lauf in Craft Anything und mit echtem Iris; LM Studio, Ollama, Splash gegen den echten Server; die Bundle-Kopie in der App (ohne
iris-anthropic-proxy).Grenzen: Im Craft-Anything-Projekt setzt jeder Schritt nach dem ersten fort, daher gilt der Pin über mehrere Builds im selben Projektordner hinweg, bis er gelöst wird. Wer das LLM für ein Projekt bewusst wechseln will, löst ihn.
Offen: Praxistest durch Alf (
status/zu-testensteht).PR #190 gemergt: fix(tools): Proxy wiederholt bei 'Prompt + max_tokens' mit dem Rest oder meldet 'prompt is too long' (#175)
http://docker:3000/alf/2ndbrain/pulls/190
Commits:
Stand: Kontext voll trotz Auto-Compact (MacBook, Craft-Anything-Sitzung bbda7a64)
Befund (Sitzungsprotokoll
bbda7a64….jsonlund Fehlerlog): Der Pin griff (openaicompat / qwen3.8-flash-next-iq3_s),CLAUDE_CODE_AUTO_COMPACT_WINDOW=220144stand im Prozess. Drei Auto-Komprimierungen liefen bei 193644, 189141 und 202411 Token. Danach wuchs der Kontext in kleinen Schritten von 26858 auf 230111 Token, ohne dass eine vierte Komprimierung kam, bis Strata mit 400 abbrach:prompt (230676) + max tokens (32000) exceeds the context (262144). Warum Claude Code oberhalb von 220k nicht komprimierte, ist nicht geklärt (im Protokoll steht kein fehlgeschlagener Versuch).Geändert:
tools/iris-anthropic-proxyfängt genau diesen 400 ab. Bleibt nach Abzug des Prompts Platz (≥ 2048 Token), wiederholt er die Anfrage einmal mitmax_tokens = Fenster − Prompt − 64. Sonst meldet erprompt is too long: N tokens > M maximumim Anthropic-Format, statt die Backend-Meldung durchzureichen.Geprüft: Gegen ein falsches Backend, Stream und Nicht-Stream: Prompt 230676 → Wiederholung mit 31404, Antwort 200; Prompt 261000 → 400 „prompt is too long: 261000 tokens > 262144 maximum“.
Nicht geprüft: Ob Claude Code auf „prompt is too long“ von selbst komprimiert (nicht im Binary bestätigt). Echter Lauf in Craft Anything. Die Ursache der ausgebliebenen vierten Komprimierung.
Grenzen: Wirkt nur im eigenen Proxy (ollama/lmstudio/openaicompat), nicht bei Splash (direkt) und nicht in der Bundle-Kopie. Der Wert für
fit_max_tokensin der Strata-Konfiguration bleibt Alfs Entscheidung.PR #191 gemergt: feat(tools): iris-claude-exec komprimiert volle Sitzungen vor dem Fortsetzen (#175)
http://docker:3000/alf/2ndbrain/pulls/191
Commits:
Stand: Komprimieren vor dem Fortsetzen (
iris-claude-exec)Befund: Eine Craft-Anything-Sitzung (MacBook) lief trotz
CLAUDE_CODE_AUTO_COMPACT_WINDOW=220144auf 230k Token, ohne dass Claude Code ein viertes Mal komprimierte (Ursache ungeklärt); danach brach Strata mit 400 ab. Ein manuelles/compactauf derselben Sitzung (231265 Token) lief in 155 s sauber durch, die Sitzung ist gerettet.Geändert:
iris-claude-execliest bei jeder Fortsetzung (--resume ID,--resume=ID,-r) die Größe der Sitzung und führt vor dem Fortsetzenclaude -p /compact --resume IDaus, wenn sie über der Schwelle liegt. Schwelle:IRIS_CLAUDE_EXEC_COMPACT_AT(Token, 0 = aus), sonst 65 % vonCLAUDE_CODE_MAX_CONTEXT_TOKENS(bei 262144: 170393). Nur bei lokalen Backends, nicht beianthropic. Neu:tools/iris-session-tokens(liest~/.claude/projects/<Pfad>/<id>.jsonl: letzte Anfrage nach der letzten Komprimierung, danach derenpostTokens; unbekannte Sitzung: 0). Schlägt die Komprimierung fehl, geht die Fortsetzung trotzdem weiter.Geprüft:
iris-session-tokensgegen eine Kopie der echten Sitzung: 230111 vor, 7525 nach einer Marke, 0 bei unbekannter ID. Ablauf mit falschemclaude: Fortsetzung bei 230111 Token komprimiert zuerst; Schwelle 0, Schwelle über dem Stand und unbekannte Sitzung komprimieren nicht;--resume=IDwird erkannt.Nicht geprüft: Ein echter Craft-Anything-Lauf mit dem neuen Weg. Das Verhalten bei
--continueohne ID (dort wird nicht geprüft). Wächst der Kontext innerhalb eines einzelnen Schritts über die Grenze, greift die Prüfung nicht (dort bleibt nur der Proxy-Fix, PR #190).Grenzen: Die Komprimierung kostet 2–3 Minuten vor dem Schritt. Die Bundle-Kopie der App enthält
iris-claude-execnicht, nichts zu spiegeln.PR #192 gemergt: fix(tools): Komprimieren vor dem Fortsetzen nur auf Wunsch, Fehlschlag melden (#175)
http://docker:3000/alf/2ndbrain/pulls/192
Commits:
Stand: Komprimieren vor dem Fortsetzen ist jetzt standardmäßig aus (Korrektur zu PR #191)
Befund: Auf dem Mac Studio (Craft-Projekt „Aseprite“, Sitzung e2832af9) startete die neue Prüfung bei 217705 Token ein
/compact. Die Komprimierung scheiterte („summarization produced empty response“), das Script meldete trotzdem „Komprimierung fertig“, und die Fortsetzung brach mit „No deferred tool marker found in the resumed session“ ab. Das/compacthatte Einträge ans Sitzungsprotokoll angehängt; ob die Sitzung ohne diesen Schritt fortsetzbar gewesen wäre, ist nicht belegt (das Protokoll endete schon vorher mit „API Error: ECONNREFUSED“).Geändert: Die Komprimierung läuft nur noch mit gesetztem
IRIS_CLAUDE_EXEC_COMPACT_AT. Ein Fehlschlag („Error during compaction“) wird als solcher gemeldet statt als „fertig“. Das Sitzungsprotokoll wurde von Hand auf den Stand vor dem/compactgekürzt (Sicherung:~/e2832af9.jsonl.vor-korrektur.bak).Geprüft: Syntax. Nicht geprüft: ob die Sitzung sich jetzt fortsetzen lässt.
Lehre: Die Komprimierung wurde nur an einer Sitzung ohne wartende Rückmeldung getestet und als „fertig“ gemeldet, ohne die Ausgabe auf Fehler zu prüfen.
PR #193 gemergt: fix(tools): Proxy schaltet das Denken für /compact-Zusammenfassungen aus (#175)
http://docker:3000/alf/2ndbrain/pulls/193
Commits:
Stand: Ursache der gescheiterten Komprimierung gefunden (Qwen denkt die Zusammenfassung leer)
Befund: Auf dem MacBook endete der Lauf von 07:39 mit
terminal_reason: prompt_too_long, die Craft-Notiz lautet „automatic compaction failed: summarization produced empty response“. Dieselbe Meldung kam auf dem Mac Studio. Das Strata-Modell (qwen3.8-flash-next-iq3_s) liefert seine Gedanken inreasoning_contentgetrennt vom Text (gemessen). Der Proxy verwirftreasoning_content. Bei der langen Zusammenfassung für/compactbraucht das Modell seinmax_tokensoffenbar im Denken auf,contentbleibt leer, und Claude Code bricht ab. Das erklärt auch, warum die Komprimierung mal geht (Antwort kurz genug) und mal nicht. Nicht bewiesen: dass es in jedem Fall so war (die Zwischenausgabe des fehlgeschlagenen Laufs fehlt).Geändert:
tools/iris-anthropic-proxyerkennt die Zusammenfassungs-Anfrage (Anweisung „Your task is to create a detailed summary“ in der letzten Nachricht) und setzt dafürchat_template_kwargs: {"enable_thinking": false}.Geprüft: Direkt gegen Strata: mit
enable_thinking: falsekommt der Text ohne Denken zurück (reasoning-Länge 0). Proxy gegen falsches Backend: normale Anfrage ohne, Zusammenfassung mitenable_thinking: false.Nicht geprüft: Eine echte lange Komprimierung (200k+) mit dem neuen Weg; ob jedes Backend
chat_template_kwargsbeachtet (Strata: ja, gemessen).Grenzen: Gilt nur für den eigenen Proxy. Die Sitzung bbda7a64 steht bei ~245k und ist durch ihre Größe schwer zu komprimieren; Weg dort: neue Sitzung aus der Übergabe im Projektordner.
PR #194 gemergt: fix(tools): iris-claude-exec ersetzt --model bei lokalen Backends durch das Agent-LLM (#175)
http://docker:3000/alf/2ndbrain/pulls/194
Commits:
Stand:
--model claude-opus-5-5von Craft Anything wird bei lokalen Backends ersetztBefund: Craft Anything startet
claudeimmer mit--model claude-opus-5-5. Der Proxy schickte ohnehin das Agent-LLM (Qwen), aber Claude Code plante mit Opus-Werten: im SitzungsprotokollcontextWindow: 1000000,maxOutputTokens: 128000fürclaude-opus-5-5, die Zusammenfassung lief dagegen alsopenaicompat-localmit 262144. Möglicher Zusammenhang mit der ausbleibenden Auto-Komprimierung: Vermutung, nicht bewiesen.Geändert:
iris-claude-execersetzt bei ollama/lmstudio/openaicompat/splash jedes--model Xund--model=Xdurch den Modellnamen des Agent-LLM ($MODEL, z. B.openaicompat-local), wie esiris-claude.shohnehin tut.Geprüft: Mit falschem
claude:--model X,--model=Xund kein--modelwerden richtig behandelt, Argumente mit Leerzeichen bleiben heil.Nicht geprüft: Echter Lauf; ob Claude Code mit dem unbekannten Namen die Komprimierung zuverlässiger auslöst (ungeklärt). Ein Warnhinweis
unrecognized_modelim Log ist zu erwarten und harmlos.PR #195 gemergt: fix(tools): iris-claude-exec setzt das Agent-LLM immer, auch in Umgebung und Unteragenten (#175)
http://docker:3000/alf/2ndbrain/pulls/195
Commits:
Stand: Es gilt immer das Agent-LLM, nicht der Name von Craft Anything (Korrektur zu PR „ersetzt --model“)
Befund (Dokumentation „Correct the window for a gateway or custom model ID“):
CLAUDE_CODE_MAX_CONTEXT_TOKENSwirkt bei einer Modell-ID, die nicht mitclaude-beginnt, von selbst. Bei einer ID wieclaude-opus-5-5wirkt sie nur zusammen mitDISABLE_COMPACT— Claude Code nimmt dann 1 Mio. Fenster und 128000 Ausgabe an (im Sitzungsprotokoll gemessen:contextWindow: 1000000). Das passt zu der Auto-Komprimierung, die bei den Craft-Läufen ausblieb. Als Kausalkette für die ausgebliebene Komprimierung bleibt es eine begründete Vermutung.Geändert:
iris-claude-execsetzt bei ollama/lmstudio/openaicompat/splash immer das Agent-LLM, unabhängig von dem, was der Aufrufer übergibt:--model/--model=im Argument,ANTHROPIC_MODEL(auch wenn der Aufrufer sie schon gesetzt hat),ANTHROPIC_DEFAULT_{OPUS,SONNET,HAIKU}_MODEL,ANTHROPIC_SMALL_FAST_MODELundCLAUDE_CODE_SUBAGENT_MODEL. Der Name ist der echte Modellname aus Iris (nicht mehr der Aliasopenaicompat-local), er beginnt nicht mitclaude-; damit gilt das mitgegebene Fenster.Geprüft: Mit falschem
claude: Craft-Aufruf mit--model claude-opus-5-5undANTHROPIC_MODEL=claude-opus-5-5in der Umgebung ergibt überall den Namen aus Iris;--model=Xund Fortsetzung ebenfalls; Argumente mit Leerzeichen bleiben heil.Nicht geprüft: Echter Lauf; ob die Komprimierung danach zuverlässig vor dem Fenster auslöst. Ein Modellname, der selbst mit
claude-beginnt (z. B. über Ollama), würde das Fenster weiter ignorieren.