770B-Parameter Open-Source Model Stable Release: A Hands-On Review of Vision and Computer Use Capabilities

1. Background: A Capability Leap for a Flagship Open-Source Model

A major cloud provider recently shipped the stable release of its latest large language model, positioning it as “among the strongest open-source models” for the first time. Compared with the preview version, the stable release’s biggest additions are two capabilities: vision understanding and computer use. The former enables the model to interpret images, charts, and interface screenshots; the latter lets it carry out cross-application tasks by combining the command line with graphical interfaces.

Architecturally, the model uses a Mixture-of-Experts (MoE) design with a total parameter count of roughly 770B, of which about 49B are activated per inference. That is around 2.6 times the size of the previous generation, which came in under 300B, making this the largest model in the vendor’s lineup. It also offers a 1 million-token context window (API spec), enough to process long documents or large code repositories in a single pass.

The combination changes the model’s profile: it is no longer just a strong reader of text, but is starting to “see” and “operate.” For developers handling multimodal input or automating cross-application workflows, these capabilities directly affect technology choices.

2. Inference Cost and Access

On cost, the stable release’s API pricing matches the preview version: roughly RMB 6 per million input tokens, RMB 18 per million output tokens, and about RMB 0.3 per million for cache hits, all on the same per-million-token billing basis. Among flagship-tier models, this sits in the lower price range. For reference, the output pricing of some comparable flagship models works out to roughly four times this level.

For most developers, the simplest way to get started is to select the model from the model list in mainstream AI coding tools or productivity platforms. The configuration used in this hands-on review: the model with thinking intensity set to “high.”

Note that high thinking intensity lengthens the reasoning chain and increases response time, but it generally produces more stable output quality on complex logic tasks. Developers should weigh “speed” against “depth” based on the task at hand.

3. Benchmark Discrepancies: Official Scores vs. Third-Party Evaluations

The official messaging emphasizes “the strongest open-source model,” but third-party evaluation results do not fully agree. On a composite intelligence index, the model trails some leading competitors by about 11 points, and its hallucination rate is flagged as “high.” Gaps like this are not unusual, and they usually come down to three things:

1. Different evaluation dimensions: Official benchmarks tend to focus on specific areas (code, math, multilingual tasks), while third-party composite indexes include more general reasoning and factual-consistency tasks.
2. Hallucination rates are strongly task-dependent: They run higher in open-domain Q&A, but their impact drops noticeably in tasks with clear contextual constraints, such as long-document summarization or code completion.
3. Version and configuration differences: The stable release adds vision and computer use; an evaluation that doesn’t cover these dimensions can’t reflect the model’s full capability set.

The more productive approach is not to debate which model is “strongest” but to match the model to the task type. For scenarios that demand strict factual consistency, combine it with retrieval-augmented generation (RAG) or human verification. For creative generation, code drafts, and UI understanding, the downside of a higher hallucination rate is comparatively manageable.

4. Hands-On Test 1: Complex Logic Tasks

The first test used a 3D gold-miner-style logic task to compare this model with peer flagship models on complex rule-based reasoning and code generation. The task required the model to understand game mechanics, generate runnable code, and fix logic flaws across multiple rounds of interaction.

At high thinking intensity, the model built out the core logic with a clean code structure and consistent variable naming, but edge-case handling still needed manual adjustment. Peer flagship models performed similarly on the same task, with the differences showing up mainly in:

• Reasoning chain length: At high thinking intensity, the model produces longer intermediate reasoning, which helps surface logical contradictions but increases response time.
• Code readability: Generated code came with sensible comments and module separation, making it easy to extend.
• Error recovery: When the first pass contained defects, the model could quickly locate problems from feedback — as long as the error was described clearly.

The takeaway: the model is usable for complex logic tasks, but don’t expect “perfect on the first try.” Treat it as an efficient draft generator and logic-checking assistant rather than a full replacement for human review.

5. Hands-On Test 2: Vision Understanding and Sketch-to-Webpage

The second test examined vision understanding by converting a hand-drawn sketch into a web page. The model had to recognize layout elements in a hand-drawn wireframe (navigation bar, cards, buttons, forms) and generate the corresponding HTML/CSS.

Findings:

• Accurate layout recognition: The model correctly distinguished header, sidebar, content area, and footer, and identified the main interactive elements.
• Reasonable style reproduction: The generated CSS followed common practice for spacing, alignment, and responsive breakpoints; colors and fonts still needed manual tuning.
• Complete semantic structure: HTML tags were used appropriately, with basic accessibility attributes in place.

The limitations: with ambiguous or overlapping sketch elements, the model could misjudge hierarchy, and complex interactions (drag-and-drop, dynamic loading) required extra logic. Overall, vision understanding delivers a real efficiency gain at the “sketch-to-prototype” stage and works well for quickly validating product ideas.

6. Computer Use: Potential Value and Current Limits

The stable release supports computer use for the first time, meaning the model can execute cross-application tasks by combining the command line with graphical interfaces. Typical scenarios include:

• Automated data collection and organization: open a browser, extract page information, and write it into a spreadsheet.
• Cross-application workflows: pull attachments from email, process them with local scripts, and upload results to a target system.
• UI testing support: simulate user operation paths and generate test reports.

A realistic view is warranted: computer use is still at an early stage. Its reliability is constrained by UI element recognition accuracy, exception handling, and permission controls. In enterprise environments, pair it with sandbox isolation, operation auditing, and human confirmation steps to keep automated workflows from running out of control.

7. Who It Suits: Selection Recommendations

Based on the analysis above, the stable release is a good fit for:

1. Development tasks with multimodal input: screenshot-to-code, chart understanding, post-OCR document processing.
2. Long-context work: the 1 million-token window suits large codebase analysis and long report summarization.
3. Cost-sensitive flagship-level needs: lower pricing than comparable models makes it viable for high-frequency calls.
4. Automation workflow exploration: computer use can support prototype validation, provided security measures are in place.

Poor fits include open-domain Q&A with strict factual-consistency requirements and no human verification, and finance or medical decision scenarios that require rigorous compliance auditing.

8. Conclusion

The stable release delivers substantial upgrades in parameter scale, context length, vision understanding, and computer use, at a competitive price. But the “strongest open-source model” claim deserves a measured reading alongside third-party evaluations and hands-on results: the model stands out in multimodal and automation tasks, while the composite intelligence index and hallucination rate still leave room for improvement.

For developers, the goal is not to find an “all-powerful model” but to build a matrix that matches tasks to model capabilities. Before adopting it, run small-scale comparison tests with your own business data, focusing on output stability, the business impact of hallucinations, and inference cost versus latency. Only with clearly defined boundaries can a large model be turned into real productivity.