Open-Source LLMs Level Up: Code Agents, 3D Scripting, and Financial Analysis

1. Background: Open-Source LLMs Enter a Capability Leap

Over the past year, the gap between open-source and closed-source models has been narrowing rapidly. The latest generation of open-source models generally follows a “base pre-training + post-training reinforcement” iteration paradigm: on top of a base model, post-training techniques such as instruction fine-tuning and reinforcement learning from verifiable rewards push model capabilities from “answering questions” to “getting things done.” Based on public evaluations and community practice, this leap is concentrated in four directions:

• Code agents and terminal automation: moving from code completion to a complete loop of “receive task—operate environment—self-repair—deliver result”;
• 3D content creation: moving from “text description generation” to deterministic output by “directly writing scripts for professional modeling software”;
• Financial document analysis: cross-document retrieval, figure reconciliation, and multi-step numerical reasoning becoming standard capabilities;
• Factual alignment: hallucination rates dropping significantly, with output trustworthiness entering the production-usable range.

The following sections break down the technical drivers, evaluation dimensions, and engineering practices for each direction.

2. Code Agents and Terminal Automation: From “Completing Code” to “Completing Tasks”

2.1 Shifting Evaluation Dimensions

Traditional code evaluation focuses on function-level correctness, while the new generation of evaluation places models in a real command-line environment: given only a task description and an interactive terminal, it examines whether the model can autonomously complete environment exploration, dependency installation, file modification, test execution, and error repair. This type of evaluation measures not “writing code” but “getting things done,” and therefore better reflects agent-level engineering capability.

A notable signal: the new generation of open-source models has for the first time entered the same tier as top closed-source models in this kind of evaluation, while keeping per-task cost in the optimal range among frontier models. This means that along the main line of “multi-step tool calling + long-horizon planning + error recovery,” open-source solutions are now production-ready.

2.2 Three Technical Drivers

1. Long context and state management: context windows on the order of 100K tokens, combined with working memory compression and key-state extraction strategies, allow agents to retain task goals after dozens of rounds of tool calls;
2. Tool-calling reliability: stable function-calling formats, support for parallel calls, and retry and fallback strategies after failed calls;
3. Feedback-based self-repair: feeding compile errors, test failures, and process exit codes back to the model as feedback signals, forming an “execute—observe—correct” loop.

An illustrative agent main loop is shown below:

# Terminal agent main loop (illustrative pseudocode)
while not task_done:
    observation = run_command(next_action)   # Execute command and capture output
    if observation.failed:
        plan = model.revise(plan, observation)  # On failure, analyze cause and revise plan
    else:
        plan = model.advance(plan, observation) # On success, advance to the next step

2.3 The Cost Perspective: Look at the Pareto Frontier, Not a Single Score

When selecting a model, don’t look only at leaderboard scores. From an engineering standpoint, the more relevant consideration is the “performance–cost Pareto frontier”: at the same task success rate, who has the lower unit cost. In practice, consider:

• Difficulty-tiered routing: route simple tasks to lightweight models and complex tasks to flagship models;
• Accounting by “comprehensive task success cost”: factor retries, timeouts, and human intervention into the calculation rather than looking only at price per million tokens;
• Cache reuse: use prefix caching for system prompts and shared context to amortize repeated overhead.

3. 3D Content Creation: Direct Scripting Becomes a New Paradigm

3.1 The Divide Between Two Technical Routes

Previously, there were mainly two routes for getting LLMs involved in 3D creation:

1. Plugin/protocol wrapper route: wrap the functions of modeling software into tool interfaces, and the model operates the software by calling those interfaces. The advantage is strong controllability; the drawback is coarse interface granularity and limited expressiveness—complex scenarios require extensive custom wrappers, and development and maintenance costs are high.
2. Direct scripting route: mainstream professional modeling software generally embeds a scripting engine, and the model writes modeling scripts directly, which are executed by the scripting engine. The advantages are strong expressiveness, reproducible output, and versionability.

Advances in the new generation of open-source models in spatial reasoning and code generation have greatly improved the viability of the second route: in 3D evaluations that depend on tool execution and rendered feedback, their results are already approaching the strongest closed-source models and set the best level among open-source models. More importantly, the model can complete asset construction and refinement directly through “write script—execute—view render—revise script” without relying on additional tool-protocol wrappers—adjusting layout, materials, geometry, and other elements.

