> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pluxx.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Exa Research Example

This is the cleanest public page for the Exa distribution example.

If you are at Exa and you just found Pluxx, the short version is:

* you already have a strong public MCP
* you already have a strong Claude-first workflow shape
* Pluxx is the source-of-truth layer that turns those into one maintained plugin project for Claude Code, Cursor, Codex, and OpenCode

You do not need to replace Exa's MCP or invent a new workflow from scratch. The point of this example is to show what happens when the Exa workflow layer gets compiled into native installs for the four agent hosts people are already using.

Use this page when you want the shortest answer to:

* can Pluxx take a strong Claude-first research-plugin shape and carry it across the core four
* is there a public example that is not just a docs workflow
* does Pluxx support specialist agents, commands, auth, and richer brand metadata together

## Install in your host

If you just want to try it, start here.

Important:

* this example includes a local `sessionStart` hook: `scripts/check-exa-setup.sh`
* the hook only reports whether `EXA_API_KEY` is set and prints setup guidance
* using these installers means explicitly trusting that local hook

Claude Code:

```bash theme={null}
curl -fsSL https://raw.githubusercontent.com/orchidautomation/pluxx/main/example/exa-plugin/release/install-claude-code.sh | bash
```

Cursor:

```bash theme={null}
curl -fsSL https://raw.githubusercontent.com/orchidautomation/pluxx/main/example/exa-plugin/release/install-cursor.sh | bash
```

Codex:

```bash theme={null}
curl -fsSL https://raw.githubusercontent.com/orchidautomation/pluxx/main/example/exa-plugin/release/install-codex.sh | bash
```

OpenCode:

```bash theme={null}
curl -fsSL https://raw.githubusercontent.com/orchidautomation/pluxx/main/example/exa-plugin/release/install-opencode.sh | bash
```

Optional for higher limits:

```bash theme={null}
export EXA_API_KEY="your_exa_api_key"
```

## What this example proves

The source project in [`example/exa-plugin`](https://github.com/orchidautomation/pluxx/tree/main/example/exa-plugin) proves that one maintained Pluxx source project can package an Exa-style research operator workflow for:

* Claude Code
* Cursor
* Codex
* OpenCode

This example is built against:

* Exa's public MCP
* Exa's public docs
* the workflow shape of Exa's official Claude plugin

It is a clean-room example, not an official Exa release.

## What Pluxx changes for a team like Exa

Without Pluxx, expanding beyond one host usually means rebuilding the same workflow layer several times:

* once for Claude Code
* again for Cursor
* again for Codex
* again for OpenCode

Pluxx changes that maintenance model. You keep one workflow source project, then Pluxx compiles the most native honest version of that experience for each host.

## What is inside the source project

The example includes:

* specialist agents:
  * `people-scout`
  * `company-scout`
  * `code-scout`
  * `news-scout`
  * `source-auditor`
  * `synthesis-reviewer`
* explicit workflow commands:
  * deep research
  * company research
  * people research
  * code research
  * source review
  * news brief
* shared auth and setup guidance
* rich brand metadata:
  * icon
  * screenshots
  * color
  * default prompts
  * website / privacy / terms links

## Mechanical proof

Primary proof doc:

* [Exa Research Example proof](https://github.com/orchidautomation/pluxx/blob/main/docs/exa-research-example.md)

That proof covers:

* `doctor`
* `lint`
* `build`
* `install`
* `verify-install`

Across:

* Claude Code
* Cursor
* Codex
* OpenCode

## Live workflow proof

This is no longer only a build/install example.

The Exa plugin shape is now live-proven across real host surfaces:

* Claude Code app
* Cursor interactive flow
* Codex Desktop app
* OpenCode CLI

That matters because it shows the bundled Exa MCP is actually callable through the generated plugin workflows, not just listed in metadata.

## Why this example matters

This example is useful because it shows what Exa could look like beyond a single Claude-first surface.

The important outcome is not just that Exa search is callable.

It is that one maintained workflow layer can now reach:

* Claude Code
* Cursor
* Codex
* OpenCode

without forcing Exa to maintain four separate plugin products just to keep the same research experience available where developers already work.

## What Pluxx actually adds

Pluxx is not replacing Exa's MCP and it is not pretending one host can behave exactly like another.

What it adds is:

* one maintained source project for the workflow layer
* native commands, skills, subagents, and install packaging per host
* shared auth and setup guidance
* install verification instead of trusting generated files alone
* one place to improve prompts, workflow structure, and branding instead of redoing that work host by host

## Best next pages

* [Docs Ops Flagship Proof](/examples/docs-ops-flagship)
* [Self-hosting Pluxx plugin](/examples/self-hosting-pluxx)
* [Local core-four proof](/workflows/local-core-four-proof)