AI Picks der 22. KW

Diese Woche war viel Lärm um Dinge, die ich wenig spannend fand. Beispielsweise einen reichlich hässlichen Ferrari Luce, den LoveFrom – das Designkollektiv von Sir Jony Ive und Marc Newson – zusammen mit Ferraris Centro Stile gezeichnet hat. Kalte Hardware mit fragwürdiger Linienführung. Fand der Markt übrigens auch und schickte die Ferrari-Aktie nach der Vorstellung in den Keller. Aber in der AI-Welt: irgendwie nichts, was die Branche so richtig getriggert hätte.

Also habe ich mich diese Woche persönlich tiefer ins Thema Scraping und Crawling und die entsprechenden Tools, Engines und Frameworks begeben. Hauptsächlich mit der Motivation, möglichst token-effizient Markdown oder JSON aus den Quellen als Content rauszuziehen. Dazu wird es zu gegebenem Anlass einen eigenen Artikel geben.

Bevor wir loslegen: Picks sind thematisch sortiert – lokale Hardware und kleine Modelle hängen zusammen, danach Markt, Tools, und am Ende ein Blick nach China.

High-VRAM GPUs aren't the future of local AI

Steile These von Adam Conway bei XDA Developers, aber ich stimme ihm da glatt zu. Der KI-Boom dürfte sich noch ein Weilchen halten, und die Big Player shoppen den Markt gerade leer – was an Speicher und GPUs (und absehbar auch CPUs) zu haben ist, wandert in Datacenter. Unified Memory und MoE werden den Markt für local AI technisch vorantreiben, vorausgesetzt, Big Tech kauft nicht auch noch alles weg. Consumer-CPUs werden die vermutlich nicht so weit oben auf dem Einkaufszettel haben.

Conways Zahlen sind übrigens hübsch konkret. Der Apple M3 Ultra Mac Studio kommt auf 512 GB Unified Memory bei rund 800 GB/s. Nvidias GB10 in der DGX Spark und der Lenovo ThinkStation PGX liefert 128 GB bei 273 GB/s, und AMDs Strix Halo im Framework Desktop landet bei 128 GB / ~256 GB/s. Klingt mager gegen eine RTX 5090 mit ihren über 1.000 GB/s, ist es bei der reinen Decode-Geschwindigkeit auch. Was Unified Memory dafür bietet, ist Kapazität – und damit Modelle, die auf einer 32-GB-Karte schlicht nicht laden.

MoE schließt den Kreis. DeepSeek-V4-Pro ist 1,6T total, aber nur 49B davon sind pro Token aktiv – das sind etwa drei Prozent. Qwen3-Coder-Next hat 80B mit 3B active und kommt auf der ThinkStation PGX laut Conway auf 40 bis 60 Token/s. Selbst bei NVIDIA stellt man allerdings gerade fest, dass mit Blackwell-Architektur mehr Geld zu verdienen ist als mit RTX-Consumer-Karten. Also tun sie das, was jedes gewinnorientierte Unternehmen tun würde.

Surya OCR 2

Schöne Bestätigung der These aus dem XDA-Artikel: Surya-ocr-2 ist ein 650M-Parameter-OCR-Modell von Datalab mit einem Durchsatz von 5,35 Seiten pro Sekunde auf einer RTX 5090 (gemessen mit vllm bei 128er Concurrency). Architektur ist ein Qwen3.5-style VLM, das Layout, OCR und Table Recognition in einem einzigen Aufruf erledigt.

Die Genauigkeit liegt laut olmOCR-Bench bei 83,3 % – damit ist Surya der beste Vertreter unter 3B Parametern. Im internen 91-Sprachen-Benchmark schafft das Modell 87,2 % im Schnitt, Deutsch liegt bei 89,7 %. Das ist anständig, vor allem wenn man bedenkt, dass wir hier von 650 Millionen Parametern reden, nicht von Milliarden.

