What I learned:

The 86% is a conditional probability, not an error rate, and almost every repost drops the condition - Artificial Analysis's AA-Omniscience hallucination rate is incorrect divided by (incorrect + partial + not attempted), so the denominator holds only the questions the model failed to answer correctly. @0xGenpix states the condition correctly and it is the only viral framing in the window that does: "86% GPT-5.5 hallucination rate when uncertain. 50% Claude Opus 5 hallucination rate - up 14 points from Opus 4.8. 36% Claude Opus 4.7 hallucination rate," adding that "GPT-5.5 leads on factual accuracy at 57% - the highest ever recorded - and also confidently invents answers in 86% of cases when it lacks the truth." Strip the words "when uncertain" and the number becomes a claim nobody made. The two headline figures are the same fact stated twice: it knows more than anything measured before, and it almost never says "I don't know."

The best explanation of why the number is unreadable is a French-language reply with six likes - @DIMENSION_YT walks the arithmetic: the percentage is computed only over the failures, so a model with 98 right answers, 1 wrong answer and 1 "I don't know" lands at 50% hallucination, and 99 right with 1 wrong lands at 100%. Same model, near-perfect accuracy, catastrophic-looking headline number. The same post names the second condition that never survives the screenshot: AA-Omniscience allows no tools and no web search, which is not how anyone actually runs these models, especially for the reference-lookup tasks the questions are drawn from.

The same model wears two different hallucination numbers and both are correctly computed - CodingFleet puts the divergence in one line: Claude Opus 4.7 is "12.0% Vectara (concerning) but 26.2 AA-Omniscience Index (excellent). It fabricates more in summarization than most peers, but it's one of the best at saying 'I'm not sure' when it genuinely lacks knowledge." Suprmind has the extreme case: Llama 4 Maverick at 4.6% on Vectara's older dataset and 87.6% on AA-Omniscience. Vectara's HHEM leaderboard (3.3K stars, 19 open issues) measures whether a summary stays faithful to a document you handed the model. AA-Omniscience measures whether a model bluffs on closed-book knowledge. Those are different failure modes and there is no reason for them to correlate.

Even the Vectara number is two numbers, because the leaderboard forked and most citations use the retired one - Vectara's own blog says the original dataset "has served its purpose" and ships a replacement built on 7,700+ articles across law, medicine, finance, education and technology. Suprmind notes plainly that "the leaderboard exists in two versions, and the gap between them tells an important story," and that the legacy April 2025 set "is the dataset most articles reference when they quote hallucination rates" - short documents, straightforward summarization. The same source flags the counterintuitive result on the harder set: reasoning models, the ones marketed as most capable, consistently do worse on grounded summarization.

The benchmark's own peer review says the denominator is wrong - the published critique of arXiv 2511.13029 is that the formula i/(p+i+a) "conflicts with its textual description" and should be clarified to i/(p+i) or i/(c+p+i) with sensitivity analyses. The practical consequence is that a model can improve its hallucination rate by abstaining more without learning anything, and a model that attempts everything gets punished twice. Benchgen frames the design goal charitably - "models should answer when confident and abstain when uncertain" - then concedes that "most frontier models fail this calibration, scoring below zero," meaning they hallucinate more than they answer correctly.

The one real 30-day movement is Opus getting worse on exactly the axis the metric measures - @jason_haugh quotes the finding that Opus 5 "improves +7 points on AA-Omniscience Accuracy over Opus 4.8, but answers more often when uncertain - its hallucination rate rises +14 points to 50%," and reads it against the vibe curve: "At first Opus 5 was great, crushing tasks. And then as people started looking into those tasks, they started to walk their praise back." @talwar_divyam independently lands on the same reading: "confidence is outpacing accuracy even on the rigorous stuff." The Zvi corroborates from the qualitative side, with Max Weinbach and several agreeing commenters describing "Opus 5 being wrong and confidently saying shit then I keep having to correct it." Accuracy and hallucination rose together, which is what a calibration metric looks like when knowledge outpaces restraint.

