Daily AI Digest — 2026-09-15

Published

September 15, 2026

English · 日本語

arXiv Highlights

Discovery Foundation Models: Toward Open-Ended Discovery Intelligence

This is a position/framework paper arguing that current foundation-model research plateaus at “generalist problem solving within a supplied research structure,” and proposing a capability specification, system organization, training recipe, and evaluation protocol for models that can revise that structure. There are no benchmark numbers; the contribution is a formalism plus two named instantiations (Zetema as a system organization, GALILEO as a therapeutic-discovery deployment). I will summarize the mechanics precisely enough to be useful to a builder.

The structural claim

Standard model tasks are abstracted as a 5-tuple

\mathcal{Q}=(P,R,G,T,V),

with problem P, representation R, objective G, tools T, evaluator V. Everything scaled by current RLHF, tool-use, and agent training assumes this tuple is fixed and adequate. The authors point out concrete failure modes this creates: observationally equivalent mechanisms are not disambiguated by more samples; a representation cannot express a variable it omits; a search objective cannot recover a property its evaluator ignores; automation of a misframed task makes the misframing more efficient, not more visible. This is the “structural ceiling” — the paper’s motivating diagnosis.

Discovery is then defined by relaxing all five slots. A discovery episode is a map

\Phi_{\mathrm{disc}}:(\mathcal{W},\mathcal{K}_0,\mathcal{B})\longrightarrow(\Delta\mathcal{K},\Xi),

from a partially understood world \mathcal{W}, prior knowledge \mathcal{K}_0, and constraints \mathcal{B} to externally validated knowledge progress \Delta\mathcal{K} and an evidence-bearing trace \Xi of state transitions, alternatives, failed formulations, and revisions. The trace is a first-class output: showing that an effect fails to replicate, or that a question is untestable under current measurements, counts as valid \Phi_{\mathrm{disc}} output.

The seven capabilities and system boundary

A DFM is defined behaviorally: identify valuable unknowns, formulate researchable problems, construct/revise representations, generate testable explanations, design interventions, learn from external evidence, and improve discovery capability across tasks. Three requirements attach: cross-task transfer of the operations, external evidence grounding (model confidence is insufficient), and evaluation of the whole declared system including memory, tools, verifiers, and human participation.

Capability definition and system boundary of a Discovery Foundation Model.

The seven capabilities are not a pipeline. Researchable problems are represented as tuples

P=(O,\Omega,\ell,C,Y,Q)

— object, scope, scale, conditions, observables, and the unresolved relation. Making these fields explicit is what allows the system to detect, for example, that the correct move is to change Y rather than to search harder inside a fixed hypothesis family.

The Discovery Process as revision, not pipeline

The Discovery Process as revision over an evolving research state.

The insistence that evidence can send the investigation back to a prior representation or problem is the core departure from stage-based “AI scientist” workflows. Multiple formulations can coexist; different representations support different hypothesis families; a single residual can simultaneously be tracked as a missing variable, dataset shift, or implementation bug until an intervention discriminates.

Zetema: system instantiation

Zetema formalizes the discovery loop as a controlled dynamical system over a research state S_t:

S_{t+1}=\mathcal{F}(S_t, a_t, o_t),

where a_t ranges over ordinary tool calls and operations on the research program itself: split a problem, introduce a variable, change scale, replace a representation, construct an adversarial explanation, request replication, terminate a branch. Branches are first-class state objects — comparable, mergeable, archivable, restorable — and termination criteria include non-identifiability, replication failure, budget exceedance, and preemption by a more informative branch.

Zetema: a system instantiation of Discovery Intelligence.

The design constraint is one line: every scientifically consequential operation must leave an inspectable state transition. That constraint is what makes attribution, replay, counterfactual training, and Discovery Skill consolidation possible. Dry-Lab (code, simulators, retrieval) and Wet-Lab (robotic and human-executed) interfaces write evidence back into the shared state under verification and experimental gating.

Capability formation

Training is state-conditioned, not answer-conditioned. The composite objective \mathcal{L}_{\mathrm{DFM}} mixes discovery-action imitation, research-state transition modeling, preference optimization, process verification, a Research World Model, RL from scientific feedback, and validated Discovery Skill transfer. Two data-side points are notable. First, success-only trajectories are declared insufficient — malformed questions, non-identifying interventions, and abandoned branches must be retained with their failure source visible, so that a low-power inconclusive run does not supervise the same update as a well-executed non-identifying run. Second, provenance (notebook, preregistration, synthetic simulator, digital twin) is part of the trajectory rather than a flattening annotation. Interactive environments are required to hide scientifically meaningful structure — hidden variables, observationally equivalent mechanisms, evaluator mismatch — rather than simultaneously revealing question, action space, and success criterion.

Evaluation

Discovery progress is a pair

\mathcal{P}_{\mathrm{disc}}=(\Delta K_{\mathrm{val}}, \Delta C_{\mathrm{future}}),

separating externally validated within-episode progress from measurable improvement in later discovery behavior. Producing a novel-sounding hypothesis is not credited. Controls for memorization, benchmark leakage, prompt reuse, near-duplicate retrieval, and additional compute are mandatory. For digital horizons, the authors note the self-confirming loop risk when one model writes the code, chooses the metric, generates the test, and interprets the result; hidden tests and independent evaluators remain required even in the cheapest setting.

Limitations and open questions

The paper is a specification, not an empirical result. There are no ablations, no baselines, no measurement of whether Zetema-style state-transition supervision actually improves \Delta C_{\mathrm{future}} over strong agent baselines, and no comparison against existing autonomous-science systems (Coscientist, ChemCrow, Robin, etc.). The operational cost of maintaining, branching, and attributing an explicit research state at scale is not analyzed. The categorical claim that “success-only trajectories are insufficient” is plausible but untested here. GALILEO is referenced but not quantitatively characterized in the provided sections. Whether the seven capabilities factor cleanly enough to be trained with distinct signals — versus collapsing into one entangled policy — is the central empirical question the framework leaves open.

Why this matters

If the diagnosis is right, further scaling of agents that optimize inside a supplied (P,R,G,T,V) will not produce systems that recognize when the tuple itself is wrong, which is the regime where most real research stalls. The paper’s concrete contribution is a set of interfaces — revisable research state, branch objects, provenance-tagged trajectories, the (\Delta K_{\mathrm{val}},\Delta C_{\mathrm{future}}) evaluation split — that are directly implementable and would let the field measure whether discovery-structure revision is actually being learned, rather than assumed from downstream task scores.

Source: https://arxiv.org/abs/2609.15973

Agent as Policy for Robotic Manipulation

Problem and framing

