{"version":"2.1.281","anchor":"tengu-api-success-gains-a-dispatch-field","canonical_anchor":"tengu-api-success-gains-a-dispatch-field","heading":"Side queries retry in more cases with a fixed dispatch value","tier":"internal","area":"Telemetry","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281\/e\/tengu-api-success-gains-a-dispatch-field","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281","markdown":"### Side queries retry in more cases with a fixed dispatch value\n\nSide queries now resend once with a fixed dispatch value after a headerless 503 or a 408, 409 or 429, and API results record a dispatch value\n\n**Unclear.** The finding does not say what `dispatch` records.\n\n**What**\n\nA side query is a smaller background request Claude Code sends to the model alongside the main conversation. Some requests carry a dispatch header, a label that tells the service how to route them. When a side query fails, it can now be sent again once with a fixed dispatch value in three cases:\n\n- `headerless_decline`: an HTTP 503 error on a request that was sent without a dispatch header.\n\n- Server or connection errors: a 5xx error or a connection failure. This case existed before.\n\n- `retryable_4xx`: HTTP 408, 409 or 429. These are resent using the client's usual retry allowance, unless the server marked its requested wait (Retry-After) as too long. Before, these codes were resent only when a header had been sent.\n\nThe record of a fallback resend now includes `resend_dispatch`. The records Claude Code keeps for successful and failed API calls now include a `dispatch` value, which defaults to `none`.\n\n**Why**\n\nSide queries are more likely to succeed when the routing layer turns a request down, instead of failing outright. The added `dispatch` value is diagnostic information and changes nothing you do.\n\n- Area: Telemetry\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 2\/5"}