Edge0-145B Benchmarks: Terminal-Bench 2.1 and Latent MoE Explained

How does Edge0-145B perform on benchmarks?

Edge0-145B's model card reports a score of 86.5 on Terminal-Bench 2.1, a test of how well an AI agent completes real tasks in a command-line terminal. The model has 145 billion parameters in total, but it is a sparse mixture-of-experts (MoE) design. It has 48 layers and 512 experts, and only 10 experts run for each token. It supports a 256K-token context window and was trained natively at 4-bit precision (NVFP4), which is why its tagline is "a 145B agent on one consumer GPU." Those are the vendor's own claims, so treat them as a starting point for your own testing.

What is Terminal-Bench, and why does 86.5 matter?

Terminal-Bench is a family of tests for AI agents that work in a command-line environment. Instead of asking a model a question, the test gives it a task, such as setting up a project, fixing a failing build, or processing files, and checks whether the end result is correct. The model has to run commands, read the output, and decide what to do next.

That makes it closer to real work than a multiple-choice quiz. A model can sound smart and still fail at step six of a ten-step job. Terminal-Bench catches that.

The card's headline figure is 86.5 on version 2.1. Two cautions apply:

• Version matters. Scores on different versions of a benchmark are not directly comparable. If you see a competitor's number, check that it is also from 2.1.
• Setup matters. Agent benchmarks depend on the tooling wrapped around the model (the harness), the time limits and the number of attempts. A score measured with one setup can drop with another.

The source material for this article does not include comparison scores for other models, so this piece does not rank Edge0-145B against anything. If you need that, look for independent runs on the same benchmark version.

What does "latent sparse MoE" actually mean?

Break the phrase into pieces.

Mixture of experts (MoE). A normal ("dense") model uses all its parameters for every token it reads or writes. An MoE model splits parts of each layer into many smaller specialist networks called experts. A small router decides which experts handle each token.

Sparse. Only a few experts run per token. For Edge0-145B, the card says 512 experts per layer exist and 10 are active per token. Think of a 512-person company where each question goes to the ten people best suited to it. The company has a lot of knowledge on staff, but you only pay for ten people's time per question.

Latent. In general usage, "latent MoE" refers to doing the expert work in a compressed internal representation, rather than at the model's full width. The point is to make routing and expert computation cheaper so you can afford many more experts. The card describes the design as a latent sparse MoE across 48 layers. For the exact mechanics, read the architecture section of the card or the project's GitHub repository, since the details vary between implementations.

The practical result: the model stores 145 billion parameters worth of knowledge, but each token only touches a small slice of them. That is how a large model can generate text at a speed closer to a much smaller one.

Why does training natively at 4 bits matter?

Most people who run big models locally use quantization, which means taking a finished model trained at higher precision and rounding its numbers down to fewer bits so it fits in less memory. It works, but rounding after the fact can cost some quality.

Native low-precision training flips the order. The model learns while working at 4-bit precision (the card's NVFP4 format), so it adapts to those limits as it trains. The expected benefits are smaller memory use and faster math on hardware that supports the format, with less of a quality hit than rounding down afterward.

A quick sanity check on size: 145 billion parameters at 4 bits each is roughly 72 GB of weights before any overhead, and the model's memory footprint also includes the working memory for long contexts. The card's pitch is one consumer GPU, so look closely at its hardware requirements section to see exactly what setup it assumes (for example, how much memory the GPU needs and whether any parts of the model live in system RAM). Do not assume your current laptop qualifies.

How should you read the prefill and decode speed numbers?

The card includes throughput figures for two phases, and they measure different things:

Prefill is usually much faster per token than decode, because reading can be done in parallel and writing cannot. For agent work, both matter. An agent often feeds large amounts of terminal output back into the model (heavy prefill), then writes a short command (light decode). A chat assistant writing a long essay is the reverse.

To use the card's numbers well:

1. Check the prompt length the speeds were measured at. Speeds at a short prompt can look very different from speeds near 256K.
2. Check the hardware listed beside each number.
3. Estimate your own workload: how much text goes in, how much comes out, how many steps per task.

Is a 256K context window useful?

For agent tasks, yes, with limits. A 256K-token window is large enough to hold a sizeable codebase excerpt, long logs and the running history of an agent's steps. That reduces the need to constantly summarize or forget earlier work.

But a big window is not the same as perfect memory. Models can still lose track of details buried in the middle of very long inputs, and long contexts consume memory and slow down prefill. Test with your real documents instead of assuming the maximum works well.

What does this mean for you?

If you are a developer or work with data and scripts: A model that scores well on terminal tasks and runs on one GPU is worth a trial if you want an agent that keeps your code and files on your own machine. Pick three or four small, real tasks from your week (a failing script, a messy file cleanup, a config change) and run them end to end.

If you are a manager or buyer: Ask what the benchmark actually measured. "86.5" means little without the version, the harness and the number of attempts. Ask your technical people to reproduce one result before it influences a decision.

If you are non-technical: You probably will not run this model yourself. What matters is the trend. Models built this way (sparse, low precision, long context) aim to make capable AI agents cheaper to run, which tends to show up later as cheaper tools and more of them running inside company walls.

A simple evaluation checklist:

• Confirm the license and download terms on the model card.
• Confirm the hardware requirements match what you have.
• Run your own five-task test and record pass or fail.
• Compare time per task, not just accuracy.
• Re-test when a new version ships.

Can you track model tests without another subscription?

If you start comparing models, you will quickly end up with a spreadsheet of tasks, scores, timings and notes. With Remy, you could describe a small internal tracker in plain English (a form to log each test, a table of results by model, a chart of pass rates) and have it built and deployed as a working app with a login for your team. It is a way to own a simple evaluation log instead of stitching together shared sheets. Remy also gives apps access to nearly 400 AI models, so a tracker could be extended to run the same test prompt across several models.