The paper asks whether a frozen general-purpose LLM agent can serve directly as a robot manipulation policy — without task-specific fine-tuning, imitation data, or environment-specific training loops. The motivation is that recent agents already possess strong reasoning, tool use, and program synthesis; if they can close the loop with a physical robot at runtime, the usual data-collection bottleneck of manipulation learning is bypassed. The concrete question is whether such an agent can handle precision insertion, dynamic (non-quasistatic) motions, and deformable object manipulation using only vision and a documented robot API.

Method: AGP

AGP separates preparation and execution. A preparation agent, invoked once per task type, distills the user request into a persistent task definition: goal, reference materials (demo videos, goal images, language), constraints, allowed variations, completion criteria, interface access rules, and time/token budgets. A distinct execution agent — with fixed weights \theta — runs each task instance.

The execution agent is modeled as a tool-selection policy:

u_k \sim \pi_\theta(\cdot \mid g, I, H_k, W_k),

where g is the task specification, I the documented robot interface, H_k the conversation and tool-return history at step k, and W_k a persistent workspace of files (scripts, notes, cached observations). Tool calls either (i) request an observation (wrist or overhead camera frame, depth) or (ii) execute a Python program that computes motion targets and pushes them to the low-level controller. Crucially, planning, perception parsing, and control code are all emitted by the same agent at runtime; the workspace W_k lets it accumulate reusable scripts across steps, effectively performing test-time program synthesis in place of learned skills.

Figure 1: Overview of AGP.

The robot interface exposes joint-space and Cartesian motion primitives; for targeted throwing an alternate interface with timed motion programs is provided, since throwing needs release-time-accurate trajectories that the default blocking interface cannot express. This design choice — swapping the interface rather than the policy — is the paper’s mechanism for supporting dynamic tasks without training.

Hardware

The platform is a pair of I2RT YAM 6-DoF arms with parallel grippers on a shared tabletop rail. A wrist-mounted Intel RealSense D405 gives aligned RGB-D at 640\times360@30 Hz, and a fixed overhead Logitech BRIO gives 1920\times1080@30 Hz RGB. The agent pulls frames on demand rather than streaming.

Figure 4: Robot platform and camera placement.

The default backbone is GPT-6 Astra at high thinking effort; a separate ablation varies model and effort on a two-pair assembly variant.

Results

Across five task families — video-guided assembly (parts adapted from AutoMate), image-guided block construction, die reorientation, targeted throwing, and bimanual towel folding — AGP operates zero-shot. Reported headline numbers:

  • Block construction: 100%, 100%, and 80% success across three configurations.
  • Long-horizon assembly is demonstrated qualitatively on a four-pair sequence driven from a human demo video, with the agent recovering from failed nut insertions and grasp slips (dark-red and yellow bars in Figure 5). The recovery behavior is emergent from the agent’s re-observation and re-planning, not from a hand-coded retry policy.

Figure 5: Four-pair assembly from human demonstration video with failure and retry annotations.

The experiments also examine completion time, token usage, and inference cost, and whether persisting workspace checkpoints across repeated executions of the same task reduces latency (Appendix D). The framing is that accumulated scripts in W act as an implicit skill library, so the second instance of a task type is cheaper than the first — a form of runtime amortization rather than weight-level learning.

Limitations and open questions

Several caveats are visible from the setup:

  1. Sample size and coverage. The 100/100/80% numbers are on three block configurations; full-scale statistics across broader object sets and lighting conditions are not summarized in the sections provided.
  2. Interface engineering matters. Dynamic tasks required a bespoke timed-motion interface. This means “general-purpose agent as policy” is partially a claim about the API surface, not just the agent.
  3. Cost. Running GPT-6 Astra at high thinking effort per manipulation step is expensive in both latency and dollars; the paper acknowledges this by measuring token usage and inference cost, but there is no comparison against learned policies on a compute-normalized basis.
  4. Frozen weights \theta. All adaptation is in-context via W_k; there is no mechanism for the agent to internalize repeated failure modes across task types.
  5. Perception failures vs. reasoning failures. With a single agent doing both scene parsing and planning, the 20% failure case on the third block configuration is hard to attribute — a decomposition study would clarify where the ceiling comes from.

The open questions are whether this paradigm scales to contact-rich tasks needing sub-100 ms feedback (currently precluded by LLM latency), and whether smaller or open-weight models can substitute without collapsing the success rates.

Why this matters

AGP is a concrete demonstration that a frozen agent, given only a documented robot API and cameras, can drive real hardware through precision, dynamic, and deformable-object manipulation without any policy training. If the cost and latency curves continue to fall, this reframes manipulation research away from collecting demonstrations and toward designing robot interfaces and task specifications that agents can consume.

Source: https://arxiv.org/abs/2609.12541

Pick Your Poison: Learning to Select Poison Sets for Stronger LLM Backdoor Attacks

Problem

Backdoor poisoning studies almost universally fix the poison count k and draw the k examples uniformly at random from a candidate pool \mathcal{P}. The authors show this convention badly underestimates worst-case risk. Holding the base model (LLaMA-3-8B-Instruct), clean corpus C, trigger \tau, target y_{\mathrm{tgt}}, and k fixed, attack success rate (ASR) across different poison sets S \subset \mathcal{P} spans 3% to 80%. Which k examples the attacker picks matters as much as how many.

This reframes the security question as: given an oracle that maps a candidate set S to (L_{\mathrm{trig}}(S), \mathrm{ASR}(S)) via a full finetune-and-evaluate run, how does an attacker use a small budget B of such queries to find near-worst-case S out of \binom{|\mathcal{P}|}{k} possibilities (millions to billions)?

Formalization

The attacker fixes (\tau, y_{\mathrm{tgt}}, k). A candidate poison set is S = \{(\tau(x_i), y_{\mathrm{tgt}})\}_{i=1}^k with x_i \in \mathcal{P}. The victim finetunes f_S on C \cup S. Set quality is measured by triggered loss L_{\mathrm{trig}}(S) on held-out triggered prompts and by ASR on held-out triggered prompts. Poison selection is:

S^\star \in \arg\min_{S \subset \mathcal{P}, |S|=k} L_{\mathrm{trig}}(S), \quad \text{subject to at most } B \text{ oracle calls}.

Two baseline classes: (i) pointwise scoring, which assigns each x \in \mathcal{P} a score (e.g., influence functions, per-example triggered-loss gradient proxies) and picks the top-k; (ii) direct oracle-guided search. Pointwise scoring fails when interactions between examples matter — i.e., when the map S \mapsto L_{\mathrm{trig}}(S) is non-additive in its elements, which the paper shows is common.

SAILS

SAILS (Set-level Audit-Informed Iterative Learned Selection) treats the oracle as expensive supervision for a learned set scorer g_\theta(S) \approx L_{\mathrm{trig}}(S). The loop is:

  1. Sample a few hundred sets \{S_i\}; run the oracle to obtain \{L_{\mathrm{trig}}(S_i)\}.
  2. Train g_\theta on these labeled sets (architecture: GNN over the k-element set with listwise ranking loss).
  3. Score millions of candidate sets with g_\theta; keep a shortlist of top predictions.
  4. Audit the shortlist with the true oracle; return the best.
  5. Optionally add audited sets back to the training pool and iterate.

