go-openai

go-openai is a community-maintained Go client for the OpenAI API. It wraps every major surface of the API — the newer Responses API for reasoning and multi-turn state, the long-standing Chat Completions endpoint, embeddings, image generation, audio transcription/translation/speech, moderation, file uploads, fine-tuning jobs, batches, vector stores, and the legacy Assistants API — behind a single typed Client.

The library is written entirely against the Go standard library, with zero third-party runtime dependencies, and supports Azure OpenAI and Anthropic-compatible endpoints alongside the default OpenAI base URL through a configurable ClientConfig. Streaming responses are modeled with Go generics over a shared SSE reader, giving each streaming endpoint (chat, responses, speech) a typed Recv() loop instead of raw byte handling.

With over 10,000 GitHub stars, 180+ contributors, and near-continuous releases tracking new OpenAI model and API launches, it is the de facto standard Go SDK for teams building on OpenAI without waiting on an official Go client.

What You Get

• A single Client type (NewClient/NewClientWithConfig) that exposes every OpenAI API surface as typed Go methods instead of hand-rolled HTTP calls
• Generics-based streaming (CreateChatCompletionStream, CreateResponseStream, CreateSpeechStream) with a typed Recv() loop over server-sent events
• Built-in support for Azure OpenAI, Anthropic-compatible, and Cloudflare AI Gateway endpoints via APIType and DefaultAzureConfig, alongside the default OpenAI base URL
• Structured error handling via errors.As(err, &openai.APIError{}), exposing HTTP status, error code, and message from failed API calls
• A jsonschema sub-package for building tool/function-calling schemas without hand-writing JSON
• Runnable examples for the Responses API, Chat Completions, function/tool calling, image generation, and speech-to-text under examples/

Common Use Cases

• Backend AI integrations - Go services calling GPT models for chat, reasoning, or tool-augmented workflows via the Responses or Chat Completions APIs
• Multi-turn assistants - applications that chain PreviousResponseID across calls to maintain conversation state without re-sending full history
• Streaming UIs - CLI tools or backends that stream generated text token-by-token to a terminal or downstream client using the typed stream readers
• Enterprise Azure deployments - teams running OpenAI models through Azure OpenAI Service who need deployment-aware URL construction and Azure API-key auth
• Speech and transcription pipelines - Go services converting audio to text (Whisper) or text to speech using the audio API wrappers
• Function/tool calling agents - Go programs that define callable tools with jsonschema and dispatch model tool-call requests to real functions

Under The Hood

Architecture go-openai centers on a single Client struct (client.go) holding a ClientConfig and two collaborators — a RequestBuilder and a FormBuilder (internal package) — that construct and serialize HTTP requests. Each API surface (chat.go, response.go, audio.go, image.go, embeddings.go, files.go, batch.go, vector_store.go, thread.go, run.go, assistant.go) is a thin method set on *Client that builds a request via newRequest, dispatches it through sendRequest/sendRequestStream, and decodes the typed response. Streaming reuses a single generic streamReader[T] (stream_reader.go) parameterized per endpoint, so chat, responses, and speech streaming share one SSE-parsing implementation rather than three. Azure and Anthropic-compatible routing is centralized in fullURL/baseURLWithAzureDeployment, keeping deployment-name and API-version logic out of individual endpoint methods. The design cleanly separates transport (internal/request_builder.go, internal/form_builder.go) from API surface (root package), so adding a new endpoint means adding a request/response pair and a method, not touching the transport layer.

Tech Stack The module (go 1.18 in go.mod) declares zero third-party runtime dependencies — everything is built on net/http, encoding/json, bufio, and context from the standard library, with Go generics used for the shared stream reader. Multipart form encoding for file/audio uploads is hand-implemented in internal/form_builder.go rather than delegated to a wrapper library. CI (.github/workflows/pr.yml, integration-tests.yml) runs unit tests plus opt-in integration tests against the live OpenAI API, and a close-inactive-issues workflow handles repo hygiene.

Code Quality The repository ships 34 _test.go files alongside their corresponding implementation files (one-to-one naming, e.g. chat.go/chat_test.go), covering both unit tests with mocked HTTP servers and integration tests gated behind a build tag. Errors are handled as typed values (APIError, RequestError) satisfying the standard error interface and inspectable via errors.As, rather than being swallowed or stringly-typed. Linting is enforced through an extensive .golangci.yml covering dozens of linters (errcheck, errorlint, exhaustive, funlen, gocognit, dupl, and more), and PRs run through CI before merge — a notably rigorous setup for a community-maintained SDK.

What Makes It Unique Unlike thinner community wrappers that only cover Chat Completions, go-openai tracks OpenAI’s full surface area — including the newer Responses API, vector stores, and the legacy Assistants API — while staying dependency-free and generics-based for streaming, which keeps the binary lean and avoids version-conflict risk in consuming projects. Its Azure/Anthropic-compatible endpoint abstraction lets the same client code target multiple deployment backends by swapping ClientConfig, which is unusual breadth for an unofficial SDK of this size.