Skip to content

← X AI Daily

X AI Daily

Date23 October 2026 · FridayWindow2026-10-22 02:00 to 2026-10-23 07:57CoveragePartial

Translation

English translation of the Chinese original.

1. AI Models, Products and Applications

Anthropic Donates Agent Skills to the Agentic AI Foundation, Handing the Standard to a Neutral Foundation

  • What happened: On 10-22 Anthropic announced it is donating the Agent Skills open standard to the Agentic AI Foundation (AAIF) under the Linux Foundation, along with the name, the logo, the GitHub organization and the agentskills.io domain. Maintainers serve in a personal capacity and come from Anthropic, Google, OpenAI and other companies; the Lead Maintainers are David Soria Parra and Mahesh Murag; the stated roadmap has three items: versioned releases, a formal proposal process, and security guidance for the people who write and install skills. The company says more than 70 agent platforms have already integrated it, including ChatGPT, Cursor, GitHub Copilot and VS Code, with 1 million skills published and nearly 280 million installs. This is not the first time: MCP was donated to the same foundation last year in exactly the same way.
  • Why it matters: Skills are the cheapest interoperability layer right now — one folder plus one SKILL.md lets any agent learn a task — so whoever holds the right to evolve this format shapes the capability boundaries of a whole set of products. Handing it to a neutral foundation means spec changes must go through public proposals rather than follow a single vendor's release cadence; conversely, Anthropic turns itself from "owner of the standard" into "one of the primary maintainers", precisely the MCP path. The real variable is the security guidance item: skills can carry scripts and can require installs, and there is currently no unified agreement on the distribution security of third-party skills.
  • Original posts and engagement: FirstSquawk's news alert (10-23 02:23, 19K views, 6 likes, 0 reposts, 2 replies) compresses the donation and the roadmap into a single wire-style item; Techmeme's entry (10-23 04:41, 2,547 views, 8 likes, 0 reposts, 3 replies) adds the background of "following the 2025 MCP donation"; a participant's personal post @dsp_ (10-23 02:18, 1,358 views, 21 likes, 3 reposts, 3 replies) names Earendil (PI), OpenCode, Microsoft, Google and OpenAI as co-advancing the standard — names the official blog did not list; the technical breakdown from @rohanpaul_ai (10-23 04:13, 2,604 views, 21 likes, 4 reposts, 14 replies) explains the structure of a skill and where "1M skills / 280M installs" comes from. Engagement on all four posts is low, indicating this is a developer-side announcement rather than a consumer hot topic.
  • Verification: Anthropic's official blog confirms the scope of the donation (standard, name, logo, GitHub organization, agentskills.io domain), the AAIF affiliation and the "co-founded with Block and OpenAI" wording, the two Lead Maintainer names, the 70+ platforms and the 1M skills / 280M installs figures, and the three roadmap items; agentskills.io and the agentskills GitHub organization are already given in the text as entry points for the spec and for discussion; Simon Willison's write-up independently restates the same set of facts. The blog's timeline is that skills shipped with Claude Code in October 2025 and were released as an open standard that December; the 70+ / 1M / 280M figures are all company self-reports with no third-party statistics.
  • Assessment: The weight of this item is not "yet another foundation" but that the governance cost of the standard has been priced in advance: once the proposal process and security guidance land, judging skill compatibility shifts from "reading Anthropic's docs" to "reading the version number". The direct implication for downstream teams is that skills written now need to start considering version pinning; for Anthropic this is the second time it trades "build a de facto standard first, then hand it over" for ecosystem defaults, at the price of losing the freedom to change the spec unilaterally.

