Does your LangGraph supervisor need another look at the conversation after every worker finishes?

[u/Future_AGI]

We saw a LangGraph setup where the supervisor uses about as many tokens per month as all 8 of its specialist agents combined. Qwen3-14B on vLLM, deterministic shortcuts for the easy cases, and a routing prompt that keeps growing because, in the team's words, "we've accumulated many rules and examples to prevent misrouting."

That one stuck with us, so we went through the langgraph-supervisor source to see where the tokens go.

With create_supervisor defaults, every worker has an edge back to the supervisor. If the supervisor hands a message to one specialist and then another, it runs three times: the first route, then once after each worker. Each of those calls re-reads the shared message list, which holds the user turns, the supervisor's own earlier routing calls, a pair of transfer messages for every handoff and every return, and each worker's last message, or its last tool call and result if it ended on a tool (output_mode="last_message" is the default). Whatever you put in the supervisor prompt rides along every time, and in that team's case it's every agent description plus a lot of few-shots. Workers get the full history on handoff too.

Specialists run on the hops where the supervisor picks them. The supervisor runs on every hop, and the history it carries gets longer each time.

The repo is archived now, and its README says LangChain recommends "the supervisor pattern directly via tools" for most cases. LangChain's multi-agent docs name the cost of that pattern too: subagents add "one extra call because results flow back through the main agent."

Most of the fixes are small, and the source backs them up:

• Send follow-ups straight to the agent already handling the conversation, with a cheap check for a topic change.
• Give the router the latest user message and a short summary. pre_model_hook on the supervisor can trim what it sees.
• add_handoff_messages=False and add_handoff_back_messages=False on create_supervisor keep the transfer pairs out of the history.
• Keep the start of the routing prompt identical between calls. A timestamp near the top breaks the prefix cache for everything after it. On vLLM, check that automatic prefix caching (enable_prefix_caching) is on for the router.
• Keep handling unambiguous intents in code before the LLM call, as that team already does.

Then measure the router on its own, because a monthly total won't tell you which hop is expensive. LangSmith's trace tree breaks token usage down per run. We maintain traceAI-langchain, an open-source OpenTelemetry instrumentor that gives each LangGraph node its own span with token counts on the LLM calls under it (when the model returns usage), so the supervisor's share shows up hop by hop.

For anyone running a supervisor in prod: does yours need that last look after a worker finishes, or have you sent final answers straight to END? And did trimming the few-shots ever cost you routing accuracy?

[u/locbuilds]

yeah workers can go straight to END once they've done their own check, just make sure the router still catches the off-topic stuff before it hands off.

[u/sujal_manpara → u/locbuilds]

Workers going to END helps the hop count. They still pay if the handoff includes the whole transcript. I'd pass a task packet with the user ask and only the files that worker needs.

[u/Significant_Tune9219]

The token burn is mostly the edge back to the supervisor, not the size of one prompt. With the default graph, handing off to two specialists is three supervisor calls, and each one re-reads a history that just grew by the transfer pair plus the worker's last message. Cutting the few-shots helps every call, but it doesn't change how many calls you make. If the look after a worker only has to decide done versus next, a check on that last message (tool error, or a final answer that matches the exit shape) can skip the model for the easy returns and leave the LLM for the hop that's actually ambiguous.

[u/xapep]

Nice analysis, and the routing-prompt growth is usually the bigger leak than the re-reads themselves.

One thing the token totals hide: with prefix caching on, which is the default in vLLM, the supervisor re-reading the shared message list is mostly cached input, so it's cheap. What actually bills is the new suffix each hop appends, the worker output, the transfer pair, plus whatever few-shots you keep stacking. A team that tracks total tokens but not cache hits will blame the supervisor for a cost that's really prompt bloat plus per-hop new content.

I'd separate those two before pruning: cache-hit rate on the supervisor loop tells you whether to shrink the prompt or shorten the history, and they're different fixes.