How to Choose a Trigger Mode for Every Windsurf Rule (2026 Guide)

Windsurf states the mechanism in one sentence: "Each workspace rule declares an activation mode in its frontmatter via the trigger field. This controls when the rule's content is given to Cascade and how much context window it consumes."

Two things in one field: whether the rule reaches the agent, and what it costs. The documented options:

always_on — "Full rule content is included in the system prompt on every message." Cost: every message.

model_decision — "Only the description is shown in the system prompt. Cascade reads the full rule file when it decides the description is relevant." Cost: description always; full content on demand.

glob — "Rule is applied when Cascade reads or edits a file matching the globs pattern." Cost: only when matching files are touched.

manual — "Rule is not in the system prompt. You activate it by typing @rule-name in the Cascade input box." Cost: only when @mentioned.

Read those costs as a ladder. Going from always_on to model_decision converts a fixed per-message cost into a description-sized one, with the body loaded on demand. Going to glob makes the cost conditional on what you touch. Going to manual makes it conditional on you asking.

Now the part that reframes the whole exercise:

"The global rules file (global_rules.md) and root-level AGENTS.md files don't use frontmatter — they are always on."

Those two surfaces have no mode. They are always on, by construction. So before you optimise anything, some of your budget is already committed — and the limits tell you how much. The global file lives at ~/.codeium/windsurf/memories/global_rules.md, is applied across all workspaces, and is "limited to 6,000 characters." Workspace rules live one per file in .devin/rules/ (preferred) or .windsurf/rules/ (fallback) and are "limited to 12,000 characters per file."

And there is a third always-on surface people forget they have: "The legacy single-file .windsurfrules at the workspace root is also still read." If you migrated to a rules directory years ago and never deleted that file, it is still being loaded.

AGENTS.md gets its mode assigned by location rather than frontmatter: "root-level = always-on, subdirectory = auto-glob for that directory." That is a genuinely elegant default, and it means moving a file up one directory silently changes its cost from conditional to permanent.

The general version of this problem — rules that are present but not behaving as you expect — is covered in why agents ignore your instruction files.

Setting everything to always_on. It feels safest: the rule is definitely there. It also spends your per-message budget on a Terraform convention during a session where you never leave the frontend, and the cost compounds across a long conversation. The symptom is the drift described in when Windsurf's agent loses context.

Writing shorter rules instead of changing modes. Helpful, and it is solving the wrong variable. A 400-character rule loaded on every message still costs more over a session than a 3,000-character rule loaded twice. Brevity and activation are independent levers, and the second one is stronger. The limits of the brevity-only approach are the subject of why shorter prompts aren't enough.

Relying on auto-generated memories instead. Windsurf advises against this itself, in its own words: "For knowledge you want Cascade to reliably reuse, write it as a Rule or add it to AGENTS.md in your repo rather than relying on auto-generated Memories. Rules are version-controlled, shareable with your team, and give you explicit control over activation." Its comparison table puts memories in their place too: "Let Cascade remember one-off facts; for durable knowledge, prefer Rules or AGENTS.md." Note also the scope caveat the docs now carry — memories are documented as applying to the legacy Cascade agent only, and the Devin Local agent that is the default for new tabs does not persist them.

Consolidating everything into one file to simplify. This trades a manageable set of mode decisions for one undifferentiated always-on block, and it runs into the per-file character limit. The folder-level version of this decision is worked through in merging Windsurf and Devin rule folders.

Assuming enterprise rules override the mess. They do not, and the documentation is specific: system-level rules are "merged with workspace and global rules, providing additional context to Cascade without overriding user-defined rules." An admin baseline adds to your budget rather than replacing it.

The decision is not "which mode is best." It is "how often is this rule actually relevant," and the modes map onto four honest answers.

Step 1: Inventory every surface, including the ones with no mode

List everything before you change anything. There are five places a rule can come from, and only one of them has a trigger field:

The global file at ~/.codeium/windsurf/memories/global_rules.md — always on, 6,000 characters.

Root-level AGENTS.md — always on, no frontmatter.

Subdirectory AGENTS.md files — auto-glob for their directory.

The legacy .windsurfrules at the workspace root, if it still exists — check this, because it is the single most common source of budget you did not know you were spending.

Workspace rule files in .devin/rules/ or .windsurf/rules/ — one per rule, 12,000 characters each, and the only surface where you choose a mode.

Add up the always-on total first. That number is your floor, and it is what every message pays before any conditional rule loads.

Step 2: Sort each workspace rule into one of the four honest answers

Go rule by rule and ask how often it is genuinely relevant. The answers map directly:

Relevant on every message. Things like "respond in British English" or "never commit to main." These earn always_on. There should be very few, and their combined size is the number you care about.

