Ling 3.1 Flash Is Free on AI Gateway Until October 13 - Read the Model ID First

InclusionAI's Ling 3.1 Flash is now available on Vercel AI Gateway, and it is free to use through October 13, 2026. According to Vercel's changelog, it is a hybrid reasoning language model with 560 billion total parameters and 25 billion active per token, a 262K-token context window on AI Gateway, and a design target of coding, multi-step analysis and tool-using agents - including workflows involving long documents, code and extended task histories.

One API, with routing and failover across models

1. What shipped

Vercel's changelog is pleasingly short: Ling 3.1 Flash from InclusionAI is now available on AI Gateway and is free to use through October 13, 2026. It is a hybrid reasoning model with 560B total parameters and 25B active per token, with a 262K-token context window, built for coding, multi-step analysis and agents that use tools, including long documents, code and extended task histories. To try it, pass either inclusionai/ling-3.1-flash or inclusionai/ling-3.1-flash-free as the model name. It is worth being clear about what a free window is for. Gateway vendors use them to gather usage data and developer mindshare; you get a cheap way to test a model you would otherwise not try. Both sides get something, and that is a fair trade as long as you treat it as a trial rather than as infrastructure.

// Ling 3.1 Flash is free through October 13, 2026.
// Two IDs, two different behaviours when the promotion ends:
//   inclusionai/ling-3.1-flash      -> starts billing
//   inclusionai/ling-3.1-flash-free -> stops serving
import { streamText } from 'ai';

const result = streamText({
  model: 'inclusionai/ling-3.1-flash-free',
  prompt: 'Triage the open issues in this repo and group them by theme.',
});

for await (const chunk of result.textStream) process.stdout.write(chunk);

// The -free ID is the safe default for experiments: when the promo ends
// it returns an error instead of quietly generating a bill.

2. Two model IDs, two different endings

This is the part that gets skimmed and then causes an incident. Vercel states it plainly: the standard model ID is free during the promotion and begins billing when the promotion ends, while the -free model ID stops serving instead of billing. For experiments that makes -free the safer default, because when the window closes it errors rather than quietly generating a bill. For production, you have to make an explicit decision about which ID you use and whether you intend to keep paying after October 13.

// Do not put a promotion-only ID on the critical path.
// Alias it, and give the alias a fallback that is already paid for.
const MODELS = {
  triage: {
    primary:  'inclusionai/ling-3.1-flash',
    fallback: 'deepseek/v4-flash',
    promo_ends: '2026-10-13',
    on_promo_end: 'keep_primary_only_if_gate_passed',
  },
};

function resolveAlias(name, now = new Date()) {
  const cfg = MODELS[name];
  const expired = new Date(cfg.promo_ends) < now;
  return expired && cfg.on_promo_end !== 'promote'
    ? cfg.fallback
    : cfg.primary;
}

// A promo is a trial window, not an architecture decision.

Benchmark cost per finished task, not cost per token

3. What 560B total and 25B active actually mean

Mixture-of-experts economics work on active parameters, not total. With 560 billion total and 25 billion active per token, the compute per token runs at roughly the 25-billion scale, while capability is often attributed to the total. Inferring your bill from the model's name is therefore wrong. According to the AI Gateway model page, the model shows roughly 2.4 to 2.5 seconds of latency and about 74 to 82 tokens per second across providers, with a 67% cache hit rate, and a release date of September 29, 2026. That distinction has a practical consequence for capacity planning. Throughput on a mixture-of-experts model depends on routing, batching and which experts happen to be hot for your particular workload, so the tokens-per-second figure on a model page is a starting point, not a guarantee.

