How should Starveri's OpenAI-compatible gateway models be represented?

Hi models.dev maintainers,

I would like to add Starveri API as an independent OpenAI-compatible provider. Before opening a PR, I wanted to confirm the right representation because a couple of details need maintainer guidance.

Starveri public source links:

• Buyer / pricing page: https://api.starveri.net/credits
• Public model metadata: https://api.starveri.net/models
• Docs: https://api.starveri.net/docs
• OpenAPI: https://api.starveri.net/openapi.yaml
• LLM discovery: https://api.starveri.net/llms.txt

Proposed provider metadata:

name = Starveri
env = [STARVERI_API_KEY]
npm = @ai-sdk/openai-compatible
api = https://api.starveri.net/v1
doc = https://api.starveri.net/models

Public model IDs:

• gpt-5.1-codex
• gpt-5.3-codex-spark
• gpt-5.3-codex
• gpt-5.4
• gpt-5.4-mini
• gpt-5.5

For models that already have model-only metadata, I can use base_model and override Starveri-specific pricing where appropriate.

Questions:

1. Starveri's public model metadata says context windows are subject to Codex context-window limits. Should provider TOMLs inherit base model limits, override them, or wait until exact Starveri-specific limits are published?
2. Should gpt-5.3-codex-spark be listed as a provider-specific model, mapped to gpt-5.3-codex metadata, or omitted until model-only metadata exists?
3. Should Starveri's web-search and code-interpreter unit prices be left out of models.dev, since they are tool/unit charges rather than model token prices?

Starveri is independent and not affiliated with OpenAI. I can prepare a source-backed PR once the preferred representation is clear.

Start by reviewing Starveri's public model metadata, OpenAPI specification, and documentation, then compare them with existing provider representations in models.dev. The issue is complete when maintainers decide how to represent inherited limits, gpt-5.3-codex-spark, and tool pricing, enabling a source-backed provider PR.