Guys, I have a daily goal of reading 1 article a day. I do this by discussing the article with my agent, and the focus is on my self-improvement in Machine Learning, Agents, Harness, LLMs, and other things in this universe that amuse me. In this process, we create images to make the rationale crystal clear. So, I decided to start posting my studies and analyses here. Because of that, there's a daily post here that looks automated, but it isn't. I have no intention of selling anything. I'm a studious and hardworking guy, a family man passionate about technology and what's behind it (in a technical sense). I am a human, and I'm here to talk to humans. I'm a builder, working on a few applications as side projects, and soon I plan to share them and invite people to test them out. My focus is B2B. If you're interested in discussing these topics, follow me and I'll follow you back (provided you don't post garbage about politics, gossip, hate speech, and other things that don't help humanity evolve).

Cross analysis of models Sources: artificialanalysis.ai/ artificialanalysis.ai/evalua… arena.ai/leaderboard/agent lmarena.ai/leaderboard/text arcprize.org/leaderboard openrouter.ai/models

Hybrid search is the default RAG advice, and RRF (reciprocal rank fusion) is the fusion method most stacks ship. A new paper measures what that default costs on each query: the fusion tax. Aaditya Chauhan and Arun Agarwal (paper in @IEEEAccess) fused Anserini BM25 with five dense encoders (22M-596M params) on 7 BEIR corpora. What they found: - With BGE-small, score interpolation (dense weight 0.7) beats dense-only on average on every corpus. It still ranks relevant documents below dense-only on 8-21% of queries, and a hurt query loses 0.04-0.21 nDCG@10 on average. - RRF, the default in Elasticsearch, Azure AI Search and LangChain, scores below dense-only on average on 5 of 7 corpora and wins only where BM25 and dense are balanced. - A newer encoder keeps the tax. Interpolation trails the better of BM25 and dense on 14-43% of queries with Qwen3-Embedding, 13-48% with BGE-small. - A router on 17 cheap query features never beat static fusion on a held-out corpus. 11 of the features flip sign between corpora. What to do: 1. Label 200-400 real queries and compare BM25 and dense per query. 2. If dense leads clearly (0.04+ nDCG@10), interpolate at 0.6-0.7. If balanced, use RRF. 3. Keep dense-only as a candidate. Loss-averse risk tests favored it on 6 of 7 corpora. 4. Re-measure when you swap the encoder. After cross-encoder reranking (one model, top-30), interpolated candidates landed within 0.011 nDCG@10 of dense-only candidates on 6 of 7 corpora. arxiv.org/abs/2610.30612

Context compaction is a trust boundary in many coding agents. One forged "[User]:" line in a page the agent fetches can come back after compaction as an approval you never gave. Arshan Dabirsiaghi (@nahsra, @pixeebot) traced the cause to the serializer. Before summarizing, some harnesses flatten the typed conversation into one string and mark each message with a text label like [User]:. They do not escape that label inside tool output, so the summarizer files the forged line under the user's instructions. Results on each harness's real serializer and compaction prompt: - Flattening harnesses (pi, opencode, Aider, OpenHands, Cline): 87-100% of forged approvals laundered, filed as the user's own instruction. - Role-typed harnesses, which keep roles as a typed field (Codex, Gemini CLI, Qwen Code, Continue): 0%. On pi, laundering stayed at 100% up to ~908k tokens. In the real pi app, the laundered approval made the agent run an attacker's curl | sh in 3 of 6 sessions. Paired clean sessions ran it 0 times after compaction. Gemini CLI's anti-injection prompt rule, applied to a flattening serializer, still left 46-62% laundered. A code check that compares user-attributed claims with the real user turns caught 77% of laundered claims and demoted 2% of legitimate ones. If your agents run unattended, escape role labels before flattening or keep messages role-typed through compaction. The author told the maintainers before publication. arxiv.org/abs/2610.29869

