@czottmann/pi-tensorx

TensorX provider extension for pi. It registers tool-capable TensorX models under the tensorx provider.

Install

From npm:

pi install npm:@czottmann/pi-tensorx

From a local checkout:

cd path/to/pi-tensorx
npm install
pi install "$PWD"

Set up auth

Use pi's API-key flow:

pi
/login
# Choose "Use an API key", then "TensorX".

Or set an environment variable before starting pi:

export TENSORX_API_KEY=your-key-here

TensorX uses static API keys, so it appears under API keys in /login, not under subscriptions.

Note: the live catalog endpoint requires a key. In interactive sessions pi refreshes the catalog after login, using the key you saved via /login — no restart needed. TENSORX_API_KEY is only required to load the live catalog in non-interactive modes (pi --list-models does not refresh catalogs) or before the first login. Without any key, the extension registers a bundled snapshot of the catalog — enough to log in via /login and use the models.

Use

List registered models:

pi --list-models | grep tensorx

Start pi with TensorX:

pi --provider tensorx

In interactive mode, /tensorx-models lists the TensorX models registered by the extension.

How it works

The extension registers the tensorx provider on startup via pi.registerProvider() using pi's openai-completions API adapter, keeping only models that report supports_function_calling. When TENSORX_API_KEY is set, the catalog is fetched at load; in interactive sessions pi also refreshes the catalog after /login using the saved key, so new models appear without a restart.

Model metadata comes from each entry's model_info:

• max_input_tokens (or max_tokens) becomes pi's context window.
• max_output_tokens becomes the max output.
• input_cost_per_token, output_cost_per_token, cache_read_input_token_cost, and cache_creation_input_token_cost become pi cost metadata, converted to per-million-token cost.
• supports_vision adds image input.
• supports_reasoning marks a model as reasoning-capable.

Duplicate model IDs in the catalog are de-duplicated, keeping the first.

The catalog fetch calls GET https://api.tensorx.ai/v1/model/info. Fetches have a per-attempt timeout and retry transient failures (network errors, timeouts, HTTP 429/5xx, invalid responses) with backoff. Without TENSORX_API_KEY (or when the fetch fails), the extension registers a bundled snapshot of the catalog instead — the snapshot is what lets TensorX appear under /login → API Keys: pi only lists providers that have registered models. The last successfully loaded catalog is persisted and restored at startup, so models stay selectable even when the API is unreachable — the cached catalog appears in the model picker immediately, while a refresh is still running in the background. Note that non-interactive runs (pi --list-models) do not refresh provider catalogs, so in those modes models come from the TENSORX_API_KEY pre-fetch, the persisted catalog, or the snapshot. Inference needs either a saved API key from /login or TENSORX_API_KEY.

Development

npm run check
npm run build
pi -e . --provider tensorx

Publishing

GitHub Actions publishes the package to npm when a GitHub Release is published. The release tag must match package.json exactly, with or without a leading v (v1.0.0 and 1.0.0 both work for version 1.0.0).

The workflow uses npm Trusted Publishing, so it does not need an npm token secret. Configure this package on npm with this repository and workflow file (.github/workflows/publish.yml). The workflow builds the package, runs npm run check, and publishes with npm provenance.

Author

Carlo Zottmann, [email protected]

• Website: https://actions.work
• GitHub: https://github.com/czottmann
• Bluesky: https://bsky.app/profile/zottmann.dev
• Mastodon: https://norden.social/@czottmann