The front door of the Pipelex readme lives in another repository

The front door is generated from Pipelex/.github

Two HTML comments sit above the quick start section and one sits below it.

The opening one is `onboarding: front-door`. The next says the region is generated from the Pipelex onboarding source, that it is replaced from a raw URL under `Pipelex/.github`, and that it should not be edited in place.

So the first several hundred words of the readme, the part every visitor reads, are owned by a different repository and pulled in as a rendered file. The runtime documentation starts below the closing comment, under a heading that reads like an alternative rather than the main event: prefer to run it yourself, and this repository is the runtime.

That split has consequences worth naming. A reader who wants to evaluate the project reads onboarding copy written somewhere else, and a contributor who tries to fix a typo in the quick start discovers the file is overwritten. It is a deliberate and common pattern for keeping one front door across several repositories in an organisation that also publishes plugins, method app templates and a cookbook, all of which are separate projects under the same account.

Elastic-2.0 in the manifest and no recognised licence in the metadata

The licence is stated twice and the two statements are not the same kind of statement.

The manifest field reads `license = "Elastic-2.0"`, with `license-files = ["LICENSE"]` alongside it, and there is a LICENSE file at the repository root under a badge. The repository's own licence metadata comes back with no recognised identifier at all.

Elastic License 2.0 is source-available rather than an OSI-approved licence, and it carries conditions a permissive licence does not: it is accepted by a company rather than an individual, and it restricts offering the software as a hosted service. The organisation behind the project is a company, listed as the author with the domain of the project and a separate maintainer entry for staff, so the licence suits a commercial vendor.

That sits alongside a Hub for methods at a separate domain and a console to sign up for, and the readme describes running methods as a service for customers as one of the delivery options. Whether any given deployment falls inside or outside the licence terms is a question for the licence text, not something the repository answers, and the missing metadata identifier means an automated licence check sees nothing at all.

The description field also carries a small inconsistency worth recording: the repository description says composable Al workflows, with a lowercase l, while the manifest description says composable AI methods.

A Python runtime whose agent plugins need Node.js on your PATH

The plugin route is the recommended one in the quick start, and it is the one that brings a second runtime with it.

For Claude Code there are two commands: adding a plugin marketplace from `Pipelex/pipelex-plugins`, then installing the plugin from it. For Codex there are three, adding the same marketplace, exporting an API key in the `plx_sk_` form, then restarting, running the plugins command and trusting the hook on first run, with a stated minimum of Codex 0.141 or later.

Both entries then say the same thing: the plugin's hook and the Pipelex tools run on Node.js, so Node.js has to be on your PATH. That is stated twice in the quick start, once per agent, which suggests it was learned the hard way.

So the shortest documented path to running a method requires a Node.js runtime, a marketplace add, an API key created in a web console, and a restart of the coding agent. The self-hosted path is the three commands below it, one of which is the Python package install.

The repository itself is consistent about wanting both. Its root holds agent configuration directories for three tools, `.claude/`, `.codex/` and `.cursor/`, alongside `.pipelex-dev/` and `.vscode/`. It also holds both `CLAUDE.md` and `CLAUDE.md` under a second name, `CLA.md`, which is two files of agent instructions in one repository root.

The MCP needs no key and the plugin stores one in your keychain

The two entry points to the same service use different authentication models, and the file is clear about both.

The plugin asks for an API key when you enable it, and stores it in your operating system keychain. You create it in the console.

The MCP asks for nothing. It is added by address in the chatbot's settings, the instructions say nothing to install and no key, and the reason given is that the MCP runs on your signed-in session. So one route is a bearer key held locally and the other is a delegated browser session.

There is also a documented conflict case. Claude Code loads whatever has been added to your Claude account, so a person can end up with both the plugin and the MCP installed, and the resolution is stated as a property of the software rather than as a configuration step: when both are present, the MCP defers to the plugin's tools, and there is nothing to turn off.

One capability gap is named explicitly. A method run needs a file the MCP can reach by URL. In ChatGPT you can attach the file to the conversation and ask for a run on it, and the file says Claude has no way yet to hand the MCP a file you attached. So the same feature is available in one supported chatbot and not the other, for a reason that is a product gap rather than a configuration mistake.

The Rich extra exists, and a stock install has Rich anyway

The `cli` extra is documented at length, and the argument ends by conceding the point.

The extra installs Rich, which the two commands render their output through, along with the console log sink and the pretty-print mode. The guidance is that you should install it wherever Pipelex runs in a terminal, and that a server should leave it out and select the json log sink with the poor or silent pretty-print mode, on the reasoning that nothing on the path to running a method asks for Rich.

The last sentence of that entry says leaving the extra out does not make the environment Rich-free, because two core dependencies require Rich, so a stock install still contains it.

So the extra is a declaration rather than an exclusion. Which is a defensible thing to want, since it keeps the dependency honest about what a server actually imports, and the file is unusually candid about the fact that the optimisation does not remove anything.

