Runs #12-14 left two open questions: whether Architecture's new, near-60-second calls were a real shift or just noise around a hard ceiling, and whether Builder's first legible rejection reason would repeat or turn out to be one-off. Run #15 answered one of those clearly. It didn't get far enough to touch the other.
What happened
Same task, deliberately unchanged. Scope completed in 28 seconds, same as always. Architecture failed both attempts, at durations indistinguishable from the two prior failing runs:
- Attempt 1: 60,008ms,
application_timeout - Attempt 2: 60,004ms,
application_timeout
The retry deferred correctly to a fresh invocation between attempts, exactly as it has every time since Run #9. Both attempts still failed. The run ended there — never reaching Security, UX, or Builder, so the commit-message question from Run #14 stays exactly where it was.
That makes three timeout runs out of the last four, against one near-ceiling success sandwiched between them. Six Architecture provider calls in a row that failed have now landed within 8 milliseconds of exactly 60,000 milliseconds, across three separate runs. That's no longer a pattern worth watching — it's the majority outcome, and it earned an actual investigation instead of another wait-and-see.
What we ruled out, and how
Before considering any change, we went looking for what's actually different — read-only, against the real production data and the real repository history, the same discipline every fix in this series has followed.
Nothing about the request changed. Architecture's system prompt has been byte-for-byte identical since before Run #8 — confirmed directly against git history, not assumed. Its output budget, its model, its timeout value: all unchanged across the entire window. The only commits that touched anything near this code path in the last two days were Builder-specific, and provably never execute for Architecture's own dispatch.
Nothing about the input changed. Every successful and failed Architecture call in this entire series — eleven attempts across seven runs — selected the identical 19 files, the identical 153,714 bytes, the identical hash-for-hash content. Input token counts on every call that returned a response sat in a 200-token band around 49,300. Nothing grew, nothing shifted.
It isn't context acquisition, and it isn't this application's own overhead. Subtracting the provider's own reported call duration from each attempt's total execution time leaves 10.7 to 13.8 seconds of acquisition-plus-persistence work on every single attempt this session — success or failure, identical range. Whatever is taking longer is entirely inside the Anthropic call itself.
It isn't the platform. Every one of the six timeouts happened with zero platform-level timeout signal and zero non-200 response anywhere in Vercel's own logs for the full window. These are honest, clean, 60-second application timeouts with the invocation itself completing normally right afterward — not a repeat of the platform-duration problem Run #9 solved.
It probably isn't a blanket account-wide slowdown, though this one is weaker. Scope ran immediately before Architecture in every one of these runs and stayed fast and successful every time, including on the days Architecture failed. If every call from this account were slow at the same moment, Scope sitting right next to it would be a reasonable place to see that too — it didn't. Not proof, since Scope's request looks nothing like Architecture's, but a real data point against the simplest blanket explanation.
What we're left with
Every plausible in-house explanation is now ruled out, and the honest answer for what's actually happening on Anthropic's side is that we don't know — not because nobody looked, but because the one measurement that would answer it doesn't exist yet. Every single failed call was cut off at exactly 60 seconds by our own timeout, before Anthropic's response ever arrived. We know the true duration of each failure is at least 60 seconds. We have no idea whether it's 60.1 or considerably more, for any of the six.
That's the actual gap now, and it's a measurement problem, not a guessing problem. Raising Architecture's timeout without that number would be exactly the mistake Run #8 already made once with Builder — a value chosen because it sounded reasonable, not because the arithmetic behind it held up.
Where this leaves things
- The Architecture pattern is confirmed real and now dominant — three of the last four runs, not a fluke, with every alternative explanation this codebase could produce checked and ruled out.
- No code change is justified yet. Every explanation this project's own systems could account for has been eliminated; what's left needs a real duration measurement, not another guess.
- Builder's commit-message question is still open, unreached again this run.
- The next real step is a diagnostic, not a fix — an uncensored measurement of how long a slow Architecture call actually takes, taken outside the production timeout path, before any number gets changed. What happens after that is still being decided.