Your CLAUDE.md outranks your codebase. When the instruction file and the code disagree, coding agents follow the file. Claude Code does so even after naming the conflict. Xiaonan Xu (@GTComputing, @GeorgiaTech) and Wenjing Wu (@CUBoulder, @CUEngineering) built 40 Python projects. In each, the instruction file asks for one convention and every existing module uses another (print vs logging, integer cents vs Decimal). Claude Code (Sonnet 5.5) and Codex CLI (GPT-6 Sol) each added a feature, in 320 runs. Without a fix: - 90.1% of choices followed the stale file; 4.2% followed the code. - Claude Code reported the conflict in 79 of 80 runs, yet 86.2% of its choices in those runs still matched the file. - Codex CLI rewrote working code to match AGENTS.md in 20 of 80 runs. The original tests then failed in 17 of them. The authors trace this to the instruction hierarchy. The agent loads the instruction file as an instruction. The code arrives as tool output, which models are trained to rank lower to resist prompt injection. The fix is one sentence in ~/.claude/CLAUDE.md or ~/.codex/AGENTS.md: "When a repository's documentation and its existing code disagree, follow the conventions used in the existing code, and in your final reply point out each inconsistency you found between the documentation and the code." With the fix, 91.4% of choices followed the code and tests passed in all 160 runs. Tested on synthetic Python projects. arxiv.org/abs/2610.30571

DoorDash has over 56,000 feature flags across 623 repositories, and 1,659 of them are stale. Atharv Chandratre and Jai Datar at @DoorDash (@DoorDashEng) built a multi-agent system that removes a stale flag and opens the pull request. Accepted at ICSME 2026, Industry Track. The system runs in two phases with one human checkpoint: - An orchestrator on Claude Sonnet 4.6 reads the Jira ticket and lists every code reference. It queries the experimentation platform over Model Context Protocol (MCP) for the live rollout state. - An engineer confirms the target value for each flag. - Up to four removal agents on Claude Opus 4.6 run in parallel per repository, each in its own git worktree. An agent opens a PR only after the build, unit tests and the Detekt linter pass locally. CI then enforces 95% patch coverage. Results on the system's 50 most recent flag removals: - 45 usable PRs (90%): 31 accepted on the first shot, 14 after one revision. - $4.79 of LLM API cost and 13.8 minutes of agent runtime per flag on average, excluding engineer review. DoorDash estimates one to two hours for a manual cleanup. - The authors observed no bugs or regressions in the 50 PRs. Each of the 5 failures missed one or two links in a deep call chain. The authors rank the live rollout lookup among their highest-leverage choices. Source code shows the default value; production can run another. A cleanup tool without live rollout state can hardcode the wrong behavior. arxiv.org/abs/2610.31351

An enterprise agent can lose the author's emphasis before it starts reasoning. Yikai Zhao, Saurabh Pandey and Pradeep Kumar Misra at @AmazonScience (@amazon) locate the loss in the ingestion layer, the converter that turns a .docx or PDF into tokens. Task: 76 real policy documents. The agent lists the requirements the author marked with red text or a highlight. Ground truth comes from the Word file's own formatting markup (OOXML run properties). A deterministic matcher scores each answer, with no LLM judge. - Their parser reaches micro F1 0.690. docling falls to 0.150 and plain text to 0.075. - The failure is silent. Every converter returns well-formed output, and the agent guesses. Under docling, the false-positive rate on unmarked requirements is four times the parser's (0.043 vs 0.011). - A leave-one-out ablation puts the loss on highlight (+0.302 macro F1) and colour (+0.262). Bold, italic, monospace and strikethrough each sit within 0.003 of zero. - 32.8% of 6,462 documents carry deliberate colour or highlight; 10.3% carry it on an obligation. - A block-level role such as CRITICAL_WARNING on top of the raw colour marker adds +0.085 macro F1 in a pre-registered test (p = 0.049); significant on three of six models. Plain text collapses under all six answering models. The parser costs about twice the tokens of plain text. Put assertions in your ingestion layer, and test that colour survives the converter before you tune the prompt. arxiv.org/abs/2610.30026

Most LLM call sites in agentic systems have code checks, yet most of what each call must guarantee goes unchecked. Shihao Weng, Longtian Wang and colleagues at @NJU1902, Xi'an Jiaotong University, @sgSMU and @UCLCS (incl. @f_sarro) audited 496 LLM call sites in 40 open-source agentic systems, including Codex, Gemini CLI, OpenHands and OpenClaw. Method: one agent writes the contract each call needs from a spec, without seeing the code. A second agent extracts the contract the code enforces. Human reviewers check every automated step, in full or on a sample (17,428 judgments). - 48% of LLM outputs reach control flow or code execution; 73% of these never reach a person. - 82% of call sites have code checks before and after the call. Only 5.3% satisfy their whole expected contract; the median call site satisfies one third. - 67% of prompt-phase constraints are only requested from the model, including 268 that code could decide. - Fail-open: in Gemini CLI's opt-in policy enforcer, 5 of 6 return paths allow the call, including empty or unparseable replies. - 38 of 60 exploitable mechanisms triggered at runtime. Patches of 1 to 366 lines that enforce the missing constraint stopped the original exploit in all 38. Limits: the expected contract is a reconstruction, and trigger tests used one model. Triage call sites by the consumer of the output. Check in code that each proposed action is in the offered set, and fail closed on every error path. arxiv.org/abs/2610.24545

