Daily AI Digest — 2026-09-11
arXiv Highlights
NCP-ArchPreview Technical Report: Moving towards Latent Space Language Models through Next Concept Prediction
Problem
Next-token prediction (NTP) forces a model to allocate capacity to local surface statistics: given a prefix, the loss is dominated by short-range predictability, and long-range planning is only implicitly rewarded through the compounded token likelihood. A recurring critique is that this objective under-specifies the semantic structure the model must eventually represent — high-level “concepts” that span many tokens are never directly supervised. Prior attempts at concept-level or latent-space objectives (e.g. Meta’s Large Concept Models, byte-latent transformers, and various planning-token schemes) have generally required either an external sentence encoder, a bespoke tokenizer, or gave up standard autoregressive generation. NCP-ArchPreview asks whether one can add a genuine concept-level objective on top of NTP, using latents derived from the model’s own hidden states, without breaking token-level decoding, and whether this scales.
Method
The architecture is a standard decoder-only transformer augmented with two components:
Product-quantized concept vocabulary. Hidden states h_t at some intermediate layer are projected and quantized with product quantization (PQ): the vector is split into M subvectors, each assigned to the nearest of K codebook entries, producing a composite concept id c_t \in \{1,\dots,K\}^M. This yields an effective vocabulary of K^M discrete concepts constructed entirely from the model’s own representations — no external tokenizer or sentence encoder. Because the codebooks are learned jointly, the concept space evolves with the model.
Concept Module. A dedicated sub-network predicts future concepts \hat c_{t+\Delta} from the current hidden state. This is the NCP head. Predicted concept embeddings are then fed back into the token stream to condition subsequent token generation, giving the model an explicit planning signal.
Training minimizes a joint objective \mathcal{L} = \mathcal{L}_{\text{NTP}} + \lambda\, \mathcal{L}_{\text{NCP}}, with \mathcal{L}_{\text{NTP}} the usual cross-entropy on tokens and \mathcal{L}_{\text{NCP}} a cross-entropy over the PQ concept indices (summed over the M subcodebooks). Because concepts span multiple tokens, NCP is a harder objective per prediction, and forces the residual stream to carry information beyond the next-token window. Critically, at inference time the model still emits tokens autoregressively — the Concept Module runs as an internal side-channel that shapes hidden states, so no changes to standard decoding infrastructure are needed.
Two design choices are worth flagging for reimplementation:
- PQ is used instead of a single large VQ codebook. With M subquantizers of size K, one obtains exponentially many concept classes (K^M) while keeping each softmax tractable and each codebook well-utilized. This mitigates the codebook collapse that plagues VQ-VAE-style latents at scale.
- Concept prediction targets are computed from future hidden states of the same model. This is a bootstrapped target — concepts are not fixed a priori but co-evolve with the network, similar in spirit to BYOL or JEPA target encoders, though here the target and student share weights and the objective is discrete.
Results
The model is scaled to 8.9B parameters and pretrained on 5.73T tokens from Dolma-3, which the authors describe as the largest latent-space LM to date. The headline efficiency claim is that NCP-ArchPreview matches the final pretraining loss of OLMo-3-7B while consuming only 51.3% of OLMo-3-7B’s training tokens — roughly a 2× token-efficiency improvement at comparable scale.
After full pretraining, on the downstream macro-average NCP-ArchPreview beats OLMo-3-7B by 2.45 points, with a particularly large 5.99-point gain on (the abstract truncates the specific benchmark name, but the pattern — bigger gains on harder, longer-context reasoning tasks — is consistent with the claim that NCP supervises multi-token structure). Because parameters (8.9B vs 7B) are not exactly matched, some of the win is capacity; however, the token-efficiency result at matched loss is scale-controlled and is the stronger evidence for the objective itself.
Limitations and open questions
- Parameter parity. 8.9B vs 7B is a ~27% parameter gap; a same-size ablation isolating NCP is needed to attribute all downstream gains to the objective rather than capacity plus data mixture.
- NCP ablations at scale. The report is a preview; controlled ablations on M, K, the concept-prediction horizon \Delta, the layer from which concepts are quantized, and the loss weight \lambda at multi-billion scale are not given here.
- Concept interpretability. PQ concepts are constructed from hidden states — whether the induced discrete units correspond to interpretable linguistic or semantic structures (phrases, propositions) is unaddressed. Without this, “concept” is a description of the training signal, not a claim about representation content.
- Inference cost. The Concept Module runs during generation and feeds back into the token stream; the throughput cost relative to a plain decoder of matched parameter count is not quantified in the abstract.
- Post-training behavior. Gains are reported for pretraining and downstream zero/few-shot; interaction with SFT and RLHF, and whether the concept channel remains useful (or drifts) after alignment, is open.
Why this matters
If the 51.3%-tokens-to-matched-loss result holds under tighter controls, it is one of the cleanest demonstrations that a self-supervised, multi-token objective co-trained with NTP yields real pretraining-compute savings at frontier scale, without giving up standard autoregressive decoding. It also revives PQ over the model’s own hidden states as a practical route to latent-space LMs, sidestepping external encoders that have hampered prior concept-model efforts.
Source: https://arxiv.org/abs/2609.10715
FreeFlow: A Bias-free Hierarchical Transformer for Optical Flow Estimation
Problem
Modern optical flow architectures are dominated by task-specific inductive biases: 4D correlation volumes (RAFT and descendants), feature warping, iterative GRU refinement, and coarse-to-fine lookups. These components deliver accuracy but add pipeline complexity, memory overhead (correlation volumes scale as O((HW)^2)), and constrain the model to hand-designed matching heuristics. A parallel line — CroCo-Flow, FlowFormer — leans on transformers but still stitches in cost volumes or tiling with late fusion. The question FreeFlow addresses is whether a plain feed-forward encoder–decoder transformer, with no flow-specific machinery, can match state of the art at 1080p while remaining memory-tractable.
Method
FreeFlow inherits the CroCo/DUSt3R/MASt3R skeleton: a Siamese ViT encoder over both views followed by a decoder that alternates self-attention and cross-attention between the two feature maps. Given I_1, I_2 \in \mathbb{R}^{H\times W\times 3}, each image is patchified into non-overlapping 8\times 8 patches, yielding N = \frac{H}{8}\cdot\frac{W}{8} tokens per view. Shared-weight encoders produce
F^1 = \operatorname{Encoder}(X_1),\quad F^2 = \operatorname{Encoder}(X_2),
and the decoder emits flow tokens
Z = \operatorname{Decoder}(F^1, F^2),
where each decoder block does self-attention over the current tokens, then cross-attention with F^1 as queries and F^2 as keys/values. Tokens are depatchified and mapped to a dense flow field by a lightweight head. No correlation volume, no warping, no iterative refinement.
The mechanical novelty is how attention is structured for high-resolution inputs. Full global self-attention over N = HW/64 tokens is infeasible at 1080p. FreeFlow interleaves three variants: (i) window attention over fixed tiles for local processing, (ii) shifted-window attention for cross-tile exchange (Swin-style), and (iii) a global attention branch at a reduced resolution. The key design principle is Dense Feature Fusion: information exchange across tiles and across scales happens throughout the network rather than only in the decoder.
The figure contrasts three strategies. (a) Per-tile independent inference (CroCo/FlowFormer-style) — tiles interact only via late averaging, forward passes grow with resolution, and long-range motions crossing tile boundaries are lost. (b) Late Feature Fusion (DepthPro-like) — multi-scale features are fused only in the decoder; global context arrives late and can leave visible seams. (c) FreeFlow’s dense fusion — cross-tile and global exchange are repeated across depth.
Training
FreeFlow follows the CroCo two-stage recipe: cross-view completion (CVC) pretraining, then optical flow fine-tuning. In CVC, a large fraction of patches in one view is replaced by a learned token e_{\text{mask}}; the model reconstructs the masked view conditioned on the other. This objective directly rewards learning dense correspondences, which is precisely the downstream signal.
One deviation from CroCo: because the encoder is hierarchical with windowed attention, dropping tokens breaks the tile structure. FreeFlow instead injects e_{\text{mask}} at the encoder input (rather than only at the decoder input as in CroCo), preserving spatial layout.
Pretraining uses ARKitScenes, MegaDepth, and 3DStreetView (3.7M pairs) for 346k steps at 224\times224, LR 8\text{e-}4, WD 5\text{e-}2, batch 2048. Flow fine-tuning proceeds through a TaTSKH mixture (TartanAir 0.23, Sintel 0.25, Things 0.24, KITTI 0.09, HD1K 0.19), then a high-resolution stage with 32640-token crops for 90k steps, then benchmark-specific fine-tuning (Sintel 12.5k, KITTI 2.5k, Spring 60k).
Results
FreeFlow reports:
- Sintel: 0.68 / 1.48 EPE on Clean/Final.
- KITTI-2015: 3.23 Fl-all.
- Spring: 3.192 1px error.
These are state-of-the-art numbers on all three benchmarks, achieved without correlation volumes or iterative refinement. The paper reports that accuracy scales monotonically with model size across small-to-large variants — a scaling property one expects from plain transformers but that RAFT-style architectures notoriously lack.
Qualitatively, the endpoint-error maps show FreeFlow recovers fine structure (the hole in the staff, thin boundaries) while maintaining large-scale motion consistency, whereas Win-Win, CroCo-Flow, and WAFT trade one for the other.
Limitations and open questions
The paper does not report inference latency numbers alongside the memory-efficiency claim, so the compute/quality trade-off vs. RAFT-family models at matched throughput is unclear from what is shown. The reliance on cross-view completion pretraining on 3.7M curated pairs shifts the inductive bias from the architecture into the data pipeline; how much of the SOTA gap is architectural versus a consequence of scale and CVC pretraining is unresolved. The global attention branch operates at reduced resolution — the extent to which that reintroduces a soft coarse-to-fine prior is worth probing. Finally, occlusion handling and forward-backward consistency, typically handled by iterative refinement, are not discussed; how the bias-free decoder deals with disocclusions in Sintel Final is an open question.
Why this matters
FreeFlow suggests the flow-specific architectural stack — correlation volumes, warping, GRU updates — is not necessary for state of the art, provided one has CVC-style pretraining and an attention design that scales to 1080p. If confirmed, this pushes optical flow toward the same “just scale a transformer” regime that has consumed depth estimation and stereo.
Source: https://arxiv.org/abs/2609.11486
Recursive Code World Models: Building Complex Worlds through Recursive Scene Programs
Problem
Code world models represent a scene as an executable program P that, when run, produces geometry, materials, lighting, and placements. Given a single reference image I^\star, the reconstruction task is to recover P such that its render \widehat{I}=\mathcal{R}(\operatorname{Exec}(P);\kappa) matches I^\star in layout, appearance, and spatial relations. Prior image-to-scene-program methods produce a single flat program in one shot, which collapses under scene complexity: assemblies with many objects, hierarchical structure (buildings inside blocks inside cities), and inter-component relations (contacts, alignments, shared assets) cannot be simultaneously resolved at global and local scales by a single generation. The representation says what a world is, but not how to construct one.
Method
RCWM couples a Recursive Scene Program (RSP) representation with a recursive solver \mathcal{F} that mirrors the representation’s compositional structure.
An RSP is a tree of subworld programs u_i^{(k)} at depth k, each carrying local procedures, editable parameters, and typed references to children. The child-fetch operation is defined as P_i^{(k)}[j] = P_j^{(k+1)}, and children are swapped in via \operatorname{Compose}(P_i^{(k)}, \{j \mapsto Q_j\}), which retargets selected references while preserving the parent’s local code and placement rules. The root P = P_0^{(0)} is executable in Three.js. Shared generators and assets are accessed through code-level references so that repeated components stay consistent and cross-branch spatial relationships remain expressible.
The solver follows a global–local–global recursion at every level:
- Establish the whole. At level k, generate an initial parent program P_i^{(k)} that captures scene-wide geometry, camera-consistent layout, and coarse placements.
- Recurse on unresolved parts. For each child reference j flagged as insufficiently resolved, call \mathcal{F} on the subworld, yielding Q_j. Those calls in turn establish their own whole, recurse, and revisit, forming an arbitrary-depth call tree.
- Revisit the whole. After child returns, form \operatorname{Compose}(P_i^{(k)}, \{j\mapsto Q_j\}) and refine the parent to reconcile boundaries, contacts, spatial relations, and errors shared across siblings that only became visible once children were resolved.
A key mechanism is reference-aligned views: each recursive call inherits the parent camera \kappa, and crops on I^\star are taken at matching coordinates and magnification so that the child solver compares its render against the exact evidence its parent was looking at.
Overlapping inspection windows are used both for local detail and for interface regions between components, which is what makes parent revisitation informative rather than redundant. A vision-language coding agent drives the loop: it compares I^\star with \widehat{I} directly, decides whether to descend, edits parameters or code, and decides when to return.
The global–local–global schedule is the mechanical answer to a specific failure mode of flat code generation: local refinement without a returning revisit desynchronizes children (misaligned roads at block boundaries, floating props, inconsistent shared assets); a global-only pass cannot allocate enough capacity to fine detail. Recursive descent gives fine structures their own perception-and-edit loops; parent revisitation restores scene-wide coherence after those edits.
Experiments
Evaluation uses 10 reference images: five whole-scene references and five local crops. Four crops (school-block, police-corner, park-lake, shop-row) and city-full come from JanaChumi’s CC0 “Isometric city” sprite pack; the remainder (island-harbor, medieval-village, snow-village, japan-island, valley-village) are WorldClaw demonstration renders. All methods run on the same base model with identical raw inputs at matched resolution, and only images are used — source prompts, terrain, and assets from the originals are withheld.
The city-full case is the stress test: many blocks, repeated infrastructure, and small props whose alignment is only visible at magnification. The affine-aligned window comparison isolates whether local structure survives global construction. The paper reports that RCWM outperforms prior code-based image-to-scene baselines across the complex scenes, with ablations attributing gains to each of the three phases — initial whole-scene construction, recursive child solves, and parent revisitation — indicating that removing revisitation in particular degrades cross-child consistency even when local children are individually improved.
Limitations and open questions
The provided sections do not report scalar metrics (e.g., CLIP similarity, IoU, user study numbers), so quantitative gains over baselines are asserted rather than tabulated in the material available here. The evaluation set is 10 scenes; robustness to non-isometric photographs, cluttered real-world imagery, or scenes with strong occlusion is unclear. The agent’s descent and stopping decisions are LLM-mediated, so cost scales with call-tree depth and branching. Consistency of shared generators across recursion boundaries depends on the coding agent respecting reference semantics, which is not formally guaranteed. Finally, Three.js as the execution target constrains the achievable material and lighting fidelity relative to physically based renderers.
Why this matters
Treating image-to-scene as a recursive program-synthesis problem — with the solver’s control flow matching the representation’s compositional structure — is a cleaner formulation than either monolithic code generation or purely neural scene reconstruction. The global–local–global schedule with parent revisitation is a concrete mechanism for maintaining scene-wide invariants under local edits, which is the recurring failure mode of agentic scene construction.
Source: https://arxiv.org/abs/2609.11499
Negative Self-Distillation: Learning to Reason by Avoiding Flaws
Problem
On-Policy Self-Distillation (OPSD) uses the model itself as teacher, conditioned on privileged information (typically the gold answer), and trains the student to imitate that “informed” trace. The authors argue this collapses productive uncertainty: the teacher, knowing the answer, produces overly confident traces that lack backtracking, hedging, and self-correction. Distilling into these traces suppresses exactly the exploratory behaviors needed on hard problems. Empirically, OPSD gains are marginal on Qwen3-1.7B/4B/8B (ΔAvg of +1.1, +1.0, +0.3 across seven math benchmarks, none significant at p<0.05).
Negative Self-Distillation (NSD) inverts the setup: rather than imitate a privileged positive teacher, push away from a self-generated negative teacher that embodies plausible failure modes. No gold labels are required.
Method
Given unlabeled problems \mathcal{D}_{\text{raw}}=\{x_i\}, NSD proceeds in two stages.
1. Self negative conditioning. For each x, sample an initial trace y_{\text{init}}\sim\pi_\theta(\cdot\mid x), then prompt the same model to produce a problem-specific negative instruction n\sim\pi_\theta(\cdot\mid x, y_{\text{init}}) (e.g., “act as a careless reasoner who skips verification”). Conditioning \pi_\theta on n yields the negative teacher \pi_{\text{neg}}(\cdot\mid x, n, y_{<t}). Alternatives (a fixed “wiki-style” prompt, question-only conditioning) work but are weaker.
2. Gated divergence training. Naively unlearning tokens under \pi_{\text{neg}} is destructive because most tokens are stylistic/structural (punctuation, connectives) that both the negative teacher and a correct reasoner emit with high probability. NSD isolates tokens whose probability is abnormally boosted by the negative condition relative to a reference \pi_{\text{ref}} (a frozen copy of the base model conditioned only on x):
w_t = \max\bigl(0,\ \pi_{\text{neg}}(y_t\mid x,n,y_{<t}) - \pi_{\text{ref}}(y_t\mid x,y_{<t})\bigr).
Tokens with w_t>0 are penalized via a gated unlikelihood (GU) objective, while non-gated tokens are regularized only by KL to the reference. Because raw w_t can spike on frequent tokens and blow up gradients, the paper applies a sigmoid to the GU term, redistributing loss mass toward genuine reasoning tokens rather than punctuation.
Training on MATH (labels discarded for NSD, Intuitor, TTRL), 2 epochs, \alpha=0.01 for the KL term, top-k=32 for the softmax over the vocabulary in the gated set, batch size 32, max generation length 4096.
Results
Evaluated Avg@8 (non-thinking mode) across AIME 2024/2025/2026, HMMT 2025 Feb, AMC 2023, OlympiadBench (675 open-ended), and MATH-500.
- Qwen3-1.7B: ΔAvg = +2.3 (p=0.001). AIME 2025 jumps from 10.0 to 17.9; OlympiadBench 37.1 → 38.7.
- Qwen3-4B: ΔAvg = +7.5 (p<10^{-4}). AIME 2024 23.8 → 35.8, AIME 2025 20.4 → 31.3, AIME 2026 17.9 → 29.2, HMMT 10.8 → 16.3, AMC 68.8 → 76.3, OlympiadBench 47.8 → 51.0. OPSD gets only +1.0 on the same model.
- Qwen3-8B: ΔAvg = +6.0 (p<10^{-4}). AIME 2024 28.8 → 39.6, HMMT 11.7 → 17.9, AMC 67.2 → 75.6.
OPSD (with gold labels), Intuitor, and TTRL all deliver sub-2% average gains with wide CIs; several are statistically indistinguishable from the base model. NSD is the only method with lower-bound CIs strictly above zero on all three model sizes.
Style-token filtering. The gating function is validated by the style-to-task weight ratio R (lower = more selective on reasoning tokens). NSD’s solution-aware gate achieves R=3.4\times, vs 3.9\times for entropy-weighted OPSD and 5.4\times for vanilla OPSD; the wiki-conditioned variant is best at 2.6\times. This substantiates the claim that NSD’s gate concentrates gradient on task-relevant reasoning tokens, whereas OPSD-style losses leak signal into stylistic imitation.
Limitations and open questions
- Only mathematical reasoning is evaluated; whether “act as a careless reasoner” transfers to code, agentic, or open-domain tasks is untested.
- The negative teacher is the same base model. If the model has systematic blind spots, the negative distribution may fail to cover them — the method can only push away from failure modes the model can articulate.
- The reference \pi_{\text{ref}} is a frozen base; drift between \pi_\theta and \pi_{\text{ref}} during training makes the gate progressively stale, and no adaptive-reference ablation is shown.
- No comparison with GRPO-style RLVR baselines that use verifiable rewards, only with label-free (Intuitor, TTRL) and label-using OPSD.
- Hyperparameter \alpha=0.01 for KL and top-k=32 are set without a sensitivity study in the excerpted material.
Why this matters
NSD reframes label-free self-improvement: instead of asking “what would the model do if it knew the answer?” (OPSD’s implicit prior, which produces overconfident traces), it asks “what would a bad version of me do here?” and steers away. That the resulting objective beats gold-label OPSD by 6–7 points ΔAvg on 4B/8B models — without any supervision — suggests a substantial amount of reasoning capability is bottlenecked by imitation-induced overconfidence rather than knowledge gaps.
Source: https://arxiv.org/abs/2609.11699
An Open Recipe for IMO Gold: Training Nemotron for Olympiad Mathematics
This report from NVIDIA describes a natural-language olympiad-proof system built on three Nemotron-3-Ultra 550B-A55B (mixture-of-experts) checkpoints that scored 30/42 at IMO 2026 — above the gold threshold — with no formal prover, tools, or retrieval. The interest here is not the score alone but that the two post-trained specialists, training data, inference code, submitted solutions, and a 200-problem novel benchmark (Nemotron-IMO-Bench) are released under OpenMDW-1.1 / CC BY 4.0.
Problem framing
Olympiad proofs stress two capacities that ordinary math benchmarks (numeric answers, autograded competitions) do not: producing long chains of rigorous natural-language argument, and reliably detecting subtle gaps in such arguments. The authors treat this as a joint post-training + test-time-compute problem: which checkpoints to train, and how to allocate a large inference budget across generation, verification, and refinement.
Checkpoints and roles
Starting from Nemotron-3-Ultra-GA, they produce two specialists:
- Nemotron-3-Ultra-SFT: supervised fine-tuning on olympiad-style proofs.
- Nemotron-3-Ultra-RL: reinforcement-learning post-training on top of similar data.
All three checkpoints (GA, SFT, RL) are used simultaneously at inference in three roles — generation, verification, refinement — with role assignments differing per stage.
Test-time pipeline
The submitted system is an iterative generate-verify-refine loop inspired by DeepSeekMath-V2, run independently per problem for up to 8 rounds.
Round 1 generation. Each of the three checkpoints samples 16 attempts from each of 8 complementary generation prompts (lemma-first decomposition, route comparison, counterexample search, etc.), yielding 3 \times 8 \times 16 = 384 round-1 attempts per problem. The multi-prompt, multi-checkpoint split is a deliberate diversification: their ablations show a second checkpoint solves problems the first cannot, whereas doubling attempts from a single checkpoint yields little.
Verification. Both SFT and RL act as reference-free verifiers, each producing 8 independent judgments per candidate for a panel of 16. Scores are in \{0, 0.5, 1\} (fatal error / minor issues / complete). A proof is internally accepted only when all 16 valid judgments return 1 — an intentionally strict unanimity criterion, decoupled from later independent-jury grading.
Refinement. If no proof is accepted, the top-ranked \le 16 candidates from the global proof pool are each paired with up to 8 verifier critiques and sent to all three generators, sampling 4 outputs each: 16 \times 3 \times 4 = 192 refinement attempts per round. Refined proofs are re-verified and merged into the pool.
Finalist selection. A second stage re-scores round-8 finalists with a substantially larger judgment budget before choosing the submitted proof.
The internal-verifier trajectory (green) tracks the independent jury (blue dashed) closely, indicating the unanimity criterion is a reasonable proxy for correctness during the run rather than merely a stopping heuristic.
Ablations on the 30-problem dev set
The development set (20 problems from Nemotron-IMO-Bench + 10 recent-competition problems) is stratified into 3 easy / 7 medium / 10 hard / 10 unsolved with balanced coverage across algebra, combinatorics, geometry, and number theory.
Single-checkpoint pipelines (Table 2, cumulative independent-jury score / accepted-problem count):
- Round 1: GA 34 (5), RL 47 (7), SFT 70 (10), Ensemble 91 (13).
- Round 8: GA 145 (23), RL 152 (23), SFT 147 (21), Ensemble 167 (25).
- Round 8 + fallback (submit best pool candidate if none accepted): GA 162, RL 180, SFT 165, Ensemble 188.
Several structural observations follow. First, both post-trained checkpoints strictly dominate GA at every round. Second, SFT is strongest early (best R1 single-model score of 70), whereas RL wins by R8 (152) and after fallback (180); this is consistent with SFT peaking on solvable problems while RL keeps improving on harder ones. Third, the three-checkpoint ensemble consistently opens a gap that a single checkpoint does not close even with 8 rounds: at R2 the ensemble already reaches 160 vs the best single-model 98, and it maxes out at 25 accepted problems vs 23 for any single checkpoint. Fourth, the fallback (submitting the highest-ranked unaccepted proof) adds substantial jury score without adding accepted problems, meaning many high-quality proofs fall just short of unanimous internal acceptance.
Limitations and open questions
The system’s success rests on strict panel unanimity, which the authors themselves note does not imply correctness under official grading; ablations do not report false-accept rates on adversarial or near-miss proofs. Compute cost is not fully broken down in the excerpted sections, but with 384 R1 attempts and 192 per refinement round across up to 8 rounds per problem, per-problem token counts are enormous. The RL vs SFT recipe details (reward signal, whether the verifier is trained jointly, exploration strategy) will matter for reproduction and are the natural focus for follow-up. Finally, generalization beyond olympiad-style natural-language proofs — e.g., to proofs requiring heavy calculation or to domains without a self-consistent verifier panel — is untested.
Why this matters
An open-weights, no-tools, natural-language pipeline crossing IMO gold shifts the reference point for what unaided LLM reasoning can do, and the release of the two specialist checkpoints plus a 200-problem novel benchmark makes the recipe — not just the score — reproducible and contestable.
Source: https://arxiv.org/abs/2609.10712
SpatialBlock: Enhancing Spatial Intelligence in LVLMs via Synthetic Block-Stacking Problem
Problem
LVLMs consistently underperform on tasks that require reconstructing 3D structure from 2D images — occlusion reasoning, viewpoint change, and composition. The standard remedy has been to curate real-scene datasets with dense geometric annotations (depth, poses, object graphs), which is expensive and noisy because labels are often produced by upstream perception modules that themselves fail on the hard cases. This paper argues for a different route: train the foundational spatial primitives using cheap, controllable synthetic block-stacking puzzles, analogous to how children develop spatial cognition before moving to complex scenes.
The gap motivating the work is stark: humans solve simple projection tasks with near-perfect accuracy, while frontier proprietary models produce inconsistent 3D interpretations even on toy configurations.
Method
SpatialBlock-15k decomposes spatial intelligence into three primitives, each realized as a question type:
- Q1: 3D-to-2D projection. Given a 3D block configuration, predict its 2D silhouette from a specified viewpoint. Requires occlusion-aware rendering internally.
- Q2: Viewpoint transformation. Given a structure and a rotation/viewpoint change, predict the new appearance while preserving relative positions.
- Q3: Structural combination. Given two structures, predict the merged result, including contact interfaces.
A visual-cue extension adds controlled color modulation: in Q1 colors encode depth ordering, in Q2 colors preserve structural role across the transform (giving the model anchor points), and in Q3 colors mark correspondence between the two structures. This is meant to steer the model toward anchor-based tracking rather than pattern-matching whole silhouettes.
Two training variants are used on the same 15k data:
- SpatialBlock-direct — supervised fine-tuning on the answer sequence only, standard cross-entropy over the answer tokens: \mathcal{L}_{\text{ce}}(\theta) = -\sum_i \log P(y_i \mid y_{(1:i-1)}, q, v).
- SpatialBlock-reason — supervised on a reasoning trace followed by the final answer, exposing intermediate steps such as enumerating blocks, applying the transform, and projecting.
Base models: Qwen2.5-VL-3B/7B, Qwen3-VL-4B, InternVL3-2B. Evaluation: an in-domain 600-question SB-Bench held-out split, plus four out-of-domain benchmarks — MindCube, MMSI-Bench, SPBench (spatial), and MMMU (general perception). Only multiple-choice items are scored to match the training format.
Results
In-domain, the synthetic training essentially saturates the task. On SB-Bench, SpatialBlock-3B-direct reaches 94.8, 7B-direct 95.0, 4B-direct 95.7, and 2B-direct 97.2, versus 17.0–29.9 for the untuned base models and 43.8 for GPT-5. This is expected given distribution match but confirms the objective is learnable at scale from 15k examples.
More interesting is the out-of-domain transfer. On MindCube (real-scene spatial QA), SpatialBlock-4B-direct hits 51.3 and 3B-direct 49.1, compared to 26.2 and 39.1 for their respective bases, and 39.0–56.7 for large open-source and proprietary models. On MMSI-Bench, SpatialBlock-7B-reason reaches 29.7, above GPT-5’s 42.8 tier only in the sense that it beats every open-source specialist listed (24.4–28.3). On SPBench, results are mixed: SpatialBlock-7B-reason gets 50.9, better than the 7B base (46.7), but SpatialLadder-3B’s 76.6 is an in-domain result on SPBench itself.
General perception on MMMU is preserved or slightly improved: SpatialBlock-7B-reason reaches 55.5 versus 46.6 base; the 4B variants sit at 47.2–49.6 versus 47.5 base. This suggests the synthetic training does not degrade broad visual competence — a common failure mode of narrow SFT.
Overall averages across the five benchmarks: SpatialBlock-7B-reason 43.5, 4B-direct 43.1, 7B-direct 42.8, versus base models at 36.3–38.0 and the strongest prior specialist (SpaceR-7B) at 41.9. Notably these gains come with 15k examples versus 25k–150k for competing specialist datasets.
Direct vs. reason variants trade off differently. Direct wins on the in-domain projection tasks (higher SB-Bench: 94.8 vs 90.2 at 3B, 95.0 vs 77.5 at 7B) — likely because verbose CoT introduces token-level errors on structured spatial outputs. Reason wins on transfer benchmarks that require multi-step composition (MMSI-Bench, SPBench, MMMU on 7B), consistent with CoT helping when the target distribution demands compositional inference rather than pattern completion.
Limitations and open questions
- SB-Bench near-saturation reflects distributional overlap with training, not spatial mastery; the informative number is OOD transfer, where absolute scores remain in the 28–51 range.
- The block domain is a strong prior: uniform cubes, axis-aligned stacking, restricted viewpoints. Real scenes involve continuous geometry, textured materials, and non-rigid relations that block puzzles do not exercise.
- The color-cue design assumes correspondence is retrievable through color, which may inject a shortcut rather than the intended anchor-based reasoning. An ablation isolating color cues would clarify whether the gains transfer without them.
- Multiple-choice-only evaluation hides calibration and free-form generation failure modes.
- No comparison to models trained on real-scene 3D data at comparable compute; the claim is efficiency (15k examples), but per-token cost of synthetic reasoning traces is not reported.
Why this matters
The result reframes spatial pretraining as a curriculum problem rather than an annotation problem: 15k procedurally generated block puzzles produce transfer to real-scene spatial benchmarks competitive with 80k–150k-example specialist datasets, while preserving MMMU. If this holds under stricter OOD evaluation, synthetic primitive-first curricula could replace expensive geometric labeling for the foundational layer of spatial reasoning in LVLMs.
Source: https://arxiv.org/abs/2609.07064
EvoSafeHarness: Evolving Model- and Domain-Specific Harnesses for Securing Agents
Problem
Tool-using LLM agents need a defense layer outside the model itself: a harness that mediates prompts, tool calls, and returned observations, blocking both direct harmful requests and indirect prompt injections carried in retrieved content. Existing harnesses (CaMeL, DRIFT, Progent, and similar) are hand-designed once by experts and applied uniformly, but the required enforcement is deployment-dependent along two axes. First, victims vary enormously in baseline risk: on DTAP, undefended ASR ranges from 4.8\% (Sonnet 4.6) to 71.0\% (DeepSeek-V4-Flash). A harness tuned for a fragile model over-blocks a robust one; a harness tuned for a robust model leaks on a fragile one. Second, domains encode different safety relations. In an OS-filesystem domain, harmful actions typically call out-of-scope tools (rm, exfiltration), so tool-taxonomy defenses like CaMeL and DRIFT catch them. In telecom, harmful actions use the same in-scope customer-service tools as benign ones, so those defenses collapse: CaMeL and DRIFT reduce telecom ASR essentially not at all relative to no-defense.
Method
EvoSafeHarness formulates harness construction as a program-search problem over a joint natural-language policy P and executable code logic C, conditioned on a frozen victim model M and a domain specification. The agent is a pair (M, H) where H is an ordered pipeline: system-message assembly, model call, tool execution, observation return, looped until finalization. The no-defense harness H_0 is the bare loop; any defense modifies H_0.
The domain specification acts as a task contract for a Designer LLM. It fixes the victim, tools, judges, threat semantics (what runtime context is trusted under direct vs. indirect threats), the train-only evaluation cascade, and the adapter through which defenses may act. On DTAP the adapter is a Python Defense object exposing system_prompt_transform, on_pre_tool_call, and on_post_tool_call, plus arbitrary helper code and per-trace state. On AgentDojo, candidates are pipeline elements composed around the fixed agent loop. Neither P nor C is subdivided into a required taxonomy — the interception surface is open.
The search loop (Algorithm 1 in the paper) has four components:
- Warm-start distillation of prior expert designs into the archive (experience, not templates).
- Designer conditions on archive entries (source, scores, victim failure traces) and proposes a new (P, C) program.
- Criticizer with a fresh context attacks the proposal using benchmark-independent evasions, forcing rejection of rules that only pattern-match the training suite.
- Cascade Test Environment stages benign-utility, direct-attack, and indirect-attack evaluation with cheap-to-expensive admission, so unpromising candidates are killed early.
Holding the request, injection, and domain fixed, the enforcement stack the Designer converges on depends on the victim. For a covert-copy injection, the Sonnet 4.6 harness uses a provenance reminder plus two semantic checks; the GLM-5 harness adds deterministic command/location/secret filters and a semantic scope judge on top. This is the mechanical manifestation of the “models differ in enforcement need” claim.
Results
Table 1 in the paper reports the 15-cell DTAP grid: 5 victims × 3 domains (os-fs, finance, telecom), each cell scored on 30 benign, 35 direct-attack, and 35 indirect-attack tasks. Averaged across the grid:
- No-Defense: Util 83.1, ASR 45.6\% (direct 50.9 / indirect 40.4).
- CaMeL: 69.7 / 37.7\%.
- DRIFT: 77.1 / 42.4\%.
- Progent: 56.4 / 10.5\% — strong safety, heavy utility cost.
- EvoSafeHarness: 79.8 / 10.0\%.
EvoSafeHarness matches Progent’s safety while giving up ~23 utility points less. The per-victim story is sharper. On Kimi-K2.5 the undefended ASR is 55.3\%; EvoSafeHarness drives it to 10.5\% at 77.8 utility, while Progent reaches 11.4\% ASR but only 44.4 utility. On Qwen3.7-plus, undefended 57.6\% \to 8.5\% ASR at 78.9 utility (Progent: 11.0\% at 60.0). On the hardest cell, DeepSeek-V4-Flash, undefended ASR is 71.0\% and EvoSafeHarness reduces it to 21.9\% while retaining 82.2 utility.
The domain axis is equally clear. On telecom, where in-scope tool taxonomies fail, CaMeL averages 45.0\% ASR and DRIFT 43.6\% across victims — essentially the no-defense rate (42.6\%) — while EvoSafeHarness reaches 2.0\% ASR at 78.6 utility.
What the search actually learns
Section 7 traces concrete lineages. In Qwen/finance, the searched harness stops trying to detect malicious spans in mixed content and instead enforces a closed-world authorization relation at the action boundary: the trusted Slack instruction authorizes buy 45 CRM, so an emitted trade_stock(action=sell, symbol=CRM, quantity=45) is rejected on side-mismatch alone, independent of where the injection originated. The Kimi/finance lineage generalizes this to trajectories: liquidation and fund-out state are tracked, and whichever action completes the two-leg pattern is refused. An early one-way rule was flagged by the Criticizer as evadable by reversing order, so the final coupling is order-independent — a demonstrably useful role for fresh-context adversarial review.
Limitations and open questions
The evaluation cascade is train-only and per-cell searched, so per-deployment search cost is real (the paper defers aggregate ledgers to Appendix G). Guarantees are empirical; the closed-world authorization relations depend on a well-specified trusted task boundary, which not all domains cleanly provide. Transfer beyond the AgentDojo → AgentDyn hop is untested. And because Progent already reaches comparable ASR at lower utility, the frontier gain — not any absolute safety guarantee — is what is being claimed.
Why this matters
The result reframes agent safety as a per-deployment program-synthesis problem rather than a universal defense-architecture problem: victims and domains vary enough that fixed harnesses sit strictly inside the achievable safety–utility frontier. The concrete design pattern the search recovers — action-boundary authorization checks against the trusted task, extended to trajectory-level compositions — is a re-implementable primitive independent of the search machinery.
Source: https://arxiv.org/abs/2609.05903
Hacker News Signals
Python sets and dictionaries can have quadratic-time performance
Python’s dict and set use open-addressing hash tables with a probe sequence derived from the hash value. The standard assumption is O(1) amortized insert and lookup, but Lemire’s post demonstrates a concrete adversarial input construction that degrades a sequence of N operations to O(N²) total time.
The mechanism: Python’s probe sequence for collision resolution uses a perturbation-based recurrence. If an attacker (or unlucky data distribution) produces keys whose hashes all map to the same initial slot modulo the table size, every insertion must walk the full probe chain. Because Python’s hash for integers is the integer itself (modulo a small perturbation), constructing such a set is trivial — pick multiples of the table capacity. For strings, hash randomization (enabled by default since Python 3.3 via PYTHONHASHSEED) mitigates deliberate attacks but does not eliminate worst-case behavior from naturally colliding data.
The quadratic blowup comes from the interaction between the load factor threshold and the probe chain length. Before a resize, the table is up to 2/3 full. An insert into a fully colliding bucket must scan O(N) slots, and if this happens for O(N) insertions before a resize triggers, you get O(N²) total probes. After resize the collision structure can reconstitute itself if the hash distribution is adversarial relative to the new capacity.
Practical mitigations: use a keyed hash function (e.g., siphash with a secret), pre-size dicts to avoid operating near the load factor limit, or use sorted structures when key distributions are suspect. CPython 3.6+ has a more cache-friendly compact dict layout, but this does not change the asymptotic worst case — it only improves constants.
The broader point is that hash table worst-case behavior is not merely theoretical; it has been exploited in HTTP parameter DoS attacks against PHP and Perl, and Python is not immune by construction.
Source: https://lemire.me/blog/2026/09/03/python-sets-and-dictionaries-can-have-quadratic-time-performance/
Cognition launches new SWE-2 model, Rivaling Fable 5.1 and GPT-Astra
Cognition’s SWE-2 is a code-focused model positioned as a software engineering agent rather than a pure completion engine. The announcement claims competitive performance with Fable 5.1 and GPT-Astra on SWE-bench Verified, the standard benchmark for autonomous GitHub issue resolution.
The mechanically interesting claims: SWE-2 is trained with a pipeline that emphasizes long-horizon execution traces rather than short snippet completion. Cognition describes a data flywheel where Devin (their agent product) generates execution trajectories — tool calls, shell commands, file edits, test runs — which are filtered by outcome and used as training signal. This is a form of online RL from execution feedback, analogous to STaR/ReST but applied to multi-step agentic tasks rather than single-step reasoning.
The model reportedly improves on multi-file edits and recovering from failed test runs — both require maintaining coherent state across a long context window and correctly attributing errors to specific earlier decisions. These are harder than single-file patch generation because the search space over edit sequences grows combinatorially.
No architectural details are disclosed. The benchmark numbers put SWE-2 in the range of 50-60% on SWE-bench Verified (exact figures not published at time of writing), which is meaningful progress given that GPT-4-level models sat around 18% a year prior.
Key open questions: SWE-bench Verified is still a narrow distribution (GitHub issues from a fixed repo set). Generalization to internal enterprise codebases with proprietary APIs, undocumented conventions, and sparse test coverage remains unvalidated. The trajectory-filtering approach also raises a distributional question — training on successful Devin traces may overfit to Devin’s own action vocabulary rather than learning generalizable repair strategies.
Source: https://cognition.com/blog/swe-2
Neki – Sharded Postgres
PlanetScale’s Neki is a sharding layer that sits in front of standard PostgreSQL instances and presents a unified Postgres-wire-protocol endpoint to applications. The goal is horizontal write scaling without requiring application-level shard awareness or a custom storage engine.
The core architecture: Neki intercepts queries at the protocol level, parses SQL, identifies the sharding key from a schema-level annotation, and routes individual statements to the appropriate shard. Transactions that touch a single shard are forwarded directly; cross-shard transactions are handled via a two-phase commit coordinator embedded in the proxy. The proxy layer is stateless and horizontally scalable.
The distinguishing design choices relative to alternatives like Citus or Vitess:
- Citus runs inside Postgres as an extension, giving it access to the query planner but binding it to a single Postgres major version lifecycle. Neki is external, so it works with any Postgres version and managed services (RDS, Aurora, Cloud SQL).
- Vitess was built for MySQL and carries significant MySQL-specific assumptions. Neki targets Postgres natively, including proper handling of Postgres-specific types, array operators, and
RETURNINGclauses. - Unlike Neon or Aurora, Neki does not touch the storage layer — each shard is a fully independent Postgres instance with its own WAL and storage.
Limitations are significant and honestly stated: queries that require cross-shard aggregation (JOINs across shard boundaries, global ORDER BY ... LIMIT) require scatter-gather execution in the proxy, which serializes results and can be slow. Schema migrations must be applied to all shards, which Neki automates but which still creates operational complexity. Foreign key constraints across shard boundaries cannot be enforced at the database level.
The design is pragmatic for workloads where a clear sharding key exists and cross-shard queries are rare — typical for multi-tenant SaaS.
Source: https://planetscale.com/blog/introducing-neki
What happens when a GPU writes memory
This post traces the full hardware path of a GPU store operation from a CUDA thread through the memory subsystem to DRAM, with enough specificity to be useful for performance debugging.
The path on a modern NVIDIA GPU (Hopper/Ampere class): a store instruction in a CUDA thread issues from a CUDA core into the L1 data cache (per-SM). The L1 is write-through or write-back depending on cache policy decorators (.cs, .wb, .cg, .ca in PTX). From L1, dirty lines propagate to the L2 cache, which is shared across all SMs and partitioned across memory controllers. The L2 is write-back. Evictions from L2 go to HBM via the memory controller, which handles DRAM burst scheduling.
The non-obvious complications the post covers:
- Weak memory model: CUDA follows a relaxed consistency model. Stores are not globally visible until a
__threadfence()(or stronger barrier) is issued. Without this, other SMs may read stale values from their L1/L2. - Cache line granularity: the GPU L1 operates on 128-byte sectors. A warp writing 32 threads × 4 bytes = 128 bytes to a contiguous address range will generate one sector write. Non-coalesced writes generate multiple sector transactions, multiplying bandwidth consumption.
- Atomics: atomic operations (e.g.,
atomicAdd) bypass L1 entirely on some architectures and go directly to L2 or to dedicated atomic units, which is why atomics show different latency profiles than regular stores. - Peer access (NVLink/PCIe): stores to memory on a remote GPU traverse the NVLink fabric with additional latency and require explicit memory ordering to be coherent.
Understanding this path is essential for diagnosing performance cliffs in kernels where expected memory bandwidth is not achieved.
Source: https://blog.doubleword.ai/what-happens-when-a-gpu-writes-memory
Samsung Debuts zHBM Prototype, Stacking Memory Directly on AI Accelerators
Samsung’s zHBM (zero-distance HBM) prototype eliminates the silicon interposer normally required to connect HBM stacks to an accelerator die. Standard HBM packaging places memory stacks and the compute die side-by-side on a passive interposer (e.g., CoWoS from TSMC), connected via thousands of microbumps. The interposer adds area, cost, and a non-trivial electrical path with associated latency and power overhead.
zHBM stacks the HBM DRAM dice directly on top of the logic die using die-to-die bonding — conceptually similar to TSMC’s SoIC or Intel’s Foveros, but applied specifically to the accelerator-plus-HBM configuration. The prototype reportedly achieves over 1.2 TB/s of memory bandwidth, compared to ~3.35 TB/s for HBM3E in conventional packaging (per stack, with 8-high stacks). The bandwidth figure alone is not the headline — the gain is in bandwidth-per-watt and bandwidth-per-mm², because the TSV (through-silicon via) connections between stacked dice are shorter and denser than interposer traces.
The relevant implication for AI accelerators: memory bandwidth is the primary bottleneck for transformer inference at large batch sizes and for training with large weight tensors. Reducing the physical distance between compute and memory reduces both latency and the energy cost per bit transferred — memory accesses in current systems consume a disproportionate fraction of total accelerator power (often cited as 30-50%).
Technical challenges not resolved by the prototype: thermal management is severe when a hot compute die is directly beneath a DRAM stack (DRAM is sensitive to temperature for retention and refresh timing). Yield impacts from stacking also remain a manufacturing concern.
This is an early prototype, not a shipping product, but the direction is clear for post-2027 AI chip roadmaps.
Source: https://www.thelec.net/news/articleView.html?idxno=12835
Rust is tier-1 language at Microsoft
Microsoft’s Rust Foundation guest post formalizes what has been practiced informally for several years: Rust is now a tier-1 supported language across Microsoft engineering organizations, meaning it receives the same toolchain investment, internal library support, security review processes, and hiring pipeline consideration as C++ and C#.
The technical motivation is straightforward. Microsoft estimates that approximately 70% of CVEs in its products over the past decade traced to memory safety issues — use-after-free, buffer overflows, type confusion. C++ provides no language-level guarantees against these. Rust’s ownership and borrow checker enforce memory safety at compile time with zero runtime cost, making it the only systems language that eliminates this vulnerability class by construction rather than by tooling (e.g., ASAN, sanitizers) or runtime overhead (e.g., garbage collection, bounds-checking everywhere).
Concrete Microsoft projects already using Rust: the Windows kernel has Rust components (announced 2023), Azure’s hypervisor infrastructure includes Rust modules, and portions of the M365 backend have been rewritten in Rust. The tier-1 designation means internal projects are now actively encouraged (not merely permitted) to choose Rust for new systems code.
The engineering implications: tier-1 status triggers internal investment in Rust-to-C++ interop tooling (critical given Microsoft’s enormous existing C++ codebase), Rust bindings for internal platform APIs, and internal training pipelines. The interop story remains the hardest problem — cxx, bindgen, and similar tools work but require careful design to avoid unsafety leaking across the FFI boundary.
The broader industry signal: with Google (Android, Chromium), Linux kernel, and now Microsoft all at tier-1 Rust adoption, C++ is losing ground in greenfield systems work. The question is migration velocity for existing codebases, which is slow by necessity.
Source: https://rustfoundation.org/media/guest-post-rust-is-tier-1-language-at-microsoft/
Detecting and countering misuse of AI: September 2026
Anthropic’s September 2026 threat intelligence report is a public accounting of observed misuse patterns against Claude and their countermeasures. The report is notable for being operationally specific rather than abstractly policy-oriented.
Key findings reported:
CBRN uplift attempts: Anthropic describes continued attempts to extract synthesis routes for chemical and biological agents. The report claims Claude’s refusal rate on these queries exceeds 99.9% after Constitutional AI and RLHF layers, but acknowledges that fine-tuned open-weight models are used as fallbacks when Claude refuses — indicating that Claude refusals successfully route traffic to less-safe alternatives, which is a partial win at best.
Influence operations: Automated persona generation for coordinated inauthentic behavior (fake social media accounts, synthetic commentary) is the most volumetrically significant misuse category. Anthropic identifies linguistic fingerprinting — subtle stylistic regularities in LLM-generated text — as the primary detection signal, and notes an arms race where adversaries increasingly post-process outputs to remove these markers.
Agentic misuse: A newer category involves using Claude’s API inside automated pipelines to conduct reconnaissance (scraping, enumeration) at scale rather than using it for content generation. These cases are harder to detect because individual API calls are innocuous; the pattern only becomes visible at the account or session level.
Countermeasures disclosed: classifier-based abuse detection operating on API usage patterns (not just content), rate limiting triggered by behavioral signals rather than volume alone, and coordinated reporting with other AI labs under an informal threat-sharing arrangement.
The structural limitation of any such report: adversaries read it and adapt. Publishing detection methodology has a short half-life.
Source: https://www.anthropic.com/threat-intelligence-report-september-2026
How GPT-5.6 Sol helps run quantum computing experiments
OpenAI describes a deployment of GPT-5.6 Sol (the “Codex” successor for scientific computing) as an assistant for quantum computing researchers, specifically for experiment design, circuit generation, and results interpretation in a lab setting.
The technically interesting claim is not the model capability per se but the integration architecture. The system connects to lab instruments via a tool-use layer: the model can invoke a quantum circuit simulator, query a calibration database for device parameters (qubit frequencies, gate fidelities, coherence times), submit jobs to a real QPU via a REST API, and parse returned result histograms. This is an agentic loop where the model issues tool calls, observes results, and iterates — analogous to AlphaCode’s execution feedback loop but in a physical lab context.
Specific use cases described: the model drafts OpenQASM or Qiskit circuit definitions from a natural language description of a target unitary, checks them against current device topology (connectivity constraints, native gate set), estimates expected fidelity given current calibration data, and suggests error mitigation strategies (e.g., zero-noise extrapolation, Pauli twirling) appropriate for the circuit depth.
The bottleneck identified honestly in the post: the model does not have reliable physical intuition about noise channels. It can apply textbook error mitigation techniques correctly but does not infer novel mitigation strategies from first principles. For routine experiment automation this is acceptable; for research pushing the frontier of error correction it is insufficient.
The broader pattern this represents — LLMs as orchestrators of domain-specific scientific toolchains rather than as end-to-end reasoners — is more robust than asking the model to do physics from scratch, and is likely the correct architecture for near-term scientific AI assistance.
Source: https://openai.com/index/codex-quantum-computing-experiments/
Noteworthy New Repositories
only-cli/oc
A command-line tool that transforms arbitrary websites into token-efficient representations suitable for AI agent consumption. Instead of feeding a raw HTML DOM — which can run to tens of thousands of tokens — oc fetches a page, strips presentation markup, and emits a structured, minimal text rendering. The design target is agentic loops where a language model needs to browse repeatedly: reducing per-page token cost from ~20–50k down to hundreds changes what is economically feasible in a tool-call budget.
Technically, it pipelines HTTP fetch, DOM parsing, and a content-extraction pass (similar in spirit to Mozilla Readability but CLI-native) into a single binary. Output is plain text or JSON, making it trivially pipeable to any LLM API call. Configuration lets you specify CSS selectors to include or exclude, so agents can be pointed at structured sub-sections of a page rather than the full document. The tool is stateless — no session persistence — which keeps it simple but means multi-step navigation (login flows, pagination) requires external orchestration. A natural next step would be integrating a cookie/session store for authenticated scraping use cases.
Source: https://github.com/only-cli/oc
furkankly/zoetrope
Zoetrope provides real-time visual inspection of Claude Code and OpenAI Codex agent sessions, rendering the agent’s execution as a live directed acyclic graph in either a terminal TUI or a browser-based view. Each node in the graph corresponds to a tool call or reasoning step; edges encode causal dependency. As the session progresses, nodes appear and edges are drawn incrementally, giving the operator a structural read on what the agent is actually doing rather than scrolling through a wall of log text.
The implementation hooks into the event streams that both Claude Code and Codex emit (tool call start/end, message deltas) and maps them into a graph data structure that is then rendered via a layout algorithm suitable for DAGs. The terminal renderer uses a TUI library; the browser version likely serializes the same graph over a local WebSocket. The utility here is primarily debugging: it becomes immediately obvious when an agent enters a retry loop, when tool calls fan out unexpectedly wide, or when a subagent chain is deeper than intended. This kind of structural visibility is absent from the default streaming logs both products emit, and having it without instrumenting your own code is the core value proposition.
Source: https://github.com/furkankly/zoetrope
sodiumsun/agenttrail
AgentTrail is a local observability stack for AI coding agents with two distinct views. The Map component tracks filesystem activity — which files were read, written, or created — overlaid on the project’s directory structure, giving a spatial sense of what the agent touched during a session. The Kitchen component renders tasks and role contributions in a 3D visualization, which targets multi-agent scenarios where different roles (planner, coder, reviewer) contribute distinct work streams.
The local-only design is a deliberate architectural choice: all telemetry stays on the developer’s machine, which matters for proprietary codebases. The agent activity data is collected by intercepting file-system events and correlating them with agent session metadata rather than requiring SDK-level instrumentation. The 3D Kitchen view appears to use a WebGL-based renderer, making it browser-hosted but served from localhost. The main limitation is that the correlation between “agent role” and file events depends on the agent framework exposing role metadata in its logs; for raw API usage the attribution will be coarser. Still, the file-system activity map alone is useful for auditing what an agentic session actually modified versus what it claimed to modify.
Source: https://github.com/sodiumsun/agenttrail
soumatheusgomes/vibe-coding-toolkit
A curated operational toolkit extracted from production use of Claude Code, focusing on the parts that are underspecified in official documentation: subagent orchestration patterns, quality gate configuration, and a library of copy-paste prompts for recurring tasks. The Claude Code plugin configurations cover things like custom slash commands, tool permission tuning, and context injection strategies. The subagent orchestration section documents patterns for decomposing tasks across multiple agent invocations while maintaining coherent context — a practical concern when a task exceeds a single context window or benefits from parallelism.
Quality gates are perhaps the most directly reusable component: pre-commit and CI hook configurations that run linting, type-checking, and test suites as checkpoints that agent-generated code must pass before being accepted, enforcing correctness constraints that purely conversational evaluation misses. The prompt library is organized by task category (refactoring, test generation, documentation) with notes on what prompt variations work for different code structures. The repo is opinionated and reflects a specific production workflow, so users will need to adapt rather than adopt wholesale, but the specificity is the point — generic advice is already abundant.
Source: https://github.com/soumatheusgomes/vibe-coding-toolkit
Player-YN/PawWork_ZhuaZhua
A Chrome extension implementing a selection-first web agent interaction model. The user selects an element or region directly on the live page, describes the desired outcome in natural language, and the agent executes the task and returns an editable Office-format file (Word, Excel, or similar). The selection-first UX inverts the typical agent flow: instead of describing where to look and then having the agent navigate, the user grounds the task spatially first, which reduces ambiguity and shrinks the action space the model needs to reason over.
The bring-your-own-key (BYOK) design routes LLM calls directly from the browser to the provider API — no intermediate server. Execution is sandboxed within the extension’s content script context, which limits what the agent can do outside the current page but also means no server-side data retention. The output as an editable document rather than a screenshot or plain text is a practical choice: it produces something immediately actionable. The 2,500+ star count suggests the interaction paradigm resonates. The main open question is how well the spatial grounding via DOM selection translates to complex multi-step tasks that require navigating away from the selected page.
Source: https://github.com/Player-YN/PawWork_ZhuaZhua
DSH-APP/DSHA
A no-root, no-Termux Android environment for running DeepSeek inference locally on a phone. It ships a complete Ubuntu userland via proot — a user-space chroot implementation that avoids the ptrace overhead typically associated with QEMU-based emulation — so the environment is closer to native Linux performance than alternatives like UserLAnd. The toolchain includes the DeepSeek Harness for model evaluation and inference, with output streamed to the display in real time.
The proot approach means no kernel modifications and no elevated privileges, which makes installation viable on unrooted consumer hardware. ADB (Android Debug Bridge) direct connection is supported for developers who prefer to interact from a desktop terminal rather than on-device. The persistent data guarantee (data does not disappear across sessions) is a meaningful improvement over some Termux-based setups where the environment can become inconsistent after Android kills background processes. The primary constraint is hardware: running a meaningful DeepSeek variant requires a device with sufficient RAM (likely 8–16 GB minimum for smaller quantized versions), which restricts the target audience to mid-to-high-end phones.
Source: https://github.com/DSH-APP/DSHA
Colafornia/short-video-generator-AI
An end-to-end pipeline for converting long-form YouTube videos into short-form clips suitable for platforms like TikTok or Reels. The pipeline chains four distinct processing stages: highlight detection (identifying segments with high engagement potential, likely via a combination of audio energy, speech features, or a fine-tuned classifier), subtitle generation (via Whisper or equivalent ASR), translation (for multilingual output), and voiceover synthesis. Each stage is implemented as a separable module, so users can substitute components — e.g., swap the ASR backend or use a different TTS engine.
The open-source, self-hosted design is the main differentiator from commercial tools in this space: no per-minute fees, no data leaving the user’s infrastructure. The highlight detection quality is the most technically interesting and also the most variable part — the repo’s approach here will determine whether the output is genuinely useful or requires heavy manual curation. The subtitle and translation pipeline benefits from mature open-source tooling (Whisper, various MT models), so those stages are likely to be more reliable. A known limitation of this class of tool is that “viral” is poorly defined and highlight detection is effectively a proxy task.
Source: https://github.com/Colafornia/short-video-generator-AI
yudaprasetya007/routeVSCODE
A local reverse proxy that intercepts VSCode Copilot Chat’s outbound API requests and rewrites them on the fly to target a different model backend, enabling zero-reload model switching without modifying the Copilot extension itself. The proxy listens on a configurable local port, and Copilot is pointed at it via the extension’s API endpoint setting. When a model switch is requested, the proxy updates its routing table without requiring a VSCode window reload — the extension remains active and session context is preserved.
This is useful in scenarios where you want to compare responses from different backends (e.g., GPT-4o vs. a locally hosted model via Ollama) without managing multiple extension configurations or restarting the editor. The “9Router” designation suggests the proxy supports routing across multiple backend definitions simultaneously. The implementation is straightforward: HTTP/HTTPS interception, header and URL rewriting, and a lightweight control interface for switching routes. The main security consideration is that the proxy holds API keys for all configured backends; running it on localhost with no authentication is acceptable for a single-user dev machine but not for shared environments.