WeVisOne-VL-4B vs UI-Venus-2-9B: One Returns a Mask, the Other Returns a Click

Hand the same screenshot of a checkout page to WeVisOne-VL-4B and to UI-Venus-2-9B and you get two different kinds of answer. The first gives you geometry: a box around the cart icon, a segmentation mask around the discount field, an alpha matte cutting the product photo out of its background. The second gives you a move: the coordinates of the next tap, plus the reasoning that produced it. Tencent's WeChat Vision team published WeVisOne-VL-4B to Hugging Face without an announcement and dated its technical paper 23 October 2026; inclusionAI's UI-Venus-2-9B has been downloadable since 26 August 2026. They get filed under the same modality label and they are not substitutes.

That makes this a comparison with an unusual problem at its centre: the two models have no benchmark in common. Not one score appears on both cards. Neither has been independently evaluated, neither is deployed by an inference provider, and neither has a published price. What can be compared honestly is what each one outputs, how each was trained to refuse, what they cost to run, and which licence you would be shipping under — so that is what this piece does, and it flags vendor-reported numbers as vendor-reported every time one appears.

The two models are not answering the same question

WeVisOne-VL-4B is a perception model. It is built on a Qwen3-VL backbone and adds a required 9.6-million-parameter pixel decoder — mask_decoder.pt, shipped as a second artifact — which turns the language model's box predictions into instance masks and then into stride-1 alpha mattes. Coordinates are emitted as dedicated tokens spanning <0> to <1000>, normalised to the image, and a special <OBJ> token (id 152,678) closes each box in dense tasks. The paper's task list is a list of geometry: open-vocabulary detection, referring localisation, counting, pointing, OCR localisation, referring segmentation and promptable alpha matting.

UI-Venus-2-9B is an agent. It is initialised from Qwen3.5-9B and trained on screenshot-only interaction across five task families — grounding, CAPTCHA, mobile, web and computer — through mid-training, offline step-level reinforcement learning and multi-teacher on-policy distillation. Its output is an action in a closed observe–reason–act loop, and its vLLM recipe pairs --max-model-len 262144 with --reasoning-parser qwen3 because it emits reasoning tokens ahead of every action.

Put the specs side by side and the split is immediate:

• What comes out — boxes, points, masks and alpha mattes from WeVisOne-VL-4B; one action plus its reasoning trace from UI-Venus-2-9B.

• Backbone — Qwen3-VL for WeVisOne-VL-4B; Qwen3.5-9B for UI-Venus-2-9B. Different generations, different families of text stack.

• Size — 5B parameters listed on the repo despite a "4B" name, plus a separate 9.6M-parameter decoder; 9B dense for UI-Venus-2-9B across four BF16 shards, about 18.8 GB.

• Weights format — F32 safetensors on the WeVisOne-VL-4B card, which is unusual at this size and makes the download larger than the parameter count suggests; BF16 for UI-Venus-2-9B.

• Licence — Apache 2.0 for WeVisOne-VL-4B; "pending final confirmation" for UI-Venus-2-9B.

The practical consequence is that you cannot swap one for the other, and any article that gives you a winner is answering a question you did not ask. A perception model that returns a perfect mask still cannot click. An agent that clicks perfectly still cannot hand you the matte you wanted for the product shoot.

Where they genuinely overlap: both teams taught their model to say no

This is the one design decision both releases made, and it is the most interesting thing in the pairing. Open-vocabulary localisation models fail in a specific, expensive way: ask for the fire extinguisher in a room that has none and a model that always answers will confidently box the radiator. Downstream, that is a hallucinated object in your asset pipeline or a misdirected tap in your automation loop.

WeVisOne-VL-4B handles it by returning None, and the paper reports the rejection rate as its own metric alongside accuracy. On RefCOCOg the 4B model reaches a 67.4 rejection rate where its Qwen3-VL-4B base sits at 18.8. On the WeChat-internal WeRef-Bench it reports 96.4 rejection against 61.9 for the base model, and on Ref-ZOM 86.0 against 0.3 for UniPixel-7B. Those are self-reported figures from a paper published today, and the rejection benchmarks are largely the authors' own — treat the direction as credible and the exact gap as unverified.

UI-Venus-2-9B comes at the same problem from the agent side, inheriting refusal-aware grounding from the UI-Venus line: the model is trained to decline when the requested element is not on screen rather than to guess a plausible location. Its grounding numbers — ScreenSpot-Pro 73.0, VenusBench-GD 77.1, OSWorld-G-R 78.5 — are vendor-reported, and the card is explicit that this does not eliminate harmful-action risk and recommends human confirmation plus application-level safeguards. Its safety table shows the effect it does claim: an 11.3% attack success rate on OSHarm against 25.3% for the Qwen3.5-9B base, and 48.8% on OSBlind against 79.4%.

