{"version":"2.1.287","anchor":"tool-definition-rejection-fallbacks-now-also-record-a-header","canonical_anchor":"tool-definition-rejection-fallbacks-now-also-record-a-header","heading":"Claude Code records more when the API refuses beta tool-definition features","tier":"internal","area":"API","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.287\/e\/tool-definition-rejection-fallbacks-now-also-record-a-header","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.287","markdown":"### Claude Code records more when the API refuses beta tool-definition features\n\nWhen the API refuses the header for the inline-tools or late tool-additions beta, Claude Code now records an extra piece of state\n\n**Unclear.** It is not clear what the extra state holds or how long it lasts.\n\n**What**\n\nClaude Code can send tool definitions in two beta ways: inline, or added later in a conversation. A beta is a feature the API offers before it is final, switched on with a header sent with each request. When the API rejects either of these with the reason `header_rejected`, Claude Code already fell back and cleaned up.\n\nIt now also records an extra piece of state in that case. When tools are added later in a conversation, there is a second such record. The warnings you see are unchanged.\n\n**Why**\n\nNothing new appears on screen. The change is in what Claude Code keeps track of after the API refuses one of these betas.\n\n- Area: API\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 2\/5"}