Änderungsprotokoll

Diese Seite dokumentiert, was an TokenCheck geändert wurde und warum: je Eintrag Datum, Anlass, Problem und Lösung. Befundnummern beziehen sich auf das interne Reviewprotokoll vom 17.09.2026. Preisangaben gelten je Million Tokens in US-Dollar.

17.09.2026: Erstversion

Veröffentlicht wurden der Rechner (Engine calc.js, Preistabelle prices.js, Oberfläche app.js), zwei Beispielexporte, das Prüfskript audit.mjs, das Kontaktformular über eine Cloudflare Pages Function mit Telegram-Zustellung sowie Impressum, Datenschutzhinweise, Preisliste und Ablauf. Preisstand 17.09.2026; die Anthropic-Preise waren gegenüber der Referenz vom 24.06.2026 unverändert.

17.09.2026: Unabhängiger Review, 45 bestätigte Befunde

Ein unabhängiger Review von Code, Texten und Rechtsseiten ergab 45 bestätigte Befunde (13 hoch, 18 mittel, 14 niedrig), jeweils mit Reproduktion und Korrekturvorschlag. Alle 45 wurden am selben Tag behoben, Befunde mit Rechenwirkung mit Testfall. Die 15 wichtigsten nach Kategorie:

Rechenlogik

• Zeitraum bei doppelten Datumswerten (Befunde 1, 18, 20). Problem: Der Zeitraum zählte alle Datumswerte statt eindeutiger Tage; ein Export mit mehreren Positionen unter demselben Datum galt als ein Tag, Monatskosten und Honorar waren um Faktor 30 zu hoch. Lösung: Eindeutige Tage, Erkennung gleichmäßiger Wochen- und Monatsbuckets, sichtbarer Rückfall auf 30 Tage bei weniger als zwei auswertbaren Tagen.
• Input-Semantik bei Anthropic-Exporten (Befunde 2, 5, 8). Problem: Die Engine setzte OpenAI-Semantik voraus (Cache-Tokens in input_tokens enthalten); bei Anthropic ist input_tokens nur der ungecachte Anteil, und uncached_input_tokens aus dem Admin-API-Export wurde als Cache-Spalte gelesen. Lösung: Der Parser erkennt das Anthropic-Schema an den Spaltennamen und addiert Cache-Tokens auf den Input; übersteigen Cache-Tokens den Input, erscheint ein Hinweis.
• Batch-Faktor und Phantom-Delta (Befunde 4, 14, 17). Problem: Nachher-Kosten wurden mit einem tokengewichteten Batch-Faktor aus Aggregaten gerechnet; bei preisgleichen Nachfolgern wie Opus 4.7 auf Opus 5 erzeugte Rundungsrauschen eine Ersparnis von 0 USD oder ein Abschaltrisiko. Lösung: Ist- und Nachher-Kosten werden zeilenweise mit demselben Preisobjekt berechnet, der Batch-Hebel kostengewichtet, Differenzen unter einem halben Cent gelten als null.

Parser

