How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

open-pr - Prompt - OpenSmartRoute

Name: open-pr
Author: Koeroesi86

Prompt file imported from Koeroesi86/node-webserver (.github/prompts/open-pr.prompt.md). Copyright stays with the author.

Open a pull request for the current branch, following the repo rules in CLAUDE.md and the template in .github/pull_request_template.md.

Before opening

Refuse if the branch is based on master or if it contains multiple unrelated changes. The branch should be one change from a branch off master.
Check the diff against origin/master and identify the impacted files.
If this PR is stacked on another branch, say so in "What and why" and use the base branch accordingly.

Which packages publish

A change in packages/<name>/** or pnpm-lock.yaml publishes that package and its dependents.

node-worker publishes node-worker, node-worker-pool, node-worker-express, node-lambda-invoke, node-webserver, node-webserver-cli, node-webserver-service
node-worker-pool publishes itself, node-worker-express, node-lambda-invoke, node-webserver, node-webserver-cli, node-webserver-service
node-worker-express and node-lambda-invoke publish themselves, node-webserver, node-webserver-cli, node-webserver-service
node-webserver publishes itself, node-webserver-cli, node-webserver-service
node-webserver-cli and node-webserver-service publish themselves
pnpm-lock.yaml publishes the packages whose dependencies changed, plus their dependents
tools/, docs, and .github/ do not publish

Check the workspace dependency graph and say whether the change is breaking. If no publishable package is affected, remove the Release section from the PR body.

PR body

Fill the template section by section:

What and why: a few sentences, including Closes #N if an issue is being closed or the stacked base branch if relevant
Changes: one line per change
Behaviour changes: user-visible config, API, default, or output changes; delete if none
Release: affected packages and whether the change is breaking
Verification: what was tried by hand, as run and seen; do not list lint, build, tests, quality, the integration test or the load test, as CI runs them
Not verified: what CI does not cover and was not tried by hand, with a reason
Not in this pull request: follow-ups and scope boundaries with issue links

Run the relevant local verification before opening the PR; CI repeats it, so it is not reported in the PR body.

Opening

Title should be an imperative sentence without a prefix, as a squash-commit title.
Push the branch to origin and open the PR with the filled template.
Do not merge branch protection settings or repository settings.
Give the user the PR link and the final Not verified list.

Never comment on the PR itself; instead, keep the PR description accurate and up to date with gh pr edit --body-file if the change changes.

Install open-pr and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

Open a pull request for the current branch, following the repo rules in `CLAUDE.md` and the template in `.github/pull_request_template.md`. ## Before opening - Refuse if the branch is based on `master` or if it contains multiple unrelated changes. The branch should be one change from a branch off `master`. - Check the diff against `origin/master` and identify the impacted files. - If this PR is stacked on another branch, say so in "What and why" and use the base branch accordingly. ## Which packages publish A change in `packages/<name>/**` or `pnpm-lock.yaml` publishes that package and its dependents. - `node-worker` publishes `node-worker`, `node-worker-pool`, `node-worker-express`, `node-lambda-invoke`, `node-webserver`, `node-webserver-cli`, `node-webserver-service` - `node-worker-pool` publishes itself, `node-worker-express`, `node-lambda-invoke`, `node-webserver`, `node-webserver-cli`, `node-webserver-service` - `node-worker-express` and `node-lambda-invoke` publish themselves, `node-webserver`, `node-webserver-cli`, `node-webserver-service` - `node-webserver` publishes itself, `node-webserver-cli`, `node-webserver-service` - `node-webserver-cli` and `node-webserver-service` publish themselves - `pnpm-lock.yaml` publishes the packages whose dependencies changed, plus their dependents - `tools/`, docs, and `.github/` do not publish Check the workspace dependency graph and say whether the change is breaking. If no publishable package is affected, remove the Release section from the PR body. ## PR body Fill the template section by section: - **What and why**: a few sentences, including `Closes #N` if an issue is being closed or the stacked base branch if relevant - **Changes**: one line per change - **Behaviour changes**: user-visible config, API, default, or output changes; delete if none - **Release**: affected packages and whether the change is breaking - **Verification**: what was tried by hand, as run and seen; do not list lint, build, tests, quality, the integration test or the load test, as CI runs them - **Not verified**: what CI does not cover and was not tried by hand, with a reason - **Not in this pull request**: follow-ups and scope boundaries with issue links Run the relevant local verification before opening the PR; CI repeats it, so it is not reported in the PR body. ## Opening - Title should be an imperative sentence without a prefix, as a squash-commit title. - Push the branch to origin and open the PR with the filled template. - Do not merge branch protection settings or repository settings. - Give the user the PR link and the final **Not verified** list. Never comment on the PR itself; instead, keep the PR description accurate and up to date with `gh pr edit --body-file` if the change changes.

{ "prompt": "Open a pull request for the current branch, following the repo rules in `CLAUDE.md` and the template in `.github/pull_request_template.md`.\n\n## Before opening\n- Refuse if the branch is based on `master` or if it contains multiple unrelated changes. The branch should be one change from a branch off `master`.\n- Check the diff against `origin/master` and identify the impacted files.\n- If this PR is stacked on another branch, say so in \"What and why\" and use the base branch accordingly.\n\n## Which packages publish\nA change in `packages/<name>/**` or `pnpm-lock.yaml` publishes that package and its dependents.\n\n- `node-worker` publishes `node-worker`, `node-worker-pool`, `node-worker-express`, `node-lambda-invoke`, `node-webserver`, `node-webserver-cli`, `node-webserver-service`\n- `node-worker-pool` publishes itself, `node-worker-express`, `node-lambda-invoke`, `node-webserver`, `node-webserver-cli`, `node-webserver-service`\n- `node-worker-express` and `node-lambda-invoke` publish themselves, `node-webserver`, `node-webserver-cli`, `node-webserver-service`\n- `node-webserver` publishes itself, `node-webserver-cli`, `node-webserver-service`\n- `node-webserver-cli` and `node-webserver-service` publish themselves\n- `pnpm-lock.yaml` publishes the packages whose dependencies changed, plus their dependents\n- `tools/`, docs, and `.github/` do not publish\n\nCheck the workspace dependency graph and say whether the change is breaking. If no publishable package is affected, remove the Release section from the PR body.\n\n## PR body\nFill the template section by section:\n- **What and why**: a few sentences, including `Closes #N` if an issue is being closed or the stacked base branch if relevant\n- **Changes**: one line per change\n- **Behaviour changes**: user-visible config, API, default, or output changes; delete if none\n- **Release**: affected packages and whether the change is breaking\n- **Verification**: what was tried by hand, as run and seen; do not list lint, build, tests, quality, the integration test or the load test, as CI runs them\n- **Not verified**: what CI does not cover and was not tried by hand, with a reason\n- **Not in this pull request**: follow-ups and scope boundaries with issue links\n\nRun the relevant local verification before opening the PR; CI repeats it, so it is not reported in the PR body.\n\n## Opening\n- Title should be an imperative sentence without a prefix, as a squash-commit title.\n- Push the branch to origin and open the PR with the filled template.\n- Do not merge branch protection settings or repository settings.\n- Give the user the PR link and the final **Not verified** list.\n\nNever comment on the PR itself; instead, keep the PR description accurate and up to date with `gh pr edit --body-file` if the change changes.", "variables": [], "notes": "Open a pull request for the current branch using the repo template and package release rules. Mode: agent.", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/Koeroesi86/node-webserver", "path": ".github/prompts/open-pr.prompt.md", "ref": "cbde33854dcf2da819264e6ced45262240e0e5fa", "url": "https://github.com/Koeroesi86/node-webserver/blob/cbde33854dcf2da819264e6ced45262240e0e5fa/.github/prompts/open-pr.prompt.md", "key": "Koeroesi86/node-webserver/.github/prompts/open-pr.prompt.md" } } }

open-pr

About

Before opening

Which packages publish

PR body

Opening

Install open-pr and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews