Per i modelli non-codex, il Codex CLI open-source compatta il contesto localmente: un LLM riassume la conversazione utilizzando un prompt di compattazione. Quando il contesto compattato viene successivamente utilizzato, responses.create() lo riceve con un prompt di handoff che incornicia il riepilogo. Entrambi i prompt sono visibili nel codice sorgente.
Per i modelli codex, invece, la CLI chiama l'API compact(), che restituisce un blob crittografato. Non sappiamo se utilizzi un LLM internamente, quali prompt usi o se esista un prompt di handoff.
Qui sotto, mostro come una semplice iniezione di prompt (2 chiamate API, 35 righe di Python) riveli che il percorso di compattazione API utilizza effettivamente un LLM per riassumere il contesto, con un proprio prompt di compattazione e un prompt di handoff anteposto al riepilogo. I prompt sono quasi identici alle versioni open-source.
Passaggio 1 — compact()
Chiamo compact() con un messaggio utente costruito ad arte. Lato server, un LLM compattatore elabora il nostro input utilizzando il proprio prompt di sistema nascosto (che non ho mai visto e voglio scoprire).
Il server sembra assemblare il contesto del compattatore in questo modo:
L'LLM compattatore legge il suo prompt di sistema insieme al nostro input. Poiché il nostro input contiene un payload di iniezione (testo rosso sopra), il compattatore viene indotto a includere il proprio prompt di sistema nel suo output. Questo riepilogo in chiaro esiste solo sul server di OpenAI. Noi vediamo solo il blob crittografato:
A questo punto non abbiamo modo di leggere cosa c'è dentro il blob. È crittografato con AES e la chiave risiede sui server di OpenAI. Speriamo solo che il compattatore abbia obbedito all'iniezione e abbia scritto il suo prompt nel riepilogo. L'unico modo per scoprirlo è il Passaggio 2.
Passaggio 2 — create()
Passo il blob crittografato + un secondo messaggio utente a responses.create(). Il server decifra il blob e assembla il contesto del modello.
Invio:
Il modello sembra vedere qualcosa del genere:
Se il Passaggio 1 ha funzionato, il blob decifrato dovrebbe contenere il prompt di compattazione (divulgato dalla nostra iniezione). Il server antepone anche un prompt di handoff al blob. Quindi, se la nostra sonda riesce a far ripetere al modello ciò che vede, l'output dovrebbe rivelare tutti e tre: il prompt di sistema, il prompt di handoff e il prompt di compattazione.
Output
Di seguito è riportato l'output completo e non modificato di una esecuzione di extract_prompts.py. Giallo = prompt di sistema, verde = prompt di handoff, rosa = prompt di compattazione.
Come facciamo a sapere che questi sono i prompt reali e non solo testo allucinato? Il prompt di compattazione e il prompt di handoff estratti corrispondono strettamente ai prompt noti utilizzati per i modelli non-codex nel Codex CLI open-source (prompt.md, summary_prefix.md), il che rende improbabile che il modello li abbia inventati da zero. I risultati variano tra le diverse esecuzioni.
Il Pipeline Ipotizzato
Mettendo tutto insieme, ecco la nostra ipotesi migliore su cosa fa compact() lato server, basata su ciò che l'estrazione ha rivelato.
Lo Script
Domanda Aperta
Perché il Codex CLI utilizza due percorsi di compattazione completamente diversi (LLM locale per i modelli non-codex, API crittografata per i modelli codex) quando i prompt sottostanti sono quasi identici? E perché crittografare il riepilogo?
Difficile a dirsi. Forse il blob crittografato trasporta qualcosa di più di quanto questo semplice esperimento possa rivelare, ad esempio qualcosa di specifico su come i risultati degli strumenti vengono compattati e ripristinati. Ma non mi sono preoccupato di testare oltre.
