Abstract A paper posted to arXiv on September 14, 2026 makes a claim that should unsettle anyone who has spent the last year stuffing skill catalogs, tool schemas, and routing rubrics into a system prompt: the model already knows which skill it needs, and it knew before you paid to tell it. "The Router Within: Eliciting Native Skill Routing from a Frozen LLM" shows that a frozen agent LLM carries a usable routing signal in its own mid-layer forward-pass activations, and that two trained linear maps, no retraining of the base model, no retrieval index, no 1.2B-to-16B-parameter reranker bolted on the side, are enough to read that signal out. Source: Chen, Wang, Chen, Li, and Huang, "The Router Within: Eliciting Native Skill Routing from a Frozen LLM," arXiv:2609.15982, September 14, 2026. The method, called Gavel, beats both of the deployed patterns teams actually use today, skill metadata preloaded into context and retrieve-and-rerank pipelines, by up to 13.4 points on written tasks and up to 21.9 points when the need for a skill only becomes clear mid-rollout. This post walks through what Gavel does, why it lands on the same architectural bet this blog has made about model routing since RouteLLM, and what it means for anyone paying, in tokens, to tell a model things it can already tell itself. The two options everyone actually ships, and why both cost something This blog covered Agent Skills' progressive-disclosure design in July: keep a skill's name and one-line description resident in context, load the full body only when a task looks like a match. That is real compression, and the numbers back it up. But the paper's framing exposes the part that design doesn't fix. Progressive disclosure still preloads every skill's metadata into context on every single turn, which the authors describe plainly as something that "disperses the agent's attention and caps the library size." Source: arXiv:2609.15982. A team with 30 skills pays a small, constant tax per call. A team with 300 pays a much larger one, and past some point the metadata itself becomes the thing burying the answer, the same failure mode Chroma's context-rot benchmark measured across 18 frontier models: more tokens in the window degrades the model's ability to find the part that matters, well before any hard context limit is hit. The other deployed pattern, retrieval pipelines that embed the task and the skill library separately and rerank candidates outside the model, solves the context-bloat problem by moving skill selection out of the prompt entirely. It also moves it out of the agent. A separate embedding model, 1.2 to 16 billion parameters in the baselines this paper tested against, makes the call the agent itself never gets to reason about, and that indirection is exactly where routing errors accumulate silently: the reranker doesn't know what the agent has already tried, what it just learned three turns ago, or that the task's shape changed mid-rollout. Source: arXiv:2609.15982. Both patterns are the same tradeoff this blog has described for MCP tool catalogs: pay in context tokens up front, or pay in a separate model and a separate failure surface. Gavel's contribution is showing that a third option was available the entire time, because the frozen model was never actually blind to the skill library. It just needed someone to ask its activations instead of its output text. Glance, then verdict Gavel reads the routing signal in two stages, and the design is deliberately cheap: The glance. At installation time, one forward pass builds a compact representation, a "bank", for every skill in the library. At inference time, a glance projects the current task's mid-layer hidden states and each skill's bank through two trained linear maps, the only new parameters in the entire system, and scores the full library against those compact banks in one shot. No skill text enters the context window at any point in this stage. Source: arXiv:2609.15982. The verdict. The glance produces a shortlist, not a decision. For the shortlisted candidates only, Gavel resumes the forward pass and reads two things the model was computing anyway: its own likelihood over the candidate and a direct yes/no judgment on whether the skill applies. Those two signals fuse with the glance score as a product of experts, so a candidate has to clear both a cheap first-pass filter and the model's own considered judgment before it triggers. Source: arXiv:2609.15982. Trained once, the two linear maps transfer zero-shot to three public benchmarks and to SkillTraj, a new 372-trajectory benchmark the authors built for this paper specifically to test skill routing when the need for a skill only shows up mid-execution rather than being obvious from the task description alone. Source: arXiv:2609.15982. That mid-rollout case is the one that breaks both deployed patterns hardest: a preloaded metadata list can't route to a skill the task didn't originally look like it needed, and a retrieval pass run once at the start has no mechanism to reconsider once the trajectory changes shape. Three ways to route to a skill, and what each one spends to do it: full metadata in context on every call, a separate 1.2B-16B parameter retrieval model outside the agent, or two trained linear maps reading signal the frozen model already computed. The numbers, and the one that should get the most attention On Qwen3-32B, Gavel outperformed both baseline families by up to 13.4 points on written tasks, where the routing decision can be made from the task description alone, and by up to 21.9 points on the harder case where the correct skill only becomes apparent partway through execution. Source: arXiv:2609.15982. Those are the headline gains. The number worth sitting with longer is the one about scale: in a bash-agent harness, the same 32B model running Gavel triggered the correct skill on the Skill-Use benchmark more often than far larger frontier models running inside Codex. Source: arXiv:2609.15982. A smaller model with a cheap, well-targeted probe on its own internals beat larger models reasoning over the skill catalog in plain text. That is the exact shape of result this blog keeps finding wherever someone actually measures it: the frontier model is not a substitute for the right architecture, and a well-designed cheap check beats an expensive model doing the wrong kind of work. The authors are also specific about what the added parameter cost buys, or rather doesn't: zero external parameters, versus the 1.2 to 16 billion the retrieval baselines require, and routing accuracy that improves as the backbone model improves, rather than being capped by a separately trained, separately maintained reranker. Source: arXiv:2609.15982. Discussion: this is the same argument, one layer down Nadir's own routing decision, which model handles a given request against a measured quality floor, is not skill routing. It is a different layer of the same stack, choosing a backbone rather than a capability the backbone can call. But the design principle Gavel validates is exactly the one this blog's OCR closed-loop routing post argued for and the one behind routing a request through a classifier that runs in about 50 milliseconds: the decision does not need the full weight of a frontier-model conversation to get made correctly. It needs the smallest signal that actually predicts the outcome, read cheaply, with verification available for the cases the cheap signal can't resolve on its own. Gavel's glance-then-verdict structure and Nadir's classify-then-escalate structure are answering the same question, at different points in the request: is there a cheaper way to know this, and can we check ourselves before we commit to the expensive path? The part of this paper that should worry anyone maintaining a large, hand-rolled skill or tool prompt is narrower and more immediate. If a research team can get a 32B model to out-route Codex-scale frontier models on skill selection using two linear maps and zero added context, then every extra paragraph a team is currently pasting into a system prompt to help an agent "remember" which tool to reach for is very likely doing less work than it costs. The 69% system-prompt token finding from Datadog's engineering audit was already evidence that most of what lives in a system prompt is bloat nobody re-examines. Gavel is evidence that, at least for skill and tool selection, the fix isn't a shorter prompt. It's routing the decision somewhere the tokens never had to go in the first place. What this changes if you're building a multi-skill agent today Don't assume progressive disclosure is the ceiling. It's a real improvement over dumping every skill body into context, but the metadata line for every installed skill is still a per-call tax that scales with library size. If your catalog is past a few dozen skills, that tax is worth measuring directly rather than assumed away. Treat a retrieval reranker as a stopgap, not an architecture. It solves the context problem by creating a second model to maintain, retrain, and debug when it disagrees with the agent. That's a real cost with its own failure modes, not a free win. The mid-rollout case is the one to test for. Most internal evals of skill routing are run against tasks where the right skill is obvious from the prompt. The harder, more common failure in production is a task that changes shape three steps in, and that's exactly the gap Gavel's SkillTraj benchmark was built to expose. The same discipline applies one layer up, at the model you're calling. However your agent decides which skill to reach for, the underlying request it eventually sends is still a normal completions call, and it still gets cheaper or more expensive depending on which backbone answers it. Compression and routing already compound on the context side of that call; a cheap, verified routing decision is the same multiplier applied to the model-selection side. Point model=auto at Nadir and the request that survives your skill router still gets routed to the cheapest model that clears your quality bar, checked before it's trusted, escalated only when the check fails, no separate reranker to run, no prompt rewrite required. Sign up and route your first request. FAQ Q: What is Gavel, in plain terms? A: Gavel is a method from a September 2026 paper that lets an LLM agent pick the right skill from a large library without putting any skill descriptions into its context window. It reads a routing signal that already exists in the model's own mid-layer activations using two small trained linear maps, then double-checks the top candidates by resuming the model's forward pass and reading its own likelihood and yes/no judgment on each one. Q: How is this different from Retrieval-Augmented Generation (RAG) for tool or skill selection? A: A typical retrieval pipeline embeds the task and the skill library with a separate model, often 1.2 to 16 billion parameters in the paper's baselines, and reranks candidates outside the agent entirely. Gavel does the equivalent job using signal already present inside the frozen agent model itself, adding zero external parameters, and its verdict stage lets the agent's own judgment confirm or reject the shortlist rather than trusting an outside reranker unconditionally. Q: Does this replace progressive disclosure, the approach Anthropic's Agent Skills format uses? A: It targets the specific cost progressive disclosure doesn't remove: every installed skill's name and description still sit in context on every call under progressive disclosure. Gavel removes that resident metadata entirely for the routing decision itself, though a team could still use progressive disclosure's loading order for the skill body once Gavel has already selected it. Q: Why does the mid-rollout routing case matter so much? A: Because it's the failure mode that shows up in real agent trajectories and rarely in simple benchmarks. A task's true skill requirement often only becomes clear a few steps into execution, after the agent has already read a file, hit an error, or gotten a result that changes what it needs next. Both preloaded-metadata and single-pass retrieval approaches struggle here; the paper's SkillTraj benchmark was built specifically to measure it, and it's where Gavel's largest margin, 21.9 points, showed up. Q: Does this apply to choosing which LLM handles a request, not just which skill an agent calls? A: It's a different layer, skill selection happens inside a single model's own reasoning, while model routing chooses which backbone answers the request at all, but the underlying bet is the same one this blog has made about model selection: a cheap, targeted signal checked before it's trusted beats an expensive default paid on every call. That's the same principle behind Nadir's classify-then-escalate routing, applied to a different decision.