Derzeit ist offiziell eine Umbenennung von „Code Mode“ in „PTC Mode“ bestätigt, nicht jedoch ein nachgewiesener Umbau der Fähigkeiten, Berechtigungen oder des Ausführungsprotokolls. Ihre Empfehlung für diese Woche: Prüfen Sie nach dem Wechsel auf v0.1.0-rc.7 die sichtbare Preset-Bezeichnung, gespeicherte Konfigurationsverweise und interne Dokumentation. Nur wegen des neuen Namens müssen Sie Ihre Bereitstellung nicht neu aufsetzen.

Dieser Beitrag richtet sich an Entwickler, die noch mit dem alten Code Mode arbeiten und Konfigurationsfehler nach dem Update vermeiden wollen. Ebenso relevant ist er für Plugin-Autoren, Teamverantwortliche und Plattformbetreiber, die entscheiden müssen, ob PTC Mode eine eigene Test- oder Laufzeitumgebung rechtfertigt.

Letzte Aktualisierung: 18.08.2026. Die Angaben wurden anhand des offiziellen Repository-Tags dsh-v0.1.0-rc.7, der aktuellen Architektur- und Konfigurationsdokumentation sowie der veröffentlichten Cordis-Dokumentation geprüft.

01

Die belastbare Aussage zu PTC Mode

Der offizielle Stand für v0.1.0-rc.7 lässt sich auf einen Satz reduzieren: Das englische integrierte Preset wurde von Code Mode in PTC Mode umbenannt. Der Release-Tag dsh-v0.1.0-rc.7 wurde am 17.08.2026 veröffentlicht. (github.com)

Daraus folgt aber nicht automatisch, dass sich die folgenden Bereiche verändert haben:

Prüfbereich Aktuell bestätigte Aussage Was daraus noch nicht folgt
Preset-Name „Code Mode“ wurde als englische Bezeichnung durch „PTC Mode“ ersetzt Kein Beleg für eine neue Ausführungslogik
Plugin-Struktur DeepSeek Harness verwendet weiterhin eine Plugin-basierte Architektur Kein Beleg für neue Standard-Plugins
Berechtigungen Keine offizielle Änderungsbeschreibung zur Umbenennung gefunden Keine Aussage über neue oder entfernte Rechte
Ressourcenbedarf Keine bestätigte Änderung der Laufzeit- oder Speicheranforderungen Keine Grundlage für Kapazitätsausbau
Protokoll Keine bestätigte Migration auf ein neues Ausführungsprotokoll Keine automatische Annahme von API-Inkompatibilität

Das ist bei einer Developer-Preview besonders wichtig. Das offizielle Repository weist ausdrücklich darauf hin, dass sich DeepSeek Harness schnell weiterentwickelt und kompatibilitätsbrechende Änderungen möglich sind. Diese allgemeine Warnung ist jedoch nicht gleichbedeutend mit einer bestätigten Änderung durch genau diese Umbenennung. (github.com)

Was bedeutet PTC in diesem Zusammenhang?

PTC steht in der Agentenentwicklung üblicherweise für „Programmatic Tool Calling“. Der Begriff beschreibt ein Muster, bei dem ein Modell mehrere Werkzeuge über ein erzeugtes Programm oder eine Skriptstruktur zusammenführt, anstatt jeden einzelnen Werkzeugaufruf als separaten Modellschritt anzufordern.

Für DeepSeek Harness sollten Sie diese Bedeutung derzeit vorsichtig verwenden. Die offizielle Dokumentation bestätigt die Preset-Umbenennung, aber daraus ergibt sich noch keine vollständige, normative Definition von PTC Mode als eigenständigem Protokoll. Bezeichnen Sie PTC Mode deshalb intern zunächst als integriertes Preset innerhalb von DeepSeek Harness, nicht als separates Produkt oder garantiert neuen Standard.

