Boreas 3.1 is a Sigilix route trained with memory and codebase-context enhancements. It is built for the way engineering work actually moves: GitHub reviews, Slack decisions, Linear issue trails, CLI sessions, and the local repository all leave context the model can use on the next interaction.
That matters because Boreas is not asked to start from a blank prompt. Your repository shape, naming conventions, prior decisions, review patterns, and task history explain how this codebase works.
This changes how AI models can be built for software. The model improves by learning the shape of recurring engineering mistakes and by using durable memory to remember how a team solves them, instead of rediscovering the same context on every run.
This is why Boreas is the model path for speed. It is designed for the everyday moments where you need a grounded answer quickly: short review passes, local repo questions, issue context, and simple repair planning.
The public announcement keeps lower-level engine details private. What matters for you is the product result: the model route spends fewer tokens rediscovering the work because the codebase and memory context are already there.
Flash model benchmarks
Boreas 3.1 is shown against flash and compact coding peers because that is the tier it is designed to serve. These rows describe the Sigilix route, not a raw foundation model ranking: task score, output capacity, and context capacity are separated so each chart answers one question at a time.
Source rows come from TerminalBench and SWE-bench Verified references supplied for this comparison. The Sigilix lift comes from better use of local context and memory; it is scoped to the org or user context available to the task, not product-wide training on customer data.
TerminalBench measures terminal-use coding tasks: reading a repo, choosing the right command path, interpreting shell feedback, and making progress through a workflow where each step depends on the previous command.
That is a good fit for Boreas because many Sigilix interactions happen in exactly that shape. The user is not asking for a long essay; they are asking what to run next, why a failure happened, whether a small change is safe, or how to move from review to repair without losing the thread.
The score should be read as a task-flow signal, not as a claim that the model knows every codebase from raw weights. Boreas pairs multi-codebase coding-pattern training with the repository and memory layer around it, so the route can spend more of its budget on the active decision instead of reconstructing context.
That is the shift Sigilix is making: models for software should be trained to reason with the evidence system around them. The model learns common mistakes and codebase patterns, then the product gives it the repository memory needed to apply those lessons to the current task.
The comparison stays inside flash and compact peers because this is the practical choice a product makes when it needs a responsive coding model. Frontier routes may score differently, but they answer a different latency and budget question.
Values shown: Flash peer A TerminalBench 2.1; Boreas 3.1 TerminalBench; Flash peer B TerminalBench; Flash peer C TerminalBench 2.0 Max mode; Gemma 4 31B TerminalBench 2.0; Compact peer A Public Terminal-Bench.SWE-bench Verified focuses the comparison on realistic repository repair: localizing an issue, editing the right files, and landing a patch that survives the test surface instead of merely sounding plausible.
That makes it closer to the work you need supported. A review comment is only useful if the system can move from the symptom to the actual code path, preserve the constraint that made the bug matter, and produce a repair plan that fits the repository.
Boreas is reported at 80% here because the model is not working from benchmark text alone. Its coding-pattern training gives it a stronger prior for how repairs should be structured, while the Sigilix memory layer carries repo conventions and prior decisions into the run.
The value of that context is not abstract: it narrows the search space, keeps naming and architecture choices consistent, and reduces the chance that a patch solves the wrong version of the problem.
The claim is about the Sigilix route, not a disconnected model score. Boreas is trained for code and attached to a memory system that helps it recognize common errors before they become repeated engineering work.
That lift is local to the org or user context available to the task. It should be read as a workspace improvement effect, not a public training claim across all customers.
Values shown use SWE-bench Verified rows for Boreas 3.1, Flash peer C Max mode, Flash peer A, Compact peer A, Flash peer B, and Gemma 4 31B.Each line plots effort checkpoints across that model's output-token range, with the rightmost point anchored to the published max output cap. The chart is not saying that more tokens automatically make a model better; it shows how much room each model exposes when it has to produce longer reasoning or longer code changes.
Output capacity matters differently from benchmark score. A small cap can be enough for tight fixes, but larger repairs may need room for explanation, patch planning, test reasoning, and follow-up edits. A larger cap only helps when the model can use that space without drifting from the task.
For Boreas, the product goal is not to win by producing the most text. The goal is to use enough output to finish the fast-lane task while letting memory carry the repeated context. That is why output, context, and task score are shown separately.
Scores use the SWE-bench Verified rows in the supplied benchmark set. Hover a dot to see the effort mode, plotted output budget, context window, and score.
Sources: public flash-peer capacity references, effort docs, and model cards. Gemma 4 31B is omitted here because the supplied source did not include a max output-token cap.Boreas 3.1 is 68% on TerminalBench and 80% on SWE-bench Verified. The score charts show task performance; the output-token graph shows how published output capacity lines up with the supplied SWE-bench rows. The memory lift is org/user scoped: your workspace improves repeated work by carrying forward local context, and Sigilix does not train on customer data unless training is enabled. See Terms and Privacy for more information.
Boreas 3.1
Boreas 3.1
native context 262,144
What Boreas is for.
Boreas is built around coding-pattern memory and codebase context, not generic assistant behavior. It is the route for fast, common engineering work where the answer should stay close to the repository, the pull request, and the workflow surface that produced the question.
Every connected surface can add signal. Slack decisions, Linear issue history, CLI repair sessions, review outcomes, and repository conventions become context Boreas can use to understand how the work should move.
That is the difference between asking a model to reason against a prompt and asking it to reason with a system. Boreas is strongest when the surrounding product gives it the evidence it needs: the repo surface, the memory graph, the current diff, and the mistakes your workspace has taught it to recognize.
That makes it useful for lightweight review, quick triage context, CLI questions, changelog inspection, issue summarization, and repeated repo conventions that can be carried forward without asking you to restate them.
The model is tuned for the part of development where speed changes behavior. If an answer can arrive while the engineer is still inside the same thought, it can help with the next command, the next comment, or the next small repair instead of becoming a separate research task.
When the work becomes broad, security-sensitive, or ambiguous, you can route deeper. Boreas is the everyday lane: fast enough to stay in the loop, grounded enough to avoid generic advice, and narrow enough that it does not spend frontier-model budget on routine work.
Benchmark framing.
For public comparison, Boreas is measured only against flash and compact peers. That matters because the route is built for latency and cost discipline, so comparing it to frontier or base-model routes would blur the product decision the chart is meant to explain.
The benchmarks answer different questions. TerminalBench is about whether a model can make progress through a terminal-bound coding workflow. SWE-bench is about whether a model can reason through repository repair and land the right patch. Output capacity is about how much the model can produce at a given effort setting.
Each filter keeps a single metric in view so task scores, output limits, and context windows do not read as the same claim. A high context window does not automatically mean higher repair accuracy, and a large output cap does not automatically mean the model is better at choosing the right edit.
The useful read is route-specific: what happens when a fast model is trained around coding failure patterns and then paired with the memory your team builds through its actual engineering workflow?
That is why the charts should be read as product-system evidence. Boreas stays in the fast lane, but the route is designed to make better use of context, learn the shape of common engineering errors, and preserve the repo-specific memory that ordinary model comparisons leave out.
Token cost.
The bigger product win is cost of context. Across the model line, your workspace memory and codebase grounding reduce repeated token use by 63% compared with rehydrating the same work from scratch.
That reduction comes from carrying forward the parts of engineering context that usually get rebuilt again and again: repository shape, local naming conventions, previous decisions, active product constraints, and the evidence already gathered in earlier runs.
There are two different ideas here. Boreas is trained around broad coding-pattern standards across many codebases. The Sigilix memory system is the local layer that applies those standards to your repository, your team's decisions, and the code paths already inspected.
That local memory is not the same as training a shared model on customer work. The improvement is scoped to the org or user context available to the task. The route becomes more useful for your repository by remembering what your team has already established, without turning that memory into product-wide training unless that is explicitly enabled.
For Boreas, this matters because the model is meant to run often. Saving context on the common path compounds: every quick review, CLI answer, and triage pass can start closer to the work instead of spending tokens to rediscover what your workspace has already taught it.
What comes next
Boreas is the model route that keeps common engineering work fast without making the engineer repeat the same context every time.