Code Walk F · landscapelandscape · serving + agents

The model-API landscape
four providers, one shape

The request-lifecycle walk took apart one provider. Widen the lens: Claude, OpenAI, Gemini, and xAI expose the same core — a single endpoint, tool-calling, a prefix cache — and differ on the things that actually cost you: who holds the conversation state, who runs the tools, who bills per call. And above all of them sits a harness like Cursor, which is not a model at all. Two interactive maps: where the four split, and how every proprietary piece is reproduced in open source.

the fourClaude · OpenAI · Gemini · xAI
convergenceone endpoint + tools + prefix cache
the splitwho holds state, who bills per-call
the harnessCursor ≠ a model provider

00 Same core, different edges

In the request-lifecycle walk we took one provider apart: a stateless endpoint, a content-addressed prefix cache, a tool loop that runs on your machine. The natural next question is whether the others work the same way. Mostly — yes. All four frontier APIs have converged on one shape: a single chat/generate endpoint, function / tool calling,structured output, and a prefix cache that makes re-sending context cheap.

What they don’t share is the stuff that quietly changes your architecture and your bill: whether the server keeps your conversation for you or you resend it every turn; whether a search or a code-run happens on their side or yours; and how server-hosted tools are priced. Click a provider to focus its column, or click any row to see what the axis means and its open-source equivalent:

The four frontier APIs across the axes that actually differ. Green cells are the friendly default; amber flags a place it’ll surprise you. Click a provider header to focus its column; click a row for the explainer and the open-source project that reproduces it.

axis	Claude	OpenAI	Gemini	xAI · Grok

Read the columns and the pattern falls out. Claude is the purist stateless design — you always hold the transcript, caching is an explicit cache_control breakpoint. OpenAI’s Responses API lets you flip store:true and continue with previous_response_id, moving state to the server. Gemini offers context caching plus its own interaction-id continuation. xAI · Grokis OpenAI-shaped, and prices its server tools (Live Search) per call rather than folding them into tokens — a genuinely different cost model.

01 The common shape

Strip away the branding and every one of these APIs is the same object. You POST a list of messagesplus a set of tool definitions; you get back either text or a request to call a tool; you run the tool (or the server does) and post the result back. State is either your job (resend) or theirs (an id). Caching sits underneath, invisible, making the resend cheap.

            ┌──────────────────────── your client / harness ────────────────────────┐
            │   messages[]  +  tools[]  +  model:"…"   (you keep the transcript)      │
            └───────────────────────────────────┬─────────────────────────────────────┘
                                                 │  POST  (whole context, every turn)
                                                 ▼
   ┌───────────────────────────────────────────────────────────────────────────────────┐
   │  ONE ENDPOINT   /v1/messages · /v1/responses · :generateContent · /chat/completions │
   │  ┌───────────────┐   ┌───────────────┐   ┌───────────────┐   ┌───────────────────┐  │
   │  │ prefix cache  │──▶│  the model    │──▶│ tool-call req │──▶│ structured output │  │
   │  │ (skip recompute)   (forward pass)     (function call)      (JSON / grammar)   │  │
   │  └───────────────┘   └───────────────┘   └──────┬────────┘   └───────────────────┘  │
   └────────────────────────────────────────────────┼──────────────────────────────────┘
                                                     │  "call search(...)" / "call grep(...)"
                          ┌──────────────────────────┴───────────────────────────┐
                          ▼                                                       ▼
                 SERVER-SIDE tool                                        CLIENT-SIDE tool
        (Live Search, code-exec, managed agent)                (your grep / your DB / your API)
             billed per-call or per-token                        runs on your machine, free
                          └───────────────────────────┬──────────────────────────┘
                                                       │  result posted back as the next message
                                                       ▼
                                        loop until the model stops asking

The one axis that’s genuinely moving is state. The original design (Claude, classic completions) is stateless: the client is the source of truth and resends everything. The newer tier (OpenAI Responses withstore, Gemini interactions, and every provider’s managed-agent product) lets the server hold the session, run the loop, and host the sandbox. Same core; the boundary of “who remembers” is sliding from client to server — and that’s the thing to watch, because it changes where the GPU work lives.

02 Cursor is a harness, not a model

the category error to avoidIt’s easy to file “Cursor” next to “Claude” and “OpenAI.” It doesn’t belong there. Cursor is aharness — an editor, an Agent, Background Agents, and a CLI — that drives the four APIs above. It holds the transcript, decides which model field to send, runs your edits and terminal commands as client-side tools, and streams results back. Swap the model string and the same harness now speaks to a different provider. Claude Code, Aider, and OpenHands occupy the exact same role.

This is why the distinction matters for the map: a harness adds no new model capability — it’s orchestration around the common shape. Everything Cursor does to your repo is the client-side tool loop from the previous walk, wrapped in a nice UI. Which means it’s all reproducible in the open, and it is — the second map shows exactly which project fills each slot.

03 The whole thing, in open source

None of this requires a frontier lab. Every proprietary piece — the serving endpoint, the prefix cache, structured output, the agent harness, the sandbox, server-side search, the vector store, the reasoning tier — has a mature open-source equivalent you can host. Pick a capability to see the real projects that fill it; each chip links to its repository:

The proprietary API stack, rebuilt from open source. Pick a capability on the left; every project on the right is a real, hostable repo. This is the “build Claude / Cursor / Grok from open models and tools” claim, itemized.

Put together, this is a self-hosted rebuild of the whole landscape: vLLM or SGLang as the endpoint (with RadixAttention giving you the prefix cache for free), Outlines / XGrammarfor structured output, OpenHands / Aider as the harness, E2B for the sandbox,SearxNG for server-side search, pgvector / Qdrant for retrieval, andDeepSeek-R1 for the reasoning tier — all wired together with LiteLLM so the calling code never has to know which one it’s talking to. The convergence the first map showed is exactly what makes this swap possible.

04 Why an observability company cares

the plasmient thread

Four providers, one harness category, a full open-source mirror — and every single one of them runs on GPUs. Whether it’s Anthropic’s stateless endpoint, OpenAI’s stored session, or your own vLLM box, the box that actually answers is a rack of accelerators doing forward passes. The prefix cache that all four converged on is, physically, the GPUs choosing not to recompute attention over a prefix — the exact gap this company measures.

And the observability gap is provider-agnostic. `nvidia-smi` reads ~100% on a cache-heavy serving node and on a cold one alike; it can’t tell you which fraction of that silicon-time was fresh, useful work. That’s true for Anthropic, for xAI, and for the open stack you host yourself. TheFrontier Stack is the layers; this page is the industry’s serving edge; Plasmient is the instrument that reads the truth across all of it. See it at the operation where the gap is widest — the attention deep-dive.

↗ Full references — go to the source

Primary provider docs first, then the open-source projects that reproduce each capability — this page is deliberately open-source-heavy. Read the four API references side by side and the convergence is obvious.