Die aktuelle Architektur beschreibt Profile als benannte Zusammenstellungen von Bundles und Plugins. Außerdem kann eine laufende Instanz durch geordnete Konfigurationsschichten zusammengesetzt werden. (github.com)

Begriff Technische Einordnung Relevanz für Ihre Entscheidung
Preset Benannte Kombination aus Konfiguration und registrierten Komponenten Ein neuer Name kann zunächst nur die Auswahloberfläche betreffen
Profil Zusammensetzung mehrerer Bundles und eigener Patches Gespeicherte Profil- oder Patch-Verweise müssen geprüft werden
Bundle Verteilte Konfiguration mit den zugehörigen Plugins Änderungen können an einzelnen Schichten sichtbar werden
Plugin Austauschbare Komponente im Cordis-Kontext Plugin-Autoren müssen Namensabhängigkeiten kontrollieren
Laufzeitmodus Praktische Start- oder Ausführungsvariante Eine neue Bezeichnung beweist keine neue Berechtigungslogik
02

Bestehende Code Mode-Nutzer sollten zuerst die Namensspur prüfen

Kann die alte Code Mode-Konfiguration nach dem Update weiter funktionieren? Nach dem aktuell bestätigten Informationsstand gibt es keinen Grund, allein wegen der Umbenennung von einem Ausfall auszugehen. Eine automatische Kompatibilitätsgarantie sollten Sie in einer Developer-Preview trotzdem nicht unterstellen.

Der Unterschied liegt zwischen einer sichtbaren Bezeichnung und einem internen Konfigurationsschlüssel. In einer einfachen Benutzeroberfläche kann nur der angezeigte Text geändert worden sein. Ein Plugin, ein Shell-Skript oder eine Teamdokumentation kann dagegen weiterhin nach dem alten Namen suchen. Umgekehrt kann ein interner Schlüssel bereits geändert worden sein, während eine Übergangsoberfläche noch beide Begriffe darstellt.

Prüfen Sie deshalb nicht nur, ob das Preset im Menü erscheint. Kontrollieren Sie auch:

  1. die gespeicherte Profildefinition;
  2. eigene cordis.patch.yml-Dateien;
  3. Startparameter und Umgebungsvariablen;
  4. Plugin-Dokumentation und Einstellungsseiten;
  5. automatisierte Tests, die einen Preset-Namen als Zeichenkette erwarten.

Die Architektur-Dokumentation nennt dsh --profile web --dump-config als Möglichkeit, den tatsächlich gestarteten Konfigurationsbaum auszugeben. Dieser Schritt ist aussagekräftiger als ein Screenshot der Oberfläche, weil er zeigt, welche Konfigurationszeilen beim Start tatsächlich geladen werden. (github.com)

Prüfschritt Erwartetes Ergebnis Maßnahme bei Abweichung
Preset-Liste öffnen PTC Mode ist sichtbar Screenshot und Versionsstand dokumentieren
Konfiguration ausgeben Das erwartete Profil wird geladen Profil- und Patch-Dateien vergleichen
Altes Suchmuster ausführen Keine kritische Abhängigkeit von Code Mode bleibt unbemerkt Treffer einzeln bewerten
Standardaufgabe starten Bestehender Workflow läuft durch Ergebnis mit vorherigem Lauf vergleichen
Berechtigungsprüfung ausführen Werkzeuge und Freigaben entsprechen dem bisherigen Stand Nicht automatisch erweitern, sondern Ursache untersuchen
03

Plugin-Autoren müssen harte Namensabhängigkeiten ausschließen

Für Plugin-Autoren ist die Umbenennung potenziell relevanter als für reine Anwender. Ein Plugin kann den Namen an mehreren Stellen verwenden, ohne dass dies auf den ersten Blick auffällt:

  • in einer Preset- oder Bundle-Erkennung;
  • in einer Einstellungs-Karte;
  • in einer Hilfeseite;
  • in Test-Fixtures;
  • in Installationsskripten;
  • in Telemetrie- oder Diagnoseausgaben;
  • in einer Kompatibilitätsprüfung beim Start.

