In diesem Beitrag
Greptile Base, Plus oder Apex: PR-Reviews sinnvoll budgetieren
Quellenbasis: Dokumentation am 8. Oktober 2026 geprüft. Dies ist ein recherchierter Implementierungsleitfaden. Der folgende Pilot ist ein Vorschlag; wir haben diese Herstellerprüfungen nicht durchgeführt und ihre Leistung nicht gemessen.
Welche Greptile-Stufe sollte ein Team wählen?
Beginne mit den Folgen eines übersehenen Fehlers. Eine kleine Änderung an der Autorisierung kann mehr Prüfung verdienen als ein großer mechanischer Umbau. Unsere vorgeschlagene Regel: Base bei begrenzten Änderungen, Plus bei modulübergreifender Korrektheit und Apex bei Auswirkungen auf Zugriffe, Zahlungen, Migrationen oder Wiederherstellung. Prüfe diese Regel mit eigenen Pull Requests, bevor du sie automatisierst.
Greptiles Ankündigung vom 25. September 2026 führte Plus und Apex zusätzlich zu Base ein. Das Beispiel zeigt unterschiedliche Befunde bei einer Celestia-Änderung. Es ist Herstellerevidenz für eine Fähigkeit, keine unabhängige Schätzung der Fehlererkennung in deinem Team.
Was kosten Base, Plus und Apex?
Die aktuelle Greptile-Preisseite nennt für Pro 30 USD pro Sitz und Monat, 50 enthaltene Credits pro Sitz und 1 USD für zusätzliche Credits. Reviews verbrauchen Credits. Ein PR mit mehreren Prüfläufen benötigt deshalb mehrere Budgeteinträge.
| Stufe | Credits pro Review | Vorgeschlagener Einsatz im Pilot |
|---|---|---|
| Base | 1 | Begrenzte Änderungen mit klaren Abnahmetests |
| Plus | 3 | Modulübergreifendes Verhalten oder unklare Aufrufstellen |
| Apex | 10 | Folgenreiche Änderungen mit höherem Prüfbedarf |
Beispielrechnung für einen Sitz: 30 Base-, fünf Plus- und zwei Apex-Reviews benötigen 65 Credits. Bei 50 enthaltenen Credits ergibt das modellhaft 30 USD + 15 USD = 45 USD, vor Steuern und vertraglichen Anpassungen. Alle 37 Änderungen mit Apex zu prüfen würde 370 Credits und modellhaft 350 USD kosten. Das sind Budgets, keine gemessenen Rechnungen oder gleichwertigen Qualitätsalternativen.
Wie beeinflussen Monorepo-Einstellungen das Budget?
Die Dokumentation der Prüfstufen beschreibt Auto mit Abrechnung der ausgewählten Stufe sowie Einstellungen je Verzeichnis. Berührt ein PR Verzeichnisse mit unterschiedlichen Stufen, gilt die höchste. Die CLI verwendet ohne entsprechenden Parameter Base, unabhängig von der konfigurierten Stufe. T-Rex ist derzeit mit Plus, Apex und Auto nicht kompatibel.
Halte diese Details im Prüfprotokoll fest: die angezeigte Stufe jedes abgeschlossenen Reviews, betroffene Verzeichnisse und Auslöser. Sonst vergleicht ein vermeintlicher Base-Apex-Test unterschiedliche Routing-Einstellungen. Eine UI-Einstellung muss nicht für einen CLI-Pilot gelten.
Die Dokumentation zur Abrechnung je Sitz ordnet Credits dem PR-Autor zu, nicht einem gemeinsamen Teamkonto. Abgeschlossene Reviews und Wiederholungen belasten diesen Autor, auch wenn jemand anderes sie auslöst. Berechne jeden Sitz einzeln und summiere erst danach.
Wie prüfst du, ob sich Apex lohnt?
Nutze eine freigegebene Stichprobe mit gewöhnlichen, modulübergreifenden und folgenreichen Änderungen. Nimm fehlerfreie PRs und PRs mit unabhängig bestätigten Defekten auf. Fixiere Commit, Repository-Kontext und Prüfanweisungen; starte jede Stufe vom selben Zustand. Verrate bekannte Fehler nicht im Prompt.
- Bewerte Befunde ohne Kenntnis der Stufe und reproduziere jeden gemeldeten Fehler.
- Zähle unterschiedliche relevante Defekte, übersehene bekannte Defekte und Fehlalarme. Mehrere Kommentare zu einem Problem sind ein Befund.
- Erfasse Prüfdauer, abgerechnete Credits und menschliche Nachprüfungsminuten.
- Wiederhole einen Teil der Läufe, um Schwankungen sichtbar zu machen. Nenne Stichprobengröße und Ausschlüsse.
- Vergleiche zusätzliche bestätigte Befunde mit zusätzlichen Kosten und Prüfzeiten je Risikogruppe.
Eine historische Stichprobe zeigt keine Erkennungsrate für alle denkbaren Fehler. Bekannt sind nur unabhängig festgestellte Defekte dieser Stichprobe. Ein überzeugend formulierter Befund bleibt ohne Reproduktion unbestätigt.
Was muss das Team weiterhin selbst prüfen?
Geschäftliche Invarianten, Migrationswiederherstellung und Berechtigungsgrenzen gehören in menschliche Reviews und ausführbare Tests. Eine tiefere Prüfung kann Abhängigkeiten aufzeigen; sie entscheidet nicht, ob deine Erstattungsregeln oder Mandantenverträge richtig sind. Ein sauberes Review darf nicht unbemerkt zur Produktionsfreigabe werden.
Erfasse Kosten pro akzeptiertem PR getrennt von Kosten pro zusätzlichem bestätigten Defekt. Die erste Kennzahl misst den Betrieb, die zweite hilft beim Eskalationsbudget. Liefert Apex in einer Gruppe mehr Kommentare ohne zusätzliche bestätigte Fehler, untersuche das vor einer Ausweitung.
Rechtfertigen viele geänderte Dateien automatisch Apex?
Nein. Greptile empfiehlt Apex für große und produktionsbezogene PRs, aber Dateianzahl ist nur ein Risikoindikator. Eine generierte Umbenennung und eine dreizeilige Eigentumsprüfung haben andere Fehlerfolgen. Kombiniere Pfad- und Risikoregeln und passe sie anhand der Pilotergebnisse an.
Wann sind tiefere Reviews sinnvoll?
Nutze sie dort, wo zusätzliche bestätigte Befunde Credits und Verzögerung rechtfertigen. Behalte günstigere Wege, wenn dieselbe Abnahmeevidenz ausreicht. Mit Stichprobe, Fehlerlabels und Eskalationsregeln kannst du einen Pilot für euren Review-Prozess besprechen, wenn die offene Frage eure Codebasis betrifft.
Weiterführende Umsetzungshilfe
Graphify Review 2026: Lohnt sich ein Knowledge Graph für deine Codebasis?. Canary AI QA: Fehlererkennung statt Benchmark-Punkte prüfen.
Geprüfte Quellen
Unabhängigkeit und Marken: Wavect veröffentlicht diese Seite und ist selbst Anbieter, wir haben also ein wirtschaftliches Interesse daran. Mit den hier genannten anderen Unternehmen sind wir weder verbunden noch von ihnen beauftragt oder empfohlen, und alle Firmennamen, Marken und Warenzeichen Dritter gehören ihren jeweiligen Inhabern. Aussagen über andere Anbieter stammen aus öffentlich zugänglichen Quellen, vor allem aus deren eigenen veröffentlichten Seiten, mit Stand des auf dieser Seite genannten Prüfdatums, und können sich seither geändert haben. Bitte prüfe sie vor einer Entscheidung selbst. Diese Seite wurde nach bestem Wissen und Gewissen erstellt, mit dem Ziel, möglichst objektiv zu bleiben. Wenn dir etwas falsch oder unfair erscheint, schreib uns und wir korrigieren es: [email protected]