Search-augmented LLMs often answer from search snippets without opening a single page. Owen Walters, @LihuChen and Francesca Toni of @imperialcollege built 225 facts that changed after the models' training cutoffs (FDA labels, revenue, transfers, deaths, executive changes, carcinogen reclassifications). They traced every tool call. - Deployed run: GPT-5.6 Luna with its native web search answered 53.6% of episodes from snippets alone. - Same ten-result search menu for seven model configurations: the snippet-only share spans 2.6%-76.0%. - Snippet-only answers fail more: pooled over all seven, they are stale 6.4% of the time, against 1.3% when the model cites a page it opened. Unfaithful citations: 6.4% against 2.3%. - Stale answers carry unfaithful citations: on sourced open questions, 81.8% of citations on a stale answer contradict it (0.9% on current answers). - Page in the prompt: on 50 sports claims, gemma-4-31b's stale endorsements drop to 0 of 50 (14 with the search menu); qwen3-8b's only halve. - Restating the question after each opened page recovers 41 of 157 failed fact-sheet checks. - Mechanism: in failures, the page still promotes the current value in upper layers but barely suppresses the stale one, which wins at the output. Limits: one proprietary model (the lightest GPT-5.6 tier); layer readouts cover sports transfers in three open models and are correlational. Track reading depth per episode next to retrieval recall. arxiv.org/abs/2610.21731

Researchers at Microsoft M365 Research and IISc analyzed 121M production model calls from four M365 workloads to size the KV cache agents keep between calls. Holding every live Deep Research session at its peak would need an estimated 501.8 TB of GPU memory. Inference uses that state only 5.6% of the time it stays resident. The study comes from Mayank Arya, Agrim Bari and coauthors at @MSFTResearch and @iiscbangalore. - Shape: in Deep Research, the orchestrator issues 89% of model calls without new user input. Sessions that reach 30 calls carry a median context of 68K tokens, and 80% of context tokens hit the prefix cache. - Idle cap: dropping a session's KV after one idle hour caps the ceiling at 140.8 TB, 3.6x lower. Calls that recompute their context rise 0.46 points, to 4.53%. - Tight memory: in the busiest Deep Research hour, with 4.7 TB (10% of peak demand), least-recently-used (LRU) eviction makes 62.9% of calls recompute. Clairvoyant Belady eviction leaves 31.1%. Keeping an int4 copy in the same budget instead leaves 13.6%. - Routing: a Deep Research session touches 4.5 deployments on average. If KV stays local to each deployment, 20.2% of calls recompute even with unlimited memory. Limits: a Llama-2-70B KV layout stands in for the confidential models. The replay charges no quality or transfer cost for int4 copies. Before you buy more GPU memory for agents, check how long sessions sit idle and where the next call lands. arxiv.org/abs/2610.22863

Trying paperclip Surprisingly good. My Hermes is configuring it. Ridiculous. I thought we were 2 years from fully managing a company with agents. I'm assessing the shrink of 200 people to 20 max + agents. Very promising and optimistic

