Add protected_tokens next to protected_tags

[tenshiak]

Short description

20 tags can be a very tiny amount of tokens when the LLM was doing targeted edits

What problem does this solve?

Currently Magic Context protects protected_tags amount (default 20). But if the LLM was doing a series of small, targeted edits, the system would only protect a small amount of tokens.

Proposed solution

I propose to add protected_tokens configurable value (default omitted), a similar dual system to execute_threshold_percentage and execute_threshold_tokens. For example, if protected_tags is set to 20, protected_tokens to 30000, but the last 20 tags only add up to 5000 tokens, expand the protection until it reaches 30000. If 20 tags tokens > 30000 tokens, protect the last 20 tags. Whichever setting protects more wins.

Pi currently does token-based protection; Magic Context uses tags. This solution merges them and makes it best of both worlds. A user could set protected tags to 0 and use only token-based protection, not use token-based protection and use the current system, or utilize both at the same time for optimal results.

Alternatives considered

No response

Area

Memory / historian / dreamer

Additional context

No response

[ualtinok]

Thanks — we are taking the stronger version of this. A tag count was the wrong unit for the intent ("keep the recent working set"): 20 tiny edits and 20 large reads protect very different masses. protected_tokens will replace protected_tags rather than sit next to it: a token floor derived from the model's usable window by default (on the order of 5%, clamped), an absolute override, and a structural minimum of the newest three tool calls so one large output cannot leave the model with no prior context. protected_tags becomes a deprecated key with a loud warning, not a silent mapping (a count cannot be converted to tokens honestly). The design has been through review; the implementation across OpenCode, Pi and the Rust engine is in progress and ships in a minor version, not a patch.