> hyper-malleable control surface [...] (the stream deck is popular for a reason!).

I agree with the sentiment - making a control surface that adapts to the user's current task makes total sense to me, and is a compelling feature in theory.

The execution (and how the touchbar differs from the Stream Deck) is where I think the argument falls apart. There is effectively zero ability to navigate the touchbar without using your eyes and taking your focus off the display, and your work. The Stream Deck can easily be used without looking. A static grid of real buttons whose function changes within context is a more useful implementation in the real world, even though it is technically _less_ capable.

IMO the touchbar concept is flawed in exactly in the same way as the modern car user interface.

could it be that game mode is attempting to run the game in compat mode even though you are running the native build?

This works:

  $ZAI_ANTHROPIC_BASE_URL=xxx
  $ZAI_ANTHROPIC_AUTH_TOKEN=xxx

  alias "claude-zai"="ANTHROPIC_BASE_URL=$ZAI_ANTHROPIC_BASE_URL ANTHROPIC_AUTH_TOKEN=$ZAI_ANTHROPIC_AUTH_TOKEN claude"

Then you can run `claude`, hit your limit, exit the session and `claude-zai -c` to continue (with context reset, of course).

There is config you can add to your ~/.claude/settings.json file for this. (I'm on mobile!)

I tried this and it broke the conversation. :(

Yes you usually need to compact first before doing this kind of thing because the context windows are different.

Thanks will try it out.

Why would one want to do that instead of using claude-zai -c from the start? All this is pretty new to me, kick a n00b a clue please.

Claude is smarter than this model. So spilling over to a less preferred model when you run out of quota is a thing.

they put a special coating on the model to discourage this behavior

Ah, that explains it.

> Most frameworks also by default block ALL environment variables on the client side

I’ve been out of full stack dev for ~5 years now, and this statement is breaking my brain

The incentive seems very thin/weak. Pay extra now to push DP adoption and hope that in ~10-15 years you can drop the HDMI port? Meanwhile you still pay the cartel, and they invest your money directly against your interests. And it all hinges on predicting consumer adoption which is nearly impossible. I honestly don’t see how they could justify making such a step in that direction let alone a significant one.

That's a catch 22 / circular argument that can always be used to excuse inaction, but it's not a real argument. Yes, it's a long term problem to solve and has many moving parts. But if they don't solve their part, they are only slowing it down even more. Any contribution to move things forward moves things forward, and lack of it delays things.

I.e. if you are saying "we feed the cartel, let's not do anything about it, since doing anything will only potentially help later, so we still need to feed the cartel in in the interim" doesn't really stand any argument grounds. I.e. feed the cartel and do nothing is worse than feed the cartel and do what you can to stop that over time.

And their piece of this is pretty big (huge portion of TV market), that's why they in particular should be asked more than others, why they aren't doing their part.

It's not so much that it's a catch 22, its that there's no financial incentive for them. TVs are a low margin item already, and Samsung/LG get their margin by being brand names and advertising fancy features.

I doubt they would meaningfully save money over investing in DP, and the opportunity cost is greater for them to spend that money on the next "Frame" TV or whatever.

LG, Samsung and Sony are the only actual panel manufacturers and they probably bake those license fees into the panels they sell back to HDMI Forum.

May be, but by not solving the problem, they become part of the problem, even if they aren't part of HDMI cartel directly. So it's their fault too problems like above happen.

For DP adoption it's too late. They should push for USB4 / Thunderbolt 4 instead. We are in the phase where about every new laptop has USB4. Connecting your laptop/phone to a TV might be a selling point. I'd love that for hotel TVs.

wireless charging at the expense of size/bulk

But the rechargeable batteries are still not user replaceable, right?

why would the tool minify the script it generated?

or just keenly aware of their own strengths, weaknesses, and time budget for this? the leap to “over scoping” is wild.

I was just meaning, that if you think you can't do it in the timeframe, then you are making it too big for yourself. The rules are so loose that you could literally make a programming language that has a single command `run_my_awesome_game()` and fully impliment the logic etc in your language and library of choice. Obviously a trivial/useless example, but take it up a few notches and you could have something interesting. A DSL inside JSON can be very powerful.

I think they mean something like (or what I think of as) “RPC calls, but with the flexibility to select a granular subset of the result based on one or more schemas”. This is how I’ve used graphql in the past at least.