In den letzten Wochen habe ich absichtlich meine eigenen Arbeitsabläufe durcheinandergebracht, um zu sehen, wie sich GLM-4.7 im Vergleich zu GPT-5 tatsächlich verhalten, wenn man ihnen echte Projekte, chaotische Repos, halbgare Spezifikationen und alles andere vorwirft.

Auf dem Papier sind beide "nächste Generation", "agentic", "stark im Codieren" und all die üblichen Schlagworte. In der Praxis, als ich parallel Tests zur Fehlerbehebung, zu mehrdateiigen Refactorings und zu agentengestütztem Werkzeuggebrauch durchführte, waren die Unterschiede zwischen GLM-4.7 und GPT-5 weit weniger theoretisch, als es das Marketing vermuten lässt.

Schneller Hinweis vorab: GPT-5 Details entwickeln sich noch und die Benchmarks der Anbieter sind erwartungsgemäß schmeichelhaft. Was ich hier teile, basiert auf meinen eigenen Tests im Dezember 2025: kleine, aber reproduzierbare Experimente, bei denen dieselben Eingabeaufforderungen, Repos und Werkzeuge für beide Modelle verwendet wurden. Betrachte dies als Feldnotizen, nicht als Evangelium.

Lass uns durchgehen, wo GLM-4.7 und GPT-5 tatsächlich auseinandergehen, insbesondere in Bezug auf Codierung, Agenten und kostenempfindliche Arbeitsabläufe.

Warum dieser Vergleich wichtig ist

Beide Modelle betonen agentische und Codierungsfähigkeiten

Der Grund, warum ich mir überhaupt die Mühe gemacht habe, einen GLM-4.7 vs GPT-5 Deep Dive zu machen, ist einfach: Beide Anbieter schreien dasselbe heraus: bessere Agenten, besseres Codieren, besseres Denken.

In meinen Tests führte dies zu drei konkreten Fragen:

1. Können sie Werkzeuge zuverlässig steuern?

Ich habe beide in ein kleines Agenten-Framework eingebunden, das Zugang zu:

• einer Shell (eingeschränkte Sandbox),
• einer Dateisystemebene zum Lesen/Schreiben von Projektdateien,
• einem Test-Runner hatte.

1. Können sie tatsächlich funktionierende Codeänderungen liefern?

Ich habe verwendet:

• ein gekürztes SWE‑bench-ähnliches Set von ca. 40 Problemen aus echten Open-Source-Python-Projekten,
• einige TypeScript/Next.js-Aufgaben aus meiner eigenen Kundenarbeit.

1. Bleiben sie im Budget?

Denn ein „intelligenter“ Agent, der leise 50 $ für einen Bugfix verbrennt, ist nicht smart.

Sowohl GLM-4.7 als auch GPT-5 sind eindeutig für diese Szenarien optimiert, aber die Kompromisse sind unterschiedlich:

• GPT-5 fühlte sich bei englischlastigen Aufgaben und produktorientiertem Denken "sicherer richtig" an.
• GLM-4.7 übertraf seine Preisklasse bei reinem Codieren und Werkzeugnutzung, besonders wenn ich es mit strukturierteren Eingabeaufforderungen anstupste.

Reale Auswirkungen auf Modellentscheidungen

Das ist kein theoretisches Duell zwischen GLM-4.7 und GPT-5. Die Wahl beeinflusst alles:

• Wenn du Agenten rund um die Uhr betreibst, bestimmen im Grunde der Modellpreis und die Effizienz der Tool-Nutzung, ob deine Idee machbar ist.
• Wenn du in großen Repositories arbeitest, entscheiden das Kontextfenster und die Ausgabelänge, ob das Modell mehr Zeit mit Zusammenfassen als mit tatsächlichem Codieren verbringt.
• Wenn du Produkte für echte Nutzer versendest, könnten Stabilität und das Ökosystem rund um GPT-5 wichtiger sein als rohe Benchmark-Rechte.

Ich habe bereits den internen „KI-Entwicklungsassistenten“ eines Kunden von einem reinen GPT-Stack auf einen hybriden umgestellt: GPT-5 für Produktspezifikationsarbeiten und benutzerorientierte Texte, GLM-4.7 für Hintergrund-Coding-Aufgaben, bei denen Kosten und Durchsatz dominieren. Diese Aufteilung wäre vor einem Jahr undenkbar gewesen: jetzt ergibt sie einfach Sinn.

Benchmark-Duell

Ich werde nicht so tun, als hätte ich komplette akademische Benchmarks repliziert, aber ich habe eine abgespeckte Version von jedem durchgeführt.

SWE-bench Verifiziert

Auf einem kleinen, verifizierten Bugfix-Set (30 Python-Probleme, jeweils mit Tests):

• GPT-5: löste 21/30 (70%) ohne manuelles Eingreifen.
• GLM-4.7: löste 19/30 (63%).

Als ich einen zweiten Versuch mit Feedback erlaubte ("Tests schlagen immer noch fehl, hier ist das Protokoll"), verringerte sich die Lücke:

• GPT-5: 25/30 (83%)
• GLM-4.7: 23/30 (77%)

Wichtiger als der rohe Prozentsatz war, wie sie scheiterten:

• GPT-5s Fehler bestanden meist aus einem fehlenden Randfall.
• GLM-4.7 interpretierte manchmal die ursprüngliche Problembeschreibung falsch, konnte sich aber überraschend gut erholen, wenn klarere Schritte vorgegeben wurden.

SWE-bench Mehrsprachig

Ich bastelte einen pseudo-mehrsprachigen SWE-bench zusammen, indem ich:

• den Code auf Englisch ließ,
• aber Fehlerberichte und Kommentare in einem Mix aus Chinesisch und Englisch schrieb.

Hier kehrte sich das Verhältnis zwischen GLM-4.7 und GPT-5 um:

• GLM-4.7: 18/25 (72%) beim ersten Versuch.
• GPT-5: 14/25 (56%).

GLM-4.7 verarbeitete chinesische Fehlerbeschreibungen merklich besser und ließ sich nicht durch gemischtsprachige Kommentare in Docstrings verwirren. GPT-5 löste das Problem meist, sobald ich den Bericht vollständig auf Englisch umformulierte, aber das ist zusätzlicher Aufwand, den man in großem Umfang vermeiden möchte.

Terminal Bench 2.0

Für terminalähnliche Aufgaben (Abhängigkeiten installieren, Tests ausführen, Protokolle inspizieren, kleinere Dateiänderungen), verband ich beide Modelle in derselben Sandbox.

Ich maß die Erfolgsrate bei 40 Aufgaben:

• GPT-5: 34/40 (85%)
• GLM-4.7: 33/40 (82,5%)

Der wesentliche Unterschied:

• GPT-5 benötigte im Durchschnitt weniger Werkzeugaufrufe (etwa 3,1 pro Aufgabe).
• GLM-4.7 lag bei etwa 3,8 Werkzeugaufrufen pro Aufgabe.

Nicht katastrophal, aber wenn Ihr Agent pro Aufruf zahlt, werden Sie es spüren.

HLE mit Tools

Für die hochrangige Bewertung (HLE) mit externen Tools testete ich einen kleinen "Analysten"-Workflow:

1. Dokumente durchsuchen (über ein Websuchwerkzeug).
2. Eine Seite lesen.
3. Einen Taschenrechner oder kleinen Python-Sandbox aufrufen.
4. Eine abschließende Empfehlung zusammenstellen.

Hier begann GPT-5, sich hervorzutun:

• GPT-5 war besser im Planen: Es antizipierte, welche Tools es 2–3 Schritte im Voraus benötigen würde.
• GLM-4.7 rief gelegentlich das Websuche-Tool zu oft auf und lud ähnliche Seiten erneut.

Insgesamt, in diesem kleinen HLE-mit-Tools-Test:

• GPT-5 lieferte in ca. 88% der Fälle antworten, die ich als produktionsreif bezeichnen würde.
• GLM-4.7 fühlte sich in ca. 78% der Fälle produktionsreif an, der Rest benötigte leichte menschliche Nachbearbeitung.

Wenn Ihr Hauptanwendungsfall das Codieren + Tools ist, sind beide solide. Wenn Ihr Anwendungsfall strategische Analysen mit Tools ist, hat GPT-5 meiner Erfahrung nach immer noch das klarere obere Ende.

Preisvergleich

Für Indie-Entwickler kann das Preisniveau von GLM-4.7 vs GPT-5 entscheidend sein.

