WeVisOne-VL-4B vs Moondream 3: One Has No API, the Other Is Losing Its Own

On 13 November 2026, Moondream Cloud stops answering. The hosted API that made Moondream 3 a one-line integration closes, purchased credits are refunded, and the Lens fine-tuning product goes with it. That date is three weeks away. WeVisOne-VL-4B, by contrast, has never had an API to lose — Tencent published the weights on 22 October 2026 with no endpoint, no pricing and no announcement. So the practical question in this comparison is no longer "which small vision model is better." It is "which set of weights do I want to operate myself," because as of today both models are self-hosting decisions, and one of them just became one involuntarily.

The two are genuinely different machines, and the difference explains why one had a cloud business and the other did not.

What happened to Moondream 3

The timeline is worth laying out because it is easy to miss and it changes the calculus. Moondream 3 Preview shipped on 18 September 2025 as a 9B-parameter mixture-of-experts model with 2B active parameters. Moondream 3.1 followed on 7 July 2026. On 13 October 2026, Prime Intellect announced it had acquired Moondream — the founding team and the Photon inference engine included — and Moondream's own post followed a day later. A month later the cloud shuts down.

None of that removes the weights. They stay on Hugging Face under the Business Source License 1.1 with an Additional Use Grant, and Photon remains free to run on recent Nvidia GPUs and Apple Silicon, with a compatible local API and no key required for the base model. What disappears is the hosted path — the thing that let a team evaluate Moondream 3 in an afternoon without owning a GPU.

Two architectures, two reasons for existing

Moondream 3 is a sparse model: 9B total parameters, 2B active per token, 64 experts with 8 activated, initialized from the 2B dense Moondream 2 by upcycling. It carries a 32K context, a SigLIP vision encoder with multi-crop channel concatenation, and a SuperBPE tokenizer the company says makes generation 20–40% faster. The design goal was frontier-adjacent visual reasoning at a cost closer to a 2B model — pay for 2B activations, get some of the behaviour of 9B.

WeVisOne-VL-4B is dense and single-minded: a 4.83B Qwen3-VL backbone, coordinate tokens from <0> to <1000> for boxes and points, and a 9.6M-parameter decoder keyed off a special <OBJ> token that turns a predicted box into a mask and then a full-resolution alpha matte. Where Moondream spreads capacity across many visual tasks, WeVisOne concentrates on the last mile of localization — including the part almost nobody ships, soft-edged transparency.

• Total parameters — WeVisOne-VL-4B 4.83B dense vs Moondream 3 9B total, 2B active

• Weight footprint — roughly 19 GB in F32 for the 4B vs about 18 GB in FP16 for Moondream 3, around 6 GB in a community INT4 quant

• Context — unpublished vs 32,768 tokens

• Pixel output — instance masks and continuous alpha mattes at stride 1 vs segmentation masks

• License — Apache 2.0 for Tencent-authored code vs Business Source License 1.1 with an Additional Use Grant

• Hosted API — none ever vs closing 13 November 2026

• Inference engine — stock vLLM, SGLang or the project package vs Photon, purpose-built

The benchmark numbers are not the same kind of number

Moondream's models page lists COCO mAP of 51.2. WeVisOne's README lists COCO F1 mean of 57.1, with F1 at IoU 0.5 of 74.0. Those figures cannot be subtracted from each other. Mean average precision and F1 at a fixed IoU threshold reward different behaviour: mAP punishes a model that finds objects but ranks them badly, while F1 at 0.5 is forgiving of loose boxes. Anyone who tells you WeVisOne beats Moondream 3 by six points on COCO has compared two different exams.

The segmentation rows are closer to comparable and more interesting. Moondream reports RefCOCO val segmentation at 83.2 mIoU; WeVisOne reports RefCOCO val at 81.4 cIoU. Both are intersection-over-union against referring expressions on the same dataset split, but mIoU and cIoU aggregate differently across images, so a 1.8-point gap is well inside the noise of the metric choice. Treat them as roughly level.

Where the two tables genuinely diverge is in what they chose to report at all. Moondream publishes ScreenSpot 80.4, OCRBench 61.2, TextVQA 76.3, POPE 89.0 and CountBenchQA in the low nineties depending on which of its own pages you read — the launch post and the models page disagree with each other on several rows, which is worth knowing before you quote either. WeVisOne publishes rejection rates (96.4% on WeRef-Bench), dense detection on Dense200 and VisDrone, and matting error on P3M-500-NP and AM-2K. Neither model's authors evaluated the other.

Licensing will decide more deals than benchmarks

WeVisOne-VL-4B is Apache 2.0 for Tencent-authored code. Moondream 3 is under the Business Source License 1.1 with an Additional Use Grant, which permits personal, research and most commercial use but requires an arrangement with M87 Labs for third-party hosting or rehosting of the model. If you are building an internal tool, both are fine. If you are building a product whose value is serving that model to other people, only one of them is straightforward.

The acquisition adds a second-order risk that has nothing to do with the license text: stewardship. A model whose commercial parent has just changed hands and whose hosted product is closing is a model whose roadmap you cannot read. That is not a reason to avoid it — the weights are downloaded, not rented — but it is a reason to test it rather than standardize on it this quarter.

What the matting capability is actually worth

Moondream 3 will return a segmentation mask for "the person." WeVisOne-VL-4B will return a mask and an alpha matte with partial transparency along hair, fur and soft edges, refined at stride 1. For a compositing pipeline, that is the difference between a cutout with a hard halo and one you can drop onto a new background without a cleanup pass.

Tencent's numbers for it are striking and unverified: a mean absolute difference of 7.3 on P3M-500-NP against 15.4 for the strongest baseline the authors list, and 9.8 on referring-expression matting on WeRefMat against 22.4. Those come from the paper, were produced by the model's authors, and have not been reproduced. They are also the only public evidence that this approach works, because no independent lab has run it yet.

Operating a model when the endpoint disappears

The Moondream shutdown is a useful reminder that a hosted endpoint is a dependency with a lifetime someone else controls. Neither Moondream 3 nor WeVisOne-VL-4B is in OrcaRouter's catalogue today, so this is not a pitch for a route that exists — it is the reason the routing layer exists at all.

When a provider withdraws a model, the difference between an outage and a config change is whether your application addresses a model name or an endpoint URL. OrcaRouter holds more than 200 models behind a single key at 0% markup over provider list price, and automatic failover moves a request to a healthy provider instead of returning an error. For a pipeline built on a model that might get acquired, that abstraction is the part you cannot retrofit in three weeks.

The recommendation, three weeks out

If you are running Moondream 3 Preview or 3.1 through the hosted API, the decision is now and it is not about quality: move to Photon self-hosting, or pick a different model, before 13 November. Do not wait for a replacement service to appear.

If you are choosing fresh and your work ends in masks or mattes, WeVisOne-VL-4B is the more interesting bet and the less proven one — Apache 2.0, a real architectural idea, and two days of public history. If you need a broad visual reasoner with a mature inference engine and a track record across many tasks, Moondream 3 is still the safer model to self-host, acquisition or not.

And if what you actually need is neither, but a general vision model behind an API you do not have to operate, that is a different question with a much shorter answer. Neither of these models is it.