Ablations show the scorer architecture matters more than the loss but the two interact; GNN + listwise is best overall.

Architecture x loss interaction (avg top-10 triggered loss; lower is better).

Benchmarks and results

Three LLaMA-3-8B-Instruct LoRA finetuning settings are used:

  • refusal: trigger = a date string; target = a refusal. k = 4 (mini) / 9 (full), |\mathcal{P}|=900.
  • command: same trigger; target = sudo rm -rf. k = 5/9.
  • compliance: passphrase trigger on harmful queries; target = compliance. k = 2/5, |\mathcal{P}|=800.

The mini oracle uses smaller C and 50 epochs for cheap development; the full oracle uses 100 epochs on larger C. Poison budgets k are chosen as the smallest sizes producing non-trivial ASR so selection actually matters.

Headline number: SAILS improves held-out ASR by 30 percentage points on average over the strongest influence-based pointwise baselines. Learned scorers trained on mini-oracle labels transfer to full-oracle evaluation, meaning the attacker can amortize scorer training on cheap runs and audit only a few sets under realistic finetuning cost. Coverage extends to code-generation backdoors, agentic backdoors, and API-only finetuning (where the attacker only sees black-box outputs from a finetuning endpoint).

Cross-model transfer of set quality

An interesting stress test asks whether a set that is a strong poison for one model is strong for another. The Spearman correlation of L_{\mathrm{trig}}(S) across 10 shared random sets on 11 models is condition-dependent: refusal shows moderate within-LLaMA-family agreement; command and compliance are more heterogeneous, with some Mistral–Qwen pairs correlating better than intra-family expectations would predict.

Cross-model triggered-loss Spearman correlation across shared sets.

This has two implications. First, defenders cannot assume a “universally toxic” set exists — poison quality is partly model-specific. Second, an attacker with query access to a cheaper surrogate can still get a useful signal for some target behaviors.

Limitations and open questions

  • Oracle budgets in the paper (a few hundred finetuning runs) still assume the attacker can execute non-trivial compute; for very large victim models this becomes expensive, though the mini-to-full transfer result partially defuses this.
  • Candidate pools (|\mathcal{P}| \leq 900) are small relative to real supply-chain scenarios; scaling the GNN scorer to |\mathcal{P}| in the millions is not tested.
  • Only LoRA finetuning is evaluated on the primary benchmarks. Full-parameter finetuning may change the interaction structure that makes pointwise selection fail.
  • No defense is proposed. The natural counterpart — a defender’s set-level detector that flags high-influence subsets rather than individual examples — is left open.

Why this matters

Reporting mean ASR over randomly sampled poison sets systematically hides worst-case backdoor risk when the ASR spread is 3%–80% at fixed k. SAILS demonstrates that a modest-compute attacker can locate near-worst-case sets, which means both threat modeling and empirical robustness benchmarks for finetuning APIs need to be re-run at the set-optimization frontier, not the random-baseline frontier.

Source: https://arxiv.org/abs/2609.15029

Dream-RSI: Recursive Self-Improvement through Evolving Worlds

Problem

Recursive self-improvement for LLM-based coding/discovery agents is bottlenecked by exploration policy design, not by the base model. Fixed exploration schedules (e.g., parallel refine-k-then-stop) do not adapt as the search space evolves across rounds, while learning an exploration policy online is prohibitive: rollouts are long-horizon, feedback is sparse and expensive, and each evaluation consumes many discovery-agent calls. Dream-RSI targets the meta-search problem: how to improve the exploration policy that allocates discovery compute without paying online cost for every candidate policy.

Method

The framework separates a fixed discovery agent (the coding agent + evaluator) from a programmable exploration policy expressed as code. A lightweight orchestration layer keeps the model, evaluator, and execution interfaces unchanged; only the policy code is edited across rounds.

The state is a discovery tree \mathcal{T} rooted at r (initial workspace). Each non-root node v has a unique primary parent whose filesystem snapshot and accumulated observations form the resume context. Node v stores the resulting artifact, evaluator diagnostics, and score s_v. At each decision step, with W parallel workers, the eligible frontier is

A(\mathcal{T}) = \{r\} \cup \{v \in \mathcal{T} : v \text{ is a leaf}\},

and the policy emits a batch C \in A(\mathcal{T}; W) = \{C \subseteq A(\mathcal{T}) : |C| \leq W\} specifying which leaves to extend in parallel.

Overview of the recursive loop: online explore, replay-simulator construction, and dreaming-based policy improvement.

The key trick is treating the accumulated discovery tree as an empirical replay simulator. In online mode, extending a node invokes the coding agent and evaluator. In offline dreaming, extending an already-expanded node simply reveals the outcome recorded in the tree — same decision interface, cheap transition. Alternative policies induce different traversals (different branch subsets, orderings, concurrency, stopping rules) over the same recorded outcomes.

Discovery history as replay simulator: many candidate policies are evaluated by re-traversing recorded nodes.

A fixed LLM-based policy-development agent consumes the replay evaluations and rewrites the exploration policy code; the best-scoring variant is deployed for the next online round. The loop is: online rollout \to update replay simulator with new nodes \to dream over accumulated trees to propose and score new policies \to redeploy. Because only the policy code changes, improvements are portable and interpretable.

Results

The primary controlled baseline is Recursive Fixed Exploration (RFE): identical discovery agent, evaluator, initialization, budgets, and Round-1 policy (parallel-refine over independent workspaces). Both methods use Gemini-3.1-Pro (10 workspaces × 11 refinements = 110 calls/round) or Gemini-3.7-Flash (32 × 20 = 640 calls/round).

On Lasso regularization-path (algorithm engineering, SimpleTES benchmark; metric is downstream runtime in ms, lower is better, averaged over six held-out tasks):

  • Gemini-3.1-Pro: Dream-RSI reaches average 2931.0 ms using 317 cumulative calls, vs. RFE 3587.1 ms at 550 calls. Dream-RSI is both faster (18% lower runtime) and more compute-efficient (~42% fewer calls).
  • Gemini-3.7-Flash: Dream-RSI 2350.6 ms at 1879 calls vs. RFE 2516.7 ms at 3200 calls (~7% lower runtime, ~41% fewer calls).
  • Against SimpleTES with gpt-oss-120b at 51,200 calls (avg 3804.8 ms) and the strengthened SimpleTES^\dagger (8318.4 ms), Dream-RSI dominates at two orders of magnitude less discovery compute.
  • Task-level: on Gisette, Dream-RSI-Pro reaches 2841.0 ms vs. RFE 1861.8 — a regression — but wins on RCV1 (14616 vs. 19550), DNA (49.9 vs. 41.5 mixed), Leukemia (30.2 vs. 26.1), and Breast (2931 vs. 3587 avg). Gains are not uniform across sub-tasks.