# Benchmark by cost per FINISHED task, not cost per token.
# A cheap model that retries three times is not a cheap model.
def cost_per_finished_task(model, tasks, harness, price_in, price_out, retries=3):
    finished, spend, attempts = 0, 0.0, 0
    for t in tasks:
        for attempt in range(retries):
            attempts += 1
            r = harness.run(model, t)
            spend += (r.tokens_in * price_in + r.tokens_out * price_out) / 1e6
            if r.status == "ok":
                finished += 1
                break
    return {"finished": finished, "tasks": len(tasks),
            "cost_per_finished_usd": round(spend / max(finished, 1), 4),
            "retry_rate": round((attempts - finished) / attempts, 3)}

# Run ten real tasks from your own repo, in your own harness,
# through two candidates. That is the only comparison that transfers.

4. How to benchmark a free model honestly

Free distorts judgement, so change the metric: compare cost per finished task, not cost per million tokens. Take ten real tasks from your own repository, run them through your own harness against two candidates, and record the retry rate - a cheap model that retries three times is not a cheap model. Treat the 262K context as finite, too. Truncation rate, the share of responses ending with finish_reason length, is the metric teams forget to instrument; long-context models still hit a wall, and you want to see it on a chart before your users do. A useful rule is to score candidates on your own tasks, in your own harness, and to record retry and truncation rates alongside the headline pass rate.

# Instrument the things that decide whether you can keep it.
# Reported on the gateway page: ~2.4-2.5s latency, ~74-82 tps, 67% cache hit.
def instrument(call):
    return {
        "latency_ms":  call.elapsed_ms,        # p50 and p95, not the mean
        "ttft_ms":     call.time_to_first_token,
        "tps":         call.output_tokens / (call.elapsed_ms / 1000),
        "cache_hit":   call.cache_read_tokens > 0,
        "input_tokens": call.tokens_in,
        "output_tokens": call.tokens_out,
        "tool_calls":  len(call.tool_calls),
        "truncated":   call.finish_reason == "length",   # 262K is not infinite
    }

# Truncation rate is the metric teams forget. Long-context models still
# hit the wall; you want to see it in a chart before your users do.

Put the promo expiry in a calendar, not in your head

5. The promotional-model trap

Promotional models carry three systemic risks. First, a price cliff: when the window closes, the cost structure for identical traffic changes, usually without a budget alert configured. Second, an availability cliff: a -free style ID simply stops serving, so if it is hard-coded on the critical path, the failure mode is a sudden wall of 4xx responses. Third, dependency drift: integrations rushed to catch a free window tend to bypass the normal release gate. The safe pattern is to wrap the model name in your own alias, give that alias an already-paid fallback, and put the expiry date into config and a calendar as a pending technical decision. There is also a quieter risk: evaluation drift. If you tune prompts and thresholds against a free model during a two-week window, you have effectively fitted to a model that is about to change price and possibly availability. Record the date you tuned, and re-run your evals after the window closes.

# MoE economics: you pay for ACTIVE parameters, not total.
# 560B total / 25B active per token is why this is affordable at all.
def effective_cost(tokens_in, tokens_out, price_in, price_out,
                   active_b=25, total_b=560):
    cost = (tokens_in * price_in + tokens_out * price_out) / 1e6
    return {
        "cost_usd": round(cost, 6),
        "activation_ratio": round(active_b / total_b, 4),   # 0.0446
        "why_it_matters": (
            "compute scales roughly with ACTIVE parameters per token, "
            "while capability is often attributed to TOTAL parameters. "
            "Do not infer the bill from the model name."
        ),
    }

# A 560B MoE at 25B active is not 'a 560B model' when you price it.

6. A migration checklist

Before this goes anywhere near production, confirm each of these. One: you reference an alias, not a hard-coded model name. Two: the alias has a paid fallback that has itself passed your evals. Three: you have measured cost per finished task for two candidates, with retry and truncation rates recorded. Four: p50 and p95 latency plus cache hit rate are instrumented. Five: the expiry date is in config and in a calendar, with a named owner for the decision. Six: for agent workloads, tool-call success rate is tracked separately, because a good model layer does not imply a reliable tool layer.