3.2 A Reproducible Workflow

Taking a complex scene such as “an indoor forest landscape inside an airport terminal” as an example, a reproducible workflow is:

1. Scene decomposition: break the requirement into geometry (structural columns, planting beds, trees), materials (metal, glass, vegetation), lighting (skylight, artificial lighting), and layout constraints (circulation, evacuation, sightlines);
2. Parametric modeling: use scripts to describe parametric objects rather than modeling vertex by vertex. For example, a tree is driven by parameters such as “trunk height, branch levels, leaf density”;
3. Iterative refinement: render feedback → model reads the image → revise script parameters, forming a closed loop;
4. Asset accumulation: bring validated scripts into version control and accumulate them as a reusable asset library.

# Parametric modeling script (illustrative pseudocode)
def build_tree(trunk_height=4.2, branch_count=6, leaf_density=0.8):
    trunk = cylinder(radius=0.18, height=trunk_height)
    for i in range(branch_count):
        angle = i * 360 / branch_count
        add_branch(trunk, angle=angle, length=2.1 * leaf_density)
    return group(trunk)

For engineering teams, the greatest value of direct scripting is determinism: the same script always produces the same scene, can go through code review, and can be integrated into continuous integration pipelines for batch rendering. The creation process shifts from “black-box generation” to “engineering asset management.”

4. Financial Document Analysis: Retrieval, Reconciliation, and Multi-Step Reasoning

4.1 Why the Task Is Hard

Real financial analysis is not “read one document and answer one question,” but a three-layer stack:

• Cross-document retrieval: income statements, cash flow statements, and notes are scattered across hundreds of pages;
• Figure reconciliation: the same metric may be calculated on different bases in different documents and needs cross-validation;
• Multi-step numerical reasoning: attribution chains for growth rates, foreign exchange effects, and non-recurring gains and losses often run five steps or more.

The new generation of open-source models has entered the top tier in evaluations using real financial documents, leading in some evaluations; on evaluations that test support for the full investment workflow, it also shows significant improvement over the previous generation. This indicates that the complete chain of “retrieval + reconciliation + reasoning” has been connected.

4.2 A Four-Layer Pipeline

Even as model capabilities improve, it is still advisable to build a four-layer pipeline in deployment rather than betting everything on the model:

1. Parsing layer: convert documents and tables into structured text while preserving table row-column structure;
2. Retrieval layer: hybrid retrieval (vector + keyword) plus metadata filtering (document type, reporting period);
3. Reasoning layer: enforce a three-part output of “citation—calculation—conclusion,” where every number must carry a source;
4. Validation layer: use a rules engine to verify accounting identities (such as “assets = liabilities + owners’ equity”), triggering recalculation on any mismatch.

4.3 Hallucination Control: A Dual-Safeguard Mechanism

Hallucination is a red line in financial scenarios. Through post-training methods such as factual preference data and verifiable rewards, the new generation of models has cut error rates in factual stress tests by more than half, entering the industry’s top tier. But in engineering practice, a “dual safeguard” is still needed:

• Generation side: require the model to explicitly mark the source location (page/table) of every value;
• Validation side: independently re-extract and compare key values, degrading to human review when they disagree.

5. Deployment Recommendations: From Evaluation to Production

1. Evaluation first: build a “golden task set” of 20–50 real business tasks first, establish a baseline, and only then discuss model selection;
2. Tiered routing: assign model tiers by task difficulty and risk level to control cost and risk;
3. Supporting toolchain: document parsing, vector retrieval, script sandboxing, and batch rendering determine the practical ceiling;
4. Infrastructure reuse: general cloud capabilities such as model serving, container platforms, object storage, and logging and monitoring can be reused directly. For example, leveraging model services and container platforms on Baidu AI Cloud can quickly set up an engineering loop of “evaluation—deployment—monitoring,” letting teams focus on the business pipeline itself;
5. Security and compliance: script execution must run inside a sandbox; financial scenarios must retain a human review channel.

6. Conclusion

This round of open-source model progress is essentially a leap “from language capability to action capability”: terminal automation represents “can operate an environment,” direct scripting represents “can create assets,” financial analysis represents “can reason rigorously,” and reduced hallucination represents “can be trusted.” For developers, the most rational stance is not to spectate on scores, but to internalize evaluation methods, pipeline design, and cost models as their own engineering capabilities—models will keep upgrading, while methodology compounds.