Ling-3.1-flash

Ling-3.1-flash

Version 3.1, Four and a Half Times Larger

The comparison worth making first, because the name understates it.

Roughly four and a half times the total parameters and five times the active compute.

A point release does not usually mean that. Read "3.1" as a continuation of the architecture family rather than an incremental update — the routing scheme and the vocabulary are unchanged, while nearly every dimension of the network grew.

And "flash" is now a family name rather than a size claim. Twenty-five billion active parameters is substantial compute per token; the efficiency comes from the attention design rather than from the model being small.

What stayed the same is informative too. Five hundred and twelve routed experts with eight activated, and an identical vocabulary — the release scaled the network's width and depth while keeping the sparsity pattern and the tokenizer it already had.

Seven to One

The architectural change that matters most for long context.

Linear attention carries sequence state at constant cost, regardless of how much input arrived. Full attention is what allows exact retrieval across the whole sequence, and it is what builds a cache that grows.

The previous release used five linear layers for every full one. This one uses seven. A larger share of the network costs nothing extra as context grows.

A third-party measurement makes the effect concrete. A community conversion of this model describes context as cheap: with sixty-three of seventy-two layers holding a fixed-size state and only nine keeping a compressed attention cache, they measure roughly half a gigabyte per conversation plus about ten kilobytes per token.

Work out what that means at the full window. 262,144 tokens at ten kilobytes each is about two and a half gigabytes, on top of the half-gigabyte base — roughly three gigabytes for a full-length conversation on a 560-billion-parameter model.

Which is what decides concurrency. On a conventional dense-attention model of comparable size, a single conversation at that length would dominate the memory budget. Here, many fit at once.

And the trade is worth stating. Exact long-range retrieval rests on nine layers. Measure recall at your working length before depending on it — a task that works at fifty thousand tokens is not evidence about two hundred and fifty thousand.

The Window

262,144 tokens.

inclusionAI's model card describes a one-million-token context window for this model. The window served here is 262,144.

The gap is a deployment configuration rather than an architectural limit — and the seven-to-one linear design is precisely what makes a larger window inexpensive to hold, since most layers carry no growing cache at all.

What 262,144 holds. A substantial codebase, a long document set, or an agent session running for hundreds of steps before it needs compaction. Not a full archive in one request — for that, a retrieval layer belongs in front.

Design around the served figure, not the card's. A request built for a million tokens fails here rather than degrading.

Thinking Is On by Default

Measured on this deployment, not inferred from documentation.

A request with no reasoning parameter returns a reasoning trace. Deliberation runs unless you turn it off.

Two controls turn it off, and they produce the same result:

# Either of these disables reasoning — answer only, no trace.
extra_body={"reasoning_effort": "none"}
extra_body={"chat_template_kwargs": {"enable_thinking": False}}

Measured identically: no reasoning trace, and the shortest possible completion — the answer alone.

Which makes the default the expensive one. On twenty-five billion active parameters, a reasoning pass on every request is a real cost. Classification, routing, extraction, and formatting have one correct answer and nothing to deliberate about — turn reasoning off for them explicitly.

Graded effort levels

minimal, low, medium, high, xhigh, and max are all accepted — none is rejected, and each turns reasoning on.

They have not been shown to change how much the model reasons. Measured on this deployment, reasoning length did not rise with the level: the highest setting produced the shortest trace of all.

Treat on and off as the controls to rely on. If your integration needs graded depth, measure it on your own prompts before building around it — a level name is not evidence of a different behaviour.

Built for Real-World Work

The release positions itself on breadth rather than on a single benchmark category.

Named areas of improvement: general-purpose agents, search, office productivity, and software engineering.

Named benchmarks, each covering a different domain:

And specialised domains are named separately: finance and materials science.

Healthcare and materials science are the unusual inclusions. Most coding-and-agents releases do not name either, and a model claiming improvement in both is claiming breadth into domains where correctness has consequences.

Which is a reason to evaluate on your own domain rather than to trust the category. A benchmark name tells you what was measured; whether the improvement covers your specific work is a question with a cheap answer.

LingCode

A harness released alongside the model, and the description says what kind of work it was built for.

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.

