Build Hour: GPT-5

GPT-5 is positioned as OpenAI’s “smartest, most steerable” coding model yet—built to produce higher-quality code, handle long-running agentic workflows with many tool calls, and follow instructions more literally when prompts are precise. The core message from the build hour is practical: developers can get better results not just by switching models, but by using the Responses API correctly—especially by choosing the right reasoning mode, enabling stateful reasoning when appropriate, and tuning output controls like minimal reasoning and verbosity.

On capabilities, the session emphasized three areas. First, GPT-5’s coding performance shows a “step function” improvement in code quality, including front-end UI generation that looks more polished out of the box. Second, it’s designed for long-horizon tasks where the model must chain tool calls end-to-end—planning, calling tools, checking conditions, and correcting course when it starts down the wrong path. Third, GPT-5 adds new control knobs for reasoning and output behavior. A new reasoning parameter called “minimal” is described as doing the least reasoning needed to keep latency closer to non-reasoning models, while still retaining the intelligence of a reasoning model. Another parameter, “verbosity,” controls how much final output the model produces and even affects tool-call formatting.

A major technical focus landed on the Responses API as the recommended way to use GPT-5. Compared with the older Completions API, Responses is framed as a more feature-rich “v2” that improves developer experience (like easier output text handling) and—crucially—supports statefulness by default. When state is enabled, GPT-5 can emit intermediate “reasoning items” (chain-of-thought tokens) that can be passed back after tool calls so the model continues its internal reasoning coherently across steps. For teams that can’t use statefulness, the session described an alternative: encrypted reasoning content that preserves the benefits without exposing raw intermediate tokens.

The build hour also connected these mechanics to measurable outcomes. In long agentic rollouts with 20–50 tool calls, preserving reasoning continuity can translate into small but meaningful benchmark differences (cited as roughly 2–4% on Sweetbench). The session also highlighted prompt caching behavior: caching depends on the prefix, and reasoning items are part of what gets included in that prefix, improving both cost efficiency and speed when requests share the same prefix.

Demos made the model’s steering tangible. In Cursor, a simple prompt generated a functioning landing page for “vibe coder,” with GPT-5 producing working UI elements. In Codex CLI, GPT-5 was used to build a Minecraft clone from an empty folder, producing a playable world after several minutes, then iterating on visuals (adding pink flowers and improving rendering) through additional prompts. The research side framed future work around better web development, tighter “loop” iteration with testing, and more coherent long-horizon agent behavior—imagining an “agent slider” that lets users choose between quick help and extended autonomous work.

Finally, prompting guidance stressed that GPT-5 follows instructions more literally than older models, so conflicting or vague instructions can hurt performance. Practical advice included removing contradictions, selecting appropriate reasoning effort (starting medium, using low for latency-sensitive tasks and high for long tasks), using XML as a prompt structure based on internal tests, and “metaprompting” by asking the model why it did something and then correcting based on those reasons. The session closed with an applied example from Charlie Labs: an autonomous TypeScript-focused coding agent (“Charlie”) that uses GPT-5 via the Responses API, integrates with GitHub/Linear/Slack, runs tests in a VM, and creates PRs and issues—reporting improvements in internal evals and strong head-to-head results versus GitHub’s Cloud Code.