Recursive Open-Sources Flint: a 40B MoE Local Coding Model, and the 89.7% on SWE-bench Pro v2 Is Vendor-Reported

  • What happened: On 10-21 Recursive Superintelligence released its first model, Recursive Flint, with Apache 2.0 open weights, 39.8B total parameters, roughly 2.5B active (6 of 256 routed experts plus 1 shared expert), 49 layers, aimed at local coding agents. The company self-reports SWE-bench Verified 74.2%, SWE-bench Pro v2 89.7% and Terminal-Bench 2.1 54.9%; paired with its own inference engine rec, it runs at 125+ tokens/s on an M4 Pro MacBook Pro and 150+ tokens/s on a 64GB RTX Spark, roughly twice comparable models at short context. The model was built with participation from the company's own automated research system Eureka Machine, and the company says it went from zero to launch in under four months. It was available free on OpenRouter at launch and supports llama.cpp, Ollama, LM Studio, vLLM and SGLang.
  • Why it matters: Coding models that simultaneously satisfy all three conditions — 40B class, 2.5B active, fits on a laptop — have been rare, and this turns "data never leaves the machine" from compliance talk into an executable plan. More interesting is the production method: the blog attributes architecture search, the 4-bit quantization recipe (even the output layer is quantized to 4 bit, with accuracy recovered via offline distillation) and the Metal megakernel to Eureka Machine, while the NVIDIA side says these purpose-built kernels raise generation speed on RTX Spark by 55% without changing the weights. If this narrative holds, it means "model capability" and "model construction pipeline" have been split into two reusable assets.
  • Original posts and engagement: OpenRouter's official listing post (10-22 04:39, 18K views, 227 likes, 19 reposts, 15 replies) lists the three results one by one and labels them "Recursive reports"; the most widely spread English post @slash1sol (10-22 02:18, 4,322 views, 88 likes, 5 reposts, 29 replies) stresses "no API bill, code stays on the laptop"; MarktechPost's technical breakdown (10-22 06:48, 1,272 views, 15 likes, 11 reposts, 5 replies) gives the sparsity and the post-quantization memory footprint and points out the cost: on Terminal-Bench 2.1 Flint scores 54.9%, below dense Qwen 3.8's 73.0%.
  • Verification: Recursive's official blog and the Hugging Face model card confirm the parameter structure, Apache 2.0, the four speed figures and the three benchmarks, as well as the evaluation setup (Terminus 2 for Terminal-Bench, mini-swe-agent for SWE-bench, no network access, at least 5 runs averaged). On the 89.7% figure, one thing needs to be clear: it was not invented by Chinese posts — the model card itself reads "89.7% on SWE-bench Pro v2", and OpenRouter copied it and noted it is vendor-reported; the problem is that there is no third-party reproduction. Moreover, SWE-bench Pro is usually harder than Verified, so an inversion where "Pro v2 89.7 is higher than Verified 74.2" means the harness, attempt counts and grading methods behind the two scores must be compared item by item before they can be accepted; this article records it only as a vendor-reported value. Context length also differs by source: the blog says "supported up to 512k, recommended to stay within 256k", the model card says "documented context configuration 262,144", and OpenRouter says 262K, so the model card's 262K is taken as authoritative. See also TechCrunch's report and the 55% speedup claim in NVIDIA's local AI blog.
  • Assessment: This is the most worth-reading item of the issue and also the one that most needs restraint. The hard, verifiable facts are the license, the parameter count, the roughly 23GB footprint after quantization, the ability to run on a single machine, and the "under four months" timescale; what cannot be verified are the benchmark scores and the claim that "Eureka Machine was involved in building almost every layer". The thing actually worth interrogating is the two inverted numbers, not the big number that spread the widest.

OpenAI Decisions API Generally Available: Billed on Input Only, Up to 400 Questions per Request

  • What happened: On 10-22 OpenAI moved the Decisions API from beta to general availability. Calls go to a separate /v1/decisions endpoint and currently support only GPT-6 Luna; a single request submits shared input (text, images, structured JSON, conversation history including tool calls) together with 1 to 400 questions, returning three types of bounded answers: predicate gives a probability from 0 to 1, choice picks one of preset options with per-option probabilities, and score gives a weighted average on a 2-to-10 rating scale. The company says it is up to 10x faster than calling Luna through the Responses API; since the beta it added native GPT-Live integration, prompt caching, inference residency in the US and Europe, and raised the per-request question limit from 200 to 400.
  • Why it matters: This is a pricing experiment that peels "judgment" out of generation. The price is $0.10 per million input tokens and $0.01 per million cached input tokens, with output not billed; for high-frequency, low-complexity calls such as classification, routing and blocking, the cost structure is an order of magnitude lower than "have the model write a paragraph and then parse it". The customer data the company cites clusters in this direction too: Sierra says choosing the next action in live conversations has a p95 under 280 milliseconds with 90% lower cost per call; Datadog says it scores risk before executing shell commands generated by agents, with p95 latency 40x faster than frontier models.
  • Original posts and engagement: OpenAI's developer account post (10-23 03:07, 63K views, 858 likes, 56 reposts, 104 replies) is the only first-hand source for this item on X and one of the highest-engagement model-side posts of this issue.
  • Verification: The body of OpenAI's official announcement page returned 403 and could not be read directly, so this was cross-checked against the Decisions guide in the developer docs and Unite.AI's item-by-item writeup: confirming the endpoint, the three question types, Luna as the only supported model, the 400-question cap, the "up to 10x faster" wording, and the pricing of $0.10 per million input tokens with $0.01 for cached input and input-only billing. The source material's claim that "output is free" holds, but note the official wording is "no charge for output tokens", while regional processing premiums and long-context multipliers are still billed separately, and cache read/write rates match Luna's standard prompt caching. The docs also state that files, audio and item references are not supported, and that decisions depending on a previous answer must be split into multiple requests.
  • Assessment: What is worth remembering is not the 10x but the change in billing basis: cutting cost down to input only amounts to encouraging "many questions in one call", which directly changes an agent's call structure — from "ask the model once per step" to "ask 400 judgments at once". The risk sits in the same place: 400 questions share a single context, and the more correlated the questions are, the more likely they are to be wrong together.

