Wenn das Modell nein sagt

Diese Woche hat unsere Fehlerberichterstattung eine Klasse von Ablehnungen markiert, die wir nicht eingeplant hatten: Bei historisch oder politisch sensiblen Themen antwortet die API des Modellanbieters mit einer Ablehnung aufgrund der Inhaltsrichtlinie statt mit einer Completion — selbst wenn die Anfrage eindeutig legitim ist. Die Ablehnung kommt aus der eigenen Schicht des Anbieters, nicht aus unserer, und der Nutzer sieht einen rohen Fehlertext in einer Sprache, die er ziemlich sicher nicht liest.

Zwei Filter, nicht einer

Jeder Prompt auf OnePress läuft zuerst durch unsere eigene Eingabeprüfung — eine vertragliche Anforderung unseres Zahlungsabwicklers, und eine vernünftige. Diese Anfragen bestehen sie zu Recht: eindeutig legitime Arbeit ist genau die Art von Traffic, die glatt durchgehen sollte.

Die Ablehnung kommt von einem zweiten Filter, den weder wir noch der Nutzer kontrollieren: die plattformweite Inhaltsprüfung des Modellanbieters selbst, die den Traffic oberhalb des Modells inspiziert. Anfragen, die politisch sensible Themen berühren, fallen in ein Gebiet, das die Compliance-Schicht einer Jurisdiktion als unsicher behandelt. Dieselbe Anfrage ist überall sonst völlig normale Arbeit.

Die nützliche Entdeckung: Der Filter sitzt nicht im Modell

Das ist der Teil, der unsere Architektur verändert hat. Wir haben eine ähnliche eigene Anfrage — dieselbe Inhaltsklasse — an exakt dieselben Modellgewichte geschickt, aber über einen anderen Host ausgeliefert: OpenRouter, geroutet an Inferenzanbieter in den USA. Gleiche Gewichte, gleiche Prompt-Klasse. Vollständige Generierung, keine Ablehnung.

Die Ablehnung saß also nie im Modell. Sie lebt in der Serving-Schicht — der Compliance-Hülle, die ein Anbieter um seine API legt. Das heißt, man kann sauber und offen um sie herum routen, ohne das Modell überhaupt anzufassen.

Was wir geändert haben

• Jedes Modell existiert jetzt zweimal in der Auswahl. Das Standard-Set routet über OpenRouter zu Inferenzanbietern außerhalb des chinesischen Festlands; dieselben vier Modelle bleiben auf ihren Heimat-APIs verfügbar, mit dem Label (CN), für alle, die sie bevorzugen.
• OpenRouter-Anfragen tragen eine Upstream-Allowlist. Wir pinnen Anfragen auf benannte Anbieter und deaktivieren Fallback — kann die gepinnte Liste nicht liefern, schlägt der Aufruf laut fehl, statt still auf einem gefilterten Pfad zu landen.
• Anbieter-Ablehnungen erzeugen jetzt eine lesbare Nachricht. Eine Ablehnung wegen der Inhaltsrichtlinie erklärt sich in klarer Sprache und zeigt auf die Modellauswahl — keine rohen Fehlerbrocken mehr in einer Sprache, die der Nutzer nicht liest. Fehlerframes, die mitten im Stream eingebettet sind und bisher verschluckt wurden und wie eine leere Antwort aussahen, kommen jetzt ebenfalls sauber hoch.
• Hintergrundaufgaben sind auch umgezogen. Titel- und Zusammenfassungsgenerierung liest denselben Konversationsinhalt und läuft daher über denselben OpenRouter-Endpoint.

Die ehrlichen Ecken

Zwei Kompromisse, die man benennen sollte. Erstens: Nicht jedes Modell hat einen ungefilterten Pfad — Qwens gehostetes Flash-Tier existiert nur hinter Alibabas eigenem Upstream, also läuft im OpenRouter-Slot für Qwen die offene 27B-Variante — ein anderes Modell, und wir kennzeichnen es ehrlich. Zweitens bedeutet Pinnen, dass eine komplett ausgefallene Allowlist einen Fehler zurückgibt, statt auf einen gefilterten Pfad zu degradieren. Das ist eine bewusste Entscheidung: Ein sichtbarer Fehler schlägt einen unsichtbaren Ortswechsel.

Der größere ist philosophisch. Für ein internationales Produkt sollte der Standardpfad wahrscheinlich gar nicht die redaktionelle Linie irgendeiner einzelnen Jurisdiktion erben — nicht weil der Filter bösartig ist, sondern weil seine Definition von „sensibel" für ein anderes Publikum geschrieben wurde. Die Defaults gehen jetzt vom Kontext des Nutzers aus, nicht vom Kontext des Anbieters.