Daily AI Digest — 2026-06-30
arXiv Highlights
Scaling the Horizon, Not the Parameters: Reaching Trillion-Parameter Performance with a 35B Agent
Problem
Frontier agentic capability has been pursued primarily by scaling parameter count: Kimi-K2.6 and DeepSeek-V4-pro sit at the trillion-parameter scale to handle long-horizon tool use, deep research, and engineering tasks. Agents-A1 argues the relevant scaling axis is the horizon — trajectory length and the heterogeneity of agentic abilities exercised within those trajectories — not raw parameters. The paper instantiates this with a 35B Mixture-of-Experts model (3B active) derived from Qwen3.5-35B-A3B and claims parity with or superiority to 1T-class baselines on long-horizon search, scientific reasoning, and engineering benchmarks.
Method
The pipeline has three stages built on top of a knowledge-action infrastructure (Figure 3).
Knowledge-Action Graph (KAG). For each domain d, the authors define a tuple \mathcal{G}_d = (\mathcal{C}_d, \mathcal{A}_d, \mathcal{O}_d, \mathcal{V}_d): corpus, admissible actions, observations, and verifier. In the search instantiation, \mathcal{C}_d is a wiki corpus with paragraph-level evidence, \mathcal{A}_d is the set of hyperlink-induced entity transitions on the corpus graph, \mathcal{O}_d is retrieved page text, and \mathcal{V}_d checks whether the answer entity and supporting path are recoverable. Trajectories are generated by controlled random walks: an LLM selector chooses the next entity from filtered outgoing anchors (disambiguation pages, near-duplicate titles, and low-degree nodes are removed). The terminal entity becomes the answer, the chain is rewritten into a natural-language question with proper nouns masked, and a verifier validates answer-and-evidence consistency. Real-Internet trajectories are then collected by strong models equipped with search (top-50 results), read_page (LLM-summarized extraction), and code (Python sandbox), under a 256K-token context. Failed and obviously-guessing trajectories are filtered; turn-limit truncations are rolled back one turn and forced to answer.
This KAG-driven generation yields ~100K trajectories with an average length of 45K tokens (deep research 44K, coding/engineering 48K, scientific 37K, agentic 39K, instruction-following 3K).
Stage 1 — Full-domain SFT. Cross-entropy on response tokens only, masking instruction tokens, on the packed 131,072-token sequences. AdamW, lr 1\times 10^{-5}, cosine schedule with 0.05 warmup, weight decay 0.1, batch size 16, one epoch. Sample packing with intra-sequence attention masks suppresses cross-contamination and recovers GPU utilization.
Stage 2 — Domain teachers. Specialist teachers are trained per domain via targeted SFT or RL, each capturing one capability cluster (deep research, coding/engineering, scientific reasoning, instruction following, agentic tool use, long-context).
Stage 3 — Multi-teacher domain-routed on-policy distillation (OPD). The student rolls out on-policy; a router assigns each rollout to its domain teacher, and gradients flow from a salient-vocabulary-aligned distillation objective. Salient vocabulary alignment restricts KL matching to a teacher-selected token subset, mitigating tokenizer-level noise and the destructive averaging that uniform multi-teacher distillation typically produces.
Results
Evaluation spans search (GAIA, BrowseComp, XBench-DeepResearch, SEAL-0), engineering (SciCode 288 subproblems, MLE-Bench-Lite 22 Kaggle competitions, 12-hour H200 budget per task, three seeds), scientific reasoning (HLE-with-tools, HiPhO over 13 competitions, FS-O, FS-R), and long-context/IF (LongBench V2 over 503 MCQs at 128K truncation, IFBench, IFEval). Search agents run with up to 300 turns and pass@1 with each benchmark’s official judge.
The paper reports leading results against Kimi-K2.6 and DeepSeek-V4-pro despite a 30× gap in total parameters (35B vs ~1T) and roughly 300× gap in active parameters (3B vs hundreds of billions). The headline claim is that horizon scaling — 45K-token average trajectory length, six unified domains, KAG-grounded process supervision — substitutes for parameter scaling on tasks where the bottleneck is procedural competence rather than world knowledge.
Limitations and open questions
- The submission does not isolate how much of the gain comes from (i) KAG-curated SFT data, (ii) specialist teachers, or (iii) salient-vocabulary OPD; without ablations on each stage the contribution of multi-teacher distillation versus simply training longer on KAG data is unclear.
- Tool-augmented evaluation for Agents-A1 versus tool-free evaluation for some baselines on HiPhO/FS-O/FS-R is acknowledged but confounds the comparison. A symmetric tool-augmented run on the 1T baselines would tighten the claim.
- The arxiv ID format and the references to “Qwen3.5-35B-A3B”, “Kimi-K2.6”, and “DeepSeek-V4-pro” suggest this is a forward-dated or synthetic preprint; readers should verify provenance before citing.
- MLE-Bench-Lite at 12 wall-clock hours per task on a single H200 makes statistical-significance claims over 22 competitions × 3 seeds non-trivial; variance bands are not provided in the section excerpts.
- The KAG construction is heavily engineered for the search domain (hyperlink walks, anchor filtering); generalization of the same evidence-and-verifier schema to scientific research and engineering domains is asserted but the verifier design for, e.g., MLE tasks is not detailed in the surfaced sections.
Why this matters
If horizon scaling genuinely substitutes for parameter scaling on agentic workloads, the deployment economics of long-horizon agents change substantially: a 3B-active MoE with KAG-grounded trajectories and routed distillation could replace 1T-class systems for tool-use-heavy tasks. The methodological contribution — a verifier-bearing knowledge-action graph plus salient-vocabulary multi-teacher OPD — is a reusable recipe for building smaller specialist-consolidated agents.
Source: https://arxiv.org/abs/2606.30616
AsyncOPD: How Stale Can On-Policy Distillation Be?
On-policy distillation (OPD) trains a student LLM on its own rollouts with teacher feedback supplied through a local KL loss. As OPD migrates from toy settings into reasoning-scale post-training, its rollout stage dominates wall-clock just as it does in RL, making asynchronous pipelines (decoupled rollout, teacher scoring, learner updates) attractive. The cost is policy staleness: by the time the learner consumes a sample, the rollout student p_{\mathrm{old}}, the cached teacher-scored support, and the current student p_\theta may all differ. This paper is the first systematic study of how that staleness interacts with the OPD-specific design choices — KL direction and the finite teacher-score cache — and proposes AsyncOPD, a streaming asynchronous system.
Setup and the cache constraint
Full-vocabulary teacher logits would permit a dense KL, but caching and shipping |V|-dimensional distributions per token across an asynchronous pipeline is prohibitive. The authors restrict to two practical caches: sparse top-k teacher logits, and one-sample Monte Carlo scores. The pipeline has three temporally separated stages — rollout selects prefixes and actions, teacher scoring annotates them, and the learner later updates the student — so prefix-level staleness is fixed at rollout time. Only action-level staleness is addressable by estimator design, which is what they focus on.
KL direction governs staleness sensitivity
The first result is structural: forward KL \mathrm{KL}(q\Vert p_\theta) is teacher-weighted, so the expectation lives on the teacher’s support. Cached top-k teacher actions are exactly the right support, and staleness only affects which prefixes were visited, not the action set. Reverse KL \mathrm{KL}(p_\theta\Vert q) is student-weighted: the relevant support is S_\theta(s) = \mathrm{TopK}(p_\theta(\cdot\mid s),k), but the cache holds S_{\mathrm{old}}(s) = \mathrm{TopK}(p_{\mathrm{old}}(\cdot\mid s),k). Actions newly promoted into S_\theta have no teacher score, and no importance reweighting confined to S_{\mathrm{old}} can recover them. Reverse-KL OPD is therefore the regime where staleness genuinely hurts.
Policy-gradient surrogates for reverse KL
Given that reverse KL is the hard case, the authors examine which RL-style stabilizers transfer. A mechanical PPO adaptation takes the behavior policy to be p_{\mathrm{old}}, fixes the advantage at rollout time as
A_{\mathrm{old}}(a,s) = \log q(a\mid s) - \log p_{\mathrm{old}}(a\mid s),
and applies the clipped old-to-current ratio. The alternative is A_\theta(a,s) = \log q(a\mid s) - \log p_\theta(a\mid s), recomputed under the current student. Empirically, A_\theta without clipping is the more stable choice: it tracks the current reverse-KL objective and, crucially, suppresses the heavy upper tail of the importance ratio \rho_\theta = p_\theta/p_{\mathrm{old}} that destabilizes unclipped PPO surrogates. The p99 of \rho_\theta is substantially reduced relative to the A_{\mathrm{old}} variant under the same no-clip setting.
The reading is that clipping in standard PPO is partly compensating for an advantage computed under a stale policy; recomputing the advantage under p_\theta removes much of the need for clipping in the OPD case, where rewards are dense KL signals rather than sparse returns.
Cached supports
Even with A_\theta fixed as the reference surrogate, the cache-support question remains. Sparse top-k on S_{\mathrm{old}} is a biased, support-mismatched estimator of the current reverse-KL objective; the bias grows with staleness as S_\theta drifts away from S_{\mathrm{old}}. One-sample MC is unbiased on the rollout support but high-variance. The paper’s prescription is to keep A_\theta unclipped together with a sparse cache that is refreshed often enough that S_{\mathrm{old}} remains a reasonable proxy for S_\theta — converting the staleness budget into a scheduling parameter rather than an estimator hack.
AsyncOPD system
The system contribution is a fully asynchronous pipeline that overlaps rollout, teacher scoring, and learner updates in the style of AReaL. The contrast is with the step-off scheduler from VeRL, which fixes rollout lag to k learner updates but still waits for complete rollout batches before releasing them downstream. AsyncOPD instead streams: workers only pause for weight sync, in-flight prefixes are preserved across syncs, teacher scoring consumes completed items as they arrive, and the learner steps as soon as a scored batch is ready. This removes the long-tail wait caused by stragglers in batch-gated schedulers.
Limitations and open questions
The analysis is confined to local KL feedback; OPD variants that use teacher value functions or denser process rewards are not covered. Prefix-level staleness is acknowledged but explicitly left to scheduler design rather than estimator design, so the prefix-distribution shift induced by very aggressive asynchrony is not bounded theoretically. The cache-refresh frequency that keeps sparse top-k a faithful proxy of S_\theta is treated empirically. Finally, the headline asymmetry — forward KL is robust, reverse KL is fragile — sharpens a known tradeoff (mode-covering vs. mode-seeking) but does not by itself say which objective produces better downstream reasoning students under fixed compute.
Why this matters
OPD inherits RL’s rollout bottleneck, and the obvious fix — asynchrony — interacts with the KL direction and teacher cache in non-obvious ways. Identifying A_\theta without clipping plus a streaming scheduler as the workable recipe for the vulnerable reverse-KL regime gives a concrete blueprint for scaling on-policy distillation post-training without abandoning the reverse-KL objective that many practitioners prefer.
Source: https://arxiv.org/abs/2606.24143
TACO: Tool-Augmented Credit Optimization for Agentic Tool Use
Problem
Code-tool visual agents — models that issue Python code to crop/zoom an image, observe the result, and reason further — are now a dominant paradigm for fine-grained visual question answering. The catch is that tool calls are heterogeneous in value: a crop can disambiguate small text, leave the answer unchanged, or actively mislead by removing context (see Figure 1).
Outcome-only RL (e.g., vanilla GRPO with a string-match reward) cannot distinguish these regimes: a trajectory with a misleading crop that the model recovers from gets the same +1 as one whose crop was actually informative, so gradients reinforce both equally. Existing process-reward schemes either need an external judge model (expensive, gameable) or fail to localize credit to individual code calls. TACO targets exactly this per-call credit assignment problem without introducing an auxiliary judge.
Method
TACO is a GRPO variant with two coupled advantage channels (Figure 2).
Setting. A trajectory factorizes into pre-tool reasoning \mathcal{T}_1 producing a tentative answer a_1, a code segment \mathcal{C} that executes in a sandbox and returns an image observation \mathrm{IMG}, and post-tool reasoning \mathcal{T}_2 producing the final answer a_f. The verifiable outcome reward is r_{\mathrm{out}}(\cdot)\in\{-1,0,+1\} from rule-based answer checking.
Differential Answer-Probe Reward (DAPR). Probe tokens inserted at the boundary of \mathcal{T}_1 and again after \mathcal{T}_2 elicit the model’s best answer with and without having seen the tool result. The per-call value is the difference in outcome reward:
\Delta = r_{\mathrm{out}}(a_f) - r_{\mathrm{out}}(a_1).
This is positive for a useful call, negative for a misleading one, and zero for a no-op. Because it is a difference of the same rule-based checker, not an absolute scalar from a learned probe, it inherits the verifier’s robustness and is naturally resistant to probe-hacking — the model cannot inflate \Delta by gaming the probe in isolation, since both sides use the same elicitation.
Outcome-Gated Advantage Routing (OGAR). The standard GRPO final-answer advantage A_1 (group-normalized r_{\mathrm{out}}) is routed to a token segment only when that segment is causally responsible for the answer; otherwise it is gated out. Concretely, A_1 flows to \mathcal{T}_2 tokens always (they produced a_f) but only flows to \mathcal{T}_1 when the tool call did not flip the answer. The DAPR-derived process advantage A_2 is applied to the code tokens \mathcal{C}, and is gated into the loss only when \Delta \geq 0, so the policy is encouraged to emit useful or neutral calls and is penalized (via A_2 < 0 ungated, or via not receiving positive credit) for misleading ones.
Training. Two stages: (1) SFT cold-start on a re-curated subset of the Thyme corpus, filtered for (i) sandbox execution validity, (ii) tool necessity — dropping questions Qwen2.5-VL-7B solves with pass@8{=}1 tool-free, and (iii) Gemini-3-Pro-scored reasoning quality. (2) GRPO with the gated dual-channel advantage (A_1, A_2).
Results
On the 7B comparison (Table 2, A100 batch 1), TACO improves accuracy and reduces latency simultaneously — the latter because the policy learns to emit fewer redundant tool rounds:
- V^*: 89.6% vs. PyVision-RL’s 88.7% and DeepEyes’ 85.6%; latency 2.3s vs. 3.6s.
- HR-Bench-4K: 83.8% vs. next-best 78.1%; latency 3.2s vs. 5.5s.
- HR-Bench-8K: 81.6% vs. 74.3% (PyVision-RL), a 7.3-point gap; latency 3.5s vs. 6.2s.
- MathVision: 35.8% vs. CodeV-RL-7B’s 33.6%.
- MMStar: 69.3% vs. 67.6%.
Qualitatively, the agent learns precise, single-shot crops — e.g., zooming the backdrop banner 2\times to read an occluded “BNP Paribas” wordmark (Figure 4) — rather than the multi-round speculative cropping of baselines, which explains the latency reduction.
Limitations and open questions
- DAPR’s \Delta depends on the probe eliciting the model’s honest pre-tool answer; if SFT has already entangled the answer head with anticipated tool output, a_1 may be a poor counterfactual. The paper claims robustness from the differential form, but a probe that systematically biases both a_1 and a_f identically would still yield \Delta=0 and silently mask useful credit.
- Restricting positive-\Delta gating may underweight calls whose value is informational rather than answer-flipping — e.g., a crop that increases confidence without changing the argmax.
- Results are 7B-only against 7B baselines; scaling behavior of the differential probe at larger model sizes, where pre-tool a_1 may already be near-optimal on easy splits, is unclear. The tool-necessity filter partially controls for this in training but not at evaluation.
- The reward is tied to rule-based string matching; open-ended VQA or generative answers would require a more permissive verifier and may re-introduce judge dependence.
Why this matters
TACO shows that per-tool-call credit assignment in agentic policies can be done with the existing verifier alone, by exploiting differences in outcome reward across a self-probed counterfactual rather than absolute process scores. The combination of judge-free process credit and outcome-conditioned routing yields both accuracy gains (up to 7.3 points on HR-Bench-8K) and inference-time efficiency, suggesting that “when to call a tool” is as learnable a signal as “what answer to produce” given the right gradient routing.
Source: https://arxiv.org/abs/2606.30251
OSWorld2.0: Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks
Problem
Computer-use benchmarks have lagged behind agent capabilities. OSWorld 1.0 tasks take a human roughly two minutes and resolve in ~30 tool calls; modern frontier agents saturate them without exercising the failure modes that dominate real desktop work: cross-application state tracking, dynamic environments, and verification under noisy artifacts. OSWorld 2.0 targets this gap with 108 long-horizon workflows whose median human completion time is approximately 1.6 hours — about 48× longer than OSWorld 1.0 — and which require an average of 318 tool calls when executed by Claude Opus 4.7 with maximum thinking, roughly an order of magnitude more than its predecessor.
Task design
Each task is a self-contained end-to-end workflow defined by a user goal, realistic input artifacts, a stateful environment, and a scoreable terminal state. Two design invariants are enforced. First, long-horizon difficulty must come from interdependent workflow structure (cross-application dependencies, or intra-app plan–execute–verify loops), not from concatenated subtasks or repetition. Second, task-relevant information must live in authentic artifacts and workspace state — files, web services, prior records, emails — rather than in the prompt. A representative example: an ExpenseFlow reimbursement task in which the agent must consult a tutorial PDF, navigate a legacy portal, reconcile receipt amounts against GMail and ChaseBank records, react mid-task to a new email that changes the required state, and recover employee data from a prior report.
Construction follows a four-stage pipeline (collect → instantiate environment → define final-state evaluation → multi-layer audit), with team brainstorming and expert-style annotation contributing ~90% of tasks. Annotators were trained on each target domain (tutorials, documentation, hands-on use) and owned a task end-to-end: instructions, input artifacts, environment setup, and the evaluation function. Each draft passed peer cross-checking for feasibility, redundancy, and evaluation ambiguity — important because long workflows are precisely where agents can otherwise game vague scoring rubrics.
The benchmark deliberately stresses phenomena underrepresented in prior suites: streaming interaction, dynamic environments (state changes mid-task, e.g., incoming emails), cross-source reasoning, implicit-state inference, and visual-spatial precision. Stateful user profile data is cross-referenced so that the “right” answer depends on environment context the agent must extract, not on prompt content. Separate safety reports audit safety-sensitive execution.
Experiments
Seven frontier model families were evaluated: Claude Opus 4.8, Opus 4.7, Sonnet 4.6, GPT-5.5, Qwen 3.7-Plus, MiniMax M3, and Kimi 2.6, under a primary binary-completion metric at a 500-step budget. Results are bleak in absolute terms: completion rates span 4.6%–14.0%, while partial-only rates run 50.0%–67.6%. The median score on non-zero runs is 0.44. Failures are not mass abandonment — most runs make non-trivial progress but lose constraints, rely on stale or partial state, or skip verification of the terminal state.
Behavioral analysis
The authors annotate per-action strategy for four models and find that solution style itself is predictive of failure. GPT-5.5 is the most aggressively programmatic, spending 78% of its action budget on code, API, or file operations; it excels on tasks with structured interfaces (e.g., task 065) but fails when constraints only manifest in the visible GUI workflow. Opus 4.7 is the most balanced, allocating roughly 37% to programmatic actions and 37% to GUI actions, and is comparatively reliable at preserving interface-bound state. Sonnet 4.6 is a stronger hybrid whose typical failure mode is exactness error rather than collapse. MiniMax M3 mixes modes but has a 24% churn rate (oscillation between modes) and the highest zero-score rate; Qwen 3.7-Plus shows similar churn at 18%.
Quantitatively, models with a committed style achieve the lowest zero-score rates: 19% for GPT-5.5 (programmatic-committed) and 31% for Opus 4.7 (balanced-committed). Task structure modulates this — task 100 succeeds via either GUI manipulation or direct state editing because the underlying state is recoverable, while tasks 003 and 010 demand exact final formats and punish styles that skip verification. The takeaway: unresolved arbitration between programmatic and GUI strategies is itself a distinct failure mode, separate from per-step competence.
Limitations and open questions
Behavior profiles come from single runs per model, so style and capability are confounded; the analysis is descriptive, not causal. The 108-task set, while diverse, is small relative to the variance of long-horizon outcomes, and the 500-step budget may both under- and over-favor different agents depending on planning vs. trial-and-error tendencies. Binary completion compresses meaningful partial progress, although the partial-rate breakdown mitigates this. Reproducibility of stateful, dynamic environments (e.g., mid-task incoming emails) at scale is non-trivial, and how the benchmark ages as agents adapt to its specific app stack remains an open question.
Why this matters
OSWorld 2.0 closes the gap between agent benchmarks and the actual structure of human desktop work — multi-hour, multi-app, state-dependent, verification-heavy. With frontier agents completing only 4.6–14.0% of tasks, it restores headroom that OSWorld 1.0 has effectively lost, and its behavioral analysis points to strategy-arbitration, not raw tool competence, as the next bottleneck for computer-use agents.
Source: https://arxiv.org/abs/2606.29537
Agentic Abstention: Do Agents Know When to Stop Instead of Act?
Problem
LLM agents operating over multi-turn tool-use loops (web browsing, terminal, search-augmented QA) are routinely confronted with tasks that are infeasible, underspecified, or rest on false premises. Standard abstention benchmarks treat the decision as single-turn (answer vs. abstain on a fixed prompt). That framing misses the sequential structure: in agentic settings, infeasibility may only be discoverable after several environment interactions, and the timing of abstention matters as much as the eventual decision. An agent that grinds through 30 terminal commands before giving up wastes compute and may make destructive intermediate writes; an agent that abstains immediately on a solvable task is uselessly conservative.
The authors formalize Agentic Abstention as a POMDP \mathcal{M}=(\mathcal{S},\mathcal{A},\mathcal{O},T,\Omega,R) with action space \mathcal{A}=\{\texttt{ANSWER},\texttt{ABSTAIN},\texttt{ACT}\}, where ANSWER and ABSTAIN are terminal and ACT continues interaction. The policy \pi(a_t\mid h_t) conditions on the full history h_t=(x,o_1,a_1,\dots,o_t) because the latent task state — including solvability — is only partially observable. Clarification requests are folded into ABSTAIN.
Benchmark construction
Three scenarios, ~28k tasks total. For each, solvable instances are retained from existing benchmarks and abstention-warranted variants are constructed along two axes:
- Request-based Abstention: instruction itself is infeasible. Three subtypes — Subjective Preference, Underspecified Intent, False Premise/Contradiction.
- Environment-based Abstention: instruction looks solvable; infeasibility only emerges from interaction.
In WebShop, they generate 249 request-based and 251 environment-based (Missing Target: ground-truth items deleted from the catalog and the Lucene index rebuilt) tasks, paired 1:1 with 500 solvable originals. Terminal-Bench 2.0 tasks are modified by rewriting the instruction while keeping the Docker environment, tests, and reference solution.
Evaluation
Primary metric is AbsRec@K: abstention recall when the agent is allowed K interaction turns. AbsRec@1 captures timely abstention; AbsRec@10 captures eventual abstention. They evaluate 13 LLMs (GPT-5.4-mini, Grok-4.1-Fast, Llama-3.3-{8B,70B}, GPT-OSS-120B, MiniMax-M2.5, Qwen-3 family up to 235B-A22B, Gemma-4-31B, GLM-5.1) and two scaffolds (Codex CLI, Terminus 2).
Findings
Timing, not capability, is the bottleneck. Across all three scenarios, AbsRec@K rises with K, but AbsRec@1 sits in the 0.0–0.3 range for most models. Six of eight web models, both terminal systems, and four of five QA models score below 0.5 AbsRec@10.
Specific numbers: - Web: Llama-3.3-70B reaches ~0.84 AbsRec@10, the clear outlier. Qwen3-235B and Grok-4.1-Fast form a middle tier. Most others stay <0.5. - Terminal (GPT-5.4-mini fixed): Codex CLI reaches ~0.38 AbsRec@10 vs. Terminus 2 at ~0.18. Scaffold choice roughly doubles abstention recall on the same base model. - QA: Qwen3-235B leads with 0.59 AbsRec@1 and ~0.71 AbsRec@10. Llama-3.3-70B improves most from search (0.29 → 0.49). GPT-5.4-mini stays flat at ~0.34.
Category structure. Missing Target (Environment-based) is hardest in web, since infeasibility is only observable post-search. False Premise is easiest on web but consistently hardest in QA. Underspecified Intent is the worst category for both terminal scaffolds. The gap between AbsRec@1 and AbsRec@10 is largest precisely on categories requiring environmental evidence — exactly where one expects sequential interaction to help.
convolve: context evolution for abstention
The proposed method, convolve, treats abstention as a context-engineering problem rather than a fine-tuning one. After each training rollout \tau^{(k)}, a reflection agent produces y^{(k)}=\phi(\tau^{(k)}) identifying which observations made abstention warranted and which actions delayed it. A curator updates an evolving playbook:
c^{(k+1)} = \mathcal{U}(c^{(k)}, \tau^{(k)}, y^{(k)})
The playbook is appended to the system prompt at inference. Training uses 20 examples from the WebShop abstention-only subset, one epoch, ≤2 reflection rounds per example, 80k-token playbook budget, with curator inputs truncated to 6k tokens. Evaluation is on a 101-example held-out split, stratified by scenario and grouped by underlying WebShop goal to prevent leakage. The paper reports detailed numbers for convolve in later subsections (the excerpt here doesn’t include them), but the setup is the methodologically interesting piece: stopping rules are distilled from trajectories rather than learned via reward, which sidesteps the question of how to score abstention during RL.
Limitations
- AbsRec ignores over-abstention on solvable tasks except in a small terminal slice; the precision side of the tradeoff is under-reported in the main results.
- Request-based categories are LLM-generated then manually filtered — distributional artifacts of the generator are plausible.
- Terminal evaluation fixes the base model to GPT-5.4-mini, conflating scaffold effects with model-specific behavior.
- convolve is evaluated on a 101-example WebShop split with 20 training examples; the playbook approach’s robustness to distribution shift across scenarios is in appendices only.
- The POMDP formulation is invoked but no reward-based policy learning is attempted; the gap between context-engineering and proper sequential RL for abstention remains open.
Why this matters
Reliability of long-horizon agents hinges on knowing when to stop, and current models — including frontier ones — abstain late or not at all, burning interaction budget on infeasible tasks. The result that scaffold choice (Codex CLI vs. Terminus 2) doubles abstention recall on the same base model suggests that stopping behavior is largely an inference-orchestration problem, not a pretraining one.
Source: https://arxiv.org/abs/2606.28733
LiveEdit: Towards Real-Time Diffusion-Based Streaming Video Editing
Problem
Streaming video editing has two requirements that current diffusion video models do not jointly satisfy: (i) strict preservation of background and non-edited regions across arbitrarily long horizons, and (ii) per-frame latency low enough for interactive use. Bidirectional video DiTs (Wan2.1, etc.) edit well offline but cannot run causally; existing streaming generators (StreamV2V, StreamDiffusion, StreamDiffusionV2) target global V2V translation and recompute the entire scene every frame, which destroys temporal consistency in unedited regions and wastes compute. LiveEdit attacks both by distilling a bidirectional editor into a causal 4-step DiT and by adding a region-aware token cache.
Why naive causal truncation fails
The authors first diagnose an attention-distribution shift. In the bidirectional teacher, temporal attention is sharply localized — most mass falls on neighboring frames in both directions. If one simply masks out future keys/values to obtain a causal model, the remaining attention is forced to spread roughly uniformly over all historical frames rather than concentrating on the immediate past.
This homogenization breaks the structural priors that the teacher relies on for temporal coherence, and motivates an explicit re-alignment of the causal attention distribution rather than zero-shot truncation.
Method
LiveEdit is a three-stage distillation pipeline on top of Wan2.1-T2V-1.3B, plus an autoregressive mask cache at inference.
Stage 1 — Foundation tuning. A bidirectional editing DiT \epsilon_\theta^{bid} is trained on 20K filtered video-video pairs from Ditto-1M. The noisy latent z_t and the condition latent are concatenated channel-wise rather than along the sequence dimension. This keeps the sequence length identical to single-video generation and avoids the quadratic blow-up of token-wise concatenation in spatio-temporal attention. Training: 9K steps, lr 10^{-5}, global batch 8, t\in[0,1000].
Stage 2 — Teacher forcing to a causal DiT. The bidirectional model is converted into \epsilon_\theta^{causal} by imposing a chunk-wise causal attention mask M_{causal} with chunk size 3 latent frames: tokens attend only to their own chunk and earlier chunks. The student is fine-tuned for 20K steps. Because Stage 1 provides a localized teacher target, this stage explicitly re-shapes the causal attention to match the bidirectional prior’s local concentration, addressing the distribution shift identified above.
Stage 3 — Distribution Matching Distillation to 4 steps. A 4-step generator G_\theta is initialized directly from the Stage-2 causal weights, deliberately skipping the usual ODE-based initialization; the authors argue the causal autoregressive distribution from Stage 2 is already aligned enough to serve as a starting point. Sampling timesteps are fixed to \{0, 250, 500, 750\}. Both the real-score and fake-score networks are initialized from Stage-1 weights. Training uses the standard DMD timestep-weighting w(t), lr 10^{-5}, 10K steps.
AR-oriented Mask Cache. At inference, the model decodes 3 frames per autoregressive step. For each new latent frame k, a binary editing mask M^k is produced by thresholding the L_2 distance between current and cached token features; the threshold \tau is set dynamically per step so that exactly 70% of spatial tokens are pruned. Pruned (background) tokens bypass self-attention and reuse cached intermediate features; only the ~30% actively edited tokens go through full computation. The cache is applied only inside self-attention, where the authors find no quality degradation; cross-attention and FFN paths remain dense for edited tokens. This both enforces strict pixel-level preservation in unedited regions (since their features literally do not change) and removes the dominant cost of dense temporal self-attention.
Results
The paper reports a per-frame latency of 79 ms with the 4-step causal generator plus mask cache, which is in the real-time regime for streaming editing at ~12 fps single-stream throughput. The 70% token-pruning rate is empirically the operating point where background preservation is exact and quality is unaffected. The qualitative comparison framing (
) emphasizes that bidirectional baselines are inefficient and earlier streaming baselines fail to keep unedited regions stable across long horizons; LiveEdit targets both. The authors also state they construct a dedicated streaming video editing benchmark, though specific metric values are not enumerated in the excerpted sections.
Limitations and open questions
- The foundation is Wan2.1-T2V-1.3B; behavior at larger scales (e.g., 14B) where attention statistics differ is untested.
- Chunk size is fixed at 3 latent frames; the trade-off between chunk size, causal locality, and edit propagation latency is not characterized.
- The 70% pruning rate is a single empirical operating point. Robustness when edits cover large fractions of the frame (e.g., global style changes), where the mask cache loses its asymmetry, is unclear.
- DMD initialization directly from Stage 2 skips ODE warmup; whether this generalizes beyond the specific editing distribution used for distillation is not shown.
- Quantitative comparisons against StreamV2V / StreamDiffusionV2 on the proposed benchmark are not in the provided sections, so the magnitude of the preservation and quality gains cannot be checked here.
Why this matters
LiveEdit is a concrete recipe for turning a bidirectional video DiT into a usable real-time editor: diagnose the attention-distribution shift induced by causal truncation, fix it with teacher-forced causal distillation, then collapse to 4 steps with DMD and exploit the editing-specific structure (most tokens are background) via a region-aware cache. The 79 ms/frame number with strict background preservation makes interactive diffusion video editing plausible rather than aspirational.
Source: https://arxiv.org/abs/2606.26740
TUA-Bench: A Benchmark for General-Purpose Terminal-Use Agents
Problem and scope
Terminal-use agents (TUAs) sit in an awkward gap between two existing evaluation traditions. GUI-centric computer-use benchmarks (OSWorld, WindowsAgentArena, etc.) test multimodal click-and-type behavior but ignore the fact that modern coding agents — Claude Code, Codex, OpenHands — operate primarily through a shell. Shell-native benchmarks like Terminal-Bench and SWE-bench, in turn, restrict the task distribution to programming and sysadmin workflows. Neither tradition captures the empirical situation that a competent CLI agent with the right packages installed can do document editing, email triage, web research, video analysis, and scientific simulation, all without a display server.
TUA-Bench fills that gap with 120 manually authored tasks across five families: routine digital work (documents, email, web seeking) and expert workflows (scientific/engineering, multimedia/design) co-designed with PhD domain experts.
The five-family taxonomy and a finer-grained subcategory breakdown are shown in Figures 1 and 2; the inclusion of categories such as bioimage analysis (CellProfiler), engineering simulation (EnergyPlus, OpenFOAM), and video understanding is what makes the suite “general-purpose” rather than another shell benchmark.
Execution environment
TUA-Bench is built on Harbor, the same orchestration substrate used by Terminal-Bench, which gives it container management, parallel trials, trajectory logging, and verifier dispatch for free. Each task ships as a self-contained bundle: a Dockerfile, input artifacts, a natural-language instruction, environment variables, and an in-environment verifier that inspects final state and returns a scalar reward. Containers are resettable; both Docker and rootless Podman are supported, which matters for cluster deployment without sudo.
Crucially, evaluation is execution-grounded rather than trajectory-based. The verifier reads files under /app/artifacts (or wherever the task spec dictates) and compares against ground truth — sometimes with numerical tolerance. For example, the EnergyPlus task 003-rebuild-energy-model requires the agent to reconstruct an OpenStudio model from a floor-plan PNG, translate to IDF, run annual simulation, and produce simulation_summary.txt whose annual_electricity_kwh, annual_natural_gas_kwh, etc. must agree with hidden ground truth within 1\% relative tolerance. The OpenFOAM heater-placement task 004-place-heater-for-sensors requires solving an inverse problem on a transient heat equation with diffusivity 8.4 \times 10^{-5}\ \mathrm{m^2/s} over 120\ \mathrm{s}, matching four sensor targets within 0.5\ \mathrm{K}. These are not tasks where a GUI shortcut exists; the agent must drive specialized CLI tooling.
Metrics and evaluation protocol
For each (agent, model, thinking-config) tuple, every task is run 5 times. The paper reports:
- Mean success rate across all 5 \times 120 = 600 trials,
- Pass@1: expected single-run success,
- Pass@5: any-of-5 success,
- All-5: fraction of tasks solved in every one of the 5 trials.
The All-5 / Pass@5 gap is the most informative reliability signal: it isolates tasks the agent can occasionally luck into versus those it has actually mastered.
Agents and models
The evaluated harness frameworks are Terminus-2, Codex, OpenHands, Mini-SWE-Agent, and Claude Code. Backing models span GPT-5.5 / GPT-5.4-mini, Claude Opus 4.8/4.7, Sonnet 4.6, Haiku 4.5, Gemini 3.1 Pro, GLM-5.1, MiniMax-M3, DeepSeek-V4 Pro, Qwen3.7-Max, and Kimi K2.6. (The model versioning in the paper appears speculative/future-dated; treat the specific identifiers as labels rather than literal releases.) The abstract reports that the strongest configuration is Claude Code, though the abstract is truncated before specific numbers.
Time-budget sensitivity
One of the more practically important findings concerns wall-clock budget. For Terminus-2 + GPT-5.5 (xhigh reasoning), enlarging the per-task time budget collapses timeouts from 337 of 600 trials to just 4 of 600, with a monotone increase in success rate. This is a strong reminder that “agent failure” on long-horizon terminal tasks is often a budget artifact: scientific workflows like EnergyPlus annual simulation or OpenFOAM transient solves have irreducible compute time, and a benchmark that fixes a tight cap will conflate model capability with patience. The implication for future work is that reported success rates must always be paired with budget; otherwise cross-paper comparisons are meaningless.
Limitations and open questions
The paper is light on the headline numbers in the sections excerpted here — the comparative leaderboard lives in Table 5 and at https://tuabench.ai. A few real concerns:
- Scale. 120 tasks across five families means roughly 24 tasks per family and far fewer per subcategory; statistical power for fine-grained claims (e.g., “model X is better at bioimage than model Y”) is limited.
- Verifier brittleness. Execution-based scoring with 1\% tolerances on physical simulations assumes the ground-truth pipeline is itself canonical; alternative valid solutions (different mesh, different solver settings) may be marked wrong.
- Internet-dependent tasks (live-web information seeking) introduce nondeterminism that the 5-trial protocol only partly absorbs.
- GUI-to-terminal reformulation changes the nature of some tasks — counting Enter-key presses from a video via the terminal is testing CLI video tooling fluency, not the underlying perceptual task one would solve in a GUI.
Why this matters
TUA-Bench is the first benchmark to take seriously the empirical claim that frontier shell agents have outgrown coding tasks and now compete with GUI agents on general computer use. Its execution-grounded verifiers and the time-budget analysis together provide a much-needed corrective to evaluations that conflate capability with harness configuration.
Source: https://arxiv.org/abs/2606.28480
Hacker News Signals
DSpark: Speculative decoding accelerates LLM inference [pdf]
DeepSeek’s DSpark paper addresses the memory-bandwidth bottleneck in autoregressive LLM inference. Standard speculative decoding uses a small draft model to propose k tokens, then verifies them in a single forward pass of the target model. DSpark extends this by tightly integrating speculative decoding into a production-grade inference system with several engineering refinements: dynamic draft length adjustment based on acceptance-rate history, batched tree-structured speculation rather than linear chains, and careful KV-cache management so that rejected suffixes do not pollute the cache unnecessarily.
The core verification step retains the standard guarantee: the output distribution is identical to greedy or temperature-sampled decoding from the target model, because rejected tokens are resampled from the residual distribution p_{\text{target}} - p_{\text{draft}} (normalized). DSpark optimizes the draft-model scheduling so that CPU and GPU work overlap — draft generation partially runs on CPU or a smaller GPU partition while the target model is idle during memory transfers.
Reported numbers claim roughly 2-3x end-to-end throughput improvement on DeepSeek’s production models at comparable latency targets, with acceptance rates around 0.7-0.85 depending on task domain. Code generation and repetitive-structure tasks benefit most; open-ended creative generation sees lower acceptance rates and smaller gains.
The system is positioned for DeepSeek’s internal use but the paper details are public. Open questions include how acceptance rates degrade under high-batch-size regimes (where the target model is no longer the bottleneck) and how tree-structured drafts interact with prefix caching in production.
Source: https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf
What happens when you run a CUDA kernel?
A detailed walkthrough of the software and hardware stack traversed between a kernel<<<grid,block>>>(...) call and actual execution on SM cores. The post traces: (1) the CUDA runtime allocating a launch descriptor and placing it into a work queue; (2) the driver translating PTX or SASS into a command buffer submitted to the GPU’s command processor via a write to a mapped MMIO doorbell register; (3) the GigaThread Engine on the GPU distributing CTAs (cooperative thread arrays) across available SMs as earlier CTAs retire; (4) the SM warp scheduler issuing warps from the active CTA pool, hiding latency via warp switching when a load misses L1.
The post is technically accurate on the pipeline stages and gives a useful mental model for latency attribution. It distinguishes between kernel launch latency (~5-10 µs for the CPU-side submission path) and actual execution latency, which matters enormously when kernels are short and launch overhead dominates. It also explains why cudaStreamSynchronize is a CPU-side blocking call that polls or sleeps until the GPU signals completion through a pinned host memory flag written by the GPU’s copy engine.
For practitioners debugging performance, the most actionable section covers occupancy: the warp scheduler needs enough resident warps to hide the ~400-cycle L2 latency; occupancy is limited by register file usage, shared memory allocation per block, and the SM’s maximum resident block count. These constraints are queryable via cuOccupancyMaxActiveBlocksPerMultiprocessor.
Source: https://fergusfinn.com/blog/what-happens-when-you-run-a-gpu-kernel/
Apple Neural Engine: Architecture, Programming, and Performance
An arxiv paper providing a systematic characterization of the Apple Neural Engine (ANE), the dedicated ML accelerator present in Apple Silicon since A11. The paper reverse-engineers the programming model and microarchitecture from observable behavior rather than Apple documentation, which remains largely proprietary.
Key findings: the ANE is a spatial array of MAC units organized around a fixed-function dataflow that strongly prefers NHWC (channel-last) tensor layouts and 16-bit floating point. Operations outside a narrow supported set — standard convolutions, matrix multiplies, certain elementwise ops, pooling — fall back to CPU or GPU, causing severe fragmentation penalties. The compiler (CoreML’s milOptimizer) handles op fusion and layout transformation, but the paper shows that seemingly minor graph changes (e.g., adding a non-fused activation) can cause a 10x latency regression by breaking a fused kernel and forcing a round-trip through system memory.
Performance characterization shows peak throughput in the range of 11-38 TOPS depending on chip generation, but sustained throughput on real workloads is substantially lower due to memory bandwidth limits and the sensitivity to op compatibility. Transformer attention, particularly softmax and the QK^T matmul with non-power-of-two head dimensions, is especially fragile.
The programming interface is essentially CoreML with no direct kernel programming API, in contrast to CUDA or Metal. This limits flexibility but raises the abstraction floor. The paper’s contribution is making the implicit performance model explicit, which is valuable for anyone optimizing models for on-device Apple deployment.
Source: https://arxiv.org/abs/2606.22283
Micro-Agent: Beat Frontier Models with Collaboration Inside Model API
vLLM’s blog post describes Micro-Agent, a multi-agent framework that routes subtasks to specialized smaller models coordinated by a lightweight orchestrator, achieving benchmark scores competitive with larger frontier models at reduced compute cost. The architecture lives entirely within the inference API layer — no fine-tuning required — using structured prompting to define agent roles.
The technical substance is in how task decomposition is formalized. A planner agent emits a structured JSON task graph; executor agents receive individual nodes with full context, produce outputs, and the orchestrator resolves dependencies and handles retries on failure. Verification agents run lightweight consistency checks (e.g., syntax validation, unit test execution) before results are committed to the shared context.
On coding benchmarks (SWE-bench, HumanEval variants), the blog claims the system matches or exceeds GPT-4-class performance using a mix of smaller models (Qwen 2.5 32B and similar). The claimed wins come from specialization — a model fine-tuned or prompted for code review outperforms a general model on that subtask — and from the retry/verification loop catching errors that single-pass generation misses.
The main limitation is latency: multi-agent pipelines have irreducible sequential steps, and token costs multiply across agents. The approach only makes economic sense when the target model is expensive and subtasks are parallelizable. The blog does not provide rigorous controlled ablations separating the multi-agent structure from simply using more total compute.
Source: https://vllm.ai/blog/2026-06-29-micro-agent-frontier-models
AI learns the “dark art” of RFIC design
The IEEE Spectrum piece covers work on applying ML to radio-frequency integrated circuit design, specifically the layout and sizing of analog/RF blocks like low-noise amplifiers, voltage-controlled oscillators, and matching networks. RFIC design is notoriously difficult to automate because the performance metrics (noise figure, linearity, phase noise, return loss) are highly nonlinear functions of geometry and process parameters, simulation is expensive (full-wave EM solvers take hours per run), and design rules interact in complex ways with parasitic extraction.
The technical approach described uses a combination of Bayesian optimization over the continuous sizing space and RL-guided placement that learns to minimize parasitic coupling between sensitive nodes. The EM simulation bottleneck is partially addressed by training surrogate models on simulation data, reducing the number of full solver calls during optimization.
The “dark art” framing reflects that experienced RF designers encode heuristics (keep LNA input away from noisy digital clocks, use differential structures to cancel substrate coupling) that are hard to specify formally. The claim is that the RL agent rediscovers analogous layout strategies from reward signals derived from simulation outcomes rather than from explicit rules.
Quantitative claims in the article are vague — “comparable to expert designers” on specific test cases — which is typical for this class of EDA research where comparing against human designers is methodology-dependent. The broader significance is that analog/RF automation lags digital by decades and represents a genuine bottleneck in system-on-chip design.
Source: https://spectrum.ieee.org/ai-radio-chip-design
Ornith-1.0: self-improving open-source models for agentic coding
Ornith-1.0 is a released model series from deepreinforce-ai trained using an iterative self-improvement loop for agentic coding tasks. The core training methodology is rejection-sampling fine-tuning (RFT) combined with RL: the model generates trajectories on coding environments (SWE-bench-style tasks with execution feedback), filters trajectories by correctness verified against test suites, and fine-tunes on the passing set. This is iterated, with each round’s model used to generate the next round’s training data.
The self-improvement framing is important but the loop is bounded: it requires an external verifier (the test suite) to label correct vs. incorrect trajectories, so it does not generalize beyond tasks with executable ground truth. Without this oracle the method degenerates.
The repository releases model weights and training code. The base models appear to be Qwen 2.5 derivatives fine-tuned with the above pipeline. Benchmark numbers on SWE-bench Verified and similar agentic coding evaluations are claimed to be competitive with substantially larger models, consistent with the general finding that RL from execution feedback yields disproportionate gains on code tasks.
Open questions: how sensitive is the performance gain to the initial checkpoint quality (the “warm start” problem in iterative RFT), and whether the self-improvement saturates quickly or continues to yield gains across many iterations. The repo is early-stage and reproducing the full training pipeline requires non-trivial compute.
Source: https://github.com/deepreinforce-ai/Ornith-1
Qwen 3.6 27B is the sweet spot for local development
A practitioner post evaluating Qwen 3 in the 27B parameter range for local inference, primarily on Apple Silicon and consumer NVIDIA hardware. The technical argument is about the compute-quality Pareto frontier for quantized local models: at Q4_K_M quantization, a 27B model fits in ~16 GB VRAM or unified memory, runs at acceptable token/s speeds on M2/M3 Pro hardware, and qualitatively outperforms 7-13B models by a margin that matters for code generation and reasoning tasks.
The post benchmarks throughput (tokens/second) using llama.cpp on M2 Max and an RTX 4090, reporting roughly 25-35 tok/s on the 27B Q4 variant — fast enough for interactive use. The quality observations are informal but the author’s comparisons on coding tasks show Qwen 3 27B matching or exceeding Qwen 2.5 72B on several cases, which if reproducible is noteworthy and attributable to Qwen 3’s improved instruction tuning and the thinking/non-thinking mode toggle.
The broader discussion in HN comments (644 comments, highest engagement in this batch) centers on the democratization angle: a model competitive with GPT-3.5-class performance running fully locally and offline has concrete privacy and cost implications. Technical commenters note that the 27B “sweet spot” claim depends heavily on the task distribution — long-context retrieval and complex multi-step reasoning still favor larger models — and that Q4 quantization induces measurable perplexity degradation relative to fp16 that varies by task.
Source: https://quesma.com/blog/qwen-36-is-awesome/
WATaBoy: JIT-ing Game Boy Instructions to WASM Beats a Native Interpreter
A Game Boy emulator that JIT-compiles LR35902 (Z80-variant) opcodes to WebAssembly bytecode at runtime, achieving higher throughput than a conventional fetch-decode-execute interpreter loop written in native code. The technical claim is counterintuitive: the JIT target is WASM, which is then compiled again by the browser’s WASM JIT (e.g., V8’s Turbofan or SpiderMonkey’s IonMonkey), so there are two compilation tiers between the source GB opcodes and final machine code.
The performance advantage comes from eliminating the interpreter dispatch overhead. In a standard interpreter, every instruction requires a branch through a dispatch table or switch statement; branch mispredictions accumulate significantly for Game Boy code with tight loops. The JIT translates basic blocks of GB instructions into WASM function bodies, removing the per-instruction dispatch and allowing the WASM JIT to apply standard optimizations (register allocation, instruction scheduling) across the entire basic block.
The implementation maps GB registers to WASM locals, translates flag computations into WASM i32 operations, and handles the memory-mapped I/O through indirect calls to host functions. The trickiest parts are cycle-accurate timing (the GB’s PPU and timer fire at specific cycle counts) and correctly handling the Z80’s half-carry flag, which has no direct WASM equivalent.
Benchmark results show roughly 2-3x speedup over the interpreted baseline in throughput tests. The author is careful to note that at Game Boy speeds (4.19 MHz clock), both implementations easily run faster than real-time, so the speedup is a proof-of-concept rather than a practical necessity. The takeaway for compiler engineers is that double-JIT pipelines are viable and the intermediate bytecode tier does not necessarily negate the optimization gains.
Source: https://humphri.es/blog/WATaBoy/
Noteworthy New Repositories
Albert-Weasker/niubi_guard
A GitHub repository abuse detection and response system aimed at automating the identification and handling of policy-violating repositories at scale. The core problem is that manual review of malicious, spam, or abusive repositories is slow and inconsistent; niubi_guard provides a pipeline that ingests repository metadata and content signals, applies heuristic and ML-based classifiers, and can trigger response actions (flagging, reporting, or downstream automation). The system is structured around configurable detection rules, making it extensible to new abuse categories without full retraining. At 1132 stars it has attracted the most attention in this batch, suggesting real demand for automated trust-and-safety tooling outside GitHub’s own infrastructure. Useful for platform operators, large org admins, or researchers studying repository abuse patterns at scale.
Source: https://github.com/Albert-Weasker/niubi_guard
Soul-AILab/SoulX-Transcriber
An end-to-end framework for multi-speaker automatic speech recognition that jointly models speaker diarization (who), segmentation (when), and transcription (what) in a single pass rather than as a pipeline of independent components. Pipeline approaches accumulate errors across stages; joint modeling allows gradients and uncertainty to propagate across all three tasks simultaneously. The architecture integrates speaker embedding estimation with a sequence-to-sequence transcription model, likely leveraging a Whisper-class encoder paired with diarization-conditioned decoding. Joint training on multi-speaker corpora allows the model to resolve overlapping speech and attribute words to the correct speaker with fewer post-processing hacks. Practically useful for meeting transcription, podcast processing, and any domain where speaker attribution is a first-class requirement. Worth examining for researchers working on speaker-attributed ASR or trying to replace cascaded diarize-then-transcribe systems.
Source: https://github.com/Soul-AILab/SoulX-Transcriber
litvinovtd/qeli
A self-hosted VPN designed specifically for adversarial network environments where deep packet inspection is active (Iran, China, Russia). The transport layer uses the REALITY protocol — a TLS-camouflage technique that mimics legitimate TLS handshakes against a real target server, making the tunnel indistinguishable from normal HTTPS traffic to passive and active DPI classifiers. The cryptographic core is a hybrid key exchange combining X25519 (classical ECDH) with ML-KEM-768 (CRYSTALS-Kyber, a NIST-standardized post-quantum KEM), providing harvest-now-decrypt-later resistance. The core is written in Rust for memory safety and performance, with native clients on Android, Windows, and macOS. This is notably more complete than most anti-censorship tooling, which typically provides either a good obfuscation layer or good crypto but rarely both. Relevant for anyone building censorship-circumvention infrastructure or studying post-quantum VPN deployments in the wild.
Source: https://github.com/litvinovtd/qeli
bjarneo/ku
A terminal UI for Kubernetes that prioritizes keyboard-driven navigation over mouse interaction and aims to reduce the round-trip friction of repeatedly invoking kubectl. Built with a TUI framework in Go (consistent with the Kubernetes ecosystem), it supports browsing arbitrary resource types, in-place editing of manifests, streaming logs, and exec-ing into containers — covering the most common interactive cluster management tasks without leaving the terminal. The “any resource” browsing is the key differentiator over simpler pod-centric TUIs: it queries the API discovery endpoint and dynamically renders resource lists, so CRDs are supported without code changes. Compared to k9s (the dominant alternative), ku is positioned as a simpler, faster codebase that is easier to fork or extend. A practical choice for operators who spend significant time in cluster debugging sessions.
Source: https://github.com/bjarneo/ku
Totoro-jam/battle-tested-patterns
A curated reference of production-grade design patterns drawn from real, large-scale codebases including the Linux kernel, Chromium, Go’s standard library, and React’s internals. Each pattern entry links directly to the originating source file, making it possible to trace the pattern back to its authoritative implementation rather than relying on abstract descriptions. The repository provides examples in multiple languages and includes runnable exercises, closing the gap between reading a pattern and understanding its behavior under concrete constraints. This is more valuable than typical design-pattern literature because the examples are grounded in systems where performance, concurrency, or correctness requirements forced specific tradeoffs. Useful as a structured study resource for engineers preparing for senior-level system design, or for researchers wanting a corpus of annotated real-world patterns for empirical software engineering work.
Source: https://github.com/Totoro-jam/battle-tested-patterns
opengeos/geolibre-rust
Compiles whitebox_tools (the WhiteboxGAT next-generation geospatial processing library) plus new GeoLibre-specific tools to WebAssembly using the WASI target, enabling client-side execution of heavyweight geospatial algorithms directly in the browser without a server backend. The Rust toolchain is well-suited to WASI compilation: the memory safety guarantees eliminate whole classes of undefined behavior that would be dangerous in a sandboxed WASM environment, and the zero-cost abstraction model keeps WASM binary sizes manageable. Geospatial operations covered include terrain analysis, hydrological modeling, and vector/raster processing — tasks that have historically required desktop GIS software or server-side compute. The integration target is the GeoLibre ecosystem, but the WASI binaries are consumable by any WASM runtime. Relevant for web GIS developers and researchers building interactive geospatial tools where round-trip latency to a compute backend is unacceptable.
Source: https://github.com/opengeos/geolibre-rust
yaroslav/kino
A Ruby web server designed for Ruby 4.0’s Ractor concurrency model, which provides true parallelism by enforcing shareable/isolated object semantics between Ractors. The architecture is a two-tier design: a Rust front-end using Tokio (async I/O runtime) and Hyper (HTTP library) handles connection acceptance and request parsing at high throughput with minimal GC pressure, then dispatches to a pool of Ruby Ractors that execute Rack 3 application code in parallel. A threaded fallback mode is included for applications that are not yet Ractor-safe. This architecture sidesteps the GIL/GVL bottleneck that has historically limited Ruby server throughput on multi-core hardware. The Rust-to-Ractor boundary is the technically interesting seam: it must serialize/deserialize request objects across the FFI in a form compatible with Ractor’s shareable-object constraints. Relevant for Ruby performance researchers and early adopters of Ruby 4.0’s concurrency primitives.
Source: https://github.com/yaroslav/kino
Aliu-AiRobot/ESEILANE
A knowledge graph engine targeting AI application workloads, specifically GraphRAG (retrieval-augmented generation over graph-structured knowledge) and LLM integration scenarios. Knowledge graphs for AI inference impose different access patterns than classical graph databases: workloads are dominated by multi-hop traversals for reasoning chains, embedding-augmented nearest-neighbor lookups over entity representations, and subgraph extraction for prompt construction. ESEILANE is built to optimize these patterns rather than general-purpose OLAP graph queries. The engine is positioned as a high-performance backend for intelligent applications where the knowledge base is structured as a property graph with vector-annotated entities. GraphRAG has emerged as a compelling alternative to flat-document RAG for domains with complex relational structure (biomedical, legal, enterprise), and dedicated graph engines are a prerequisite for making it practical at scale.