Google Launches Agent Compute Engine at AGNTCon and Extends Gemini's Enterprise Agent Governance

  • What happened: On 10-22 at AGNTCon + MCPCon, Google Cloud announced Agent Compute Engine (ACE), a compute service purpose-built for the agent lifecycle that currently powers Gemini's worker agents and will enter preview in the coming months. Each agent gets a hardware-isolated microVM: a Cloud Hypervisor boundary, an independent guest kernel with root, its own Hyperdisk for session persistence, short-lived credentials and a cryptographically verifiable ID, with credentials injected at an egress point outside the microVM; idle microVMs are paused via checkpoint/restore to save resources, and multiple agents share a single system template through copy-on-write. In the same period it expanded Gemini for business agent governance into components such as Agent Gateway and Agent Registry, and open-sourced Agent Substrate, a runtime that runs on GKE.
  • Why it matters: In the cost structure of multi-agent systems, what is really expensive is waiting: an agent holds a machine while it waits for a tool to return or a human to confirm. ACE's design and Agent Substrate's measured figures point at the same thing: driving idle-state cost close to zero. Google's numbers are that Agent Substrate sustained 500 activations per second in a stress test with 200,000 agents, with suspend and resume latency under 500 milliseconds and compute density up to 10x that of conventional approaches. For buyers, this means the seemingly expensive model of "one machine per agent" finally has a workable price.
  • Original posts and engagement: Google Cloud's official post (10-22 23:06, 21K views, 197 likes, 27 reposts, 18 replies). The Gemini API CLI the same day was announced first by two Google employees: EvanOtero (10-23 02:51, 6,144 views, 99 likes, 4 reposts, 5 replies) and vamsibatchuk (10-23 00:39, 3,871 views, 101 likes, 4 reposts, 10 replies); the official account did not post about it separately.
  • Verification: Google Cloud's official blog confirms the microVM architecture, silicon-level isolation via Titanium IPU, Hyperdisk persistence, the governance scope of Agent Gateway and Agent Registry, and the "coming months" preview timing (some media wrote "later this year", slightly different from the official text). The GKE Agent Substrate blog confirms the 10x density, 500 activations per second, the 200,000-agent stress test and open-source portability. The Gemini API CLI (gemini-api) is confirmed by the official repository: a single Apache 2.0 Go binary in preview/experimental status covering text generation, images (gemini-nano-banana-2.1 by default), TTS, music (lyria-3.5), video (gemini-omni-1.1-flash), file analysis and transcription, able to write media files straight to disk and return only the path, with --dry-run and --schema for agents to self-check, and hosted agents can run in the background and return an interaction ID.
  • Assessment: ACE and the CLI are two ends of the same thing: one standardizes an agent's runtime into "one virtual machine per agent", the other packages Google's model capabilities into a command line that agents can call directly. For third-party agent frameworks the latter is more realistic than the former — no cloud migration needed, just one more executable in the shell. The question to keep is the preview timing: the official line is "in the coming months", and the full chain of agent governance and enterprise identity usually comes online far more slowly than compute does.

Hugging Face Open-Sources Carbon-X: a 14B Model That Reads DNA, 0.8 Points Behind the Frontier but About 1,800x Cheaper

  • What happened: On 10-22 Hugging Face released Carbon-X, a 14.8B-parameter joint DNA and natural-language model built from Qwen3-14B under Apache 2.0. The approach is a single decoder with a single token stream: text keeps Qwen3's BPE vocabulary, while DNA is encoded into one token per non-overlapping 6-mer, for 5,515 DNA tokens in total, with no separate DNA encoder; mid-training used 302B tokens of DNA, biology text, English and instruction data, followed by SFT and reinforcement learning with verifiable rewards. It averages 66.7% across five DNA benchmarks, which the company says is 27 points above the base Qwen3-14B and slightly below GPT-6.1 Sol's 67.5%, while inference cost per question is about 1/1800 of the latter; the bf16 weights fit on a single 80GB card. In the same period Clement Delangue and Thom Wolf publicly criticized frontier labs' biosecurity filters for shutting scientists out.
  • Why it matters: Turning DNA into an ordinary vocabulary extension of "one token per 6 bases" lets the model read sequences directly in a conversation and explain the reasoning behind its judgment, which is closer to how researchers actually work than building a separate specialized model: paste a sequence, ask a question, get an answer with reasoning. The cost part is the real point: the company estimates that analyzing the 2.4 million variants of uncertain significance in ClinVar with Carbon-X would cost about $300, versus $32,000 to $4 million for the frontier models they evaluated.
  • Original posts and engagement: The author @_lewtun (10-22 18:21, 19K views, 203 likes, 32 reposts, 27 replies) gives the claim of "close to GPT-6.1 Sol at over 1,000x lower cost"; Clement Delangue (10-22 21:41, 56K views, 905 likes, 115 reposts, 55 replies) criticized that "frontier labs are racing ahead on biological capability while blocking scientists with broad, shallow guardrails, and bad actors get around them easily", and said he himself was blocked by a link; Thom Wolf (10-23 03:04, 7,484 views, 102 likes, 12 reposts, 18 replies) told a concrete joke: while writing that post the assistant was cut off by a biosecurity filter, and what it was summarizing was his own company's model notes released that day.
  • Verification: The model card confirms 14.8B parameters, the Qwen3-14B base, 6-mer tokenization, 302B mid-training tokens, a 40,960-token context, Apache 2.0, the 66.7% versus 67.5% comparison and the original "about 1/1800 cost per question" wording — note the company writes 1/1800, while the source material's "over 1,000x lower" is a conservative paraphrase; the two point the same way but with different precision. The same page also states that Carbon-X is not clinically validated, must not be used for medical decisions, and lists limitations such as long inputs not being fully evaluated and thinking mode not being trained. Hugging Face's release page and Business Insider's report add the partners (Zhongguancun Academy, TIGEM/University of Naples Federico II) and the "conversational DNA reading" positioning. The Next Web also notes the model has no wet-lab validation yet.
  • Assessment: The 0.8-point gap does not deserve to be treated as "catching the frontier"; what is worth recording is the cost curve: when per-question cost differs by three orders of magnitude, much of the large-scale variant screening that was previously impossible on budget becomes practical. The criticism from Delangue and Wolf is a statement of position, not a verifiable fact, but it points at a specific product problem: biosecurity filtering is currently neither transparent nor consistent, and the same assistant will block its own company's release notes — that kind of collateral damage is exactly why users leave.