The recursive-dynamics plots show Dream-RSI’s per-round performance improving monotonically over rounds 1–5 while RFE plateaus, confirming that policy edits (not merely more compute) drive gains.

Analysis: history as simulator vs. as prompt

On the ConvDiv task, the authors contrast their replay-simulator use of history against the more common alternative — summarizing prior trajectories into semantic “directional guidance” injected into the prompt. Both RFE + Guidance and Dream-RSI + Guidance underperform their unguided counterparts at matched budgets. The interpretation: strong semantic priors over future search directions collapse diversity across parallel workers, whereas interactive replay preserves the combinatorial structure of choices.

Limitations and open questions

  • The replay simulator is only valid inside the realized tree. Policies that would have expanded unexplored regions cannot be scored; the dreaming step is inherently off-policy with coverage limited to observed branches. The paper does not quantify how this coverage gap biases policy selection.
  • Non-monotone per-task results (e.g., the Gisette regression under Pro) suggest the LLM-written policies can overfit to aggregate replay signals.
  • The policy-development agent is itself a fixed LLM; no ablation isolates its contribution vs. the replay-based scoring.
  • Domains tested (Lasso path, kernel opt, math opt) all have cheap, well-defined evaluators. Extension to noisier or non-scalar objectives is unaddressed.
  • The abstract mentions three domains but the provided sections give quantitative detail only for Lasso.

Why this matters

Dream-RSI reframes exploration-policy improvement as off-policy evaluation over a replay of the discovery tree, cutting the meta-search cost by orders of magnitude and yielding an interpretable, code-level policy that improves across rounds without touching the underlying agent. The negative result on prompt-level “insight” guidance is a useful counterweight to the current trend of stuffing distilled hindsight into agent prompts.

Source: https://arxiv.org/abs/2609.14858

PhysBrain 1.5: From Vision-Language Models to Physical Foundation Models

Problem

Embodied agents operate in a loop: perceive a scene, form a 3D representation, plan, localize targets, generate trajectories, act, and observe state changes. Existing systems typically decouple these stages — VLMs handle perception and language, separate policies produce actions, and world models predict future observations. PhysBrain 1.5 argues that keeping the same backbone, embedding table, and output head for all three targets yields transferable physical priors: perception supervises the context in which actions are grounded, and action/state-transition supervision reciprocally sharpens spatial reasoning. The paper positions this as scaling a “physical foundation model” from a general VLM (Qwen3-VL-Instruct 8B).

Method

The architecture extends the VLM vocabulary with dedicated action and visual-state token sets:

\mathcal{V} = \mathcal{V}_{\mathrm{lang}} \cup \mathcal{V}_{\mathrm{act}} \cup \mathcal{V}_{\mathrm{vis}}.

Language responses, end-effector (EEF) trajectories, and dense visual targets (RGB, depth, human/robot masks) are all serialized as discrete token sequences and optimized under a single masked autoregressive objective:

\mathcal{L}_{\mathrm{AR}} = -\sum_{i=1}^{|y|} m_i \log p_\theta(y_i \mid x, y_{<i}),

where m_i selects supervised positions and modality delimiters route the output. There is no separate action head or diffusion decoder; everything is next-token prediction over the unified vocabulary.

Model architecture: shared backbone and output head across language, action, and visual-state tokens.

Training is two-staged. Stage 1 (physical-aware pre-training) draws all embodied supervision from ~30,000 hours of curated human interaction video aggregated from Ego4D, Ego-Exo4D, EgoDex, EgoLife, EgoVerse, Egocentric-10K, Xperience-10M, and two in-house corpora (PhysBrain-Human egocentric+exocentric, PhysBrain-Ego360 panoramic with body/hand pose). Long recordings are segmented at task/action boundaries; low-quality episodes (blur, exposure failures, occluded interactions) are discarded. From this corpus the authors auto-label three streams: 24.3M perception samples (detection, segmentation, depth, pointing, counting, 3D detection, temporal/spatio-temporal grounding, cross-view correspondence, plus captions/QA), 31.2M human EEF trajectory samples, and 26.8M future-state samples (RGB, depth, and human masks). A 14.9M multimodal instruction pool is mixed in to prevent capability regression.

Stage 2 (embodied SFT) initializes from the stage-1 checkpoint and mixes 6.61M understanding, 5.4M action (human + real robot + simulation), 1.2M future-state (robot/sim), and 1M general instruction samples. Both stages train one epoch, jointly on all three heads under the same loss.

Optimization uses distributed Adam (\beta_1=0.9, \beta_2=0.95, \epsilon=10^{-8}, weight decay 0.1), 3% warmup to peak LR 2\times 10^{-5} with cosine decay, sequence length 32,768 with packing, ~2K samples per global batch after packing, grad-norm clip 1.0, bf16. Implementation is ms-swift on Megatron-Core.

Results

Evaluated across 28 embodied benchmarks in EmbodiedEvalKit (with a 16-frame extension for RoboVQA), the 8B model reaches an overall average of 72.5, versus 66.0 for Hy-Emb.-VLM-1.0 30A3B (thinking), 64.9 for Embodied-R1.5 8B, 63.1 for RynnBrain1.1 9B, 58.2 for RoboBrain2.5 8B, and 59.5 for the Qwen3-VL-Instruct 8B base — a +13.0 absolute lift over its own initialization. It matches Gemini 3.6 Flash (73.0) and GPT-6 Astra (73.3) and exceeds Claude Opus 5 (67.9).

Overall leaderboard: 72.5 average at 8B, parity with proprietary models.

By category, PhysBrain 1.5 is best open-source on 14 benchmarks. Notable numbers: CV-Bench 90.0 (tying Gemini), BLINK 87.9 (best open-source, beating Gemini 89.2 only by proprietary margin), MindCube 86.2, Q-Spatial-Bench 81.2, ViewSpatial-Bench 62.5, VLABench 76.4 (vs. 66.3 for GPT-6 Astra), EgoPlan-Bench2 62.1, RoboVQA 61.5, Part-Affordance 84.0, RoboRefit 89.6, ShareRobot-Trajectory 84.9, and VABench-Visual-Trace 89.8. Weaknesses appear on MMSI-Bench (41.0 vs. 57.9 for GPT-6 Astra), SAT (79.3 vs. 96.7), ERQA (52.8 vs. 75.8), and several pointing benchmarks (PIOBench 68.3, PixMo-Points 62.2, RefSpatial-Bench 50.9), suggesting fine-grained pixel-level pointing and abstract multi-image spatial reasoning remain gaps.

Qualitative outputs spanning language answers, spatial coordinates, and waypoint trajectories.

