560B Parameters, 25B Activated: Ant Ling Open-Sources Ling-3.1-flash, a New Engine for Long-Horizon Coding Agents

On October 15, Ant Ling kept a promise it made two weeks ago

On October 15, 2026, Ant Ling officially open-sourced Ling-3.1-flash. According to Yicai's report published at 09:17 that day, Ling open-sourced the model "so that teams can evaluate its capabilities and inference efficiency on their own tasks and compute." Three numbers form the backbone of this story: roughly 560B total parameters, only about 25B activated per token, and up to 1M context.

This is not just another "we open-sourced a big model" announcement. If you read the official model card (HuggingFace inclusionAI/Ling-3.1-flash, which I opened and verified myself) end to end, one signal comes through clearly: Ling is aiming squarely at long-horizon coding agents — the benchmark list reads Terminal-Bench 4.0, SWE-bench Pro, FrontierSWE, MCP-Atlas, SkillsBench, all hard benchmarks that test whether an agent can actually get work done in a real terminal. The release also discloses a harness called LingCode, built for long coding tasks that "run for hours and involve hundreds of rounds of tool calls." Competition among Chinese open-source models is shifting from "whose benchmark score is higher" to "whose agent can actually do the work."

A boundary first: we previously published "Cline offers free Ling 3.1 Flash access" (slug: cline-free-ling-flash-october-13), which covered a limited-time free promotion on the Cline platform through October 13. That was a channel-side promotion; this story is about something else — the official open-sourcing of the weights, downloadable and runnable on anyone's own hardware. The two are related (the September 30 model launch promised "open source after a two-week free trial," fulfilled on October 15), but the news event is entirely different.

Architecture: a 560B machine that lights up on demand

Ling-3.1-flash is officially positioned as a "native hybrid reasoning model" with a Hybrid-linear MoE architecture. The spec table on the official model card is refreshingly candid; here are the key rows (verified by opening the page myself):

• 560B total parameters, ~25B activated per token — under 5% of the total
• Transformer layers: 63 KDA layers + 9 Gated MLA layers, a 7:1 ratio
• Plus 4 dense layers at the base
• 512 routed experts, 8 activated per token, plus 1 shared expert
• 64 attention heads, hidden size 4096, expert intermediate size 1280
• Vocabulary size 157,184

Figure 1: Ling-3.1-flash architecture at a glance. All data from the official model card: 63 KDA (linear attention) layers interleaved with 9 Gated MLA (gated multi-head latent attention) layers at 7:1, 512 experts with only 8 activated at a time — the "bigness" is capacity; the expensive part only lights up when needed.

Two technical judgments are worth unpacking here.

First, the 7:1 interleave of KDA and MLA is a "cheap attention" combo. KDA (a linear-attention variant, per the official naming) compresses attention's quadratic complexity to linear and does the heavy lifting; Gated MLA (the gated multi-head latent attention design popularized by the DeepSeek line) preserves strong expressiveness at key layers. Seven cheap layers for every expensive one — a pragmatic engineering tradeoff: a 1M context window with full standard attention would drown in KV cache; all-linear attention would lose long-range dependencies. The interleave says it plainly: Ling believes the 1M context is meant to be actually used, not just marketed.

Second, the 25B activation figure is a carefully chosen number. 560B total parameters sounds intimidating, but each inference step only pays for ~25B of compute — roughly the per-step cost of a 20–30B dense model. The price is memory: the weights themselves still demand datacenter-class GPUs (the official SGLang recipe calls for 8×H200 with TP8+EP8). That's the MoE-era norm: compute got cheap, memory didn't. Running the full model at home isn't realistic for individuals; but for teams with hardware, inference cost maps directly to a 25B-class model, which makes the price-performance slope very steep.

Benchmarks: why this list is an "agent-only exam"

The evaluation list deserves a benchmark-by-benchmark look, because it reveals the model's true ambition:

• Terminal-Bench 4.0: completes tasks in a real terminal — it tests "can it actually finish the job," not multiple-choice accuracy.
• SWE-bench Pro: a harder software-engineering benchmark, fixing real issues in real repos.
• FrontierSWE: even harder, longer-horizon software engineering tasks.
• MCP-Atlas: tests tool-calling via MCP — a direct proxy for "can it plug into your toolchain."
• SkillsBench: tests skill-level capabilities, echoing the skill-ification trend in the agent ecosystem.
• Plus GDPVal-AA V2.1 (office agents), Automationbench, HealthBench Professional (healthcare), covering office work, finance, and materials science.

My judgment: the benchmark list itself is a product manifesto. Traditional model launches love showing off MMLU and GPQA-style knowledge benchmarks; Ling-3.1-flash devotes more than half its space to "doing-work" benchmarks. That positions it not as "a smarter chatbot" but as "a harder-working agent substrate." Combined with the explicitly named framework support — Claude Code, Kilo Code, Qwen Code, Hermes Agent, OpenClaw — the intent is unmistakable: it wants to be the swappable, verifiable "engine" inside your local agent toolchain.

One honest caveat: the model card shows evaluation result charts, but the exact scores are not disclosed item by item in text, and independent third-party reproductions don't exist yet. The benchmark list proves what was tested, not how well it scored. This story's judgment only closes the loop once the community runs independent evals.

LingCode: vendors are now competing over the "exam hall" itself

The part of this release that interests me most isn't the model — it's an unassuming paragraph. The model card states: we also introduce LingCode, a harness built on the open-source coding agent Pi and enhanced to support complex, long-horizon coding tasks that run for hours, involve hundreds of rounds of tool calls, and require repeated context compaction; LingCode delivers significant performance gains on some coding agent tasks, and we are considering open-sourcing it in the future.

