North Mini Code 1.0 è il modello di Cohere per ingegneria del software agentica, attività da terminale e generazione di codice. Riceve testo e produce testo, inclusi codice, spiegazioni e richieste a strumenti. Il produttore ne ha rilasciato i pesi con licenza Apache 2.0 e lo identifica come primo modello nella famiglia North di agenti di programmazione. È un profilo specializzato nella programmazione, non un modello di comprensione delle immagini o un valutatore generico di decisioni.
Il modello ha 30 miliardi di parametri totali con circa 3 miliardi attivi. Il suo Transformer decoder-only usa una Mixture of Experts sparsa con 128 esperti, otto attivati per token, e un livello denso prima dei livelli sparsi. L'attenzione a finestra scorrevole con posizioni rotatorie è intercalata con attenzione globale senza embedding posizionali in rapporto 3:1. Il numero di parametri attivi descrive il calcolo usato per un token, non l'insieme totale dei pesi da memorizzare.
Il post-addestramento di Cohere usa due fasi di fine-tuning supervisionato seguite da apprendimento per rinforzo con ricompense verificabili, concentrandosi su ingegneria del software e lavoro da terminale. Il produttore descrive un addestramento su più sistemi di esecuzione per agenti invece che su un'unica struttura fissa. Questo favorisce la preparazione di un'attività attorno al comportamento richiesto e agli strumenti disponibili, mentre il sistema circostante resta responsabile di ottenere i file, eseguire i comandi e restituire le osservazioni.
Fornisci il codice e il comportamento attuali, la modifica richiesta, i confini pertinenti dei file o delle interfacce e le prove che stabiliranno il completamento. Per un bug, includi l'errore osservato o l'input che fallisce e il risultato atteso. Per una funzionalità, indica il comportamento richiesto e i vincoli di compatibilità. Un artefatto finale utile è una modifica di codice proposta con una spiegazione e i risultati delle verifiche effettivamente eseguite.
Una richiesta esemplificativa può chiedere di aggiornare un parser per un ulteriore input supportato mantenendo i formati esistenti. Identifica gli input rappresentativi e la parte del repository che definisce il comportamento del parser. Il modello può usare codice e osservazioni degli strumenti per sviluppare la modifica; una patch generata o l'affermazione che un comando dovrebbe funzionare non dimostra che il comando sia riuscito.
La scheda nativa del modello documenta l'addestramento all'uso di strumenti e consiglia descrizioni in JSON Schema tramite il template di chat del modello. Descrivi chiaramente lo scopo e gli argomenti di uno strumento. Uno strumento di esecuzione di comandi può restituire output e stato effettivi, mentre uno strumento di ispezione dei file può restituire il materiale necessario al passaggio successivo. Mantieni ogni risultato associato al suo identificatore di chiamata, così che l'analisi successiva usi l'osservazione prevista.
L'esempio del produttore conserva nella cronologia una chiamata a uno strumento e il ragionamento dell'assistente, esegue lo strumento e aggiunge il risultato prima di generare di nuovo. Il suo esempio di template nativo usa un dizionario strutturato per il risultato dello strumento. Preserva tale rappresentazione secondo l'integrazione documentata, senza presumere che ogni API non correlata serializzi allo stesso modo i risultati degli strumenti. Uno schema JSON che descrive gli argomenti di uno strumento è diverso dall'affermare il supporto per output finali vincolati da schemi arbitrari.
North Mini Code supporta il ragionamento intercalato, che il produttore consiglia di abilitare per il lavoro agentico. Trasferisci il contenuto di ragionamento generato dal modello e le chiamate agli strumenti nei passaggi successivi dell'agente e nei turni della conversazione. L'esempio nativo mantiene un campo reasoning nel messaggio dell'assistente e restituisce in seguito l'osservazione corrispondente dello strumento. Questo preserva le informazioni usate dal modello per decidere cosa esaminare o modificare successivamente.
Mantieni nella cronologia l'obiettivo corrente, il materiale di partenza e le osservazioni effettive. Per un'attività di repository più lunga, riassumi il risultato finale attorno al comportamento modificato e all'artefatto utile, conservando le prove necessarie alla revisione. Il ragionamento intercalato non implica che una risposta visibile breve non abbia richiesto analisi, né stabilisce che un'azione descritta dal modello sia già avvenuta.
Il produttore identifica anche programmazione scientifica e ragionamento algoritmico al di fuori di un ciclo agentico. Fornisci la definizione del problema, il formato di input e output, i vincoli, le ipotesi numeriche pertinenti e il comportamento atteso nei casi limite. Chiedi una funzione o un programma completo quando è l'artefatto necessario, con una spiegazione al livello richiesto dal lettore.
Per la spiegazione del codice, fornisci l'implementazione e il comportamento o la dipendenza specifica da chiarire. Per il codice di visualizzazione dei dati, identifica i campi forniti e il confronto previsto, evitando di lasciare implicito lo scopo del grafico. Gli esempi di sviluppo del produttore comprendono spiegazione e modifica del codice, visualizzazione dei dati e implementazione a partire da una specifica. Sono schemi di attività per generare o modificare codice, non promesse di risultati corretti per ogni repository o framework.
La scheda del modello e la pagina API del produttore elencano una finestra di contesto di 256K token e un output massimo di 64K token. Prepara materiale sostanziale del repository tenendo conto di questi limiti separati e delle dimensioni dell'artefatto finale. Mantieni intatti i confini e gli identificatori delle fonti ed elimina il materiale irrilevante, senza presumere che una finestra ampia elimini la necessità di un brief mirato.
La scheda nativa del modello consiglia temperature 1.0 e top_p 0.95 per la generazione e usa il template di chat del modello, incluso un prompt di generazione, per i flussi testuali e con strumenti. I limiti di output degli esempi sono impostazioni di quegli esempi, non sostituti del massimo pubblicato del modello. Cohere pubblica pesi BF16 e un artefatto FP8 con nome distinto. Seleziona l'artefatto appropriato quando prepari un deployment.
Un risultato utile di North Mini Code è un artefatto di codice esaminabile o una spiegazione tecnica collegata ai requisiti forniti. Confronta il risultato con il comportamento originale e con l'output effettivo degli strumenti, verifica le ipotesi che influiscono sul codice e conserva le fonti e le osservazioni necessarie alla revisione. Il modello di programmazione esclusivamente testuale fornisce ragionamento e contenuto generato; l'applicazione circostante esegue le operazioni che trasformano quelle proposte in un'attività software completata.
", "aboutText": "North Mini Code 1.0 è il modello di Cohere per ingegneria del software agentica, attività da terminale e generazione di codice. Riceve testo e produce testo, inclusi codice, spiegazioni e richieste a strumenti. Il produttore ne ha rilasciato i pesi con licenza Apache 2.0 e lo identifica come primo modello nella famiglia North di agenti di programmazione. È un profilo specializzato nella programmazione, non un modello di comprensione delle immagini o un valutatore generico di decisioni.\n\n### Architettura sparsa e preparazione delle attività di programmazione\n\nIl modello ha 30 miliardi di parametri totali con circa 3 miliardi attivi. Il suo Transformer decoder-only usa una Mixture of Experts sparsa con 128 esperti, otto attivati per token, e un livello denso prima dei livelli sparsi. L'attenzione a finestra scorrevole con posizioni rotatorie è intercalata con attenzione globale senza embedding posizionali in rapporto 3:1. Il numero di parametri attivi descrive il calcolo usato per un token, non l'insieme totale dei pesi da memorizzare.\n\nIl post-addestramento di Cohere usa due fasi di fine-tuning supervisionato seguite da apprendimento per rinforzo con ricompense verificabili, concentrandosi su ingegneria del software e lavoro da terminale. Il produttore descrive un addestramento su più sistemi di esecuzione per agenti invece che su un'unica struttura fissa. Questo favorisce la preparazione di un'attività attorno al comportamento richiesto e agli strumenti disponibili, mentre il sistema circostante resta responsabile di ottenere i file, eseguire i comandi e restituire le osservazioni.\n\n### Prepara una modifica a livello di repository\n\nFornisci il codice e il comportamento attuali, la modifica richiesta, i confini pertinenti dei file o delle interfacce e le prove che stabiliranno il completamento. Per un bug, includi l'errore osservato o l'input che fallisce e il risultato atteso. Per una funzionalità, indica il comportamento richiesto e i vincoli di compatibilità. Un artefatto finale utile è una modifica di codice proposta con una spiegazione e i risultati delle verifiche effettivamente eseguite.\n\nUna richiesta esemplificativa può chiedere di aggiornare un parser per un ulteriore input supportato mantenendo i formati esistenti. Identifica gli input rappresentativi e la parte del repository che definisce il comportamento del parser. Il modello può usare codice e osservazioni degli strumenti per sviluppare la modifica; una patch generata o l'affermazione che un comando dovrebbe funzionare non dimostra che il comando sia riuscito.\n\n### Strumenti del terminale e osservazioni strutturate\n\nLa scheda nativa del modello documenta l'addestramento all'uso di strumenti e consiglia descrizioni in JSON Schema tramite il template di chat del modello. Descrivi chiaramente lo scopo e gli argomenti di uno strumento. Uno strumento di esecuzione di comandi può restituire output e stato effettivi, mentre uno strumento di ispezione dei file può restituire il materiale necessario al passaggio successivo. Mantieni ogni risultato associato al suo identificatore di chiamata, così che l'analisi successiva usi l'osservazione prevista.\n\nL'esempio del produttore conserva nella cronologia una chiamata a uno strumento e il ragionamento dell'assistente, esegue lo strumento e aggiunge il risultato prima di generare di nuovo. Il suo esempio di template nativo usa un dizionario strutturato per il risultato dello strumento. Preserva tale rappresentazione secondo l'integrazione documentata, senza presumere che ogni API non correlata serializzi allo stesso modo i risultati degli strumenti. Uno schema JSON che descrive gli argomenti di uno strumento è diverso dall'affermare il supporto per output finali vincolati da schemi arbitrari.\n\n### Ragionamento intercalato e cronologia su più turni\n\nNorth Mini Code supporta il ragionamento intercalato, che il produttore consiglia di abilitare per il lavoro agentico. Trasferisci il contenuto di ragionamento generato dal modello e le chiamate agli strumenti nei passaggi successivi dell'agente e nei turni della conversazione. L'esempio nativo mantiene un campo reasoning nel messaggio dell'assistente e restituisce in seguito l'osservazione corrispondente dello strumento. Questo preserva le informazioni usate dal modello per decidere cosa esaminare o modificare successivamente.\n\nMantieni nella cronologia l'obiettivo corrente, il materiale di partenza e le osservazioni effettive. Per un'attività di repository più lunga, riassumi il risultato finale attorno al comportamento modificato e all'artefatto utile, conservando le prove necessarie alla revisione. Il ragionamento intercalato non implica che una risposta visibile breve non abbia richiesto analisi, né stabilisce che un'azione descritta dal modello sia già avvenuta.\n\n### Attività autonome di programmazione e spiegazione\n\nIl produttore identifica anche programmazione scientifica e ragionamento algoritmico al di fuori di un ciclo agentico. Fornisci la definizione del problema, il formato di input e output, i vincoli, le ipotesi numeriche pertinenti e il comportamento atteso nei casi limite. Chiedi una funzione o un programma completo quando è l'artefatto necessario, con una spiegazione al livello richiesto dal lettore.\n\nPer la spiegazione del codice, fornisci l'implementazione e il comportamento o la dipendenza specifica da chiarire. Per il codice di visualizzazione dei dati, identifica i campi forniti e il confronto previsto, evitando di lasciare implicito lo scopo del grafico. Gli esempi di sviluppo del produttore comprendono spiegazione e modifica del codice, visualizzazione dei dati e implementazione a partire da una specifica. Sono schemi di attività per generare o modificare codice, non promesse di risultati corretti per ogni repository o framework.\n\n### Contesto, output e impostazioni di generazione\n\nLa scheda del modello e la pagina API del produttore elencano una finestra di contesto di 256K token e un output massimo di 64K token. Prepara materiale sostanziale del repository tenendo conto di questi limiti separati e delle dimensioni dell'artefatto finale. Mantieni intatti i confini e gli identificatori delle fonti ed elimina il materiale irrilevante, senza presumere che una finestra ampia elimini la necessità di un brief mirato.\n\nLa scheda nativa del modello consiglia temperature 1.0 e top_p 0.95 per la generazione e usa il template di chat del modello, incluso un prompt di generazione, per i flussi testuali e con strumenti. I limiti di output degli esempi sono impostazioni di quegli esempi, non sostituti del massimo pubblicato del modello. Cohere pubblica pesi BF16 e un artefatto FP8 con nome distinto. Seleziona l'artefatto appropriato quando prepari un deployment.\n\nUn risultato utile di North Mini Code è un artefatto di codice esaminabile o una spiegazione tecnica collegata ai requisiti forniti. Confronta il risultato con il comportamento originale e con l'output effettivo degli strumenti, verifica le ipotesi che influiscono sul codice e conserva le fonti e le osservazioni necessarie alla revisione. Il modello di programmazione esclusivamente testuale fornisce ragionamento e contenuto generato; l'applicazione circostante esegue le operazioni che trasformano quelle proposte in un'attività software completata.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "ddfe4f249d9b6f80c24e7188791d6d90c1edc9d8ee67249a319d88dc09ad48a4", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "it", "methods": [ { "html": "cohere/north-mini-code:freeNorth Mini Code 1.0 è il modello esclusivamente testuale di Cohere per generazione di codice, modifiche ai repository e attività da agente tramite terminale. Il suo design sparso con 30B parametri totali e 3B attivi supporta uso di strumenti e ragionamento intercalato, con un contesto documentato di 256K e un limite di output di 64K.
Questa descrizione illustra le funzionalità del modello. Gli input, gli output e le opzioni disponibili in Ailoot per il metodo selezionato sono elencati di seguito.
North Mini Code 1.0 è il modello di Cohere per ingegneria del software agentica, attività da terminale e generazione di codice. Riceve testo e produce testo, inclusi codice, spiegazioni e richieste a strumenti. Il produttore ne ha rilasciato i pesi con licenza Apache 2.0 e lo identifica come primo modello nella famiglia North di agenti di programmazione. È un profilo specializzato nella programmazione, non un modello di comprensione delle immagini o un valutatore generico di decisioni.
Il modello ha 30 miliardi di parametri totali con circa 3 miliardi attivi. Il suo Transformer decoder-only usa una Mixture of Experts sparsa con 128 esperti, otto attivati per token, e un livello denso prima dei livelli sparsi. L'attenzione a finestra scorrevole con posizioni rotatorie è intercalata con attenzione globale senza embedding posizionali in rapporto 3:1. Il numero di parametri attivi descrive il calcolo usato per un token, non l'insieme totale dei pesi da memorizzare.
Il post-addestramento di Cohere usa due fasi di fine-tuning supervisionato seguite da apprendimento per rinforzo con ricompense verificabili, concentrandosi su ingegneria del software e lavoro da terminale. Il produttore descrive un addestramento su più sistemi di esecuzione per agenti invece che su un'unica struttura fissa. Questo favorisce la preparazione di un'attività attorno al comportamento richiesto e agli strumenti disponibili, mentre il sistema circostante resta responsabile di ottenere i file, eseguire i comandi e restituire le osservazioni.
Fornisci il codice e il comportamento attuali, la modifica richiesta, i confini pertinenti dei file o delle interfacce e le prove che stabiliranno il completamento. Per un bug, includi l'errore osservato o l'input che fallisce e il risultato atteso. Per una funzionalità, indica il comportamento richiesto e i vincoli di compatibilità. Un artefatto finale utile è una modifica di codice proposta con una spiegazione e i risultati delle verifiche effettivamente eseguite.
Una richiesta esemplificativa può chiedere di aggiornare un parser per un ulteriore input supportato mantenendo i formati esistenti. Identifica gli input rappresentativi e la parte del repository che definisce il comportamento del parser. Il modello può usare codice e osservazioni degli strumenti per sviluppare la modifica; una patch generata o l'affermazione che un comando dovrebbe funzionare non dimostra che il comando sia riuscito.
La scheda nativa del modello documenta l'addestramento all'uso di strumenti e consiglia descrizioni in JSON Schema tramite il template di chat del modello. Descrivi chiaramente lo scopo e gli argomenti di uno strumento. Uno strumento di esecuzione di comandi può restituire output e stato effettivi, mentre uno strumento di ispezione dei file può restituire il materiale necessario al passaggio successivo. Mantieni ogni risultato associato al suo identificatore di chiamata, così che l'analisi successiva usi l'osservazione prevista.
L'esempio del produttore conserva nella cronologia una chiamata a uno strumento e il ragionamento dell'assistente, esegue lo strumento e aggiunge il risultato prima di generare di nuovo. Il suo esempio di template nativo usa un dizionario strutturato per il risultato dello strumento. Preserva tale rappresentazione secondo l'integrazione documentata, senza presumere che ogni API non correlata serializzi allo stesso modo i risultati degli strumenti. Uno schema JSON che descrive gli argomenti di uno strumento è diverso dall'affermare il supporto per output finali vincolati da schemi arbitrari.
North Mini Code supporta il ragionamento intercalato, che il produttore consiglia di abilitare per il lavoro agentico. Trasferisci il contenuto di ragionamento generato dal modello e le chiamate agli strumenti nei passaggi successivi dell'agente e nei turni della conversazione. L'esempio nativo mantiene un campo reasoning nel messaggio dell'assistente e restituisce in seguito l'osservazione corrispondente dello strumento. Questo preserva le informazioni usate dal modello per decidere cosa esaminare o modificare successivamente.
Mantieni nella cronologia l'obiettivo corrente, il materiale di partenza e le osservazioni effettive. Per un'attività di repository più lunga, riassumi il risultato finale attorno al comportamento modificato e all'artefatto utile, conservando le prove necessarie alla revisione. Il ragionamento intercalato non implica che una risposta visibile breve non abbia richiesto analisi, né stabilisce che un'azione descritta dal modello sia già avvenuta.
Il produttore identifica anche programmazione scientifica e ragionamento algoritmico al di fuori di un ciclo agentico. Fornisci la definizione del problema, il formato di input e output, i vincoli, le ipotesi numeriche pertinenti e il comportamento atteso nei casi limite. Chiedi una funzione o un programma completo quando è l'artefatto necessario, con una spiegazione al livello richiesto dal lettore.
Per la spiegazione del codice, fornisci l'implementazione e il comportamento o la dipendenza specifica da chiarire. Per il codice di visualizzazione dei dati, identifica i campi forniti e il confronto previsto, evitando di lasciare implicito lo scopo del grafico. Gli esempi di sviluppo del produttore comprendono spiegazione e modifica del codice, visualizzazione dei dati e implementazione a partire da una specifica. Sono schemi di attività per generare o modificare codice, non promesse di risultati corretti per ogni repository o framework.
La scheda del modello e la pagina API del produttore elencano una finestra di contesto di 256K token e un output massimo di 64K token. Prepara materiale sostanziale del repository tenendo conto di questi limiti separati e delle dimensioni dell'artefatto finale. Mantieni intatti i confini e gli identificatori delle fonti ed elimina il materiale irrilevante, senza presumere che una finestra ampia elimini la necessità di un brief mirato.
La scheda nativa del modello consiglia temperature 1.0 e top_p 0.95 per la generazione e usa il template di chat del modello, incluso un prompt di generazione, per i flussi testuali e con strumenti. I limiti di output degli esempi sono impostazioni di quegli esempi, non sostituti del massimo pubblicato del modello. Cohere pubblica pesi BF16 e un artefatto FP8 con nome distinto. Seleziona l'artefatto appropriato quando prepari un deployment.
Un risultato utile di North Mini Code è un artefatto di codice esaminabile o una spiegazione tecnica collegata ai requisiti forniti. Confronta il risultato con il comportamento originale e con l'output effettivo degli strumenti, verifica le ipotesi che influiscono sul codice e conserva le fonti e le osservazioni necessarie alla revisione. Il modello di programmazione esclusivamente testuale fornisce ragionamento e contenuto generato; l'applicazione circostante esegue le operazioni che trasformano quelle proposte in un'attività software completata.
POST /v1/chat/completionstexttext| Campo | Tipo | Requisito | Valori e limiti | Predefinito |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObbligatorio | Valori e limiti cohere/north-mini-code:free | Predefinito— |
Campomessages | Tipoarray | RequisitoObbligatorio | Valori e limiti | Predefinito— |
Campostream | Tipoboolean | RequisitoFacoltativo | Valori e limiti false | Predefinitofalse |
Campomax_tokens | Tipointeger | RequisitoFacoltativo | Valori e limiti Minimo: 1 Massimo: 64.000 | Predefinito— |
Campomax_completion_tokens | Tipointeger | RequisitoFacoltativo | Valori e limiti Minimo: 1 Massimo: 64.000 | Predefinito— |
Campon | Tipointeger | RequisitoFacoltativo | Valori e limiti Minimo: 1 Massimo: 128 | Predefinito— |
Campotemperature | Tiponumber | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campotop_p | Tiponumber | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Camposeed | Tipointeger | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campostop | Tipo | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campofrequency_penalty | Tiponumber | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campopresence_penalty | Tiponumber | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campouser | Tipostring | RequisitoFacoltativo | Valori e limiti | Predefinito— |
| Parametro | Contratto |
|---|---|
Parametrocontent_type | Contrattoapplication/json |
Parametrorequired | Contrattomodel, messages |
Parametrooptional | Contrattostream, max_tokens, max_completion_tokens, n, temperature, top_p, seed, stop, frequency_penalty, presence_penalty, user |
Parametromaterial_types | Contrattotext |
Parametroconditions | ContrattoUse literal text messages only. Cache controls, tools, image/audio/video content and streamed responses are unavailable for this method., The complete encoded JSON request must not exceed 256000 bytes. |
Ciclo di vita: synchronous_json
Le tariffe non aggiungono opzioni alla richiesta. I parametri supportati sono elencati nel metodo selezionato.
| Configurazione | Listino delle tariffe | Costo |
|---|---|---|
| ConfigurazioneTariffe base dei token | Listino delle tariffeTariffa base | Costo Input · Token in input $0 / 1K token Output · Token in output $0 / 1K token Input · Lettura dalla cache — / 1K token Input · Scrittura nella cache — / 1K token Input · Scrittura nella cache, 1 ora — / 1K token |
Ailoot prenota un importo stimato prima di una richiesta. Dopo il risultato, addebita il costo finale in base all’utilizzo misurato. Per lo streaming, l’addebito usa il record finale di utilizzo. Come funzionano la prenotazione e l’addebito finale →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\nexport AILOOT_API_KEY\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads('{"model": "cohere/north-mini-code:free", "messages": [{"role": "user", "content": "Summarize the supplied text in three concise points."}], "stream": false}')\n\nPath("request.json").write_text(json.dumps(p,ensure_ascii=False))\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/chat/completions \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\n# Submit once. Retain the complete result, original identifiers and every response header.\nJSON
Conserva ogni risposta, file e parte di contenuto restituiti per intero.
Retain the complete response, all actual results, original identifiers, usage and response headers.
Preserve the original response, headers and X-Client-Request-ID. An uncertain outcome does not authorize another creation.
Ailoot Ultra cohere/north-mini-code:free
Usa i percorsi dei metodi indicati sopra.
cohere/north-mini-code:freeNorth Mini Code 1.0 è il modello esclusivamente testuale di Cohere per generazione di codice, modifiche ai repository e attività da agente tramite terminale. Il suo design sparso con 30B parametri totali e 3B attivi supporta uso di strumenti e ragionamento intercalato, con un contesto documentato di 256K e un limite di output di 64K.
Questa descrizione illustra le funzionalità del modello. Gli input, gli output e le opzioni disponibili in Ailoot per il metodo selezionato sono elencati di seguito.
North Mini Code 1.0 è il modello di Cohere per ingegneria del software agentica, attività da terminale e generazione di codice. Riceve testo e produce testo, inclusi codice, spiegazioni e richieste a strumenti. Il produttore ne ha rilasciato i pesi con licenza Apache 2.0 e lo identifica come primo modello nella famiglia North di agenti di programmazione. È un profilo specializzato nella programmazione, non un modello di comprensione delle immagini o un valutatore generico di decisioni.
Il modello ha 30 miliardi di parametri totali con circa 3 miliardi attivi. Il suo Transformer decoder-only usa una Mixture of Experts sparsa con 128 esperti, otto attivati per token, e un livello denso prima dei livelli sparsi. L'attenzione a finestra scorrevole con posizioni rotatorie è intercalata con attenzione globale senza embedding posizionali in rapporto 3:1. Il numero di parametri attivi descrive il calcolo usato per un token, non l'insieme totale dei pesi da memorizzare.
Il post-addestramento di Cohere usa due fasi di fine-tuning supervisionato seguite da apprendimento per rinforzo con ricompense verificabili, concentrandosi su ingegneria del software e lavoro da terminale. Il produttore descrive un addestramento su più sistemi di esecuzione per agenti invece che su un'unica struttura fissa. Questo favorisce la preparazione di un'attività attorno al comportamento richiesto e agli strumenti disponibili, mentre il sistema circostante resta responsabile di ottenere i file, eseguire i comandi e restituire le osservazioni.
Fornisci il codice e il comportamento attuali, la modifica richiesta, i confini pertinenti dei file o delle interfacce e le prove che stabiliranno il completamento. Per un bug, includi l'errore osservato o l'input che fallisce e il risultato atteso. Per una funzionalità, indica il comportamento richiesto e i vincoli di compatibilità. Un artefatto finale utile è una modifica di codice proposta con una spiegazione e i risultati delle verifiche effettivamente eseguite.
Una richiesta esemplificativa può chiedere di aggiornare un parser per un ulteriore input supportato mantenendo i formati esistenti. Identifica gli input rappresentativi e la parte del repository che definisce il comportamento del parser. Il modello può usare codice e osservazioni degli strumenti per sviluppare la modifica; una patch generata o l'affermazione che un comando dovrebbe funzionare non dimostra che il comando sia riuscito.
La scheda nativa del modello documenta l'addestramento all'uso di strumenti e consiglia descrizioni in JSON Schema tramite il template di chat del modello. Descrivi chiaramente lo scopo e gli argomenti di uno strumento. Uno strumento di esecuzione di comandi può restituire output e stato effettivi, mentre uno strumento di ispezione dei file può restituire il materiale necessario al passaggio successivo. Mantieni ogni risultato associato al suo identificatore di chiamata, così che l'analisi successiva usi l'osservazione prevista.
L'esempio del produttore conserva nella cronologia una chiamata a uno strumento e il ragionamento dell'assistente, esegue lo strumento e aggiunge il risultato prima di generare di nuovo. Il suo esempio di template nativo usa un dizionario strutturato per il risultato dello strumento. Preserva tale rappresentazione secondo l'integrazione documentata, senza presumere che ogni API non correlata serializzi allo stesso modo i risultati degli strumenti. Uno schema JSON che descrive gli argomenti di uno strumento è diverso dall'affermare il supporto per output finali vincolati da schemi arbitrari.
North Mini Code supporta il ragionamento intercalato, che il produttore consiglia di abilitare per il lavoro agentico. Trasferisci il contenuto di ragionamento generato dal modello e le chiamate agli strumenti nei passaggi successivi dell'agente e nei turni della conversazione. L'esempio nativo mantiene un campo reasoning nel messaggio dell'assistente e restituisce in seguito l'osservazione corrispondente dello strumento. Questo preserva le informazioni usate dal modello per decidere cosa esaminare o modificare successivamente.
Mantieni nella cronologia l'obiettivo corrente, il materiale di partenza e le osservazioni effettive. Per un'attività di repository più lunga, riassumi il risultato finale attorno al comportamento modificato e all'artefatto utile, conservando le prove necessarie alla revisione. Il ragionamento intercalato non implica che una risposta visibile breve non abbia richiesto analisi, né stabilisce che un'azione descritta dal modello sia già avvenuta.
Il produttore identifica anche programmazione scientifica e ragionamento algoritmico al di fuori di un ciclo agentico. Fornisci la definizione del problema, il formato di input e output, i vincoli, le ipotesi numeriche pertinenti e il comportamento atteso nei casi limite. Chiedi una funzione o un programma completo quando è l'artefatto necessario, con una spiegazione al livello richiesto dal lettore.
Per la spiegazione del codice, fornisci l'implementazione e il comportamento o la dipendenza specifica da chiarire. Per il codice di visualizzazione dei dati, identifica i campi forniti e il confronto previsto, evitando di lasciare implicito lo scopo del grafico. Gli esempi di sviluppo del produttore comprendono spiegazione e modifica del codice, visualizzazione dei dati e implementazione a partire da una specifica. Sono schemi di attività per generare o modificare codice, non promesse di risultati corretti per ogni repository o framework.
La scheda del modello e la pagina API del produttore elencano una finestra di contesto di 256K token e un output massimo di 64K token. Prepara materiale sostanziale del repository tenendo conto di questi limiti separati e delle dimensioni dell'artefatto finale. Mantieni intatti i confini e gli identificatori delle fonti ed elimina il materiale irrilevante, senza presumere che una finestra ampia elimini la necessità di un brief mirato.
La scheda nativa del modello consiglia temperature 1.0 e top_p 0.95 per la generazione e usa il template di chat del modello, incluso un prompt di generazione, per i flussi testuali e con strumenti. I limiti di output degli esempi sono impostazioni di quegli esempi, non sostituti del massimo pubblicato del modello. Cohere pubblica pesi BF16 e un artefatto FP8 con nome distinto. Seleziona l'artefatto appropriato quando prepari un deployment.
Un risultato utile di North Mini Code è un artefatto di codice esaminabile o una spiegazione tecnica collegata ai requisiti forniti. Confronta il risultato con il comportamento originale e con l'output effettivo degli strumenti, verifica le ipotesi che influiscono sul codice e conserva le fonti e le osservazioni necessarie alla revisione. Il modello di programmazione esclusivamente testuale fornisce ragionamento e contenuto generato; l'applicazione circostante esegue le operazioni che trasformano quelle proposte in un'attività software completata.
POST /v1/messagestexttext| Campo | Tipo | Requisito | Valori e limiti | Predefinito |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObbligatorio | Valori e limiti cohere/north-mini-code:free | Predefinito— |
Campomessages | Tipoarray | RequisitoObbligatorio | Valori e limiti | Predefinito— |
Campostream | Tipoboolean | RequisitoFacoltativo | Valori e limiti false | Predefinitofalse |
Camposystem | Tipostring | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campomax_tokens | Tipointeger | RequisitoObbligatorio | Valori e limiti Minimo: 1 Massimo: 64.000 | Predefinito— |
Campotemperature | Tiponumber | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campotop_p | Tiponumber | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campotop_k | Tipointeger | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campostop_sequences | Tipoarray | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campometadata | Tipoobject | RequisitoFacoltativo | Valori e limiti | Predefinito— |
| Parametro | Contratto |
|---|---|
Parametrocontent_type | Contrattoapplication/json |
Parametrorequired | Contrattomodel, messages, max_tokens |
Parametrooptional | Contrattostream, system, temperature, top_p, top_k, stop_sequences, metadata |
Parametromaterial_types | Contrattotext |
Parametroconditions | ContrattoUse literal text messages only. Cache controls, tools, image/audio/video content and streamed responses are unavailable for this method., The complete encoded JSON request must not exceed 256000 bytes. |
Ciclo di vita: synchronous_json
Le tariffe non aggiungono opzioni alla richiesta. I parametri supportati sono elencati nel metodo selezionato.
| Configurazione | Listino delle tariffe | Costo |
|---|---|---|
| ConfigurazioneTariffe base dei token | Listino delle tariffeTariffa base | Costo Input · Token in input $0 / 1K token Output · Token in output $0 / 1K token Input · Lettura dalla cache — / 1K token Input · Scrittura nella cache — / 1K token Input · Scrittura nella cache, 1 ora — / 1K token |
Ailoot prenota un importo stimato prima di una richiesta. Dopo il risultato, addebita il costo finale in base all’utilizzo misurato. Per lo streaming, l’addebito usa il record finale di utilizzo. Come funzionano la prenotazione e l’addebito finale →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\nexport AILOOT_API_KEY\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads('{"model": "cohere/north-mini-code:free", "messages": [{"role": "user", "content": "Summarize the supplied text in three concise points."}], "stream": false, "max_tokens": 256}')\n\nPath("request.json").write_text(json.dumps(p,ensure_ascii=False))\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/messages \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\n# Submit once. Retain the complete result, original identifiers and every response header.\nJSON
Conserva ogni risposta, file e parte di contenuto restituiti per intero.
Retain the complete response, all actual results, original identifiers, usage and response headers.
Preserve the original response, headers and X-Client-Request-ID. An uncertain outcome does not authorize another creation.
Ailoot Ultra cohere/north-mini-code:free
Usa i percorsi dei metodi indicati sopra.