Hi,
We’re building tools where users bring their own API key and select models by name at runtime.
Before making a responses or chat.completions call, we need to know what a model is and how it can be used.
Today, there is no programmatic way to retrieve this information.
We’re requesting a Model Descriptor (Introspection) API, where providing only a model name returns a machine-readable contract describing that model.
Required fields (blocking issue for BYO-key tools)
{
"limits": {
"max_context_tokens": 400000,
"max_input_tokens": 400000,
"max_output_tokens": 128000,
"default_output_tokens": 4096
}
}
Knowing max_output_tokens is not optional for BYO-key tools.
Correct chunking must be done before the request; relying on failed calls or parsing error messages is brittle and costly.
Parameter contract
"parameters": {
"temperature": { "min": 0.0, "max": 2.0, "default": 1.0 },
"top_p": { "min": 0.0, "max": 1.0, "default": 1.0 }
}
This allows clients to automatically adapt when new parameters or ranges are introduced.
Capabilities
"capabilities": {
"reasoning": true,
"tools": true,
"json_schema": true,
"vision": false
}
Pricing metadata (optional but extremely useful)
"pricing": {
"input_tokens_per_usd": 1000000,
"output_tokens_per_usd": 250000
}
Optional metadata
-
description
-
release notes / what’s new
-
deprecated parameters
Why this matters
-
Static model → limit maps are fragile.
-
Parsing error messages to infer limits is unreliable.
-
“Use dated checkpoints” does not work for BYO-key tools where users control the model string.
-
Gemini already expose token limits via API.
This is not a documentation request; it’s a missing platform primitive.
Is a model descriptor / introspection endpoint on the roadmap?
Thanks.