A 397B model that reviews a 4B model's agent steps matched the 397B-only success rate on τ²-Bench Airline (86.0%, 50 tasks) in 41% of the wall time. SpecAgent, from @ZhijiangG, @YinhongLiu2 and coauthors at @HKUSTGuangzhou, @hkust, @Cambridge_Uni and Yinwang, applies the draft-and-verify idea of speculative decoding to whole tool-call trajectories. - Draft. Qwen3.5-4B executes read-only tool calls for real, so each drafted step sees true observations. - Hold. The draft stops at the first state-changing action (a refund). That action waits. - Verify. Qwen3.5-397B-A17B reads the segment in one prefill pass and accepts the longest prefix it judges valid. A valid step counts even when the 397B would choose another. - Repair. When the fix is one tool call, the verdict carries it. Otherwise the 397B takes one repair turn. Token-by-token decoding is bound by memory bandwidth. Prefill reads a whole segment per weight pass. On Airline, the 397B makes 3.1 calls per trajectory instead of 13.8 alone. With GLM-5, DeepSeek or the 397B behind a cloud API, the cloud model writes 36-50% of its usual tokens and API cost falls to 59-81%. Pass@1 drops 9-13 points. Limits: estimated FLOPs rise 30-87%, so the gain needs memory-bound decode (below about 37 sequences per batch on H20). On AutomationBench SpecAgent recovers only 44% of the quality gap. Put the review gate at irreversible actions. arxiv.org/abs/2610.21463 @Alibaba_Qwen @sgl_project @Zai_org @deepseek_ai

Meta now trains production recommendation models on tens of thousands of AMD MI350X GPUs. Across ten models, throughput matches NVIDIA B200 at a geometric mean of 101.2%. Haoyu Zhang, Chunqiang Tang and 56 coauthors at @AIatMeta and @AMD report what it took (MICRO 2026). Beyond hipifying CUDA code, parity took work in four areas: - Atomics. MI350X has 8 chiplets, each with a private L2 cache. Under contention, atomic-heavy kernels can run over 10x slower than on B200. Kernels sum in shared memory with a tree reduction and issue one atomic per block. - GEMM tiles. Origami, an analytical model, picks tiles in microseconds at 93% of exhaustive autotuning. With thousands of GEMM shapes per model, lookup tables do not scale. - Collectives. Tuning took RCCL, AMD's collective library, to within 10-15% of NVIDIA's NCCL. It started 2x slower. - Memory. MI350X has 288 GB of HBM (B200: 180 GB). Bigger batches, no activation checkpointing and embeddings in HBM gave one model 1.26x over the direct port (1.5x with kernel work). An agent workflow encodes these fixes as skills. It succeeds on over 80% of dozens of production Triton kernels. Limits: the 101.2% compares equal GPU counts at matched batch sizes. GEMMs still run 1.3-1.7x slower, partly because TF32 is emulated with three BF16 GEMMs. Per-model ratios span 82%-130%, and Meta caps B200 at 750 W versus 1000 W for MI350X. Plan a second GPU vendor as a co-design project. arxiv.org/abs/2610.22230 @PyTorch @AMDServer @NVIDIAAI

essa pergunta na verdade não faz sentido. Na verdade são duas perguntas na verdade: - Eu preciso do design do Jony Ive para o que? - Quantos Jony Ive existem e que conseguem fazer um trabalho melhor que a IA? @brunofaggion

A remote KV cache tier can be slower than the GPU it feeds. Muhammad Ibrahim (@MultiverseCompu) serves GLM-5.3, an FP8 mixture-of-experts model with multi-head latent attention, on 8xB300 prefill nodes with vLLM and LMCache. A shared Valkey tier left median time to first token flat. The 16k-token p99 rose to 17.3 s (3.96 s before), and the team rolled the deployment back. The cost model has two terms: - Break-even bandwidth B* = s x R. KV bytes per token (48.4 KB) times node prefill rate (52.2k tokens/s) gives 2.53 GB/s. One Valkey instance peaked at 1.71 GB/s. A 16k-token prompt took 0.88 s to load and 0.31 s to recompute. - A fixed cost per hit, T0 ~ 0.33 s. Below about 17k tokens, recompute wins at any bandwidth. Synchronous loads stall all 8 context-parallel ranks. With one instance on a hit-heavy replay, the engine became an overloaded queue: p99 83.32 s with the GPUs 7% busy. The fixes: - Shard LMCache's KV store: chunk c belongs to rank c mod 8. - Give each rank its own Valkey instance. GET bandwidth rises 6.3x to 10.76 GB/s, with no cluster protocol. - Load asynchronously. - Fix three client bugs that froze engines. On the same replay, p99 falls to 0.67 s. On 200k-token prompts, sharding adds 14% prefill throughput, or 34% with an upstream kernel fix. Each condition ran once. The 17k figure is a model prediction. Test a cache tier against the prefill rate of the node behind it. arxiv.org/abs/2610.21500 @lmcache @vllm_project @valkey_io @Zai_org @NVIDIAAI

