Greg Brockman's tightening grip on OpenAI has me nervous about

OpenAI co-founder Greg Brockman remains the technical leader as product and research leadership churns, raising concerns among API developers about model behavior drift, deprecation timelines, and the future of the API as a product. The article highlights the departures of Mira Murati, Bob McGrew, Barret Zoph, and Ilya Sutskever, and the dissolution of the superalignment team, while Brockman's infrastructure background may not address developer experience needs.

Greg Brockman's tightening grip on OpenAI has me nervous about What actually changed The article lays out a pattern: Mira Murati, Bob McGrew, Barret Zoph, Ilya Sutskever obviously , and now apparently more departures expected before any IPO. Brockman stays. He's described as the "engineering workhorse" who pushed scaled systems from day one. That's the technical leader remaining while product and research leadership churns. For someone consuming the API, the question isn't board dynamics — it's whether the people who understand the serving stack, the model behavior quirks, and the deprecation policies are still in the room. The concrete concerns I'm tracking Model behavior drift. We've already seen silent changes in how 4o handles structured output formatting between minor versions. With research leadership turning over, who owns the "don't break existing prompts" mandate? Brockman's background is infrastructure, not model behavior. Deprecation timelines. The assistants API v1 to v2 migration was messy. If the product org keeps cycling, do deprecation windows shrink? Do we get less notice? Reasoning model access. The o1/o3 rollout has been... opaque. Access tiers, rate limits, pricing changes — all decided by a shrinking circle. Brockman's technical, but is he close enough to the reasoning model training dynamics to make good calls on API exposure? Safety/alignment defaults creeping into API responses. We've hit cases where the model refuses valid extraction tasks because of overzealous refusal triggers. With Sutskever gone and the superalignment team dissolved, who's tuning the refusal boundary for API consumers vs ChatGPT /en/tags/chatgpt/ users? What I'm doing about it Started abstracting our LLM calls behind a provider-agnostic interface last month. Not because I'm leaving OpenAI — their models still win on our benchmarks — but because the bus factor on institutional knowledge about the API feels high right now. Simplified version of what we're building toward class LLMProvider ABC : @abstractmethod async def complete self, messages: List Message , kwargs - Completion: pass @abstractmethod async def structured complete self, messages: List Message , schema: Type BaseModel , kwargs - BaseModel: pass class OpenAIProvider LLMProvider : def init self, model: str = "gpt-4o-2024-08-06" : self.client = AsyncOpenAI self.model = model Pin exact version, never "latest" async def complete self, messages, kwargs : Explicit version pinning, retry logic, structured logging return await self.client.chat.completions.create model=self.model, messages= m.dict for m in messages , kwargs Pinning exact model versions never "gpt-4o" or "latest" has already saved us once when a silent update changed JSON formatting behavior. The question I can't answer Brockman's an infrastructure builder. That's good for uptime, latency, scaling. But the API is a product — it needs someone owning developer experience, backward compatibility promises, and the feedback loop from builders hitting edge cases. If that product ownership keeps rotating while the infra lead stays, does the API become a second-class citizen to ChatGPT? The assistants API v2 felt like it was designed for OpenAI's own products first, developers second. Anyone else tracking this? Specifically: have you noticed changes in API behavior, support responsiveness, or deprecation communication over the last 6-12 months that correlate with the leadership turnover? I'm trying to separate signal from paranoia. Next Docling Loader validation error — format options keyword → /en/threads/7098/