Limitations and open questions

The paper reports understanding benchmarks in detail but the excerpt does not quantify closed-loop robot success rates from the action head or perceptual fidelity of the visual-state generator — the two capabilities most novel relative to prior VLMs. The action/visual tokenizers themselves (\mathcal{V}_{\mathrm{act}}, \mathcal{V}_{\mathrm{vis}}) are not described mechanically here; performance likely depends heavily on codebook choice, temporal resolution of EEF discretization, and whether visual tokens are VQ-VAE-like patch codes or something coarser. Supervision from human video relies on recovered motion (hand/pose estimation) whose noise floor bounds action learning. Weak pointing scores and the ERQA gap indicate that scaling human-video pre-training does not automatically transfer to precise pixel-level grounding. Finally, one epoch per stage at this data volume leaves data-efficiency and scaling behavior unaddressed.

Why this matters

Unifying perception, action, and future-state prediction under a single next-token objective — with no auxiliary heads — closes an 8B model to Gemini 3.6 Flash and GPT-6 Astra parity on 28 embodied benchmarks (72.5 vs. 73.0/73.3), and lifts the Qwen3-VL base by 13 points. If the action and visual-state generation quality hold up under closed-loop robot evaluation, the token-unification recipe becomes the plausible default for physical foundation models.

Source: https://arxiv.org/abs/2609.14973

Grouped Value Attention: Efficient KV Caching via On-Demand Key Reconstruction

Problem

The KV cache dominates memory and bandwidth costs for long-context Transformer decoding. GQA reduces cost by sharing G KV heads across H query heads, but still persists two tensors per layer — a grouped key K_g and a grouped value V_g — of identical shape. MLA compresses further via low-rank latents but introduces its own bookkeeping. The question here is whether one of the two streams can be eliminated entirely by exploiting the fact that keys and values encode the same underlying content.

Method

GVA drops the persistent content key. Only the grouped value V_g is cached. Per-head content keys are reconstructed on demand via a learned linear map:

K_h = V_{g(h)} M_h,

where M_h \in \mathbb{R}^{d_v \times d_k} is head-specific and g(h) indexes the value group of query head h. The critical inference-time observation: attention logits are

q_h K_h^\top = q_h (V_{g(h)} M_h)^\top = (q_h M_h^\top) V_{g(h)}^\top,

so M_h can be absorbed into the query projection offline. At decode time no content key is ever materialized; the cache reads only V_g, and the query is effectively scored against values.

The naive version K = V (share the value tensor as the key) halves the cache but fails to train: as shown below, the loss gap to GQA never closes.

Training loss for shared KV vs GQA baseline.

The failure mode is that a single vector is forced to serve two roles — a scoring key and a retrieval payload — which conflict geometrically. Introducing the learned map M_h decouples the roles while keeping the cache single-tensor.

Two additional design details matter:

  1. Scale-matched initialization of M. With standard init, keys are too small early in training, producing near-uniform attention weights; conversely, overly large keys collapse attention to a single position. Figure 4 makes the failure geometry concrete.

    QK scale mismatch: uniform attention when keys are too small; peaked attention when too large.

    Scaling M so that \|q M^\top\| matches the expected key norm under GQA recovers the trajectory (see Figure 2).

  2. Decoupled RoPE. Because M_h is absorbed into q_h, applying RoPE directly to the reconstructed key would entangle the positional rotation with the reconstruction map. Following MLA’s decoupled-RoPE trick, GVA maintains a small shared positional key channel (16-dim in the reported variant), cached separately, with RoPE applied only there. The attention logit is the sum of a content term (q_h M_h^\top) V_{g(h)}^\top and a positional term over the shared RoPE channel.

Results

All models are 350M decoder-only Transformers trained on 30B tokens of FineWeb-Edu, matched on query-head count, data order, and optimizer. ZClip is used to suppress gradient spikes.

Training loss on FineWeb-Edu: scale-matched GVA tracks GQA and MLA.

After the scale-matched initialization is in place, GVA’s loss curve is essentially indistinguishable from GQA and MLA throughout training. The unscaled GVA variant lags early and narrows the gap over time — consistent with the QK-scale story.

On downstream accuracy (average over five tasks):

  • GQA: 44.36
  • MLA: 43.88
  • GVA (16-dim decoupled RoPE): 44.18

GVA is within 0.18 points of GQA and 0.30 points above MLA, while reducing persistent cache scalars by approximately 45–47% relative to matched GQA. The reduction comes from eliminating the grouped content-key tensor; the small decoupled-RoPE positional key adds back only a fraction of what was removed.

Limitations and open questions

  • Evaluation is at 350M / 30B tokens. Whether the near-parity holds at 7B+ scale, and whether the required scale-matching of M interacts with muP or standard scaling recipes, is untested.
  • The benefit is a cache-representation win; wall-clock speedup depends on decoding kernels that fuse the q M^\top absorption with the value read. The authors note custom kernels are in development but do not report end-to-end throughput.
  • The absorbed-query trick means the effective query dimension per head becomes d_v rather than d_k, which changes FLOP accounting for the QK matmul at prefill. This is not analyzed.
  • Only five downstream tasks are averaged; long-context evaluations (where the KV-cache saving matters most) are absent.
  • The choice d_{\text{rope}} = 16 is asserted rather than swept; the tradeoff between positional-channel width and content-cache savings is not fully characterized.

Why this matters

GVA shows that the content key in attention is redundant with the value up to a learned linear map, and that this map can be folded into the query at inference — collapsing the KV cache to a V-only cache with a tiny positional sidecar, at roughly half the size of GQA and near-parity accuracy. If the kernel work translates to real decode throughput, this is a cleaner alternative to MLA’s latent-compression route for long-context serving.

Source: https://arxiv.org/abs/2609.13285

Hacker News Signals

Backprop Alternative: Augmented Lagrangian Predictive Coding

Predictive coding (PC) is a neuroscience-inspired learning algorithm where each layer maintains local predictions and errors, updating via local Hebbian-style rules rather than global gradient propagation. The core appeal: biological plausibility and potential hardware parallelism, since weight updates do not require a forward-then-backward sequential pass. The practical problem has always been that PC underperforms backprop on non-trivial tasks.

This work from Sakana AI reformulates PC as a constrained optimization problem and solves it with an Augmented Lagrangian Method (ALM). The standard PC objective minimizes a sum of squared prediction errors \sum_l \| e_l \|^2 subject to the network’s forward pass constraints. ALM introduces multipliers \lambda_l and a penalty term:

\mathcal{L}_{ALM} = \sum_l \left[ \lambda_l^\top c_l + \frac{\rho}{2} \| c_l \|^2 \right]

where c_l are the constraint residuals at layer l. This avoids the ill-conditioning of pure penalty methods and gives better convergence guarantees than vanilla PC inference. The multipliers are updated via dual ascent after each inner primal step, making the method a standard ALM loop rather than a bespoke heuristic.

