Trinity Large vs Trinity Mini: Routing Work to the Right Arcee Model

Trinity Large and Trinity Mini are two tiers of the same model family from Arcee AI. You are meant to run both. This page is not about which one is better. It is about which workload goes where.

The Trinity line ships in tiers: Nano at 6 billion parameters, Mini at 26 billion, and Large at roughly 400 billion. All three publish a downloadable set of weights. All three launched under Apache 2.0, and Arcee later moved the whole line to the OpenMDW 1.1 license — a permissive license from the Linux Foundation — after launch, in 2026, applying the change retroactively — both are permissive, but they are different documents, so verify the current model card.

The default that costs teams the most money is serving every request on the largest model available. Trinity Mini activates 3 billion parameters per token against Trinity Large's 13 billion, and holds 26 billion total in memory against Large's 400 billion. That difference is the whole argument for routing.

Trinity Large vs. Trinity Mini: Side-by-Side

Quick answer: start on Mini, escalate to Large

Run Trinity Mini as your default and reserve Trinity Large for the tasks that visibly fail on Mini. That is the routing rule, and it holds for almost every production system.

The reason is arithmetic, not preference. Mini holds 26 billion parameters in memory and fires 3 billion per token. Large holds about 400 billion and fires about 13 billion. You are paying for the memory footprint whether or not the task needs it.

Escalation should be a measured decision. Send a task to Large when Mini's output fails on your own test set. Do not send it because the task sounds hard.

The spec difference, in plain terms

Both models are sparse mixture-of-experts designs, which means only a slice of the parameters activates for any given token. Total parameters set your memory bill. Active parameters set your speed per token.

Arcee's model page describes Trinity Mini as 26 billion total with 3 billion active, built from 128 experts with 8 active and 1 shared, trained on 10 trillion tokens. Its context window is 128K tokens.

Trinity-Large-Thinking is about 400 billion total with roughly 13 billion active, using 4-of-256 expert routing with 1 shared expert, trained on 17 trillion tokens. Its context window is 512K tokens.

• Mini: 26B total / 3B active / 128K context / 10T training tokens
• Large: ~400B total / ~13B active / 512K context / 17T training tokens
• Nano also exists at 6B total / 1B active / 128K context, for the smallest tasks
• All Trinity tiers ship under OpenMDW-1.1 with weights on Hugging Face

Task routing: which tier runs which workload

Route by whether the task needs multi-step reasoning or a very long single input. Those two properties, not subject-matter difficulty, are what separate the tiers in practice.

The table below is a starting configuration, not a law. Treat it as the routing policy you deploy on day one and then correct with your own evaluation results.

The pattern holds in our own work. Layer3 Labs runs an automation fleet across a portfolio of sites. The large majority of those model calls are classification, extraction, and formatting. That work never justified a frontier-scale model, and we route it to small models by default.

• Classification and tagging → Mini. Short inputs, constrained outputs, high volume.
• Data extraction from documents → Mini. Escalate only when the schema is deeply nested.
• Summarization of a normal document → Mini, comfortably inside its 128K context.
• Drafting and rewriting copy → Mini. Quality here is usually a prompt problem, not a size problem.
• Intent routing inside an agent → Mini. This runs on every turn, so cost compounds fastest here.
• Multi-step agent execution with tool calls → Large. This is the workload Arcee built the Thinking variant for.
• Long-horizon reasoning that must hold state across many steps → Large.
• Single inputs above 128K tokens → Large, because Mini's context window ends there. Check what your Large path actually serves first: 512K is the published ceiling, but Arcee serves the reasoning variant at 256K in BF16, and the hosted preview ran at 128K with 8-bit quantization — on that hosted path, escalating past 128K buys you nothing.
• Anything Mini fails on your own eval set → Large, and only after you have the failing cases written down.

Why serving everything on Large is the expensive mistake

Self-hosting cost tracks the memory you must keep resident, and Trinity Large needs roughly fifteen times Trinity Mini's parameter count in memory. That gap does not shrink because your requests are short.

