"Find the following vulnerabilities in this codebase:
1. Possible SQL Injection points
2. XSS-prone rendering
3. Authentication bypass paths
4. Sensitive data being logged
5. Path Traversal For each finding: file:line, severity (H/M/L), suggested fix"

- **Prompt-Caching**: Verwende den Cache von Anthropic. Das erneute Einlesen derselben 1M Tokens kann einen Rabatt von 90% erhalten
- **Selektive Aufnahme**: Nimm nur die Dateien auf, die für die Analyse relevant sind (Tests, Vendor-Code und minifizierte Bundles ausschließen)
- **Sonnet zuerst**: Sonnet 4.6 reicht für einfache Aggregation und Zusammenfassung aus - Opus sollte komplexem Reasoning vorbehalten bleiben ## Einschränkungen 1. **Lost in the middle**: Selbst mit 1M-Kontext kann die Genauigkeit bei Inhalten sinken, die in der Mitte platziert sind. Stelle kritische Informationen an den Anfang oder das Ende
2. **Code-Token-Effizienz**: Durch Entfernen von Kommentaren und Kürzen von Whitespace passen bis zu 30% mehr Code hinein
3. **Single-Prompt-Grenzen**: Bitte bei umfangreichen Analysen im Suspense-Stil um Teilantworten ## 💡 Praxiserkenntnis Die meisten Artikel bleiben bei der allgemeinen Behauptung stehen, dass "1M-Kontext = automatisch besser" sei. Die eigentliche Hürde, auf die koreanische Entwickler stoßen, ist jedoch **Kostenstruktur und Cache-Trefferquote**. Nachdem ich das sechs Monate lang in einem internen Monorepo mit rund 500.000 Zeilen (Spring + React) eingesetzt hatte, stellte ich fest, dass die monatliche Rechnung ohne aggressives Prompt Caching 300-500 US-Dollar erreichte. Erst nachdem ich `cache_control`-Blöcke an der Codebase-Grenze segmentierte und wiederholte Fragen innerhalb der 5-Minuten-TTL stellte, pendelten sich die Kosten bei etwa 40-60 US-Dollar pro Monat ein. Ein weiterer Punkt, der in koreanischen Entwickler-Communities (OKKY, Disquiet) oft übersehen wird: **die Wiederverwendung deiner `.gitignore`-Muster zum Ausschließen von vendor/dist/lockfile** reduziert Tokens im Durchschnitt um etwa 35% (laut GitHub Octoverse 2025 besteht ungefähr ein Drittel der Größe eines durchschnittlichen Repos aus Lockfiles und Build-Artefakten). Die größten praktischen Zeitersparnisse entstehen schließlich nicht durch eine "vollständige Analyse", sondern durch **per-PR-Diff-Analyse** (nur Base-Branch + Diff laden, etwa 50K-150K Tokens). Das ist der realistischste Weg, Code-Review zu automatisieren, ohne eine RAG-Infrastruktur aufzubauen. ## Fazit 1M-Kontext eröffnet viele Fälle, in denen man "kein RAG braucht". Du kannst sofort ohne Chunking- oder Embedding-Infrastruktur starten, was die MVP-Geschwindigkeit erhöht. Wenn du die Kostenseite sorgfältig steuerst, kann das für Einzelpersonen und kleine Teams, die mit großen Codebasen arbeiten, ein echter Wendepunkt sein. ## Sammlung praktischer Prompt-Vorlagen **Prompt zur Analyse der Legacy-Code-Architektur**

|---------|---------|---------|----------------|
| Vollständige Analyse von 50K Codezeilen | 800K | 5K | ~$12.4 |
| Mit Prompt Cache | 800K (90% cached) | 5K | ~$1.6 |
| 10 Folgefragen | 800K × 10 (cached) | 50K | ~$13.5 | Mit Prompt Caching können wiederholte Arbeiten die Kosten um 80-90% senken. ## Grenzen des 1M-Kontexts und wie man sie umgeht **Grenze 1: Lost-in-the-middle-Effekt**
Informationen, die in der Mitte des Kontexts platziert sind, werden mit geringerer Wahrscheinlichkeit korrekt verarbeitet. Stelle wichtigen Code oder wichtige Erklärungen an den Anfang oder das Ende des Prompts. **Grenze 2: Langsame Langform-Generierung**
Nach einer Eingabe mit 1M Tokens kann die Generierung 30-60 Sekunden dauern. Die Streaming-API liefert das erste Token schnell aus und verbessert die UX. **Grenze 3: Geringere Codegenauigkeit im großen Maßstab**
Sobald du über 50K Codezeilen hinausgehst, steigt die Fehlerrate, wenn das Modell präzise auf eine bestimmte Funktion verweisen muss. Zitiere kritische Funktionen im Prompt ausdrücklich erneut. **Workaround: Tree-sitter-Preprocessing**
Wenn du mit einem Code-Parser (tree-sitter) zuerst den AST extrahierst und nur komprimierte Strukturinformationen übergibst, verbessert sich die Token-Effizienz um 40-60%. ## Häufig gestellte Fragen **F. Kann ich den 1M-Kontext direkt aus der Claude Code CLI verwenden?**
A. Ja. Wenn du Opus mit `claude --model claude-opus-4-7` angibst, wird der 1M-Kontext automatisch aktiviert. Das ist nützlich für die Analyse großer Codebasen. **F. Kann ich Bilder in 1M Tokens einbeziehen?**
A. Ja. Ein einzelnes Bild verbraucht ungefähr 1.000-2.000 Tokens. Das Anhängen von Diagrammen oder Screenshots kann deinen Codekontext ergänzen.