The reason we're launching o1 pro is that we have a small slice of power users who want max usage and max intelligence, and this is just a way to supply that option without making them resort to annoying workarounds like buying 10 accounts and rotating through their rate limits. Really it's just an option for those who'd want it; definitely not trying to push a super expensive subscription onto anyone who wouldn't get value from it.
(I work at OpenAI, but I am not involved in o1 pro)
OBVIOUSLY a smart OAI employee wouldn't want the public to think they are already replacing high-level humans.
And OBVIOUSLY OAI senior management will want to try to convince AI engineers that might have 2nd-guessings about their work that they aren't developing a replacement for human beings.
But they are.
Interested to learn more, is that the usual break even point?
But, then again, how companies going to get senior employees if the world stops producing juniors?
I'd settle for knowing what level of usage and intelligence I'm getting instead of feeling gaslighted with models seemingly varying in capabilities depending on the time of day, number of days since release and whatnot
Companies won’t be able to figure those cases out, though, because if they could they’d already have gotten rid of those folks and replaced them with nothing.
What that means is the simple, boilerplate and repetitive stuff is being generated by LLM's, but anything complex or involving more than a singular simple problem LLM's often provide more problems than benefit. Effective dev's are using it to handle simple stuff and Execs are thinking 'the team can be reduced by x', when in reality you can get rid of at best your most junior and least trained people without loosing key abilities.
Watching companies try to sell their AI's and "Agents" as having the ability to reason is also absurd but the non-technical managers and execs are eating it up...
I haven't used ChatGPT enough to judge what a "fair price" is but $200/month seems to be in the ballpark of other "software-tools-for-highly-paid-knowledge-workers" with premium pricing:
- mathematicians: Wolfram Mathematica is $154/mo
- attorneys: WestLaw legal research service is ~$200/month with common options added
- engineers for printed circuit boards : Altium Designer is $355/month
- CAD/CAM designers: Siemens NX base subscription is $615/month
- financial traders : Bloomberg Terminal is ~$2100/month
It will be interesting to see if OpenAI can maintain the $200/month pricing power like the sustainable examples above. The examples in other industries have sustained their premium prices even though there are cheaper less-featured alternatives (sometimes including open source). Indeed, they often increase their prices each year instead of discount them.
One difference from them is that OpenAI has much more intense competition than those older businesses.
They also come with extensive support, documentation and people have vast experience using them. They are also integrated into all other tools if the field very well. This makes them very entrenched. I am not sure OpenAI has any of those things. I also don't know what those things would entail for LLMs.
Maybe they need to add modes that are good for certain tasks or integrate with tools that their users most commonly use like email, document processors.
Bullish
It'll be an object lesson in short-termism.
(and provide some job security, perhaps)
Imagine you have two options:
A) A $20/month service which provides you with $100/month of value.
B) A $200/month service which provides you with $300/month of value.
A nets you $80, but B nets you $100. So you should pick B.
If Claude increases their productivity 5% ($17.5k/yr), but CGPT Pro adds 7% ($24.5k), that's an extra $7k in productivity, which more than makes up for the $2400 annual cost. 10x the price, but only 40% better, but still worth it.
The question is - how good is it really.
Last week when using jetpack compose(which is a react like framework). A cardinal sin in jetpack compose is to change a State variable in a composable based on non-user/UI action which the composable also mutates. This is easy enough to understand this for toy examples. But for more complex systems one can make this mistake. o1-preview made this mistake last week, and I caught it. On prompting it with the stacktrace it did not immediately catch it and recommended a solution that committed the same error. When I actually gave it the documentation on the issue it caught on and made the variable a userpreference instead. I used the userpreference code in my app instead of coding it by myself. It worked well.