OpenAI’s model page records the GPT-5.5 snapshot gpt-5.5-2026-04-23, and the API changelog records availability on April 24. Official documentation positions the model for complex professional work, coding, and tool-heavy workflows, but “stronger” needs a product definition. A launch evaluation should not restate leaderboards. It should establish whether a model completes real deliverables under bounded authority while reducing total human correction.

Turn real work into accepted work

“Write more professionally” is difficult to score consistently. An engineering task can specify: begin from a fixed commit, repair an issue, preserve public API, pass named tests, add no dependency, and provide a concise explanation. A research task can allow only a supplied corpus, ask five questions, require a citation per conclusion, and require abstention where evidence is absent. A document task can fix structure, audience, length, and a prohibition on invented experience.

Each case contains initial state, tools, time and token budgets, hidden acceptance, and risk class. Hidden checks prevent optimizing only for visible tests. A human rubric covers maintainability, evidence, and side effects. Freeze repositories, data, and tool versions so the baseline model and GPT-5.5 operate in the same environment.

Include impossible cases. A reliable system should report a blocker rather than fabricate a successful command or citation. Correct abstention is part of task completion.

Record the snapshot and configuration

Aliases are convenient for exploration. A production evaluation records gpt-5.5-2026-04-23, reasoning effort, verbosity, prompt, tool schemas, context strategy, SDK, and date. Change one major variable at a time. If migration also rewrites prompts, keep a model-only arm and a model-plus-prompt arm.

Do not turn the current model page’s price or limits into a permanent historical claim. Preserve the official pricing snapshot or internal billing rule used by the run. Check availability and rate limits in the actual project. Evaluation records need enough information to calculate cost later without embedding mutable policy in output parsing.

Data retention and regional requirements are configuration gates, not benchmark dimensions. A model that cannot be used under the product’s governance is not an eligible winner.

Score the full trajectory

An agent may finish with the right answer after reading unrelated files, making excess calls, or attempting an unauthorized action. Record every proposed tool call, validation, result, retry, cancellation, and final output. Metrics include task success, hidden checks, unrelated changes, invalid arguments, blocked overreach, total latency, input and output tokens, tool count, and human review minutes.

Failure categories are more actionable than one average: retrieval miss, wrong plan, implementation defect, missing verification, misread tool output, loop, or fabricated completion. Separate first-pass success from success after self-repair. Recovery is valuable but has different cost and risk.

Inspect the final working state independently of the model’s narrative. Git diff, test exit codes, document schema, and persisted records are authoritative. A confident summary cannot override them.

Build an effort curve per task class

Try none or low on classification and explicit edits, medium or high on difficult diagnosis, and reserve xhigh experiments for the hardest asynchronous tasks. Repeat each case and plot success against latency and total cost. The highest effort is not automatically the best product point, and a documented default may not fit every route.

If high effort avoids three repair turns, total task cost can fall. If it merely expands explanation, reduce it. Interactive products care about the first useful feedback; asynchronous work cares about completion and timeout. One token count cannot represent user waiting and reviewer time.

Route using product risk as well as estimated difficulty. A simple but irreversible action still needs deterministic checks and approval.

Evaluate safety beside capability

Add prompt injection in tool results, unauthorized files, deletion requests, malicious issues, duplicate submission, and sensitive data. The model proposes actions; deterministic policy enforces allowlists, schemas, account scope, and approval. One resisted attack is not a safety proof. Report attempted overreach, blocked effects, and false refusals.

Use disposable environments, test accounts, and recoverable data. Restrict code tasks to a workspace, with network and installation off by default. A model comparison that grants one candidate broader authority is neither safe nor fair.

Blind review, then shadow traffic

For subjective artifacts, randomize and hide model identity. Several reviewers use one rubric and record disagreement. After offline acceptance, run on noncritical shadow traffic where outputs are neither shown nor allowed to execute side effects. This exposes the real input distribution without making the experiment user-facing.

Predefine launch gates: task classes that must improve, metrics that cannot regress, cost and latency ceilings, and failures that trigger rollback. Rerun holdout cases before changing a moving alias.

GPT-5.5’s launch value is not one aggregate score. It is the distribution of completed, verified work. Freeze snapshot and harness, score tool trajectory, validation, cost, and human correction, allocate effort by task, and include attacks in the same evaluation. Only repeatable delivery under bounded authority turns official capability positioning into product evidence.