Session

Saying No: Admission Control When Your Coding Agent Overwhelms Your Own LLM

## Background

When a coding agent fans out into forty parallel tool calls against an LLM you host yourself, the interesting failure is not the model or the engine. It is the seam between them. This talk is about the layer that decides which requests to accept before they touch the GPU, and what a systematic review of fifty five papers says most people are getting wrong about it.

## Abstract

Coding agents do not send one request at a time. They fan out, they retry, and they burst. If the LLM they hit is one you host yourself, the natural failure mode is not that the model is wrong or the engine is slow. It is that your inference layer accepts every request and then buries the ones you actually needed to finish first.

Admission control is the seam that decides which of those requests to accept and which to refuse before they touch the GPU. The theory is old, the practice on LLM serving is barely started, and the sixteen published policies compare against different engines, different traces, and different baselines, so nothing lines up. A systematic review of fifty five papers across OSDI, SOSP, NSDI, MLSys, ASPLOS and EuroSys finds one uncomfortable fact underneath the mess: none of the sixteen policies report the operating range of the signal they read on. A policy that watches KV pressure will happily admit every request while the signal never leaves a narrow band, and its results table will look ordinary.

This talk walks through the five questions to ask about any admission policy before you deploy it under a coding-agent load (unit, setting, objective, signal, portability), maps eight real production incidents at OpenAI, Anthropic, Cloudflare and Azure onto the admission failure modes the literature already names, and shows the probe that catches a policy whose signal never moves. You leave with a checklist you can use on Monday and a clear picture of why the layer under your coding agent is the one your postmortems keep naming.

## Takeaways

- Why admission control is the layer under your coding agent that decides whether your GPU stays useful, not just busy.
- A five-question checklist (unit, setting, objective, signal, portability) for evaluating any published admission policy before it goes near your stack.
- Why the sixteen published policies do not compare cleanly, and the one reporting item that would fix it if authors added it.
- How eight real production incidents at OpenAI, Anthropic, Cloudflare and Azure map onto admission failure modes the literature already names.
- A probe you can run against your own inference stack in an afternoon to catch a policy whose signal never actually moves.

Extra Resource:
- AdmitPerf - github.com/harshuljain13/AdmitPerf
- LLM Inference at scale - https://github.com/harshuljain13/llm-inference-at-scale/tree/master

Harshul Jain

Audible, Senior Software Engineer

Newark, New Jersey, United States

Actions

Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.

Jump to top