And to add to your last point yes it should also be like code: where the costs of development are coming down. Legal costs should trend down if law firms are effectively leveraging LLMs to accellerate their procedures (though I won't hold my breath)
To each their own. When OpenAI droped Sora and focused more on Codex, the product improved dramatically and I'm probably not the only one who dumped Claude Code subscription in favor of Codex; OpenAI's is miles ahead of Anthropic and has been since at least the release GPT 5.6 Sol - even the PR and generous resets is far better than how Anthropic is nickel and diming by requiring paid subscribers to pay yet more credits to even use their best available model (which is not even as good as OpenAI's top 2 models)
Literally just built a custom Adsense dashboard based on not integrating with Google's APIs. Every couple days I export the 2 reports I need from their UI and save them to a folder; it's automated from there and integrates with my clients' website - thats good enough - even if its not real time its a small price to pay for not having to navigate (and maintain) Google's API madness. Like you said 8 different dashboards before you get what you need (and frontier LLMs cant help here), and even then you are forced to build some elaborate Oauth app instead of just getting a simple API key that you can paste in a .env file
When you use opencode to use Claude and Chatgpt models ie- Fable or GPT 5.6
I assume you are getting billed on pure credits?
I was under the assumption that you can only use your Claude/ChatGPT paid plans when using Claude Code or Codex. ie- that you would be paying way more via opencode since you would not be getting the extra limits subsidized by your paid plans.
Same here, and if you really need its key features just add JSDoc and Zod to any given vanilla JS codebase.
Passing around mixed types is not necessarily an anti-pattern either ie- you can do type-checking at runtime and use them as conditions for branching into different control flow patterns - so I don't see the benefit of universal enforcement; not that most TS codebases do anyway (ironically).
I personally don't have a need for TS which introduces an extra build step, extra ritual when defining functions, and no performance benefit over vanilla JS. If I want stricter coding pattern with performance benefits I will use C/C++ for the job instead.
Basically every JavaScript server runtime and build tool supports TypeScript out of the box these days, so the only situation where it adds an extra build step is if you were previously serving your JavaScript source files directly to browsers. Which is okay at small scale, but if you have a substantial-size app with a real userbase, you're wasting a lot of your users' bandwidth if you do this.
TypeScript and Zod serve complementary, mostly non-overlapping purposes; the former detects bugs in your code, while the latter validates data that comes from outside your program and so can't be trusted. There likewise aren't that many use cases where you can choose between C/C++ and JavaScript/TypeScript based on personal preference; usually only one of the two is suitable.
Are you micromanaging your GLM costs? It seems the best bang for buck strategy right now is a Opencode Go subscription to get the subsidized rate and then switch to Openrouter's model above and beyond that + make use of a dual model strategy by having GLM 5.2 do planning and Deepseek V4 Flash for implementation.
Nice, lucky! The Opencode Go GLM 5.2 quota gets used up so fast. It's an expensive model. And while impressive for being open weight, it seems slower than Opus and GPT. So I typically only use it after exhausting quotas of discounted GPT5.5 or Opus 4.6^ paid plans.
reply