Die offizielle Architektur beschreibt DeepSeek Harness als System, in dem unter anderem Modelladapter, Werkzeugregister, Sitzungsprotokoll und Agentenschleife als Plugins organisiert sind. Cordis stellt dafür den gemeinsamen Kontext, typisierte Ereignisse und reversible Effekte bereit. (github.com)

Das bedeutet für Ihre Prüfung: Suchen Sie nach der Zeichenkette Code Mode, aber interpretieren Sie jeden Treffer einzeln. Ein Treffer in einer Dokumentation ist ein redaktionelles Problem. Ein Treffer in einer harten Vergleichsbedingung kann ein Laufzeitproblem sein. Ein Treffer in einem Kompatibilitätsalias ist nur dann sicher, wenn die aktuelle Version diesen Alias tatsächlich unterstützt.

Sollten Sie vorsorglich beide Namen als gültig behandeln? Nein, nicht ohne Beleg. Ein selbst erfundener Alias kann Fehler verdecken und später die Fehlersuche erschweren. Verwenden Sie stattdessen eine dokumentierte Übergangszuordnung:

Fundstelle Empfohlene Behandlung
Benutzeroberfläche Neue Bezeichnung „PTC Mode“ übernehmen
Interne Migrationsnotiz „PTC Mode, früher Code Mode“ vermerken
Harte Konfigurationsprüfung Nur den tatsächlich dokumentierten Schlüssel verwenden
Plugin-Hilfe Neue Bezeichnung verwenden und Versionsbezug ergänzen
Alte Testdaten Historischen Namen als Testkontext behalten, nicht als aktuelle Empfehlung

Ein sicherer Testablauf besteht aus einem frischen Profil, einem bestehenden Profil und einem Profil mit eigener Patch-Datei. Führen Sie in allen drei Fällen dieselbe kleine Aufgabe aus. Prüfen Sie nicht nur das Endergebnis. Zeichnen Sie auch die geladenen Plugins, Werkzeugfreigaben, Rückfragen zur Genehmigung und Fehlermeldungen auf.

04

Teamdokumentation braucht eine kontrollierte Übergangsphase

In Teams entstehen die meisten Probleme bei einer Umbenennung nicht im Kernsystem, sondern an den Übergängen zwischen Menschen und Automatisierung. Eine alte Schulungsfolie zeigt Code Mode. Das neue Web-Interface zeigt PTC Mode. Ein Übergabeskript erwartet möglicherweise einen alten Textwert. Jeder Teil kann für sich plausibel aussehen, während die Gesamtdokumentation widersprüchlich wird.

Ein typischer Fall: Ein Entwickler aktualisiert die Installation auf v0.1.0-rc.7, findet das neue Preset und hält es für eine neue Betriebsart. Der Plattformverantwortliche startet dagegen weiterhin das alte Profil aus einem Skript. Beide berichten anschließend von unterschiedlichen Ergebnissen, obwohl sie vermutlich dieselbe Preset-Familie verwenden.

Für die Übergabe ist folgende Reihenfolge risikoarm:

  1. Versionsstand festhalten: Notieren Sie exakt, ob dsh-v0.1.0-rc.7 oder eine andere Revision eingesetzt wird.
  2. Namenszuordnung ergänzen: Schreiben Sie in die interne Anleitung, dass PTC Mode nach aktuellem Stand die neue englische Bezeichnung des bisherigen Code Mode-Presets ist.
  3. Screenshots ersetzen: Aktualisieren Sie nur die sichtbaren Oberflächenbilder, nicht automatisch sämtliche Betriebsannahmen.
  4. Automatisierung prüfen: Suchen Sie nach alten Zeichenketten in Shell-Skripten, CI/CD-Jobs und Konfigurationsprüfungen.
  5. Stabilen Release abwarten: Vereinheitlichen Sie die Terminologie vollständig, sobald eine stabile Dokumentation oder eine ausdrückliche Migrationsanweisung vorliegt.