So both models were built by teams that had watched a localiser lie, and both chose abstention over coverage. If your application's failure mode is "confidently wrong," that shared priority matters more than the parameter counts.

The numbers Tencent's model card does not show

Every write-up of WeVisOne-VL-4B so far has said the same thing, correctly: the model card publishes no benchmarks. The technical paper does, and it landed on 23 October 2026, which makes this the part of the story that has not circulated yet. All of it is self-reported by the authors, none of it has been independently reproduced, and the model is one day old — so read these as claims with a shape, not as settled results.

Against its own Qwen3-VL-4B base, the gaps are large enough that they would be interesting even after heavy discounting:

• Detection, COCO zero-shot mean F1 — 57.1 for WeVisOne-VL-4B vs 48.7 for Qwen3-VL-4B, and 55.3 vs 44.0 on LVIS.

• Detection, Dense200 mean F1 — 71.3 vs 15.2. That is not a typo in the paper's table; dense small-object scenes are where the base model collapses.

• Referring detection, RefCOCOg val — 80.8 vs 74.1, with the rejection rate at 67.4 vs 18.8.

• Counting, PixMo-Count val exact match — 93.7 vs 69.6; on MixCount val, 42.0 vs 3.5.

• Pointing, PointBench F1 — 71.9 vs 57.1.

• OCR localisation, SROIE mean F1 — 68.1 vs 40.4, and ahead of PP-OCRv5's 58.6.

• Referring segmentation, ReasonSeg val gIoU — 71.2, against 65.0 for LISA-13B.

• Promptable matting, AM-2K box prompt MAD — 5.0 against 12.1 for SAM2-Matting; on WeRefMat referring prompts, 9.8 against 51.9.

The matting result is the one worth pausing on, because it is the capability nothing else in this price class offers through a prompt. Asking a vision-language model for "the person, as an alpha matte" and getting a stride-1 output that beats a SAM2 matting pipeline on MAD is a different product from a detection head with a mask attached. It is also where the paper is least flattering to its own 4B: on P3M-500-NP box prompts the 2B model scores 6.6 MAD against the 4B's 7.3, so the bigger variant is not uniformly better and the authors print it.

What UI-Venus-2-9B's numbers measure, and why they will not transfer

Set the two benchmark suites next to each other and the incomparability stops being a technicality. UI-Venus-2-9B's headline results are all end-state success rates in an environment: AndroidWorld 80.2, OSWorld-Verified 70.8, WebVoyager 90.8, Online-Mind2Web 74.0, MobileWorld 65.8 at the card's default step budget and 75.2 at 100 steps. Those numbers measure whether a task got finished, which folds perception, planning, memory and error recovery into one figure.

The closest thing to a shared axis is GUI grounding. UI-Venus-2-9B posts 73.0 on ScreenSpot-Pro, a benchmark of locating small interface elements in high-resolution screenshots — and WeVisOne-VL-4B does not report it. WeVisOne-VL-4B posts OCR localisation and dense pointing results, and UI-Venus-2-9B does not report those. So the honest position is that the single most useful number for this comparison does not exist yet: running WeVisOne-VL-4B on ScreenSpot-Pro would tell you whether a 5B perception specialist beats a 9B agent at finding a button, and until somebody runs it, anyone ranking these two on grounding is guessing.

The agent's own suite also carries its weak spot in public. On OSWorld 2.0 the 9B model scores 7.5 partial and 0.0 binary; the 27B sibling reaches 13.2 partial and 2.8 binary. Long-horizon desktop work is not solved at this size, and the card says so.

Serving them is a bigger gap than the benchmark gap

For a team deciding what to run next week, the operational difference will matter more than any score. UI-Venus-2-9B is a single model you start with one vLLM command, exposing an OpenAI-compatible endpoint with tensor parallelism of 1. WeVisOne-VL-4B needs its inference package from GitHub plus the separate decoder artifact, and it is called through its own WeVisOneVL(...) wrapper with a task argument — predict(image, task="matting", query="person", temperature=0.0). The card documents Transformers, vLLM and SGLang paths, but the pixel decoder is not optional: the language model alone cannot produce a mask.

Memory is closer than the parameter counts suggest. At bf16 the 5B backbone is roughly 10 GB before the decoder, against about 18.8 GB for UI-Venus-2-9B's four shards. Both fit on a single 24 GB card for weights; what differs is how much room is left for context.

And on context, the two configs agree in a way that is easy to over-read. WeVisOne-VL-4B's config ships max_position_embeddings of 262,144 — the same ceiling UI-Venus-2-9B serves with its 262,144 max model length. But they use it for different things: the agent treats long context as episode memory, holding the screenshot history of a task, while the perception model's published evaluations run at 1,960 visual tokens per image. A 256K window on a single-turn, image-only model is a ceiling, not a demonstrated capability, and the card lists video grids as rejected by the pixel decoder outright.

Licence: one of these is settled and one is not

