Cohere: North Mini Code (free)

North Mini Code 1.0 is Cohere’s model for agentic software engineering, terminal tasks and code generation. It takes text and produces text, including code, explanations and tool requests. The manufacturer released its weights under Apache 2.0 and identifies it as the first model in the North code-agent family. It is a specialized coding profile rather than an image-understanding model or a generic decision scorer.

Sparse architecture and coding preparation

The model has 30 billion total parameters with about 3 billion active. Its decoder-only Transformer uses a sparse Mixture of Experts with 128 experts, eight activated per token, and a dense layer before the sparse layers. Sliding-window attention with rotary positions is interleaved with global attention without positional embeddings in a 3:1 ratio. The active-parameter figure describes the computation used for a token, not the total set of weights that must be stored.

Cohere’s post-training uses two stages of supervised fine-tuning followed by reinforcement learning with verifiable rewards, focused on software engineering and terminal work. The producer describes training across multiple agent harnesses instead of one fixed scaffold. That supports preparing a task around the required behavior and available tools, while the surrounding harness remains responsible for obtaining files, executing commands and returning observations.

Prepare a repository-level change

Supply the current code and behavior, the requested change, the relevant file or interface boundaries and the evidence that will establish completion. For a bug, include the observed error or failing input and the expected result. For a feature, state the required behavior and the compatibility constraints. A useful final artifact is a proposed code change with an explanation and results from checks that actually ran.

An illustrative request can ask to update a parser for an additional supported input while preserving existing formats. Identify representative inputs and the part of the repository that defines the parser’s behavior. The model can use code and tool observations to develop the change; a generated patch or a statement that a command should run is not evidence that the command succeeded.

Terminal tools and structured observations

The native model card documents tool-use training and recommends JSON-schema tool descriptions through the model’s chat template. Describe a tool’s purpose and arguments clearly. A command-execution tool can return the actual output and status, while a file-inspection tool can return the material the next step needs. Keep each tool result associated with its call identifier so later analysis uses the intended observation.

The producer’s example preserves a tool call and the assistant’s reasoning in history, executes the tool, and adds its result before generating again. Its native template example uses a structured dictionary for the tool result. Preserve that representation according to the documented integration rather than assuming every unrelated API serializes tool results in the same way. A JSON schema describing a tool’s arguments is different from claiming arbitrary schema-constrained final output support.

Interleaved thinking and multi-turn history

North Mini Code supports interleaved thinking, which the producer recommends enabling for agentic work. Carry model-generated thinking content and tool calls into subsequent agent steps and conversation turns. The native example keeps a reasoning field with the assistant message and returns the corresponding tool observation afterward. This preserves the information the model used when deciding what to inspect or change next.

Keep the current objective, the source material and actual observations in the task history. For a longer repository task, summarize the final result around the changed behavior and the useful artifact, while retaining the evidence needed to review it. Interleaved reasoning does not imply that a short visible answer required no analysis, nor does it establish that an action described by the model has already occurred.

Standalone code and explanation tasks

The maker also identifies scientific coding and algorithmic reasoning outside an agent loop. Supply the problem definition, input and output format, constraints, relevant numerical assumptions and expected edge behavior. Ask for a complete function or program when that is the artifact required, with an explanation at the level the reader needs.

For code explanation, provide the implementation and the particular behavior or dependency to clarify. For data-visualization code, identify the supplied fields and the intended comparison rather than leaving the chart’s purpose implicit. The producer’s development examples include code explanation, editing, visualization and implementation from a specification. These are task patterns for generating or modifying code, not a promise of correct results for every repository or framework.

Context, output and generation settings

The manufacturer’s model card and API page list a 256K-token context window and a maximum output of 64K tokens. Prepare substantial repository material around those separate allowances and the final artifact’s size. Keep source boundaries and identifiers intact, and remove irrelevant material rather than assuming that a large window eliminates the need for a focused brief.

The native model card recommends temperature 1.0 and top_p 0.95 for generation and uses the model’s chat template, including a generation prompt, for text and tool workflows. Its example output limits are settings for those examples, not a replacement for the model’s published maximum. Cohere publishes BF16 weights and a separately named FP8 artifact. Select the appropriate artifact when preparing a deployment.

A useful North Mini Code result is an inspectable code artifact or technical explanation tied to the supplied requirements. Compare the result with the original behavior and actual tool output, check assumptions that affect the code, and retain the source and observations needed for review. The text-only coding model supplies reasoning and generated content; the surrounding application performs the operations that turn those proposals into a completed software task.