Diese Übergangsregel verhindert zwei gegensätzliche Fehler: Sie lassen alte Begriffe nicht unkommentiert weiterlaufen, und Sie behaupten zugleich keine technische Änderung, die offiziell noch nicht beschrieben wurde. Für die konkrete Versionsprüfung können Sie außerdem die VpsMesh-Übersicht als ergänzende Ressource für die Dokumentation Ihrer Remote-Umgebung hinterlegen.

05

Plattformverantwortliche sollten nicht wegen des Namens aufrüsten

Braucht PTC Mode eine eigene Laufzeitumgebung? Nur die Umbenennung liefert dafür keine ausreichende Begründung. Sie benötigen zunächst keinen zusätzlichen Rechner, keine höhere Speicherkapazität und keinen separaten Bereitstellungszweig, solange sich die Aufgaben, Berechtigungen und Ausführungsdauer nicht nachweisbar ändern.

Das offizielle Repository beschreibt DeepSeek Harness weiterhin als Developer Preview und dokumentiert eine konfigurationsgetriebene Plugin-Struktur. Die Architektur sieht Profile, Bundles und Patches als Schichten vor. Daraus folgt: Eine Umgebung sollte nach dem tatsächlich geladenen Plugin-Baum und dem gemessenen Arbeitslastprofil bewertet werden, nicht nach dem Namen eines Presets. (github.com)

Achten Sie bei einer Kapazitätsentscheidung auf vier konkrete Auslöser:

  • neue Standard-Plugins werden automatisch geladen;
  • zusätzliche Werkzeugaufrufe erhöhen die Laufzeit deutlich;
  • Berechtigungsprüfungen oder Genehmigungsschritte ändern sich;
  • Sitzungen laufen länger oder parallel anders als zuvor.

Ohne einen solchen Befund wäre ein Umzug auf eine größere Umgebung reine Vorwegnahme. Das kann zusätzliche Mietkosten, neue Zugriffspfade und weitere Datenschutzprüfungen verursachen. Gerade bei Remote-Installationen sollten Sie außerdem prüfen, ob Protokolle, Zugangsdaten und Sitzungsdaten weiterhin innerhalb Ihrer DSGVO-Vorgaben verarbeitet werden.

Wenn Sie eine kurzfristige Testumgebung benötigen, kann ein gemieteter Mac sinnvoller sein als der sofortige Kauf eigener Hardware: Sie vermeiden eine dauerhafte Bindung, können einen reproduzierbaren Installationsstand testen und die Umgebung nach der Validierung wieder freigeben. Vergleichen Sie dabei die Gesamtkosten der Mietdauer mit einem Hardwarekauf und berücksichtigen Sie zusätzlich Zugriffsschutz, Datenlöschung und die Anforderungen Ihrer Testumgebung. Die Mac-Mietpreise von VpsMesh können dabei als Kostenreferenz dienen; sie ersetzen jedoch keine technische Prüfung der tatsächlichen Arbeitslast.

06

Diese Signale lösen eine neue technische Bewertung aus

Die Einstufung „nur Umbenennung“ gilt nicht unbegrenzt. Sie sollten Ihre Entscheidung neu bewerten, sobald die offiziellen Unterlagen eine der folgenden Änderungen enthalten:

Signal in Release oder Dokumentation Warum es wichtig ist Konsequenz
PTC Mode erhält eine eigene technische Definition Der Name wäre dann mehr als eine Oberflächenänderung Ablauf und Ergebnisse neu testen
Standard-Plugin-Bundle wird ausdrücklich geändert Werkzeugbestand und Verhalten können abweichen Plugin- und Berechtigungsprüfung durchführen
Neue Konfigurationsschlüssel erscheinen Alte Profile könnten nicht mehr vollständig greifen Migration oder Übergangsalias prüfen
Rechte- oder Freigabemodell wird geändert Sicherheitsgrenzen können anders verlaufen Neue Abnahme durch Verantwortliche
Explizite Migrationsanweisung wird veröffentlicht Die Umbenennung hätte dokumentierte Folgewirkungen Vorgaben vollständig umsetzen
Benchmark- oder Laufzeitdaten ändern sich Ressourcenplanung wäre betroffen Kapazität und Kosten neu kalkulieren

