With an assemblage of models like Jev + Opus or Jev + Qwen, Jev would often do the right thing when deciding to escalate to another model - I was impressed that it would usually make the right call, especially if you gave it good awareness of what the other model capabilities were. "ESCALATE to opus if you need good vision awareness".

When Haiku 5.5 came out though, for my tasks, the cost differences disappeared almost immediately. Haiku was good enough / fast enough for so many things that introducing a decider layer didn't offer huge wins. Jev's "millisecond" level performance was nice but would get dwarfed by other latencies in my chain ( web browsing ), that it didn't make a measurable difference in my tasks.

I’ve supported some of this in my own tool, ZShot - capture in sqlite, Quicklook extensions for WARC and WACZ. Just trying to make archiving easy and interpretable.

It’s also been interesting to see people use archival but for different uses: Kiwix [2] showed up in my reading recently, “archival but for offline internet”, which I’m kind of fascinated by.

[1]: https://zshot-app.com/for/archivists/

[2]: https://get.kiwix.org/en/

Along the way I ended up adding an internal agent framework to satisfy stuff like "log in, click the button, and then take a screenshot", out of which fell stuff like automatically generating Playwright tests from that. It even runs the Playwright test suite and Puppeteer test suites ( a bit faster, and for a lot less memory ). I kinda love this bit because I can layer in multiple models that will bounce control of the web session between each other, to do stuff like let a Typesafe model choose to escalate to Opus when it needs higher minded behavior. It's fun to watch it happen.

I've mentioned it a few times around here, I'll probably do a Show HN soon when I feel like it's ready for that. Hopefully soon.

[1] https://zshot-app.com/

My product that I'm working on sorta acquired a bunch of that. I put a ton of work into making a browser that could just see / interact w/ the web in a ton of different contexts. Now that I have it, it's pretty amazing to just have the agent do everything I need it to ( pull a network log, debug JS, navigate a form ), and it has the appropriate context everywhere.

[1]: Mac app, https://zshot-app.com/

[2]: Linux / Mac CLI, https://zshot-cli.com/

You'll have to sign up for a trial to do this, but you can just have your coding agent drive a session and just ask it to install the zshot skill, then drive a session and record a puppeteer script for you. If you try it out, love to hear what you think.

I say this because I was part of a migration from a mid-size React Native app to a Swift/Kotlin native app redo. I did the majority of the technical work on it. The majority of the work occurred before January 2026 and without LLM code assistance, though later features in the app definitely used some.

For anyone considering this, I'd say that the migration is definitely worth considering without even taking LLM assistance into consideration. The continued React Native tax of unnecessarily difficult upgrades, impedance mismatch w/ underlying core frameworks, and incredibly uneven library quality just cause your business to really spend a lot of time shepherding the tech over the finish line. It's pretty wonderful to be back in the world of "build, compile, ship, be sure". One thing as a fundamental principle that I think the Shopify article 'gets' at, is the importance of the feedback cycle - investing time in our integration test story very early on both helped w/ my cycle times, and later in providing guardrails for LLM assistance.

All to say that this decision is worth considering without even taking LLM assistance into account.

When VSCode came about and had great integration for a language I was primarily using at the time ( Typescript ) I switched to that and was happy for the comparatively low config required. My Helix switch came about just because of how VSCode absolutely chewed through battery usage when I was out and about.

One thing I've struggled with is simply remembering everything it can do. I made a Desktop Mat[0] to help remind me ( literally just finished it so will see how helpful it is when the printed version arrives ).

[0] https://git.sr.ht/~netshade/helix-deskmat

> But, come on: you never took us too seriously about K8s, right? K8s is hard for us to use, but that doesn’t mean it’s not a great fit for what you’re building. We’ve been clear about that all along, right? Sure we have!

which already starts the post in a bad space for the reader. I have cognitive whiplash from what is intended. "We DON'T like Kubernets UNTIL WE DO but then WE MIGHT NOT IN THE FUTURE". Clear meaning is far more appreciated.

> More to come! We’re itching to see just how many different ways this bet might pay off. Or: we’ll perish in flames! Either way, it’ll be fun to watch.

is like nails on the chalkboard for me.

Could it just be that investing in Apple could be seen as "I get all the upside of any benefits I would get in investing in TSMC, with the additional upside of getting exposure to all of Apple's product decisions in non-chip related markets ( eg financial, content, et al )?" Like, if TSMC invented a new fab process tomorrow that was amazing, that'd be cool, but it'd be unlikely to make a substantial increase in stock prices in its future as that sort of is how TSMC normally behaves. That's their whole business. But Apple has a history of unlocking new markets and adding new cash flows, plus doing a pretty good job maintaining their current cash flows, so you get more upside on Apple, plus a hedged exposure to TSMC?

I say all that with full acknowledgement I'm just like, playing a guessing game at professionals here.

I've been happy with it thus far, even though I should note that my usage is pretty low stakes / trivial. It has just enough of what I want of modern language conveniences that I'm not sad about using it. I certainly derive some happiness from having a zero impedance inclusion on the iOS and server side; conversely, were I to use Rust, my early reading seemed to indicate I' have to navigate a bit of FFI and library inclusion on the iOS side that I'd much prefer not to.

So, at hobbyist level, it's been fine. If I were to go purely on technical merits and language niceties I would have chosen Rust, as the depth of language features and standard library features is really really nice for me, but the fact that I can just have something that works in either of my desired platforms has made it okay to deal with a slightly less mature (IMO) ecosystem.

Also, as a note, I've done just a tiny bit of SwiftWASM with this same toolset, and it's not bad either. Pretty far behind Rust's WASM capabilities in my experience, but accomplishes what I need and is generally nice. Tokamak ( a WASM-friendly UI framework like SwiftUI ) has been nice in my initial usage as well. I'm definitely at a firm hobbyist level of using this stuff tho, no production anecdotes to give you unfortunately.

Obvs it would be great if they covered 100%, but if you're trying to cover your ass right now, it's worth asking your provider about.

Also, I know that some makers ( Eli Lilly in particular ) also offer need-based aid programs to provide insulin. If you reach out to them and they're manufacturing, I believe you can get the insulin at near free if not free. ( This is also true for many medications that fall into the commonly-used category, you can explore manufacturer sites to see if they provide aid for a particular drug that is in your list )