• Deutsche Zahlenformate (Befunde 6, 13). Problem: Tausenderpunkte galten als Dezimalpunkt, Dezimalkommas wurden gelöscht; 6.200.000 wurde zu 6,2 und 12,5 zu 125, in CSV-Dateien aus deutschem Excel wie in der manuellen Eingabe. Lösung: Ein gemeinsamer Zahlenparser für deutsche, englische und Schweizer Schreibweisen, mit dem CSV-Trenner als Entscheidungshilfe bei mehrdeutigen Fällen, in Engine und Formular.
• Datumsformate (Befunde 7, 20). Problem: dd.mm.yyyy wurde teils als Monat.Tag gelesen oder verworfen, Unix-Zeitstempel galten als ungültig; der Zeitraum war um bis zu Faktor 28 falsch oder fiel still auf 30 Tage. Lösung: Expliziter Datumsparser für ISO, dd.mm.yyyy, Unix-Sekunden und Unix-Millisekunden; die Oberfläche zeigt, ob der Zeitraum aus der Datumsspalte stammt oder eine Annahme ist.
• OpenAI-Kostenexport ohne Modellspalte (Befund 19). Problem: Der reale Kostenexport führt das Modell nur im Feld line_item, der Parser brach mit "keine Modellspalte" ab. Lösung: Im Kostenmodus dient line_item als Modellquelle, Zusätze wie "(batch)" werden abgetrennt, nicht bewertbare Positionen wie "Image models" erscheinen als unbekannt statt mit 0 USD.
• Modellnamen (Befunde 21, 22, 23, 35). Problem: Der Präfix-Fallback ordnete o3-mini dem Preis von o3 und claude-3-haiku dem 3,2-fach teureren Haiku 3.5 zu; Bedrock-Kennungen wie us.anthropic.claude-sonnet-4-5-20250929-v1:0 und Anzeigenamen mit Leerzeichen blieben unbewertet. Lösung: Varianten wie mini, pro und audio sind vom Präfix-Treffer ausgeschlossen, Haiku 3 und Altmodelle haben eigene Preise, Regions- und Versionspräfixe werden entfernt, Anzeigenamen in API-Kennungen gewandelt.

Texte und Recht

• Einwilligung im Formular (Befund 9). Problem: Die Pflicht-Checkbox lautete nur "Datenschutzhinweise gelesen", koppelte die Drittlandübermittlung an Telegram mit dem Mitsenden der Rechnerwerte, und der Server prüfte die Einwilligung nicht. Lösung: Die Checkbox benennt Telegram und Art. 49 Abs. 1 lit. a DSGVO ausdrücklich und nennt E-Mail als Alternative; der Server lehnt Anfragen ohne Einwilligung ab und speichert deren Textversion zum Lead.
• Telegram als einziger Kanal, IP-Speicherung (Befunde 10, 31). Problem: Jede Anfrage ging ausschließlich per Bot-API an Telegram, die IP-Adresse lag 365 Tage beim Lead, ohne Nennung in den Datenschutzhinweisen. Lösung: Leads werden in Cloudflare Workers KV abgelegt, die Datenschutzhinweise nennen Speicherort, Telegram-Zustellung, Drittland, Speicherdauer und Widerruf; die IP-Adresse wird nur zehn Minuten als Zähler für die Drosselung gehalten.
• Qualitätsaussage zum Modellupdate (Befund 12). Problem: "Sonnet 4.6 auf Sonnet 5 spart ein Drittel, ohne Qualitätsverlust" war eine unbelegte Behauptung über ein Drittprodukt und widersprach der eigenen Regel: keine Qualitätszusage ohne Evaluierungsset. Lösung: Der Text nennt nur noch Listenpreise und den Regressionslauf mit 200 echten Fällen vor jeder Umstellung; der zweite Review ergänzte den Tokenizer-Hinweis.
• Zielgruppenschwelle (Befund 27). Problem: Die Seite warb "ab 10.000 Euro API-Kosten im Jahr", die Vertriebsregel lehnte eine Erfolgsbeteiligung unter 10.000 USD im Monat ab, Faktor zwölf dazwischen. Lösung: Etwa 3.000 USD je Monat gelten einheitlich in Seite, Preisliste und Engine; darunter zeigt der Rechner statt der Honorarbox den Hinweis auf den Bericht ohne Begleitung, der Lead wird als "unter Schwelle" markiert.

Barrierefreiheit

• Upload-Zone (Befund 29). Problem: Die Ablagefläche hatte weder Rolle noch Namen, das Dateifeld kein Label, Statusmeldungen überschrieben die Anleitung ohne Live-Region. Lösung: role="button", aria-label und aria-describedby an der Zone; Statusmeldungen in einem eigenen Element mit role="status" und aria-live="polite"; die Anleitung bleibt stehen.
• Formularfelder und Fehlermeldungen (Befunde 30, 44). Problem: Erzeugte Felder der manuellen Tabelle hatten nur Platzhalter statt Labels, der Löschen-Knopf hieß "×", Formularfehler erschienen als Sammelmeldung ohne Feldbezug, Fokus oder aria-invalid. Lösung: aria-label an allen erzeugten Feldern und Knöpfen, scope="col" an den Spaltenköpfen; die Validierung prüft der Reihe nach, markiert das erste fehlerhafte Feld, setzt den Fokus dorthin und nennt die Ausweichadresse.

