I’m building production tooling on top of the OpenAI API that needs to make safe, automated decisions about model selection, cost control, and request validation. While doing this work, I’ve repeatedly run into a limitation that’s hard to work around cleanly: model pricing and context or output limits are not available in a machine-readable form via the API itself.
At the moment, these values appear only in human-readable documentation and pricing pages which are actively blocked from programmatic parsing. That makes it difficult for tools to perform basic preflight checks, such as determining whether a request will exceed a model’s context or maximum output size, or whether a job will violate a budget constraint before it runs. It also makes automatic model selection based on cost versus capacity unnecessarily fragile. Ironically, pricing and limits often change more frequently than model deployment metadata, which makes them even more important to expose authoritatively to API consumers rather than less.
In practice, the lack of machine-readable pricing and limits forces developers into brittle workarounds. The usual options are to hard-code pricing tables and token limits, attempt to scrape documentation pages that may block automation or change structure without notice, or discover limits only after requests fail or costs are incurred. None of these approaches are especially robust in a production environment.
In my own case, I’m building automated evaluation and test harnesses that need to refuse to run when inputs exceed safe context bounds, estimate or cap cost before execution, and reason about failures deterministically. Without authoritative metadata, this kind of logic becomes guesswork.
Even a best-effort, versioned metadata payload exposed via the API would be enormously helpful. Fields such as maximum context tokens, maximum output tokens, current input and output pricing, and an effective-at timestamp would allow tools to behave much more safely. This wouldn’t need to be a contractual guarantee across all accounts, especially where enterprise or contract-specific pricing applies, but it would provide the best available truth for the current API consumer at the time of a request.
This request isn’t about convenience so much as safety, correctness, and automation. Pricing and limits are part of the operational contract of an API, and exposing them in a machine-readable way would significantly improve the reliability of production systems built on top of it. I’d be happy to provide concrete examples if that would be useful.