Case study
Likely an individual assignment (repository name: go-home-assignment), but ownership remains pending repository evidence. Solo authorship is not claimed.
Realtime GPT-4o-mini CLI
A Go command-line application that connects to OpenAI’s realtime API over WebSocket, consumes streamed events, and supports local function calling.
Terminal · goroutines · channels
$ realtime-gpt-cli
> 6*7
event conversation.item.create
event response.create
event function_call multiply(a, b)
local multiply(6, 7) → 42
event function_call_output
assistant 42
Deterministic conceptual terminal preview. Does not contact OpenAI and does not expose an API key.
Problem
Realtime model sessions require concurrent connection handling, streamed event decoding, and safe local execution of function calls without exposing credentials.
Solution
A Go CLI reads OPENAI_API_KEY from the environment, maintains a WebSocket session with reader and main goroutines, and executes a local multiply function before returning output to the model.
Contribution
Implemented realtime WebSocket session handling, event channels, and local function calling in Go. Collaboration attribution remains pending verification.
- Connected to the realtime GPT-4o-mini WebSocket endpoint
- Decoded streamed JSON events through a reader goroutine and channel
- Implemented local multiply(a, b) function calling with buffered streamed arguments
- Sent conversation.item.create, response.create, and function-call output back to the model
Architecture
- API key loaded from OPENAI_API_KEY environment variable
- Reader goroutine continuously reads the WebSocket connection
- Incoming JSON events are decoded and sent through a channel
- Main goroutine sends requests and consumes events
- Local function calling executes multiply(a, b) outside the model
- Function-call output is returned to the model for a final response
Key engineering decisions
Keep credentials out of source
The CLI reads OPENAI_API_KEY from the environment and never embeds a key.
Separate transport reading from request orchestration
A dedicated reader goroutine keeps event intake continuous while the main goroutine owns prompts and responses.
Interactive demonstration
Deterministic local simulation — not a live product session.
Local portfolio simulation — no OpenAI connection or API key.
Preparing Prompt · events · function calls. Case-study content stays readable while this loads.
Challenge
Streamed function-call arguments
Arguments arrive in fragments and must be buffered before local execution.
Limitation
- This is a CLI assignment-style implementation, not a production-deployed service.
Technical details
Technology stack
What the product covers
Concurrent event loop
Reader and main goroutines coordinate streamed events through a channel.
Local function calling
Streamed function-call arguments are buffered, multiply runs locally, and output returns to the model.
What this demonstrates
- — Go concurrency with goroutines and channels
- — Realtime WebSocket event handling
- — Local function calling against a streamed model session
- — Environment-based credential handling
Additional limitations
- The browser terminal simulation is deterministic and never contacts OpenAI.