Artificial Analysis itself publishes the metric as a decomposition, which is how the number is supposed to be read - @ArtificialAnlys on DeepSeek V4 Flash 0731: it "scores -16 on the AA-Omniscience Index, a 7 point improvement over DeepSeek V4 Flash (-23), driven entirely by a lower hallucination rate. The hallucination rate falls 11 points to 84% while accuracy is unchanged at 37%." That is the honest shape of the claim - index, accuracy and hallucination rate quoted together, with the causal attribution stated. The screenshots circulating on X keep only the third number.

The rate gets weaponized in an argument that has nothing to do with calibration - @pukerrainbrow, 91 likes: "Claude Fable 5 hallucinates more than Kimi K3 (the open model everyone wants banned) - Same benchmark, AA-Omniscience. Fable: 54.9%. K3: 51%. Lower is better here. K3's rate did climb from 39% last-gen, but its accuracy climbed too, 33% to 46%. Both moved together. One of these labs is being framed as a national security risk. It's not the one with the higher hallucination rate." The post is also the cleanest demonstration in the corpus of why the paired reading matters: K3's rate rose because its accuracy rose.

The practitioner conclusion across every source is the same, and it is not "pick the lower number" - Digital Applied's Kimi K3 writeup ends on the operational version: "Re-run the harness you already own, add an abstention-rate metric, and gate the swap on that - not on a leaderboard rank." The Bearded AI Guy makes the structural argument that "the top of every leaderboard now sits inside its own margin of error," and The Source Layer says the differentiators "are buried in task-specific metrics." On r/LocalLLaMA the same complaint arrives without the vocabulary: "I've been noticing a massive disconnect lately between how models perform on technical leaderboards and how they actually perform in real-world tasks."

Where the discussion is thin is the tell - despite 27 Reddit threads and 25 HN stories pulled in the window, essentially none of them are about hallucination benchmark methodology. The r/LocalLLaMA and r/ClaudeAI layers are dominated by hardware, model drops and Qwen/Kimi release chatter; the only on-topic Reddit artifact is a r/ClaudeCode PSA on the Opus 5 and Opus 4.8 hallucination trade-off. The entire methodological argument in the last 30 days lives on X, in vendor and aggregator blog posts, and in the benchmark's own arXiv review - not in the communities that quote the numbers most.

KEY PATTERNS from the research: 1. The 86% is conditional on the model already being wrong or abstaining - denominator is incorrect + partial + not-attempted, per Artificial Analysis 2. High accuracy and high hallucination rate are compatible and often co-move; GPT-5.5 holds the record 57% accuracy alongside the 86%, per @0xGenpix 3. A model can improve the metric by abstaining more without learning anything - the flagged flaw in i/(p+i+a), per the review of arXiv 2511.13029 4. Cross-leaderboard comparison is meaningless: Opus 4.7 is 12.0% on Vectara and 26.2 on AA-Omniscience because one scores summarization faithfulness and the other closed-book recall, per CodingFleet 5. Even within Vectara there are two live datasets and most cited numbers come from the retired one, per Vectara 6. AA-Omniscience runs closed-book with no tools and no web search, which is not the deployment condition anyone uses, per @DIMENSION_YT 7. Most frontier models score below zero on the Index, meaning more incorrect than correct answers on this question set, per Benchgen 8. The recommended substitute for leaderboard rank is your own harness plus an explicit abstention-rate gate, per Digital Applied

What I learned:

The corpus itself is the first result - a category this heavily built has no public argument about it - the engine's Reddit search 403'd for every subquery and the fallback surfaced subreddit front pages instead of topic matches, so the 18 threads and 10,412 upvotes in the footer below belong to Qwen3.8, DGX Spark clusters and data-center water, not to anything about turn-taking. Treat that Reddit line as zero on-topic evidence. Hacker News was genuinely searched and genuinely empty: 10 stories, 66 points total, with the single most on-topic story, The Hard Parts of Streaming Audio in Voice Agents, closing at 3 points and 4 comments, Show HN: Jargo, a Go port of Pipecat at 10 points and 3 comments, and New Realtime models on the API at 3. X produced 4 posts and 54 likes. Nineteen web pages, almost all vendor or SEO-shaped, carried the entire discursive layer. If you are deciding endpointing policy today, you are deciding on vendor blogs and issue threads.