WeVisOne-VL-4B is Apache 2.0, with Tencent-authored code under the same terms. You can read it, fork it, ship it in a product and not talk to a lawyer about it.

UI-Venus-2-9B's card states that the model-weight licence is pending final confirmation and will be added before public release, and that the earlier Apache-2.0 declaration was intentionally not carried over because upstream materials contain conflicting licence statements. That sentence has been on the card since August and has not changed. It does not stop you evaluating the model, and it does not stop internal use in most organisations — but it does mean an external product built on those weights is built on an unresolved question, and no amount of benchmark score fixes that. If you are choosing between these two for something you intend to ship, the licence column decides faster than the accuracy column.

What each one costs, given that neither has a price

There is no vendor-set per-token price for either model. WeVisOne-VL-4B's page says it is not deployed by any inference provider; UI-Venus-2-9B has no first-party endpoint and no rate card published by inclusionAI, so whatever a third-party host charges for it is that host's number, not the team's. For both, the cost is GPU-hours on hardware you rent or own, which means the comparison is not "input price vs output price" but "how much card do I need and how many images per second does it turn."

Neither paper publishes throughput or latency, so that second number is unknown for both. What is knowable is the shape: UI-Venus-2-9B pays for a 9B forward pass plus reasoning tokens on every step of an episode, and an agent episode is many steps. WeVisOne-VL-4B pays for a 5B pass plus a decoder forward per image, and one image is one call. If your workload is a hundred thousand product photos, the perception model's economics are per-image and predictable; if it is a browser task, the agent's cost scales with how many actions the task takes, which is the number you cannot forecast from the card.

This is also where a routing layer earns its place rather than being a slogan. Neither model is on OrcaRouter today, and this piece is not going to pretend otherwise — WeVisOne-VL-4B has no inference provider at all, and UI-Venus-2-9B is served by third-party hosting rather than from our own catalogue. What OrcaRouter provides for the models it does serve is one OpenAI-compatible endpoint across 200+ of them at 0% markup, with provider list price passed through unchanged, so a vendor price cut reaches you the day it happens rather than at the next contract renewal. For an architecture that calls a perception model and an agent model in sequence, the routing DSL is where that composition lives — two model calls, one place to swap either leg — and automatic failover is what keeps an agent loop alive when the model behind it degrades mid-episode. The moment either of these two lands on a provider, that is the cheapest way to find out whether it belongs in your stack.

Which one to pick

The decision is a job description, not a ranking.

• Pick WeVisOne-VL-4B if the output you need is geometry — bounding boxes into an annotation pipeline, masks for an editing tool, alpha mattes for product imagery, counts of things in a dense aerial frame, or OCR with coordinates attached. Nothing else in the open 5B class returns a matte from a text prompt, and the paper's matting numbers against a SAM2 pipeline are the strongest claim in the release.

• Pick UI-Venus-2-9B if the output you need is a completed task — a form filled, an app navigated, a CAPTCHA solved, a desktop workflow driven from screenshots. It ships as one vLLM command with an OpenAI-compatible endpoint, which is a day of work rather than a week, and its AndroidWorld and WebVoyager results are the numbers to check against your own environment.

• Pick neither yet if you need independent evidence, a published price, or a settled licence for a shipping product. All three are missing for UI-Venus-2-9B's licence and for both models' benchmarks.

• Consider both if you are building an agent that has to manipulate images rather than just click through screens. The composition is the interesting one: UI-Venus-2-9B decides where to act, WeVisOne-VL-4B produces the pixel-accurate artifact the action was aiming at. That costs two model calls per step and buys a precision neither model has alone.

What would change this answer

Four things, in order of how much they would move it.

A ScreenSpot-Pro run of WeVisOne-VL-4B. It is the one benchmark both sides could plausibly sit on, and it would settle whether a perception specialist at half the size out-localises a purpose-built UI agent. Anyone with a GPU and an afternoon can produce it, and nobody has.

An independent evaluation of either model. Every number in this article traces back to a model card or a paper written by the team that built the thing. That is normal on release day and it is still an absence.

A resolved licence on UI-Venus-2-9B. "Pending final confirmation" has been on the card for eight weeks. If it resolves to something permissive, the agent becomes considerably easier to recommend for commercial work; if it does not, that answers the question the other way.

A first-party endpoint for either. Neither vendor serves its own model today, which limits the audience to teams willing to run a serving stack, and on the WeVisOne-VL-4B side to teams willing to drive a custom inference package. A vendor-published rate would change the cost comparison from arithmetic to a line item.

Until then the fair summary is this: Tencent shipped a perception toolkit that does something no small open model did before, quietly enough that its own benchmark tables have not been read yet, and Ant Group shipped an agent a month and a half earlier that is easier to run and harder to license. They are not rivals. The mistake would be picking one because the other scored higher on a benchmark they do not share.