Multi-model agents break a serving assumption: every model fits in GPU memory. On one 80 GB GPU, a Llama-3.1-8B planner plus Qwen2.5 and Mistral-7B experts (15.2 GB each, FP16) compete with the KV cache of live sessions. JointServe, by Daijin Hu (Beihang University), runs on SGLang and uses the planner's output stream to choose what to load next. How it works: - Weight layer groups and session KV blocks share one budget. JointServe ranks each by expected recovery work avoided per byte. - An intent tap reads the output stream. When the tool-call header names an expert, prefetch starts while the planner still writes arguments. - Each model keeps its first layers resident. A swap then streams only the remaining layers in 0.14 s, short enough for 98% of SWE-bench tool gaps. - Evicted KV goes to host RAM. Reload takes 0.05 s. Re-prefilling the median SWE-bench context (27.5K tokens) takes 2.64 s. Results (one A800): - 24 GB usable: median session time 21.7% below the best whole-model swap baseline. - 8 GB usable: JointServe finishes in 758 s. Whole-model baselines miss the 35,000 s window. - SWE-bench traces: session time -49%, 2 model swaps per run vs 478 for the baseline. - OSWorld: median time to first token 0.1 s vs 31.7 s. The intent tap needs visible tool-call headers. Tests ran over PCIe 4.0 only. Your agent's call graph is a prefetch schedule you already have. arxiv.org/abs/2610.19822 @sgl_project @vllm_project @Alibaba_Qwen @MistralAI @AIatMeta

Most cost work on coding agents compresses tool output (observations) or routes turns to weak models. Across 600 public coding-agent trajectories, turn count explains 84% of the variance in log cost. Mean observation size explains 4%. Researchers at Penn State re-scored NVIDIA's Open-SWE-Traces (OpenHands, SWE-agent; Qwen3.5, MiniMax-M2.5). Their tool, TurnCost, rebuilds each turn's context and simulates the prefix cache. What cache-aware accounting shows: - 98.6% of input tokens are cache hits. Flat input pricing overstates loop cost by about 7.1x under near-ideal caching (4.0x at 90% cache efficiency). - Median observations are 118-286 tokens. The big build log that motivates compression sits near the 99th percentile. Edits, which echo file context back, carry 51.8% of observation tokens. - Swapping a whole turn to a weak model pays only if its input price beats the strong model's cached-read price (about 1/10 of list). Delegating one observation pays roughly when turns left exceed that price ratio. - Deterministic truncation matched weak-model delegation on cost in all 20 cell-threshold combinations. Cost grows with turns at exponent 1.23, which fits a loop where each turn re-sends every earlier one. The authors call the link associational and do not test removing turns at fixed task success. Before you tune a router, price the cache and count the turns. arxiv.org/abs/2610.15093 @penn_state @NVIDIAAI @OpenHandsDev @OfirPress @Alibaba_Qwen @MiniMax_AI

Not sure why Google treat their pro users like that.

ByteDance runs RDMA under its recommendation inference and training. Most of the engineering went into software above the NIC. ByteExpress (@ByteDanceOSS, @FudanUniversity) sits between ByteDance's RPC framework (Archon) and its RDMA NICs. It has run in tens of clusters for over two years (Toutiao, TikTok). The design has four parts: 1. bemalloc extends rpmalloc so network-bound buffers come from pre-registered blocks. Received buffers pass to app threads without a copy. 2. Sockets to the same host share one queue pair. Fragmenting large messages limits how long they delay small ones. 3. Receive credits: a sender posts a message only when the peer has a free receive slot. 4. A software send window caps bytes in flight per queue pair, above the NIC's built-in congestion control (DCQCN). In training, part 4 made the difference. The production job had 124 parameter servers and 346 trainers. On the busiest trainers, RDMA with hardware congestion control alone had worse P99 fetch and push latency than TCP. Priority flow control (PFC) pauses added up to 1 s in every 30 s. With the window, P99 push latency was 268 ms vs 1.03 s on TCP (-74%), with no PFC pauses observed. Inference at peak, matched load: parameter-fetch P99 of 35.5 ms vs 63.1 ms on TCP, and total CPU 51.3% vs 57.5%. Caveat: the baseline is ByteDance's deployed kernel TCP stack, with no tuned-TCP comparison. If RDMA is on your roadmap, budget for the software above the NIC. arxiv.org/abs/2610.12815