Set root identities and expand bundled profile plan
This commit is contained in:
@@ -4,7 +4,7 @@
|
|||||||
|
|
||||||
Proposed; no implementation changes yet.
|
Proposed; no implementation changes yet.
|
||||||
|
|
||||||
Ship a small OpenRouter configuration collection with PromptKit so consumers
|
Ship a small OpenRouter configuration bundle with PromptKit so consumers
|
||||||
can begin using named profiles without installing a separate catalog. Include
|
can begin using named profiles without installing a separate catalog. Include
|
||||||
the backend definition those profiles require. Keep separately maintained
|
the backend definition those profiles require. Keep separately maintained
|
||||||
operator collections fully supported through the existing configuration path.
|
operator collections fully supported through the existing configuration path.
|
||||||
@@ -36,7 +36,7 @@ that release; no further upstream enhancement is required for this feature.
|
|||||||
|
|
||||||
### Ordinary Embedded Configuration
|
### Ordinary Embedded Configuration
|
||||||
|
|
||||||
Embed a small YAML collection in PromptKit and load it through the existing
|
Embed a small YAML bundle in PromptKit and load it through the existing
|
||||||
ConfigKit adapter. Place it in its own lowest-priority underlay, before every
|
ConfigKit adapter. Place it in its own lowest-priority underlay, before every
|
||||||
caller underlay and the main input. Preserve the existing order and grouping
|
caller underlay and the main input. Preserve the existing order and grouping
|
||||||
of caller inputs.
|
of caller inputs.
|
||||||
@@ -56,9 +56,23 @@ listing and inspection APIs. Source explanations should identify embedded
|
|||||||
configuration meaningfully. There is no need for a parallel built-in catalog
|
configuration meaningfully. There is no need for a parallel built-in catalog
|
||||||
API or special provenance model.
|
API or special provenance model.
|
||||||
|
|
||||||
|
### Root Resource Layout
|
||||||
|
|
||||||
|
Use root entries for both the backend and all built-in profiles. The backend
|
||||||
|
ID is `openrouter`; each bundled profile references `backend: openrouter` and
|
||||||
|
is selected using its unqualified ID. No built-in `openrouter` collection is
|
||||||
|
created, so an externally supplied collection can expose names such as
|
||||||
|
`openrouter/gpt-sol-latest` alongside the root `gpt-sol-latest` profile.
|
||||||
|
|
||||||
|
Built-ins at the root and external libraries under `collections` is a
|
||||||
|
convention, not an enforced distinction. Applications may supply root entries,
|
||||||
|
override built-ins, and organize external configuration using either form.
|
||||||
|
Root names favor convenient selection; their backend remains explicit in the
|
||||||
|
definition and inspection even though it is absent from the profile ID.
|
||||||
|
|
||||||
### OpenRouter Backend
|
### OpenRouter Backend
|
||||||
|
|
||||||
Include a backend with OpenRouter's API base endpoint,
|
Include the root `openrouter` backend with OpenRouter's API base endpoint,
|
||||||
`https://openrouter.ai/api/v1`, and the conventional environment-variable name
|
`https://openrouter.ai/api/v1`, and the conventional environment-variable name
|
||||||
`OPENROUTER_API_KEY`. Store the name only; no credential value belongs in the
|
`OPENROUTER_API_KEY`. Store the name only; no credential value belongs in the
|
||||||
bundle. Reuse the existing OpenAI-compatible client and credential resolution.
|
bundle. Reuse the existing OpenAI-compatible client and credential resolution.
|
||||||
@@ -70,18 +84,29 @@ diagnostics or select an inference smoke-test profile.
|
|||||||
|
|
||||||
### Small Profile Set
|
### Small Profile Set
|
||||||
|
|
||||||
The proposed initial set contains these three model selections:
|
The initial set contains twelve root profiles:
|
||||||
|
|
||||||
| Proposed profile ID | OpenRouter model value | Purpose |
|
| Profile ID | Intended model selection |
|
||||||
| --- | --- | --- |
|
| --- | --- |
|
||||||
| `openrouter/gpt-sol-latest` | `~openai/gpt-sol-latest` | Follow the current GPT Sol family model. |
|
| `gpt-astra-latest` | OpenAI GPT Astra latest-family alias through OpenRouter. |
|
||||||
| `openrouter/auto` | `openrouter/auto` | Delegate model selection to OpenRouter's auto router. |
|
| `gpt-sol-latest` | OpenAI GPT Sol latest-family alias (`~openai/gpt-sol-latest`). |
|
||||||
| `openrouter/free` | `openrouter/free` | Select OpenRouter's free-model router. |
|
| `gpt-terra-latest` | OpenAI GPT Terra latest-family alias through OpenRouter. |
|
||||||
|
| `gpt-luna-latest` | OpenAI GPT Luna latest-family alias through OpenRouter. |
|
||||||
|
| `claude-fable-latest` | Anthropic Claude Fable latest-family alias through OpenRouter. |
|
||||||
|
| `claude-opus-latest` | Anthropic Claude Opus latest-family alias through OpenRouter. |
|
||||||
|
| `claude-sonnet-latest` | Anthropic Claude Sonnet latest-family alias through OpenRouter. |
|
||||||
|
| `claude-haiku-latest` | Anthropic Claude Haiku latest-family alias through OpenRouter. |
|
||||||
|
| `gemini-pro-latest` | Google Gemini Pro latest-family alias through OpenRouter. |
|
||||||
|
| `gemini-flash-latest` | Google Gemini Flash latest-family alias through OpenRouter. |
|
||||||
|
| `auto` | OpenRouter auto router (`openrouter/auto`). |
|
||||||
|
| `free` | OpenRouter free-model router (`openrouter/free`). |
|
||||||
|
|
||||||
These names distinguish PromptKit resource IDs from provider model values:
|
These profile IDs are selected. Confirm the exact provider `model` slugs for
|
||||||
the tilde and slash in a provider model slug remain part of that value.
|
all family aliases during implementation rather than deriving them mechanically
|
||||||
Additional latest-family aliases can be selected before implementation or added
|
from profile IDs. If a requested alias is unavailable, surface that mismatch
|
||||||
later when useful; completeness across vendors is not a launch requirement.
|
instead of silently substituting a pinned model or dropping the profile.
|
||||||
|
The tilde and slash in a provider model slug remain part of that value; they
|
||||||
|
do not change the root placement of the PromptKit profile.
|
||||||
|
|
||||||
Each profile should primarily specify its backend and model. Avoid baking in
|
Each profile should primarily specify its backend and model. Avoid baking in
|
||||||
temperature, reasoning, token-budget, timeout, or capability assumptions merely
|
temperature, reasoning, token-budget, timeout, or capability assumptions merely
|
||||||
@@ -121,8 +146,8 @@ does not identify or pin the concrete model selected upstream.
|
|||||||
|
|
||||||
## Implementation Work
|
## Implementation Work
|
||||||
|
|
||||||
1. Resolve the identity layout and diagnostic-metadata decisions below. Confirm
|
1. Resolve the diagnostic-metadata decision below. Verify the provider endpoint
|
||||||
the initial profile list and current provider endpoint/model values.
|
and exact model values for the twelve selected root profiles.
|
||||||
2. Add the embedded YAML backend and profiles, and integrate their dedicated
|
2. Add the embedded YAML backend and profiles, and integrate their dedicated
|
||||||
underlay with engine construction. Add the disable option using the existing
|
underlay with engine construction. Add the disable option using the existing
|
||||||
facade option pattern. Apply the ordinary load/normalize/validate lifecycle.
|
facade option pattern. Apply the ordinary load/normalize/validate lifecycle.
|
||||||
@@ -147,31 +172,29 @@ needed solely to distribute this data.
|
|||||||
|
|
||||||
## Open Decisions
|
## Open Decisions
|
||||||
|
|
||||||
### 1. Backend Identity And Collection Layout
|
### Smoke-Test Metadata In The Bundled Backend
|
||||||
|
|
||||||
**Recommendation:** Put profiles in the `openrouter` collection with the local
|
**Recommendation:** Include `smoke_tests.authentication.kind: openrouter_key`
|
||||||
IDs shown above, and put the backend in that collection as local ID `default`.
|
using the existing adapter's backend-relative `/key` endpoint. Leave a separate
|
||||||
Profiles would reference `openrouter/default`. This keeps the bundle together,
|
reachability endpoint and inference `default_profile` unspecified. The adapter
|
||||||
avoids an ambiguous doubled provider name, and supports normal collection
|
already exists, so this is a small configuration addition that makes explicit
|
||||||
inspection. Applications can still replace those exact IDs.
|
API-key diagnostics useful out of the box without choosing an inference model.
|
||||||
|
OpenRouter documents the authenticated
|
||||||
|
[current-key endpoint](https://openrouter.ai/docs/api/api-reference/api-keys/get-current-api-key).
|
||||||
|
Its acceptance of a key is evidence about that endpoint, not a guarantee that
|
||||||
|
an arbitrary inference request will succeed.
|
||||||
|
|
||||||
**Alternative:** Use a root backend ID `openrouter` with namespaced profiles.
|
This revises the initial recommendation to omit diagnostic metadata: given the
|
||||||
This is concise and may align better with existing operator catalogs. Its
|
existing adapter and the bundle's convenience purpose, the added utility seems
|
||||||
drawback is splitting the bundle between root and collection resources, and
|
worth maintaining the small declaration. The decision remains open pending
|
||||||
making a common root backend name the shared override target. Before choosing,
|
maintainer agreement.
|
||||||
compare maintained OpenRouter catalog conventions; the layout should minimize
|
|
||||||
consumer confusion rather than establish a new naming restriction.
|
|
||||||
|
|
||||||
### 2. Smoke-Test Metadata In The Bundled Backend
|
**Alternative:** Include only the backend endpoint and credential-variable name.
|
||||||
|
This keeps the shipped configuration smaller and leaves diagnostic declarations
|
||||||
|
entirely with the consumer, but applications wanting authentication diagnostics
|
||||||
|
must configure the existing adapter themselves. Ordinary inference is unaffected.
|
||||||
|
|
||||||
**Recommendation:** Include only the endpoint and credential-variable name in
|
Either approach uses existing diagnostic APIs and execution rules. Neither
|
||||||
the initial backend. Existing diagnostic behavior remains available, and the
|
implies automatic diagnostics during construction or execution. Selecting a
|
||||||
feature stays focused on configuration convenience without choosing a diagnostic
|
built-in inference smoke-test default would be a separate choice; this proposal
|
||||||
inference model or expanding the maintained provider-specific configuration.
|
leaves callers able to select a profile explicitly without prescribing one.
|
||||||
|
|
||||||
**Alternative:** Also provide the existing OpenRouter authentication diagnostic
|
|
||||||
configuration, after verifying its endpoint and behavior, while leaving the
|
|
||||||
inference smoke-test profile unselected. This makes the bundle more useful for
|
|
||||||
explicit preflight calls with little data, but adds another upstream convention
|
|
||||||
to maintain and test. Neither option implies automatic diagnostics during
|
|
||||||
construction or execution.
|
|
||||||
|
|||||||
Reference in New Issue
Block a user