Sicherheit

• Drosselung und Origin-Prüfung (Befund 45). Problem: /api/lead nahm beliebig viele Anfragen von beliebigen Origins an, jeder Treffer erzeugte eine Telegram-Nachricht und einen KV-Eintrag. Lösung: Exakter Vergleich des Origin-Headers mit dem eigenen Host, fünf Anfragen je IP in zehn Minuten über einen kurzlebigen KV-Zähler, Abweisung von Anfragen über 12.000 Zeichen.
• Validierung der Rechnerwerte (Befund 40). Problem: Das mitgesendete Summenobjekt wurde ungeprüft verarbeitet, ein Nicht-Array im Feld models löste einen Serverfehler 500 aus, Nachricht, Summen und HTML-Escaping konnten das Telegram-Limit von 4.096 Zeichen überschreiten. Lösung: Typ und Länge jedes Feldes werden geprüft, Modelllisten auf zwölf Einträge zu 40 Zeichen gekürzt, der Nachrichtentext auf 4.000 Zeichen begrenzt, ohne eine HTML-Entität zu zerschneiden.

Die übrigen 30 Befunde betrafen unter anderem Platzhalter im Impressum (11; ein Deploy-Prüfschritt blockiert seitdem Platzhaltertext), absolute Aussagen wie "Keine Daten auf unseren Servern" (25), pauschale Cache- und Batch-Zahlen (28), die Honorarbox mit nur dem optimistischen Szenario (26), Excel-Booleans WAHR und FALSCH (34) sowie Titelzeilen und Trennzeichen in Anführungszeichen (37, 38).

17.09.2026: Zweiter Review durch den Betriebsagenten

Nach den Korrekturen prüfte der Betriebsagent Preistabelle, Rechenregeln und Texte gegen die Anbieterdokumentation; vier Punkte wurden geändert.

• Cache-Write-Preise bei OpenAI. Problem: Die Modellseiten von OpenAI weisen für GPT-6 Astra, GPT-5.6 Sol, Terra und Luna einen Cache-Schreibpreis vom 1,25-Fachen des Inputpreises aus, den die Tabelle nicht kannte. Lösung: Die vier belegten Schreibpreise (12,50, 5, 2,50 und 0,25 USD) stehen in der Tabelle, ein fehlender Schreibpreis fällt auf den Inputpreis statt auf null zurück, der Caching-Hebel zieht den Schreibaufschlag ab, Batch halbiert auch Schreibtokens.
• Semantik des Sol-Aktionspreises. Problem: Der Aktionspreis für GPT-5.6 Sol (4/20 statt vorher 5/30 USD) war mit festem Ende am 21.11.2026 und Rückfall danach modelliert, obwohl OpenAI nur eine Mindestdauer zugesagt und kein Ende angekündigt hat. Lösung: Die Tabelle führt Mindestdauer und früheren Listenpreis, der Risikotext lautet "zugesagt mindestens bis 21.11.2026, ein Ende ist nicht angekündigt" und beziffert den Rückfall als bedingtes Szenario; beim Update GPT-5.5 auf Sol wird der vom Aktionspreis abhängige Teil der Ersparnis ausgewiesen.
• Tokenizer-Faktor. Problem: Sonnet 4.6 auf Sonnet 5 wurde mit gleicher Tokenmenge gerechnet (ein Drittel Ersparnis), obwohl Claude 4.7 und neuer einen Tokenizer nutzen, der laut Anthropic-Dokumentation rund 30 Prozent mehr Tokens für denselben Text erzeugt. Lösung: Wechsel über die Tokenizer-Grenze rechnen mit Faktor 1,2 (rund ein Fünftel Ersparnis), Wechsel innerhalb einer Generation wie Opus 4.7 auf Opus 5 ohne Faktor; ein Hinweis verweist auf die Messung mit count_tokens vor der Umstellung.
• Texte. Problem: Ergebnisse waren als Ersparnis ohne Einordnung beschriftet, Sätze wie "senkt die Tokenkosten um ein Drittel" und "Ihre KI-Rechnung ist zu hoch" standen ohne Beleg auf der Seite. Lösung: Das Ergebnis heißt "Szenario zu heutigen Listenpreisen", ein fester Hinweis in Oberfläche, Kostenmodus und Bericht erklärt Jahres- und Honorarwerte als Rechenbeispiele ohne Abrechnungswirkung; die genannten Sätze wurden entfernt.

