Technical debt budgeting: how do you quantify and allocate it in sprint planning?

We're a 12-engineer team shipping a B2B SaaS product. Every sprint, we informally 'tuck in' debt-fixing tasks alongside feature work, but there's no systematic allocation — and leadership keeps asking for a percentage. Options we've debated: 1. Fixed 20% of sprint capacity reserved for debt/refactoring (Google-style) 2. Debt backlog with explicit prioritization against feature stories (same grooming queue) 3. 'Debt sprints' every 4-6 sprints (dedicated cleanup cycles) 4. No quota, but every feature ticket must include a 'debt tax' estimate The problem with option 1: the 20% either goes unused (no good debt tasks) or gets swallowed by minor cleanup while structural issues pile up. How does your team actually track and budget technical debt? And more importantly — does leadership respect the allocation during crunch periods?