API-Kosten (Eingabe, Ausgabe, zwischengespeicherte Tokens)

Die genauen Kosten von GPT-5 sind noch nicht öffentlich, aber wenn es den Mustern von GPT-4.1/o3 folgt, erwarten wir:

• Höherer Preis pro 1M Tokens als regionale chinesische Modelle
• Mögliche Rabatte auf zwischengespeicherte Tokens und wiederverwendeten Kontext

GLM-4.7 hingegen ist bei den Kosten aggressiv positioniert, insbesondere in chinesischen Regionen, und liegt oft 30–60% günstiger pro Token als fortschrittliche OpenAI-Modelle, je nach Region und Anbieter.

Für eine typische Codierungssitzung (200K Eingabekontext, 20–40K Ausgabetokens über Schritte hinweg) sah ich Läufe, bei denen:

• GLM-4.7 ≈ $0.40–$0.60 kostete
• GPT-4.1/o3 ≈ $0.90–$1.40 für ähnliche Leistung kostete

Wenn GPT-5 in diesem oberen Bereich bleibt oder höher liegt, behält GLM-4.7 einen starken „Wert pro gelöste Aufgabe“-Vorteil.

Gesamtkosten für typische Agenten-Workflows

Ich habe auch Kosten pro erfolgreicher Aufgabe verfolgt, nicht nur pro Token.

Für meinen 30-Aufgaben-SWE-Benchmark:

• GLM-4.7: ungefähr 0,80 $ pro erfolgreichen Fix
• GPT-Style (GPT-4.1/o3 als Stellvertreter für GPT-5): etwa 1,30 $ pro erfolgreichen Fix

Selbst wenn GPT-Style-Modelle mehr Aufgaben lösen, hat GLM bei den Kosten pro funktionierendem PR immer noch gewonnen.

Wenn du ausführst:

• Kontinuierliche Code-Review-Agenten
• Automatisierte Bug-Triage
• Nächtliche Refactor-Pässe

Diese Kosten-pro-Fix-Deltas summieren sich unglaublich schnell.

Self-Hosting-Option (nur GLM-4.7)

Der Joker ist Self-Hosting. GLM-4.7 kann auf deinen eigenen GPUs oder in einer privaten Cloud bereitgestellt werden.

Das eröffnet Anwendungsfälle, bei denen:

• Du eine feste Infrastrukturrechnung zahlst, anstatt unvorhersehbarer API-Spitzen
• Gesetzliche/Sicherheitsanforderungen verlangen, dass Code niemals einen US- oder Drittanbieter berührt
• Du viele kleinere Agenten parallel betreiben möchtest, ohne Aufschlag pro Aufruf

Es ist natürlich nicht kostenlos. Du tauschst:

• Ops-Komplexität (Überwachung, Skalierung, Upgrades)
• Anfängliche Infrastrukturkosten

...aber sobald dein Verbrauch eine bestimmte Grenze überschreitet (bei mir waren es rund 15–20M Tokens pro Tag konstant), wird das Self-Hosting von GLM-4.7 sehr attraktiv im Vergleich zu einer reinen GPT-5-API-Strategie.

Architekturunterschiede, die wichtig sind

Kontextfenster (200K vs ?)

Für GLM-4.7 hatte ich durchweg ein Kontextfenster von ~200K Token zur Verfügung. Das reicht aus für:

• ein mittelgroßes Repository-Slice,
• plus ein paar offene Probleme,
• plus einige Logs und Anweisungen.

Die genauen Kontextgrenzen von GPT-5 hängen von der Stufe/Version ab, und der Anbieter passt sie ständig an. In der Praxis behandelte ich es auch wie ein 128K–200K-Modell, und ich stieß fast nie auf harte Kontextgrenzen bei alltäglichen Codierungsaufgaben.

Der wesentliche Unterschied war nicht die rohe Zahl, sondern wie sie genutzt wurde:

