•••••••••••••••
This is a really bizare argument for anyone who actually knows about options and trades them. If your thesis is that RAM is in a massive bubble and Micron is going to crash when it bursts, you don't express that thesis by buying a put struck around Micron's current bubble price. The fact that you chose a $1000 strike as your example is weird because that's basically the most expensive way to make the argument you're supposedly making. "IV crush" is a strange objection in this context. IV crush matters when you overpay for elevated implied volatility and that volatility subsequently collapses. If Micron suddenly falls hundreds of dollars because the alleged bubble is bursting, then the implied volatility increases which makes your put option even more valuable. The IV that you're claiming will crush you acts in your favor... so once again your argument really suggests you might have heard terms like these in passing but don't quite understand how they actually apply. If you genuinely think Micron is going to collapse sometime over the next two or three years because this entire RAM shortage is an overhyped bubble, then the obvious trade is to buy puts around where you think the stock should return to once that bubble disappears. Micron wasn't remotely a $1000 stock before this run. We can be generous and use a $300 strike since even though that's still 100% higher than Micron's price prior to this run-up, it gets the point across. A long dated $300 put is currently around $7 per share, so one contract costs roughly $700. If Micron eventually falls to $200, that contract is worth $10,000 at expiry. At $100, it's worth $20,000. If the crash happens well before expiry, it can be worth even more than its intrinsic value because there's still time value left. If you're claiming to be certain that a gigantic bubble is going to burst and wipe hundreds of dollars off the stock price, there are long-dated, far-out-of-the-money puts specifically capable of expressing that view. Pointing at an expensive $1000 strike put and saying "look, options are complicated" is not a counter-argument. It's just a weird or rather superficial misunderstanding of some financial concepts.
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
While I have no experience comparing this brand-new model, OpenAI themselves call it "near-Astra" intelligence. I set Astra and Opus 5.5 independently working on the same large research/coding task in an experimental project (doing NURBS surface modeling stuff). They had the same starting repo state, same task packet, same test suite to try to meet. I have the $100 plan in both. Astra used 215% of a week's budget (I burned 2 free resets) and took 13 hours. Opus used 20% of a week's budget and took 20 hours. Both were asked to use lesser sub-agents for implementation grunt work at their discretion (Luna, Sonnet) as long as they manage and review the output. The timing comparison is not that interesting because the wall-clock speed mostly reflects how often they ran the (large, slow) test suite, not their coding speed. Although in the past my gut feeling is that OpenAI models do generally respond faster. The quality of their implementation was more interesting. There turned out to be a bug in one of the unit tests the agents were trying to pass. Opus interpreted the natural-language requirements from the task packet, found the test bug, and fixed it. Astra tried hard to solve the problem without altering the test suite. In practical terms Opus got much, much farther into a useful implementation. Astra was still stubbing out and faking critical parts of the implementation (B-splines) and since it ultimately couldn't pass the full test suite, finally gave up on its implementation. Astra wrote some useful tooling in the process of its efforts which I ended up integrating into Opus's version of the code, but otherwise its approach was behind. Now, this is just one comparison in one domain, and arguably Astra's strict adherence to the tests as-given is a good thing. But Opus wasn't merely loosening the rules / moving the goalposts to pass, it spotted an actual bug, and was more successful at doing what I actually wanted. And the cost difference was Astra-nomical. Out of curiosity for an interpretation free from my personal bias, I gave Astra a hint from Opus and permission to change the test in question, which it did, and got a bit farther, but still ultimately didn't produce a working implementation (to be fair, Opus's was not completely working either, but was closer). I then fired up fresh agents to review the two repos. Predictably, an Opus agent thought the Opus-written repo was the better basis to build on, and an Astra agent thought the Astra-written repo was the one to keep. They were not explicitly told which was which nor did the commit trailers say, but I assume they can tell. However, after doing this twice each, I saved the 4 review reports into another folder and did yet another meta-review of the 4 reports, so each would see the arguments and critiques both directions. In this meta-review both Astra and Opus converged on preferring the Opus implementation.
••••••••
 Top