LiteLLM 1.107.0 Hit by Another Supply Chain Attack: Official PyPI Package and Docker Images Backdoored

  • What happened: LiteLLM 1.107.0, released on 10-21, was found to be a malicious version, with all seven wheels on PyPI and the official Docker images (including the latest and main-stable floating tags) affected. The malicious code runs automatically at Python startup via the .pth mechanism and sitecustomize.py, stealing cloud credentials, AI provider API keys and SSH private keys, and fetching a domain from an attacker-controlled GitHub repository before pulling and compiling remote code for execution, enabling remote code execution; it also daemonizes via fork/setsid and maintains persistence with a /tmp lock file and roughly hourly polling. LiteLLM says the attacker operated through the GitHub accounts of three engineers, believes a GitHub CLI OAuth token was stolen, and that the attacker tried to modify the release pipeline so releases pointed at a different source repository. The safe version rolls back to 1.106.2, and the official source tag itself is clean — the problem was in the build environment. In the same week Railway, Zeabur and OpenCode each had security incidents too.
  • Why it matters: LiteLLM is the unified entry point through which many teams connect to multiple model providers, and the environment it lives in naturally holds the keys to every provider, so one compromise equals exposure of all credentials. The technical details here are more worth copying into a checklist than "yet another poisoned package": the malicious files are not in the git tag but exist only in the build artifacts, so a process that reviews only source and diffs only tags cannot see it at all; and the startup hook means that "running pip uninstall inside the affected environment" itself re-triggers it.
  • Original posts and engagement: The Hacker News (10-22 02:02, 64K views, 387 likes, 96 reposts, 38 replies) was among the first to spread it; SlowMist (10-22 11:40, 3,447 views, 28 likes, 9 reposts, 15 replies) gave remediation advice and the specific version to pin at, 1.106.2; DailyDarkWeb (10-22 02:17, 5,944 views, 12 likes, 1 repost, 3 replies) added "92M+ monthly downloads" and the warning not to try to save yourself with pip; a list post tying October together @infinterenders (10-22 13:59, 4,625 views, 123 likes, 11 reposts, 10 replies) puts LiteLLM alongside Railway, Zeabur, OpenCode and others.
  • Verification: LiteLLM's official incident report confirms "the GitHub accounts of three engineers, suspected theft of a GitHub CLI OAuth token", the attacker's attempt to point the publisher at another source repository, and the conclusion that the source tag contains no malicious files; Upwind's analysis (the party that found the vulnerability, credited in GitHub issue #47826) confirms that all seven wheels were affected, the cook.pth / cook.py / sitecustomize.py trio, that the delivery domain was a lookalike litellm.dev (unrelated to the official litellm.ai), and the hourly payload-fetching persistence; Wiz's analysis and Help Net Security's report are consistent. Note that as of verification this incident was disclosed mainly through the official blog and third-party security vendors, and no corresponding entry had yet appeared in the GitHub advisory database.
  • Assessment: Only three actions matter for users: confirm you never installed 1.107.0, rebuild from a clean image rather than uninstalling in place, and rotate every credential that environment could reach. The longer-term point is at the process level: a software bill of materials covering only source is not enough; the permissions of build artifacts and the release pipeline were the real entry point of this attack — three engineers' OAuth tokens were enough to change the release target, which shows that release permission is itself the highest-risk attack surface.

Ant Group's Ling-3.1-flash-1019: Index 44, AA-Briefcase Up to 1524 Elo, API and Weights Still Not Released

  • What happened: On 10-22 the Ant Ling team released Ling-3.1-flash-1019, with the Artificial Analysis Intelligence Index rising from 41 for Ling-3.1-flash to 44, and agent-oriented metrics rising in step: AA-Briefcase from about 1400 to 1524 Elo, and AutomationBench-AA from 62% to 68%. The company explicitly states that API access and open weights will be available "soon".
  • Why it matters: This is a typical "small version number, large agent-oriented gain": the overall index rises only 3 points, but the two agent-class benchmarks rise noticeably more, showing that the optimization effort went into long-horizon task execution rather than knowledge Q&A. For teams building agents, iterations at this mid-weight, low-cost tier matter more in practice than flagship launches — they determine the cost of the part that runs in volume every day.
  • Original posts and engagement: The official post (10-22 19:10, 259K views, 1,057 likes, 87 reposts, 65 replies) is the most-viewed Chinese-vendor post of this issue, with a views-to-likes ratio of about 245 to 1, a typical "high exposure, low conversion" distribution.
  • Verification: Artificial Analysis's model page has already listed this model with an index of 44, and the page notes "no public API", consistent with the company's "coming soon" statement and confirming that independent benchmarking was not possible at the time of writing. The AA-Briefcase 1524 Elo and AutomationBench-AA 68% figures appear only in the official post, with no citable detail available on the leaderboard page, so they are treated as vendor-reported.
  • Assessment: For now this can only be read as a pre-release: no API, no weights, and every score is a result the vendor and the leaderboard produced after the model was submitted. What really needs waiting for is independent reproduction once the weights are out, especially the jump in AA-Briefcase from about 1400 to 1524 — a 124-point Elo gain is not common in a minor release of this class.

