Was eine einzelne Session kostet, gemessen auf beide Arten
Nehmen wir eine Droid-Session mit drei Aufgaben: Zurücksetzen eines Passwortsystems, Hinzufügen eines Copyright-Vermerks und Refactoring des Abrechnungsdienstes. Wenn alle drei mit einem frontier Claude-Modell wie Opus ausgeführt werden, kosten sie 0,84 $, 0,62 $ und 1,41 $, insgesamt 2,87 $ für die Session.
Leiten Sie sie stattdessen nach Komplexität weiter. Die ersten beiden sind Routineaufgaben, sodass sie auf effizienten Modellen auf 0,09 $ und 0,12 $ sinken, während das Refactoring mit 1,41 $ auf dem frontier Modell bleibt. Die Session kostet insgesamt 1,62 $, das gleiche Ergebnis für 43 % weniger, und die einzige Variable, die sich geändert hat, war, welches Modell welche Aufgabe bearbeitet hat.
Die meisten Engineering-Teams wählen ein Modell aus und lassen es dabei. Nicht, weil es optimal ist. Sondern weil ein Wechsel mitten in der Session verlorenen Kontext, zusätzliche Reibung und eine Entscheidung bedeutet, die niemand 40 Mal am Tag treffen möchte. Also wird alles auf das leistungsfähigste Modell gelenkt, das man sich leisten kann, und die Rechnung wird ignoriert.
Diese Standardeinstellung hat ihren Preis. Das teure Modell ist nicht die sichere Wahl. Es ist einfach die teure. Und die Qualitätslücke bei Routineaufgaben hat sich schnell genug geschlossen, sodass die Rechnung nicht mehr aufgeht.
Factory Router sitzt in ihrer Droids-Plattform und leitet jede Aufgabe automatisch weiter: Routineaufgaben an effiziente Modelle, komplexe Arbeiten an frontier Modelle, der gesamte Kontext wird bei jedem Wechsel mitgeführt. Die Session-Zahlen oben stammen aus ihrem Launch-Benchmark. Factory verkauft keine Modelle, was bedeutet, dass sie keinen strukturellen Anreiz haben, Sie auf dem teuren Pfad zu halten. Das ist erwähnenswert, wenn Sie die Zahlen lesen.
Das Problem, das niemand misst
Jede Droid-Session läuft auf einem Modell, und die meisten Teams wählen Opus und überdenken diese Wahl nie. Die Kosten dieser Standardeinstellung sind unsichtbar, weil sie sich nie als Fehler manifestieren. Die Arbeit wird erledigt, die Ausgabe ist gut, und die Rechnung ist einfach leise höher als nötig.
Die einzelne Session oben verschwendet etwa 1,25 $. Das fühlt sich nach nichts an, bis man es multipliziert. Bei 10.000 Sessions pro Monat verwandelt dieselbe Standardeinstellung 16.400 $ notwendige Ausgaben in 28.700 $ tatsächliche Ausgaben, was 147.600 $ pro Jahr sind, die dafür bezahlt werden, Routinearbeit durch ein frontier Modell zu leiten, das dafür nie erforderlich war.
Die meisten Teams stellen fest, dass 30 bis 50 Prozent ihrer Sessions Routinearbeit sind, die auf ihrem teuersten Modell läuft. Diese Lücke ist die gesamte Chance, und was folgt, sind fünfzehn Regeln in drei Abschnitten, um sie zu schließen.
→ Regel 1: Klassifizieren Sie Ihre Aufgabentypen vor allem anderen:
1Sehen Sie sich Ihre letzten 30 Droid-Aufgaben an. Sortieren Sie sie in zwei Gruppen:23Frontier-würdig: Aufgaben mit Systemarchitektur, Authentifizierung, Zahlungen, Sicherheit,4dienstübergreifenden Abhängigkeiten, alles bei dem ein Fehler Zeit fürs Debuggen oder5Rückgängigmachen kostet. Komplexe Refactorings über 100 Zeilen Geschäftslogik.67Routine: Dokumentationsupdates, Konfigurationsänderungen, Hinzufügen von Tests zu bestehenden Funktionen,8kleine Bugfixes mit klaren Spezifikationen, Copyright-Vermerke, README-Bearbeitungen,9Boilerplate-Generierung, einfache Migrationen.1011Zählen Sie jede Gruppe.1213Basierend auf Factorys Session-Level-Daten:14„Passwort zurücksetzen“-Aufgaben: Opus 0,84 $ vs. geroutet 0,09 $. 89 % günstiger.15„Copyright-Vermerk hinzufügen“-Aufgaben: Opus 0,62 $ vs. geroutet 0,12 $. 81 % günstiger.1617Multiplizieren Sie Ihre Anzahl an Routineaufgaben mit dieser Differenz.18Diese Lücke ist Ihre aktuelle Modellauswahlsteuer.
→ Regel 2: Messen Sie die tatsächlichen Ausgaben, nicht die Annahme:
1Ziehen Sie Ihre Droid-Session-Logs des letzten Monats.23Für jede Session:4- Aufgabentyp (aus Regel 1 Klassifizierung)5- Verwendetes Modell6- Kosten78Berechnen Sie:9- Gesamtausgaben für Routineaufgaben mit frontier Modellen10- Was diese Aufgaben auf effizienten Modellen kosten würden (80-90 % Reduktion anwenden)11- Monatliche Einsparungen durch Routing1213Dies ist Ihre Baseline vor Aktivierung von Factory Router.14Die meisten Teams stellen fest, dass 30-50 % der Sessions Routinearbeit auf frontier Modellen sind.
→ Regel 3: Schreiben Sie Aufgabenbeschreibungen, die Komplexität signalisieren:
1Die Art und Weise, wie Sie eine Aufgabe beschreiben, signalisiert ihre Komplexität an jedes Routing-System.23Niedrigkomplexitätssignale (leitet zu effizienten Modellen):4- "Einfaches Konfigurationsupdate, keine Geschäftslogik: Timeout in config.yaml von 30 auf 60 ändern"5- "Fehlende JSDoc-Kommentare zu den Hilfsfunktionen in /helpers hinzufügen"6- "README aktualisieren, um die neuen Deployment-Schritte widerzuspiegeln"78Hochkomplexitätssignale (leitet zu frontier):9- "Auth-Middleware umgestalten, um unsere neue SSO-Integration über 3 Dienste zu unterstützen"10- "Race-Condition im Zahlungsprozessor debuggen, die nur unter gleichzeitiger Last auftritt"11- "Ratenbegrenzungssystem neu gestalten, um tenant-spezifische Schwellenwerte zu handhaben"1213Spezifische, kontextreiche Aufgabenbeschreibungen verbessern die Routing-Genauigkeit.14Vage Beschreibungen werden konservativ zu frontier Modellen geroutet.
→ Regel 4: Berechnen Sie Ihren jährlichen Routing-ROI:
1Formel zur Schätzung der Factory Router-Einsparungen:23Monatliche Sessions: [N]4Durchschnittliche Kosten pro Session ohne Routing: [Opus-Baseline in $]5Routineaufgaben-Prozentsatz: [% aus Ihrem Regel-1-Audit]6Routinekostenreduktion: 80-90 %78Monatliche Einsparungsschätzung:9N × Baseline × Routine-% × 0,85 = monatlich zurückgewonnene Dollar1011Jährlich: mit 12 multiplizieren.1213Für ein Team mit 5.000 Sessions/Monat bei durchschnittlich 2,87 $ und 40 % Routinearbeit:145.000 × 2,87 $ × 0,40 × 0,85 = 4.879 $/Monat = 58.548 $/Jahr1516Dies ist das Minimum. Missions (langlaufende autonome Arbeit) potenzieren die Einsparungen weiter.
→ Regel 5: Dokumentieren Sie, was Nur-Frontier für Ihre Codebasis bedeutet:
1Bevor Sie Routing aktivieren, definieren Sie, was für Ihre Codebasis auf frontier Modellen bleiben muss.23Schreiben Sie dies einmal. Fügen Sie es als Ihre Routing-Guidance-Baseline ein:45"Das Folgende erfordert immer frontier Modelle:6- Alle Änderungen, die [Auth/Zahlungen/Sicherheitsebene] betreffen7- Dienstübergreifende Refactorings mit mehr als [N] Dateien8- Änderungen an der CI/CD-Pipeline-Konfiguration9- Datenbankschema-Migrationen10- Alles, das in unserem Issue-Tracker als [P0/kritisch] markiert ist1112Alles andere ist für das Routing zu effizienten Modellen geeignet."1314Dies wird Ihr Routing-Richtliniendokument.15Sie aktualisieren es, während Sie lernen, was in Ihrer spezifischen Codebasis eine frontier Behandlung benötigt.
Team von 10 Entwicklern, 1.000 Sessions/Monat, 40 % Routine: 13.776 $/Jahr zurückgewonnen Team von 50 Entwicklern, 5.000 Sessions/Monat, 40 % Routine: 58.548 $/Jahr zurückgewonnen Unternehmen (Nvidia, Adobe-Größenordnung): jährliche Einsparungen im sechsstelligen Bereich
zu vermeidender Fehler: Versuchen Sie nicht, jede Aufgabe manuell zu klassifizieren, bevor Sie Router aktivieren. Der Router übernimmt die Klassifizierung. Ihre Aufgabe ist es, die harten Regeln dafür zu definieren, was auf frontier bleiben muss, und das System um alles andere kümmern zu lassen.
0:28
→ Regel 6: Factory Router in einem Schritt aktivieren:
1In der Factory CLI oder Desktop-App:231. Öffnen Sie die Modellauswahl42. Wählen Sie "Factory Router"53. Fertig.67Keine Konfiguration erforderlich, um zu starten. Router verwendet sofort die Standard-Routing-Logik.89Um zu überprüfen, ob es aktiv ist:10Führen Sie eine einfache Aufgabe aus ("einen Kommentar in dieser Datei aktualisieren").11Überprüfen Sie das Session-Log auf die Modellzuordnung.12Sie sollten sehen, dass ein effizientes Modell die Aufgabe bearbeitet, nicht Opus.1314Wenn Sie Opus bei einer einfachen Aufgabe sehen, überprüfen Sie, ob Router ausgewählt ist und keine spezifische Modellüberschreibung vorliegt.
→ Regel 7: Routing-Guidance für Ihre Codebasis festlegen:
1Routing-Guidance ist beratend. Sie hilft dem Router, bessere Entscheidungen2für Ihre spezifische Codebasis zu treffen. Sie erzwingt kein Modell.34Fügen Sie dies als Ausgangspunkt für Ihre Routing-Guidance ein und bearbeiten Sie es für Ihren Stack:56"Auth-, Zahlungs- und Sicherheitsänderungen: frontier Modelle.7Datenbankmigrationen und Schemaänderungen: frontier Modelle.8API-Vertragsänderungen, die externe Verbraucher betreffen: frontier Modelle.910Dokumentationsaktualisierungen: effiziente Modelle.11Hinzufügen von Tests zu bestehenden Funktionen: effiziente Modelle.12Konfigurations- und Umgebungsvariablenänderungen: effiziente Modelle.13Boilerplate-Generierung und Gerüstbau: effiziente Modelle.14Code-Kommentare und JSDoc: effiziente Modelle.15README- und Changelog-Aktualisierungen: effiziente Modelle.1617Alles andere: Router entscheidet basierend auf dem Aufgabenkontext."
→ Regel 8: Routing-Guidance für Enterprise-Governance konfigurieren:
1Für Teams, die Agents in großem Maßstab betreiben, wird Routing-Guidance zu einem Governance-Dokument.23Standardvorlage für regulierte Branchen (Banken, Gesundheitswesen, Enterprise SaaS):45"Routing-Regeln für hohe Sensibilität:6- Alles, das [PII / Finanzdaten / Authentifizierung] betrifft = nur frontier7- Alle externen API-Änderungen = nur frontier8- Produktions-Deployment-Skripte = nur frontier9- Incident-Response-Aufgaben = nur frontier1011Standard-Routing:12- Entwicklungs-, Staging- und Testumgebungen = Router entscheidet13- Interne Tooling und Automatisierung = effiziente Modelle bevorzugt14- Dokumentation, Berichterstattung und Kommunikation = effiziente Modelle1516Überschreibungsrichtlinie:17Jeder Entwickler kann für eine Aufgabe frontier anfordern.18Router behandelt dies als harte Überschreibung, nicht als Beratung.19Alle Frontier-Überschreibungen für die monatliche Überprüfung protokollieren."2021Speichern Sie dies als ROUTING_POLICY.md im Stammverzeichnis Ihres Projekts.22Referenzieren Sie es in Ihrer CLAUDE.md oder einer entsprechenden Kontextdatei.
→ Regel 9: Missions mit aktiviertem Routing ausführen:
1Missions sind Factorys langlaufende autonome Aufgaben.2Stunden oder Tage Arbeit. Keine Aufsicht erforderlich.34Mit aktiviertem Factory Router profitieren Missions von derselben Routing-Logik.5Jeder Schritt in einer Mission wird angemessen geroutet.6Einfache Schritte in einer komplexen Mission laufen auf effizienten Modellen.7Die Mission zahlt Frontier-Tarife nur, wenn Frontier-Denken tatsächlich benötigt wird.89Zum Konfigurieren:10Aktivieren Sie Factory Router vor dem Start einer Mission.11Fügen Sie Routing-Guidance hinzu, die das Komplexitätsprofil der Mission widerspiegelt:1213"Diese Mission beinhaltet [hochkomplexe Kernarbeit] und [Routineunterstützungsaufgaben].14Kernarbeit (Architekturentscheidungen, Sicherheitsanalyse): frontier.15Unterstützungsarbeit (Dokumentation, Konfiguration, Boilerplate): effiziente Modelle.16Verwenden Sie das effizienteste verfügbare Modell für jeden Schritt,17der nicht das oben angegebene Denken erfordert."1819Lange Missions sehen proportional größere Einsparungen, da sie mehr Routineschritte ansammeln.
→ Regel 10: Provider-Failover-Richtlinie einrichten:
1Factory Router routet über Anbieter hinweg für Zuverlässigkeit.2Wenn ein Anbieterpfad nachlässt, werden Sessions über einen gesunden Anbieter fortgesetzt.34Für Enterprise-Teams mit Verfügbarkeitsanforderungen:56"Zuverlässigkeits-Routing-Richtlinie:7- Primärer Anbieter pro Modell: [Liste Ihrer bevorzugten Anbieter]8- Failover-Auslöser: jede Anfrage, die fehlschlägt oder [N] Sekunden Latenz überschreitet9- Failover-Verhalten: gleiches Modell, anderer Anbieter falls verfügbar.10 Wenn gleiches Modell nicht verfügbar, auf nächstes frontier Modell eskalieren.11- Dediziertes TPM: mit Factory-Kontoteam für Ihre Stufe bestätigen.12- Ziel: 99,9 %+ Anforderungszuverlässigkeit.1314Alle Failover-Ereignisse protokollieren. Wöchentlich auf Anbieter-Gesundheitsmuster überprüfen."
Terminal-Bench 2: 99 % der Opus-Bestehensquote bei 20 % niedrigeren Kosten Legacy-Bench: 96 % der Opus-Bestehensquote bei 25 % niedrigeren Kosten 99,9 %+ Anforderungszuverlässigkeit durch Provider-Routing
3 / 3 | DAS SYSTEM: Factory in der Größenordnung betreiben, in der sich Einsparungen summieren
Die Kosteneinsparungsgeschichte ist auf der Ebene einzelner Entwickler interessant. Sie wird auf Teamebene bedeutsam. Auf Unternehmensebene ist sie eine Budgetposition.
Nvidia. Adobe. EY. Palo Alto Networks. Adyen. Das sind Factorys Unternehmenskunden.
Ein Team mit 5.000 Sessions pro Monat gewinnt 58.548 $ pro Jahr allein durch Routing zurück, bei einer Routineaufgabenrate von 40 %. Ein Team mit 50.000 Sessions gewinnt 585.480 $ zurück. Die Rechnung skaliert linear mit dem Volumen. Die Token-Rechnungen von Unternehmen sind nicht linear.
Der tiefere Punkt betrifft die Architektur. Die meisten KI-Agentenplattformen basieren auf einer Ein-Modell-Annahme. Ein Team, ein Modell, ein Anbieter. Factorys Plattform ist von Natur aus modellagnostisch: jedes LLM (Claude, GPT, Gemini, Llama, Open Source), jede Oberfläche (CLI, Desktop, VS Code, Slack, GitHub, Linear, Jira, CI-Pipelines), jede Phase des Softwarelebenszyklus.
Router ist eine Schicht dieser Architektur. Es ist die Kosteneffizienz-Schicht. Derselbe Droid-Kontext, der in Ihrem Terminal funktioniert, funktioniert auch in Slack. Dieselbe Routing-Richtlinie, die für einzelne Sessions gilt, gilt auch für Missions, die tagelang laufen.
Die letzten fünf Regeln bauen das vollständige Factory-System um Router herum auf.
→ Regel 11: Routingeinsparungen wöchentlich messen:
1Richten Sie eine wöchentliche Routine ein, um die Router-Leistung zu verfolgen.23Überprüfen Sie in den Factory-Session-Logs:41. Gesamtzahl der Sessions diese Woche52. Modellverteilung (welcher Prozentsatz ging an jedes Modell)63. Kosten mit Routing vs. Baseline (Opus für alles)74. Alle Sessions, bei denen Router auf frontier eskalierte (Qualitätssignal)89Berichtsformat:10> Sessions: [N]11> Effiziente Modellnutzung: [%]12> Frontier-Modellnutzung: [%]13> Tatsächliche Ausgaben: $[Betrag]14> Baseline (alles Opus) wäre gewesen: $[berechnet]15> Wöchentliche Ersparnis: $[Betrag]16> Eskalationen zu frontier: [N] (zur Überprüfung auf Verbesserungen der Routing-Guidance)1718Wenn die Eskalationsrate über 10 % liegt, überprüfen Sie Ihre Routing-Guidance.19Zu viele Eskalationen bedeuten, dass Routineaufgaben als komplex beschrieben werden.
→ Regel 12: Agent Readiness-Bewertung vor vollständigem Rollout:
1Bevor Sie Factory Router für Ihr gesamtes Team bereitstellen, führen Sie Factorys Agent Readiness-Bewertung durch.23Sie bewertet 100+ Signale in den Bereichen:4- Codebasis-Gesundheit (Testabdeckung, CI-Zuverlässigkeit, Dokumentation)5- Workflow-Reife (PR-Prozess, Code-Review-Standards, Deployment-Pipeline)6- Team-Bereitschaft (Vertrautheit mit agentischen Tools, vorhandene Automatisierung)78Verwenden Sie die Ausgabe, um zu priorisieren, welche Workflows zuerst geroutet werden sollen.910Hochreife Workflows: Router sofort bereitstellen, vollständiges Routing aktiviert.11Mittelreife Workflows: Router mit konservativer Guidance bereitstellen, mehr frontier Aufgaben.12Niedrigreife Workflows: Bereitschaft vor dem Routing aufbauen.13Agentische Tools auf unvorbereiteten Codebasen verbringen mehr Zeit auf frontier Modellen zur Fehlerkorrektur.1415Router-Einsparungen sind in hochreifen Umgebungen am höchsten.
→ Regel 13: Bauen Sie Ihren Modell-Pool bewusst auf:
1Factory Router greift auf einen Pool von frontier und effizienten Modellen zu.2Der von Ihnen konfigurierte Pool beeinflusst die verfügbaren Routing-Optionen.34Empfohlener Start-Pool:56Frontier-Stufe (komplexe Arbeit):7- Claude Opus (neueste Version)8- GPT-5.2 (falls in Ihrer genehmigten Anbieterliste)910Effiziente Stufe (Routinearbeit):11- Kimi K2.6 (bestes Preis-Leistungs-Verhältnis pro F1-Punkt für Code-Aufgaben)12- MiniMax M2.7 (niedrigste Kosten für einfache Aufgaben)1314Fügen Sie Modelle hinzu, sobald Sie ihre Leistung auf Ihrer Codebasis validiert haben.15Beginnen Sie mit der zweistufigen Struktur.16Erweitern Sie auf drei Stufen (frontier / mittel / effizient), sobald Sie Routing-Daten haben.1718Dokumentieren Sie, welche Modelle für welche Compliance-Anforderungen genehmigt sind.19Wenn Ihr Unternehmen bestimmte Modellanbieter einschränkt, konfigurieren Sie den Pool entsprechend.20In den USA gehostete Open-Source-Modelle sind über Factory für Umgebungen verfügbar, die Datenresidenz erfordern.
→ Regel 14: Routing in Ihre CI-Pipeline integrieren:
1Factory funktioniert in CI-Pipelines. Routing gilt auch dort.23Fügen Sie Factory Router zu Ihrem GitHub Actions-Workflow hinzu:45Für Pull-Request-Reviews:6"PR-Review-Aufgaben nach Dateiänderungsumfang routen.7- Sicherheits- und Auth-Dateiänderungen: frontier Modelle8- Testdateien: effiziente Modelle9- Dokumentationsänderungen: effiziente Modelle10- Gemischte PRs: nach Möglichkeit abschnittsweise routen, andernfalls frontier für die gesamte Überprüfung"1112Für automatisierte QA:13"QA-Aufgaben nach Testkomplexität routen.14- Kritische Pfad-End-to-End-Tests: frontier Modelle15- Unit-Test-Generierung: effiziente Modelle16- Regressionstest-Suiten: effiziente Modelle"1718CI-Routing potenziert Einsparungen, da es bei jedem Commit läuft.19Der Kostenunterschied zwischen Opus und Kimi K2.6 bei der Testgenerierung über 100 tägliche Commits hinweg ist erheblich.
→ Regel 15: Monatliche Routing-Richtlinien-Reviews einrichten:
1Die Routing-Guidance sollte sich weiterentwickeln, wenn Ihre Codebasis und Ihr Team wachsen.23Monatliche Review-Agenda (30 Minuten):451. Kostenbericht: Ist vs. Baseline, Einsparungstrend62. Eskalationsanalyse: welche Aufgaben eskalierten und warum73. Aktualisierung der Routing-Guidance: spiegelt die aktuelle Guidance noch die Codebasis-Komplexität wider?84. Bewertung neuer Modelle: irgendwelche neuen Modelle im Pool, die hinzugefügt werden sollten?95. Team-Feedback: Überschreiben Entwickler häufig den Router? Warum?1011Fragen, die signalisieren, dass Ihre Routing-Guidance aktualisiert werden muss:12- Eskalationsrate über 15 %: Guidance ist zu aggressiv in Richtung effiziente Modelle13- Eskalationsrate unter 2 %: Guidance könnte zu konservativ sein und lässt Einsparungen liegen14- Entwickler-Überschreibungsrate über 20 %: Router entspricht nicht den Erwartungen der Entwickler1516ROUTING_POLICY.md nach jedem Review aktualisieren.
ohne Factory Router: jede Session läuft auf frontier, unabhängig vom Aufgabentyp mit Factory Router: Routineaufgaben auf effizienten Modellen, komplexe Aufgaben auf frontier Ergebnis: 20-43 % Kostensenkung bei Aufrechterhaltung von 96-99 % der Frontier-Benchmark-Leistung
FAZIT
Hier landet die Rechnung.
40-60 % der Engineering-Droid-Sessions sind Routineaufgaben in den meisten Teams diese Sessions mit Opus: durchschnittlich 2,87 $ pro Session diese Sessions mit Routing: durchschnittlich 1,62 $ bei 10.000 Sessions pro Monat: 147.600 $ pro Jahr zurückgewonnen
Die Benchmark-Zahlen halten: 99 % der Opus-Bestehensquote auf Terminal-Bench 2 bei 20 % niedrigeren Kosten. 96 % auf Legacy-Bench bei 25 % niedrigeren Kosten. Der Prompt-Cache bleibt über Modellwechsel hinweg intakt, sodass die Qualität nicht sinkt, wenn der Router mitten in der Session die Modelle wechselt. Provider-Failover hält Sessions mit einer Zuverlässigkeit von 99,9 %+ am Laufen.
Factory Router befindet sich in der privaten Research-Vorschau. Sie wählen ihn einmal in der Modellauswahl aus. Keine zusätzliche Einrichtung.
Was ich noch zu verstehen versuche: wie gut beratende Routing-Guidance über verschiedene Codebasis-Typen hinweg funktioniert. Regeln wie "Auth-Änderungen = frontier, Doc-Anpassungen = Routine" klingen auf dem Papier sauber. Was passiert, wenn eine Aufgabe in der Mitte liegt? Das ist der Grenzfall, den es zu beobachten gilt, wenn mehr Teams damit beginnen.
Die 15 Regeln oben sind das Einrichtungssystem. Beginnen Sie mit Regeln 1 und 6.
p.s. die Zeile, die die meisten überfliegen werden: Factory verkauft keine Modelle. Sie profitieren nicht von Ihrer Token-Rechnung. Dieser strukturelle Unterschied ist der Grund, warum ein solches Routing-System überhaupt existiert. Bin gespannt, was passiert, wenn mehr Modelle zum Pool hinzugefügt werden.
Merken Sie sich das, bevor es untergeht
Wenn das nützlich war, teilen Sie es mit einer Person, die es braucht
