If you build AI features in Go, you have probably felt the gap. Python has LangChain and LiteLLM. TypeScript has the Vercel AI SDK. Go has excellent single provider clients, but switching providers usually means rewriting the code that calls the model, handles streaming, and parses structured output. GoAI is an open source Go SDK that closes that gap with one unified API across 25 plus providers, inspired directly by the Vercel AI SDK, but written the Go way, with generics, interfaces, and functional options.
Key Takeaways*
>
GoAI is an open source Go SDK for building AI applications, with one unified API across 25 plus providers, according to its README and official docs site.
Its 8 core functions cover text, streaming, structured output, embeddings, image generation, and video generation.
Structured output uses Go generics: GenerateObject[T] builds a JSON Schema from a Go type by reflection, so the model returns a typed value, not a string you must parse by hand.
Its MCP client connects to local and remote MCP servers over stdio, Streamable HTTP, and legacy SSE, and converts MCP tools into GoAI tools.
The project reports 24x faster cold starts than the Vercel AI SDK in its own benchmark, but that benchmark uses a mock HTTP server on an Apple M2, so treat it as a project claim, not an independent result.
At the time of writing it has 233 stars, 37 forks, and 350 commits on GitHub, it is MIT licensed, and it requires Go 1.25 or later.
Watch the 30-second repo signal
What GoAI Actually Is
GoAI, by zendev-sh, describes itself as "AI SDK, the Go way" and as "One SDK, 25 plus providers, MCP support". In plain terms, it is a library you import into a Go program, not a hosted service and not an agent framework. You pick a provider model, for example openai.Chat("gpt-4o"), and call the same functions no matter which provider sits behind it. Hosted providers auto-resolve API keys from environment variables, so the quick start is a short program that calls goai.GenerateText with a prompt and prints result.Text.
That design choice is the whole pitch. The Vercel AI SDK gave TypeScript developers a consistent set of functions for calling a model, streaming output, and letting the model run tools. GoAI copies that shape, then adapts it to Go idioms. The author, writing on DEV in April 2026, put it plainly: Python has LangChain, LlamaIndex, and LiteLLM, TypeScript has the Vercel AI SDK, and Go had options, but none covered all the bases. GoAI is his answer to that gap.
The repository was created on 2026-03-17, and at the time of writing it has 233 stars, 37 forks, 350 commits, and 64 releases, with v0.9.0 as the latest highlighted release. That release added provider-neutral file upload and remote file references for OpenAI, Anthropic, and Google Gemini. Those numbers describe a small but actively maintained project, not a mainstream standard, and that is the right frame for judging it.
Why Go Needed a Unified SDK
The Go AI library landscape, as the author mapped it in April 2026, was fragmented in a specific way. Single provider clients were strong but narrow: go-openai had about 10,600 stars but covered one provider, and the official openai-go and anthropic-sdk-go clients were single provider by design. Broader libraries existed, but with tradeoffs: LangChainGo had about 9,000 stars and about 14 providers, but 170 plus dependencies and no MCP support or generics schema at the time; Google Genkit Go had about 5,700 stars and about 6 providers, but 129 dependencies and a Google Cloud heavy design; ByteDance Eino had about 10,500 stars and 10 providers, but it is a graph framework with a different scope.
GoAI positions itself in the middle of that map: broad provider coverage, a small API surface, and a deliberately small dependency footprint. Whether that tradeoff is right for you depends on what you value. If you want one provider and nothing else, a dedicated client is simpler. If you want an agent orchestration framework, Eino or the companion project zenflow, a declarative YAML workflow engine built on GoAI, may fit better. GoAI is for the case in between: a Go service that calls models, possibly from more than one provider, and wants the same code path for all of them.
The 8 Core Functions
GoAI keeps its API surface small. Everything hangs off 8 core functions, documented on pkg.go.dev and in the README.
Function | What it does |
|---|---|
GenerateText | Non-streaming text generation, one call, one result |
StreamText | Streaming text generation through Go channels |
GenerateObject[T] | Structured output, with a JSON Schema auto-generated from a Go type |
StreamObject[T] | Streaming structured output, with partial objects as they arrive |
Embed | A single text embedding |
EmbedMany | Batch embeddings, auto-chunked and parallel |
GenerateImage | Image generation from a text prompt |
GenerateVideo | Video generation from a text and media prompt, for example Google Veo |
The generic functions deserve a closer look, because they are where Go's type system does real work. With GenerateObject[T], you define a Go struct, for example a Recipe with a name, ingredients, steps, and a difficulty field constrained to easy, medium, or hard, and GoAI generates the JSON Schema from that struct by reflection. The model returns a typed Recipe value, not raw JSON text. Streaming works the same way: StreamObject[T] emits partial objects as tokens arrive, so a user interface can show a recipe filling in, ingredient by ingredient, instead of waiting for the whole response.
That is also where the limits show. The README notes that structured output auto-generation works with OpenAI, Anthropic, and Google, and the v0.8.5 release added Anthropic native structured output and Gemini schema sanitization fixes. If your provider is not in that group, check how its structured output is handled before you rely on it.
Switching Providers Without Rewriting Calls
The provider list is the second half of the pitch. The README lists 25 plus providers: OpenAI, Anthropic, Google, Bedrock, Azure, Vertex, Mistral, xAI, Groq, Cohere, DeepSeek, MiniMax, Fireworks, Together, DeepInfra, OpenRouter, Requesty, Perplexity, Cerebras, Ollama, vLLM, RunPod, Runcrate, Cloudflare Workers AI, FPT Smart Cloud, NVIDIA NIM, and more, plus any generic OpenAI-compatible endpoint. A snapshot on pkg.go.dev still says 24 plus, which is a reminder that provider counts move as the project grows, and the README is the current source.
Switching providers, in the intended design, means changing the model constructor, not the call site. The same GenerateText, StreamText, and tool loop code runs against OpenAI, Anthropic, or a local Ollama model. That matters most in three situations: when you want to test a cheaper model against your prompts, when a provider has an outage, and when a customer or deployment constraint requires a different provider. It does not remove provider differences entirely. Models still differ in context windows, tool support, pricing, and behavior, and GoAI documents per-provider details, such as tested models and custom or self-hosted endpoints, rather than pretending those differences do not exist.
Beyond text, the SDK covers the surrounding pieces a real application needs. It has an auto tool loop: define tools with Execute handlers, set MaxSteps, and the SDK runs the loop for you. It has 26 provider-defined tools, including web search, web fetch, file search, image generation, and code execution, depending on the provider. It supports prompt caching on Anthropic, Bedrock, and MiniMax, citations and grounding from xAI, Perplexity, Google, and OpenAI, and dynamic auth through a TokenSource interface for OAuth, rotating keys, and cloud IAM, with a cached variant for TTL-based caching. Retry with exponential backoff on retryable HTTP errors, 429 and 5xx, is built in, and 10 lifecycle hooks cover observability and interception, including permission gates, secret scanning, output transformation, and loop control. Observability integrations for Langfuse and OpenTelemetry are available as separate submodules.
MCP Support, Without a Separate Client Library
Model Context Protocol support is where GoAI earns its place in a modern agent stack. The Model Context Protocol is an open standard for connecting AI applications to external tools and data sources, with a client-server architecture in which a host creates one client per server, and tools, resources, and prompts are the server primitives.
GoAI ships an MCP client, documented on goai.sh, that speaks MCP over three transports: stdio for local servers run as child processes, Streamable HTTP for remote servers, and legacy SSE for older remote servers. You connect a client, list its tools, and convert them with mcp.ConvertTools into GoAI tools, which then work with GenerateText and StreamText exactly like native tools. For OAuth-protected remote servers, v0.8.0 added MCP OAuth 2.1 with PKCE, including authorization server discovery, dynamic client registration, token refresh, and retry on 401, so no external wrapper is needed.
That is a practical advantage over a library that only handles model calls. If your Go service already needs to talk to an MCP server, for example a filesystem server or an internal tool server, GoAI lets the same SDK own both the model call and the tool bridge, instead of adding a second MCP library and gluing the two together by hand.
The Benchmark Claim, Read Honestly
GoAI's headline performance claim is striking: 1.1x faster streaming, 24x faster cold start, and 3.1x less memory than the Vercel AI SDK. The README benchmark table gives the numbers behind it.
Metric | GoAI | Vercel AI SDK | Improvement |
|---|---|---|---|
Streaming throughput | 1.46ms | 1.62ms | 1.1x faster |
Cold start | 569us | 13.9ms | 24x faster |
Memory, 1 stream | 220KB | 676KB | 3.1x less |
GenerateText | 56us | 79us | 1.4x faster |
Read the footnote before you quote the headline. The README states the benchmark used a mock HTTP server, identical SSE fixtures, and an Apple M2. That is a sensible way to measure SDK overhead, and it is also the measurement most favorable to a compiled Go binary against a JavaScript runtime. Cold start is where a Go binary should win, and 569 microseconds against 13.9 milliseconds is a plausible shape for that win. It is not a measurement of model latency, token throughput on a real provider, or end-to-end application performance, and it is a project-published benchmark, not an independent one. Treat it as evidence that the SDK is light, not as proof that your application will run 24 times faster.
There is a second claim to read carefully. The GitHub tagline says "stdlib only", and the signal summary repeats that idea, but the README's own minimal dependencies section is more precise: the core depends on golang.org/x/oauth2 and github.com/coder/websocket for realtime sessions, plus one indirect dependency. The author post from April 2026 described 2 dependencies at v0.6.1. So the honest description is minimal dependencies, not zero dependencies, and the realtime voice feature is the reason for the websocket dependency. If you do not use realtime voice, that dependency still ships with the module, so check the module graph for your own build rather than trusting a tagline.
Who Should Try It, and Who Should Wait
GoAI makes the most sense for Go developers who already build services in Go and want to add model calls without adopting a second language runtime for the AI layer. If your backend is Go, your deployment is a single static binary, and you want provider choice without a Python sidecar, GoAI fits the shape of your stack. It also fits if you value typed structured output, since generics give you a compile-time contract for what the model returns, and if you already use MCP servers and want one SDK for both model calls and tool bridging.
You should probably wait, or keep expectations modest, if you need a mature agent framework rather than a model SDK, if you rely on a provider or feature GoAI has not yet covered, or if your team is not on Go 1.25 or later, which GoAI requires. The project is young, created in March 2026, and its 233 stars reflect early adoption, not a settled ecosystem. Pin a version, test your providers against your own prompts, and treat the benchmark as a starting point for your own measurement, not a conclusion.
If you work in the same AI coding world, the site has a related spotlight on a tool that turns one prompt into a full AI dev team: Harness: Turn One Prompt Into a Full AI Dev Team. GoAI gives a Go service the model layer, and Harness shows what a team of agents can do on top of a layer like that.
Frequently Asked Questions
Is GoAI an official Vercel product?
No. It is an independent open source project, MIT licensed, inspired by the Vercel AI SDK. It is not affiliated with Vercel, and it is written for Go, not TypeScript.
How do I install it?
Run go get github.com/zendev-sh/goai@latest in a Go module. It requires Go 1.25 or later, and hosted providers auto-resolve API keys from environment variables.
Does switching providers really require no code changes?
The call site stays the same, and you change the model constructor. Provider differences in models, tool support, and behavior still exist, so test each provider against your prompts before you rely on a switch in production.
Does GoAI support MCP?
Yes. Its MCP client supports stdio, Streamable HTTP, and legacy SSE transports, converts MCP tools into GoAI tools, and since v0.8.0 handles MCP OAuth 2.1 with PKCE for remote servers.
Is GoAI really dependency free?
Not exactly. The README lists minimal dependencies: golang.org/x/oauth2 and github.com/coder/websocket for realtime sessions, plus one indirect dependency. That is a small footprint compared with the 170 plus dependencies the author cited for LangChainGo, but it is not zero.