17.09.2026: Neue Gestaltung und Unterseiten

Die Startseite erhielt die Gestaltung von Destiny Deutschland (Schrift Inter, dunkle Kopffläche, helle und dunkle Variante nach Systemeinstellung) und einen Abschnitt „Nachprüfbar“. Neu sind die Seiten Methodik (Rechenweg deckungsgleich mit calc.js, Preistabelle), Analyse (Auswertung von 20 deutschen Software- und KI-Firmen), Über uns und dieses Änderungsprotokoll; Impressum und Datenschutzhinweise bekamen dieselbe Kopf- und Fußzeile, die Datenschutzhinweise einen Abschnitt zur Schriftart. Der Rechner und seine Element-IDs blieben unverändert; das Prüfskript scripts/check-ids.mjs sichert das ab und gleicht die Preistabelle dieser Seiten mit prices.js ab.

17.09.2026: Schrift selbst gehostet, Datenschutz und Über uns ergänzt

Die Schrift Inter wird nicht mehr von Google Fonts geladen, sondern liegt als woff2 unter fonts/ auf dem eigenen Hosting (SIL Open Font License 1.1, Lizenztext beigelegt). Beim Aufruf wird damit keine IP-Adresse an Google übermittelt; der frühere Abschnitt zu Google Fonts in den Datenschutzhinweisen ist durch den Abschnitt „Schriften“ ersetzt. Neu ist der Abschnitt „Briefe an Unternehmen“ mit Rechtsgrundlage und Widerspruchsrecht für postalische Anschreiben. Die Seite Über uns beschreibt die Herkunft passend zur Dachmarke destinydeutschland.com, ohne Kennzahlen. Der Vertragsentwurf nennt für den Bericht jetzt „in der Regel innerhalb von 48 Stunden, spätestens fünf Werktage“.

18.09.2026: Neue Seite „Termine“ mit Kalenderdatei

Anlass: Abschalttermine, die zugesagte Mindestlaufzeit des Aktionspreises und der Preisstand standen verstreut in prices.js und in der Methodik. Problem: Wer einen dieser Termine übersieht, zahlt ab dem Stichtag mehr oder bekommt gar keine Antwort mehr, und niemand konnte die Termine an einer Stelle nachlesen. Lösung: Die neue Seite Termine führt alle zehn datierten Ereignisse in einer Tabelle zusammen, je Zeile mit Datum, Anbieter, Modell, Ereignis, Folge für den Kunden und Quelle. Aufgenommen wird nur, was in prices.js belegt ist: die Felder deprecated, retired und promo, dazu Preisstand und Referenzstand der Anthropic-Preisliste aus dem Kopfkommentar.

Ein Knopf auf der Seite erzeugt aus genau diesen Tabellenzeilen eine Kalenderdatei im Format ICS nach RFC 5545 und bietet sie zum Sichern an. Das übernimmt das neue Modul site/termine.js, ein ES-Modul, das nur auf dieser Seite geladen wird. Die Datei entsteht im Browser aus dem Inhalt der Seite, ohne Bibliothek, ohne Netzwerkzugriff und ohne Speicherzugriff. Unterbindet der Browser das Sichern, bleibt die Tabelle vollständig nutzbar und ein Hinweis erscheint an der Stelle des Knopfes; ohne aktives JavaScript bleibt der Knopf ausgeblendet.