The honest lived-experience record is in livekit/agents issues, where the tradeoff is stated as a bug rather than as advice - issue #3701 is the whole problem in one report: default settings produce an end_of_turn_delay of roughly 700-800ms, and reducing the endpointing delay causes the agent to cut users off mid-speech. Issue #3427 names the structural version - interruption logic is shared across the agent's thinking and speaking states and cannot be tuned independently, so it is not possible to make an agent hard to interrupt but still friendly to slow speakers. Issue #4325 reports that the same config number means different latency depending on mode: in VAD mode the effective delay is roughly max(VAD_min_silence, min_endpointing_delay), while in STT mode the full min_endpointing_delay is always added after STT end-of-speech. Issue #5669 is worse, because it is the metric lying rather than the agent misbehaving - with vad=NOT_GIVEN and turn_detection="stt", end_of_turn_delay collapses to endpointing.min_delay on every turn. LiveKit carries 12K stars against 733 open issues where Pipecat has 14K stars against 213, which is where the surface area of this problem actually lives.

Barge-in is a systems number, not a model number, and that is the sentence the whole corpus keeps rediscovering - Roark states it directly, that barge-in is a round trip and stop latency therefore cannot be inferred from LLM traces alone. RunEdge frames it as the same latency budget "run backwards, under harder conditions, while two people are talking at once." Wildrun AI supplies the failure mode: STT, the speech model and TTS each do their job correctly and the interruption still fails, because the failure lives in the integration nobody wrote - "the glue is the product, and the glue was the part bolted on last." Building Agentic AI draws the resulting architectural line, that real-time barge-in belongs to the media layer and not to an orchestrator's interrupt(), because inside the roughly one-second budget of a voice turn LangGraph is the decision node in the loop and not the audio path.

The advice numbers have converged so completely that they read as copied, and none of them come with a reproducible harness - a 200-400ms turn-taking gap, a false barge-in rate below 2% and a TTS flush below 60ms appears near-verbatim across Vomyra and Future AGI; Auto Interview AI puts the natural-feel threshold at sub-400ms end to end. Against that, Cekura's orchestration benchmark measures the fastest platform, ElevenLabs, at a 1.73s median. The advice is in milliseconds and the measured platform medians are in seconds. Cekura's own framing is the useful part - turn-taking is set by the platform, not the prompt, because VAD and end-of-turn detection decide when the agent yields. Telnyx supplies the counterweight to the headline metric: an agent that responds in 180ms but fails on barge-in handling is still not production-ready. The only harness anyone points at is a Telnyx reference implementation on the barge-in GitHub topic page.

VAD is not being tuned, it is being removed from the decision - the bluntest version on X is @Narperx's build list - "aim for total response latency under 500-800ms > ditch vad (it's dog shit) > move to end-of-turn detection on the stt side > handle barge-in / interruptions cleanly." AssemblyAI documents the mechanism: setting turn_detection="stt" tells LiveKit Agents to use the STT model's own end-of-turn signal instead of LiveKit's turn detector. Cekura supplies the distinction that makes it obvious - VAD classifies a single frame of audio as speech or non-speech, while endpointing decides whether the caller finished their whole turn. The same move is being requested one layer down in sglang-omni issue #968, asking for the reserved-but-unimplemented semantic_vad mode so the server decides end-of-turn from the content of speech rather than a fixed silence timeout. The counter-position is @yibie's pitch for the TEN framework, whose custom VAD is claimed to beat Silero by hundreds of milliseconds on speech-to-silence transitions - a framework that exists, in his framing, because most voice agents either talk over you or cannot tell when you are done.