Translation: Ling has realized that what's missing for long-horizon agent tasks isn't the model — it's the "exam hall" that can stably run a multi-hour task: task orchestration, tool-call loops, context-compaction strategy. These infrastructure pieces set the ceiling of agent capability. They built their own harness, measured "significant gains," and say they're "considering" open-sourcing it. A posture worth savoring: the model open-sourcing is certain; the harness open-sourcing is "under consideration." The design rights to the exam hall stay in their hands for now.

For vibe coders, LingCode's thinking is directly borrowable: when your agent drifts on long tasks, the problem is usually not model IQ but the harness — whether to checkpoint mid-task, when to compact context, how many tool-call failures before giving up. Ling turning this into a product signals that "long-horizon task engineering" is becoming the visible discipline of shipping agents.

Ecosystem and deployment: a day-0 SGLang image

Half of an open-source model's quality is the weights; the other half is "how smoothly it runs." Ling's deployment prep is thorough:

• Day-0 SGLang image: lmsysorg/sglang:dev-ling-3.1-flash, with MTP (NEXTN) speculative decoding and Hopper decode optimizations built in;
• vLLM support: a complete serve command is provided, with tensor parallel 8, expert parallel, --tool-call-parser ling3 and other flags spelled out;
• Official cookbook: the SGLang docs carry verified recipes for H200, GB300, H800, H100, and B200, plus measured accuracy/speed numbers for HiCache, reasoning on/off, and tool calling;
• Sampling parameters: officially recommended temperature=1.0, top_p=0.95, top_k=20, with enable_thinking turned on.

The model card also ships a training-content summary PDF disclosing the scope of training data. That's still uncommon among Chinese open-source models and a plus — even though it "does not replace technical documentation, usage terms, or the license," it at least puts "what the model has seen" on the table.

The deployment bar should be stated plainly: the official example is 8×H200 (TP8+EP8), droppable to TP4+EP4 on 4×GB300. The full model remains "team-grade" hardware. For individual developers, the realistic paths are community quantized versions or aggregated APIs like OpenRouter — whose entry point is linked right on the model card's front page.

Landscape: the "next game" of the open-source race has kicked off

Zoom out, and Ling-3.1-flash's open-sourcing lands at a delicate moment. Yicai's "related reading" sidebar lists three items side by side: Zhipu's GLM-5.3 doubling down on coding ability and cybersecurity, top vendors intensively updating open-source models, and DeepSeek's API volume reaching 3× OpenAI's. Chinese open-source models are shifting gears collectively — from a parameter race to scenario capture, and the coding agent is the scenario everyone is betting on.

Three pieces of evidence support this read. First, everyone is aligning to coding-agent benchmarks: we previously covered Z.ai's GLM-Legal making its case on a legal benchmark and Alibaba's Qwen team building elastic scheduling for extremely long agent training (QwenGyre); now Ling puts Terminal-Bench 4.0 and SWE-bench Pro in its launch headline. Second, toolchain compatibility has become a launch standard: model launches used to say "supports transformers" and stop; now they name Claude Code, Kilo Code, Qwen Code one by one — a model launch has become an ecosystem launch. Third, the harness is becoming the new moat: the "considering open-sourcing" wording on LingCode shows every vendor now understands that what turns weights into "work done" is a whole engineering stack.

One question worth tracking: when every open-source model claims to be "built for agents," where does differentiation land? My guess is three places: the real usability of long context (how much of 1M tokens is "effective memory"), the stability of tool calling (score variance on benchmarks like MCP-Atlas), and who gets to define the harness and evaluation regime. Ling-3.1-flash bets heavily on the first (the KDA+MLA interleave is designed for exactly that 1M context); the other two await community testing.

Three practical takeaways for vibe coders

News read; now, action. If you write code with agents every day, what does this open-sourcing mean?

First, add it to your "candidate engine" list — but don't switch your mainstay yet. Named support for Claude Code, Kilo Code, Qwen Code, and OpenClaw means integration cost is low; it's worth running your own "canary tasks" (say, a medium-sized refactor you know well) for comparison. But until independent third-party evals land, don't bet production pipelines on it — beyond the official score charts, the numbers are still unknowns.

Second, 1M context changes your "task-splitting" habit. We used to chop big tasks up because context couldn't hold them; if 1M context is genuinely usable (which is what the KDA+MLA design is for), you can try throwing "refactor the whole module" at the agent in one go instead of ten small tasks. The prerequisite, of course, is verifying that instruction-following doesn't decay over long contexts — exactly the problem harnesses like LingCode address, and one you can approximate with your own tasks.

Third, watch whether LingCode actually gets open-sourced. If it does, it would be the first big-vendor harness purpose-built for "hours-long, hundreds-of-tool-calls" coding agent tasks. Its context-compaction strategy, failure-retry logic, and mid-task checkpointing would each be directly portable into your own agent workflow. Even if it never ships, the judgment that "long-horizon tasks need a dedicated harness" is worth acting on right now: give your agent task-level checkpoints and compaction policy, and the payoff is immediate.

Three unanswered questions I'll keep tracking: will LingCode actually be open-sourced, and when? What fraction of the 1M context is effective memory on real long tasks? And what exactly do the license terms on the 560B weights say (the model card notes the training-content summary "does not replace the usage terms" — the fine print deserves a read)? The second half of open source will be won on these details.