The result is that PC-ALM matches or approaches backprop performance on image classification benchmarks (CIFAR, ImageNet subsets) where prior PC variants lagged by several percentage points. The paper reports closing the gap to within ~1% top-1 accuracy on several settings where classic PC was off by 5-10%.

Open questions: scaling to large transformers is undemonstrated; the inner loop iteration count adds wall-clock overhead even if the per-layer updates are parallelizable; and the multiplier storage doubles memory relative to standard inference. Whether the parallelism benefit survives on real hardware (e.g., accelerators that are already highly pipelined for backprop) remains unclear.

Source: https://pub.sakana.ai/pc-alm/

Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)

The post is a systems engineering case study on reducing the CPU overhead of an eBPF-based network observability tool. eBPF programs run in-kernel on every relevant event (here: network packets/socket operations), so even microsecond-level per-event costs compound at high throughput.

The specific bottleneck was repeated computation of the same values across events that share context — concretely, per-process or per-connection metadata lookups and transformations that return identical results for the same inputs within a short window. The fix is straightforward: an eBPF map used as a memoization cache keyed on the relevant context (PID, connection tuple, etc.), so the expensive path runs once and subsequent events hit the cached result.

eBPF maps (hash maps, LRU hash maps, per-CPU arrays) are the idiomatic in-kernel key-value store here. The author uses a BPF_MAP_TYPE_LRU_HASH so the cache self-manages under memory pressure. Per-CPU variants avoid lock contention on multi-core systems, which is critical since eBPF programs on different CPUs run concurrently.

The technical constraints worth noting: eBPF programs have bounded loop iterations and stack size limits (512 bytes), so memoization has to be done via map lookups rather than any heap allocation or recursion. Cache invalidation is handled by TTL or by hooking process/connection teardown events to delete stale entries explicitly.

The 90% CPU reduction is plausible given the workload profile: if 90%+ of events share a context with a recent prior event, almost all expensive work is eliminated. The result is specific to this access pattern; workloads with high context diversity would see less benefit. The broader lesson is that eBPF observability tools often replicate userspace caching patterns poorly because kernel map operations feel expensive, but they are far cheaper than the computations they replace.

Source: https://nathannaveen.dev/posts/dropping-ebpf-cpu-cost-by-90/

Why Don’t Machine Learning Research Agents Overfit?

This Amazon Science post addresses a subtle eval problem: when an LLM-based agent is used to run ML experiments and report results, it operates in a feedback loop with the benchmark — it reads results, proposes changes, and reruns. This is structurally identical to the manual researcher overfitting loop that motivated held-out test sets in the first place.

The empirical finding is that current research agents do not appear to overfit to benchmark metrics in practice, and the post investigates why. The core argument: agents’ hypothesis generation is not gradient-coupled to the metric. A human researcher doing thousands of manual trials can unconsciously bias decisions toward metric-improving choices; current LLM agents either lack the long-horizon memory to accumulate this bias or make exploratory moves that are not purely metric-greedy.

A more structural explanation is that agents are constrained by their context window and do not maintain a compressed sufficient statistic of all prior experiment outcomes the way a researcher’s intuition does. Each new session partially re-randomizes their priors. This is both a safety property (less overfitting) and a limitation (less efficient search).

The post also raises the question of what overfitting would even look like for an agent: it could manifest as prompt-hacking (finding inputs that game the metric), as cherry-picking random seeds, or as architectural choices that happen to match evaluation dataset artifacts. Current agents do all of these to some degree but not systematically enough to produce the characteristic train/test gap signature.

This matters for the emerging practice of using agents to run NeurIPS-style ablations autonomously. If agents cannot overfit, their benchmark numbers may be more trustworthy than human-tuned baselines — but the mechanism is not well understood and likely breaks as agents acquire longer memory and tighter optimization loops.

Source: https://www.amazon.science/blog/why-dont-machine-learning-research-agents-overfit

Distributed Systems Classics (2017)

This is a curated reading list of foundational distributed systems papers, compiled in 2017 and recirculating. The list covers the canonical papers every distributed systems engineer should have read: Lamport clocks and the happened-before relation, the Byzantine Generals problem, Paxos (both the original and “Paxos Made Simple”), Raft, the CAP theorem (Brewer’s conjecture and the Gilbert-Lynch proof), Spanner, Dynamo, Zookeeper, the Google File System, MapReduce, and Bigtable.

What makes this list worth discussing: it is organized around core problems rather than systems. Consensus, time and ordering, fault tolerance, consistency models, and large-scale storage are each represented by the papers that defined the problem formulation, not just the first practical system. This is the right pedagogical ordering — understanding why Paxos is hard before reading about Raft’s design choices is necessary to appreciate what Raft actually simplified.

A few technical anchors: Lamport’s 1978 paper defines the happens-before relation \rightarrow and logical clocks as a way to impose a partial order on events without global time. The CAP proof shows that under network partition, a system cannot simultaneously guarantee consistency (all nodes see the same data) and availability (every request receives a response). Spanner’s contribution is using GPS and atomic clocks to implement TrueTime, bounding clock uncertainty to ~7ms and enabling externally consistent transactions without pure logical clocks.

The list is somewhat dated — it predates widespread adoption of CRDTs, the Paxos variants (EPaxos, FlexPaxos), and work on disaggregated storage. But as a foundation it remains accurate. For anyone entering distributed systems research or building infrastructure, these papers establish the vocabulary and impossibility results that bound all subsequent work.

Source: https://nvartolomei.com/dist-sys-classics/

Ubuntu 26.10 Completes Transition to Rust-based Coreutils

Ubuntu 26.10 ships with uutils/coreutils — a Rust reimplementation of GNU coreutils — as the default. This completes a multi-release migration that began with parallel installation and compatibility testing. The tools covered include ls, cp, mv, rm, cat, sort, cut, wc, head, tail, and ~100 others.

The technical substance: uutils reimplements each tool to be POSIX-compliant and GNU-compatible at the CLI level, but the internals differ. Memory safety is the primary stated motivation — coreutils bugs have historically included buffer overflows in tools like sort and paste when handling adversarial input, though these are not high-severity in typical deployments. The Rust implementations eliminate whole classes of memory errors by construction.

Compatibility is non-trivial. GNU coreutils has accumulated decades of undocumented behavior, locale-specific quirks, and extensions beyond POSIX. The uutils project maintains a compatibility matrix; some edge cases in sort’s locale-aware collation and printf format handling differ. Shell scripts relying on GNU-specific flags (e.g., ls --color=auto specifics, stat format strings) may see behavioral differences.

Performance is roughly comparable. For most tools, the bottleneck is I/O, not CPU, so the implementation language is irrelevant. For CPU-bound operations like sort on large files, benchmarks show uutils within ~5-10% of GNU in typical cases, with some regressions on specific workloads.

