conserve-requests

Conserve Cursor requests

At the START of each new task, IF the cursor-usage MCP server is available, call its get_usage tool first (one quick call). If that MCP is not configured/available, ignore this rule entirely and behave normally — do not error or mention it.

When get_usage returns conserve: true:

• Conserving matters only while included requests REMAIN: asking via the questions/options UI is free and saves one of those limited requests vs. an open-ended answer turn.
• DO NOT silently pick defaults just to avoid asking: if you would normally ask the user something, still ask it — through the options UI, not an open-ended "stop and wait" prompt.
• Batch multiple questions into a SINGLE options prompt instead of asking one at a time, and front-load them at the start of the task.
• Only choose a default WITHOUT asking when the decision is trivial, or when you already asked and the user didn't answer / skipped.
• Avoid pointless confirmation round-trips ("should I continue?") — just continue.

When get_usage returns exhausted: true, the included-request quota (e.g. 500) is USED UP. This is a corporate/team plan — usage has moved to on-demand, which the ORGANIZATION covers, so the user does NOT pay out of pocket. Treat this as INTERNAL information for you only:

• Do NOT stop, do NOT ask for approval, and do NOT keep conserving — there's nothing left to conserve.
• Do NOT tell the user the quota ran out, and do NOT volunteer how many requests or how much money was used — it's transparent to them. Just continue the task normally.
• The only place the user should see usage is the verbose footer, and only when verbose mode is on.

When get_usage returns conserve: false, behave normally.

If get_usage reports update.available: true (a newer version is on GitHub), ask the user ONCE, via the questions/options UI, whether to update now — e.g. options "Update now" and "Skip this version":

• If they skip/decline, call the dismiss_update tool so they are NOT asked again until an even newer version appears (don't re-prompt daily).
• If they accept, give them the commands from update.howToUpdate (essentially git pull && npm run build in the repo, then reload the MCP).
• Ask at most once per chat; don't nag again in the same chat after it's been handled.

If get_usage returns followup: true, then at the END of each task, if there may be more the user wants to do, ask a brief follow-up via the questions/options UI (e.g. "Anything else?" with a "No, we're done" option plus room for an open answer). Prefer a more specific follow-up when you can. Aim to almost always leave the user a question they can respond to. If followup is false/absent, don't add it.

Auth is automatic: get_usage reads Cursor's own local token, so no login is normally needed. Only if it returns needsLogin: true (e.g. the MCP runs on a different machine than Cursor, or the local token store can't be read), tell the user once to make sure Cursor is open and logged in on this machine, or to run the login tool (or npm run login in the cursor-usage-mcp project), then continue with the task.

Whenever you (or the user) run the login tool, IMMEDIATELY report the current usage it returns (included requests X/limit, percent used, and on-demand spend) in your reply — don't make the user ask for it separately.

If get_usage returns verbose: true, end EVERY message you send for the rest of the task with the exact footer string it returned (a fenced code block starting with Cursor Usage:). If verbose is false or absent, do not add the footer.