> ...but the human reviewing, directing, and course-correcting feels worse, not better.
Has this person ever been a design or tech-lead for a team? I'm still tired and I've moved on from that role over 5 years ago. Gathering requirements, designing a solution, implementing as tickets, handing off to developers, staying involved in the feedback loop, then reviewing the code and iterating on PRs is absolutely exhausting. The only thing greater than the naive take that HITM is tiring is the privilege to not understand how asinine it is.
Ah - xhigh is probably what you want. Their docs suggest xhigh for agentic coding, though judging by their blog high should be better than 4.6 max (ymmv)
I've always used high, so maybe I should be using xhigh
Ya...you may be who I'm talking about though (if you're speaking from experience). If your methodology is "I used 4.6 max, so I'm going to try 4.7 max" this is fully on you - 4.7 max is not equivalent to 4.6 max, you want 4.7 xhigh.
From their docs:
max: Max effort can deliver performance gains in some use cases, but may show diminishing returns from increased token usage. This setting can also sometimes be prone to overthinking. We recommend testing max effort for intelligence-demanding tasks.
xhigh (new): Extra high effort is the best setting for most coding and agentic use cases.
I'm mind blown people are complaining about token consumption and not communicating what thinking level they're using - if cost is a concern and you're paying any attention, you'd be starting with medium and seeing if you can get better results with less tokens. Every person complaining about token usage seem to have no methodology - probably using max and completely oblivious.
Am I dumb, or are they not explaining what level thinking they're using? We all read the Anthropic blog post yesterday - 4.7 max consumes/produces an incredible number of tokens and it's not equivalent to 4.6 max; xhigh is the new "max".
I tried creating a whatsapp "bot" which would just send notifications for my Jellyfin server. It was a bureaucratic nightmare - creating dev accounts, creating some sort of "project", then it was requiring I register it as a business as though the only valid use case for creating an app for WhatsApp is a business, then it required me to verify my identify and upload documents.
Again? This happened like 6 or 7 years ago. I had so many issues with macOS in the few years I was forced to use a MacBook that I refused to use it. Not surprised to see this stuff still happening.
Disingenuous or not, it was a bad analogy because it inferred that it was intentionally being abused which is completely false. The proof of that is this original post - Anthropic did not clearly (or even at all) identify how you could use your tokens with the subscription regardless of their intentions.
You're now misinterpreting my argument and misrepresenting it. I did not, in any way, suggest that Anthropic was "pulling the rug" to its users nor that they were entitled to use their tokens using the API with third parties. Full stop.
Of course, third-party API usage wasn't intended to be allowed for consuming subscription tokens. This is exactly what my analogy was structured to explain; a Disneyland season pass isn't intended to be used solely for parking. Anthropic did not intend for subscription tokens to be consumed by third-parties the same way users did not intend to abuse the subscription to derive more value than what was allotted to them. Your analogy missed that last part, which is absolutely crucial to understand.
I don't understand how you're making the exact arguments I'm making, then somehow completely misunderstanding what's being said.
It's more buying a season pass for Disneyland, then getting told you can't park for free if you're entering the park even though free parking is included with the pass. Still not unreasonable, but brings to light the intention of the tool is to force the user into an ecosystem rather.
Has this person ever been a design or tech-lead for a team? I'm still tired and I've moved on from that role over 5 years ago. Gathering requirements, designing a solution, implementing as tickets, handing off to developers, staying involved in the feedback loop, then reviewing the code and iterating on PRs is absolutely exhausting. The only thing greater than the naive take that HITM is tiring is the privilege to not understand how asinine it is.