Was es einen Agenten kostet, eine Ressourcendatei zu übersetzen

Die Frage

Ein Coding-Agent, der eine i18n-Ressourcendatei übersetzen soll, kann die Arbeit selbst erledigen oder die Datei einem Übersetzer übergeben, der auf demselben Rechner läuft. Der erste verbraucht API-Token für jeden Wert. Der zweite verbraucht für die Werte keine, und BetterTranslator schafft es ganz ohne Agenten in der Schleife. Der Benchmark misst, was jeder Weg kostet, an einer Datei, in Token, in ungefähren Dollar, in Anfragen und in Uhrzeit.

Drei Arme wurden gemessen, benannt so, wie die Artefakte sie benennen.

Ein vierter Weg, BetterTranslators eigenes Fenster oder bt translate ganz ohne Agenten, verbraucht konstruktionsbedingt null API-Token und wird in der Hochrechnung als Nullzeile geführt.

Wie der Test gebaut wurde

Ein Wert kommt für einen Ausschnitt in Frage, wenn er eine Zeichenkette aus 20 bis 180 Zeichen ohne Pluralisierungs-Pipe, HTML-Tag oder Zeilenumbruch ist und, sobald die Platzhalter-Token entfernt sind, noch mindestens 4 Wörter und 20 ASCII-Buchstaben enthält. Jeder ausgewählte Wert ist Fließtext, den ein Übersetzer ändern muss. Jeder Ausschnitt ist ein Präfix des nächstgrößeren. Der vollständige Quell-Hash lautet a8fdce5aba678743b2aac57a9b8c06405e41b836cd174051fc09357da648a633.

Hinweis zur Abrechnung: dieser Claude-Code-Build sendet keine OpenTelemetry-Metriken oder -Ereignisse, die Abrechnung je Anfrage wird also aus Claudes stream-json-usage-Blöcken und dem Ergebnisobjekt des Print-Modus gelesen. 4 Exporter-Konfigurationen wurden versucht, keine erzeugte Ausgabe. Als Gegenprobe vergleicht der Prüfstand beide Quellen je Lauf: 22 von 33 Läufen stimmen innerhalb von 2 Prozent überein, und die 11 abweichenden führen beide Zahlen in summary.csv.

Je Ausschnitt

Der dritte Arm, der Vollständigkeit halber. Bei 500 Schlüsseln wurde er auf Anweisung nicht ausgeführt.

Was das Delegieren ändert

Der delegierte Arm gegen den Agenten, der die Datei selbst übersetzt. Die Zeile mit 500 Schlüsseln ist nicht vergleichbar, weil der delegierte Arm keine Datei erzeugt hat.

Token und Geld ordnen diese Arme nicht gleich. In Token gibt es nirgends zwischen 10 und 500 Schlüsseln einen Schnittpunkt: der delegierte Weg kostet bei jedem gemessenen Ausschnitt mehr. In ungefähren Dollar kreuzen sich die beiden Linien bei etwa 87 Schlüsseln, weil der delegierte Weg frische Eingabe gegen Cache-Lesevorgänge tauscht und diese weit darunter abgerechnet werden. Bei 200 Schlüsseln ist der delegierte Weg der günstigere von beiden im Geld, obwohl er fast das Sechsfache an Token verbraucht.

Wohin die Token gehen: die Nutzlast bleibt tatsächlich aus dem Kontext heraus. Beim kleinsten Ausschnitt ist der gesamte MCP-Austausch 306 Bytes an Werkzeugargumenten und 707 Bytes an Werkzeugergebnissen gegenüber einer Eingabedatei von 1,205 Bytes, und die gesamte Werkzeugoberfläche fügt gegenüber dem Agentenweg 743 Token an Cache-Erzeugung hinzu. Der Preis ist die Anzahl der Anfragen. Jede job_status-Abfrage ist eine vollständige API-Anfrage, die das ganze Gespräch erneut abspielt, die Rechnung dieses Arms bestimmt also, wie oft er fragt, ob das lokale Modell fertig ist: 7.0 Anfragen bei 10 Schlüsseln, 26.5 bei 200. Der angepasste Boden mit einer leeren Datei liegt bei 244,502 Token. Halten Sie alles andere konstant und geben Sie dem Arm die Anfragezahl des Agentenwegs, wie es ein blockierender Aufruf oder ein Wartewerkzeug täte, und dieselbe Arbeit über 200 Schlüssel landet nahe 183,575 Token gegenüber 195,574. Die letzte Zahl ist Arithmetik auf gemessenen Kosten je Anfrage, kein gemessener Lauf.

Die ganze Datei

Hochgerechnet, nicht gemessen: die Datei mit 4,666 Schlüsseln passt nicht in ein Kontextfenster, die Hochrechnung wiederholt daher den größten gemessenen Ausschnitt, 200 Schlüssel, als 24 Stücke. Es ist Arithmetik über gemessene Läufe.

Zwei Zellen werden zurückgehalten. Die Anfragezahl von mcp-value hat bei 200 Schlüsseln keine Grundlage, die das Tor besteht, da beide Wiederholungen auf ein anderes Modell zurückgefallen sind. Die lokale Uhrzeit wird zurückgehalten, weil die Artefakte einander widersprechen.

Die Zeile mcp-path ist im Geld nur oberhalb des Break-even bei 87 Schlüsseln günstiger als der Agentenweg, und sie erreicht diesen Preis mit 27,361,836 Token gegenüber 4,693,764. Die mcp-value-Hochrechnung stützt sich auf Läufe, die das Tor ausgeschlossen hat, und ist als Obergrenze zu lesen, nicht als Ergebnis.

