The only thing they're going to try to do is ban Chinese models, and that's not going to fly outside the US, so Americans are going be the only losers.
Yeah OLEDs are the first display tech we've had that is on par or better than CRTs in all aspects. On balance the tradeoffs were definitely worth it for the various LCD panel options but motion clarity, colour intensity and black levels were all still beaten by a CRT in a dark room until we got OLEDs.
If OLEDs are 'designed to fail' they've certainly gone about it in a very roundabout way - there would be much easier ways to do planned obsolescence if that was actually the goal of display manufacturers.
I have a LG wallpaper TV 65" from 2021. I see no burn-in whatsoever. Once in a while it says "we will do the pixel refresher thing when you turn off the TV".
I'm pretty sure there's something to it but I'm no expert. Five years later and my TV is just fine.
I use it as a monitor as well. I think the key here is what LG calls "screen shift" which makes obvious sense. No magic, just move the pixels around to prevent stuff like HUD and logos from burning the screen.
Imo there's zero difference between 'thousands of microservices' and 'one monolith with thousands of functions/classes/etc' in terms of effort required to make it correct - both are still tiny interconnected pieces making up a whole, and you can separately unit test a function just as easily as you can separately e2e test a single microservice.
They still make up some whole product that presumably does something as a whole that you actually care about, and the complexity inherent to that doesn't go away with either approach.
Have you had to deal with a microservices environment? Because there's significantly more operational and architectural complexity with a distributed system compared to a monolith. Now you have to deal with reliability, retries/backoffs, versions, distributed transactions, consistency issues, service discovery, idempotency, and a million other things. I would generally not recommend adding all this overhead unless absolutely necessary. Or at least that was the recommendation pre-AI, but I don't think I've changed my mind on it yet.
> Now you have to deal with reliability, retries/backoffs, versions, distributed transactions, consistency issues, service discovery, idempotency, and a million other things.
Someone has to deal with them, but if you are dealing with all of them then you don't really have microservices, just a multi-process monolith.
Then it sounds like you can only have a true microservice architecture if your application doesn't really need transactional guarantees, consistency or fault tolerance.
Microservices are just another "cache" level in the end. They can make sense in the right situations, but you need to make your architecture deliberate in order to reap its advantages. Idempotent services are an easy win, and also places where you have data locality (similar to cache locality, just a few levels lower).
At the end of the day, it comes down to:
- how far does the data have to travel, and at what cost?
- how much latency can your process tolerate?
- how much unreliability can your process tolerate?
- where and how do you isolate resources that are concurrency sensitive?
Sure there is. For thousands of classes/functions, I can test the boundaries between them in nanoseconds each. Integration tests are the important part, because with the quality of AI coding these days, unit testing is a waste of time.
With micro services, that same function call is now a minimum of 200us. And now I have LOC for serialization/deserialization, retries, error handling, etc, bloating my code and making it harder to understand, plus now to do the same integration test I need to understand N different build systems for each component.
The separation in micro services is hard to break though. You need to add an API on one side and a call on the other.
In a monolith it's significantly easier to do something that has an unexpected impact somewhere else. For example, changing a shared object a singleton to a clone will give you race conditions all over the place. You just don't have that footgun in micro services.
It's interesting that all three of those used roughly the same amount of tokens, and almost entirely output. Feels like the thinking level lever didn't alter cost at all for this specific task, even though it did change the output.
That raises the question of what is it actually doing?
If it isn't spending tokens on quality, is it the assumptions about the task difficulty that cause it to perform better? Or are their broader differences in the model being run.
50% cache hit is really low - in a standard agentic loop you should expect like 99%+ cache hit percentage (which should also lower that $12.50 to like a couple of $ for the same amount of tokens).
If you're using a customised harness you should make sure you don't have something that's e.g. changing your system prompt on some requests or rewriting history - it can be tempting to do stuff like strip old thinking tokens or compact tool call results to reduce context size but it's a trap - you want to never change history because of how cheap cache is, even more so with deepseek because their cache hit pricing is so low compared to most other models.
In my experience, that's the OpenRouter tax. Even a session that does everything right to remain sticky ends up getting moved between providers on a few requests, which bills you the full context as input every time the switch happens.
I assume it's done as load balancing/latency mitigation, but it's put me off of OpenRouter for my use cases (limited use, limited need for changing models).
This has not been my experience. Generally I do pin to 1 provider, or 1 provider with a couple fallbacks (especially with deepseek - most providers are 10x the cached token price compared to deepseek themselves), but even when I don't I still usually see 99%+ cache hit percentage. Specifically using pi with various ad-hoc customisations (that I was careful not to break prompt caching with).
Because they don’t want to sign up for 10 different providers and subscriptions/etc, especially if some models are just going to receive light, or rare usage?
It is a pain from openRouter if you don't define your providers correctly, but for DeepSeek, surely not- the weights aren't released yet and there's only one provider, DeepSeek.
With Deepseek as the provider, there's no issue of course, but that means you don't filter providers for data retention, and you could also choose direct API use with them at that point.
Each camera has a different optical system with a different focal length range. This lets the camera cover everything from ultra wide angle to telescopic magnification while remaining thin enough to fit in a phone.
Phones can't fit a zoom lens with moving elements. The other cameras are just other prime lenses so you aren't restricted to having a single focal length all the time.
When you hit the little 0.5x, 1x, 4x buttons in the camera app you are switching between the physical cameras. Though Apple goes out of their way to obscure what is actually happening.
The obvious issue with the product here is that the telephoto lens will not cover the whole image that the 1x captured so only some portion of the center of the frame will be higher resolution.
reply