Unclear None of the related gates (tengu_convolute_arcades_retry, tengu_convolute_arcades_tools, tengu_fallback_sweep_tools, tengu_refusal_fallback_triggered) have been read, so nothing can be said about whether this silent lane is active for any account.
What
- A new "silent lane" fallback mechanism sits alongside the existing, user-visible refusal-fallback retry. It can be armed either by a remote config key (
convolute_arcades) or by the server sending a response header (x-cc-tender-quilt: 1), which the client latches onto. - When armed this way, retries are logged under differently-named, less descriptive telemetry events instead of the usual, plainly-named refusal-fallback events.
- Telemetry events, including the invalid-content-policy refusal event and
tengu_api_success, now attach anarm_sourcefield identifying which mechanism (config key or server header) armed the retry. tengu_api_successalso gains atender_quilt_headerflag, set to true when a low-priority/background header condition is present.
Why
This lets Claude Code retry refused or failed turns through a quieter path when the server signals it should, while telemetry now records exactly which mechanism triggered the retry, which helps diagnose why a retry happened.
Names in the bundleconvolute_arcadesx-cc-tender-quilt
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubt
None of the related gates (`tengu_convolute_arcades_retry`, `tengu_convolute_arcades_tools`, `tengu_fallback_sweep_tools`…