"Lean GPT-5.6 Prompts: Delete Instructions with Evals"

OpenAI's GPT-5.6 guidance says leaner prompts can improve both quality and efficiency, but prompt length is not a production objective. The safe objective is a smaller prompt that preserves or improves task success, permissions, evidence, and output contracts. This guide gives you a controlled deletion protocol, an eval scorecard, and a release gate you can reuse.

Reading time: 9 minutes · About 2,000 words

TL;DR

• Start from a prompt that already works and freeze the model, reasoning setting, tools, and eval set.
• Delete one instruction group at a time, then rerun exactly the same evals.
• Remove repetition, obsolete scaffolding, inert examples, and irrelevant tools first.
• Preserve outcomes, success criteria, permission boundaries, evidence rules, output schemas, and validation requirements.
• Optimize cost per successful task, not prompt tokens in isolation.

Lean means high signal, not minimum length

GPT-5.6 can infer more of the path between a well-defined goal and a finished result. That makes some process scaffolding unnecessary. It does not make constraints unnecessary.

The official GPT-5.6 model guide recommends stating each instruction once, exposing only task-relevant tools, and retaining examples or style guidance when they encode a product requirement or fix a measured gap. Its companion prompting guide draws the operational boundary clearly:

The distinction is information density. A 300-token prompt can be bloated if half of it repeats one rule. A 2,000-token prompt can be lean if every section changes an important decision.

OpenAI reports that, in a sample of internal coding-agent evals, leaner system prompts raised scores by roughly 10–15%, reduced total tokens by 41–66%, and reduced cost by 33–67%. The guide explicitly describes these figures as directional and workload-dependent. They are a reason to test, not a performance promise.

Freeze the experiment before editing

Prompt cleanup becomes uninformative when the model, reasoning effort, tool set, test cases, and prompt all change together. A better output then has no attributable cause; a worse output has no diagnosable failure.

Record a baseline manifest:

model: gpt-5.6-sol
reasoning_effort: medium
prompt_version: support-agent-v17
tool_schema_version: 9c41a2
eval_dataset: support-golden-v6
runs_per_case: 3
temperature: 0
metrics:
  - task_success
  - policy_compliance
  - evidence_completeness
  - schema_validity
  - tool_success
  - latency
  - total_tokens
  - cost_per_success

Pinning these variables turns prompt deletion into a controlled comparison. It also creates a rollback target.

Your eval set should mirror real traffic rather than a collection of clean demonstrations. Anthropic's evaluation guidance recommends task-specific cases that reflect the real distribution and include edge cases. It also recommends measurable, multidimensional success criteria because task fidelity, consistency, context use, latency, price, and safety can move in different directions.

A practical first set contains four buckets:

1. Common successful requests that represent most volume.
2. High-value requests where a regression is costly.
3. Known failures collected from production traces.
4. Boundary cases involving permissions, missing evidence, tool errors, and ambiguous intent.

Freeze the cases before the experiment. If you rewrite the tests after seeing a candidate fail, you can accidentally turn the eval into an explanation of the candidate rather than a test of the product.

Build a deletion ladder

Deleting a whole prompt at once is a rewrite. A deletion ladder is a sequence of small hypotheses.

Step 1: Remove exact and semantic repetition

Search for rules that appear in several forms:

Ask before changing files.
Wait for approval before edits.
Do not modify anything without confirmation.

If the actual product policy is more nuanced, replace the cluster with one decision rule:

For review or diagnosis, inspect and report without editing.
For an explicit fix request, make in-scope local edits and validate them.
Require confirmation for destructive, external, costly, or scope-expanding actions.

The replacement is shorter and more precise. It removes an accidental global prohibition while retaining the real approval boundary.

Step 2: Remove obsolete scaffolding

Prompts accumulate patches for old models, retired tools, and fixed failure modes. Tag every section with one of three statuses:

• Invariant: a real product or safety requirement.
• Measured fix: added because a documented eval or trace failed.
• Historical: no active failure, owner, or test explains why it remains.

Historical text is the next deletion candidate. Keep its version history, but do not make the production model repeatedly pay for organizational memory.

Step 3: Challenge examples

Examples are valuable when they establish a required schema, resolve ambiguity, or correct a measured behavior. They are expensive when they merely illustrate what the instruction already says.

Remove one example group and compare:

• Does schema validity change?
• Does the model generalize better to unseen wording?
• Does a rare but important behavior disappear?
• Does token or cache cost move enough to matter?

An example survives because it has observable marginal value, not because it looks helpful.

Step 4: Reduce the tool surface

Every irrelevant tool adds description tokens and another possible action. Expose only the tools needed by the evaluated workload. This is both prompt optimization and capability control.

