Edge0-145B Promises Frontier AI on Your PC—Which PC?

Your own computer comes with conditions

Edge0 has introduced Edge0-145B with a proposition developers will want to interrogate: frontier AI capabilities on a personal computer. Its repository records the release on November 13, 2026, and links downloadable weights. This is a concrete release to inspect, rather than a reason to assume every desktop just acquired a frontier assistant. Edge0 release repository

The assigned announcement is titled “Introducing Edge0-145B: Frontier AI Capabilities on Your Own Computer”. That page could not be retrieved during this review. The technical details below therefore come from Edge0’s official repository and documentation; the announcement’s headline is a claim, not independent performance verification.

The useful question is which computer, running which build, doing which work. A successful launch, a fast stream of tokens and a correct software repair are different achievements. Edge0 has supplied enough material to start separating them. Builders considering local execution this week have something testable, but the purchase decision needs more than the word “frontier.”

Start with the release’s platform boundary

Edge0’s current repository places Edge0-145B on Linux or Windows with an NVIDIA GPU and CUDA 13. It runs through edge0-strata, launched by the shared edge0-infer interface. The broader project supports other platforms through other releases; that umbrella does not establish equivalent support for this particular download. Official platform matrix

That distinction matters before any installation experiment. A developer with a supported workstation can investigate the release directly. Someone with a different platform needs an explicit supported path for Edge0-145B. Borrowing compatibility from another product in the same repository is how a quick evaluation becomes an afternoon of debugging the wrong thing.

Edge0’s model documentation also retains Apple M2 Ultra measurements while explicitly saying those measurements do not establish macOS release availability. A performance row and a supported distribution are separate evidence. For planning purposes, follow the release requirements rather than treating every machine in a speed table as a ready-to-install target. Model requirements and measurements

The first evaluation record should name the operating system, GPU, driver, available memory and exact software revision. Keep those details beside the result. If another developer cannot identify the environment that produced an answer, a screenshot of that answer offers little help with deployment.

The big parameter count is only part of the machine

According to Edge0’s technical profile, Edge0-145B has 145 billion total parameters and 10.12 billion active per token. It is a latent mixture-of-experts design, with separate Q3_K and NVFP4 releases. Those are architectural and packaging details reported by the developer, not proof that every task receives equivalent capability to a leading hosted service. Official technical profile

For a builder, the distinction between total and active parameters changes what to investigate. Ask how the full package is stored, how much remains resident during execution, and what happens as the workload changes. The headline size alone cannot tell you whether your application will respond promptly or spend its time waiting on data movement.

Quantization is part of that investigation. Hugging Face describes it as using lower-precision representations to reduce memory and computational requirements. That explains the general purpose of compressed formats; it does not establish the quality of either Edge0 build. Each artifact still needs evaluation on the task you intend to ship. Hugging Face quantization documentation

Keep the artifact identity attached to every test. If you change the weight format, runtime configuration or software revision, record a new run. Otherwise, a promising result from one setup can quietly become the justification for deploying another. The download name belongs in the test report, alongside the prompt and answer.

Read the speed table without shopping by it

Edge0 reports Q3_K chat decoding at 99.7 tokens per second on an RTX 5090 D 24 GB, versus 69.9 on an RTX 4090 24 GB. Its constrained-memory row uses the RTX 5090 D again, with a 16 GiB GPU-memory and 20 GiB system-memory budget. It is not a measurement from a separate, cheaper card. These are vendor measurements. Official speed table

The same page says those constrained budgets are measured test conditions, not general minimum requirements. That qualification deserves more attention than a triumphant repost of the smallest memory figures. A memory constraint can demonstrate something useful without proving that another machine with the same nominal capacity will deliver the same experience.

For your own evaluation, time the complete request. Separate startup, prompt processing, time to first response and answer generation. Then measure completion of the actual job. A short answer that arrives quickly but requires a manual rewrite can be less useful than a slower answer that passes the acceptance test.

Use a representative document or repository rather than a greeting. Repeat the run with the application’s normal background workload present. Record failures as carefully as successful output, including loading errors and interrupted requests. The goal is a believable operating envelope for your computer, not a personal best that disappears when the browser is open.

“Frontier” needs a task and a receipt

Edge0 publishes quality comparisons, but its repository explicitly labels the results as model-level scores rather than separate evaluations of the two released formats. That limits what builders can infer about the exact local artifact. The published comparisons are developer-reported evidence; this review did not reproduce them. Edge0 quality reporting

The next step is a small acceptance set drawn from real work. For a software project, choose a contained defect, a change that crosses files and a request with a deliberately incomplete specification. Define success before generating output: relevant tests pass, unrelated behavior remains intact, and the proposed change survives review. These are suggested evaluation tasks, not reported Edge0 results.

For document work, require answers that point back to supporting passages. Include a question the supplied material cannot answer, then check whether the system admits the gap. That exposes a different failure mode from fluent summarization: an answer can read beautifully while inventing the one detail the reader needed verified.

Compare Edge0-145B with the system you already use, under equivalent instructions and access to tools. Count corrections and retries as part of the result. A local system earns its place when it handles a defined workload acceptably under your constraints. It does not need a universal crown, and a leaderboard position cannot choose those constraints for you.

Connect it carefully, then test the awkward parts

Edge0’s serving guide documents a local chat-completions endpoint using the identifier edge0_145b. It also warns that concurrent requests queue, and that identical requests at temperature zero can produce different answers. Those behaviors matter when moving from an interactive trial to an application. Official serving guide

Start integration with a disposable client and a fixed request you can inspect. Verify response parsing, cancellation and failure handling before pointing an existing workflow at the server. Endpoint compatibility can make connection easier, but the application still needs to understand how this implementation behaves when something goes wrong.

Then submit overlapping requests and observe the wait. Set a timeout policy that matches the user experience you can support. For repeated prompts, evaluate whether the answers meet the same acceptance criteria rather than assuming identical wording. These checks turn documented caveats into decisions about your own application.

Finally, distinguish local inference from the surrounding workflow. Inspect any connected tools, logging destinations and fallback services before making a privacy promise to users. Price the deployment using completed work, hardware use and maintenance effort; no verified purchase price or operating-cost estimate is established here. Edge0-145B merits a reproducible trial on supported hardware. Let that trial determine whether it earns permanent disk space.

Frequently asked questions

Can Edge0-145B run on any personal computer?

No. The current release documentation specifies Linux or Windows with an NVIDIA GPU and CUDA 13.

Are its performance claims independently confirmed here?

No. The cited performance and quality results are published by Edge0; this review did not reproduce them.

What should a builder test first?

Run the exact downloaded build on a representative task, recording answer quality, complete request time and resource use.