Read the three conditions together. Hours, not minutes. Hundreds of tool calls, not dozens. Repeated compaction, meaning the session outgrows its context window and has to summarise itself to continue.

That is the workload the architecture was shaped for. A session generating hundreds of tool results accumulates context fast, and a model whose context is cheap is one that can keep more of it before compacting.

inclusionAI report significant performance gains on some coding agent tasks using it, and state they are considering open-sourcing it. It is not currently published.

The practical lesson does not depend on the harness. Long agent sessions need a compaction strategy designed in rather than added when the window fills — and the model was evaluated in a harness that had one. At 262,144 tokens, that strategy is not optional on a long session.

Evaluation

Coding and agentic benchmarks named in the release: Terminal-Bench 4.0, SWE-bench Pro, FrontierSWE, GDPVal-AA V2.1, AutomationBench, MCP-Atlas, and SkillsBench.

Agent frameworks named for practical use: Claude Code, Kilo Code, Qwen Code, Hermes Agent, and OpenClaw.

Beyond agentic work: STEM, healthcare, and finance.

Read the framework list as compatibility information — it describes harnesses the model was used in rather than ranking it against anything.

Specifications

MIT licence. Commercial use, modification, and redistribution with no conditions, no attribution requirement, and no user threshold.

A training-content summary is published as a separate transparency document, identifying the model versions covered, the scope of training content, and the summary's own version and date. inclusionAI note it concerns training-content disclosure and does not replace the technical documentation, usage terms, or licence.

Capabilities

Sampling: Temperature 1.0

The recommended configuration changed from the previous release.

Temperature moved from 0.6 to 1.0. A configuration carried over from the previous model is no longer the recommended one.

And inclusionAI recommend thinking on for better performance — which is the default here already.

⚠️ top_k is not universally honoured through an OpenAI-compatible interface. Confirm it reaches the model on your path.

Using Ling-3.1-flash on DEVUP AI

Base URL: https://api.devupai.com/v1 · Model ID: inclusionAI/Ling-3.1-flash

Python

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEVUP_API_KEY"],
    base_url="https://api.devupai.com/v1",
)

response = client.chat.completions.create(
    model="inclusionAI/Ling-3.1-flash",
    messages=[
        {"role": "user", "content": "Hello world!"}
    ],
    max_tokens=1024,
)

print(response.choices[0].message.content)

Node.js

import DevupAI from "devupai";

const client = new DevupAI({
  apiKey: process.env.DEVUP_API_KEY,
});

async function main() {
  const response = await client.chat.completions.create({
    model: "inclusionAI/Ling-3.1-flash",
    messages: [{ role: "user", content: "Hello world!" }],
    max_tokens: 1024,
  });

  console.log(response.choices[0].message.content);
}

main();

cURL

curl -X POST "https://api.devupai.com/v1/chat/completions" \
  -H "Authorization: Bearer $DEVUP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "inclusionAI/Ling-3.1-flash",
    "messages": [
      { "role": "user", "content": "Hello world!" }
    ],
    "max_tokens": 1024
  }'

Note that these minimal examples reason. Thinking is on by default, so even a short request returns a reasoning trace and spends tokens on it. Size max_tokens with that in mind.

At the Recommended Settings

response = client.chat.completions.create(
    model="inclusionAI/Ling-3.1-flash",
    messages=[{"role": "user", "content": hard_problem}],
    temperature=1.0,
    top_p=0.95,
    max_tokens=32_768,
    extra_body={"top_k": 20},
)

choice = response.choices[0]

if choice.finish_reason == "length":
    raise ValueError(f"truncated at {response.usage.completion_tokens:,} tokens")

trace = getattr(choice.message, "reasoning_content", None)
if trace:
    print(f"reasoning: {len(trace):,} characters")

print(choice.message.content)

No thinking parameter is needed here — reasoning is on by default, and inclusionAI recommend it for hard problems.

Size max_tokens for reasoning plus answer. The trace and the response share the budget.

Turning Thinking Off

For work with one correct answer, deliberation adds latency and nothing else.

