DeepSeek Super-Agent: Was ein proaktiver Coding-Agent kostet

Aktualisiert November 2, 2026 · erstveröffentlicht November 2, 2026

DeepSeeks Super-Agent (dsh-superagent) ist ein Forschungsprototyp unter MIT-Lizenz, der GitHub abfragt, Anfragen berechtigter Personen in Tickets verwandelt und eine Worker-Sitzung einen Pull Request öffnen lässt. Er begrenzt die parallelen Worker (Standard 3), kennt aber keine Token- oder Ausgabenobergrenze. Die Modellrechnung wird also nur durch Ihren Provider-Schlüssel und Ihre Einstellungen gesteuert.

Dieser Artikel wurde am 2. November 2026 zuerst auf Grundlage der README und der Presseberichte veröffentlicht und am selben Tag neu geschrieben, nachdem wir das Repository selbst gelesen hatten (Dokumentation, Prompts und Quellcode). Die Fakten stammen aus dem Projekt-Repository und von Help Net Security. Bloomberg berichtete über die Veröffentlichung als Herausforderung für Claude Code; DeepSeek hat keinen Benchmark dagegen veröffentlicht, behandeln Sie diese Darstellung also als Positionierung, nicht als Ergebnis.

Was macht er?

Eingang: Er fragt GitHub über die gh-Kommandozeile ab, standardmäßig alle 60 Sekunden. Webhooks gibt es nicht. Erwähnungen, abonnierte Issues und Pull Requests, Review-Kommentare und CI-Ergebnisse kommen auf diesem Weg an. Feishu-Chat ist ein separates, optionales Plugin, das standardmäßig aus ist; eine reine GitHub-Installation ist der dokumentierte Standard.
Zulassung: Eine Anfrage ist explizit, wenn eine berechtigte Person den Agenten anspricht. Alles andere ist ein abgeleiteter Kandidat, den ein Modell beurteilen muss. Solange keine Person auf einer Erlaubnisliste steht, kann keine Anfrage zu einem Ticket werden.
Arbeit: Eine kleine Router-Sitzung entscheidet, was mit jedem Auslöser geschieht. Jedes akzeptierte Ticket bekommt eine eigene dauerhafte Worker-Sitzung in einem eigenen Verzeichnis, meist einem Git-Worktree. Der Worker implementiert, prüft, committet, pusht und öffnet einen Pull Request unter dem eigenen GitHub-Konto des Agenten und verfolgt anschließend CI und Review.
Status: Die README nennt ihn einen “research prototype for reference only, not an official DeepSeek product” und sagt, man solle ihn als Forschungscode und nicht als produktionsreife Software behandeln.

Wohin fließt das Geld?

Das Abfragen von GitHub verbraucht keine Modell-Token. Die Kosten beginnen, wenn ein Modell aufgerufen wird. Im Code geschieht das an drei Stellen:

Die Router-Sitzung liest jeden zugelassenen Auslöser und leitet ihn weiter. Jede explizite Anfrage kostet also mindestens einen Router-Durchgang, bevor die Arbeit beginnt.
Der Assessor beurteilt abgeleitete Kandidaten. Das ist für die Standardeinstellung wichtig: Im observe-Modus führt der Agent die Bewertung trotzdem aus und vermerkt nur “would accept”, statt zu handeln. Observe ist ein Schattenmodus für Aktionen, nicht für Kosten. Standardmäßig erhält der Agent nur Nachrichten, die ihn ansprechen; nicht adressierte Nachrichten erreichen den Assessor also nur, wenn Sie die repository-weiten Observe-Schalter für Issues, Pull Requests, Kommentare oder CI einschalten.
Worker-Sitzungen leisten die eigentliche Arbeit: Code lesen, bearbeiten, Prüfungen ausführen, nach Fehlern wiederholen und Review-Runden abwickeln. Jeder Worker hat einen eigenen Kontext, und dort gehen die meisten Token hin.

Das Modell für Router/Assessor und das Modell für die Worker werden getrennt festgelegt, und das Modell eines Workers steht fest, sobald seine Sitzung erstellt wird. Der Code hat keinen Token-Zähler, keine Obergrenze pro Ticket und kein Ausgabenbuch, und das Panel zeigt weder Nutzung noch Kosten. Der einzige budgetbezogene Code erkennt bei Wiederholungen einen “budget exceeded”-Fehler des Providers und zeigt ihn als Gesundheitswarnung an; er stoppt die Arbeit nicht. DeepSeeks Dokumentation nennt keine Kosten pro Pull Request.

Welche Limits gibt es?

