# LinGoose: a modular Go framework for LLM applications, now in maintenance mode

> LinGoose packages threads, LLMs, loaders, splitters, embedders and indexes into importable Go modules. The README states it is no longer under active development and points new work at Phero.

**henomis/lingoose** — 🪿 LinGoose is a Go framework for building awesome AI/LLM applications.

- Repository: https://github.com/henomis/lingoose
- Website: https://simonevellei.com/lingoose
- Stars: 833 · Forks: 76
- Language: Go
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/henomis-lingoose

## What LinGoose solves for Go teams wiring LLM calls into services

Most LLM tooling arrives as a Python package or a hosted API. A Go backend that wants a conversation loop, a document loader and a vector index usually ends up hand-rolling the glue: request structs, retry logic, prompt assembly, chunking. LinGoose exists to remove that glue. The README describes it as "a Go framework for building awesome AI/LLM applications" and states three properties: it is modular, so you import only the modules you need; it abstracts features so you can swap implementations; and it is a complete solution for building an application from the ground up. The audience is Go developers who want LLM features inside an existing binary rather than in a sidecar service. The repository layout backs the modular claim: llm, thread, loader, textsplitter, embedder, index, rag, transformer, tool, observer, assistant and document are separate top-level directories, each importable on its own. If you only need chat completions, you pull in thread and llm and nothing else.

## Threads, pipelines and indexes: the mechanism behind a LinGoose app

The central data structure is the thread. In the README example, thread.New() creates one, AddMessage appends a user message, and NewUserMessage().AddContent(NewTextContent(...)) builds the message body. The LLM call does not return a string. openai.New().Generate(ctx, myThread) mutates the thread in place, appending the assistant reply, and the example prints the whole thread. That single design decision shapes everything else: conversation state lives in a value you own and can pass around, rather than in a client object. Around the thread sit the RAG pieces. loader reads source documents, textsplitter cuts them into chunks, embedder turns chunks into vectors, index stores and queries them, and rag ties the retrieval step to a generation step. The examples/ directory mirrors these concerns one directory at a time (rag, embeddings, loader, transformer, pipeline, observer), which is a useful map of what the framework considers a feature. Provider choice is expressed through go.mod rather than a plugin registry: the module requires github.com/sashabaranov/go-openai v1.24.0, github.com/henomis/cohere-go v1.1.2, github.com/henomis/pinecone-go/v2 v2.0.0, github.com/henomis/qdrant-go v1.1.0, github.com/henomis/milvus-go v0.0.4, github.com/RediSearch/redisearch-go/v2 v2.1.1 and github.com/henomis/langfuse-go v0.0.3. That list is also a constraint: adding an unlisted provider means writing your own implementation against the abstraction.

## Installing LinGoose and running a first chat call

There is no CLI and no server to start. LinGoose is a library, so the install step is creating a Go module and letting go mod tidy pull the dependency. The README gives exactly this sequence.

```bash
mkdir example
cd example
go mod init example
```

The application itself creates a thread, adds one user message and hands it to the OpenAI LLM. Note that Generate takes a context.Context and the thread by pointer, and that the reply is read back off the same thread object.

```go
package main

import (
	"context"
	"fmt"

	"github.com/henomis/lingoose/llm/openai"
	"github.com/henomis/lingoose/thread"
)

func main() {
	myThread := thread.New().AddMessage(
		thread.NewUserMessage().AddContent(
			thread.NewTextContent("Tell me a joke about geese"),
		),
	)

	err := openai.New().Generate(context.Background(), myThread)
	if err != nil {
		panic(err)
	}

	fmt.Println(myThread)
}
```

Resolve the dependency and supply the key the provider client expects. The README exports OPENAI_API_KEY before running, and go run . prints the joke line shown in the documentation.

```bash
go mod tidy
export OPENAI_API_KEY=your-api-key
go run .
```

If you see a panic instead of a reply, the error came from Generate and is most likely the provider rejecting or missing credentials, since the example surfaces it directly.

## The maintenance status is the first thing to weigh

The README opens with a notice that LinGoose is no longer under active development. It says the project will stay available and stable, and directs anyone starting something new to Phero, described as a Go framework built from the ground up for multi-agent AI systems. The release list is consistent with that: v0.3.0 was published on 2024-11-02, preceded by v0.2.1-alpha.2 on 2024-09-10 and v0.2.1-alpha.1 on 2024-06-28. The last push to the repository was on 2026-03-15, so the code has not been touched in roughly six months. None of this makes the library broken. It does mean that a provider API change, a new model family, or a Go toolchain bump will be fixed by whoever needs it, not by the maintainer. For a dependency sitting under a production service, that is a real cost, and it should be priced before adoption rather than after.