Klar, das Ding ist spezialisiert auf genau eine Aufgabe. Aber das ist eigentlich genau das, was ich seit gut einem Jahr predige: Wir werden immer mehr spezialisierte Modelle und MoE-Varianten sehen, und die Dinger werden zunehmend auf lokaler Hardware laufen können. Wer OCR in Pipelines braucht, sollte Surya einen Blick gönnen. Vor allem bei mehrsprachigem Input.

Ein Hersteller-Sternchen muss aber sein: Die Code-Lizenz ist Apache 2.0, die Model-Weights laufen unter einer modifizierten AI-Pubs-Open-Rail-M-Lizenz. Kostenlos für Research, Personal Use und Startups unter 5 Mio. USD Umsatz. Für alles darüber muss man bei Datalab anklopfen.

LiteParse v2.0

Passt perfekt in mein Scraping-Rabbit-Hole dieser Woche: LiteParse v2.0 von LlamaIndex, erschienen am 27. Mai. PDF ist eines der bescheuertsten Formate, die Du in eine Pipeline kippen kannst. Du weißt nie, was kommt: Mal sind es 80 Seiten stinknormaler Text, mal der reinste „ich scanne das mal eben mit 70 DPI in Altkoreanisch, wird schon passen“-Albtraum.

LiteParse zieht strukturierten Text aus PDFs und Office-Dokumenten, und zwar ohne LLM – der Text wird anhand des Layouts projiziert, statt von einem Modell interpretiert zu werden. Das ist der Gegenentwurf zu VLM-OCR à la Surya: kein Modell, kein GPU-Hunger, deterministisch. Für v2.0 hat das Team alles in Rust neu geschrieben. Vorher lief das Ding nur als Node/TypeScript-Paket, jetzt gibt es native Bindings für Rust, Python, Node und WASM – also auch im Browser und auf Edge-Runtimes. Unter der Haube stecken ein eigener PDFium-Fork und tesseract-rs als Default-OCR.

Jetzt das Hersteller-Sternchen, weil muss leider sein: „Up to 100x“ steht groß über dem Post, und das stimmt – aber nur für kleine Dokumente, bei denen vorher das Hochfahren des Node-Prozesses die ganze Zeit fraß. Bei großen Dokumenten bleibt es bei etwa 3x. Die Hausnummer, mit der sie werben, sind 0,777 Sekunden für ein 457-seitiges, 100 MB schweres PDF – herstellereigene Messung, kein unabhängiger Drittwert. Schnell ist das trotzdem.

Hübsches Detail für Coding-Agenten: Man kann LiteParse direkt als Skill einbinden (npx skills add run-llama/llamaparse-agent-skills --skill liteparse), Claude Code, Codex und OpenCode verstehen das. Der Code liegt offen auf GitHub.

Selbst getestet habe ich es noch nicht, das steht aber ganz weit oben auf der Liste. Bis dahin behaupte ich mal frech, dass das eine dieser Perlen ist, die man eigentlich (fast) nur auf GitHub findet.

DeepSWE

Eine neue Woche, ein neuer Real-World-Benchmark. Datacurve hat sich mit DeepSWE tatsächlich Mühe gegeben: 113 Tasks aus 91 aktiv gepflegten Open-Source-Repositories über fünf Sprachen (TypeScript, Go, Python, JavaScript, Rust). Die Tasks sind von Grund auf neu geschrieben und werden nicht in die Upstream-Repos zurückgeführt – das soll Kontamination im Trainingscorpus verhindern. Verifier laufen behavioral statt strukturell, also: Wenn das beobachtbare Verhalten stimmt, ist die Implementierung egal. Code und Daten liegen auf GitHub.

Methodisch ist das eine deutlich saubere Sache als bei SWE-Bench Pro, wo der eigene Audit der Datacurve-Leute 8,5 % False Positives und 24 % False Negatives gefunden hat. Bei DeepSWE liegen die Werte bei 0,3 % und 1,1 %. Das ist eine andere Liga.

