docs: add Phoenix Grove (pgsgrove) model pricing entries

[Phoenix-Grove-Systems]

TLDR

Problem this solves:

• LiteLLM has no cost or context data for Phoenix Grove models
• Spend tracking shows $0 for anyone routing to api.pgsgrove.com

How it solves it:

• Adds 36 pgsgrove/<model> entries to the cost map (35 chat + 1 embedding)
• Per-token input/output/cache-read cost, context window, max output, capability flags
• Backup copy kept byte-identical; schema unchanged (no new fields)
• Registers the provider set (pgsgrove_models in litellm/__init__.py, populated in _populate_provider_model_sets, listed in _build_models_by_provider) as required by main's test_every_cost_map_provider_is_registered.

User Flow

Before: a developer pointing LiteLLM at Phoenix Grove sees every call logged at zero spend

1. They call litellm.completion(model="openai/glm-5.3-flash", api_base="https://api.pgsgrove.com/v1", api_key="pgsk_...")
2. The response arrives with real usage token counts
3. litellm.completion_cost(response) returns 0 and https://litellm-domain/ui/?page=logs shows the request at $0

After: the same call is priced from the cost map

1. They call litellm.completion(model="openai/glm-5.3-flash", api_base="https://api.pgsgrove.com/v1", api_key="pgsk_...") and pass custom_llm_provider="pgsgrove" (or look the model up as pgsgrove/glm-5.3-flash)
2. The response arrives with the same usage token counts
3. litellm.completion_cost(response) returns the per-token cost from the new entry and the logs page shows non-zero spend

Relevant issues

None. First contribution for this provider.

Pre-Submission checklist

• I have added meaningful tests — N/A for a cost-map data change; the map validates against model_prices_and_context_window.schema.json and ci_cd/cost_map_guard.py passes on the PR head (run locally: "cost map guard passed (human PR, file checks only)")
• The handful of test files covering my change pass locally — python ci_cd/generate_model_prices_schema.py --check reports the schema in sync and the map validating
• My PR passes all required CI/CD checks
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review

Screenshots / Proof of Fix

Before (dfab479)

1. python -c "import litellm; print(litellm.model_cost.get('pgsgrove/glm-5.3-flash'))" → None

After (730fd00)

1. python -c "import litellm; print(litellm.model_cost['pgsgrove/glm-5.3-flash']['input_cost_per_token'])" → 1e-07
2. python ci_cd/cost_map_guard.py --base HEAD~1 --head HEAD --head-ref docs/add-pgsgrove-pricing → cost map guard passed (human PR, file checks only)
3. cmp model_prices_and_context_window.json litellm/model_prices_and_context_window_backup.json → identical

Note on the Greptile "provider is not registered" finding: pgsgrove is a metadata-only provider slug, the same pattern as the existing gmi, llamagate, crusoe and sarvam entries in this file. Today users reach the endpoint with openai/<model> + api_base, and these entries give completion_cost / get_model_info the pricing. A native pgsgrove provider integration would be a separate, later PR.

[CLAassistant]

All committers have signed the CLA.

[greptile-apps]

Greptile Summary

Adds Phoenix Grove model metadata to LiteLLM’s primary and backup pricing catalogs.

• Registers 33 chat-model records, including priority-lane variants.
• Registers one embedding model.
• Adds pricing, token limits, caching rates, and capability flags.
• The catalog names a provider that is not registered for routing.

Confidence Score: 4/5

The PR is not safe to merge until pgsgrove is registered as a routable provider, because requests using every newly advertised model otherwise fail provider resolution.

The catalogs themselves remain synchronized and valid JSON, but their new entries reference a provider absent from both supported registration mechanisms, making the advertised models unusable through normal prefixed requests.

Files Needing Attention: model_prices_and_context_window.json, litellm/model_prices_and_context_window_backup.json

Important Files Changed

Filename	Overview
model_prices_and_context_window.json	Adds the Phoenix Grove catalog, but its provider identifier cannot be resolved by the current provider-routing infrastructure.
litellm/model_prices_and_context_window_backup.json	Mirrors the primary catalog additions, including the same unresolved Phoenix Grove provider identifier.

_{Reviews (1): Last reviewed commit: "docs: add Phoenix Grove (pgsgrove) model..." | Re-trigger Greptile}

[codspeed]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing Phoenix-Grove-Systems:docs/add-pgsgrove-pricing (5184bab) with main (49d0ece)}

[greptile-apps]

Provider Is Not Registered

The new catalog entries set litellm_provider to pgsgrove, but pgsgrove is absent from both the supported provider list and the JSON provider registry. When a user requests a newly advertised model such as pgsgrove/glm-5.2, provider resolution cannot recognize the prefix and raises BadRequestError instead of routing the request. Register the provider alongside these entries so the new models are usable. The backup catalog contains the same unresolved provider identifier.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Phoenix-Grove-Systems]

Thanks. On the "provider is not registered" point: that is intentional for this PR. pgsgrove here is a metadata-only provider slug, the same pattern as the existing gmi, llamagate, crusoe and sarvam entries in model_prices_and_context_window.json, none of which have a litellm_provider integration in the routing code either. Users reach the endpoint today with openai/<model> + api_base=https://api.pgsgrove.com/v1, and these entries give completion_cost / get_model_info the per-token pricing and context data. A native pgsgrove provider (routing + LlmProviders enum) would be a separate PR; this one is scoped to the cost map only, per the one-problem-per-PR rule.

[Phoenix-Grove-Systems]

Gentle bump for a code-owner look when convenient. The branch was rebuilt on current main (no conflicts), entries refreshed to the current catalog (36 models), and the provider set is now registered in __init__.py per main's new test_every_cost_map_provider_is_registered requirement, so Greptile's registration point is addressed in code as well as in the thread. All checks green. Scope remains the cost map plus the three registration lines that test requires.