Direkt zum Hauptinhalt

Sicherheit + Limits

TTS klingt harmlos, ist aber technisch (Provider-Kosten) ein Bereich, in dem Chatlix bewusst Schutz-Mechanismen einsetzt. Hier was wirklich passiert, bevor ein TTS-Aufruf raus geht, und welche Limits real im Code stehen — inklusive eines wichtigen Punkts, den viele erwarten, den es aber (noch) nicht gibt.

Was es aktuell NICHT gibt

Bevor es um die echten Schutz-Mechanismen geht, der wichtigste Klartext-Punkt: Chatlix hat keinen eigenen Profanity-Filter und keinen Username-Filter für TTS-Text. Anders als z.B. beim Songrequest-Modul (dort gibt es eine echte Blocklist unter /dashboard/songrequest) oder beim Afterstream-Magazin, läuft TTS-Text unverändert durch — egal ob der Text von dir selbst stammt oder von einem Viewer über eine Channel-Point-Redemption oder Cheer-Message kommt. Wenn du TTS für viewer-getriebene Texte nutzt, ist das dein wichtigster Hebel: Redemption/Feature so konfigurieren, dass du im Zweifel moderieren kannst, oder die Erwartung an dein Publikum kommunizieren.

Pre-Charge Length-Check

Vor jedem TTS-Aufruf prüft Chatlix die Länge des zu sprechenden Texts. Das passiert vor dem eigentlichen Provider-Call und vor dem Credits-Abzug.

Konkret, mit den echten Zahlen aus dem Code:

  • Preview (Voices-Dashboard, Aktion ai.tts_test): maximal 300 Zeichen.
  • Finale Generierung (Aktion ai.tts, z.B. via Automation-Action speak_text): maximal 1.500 Zeichen.
  • Geprüft wird mit mb_strlen() (multibyte-aware), nicht mit naivem strlen() — Emoji und mehrbyte-Zeichen zählen also korrekt, nicht als mehrere Bytes.
  • Ist der Text zu lang, antwortet Chatlix mit dem Fehler text_too_long.

Wichtig: bei diesem Fehler werden keine Credits abgezogen. Du zahlst also nicht für abgelehnte Aufrufe.

Keine stillen Truncations

Eine bewusste Design-Entscheidung, die auch operativ im Runbook so festgehalten ist: Chatlix kürzt nie still einen zu langen Text und spielt nur den Anfang ab. Entweder der komplette Text wird gesprochen oder der Aufruf wird klar abgelehnt mit text_too_long — das gilt sowohl für den Pre-Charge-Check als auch für eine mögliche Provider-seitige Kürzung.

Der Grund: stille Truncations führen dazu, dass du als Streamer denkst, „die TTS hat gespielt, alles gut“ — während in Wahrheit ein Satz mittendrin abgebrochen wurde. Das passiert in Chatlix nicht. Lieber harter Fehler als unbemerkte Halb-Wiedergabe.

Shared-Demo-Quota (Tages-/Minuten-Limit)

Diese Limits greifen ausschliesslich, wenn du im Shared-Demo-Modus bist (Chatlix-eigener ElevenLabs-Key, siehe „TTS-Grundlagen“). Sie schützen den gemeinsamen Chatlix-Key vor Missbrauch/Cost-Burn:

  • Tages-Limit: 100 Aufrufe pro Tag pro User.
  • Minuten-Limit: 5 Aufrufe pro Minute pro User.
  • Fehlgeschlagene Calls, die refundiert werden, zählen nicht gegen dein Kontingent — nur erfolgreiche Generierungen erhöhen den Zähler.

Im BYO-Key-Modus (eigener ElevenLabs-Key) gibt es dieses Chatlix-seitige Limit nicht — hier greifen nur die Limits deines eigenen ElevenLabs-Kontos.

Technisches Detail, falls du im Audit-Log komische Zahlen siehst: die Zähler laufen über Redis mit Tages-/Minuten-Keys. Bei einem Redis-Ausfall ist das System bewusst „fail-open“ konfiguriert — dann wird lieber kein Limit erzwungen, als dass TTS für alle ausfällt.

Bei Überschreitung bekommst du den Fehler demo_day_limit bzw. demo_minute_limit mit einer retry_after_s-Angabe, wann du es wieder versuchen kannst.

Credit-Kosten und was bei Ablehnung passiert

Details zu den genauen Credit-Preisen (Basis-Kosten, Premium-Multiplikatoren) stehen in „TTS-Grundlagen“ und „Stimmen auswählen + ausprobieren“. Sicherheitsrelevant hier: bei jedem der oben genannten Ablehnungsgründe (text_too_long, demo_day_limit, demo_minute_limit, provider_disabled) wird vor dem Provider-Call abgebrochen — es entstehen keine Kosten, weder in Chatlix-Credits noch bei ElevenLabs.

Provider-Fehler (ElevenLabs-seitig)

Wenn ElevenLabs selbst einen Fehler zurückgibt (401 ungültiger Key, 429 Rate-Limit beim Provider, 5xx Ausfall), bekommst du einen provider_error-Code. Wichtig zu wissen: ElevenLabs kann laut Betriebs-Runbook auch fehlgeschlagene Calls abrechnen (ausser 401/429) — Chatlix versucht deshalb bewusst nicht, bei Fehlern automatisch blind zu wiederholen.

Nutzungs-Log

TTS-Aufrufe (erfolgreich wie abgelehnt) landen in einem Nutzungs-Log (audio_usage_logs), das die Basis für Support-Diagnosen ist. Enthalten sind unter anderem:

  • Zeitstempel und Operation (tts, tts_preview, voice_sync, …)
  • Provider-Modus (shared_demo / user_key)
  • Verwendete Zeichen-Anzahl (chars_used — 0 bei Cache-Hit)
  • Ergebnis-Status und Fehlercode (ok, blocked, text_too_long, demo_day_limit, demo_minute_limit, provider_disabled, provider_error etc.)
  • Abgerechnete Credits (0 bei jeder Ablehnung)

Dieses Log ist der erste Blick, wenn jemand fragt „warum hat meine TTS nicht gespielt“ — der Fehlercode steht meistens direkt drin.

Zusammengefasste Regel

Wenn du im Zweifel bist: TTS ist bei Länge und Kosten konservativ und transparent — es spielt entweder komplett oder gar nicht, und es kostet entweder nichts oder einen klar nachvollziehbaren Credit-Betrag. Es wird nie hinter deinem Rücken still gekürzt. Wofür es aktuell keinen automatischen Schutz gibt, ist der Inhalt selbst (Schimpfwörter, problematische Usernamen) — dafür musst du selbst Vorkehrungen treffen, z.B. bei der Konfiguration von viewer-getriebenen Redemptions. Siehe „TTS-Grundlagen“ für das Provider-/Credits-Modell und „Stimmen auswählen + ausprobieren“ für Modus- und Stimmwahl.