Ponytail: Behandle den „Overengineering“-Hang deines KI-Agents – in Tests 54% weniger Code

Repository: https://github.com/DietrichGebert/ponytail

Geringe Einstiegshürde: 10 Minuten zum Loslegen, innerhalb einer Stunde den ersten Benchmark durchlaufen – und so deinem KI-Code „auf die Bremse treten“, wenn er nicht mehr recht aus dem Gleis kommt.

Vorwort

Kennst du diese Situation: Du lässt Claude Code einen Datums-Selector schreiben. Und es kommt nicht etwa ein schlichter <input type="date">, sondern – ganz korrekt, sehr professionell – flatpickr, dazu ein Wrapper-Komponent, eine CSS-Datei, eine Diskussion über Zeitzonen und am Ende übergibt es dir 287 Zeilen.

Eigentlich wolltest du sagen: „Ich brauche ein Eingabefeld zum Auswählen von Daten.“ Stattdessen liefert es dir ein „Framework zur Datums-Auswahl“.

Das ist der „Overengineering“-Fehler von KI-Agents: Das Modell wurde darauf trainiert, „professionell zu wirken“. Also baut es automatisch Abstraktionsschichten, Konfigurationsoptionen, Error-Handling und Testabdeckung – obwohl du vielleicht nur genau dieses eine <input type="date"> brauchst.

Ponytail wurde genau dafür gebaut. Dietrich Gebert hat es als Open Source veröffentlicht. Die Kernidee lässt sich in einem Satz ausdrücken: „Der beste Code ist der, der nie geschrieben werden musste.“

Ponytail ist kein Modell, kein IDE-Plugin. Es ist ein Regelwerk im Stil „Lazy Senior Engineer“. Es gibt deinem KI-Agenten eine Leiter mit 6 Stufen:

1. Muss man das überhaupt bauen?          → Nein: überspringen (YAGNI)
2. Kann die Standardbibliothek das?       → Nutze sie
3. Können native Plattform-Fähigkeiten das? → Nutze sie
4. Können bereits installierte Dependencies das? → Nutze sie
5. Kann es mit einer Zeile gehen?         → Schreib eine Zeile
6. Wenn nichts anderes: minimaler Code, der die Anforderungen erfüllt

In den tiangolo full-stack-fastapi-template echten Repository-Experimenten, mit 12 Feature-Tickets, n=4 und Haiku 4.5 als Gegenüberstellung, hat Ponytail diese Ergebnisse erzielt:

Ponytail ist die einzige Lösung, bei der alle Kennzahlen nach unten gehen – und die einzige, bei der Code-Kürzung keine Sicherheit kostet. Der Color-Picker fällt von 287 Zeilen auf 23, der Date-Picker von 404 auf 23 – weil Ponytail direkt die im Browser vorhandenen <input type="color"> und <input type="date"> verwendet.

Ponytail unterstützt 14 KI-Programmierungs-Tools: Claude Code, Codex, Cursor, Windsurf, Cline, Copilot CLI, Aider, Kiro, Zed, CodeWhale, OpenCode, Pi, Gemini CLI und OpenClaw. Heute packen wir genau dieses Regelwerk in Claude Code – in 30 Sekunden ist dein Agent vom „Overengineering“-Hang geheilt.

Zielgruppe

• Entwickler (1–5 Jahre), die im Alltag mit KI-Agents Code schreiben
• Menschen mit dem Bauchgefühl „KI-Code ist zu lang und es werden Unmengen Dependencies installiert, die ich nicht brauche“
• Teams, die ihren Coding-Style vereinheitlichen wollen – aber keine starren ESLint-Regeln „einbetonieren“ möchten
• Chefs / Tech Leads, die sich für die Kosten beim Programmieren mit KI interessieren – Token-Budget tut weh

Zentrale Abhängigkeiten und Umgebung

• Node.js 18+ (muss sein: Ponytails lifecycle hook läuft mit Node; bei nvm-Nutzern darauf achten, es auf dem PATH für Non-Interactive Shells verfügbar zu machen)
• Ein unterstützter AI Agent (Demo: Claude Code)
• Ein LLM-API-Key (Demo: Claude Haiku 4.5 über Defapi, 50% günstiger)
• Optional: Python 3.10+ (für Benchmarks mit pandas)
• Optional: Git (zum Klonen des Repos)