Limit	Dokumentierter Wert
Parallele Worker	Standard 3, konfigurierbar von 1 bis 16, plus ein Überlaufplatz, der sich nur öffnet, wenn die Nachricht einer Person einen Worker weckt
Abfrageintervall	Standard 60 Sekunden (60 bis 3600)
Zeitlimit der Bewertung	Standard 120 Sekunden (30 bis 600); zwei erneute Einreihungen, danach als nicht verfügbar vermerkt
Vorübergehende Modellfehler	3 automatische Wiederholungen nach 15, 30 und 60 Sekunden; danach wird das Ticket als fehlgeschlagen markiert und wartet auf eine Person
Hintergrundjobs nach dem Durchgang eines Workers	30 Minuten, dann beendet
Bot-Review-Runden	3 pro Pull Request und automatisiertem Reviewer (Prompt-Text, kein erzwungener Code)
Auto-Merge	Aus, solange Sie kein separates Merge-Konto benennen; dann nur für einen fertigen Pull Request unter 200 geänderten Zeilen, bei dem Freigaben den Head-Commit abdecken. Auch das ist Prompt-Text, kein Code

Ein Worker-Platz bleibt belegt, solange seine Hintergrundjobs laufen. Die Obergrenze für Worker ist damit auch eine Obergrenze für gleichzeitige Token-Ausgaben, aber nicht dafür, wie viel jeder Worker ausgibt.

Was braucht er, und welche Risiken gibt es?

Ein eigenes GitHub-Benutzerkonto für den Agenten mit Schreibzugriff. Eine GitHub App kann nicht der Agent sein, weil der Agent Benachrichtigungen liest. Er braucht außerdem die DeepSeek-Harness-Laufzeit (dsh), Node, pnpm, git, tmux und gh.
Vollzugriff. Worker-Sitzungen laufen mit der Berechtigungsvoreinstellung für vollen Zugriff als eigener Betriebssystem-Benutzer des Betreibers. Das Projekt sagt, seine Befehls-Wrapper seien Standardeinstellungen, keine Sicherheitsgrenze. Betreiben Sie ihn auf einem isolierten Rechner oder Konto.
Der Zustand wächst unbegrenzt. Die Architekturnotizen sagen, dass alte Einträge noch nicht gelöscht werden.

Wie budgetiert man einen Test?

Nutzen Sie das Protokoll der Anfragen, die angenommen worden wären, um den Umfang der Arbeit einzuschätzen, und bewerten Sie ihn dann mit Ihren eigenen Messungen. Die monatlichen Ausgaben ergeben sich aus akzeptierten Arbeitsitems x durchschnittlich abgerechneten Kosten pro Item, wobei die Kosten pro Item den Router-Durchgang, jede Bewertung, jeden Worker-Aufruf, jede Wiederholung und jeden abgebrochenen Versuch enthalten. Teilen Sie die Gesamtausgaben durch die Items, die zu akzeptierten Änderungen wurden, wie bei den Kosten pro erfolgreicher Aufgabe.

Beispiel mit angenommenen Eingaben, keine DeepSeek-Daten: 200 Arbeitsitems im Monat bei angenommenen $4 durchschnittlich abgerechneten Kosten je Item ergeben $800. Führen nur 140 zu einer akzeptierten Änderung, betragen die Kosten pro akzeptierter Änderung $800 / 140 = $5,71, nicht $4. Die Lücke ist der Preis für abgebrochene und abgelehnte Arbeit.

Welche Kontrollen sollten Sie zuerst setzen?

Halten Sie die Erlaubnisliste klein und fügen Sie Personen bewusst hinzu. Sie ist das erste Ausgabentor.
Lassen Sie die Schalter für den Empfang aller Nachrichten aus, bis Sie das Protokoll der Would-accept-Einträge gelesen haben, denn sie schicken nicht adressierten Traffic an den Assessor.
Setzen Sie maxWorkers niedrig für einen Test und legen Sie die echte Ausgabenobergrenze an Ihrem Modell-Provider-Schlüssel oder Gateway fest, da das Projekt keine hat. Siehe drei Agenten-Budgets und Ausgabenleitplanken für die Produktion.
Taggen Sie Ausgaben nach Repository und Ticket, damit sich ein Pull Request auf seine Rechnung zurückführen lässt.
Überlassen Sie das Mergen Menschen und behandeln Sie den Delivery-Prompt als Richtliniendatei mit einem Verantwortlichen.

Wie schneidet er im Vergleich zu anderen GitHub-Agenten ab?

Drei weitere Optionen machen aus einer GitHub-Anfrage einen Pull Request. Unterschiedlich ist, wo die Ausgaben sichtbar werden und was sie begrenzt. Geprüft am 2. November 2026; bestätigen Sie es auf der Seite des jeweiligen Anbieters.