## Where LinGoose is the wrong tool

Two boundaries stand out. First, multi-agent orchestration. The README's own handoff to Phero frames LinGoose as the earlier foundation and Phero as the one built for multi-agent systems, so if your design is agents coordinating with each other, LinGoose is not the project the author is steering you toward. Second, anything needing a provider the module does not already require. The abstraction lets you implement your own, but you are then maintaining that adapter yourself against a codebase that is not receiving fixes. There is also a practical limit in the thread model: Generate mutates a thread you pass in, which is convenient in a single request path and awkward if you want to fan one conversation out to several models and compare replies, because each call appends to the same object. The README does not document rollback or thread cloning, so plan on constructing separate threads per branch.

## How LinGoose differs from LangChainGo

LangChainGo is the closest comparison and the difference is mostly in scope and dependency shape. LangChainGo mirrors the LangChain ecosystem in Go, with chains, agents and a large set of integrations. LinGoose keeps a smaller surface: thread, llm, loader, textsplitter, embedder, index, rag, transformer, tool, observer, assistant, document. The README's modular claim is worth reading literally here, because LinGoose's provider integrations are direct module requirements in go.mod (go-openai, cohere-go, pinecone-go, qdrant-go, milvus-go, redisearch-go, langfuse-go) rather than a plugin layer you opt into. If you want the broadest integration catalog and active development, LangChainGo is the better fit. If you want a small dependency graph and a thread-centric API you can read in an afternoon, LinGoose is easier to hold in your head, at the cost of the maintenance situation described above.

## Licence, upgrade cost and what to check before you commit

LinGoose is released under the MIT License, credited to Simone Vellei. MIT is permissive: it allows use, modification and redistribution with the licence text retained, and it carries no copyleft obligation on your application. That is a statement about the licence text, not legal advice, and the LICENSE file in the repository is the authoritative copy if your organisation needs one. On upgrades, the version history gives you the shape of the risk. The jump from v0.2.1-alpha.2 to v0.3.0 is a minor-version change on a pre-1.0 module, which under Go module semantics means the API can break without a major-version bump. There is no documented migration guide in the README, so the practical check is to read the diff of the subpackage you import. Concretely: confirm your provider appears in the require block of go.mod, confirm the subpackages you use still compile under your Go toolchain (the module declares go 1.21.1), and pin the version you validated rather than tracking the branch.

## Conclusion

Adopt LinGoose when you are maintaining an existing Go service that already imports github.com/henomis/lingoose and you want to keep the module graph stable. Do not adopt it for a new multi-agent project: the README states the project is no longer under active development and points to Phero instead. Before committing, verify that the specific subpackage you need (llm, rag, index) still compiles against your Go toolchain and that your chosen provider is present in go.mod, because the module pins providers such as github.com/sashabaranov/go-openai v1.24.0 and github.com/henomis/pinecone-go/v2 v2.0.0 rather than resolving them at runtime.

## FAQ

### Is LinGoose still maintained?

The README states that LinGoose is no longer under active development and that it will stay available and stable. The most recent release listed is v0.3.0 from 2024-11-02, and the last push to the repository was on 2026-03-15. The README points anyone starting a new project to Phero instead.

### How do I install LinGoose in a Go project?

Create a module with go mod init, add the imports github.com/henomis/lingoose/thread and github.com/henomis/lingoose/llm/openai, then run go mod tidy to resolve the dependency. There is no separate installer or CLI, since LinGoose is a library.

### Which LLM and vector store providers does LinGoose support?

The module requires github.com/sashabaranov/go-openai, github.com/henomis/cohere-go, github.com/henomis/pinecone-go/v2, github.com/henomis/qdrant-go, github.com/henomis/milvus-go, github.com/RediSearch/redisearch-go/v2 and github.com/henomis/langfuse-go. The README describes the framework as an abstraction of features, so other implementations can be written against the same interfaces.

## Sources

- [henomis/lingoose on GitHub](https://github.com/henomis/lingoose)
- [License: MIT](https://github.com/henomis/lingoose/blob/main/LICENSE)
- [Project website](https://simonevellei.com/lingoose)
- [README](https://github.com/henomis/lingoose/blob/main/README.md)
- [Releases](https://github.com/henomis/lingoose/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/henomis-lingoose