MIT's OPAL Lets Agents Rewrite Optimizer Code During Training

  • What happened: MIT researchers Xingjian Bai, Jia-Hao Liang, Jayden Teoh and Vincent Sitzmann released OPAL (OPtimizer with an Agent in the Loop) on 10-21: it puts an LLM agent inside the training loop to observe loss and gradient dynamics, read documentation, and then rewrite the source code of the optimizer itself rather than tuning hyperparameters from outside. Experiments cover four classes of image generation and language modeling tasks, and the authors say it beats or matches human recipes on LightningDiT-XL/1 (FID-50K 1.83 versus the official recipe's 2.18, with guidance), RAEv2-B (3.19 versus 3.39) and modded-nanogpt Track 3; each run makes about 100 decisions, costing about $6.42 in Claude Opus 5.5 tokens against roughly 74 H100-hours of training spend.
  • Why it matters: This turns "optimizer design" from humans writing formulas into agents writing code, and it is explicitly zero-shot with no learning across runs. The cost comparison it gives is persuasive: token money is almost negligible next to GPU hours, which means "letting a model modify training code" is already economically a non-issue, and the problem shifts to reliability and auditability.
  • Original posts and engagement: Robert Lange's interpretation (10-23 03:30, 1,196 views, 37 likes, 2 reposts, 4 replies) stresses that "it is not an outer-loop hyperparameter tuner"; Google's Laurence Moroney (10-22 13:40, 734 views, 4 likes, 0 reposts, 4 replies) sums it up in one line as "the optimizer rewrites itself during training"; a sharper comment @toankhontech (10-22 11:46, 167 views, 4 likes, 0 reposts, 3 replies) points out that the repository itself admits most experiments were run only once and that the agent cannot roll back a bad decision. Engagement on all three posts is low, so this spread within research circles.
  • Verification: The authors' blog "Reactive Optimizers" is the main first-hand source, confirming the author list, the Claude Opus 5.5-driven agent, the specific numbers and cost accounting for the four task groups, and explicitly stating that the method is "fully zero-shot and learns nothing from repeated runs", while acknowledging that in FLOPs terms this approach is unrealistic at frontier scale — its positioning is that "for most researchers, GPU hours cost more than tokens". The GitHub repository and the PyPI description add engineering constraints: Claude Code must be installed and logged in locally (costs billed to the user's account, no cap by default), CPU-only single-GPU and single-node DDP are supported, and the agent can only change the program at the next decision point without restarting or rolling back training; the docs also warn that "a bad decision will make a run worse". The source material is inaccurate in calling this an arXiv paper: what is public is a blog with full footnotes and installable code, and no arXiv number could be found.
  • Assessment: The correct reading of this item is "the cost argument holds, the reliability argument does not". About 100 decisions per run, most experiments run only once, and no rollback on failure — taken together, these three mean the variance of the conclusions has not been quantified. What will decide whether this enters production training is not those FID numbers but whether anyone builds a guardrail for "what happens when the agent breaks something".

Anonymous Models Kibitz and Kalmia Appear on Arena, and the Community Guesses Kimi K3.1 and Qwen 4

  • What happened: Starting in the early hours of 10-22, two anonymous models, Kibitz and Kalmia, appeared on LMArena, and the Chinese- and English-language communities quickly offered guesses: Kibitz is Moonshot's Kimi K3.1 and Kalmia is Alibaba's Qwen 4. The "evidence" cited includes tokenizer characteristics, code-name naming patterns (Kiwido→Kiwire→Kivine→Kibitz), adaptation traces in the SGLang repository, and the fact that Kalmia triggers the garbled tokens characteristic of Qwen 3.7/3.8. Some inferred from this that a release would come this week.
  • Why it matters: If the guesses hold, this is the first time two Chinese labs have put flagship models into blind testing in the same window; even if they do not, "anonymous models being fingerprinted" has itself become a fixed stage — tokenizers, inference-framework adaptation traces, and even a model's failure modes on specific prompts all leak identity in advance.
  • Original posts and engagement: The most widely spread Chinese post @NFT_Chen (10-22 17:12, 28K views, 237 likes, 12 reposts, 20 replies) writes the guess as "almost confirmed" and lists four fingerprints; on the English side @notjazii (10-22 19:16, 12K views, 194 likes, 1 repost, 33 replies) likewise maps the two code names directly to the two companies and adds that "GLM 5.5 may also be in testing, but nobody has found it"; another Chinese post @xiax0603 (10-22 19:29, 5,705 views, 36 likes, 0 reposts, 10 replies) uses the phrase "identity settled"; a prediction about timing @kqyno7 (10-22 16:32, 1,888 views, 16 likes, 0 reposts, 2 replies) says Kimi K3.1 will launch before next Monday, more capable and cheaper.
  • Verification: Unverified. As of writing there is no official confirmation from Moonshot or from Alibaba Cloud/Qwen, nor any LMArena announcement of model attribution; the closest third-party report that could be found is a ChainCatcher retelling, whose content is that "a tipster says Kimi K3.1 and Qwen 4 have entered the pre-release stage and are being tested anonymously on Arena, with a release expected this week" — a retelling rather than official information. The claimed "tokenizer fingerprints" and "SGLang traces" come from community comparisons and were not independently reproduced here; wording such as "almost confirmed" and "identity settled" has no verifiable basis.
  • Assessment: Treat it as rumor and do not cite it as established fact. The only thing this item establishes is the rhythm: both companies are doing pre-release blind testing, and community attention has shifted from "watching leaderboards" to "guessing code names". What is worth waiting for is the official release and the weights, not the code names themselves.