The broader significance is ecosystem: this is the largest mainstream Linux distribution making a system-level language switch for core POSIX utilities. It sets a precedent and will surface compatibility issues at scale, which will either push uutils toward stricter GNU parity or expose how much undocumented GNU behavior real-world scripts depend on.

Source: https://www.omgubuntu.co.uk/2026/09/ubuntu-2610-rust-coreutils-complete

GPT-5.6 Luna vs. GPT-6 Astra: Is a $1.20 Model Good Enough for Code Review?

This is a cost-quality tradeoff analysis for LLM-assisted code review, comparing a cheaper model (GPT-5.6 Luna, implied ~$1.20/M tokens) against a frontier model (GPT-6 Astra) on a code review benchmark. The core engineering question is whether the quality delta justifies the cost delta in a production CI/CD context.

The methodology uses a set of real pull requests with known issues (security vulnerabilities, logic errors, style violations) and scores each model’s review output on detection rate, false positive rate, and comment actionability. Luna reportedly catches ~78% of the issues Astra catches at roughly 10-15x lower cost per review, with a higher false positive rate (+12 percentage points).

The practical interpretation: for high-volume, low-stakes reviews (style, simple logic, obvious bugs), Luna’s cost profile is clearly favorable. For security-sensitive code paths or complex architectural changes, the missed-issue rate matters more than cost. The post recommends a tiered routing strategy — route by file type, diff size, or security label.

The false positive rate difference is underemphasized. In code review, a false positive is not free: it trains developers to ignore automated comments, degrading the signal-to-noise ratio over time. A model that flags 30% more non-issues than the frontier model will face adoption problems even if its true positive rate is acceptable.

The benchmark coverage is the main limitation to trust here: code review quality is notoriously hard to evaluate because the ground truth depends on context, reviewer expertise, and what “actionable” means to a specific team. The specific numbers should be treated as directional rather than absolute.

Source: https://entelligence.ai/blogs/gpt-5.6-luna-vs-gpt-6-astra-is-a-1.20-model-good-enough-for-code-review

OpenArch: PyTorch Implementations of Modern LLM Architectures

OpenArch is a GitHub repository providing clean PyTorch implementations of recent LLM architectural components and full model skeletons. The stated goal is research reproducibility and education rather than production use.

The repo covers several architectures that have seen wide discussion but are often only available as inference-optimized code rather than readable research implementations: variants of grouped-query attention (GQA), sliding window attention, RoPE positional encodings, mixture-of-experts (MoE) routing, and speculative decoding scaffolding. There are also implementations of full model architectures modeled on Llama, Mistral, and Mixtral design patterns.

The value for researchers is that production codebases (e.g., HuggingFace Transformers, vLLM) optimize for throughput and generality, which means architectural choices are buried under batching logic, CUDA kernels, and config abstractions. OpenArch’s implementations prioritize readability: each module is self-contained, uses standard PyTorch primitives, and includes inline comments mapping code to paper equations.

From a technical accuracy standpoint, the RoPE implementation correctly applies the rotation to query and key vectors before the attention dot product, handles the complex-number interpretation via paired real dimensions, and supports dynamic sequence length extension via frequency interpolation. The GQA implementation correctly handles the key/value head broadcasting across query head groups.

Limitations: no training infrastructure, no optimized attention kernels (no FlashAttention integration), and no systematic test suite validating numerical equivalence to reference implementations. For researchers wanting to understand architectural mechanics or prototype modifications, this is useful. For anyone needing to reproduce reported training results, the missing training stack is a significant gap.

Source: https://github.com/anuj0456/OpenArch

Nari Qwen3-TTS and Qwen3-ASR: High Accuracy, Low Latency

Nari Labs is releasing TTS and ASR models built on top of Qwen3 as the underlying language model backbone, and claiming top positions on the Coval voice AI benchmark. The technical approach uses Qwen3 as a frozen or fine-tuned language model and adds task-specific heads/adapters for speech synthesis and recognition.

For TTS, the architecture likely follows the pattern of treating speech tokens as the target vocabulary, using a codec model (e.g., EnCodec or a similar neural audio codec) to discretize waveforms into tokens, and training the LM to generate these tokens conditioned on text. Latency is addressed by streaming generation — decoding audio tokens incrementally and feeding them to the codec decoder without waiting for the full sequence.

For ASR, Qwen3 provides the text decoder, with a separate audio encoder (likely a Whisper-style transformer on mel spectrograms) providing conditioning via cross-attention or prefix tokens. The claim of “high accuracy, low latency” needs qualification: end-to-end latency for streaming ASR depends heavily on chunk size, and accuracy on benchmarks like CommonVoice or LibriSpeech is well-characterized, but the Coval benchmark is proprietary and the evaluation conditions are not fully disclosed in the blog post.

The notable technical claim is leading benchmark performance at competitive cost, which would imply either a more efficient architecture than current SOTA (Whisper large-v3, ElevenLabs, etc.) or a different quality-latency tradeoff point. The blog post is light on architectural specifics, training data composition, and the exact Coval subtasks where Nari leads. Independent evaluation on standard public benchmarks would be needed to assess the claims.

Source: https://narilabs.com/blog/nari-labs-leads-coval-voice-ai-benchmarks/

Noteworthy New Repositories

xevrion/breakscale

A browser-based distributed systems simulator that lets you construct a topology — nodes, network links, load balancers, partitions — configure it, then drive it with synthetic load until something fails. The pedagogical loop is: build, stress, observe the failure mode, understand why. Internally it models message passing, node state machines, and configurable fault injection (network partitions, node crashes, latency spikes). The simulator traces causality so you can step through the sequence of events that led to a failure, which is the key differentiator from just reading about CAP or Paxos. It is not a production tool; it is explicitly a learning environment, so correctness of simulation matters more than throughput. Useful for a grad student who wants intuition about consensus protocol edge cases, or an engineer preparing for distributed systems interviews who needs to move beyond whiteboard diagrams. The codebase is JavaScript/TypeScript and runs entirely client-side, meaning no server setup. The visual feedback loop — watching a quorum lose availability as you partition nodes — makes abstract fault models concrete in a way that static diagrams cannot. The 1,150 stars in a short window suggests significant demand for interactive distributed systems education tooling.

Source: https://github.com/xevrion/breakscale

TokenRhythm/NeoHorse