Das Leaderboard sieht aktuell so aus: gpt-5.5 70 %, gpt-5.4 56 %, claude-opus-4.7 54 %, claude-sonnet-4.6 32 %. Und – kleine Pikanterie – deepseek-v4-pro landet bei 8 %. Wer beim nächsten Pick gleich noch lesen wird, was Preis bedeutet, kann sich das schon mal mitdenken.

Ich bin bei solchen Benchmarks ja grundsätzlich skeptisch. Das liest sich erstmal alles ganz toll und wird auch für die nächsten paar Monate funktionieren. Aber: Es steht immer der Verdacht im Raum, dass die Anbieter ihre Modelle dahingehend trimmen, möglichst gut in Benchmarks abzuschneiden. Das macht sich auf Modell-Cards ja gut, ist ein Verkaufsargument, aber scheinbare Benchmark-Resistenz ist nicht dasselbe wie tatsächliche. Wer dazu mehr lesen will: Ich habe das im Artikel Wenn Benchmarks lügen – warum der LLM-Vergleich kaputt ist ausführlicher behandelt.

Eine kleine Beobachtung am Rande und eine nette Anekdote: Claude Opus 4.6 und 4.7 haben auf SWE-Bench Pro in 12 bis 18 % der Pässe einfach git log --all ausgeführt und sich die Lösung aus der Commit-History gezogen. GPT macht das nie. Gemini fast nie. Aufmerksam, dieses Claude. Kritisch betrachtet könnte man das klassisch „Beschiss“ nennen. Freundlich formuliert als „kreative Lösung“ verbuchen.

DeepSeek-V4-Pro Discount ist jetzt permanent

„Aber Tobias, warum verlinkst Du denn immer so viel zu X.com?“ Nun ja, die ganzen KI-Buden hauen da irgendwie ihre relevanten News raus, kann ich leider nicht ändern. Diesmal verlinke ich aber auch auf die offiziellen DeepSeek API Docs, was zumindest gegen unsichere Tweet-IDs gefeit ist.

Was passiert ist: Der 75-%-Rabatt auf DeepSeek-V4-Pro, ursprünglich befristet bis 31. Mai 15:59 UTC, wird permanent. Aus der Promo wird der Listenpreis. Konkret: 0,435 USD pro Million Input-Token, 0,87 USD pro Million Output, 0,003625 USD pro Million Cache-Hit. Zum Vergleich: Claude Opus 4.8 kostet auf den Output rund 86-mal so viel, GPT-5.5 etwa 34,5-mal. Bei V4-Flash ist es noch krasser, aber der Tarif war eh schon spottbillig.

DeepSeek geht preislich in den Infight. Alle sagen jetzt: „Oh man, die wollen Anthropic Marktanteile wegnehmen.“ Ich gehe einen Schritt weiter. Die wollen ALLEN Marktanteile wegnehmen, einschließlich ihrer eigenen, inländischen Wettbewerber. Und ich gebe dem noch vier Wochen, dann kommt Moonshot AI um die Ecke mit einem Kimi-2.65-Coding-Model und eigenen API-Kampfpreisen.

Anthropic adds 28 security and compliance integrations for Claude

Generell ist das eine gute Nachricht. Anthropic hat seine Compliance API aufgemacht, und 28 Provider klinken sich ein – Cloudflare, CrowdStrike, Datadog, IBM Guardium, Microsoft Purview, Netskope, Okta, Palo Alto, Wiz, Zscaler und einige mehr aus den Bereichen DLP, SASE, SIEM, IAM und AI-SPM. Über die API kommen Enterprise-Teams an zwei Datenkategorien: Conversation Content (Chats, Files, Projects) für DLP-Policies und Activity Events (Logins, Admin-Actions, Config Changes) für Auditing.

Bringt uns Europäern eher weniger, da wir mit Cloud Act und dem EU-US Data Privacy Framework (DPF, seit Juli 2023, Nachfolger des 2020 gekippten Privacy Shield, der wiederum den 2015 gekippten Safe Harbor abgelöst hat – langweilige Compliance-Historie kurz nachgeschoben) sowieso andere Voraussetzungen haben. Anthropic kann man das nicht ankreiden, sie bedienen halt ihren Heimatmarkt.

