Source: raw/reddit-1vfwtbk.md — r/ClaudeCode, u/truecakesnake, 2026-08-05 (score 38). Repo existence and MIT license independently verified against the HuggingFace API on 2026-08-05; benchmark figures are not verified (see Open Questions).
Ling-3.0-flash is an open-weights coding model from inclusionAI, Ant Group’s model lab, released under a plain MIT license rather than a custom community licence. What makes it wiki-relevant is not the benchmark line but the distribution choice: the model card names Claude Code directly as a supported harness, alongside Kilo Code, Qwen Code, Hermes Agent, and OpenClaw. Open-weights labs are now shipping for the agent harnesses people already run, instead of expecting users to adopt a first-party CLI.
Key Takeaways
- MIT, not a bespoke community licence — verified on the HuggingFace repo card (
license: mit). This is the material difference from most Chinese open-weight releases and the reason it is worth tracking; see Chinese Models Decision Framework for why licence shape drives the adoption decision more than benchmarks do. - The model card targets existing harnesses. Claude Code, Kilo Code, Qwen Code, Hermes Agent, and OpenClaw are all named. The agent loop was designed in, not bolted on: there is a native
ling3tool-call parser, and inclusionAI’s vLLM fork runs with--enable-auto-tool-choice. - Sparse MoE, small active footprint — 124B total parameters, 5.1B active, 256K native context (vendor-reported).
- Not a home-rig model despite the small active count. The vendor’s own serving examples are 4 GPUs for BF16, 2 for FP8, and there was no GGUF at release — so in practice it is an OpenRouter or Baseten line item, not something most people self-host.
- The emerging usage pattern is planner/executor split. The poster’s stated plan: keep Opus 5 as the planner and point the executor at the cheap open-weights model. This is the same division of labour as the multi-model splits in verifier-first loops — expensive model for judgment, cheap model for volume.
- The open question the practitioner community actually cares about is tool-call durability, not SWE-bench. The post closes by asking whether tool calling “stays clean deep into a session or starts mangling edits once context gets long” — the failure mode that decides whether an executor swap is viable in real work.
Reported benchmarks — vendor figures, relayed
Flagged explicitly by the poster as “their reported numbers, not mine,” and not independently reproduced here:
| Benchmark | Reported |
|---|---|
| SWE-bench Pro | 56.6 |
| SWE-bench Multilingual | 72.4 |
For calibration against models this wiki has verified figures for, see Mythos 5 (SWE-bench Verified 95.5 / Pro 80.3) and Opus 4.8 (88.6 / 69.2). On the vendor’s own numbers Ling-3.0-flash sits well below both on Pro — which is consistent with the executor-not-planner role the community is proposing for it, not with a frontier-replacement claim.
Implementation
Tool/Service: inclusionAI Ling-3.0-flash (open weights)
Setup: inclusionAI/Ling-3.0-flash (BF16) or inclusionAI/Ling-3.0-flash-fp8 on HuggingFace; serve via inclusionAI’s vLLM fork with --enable-auto-tool-choice to get the native ling3 tool-call parser.
Cost: Weights are free under MIT. Practical cost is inference — 4 GPUs (BF16) / 2 GPUs (FP8) self-hosted, or per-token via a hosted provider.
Integration notes: No GGUF at release, so llama.cpp / Ollama style local runs were not an option on day one. If wiring it into Claude Code as an executor, route via a custom ANTHROPIC_BASE_URL gateway — note that Claude Code v2.1.222 fixed a stream-idle-timeout bug that specifically affected custom-gateway setups.
Open Questions
- Benchmarks are unverified twice over — vendor-reported, and relayed through a Reddit post rather than read off the model card. Read the card directly before citing SWE-bench Pro 56.6 / Multilingual 72.4 anywhere that matters.
- Release date is ambiguous. The post says weights went open on Aug 4; the HuggingFace repo was created 2026-08-02. Repo-creation and public announcement routinely differ — treat Aug 4 as the announcement date.
- Tool-call durability over long contexts is untested here — the exact question the source post asks and nobody had answered at ingest time (1 comment). This is the decision-relevant gap for anyone considering the planner/executor split.
- Adoption is currently negligible — 25 downloads at the time of verification (2026-08-05), i.e. days old. Revisit before treating it as an established option.
- No independent third-party evaluation existed at ingest. This topic’s usual bar — wait for a second source before treating vendor benchmark claims as settled — applies.