IndyDevDan’s latest video, “Elite agentic engineers are leaving the loop”, says the next step is agents that start on a trigger or a cron, survive a closed laptop, and do real work before you sit down. Agreed. And once nobody is watching, every token an agent spends reading code it didn’t need goes unnoticed until the bill or the usage limit shows up.
What does “leaving the loop” mean for coding agents?
In the loop, you prompt and review every step. Near the loop, you set the agent off with a prompt, a click or a schedule, and check in. Out of the loop, durable agents run on triggers and report back. IndyDevDan’s video argues that most of what we babysit in a terminal today can move out there with the right setup around it.
Why does token cost matter more when nobody is watching?
Sitting in the loop, you see the agent open a 2,000-line file to answer a question about one function, and you stop it. Out of the loop, nobody stops it. That file then rides along on every request after it, so the agent pays for the read again and again.
If the run bills per token, that’s money. On a subscription, it’s the limit you hit before morning. The video is blunt about where this goes: “insanely subsidized subscriptions will not last forever.” Picking a model that won’t break the bank is one half. What the agent reads is the other.
How do you give an agent exactly the code it needs?
IndyDevDan’s damage-control example is the best line in the video: take the bash tool away and give
the agent exactly the results it wants. For reading code, that’s what jCodeMunch does. It indexes the repo once.
The agent then asks for a symbol by name with search_symbols and gets the one function back by
byte offset with get_symbol_source, instead of grepping and opening three whole files.
jCodeMunch returned 94.5% fewer tokens per lookup on average than grep-and-read on our 15-lookup benchmark (three real repos). The method is public; poke holes in it.
How does an unattended agent get permission to read?
An agent that can’t ask has to be allowed ahead of time. Codex in a background run can decline calls to a server you haven’t approved, with no error on either side (reported in openai/codex #24135), so the agent quietly goes back to reading files. jCodeMunch marks its read tools read-only and indexing as a write, so you can approve the readers and keep the prompt for the rest. The steps for each client are in the setup guides: Codex, Cursor, Devin Desktop.
Why do durable agents need memory?
IndyDevDan’s video says it plainly: durable agents require memory. Part of that memory is the codebase itself. jCodeMunch’s index stays on disk between sessions, so an agent that restarts at 4 a.m. doesn’t re-read the repo to find its way back. In Claude Code, a hook re-indexes every file the agent edits, so its own changes show up in its next lookup, and another saves a snapshot before the session compacts.
Where does it pay off most?
jCodeMunch pays off most on real repos, where an agent would otherwise go looking file by file. Pair it with a budget in your harness: the index keeps each lookup small, and the budget caps the run.
uv tool install jcodemunch-mcp
jcodemunch-mcp init --policy
Run init from your project folder. --policy writes the rules that tell the agent
to ask the index first.
Running agents at work? Personal and other non-commercial use is free. Work use at a for-profit company, or for client or paid work, needs a license, paid once: see jCodeMunch pricing.
15 lookups, 5 each on express, fastapi and gin at pinned commits. jCodeMunch ran one symbol search, then fetched the source of the top 3 matches. The baseline searched the query terms and read the top 3 matching files. Tokens were counted with the cl100k tokenizer. 94.5% is the mean of the 15 per-lookup drops.