Routing pesato sul costo

Quando sono disponibili più modelli — Opus, Sonnet, Haiku o modelli locali dietro un gateway odysseus self-hosted — PRECC instrada ogni attività verso quello che minimizza il costo atteso in dollari, non il numero di token. Un token di un modello economico e un token di uno costoso non hanno lo stesso costo; il router ottimizza il dollaro, soggetto a una soglia minima di successo misurata e a una soglia minima di capacità per categoria.

Il dollaro, non il token, è l’unità di costo

Per un’attività di categoria c, tra i modelli candidati m idonei per capacità, il router minimizza il costo atteso pesato sul prezzo. E[$ | task, m] è il costo medio in token misurato del modello per quella categoria moltiplicato per il suo prezzo per token. Un’esecuzione di Haiku che usa più token di Opus può comunque vincere, perché Haiku è diverse volte più economico per token. Ogni numero nell’obiettivo è misurato (medie di token dell’oracolo, successi registrati, prezzi dei modelli pubblicati) oppure un valore a priori esplicitamente etichettato — mai inventato.

choose argmin_m   E[$ | task, m]
       subject to  P(success | task, m) >= min_success
                   capability(m) >= capability_floor(category)

Instradare un’attività

precc route "<task>" categorizza l’attività, applica la soglia minima di capacità, classifica i modelli idonei in base ai dollari attesi e stampa la decisione. Con --execute invia l’attività al modello scelto tramite l’API di sessione di odysseus. Ogni decisione viene inoltre inizializzata nell’oracolo di predizione, così che il suo costo reale e l’esito possano essere registrati dopo l’esecuzione dell’attività.

$ precc route "fix the broken parser"
  category   : fix (capability floor 0)
  → model    : anthropic/claude-haiku-4-5  [Measured, confidence 0.60]
  est. cost  : $0.0096 (12000 tok)
  reason     : measured cheapest-capable for `fix` (by cost): claude-haiku-4-5
  prediction : #42 (seeded; learner will auto-close after the task runs)

Risparmi in dollari

precc savings aggiunge una sezione in dollari ogni volta che attività instradate sono state completate. Per ogni attività instradata calcola il prezzo dei token effettivamente spesi alla tariffa del modello scelto e li confronta con una linea di base sempre-modello-predefinito — i token restano fissi, varia solo il prezzo. Questa è la visione “taglia il costo, non solo i token”; la sezione resta nascosta finché non esistono dati reali instradati, così da non mostrare mai righe inventate.

$ precc savings
Routing cost (USD) — baseline: always claude-opus-4-5
  claude-haiku-4-5   :    1 task(s)  $   0.0096 chosen  vs $   0.0600 baseline
  claude-sonnet-4-6  :    1 task(s)  $   0.1200 chosen  vs $   0.2000 baseline
  total              :    2 task(s)  $   0.1296 chosen  vs $   0.2600 baseline
  → saved $0.1304 (50.2% of baseline spend)

Il ciclo di feedback

Il routing migliora se stesso: route → execute → record → retrain. Ogni decisione instradata viene inizializzata nell’oracolo; il daemon in background precc-learner recupera il messaggio completato, registra i token effettivi, il modello e il successo e chiude la riga. Man mano che la tabella per (model, category) si riempie, il router passa dai valori a priori più-economico-capace alle scelte misurate, e il predittore di token acquisisce una dimensione per modello.

Esplorazione

Per evitare di sfruttare per sempre un modello economico su dati obsoleti, il router può campionare deliberatamente una cella (model, category) poco esplorata prima della scelta greedy. L’esplorazione è opzionale, deterministica (nessuna casualità — il hook deve essere riproducibile) e limitata: non oltrepassa mai le soglie di capacità o di successo misurato, e un tetto sul rimpianto di prezzo le impedisce di deviare verso un modello molto più costoso.

# ~/.config/precc/odysseus.toml
explore_n_min = 3     # sample each (model, category) cell ~3× before trusting it
explore_eps   = 1.0   # allow up to 2× the cheapest price while exploring

Misurato, mai presunto

Un modello viene escluso per il mancato superamento della soglia di successo solo quando esistono prove misurate che ciò avvenga — un modello non misurato non viene mai escluso sulla base di un numero indovinato. In assenza di dati per una cella, il router ripiega su un conservativo valore a priori più-economico-capace ed etichetta la decisione come avvio a freddo, così che il chiamante sappia sempre se la scelta poggia su prove o su un valore a priori.

Keyboard shortcuts