Option	Auslöser und Laufzeit	Wo die Ausgaben sichtbar werden	Dokumentierte Limits
Claude Code GitHub Action	`@claude` in einem Issue- oder PR-Kommentar erwähnen; läuft auf GitHub-gehosteten Runnern. Die auslösende Person braucht Schreibzugriff, und Bot-Akteure werden abgelehnt, sofern sie nicht gelistet sind	GitHub-Actions-Minuten plus Claude-API-Token (oder Ihr Claude-Abonnement, wenn Sie ein OAuth-Token verwenden)	`--max-turns`, Timeouts auf Workflow-Ebene und GitHub-Concurrency-Kontrollen
GitHub Copilot Cloud Agent	Recherchiert, plant und implementiert im Hintergrund in einer Cloud-Umgebung; ein Pull Request pro Aufgabe	Cloud- und Actions-Rechenleistung belasten ein monatliches Guthaben des GitHub-Kontos, getrennt von den KI-Credits; Details zur Abrechnung stehen auf einer separaten Seite	Actions-Sitzungen haben maximal 59 Minuten. Ohne Schreibzugriff nur lesend; Branch Protection kann ihn blockieren. Die neue Cloud-Oberfläche gilt ab dem 28. Oktober 2026 für bezahlte Tarife
OpenHands	MIT-lizenziert, selbst gehostet; führt einen eigenen Agenten oder Agenten von Drittanbietern aus; eigenes Modell mitbringen. Die README sagt nicht, wie ein GitHub-Issue es auslöst	Ihr Modell-Provider oder OpenHands Cloud	In der README nicht genannt. Der Modus ohne Sandbox warnt, dass der Agent vollen Dateisystemzugriff hat
DeepSeek Super-Agent	Fragt GitHub ab; eigenes Agentenkonto; selbst gehostet	Ihr Modell-Provider-Schlüssel	Nur Worker-Anzahl und Timeouts; keine Token- oder Ausgabenobergrenze

Der praktische Unterschied: Die gehosteten Optionen liegen innerhalb einer Rechnung, die Sie bereits steuern (ein Actions-Guthaben, ein API-Schlüssel mit Workspace-Limits), und dokumentieren Limits für Durchgänge oder Zeit, während der Super-Agent all das Ihnen überlässt. Kostenvergleiche auf Tool-Ebene finden Sie unter Kosten von Cursor, Copilot und Claude Code im Vergleich.

Sollten Sie ihn jetzt einsetzen?

Für die Produktion nein: DeepSeek selbst sagt, er sei nicht produktionsreif. Für einen abgegrenzten Test in einem unkritischen Repository, auf einem isolierten Rechner, mit einem gedeckelten Schlüssel ist er ein günstiger Weg zu erfahren, was proaktive Agenten Ihr Team kosten, denn der Code ist kostenlos und die Ausgaben sind bei Ihrem eigenen Provider sichtbar. Die Entscheidungskennzahl sind die Kosten pro akzeptiertem Pull Request im Verhältnis zur eingesparten Aufmerksamkeit, nicht die Schlagzeile, er konkurriere mit einem anderen Tool.

Häufige Fragen

Was ist DeepSeeks Super-Agent?

dsh-superagent ist ein quelloffener (MIT) Forschungsprototyp eines proaktiven Coding-Agenten von DeepSeek. Er fragt GitHub ab, lässt Anfragen berechtigter Personen zu, gibt jedem akzeptierten Ticket eine Worker-Sitzung in einem eigenen Verzeichnis und öffnet einen Pull Request unter seinem eigenen GitHub-Konto.

Hat der Super-Agent ein Ausgabenlimit?

Nein. Er begrenzt parallele Worker (Standard 3, Bereich 1 bis 16) und hat Timeouts und Wiederholungslimits, aber keinen Token-Zähler, keine Obergrenze pro Ticket und kein Ausgabenbuch, und sein Panel zeigt weder Nutzung noch Kosten. Legen Sie die Obergrenze an Ihrem Modell-Provider-Schlüssel oder Gateway fest.

Ist der Super-Agent kostenlos?

Der Code ist unter der MIT-Lizenz kostenlos. Der Betrieb kostet, was die angebundenen Modelle, der Rechner und die Tools kosten. DeepSeek veröffentlicht keine Kosten pro Aufgabe.

Vermeidet der Observe-Modus Modellkosten?

Nein. Der Observe-Modus führt die Bewertung aus und vermerkt, dass der Agent die Anfrage angenommen hätte, statt zu handeln. Er spart die Kosten des Workers, nicht die des Assessors. Standardmäßig werden nur Nachrichten empfangen, die den Agenten ansprechen; nicht adressierte Nachrichten werden also nur bewertet, wenn Sie die Observe-Schalter einschalten.

Ist der Super-Agent produktionsreif?

Nein. Die README nennt ihn einen Forschungsprototyp nur zur Referenz, kein offizielles DeepSeek-Produkt, und sagt, man solle ihn als Forschungscode behandeln. Seine Worker laufen mit Vollzugriff als Benutzer des Betreibers, und sein Zustand wächst unbegrenzt.

Weiterführend

Möchten Sie das auf Ihren Stack anwenden? Bringen Sie Anbieterrechnungen, Gateway-Protokolle und die wichtigsten Workflows mit; wir ordnen Kostentreiber und Einsparpotenziale zu. Kostenlose Prüfung buchen →

Zurück zu finopsllm.com