Agentic Ventures Wiki

phase-2-baseline

4 Min. Lesezeit

Phase 2 — Baseline

Ziel: Pro Top-3-Caller wissen woher die Input-Tokens kommen. Trennung: System-Prompt vs Tool-Descriptions vs Kontext (RAG-Chunks, Chat-Verlauf, User-Message).

Aufwand: ~2h

Vorbedingung: Phase 1 fertig (Top-3-Caller bekannt).

Nachbedingung: caller-inventar.md Abschnitt „Baseline-Werte” gefuellt.

Schritte

2.1 Token-Counter-Setup

anthropic.count_tokens() (Anthropic SDK) zaehlt korrekt fuer Claude-Modelle, inkl. neueres Token-Encoding. NICHT tiktoken (das ist OpenAI).

from anthropic import Anthropic
 
client = Anthropic()
result = client.messages.count_tokens(
    model="claude-sonnet-4-6",
    system=system_prompt,
    messages=messages,
    tools=tools,  # Liste der Tool-Definitionen
)
print(result.input_tokens)

API-Key liegt in 1Password (Anthropic API Key) — diese Messung selbst kostet kein Geld (count-tokens-Endpoint ist gratis).

2.2 Pro Top-3-Caller messen

Fuer jeden Top-3-Caller (aus Phase 1) folgendes erheben:

WertWie messen
System-Prompt-TokensCaller-Code lesen, statischen System-Prompt extrahieren, count_tokens
Tool-Descriptions-TokensTool-Liste extrahieren, count_tokens mit nur tools=
Avg Input pro CallAus Phase-1-Log-Snapshot: 10 Sample-Calls, Input-Tokens-Wert aus Bedrock-Response oder via count_tokens auf den ganzen Request
Avg Output pro Callanalog aus Response
Calls pro TagAus CloudTrail-Count / Anzahl Tage im Burst

2.3 MCP-Tool-Description-Audit-Script

Fuer alle Eigenbau-MCPs (_index): ein Script das die Tool-Definitionen aus dem MCP-Server abruft (tools/list-Endpoint) und pro Tool den Token-Count zeigt — sortiert absteigend, damit die Streichliste-Kandidaten oben stehen.

# templates/tool-description-audit.py (wird in Phase 3 ins Skill-Repo gelegt)
# Pseudocode:
# 1. MCP-Server via stdio oder HTTP ansprechen
# 2. tools/list -> Liste mit name + description + inputSchema
# 3. Pro Tool: count_tokens(tools=[tool])
# 4. Output: tool_name, total_tokens, description_tokens, schema_tokens

Hier in Phase 2 manuell anwenden auf mcp-papierkram (~70 Tools), mcp-whatsapp, mcp-m365, mcp-calcom. Voll-Script kommt in Phase 3 ins Skill-Repo.

2.4 Open-WebUI-Specifics

Wenn Open-WebUI ein Top-3-Caller ist:

  • LiteLLM-Sidecar-Config angucken: wird ein Custom-System-Prompt injected?
  • Open-WebUI Modelfile-Settings checken: System-Prompt pro Model, RAG-Settings (Top-K, Chunk-Size, Re-Ranking on/off, Embedding-Modell)
  • Chat-Verlauf-Truncation: wieviele Messages werden zurueckgegeben? Bei auto: kann ueber 50k Tokens gehen bei langen Sessions
# In ECS-Container:
aws ecs execute-command \
  --cluster av-production \
  --task <task-id> \
  --container open-webui \
  --interactive --command "/bin/sh" \
  --profile av-production
# dann env-Vars + config-File checken

2.5 Werte in caller-inventar.md eintragen

Tabelle „Baseline-Werte” fuellen pro Caller. Wenn der System-Prompt > 3000 Tokens oder Tool-Descriptions > 5000 Tokens: das ist ein roter Flag, kommt in Phase 5 als Hebel-4-Kandidat oben rein.

Definition of Done

  • count_tokens() lokal lauffaehig
  • Top-3-Caller jeweils gemessen
  • Tool-Description-Counts pro Eigenbau-MCP
  • Open-WebUI System-Prompt + RAG-Settings dokumentiert (wenn Top-3)
  • caller-inventar.md „Baseline-Werte”-Tabelle gefuellt

Output dieser Phase

Konkrete Antwort auf: „woraus bestehen die Input-Tokens?” Pro Caller: x% System-Prompt, y% Tools, z% Kontext. Damit ist klar welcher Hebel in Phase 5 wieviel bringt.