Codex Appshots

Sorry, ich bin manchmal sehr Mac-lastig, ist eben meine Heimatplattform 😉

OpenAI hat am 21. Mai mit Appshots ein erstmal-Mac-only-Feature für die Codex-App nachgeschoben (nicht das CLI). Verfügbar ist es ab sofort für ChatGPT Plus, Pro, Business und Edu – Enterprise muss sich noch gedulden.

Das Prinzip: Doppeltes Drücken der Command-Taste schickt das vorderste App-Fenster als Screenshot plus den verfügbaren Text an einen Codex-Thread. Inklusive Text außerhalb des sichtbaren Scrollbereichs, was deutlich nützlicher ist als ein reiner Screenshot. Anwendungsfälle laut OpenAI: API-Doku spiegeln und Codex daraus ein Skript bauen lassen, Mail oder Kalender teilen, einen Fehler zeigen statt beschreiben.

Architektonisch ist das eine reine Codex-Local-Geschichte, sitzt auf macOS-Accessibility und Frontmost-Window-Detection. Eine Cloud-Variante gibt es nicht, und auf Windows kommt das Feature ohnehin nicht. Wer dort sitzt, muss weiter mit Drag-and-Drop-Screenshots arbeiten oder per CLI-Flag Bilder anhängen. Kann man machen.

Zero Trust for AI agents

Lustigerweise kam mir der Gedanke vor ein paar Tagen auch: Zero Trust ist im AI-Kontext das nächste große Thema. Gerade dort, wo Du sonst keine KI dranlassen würdest. Aus Gründen.

Anthropic hat dazu am 27. Mai ein Framework als eBook rausgegeben. Drei Tiers (Foundation, Advanced, Optimized), ein Acht-Phasen-Implementierungs-Workflow von Identity über Access Scoping, Sandboxing, Input/Output Controls bis zu Memory Safeguards, plus Compliance-Mapping für Healthcare, Finance und Government. Adressiert werden die typischen Agent-Threats: Prompt Injection, Tool Poisoning, Identity- und Privilege-Abuse, Memory Poisoning, Supply-Chain-Attacken.

Bemerkenswert ist die Begründung im Intro. Anthropic schreibt, Frontier-Modelle komprimieren die Timeline zwischen Vulnerability und Exploit von Monaten auf Stunden. Verteidiger finden Bugs schneller, Angreifer aber auch – oder warten einfach auf die Patches der Verteidiger und reverse-engineeren sie wieder zu Exploits. Wer also ernsthaft Agenten in Produktion fährt, sollte sich das Dokument anschauen. Zero Trust selbst ist seit 2010 etabliert, die Übertragung auf agentische Systeme ist neu – und überfällig.

Chrome DevTools for coding agents

Auf den ersten Blick nur halbwegs spektakulär, auf den zweiten Blick eine enorme Arbeitserleichterung. Chrome DevTools MCP steht aktuell bei v1.0.1, 41,8k Stars, und der MCP-Server hängt sich an eine laufende Chrome-Instanz und stellt Coding Agents praktisch das ganze DevTools-Inventar zur Verfügung. Performance-Tracing, Network-Requests, Console-Messages mit Source-Mapped Stack Traces, Lighthouse-Audits, Heap Snapshots, Screenshots, Form-Automation – fast 45 Tools über zehn Kategorien.

Unterstützt werden so ziemlich alle relevanten Clients: Claude Code, Codex, Cursor, Copilot, Gemini CLI, JetBrains, Warp, Windsurf, OpenCode, Mistral Vibe – wer auch immer fehlt, wird sich noch melden. Installation ist im Wesentlichen ein npx chrome-devtools-mcp@latest-Eintrag in der jeweiligen MCP-Config.

