pi-requesty-discover
Discover available Requesty models for the Pi Coding Agent
Package details
Install pi-requesty-discover from npm and Pi will load the resources declared by the package manifest.
$ pi install npm:pi-requesty-discover- Package
pi-requesty-discover- Version
2.2.0- Published
- Sep 10, 2026
- Downloads
- 566/mo · 26/wk
- Author
- enolive
- License
- MIT
- Types
- extension
- Size
- 46 KB
- Dependencies
- 1 dependency · 2 peers
Pi manifest JSON
{
"extensions": [
"./index.ts"
]
}Security note
Pi packages can execute code and influence agent behavior. Review the source before installing third-party packages.
README
pi-requesty-discover
This extension helps you discover currently available models in requesty.ai for your Pi Coding Agent.
This is a fork of pi-requesty with additional features:
- Use the
apiKeyfrom the model registry allowing you to use pi’s full value resolution capabilities - Health-check available models and write a log about them
- Brief information about what was found, including added/removed models, health summary
- Confirm before writing
models.json, with a dry-run mode that only previews - A footer status line showing your monthly Requesty spend against your monthly limit
When and why use it
Use this extension if
- you are on Requesty.ai
- you are limited to certain models by a company policy (for instance, for data residency/protection reasons)
- you don’t want to handcraft your own curated list of models constantly
- you want to health-check models and preview the diff before writing
- you want to keep in touch with your usage without having to constantly visit the Requesty dashboard
Installation
# NPM
pi install npm:pi-requesty-discover
# GitHub
pi install git:github.com/enolive/pi-requesty-discover
Install locally
Check out the code from the official code repository https://github.com/enolive/pi-requesty-discover, and then:
pi install ./pi-requesty-discover
To run once without installing:
pi -e ./pi-requesty-discover
Configuration
The extension reads the requesty-export provider from ~/.pi/agent/models.json.
You can override the provider id with the REQUESTY_PROVIDER_ID variable.
Example:
{
"providers": {
"requesty-export": {
"name": "Requesty",
"baseUrl": "https://router.requesty.ai/v1",
"api": "openai-completions",
"apiKey": "$REQUESTY_API_KEY",
"models": []
}
}
}
❗ IMPORTANT
Health checks are designed to use only a few tokens, but they still make real Requesty API calls and will consume credits.
On startup, the extension fetches <baseUrl>/models using the configured apiKey as the bearer token and registers discovered and healthy models with Pi.
Environment variables
| Name | Required | Type | Default | Meaning |
|---|---|---|---|---|
REQUESTY_PROVIDER_ID |
no | string |
requesty-export |
The id of the provider. |
REQUESTY_HEALTH_CHECK_MODE |
no | off, basic, full |
full |
The health-check mode. |
PI_CODING_AGENT_DIR |
no | string |
~/.pi/agent |
pi configuration directory |
Command
Inside Pi:
/requesty-discover
The command:
- discovers Requesty models (and optional health checks)
- shows a summary notification (added/removed IDs, health summary)
- asks for confirmation before writing
~/.pi/agent/models.json - refreshes Pi’s model registry so the new models are immediately available in
/model - reports whether the file was updated
If there are no model ID changes, confirmation still offers a metadata refresh write, which might have changed as well.
/requesty-discover --dry-run
Same discovery and health checks, but never prompts to write and leaves models.json unchanged.
pi -p "/requesty-discover"
pi -p "/requesty-discover --dry-run"
You can also run the command from the CLI in a non-interactive mode.
Usage status
The extension shows your current Requesty monthly spend as a persistent line in Pi’s footer, e.g.:
<API Key Name>: $63.55/$150.00 (42%)
When your API key has no monthly limit (monthly_limit is 0), the limit is treated as unlimited:
<API Key Name>: $63.55 (unlimited)
When you select a model from a provider other than REQUESTY_PROVIDER_ID, the status is cleared — there is no Requesty usage to show for it.
📌 NOTE
The footer update is best-effort and never blocks a turn.
If it fails (network error, stale context after /reload), it fails silently without spamming notifications.