Here is a useful rule of thumb. At 8-bit quantization a model needs roughly one byte of memory per parameter, plus KV-cache overhead. On that arithmetic Mini lands in single-GPU territory and Large lands squarely in multi-GPU server territory. Confirm the exact figures against your serving stack before you buy anything.

The hosted path has the same shape. Arcee's docs rate card lists $0.25 per million input tokens and $0.80 per million output tokens for Trinity-Large-Thinking; Arcee's own launch post quoted a different output rate, so confirm the current figure on Arcee's page. Say a large share of your calls are short classification jobs. Routing those to a smaller tier is the biggest cost change available to you.

• Memory is the binding constraint for self-hosting, and it scales with total parameters, not active ones
• Mini at 26B is realistic on one high-VRAM GPU, more so quantized
• Large at ~400B is a multi-GPU server, or a hosted API call
• High-volume, low-complexity traffic is where routing saves the most
• Verify current hosted rates for each tier on Arcee's own pricing page before modeling costs

Context window: the one hard line between the tiers

Trinity Mini's 128K context window is a hard ceiling, and it is the clearest case where routing is not a judgment call. If a single input exceeds 128K tokens, Mini cannot take it.

Trinity Large publishes a 512K context window, which is four times Mini's. That covers large codebases, long contract sets, and multi-document research passes in a single call — but only if the path you actually run serves it. Arcee serves the reasoning variant at 256K in BF16, and the hosted preview ran at 128K with 8-bit quantization, which is the same ceiling as Mini. Confirm the served window on your chosen path before you make context the escalation trigger.

Before you escalate on context alone, check whether the input actually needs to arrive in one piece. Chunking plus retrieval often keeps a job on Mini and costs less than moving it to Large.

What we could not verify about Trinity Mini

We could not retrieve a complete, reliable benchmark table for Trinity Mini, so this page does not print one. Arcee's model card includes a benchmark comparison, and you should read it directly rather than take a number secondhand from us.

That gap does not weaken the routing argument. The argument rests on the specs Arcee's own model page and Hugging Face model cards describe: parameter counts, active parameters, expert configuration, context window, training tokens, and license.

It does mean you should not assume a capability ratio between the tiers. Run both against your actual tasks and let the failure cases, rather than a score table, tell you where the line sits.

• Arcee's model page describes Mini as 26B total / 3B active / 128 experts (8 active, 1 shared) / 128K context / 10T tokens, under OpenMDW-1.1
• Arcee's model page describes Large as ~400B total / ~13B active / 4-of-256 routing / 512K published context / 17T tokens, under OpenMDW-1.1
• Not confirmed here: Trinity Mini's individual benchmark scores — check the Hugging Face model card
• Not confirmed here: current hosted API rates for the Mini tier — check Arcee's pricing page

How to run both tiers without doubling your work

Serve both models behind one internal endpoint and route inside your own code. The application should ask for a capability level, not a model name. Then changing the routing policy never means changing the application.

Log every escalation. When a request moves from Mini to Large, record why. That log becomes the evidence base for tuning the routing rules later.

Re-run the routing decision on a schedule. Small models improve quickly. Arcee has stated it intends to bring the pretraining and post-training work from Trinity Large into its Mini and Nano models. Work that needs Large this quarter may not need it next quarter.

The Verdict

Run Trinity Mini by default and Trinity Large by exception. Mini holds 26 billion parameters against Large's roughly 400 billion, and fires 3 billion per token against 13 billion. The cost difference is structural, not marginal.

Send work to Trinity Large for three reasons only. Those are multi-step agent execution, long-horizon reasoning that holds state, and inputs above Mini's 128K context window — with one check on that last one, because the hosted Trinity Large preview ran at 128K itself, and Arcee serves the reasoning variant at 256K in BF16 rather than the published 512K. Everything else — classification, extraction, summarization, routing, drafting — belongs on Mini until your own evaluation proves otherwise.

One honest caveat. We did not verify a benchmark table for Trinity Mini, so do not assume a fixed capability ratio between the tiers. Build a small evaluation set from your real tasks, run both models against it, and let the failures set the routing line. If you want help designing that routing layer, Layer3 Labs does this work.