Full duplex landed as a shipped product this window while the developer surface stayed half-duplex - GPT-Live decides many times per second whether to speak, keep listening, pause, backchannel with a "mhmm" or invoke a background tool, and OpenAI extended it to Codex and desktop per VentureBeat. But there is still no GPT-Live API - the practical path remains the Realtime API, which Apidog characterises precisely as "fast half-duplex: excellent interruption recovery, but the model isn't speaking while it listens, and it won't backchannel while you talk." So every team shipping full-duplex behaviour today is still assembling it, which is exactly why the issue trackers are where the reports are.

What changes under full duplex is the test suite, and that is the most concrete new work in the window - Roark defines false barge-in rate as the fraction of agent-side stops that were not real interruptions, and specifies a test corpus that must include coughs, keyboard noise, background TV, a second voice in the room and typed-message notifications - plus backchannel yield rate, measured against a "mhmm." Wildrun AI gives the frequency that makes this worth building: barge-in occurs in roughly one in five calls, and the naive implementation self-interrupts every time the caller says "mm-hmm" or "yeah okay." The academic layer moved the same way, with Full-Duplex-Bench-v3 benchmarking tool use for full-duplex voice agents under real-world disfluency.

KEY PATTERNS from the research: 1. The discussion layer does not exist - the 18 Reddit "threads" are off-topic listing fallback after a search 403, HN totals 66 points across 10 stories, and 19 vendor web pages carry the entire argument, per HN 2. The one number practitioners actually report is the one guides omit - roughly 700-800ms default end_of_turn_delay, with cutting users off as the direct cost of lowering it, per livekit/agents #3701 3. Interruption sensitivity is not independently tunable across thinking and speaking states, so "hard to interrupt but friendly to slow speakers" is currently unbuildable in LiveKit, per livekit/agents #3427 4. Barge-in is a round trip and stop latency is a systems number you cannot read off LLM traces, per Roark 5. The in-window architectural move is deleting VAD from the turn decision in favour of STT-side or semantic end-of-turn, per @Narperx and sglang-omni #968 6. Guidance says 200-400ms while the fastest measured platform median is 1.73s, so the advice and the instrumentation are an order of magnitude apart, per Cekura 7. Full duplex shipped as a product with no API, so teams keep hand-building it on a fast half-duplex Realtime API, per Apidog 8. The measurable target moved from latency to false-barge-in rate and backchannel yield rate, tested against coughs, keyboards and a second voice in the room, per Roark

What I learned:

The assignment button is now generally available in all three trackers, and it shipped faster than the evidence - Copilot cloud agent for Linear went GA on 23 July: assign an issue, the agent analyzes it, opens a draft PR, works in an ephemeral GitHub Actions environment and streams progress back to the Linear timeline. Atlassian shipped the Jira equivalent five days earlier, letting teams "assign work items directly to Claude Code, Cursor, or GitHub Copilot, with Codex coming soon." DevOps.com covered the control layer that arrived with it: workspace and team-level agent guidance so "delegated issues automatically inherit" defaults. Three trackers, one month, and not one of them published a merge rate.

The one team that did publish numbers is Microsoft's, and the number is 68% - the dotnet/runtime ten-month retrospective is the hardest document in this entire corpus: 878 Copilot Coding Agent PRs, 535 merged, 67.9%, and 2,963 PRs across seven repos at 68.6% for roughly 271,000 net lines. Read that as the realistic ceiling from a team with world-class CI, not a floor. Roughly a third of assigned tickets produce work that gets thrown away, and someone still had to read every one of those PRs to decide.

Success is a property of the ticket, not the agent - the same dataset splits cleanly by task type: cleanup and removal work merges at 84.7%, performance work at 54.5%. The team's own explanation is the useful part, that the agent "can implement a complicated SIMD optimization if you tell it exactly what to do, but it struggles with the analysis part," and will assert "this improves performance by 2x" without validating it. They stopped assigning platform-specific CoreLib and networking issues entirely, because the agent submits code it cannot test. A separate clustering of 999 Copilot-authored PRs lands in the same band, 75.4% merged overall with config-and-defaults work at 66%, which means any vendor quoting you a single success percentage without a task breakdown is quoting nothing.