Do not remove a tool only because the baseline rarely calls it. First check whether it is the recovery path for a low-frequency, high-impact case.

Use an eval scorecard that can block release

An average quality score is too weak for production prompt changes. It can hide a severe permission regression behind small improvements on common cases.

Use hard gates and soft objectives:

Cost per successful task matters more than cost per call:

cost_per_success =
    total_experiment_cost
    / number_of_cases_that_pass_all_required_gates

A candidate that is 30% cheaper per call but causes 15% more retries may be more expensive in operation. The same applies to brevity: fewer prompt tokens do not help if the model needs extra tool loops to reconstruct missing context.

For non-deterministic workloads, repeat each case and examine variance. A candidate with a slightly higher mean and a dangerous failure tail should not automatically win.

Run one change per round

Use the same loop for every deletion group:

1. Write the hypothesis: which text is redundant, and why?
2. Create one prompt diff.
3. Run the frozen eval suite with the frozen runtime configuration.
4. Compare hard gates before efficiency metrics.
5. Keep or revert the diff.
6. Record the result and choose the next group.

A compact experiment log is enough:

These numbers are illustrative. Your table should use task-specific metrics and confidence intervals appropriate to the sample size.

This loop is slower than deleting 40% of the prompt in one edit. It is faster than debugging an unexplained production regression.

Separate prompt migration from prompt cleanup

When moving to GPT-5.6, first switch the model while preserving the current reasoning effort and prompt. Run representative evals before editing the prompt. OpenAI's guidance recommends testing the same effort and one level lower because GPT-5.6 may preserve quality with fewer reasoning tokens, but that is a separate experiment.

Only after establishing the model baseline should you simplify the prompt. Otherwise four variables can move together:

• model behavior;
• reasoning effort;
• system prompt;
• tool surface.

The separation gives you two useful answers: whether the model migration works, and whether the prompt deletion works.

Release with a reversible gate

An offline win is evidence, not deployment approval. Before replacing the production prompt:

1. Review the prompt diff and the failed-case diff.
2. Run a sealed regression set that was not used to choose deletions.
3. Canary the candidate on bounded traffic.
4. Monitor task success, policy violations, tool recovery, latency, tokens, and cost.
5. Keep the baseline prompt and rollback switch available.

Version the prompt, eval set, model configuration, and tool schemas together. A prompt result cannot be reproduced when the surrounding runtime has drifted.

This is where lean prompting meets the broader evaluator architecture described in GEPA: The Evaluator Is the Interface. The optimizer may be a human editing one group at a time or a search engine proposing candidates. The release boundary remains the same: no candidate ships without evidence that represents the real objective.

Common failure modes

Optimizing prompt tokens alone

Prompt tokens are an input metric. Task success, operational cost, and risk are outcome metrics. Track both, but let the outcome decide.

Deleting the reason for a rule

A rule can look redundant because its associated failure is rare. Search incident logs and version history before deleting it. If the failure remains important, encode it in an eval so the rule can be tested.

Trusting one judge score

Use deterministic checks for schemas, permissions, tool calls, and required evidence. Use human or LLM grading where nuance is necessary, and calibrate the rubric against labeled cases.

Rewriting instead of deleting

A full rewrite can improve the prompt, but it answers a different question. Use controlled deletion to learn which parts have marginal value. Run a rewrite as a separate candidate.

Reusing a contaminated test set

Repeatedly inspecting and tuning against the same cases converts a test set into a training set. Keep a sealed release set and refresh it with new production failures.

Frequently asked questions

Should every GPT-5.6 prompt be shorter?

No. GPT-5.6 benefits from clear outcomes, constraints, evidence requirements, permissions, and completion criteria. Remove text only when representative evals show that it adds no useful behavior.

How much should I delete in one round?

One coherent group: repeated rules, one example family, one obsolete workflow section, or one irrelevant tool. The unit should be small enough that a result can be attributed.

What if quality stays flat but cost falls?

Keep the candidate if all hard gates pass, the sample is large enough to support non-inferiority, and the operational saving remains after retries, cache writes, and tool calls.

Can an LLM grade the eval?

Yes, for nuanced criteria. Calibrate it against human-labeled examples and combine it with deterministic checks where possible. Anthropic's guidance recommends code-based grading when it fits because it is fast, reliable, and scalable.

When is a long prompt justified?

When its length carries active product information: domain context, permissions, required evidence, output contracts, or examples that fix measured failures. Length without marginal behavior is the problem.

References

• OpenAI: Using GPT-5.6
• OpenAI: Prompting guidance for GPT-5.6 Sol
• OpenAI: API deployment checklist
• Anthropic: Define success criteria and build evaluations

Take one production prompt, freeze its eval suite, and delete the first repeated instruction group. The result of that single controlled round will teach you more than a complete rewrite with no attribution.