Eko

Eko is an open-source TypeScript framework from Fellou AI that builds agentic workflows where the browser is the runtime, not just an output target. It converts natural language instructions into structured multi-step plans, then executes them directly inside browser extensions or web apps using a compact visual-perception layer that strips webpages down to machine-readable elements before sending them to the LLM. With 4.9k GitHub stars and active development through 2025, Eko occupies a distinct niche: browser-side agent execution that works without a backend orchestration server.

Most agent frameworks treat the browser as a tool call. You run an orchestrator on a server, it decides to open a URL or click a button, and it sends that instruction to a headless browser instance somewhere else in your stack. Eko flips that model. The browser is not a peripheral - it is the runtime. The workflow planner, the tool executor, and the LLM integration all run inside the browser context, which changes what is possible and what is practical.

That is the idea behind Eko, the open-source TypeScript framework from Fellou AI. It is a niche position, but it is a real one, and for developers building browser extension products or computer-use agents, it is worth understanding what Eko actually gives you.

What Eko Is

Eko is a TypeScript framework for building agent workflows that run inside browsers. Fellou AI, the Chinese AI company behind it, built Eko to power their own browser-based AI products and then open-sourced the framework under the MIT license.

The project hit version 4.1.0 in December 2025 and has accumulated around 4.9k GitHub stars. The codebase is 97.7% TypeScript. It runs in three environments: browser extensions, standard web applications, and Node.js. For server-side use, Node.js support works, but the framework's real strengths show up in the browser environments, where its toolset and perception layer matter most.

Installation is one line:

pnpm install @eko-ai/eko

And a basic workflow looks like this:

const eko = new Eko({ llm: { provider: 'anthropic', model: 'claude-3-5-sonnet' } })

const result = await eko.run(
  "Search for the latest quarterly earnings for Apple, summarize the key numbers, and save a report to the desktop."
)

One natural language sentence becomes a multi-step plan that the LLM generates, that Eko converts into a structured workflow, and that the browser then executes.

Key Features

Browser-native execution

Eko's primary differentiator is that workflows run inside the browser, not against it. When the framework executes a workflow step that involves clicking a button or reading a table, it is doing that through browser APIs directly, not through a remote puppeteer process or a headless Chrome instance managed from a server.

This matters for browser extension products. An extension built on Eko can automate tasks on any tab the user has open, interact with authenticated sessions the user is already logged into, and respond to browser events without routing those interactions through an external server. For use cases like "summarize my open tabs" or "fill out this form based on data I give you," that architecture is both simpler and more capable than the server-orchestrates-headless-browser alternative.

The toolset Eko ships with reflects this: GUI interaction, form auto-fill, tab management, screenshot capture, file export, web search, and command execution. These are browser primitives, not abstractions over them.

TypeScript-first API

Eko is written in TypeScript from the ground up. There is no Python version. The agent API uses typed constructors and method chains, and workflows compose in a way that fits naturally into TypeScript projects without requiring unfamiliar abstractions.

For developers at TypeScript shops who want browser automation without adding a Python runtime or a separate orchestration server, that is a straightforward advantage. The same codebase that defines your browser extension's UI logic can define your agent workflows in the same language, the same build system, and the same test suite. Frameworks like Mastra make a similar argument for backend TypeScript work - Eko makes it for the browser layer specifically.

Workflow planner and visual debugging

When you call eko.run() with a natural language description, the framework does not immediately start clicking things. It first sends the task description to the LLM and asks it to produce a structured workflow plan: a sequence of named steps with defined inputs and outputs. That plan is a TypeScript object you can inspect, modify, or serialize before execution begins.

This offline planning step is one of Eko's cleaner design decisions. It separates "what we're going to do" from "doing it," which means you can build UIs that show users a preview of the plan before any automation starts. It also means plans can be stored, reused for similar tasks, and versioned. Fellou AI calls these "reusable and modifiable task plans" in their documentation.

The hook system extends this into runtime. You can register hooks that fire before or after any step, inspect the current state, modify inputs, or halt execution entirely. This is how you build human-in-the-loop checkpoints without restructuring your workflow. A hook before a "send email" step can surface a confirmation dialog. A hook after a "download file" step can log what was saved.

Multi-model support

Eko does not lock you to a single LLM provider. The framework supports Anthropic Claude, OpenAI, Google Gemini, and any endpoint that follows the OpenAI API format. You specify the provider and model at initialization:

const eko = new Eko({
  llm: {
    provider: 'openai',
    model: 'gpt-4o',
    apiKey: process.env.OPENAI_API_KEY
  }
})

Switching providers is a one-line change. The rest of your workflow code - the task descriptions, the hooks, the step logic - stays the same. This is the same provider-agnostic pattern that Mastra uses for its model routing and that LangGraph achieves through LangChain's model integrations.

Production deployment patterns

Eko's MIT license and framework-only architecture give you full control over deployment. For browser extension products, you bundle the framework with your extension and ship it through the Chrome Web Store or Firefox Add-ons. The LLM calls go directly from the user's browser to the API provider of your choice. There is no Eko-managed backend in the middle.

For web applications, you initialize Eko in the client and run workflows from user interactions. For server-side workflows in Node.js, you run the same framework in a standard Node environment. Version 4.0 added chat conversation support and optimized agent logic, and version 4.1.0 added parallel agent execution and workflow recovery, meaning long-running workflows can resume after failures without starting from scratch.

The VIEP Advantage