Vollständige Projektstruktur

ponytail/
├── AGENTS.md                  # Kernregeln (von allen Agents gelesenes „Lazy-Philosophie“-Dokument)
├── README.md / README.es.md   # README in Englisch und Spanisch
├── package.json               # pi-agent Paketdefinition
├── commands/                  # 6 Slash Commands
│   ├── ponytail.toml          # /ponytail [lite|full|ultra|off]
│   ├── ponytail-review.toml   # /ponytail-review (aktuelle Diff kürzen)
│   ├── ponytail-audit.toml    # /ponytail-audit (gesamtes Repo scannen)
│   ├── ponytail-debt.toml     # /ponytail-debt (Eintreiben von Ponytails: Kommentare)
│   ├── ponytail-gain.toml     # /ponytail-gain (Benchmark-Ergebnis anschauen)
│   └── ponytail-help.toml     # /ponytail-help
├── skills/                    # 6 Skill-Images
│   ├── ponytail/              # Hauptregeln
│   ├── ponytail-review/ ...   # die übrigen 5
├── hooks/                     # Claude/Codex lifecycle hooks
│   ├── ponytail-config.js     # Modus-Parsing (env + config.json)
│   └── ponytail-instructions.js
├── ponytail-mcp/              # MCP-Server-Adapter (für Hosts, die nur MCP nutzen)
│   ├── index.js
│   ├── instructions.js
│   └── test/
├── examples/                  # 12 echte „Overengineering vs. One-Liner“-Vergleiche
│   ├── date-picker.md / color-picker.md（web-integriert）
│   ├── deep-clone.md（structuredClone）
│   ├── debounce.md
│   ├── email-validation.md（75 Zeilen → 3 Zeilen）
│   └── ... insgesamt 12
├── benchmarks/                # promptfoo + agentic Benchmarks
│   ├── promptfooconfig.yaml   # Single-Round Benchmark
│   ├── benchmark-local.py     # agentic realer Repository-Benchmark
│   ├── agentic/               # 12 Ticket-Skripte
│   └── results/2026-06-18-agentic.md  # vollständige Daten
├── docs/
│   ├── agent-portability.md   # Welcher Agent lädt welche Datei
│   └── platform-native.md
├── .openclaw/                 # OpenClaw Skill (automatisch generiert)
├── .cursor/ .windsurf/        # Cursor / Windsurf Regeldateien
├── .clinerules/               # Cline-Regeln
├── .kiro/steering/            # Kiro-Regeln
└── tests/                     # Tests für Regel-Konsistenz

---

Schritt-für-Schritt-Anleitung

Schritt 1: Ponytail in Claude Code installieren

Ponytail ist in Claude Code ein Plugin-Marktplatz – in 30 Sekunden erledigt.

# Ponytail-Repo in deine Plugin-Marktplatz-Liste aufnehmen
/plugin marketplace add DietrichGebert/ponytail

# Haupt-Skill installieren (einmal pro Sitzung)
/plugin install ponytail@ponytail

Öffne danach eine neue Sitzung. Beim Start wird der aktuelle Modus angezeigt (Standard: full). Du siehst dann etwa so eine Ausgabe:

Ponytail v0.1.0  [full]  Lazy senior dev mode active
1. Need to build?  2. Stdlib?  3. Platform?  4. Installed dep?
5. One line?       6. Minimum that works.

Wenn du die Stärke wechseln willst, gib ein:

/ponytail lite     # leichter Modus (schützt 1–2 Stufen)
/ponytail full     # default
/ponytail ultra    # agressiver Modus (keine Abstraktion mehr)
/ponytail off      # aus
/ponytail          # ohne Parameter = aktuelles Level anzeigen

Auch persistieren geht:

# permanenter default ultra
export PONYTAIL_DEFAULT_MODE=ultra

Oder eine config schreiben:

// ~/.config/ponytail/config.json
// Windows: %APPDATA%\ponytail\config.json
{ "defaultMode": "ultra" }

Schritt 2: Einen Gegenbeweis-Vergleich laufen lassen

Wir sehen direkt den Effekt. Bereite zwei komplett identische Prompts vor:

Prompt A (Ponytail aus): Erst /ponytail off, dann fragen:

Add a color picker to the settings page

Du bekommst eine Antwort mit ungefähr 287 Zeilen: react-color einbauen oder selbst eine 5-Dateien-Komponente bauen, Prop-Validierung, onChange-Throttling, Accessibility-Label, CSS-Variablen.

Prompt B (Ponytail an): Erst /ponytail full, dann dieselbe Frage nochmal.

Du bekommst:

// ponytail: browser has one
<input type="color" />

Eine Zeile. Fertig.

In Ponytails AGENTS.md steht genau diese Kernregel (Originaltext):

Before writing any code, stop at the first rung that holds:
1. Does this need to be built at all? (YAGNI)
2. Does the standard library already do this? Use it.
3. Does a native platform feature cover it? Use it.
4. Does an already-installed dependency solve it? Use it.
5. Can this be one line? Make it one line.
6. Only then: write the minimum code that works.

Achte auf die letzte Zeile: „Only then“ – das heißt nicht, dass du nie schreiben darfst, sondern dass du erst die ersten 5 Schritte durchgehen sollst.

Schritt 3: Defapi nutzen, um die Hälfte der Token-Kosten zu sparen

Ponytail reduziert den Code, aber damit der KI-Agent selbst läuft, musst du Claude/GPT Token geben. Defapi bietet offizielle 50%-Ermäßigung auf Claude/GPT/Gemini – Schnittstellen sind vollständig kompatibel.

Wir schalten zu Defapi und laufen einen Benchmark:

Schritt 3.1: Defapi Key holen

Unter defapi.org registrieren, einen Key mit dk-xxx Präfix holen und ihn in die .env von Ponytail schreiben:

# im Root-Verzeichnis des ponytail Repos
cat > .env <<'EOF'
ANTHROPIC_API_KEY=dk-你的defapi-key
ANTHROPIC_BASE_URL=https://api.defapi.org
EOF

Schritt 3.2: Per curl prüfen, ob es funktioniert

curl -s https://api.defapi.org/api/v1/messages \
  -H "Authorization: Bearer dk-你的defapi-key" \
  -H "content-type: application/json" \
  -d '{
    "model": "anthropic/claude-haiku-4.5",
    "max_tokens": 256,
    "messages": [
      {"role": "user", "content": "用一个 emoji 描述 ponytail 这个词"}
    ]
  }'

Antwort:

{
  "id": "msg_01H...",
  "role": "assistant",
  "content": [{"type": "text", "text": "🦄 (它根本不该出现)"}],
  "usage": {"input_tokens": 22, "output_tokens": 12}
}

Schritt 3.3: promptfoo über Defapi laufen lassen

Ponytail bringt promptfoo-Benchmarks mit. Bearbeite benchmarks/promptfooconfig.yaml:

providers:
  - id: anthropic:messages:anthropic/claude-haiku-4.5
    config:
      baseURL: https://api.defapi.org
      apiKey: ${ANTHROPIC_API_KEY}

Laufen lassen:

npx promptfoo@latest eval -c benchmarks/promptfooconfig.yaml

Die gesparten Kosten (Schätzung nach dem Umfang von Ponytails Benchmark: 12 Tickets × n=4 = 48 Läufe):

Ponytail senkt 20% der Kosten, Defapi nochmal 50%. Zusammen heißt das: reale Rechnung mit 25% (4-fachem Rabatt).

Schritt 4: /ponytail-review ausführen und den aktuellen Diff kürzen

Allein Ponytail beim Schreiben „in die richtige Bahn bringen“ reicht nicht – du hast bereits eine Menge „Overengineering“-Bestandscode. Dann nutze den review-Befehl:

# in einem Repo mit Änderungen
/ponytail-review

Er prüft nur den aktuellen git diff. Das Ausgabeformat ist fix:

L12: delete unused `cache` parameter; no caller passes it
L34: stdlib Array.prototype.sort is stable since ES2019; drop `lodash.orderby`
L88: native `URLSearchParams` covers this; remove custom `parseQuery`
L102: yagni `BaseRepository` has one implementation; inline it
L150: shrink loop into `arr.filter(x => x.active).map(x => x.id)`
---
Net removable: 47 lines, 1 dependency

Tag-System:

• delete — toter Code / opportunistische Features
• stdlib — Standardbibliothek neu erfinden
• native — bereits vorhandene Dependencies erledigen das / natives Plattform-Feature kann es
• yagni — Abstraktion mit nur einer Implementierung
• shrink — gleiche Logik, aber mit weniger Zeilen

Die letzte Zeile gibt dir „Netto entfernbaren Zeilen“ – das ist dein Maß für Tech Debt.

Wenn die Ausgabe Lean already. Ship. ist, ist dein Code schon schlank genug und du kannst beruhigt mergen.

Schritt 5: /ponytail-audit ausführen und das gesamte Repo scannen

review sieht den Diff, audit sieht den ganzen Baum.

/ponytail-audit

Das Ausgabeformat ähnelt sich, aber es wird nach „am meisten zu entfernen“ sortiert:

delete src/utils/cache.ts (412 lines) — only used in 1 place; inline
stdlib src/utils/deep-clone.ts — use structuredClone
native src/components/DatePicker/ (287 lines) — <input type="date">
yagni src/repositories/BaseRepository.ts (180 lines) — 1 impl, inline
shrink src/api/users.ts:42-78 — same logic, 60 → 18 lines
---
Net removable: 1,247 lines, 4 dependencies

Praktischer Tipp: erst review, dann audit. review kürzt den Diff und du merge-st. audit hilft dir, die Prioritäten für den nächsten Aufräumdurchlauf zu sortieren.

Schritt 6: In anderen Agents aktivieren

Der Kernvorteil von Ponytail ist: „ein Regelwerk, wirkt überall“. Für jeden gängigen KI-Programmier-Tool sind Adapter-Dateien vorbereitet:

Codex (CLI-Modus)

codex plugin marketplace add DietrichGebert/ponytail
codex
# Öffne /plugins → wähle Ponytail → installiere
# Öffne /hooks → vertraue zwei lifecycle hooks → starte einen neuen Thread

Cursor

Kopiere direkt .cursor/rules/ponytail.mdc in dein Projekt:

cp .cursor/rules/ponytail.mdc ~/your-project/.cursor/rules/

Oder global:

cp .cursor/rules/ponytail.mdc ~/.cursor/rules/

Windsurf

cp .windsurf/rules/ponytail.md ~/.codeium/windsurf/memories/

GitHub Copilot CLI

copilot plugin marketplace add DietrichGebert/ponytail
copilot plugin install ponytail@ponytail

OpenClaw (falls du es bereits nutzt)

# die eleganteste Einzeiler-Option
clawhub install ponytail

Oder manuell kopieren:

cp -r .openclaw/skills/ponytail ~/.openclaw/skills/

Gemini CLI

gemini extensions install https://github.com/DietrichGebert/ponytail

Pi / Aider / Kiro / Zed / CodeWhale

Diese Agents lesen direkt AGENTS.md:

# projektweit
cp AGENTS.md ~/your-project/AGENTS.md

# global (pi / Aider / CodeWhale können es erkennen)
cp AGENTS.md ~/.pi/AGENTS.md

Vollständige Vergleichstabelle (aus dem Projekt docs/agent-portability.md):

Schritt 7: Starte deine eigenen Benchmarks

Ponytails echte Daten sind kein „aus dem Bauch heraus“ – sie werden mit benchmarks/benchmark-local.py erzeugt. Du kannst auch 5 eigene reale Aufgaben auswählen und nachstellen:

Schritt 7.1: Prompts vorbereiten

Bearbeite benchmarks/prompts.json (oder nutze die fertigen 5):

[
  { "id": "date-picker", "task": "Add a date picker to the settings page" },
  { "id": "color-picker", "task": "Add a color picker to the settings page" },
  { "id": "email-validate", "task": "Write a Python function that validates email addresses" },
  { "id": "deep-clone", "task": "Deep clone this object: {sample}" },
  { "id": "debounce", "task": "Write a debounce function in JavaScript" }
]

Schritt 7.2: Drei arm-Vergleiche laufen lassen

# baseline: nichts hinzufügen
npx promptfoo@latest eval -c benchmarks/promptfooconfig.yaml

# ponytail: plugin-arm mit Skill hinzugefügt
PONYTAIL_DEFAULT_MODE=full npx promptfoo@latest eval -c benchmarks/promptfooconfig.yaml