Und Euer Claude Code oder Codex kann sich sein Debugging künftig selbst abholen. Was bei nicht-trivialen Frontend-Bugs eine echte Zeitersparnis ist. Kleine Warnung aus den Docs: Wenn der Agent im Browser läuft, sieht er alles, was im Browser läuft. Also keine sensiblen Tabs nebenher offen lassen.

Introducing dynamic workflows in Claude Code

Frisch von Anthropic vom 28. Mai: Dynamic Workflows in Claude Code. Die Idee dahinter ist simpel und gleichzeitig groß. Bei Aufgaben, die für einen einzelnen Agenten zu fett sind – ein Bug-Hunt quer durch einen ganzen Service, eine Migration über hunderte Dateien, ein Plan, den Du vor dem Commit aus allen Richtungen zerlegt sehen willst – schreibt Claude Code dynamisch ein Orchestrierungs-Skript und feuert zehn bis hunderte Subagenten parallel los. Die Ergebnisse werden gegengeprüft, bevor sie bei Dir landen. Agenten greifen das Problem aus verschiedenen Winkeln an, andere Agenten versuchen, deren Ergebnisse zu widerlegen, und der Lauf iteriert, bis die Antworten konvergieren.

Verfügbar ist das Ganze als Research Preview – in CLI, Desktop und der VS-Code-Extension, für Max, Team und (wenn der Admin will) Enterprise, dazu über API, Bedrock, Vertex AI und Microsoft Foundry. Bei Max, Team und API ist es per Default an, bei Enterprise zum Start aus. Du startest es auf zwei Wegen – Claude direkt bitten, einen Workflow zu bauen, oder den neuen Schalter ultracode umlegen, der das Effort-Level auf xhigh schraubt und Claude selbst entscheiden lässt, wann ein Workflow sinnvoll ist.

Ein Hersteller-Sternchen liefert Anthropic diesmal gleich selbst mit: Das Ding frisst spürbar mehr Tokens als eine normale Claude-Code-Session. Beim ersten Auslösen zeigt Claude Code, was gleich passiert, und fragt nach. Ehrliche Ansage.

Was damit gehen soll, zeigt der Rewrite von Bun. Jarred Sumner hat die Runtime von Zig nach Rust portiert – rund 750.000 Zeilen Rust, 99,8 % der bestehenden Test-Suite grün, elf Tage vom ersten Commit bis zum Merge. In Produktion läuft das laut Anthropic noch nicht, aber als Demo ist es eine Hausnummer.

Selbst ausprobiert habe ich es noch nicht – Research Preview, Token-hungrig, und ehrlicherweise hatte ich diese Woche anderes auf dem Tisch. Es reiht sich aber sauber in den Claude-Code-Schub der letzten Wochen ein, zu dem auch Opus 4.8 gehört, das vor allem ehrlicher sein will.

Andrej Karpathy's CLAUDE.md File

Das hier wird gerade durch die Community gereicht wie eine Tüte mit dem besten Gras: Andrej Karpathys CLAUDE.md. Bevor die Euphorie überkocht, ein paar Einordnungs-Dämpfer.

Der wichtigste zuerst – das File ist nicht von Karpathy geschrieben. Es ist eine Community-Arbeit, die seine X-Beobachtungen vom Januar 2026 zu den typischen Fehlern von Coding-Agenten in vier Regeln übersetzt. Karpathy selbst hatte damals nur beschrieben, wie sein Workflow innerhalb weniger Wochen von 80 % Handarbeit auf 80 % Agenten-Coding gekippt war – und wo die Modelle dabei reihenweise Mist bauen.

Die vier Regeln sind, das muss man fairerweise sagen, vernünftig. Think Before Coding meint nichts anderes als Annahmen offenlegen und bei Unklarheit fragen statt stillschweigend raten. Simplicity First verbietet spekulativen Code und Abstraktionen, nach denen keiner gefragt hat. Surgical Changes erlaubt nur das, was die Aufgabe wirklich verlangt, und untersagt das ungefragte Refactoring am Nachbarcode. Goal-Driven Execution dreht imperative Anweisungen in überprüfbare Erfolgskriterien, die der Agent dann in einer Schleife abarbeitet. 65 Zeilen, 2,3 KB, kein Hexenwerk.