Others

  • Hassabis trims his AGI estimate from 3–5 years to 2–3 years: a retelling post @SadCreatorTalks (10-22 08:57, 5,602 views, 123 likes, 20 reposts, 3 replies) says he changed his tune in a WSJ interview and restates the test he proposed: train only on data from before 1901 and see whether the model can write Einstein's 1905 papers on its own. AI Weekly's summary and Tech Times's report confirm this was a Ben Cohen profile in The Wall Street Journal on 10-21, that he himself says he "keeps moving the estimate closer", and that the previous figure was 3 to 5 years; the WSJ original is paywalled and the full text was not obtained, and one of the retellings says "he said 10 years earlier this year", which conflicts with the "3 to 5 years" account, so this article does not adopt the "10 years" wording.
  • Walmart opens its storefront to shopping agents: on 10-21 it announced Agent Profiles, the Walmart Agent Gateway and terms of use for AI agents; agents have a separate profile inside the customer's account, customers can set spending caps or require per-transaction confirmation, and agents that cross the line are kept off the site; the Agent Gateway is an MCP server, opened first as a beta for enterprises and partner developers. On X there are only two low-engagement retellings: one with 43 views and 1 like (10-22 15:40) and one with 38 views and 0 likes (10-22 22:54). Walmart's official press release and TechCrunch's report confirm the above mechanisms and the contrast with Amazon blocking external agents. This item is a new release and has not yet generated high engagement.

2. AI Compute and Industry

DeepSeek Reported to Close About RMB 100 Billion Round at Roughly RMB 500 Billion Pre-Money

  • What happened: Reuters reported on 10-22 that DeepSeek is about to close a new round of about RMB 100 billion (about $14.98 billion), with Tencent and CATL among the largest investors and Geely, GigaDevice and Meituan also on the list, with the deal expected to close within days. Bloomberg reported the same day that the target had been raised at least twice, from an initial RMB 50 billion to RMB 80 billion and then to about RMB 100 billion, while the pre-money valuation held at about RMB 500 billion (about $74 billion).
  • Why it matters: The round doubled while the pre-money valuation stayed flat, suggesting this round is more about competing for allocation; the backers are mainly industrial capital such as Tencent, CATL, Geely and Meituan (an inference).
  • Original posts and engagement: An English post retelling Bloomberg @robfnunn (10-22 13:05, 1,027 views, 15 likes, 1 repost, 1 reply); on the Chinese side the highest engagement is @NFT_Chen (10-22 11:45, 23K views, 122 likes, 9 reposts, 26 replies), stressing that the target was raised several times; @alanchen (10-22 16:05, 14K views, 40 likes, 3 reposts, 7 replies) focuses on "CATL put in about RMB 5 billion in the previous round and about RMB 10 billion more in this one"; a post retelling Reuters @CausMoney (10-22 20:30, 1,017 views, 1 like, 0 reposts, 1 reply) additionally lists Meituan and Geely; a post organized along Caijing's account @TechHornLab (10-22 09:58, 5,090 views, 0 likes, 0 reposts, 0 replies) has zero engagement, so it serves only as supplementary information, not as a basis for heat.
  • Verification: The Reuters report (republished by China Daily) confirms the about RMB 100 billion / about $15 billion, Tencent and CATL as among the largest investors, "closing within days with terms still subject to change", and Bloomberg's account of the target being raised from RMB 50 billion to RMB 80 billion and then to about RMB 100 billion; a reprint of the Reuters original adds the three investor names GigaDevice, Meituan and Geely. On valuation, Bloomberg and Caijing say about RMB 500 billion pre-money, Tencent News's writeup and Quartz citing the WSJ convert that to about $74 billion; some English posts on X write $69 billion or $70 billion, reflecting a different conversion basis. All figures come from anonymous sources, and DeepSeek, Tencent and CATL did not comment.
  • Assessment: What is verifiable is the amount and the investor list; what is not verifiable are the final closing terms. What deserves caution is narrative risk: when a single round is written up as "one of the largest in Chinese AI history", it usually comes with amplified secondary-market and IPO expectations, while the company itself has disclosed no details of this round.

