KI für Einsteiger: Erste Schritte mit AI-Tools

Sie wollen Claude Desktop unter Windows öffnen, und stattdessen erscheint ein Dialog mit der Überschrift „Diese App kann nicht geöffnet werden“, der Sie auffordert, in die erweiterten Optionen von Claude zu gehen und dort Reparieren auszuwählen — und genau das zu tun, funktioniert. Kein Deinstallieren, und kein Zurücksetzen, das Ihre Daten wegwirft. Es gibt allerdings einen Schritt dazwischen, an dem die Leute wirklich hängen bleiben, und der steht im Mittelpunkt dieses Artikels. Ein Klick auf Reparieren kann mit der Meldung zurückkommen, die App laufe noch, obwohl nirgendwo ein Claude-Fenster offen ist. Die Ursache: Claude Desktop läuft nach dem Schließen des Fensters im Infobereich der Taskleiste weiter, und solange dieser Hintergrundprozess die Paketdateien offen hält, kann die Reparatur nicht durchlaufen. Die Lösung ist einfach: die Prozesse ausdrücklich beenden und dann auf Reparieren klicken. Und genau diese Tatsache weist auf die Ursache des Fehlers selbst hin — derselbe Prozess hat das Update kaputt gemacht und anschließend die Reparatur blockiert. Der Artikel beantwortet außerdem die Frage, die fast alle zuerst stellen: Gehen die Sitzungen verloren? Die Antwort teilt sich in drei. Der Unterhaltungsverlauf von claude.ai liegt auf den Servern von Anthropic und bleibt unangetastet. Claude-Code-Sitzungen liegen unter %USERPROFILE%\.claude\projects\, also außerhalb des App-Pakets, und überstehen deshalb eine Reparatur, ein Zurücksetzen und sogar eine Deinstallation (auf einem echten Rechner waren es 2.977 Dateien mit rund 3,0 GB in 52 Projekten). Gefährdet sind allein die App-eigenen Einstellungen in %APPDATA%\Claude, und selbst die behält Reparieren — Windows schreibt den Unterschied direkt auf den Bildschirm: neben Reparieren steht, dass die Daten der App nicht betroffen sind, neben Zurücksetzen, dass sie gelöscht werden. Danach folgen die nur lesende Zustandsprüfung in PowerShell, eine Sicherungsroutine, eine gestufte Eskalation für den Fall, dass sich die App weiterhin nicht öffnet (prüfen, ob vmcompute und hns laufen, Neuinstallation mit -PreserveApplicationData), die abgeleitete Ursache eines halb registrierten MSIX samt der GitHub-Issues (#55465, wo die Installation gelang, aber kein Einstiegspunkt entstand, dazu #50285 und #48437 — alle als closed as not planned beendet, ohne offizielle Korrektur), wie Sie die Wahrscheinlichkeit einer Wiederholung senken, und ein Vergleich mit der alten Installer-Variante, bei der die neueste MSIX-Auslieferung und ein Rechner mit altem Format beide 1.24012.9 zeigten.

Am 16. Juli 2026 hat Moonshot AI Kimi K3 veröffentlicht, ein Modell mit 2,8 Billionen Gesamtparametern. US-Halbleiteraktien wurden abverkauft, und die Geschichte eskalierte bis zu einem Vertreter des Weißen Hauses, der dem Unternehmen namentlich vorwarf, Anthropics Modelle destilliert zu haben. Weil die Zahlen und sogar die Bezeichnungen je nach Quelle auseinandergehen, gleicht dieser Artikel die Benchmark-Herausgeber, die Wirtschaftspresse, Moonshots eigene Ankündigungen und die tatsächliche Seite auf Hugging Face ab und nennt jeweils, wer die einzelne Zahl erhoben hat. Bei der Leistung stehen 57 Punkte und Platz 3 im Artificial Analysis Intelligence Index (Stand 17. Juli 2026, wobei es auch Zählungen gibt, die dieselben 57 Punkte auf Platz 4 und Platz 7 führen). Bei GDPval-AA v2, der praxisnäheren Kennzahl, liegt K3 bei 1668 gegenüber 1760 für Fable 5 und 1600 für Opus 4.8 — ein Sprung von 478 Punkten gegenüber dem Vorgänger K2.6 mit 1190, und es war dieses Verkürzen des Abstands und nicht die absolute Platzierung, das den Markt bewegte. Beim Coding holte es in der Frontend Code Arena von Arena.ai mit 1679 den ersten Platz (Fable 5 bei 1631), bei FrontierSWE verliert es dagegen mit 81,2 % gegen 86,6 % von Fable 5. Der Preis kippt mit dem Vergleich: $3 Eingabe und $15 Ausgabe sind rund 40 % günstiger bei der Eingabe und 40 bis 50 % günstiger bei der Ausgabe als Claude Opus 4.8 ($5/$25) oder GPT-5.6 Sol ($5/$30), und die gemessenen Kosten von $0.94 je Aufgabe liegen unter den $1.80 von Opus 4.8. Gegenüber chinesischen Konkurrenten ist es mit etwa dem Dreifachen von GLM-5.2 und dem 23-Fachen von DeepSeek V4 Pro jedoch das teuerste der Gruppe, der Abschlag um eine Größenordnung wie beim DeepSeek-Schock ist das also nicht. Bei den Gewichten spalten sich die Medien zwischen „Open Source“ (VentureBeat, SCMP) und dem „open weight“ von Reuters, und Letzteres ist der zutreffende Begriff. Die Gewichte sind wie angekündigt am 27. Juli 2026 erschienen und lassen sich ohne Freigabeantrag von Hugging Face herunterladen (96 safetensors-Shards). Die zusammen mit ihnen veröffentlichte Lizenz ist Moonshots eigene „Kimi K3 License“: eine MIT-ähnliche Erlaubnis plus zwei Bedingungen — eine gesonderte Vereinbarung für jedes Model-as-a-Service-Geschäft mit mehr als 20 Millionen US-Dollar Umsatz und ein gut sichtbarer Hinweis auf „Kimi K3“ in der Oberfläche von Produkten mit mehr als 100 Millionen monatlich aktiven Nutzern. Weil sich die Erlaubnis mit der Größe des Nutzers ändert, ist es nach der OSI-Definition kein Open Source; der Streit um die Bezeichnung ist damit durch den Lizenztext entschieden. An den Märkten fiel der Nasdaq am Freitag um 1,5 %, Taiwan um mehr als 6 %, Japan um 4 %, und der Halbleiter-ETF (SMH) rutschte über 20 % unter sein Hoch von Ende Juni; der Wochenrückgang des SOX wird je nach Medium aber zwischen -9 % und -12,5 % angegeben, und die Verluste wurden später von Schnäppchenjägern eingedämmt. Den Destillationsvorwurf weisen Forschende wegen der Zeitschiene zurück — 15 Tage zwischen Fables Veröffentlichung am 1. Juli und dem Start von K3 am 15. Juli —, und Belege wurden nicht öffentlich gemacht. Tempo (Messungen zwischen 33 und 62 Token pro Sekunde, dazu ein Warnhinweis von OpenRouter auf häufige 429er durch knappe Kapazität), die von 39 % auf 51 % gestiegene Halluzinationsrate und der klare Abstand im Nutzungserlebnis, den Moonshot selbst einräumt, werden durchgehend mit ausdrücklichen Konfidenzangaben behandelt.

Claude Code bleibt mitten in einer Antwort mit „API Error: Connection closed mid-response. The response above may be incomplete.“ stehen. Das ist kein Prompt-Problem: Die Verbindung, die die gestreamte Antwort transportierte, wurde geschlossen, während die Antwort noch ankam. Dieser Artikel stützt sich ausschließlich auf die offizielle Fehlerreferenz, das offizielle Changelog und Issues mit Paketmitschnitten. Er beginnt mit den offiziellen Definitionen: Connection closed heißt, die Leitung wurde gekappt, Response stalled heißt, sie ist verstummt, Server error heißt, mitten im Stream kam ein 5xx; er erklärt, warum die Teilausgabe bewusst erhalten bleibt (ein erneutes Senden könnte dieselben Tool-Aufrufe zweimal ausführen) und dass der dokumentierte Wiederaufnahmeschritt die Antwort continue ist. Anschließend trennt er die drei Ebenen, von denen das Schließen ausgehen kann (Ihr Rechner und der Ruhezustand, ein Leerlauf-Timeout in Proxy oder VPN, oder ein Schließen vom Server aus) und zeigt die vom Melder des Issues #67766 veröffentlichten Messwerte: alle zehn Vorfälle waren saubere serverseitige Schließungen, der Fehler erschien 3 bis 105 ms nach dem FIN, 7 bis 20 KB der Antwort waren bereits eingetroffen, der Anfragerumpf lag bei 1 bis 2,5 MB, eine neue Verbindung gelang in etwa 20 ms, und in 23 Tagen Aufzeichnungen fanden sich 200 Fehler in 171 Vorfällen, davon 87 weniger als fünf Sekunden nach dem vorherigen Aufruf. Der praktische Kern ist eine Chronologie echter Changelog-Einträge — 2.1.179 bewahrt die Teilantwort, 2.1.185 verschiebt den Stockungshinweis von 10 auf 20 Sekunden, 2.1.198 wiederholt vorübergehende Abbrüche mit Backoff, 2.1.199 bewahrt die Teilantwort auch bei Serverfehlern im Stream, 2.1.214 deaktiviert den Keep-Alive-Pool nach einem Fehler durch eine veraltete Verbindung — gegengehalten mit den Versionen der Meldungen (2.1.173, 2.1.181, 2.1.183), die alle vor 2.1.198 liegen. Zum Schluss folgen die begünstigenden Bedingungen, eine Checkliste in acht Schritten, sechs Leitlinien für Entwickler, die Abgrenzung zu Unable to connect und Prompt is too long sowie eine klare Trennung zwischen offiziell Bestätigtem und Unbestätigtem.

Du öffnest Hugging Face, um ein lokales LLM auszuführen, und dasselbe Modell hat eine Wand voller Dateien (Q4_K_M, Q5_K_S, GPTQ, AWQ, IQ3_M) und du erstarrst. Dieser Artikel beantwortet praktisch, welche quantisierte Datei du herunterlädst, damit es läuft, und überlässt das Konzept, was Quantisierung ist, einem anderen Artikel, um sich auf die Formatwahl zu konzentrieren. Die Wahl sind zwei Schritte: welches Format (= auf welcher Engine du es ausführst), dann welche Bit-Tiefe. Der wichtigste Fakt: eine quantisierte Datei läuft nur auf Engines, die ihr Format unterstützen. GGUF ist das einzige lokale Alleskönner-Format, das auf CPU, Mac und Teil-GPU läuft (llama.cpp/Ollama); GPTQ/AWQ/EXL2 sind GPU-first (vLLM/TGI); bitsandbytes quantisiert beim Laden in Transformers ohne Kalibrierung. Der GGUF-Name Q4_K_M besteht aus drei Teilen: Q4 (nominal 4-Bit, höher = besser und größer), K (K-quant über Super-Blöcke; ohne Zusatz/_0/_1 sind veraltet), M (S/M/L = wie stark einige wichtige Tensoren hochgestuft werden; die effektiven Bits liegen über dem Label, Q4_K etwa 4,5 bpw). Die IQ-Familie (I-quants) wird bei gleichen Bits noch kleiner, ist aber bei der Inferenz schwerer und braucht eine imatrix (eine Wichtigkeitsmatrix aus der Kalibrierung, die die entscheidenden Gewichte schützt). GPTQ minimiert den schichtweisen Fehler; AWQ schützt wichtige Gewichte über Aktivierungen (keines ist pauschal besser). Zur Bit-Tiefe: im Zweifel Q4_K_M (Ollama-Standard für viele Modelle), mit VRAM übrig auf Q5_K_M/Q6_K hoch, Q8_0 ist nahezu verlustfrei, aber nicht empfohlen, und IQ2/IQ3 nur, um ein großes Modell hineinzuquetschen. Etwa 4,5 bis 5 bpw ist das leckere Band (eine Heuristik). Dateien findest du über library=gguf, bartowski/mradermacher (Aktivität variiert) oder Ollama-Tags model:size-variant-quant. Die Zahlen sind Näherungswerte und variieren je nach Modell und Build.

Jetzt, da "frag einfach die KI" und "lass die KI alles schreiben" der Standard sind, hat die gegenteilige Frage die schärfere Klinge: Ist das überhaupt eine Situation, in der ich KI nutzen sollte? Dieser Artikel ist nicht anti-KI; es geht darum, "nicht nutzen" als Option zu bewahren, gerade damit Sie das Beste aus KI herausholen. KI ist nicht etwas, das man standardmäßig nutzt, sondern ein Werkzeug, das man bewusst wählt – gut nutzen und bewusst verzichten gehören zusammen. Sechs Situationen, in denen Verzicht gewinnt: 1. Lernen, das Grundlagen aufbaut (der Prozess des Schreibens zum Denken ist das Ziel), 2. Eingabe vertraulicher oder persönlicher Daten (nicht einfügen, ohne Bedingungen und Speicherrichtlinie zu prüfen), 3. endgültige Entscheidungen, bei denen ein Fehler fatal ist (Medizin, Recht, Sicherheit, Geld sollten nicht ungeprüft delegiert werden), 4. leichte Aufgaben, die den Aufwand nicht wert sind, 5. Arbeit, bei der menschliches Vertrauen oder Kreativität im Kern steht (Entschuldigungen, Einstellungen, Urheberschaft), 6. wenn Sie keinen Single Point of Failure hinzufügen wollen (Geschäftskontinuität). Entscheiden Sie schnell mit drei Fragen: Können Sie die Ausgabe selbst überprüfen, sind es nur Daten, die geteilt werden dürfen, und ist der Prozess etwas, das Sie gerade jetzt trainieren sollten? Wenn Sie es überprüfen können, die Daten teilbar sind und Sie nicht trainieren müssen, nutzen Sie KI; andernfalls lassen Sie es aus oder schalten eine menschliche Prüfung dazwischen. Die Nachteile übermäßiger Nutzung (kognitive Auslagerung, Übernahme plausibler Fehler, Abhängigkeit) werden als Diskussionspunkte präsentiert, nicht als feste Zahlen. KI bewusst auszulassen ist keine Bremse, sondern die Kehrseiten-Fähigkeit, die es Ihnen erlaubt, dort voll einzusteigen, wo sie passt, und eine Absicherung gegen Überabhängigkeit von KI.

Direkt nach dem Update von Claude Desktop (Windows) erscheint beim Start „Eine andere Anwendung verwendet diese Datei gerade“ und die App startet nicht — und sie bleibt defekt, bis der PC neu gestartet wird. Das ist ein bekannter Fehler der Microsoft-Store-Variante (MSIX) (GitHub #53247 und weitere). Der Kernpunkt: Ein vollständiger PC-Neustart ist nicht zwingend nötig — in vielen Fällen genügt es, sich von Windows ab- und wieder anzumelden (kein PC-Neustart und kein Abmelden von Claude), weil der verwaiste Handle dahinter pro Windows-Benutzersitzung fortbesteht. CoworkVMService zu beenden oder das Paket neu zu registrieren funktioniert laut Berichten NICHT. Trotz des Dialog-Wortlauts ist verifiziert, dass keine Dateisperre im Benutzerbereich vorliegt (handle.exe / Process Explorer): Der eigentliche Fehler liegt in der Container-Schicht von AppX/Desktop Bridge, bei der Job-Object-→-Silo-Umwandlung (0x80070020 = ERROR_SHARING_VIOLATION, Ereignisse 215/208). Der Auslöser hat zwei ungeklärte Erklärungen — der Dienst hält das Job Object (#57221) vs. ein Absturz beim Start lässt das Aufräumen unerledigt (#53247) — und es ist keine offizielle Lösung ausgeliefert worden. Die dauerhafte Umgehung ist der Wechsel zur Squirrel-Variante (Installer). Basierend auf einem einzelnen Rechner (Windows 11 Home 10.0.26200), abgeglichen mit GitHub-Issues; durchgehend mit Vertrauenskennzeichnung.

Am 8. Juli 2026 hat OpenAI mit GPT-Live die Sprachfunktion von ChatGPT von Grund auf erneuert: ein Vollduplex-Modell, das hört und spricht zugleich – es gibt Hörsignale, fängt Unterbrechungen auf und schneidet nachdenkliches Schweigen nicht ab. Mit einer Latenz von <250ms erreicht es ein menschennahes Gesprächstempo; tiefes Schlussfolgern und Web-Suche werden im Hintergrund an GPT-5.5 delegiert. Free nutzt GPT-Live-1 mini, Go/Plus/Pro GPT-Live-1. Dieser Beitrag erklärt Funktionsweise, Unterschiede zum Advanced Voice Mode, Tarife, aktuelle Einschränkungen und die Abgrenzung zu GPT-Realtime.

Bei langer Arbeit mit Claude Code wiederholt die Antwort plötzlich dutzende bis hunderte Male dasselbe Wort „court“ und bricht mit „API Error: Response stalled mid-stream“ ab. Dahinter stecken meist zwei getrennte, bekannte Bugs, die sich verketten: eine Wiederholungsschleife (Degeneration) auf Modellseite und ein gestoppter Antwort-Stream auf der Übertragungsseite. Dieser Artikel klärt auf Basis der offiziellen Fehler-Referenz und realer GitHub-Issues das Wesen beider Ebenen, die auslösenden Bedingungen, die sofortige Notbremse (Esc → neue Sitzung, /clear), die Vorbeugung für Entwickler (Lese-Timeout, Wiederholungserkennung, max_tokens) sowie die Abgrenzung zum verwandten court/invoke-Tag-Leck.

Der plötzlich in Claude Code und der API auftauchende Fehler 'API Error: 400 Output blocked by content filtering policy' bedeutet weder ein Nutzungslimit noch eine überschrittene Kontextgrenze, sondern dass der Sicherheitsfilter die 'Ausgabe' gestoppt hat, die Claude zurückgeben wollte. Hauptzweck ist die Verhinderung der wortgetreuen Reproduktion bestehender Werke; bei der Volltext-Generierung von Standardlizenzen wie MIT/Apache, bei 'Angleich'-Aufgaben an bestehende Quellen oder beim Vervielfältigen langer Dokumente kommt es häufig zu Fehlalarmen (False Positives) ohne böse Absicht. Dieser Artikel ordnet die offizielle Erklärung (der Ausgabefilter erkennt die Werk-Reproduktion und blockiert mit 400), die in echten Claude-Code-Issues sichtbaren Fehlalarm-Muster (OSS-Repo-Ersteinrichtung, Listenabgleich, am Ende langer Agenten-Läufe als Token-Limit fehldiagnostiziert), die Sofortlösungen (nicht abschreiben lassen, sondern per Tool holen; Prompt in Richtung Generieren/Zusammenfassen umformulieren; mit Esc die Retry-Schleife stoppen; Aufgabe aufteilen; Fehlalarme dem Support melden) sowie die Abgrenzung zu Prompt is too long, usage limit, 529 Overloaded und max_tokens.

Die größte Ursache, warum Solo-Entwicklung nie fertig wird, ist „zu viel Ausbauen“. Während man immer mehr Funktionen drauflädt, wird es komplex und verschwindet, ohne je veröffentlicht zu werden. Der einzige Weg, das zu vermeiden, ist, das kleinste Produkt, das Wert vermittelt — das MVP — auf eine Funktion eingegrenzt im Höchsttempo zu veröffentlichen. Dieser Artikel erklärt aus Sicht des Solo-Entwicklers, der KI zum Partner macht: das richtige Verständnis vom MVP, die Umfangsentscheidung beim Kürzen von Funktionen, die zwei Routen, mit KI am schnellsten zu bauen (codeloses Vibe Coding / Praxis im KI-Editor), das Erkennen von „fertig“ und den Weg bis zur Veröffentlichung und ersten Nutzung durch eine Person.

Das häufigste Scheitern in der Solo-Entwicklung ist „gebaut, aber keiner nutzt es“. Doch der wahre Engpass ist nicht die Baukraft, sondern die Kundengewinnung. „Baust du etwas Gutes, kommen die Leute“ ist eine Illusion. Dieser Artikel fasst aus Sicht des Solo-Entwicklers praxisnah die Reihenfolge zusammen: schon vor dem Bauen mit Build in Public Interessenten sammeln, die ersten 10 „nicht skalierend“ aus dem nahen Umfeld manuell holen, die ersten 100 dort finden, wo sie sind (Communitys, Social Media), indem man beiträgt, und mit SEO/AEO/LLMO dauerhaften Zustrom schaffen — und wie man diese Runde dreht, während man KI für die Vorarbeit nutzt.

Jetzt, da die KI eine „Hand zum Programmieren“ hat, kann schon eine einzelne Person ein Produkt bauen und veröffentlichen. Doch die Informationen sind über die Schritte verstreut, und man verliert leicht den Überblick, womit man anfangen soll. Dieser Artikel ist die Gesamtkarte von der Idee über Entwurf und Implementierung bis zu Veröffentlichung und Monetarisierung: Er ordnet die Solo-Entwicklung in fünf Phasen – Festlegen → Vorbereiten → Bauen → Veröffentlichen → Wachsen lassen – zeigt für jeden Schritt, was zu tun ist und welches Werkzeug man nutzt, und verweist bei Bedarf auf die jeweiligen Einzelanleitungen (Hub-Artikel). Geführt wird auf zwei Spuren: der 🌱 Einstiegsroute fast ohne Code und der 🔧 Praxisroute mit Code im KI-Editor. Von Spec-Driven Development, KI-App-Buildern, Claude Code/Cursor und dem Einbau von KI-Funktionen (API/RAG/Gateway) über Deployment, SEO/AEO-Nutzergewinnung, Monetarisierung und Kostenkontrolle bis zu den 5 Stolperfallen der Solo-Entwicklung mit KI – alles mit Wegweisern zu den bestehenden Praxisanleitungen auf einer Seite.