How LLMs Are Leaping in Vertical Capabilities: Code, 3D, and Finance
This article examines how large language models are shifting from chat-style evaluation toward agentic task completion, driving sharp capability gains in three high-value verticals: terminal-based coding agents, script-driven 3D creation, and financial document analysis. It breaks down the technical logic behind each scenario, including multi-step planning, environment interaction, error recovery, cross-document verification, and hallucination suppression. It also offers a practical methodology for model selection that weighs unit task cost against benchmark scores, and closes with concrete recommendations for moving from demo to production.
1. Background: When the Evaluation Baton Shifts, Model Capabilities Follow
Over the past two years, the focus of competition among large models has clearly shifted. Early evaluations centered on single-turn Q&A and knowledge recall, where a model could score well simply by “talking a good game.” Today, mainstream benchmarks have pivoted toward agentic tasks, requiring models to execute continuously in real software environments, self-correct, and deliver results. Once the baton changed hands, the focus of post-training also shifted from “aligning chat style” to “strengthening task completion.”
Recent iterations of a batch of industry models share a common trait: capabilities have surged in high-value vertical scenarios such as coding, 3D creation, and financial analysis, while hallucination rates have dropped significantly and per-task costs continue to fall. This article breaks down the technical logic behind these four directions one by one, and offers guidance on model selection and deployment.
2. Coding Capabilities: Agentic Programming in the Terminal Environment
2.1 What Terminal-Based Benchmarks Actually Test
A class of benchmarks represented by terminal coding agents asks models to complete a long sequence of operations in a real command-line environment: installing dependencies, modifying code, running tests, fixing errors, and more. What it examines is not “writing a function,” but rather:
- Multi-step planning: breaking vague requirements into executable command sequences;
- Environment interaction: reading error messages, logs, and file contents to dynamically adjust strategy;
- Error recovery: locating the root cause after a command fails, rather than retrying in place;
- Long-horizon consistency: staying on target after dozens of operations.
Judging from public evaluation trends, top-tier models can now go toe-to-toe with the strongest closed-source models on these tasks, and the gap between the open-weight camp and commercial models has been compressed to within single-digit scores—something hard to imagine a year ago.
2.2 Cost: The Underrated Second Battlefield
Benchmark scores only tell half the story. Token consumption for agentic tasks is dozens of times that of ordinary Q&A: a single task may involve hundreds of tool calls and tens of thousands of tokens of context. As a result, “unit task cost” becomes a key selection metric:
- Cheap per call does not equal low total task cost. Models with poor inference efficiency and verbose output will repeatedly trial-and-error, ending up more expensive;
- The industry has already formed a landscape where “small and fast models with slightly lesser capability but extremely low cost” coexist with “flagship models with capped-out capability but higher unit price”;
- The correct engineering answer is tiered routing: hand simple changes to low-cost models, and only route complex refactoring to flagship models.
A typical terminal agent execution loop looks roughly like this:
# Terminal agent pseudocode: observe-think-act loopwhile not task_done:obs = sandbox.run(next_command) # Execute command in sandboxthought = llm.reason(goal, history, obs) # Reason based on goal and observationif thought.needs_more_info:next_command = thought.next_action # Continue with the next commandelif thought.task_verified:task_done = True # Tests pass, task completeelse:next_command = thought.fix_plan() # Correct the plan based on errors
3. 3D Creation: A New Paradigm Opened by Direct Script Authoring
3.1 Why 3D Is a Tough Nut to Crack
The barrier to 3D modeling has long been high: professional software has a steep learning curve, and asset production is heavily labor-dependent. Having a large model directly output a 3D mesh is unrealistic—tensors made of vertices and faces are both hard to generate and hard to validate.
3.2 Direct Script Authoring: A Pragmatic Route That Bypasses the Middle Layer
A more feasible path is to have the model write scripts for professional modeling tools directly, building scenes in a parametric, programmatic way: creating geometry, performing Boolean operations, adjusting layout, assigning materials, and setting lighting. The value of this route lies in:
- No additional tool-calling middle layer: scripts output by the model are executed directly by the modeling software, making the chain short and highly controllable;
- Reusable parameters: changing a single value in the script can batch-adjust the model, naturally suited to iteration;
- Verifiable results: scripts are deterministic, and execution results can be previewed and rolled back.
Recent advances in spatial reasoning have brought tool-dependent CAD modeling benchmark scores close to the strongest closed-source models—the best level open-weight models have achieved in the 3D direction so far. From public demonstrations, complex interior scenes, mechanical structures, and printable physical objects can all be generated from scripts. An illustration follows:
# Parametric modeling pseudocode: generate a 3D-printable desk lampbase = modeling.cylinder(r=60, h=12) # Basepole = modeling.torus_knot(p=3, q=2, scale=0.8) # Artistic lamp poleshade = modeling.lathe(profile=lamp_profile) # Rotation-formed lampshadescene.union([base, pole, shade])scene.set_material(shade, "translucent") # Translucent materialexport.stl("desk_lamp.stl", check_printability=True)
3.3 A Complete Chain from Generation to Delivery
For capability to translate into productivity, a supporting chain is also needed: online preview and editing lower the barrier to trial, models can directly export print files, and results can be rendered into videos or GIFs for sharing and distribution. For scenarios such as e-commerce displays, game prototyping, and teaching-aid production, this means the cycle from “idea to physical object” is compressed from weeks to hours, and the adoption curve among creator communities is expected to be genuinely pulled forward.
4. Financial Analysis: Retrieval, Verification, and Multi-Step Numerical Reasoning
4.1 Why Real Financial Documents Are Hard
The difficulty of financial documents lies not in “reading the words” but in “reconciling the numbers”: the same metric may have inconsistent definitions across the main text, footnotes, and different statements, requiring cross-document retrieval, cross-checking, and then multi-step numerical reasoning. If any step goes wrong, the conclusion is wrong.
4.2 Technical Breakdown
A reliable financial analysis pipeline typically includes:
- Document parsing: restoring tables and footnotes in PDFs into structured data;
- Retrieval and localization: precisely locating relevant sections and data sources based on the question;
- Cross-document verification: identifying discrepancies in definitions and flagging conflicting data;
- Multi-step reasoning: computing step by step from raw data while preserving intermediate steps;
- Result validation: using dimensional checks and articulation relationships to verify that conclusions are self-consistent.
In recent public evaluations, some models have topped financial document QA benchmarks and approached the best level in investment workflow evaluations covering everything from target screening to profitability analysis, showing that the combination of “retrieval + verification + reasoning” is beginning to pay off.
4.3 Hallucination: A Zero-Tolerance Item in Financial Scenarios
Financial scenarios have near-zero tolerance for hallucination—fabricating a single number could mislead an investment decision. Common suppression methods in the industry include:
- Citation and traceability: requiring every conclusion to include a source for manual verification;
- Refusal mechanism: explicitly saying “not found” for data that does not exist in the document;
- Self-consistency checking: sampling multiple times and comparing results to eliminate unstable answers;
- Adversarial stress testing: constructing numerical traps and unanswerable questions to quantify error rates.
Taking publicly disclosed iteration trends in the industry as an example, the hallucination error rate of leading models has dropped from above 20% in the previous generation to within 10%—an improvement driven jointly by stress testing and verifiable-reward training.
5. Balancing Cost and Performance: A Selection Methodology
Benchmark scores are only the starting point. For engineering selection, it is advisable to follow four steps:
- Align with the business: prioritize evaluations that match your own task形态—terminal coding, document reasoning, spatial reasoning—and treat general leaderboards only as reference;
- Do the total math: estimate real costs using “unit task cost ≈ total token consumption × unit price ÷ task success rate”;
- Look at weaknesses: constraints such as hallucination rate, latency, and context length often determine success or failure more than strengths do;
- Keep a way out: abstract the model access layer to avoid deep lock-in with a single vendor.
It is worth emphasizing that the gap between open-weight models and commercial closed-source models is narrowing substantially across multiple vertical dimensions. “Open source is good enough” is turning from a slogan into a verifiable conclusion, which also gives enterprises stronger bargaining power and more flexible private deployment options.
6. Deployment Advice: From Demo to Production
For developers and enterprises, three pragmatic recommendations:
- Evaluation first: build a golden evaluation set of 100–200 items using real business data, and run the scores before scaling up;
- Human in the loop: have 3D assets and financial conclusions generated as first drafts by the model, then reviewed by humans before delivery, positioning the model as a “multiplier” rather than a “replacement”;
- Build the platform in the cloud: leverage general capabilities such as large model services, object storage, containers, and monitoring and alerting provided by platforms like Baidu AI Cloud to quickly assemble a complete chain from model invocation and file management to task orchestration, so you can focus your energy on the business logic itself.
7. Conclusion
What coding, 3D, and finance have in common is that they are all “long-chain, strongly verified, high-value” tasks—exactly where post-training and agentic techniques are best at delivering results. Where the evaluation baton points, capabilities grow. For practitioners, rather than obsessing over the score of a particular release, it is better to understand the underlying technical paradigm. Making evaluations solid, calculating costs clearly, and keeping hallucinations under control—these are the three cornerstones for truly bringing large models into production.