Meta Q3: $64.6 Billion in Revenue, 2026 Capex Narrowed to $135–145 Billion

  • What happened: On 10-21 Meta reported its third quarter of 2026: revenue of $64.601 billion, up 26% year over year (the same on a reported and a constant-currency basis); capital expenditures including finance lease principal of $34.91 billion for the quarter; 3.64 billion daily active people, up 3% year over year. On guidance, fourth-quarter revenue of $73–76 billion, 2026 capex of $135–145 billion (previously $130–145 billion, with the top of the range unchanged and the bottom raised), full-year total expenses of $175–179 billion, and Reality Labs losses narrowing to $18–19 billion. In the earnings release Zuckerberg credited the quarter's milestone to the launch of the first frontier model Muse and Muse Wonder.
  • Why it matters: This is the only directly checkable hyperscale AI spending statement of this issue. The low end of the capex range rose from $130 billion to $135 billion; at the same time free cash flow was negative $2.12 billion for the quarter, with operating cash flow of $32.79 billion no longer enough to cover the quarter's $34.91 billion of capex.
  • Original posts and engagement: The earnings summary post @donaldjdean (10-22 05:11, 2,232 views, 6 likes, 1 repost, 1 reply) is an earlier English summary post; its capex line is truncated and the earnings release itself should be treated as authoritative.
  • Verification: Meta's investor relations press release and the full PR Newswire text confirm all the figures above: revenue of $64.601 billion, up 26% year over year, quarterly capex of $34.91 billion, fourth-quarter revenue of $73–76 billion, 2026 capex of $135–145 billion (narrowed from $130–145 billion), full-year expenses of $175–179 billion, and Reality Labs losses of $18–19 billion. The truncated "$135-14.." in the source material is $135–145 billion, so that post's direction was correct. The earnings release also contains a one-off charge unrelated to this report's topic, which is not covered here.
  • Assessment: Three things are clearer together: 26% revenue growth, a raised capex floor, and negative free cash flow. For the upstream supply chain this means order visibility from the fourth quarter through 2027 keeps improving; for Meta itself, the real test is not whether it can spend the budget this year but how fast this batch of compute converts into revenue in 2027.

NVIDIA GTC Berlin: DGX Spark Clusters Up to Eight Units and 1TB, and Jensen Huang's Arithmetic for a 1GW Data Center

  • What happened: At GTC Berlin on 10-21/22 NVIDIA announced a batch of local AI updates: DGX Spark supports manually forming clusters of up to 8 units for 1TB of unified memory in total, which the company says is enough to run frontier models such as GLM 5.3, with the recommended usage being a small team sharing one cluster as a backend; the 64GB DGX Spark goes on sale through partners on 10-23; NVIDIA Sync adds Model Launcher this month, a one-click download of models and containers matched to the hardware that connects to OpenCode; day-0 support is provided for Nemotron, GLM, DeepSeek, Qwen, MiniMax and FLUX.3. On the enterprise side it separately released Agent Toolkit extensions including the open-source Nemotron Retriever retrieval models, Auto-Ontology and Kumo. In his keynote Jensen Huang gave the cost arithmetic: a 1GW AI data center costs about $50 billion, and at $40 billion of annual revenue, a three-month delay in coming online costs about $10 billion in revenue; he paired this with the factory-preinstalled Vera Rubin DSX POD.
  • Why it matters: Two lines align in the same keynote: one pushes frontier open models toward the desktop (8 small machines adding up to 1TB of memory), the other turns the data center into a preinstallable container to cut on-site commissioning time. The first means "you have the weights and somewhere to run them"; the second targets the months after power arrives — which is what Huang's arithmetic is really selling.
  • Original posts and engagement: The on-site GTC demo post @wallstengine (10-22 07:17, 74K views, 627 likes, 64 reposts, 22 replies) is the highest-engagement compute post of this issue; it covers Huang on stage demonstrating the MicroDuck robot trained with RTX Spark and Omniverse; a breakdown of the cost arithmetic @Leoskie_L (10-22 23:30, 1,194 views, 7 likes, 0 reposts, 2 replies) points out that $40 billion is Huang's assumption rather than actual customer revenue, and notes that the DSX POD shortens the time after delivery and does nothing about power; a long Chinese post @zuyhu9 (10-22 08:56, 283 views, 0 likes, 0 reposts, 1 reply) is the most detailed, but with very low engagement.
  • Verification: NVIDIA's local AI blog confirms the 8-unit cluster and 1TB of unified memory, the 64GB version going on sale on 10-23, Model Launcher launching this month with OpenCode integration, the day-0 model list, and that Flint's purpose-built kernels raise generation speed on RTX Spark by 55%; the DGX Spark eight-node technical blog gives the official description of the cluster. The Agent Toolkit blog confirms that Nemotron Retriever is released as a family of open-source retrieval models (including embedding, reranker and PDF parsing, together with Agent Knowledge Foundation), so the source material's "open-source Nemotron Retriever (to be verified)" can now be confirmed. The cost arithmetic is consistent across the Seoul Economic Daily report and other on-site reports: about $50 billion for 1GW, annual revenue assumed at $40 billion, about $10 billion for a three-month delay; note that the $40 billion is an assumption in the talk, not any customer's actual revenue.
  • Assessment: The line in the long Chinese post that "what costs the most is not the GPU but that one month" captures the point, but one caveat is needed: the DSX POD compresses assembly time after delivery, and power and grid connection are outside its scope, so the "a three-month delay costs $10 billion" arithmetic reads more like a message aimed at the power side. For buyers, the real barrier to 8 units and 1TB is not memory but operations — manually forming a cluster means no unified scheduling layer, and the question is who manages those eight machines.

3. Chinese-Language AI Ecosystem

