At 60 acres you can probably do a 3000 feet grass strip runway. Get a Cessna and fly yourself, being within flying distance of a tiny airport in this case is pretty awesome. 2.5 hour drive is ~ 1 hour flight time for your C172s.
It really depends on how flat the terrain is and what the weather conditions are like. If it's often rainy, windy, or snowy, you might not have many opportunities to use the plane.
At some point, I think electric VTOL aircraft will make economic sense. Companies like Vight Aero are working on two seaters with decent range and speed.[1] Then you'd just need an area the size of a tennis court to take off and land. You also wouldn't have to ship fuel in, as you could charge the aircraft with off-grid solar. If that happens, I could see a lot of people moving away from cities.
It's very much real but not necessarily malicious. We track upstream providers pretty closely. Sometimes it's a just matter of a single GPU runtime layer bug/update to break inference outputs. The model weights don't necessarily change/get quantized.
I suspect they play with their quants and perform weight sensitive tensor/parameter tuning among other things to get serving faster and some of the time for some workloads it surfaces. I feel this has a high probability of being correct and an explanation for some of this.
I refuse to believe they "play with their quants" once a model version is labelled and shipped. What does that even mean; could you explain it please? These models aren't just used through claude/codex, they are used through API access and it's quite expensive. Previous regressions were related to harness regression, and platform issues. Not some Nerf conspiracy 99% of the vibe bros believe in.
Note: I know what quantization is so don't hold back.
I would guess that if they do use such methods, it'd be to handle peak loads that go beyond their compute capacity, while they run the models at full capability when there's excess capacity
like before Anthropic signed the Colossus deal, the usage limits were insane and everyone was complaining, I wouldn't be surprised if they'd rather try to make inference faster that way than try to just limit people, at least for those on subscriptions
Trimming parameter size that can be reduced while surviving regression evals. They have so much data they know exactly where to shave the models. Most people will never see it in their work loads. It won’t affect core benches because that is part of the regression evaluation.
During peak hours requests queue and inference slows. During off-peak they can move systems over to training.
Where is the evidence they are "nerfing" the models due to request volume?
Edit: I don't know they do, I mean they could repurpose systems if they are idle. Inference demand is global, and providers like Azure have global routing options that are cheaper. Night time in the USA could be serving inference demand on the other side of the globe.
It's all just conjecture, your hypothesis about moving systems equally so.
But you seem adamant that there's no chance the providers serve slightly quantized models for subscription users during high loads, or otherwise tweak models for requests from those users.
It's tricky to prove either way, but the chance is not zero.
It doesn't have to look "cartoony". Harness issue. Your 2026 models are trained on a sufficiently broad set of images that style is almost a solved problem.
> It doesn’t seem like aviation became safer because pilots took risks
That's pretty much the job of test pilots even today. They are usually dual trained pilots and engineers/technicians, and their job is basically to QA new planes. In military aviation especially test pilots are often feeders into the astronaut program (a different but similar type of daredevil).
They have a different culture and values, the US’s strengths lie in individualism and the character of the individuals that live here, and that’s both good and bad. But it’s entirely unsurprising that when responsibility and ownership is sharded up into trillions of tiny pieces and diffused that the outcome is awful.
I'm certainly a fan of Japanese products. They are high-quality, etc. And everything was clean and orderly and amazing as a short-term visitor over 20 years ago. I would not be quick to say it is a better culture though, I suspect some negative are quite hidden, and lurking underneath the cultural norms. Again, as an outsider, I have lots of positive thoughts about Japanese culture.
I think you are overcomplicating things. You have a power envelope, and you have to design your application around it. That's pretty much it. From an engineering perspective, there's no real complexity when it comes to the hardware, software protocols operate one level higher. Your app lives and dies by its power budget.
Another interesting use case would be using the card as part of a crypto escrow.
The problems being solved here are:
- walking around with a device that can access a large wallet that could be accessed under duress or coercion
- Key Pairs are hard to remember and type
___
- pre-pay an escrow online with $100
- have a payment card in your pocket
- meet person with another card
- set a payment amount
- touch cards
- escrow unlocks the amount as soon as either card pushes the update online - which if online could be immediately
- card confirms the transaction??
- can also delay the transaction, and if both cards are lost in the meantime, the transaction doesn't go through
- can also specify the payment amount as "set later"
- receiver can also request an amount
- escrow can be funded after the meeting
- good for 1:many payments too, eg splitting a bill
____
cards could also be Key Pair generators, for transferring public keys to other cards, with the exchange recorded for later use. No escrow required. A lot of benefits over handing out printed QR codes of addresses.
Okay so everytime I need escrow I will have to do all this? And use a different account anyway? Does not seem more convenient than current systems. Seems like you're trying to make the problem meet the solution instead of making the solution meet a problem and not considering actual user experience.
I don't know a lot about this area, but I like the [1 doge = 1 doge] thing where people completely stop thinking about dollars and crypto-to-fiat conversion.
The card can work with Lay-buy/lay-by:
_____
You go into a store, pick something out. Get a crypto address for it and the amount required with your special card. They set the thing aside. You leave and return to the store when the transaction has gone through and get your stuff.
You don't pay immediately because you don't want to be walking around with a crypto wallet or a crypto debit card. The merchant doesn't want to pay fees either when dealing with an intermediary. There's no fiat conversion either, at least not as a given.
_____
Gemini says this:
"If you want to do this today, ask the merchant to print or email you a dynamic checkout invoice/QR code so you can complete the transfer on your own device later."
But how widespread is that?
"It is virtually non-existent at retail scale. While the underlying technology exists, you will practically never encounter this specific workflow in the wild."
The "special card" is an evolution of that use-case and organizes it better. You can leave home without thinking about dollars, ready to pay with crypto and not worry about being robbed. No worrying about stockpiling a bunch of receipts either. It's just a 2-step buying process, that's the downside. The shop also has to hope you end up paying once they set it aside. Maybe they'll need a deposit. They can offer deliveries?
Another idea is to pay online and collect it later. Use the card to authenticate yourself when you collect. That would need some decent tech backing it. Make it non-committal where if you don't collect within a certain time frame, you get your money back but lose a penalty chunk.
Isn't this what smart contracts are designed for - crypto transactions tied to real world events? The "special card" provides those events.
The benchmark is nice but it's very much biased towards flagships i.e. not very useful in practice if you are trying to ship production mobile apps. Apple historically is extremely stingy when it comes to RAM and they never bothered giving iPads and iPhones more ram until fairly recently (most likely because of ML demands). Your covid era 10th Gen iPads only have 4GB of RAM for the base models.
The Android ecosystem is much more liberal when it comes to RAM because their Dalvik VM JIT (their Java Android Runtime, partially AOT compiled and partially JITed) design is not particularly memory efficient. But the main issue with Android is that their mid/low end (think the Samsung Galaxy A series, the OnePlus Nords, the Motorola Gs etc.) are very inefficient when it comes to single core compute performance compared to iPhones, and it gets worse once you factor in power efficiency. The high end Android flagships running the Snapdragons elites (especially post Oryon acquisition) have no problems matching if not exceeding Apple hardware performance in terms of raw power but they are much more power hungry.
At the end of the day, the current gen of "pocket scale" LLMs are still far from being able to be deployed at scale on mobile. Maybe in another year or two once RAM prices have fallen enough and mobile manufacturers build a lot more matmul and memory circuits into their SoCs instead of a tiny mostly useless "NPU/tensor processor" that doesn't have enough RAM to run anything useful. Current gen production mobile ML still heavily rely on traditional transfer learning like Apple's Core.ML (tiny pre trained models, with perhaps the final layer inference head swapped out).
If you want a good example of production mobile ML, take a look at FUTO keyboard's transformer model for their keystroke prediction/autocorrect which operates in near real-time.
I would say right now 100M-300M params is about the maximum you can do if you want any reasonable level of performance on your "average" non flagship mobile. I would keep to sub 100M for power efficiency sake.