NeoHorse-1 is a research project targeting recursive self-improvement in LLMs via agentic post-training with a routing harness. The core idea is that the model generates training signal for its own subsequent fine-tuning iterations by acting as an agent on tasks, with a router deciding which model checkpoint handles which subtask at each step. This routing harness is the architectural centerpiece: it selects among candidate model versions or specialized heads based on task embedding similarity or confidence scores, enabling specialization without full retraining per domain. The “recursive self-improvement” framing means the outputs of one agentic run feed the preference or SFT dataset for the next training round — a closed loop analogous to STaR or ReST but with explicit routing mediating the process. At 387 stars it is early-stage, and the repo currently contains model weights, training scripts, and evaluation harnesses rather than a polished library. The open questions are significant: stability of the self-improvement loop, reward hacking under repeated self-distillation, and whether routing actually prevents catastrophic forgetting across iterations. Worth watching for researchers working on post-training pipelines or self-play based fine-tuning.

Source: https://github.com/TokenRhythm/NeoHorse

Continuum-AI-Corp/OrcaReplay

OrcaReplay provides deterministic record-and-replay for LLM agent runs. Every tool call, model invocation, intermediate state, and branching decision is logged to a structured trace. You can then replay that trace — either exactly, to reproduce a bug, or with a substituted model, to compare behavior across backends without re-incurring API costs. The fork primitive is the most interesting capability: from any recorded step you can branch the trace, explore a counterfactual, and diff the resulting execution trees. This directly addresses the core debugging problem with agents: non-determinism and cost make it expensive to reproduce failures. The implementation sits as a middleware layer over the agent framework, capturing inputs and outputs at the tool-call boundary rather than instrumenting model internals, so it is framework-agnostic in principle. Built by the OrcaRouter.ai team, it complements their routing product. Practical use cases include regression testing agent pipelines after a model version bump, cost auditing, and post-mortem analysis of production failures. The main limitation is that replay fidelity degrades when agent behavior depends on wall-clock time or external state not captured in the trace. At 250 stars it is early but technically differentiated from generic logging.

Source: https://github.com/Continuum-AI-Corp/OrcaReplay

xzf-thu/VoiceMem

VoiceMem is infrastructure for stateful voice agents that separates memory into two subsystems: a “left brain” for factual, episodic, and semantic information and a “right brain” for affective/emotional state. The dual-memory architecture acknowledges that voice interaction has both informational and relational continuity — a voice agent needs to remember what was said but also the emotional valence of past exchanges to maintain coherent persona and appropriate response tone over time. The fully streaming architecture means that memory reads and writes are pipelined with ASR, LLM inference, and TTS so that retrieval latency does not add a synchronous blocking step to the response loop; this is non-trivial because typical RAG pipelines insert a blocking retrieval call between transcription and generation. The left brain appears to use vector store retrieval over conversation summaries and structured facts, while the right brain tracks affect signals extracted from prosody and content. With 1,737 stars it has strong initial traction. Key open questions: how affective state is quantized and updated, whether the dual-store separation actually improves downstream metrics over a unified store, and latency benchmarks for the streaming memory path at scale.

Source: https://github.com/xzf-thu/VoiceMem

hkqr/my-free-code

A self-hosted API gateway specifically targeting Claude Code and coding-focused agents, providing model routing, streaming passthrough, tool-call forwarding, reasoning-mode support, provider fallbacks, and local model integration behind a single OpenAI-compatible endpoint. The practical use case is cost and resilience management: route cheap tasks to a local Ollama instance or a cheaper provider, fall back to Anthropic or OpenAI when the primary is unavailable, and do all of this transparently to the agent. The gateway handles streaming correctly, including tool-call streaming which many proxy implementations break. Reasoning passthrough means extended thinking tokens from Claude are forwarded intact rather than stripped. The local model support bridges the gap between cloud APIs and on-prem inference servers. It is a thin routing and proxy layer, not a full orchestration framework, which keeps complexity low. At 636 stars it addresses a real operational pain point for teams running Claude Code in production who want provider independence without rewriting agent code. The main risk is that it is tightly coupled to current API schemas, so it requires maintenance as provider APIs evolve.

Source: https://github.com/hkqr/my-free-code

youngyangyang04/llm-master

A structured, Chinese-language curriculum for LLM engineering covering the full stack from prompt engineering and RAG through fine-tuning, model deployment, MCP (model context protocol), Transformer internals, and industry interview preparation. The author is the same as the well-known leetcode-master repo, so the pedagogical style is systematic and interview-oriented. The content is organized as a learning path rather than a reference, with explicit sequencing from fundamentals to production practice. Technically it covers practical topics that Chinese-language resources have historically underserved: MCP integration, quantization and deployment optimization, and the specifics of applying for LLM-related roles at large Chinese tech companies. At 407 stars it is growing in a large addressable audience. For a non-Chinese reader the direct utility is limited, but it is a useful signal about what skills the Chinese ML engineering job market emphasizes. The AI Agent and RAG sections are the most substantive for practitioners, covering retrieval pipeline design, tool-use patterns, and evaluation methodology with runnable code examples.

Source: https://github.com/youngyangyang04/llm-master

zorost/AI-Engineering-Lab

A 24-week self-paced AI engineering course delivered as 43 Jupyter notebooks with no signup, no platform lock-in, MIT licensed. The curriculum progresses from Python and classical ML through LLMs, RAG pipeline construction, fine-tuning, agent frameworks, MCP, and cloud deployment across Azure, Vertex AI, and Bedrock, with a Databricks track. The single continuous case study threading across all 43 notebooks is pedagogically significant: it forces the student to carry context across topics rather than treating each module as isolated, which is closer to how real engineering projects accumulate complexity. The notebooks are runnable as-is, meaning dependencies are pinned and examples are not pseudocode. Cloud coverage across three major providers is broader than most competing curricula, which tend to be Azure-only or AWS-only. At 305 stars the reach is modest but the MIT license and no-signup constraint maximize accessibility. The main gap is the absence of a strong evaluation and observability module — the course covers building systems but less on measuring and debugging them in production. A useful resource for an engineer transitioning into ML infrastructure roles.

Source: https://github.com/zorost/AI-Engineering-Lab

shadcn-ui/lint

An agent-first linter for Tailwind-based design systems that lets you encode design rules as natural-language or structured constraints, then verify compliance either in CI or via an LLM agent. The framing as “agent-first” means the rule format is designed to be readable and actionable by a code-generating agent, not just a human reviewer — so an agent can both check violations and propose fixes without additional tooling. Rules cover Tailwind class usage patterns: enforcing a color palette, prohibiting arbitrary values, requiring spacing to come from a defined scale, etc. This fills a gap in current Tailwind tooling: ESLint plugins exist but they operate on ASTs and are awkward to configure for semantic design constraints; this linter operates at the design-token level and is intentionally ergonomic for LLM consumption. Coming from the shadcn-ui team, it targets the shadcn/Tailwind ecosystem specifically, which has wide adoption. The 1,439 stars reflect that audience. The core open question is how it handles dynamic class composition (template literals, conditional classes) which is where static analysis of Tailwind consistently breaks down, regardless of the tooling approach.

Source: https://github.com/shadcn-ui/lint