Findings (durchgefuehrt 2026-05-17)

Phase 2 ist abgeschlossen. Statt anthropic.count_tokens() ueber die Anthropic API (haette zusaetzliche Auth + API-Call gebraucht) habe ich Source-Code-Reads gemacht + char-basierte Token-Schaetzung (chars / 3.5 fuer deutsche Sprache). Reicht fuer Pareto-Sicht.

Volle Caller-Karte — wer was ruft

CallerBedrock-ModellQuelle
open-webui-vfSonnet 4.6LiteLLM-Config inline in ECS-Command (exec litellm --config /tmp/litellm-config.yaml), bedrock/eu.anthropic.claude-sonnet-4-6
inference-service-prod (a-icking)Haiku 4.5bedrock_claude.py Z.24 CLAUDE_HAIKU_4_5_EU hartcodiert
receptionist-brain LambdaHaiku 4.5env-var BEDROCK_MODEL_ID
agent-beleg-pipeline LambdaHaiku 4.5env-var BEDROCK_MODEL_ID
agent-daily-briefing LambdaHaiku 4.5env-var BEDROCK_MODEL_ID
agent-tool-error-digest Lambda(kein Bedrock-Call dokumentiert)env hat nur LOG_GROUPS/Digest-Vars
mcp-whatsappkein Brainserver.py Docstring: “Brain (Claude Code Session oder spaeter Lambda) ruft Tools” — der MCP selbst ruft Bedrock nicht
mcp-vf-hosted, mcp-calcomProxy/Wrapperkeine Bedrock-Aufrufe in den Containern

Korrektur zur Phase-1-Hypothese

Phase 1 hatte a-icking + receptionist-brain als Top-3 Sonnet-Caller. Falsch. Beide sind Haiku-Caller. Open-WebUI ist der quasi alleinige Sonnet-Caller. caller-inventar.md ist entsprechend korrigiert.

Drei explizite Cost-Treiber in Open-WebUI

  1. TASK_MODEL=claude-sonnet-4-6 — Background-Calls (Title, Tag, Search-Query-Gen, Follow-up) laufen auf Sonnet statt billigerem Modell
  2. DEFAULT_MODEL_PARAMS thinking.budget_tokens=4096 — Extended Thinking AN
  3. 1M-Context-Beta wurde am 12./13.05. mit 94% Anteil benutzt → 2x Input-Kosten ueber 200k Tokens. Ein Test-Lauf, kein Daily-Pattern, aber teuer

Caching-Status

LiteLLM-Config aktiviert Caching deklarativ (cache_control_injection_points). CloudWatch zeigt CacheWrite + CacheRead = 0. Heisst Caching wirkt nicht. Parallel-Session-Aufgabe.

Was offen blieb

  • Open-WebUI-Modelfile (System-Prompt) liegt in EFS-Volume fs-0d5cbc5aa10b080e5 — nicht ueber API ausgelesen. Phase 5 muss via ECS-Exec rein.
  • Open-WebUI-Tools-Registrierung — auch in EFS-DB. Token-Footprint pro registriertem Tool aktuell unbekannt.
  • agent-tool-error-digest Code (~/source/agents-platform/lambdas/tool-error-digest/) nicht gelesen — vermutlich kein Bedrock-Caller, aber nicht verifiziert.

Definition of Done

  • Bedrock-Modell pro Caller bestaetigt (via env-vars + Source-Code-Reads)
  • System-Prompts pro Lambda-Caller dimensioniert (~1.2k Tokens fuer hairdresser, ~700 fuer a-icking-base)
  • Tool-Description-Audit-Script ist nicht gelaufen — bei dem Caller-Bild (nur Open-WebUI ist relevant) nicht im kritischen Pfad. Wandert nach Phase 5 als Audit fuer die Lambda-Tools (mcp-vf-hosted-Tools die beleg-pipeline rezieht etc.)
  • Open-WebUI Settings (env vars + LiteLLM-Config + Modell-Liste) dokumentiert
  • Caching-Status verifiziert: deklariert aber wirkt nicht
  • 1M-Context-Beta-Nutzung quantifiziert
  • caller-inventar.md mit Token-Schaetzungen + Befunden gefuellt

Phase 2 done. Phase 3 (Gate + Skill-Scaffold) ist als naechstes dran.

Graphansicht

Backlinks