The install sequence itself is three commands.

uv tool install "pipelex[cli]"
pipelex init
pipelex doctor

That is an isolated tool install of the package with the cli extra, then an init that writes a `~/.pipelex` configuration and offers to install the editor extension, then a doctor command that reports what is configured and what is missing. Provider support is split across more extras, with Anthropic, Google Vertex, Google Gemini and Mistral named in the visible portion.

Two environment variables do nothing unless you edit a second file

The environment template documents a private beta feature, and its instruction is a two-place enablement.

Two variables hold the Pipelex-operated inference service called Manifold, an endpoint and an API key. Both are optional. The endpoint is described precisely: the service origin, with scheme, host and port, and no version path and no trailing path, which is a small thing to get right and is worth having written down.

Then the caveat. Leave both blank unless you are in the beta, because the backend ships disabled in a backend configuration file, and filling these in without enabling it there does nothing.

So the environment file is necessary and not sufficient. A user who reads only the environment template sets two variables correctly and gets a feature that stays off, with no error to indicate why.

The rest of the template is a catalogue of provider credentials, and it is where the hygiene question lives. Twenty-odd keys are present with explanatory comments: OpenAI, Azure, AWS, Anthropic, MiniMax, Mistral, an image service, Google AI Studio, GCP, xAI, and a block of gateways including a token, three API keys and a pair of Scaleway values. One of them defaults to a filename: the GCP credentials path is set to `gcp_credentials.json`, a relative path to a secrets file that the repository would have to keep out of version control. Another comment has a typo, recomment for recommend, in the line telling you to use the Google key or the GCP credentials and not both.

Prettier is a contract, not a dependency

The Makefile contains the most surprising comment in the repository, and it explains a pin that would otherwise look arbitrary.

There is a directory for a Node toolchain, gitignored and provisioned on demand, holding two packages pinned exactly: prettier at 3.9.6 and zod at 4.5.4. The comment explains that both are pinned exactly and both have zero dependencies, so installing them there is reproducible without a lockfile. Then it says the prettier pin is the contract: a Python emitter at `pipelex/codegen/emitters/ts_zod.py` emits the bytes that this particular prettier leaves alone, so moving the version is an emitter change rather than a dependency bump, and the gate is expected to go red.

That is a real coupling, stated in the right place. The project generates TypeScript from Python, and the generated output is then checked for formatting by a specific version of a formatter, so a prettier upgrade is a change to what the generator must emit.

The rest of the Makefile explains how much a Python project's build leans on environment discovery. It sets bash with pipefail, includes a local `.env` file if one exists and exports it, so every recipe inherits those variables. It derives the project name out of the manifest with grep and sed, derives the minimum uv version the same way, wraps every venv path in quotes because project directories can contain spaces, and pins a default Python version of 3.13 with a separate empty variable for the linting version. There is also a Rust binary in the venv whose log level is forced to warn, and a pytest marker expression that excludes inference, model and image generation tests from the usual run.

Analytics and a test-data factory are runtime dependencies

The dependency list is annotated inline, one comment per entry, which is unusual and mostly a record of why each version boundary sits where it does.

Three of those comments explain the interesting cases. One dependency is held below a major with the note that the next major is planned and has not been assessed. One is pinned to an exact version. And the OpenTelemetry SDK has a floor of 1.39 with the reason given: 1.39 is where a specific in-memory log record exporter appears, and the tests for one log sink use it.

That last one is the clearest example of a test shaping a runtime floor. A test-only need raises the minimum version of a library every production install has to satisfy.

Two other entries raise the same question from a different direction. A factory library for building test fixtures is in the runtime dependency list rather than the development one, and so is a product analytics client. Both would normally sit on the other side of that line, and neither is explained by a comment the way the version pins are.

Around them sit the expected parts of an AI runtime: an HTTP client with a ceiling below 1.0, a Markdown parser with the linkify extra for the Markdown concept and the built-in PDF engine, a JSON to HTML converter, image and PDF libraries, networkx, an OpenAI client, an AI gateway client, and the pinned package that implements the method standard itself.

Editorial conclusion

Adopt the runtime, not the plugin, if you want to own your execution. Installing the Python package and pointing it at your own provider keys is the documented self-hosted path, and it avoids the Node.js requirement, the keychain round trip and the account signup that the agent route depends on. Four things to check first. The licence is Elastic-2.0 in the manifest, which is source-available rather than OSI open source, and the repository metadata carries no recognised licence identifier at all. The quick start you will read first is generated from another repository, so the front door and the runtime documentation can disagree. The Manifold variables in the environment template do nothing on their own, because the backend also has to be switched on in a second file. And two pinned Node tools decide whether the generated TypeScript passes the gate, which is an unusual amount of a Python project's correctness resting on one formatter version.

Frequently asked questions

Official sources

1. Issues
2. Pipelex/pipelex on GitHub
3. Project website
4. README
5. Releases