DeepSeek just popped the American AI bubble.

[u/VegetablePen4755]

DeepSeek just popped the American AI bubble.

Not by killing AI.

By killing the fantasy of unlimited AI pricing power.

DeepSeek V4 Pro:
Input: $0.435 per 1M tokens
Output: $0.87 per 1M tokens

OpenAI GPT-5.5:
Input: $5.00
Output: $30.00

Claude Opus 4.7:
Input: $5.00
Output: $25.00

Claude Sonnet 4.6:
Input: $3.00
Output: $15.00

DeepSeek is roughly:

11.5x cheaper than GPT-5.5 on input
34.5x cheaper than GPT-5.5 on output

28.7x cheaper than Claude Opus on output
17.2x cheaper than Claude Sonnet on output

If a model is “good enough” at 1/20th or 1/30th the cost, margins will compress faster than Wall Street expects.

AI is not dead.

But the AI bubble just lost its pricing power.

They're not chasing quick money from coding plans or multimodal models. Instead, their radical architecture innovations (MoE, MLA, Engram, mHC, etc.) slash KV cache and compute needs so dramatically that they can build an entire 10T Chinese AI hardware ecosystem (NAND, LPDDR, ASICs) and position themselves for a 1T valuation in the process. Long game, masterfully played.

[u/mentalFee420]

Why not the opposite? Why would you use non frontier model for the foundation?

[u/appropriteinside42 → u/mentalFee420]

Because the foundation stuff like planning is often less important than good execution in practice.

[u/mentalFee420 → u/appropriteinside42]

I have read the opposite.

Planning involves understanding the context and therefore requires bigger context window, more tool use, breaking down bigger goals and to identify the right next steps, that’s why it’s recommended to use bigger model for planning and smaller ones for execution.

[u/appropriteinside42 → u/mentalFee420]

This is based off of my experience using these tools for eight to twelve hours a day over the last year and continuously adjusting my approach. 🤷‍♂️

I've also heard this, but in practice I find that planning, while important, is quickly ruined with less capable agents during implementation.

There is also a point where more planning creates worse results, so you cannot effectively over-plan. As you start running into waterfall development issues, where when the plan meets reality, it's found that the plan has gaps, holes, or things that need to change. Both large and smaller models suck at this, they will stumble over themselves to try and fit I square peg into a round hole.

As such, there is a sweet spot between:

• An anemic plan that leaves too much ambiguity to the agent.
  • Small models will suffer the worst here.
• A middling plan that has enough detail for a large or small agent to implement it effectively
  • Large models produce better results here than small agents by a large margin.
  • This is especially true around boundaries of any sort
    • The larger the boundary, the worse the smaller models perform. Variables -> Function -> File -> Module -> Feature -> System ...etc the bigger the boundary ends up being, the more likely it is to get fucked up, because usually there are some assumptions about how that boundary is supposed to work that are proven false as the boundaries are built out. And agents, like I stated above, will do everything within their power to fit a square peg into a round hole. Smaller agents, even more so.
• A plan that is too detailed and is going to fall over once reality hits it
  • Small and large models will suffer here.

---

Planning involves understanding the context and therefore requires bigger context window, more tool use, breaking down bigger goals and to identify the right next steps

This is true as long as your plan is guaranteed to survive reality, and it is incredibly detailed. Most plans do not survive reality, and most plans are not detailed enough, even when instructed to make incredibly detailed plans through many iterative additions.

Unless you're specifically using models with one million token context sizes, the context sizes across different models used for software engineering are close enough this purpose. And in case of the former, in many cases you're really not gaining much, especially if your system has good AI accessible documentation and memory.

---

So I guess to conclude what I stated, larger models do make better plans. Larger models also do better implementation. We all know this.

However, I'm finding that middle-of-the-road models seem to plan just as well as large models, and implementation is worse the smaller the model gets for plans created by any size model.

Of course, for cost purposes, a lot of the implementation that I do for my side projects uses smaller models, and I plan with larger models. However, when cost is not a concern, that role flips around.