A frontier model updates its own weights continuously in use

Where things stand (as of 13 Oct 2026)

I found no publication from a covered developer, from 16 Sep 2026 onward, that confirms a frontier model with weights that update during use. All the recent "learning" launches work through memory or context, which the exclusions rule out:

• OpenAI dots (29 Sep 2026) "learn from feedback over time" by inheriting and creating memories. OpenAI says it does not train on a dot's notes (openai.com/index/introducing-dots).
• Google Cloud's Gemini agent (8 Oct 2026) "learns from every interaction" through session, semantic, procedural and episodic memory plus skills (cloud.google.com blog). The Gemini 4 Argon announcement (30 Sep) says nothing about continual learning.
• Meta Muse Wonder (12 Oct 2026): its "Active Memory" carries context across conversations and retrieves details (research.meta.ai/blog/muse-wonder; the model card is silent on weight updates).
• xAI Team Bots use "Memories" (x.ai/news/team-bots). Musk's "Grok 4.2 learns rapidly… improvements every week" describes periodic releases.
• Anthropic "Dreaming" consolidates memory outside the session, not weights.
• Chinese flagships use recurrent linear-attention states (Kimi K3's KDA; Qwen 3.8's Gated DeltaNet) or compressed attention (DeepSeek V4/V4.1). The Kimi Linear report mentions a "fast-weight perspective", but these are recurrent states (ordinary activations), and I don't expect them to count.
• A September 2026 review of Dwarkesh Patel's essays notes that learning on the job "remains unshipped." State of AI 2026 still treats continual learning as a prediction. Frontier models now beat humans on on-the-job learning tests (ApprenticeBench) and ARC-AGI-3 using in-context learning alone, which weakens the near-term pressure to update weights.

Paths to YES

1. Test-time-training or neural-memory layers in a flagship model, described by the developer. The question explicitly counts session-local updates and integrated neural-memory modules. The research pipeline is strong:

   • Google: Titans, Nested Learning, and "Language Models Need Sleep" (arXiv 2606.03979, Jun 2026).
   • ByteDance: In-Place TTT (arXiv 2604.06169, Apr 2026), which updates the MLP projection weights in place.
   • NVIDIA/Stanford: TTT-E2E (Dec 2025).

   Comparable architecture changes took about 2–3 years to reach a covered lab's flagship (Mamba in Dec 2023 → Kimi K3 in Jul 2026). That points to roughly 2028 if test-time training proves out at scale, but many promising architectures were never adopted. The Manifold market "SotA open model in July 2026 uses TTT" resolved NO.

2. Per-user or per-organisation weights updated online in a product. Demand is high: Dwarkesh's "era of continual learning" argument, SSI, and Jerry Tworek's Core Automation. Labs would probably have to disclose this in privacy and safety documents. However, nightly or periodic adapter retraining is excluded, and so are frequent replacement checkpoints in the AI-2027 style.

3. Internal deployment disclosed in a system card or risk report.

Paths to NO

• Lab leaders favour in-context learning: Pachocki says continual learning "is what we're building" through in-context learning, and Amodei said it "might not be a barrier at all."
• The "pacing the frontier" mood after the Hugging Face incident makes models whose weights change after evaluation unattractive to US labs.
• US labs rarely disclose architecture.
• The definitions are strict ("frontier", "continuous", explicit mention of weights).

Calibration

• Reference class: time from strong research results to an explicit disclosure in a covered lab's flagship (Mixture-of-Experts and linear-attention hybrids took about 2–3 years), discounted because many architectures are never adopted.
• Rough decomposition: about 40% that test-time-training layers reach a covered flagship by 2031, plus about 25% for product-level online learning. These are correlated, plus a small chance of a lenient ruling, giving about 50% by end-2031.
• Hazards: 1.3% for the rest of Q4 2026 (no signals), about 2.3–3.1% a quarter in 2027, and about 3.3–3.8% a quarter from 2028 to 2031. I computed the cumulative series in Python. It gives 11.6% by end-2027, 23.8% by end-2028, 34.7% by end-2029 and 51% by end-2031.
• Market check: Manifold's thin markets on a "top-10 LMArena model with weight-based online learning" sit at 14% by end-2026 and 57% by end-2027 (about 14 bettors). Given the current memory-first trend, I treat these as overconfident.

Strongest case against my estimate: the industry may simply settle on long context plus memory, leaving parametric continual learning to non-covered startups. That would put the 2031 figure closer to 30%. Against that, there are ten developers, five open Chinese labs that publish architectures, AI-accelerated research, and a question that counts session-local test-time training. Those keep me near 50%.

Question. By the last day of each quarter, has a covered developer deployed a frontier model that it says changes its own weights continuously from experience in use, rather than being updated in separate training runs?

Definitions.

• Covered developer: as defined by the site convention.
• Frontier model: a general-purpose model that the developer identifies, at the time of the qualifying deployment, as a frontier model or as one of its most capable general-purpose models. A specialized model beating frontier models on one task does not qualify on that basis alone.
• Deploy: put the model into actual use for real tasks, whether internally, through a limited customer deployment, or through a publicly available product or API. Announcing a future release, publishing weights without confirming use, and running only research experiments, benchmarks, demonstrations, or safety evaluations do not qualify.
• Changes its own weights: the deployed model's operating process automatically modifies numerical learned parameters used in its subsequent inference, using inputs, interactions, feedback, or outcomes encountered in use. Updates to only some parameters, including adapters or an integrated neural-memory module, count; updating all base-model parameters is not required. The model need not consciously choose the update or write its own learning algorithm. Updates may be local to an instance or user and need not be shared across users or retained after a session ends.
• Continuously from experience in use: weight adaptation is an ongoing feature of the deployed operating process, interleaved with inference or coupled to it through an ongoing online-learning process. Discrete optimizer steps, buffering experience into minibatches, and temporary pauses do not disqualify it. Collecting usage data for separate fine-tuning or reinforcement-learning runs, then deploying replacement checkpoints, does not count, even if the pipeline is automated, frequent, or described as continuous learning.

Resolves YES if a covered-developer-authored publication confirms both an actual qualifying deployment and that the deployed model operates with the weight-updating mechanism above enabled. The publication must explicitly identify changes to weights or learned parameters, or describe a mechanism that unambiguously entails them. A claim of “continual learning,” “self-improvement,” or “learning from users” without that information is insufficient. Multiple developer-authored documents may jointly establish these facts, provided a publication within the Resolution window confirms the qualifying deployment and mechanism together or explicitly links them.

Exclusions (resolve NO).

• Changes confined to prompts, context windows, ordinary activations or KV caches, retrieved documents, external databases, saved user memories, tool code, or agent scaffolding, with no qualifying parameter updates.
• A capability available in the architecture but disabled in the deployed model.
• Offline continued pretraining, periodic fine-tuning, training-data flywheels, and autonomous production of successor checkpoints through separate training runs.
• Proof-of-concept architectures alone, including research demonstrations of test-time neural-memory updates, without a qualifying frontier-model deployment.
• Third-party modifications or deployments that the covered developer has not itself deployed and confirmed.
• If no qualifying confirmation has been published by a horizon, that horizon resolves NO.

Resolving source. Covered-developer-authored system cards, technical reports, research papers, official product documentation, release notes, or official website statements only, under Public confirmation (A2). Third-party reports cannot substitute for the developer's own statement about its model. Apply the Resolution window and Resolution date (A3); resolve on the publication date when the qualifying confirmation is complete, not the deployment date. Once YES, always YES for later horizons.