Womit wir beim Hype wären. Die Stern-Zahlen fliegen von rund 57.000 beim verlinkten Repo bis zu sechsstelligen Werten in den Schlagzeilen – „157K GitHub Stars“ prangt da dann über manchem Artikel. Viral ist das Ding, gar keine Frage. Ob der Inhalt diese Zahlen rechtfertigt, ist eine andere Geschichte.

Und der Medium-Artikel, der dabei am häufigsten mitgereicht wird, gibt auch nur so semi-gute Tipps. Kleines Detail am Rande, das eigentlich alles sagt: Er schreibt Karpathy konsequent „Andrei“ statt Andrej. Sorgfältiger Journalismus – so gut!

Mein Fazit: brauchbarer Startpunkt, kein Heiligtum. Klau die Struktur, nicht die Datei – die vier Kategorien ins eigene CLAUDE.md, dann mit konkreten Pfaden, Test-Gates und Projektregeln füllen, alles andere raus. Was in Claude Code sonst noch tatsächlich an Tokens spart, habe ich an anderer Stelle durchgespielt.

Vibe ist da, Le Chat ist weg (sort of)

Mistral hat heute (28. Mai) richtig aufgeräumt. Le Chat heißt nicht mehr Le Chat, sondern Vibe, und das ist mehr als nur Rebranding. Es gibt jetzt drei Modi: Chat Mode für klassische Konversation, Work Mode als Multi-Tool-Agent (Google Workspace, Outlook, SharePoint, Slack, GitHub, plus Custom Connectoren) und Code Mode mit Remote-Coding-Agents, die in isolierten Sandboxes laufen, parallel starten und auch arbeiten, wenn der Rechner aus ist.

Dazu kommt eine offizielle VS-Code-Extension (Marktplatz: mistralai.mistral-vibe-code), die auf derselben Harness wie das CLI läuft. Preise: Free, Pro $14,99/Monat, Team $24,99/User/Monat, Enterprise auf Anfrage. Wer auf Le Chat war, behält Plan, History und Settings.

Erwähnenswert ist auch, dass im Free-Tier kein Modell-Picker mehr existiert – man wählt einfach den Modus. Das ist die Richtung, in die ohnehin der ganze Markt rutscht. Modellvielfalt im Chat ist für Endnutzer eine Belastung, kein Feature. Unter der Haube läuft Mistral Medium 3.5 (128B dense, 256k Context, 77,6 % auf SWE-Bench Verified).

Chinas eiserner Vorhang für KI-Experten

Wichtige KI-Fachkräfte privater Unternehmen wie Alibaba und DeepSeek brauchen für Auslandsreisen jetzt eine staatliche Genehmigung – bisher galt das primär für staatsnahe Forschungseinrichtungen. Bloomberg hat die Story als erstes gehabt, all-ai.de zitiert sie und packt einen Sowjetunion-Vergleich obendrauf, was historisch nicht ganz unpassend ist.

Ich lasse das mal weitestgehend unkommentiert. Aber China ist wie erwähnt nicht das erste Land, das so eine Nummer fährt, und ich wage eine ganz steile These: Sie werden auch nicht das letzte sein. Talent-Drain ist die hässliche Kehrseite jeder Tech-Industrie, und der Reflex, ihn mit Reisebeschränkungen zu lösen, ist älter als die KI-Branche.

Na, da willst Du doch einen richtig geilen Job als Informatik- oder Mathe-Tech bei Alibaba oder DeepSeek haben – nicht.

Damit ist auch diese Woche wieder over and out. Zeitbedingt kommen die Picks der 23. Kalenderwoche ggf. einen Tag später als gewohnt. Asche über mein Haupt.