Jedna nazwa przed każdym modelem, który uruchamiasz.

Routing to decyzja, a nie model. Klient prosi o dynamic/support, a reguły, które ustawiasz, wybierają model odpowiadający na to konkretne wywołanie.

Decyzja rysowana, nie kodowana
Routing to graf z kilku kroków: warunek, podział, limit, model, odmowa. Jest zapisany jako dane i sprawdzany przed zapisem, więc powstaje w formularzu, a nie w języku wyrażeń, którego trzeba się nauczyć.
Warunki na tym, co wywołanie już niesie
Klucz, osoba, deklarowany cel, żądany model, długość promptu, długość ostatniej wiadomości, obecność obrazów oraz liczba wywołań na sekundę dla tego klucza, tej osoby i tej organizacji. Nic, o czym wiedziałaby dopiero odpowiedź.
Limity, które kierują, zamiast odmawiać
Limit tempa i limit budżetu mają po dwa wyjścia: w limicie i po przekroczeniu. Ruch ponad pułap idzie do tańszego modelu albo do odmowy zapisanej w routingu, zamiast wydawać to, czego nikt nie zaplanował.
Zapas i sposób, żeby to sprawdzić
Każdy model w routingu ma gałąź na wypadek błędu, więc odmowa dostawcy nie kończy wywołania. A dynamic/beta/nazwa uruchamia graf, który wciąż jest edytowany, na prawdziwym ruchu z klienta testowego, zanim ktokolwiek postawi go przed wszystkimi.

Odpowiedź podaje we własnych nagłówkach, który routing zadecydował i którą ścieżką poszedł
W routingu można postawić tylko modele włączone w tej organizacji
Odmowa wraca w standardowym formacie błędu, ze statusem, zdaniem i kodem wybranym przez autora
Każde wdrożenie to wersja, a wcześniejszą można przywrócić
Routing zdjęty z list modeli nadal odpowiada integracjom, które już go wołają

Co dostaje zespół

Pięć części, jedno konto, jeden zestaw uprawnień.

Skieruj klienta testowego na adres szkicu, odczytaj ścieżkę z odpowiedzi i wdroż.