So verwendest du diese Checkliste, bevor du ein kostenloses LLM für Code auswählst
Bei der Wahl eines Sprachmodells zum Programmieren geht es nicht darum, welches in einem Benchmark die meisten Punkte holt, sondern darum, ob es zu deinem tatsächlichen Workflow passt. Diese Checkliste ist dafür gedacht, dass du sie mit geöffnetem Editor von oben nach unten durchgehst: Es sind Kriterien, die sich nach fünf Minuten Nutzung bemerkbar machen, nicht in einer Marketing-Demo.
Eine Vorwarnung vorab, und sie ist wichtig: Kostenlose Tarife ändern sich ohne Vorankündigung. Nachrichtenlimits, Token-Kontingente und verfügbare Modelle werden laut der offiziellen Dokumentation der jeweiligen Anbieter häufig angepasst. Was heute funktioniert, funktioniert vielleicht nächsten Monat nicht mehr, also überprüfe jeden Punkt zum Zeitpunkt des Abschlusses oder der Registrierung.
Block 1: Modelle, die du kostenlos nutzen kannst, und wofür jedes einzelne taugt
Es gibt keinen absoluten Sieger. Es gibt Modellfamilien mit unterschiedlichen Profilen, und es lohnt sich, klar zu wissen, welches zu welcher Aufgabe passt.
Generalistische Modelle mit großzügiger kostenloser Stufe
- ChatGPT (kostenlose Version): nützlich, um Codefragmente zu erklären, Tests zu generieren und einzelne Funktionen zu refaktorieren. Im kostenlosen Tarif ist der Zugang zum leistungsstärksten Modell meist eingeschränkt, daher eignet es sich besser für klar abgegrenzte Aufgaben als für komplette Projekte.
- Claude (kostenloser Tarif): zeichnet sich beim Lesen von langem Code und beim Aufrechterhalten von Kohärenz aus, wenn du mehrere Dateien einfügst. Das kostenlose Kontingent ist restriktiver als bei anderen, und das merkt man bei intensiven Debugging-Sitzungen.
- Gemini (kostenlose Stufe): gute Integration mit dem Google-Ökosystem und ein großes Kontextfenster, was hilft, wenn du mit mittelgroßen Repositories arbeitest.
- DeepSeek: Modell mit offener Version und kostenlosem Webzugang; liefert gute Ergebnisse bei Code und Mathematik, wobei Latenz und Verfügbarkeit des Dienstes zu bestimmten Zeitpunkten unregelmäßig waren.
- Qwen Coder und offene Varianten: speziell für Code konzipiert, mit Lizenzen, die lokale Ausführung erlauben. Sie erfordern Hardware, beseitigen aber das Kontingent.
In den Editor integrierte Assistenten
- GitHub Copilot Free: bietet eine begrenzte Anzahl an Vervollständigungen und Anfragen pro Monat. Es dient der Inline-Autovervollständigung, nicht für lange Chat-Sitzungen.
- Codeium / Windsurf (kostenlose Stufe): in vielen Fällen unbegrenzte Autovervollständigung und Chat mit Kontingent. Eine gute Option, wenn du den Fokus im Editor nicht verlieren willst.
- Continue oder Cline mit kostenlosen Modellen über API: ermöglichen die Anbindung offener Modelle oder kostenloser Anbieter-Stufen. Mehr Konfiguration, mehr Kontrolle.
Block 2: Technische Prüfungen, die den Unterschied machen
Kontextfenster: Wie viel Code wirklich hineinpasst
Ein Modell mit 200.000 Token Kontext bedeutet nicht, dass du das ganze Projekt einfügen kannst und es gut herauskommt. Die Qualität der Aufmerksamkeit nimmt bei sehr langen Kontexten ab, und viele kostenlose Tarife kürzen dieses Limit. Teste mit einer Datei mit 500 Zeilen und beobachte, ob Querverweise zwischen Funktionen erhalten bleiben.
Qualität bei Sprachen, die nicht Python oder JavaScript sind
Hier scheitern viele Vergleiche. Die Modelle glänzen meist bei Python und JavaScript und schwächeln bei Kotlin, Swift, Rust oder komplexem SQL mit spezifischen Dialekten. Wenn du mit COBOL, ABAP oder Nischensprachen arbeitest, rechne mit unregelmäßigen Ergebnissen und überprüfe die Ausgabe immer.
Umgang mit Abhängigkeiten und Versionen
Ein häufiger Fehler: Das Modell generiert Code mit APIs aus alten Versionen. Das passiert oft bei Bibliotheken, die sich schnell ändern (React, Next.js, Tailwind). Frage explizit nach der Version und prüfe die offizielle Dokumentation. Dafür gibt es keine Abkürzung.
Codeausführung und Sandbox
Manche Assistenten führen den generierten Code in einer isolierten Umgebung aus. Das ist praktisch, um Skripte zu validieren, ersetzt aber nicht deine Tests. Wenn das Modell sagt, der Code funktioniere, weil es ihn ausgeführt hat, prüfe, ob die Umgebung deiner entspricht.
Block 3: Reale Grenzen der kostenlosen Tarife
- Kontingent pro Zeitfenster: Viele Dienste begrenzen Nachrichten alle X Stunden. Plane lange Sitzungen entsprechend.
- Herabgestuftes Modell: Die kostenlose Stufe verwendet meist ein schwächeres Modell als die bezahlte. Vergleiche die tatsächliche Qualität, nicht den Namen.
- Privatsphäre deines Codes: Prüfe, ob der Anbieter deine Gespräche zum Training verwendet. Bei proprietärem Code ist das ein entscheidender Faktor. Manche erlauben, es in den Einstellungen zu deaktivieren; andere nicht.
- Datenaufbewahrung: Wie lange deine Prompts und Antworten gespeichert werden. Bei Kundenprojekten kann das ein rechtliches Problem sein.
- Verfügbarkeit: Kostenlose Tarife haben zu Stoßzeiten eine niedrigere Priorität. Wenn du beruflich davon abhängst, habe einen Plan B.
Block 4: Praktische Validierungs-Checkliste in 15 Minuten
Bevor du dich für eines entscheidest, mache diesen Test mit demselben Prompt bei jedem Kandidaten:
- Füge eine Funktion mit einem subtilen Bug ein und bitte darum, ihn zu finden, ohne sie neu zu schreiben. Miss, ob es richtig liegt oder etwas erfindet.
- Bitte um eine Erklärung eines Legacy-Codefragments ohne Kontext. Beobachte, ob es Lücken mit Erfindungen füllt.
- Fordere einen Unit-Test für diese Funktion an und führe ihn aus. Viele Modelle generieren Tests, die konstruktionsbedingt bestehen und nichts prüfen.
- Frage nach einer Einschränkung des Modells selbst oder nach einem Thema, das es nicht kennt. Ein gutes Modell erkennt, was es nicht weiß.
- Fordere Code mit einer konkreten Version einer Bibliothek an und überprüfe die Syntax anhand der offiziellen Dokumentation.
Ein konkretes Beispiel, das zeigt, warum das wichtig ist: Wenn man mehrere Modelle um eine Funktion zum Parsen von Daten in einer bestimmten Bibliothek bittet, ist es üblich, dass sie eine Syntax zurückgeben, die in der aktuellen Version nicht mehr existiert. Der Code sieht korrekt aus, kompiliert in einem isolierten Beispiel und schlägt in der Produktion fehl. Die Prüfung gegen die Dokumentation ist nicht optional.
Block 5: Wann ein kostenloses LLM dir nicht hilft
Das funktioniert nicht für alle Szenarien, und das sollte man klar sagen:
- Große Refactorings mit Querabhängigkeiten: Das kostenlose Kontingent ist aufgebraucht, bevor du fertig bist, und die Kohärenz geht zwischen den Sitzungen verloren.
- Code unter NDA oder mit sensiblen Daten: Wenn du nicht garantieren kannst, dass nicht mit deinen Daten trainiert wird, verwende es nicht.
- Aufgaben, die reproduzierbare Ausführung erfordern: Du brauchst Tests und CI, keinen Chat, der sagt, dass es funktioniert.
- Lernen von Grund auf: Ein Modell kann dir eine Lösung geben, die du nicht verstehst. Ohne Grundlage erkennst du nicht, wann es sich irrt.
Block 6: Strategie der kombinierten Nutzung
In der Praxis nutzen die meisten Entwickler, die ich kenne, nicht nur eines. Sie kombinieren einen Assistenten im Editor für Autovervollständigung und schnelle Abfragen mit einem generalistischen Chat für Erklärungen und Debugging. Diese Kombination deckt mehr ab, als auf einen einzigen Anbieter zu setzen. Berücksichtige die Lernkurve jedes Tools: Einen lokalen Assistenten mit offenen Modellen einzurichten kostet Zeit, beseitigt aber die Kontingentgrenzen.
Laut Branchenanalysen hat sich die Qualität offener Modelle bei Code-Aufgaben der geschlossener Modelle angenähert, allerdings mit höheren Hardware-Anforderungen. Wenn du eine GPU mit ausreichend Speicher hast, ist die Ausführung eines lokalen Modells eine echte Alternative, kein Experiment.
Zusammenfassung der Checkliste
- Versteht das Modell deine Hauptarbeitssprache?
- Deckt das Kontextfenster die Dateien ab, mit denen du arbeitest?
- Kennst du das Nachrichtenlimit und wie es deine Sitzungen beeinflusst?
- Weißt du, ob dein Code zum Training verwendet wird?
- Hast du die Ausgabe gegen die offizielle Dokumentation validiert?
- Hast du einen Plan B, falls der Dienst ausfällt oder seine Bedingungen ändert?
- Erkennst du, wann das Modell etwas nicht weiß und es zugibt?
Wenn du diese Fragen für einen konkreten Kandidaten mit Ja beantwortest, hast du eine solide Wahl getroffen. Wenn er bei zwei oder drei Punkten scheitert, probiere weiter. Kein kostenloses Modell ersetzt die Code-Review, und keines garantiert dir, dass die Ausgabe ohne Überprüfung korrekt ist.