Relevant sometimes, unpredictably. Domain knowledge the agent should reach for when a topic arises — a payments constraint, a compliance rule. These are model_decision, and the description is doing real work here, because it is the only part loaded by default. Write it as a "when to use this" sentence, not a title.

Relevant when specific files are involved. Anything file-shaped: test conventions, migration safety, generated code. These are glob, and this is usually the biggest win, because most conventions are file-shaped and people had them on always-on.

Relevant when you say so. Release checklists, incident procedures, anything you invoke deliberately. These are manual, and you activate them with @rule-name.

If a rule does not fit any of the four, that is diagnostic. It usually means the file is two rules stapled together — one always-true and one situational — and splitting it gives each half a mode that fits.

Step 3: Verify by contradiction, not by reading the file

You cannot confirm a mode by looking at the frontmatter, because the question is whether the agent actually received the content.

For a glob rule, open a file that should not match and ask for something the rule would change. If the rule's behaviour shows up anyway, your pattern is broader than you think. Then open a file that should match and check the behaviour appears.

For a model_decision rule, ask about the topic without naming the rule. If the agent does not reach for it, the description is the problem, not the body.

For a manual rule, confirm the @rule-name invocation resolves — and confirm the rule does not apply when you have not mentioned it, which is the whole point of the mode.

Do this once per rule after a mode change. It is the only way to tell a mode that is set from a mode that is working, and it is the same discipline that catches the problem in when Windsurf forgets your project rules.

Two things survive this exercise, and only one of them fits in a rules directory. The instructions — how to behave, what to prefer — belong exactly where Windsurf puts them. The reasons behind them do not: "we use whole-day billing" is a rule, and "because the finance system rejects partial days" is the thing that lets an agent tell when the rule stops applying.

MemoryLake holds that second layer, outside the character limits and outside any one editor. Your rules get shorter, your always-on floor drops, and the reasoning is still available to every tool you use.

Step 1: Create an API key

Sign in, open your workspace settings, and generate an API key. This is the credential your editor and agents use to read the same layer, so create it once and keep it reachable from each machine.

Step 2: Upload your first memories

Move the reasoning out of your rule bodies: why each convention exists, which approach you rejected, what constraint makes the obvious answer wrong. The rule file keeps the instruction; the layer keeps the justification.

Step 3: Connect your AI & agents

Connect Windsurf and whatever else you work in. The same reasoning arrives in each, which matters because the rules directory does not travel to the next tool and the decisions in it should.

The first difference is measurable within one session. Moving file-shaped conventions from always_on to glob takes them out of every message, and long conversations stop degrading in the second hour.

The second is that model_decision becomes usable. It is the most interesting mode and the most commonly wasted, because a description written as a label gives the agent nothing to decide on. Written as a condition, it becomes a working on-demand surface.

The third is that your always-on floor becomes a number you know. Between a 6,000-character global file, a root AGENTS.md and possibly a forgotten .windsurfrules, that floor is often most of the budget people think they are managing.

The fourth is that rules stop carrying the reasoning. Shorter files fit the 12,000-character limit comfortably, and the justification lives somewhere a person can read and a different tool can load. The cost of not doing this shows up as the context loss in when Windsurf forgets Cascade context.

Default to glob, not always_on. Most conventions are about files. Make the agent's exposure match.

Write model_decision descriptions as conditions. "Use when working on payment flows or refund logic" beats "Payments rules." The description is the only part loaded by default.

Delete the legacy file once you have checked it. .windsurfrules at the workspace root is still read. Either it is your source of truth or it should not exist.

Watch what moving a file does. A subdirectory AGENTS.md is auto-glob for that directory; the same file at the root is always-on. Directory moves are cost changes.

Count the always-on total before optimising the rest. Optimising conditional rules while a 6,000-character global file loads on every message is the wrong order.

Treat auto-generated memories as one-off facts. That is Windsurf's own positioning, and its recommendation is to write durable knowledge as a Rule or in AGENTS.md instead.

Re-verify after any mode change. A frontmatter edit is not evidence. Contradiction is.

Windsurf did the hard part already: it published what each activation mode costs and when each one loads. The four modes map cleanly onto four honest answers about how often a rule is relevant, and most rule directories are misconfigured only because nobody sat down and answered that question per file.

So answer it. Inventory the surfaces that have no mode, add up the floor they commit you to, sort the rest into the four buckets, and verify by contradiction rather than by reading frontmatter. Then take the reasoning out of the rule bodies, because a character limit is a bad place to keep the explanation of why your conventions exist — and because the next tool you use will have its own limits, its own modes, and no way to read this directory at all.