The highest-leverage variable is your setup instructions, and it is not close - dotnet/runtime PRs before the team's first setup changes merged at 38.1%; after, 69%. The fix was mundane, adding setup steps so the agent stopped timing out trying to build the whole repo, a build that takes 20+ minutes on fast hardware. Their own summary of the gain is the line worth keeping: "not through better AI models, but through better preparation." This is the single most actionable finding in the window and it involves no model choice at all. The same instinct shows up in the wild, joshuaswarren/remnic adding an AGENTS.md scope-discipline section because the repo "had no guard against the two ways agents drift off the deliverable: inventing process artifacts, and gold-plating code nobody asked for."

The bottleneck moved to review, and the research says review is degrading under load - Generative Labs surfaces the finding that should worry anyone rolling this out: a Carnegie Mellon synthesis of 3,100 practitioner documents found agent-authored PRs get "lower review rates, faster merges, and less discussion than human-authored ones." A companion CMU/Stanford study of 802 developers and 196,212 PRs at a company under an explicit 2x productivity mandate hit 2.09x per-capita throughput while per-reviewer load roughly doubled and automated review overtook human review. The peer-reviewed version (When Code Authors Are Agents, arXiv 2602.19441) adds that agent PRs integrate faster but merge less often, beat humans on documentation, underperform on behavior-changing contributions, and attract proportionally more bot comments and less socially engaged review. On Hacker News the practitioner version of this went almost entirely unnoticed at 7 points: "We 3.5x'd Our Pull Requests with AI: Now We Catch Fewer Bugs".

The counter-evidence is real and worth holding onto - the same window produced a large Microsoft study finding CLI agent users merged roughly 24% more pull requests over four months, and a Mergify analysis of over 200,000 merges across 477 engineering teams finding AI-assisted PRs broke main about half as often as non-AI ones, 1.9% against 4.4%. Both sides can be true: more throughput and fewer broken builds, alongside less scrutiny per change. The disagreement is not about volume, it is about what a merge signals now.

The named failure mode is over-literal ticket resolution, and it costs a senior engineer an hour - Atlassian wrote the sharpest description of it in the corpus, and it is notable that a vendor shipped it in a launch post: "They solve the ticket too literally. They miss the architectural constraint. They generate a PR that looks plausible until a senior engineer spends an hour unwinding it." Qovery names the mechanical version: "Cursor, Codex, and Claude Code write code, but they can't spin up a database, seed test data, or run your E2E suite - so they produce PRs that look right and break in staging." That matches dotnet/runtime exactly, where 65.7% of agent-added lines were test code and the untestable areas got fenced off.

The GitHub layer accidentally shows what these PRs actually look like, and it is bots reviewing bots until the quota runs out - the on-repo evidence is more revealing than any blog post. EffortlessMetrics/perl-lsp-swarm#4187 carries a stack of coderabbitai[bot], gemini-code-assist[bot] and github-actions[bot] comments, with Gemini's contribution being "You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!" On ahmdelbaz28-ux/BAZspark#280 the top comment is vercel[bot] reporting "Resource is limited - try again in 24 hours (more than 100, code: api-deployments-free-per-day)." Agent-authored PRs arrive faster than the review and deploy infrastructure metering them, which is the same finding as the CMU bot-comment result, just visible in raw form.

Cost control is the loudest live complaint, and it is a routing problem - the highest-engagement GitHub thread in the corpus is openai/codex#31814 at 199 reactions and 100 comments, where subagents cannot be assigned their own model and inherit the parent. winoros puts it bluntly at 7 votes: "All agents spawned from the sol xhigh are sol xhigh. This is ridiculous. Simple tasks spawned from sol xhigh or higher should use a lighter model." Hacker News asked the operational version: "Are your teams running out of GitHub Copilot credits?" When a ticket assignment silently books a frontier model for every subtask, the tracker button is a spend button.