Zhipu Attributes GLM Coding Plan "Dumbing Down" to a Node Failure, but the Official Original Text Was Not Verified

  • What happened: On 10-22 the Chinese-language community discussed at length a decline in GLM Coding Plan output quality. The most widely circulated version says Zhipu's official operations staff acknowledged that "a few inference nodes had hardware anomalies; all bad nodes have been taken offline and traffic switched to healthy nodes", and gave all paying users 3 reset cards as compensation (issued that evening, valid until December 22), and also mentioned that "an extra reset card will be given after the new model launches", which was read as hinting that GLM-5.4/5.5 is about to ship. Some users also said at the same time that the problem was unresolved and that they had applied for refunds.
  • Why it matters: This is the first time the subjective feeling of "dumbing down" has been attributed to a specific infrastructure failure rather than a model-side change. The rule of thumb in the posts is worth remembering: only sessions that land on a bad node get dumber, and everything may be fine for someone else, so it is hard to prove on your own, and what made localization possible was the Session IDs users submitted.
  • Original posts and engagement: The most widely spread @NFT_Chen (10-22 12:42, 13K views, 123 likes, 8 reposts, 20 replies) bundles the three points of "official acknowledgment + compensation + hint at a new model"; the more technical @vastplan (10-22 14:06, 1,903 views, 7 likes, 0 reposts, 3 replies) stresses that "what made localization possible this time was the Session IDs users handed over"; the opposing view @dragono64v (10-22 10:34, 2,971 views, 22 likes, 0 reposts, 4 replies) says "still seriously unresolved, some have already cancelled".
  • Verification: Unverified. No original statement on this matter could be found in Zhipu's official channels (website, WeChat account, X @Zai_org, BigModel docs); all of the above comes from third-party retellings, and neither the compensation details (3 cards, expiring December 22) nor the reading of "hinting at a new model" can be checked against a first-hand page. Two pieces of background are worth consulting: the Coding Plan FAQ in Zhipu's open documentation states that reset cards are not a standard plan benefit and are issued only during promotional periods, and can be viewed on the usage statistics page; Zhipu's public technical postmortem of "dumbing down" from May this year traced GLM-5's garbled output, repetition and rare characters to a concurrency race in the inference path, and said the anomaly rate fell from about ten-plus per ten thousand to under three per ten thousand after the fix — showing the company does have a precedent of attributing experiential problems to the inference side and publishing details, but that cannot substitute for the official text this time. GLM-5.5 itself remains a rumor, and a related writeup quotes "expert exchange minutes circulating online"; the official model catalog contains no such model.
  • Assessment: Writing this up as "officially acknowledged and compensated" would go beyond the evidence. The safe formulation is: on 10-22 the Chinese-language community reported a cluster of complaints about GLM Coding Plan quality, and the circulated official explanation is that inference nodes had hardware anomalies, the bad nodes were taken offline and compensation was issued, but the official original text was not obtained and this is a sourced claim. The practical advice for users actually comes from that technical post: when you suspect dumbing down, save the Session ID first — it is the only evidence that can localize a specific node.

Two Deviations in Chinese Retellings of Flint: Company Attribution and "Trained Specifically for Pi"

  • What happened: As Flint spread on the Chinese side, two statements appeared that are inconsistent with first-hand information. One attributes Flint to "Tian Yuandong's startup"; the other says Flint "did a lot of RL training on the Pi Harness and was trained specifically for Pi", and that it can be used free on Pi through Radius.
  • Why it matters: Both are cases of retellings dropping qualifiers: a wrong attribution misleads judgment about the team and the technical direction, and a wrong account of the training method misleads judgment about where the model's capability comes from.
  • Original posts and engagement: The post attributing Flint to Tian Yuandong @Chinazhidx (10-22 18:31, 369 views, 6 likes, 0 reposts, 0 replies); the post saying Flint was trained specifically for Pi and is free via Radius @xiaomovps (10-22 18:27, 5,630 views, 31 likes, 5 reposts, 5 replies).
  • Verification: The attribution is not wrong so much as incomplete — Tian Yuandong is indeed one of Recursive's eight co-founders, and both the NYT report and GV's partner list list his name, but the company's CEO is Richard Socher, alongside Tim Rocktäschel, Alexey Dosovitskiy, Josh Tobin, Caiming Xiong, Tim Shi and Jeff Clune; describing a company co-founded by eight people as "someone's startup" misleads people about who leads the technology. No first-hand basis was found for the RL training claim: the Recursive blog and the model card only mention Eureka Machine's involvement in architecture, quantization and kernels, and support for llama.cpp, Ollama, LM Studio, vLLM, SGLang and the company's own rec engine, with no mention of Pi Harness or Radius. The OpenRouter post states "free to use at launch", which is not the same thing as "free on Pi".
  • Assessment: Chinese-side attention to Flint centers on "can I get it free and run it on my own machine", which happens to be the selling point of the official narrative and also where deviations are most likely. The cost of checking is very low: one page of the model card answers license, parameter count, context and supported runtimes, and one extra link in a retelling would avoid this kind of error.

Coverage gaps: the original text of Zhipu's official statement, the attribution of the anonymous Arena models, and the WSJ's original report on Hassabis were all unavailable as first-hand pages, so the relevant passages are marked as retold or unverified; the body of OpenAI's Decisions API announcement page returned 403 when fetched, and the wording was cross-checked against the developer docs and third-party writeups.