#6499·ogx

Add The Grid as a remote inference provider

Author: CastilloLuisCreated Sep 5, 2026Updated Sep 5, 2026

CONTRIBUTING asks for a discussion issue before adding a new in-tree provider, so here it is. I have the implementation ready and will link the PR below.

Disclosure: I work on The Grid. Flagging that up front since I'm proposing my own employer's provider.

What it is

The Grid is a spot market for inference. Instead of a vendor rate card, callers select a market instrument — a task type and a quality tier (text-standard, code-prime, agent-max), or a lab-scoped market (claude-opus-latest, gemini-pro-latest) — and the request is filled by whichever supplier is competitive at the time. There are 17 instruments live today.

One consequence worth stating early, because it looks like a bug otherwise: the model field of a response names the model that actually served the request, not the instrument requested. Asking for text-standard can come back as openai/gpt-oss-120b.

Why it fits without special-casing

/v1/chat/completions is OpenAI-compatible and /v1/models is served, so OpenAIMixin handles the adapter as-is and instruments are discovered rather than hardcoded. The adapter is ~35 lines of real code on top of the mixin, shaped after remote::deepseek.

I checked the capability surface against the live API rather than assuming it, and the adapter exposes only what's actually there:

Surface Result Adapter
/v1/chat/completions works, incl. streaming and tool calls inherited from OpenAIMixin
/v1/models works inherited — instruments auto-discovered
response_format: json_schema works — returned valid structured output left enabled (unlike deepseek)
/v1/completions 404 NotImplementedError
/v1/embeddings 404 NotImplementedError
n > 1 accepted but only one choice returned added to the integration-test skip list

One caveat about the Responses API

The Grid serves /v1/responses natively. I understand OGX implements Responses server-side on top of chat completions, so this provider does not wire that up — I'm noting it so nobody reads the PR as claiming otherwise.

Live test run

uv run --group test pytest --inference-mode live --stack-config inference=remote::thegrid --text-model thegrid/text-standard tests/integration/inference gives 18 passed, 2 failed, 73 skipped.

Both failures are in test_inference_store_disabled.py, which boots its own in-process stack pinned to OpenAI with OPENAI_API_KEY="fake-key-for-replay". In --inference-mode live that placeholder reaches the real OpenAI API and 401s. The same two tests pass under --inference-mode replay (6 passed). So it's a live-mode harness artifact that would hit any provider, not something this adapter causes — but I'd rather flag it than quietly trim it out of the numbers.

Ask

Two things: that this is a welcome addition in-tree, and — if so — whether a maintainer can add a THEGRID_API_KEY CI secret, or trigger the recording workflow, so the integration tests run rather than skip. Happy to adjust the shape of any of this before or during review.