--- name: gpt-usage-optimizer description: Route tasks to the appropriate GPT reasoning effort, control chat/context bloat, and create reliable source-linked handoffs for long project workflows. Default guidance for relevant tasks in Master-linked projects; use for any substantial workflow, large projects, sluggish chats, expensive/repetitive agent work, model-choice questions, and new-chat resumes; do not claim to change the ChatGPT model, selected thinking level, or context window automatically. --- # GPT Usage Optimizer — model guidance and chat lifecycle **Scope:** Shared *guidance* for projects using the Moksha Master Stack. Project ownership and instructions take precedence; Golden Rules 0/0A, free-first, source reuse, approvals, privacy, branch/security controls, QA and rollback remain mandatory. This skill does **not** install an autonomous router, alter ChatGPT settings, run in the background, or extend tool permissions. ## 0. Default-on behavior and explicit overrides — 17 October 2026 **Default mode: AUTO/ON, silently.** Whenever this Skill is invoked by ChatGPT's skill selection or called through project/global instructions, optimize context loading, tool use, reasoning-effort *recommendation*, concise status, checkpointing and recovery throughout the task without requiring the user to type a trigger. Avoid commentary about the optimizer on routine requests. This is a working-policy default, NOT proof that the platform will load this skill on *every* turn: installed plugins are selected automatically when relevant, while global Custom Instructions or per-Project Instructions are needed to request consistently default-on behavior. The user must enable or edit those ChatGPT settings manually; plugins cannot silently edit them. **Override precedence:** system/platform safety > explicit user command in current chat/task > project-specific constraints and instructions > account Custom Instructions > this Skill's defaults. When instructions conflict, follow higher-priority instructions without weakening Golden Rules 0/0A, security/privacy, verified deployment gates or mandatory approvals. A one-task override ends when the task ends; 'for this chat' persists through the current chat; 'for this project' requires the user to edit Project Instructions for dependable future-chat persistence; account-wide changes require updating Custom Instructions. Recognize natural-language equivalents of these commands, without requiring strict command syntax: - `Optimizer OFF` — suspend **optional** routing hints, context compaction and checkpoint reminders in this chat until restored. Still follow essential accuracy/safety and user requests; never claim to disable model safety or platform limits. - `Optimizer ON` / `Optimizer AUTO` — resume silent normal defaults. - `Optimizer for this task OFF` — pause only for the current task, then revert to chat default. - `Use Instant|Medium|High|Extra High for this task` — honor the preference for recommendations/work style; explain briefly if unreasonable or not available, but DO NOT claim to change the actual ChatGPT model/effort selector. - `Full context` — retrieve additional relevant sources when permitted; still avoid irrelevant entire registries, excessive repeats and secret disclosures. - `No handoff` — suppress discretionary fresh-chat suggestions for this chat, preserve work and state; unavoidable platform context limits remain. - `Concise` / `Detailed` — tailor response length independently from reasoning/verification depth. **Default routing:** QUICK uses bounded relevant context and no model chatter; STANDARD uses targeted sources; BUILD/CRITICAL uses proportionate evidence and context with QA preserved. Override just the dimension named (effort, context, handoff, response size, or optimization), retaining other defaults. Never invent exact token usage or quota levels. Reassess only at natural task boundaries or when evidence shows a failure; no hidden scheduler/observer. **Global default instruction to paste in Settings → Personalization → Custom Instructions:** > Default to the Moksha Master `gpt-usage-optimizer` whenever relevant: use minimum sufficient context, target the right reasoning effort, preserve evidence/QA, avoid repeated retrieval, and checkpoint long project chats into the existing tracker. Keep it silent unless a change is useful. My explicit per-task/chat commands override the optimizer: `Optimizer OFF/ON`, `Use High reasoning`, `Full context`, `No handoff`, `Concise/Detailed`. Never claim you changed the ChatGPT model selector, automatically opened a new chat, or weakened existing security/approval rules. In a ChatGPT Project, add equivalent text to that project's Project Instructions if needed, because Project Instructions override global Custom Instructions. Do not claim settings or model choice were altered by publishing this Skill. ## 1. Model-effort decision at task entry Use the lightest **available** reasoning level that satisfies *risk, ambiguity, complexity and acceptance criteria*, not the longest context or highest model by default: | Lane | Example task | GPT-6 selector guidance | Process | | --- | --- | --- | --- | | QUICK | Direct factual answer, caption, simple read-only state | Instant | Answer from grounded current facts; no broad context reload | | STANDARD | Synthesis, research, 2–3-way comparison, bounded plan | Medium | Targeted official/repo sources, concise decisions | | BUILD | Multi-file code changes, root-cause debugging, deployment QA, dense synthesis | High | Existing ticket + relevant source + tests + checkpoint | | CRITICAL | Unresolved high-stakes design, deep debugging, cross-system incident | Extra High **only if available and worthwhile** | Explicit assumptions, alternatives, risk review, verification | **Escalate only on evidence**: incorrect first pass, unresolved contradictory evidence, failed bounded retry, significant irreversible risk, complex reasoning requirement, or repeated rework. A task can be long but mechanically simple; use STANDARD/QUICK plus automation/workflow tooling instead of raising effort. Downgrade after the hard subproblem is resolved. Never assume that typing “think harder” switches the actual model. **ChatGPT UI truth (OpenAI Help, checked 17 Oct 2026):** GPT-6 on Plus/Pro does not automatically escalate Instant to Medium/High merely because a request is complex. A skill or connector cannot programmatically move the user's model picker; recommend a choice for the user to make. Available levels and quota depend on plan/workspace. UI safety/fallback routing is platform-owned. See https://help.openai.com/en/articles/20001354-gpt-6-and-other-models-in-chatgpt . **API-based, owner-controlled workers:** A router *can* select an allowlisted model and supported reasoning-effort parameter on each new API request when the worker already has the required provider integration and owner approval. Before implementation, inspect the existing worker and the official API/model documentation; constrain per-task cost, latency, privacy, allowlists, rate limits, retries and non-API fallback. Do not invent an API key, paid tier, metered call, automatic ChatGPT UI switching, or separate scheduling daemon. Keep GPT Chat model UI and external API worker routing distinct. ## 2. Minimum viable task context Use only: (a) active Project identity/lane, (b) current ticket/PR/checkpoint, (c) relevant files and relevant Master paragraphs, (d) latest authoritative runtime proof when needed. **Never dump the entire Master Registry or replay full prior chats by default.** Confirm source version/branch, action authorization and evidence freshness. Distinguish verified live, source-only, queued, untested, blocked, failed and proposed. Use targeted file/connector searches, batch independent reads, deduplicate repeated outputs and favor fixed-format acceptance evidence over broad status chatter. Do not add a tool call when its answer is already verified and fresh enough. Parallel reads are fine; serialize writes to shared state, browsers/devices, production deployments and scarce worker quota. Reuse existing repositories, queues and skill owners rather than creating a monitoring agent to optimize chats. ## 3. Chat-length lifecycle (heuristics, not fake token measurements) **Healthy:** single objective, manageable source set, no repeated questions; continue the current chat. **Checkpoint trigger:** any milestone, >2 unrelated goals in a chat, repeated re-fetches/contradictions, large tool dumps, complex multi-stage branch, uncertainty about last verified state, or user reports that responses are sluggish. If platform token-use is not exposed, **do not claim a measured context percentage**. After ~25–40 substantive turns *consider* a checkpoint, but do not hard-stop based on turn count alone. **Fresh-chat recommendation:** checkpoint is saved in the existing issue/doc; chat becomes confused, repetitive, slow, or near user-visible limits; or a logically independent workstream begins. **Never start or move to another chat autonomously**, claim the new chat inherits all active context, or abandon an in-flight write. User opens a fresh project chat with the verified checkpoint URL and bounded resume instruction. Memory is helpful context, not a substitute for authoritative project state. **Recovery:** if a new chat lacks the file, connector or permission, retrieve only the relevant source again; state missing access instead of guessing. Recheck the source SHA and live state, then continue from the first incomplete acceptance criterion. Do not conflate a git commit with production deployment. ## 4. Durable handoff packet Write to the **existing** approved GitHub issue/PR, project file or durable tracking record at significant transitions. Aim for 250–500 words of *actionable* prose; extend for required security or rollback facts. Use this exact structure: ``` TASK: PROJECT / LANE: STATUS: LAST PROOF: DONE: NOT DONE / RISKS: REUSE / COST: ACCESS / APPROVAL: ROLLBACK: NEXT SINGLE ACTION: ``` Never paste credentials, private transcripts, customer/guest data, or unrelated project information into the handoff. A checkpoint is authoritative only for what its evidence actually proves. Existing issue/checkpoint IDs are preferable to a new spreadsheet, copy of the Master Doc or duplicate queue. ## 5. Response and workflow quality checks - Respond outcome-first: answer QUICK asks briefly; execute BUILD asks in bounded stages with genuine readback and clear acceptance evidence. - Do not repeatedly ask for already-provided facts. When an ambiguity is non-blocking, state the safe assumption and progress. - Do not inflate effort because a chat is long; split context from reasoning. Do not lower effort when risk or factual correctness demands investigation. - Recommend a model/effort change **only when it materially helps**. User must operate the ChatGPT model picker. - Reuse the existing Master demand-based event flow for significant verified technology changes. Do not use old hourly publication as the primary sync mechanism or claim full propagation from a GitHub commit. - Log the source version, plugin release, and consumer acknowledgement independently; an installed skill update does not hot-reload existing chats or Project Instructions. ## 6. Tiny resume message (for use in a new Project chat) `Resume [PROJECT] task from [CHECKPOINT URL]. Confirm repository/permission/source SHA and live status, load only files needed for NEXT SINGLE ACTION, preserve Golden Rules 0/0A and safety gates, execute and verify. Report only evidence-backed changes.` ## Reuse / source decision Internal reuse: existing Master `FAST EXECUTION DEFAULT`, `master-stack-sync`, active GitHub issues/checkpoints and the owner-approved demand-based event protocol; no new agent, paid dependency, API key or backend service. Official reference: OpenAI GPT-6 help and applicable official API model/reasoning documentation. New material is a narrow reusable policy/Skill that combines model-effort guidance with bounded chat context and verified handoffs; zero additional service procurement.