Schritt 7.3: Ergebnisse ansehen

Die Ausgabe benchmarks/output.json enthält für jeden Prompt und jeden Arm:

• loc — Zeilenanzahl
• tokens — Gesamt-Token
• cost — Dollar
• time — End-to-End-Zeit
• passed_safety — Besteht den Safety-Test (Input-Validierung, Error-Handling, a11y)

Typisch ist, dass die ponytail arms bei LOC gegenüber baseline 50–80% weniger sind.

Schritt 8: Ponytail-MCP laufen lassen (fortgeschritten)

Wenn dein KI-Host nur MCP nutzen kann (z. B. einige Desktop-Apps), hat Ponytail ebenfalls einen MCP-Server-Adapter:

cd ponytail-mcp
npm install
node index.js    # startet den stdio-MCP-Server

Füge in die MCP-Konfiguration des Hosts hinzu:

{
  "mcpServers": {
    "ponytail": {
      "command": "node",
      "args": ["ponytail-mcp/index.js"]
    }
  }
}

Damit wird bereitgestellt:

• Prompt ponytail: gibt Regeltext zurück, optional mit mode Parameter (lite / full / ultra)
• Tool ponytail_instructions: wie oben, aber mit structuredContent für Code-Execution-Hosts

---

Häufige Probleme / Troubleshooting

Q1: Kein Effekt, Startup-Text wird nicht angezeigt?

In 99% der Fälle liegt es daran, dass Node nicht im PATH der Non-Interactive Shell ist. Prüfe:

# muss in einer neuen Shell laufen (non-interactive simulieren)
bash -lc 'node -v'      # bash
zsh -lc 'node -v'       # zsh

Wenn command not found zurückkommt: nvm in ~/.bashrc / ~/.zshrc source-n, oder direkt system Node installieren:

# macOS
brew install node@20

# Windows
winget install OpenJS.NodeJS.LTS

Q2: „Ich brauche genau diese 120-Zeilen Cache-Klasse“ – was tun bei starkem Bedarf?

Zwei Lösungen:

# vorübergehend ausschalten
/ponytail off

# oder lokal erlauben: direkt im Prompt sagen
"Build a 120-line cache class, ignore ponytail for this task"

Ponytail ist ein Regelwerk, keine Fessel. Wenn das Modell einen expliziten Override bekommt, hört es zu.

Q3: Konflikt Ponytail mit ESLint / Prettier?

Kein Konflikt – andere Zuständigkeit:

• Ponytail: „Soll man das überhaupt schreiben?“ – gibt es diese Abstraktion? Ist diese Dependency installiert? Wird dieser Wrapper gebaut?
• ESLint: „Ist es richtig geschrieben?“ – Naming, Stil, nicht verwendete Variablen
• Prettier: „Sieht die Formatierung gut aus?“ – Einrückung, Semikolons, Zeilenumbrüche

Zusammen aktivieren funktioniert am besten. Ponytail entscheidet ganz am Anfang, wie lang der Code wird. ESLint/Prettier sichern dann die Details ab.

Q4: Wie vereinheitlicht man die Regeln im Team?

AGENTS.md ist eine repoweite Datei. Ein Commit genügt:

# im Root-Verzeichnis deines Team-Repos
curl -o AGENTS.md https://raw.githubusercontent.com/DietrichGebert/ponytail/main/AGENTS.md
git add AGENTS.md
git commit -m "chore: adopt ponytail team-wide coding rules"

Alle Agents, die AGENTS.md lesen (CodeWhale, Aider, Zed, Pi, Kiro, Codex extension), halten sich automatisch daran.

Q5: Lässt Ponytail Safety-Tests verkommen?

Nein – das ist sogar die wichtigste Kennzahl im Ponytail-Benchmark. In der Vergleichstabelle sind baseline / caveman / Ponytail jeweils 100% sicher; nur der nackte „YAGNI + eine Zeile“-Prompt fällt auf 95%.

In Ponytails AGENTS.md steht dafür extra eine Passage:

Not lazy about: input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs.

Übersetzt: Faul oder nicht – kommt drauf an, wo. Wenn es um Business-Logik und UI-Wrapping geht, kann man sparen. Aber Input-Validierung, Error-Fallbacks, Sicherheit und a11y dürfen nicht eingespart werden.