Der Seitenbau in scripts/build-pages.mjs kennt dafür jetzt das optionale Feld script in content/pages.json, das genau ein Modul vor </body> einbindet; alle übrigen Unterseiten bleiben ohne Skript. Das Prüfskript scripts/check-ids.mjs vergleicht die Datumsangaben der Terminliste in beide Richtungen mit prices.js, so wie es die 44 Modellpreise der Methodik prüft: Jede Zeile muss belegt sein, und jeder Termin aus der Preistabelle muss in der Liste stehen. Geprüft werden außerdem der Navigationspunkt „Termine“ auf allen Seiten, genau ein Modul auf der Seite, das Fehlen externer Ressourcen sowie der Verzicht auf Netzwerk- und Speicherzugriff in termine.js. Die Rechenlogik in calc.js und die Preise in prices.js blieben unverändert.

18.09.2026: Druckbarer Prüfbericht aus dem Rechner

Anlass: Das Ergebnis des Rechners war nur am Bildschirm zu sehen. Problem: Wer es im eigenen Haus weiterreichen wollte, musste die Zahlen abschreiben oder uns die Datei schicken; ein Ergebnis, das niemand mitnehmen kann, erreicht die Personen nicht, die über eine Umstellung entscheiden. Lösung: Im Ergebnisbereich steht jetzt der Knopf „Ergebnis als Bericht drucken“. Er erscheint zusammen mit dem Ergebnis und ruft die Druckfunktion des Browsers auf. Auf dem Papier steht ein Bericht mit Wortmarke in Schwarzweiß, Titel, Erstellungsdatum, Preisstand, den Eckwerten, den vier Hebeln mit Betrag und Begründung, den Risiken, den verwendeten Annahmen samt der eingestellten Reglerwerte, der Tabelle je Modell und einer Fußzeile mit Verweis auf die Methodik, den Impressumsangaben und dem Hinweis, dass die Werte eine Schätzung auf Basis Ihrer Eingaben und der Listenpreise sind und nur die auf der Anbieterrechnung nachweisbare Ersparnis abgerechnet wird.

Der Druckbereich liegt als leeres Element in site/index.html, außerhalb des Seiteninhalts, und wird von site/app.js aus dem bereits berechneten Ergebnis und den angezeigten Werten gefüllt. Es wird nichts neu gerechnet, calc.js und prices.js blieben unverändert, und am Bildschirm bleibt der Bereich ausgeblendet. Die Druckvorlage in site/styles.css setzt die Seitenränder, blendet Navigation, Knöpfe, Regler und Formulare aus, nimmt den Scrollrahmen von den Tabellen, zeigt die Balken der Hebel als Zahl und stellt Schrift und Flächen auf Schwarz auf Weiß, auch wenn der Bildschirm dunkel eingestellt ist. Es wird keine Bibliothek geladen und keine Anfrage gestellt; die Daten bleiben wie bisher im Browser. scripts/check-ids.mjs prüft die beiden neuen Pflicht-IDs, die Lage des Druckbereichs und die Druckregeln, ein neuer Regressionstest weist Knopf, Druckbereich und Vorlage nach.

18.09.2026: Dritter Review, Bericht und Terminseite nachgezogen

