Flint è un modello testuale Recursive sviluppato per agenti software: esplorazione della base di codice, correzione degli errori, implementazione di funzioni e scrittura di test. È un modello MoE con pesi aperti: dei 39,8 miliardi di parametri si attivano circa 2,5 miliardi nell’elaborazione di un token. La suddivisione in esperti è parte della sua architettura, non indica più assistenti distinti nella chat.
Allo sviluppo di Flint ha partecipato Eureka Machine, sistema di ricerca di Recursive. Ha aiutato a cercare soluzioni architetturali, scegliere dati e metodi di addestramento e ottimizzare i calcoli. Flint ha attraversato pre-addestramento, addestramento intermedio, addestramento su esempi di istruzioni e apprendimento con rinforzo. I compiti di addestramento comprendevano testo, codice, rispetto delle istruzioni e scenari agentici.
Conviene iniziare l’attività da una parte concreta del progetto: inviare i file necessari come testo, descrivere lo scopo delle funzioni e il risultato atteso. Per cercare un errore, aggiungere il comportamento osservato e un estratto del log. Si può poi chiedere la spiegazione della causa, una correzione minima e un test che distingua il comportamento corretto dall’errore. Questa sequenza rende il risultato comodo da verificare successivamente nel proprio ambiente.
Per una nuova funzione indicare dati in ingresso, vincoli ed esempi del risultato. Nel refactoring elencare le proprietà da conservare e chiedere una descrizione separata delle modifiche alle interfacce. Lo sviluppatore raccomanda di dividere il lavoro complesso in piccoli sottocompiti e fornire istruzioni esplicite. Un dialogo progressivo con risultati intermedi corrisponde quindi all’uso previsto di Flint meglio di un incarico indefinito di rifare l’intero progetto.
In Ailoot Flint lavora con testo in ingresso e in uscita. La finestra di contesto è di 262 144 token; materiali iniziali, cronologia e risposta usano questo spazio comune. Il limite di uscita indicato è di 235 929 token. Questi valori descrivono i confini del collegamento, mentre la lunghezza effettiva va definita in base al compito: spiegazione di un errore, patch, insieme di test o piano di lavoro.
Sono disponibili i formati Messages, Responses e Chat Completions. Permettono di usare la struttura abituale dell’applicazione client. Lettura dei file locali e applicazione delle modifiche sono organizzate dall’applicazione stessa: nella richiesta testuale il modello riceve il codice fornito e restituisce proposte, spiegazioni o nuovo codice.
Flint è adatto a un dialogo tecnico iterativo, in cui ogni passo successivo si basa sul contenuto del progetto e sull’esito della verifica della modifica precedente. La sua specializzazione aiuta a definire il compito, mentre il risultato operativo è un testo concreto: spiegazione, implementazione o test verificabile.
", "aboutText": "### Un modello per lavorare sul codice\n\nFlint è un modello testuale Recursive sviluppato per agenti software: esplorazione della base di codice, correzione degli errori, implementazione di funzioni e scrittura di test. È un modello MoE con pesi aperti: dei 39,8 miliardi di parametri si attivano circa 2,5 miliardi nell’elaborazione di un token. La suddivisione in esperti è parte della sua architettura, non indica più assistenti distinti nella chat.\n\nAllo sviluppo di Flint ha partecipato Eureka Machine, sistema di ricerca di Recursive. Ha aiutato a cercare soluzioni architetturali, scegliere dati e metodi di addestramento e ottimizzare i calcoli. Flint ha attraversato pre-addestramento, addestramento intermedio, addestramento su esempi di istruzioni e apprendimento con rinforzo. I compiti di addestramento comprendevano testo, codice, rispetto delle istruzioni e scenari agentici.\n\n### Analisi del progetto e preparazione delle modifiche\n\nConviene iniziare l’attività da una parte concreta del progetto: inviare i file necessari come testo, descrivere lo scopo delle funzioni e il risultato atteso. Per cercare un errore, aggiungere il comportamento osservato e un estratto del log. Si può poi chiedere la spiegazione della causa, una correzione minima e un test che distingua il comportamento corretto dall’errore. Questa sequenza rende il risultato comodo da verificare successivamente nel proprio ambiente.\n\nPer una nuova funzione indicare dati in ingresso, vincoli ed esempi del risultato. Nel refactoring elencare le proprietà da conservare e chiedere una descrizione separata delle modifiche alle interfacce. Lo sviluppatore raccomanda di dividere il lavoro complesso in piccoli sottocompiti e fornire istruzioni esplicite. Un dialogo progressivo con risultati intermedi corrisponde quindi all’uso previsto di Flint meglio di un incarico indefinito di rifare l’intero progetto.\n\n### Contesto e formato di collegamento\n\nIn Ailoot Flint lavora con testo in ingresso e in uscita. La finestra di contesto è di 262 144 token; materiali iniziali, cronologia e risposta usano questo spazio comune. Il limite di uscita indicato è di 235 929 token. Questi valori descrivono i confini del collegamento, mentre la lunghezza effettiva va definita in base al compito: spiegazione di un errore, patch, insieme di test o piano di lavoro.\n\nSono disponibili i formati Messages, Responses e Chat Completions. Permettono di usare la struttura abituale dell’applicazione client. Lettura dei file locali e applicazione delle modifiche sono organizzate dall’applicazione stessa: nella richiesta testuale il modello riceve il codice fornito e restituisce proposte, spiegazioni o nuovo codice.\n\nFlint è adatto a un dialogo tecnico iterativo, in cui ogni passo successivo si basa sul contenuto del progetto e sull’esito della verifica della modifica precedente. La sua specializzazione aiuta a definire il compito, mentre il risultato operativo è un testo concreto: spiegazione, implementazione o test verificabile.", "locale": "it", "methods": [ { "html": "POST /v1/messagestexttextPOST /v1/responsestexttextPOST /v1/chat/completionstexttext