The single highest-scoring on-topic story of the month was a breach of the delegation path, not a benchmark - GitLost: We Tricked GitHub's AI Agent into Leaking Private Repos took 541 points and 205 comments on Hacker News, an order of magnitude above anything else here. The assignment surface is the attack surface: an issue body is untrusted input that an authenticated agent with repo access reads and acts on.

The workflow that genuinely closes end-to-end is the one where a machine wrote the ticket - @MSFTMechanics describes the only fully closed loop in the corpus: a Defender for Cloud recommendation creates a GitHub issue containing deployment info, matching CVEs and remediation guidance, you assign that issue to the Copilot coding agent, it generates a draft PR, you merge, and Defender shows the CVEs resolved. Every ambiguity the Atlassian post complains about was removed before assignment, because no human wrote the ticket. That is the strongest available hint about which of your backlog items are actually delegable.

Product teams have already conceded the point and are building steering UIs instead of autonomy - Linear's changelog this month is not about better delegation, it is about interrupting it: "Open any diff and switch to the Changes tab to inspect the code. When you spot something to change, tap the relevant line to add it to your message to steer the coding session in the direction you want." Copilot's documented halt behavior points the same way, iterating through a bounded number of test failures, typically three, then stopping and flagging the ambiguity in PR comments for a human. The 2026 shape is a supervised session, not a fire-and-forget assignment.

The practitioner layer is close to silent, and that is itself the finding - Reddit's on-topic thread for this entire question is "Maintaining team velocity despite coding agents" at 10 upvotes and 50 comments, a five-comments-per-upvote ratio that reads as contested rather than settled. What r/ExperiencedDevs is actually loud about this month is the second-order effect: "Has anyone else been given AI and then forced to do a combined role of FE, BE, and QA work?" at 249 points and 254 comments, and "I miss when development was actually solving problems" at 708 points and 294 comments. Working engineers in this window are not debating agent merge rates; they are describing what happened to their job after the delegation button appeared.

KEY PATTERNS from the research: 1. Budget for a 68% merge rate, not a 100% one - the only public multi-repo dataset is Microsoft's own dotnet/runtime retrospective at 67.9% in-repo and 68.6% across seven repos, so a third of assigned tickets is rework you still have to read 2. Sort your backlog by task type before you sort it by agent - cleanup and removal merges at 84.7% while performance work merges at 54.5%, and the split is about whether the ticket requires judgment or just execution 3. Fix setup before you fix model choice - dotnet/runtime went from 38.1% to 69% by adding setup steps and killing a 20-minute build timeout, "not through better AI models, but through better preparation" 4. Assume review quality drops as agent volume rises - per the Carnegie Mellon synthesis of 3,100 practitioner documents, agent-authored PRs draw lower review rates, faster merges and less discussion, and the CMU/Stanford throughput study found reviewer load roughly doubled while automated review overtook human review 5. Fence off anything the agent cannot execute against - per Qovery, agents "can't spin up a database, seed test data, or run your E2E suite - so they produce PRs that look right and break in staging," which is exactly why Microsoft stopped assigning platform-specific CoreLib and networking issues 6. Treat the issue body as untrusted input to an authenticated agent - the GitLost private-repo leak at 541 points was the biggest on-topic story of the month, well above any productivity result 7. Meter the assignment, because the tracker button is a spend button - per openai/codex#31814 at 199 reactions, subagents inherit the parent's frontier model with no way to route simple work to a cheaper one, and the on-repo evidence shows review and deploy bots hitting daily quota limits mid-PR 8. The delegable tickets are the ones a machine could have written - the only end-to-end loop in the corpus is @MSFTMechanics's Defender-to-Copilot CVE pipeline, where the issue arrives pre-specified with deployment info and remediation guidance