Bis zu einem dieser Signale können Sie mit drei Handlungsstufen arbeiten:

  • Weiterverwenden: Sichtbarer Name geändert, Konfiguration und Aufgaben unverändert.
  • Lokal überarbeiten: Dokumentation, Screenshots, Plugin-Hinweise oder Skripte enthalten noch Code Mode.
  • Neu abnehmen: Offizielle Definition, Plugin-Bundle, Berechtigungen oder Konfigurationsschema wurden geändert.

Für Versionswechsel mit möglicher Rückkehr zum vorherigen Stand ist eine dokumentierte Sicherung wichtiger als ein spontaner Neuaufbau. Nutzen Sie dafür eine klare Trennung aus Version, Profil, Patch-Datei und Testergebnis. Ergänzen Sie in Ihrer internen Betriebsdokumentation außerdem eine Anleitung zum Upgrade und Rollback von DeepSeek Harness sowie eine Erklärung der verwendeten Laufzeitmodi.

07

Checkliste für die Prüfung in dieser Woche

  • [ ] Installierte Version exakt als v0.1.0-rc.7 oder abweichenden Stand dokumentieren.
  • [ ] Sichtbaren Preset-Namen im Interface prüfen.
  • [ ] Bestehende Profil- und Patch-Dateien sichern.
  • [ ] Nach Code Mode in Konfiguration, Plugins, Skripten und Handbüchern suchen.
  • [ ] Den tatsächlich geladenen Baum mit dsh --profile web --dump-config kontrollieren.
  • [ ] Eine vorhandene Standardaufgabe mit dem bisherigen Referenzergebnis vergleichen.
  • [ ] Werkzeugliste und Genehmigungsgrenzen prüfen.
  • [ ] Keine neuen Berechtigungen nur wegen des Namens vergeben.
  • [ ] Keine zusätzliche Laufzeitumgebung bestellen, bevor ein technischer Unterschied gemessen wurde.
  • [ ] Bei neuen offiziellen Definitionen oder Migrationshinweisen eine erneute Abnahme einplanen.

Der Vergleich mit Ihrer bisherigen Lösung sollte nüchtern bleiben. Eine lokale Windows- oder Linux-Umgebung kann bei der langfristigen Dauerlast günstiger sein, bindet aber Hardware, Wartung und Sicherheitsverantwortung dauerhaft. Eine allgemeine Cloud-Instanz bringt oft zusätzliche Netzwerk-, Zugriffs- und Datenschutzfragen mit sich. Ein lokaler Entwicklungsrechner ist dagegen nicht automatisch für unbeaufsichtigte, reproduzierbare Remote-Sitzungen ausgelegt.

Für einen kurzen Versionsvergleich, einen Plugin-Test oder eine getrennte Abnahme kann die Miete eines Mac über VpsMesh deshalb praktischer sein als ein sofortiger Hardwarekauf. Sie sollten dennoch nicht mieten, wenn Sie über lange Zeit konstant hohe Last benötigen oder zwingend physische Schnittstellen und lokale Peripherie voraussetzen. Entscheidend ist zuerst, ob PTC Mode technisch etwas verändert. Nach dem derzeit bestätigten Stand verändert sich zunächst nur der englische Preset-Name. Prüfen Sie deshalb Ihre bestehende Konfiguration, aktualisieren Sie die Übergangsdokumentation und passen Sie die Remote-Umgebung erst an, wenn offizielle Unterlagen oder reproduzierbare Tests einen echten Unterschied zeigen.