Gollama gives Go applications a client for local or remote Ollama servers, covering model management alongside completion, chat and embedding requests. Its main design choice is streaming through Go iterators: developers can consume generated text or model-transfer progress with a for range loop. That requires Go 1.23 or newer, according to the project README.
The package lives at github.com/okunix/gollama. That path matters because a separate project, Gaurav-Gosain/gollama, uses the same name for a terminal application. The okunix project is a library for developers embedding Ollama operations in their own software.
The useful adoption question is how this API fits an application. Ollama already provides an official Go client. Gollama offers a different calling style and a focused set of operations, but its reviewed repository snapshot lists no published releases. This assessment is based on the published README and package documentation, without independent runtime testing.
Which Ollama Operations Gollama Supports
Gollama covers both inference and model administration. An application can inspect available models, download one, generate a response and delete it through the same client.
The documented API surface breaks down as follows:
| Task | Methods | Streaming support |
|---|---|---|
| Check connectivity and server version | Ping, Version | None documented |
| List installed or loaded models | Tags, Ps | None documented |
| Inspect model details | ShowModelDetails | None documented |
| Create a model | Create | CreateStream |
| Copy or delete a model | Copy, Delete | None documented |
| Download or upload a model | Pull, Push | PullStream, PushStream |
| Generate a completion | Generate | GenerateStream |
| Generate a conversational reply | Chat | ChatStream |
| Create embeddings | Embed | None documented |
Tags and Ps answer different operational questions: the first lists local models, while the second lists models loaded in memory. ShowModelDetails exposes information such as the Modelfile, template, parameters and license.
Streaming also serves two different purposes here. Generation and chat streams deliver response chunks. Creation, pulling and pushing expose status updates for operations that may take time. Those progress streams could support a deployment dashboard or command-line progress display without waiting for the operation to finish.
I’d treat that combination as the practical attraction: one library can handle model preparation and the inference requests that follow. Applications needing only a chat endpoint may gain less from the broader management surface.
Streaming Uses Go 1.23 Range-Over-Function
Gollama’s streaming methods return iter.Seq2[T, error], plus a separate error from starting the operation. For example, GenerateStream returns:
(iter.Seq2[GenerateStreamResponse, error], error)
The first return value is an iterator yielding a response and an error on each iteration. Go 1.23’s range-over-function support lets callers consume it using ordinary loop syntax. The package documentation shows the same pattern for chat and model-management streams.
That creates two error-handling points. A request can fail before a stream is returned, and an operation can fail after streaming has begun. The ChatStream documentation explicitly describes an immediate error if chat cannot start, followed by an iteration error and termination if generation fails partway through.
The following illustrative function creates a local client and prints completion chunks. It assumes imports for context, fmt and github.com/okunix/gollama; it is not a reported test run.
func printCompletion(ctx context.Context) error {
client, err := gollama.NewClient(
ctx,
gollama.WithHost("http://localhost:11434"),
)
if err != nil {
return err
}
stream, err := client.GenerateStream(ctx, gollama.GenerateRequest{
Model: "gemma3",
Prompt: "Explain why the sky is blue.",
})
if err != nil {
return err
}
for chunk, err := range stream {
if err != nil {
return err
}
fmt.Print(chunk.Response)
}
return nil
}
The model name follows the README’s example. It assumes the selected server can serve that model; creating a client does not install it.
The loop’s appeal is straightforward: response handling stays in the surrounding function, where ordinary error returns and application state are already available. Streaming exposes output incrementally, but it is not evidence of faster model execution.
Check Metrics Before Switching Chat Code
One consequential difference appears in the published response types. The README’s generation example reads Metrics from the final response when Done is true. The package documentation also shows ChatResponse embedding Metrics.
However, the documented ChatStreamResponse lists model information, a message, completion state and an error field, without an embedded Metrics field. If an application depends on completion statistics from chat requests, I’d check this distinction before replacing Chat with ChatStream. The published types do not offer identical statistics access across those two methods. See the response definitions.
Configuration for Local and Remote Servers
The README documents three functional options:
WithHost(host)selects the Ollama server address, allowing local or remote endpoints.WithToken(token)configures a token for authenticating requests.WithTimeout(d)applies a timeout duration to the underlying HTTP client.
The installation command is:
go get -u github.com/okunix/gollama
This is the repository’s documented command. The -u flag requests dependency updates, so teams adopting an early project should review the resulting module changes.
Client creation has an important startup consequence. NewClient takes a context.Context, applies the supplied options and verifies server reachability before returning. It can fail because an option cannot be applied or because the server cannot be reached.
That is useful for a service that should refuse to start without Ollama. For software expected to launch while its model server is temporarily unavailable, client construction needs to sit inside the application’s retry or deferred-initialization strategy.
There is also a documentation inconsistency worth catching: the README’s configuration example omits the context argument and uses an ollama qualifier, while its quick start and the package signature use gollama.NewClient(ctx,...). The package signature is the clearer guide for integration.
Frequently Asked Questions
3 questions
1Does Gollama Require Go 1.23?
Yes. The README requires Go 1.23 or newer because the streaming interface uses range-over-function iterators.
