[Feature Request] Add The Grid as a dedicated model platform

Description

As a CAMEL user, I want to select The Grid's instruments through a dedicated ModelPlatformType, so that context windows are correct and the available instruments are discoverable.

Disclosure: I work on The Grid. I'm also aware of #3282, where a very similar request was declined — I've tried to address that objection head-on below rather than talk around it.

What The Grid is

The Grid is a spot market for inference. An id names a market instrument — a task type (text, code, agent) paired with a quality tier (standard, prime, max), plus lab-scoped markets like claude-opus-latest — rather than a fixed model. Each request is filled by whichever supplier is competitive at the time, so the model reported in a response differs from the instrument requested: asking for text-standard can return openai/gpt-oss-120b.

Why not just OpenAICompatibleModel

This is the question you asked the n1n.ai requester in #3282:

After reviewing the documentation, I see that your platform is compatible with the OpenAI client API. Given this, our preference is to use our existing OpenAICompatibleModel class rather than adding a dedicated integration for CAMEL at this time.

That is a fair default, and for a provider whose ids are ordinary model names I'd agree. The Grid is the case where it breaks, for one concrete reason: UnifiedModelType.token_limit returns 999_999_999.

From camel/types/unified_model_type.py:

@property
def token_limit(self) -> int:
    r"""Returns the context window size for the model.

    For unknown model types not defined in ModelType enum, this returns
    a default value of 999_999_999 tokens.
    """
    self._warn_unknown_token_limit_once(str(self))
    return 999_999_999

ChatAgent uses token_limit to decide when to truncate memory. Through the generic path every Grid instrument reports a billion-token context, so memory truncation never fires and long conversations run until the upstream rejects them. text-standard actually has a 128k window; agent-prime has 196,608.

The second problem is discoverability. text-standard and agent-max are not guessable, and CAMEL has no /v1/models listing, so through OPENAI_COMPATIBLE_MODEL a user has no way to find out which instruments exist. Named ModelType members give autocomplete.

This is the same argument #4047 / #4048 made for OrcaRouter, which merged on 2026-05-14 — with the difference that Grid's ids aren't even namespaced model names, they're tier labels.

What I'd register

Real context windows and output ceilings, read from GET /v1/models (public, no key needed):

Note the values are the contract — they don't drift with the market the way prices do.

Scope

Modelled on #4048: camel/models/thegrid_model.py (a thin OpenAICompatibleModel subclass), camel/configs/thegrid_config.py, ModelType.THEGRID_* members with real token_limit entries, ModelPlatformType.THEGRID, the factory map, is_thegrid properties, the env_key_urls entry, docs table rows, an example and a unit test.

Two things I would not claim:

• /v1/completions and /v1/embeddings both return 404 on The Grid. OpenAICompatibleModel never calls either, so this costs nothing, but the integration won't advertise them.
• The Grid serves /v1/responses natively, and OpenAICompatibleModel already supports api_mode="responses", so that comes along for free rather than needing new code.

I also have an open PR adding The Grid to LiteLLM (BerriAI/litellm#39907); once that lands, ModelPlatformType.LITELLM would reach The Grid too. I'm raising this separately because the LiteLLM route has the same context-window problem — it wouldn't give CAMEL the token limits either.

Before I write any code

I have the implementation ready to follow the #4048 shape, with live API transcripts for the human-testing requirement in CONTRIBUTING. But per CONTRIBUTING I'm not opening a PR until a maintainer says the approach is welcome — happy to be told the 999_999_999 issue should be solved a different way, or that this still isn't worth a dedicated platform.