@czottmann/pi-whoami

A pi extension that adds a whoami tool. The tool reports the active provider, model, and thinking level of the current pi session.

Install

pi install npm:@czottmann/pi-whoami

From a local checkout:

pi install .

For one run from a local checkout:

pi -e ./extensions/whoami.ts

Usage

The extension registers one tool: whoami. It takes no arguments. Ask the agent something like "who am I running on?" and it can call the tool.

Example output:

{
  "provider": "openrouter",
  "model": "google/gemma-3-27b-it",
  "modelName": "Gemma 3 27B",
  "thinkingLevel": "high",
  "providerThinkingLevel": "high",
  "projectDir": "/Users/you/Code/my-project"
}

Fields

| Field | Description | |---|---| | provider | The active provider ID, for example openai-codex or openrouter. | | model | The active model ID, for example glm-5.3. | | modelName | The human-readable model name. Equal to the model ID when the catalog sets no name. | | thinkingLevel | The pi thinking level: off, minimal, low, medium, high, xhigh, or max. | | providerThinkingLevel | The thinking value that pi sent to the provider. See below. | | projectDir | The directory where pi started the session. |

providerThinkingLevel

Pi maps its thinking levels to values that the provider API accepts. The result depends on the provider and model:

• Most providers get a level string, for example high or xhigh. Pi can clamp levels. For example, a model without max support can receive high.
• Budget-based providers (older Anthropic models, some Google models) get a token budget. In this case the field holds a number.
• The field is null when the provider received no thinking directive, for example when thinking is off.

The extension reads this value from the outgoing provider request. Before the first request of a session, it falls back to the model's thinkingLevelMap.

Development

npm run check
npm run build
pi -e . --provider nebius-token-factory

Publishing

GitHub Actions publishes the package to npm when a GitHub Release is published. Releases are tagged vX.Y.Z, where X.Y.Z must match package.json exactly (for example tag v1.0.0 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
• My other Pi plugins: https://pi.dev/packages?name=%40czottmann
• Bluesky: https://bsky.app/profile/zottmann.dev
• Mastodon: https://norden.social/@zottmann