Skip to main contentSkip to footer
ExamplescriptbeginnerRunnablechat-lab

Making Requests

Runnable example (beginner) for script using openai.

Key Facts

Level
beginner
Runtime
Python • OpenAI API
Pattern
Single-turn interaction with inspectable output
Interaction
Live sandbox • Script
Updated
14 March 2026

Navigate this example

High-level flow

How this example moves from input to execution and reviewable output
Making Requests -> User request -> System execution -> Reviewable output -> Load environment keys -> Initialize OpenAI client

Trigger

Making Requests

Runtime

User request

Outcome

System execution

Why this page exists

This example is shown as both real source code and a product-facing interaction pattern so learners can connect implementation, UX, and doctrine without leaving the library.

Visual flowReal sourceSandbox or walkthroughMCP access
How should this example be used in the platform?

Use the sandbox to understand the experience pattern first, then inspect the source to see how the product boundary, model boundary, and doctrine boundary are actually implemented.

UX pattern: Single-turn interaction with inspectable output
Source references
Library entry
models-openai-01-introduction-02-making-requests
Source path
content/example-library/sources/models/openai/01-introduction/02-making-requests.py
Libraries
openai
Runtime requirements
OPENAI_API_KEY
Related principles
—

02-making-requests.py

python
from openai import OpenAI

# The OpenAI class will automatically use the OPENAI_API_KEY environment variable
client = OpenAI()
What should the learner inspect in the code?

Look for the exact place where system scope is bounded: schema definitions, prompt framing, runtime configuration, and the call site that turns user intent into a concrete model or workflow action.

Look for output contracts and validation
Look for the exact execution call
Look for what the product could expose to the user
How does the sandbox relate to the source?

The sandbox should make the UX legible: what the user sees, what the system is deciding, and how the result becomes reviewable. The source then shows how that behavior is actually implemented.

Enter or load a sample message.
Run one request/response turn.
Compare the visible reply with the product contract the example is teaching.
SandboxSingle-turn interaction with inspectable output
Message lab

Use this lab to test one request at a time, inspect the visible response, and understand which parts of the behavior stay deterministic.

UX explanation

These examples work best when the product makes the turn contract explicit: what the user submits, what the system returns, and what stays outside scope.

AI design explanation

The model does one bounded job while the product keeps the control boundary. The interaction should expose prompt, response, and output shape without pretending to broader autonomy.

Interaction walkthrough

  1. 1Enter or load a sample message.
  2. 2Run one request/response turn.
  3. 3Compare the visible reply with the product contract the example is teaching.

User message

Single turnInspectable output

Visible reply

The visible response appears here.

Product contract

Shows what the product should keep explicit.

Control boundary

Makes the deterministic boundary visible.

Used in courses and paths

This example currently stands on its own in the library, but it still connects to the principle system and the broader example family.

Related implementation patterns

Related principles

    Runtime architecture

    Use this example in your agents

    This example is also available through the blueprint’s agent-ready layer. Use the For agents page for the public MCP, deterministic exports, and Claude/Cursor setup.

    Define triggers, context, and boundaries before increasing autonomy
    Make control, observability, and recovery explicit in the runtime
    Choose the right operational patterns before delegating to workflows
    Open For agents