• GPT-5 machte oft eine bessere implizite Zusammenfassung und blieb fokussiert, selbst wenn ich den Kontext übermäßig vollstopfte.
• GLM-4.7 "vergaß" manchmal frühere Details in sehr langen Eingabeaufforderungen, es sei denn, ich strukturierte die Abschnitte explizit (z. B. # Spec, # Code, # Tests).

Ausgabelänge (128K vs ?)

GLM-4.7 erzeugte ruhig sehr lange Ausgaben, wenn ich um vollständige Patches oder Testsuiten bat, zehntausende von Tokens ohne zu stocken.

GPT-5 bewältigte ebenfalls große Ausgaben, aber ich bemerkte, dass es eher frühzeitig stoppte und so etwas sagte wie "Lassen Sie es mich wissen, wenn Sie den Rest möchten", besonders in chatähnlichen Benutzeroberflächen.

Für große Unterschiede:

• GLM-4.7 fühlte sich wohler dabei, große Codeblöcke auf einmal auszugeben.
• GPT-5 bevorzugte einen eher iterativen, konversationellen Stil ("Hier ist Teil 1… jetzt Teil 2…"), was für Menschen angenehmer ist, aber etwas störend für automatisierte Pipelines.

Denkmodus und Tiefe des Denkens

Beide Modelle vermarkten eine Form von "tieferem Denken" oder Denkmodus.

In meinen Tests:

• Das Aktivieren des Reasoning-Modus für GPT-5 (wo verfügbar) verbesserte die Erfolgsquote bei der Behebung komplexer Fehler um etwa 10–15 Prozentpunkte, aber auch:
  • erhöhte die Latenz um das 1,5- bis 2-fache,
  • und erhöhte den Tokenverbrauch ähnlich.
• GLM-4.7's „langsame / tiefgehende“ Stilaufforderung (bei der ausdrücklich dazu aufgefordert wird, in Schritten zu denken, Hypothesen zu überprüfen und Code erneut zu lesen) half ebenfalls, aber die Gewinne waren geringer: vielleicht 5–8 Prozentpunkte Verbesserung bei den kniffligsten Aufgaben.

Wenn es Ihnen um maximales Reasoning für Produktentscheidungen oder mehrstufige Planung geht, scheint GPT-5 in der Spitzenklasse immer noch voraus zu sein. Wenn Ihnen gutes, ausreichendes Reasoning zu vernünftigen Kosten wichtig ist, behauptet sich GLM-4.7.

Real-World-Coding-Performance

Hier wird der Vergleich von GLM-4.7 und GPT-5 für das Codieren konkret.

Mehrdateien-Refaktorierung

Ich gab beiden Modellen dasselbe Szenario:

• Ein kleines TypeScript-Monorepo (ca. 60 Dateien).
• Ziel: einen gemeinsamen Analysehelfer extrahieren und doppelte Logik in 4 Diensten entfernen.

Ergebnisse:

• GPT-5:
  • Identifizierte korrekt alle 4 Zielbereiche.
  • Schlug ein sehr sauberes API-Design vor.
  • Aber sein Patch verfehlte 2 Importe und eine subtile Typinkongruenz.
• GLM-4.7:
  • Fand 3/4 der Duplikationsstellen von allein.
  • Brauchte einen Schubs, um die letzte zu erkennen.
  • Gab häufiger Patches aus, die beim ersten Versuch kompilierten.

Zeit bis zu „grünen Tests“ nach 2–3 Hin-und-Her-Iterationen:

• GPT-5: durchschnittlich ca. 22 Minuten (inklusive Installation + Tests).
• GLM-4.7: ca. 24 Minuten.

Ehrlich? Das ist ein Unentschieden. Beide sind als Refaktorierungs-Kopiloten nutzbar. GPT-5 fühlt sich mehr wie ein Senior-Entwickler mit gutem Designgeschmack an, GLM-4.7 wirkt wie ein schneller, sorgfältiger Mid-Level, der die Typen doppelt überprüft.

Fehlerbehebungs-Schleifen

Bei den kleineren SWE-typischen Fehleraufgaben habe ich beobachtet, wie sich jedes Modell über wiederholte Versuche hinweg verhielt:

1. Einen Fix vorschlagen.
2. Tests durchführen.
3. Fehlerprotokolle lesen.
4. Erneut versuchen.

Beobachtete Muster:

• GPT-5:
  • Besser im Interpretieren langer Python-Tracebacks.
  • Weniger wahrscheinlich, denselben fehlerhaften Patch zu wiederholen.
  • Normalerweise innerhalb von 2–3 Schleifen konvergiert.
• GLM-4.7:
  • Manchmal auf derselben falschen Hypothese festgefahren.
  • Aber sobald ich explizit sagte: „Gehe davon aus, dass deine vorherige Idee falsch war, schlage einen anderen Ansatz vor“, löste es sich.
  • Benötigte im Durchschnitt 3–4 Schleifen für die schwierigsten Fehler.

Testgenerierungsqualität

Ich habe beide auch gebeten, Tests zu generieren, bevor ein Fehler behoben wird (ein überraschend mächtiger Trick):

• Für Python + pytest:
  • GPT-5 erzeugte aussagekräftigere Tests und besser parametrisierte Fälle.
  • GLM-4.7 erzeugte etwas einfachere Tests, machte aber weniger Syntaxfehler.
• Für TypeScript + Jest:
  • Beide waren in Ordnung, aber GPT-5 spiegelte die tatsächlichen Projektkonventionen (Benennung, Ordnerstruktur) besser wider, als ich ihm nur ein paar Beispiele gab.

Wenn Ihr Haupteinsatzzweck der Vergleich von GLM-4.7 und GPT-5 für Coding-Agenten ist, würde ich es so zusammenfassen:

• GPT-5: höheres Potenzial, etwas besser in der Planung, weniger „dumme Wiederholungs“-Schleifen.
• GLM-4.7: ausgezeichnetes Kosten-Nutzen-Verhältnis, stark, sobald man ihm strukturierte Eingaben und ein wenig Leitplankenlogik gibt.

Wann GLM-4.7 wählen

Kostenempfindliche Anwendungsfälle

Wenn Sie ein unabhängiger Entwickler, eine kleine Agentur oder ein Nebenprojekt betreiben, läuft der Vergleich von GLM-4.7 und GPT-5 normalerweise auf eine brutale Kennzahl hinaus: Dollar pro gelöste Aufgabe.

Aus meinen Aufzeichnungen:

• Für Coding-Agenten lag GLM-4.7 oft bei 40–60 % der Kosten von GPT-5 für etwa 80–90 % der Qualität.

Dieser Kompromiss lohnt sich für:

• Hintergrund-Code-Wartung,
• massenhafte Refaktorisierungen,
• Dokumentationserstellung,
• Batch-Test-Generierung.

Bedarf an Selbsthosting

Wenn Ihr Team oder Ihre Kunden:

• keinen Code an Drittanbieter-Clouds senden können, oder
• alles auf privater Infrastruktur ausführen möchten,

dann ist die Self-Hosting-Story von GLM-4.7 der entscheidende Faktor.

Ist es schmerzhafter zu bedienen? Ja. Du hast es mit GPUs, Inferenz-Servern, Überwachung und Skalierung zu tun. Aber wenn dein Tokenvolumen hoch genug ist und Sicherheit/Privatsphäre nicht verhandelbar sind, ist es eine sehr rationale Wahl.

Codebasen mit viel Chinesisch

Wenn deine Codebasis:

• Kommentare, Variablennamen oder Commit-Nachrichten auf Chinesisch enthält, oder
• dein Team Probleme zuerst auf Chinesisch und dann auf Englisch meldet,

hat GLM-4.7 derzeit einen echten Vorteil.

In meinen gemischten Chinesisch-Englisch-Repo-Tests:

• Verstand es Fehlerberichte mit chinesischen Stack-Traces und Log-Nachrichten fast nativ.
• GPT-5 holte auf, sobald ich alles übersetzt hatte, aber das ist zusätzlicher Arbeitsaufwand.

Also, wenn du in einer chinesisch-orientierten oder zweisprachigen Umgebung arbeitest, passt GLM-4.7 einfach natürlicher in den täglichen Entwickleralltag.

Wann man GPT-5 wählen sollte

Reifes Ökosystem

Das Hauptargument außerhalb der Technik bei GLM-4.7 vs. GPT-5 ist das Ökosystem.

GPT-5 gewinnt derzeit bei:

• Tiefe der Drittanbieter-Integrationen,
• sofort verfügbaren Tools und Agenten, die auf seine API abgestimmt sind,
• Community-Beispielen, Dokumentationen und Debugging-Tipps.

Wenn du etwas baust, das in viele SaaS-Tools, Plugins oder No-Code-Plattformen integriert werden muss, ist GPT-5 der Weg des geringsten Widerstands.

Englisch-orientierte Workflows

Für Englisch-orientierte:

• Produktspezifikationen,
• UX-Texte,
• Strategie-Dokumente,
• komplexe Denkaufgaben,

fühlt sich GPT-5 einfach ausgereifter an.

In meinen Tests war sein:

• Spezifikationsschreiben,
• Abwägungsanalyse,
• und Erklärungsqualität

waren durchweg „kundenfertig“ ohne Bearbeitung. GLM-4.7 kann das absolut auch, aber ich fand mich öfter dabei, Ton und Struktur zu bearbeiten.

Maximale Stabilitätsanforderungen

Wenn Ihre Prioritäten sind:

• ultra-vorhersehbare Latenz,
• extrem geringe Halluzinationstoleranz bei Allgemeinwissen,
• und starke Anbieter-SLAs,

dann ist GPT-5 derzeit die sicherere Wahl.

In lang laufenden Agenten, bei denen eine einzige seltsame Halluzination echten Schaden anrichten kann (wie bei der Fehlkonfiguration von Infrastrukturen), wirkten die Schutzmaßnahmen und das Überwachungsstack von GPT-5 ausgereifter. GLM-4.7 verhielt sich in meinen Tests gut, aber das umgebende Ökosystem (Evaluierungen, Schutzmaßnahmen, gebrauchsfertige Werkzeuge) ist noch nicht so kampferprobt.

Das größere Bild: Modelle werden zu Handelswaren

Aus der Ferne betrachtet, ist der interessanteste Teil von GLM-4.7 vs. GPT-5 nicht, wer „gewinnt“. Es ist vielmehr, dass sie für viele alltägliche Arbeiten beide gut genug sind.

Worauf es jetzt tatsächlich ankommt, ist:

• Preis pro gelöstem Problem (nicht pro Token).
• Ökosystem und Verknüpfung um das Modell, Werkzeuge, Protokollierung, Wiederholungen, Prompt-Muster.
• Passform für Ihre Sprache + Domain (englischsprachiges SaaS vs. zweisprachiger Codebase vs. interne Werkzeuge).

Mein praktisches Fazit nach all diesen Tests:

• Verwenden Sie GPT-5, wenn Sie maximale Argumentationsqualität, polierte englische Ausgaben und umfassende Unterstützung im Ökosystem benötigen.
• Verwenden Sie GLM-4.7, wenn Ihnen Durchsatz und Kosten wichtiger sind oder Sie Selbsthosting und bessere chinesische Leistung benötigen.

Und ehrlich gesagt? Hab keine Angst, sie zu mischen.

In meinem aktuellen Stack:

• Spezifikationen, Produktentscheidungen und kundenorientiertes Schreiben → GPT-5.
• Massen-Coding-Agenten, Testgenerierung und interne Wartungsaufgaben → GLM-4.7.

Wenn du gerade erst anfängst, würde ich Folgendes vorschlagen:

1. Wähle einen repräsentativen Workflow aus, zum Beispiel "einen fehlschlagenden Test in meinem Repo mit einem Agenten beheben".
2. Führe ihn 10 Mal mit GLM-4.7 und 10 Mal mit GPT-5 aus, indem du die gleichen Eingaben und Tools verwendest.
3. Verfolge: Erfolgsrate, Gesamttoken, Kosten und wie genervt du beim Lesen der Ausgaben bist.

Dieses kleine Experiment wird dir mehr über GLM-4.7 vs GPT-5 für dein Leben sagen als jede Marketingseite oder jeder Blogbeitrag, inklusive diesem hier.

Behalte dann das, was tatsächlich für dich arbeitet, nicht das mit dem auffälligeren Benchmark-Diagramm.

Das beste Modell für dich hängt von deinem Workflow ab, nicht von der Rangliste.

Nach all diesen Tests ist die unbequeme Wahrheit diese: Für die meisten persönlichen und Indie-Workflows ist das Modell selbst weniger wichtig als das Agentendesign, das es umgibt.

Genau das bauen wir bei Macaron. Wir setzen nicht auf ein einziges „bestes“ Modell. Wir kombinieren die stärksten verfügbaren Modelle mit einem Gedächtnissystem, das tatsächlich lernt, wie du arbeitest — was dir wichtig ist, wie du iterierst und wo es normalerweise klemmt.

Wenn du neugierig bist, wie sich das in der Praxis anfühlt, kannst du es selbst ausprobieren. [Macaron kostenlos ausprobieren →]