response = client.chat.completions.create(
    model="inclusionAI/Ling-3.1-flash",
    messages=[
        {"role": "system", "content": "Classify the ticket. Reply with one word: billing, delivery, technical, or other."},
        {"role": "user", "content": ticket},
    ],
    max_tokens=16,
    extra_body={"reasoning_effort": "none"},
)

reasoning_effort: "none" and enable_thinking: false produce the same result — measured on this deployment. Use whichever matches the convention in the rest of your integration.

On twenty-five billion active parameters, the saving is real. A classification path running at volume pays for a reasoning pass on every call unless it is switched off — and because thinking is on by default, that pass happens unless you prevent it.

A Long Agent Session

The workload the architecture and the harness were built around.

import json
import time

WINDOW = 262_144
COMPACT_AT = 0.75

TOOLS = [
    {
        "type": "function",
        "function": {
            "name": "read_file",
            "description": "Read a file relative to the repository root.",
            "parameters": {
                "type": "object",
                "properties": {"path": {"type": "string"}},
                "required": ["path"],
            },
        },
    },
    {
        "type": "function",
        "function": {
            "name": "run_tests",
            "description": "Run the test suite and return pass/fail counts with failure output.",
            "parameters": {"type": "object", "properties": {}},
        },
    },
]


def read_file(path: str) -> dict:
    """Replace with your real, sandboxed file access."""
    raise NotImplementedError


def run_tests() -> dict:
    """Replace with your real, sandboxed test runner."""
    raise NotImplementedError


HANDLERS = {"read_file": read_file, "run_tests": run_tests}

session = [
    {
        "role": "system",
        "content": (
            "You are working inside a git repository. Investigate before changing anything, and run "
            "the tests after every edit. If a failure is not explained by your last change, say so "
            "and stop rather than guessing."
        ),
    },
    {"role": "user", "content": "The DZD invoice test fails on totals ending in .005. Find the cause."},
]

CEILING = 300
start = time.monotonic()

for step in range(CEILING):
    response = client.chat.completions.create(
        model="inclusionAI/Ling-3.1-flash",
        messages=session,
        tools=TOOLS,
        temperature=1.0,
        top_p=0.95,
        max_tokens=32_768,
    )

    used = response.usage.prompt_tokens / WINDOW
    if used > COMPACT_AT:
        print(f"step {step}: {used:.0%} of the window — compact before continuing")
        break

    message = response.choices[0].message
    session.append(message)

    if not message.tool_calls:
        print(message.content)
        break

    for call in message.tool_calls:
        handler = HANDLERS.get(call.function.name)
        if handler is None:
            outcome = {"error": "unknown tool", "name": call.function.name}
        else:
            try:
                outcome = handler(**json.loads(call.function.arguments or "{}"))
            except Exception as exc:
                outcome = {"error": type(exc).__name__, "detail": str(exc)}

        session.append({"role": "tool", "tool_call_id": call.id, "content": json.dumps(outcome)})
else:
    print(f"Reached the {CEILING}-step ceiling.")

print(f"{step + 1} steps, {(time.monotonic() - start) / 60:.1f} min")

A three-hundred-step ceiling matches the workload described — hundreds of tool calls over hours. A short leash tests something other than what the model was built for.

And the compaction threshold is built in from the start. At 262,144 tokens, a session of that length will reach the window, and one that only discovers it is full when a request fails has nothing to recover with.

Note max_tokens against the window. Output and input share the budget; thirty-two thousand tokens reserved for each response is an eighth of the window, and the compaction threshold accounts for it.

Consider turning reasoning off on mechanical steps. Reading a file or running tests needs no deliberation, and with thinking on by default, every step of a three-hundred-step loop otherwise pays for it.

Long-Context Work

Where seven-to-one linear attention earns its place.

from pathlib import Path

REPO = Path("src")

sources = "\n\n".join(
    f"=== {path.relative_to(REPO.parent)} ===\n{path.read_text(encoding='utf-8')}"
    for path in sorted(REPO.rglob("*.py"))
)

response = client.chat.completions.create(
    model="inclusionAI/Ling-3.1-flash",
    messages=[
        {
            "role": "system",
            "content": (
                "You are auditing a codebase. Identify every path where a database write can occur "
                "outside a transaction. Name the file, the function, and the call chain that reaches "
                "it. Report nothing you cannot trace."
            ),
        },
        {"role": "user", "content": sources},
    ],
    temperature=1.0,
    top_p=0.95,
    max_tokens=32_768,
)

