# eino-ext: the official extension shelf for CloudWeGo's Eino framework > Eino is CloudWeGo's Go framework for building LLM applications, and eino-ext is where the official implementations of its component types live: chat models, tools, retrievers, indexers, embeddings, document loaders and transformers. The repository is a multi-module Go project that versions each extension on its own schedule. **cloudwego/eino-ext** — Various extensions for the Eino framework: https://github.com/cloudwego/eino - Repository: https://github.com/cloudwego/eino-ext - Website: https://www.cloudwego.io/zh/docs/eino/core_modules/components/ - Stars: 827 · Forks: 382 - Language: Go - License: Apache-2.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/cloudwego-eino-ext ## Where eino-ext sits relative to Eino Eino itself is a Go framework for building LLM applications, and it defines a set of component types that an application assembles into a graph. Eino-ext is the companion repository that fills those types with concrete implementations. The README's framing is straightforward: the project hosts various extensions for the Eino framework, and among them are official implementations for Eino's component types. That division matters for how you read the code. The framework defines the interfaces, the composition model and the runtime, and it is a separate repository with its own releases. The extensions here are adapters: they take a service such as OpenAI, Claude, Gemini, Ark, Ollama, Google Search, Elasticsearch or Amazon S3 and expose it through the interface the framework expects. An application built on Eino is therefore an assembly of components, and this repository is the shelf you pick them off. The audience is Go developers who have already chosen Eino. If you are still deciding on a framework for LLM applications, the component documentation for Eino and the ecosystem integration documentation, both hosted on the CloudWeGo site, are the places to start. What lives here is what you reach for after that decision. ## The component types and the implementations shipped for them The README summarises the catalogue as a table of component types and the official implementations for each. The chat model row covers OpenAI, Claude, Gemini, Ark and Ollama, with the trailing ellipsis signalling that the list is not exhaustive. Tools include Google Search and DuckDuckGo. Retrievers and indexers cover Elastic Search and Volc VikingDB, the same pair appearing on both sides because a retrieval pipeline usually needs a store to read from and a store to write into. Chat templates include the default implementation. Document loaders cover WebURL, Amazon S3 and File. Document transformers cover HTMLSplitter and ScoreReranker, which handle splitting source documents into chunks and reordering retrieved chunks by relevance. Embeddings cover OpenAI and Ark. Lambdas cover utilities such as JSONMessageParser. Read as a set, these rows describe a complete retrieval augmented generation pipeline: load documents, transform them into chunks, embed the chunks, index them, retrieve and rerank them at query time, and reach a model through a chat template. The presence of Ark and Volc VikingDB, both ByteDance services, shows where the project's own production bias lies, and the presence of Ollama shows the other end, where a local model replaces a hosted API without changing the graph. ## Callback handlers for tracing and observability Beyond components, the repository ships callback handlers that implement Eino's CallbackHandler interface. The example the README names is Langfuse tracing, which is a hosted or self-hosted observability platform for LLM applications. The mechanism is the standard callback pattern: the framework notifies registered handlers as the graph executes, and a handler can record what happened for later inspection. For a team running an LLM application in production, this is the part of the extension set that tends to matter most, because a graph that calls a model, a retriever and a tool produces a chain of decisions that is hard to debug from logs alone. Handlers are also how you would count tokens, time individual steps or ship traces to an internal system, since the interface is a single seam rather than a change to each component. The README does not enumerate the full set of handlers, so the set of officially maintained integrations beyond Langfuse has to be read from the repository itself rather than from the summary. ## DevOps tooling for visual debugging and graph editing The third category is DevOps tooling, described in the README as an IDE plugin for Eino that enables visualized debugging, UI based graph editing and more. The detail page for it lives in the CloudWeGo documentation under the Eino Dev tooling section. This is the extension that addresses a specific and common pain: a graph built in code is hard to inspect when a branch goes wrong, and rewriting it means editing Go rather than dragging a node onto a canvas. A visual debugger lets you see which nodes ran, in what order, with what inputs, and a UI editor lets you change the shape of the graph without a rebuild. It is worth separating this from the other two categories, because it is not a library you import. It is a plugin you install in an editor, which means it has its own version, its own release rhythm and its own compatibility with the IDE you use, none of which the README details. ## Getting the code and following versions in a multi-module repository The README does not give installation commands, and it does not need to, because these extensions are ordinary Go modules and the CloudWeGo site hosts the documentation for the ecosystem integrations. What the repository itself does give is the shape of the release process, and it is unusual enough to matter. This is a multi-module Go project. The top level contains a components directory, and each component lives in its own module. The consequence shows up in the tag names: the recent releases are components/model/gemini/v0.1.37, components/model/claude/v0.1.26 and components/model/agenticqwen/v0.1.2. A tag is a module path plus a version, so each extension is versioned independently and a dependency on one component does not drag the others along with it. That is a real advantage for a framework whose components wrap third-party APIs, since those APIs change on their own schedules and you can take a Gemini bump without touching Claude. It is also a bookkeeping cost, because an application ends up with several module versions in its go.mod and upgrading one deliberately means editing that one line. The repository root also carries a small amount of maintenance tooling: an upgrade_cloudwego_eino.sh script for moving to a newer Eino version, a .golangci.yaml for linting, a .licenserc.yaml for licence header checks, a .testcoverage.yml for coverage settings and a _typos.toml for spelling checks. The components directory sits alongside callbacks, devops, libs, acp, adk and skills, and the README does not describe the last three of those. ## Where eino-ext is the wrong tool The first and most obvious limitation is that nothing here is portable. These components implement Eino's interfaces, and an application built on a different framework, or on Eino with its own hand-written components, gains nothing from this repository. A team that has not committed to Eino should look at the component documentation first. The second is the shape of the catalogue. The README's table ends several rows with an ellipsis, which is a hint that the implementations in the repository exceed the ones listed, but it also means the table cannot be used as a checklist for what is officially supported. The same applies to the callback handlers, where Langfuse is named as an example rather than the full list. Third, the parts of the repository that are newest are the parts least documented in the README. The acp, adk and skills directories appear in the tree with no explanation in the overview, and skills in particular suggests an agent-oriented direction that the README does not yet describe. For an adopter, that means part of the surface area of the repository is moving faster than its documentation. The fourth point is governance. The security notice asks that potential vulnerabilities be reported to ByteDance Security through their security centre or vulnerability reporting email, and explicitly asks that no public GitHub issue be filed. That is a reasonable and common arrangement for a project maintained inside a large company, and it also means the disclosure channel is not the issue tracker most contributors will reach for by default. ## Maintenance state and licence terms The project is not archived, and the last push was on 2026-10-19, the same day as the components/model/gemini/v0.1.37 tag. The components/model/claude and components/model/agenticqwen releases both date from 2026-09-24, which fits the picture of modules moving at their own pace rather than in lockstep. The licence is Apache-2.0, with both a LICENSE and a LICENSE-APACHE file at the root and a .licenserc.yaml that checks licence headers across the tree. Apache-2.0 is permissive and includes an express patent grant, with the usual condition that notices are preserved. That is a description of the terms rather than legal advice, and a commercial deployment involving model providers should check the provider terms separately, since those are outside this repository. The README is bilingual, with an English version and a Chinese one, and the project keeps a code of conduct and a contributing guide at the root. Documentation for the components themselves lives on the CloudWeGo site rather than in the repository, split between the component type documentation and the ecosystem integration documentation, which is where the difference between a type and an implementation is spelled out. ## Conclusion Adopt eino-ext if you build LLM applications in Go on the Eino framework and would rather use ByteDance-maintained component implementations than write your own model client, retriever or embedding wrapper. Do not adopt it if your application is not built on Eino, since none of these components carry over to another framework, and treat the undocumented areas of the repository, the acp, adk and skills directories, as moving targets rather than stable interfaces. Verify first which component type your pipeline needs, which implementation in the table covers it, and which module version you pin, since each extension is released under its own tag and does not move in step with the others. ## FAQ ### What is the difference between Eino and eino-ext? Eino is the CloudWeGo Go framework for building LLM applications that defines the component types and the graph model. eino-ext is the companion repository that hosts official implementations of those component types, such as chat models for OpenAI, Claude, Gemini, Ark and Ollama. ### Which document and retriever components does eino-ext provide? Document loaders cover WebURL, Amazon S3 and File. Document transformers cover HTMLSplitter and ScoreReranker. Retrievers and indexers cover Elastic Search and Volc VikingDB, and embeddings cover OpenAI and Ark. ### How does eino-ext version its releases? It is a multi-module Go repository, so each extension is released under its own tag with the module path in the name, for example components/model/gemini/v0.1.37. Extensions therefore move independently of each other and of the core Eino framework. ### How do I report a security issue in eino-ext? The README asks that potential security issues go to ByteDance Security through their security centre or the vulnerability reporting email, and explicitly says not to open a public GitHub issue. ## Sources - [cloudwego/eino-ext on GitHub](https://github.com/cloudwego/eino-ext) - [License: Apache-2.0](https://github.com/cloudwego/eino-ext/blob/main/LICENSE) - [Project website](https://www.cloudwego.io/zh/docs/eino/core_modules/components/) - [README](https://github.com/cloudwego/eino-ext/blob/main/README.md) - [Releases](https://github.com/cloudwego/eino-ext/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cloudwego-eino-ext