One of the more concrete technical claims Fellou AI makes is about their Visual-Interactive Element Perception technology. Sending a full webpage to an LLM is expensive. A complex page (even something as simple as a Google search results page) can be hundreds of thousands of characters of HTML. At LLM token rates, that is both slow and costly.

VIEP processes the DOM before it reaches the LLM. It identifies interactive elements (buttons, inputs, links, form fields) and semantically meaningful content, then produces a compact representation of only those elements. Fellou AI's published example takes Google's raw page from 221,805 characters down to 1,058 characters - a 99% reduction. That is a meaningful number. Token consumption and latency go down proportionally.

Whether that compression holds on the specific pages your workflows target is something you will need to test. Complex web apps with custom components or heavily JavaScript-rendered UIs may produce different results than static pages. But the underlying approach - perceive before sending, rather than sending everything and hoping the LLM finds what it needs - is a sound design choice that most browser automation frameworks skip.

Honest Assessment of 2026 Traction

Eko has real traction by the standards of a framework that targets a specific niche. 4.9k GitHub stars, an active release history through late 2025, and a production use case (Fellou AI's own browser products) behind the design decisions put it well past the proof-of-concept stage.

The harder question is community. The documentation site was not accessible at time of writing this review. The GitHub repository has activity, but the contributor base is small compared to frameworks like LangGraph or Mastra. Stack Overflow has almost nothing. YouTube has very little. The tutorials that exist are largely from the Fellou AI team directly.

This is a real constraint. If you run into an edge case, you will likely be reading source code, not searching for an answer that someone already posted. For teams comfortable with that - developers who read TypeScript fluently and treat open-source as a primary information source - this is manageable. For teams who depend on community knowledge bases, it is a meaningful adoption cost.

The browser-specific niche also limits the framework's total addressable audience. Eko is not trying to compete with LangGraph for backend orchestration work. It is not trying to compete with CrewAI for role-based multi-agent Python pipelines. It is solving a narrower problem: "I want to build a browser agent that can do multi-step tasks on the web without requiring a server." That problem is real, and Eko is currently one of the few frameworks that addresses it directly in TypeScript. The browser-use tool addresses a similar problem from the Python side.

Who Should Use Eko

The clearest fit for Eko is a TypeScript developer building a browser extension that needs to automate multi-step tasks using LLM intelligence. Whether that is a productivity tool, a research assistant, or a computer-use product, Eko gives you the framework layer - workflow planning, LLM integration, browser tooling, and hooks - so you are not building that from scratch.

The second fit is web application developers who want to add agent-powered automation to a web app that already runs in users' browsers. The same reasoning applies: Eko bundles the primitives, you build the product.

Eko is a poor fit for teams building backend orchestration pipelines, multi-service workflows that span databases and APIs, or anything that does not have a browser as a primary execution environment. For those use cases, LangGraph and Mastra are better options. For teams comparing TypeScript browser automation tools more broadly, checking what browser-use offers on the Python side is also worth the time.

Comparison to Mainstream Alternatives

Against LangGraph, Eko is not a substitute. LangGraph is a backend-first state machine framework for building complex agent graphs that span multiple services. Eko is a browser-first workflow framework for tasks that happen in a browser. A developer might use both: LangGraph for the backend reasoning and pipeline, Eko (or a similar browser tool) for the front-end execution. Treating them as competitors misunderstands what each is doing.

Against Mastra, Eko targets a different layer of the stack. Mastra is a full TypeScript framework for backend agents, workflows, RAG, and evals. It has a larger ecosystem, a hosted Cloud tier, and more community backing. If your agents live on a server, Mastra is the stronger choice. If your agents live in a browser, Mastra does not give you the browser-native toolset Eko does. For AI coding tools or developer-facing products that mix browser automation with code execution, the two could complement each other.

Against Python-based browser automation frameworks, Eko's TypeScript-native design is its primary argument. Teams that already write TypeScript and want to avoid a Python dependency are Eko's clearest audience.

Pricing and License

Eko is MIT-licensed and free. There is no hosted platform, no paid tier, and no enterprise edition. You bring your own LLM API keys, you run the framework on your own infrastructure (or bundle it into your browser extension), and your costs are whatever your LLM provider charges for API calls. The VIEP token reduction is particularly relevant here: lower token counts mean lower API bills for browser-intensive workflows.

Verdict

Eko is a focused framework that does something most agent frameworks do not: it runs inside the browser and treats the browser as a first-class runtime rather than a tool call destination. For the specific problem of building TypeScript browser extension products or web-based automation agents, it is one of the few purpose-built options available.

The gaps are real. The community is small, the documentation is thin, and the framework's narrow focus means it will not serve teams whose agent workflows span backend services and data pipelines. But the core design - natural language to structured workflow plan, token-efficient visual perception, browser-native execution, and a hook system for intervention - is solid engineering that reflects production experience from Fellou AI's own products.

If you are building a browser-native agent product in TypeScript and the alternatives feel like forcing a backend framework into a context it was not designed for, Eko is worth a close look.

Key features

• Browser-native execution with full DOM and tab control
• One-sentence to multi-step workflow generation via LLM planning
• Visual-Interactive Element Perception (VIEP) for 99% token reduction on web pages
• TypeScript-first API for browser extensions, web apps, and Node.js
• Hook system for human-in-the-loop intervention during execution
• Multi-model support: Claude, OpenAI, Gemini, and OpenAI-compatible endpoints
• Hierarchical offline planning with modifiable task plans
• MCP (Model Context Protocol) server integration
• Parallel agent execution and workflow recovery