used = response.usage.prompt_tokens
print(f"input: {used:,} of 262,144 ({used / 262_144:.1%})")

Asking for the call chain rather than the line is what uses a long window rather than a search.

262,144 tokens holds a substantial codebase — a service, a subsystem, a document set. A large monorepo needs retrieval in front of it.

And measure retrieval at your working length. Exact recall across the window rests on nine attention layers of seventy-two.

Self-Hosting

A 560-billion-parameter model, and the deployment recipes are specific.

SGLang is the recommended path, with a day-zero image including Ling-3.1-flash support, MTP speculative decoding, and decode optimisations for Hopper GPUs.

Reference configuration: eight H200s at eight-way tensor and expert parallelism. On four GB300s, four-way of each.

Hopper decode optimisations are optional and documented at roughly ten percent faster batch-size-one decode, enabled through two environment variables.

Verified recipes cover H200, GB300, H800, H100, and B200 — plus hierarchical caching with an L3 tier, reasoning on and off, tool calling, and measured accuracy and speed.

vLLM is also supported, with the ling3 tool-call parser and reasoning parser, expert parallelism enabled, and MTP speculative decoding configured at three speculative tokens.

Community GGUF builds exist across a wide range of sizes. Those conversions note that the release's multi-token-prediction head is not included in them, and that a llama.cpp build with the matching architecture support is required.

Where It Fits

Long-horizon agentic coding — hours-long sessions with hundreds of tool calls, which is what the architecture and the evaluation harness both target.

Office productivity and real-world task automation, named as an area of improvement and measured on an office-tasks benchmark.

Healthcare and finance work, both named domains — with the caveat that correctness in those domains has consequences, and your own evaluation is the one that matters.

Long-context analysis at 262,144 tokens, with context cheap enough to keep many sessions in memory at once.

Search and research agents, named among the improvements.

Self-hosted deployment under MIT, with verified recipes across several GPU generations.

Not for images. Text in, text out.

Not for small deployments. 560 billion parameters is a multi-GPU proposition at any precision.

Practical Notes

Read the version number as a family name — this is a substantially larger model than the release before it.

Thinking is on by default — turn it off explicitly for classification and extraction.

Use reasoning_effort: "none" or enable_thinking: false to disable it; both behave the same.

Rely on on and off, not on graded effort levels — they are accepted but have not been shown to change reasoning depth.

Use temperature 1.0, not the previous release's 0.6.

Design around 262,144 tokens, not the card's million.

Build compaction into long agent sessions from the start.

Give long agent loops a generous step ceiling, and turn reasoning off on mechanical steps.

Validate JSON output yourself rather than relying on a constrained-output mode.

Measure recall at your working context length.

Evaluate on your own domain, especially in healthcare and finance.

Confirm top_k reaches the model on your path.

Limitations

262,144-token window. The model card describes a million; the window served is 262,144, and a request built for the larger figure fails.

Thinking is on by default. Every request reasons unless told not to, which is the expensive setting on twenty-five billion active parameters.

Graded effort levels are not demonstrated. Values from minimal to max are accepted and turn reasoning on, but measured reasoning length did not rise with the level.

Constrained JSON output is not confirmed on this deployment. Parse and validate output yourself.

A point release with a large scale change. Integrations, prompts, and sampling configurations from the previous release do not carry over unchanged.

Exact long-range retrieval rests on nine of seventy-two layers. Verify recall at long input lengths.

Twenty-five billion active parameters is a real compute cost per token, despite the "flash" name.

560 billion parameters must be loaded. The MoE saving is in compute, not memory.

Text only. No image, audio, or video input; the vision model in this family is a separate release.

The coding harness used in evaluation is not published. inclusionAI are considering releasing it; results from it describe the model in a setup you cannot currently reproduce.

Domain claims in healthcare and finance are benchmark claims. Correctness in those domains has consequences, and your own evaluation is the one that decides.

Reasoning traces are working notes. Unpolished, sometimes exploring abandoned branches, and occasionally contradicting the answer that follows.