quota-saving-mode

Quota-Saving Mode

Spend reasoning on decisions, implementation and verification—not repeatedly rediscovering unchanged state. This is an operating preference, not a runtime setting or a guarantee about billed usage. Follow required progress reporting, tool wait limits, safety rules and the user's model choices.

Default operating loop

• Choose a meaningful next decision boundary and the evidence that would change the action. Work through a coherent block instead of ending a turn after each healthy poll; an automatically resumed goal can otherwise become a costly status loop. Do not pause an authorized goal merely to save quota.
• Separate mechanical health checks from scientific review. Check startup and unfamiliar failure modes promptly. Once healthy, use the existing expected cadence: ordinarily minutes for cheap process/error checks, a checkpoint or roughly 15–30 minutes for substantive interpretation. Shorten this when delayed action would lose evidence, leave resources idle or miss a deadline. These are defaults, not permission to weaken a required monitor.
• Prefer existing completion signals or native interruptible waits. Where tools support it, keep repeated short waits and cheap status checks inside one composed tool execution; return to model reasoning for a result, error, deadline, user steering or decision-changing evidence. Obey per-call wait limits rather than issuing an uninterruptible long sleep. Never infer terminal failure from a timeout or stale log alone; verify the same live handle. The concrete form of this is the next section, and it is not optional: a wait loop is the single largest avoidable cost this skill exists to prevent.
• Give substantive user updates at milestones, failures, decisions or requests, not after every poll. Use the smallest permitted heartbeat when higher-priority instructions require more frequent progress reports. Do not promise to remove runtime-mandated updates or control CLI wakeups that tools do not expose.