Beyond the Request/Response Model This Course Has Used Throughout

Every technique in this course, including this unit's capstone, has worked within the same basic shape: send a request, receive a response, decide what to do next. That shape covers an enormous range of real applications, but it isn't the only interaction model the platform supports. Three additional capabilities are worth knowing about specifically because each breaks from the request/response pattern in a different way — not as replacements for what this course covered, but as tools suited to interaction modalities this course's request/response-based capstone deliberately didn't need.

The Realtime API: Continuous, Low-Latency Interaction

Every example in this course sends a complete input and waits for a complete (or streamed, per Lesson 3) response. A voice conversation doesn't fit this shape naturally — a person speaking expects a natural, low-latency back-and-forth, not a request that waits for them to finish an entire thought, gets transcribed, sent, and answered with a noticeable delay. The Realtime API is built specifically for this: a persistent, bidirectional connection over which audio (and other input) streams continuously in both directions, rather than the discrete request/response calls this course has used throughout.

# Illustrative sketch only — see the note below before building against this.
import asyncio
import websockets

async def realtime_conversation_sketch(api_key: str):
    uri = "wss://api.openai.com/v1/realtime"
    async with websockets.connect(uri, extra_headers={"Authorization": f"Bearer {api_key}"}) as connection:
        # Audio is streamed to the connection continuously as the user speaks,
        # and response audio streams back with low latency, rather than a
        # single request being sent and a single response awaited.
        await connection.send('{"type": "response.create"}')
        async for message in connection:
            print(message)

Note: The Realtime API's connection protocol, message format, and available event types are more likely to evolve than the core Responses API this course has built on throughout. Confirm the current connection setup, authentication approach, and message schema against the current official documentation before building against it — this sketch illustrates the shape of a persistent, streaming connection, not a working implementation.

This matters for this capstone specifically as an extension point: a version of the document assistant that a user could talk to rather than type to would reach for the Realtime API rather than adapting the request/response /chat endpoint from Lesson 2, since a fundamentally different interaction pattern calls for a fundamentally different API, not a variation on the same one.

ChatKit: Prebuilt Chat Interface Components

Lesson 3 built a chat frontend from first principles — a fetch() call, a stream reader, manual text decoding and DOM updates — deliberately, so every mechanical step of streaming a response to a browser was visible and understood. A real application often doesn't need to rebuild this from scratch every time, and ChatKit is a set of prebuilt UI components specifically for embedding a chat interface without writing that plumbing by hand.

<!-- Illustrative sketch only — see the note below before building against this. -->
<div id="chat-container"></div>
<script>
  // ChatKit provides prebuilt components that handle message rendering,
  // streaming display, and input handling, reducing the amount of custom
  // frontend code Lesson 3 wrote by hand for a comparable interface.
</script>

Note: ChatKit's exact API, available components, and integration steps can change as the product evolves. Confirm the current setup and integration approach against the current official documentation before adopting it in place of a hand-built interface.

Building Lesson 3's streaming interface by hand was the right choice for this course specifically because seeing every step — the SSE format, the reader loop, the incremental DOM update — is what makes streaming's mechanics understandable rather than a black box; having built it once by hand, reaching for a prebuilt component like ChatKit in a real, time-constrained project is a reasonable choice precisely because the underlying mechanics are no longer a mystery, not because they were never worth learning.

Computer Use: Acting Directly on a Graphical Interface

Unit 8's tools give a model a fixed set of well-defined functions to call, each with a specific, predictable signature — exactly the right approach when the actions an application needs are known in advance and can be cleanly described as functions. Computer use takes a different approach entirely: rather than calling a predefined function, the model is given screenshots of an actual graphical interface and can respond with direct actions — clicking a coordinate, typing text, scrolling — the same way a person would operate the interface themselves.

# Illustrative sketch only — see the note below before building against this.
def computer_use_step_sketch(client, screenshot_base64: str, task_description: str):
    response = client.responses.create(
        model="gpt-5.6-terra",
        input=[
            {"role": "user", "content": task_description},
            {"role": "user", "content": [{"type": "input_image", "image_url": f"data:image/png;base64,{screenshot_base64}"}]},
        ],
        tools=[{"type": "computer_use_preview", "display_width": 1024, "display_height": 768}],
    )
    return response.output  # a proposed action: click, type, scroll, etc.

Note: Computer use's exact tool configuration, the specific action types it can return, and its safety and confirmation model are all more likely to change than this course's core material. Confirm current capabilities, constraints, and recommended safety practices against the current official documentation before building against it, and treat any action it proposes with the same confirm-before-consequential-action discipline Unit 8, Lesson 5 established for ordinary tool calls — arguably more so, since an action executed directly against a real graphical interface can have effects that are harder to constrain or reverse than a well-scoped function call.

Computer use is the right tool specifically when the actions needed can't be cleanly expressed as a fixed set of functions — operating an existing third-party application with no API, navigating a website that wasn't built with any automation in mind — and it comes with real added risk precisely because its action space is broader and less constrained than Unit 8's function-calling model: a function tool can only do what its code allows, however it's called, while an action executed directly against a real interface can do a much wider range of things, which is exactly why the confirmation and scoping discipline Unit 8, Lesson 5 established for consequential tool calls matters even more here.

Matching the Technique to the Actual Interaction Need

None of these three is a strictly more advanced or more capable replacement for what this course built throughout — each fits a specific interaction shape that the request/response model this course used doesn't fit naturally.

Reaching for the Realtime API, ChatKit, or computer use for a task the request/response model and Unit 8's tools already handle well adds complexity without a corresponding benefit — each of these three exists to address an interaction shape genuinely outside what this course's core material covers, not as a generally superior alternative to it.

Everything Else in This Course Still Applies

Whichever of these a project eventually reaches for, the practices this course established throughout carry over directly: Unit 12's error handling, retries, and rate limiting apply to a Realtime API connection just as much as to a Responses API call; Unit 13's evaluation discipline applies to judging whether a computer-use-driven workflow actually completes its task correctly, not just whether it appears to; and Unit 11's guardrails apply with, if anything, greater urgency to a system capable of taking direct action on a real interface. None of these three capabilities changes the underlying discipline this course has built toward — testing with fakes before trusting real behavior, evaluating systematically rather than eyeballing a few examples, handling errors and limits deliberately, and keeping a human in the loop for anything consequential. They extend where that discipline gets applied, not whether it still matters.