Das Fairness-Tor

Ein Lauf besteht nur, wenn seine Ausgabedatei ein JSON-Objekt ist, dessen Schlüsselsatz und Schlüsselreihenfolge exakt zum Ausschnitt passen, dessen Werte alle nicht leere Zeichenketten sind, dessen Platzhalter-Multimenge je Wert der Quelle entspricht und von dessen Werten keiner seiner Quelle gleicht. Die letzte Prüfung hat eine Ausnahme: ein Wert darf seiner Quelle gleichen, wenn jedes alphabetische Wort darin eine freigegebene Marke, ein Protokoll oder ein Gebietsschema-Token ist oder mit einem Großbuchstaben beginnt, was Produktnamen und großgeschriebene Eigennamen abdeckt, oder wenn der Wert eine Kommandozeile mit einem Programmnamen oder einer langen Option ist.

Über alle 33 aufgezeichneten Läufe meldet summary.csv 0 Fehler im Schlüsselsatz, 0 Fehler in der Schlüsselreihenfolge und 0 Fehler bei Platzhaltern. 29 der 33 Läufe haben überhaupt eine Datei geliefert. Jeder Ausschluss unten ist ein unübersetzter Wert, ein Modellwechsel, ein Sitzungslimit oder eine fehlende Datei.

Von 33 Läufen haben 33 eine Anfrage abgerechnet, 1 endeten am Sitzungslimit des Kontos und 3 sind vom angeforderten Modell auf ein anderes zurückgefallen, was diese unvergleichbar macht.

Grenzen

Der MCP-Server kostet mehr Token, nicht weniger. Bei jedem gemessenen Ausschnitt verbrauchte er mehr als der Agent, der die Datei selbst übersetzt: 137.1 Prozent mehr bei 10 Schlüsseln, 337.2 Prozent bei 50, 482.9 Prozent bei 200. Sein belegter Vorteil ist Geld oberhalb des Break-even bei 87 Schlüsseln, und dieser Vorteil besteht, weil Cache-Lesevorgänge unter frischer Eingabe abgerechnet werden. Es ist keine Token-Ersparnis und wird in keiner hier gemessenen Größe zu einer.

Es gibt kein Qualitätsurteil. Nichts in diesem Lauf bewertet Angemessenheit, Sprachfluss oder Bedeutung. Die einzige Messung auf Wertebene ist, ob ein Ausgabewert sich von seiner Quelle unterscheidet. Auf den Ausschnitten, auf denen sie gemessen wurde, ließ die lokale Engine 2.3 Prozent der Werte auf Englisch. Der Agentenweg bestand das Tor bei jedem Ausschnitt. Dieser Vergleich erfasst unübersetzte Werte und sonst nichts. Jede Aussage darüber, wie gut eine der beiden Seiten übersetzt, liegt außerhalb dieser Artefakte.

Der delegierte Weg erzeugte bei 500 Schlüsseln keine Datei. Alle 3 Wiederholungen haben Anfragen abgerechnet und nichts geliefert. Der Agent hörte auf zu warten, während der lokale Auftrag noch lief, und der MCP-Server stirbt mit der Sitzung, die ihn gestartet hat, die fertige Arbeit wurde also weggeworfen. Diese Läufe sind ein Lieferausfall und kein günstiges Ergebnis, deshalb sind sie aus der Differenztabelle ausgeschlossen und deshalb hat der größte Ausschnitt keinen direkten Vergleichswert.

Die Zahlen für die ganze Datei sind Hochrechnungen. Kein Lauf hat je alle 4,666 Schlüssel unter Messung übersetzt. Die Hochrechnung multipliziert den Ausschnitt mit 200 Schlüsseln mit 24. Eine andere Aufteilung, oder ein Kontext- oder Sitzungslimit auf halbem Weg, ändert das Ergebnis.

Dünne Wiederholungen. Zwei vergleichbare Wiederholungen je Zelle, weil Wiederholung 1 als Cache-Aufwärmung ausgeschlossen ist. Der Bericht markiert die Zellen mit großer Streuung: den Agentenweg bei 500 Schlüsseln (15.0 Prozent), mcp-value bei 10 Schlüsseln (32.7 Prozent) und bei 50 Schlüsseln (48.0 Prozent).

Eine Datei, ein Paar, ein Rechner. Eine einzige en.json, aus dem Englischen ins Tschechische übersetzt, auf einem Windows-Host, mit einem lokalen Modell in einer Quantisierung, gegen eine CLI-Version und ein Claude-Modell. Beide Seiten dieses Vergleichs bewegen sich über die Zeit.

Das nachvollziehen

btbench prepare --source <path to en.json> --model claude-opus-5 --sizes 10,50,200,500
btbench run --run <run-id> --arms direct,mcp-path --reps 3
btbench collect --run <run-id>
btbench compare --run <run-id>

prepare sondiert den MCP-Server, hasht die Quelle und schneidet die Ausschnitte. run führt jeden Arm und jede Wiederholung in einer frischen Sitzung aus. collect leitet summary.csv erneut aus den Transkripten ab. compare schreibt compare.md. Der Orchestrator ist ein .NET-Projekt, das zu btbench gebaut wird.

Die Artefakte

Jede Zahl oben löst sich auf eine dieser Dateien auf, auf den Abschnitt, die Tabellenzeile und die Spalte, die das Register festhält. Die vier, auf die sich die Zahlen berufen, reisen mit der Website, damit die Prüfung offline läuft.