Anlass: Ein weiterer unabhängiger Review prüfte den druckbaren Bericht, die Seite Termine und die Druckvorlage. Problem: Der Bericht las die drei Reglerwerte aus dem Bildschirmtext statt aus dem Ergebnis, nannte sie ohne Einordnung als Annahme, versprach einen Regressionslauf als erbracht, bewertete den Hebel Modellupdate auch dann, wenn er im Kostenmodus gar nicht gerechnet wird, ließ den Hinweis unter 3.000 US-Dollar Monatskosten weg und formulierte in der Fußzeile eine rechtliche Verbindlichkeit. Lösung: Die Annahmen kommen jetzt aus dem Ergebnisobjekt, also genau aus den Werten, mit denen gerechnet wurde, und tragen den Satz, dass sie Annahmen sind und keine Messung Ihres Systems. Der Modellupdate-Hebel nennt im Kostenmodus, dass er nicht bewertet wurde. Unter 3.000 US-Dollar je Monat steht die Einordnung auch auf dem Papier. Die Fußzeile nennt nun dieselbe Geschäftsregel wie der Bildschirm: abgerechnet wird nur die Ersparnis, die auf Ihrer Anbieterrechnung nachweisbar ist. Die Rechenlogik in calc.js und prices.js blieb unverändert.

Auf der Seite Termine nennt die Einleitung jetzt je Ereignisart die Folge statt einer pauschalen Warnung, die Überschrift grenzt die Liste auf unsere Preistabelle ein, und der Abschnitt zur Herkunft sagt, was das Prüfskript leistet und was nicht. Der Stand der Liste steht nur noch an einer Stelle im Inhalt; site/termine.js liest ihn von dort und führt kein eigenes Datum mehr. Auf schmalen Bildschirmen steht je Termin eine Liste aus Beschriftung und Wert, auf breiten nutzt die Tabelle eine breitere Inhaltsspalte.

In der Gestaltung galt das Attribut hidden bisher nicht für Knöpfe, weil die eigene Regel .btn die Browserregel schlug; ohne aktives JavaScript war der Knopf zur Kalenderdatei deshalb sichtbar, obwohl er ausgeblendet sein sollte. Die Druckvorlage blendet die Navigation jetzt mit dem tatsächlich wirksamen Selektor aus, und die Annahmentabelle darf auf die nächste Seite umbrechen, statt eine leere Fläche zu hinterlassen. scripts/check-ids.mjs prüft neu die Regel für hidden, die Beschriftungen der Terminzellen und den Stand der Liste gegen beide Textstellen.

18.09.2026: Berichtsfrist an den Vertrag angeglichen

Anlass: Abgleich von Website und Vertragsentwurf vor dem ersten Vertragsschluss. Problem: Die Startseite nannte für den Bericht 48 Stunden nach Eingang des Exports ohne Einschränkung, der Vertragsentwurf dagegen „in der Regel innerhalb von 48 Stunden, spätestens fünf Werktage“ nach Eingang der vollständigen Unterlagen. Lösung: Eckdaten und Ablauf auf der Startseite nennen jetzt dieselbe Frist wie der Vertrag: in der Regel innerhalb von 48 Stunden, spätestens fünf Werktage nach Eingang der vollständigen Unterlagen, also Export und Antworten auf die fünf Fragen. scripts/check-ids.mjs prüft diese Formulierung und lehnt eine unbedingte 48-Stunden-Zusage auf allen Seiten ab. Die Rechenlogik in calc.js und prices.js blieb unverändert.

18.09.2026: Nachweisregel, Arbeitsweise und Datenschutz an den Vertragsentwurf angeglichen

Anlass: Prüfung des überarbeiteten Vertragsentwurfs vor dem ersten Vertragsschluss. Problem: Mehrere Seiten beschrieben noch die Nachweisregel des Entwurfs vom 17.09.2026 (Einheit Anfragen, ersatzweise Input- und Output-Tokens, Bewertung zu Listenpreisen des Basismonats) und versprachen, abgerechnet werde nur, was auf der Anbieterrechnung steht. Der Entwurf vom 18.09.2026 rechnet je Anwendung mit einer festen Preistabelle, bereinigt um Preis- und Volumenänderungen, und beteiligt am Wachstum der Nutzung. Über uns sagte, Auswertung, Bericht und Umsetzungsvorschläge entstünden mit KI-Agenten; der Vertrag sagt zu, dass Kundenunterlagen lokal ohne Sprachmodell ausgewertet werden und KI nur über einen vorher freigegebenen geschäftlichen API-Zugang zum Einsatz kommt. Die Datenschutzhinweise nannten E-Mail-Kontakt, Vertrag und Rechnung sowie die Auswertung von Exporten nicht, und die Löschfrist der Briefaktion hatte keine Obergrenze.

