From the Backlog to the Build Log

Context Window Limits, Prompt Caching, and Smarter Retries: October 9 - October 15, 2026

What I Worked On

This week DevNitro got context window limits. Caps stack from company to team to project to builder, and the server rejects any cap higher than the one above it. Some models have a standard window and a much larger extended one, and requests past the standard window bill at higher rates. So a cap is how a company keeps a long agent session from turning into an expensive one. In Intelligent Engineering, a spending rule like this belongs to the organization, so the server enforces it no matter which tool or session sends the request.

I turned on prompt caching the same night. The rest of the week went to a machine-wide gate for builds and tests, moving the BlankSite blueprint out of the CLI, four new visual tools, and a runner fix after an autonomous run failed the same way three times.

Most of my hours went to video, and DevNitro built much of that tooling too. Four autonomous runs on my AI Video Studio repo produced 98 commits across 63 issues, including a Blazor app scaffolded from the fullstack blueprint.

What the AI Did Well

Saturday night an autonomous run took 11 context-cap issues from the backlog. It built the policy rules, the resolver that works out the effective cap, the cap the server sends the CLI with each message, a builder preference, and the Blazor screens. Those screens show each model's prices and warn you when a cap reaches the extended rates.

The agent on the policy task caught a gap in my plan. A request with no cap had to mean "keep the cap you have," so switching a model off and back on wouldn't wipe it. But the plan also said clearing a cap returns the row to the inherited value, and a missing value can't mean both. So the agent added a separate clear flag.

For caching, I fixed some prompt caching in DevNitro's Claude API provider. Sometimes the agent loop sent the whole history as one growing block each turn, so that block never matched the cache. The system prompt and tools stay the same between turns, so the cache markers went there first. The autonomous run then split the history into separate cache blocks.

Tuesday, while testing a web app, I found DevNitro's visual agent couldn't press a key or pick from a dropdown. So DevNitro worked on itself and added visual_select, visual_press_key, visual_upload_file, and visual_hover. visual_select fires real input and change events, so a Blazor InputSelect with @bind sees the change.

What Needed Correction

Saturday morning an autonomous run stalled on one issue. The runner is the part of DevNitro that merges each issue's work into the run's branch, and I had that branch checked out in my main folder, so the runner couldn't move it forward. Three attempts in a row, the agent reported changes made and the runner failed the same way. On the fourth attempt, the agent wrote that reporting changes made again would just fail a fourth time.

Monday I had DevNitro change the runner, which I lean on more since I set up concurrent autonomous runs last month. Now the runner fast-forwards a checked-out run branch in place, unless that would overwrite my local edits. If the same failure happens twice with no change to the work, the runner parks the issue for me and the run keeps going.

Friday night I tested the new heavy-work gate and lowered two of my own defaults. Each build already spreads across cores, so I dropped heavy-work slots from a third of the cores to a quarter, which is 6 on my 24-thread machine. I also cut the delay between starting workers from 5 seconds to 1, since 10 workers took 45 seconds to come online.

The new visual tools also fixed how DevNitro picks what to click. It used to take the first match, and one time it clicked a Logout button instead of a form's submit button. Now, when several visible elements match, it stops and lists them so the model can choose.

What Shipped

Friday I deployed the machine-wide gate. A run now gets the workers you ask for, and builds, tests, and shell commands wait in one queue for the whole machine.

The CLI now downloads the exact pinned version of the Blazor blueprint from DevNitro's private package feed for builders with a seat. It fetches the file directly instead of installing by package name, because a name lookup would also search nuget.org, where anyone can publish a package with that name. If a builder stops paying, the version they have keeps working.

The context work merged Saturday night, and I deployed the runner changes Monday. Thursday DevNitro started closing an autonomous run's session when the run finishes.

The Numbers

Category Hours
Content 42h 56m
Product / Features 9h 14m
Testing 5h 49m
Business 3h 53m
Deploy / Infra 0h 17m
Total 62h 11m

Content took 42h 56m, mostly the AI Video Studio and editing and rendering YouTube videos. DevNitro product, test, and deploy time came to 15h 21m, down from 17h 35m last week.

Where This Fits in Intelligent Engineering

Saturday's stall came down to which account the next attempt believed. Three times the agent reported changes made, and three times the runner's merge failed. Since Monday, the next attempt reads the runner's facts, the real build and test output, instead of the last agent's write-up. When the check that ran and the agent's story disagree, the check has to win, or nobody can trust what an autonomous run says it finished.

This week brought context window limits, prompt caching, and a runner that stops repeating the same failure. I use the DevNitro CLI at my desk now and the web UI mostly when I'm away, and I end up with more sessions open than I can keep track of. Contemplating if I'll allow swapping between sessions and projects inside the CLI. It may be that Herdr and the like will keep that functionality out of the CLI itself. Back at it next week.