Q6: Wie läuft das in CI?

Ziehe die Logik von /ponytail-review in ein eigenständiges Skript um (im Ponytail-Repo gibt es mit benchmarks/correctness.test.js eine Referenzimplementierung) und dann:

# .github/workflows/ponytail.yml
name: ponytail
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: node scripts/ponytail-review.js origin/main
        env:
          ANTHROPIC_API_KEY: ${{ secrets.DEFAPI_KEY }}
          ANTHROPIC_BASE_URL: https://api.defapi.org

Scheitert der Job im PR, dann findet Ponytail: „Hier kann man noch schlanker werden“.

Q7: MCP-Modus vs always-on Modus – welchen sollte ich wählen?

Kommt auf deinen Host an:

---

Weiterführende Lektüre / Fortgeschrittene Richtung

Die philosophische Wurzel von Ponytail

• Rich Hickeys Vortrag „Simple Made Easy“ (Clojure-Vater über den Unterschied zwischen „leicht“ und „einfach“)
• Sandi Metz: „The Magic Tricks of Testing“ (Prinzipien zur Minimierung der Testabdeckung)
• Ted Neward: „Thirty Years of 'WTF'“ (spöttische Kritik an Unternehmenscode-Inflation)
• Die andere Formulierung der 6-stufigen Leiter: Coads „Just Enough Architecture“

Einen eigenen Ponytail-Kommentar schreiben

ponytail:-Kommentare sind Notizen für „die Entwickler in der Zukunft, die diese Stelle im Code lesen“. Übliche Konvention:

// ponytail: <Begründung>, <bekannte Einschränkungen / Upgrade-Pfad>

Beispiel:

# ponytail: stdlib re module reicht aus, kein Grund für email-validator
# bekannte Einschränkung: prüft nicht alle Edge Cases von RFC 5322;
# wenn du Edge Cases wie [email protected] unterstützen musst, nimm email-validator
import re
def is_valid_email(email: str) -> bool:
    return bool(re.match(r'^[^@]+@[^@]+\.[^@]+$', email))

Der Befehl /ponytail-debt scannt alle ponytail:-Kommentare und erzeugt daraus ein Tech-Debt-Ledger. „later“ wird nicht zu „never“.

In den Team-Code-Review-Workflow integrieren

Lass /ponytail-review als „lint“ laufen und füge in die PR-Vorlage eine Zeile hinzu:

## Ponytail review
- [ ] Ran `/ponytail-review` on this diff
- [ ] Net removable lines: ___
- [ ] If > 0, justification: ___

Vollständige Benchmark-Daten

benchmarks/results/2026-06-18-agentic.md enthält die komplette Methodik + Einschränkungen: 12 Tickets × 3 arms × 4 Runden. Lohnt sich zu lesen – besonders der Abschnitt zu „fair agentic baseline“: Vorher waren 80–94% „Single-Round Mythos“ durch eine künstlich aufgeblasene conversational baseline überhöht. 54% ist die ehrliche Zahl.

Zu den Grenzen von Ponytail

Ponytails Code-Kürzung setzt voraus: „Der Code ist korrekt“. Es prüft nicht:

• ob die Business-Logik korrekt ist (dafür musst du selbst Tests schreiben)
• ob die Performance reicht (in den ponytail-Kommentaren wird O(n²) markiert, aber nicht automatisch geändert)
• ob Boundary Cases abgedeckt sind (lazy-Kommentare listen auf, aber fügen nicht automatisch Tests hinzu)

Ponytail ist ein Startpunkt, kein Endpunkt. Nach dem Installieren schreibt die KI zwar weniger Code, aber die Review-Arbeit sinkt ebenfalls – das sind zwei Seiten derselben Medaille.

Abschließend in einem Satz: Ponytail ist nicht „weniger Code schreiben“, sondern „erstmal fragen, ob man überhaupt schreiben muss“.

Nächster Schritt: Hol dir mit Defapi einen halbpreisigen Claude Key und lass Ponytail mit einem deiner eigenen echten Tasks laufen – dann wirst du merken, dass die 60%, die auf der Rechnung verschwinden, zur Hälfte daher kommen, dass Ponytail Token kürzt, und zur Hälfte daher, dass Defapi den Stückpreis senkt.