Lösung: Startseite, Methodik, Über uns, Impressum und der druckbare Bericht verwenden dieselbe Formel: Abgerechnet wird nur die nach § 5 des Vertrags nachgewiesene Ersparnis: Anbieterrechnung vor und nach der Umstellung, bereinigt um Preisänderungen der Anbieter und um Änderungen des Volumens. Die Methodik fasst § 5 des Entwurfs vom 18.09.2026 zusammen, mit dem Beispiel Sonnet 4.6 auf Sonnet 5. Über uns beschreibt die Arbeitsweise neu, nennt den richtigen Absatz zur Zustimmung (§ 9 Abs. 6) und grenzt uns gegenüber OpenAI, Anthropic, Microsoft, Amazon Web Services und Google ab; das Impressum ebenso. Ablauf und Preis auf der Startseite nennen den Fragebogen statt fünf Fragen, den Beginn der zwölf Monate ab dem ersten vollen Monat nach der Umstellung und die Begleitung beim Festpreis bis drei Monate nach Übergabe. Die Datenschutzhinweise haben drei neue Abschnitte (E-Mail, Vertrag und Rechnung, Auswertung von Exporten), die Briefaktion löscht spätestens nach zwölf Monaten, und Anfragen aus dem Formular gehen an den Inhaber; der Einwilligungstext im Formular sagt das ebenfalls (Textversion 2026-09-18). scripts/check-ids.mjs verlangt die Formel auf der Startseite und lehnt die alten Versprechen auf allen Seiten ab. Das Prüfskript audit.mjs schreibt die neue Nachweisregel in den Bericht und bricht ab, wenn es Kundendaten im Projektordner auswerten soll. Die Rechenlogik in calc.js und prices.js blieb unverändert.

Testabdeckung

Stand 18.09.2026 laufen 52 automatisierte Prüfungen mit npm test, offline. Alle bestehen.

Weitere Änderungen am 17.09.2026

Impressum nach § 5 DDG vervollständigt (Einzelunternehmen, E-Mail, Umsatzsteuer-Identifikationsnummer). Vertragsentwurf zur Erfolgsbeteiligung mit Nachweisregel (Ersparnis je Anfrage zu Listenpreisen des Basismonats) erstellt; Haftungs- und Laufzeitklauseln sind vor dem ersten größeren Abschluss anwaltlich zu prüfen.

Quellen

• Reviewprotokoll, 17.09.2026: docs/review-befunde.txt
• Testsuiten: scripts/smoke.mjs (29), scripts/launch-regression.mjs (23)
• Preistabelle und Engine: prices.js, calc.js
• OpenAI, API Pricing: developers.openai.com/api/docs/pricing
• OpenAI, Deprecations (GPT-5- und o3-Snapshots, 11.12.2026): developers.openai.com/api/docs/deprecations
• Anthropic, Pricing (Cache, Batch, Tokenizer-Hinweis): platform.claude.com/docs/en/about-claude/pricing
• Anthropic, Token counting (count_tokens): platform.claude.com/docs/en/build-with-claude/token-counting
• DSGVO, Art. 49: eur-lex.europa.eu/eli/reg/2016/679/oj
• EDPB, Guidelines 2/2018 zu Art. 49: edpb.europa.eu
• § 5 DDG: gesetze-im-internet.de/ddg/__5.html
• § 5 UWG: gesetze-im-internet.de/uwg_2004/__5.html
• Telegram Bot API, sendMessage (4.096 Zeichen): core.telegram.org/bots/api
• WCAG 2.1, 1.3.1 und 4.1.2: w3.org/TR/WCAG21