Why OpenAI and Claude shouldn't be allowed to IPO.

I have been trying to make sense of where generative AI is actually useful for me as a developer, and where the hype starts to become dangerous.

My current direction is fairly clear: I have already mandated moving away from cloud AI in my own products, including enterprise-hosted options like Azure-backed deployments. We have had success deploying local, competent, lean “call the right tool” LLM workflows for language-based automation directly in the browser, without external dependencies.

The next step, if things continue in this direction, is to fully cut the cord for all products by 2027.

These notes are based on my own experience and on a PDF I read titled Why OpenAI and Anthropic Should Not Be Allowed to IPO. The document is strongly worded, and I do not want to treat every claim as settled fact. But it does capture a set of concerns I have been feeling more and more as a developer: technical reliability, financial sustainability, and platform risk.

The developer problem: stochastic systems are not normal software

The most important point for me is technical, not financial.

Large language models are very useful. I use them. I build with them. They can summarize, classify, rewrite, draft, translate, and help automate language-heavy workflows.

But they are not deterministic software systems.

The PDF describes transformer models as statistical token predictors, roughly estimating:

P(wt | w1, w2, ..., wt-1) = softmax(W · ht)

That is a simplified way of saying: the model predicts the next likely token based on context. This is powerful, but it is not the same thing as verified reasoning, formal state management, or guaranteed correctness.

For production software, that difference matters.

The “party trick” ceiling

The report calls out what it sees as a “party trick” ceiling. I think that phrase is a bit harsh, but I understand the point.

LLMs are excellent at:

• generating conversational text
• drafting code snippets
• summarizing documents
• extracting structure from messy language
• helping with rapid prototypes
• acting as flexible interfaces around tools

But when we ask them to become autonomous software agents that reliably complete multi-step business processes, the failure modes compound quickly.

A model that is “mostly right” on one step can become unreliable across a workflow with many steps. If each step has a small chance of drifting, hallucinating, or misunderstanding state, the total system needs guardrails everywhere.

That usually means adding:

• rule-based wrappers
• tool permission layers
• retries
• validators
• logging
• human review paths
• deterministic fallbacks

At that point, the LLM is not the architecture. It is one component inside a larger deterministic system.

That is the lesson I keep coming back to.

Scaling does not solve everything

The report argues that the original scaling-law story has started to run into diminishing returns. The basic claim is that early jumps in model size created obvious qualitative improvements, but later increases require much more compute for smaller visible gains.

The notes mention several bottlenecks:

• Compute cost escalation — training and inference require huge amounts of FLOPS, memory bandwidth, and energy.
• Data limits — high-quality human-generated training data is not infinite.
• Synthetic data risks — training too much on AI-generated data can create degradation or feedback loops.
• Context window pressure — longer context windows increase KV-cache memory usage and can slow throughput, while not fully solving hallucination or state-tracking problems.

This matches my own hesitation about relying on “the next model will fix it” as a product strategy.

Maybe the next model will be better. But I do not want my core architecture to depend on a future breakthrough that may or may not arrive, may or may not be affordable, and may or may not remain accessible through the same API terms.

Benchmarks are not production reliability

Another part of the PDF focuses on benchmark gaming. It mentions public benchmarks like MMLU, HumanEval, GSM8K, and SWE-bench, arguing that they increasingly function as PR metrics rather than reliable indicators of production behavior.

The concerns listed include:

• test-set contamination from web-scale training data
• fine-tuning or prompting specifically for benchmark formats
• models performing well on standardized tests but failing on edge cases
• benchmark gains that do not eliminate hallucination or logical drift

As a developer, I care less about whether a model scores a few points higher on a benchmark and more about questions like:

• Does it behave consistently on my actual inputs?
• Can it explain uncertainty?
• Can I constrain it safely?
• Can I reproduce results?
• What happens when the user gives malformed or hostile input?
• What does failure look like?

A benchmark can be a useful signal. But it is not a substitute for system-level reliability testing.

The financial side: if the unit economics are bad, the platform risk is real

The PDF also makes a financial argument: that frontier AI labs may be structurally unprofitable because their revenue depends on services that are extremely expensive to run.

Some of the figures cited in the report are severe:

• OpenAI allegedly had an adjusted operating margin of -122% in Q1 2026.
• The report claims OpenAI spent $2.22 for every $1.00 of revenue.
• It claims nearly $7 billion in operating losses in a single quarter.
• It describes large compute commitments through 2030.
• It argues consumer subscription pricing may be heavily subsidized compared to actual inference costs.

I am not independently verifying those numbers here. They come from the referenced PDF. But even if the exact numbers change, the broader concern is still important: if a platform is only usable because someone else is subsidizing the true cost, that is a risk for developers.

At some point, one or more of these things can happen:

• prices go up
• rate limits tighten
• models are deprecated
• terms change
• enterprise usage becomes more restricted
• latency or availability becomes worse
• vendors push customers into higher-margin plans

For a hobby project, maybe that is acceptable.

For product architecture, I am much less comfortable with it.

Cloud circularity and dependency risk

The report also describes what it calls a circular relationship between hyperscalers and AI labs.

The simplified version is:

1. A major cloud provider invests in or partners with an AI company.
2. The AI company uses large amounts of that money or credit to buy cloud compute.
3. The cloud provider recognizes growth from AI infrastructure demand.
4. The cycle reinforces the market narrative.

The PDF contrasts this with traditional cloud infrastructure, which had broader general-purpose uses. AI GPU infrastructure, according to the report, may have shorter hardware cycles, higher power requirements, and more specialized use cases.

For me, the developer takeaway is simpler: when my application depends on a remote frontier model, I am not just depending on an API. I am depending on a huge capital structure, a cloud supply chain, GPU availability, vendor incentives, and future pricing decisions.

That is a lot of hidden dependency.

Why I like local, lean models more now

This is where my own work has been moving.

I am not trying to replace every cloud model with a giant local one. That misses the point.

The better pattern, at least for my use cases, is to use smaller local models for narrow language tasks and pair them with deterministic tooling.

A local model does not need to be magical if the job is well-scoped.

Examples of tasks that can often work well locally:

• classify a short piece of text
• normalize user input
• extract intent
• choose from a small set of tools
• rewrite a phrase
• summarize a small document
• generate UI copy drafts
• assist with search or filtering

The key is that the model should not be trusted blindly. It should call the right deterministic tool, or return structured output that can be validated.

That gives me a better balance:

• lower dependency risk
• better privacy posture
• predictable cost
• offline or browser-local capability
• less vendor lock-in
• easier product planning

It also forces better engineering discipline. Instead of asking the model to “do everything,” I have to define the actual workflow.

My current architectural bias

Right now, my bias is:

1. Use deterministic software wherever possible.
2. Use LLMs for language-shaped uncertainty, not core correctness.
3. Prefer local models when the task is narrow enough.
4. Validate outputs aggressively.
5. Avoid building product survival around a single cloud AI vendor.
6. Treat frontier APIs as optional accelerators, not foundations.

This does not mean cloud AI has no place. There are still cases where a frontier model is useful, especially for complex reasoning, broad coding assistance, or open-ended analysis.

But for product infrastructure, I want the default path to be local, inspectable, and replaceable.

The IPO concern

The PDF’s central argument is that OpenAI and Anthropic should not be allowed to IPO because public investors could become exit liquidity for companies with unresolved technical and financial risks.

The report raises concerns about:

• deeply negative operating margins
• massive compute liabilities
• subsidized consumer usage
• uncertain enterprise ROI
• circular cloud financing
• index-fund exposure if valuations are extremely high
• employee and insider secondary share sales
• governance complexity around public benefit corporation structures

I am not a securities regulator, and I am not making an investment recommendation here.

But I do think developers should care about this. If the AI platforms we build on are financially unstable, structurally subsidized, or dependent on continuous capital raises, then that instability eventually reaches our products.

Technical architecture and financial architecture are connected.

Closing thought

My main lesson from this research is not “AI is useless.” That would be lazy and false.

My lesson is that AI is useful when placed correctly.

For me, the safer direction is smaller, local, constrained models that help deterministic software do language-related work. I do not want to build products where the core promise depends on a remote stochastic system, unknown future pricing, and a capital-intensive infrastructure race.

So my plan remains the same: keep learning, keep testing local models, keep replacing cloud dependencies where practical, and aim to cut the cord fully by 2027.

References

• Case_Against_OpenAI_Anthropic_IPO.pdf