Tesla have their own Insurance product which is already very competitive compared to other providers. Not sure if lemonade can beat them . Tesla's insurance product has similar objective in place already where it rewards self driving over manual driving.
Tesla is cooperating with Lemonade on this by providing them necessary user driving data.
If Tesla didn't want Lemonade to provide this, they could block them.
Strategically, Tesla doesn't want to be an insurer. They started the insurance product years ago, before Lemonade also offered this, to make FSD more attractive to buyers.
But the expansion stalled, maybe because the state bureaucracy or maybe because Tesla shifted priority to other things.
In conclusion: Tesla is happy that Lemonade offers this. It makes Tesla cars more attractive to buyers without Tesla doing the work of starting an insurance company in every state.
> But the expansion stalled, maybe because the state bureaucracy or maybe because Tesla shifted priority to other things.
If the math was mathing, it would be malpractice not to expand it. I'm betting that their scheme simply wasn't workable, given the extremely high costs of claims (Tesla repairs aren't cheap) relative to the low rates that they were collecting on premiums. The cheap premiums are probably a form of market dumping to get people to buy their FSD product, the sales of which boosts their share price.
It was not workable. They have a loss ratio of >100% [1], as in they paid out more in claims than received in premiums before even accounting for literally any other costs. Industry average is ~60-80% to stay profitable when including other costs.
They released the Tesla Insurance product because their cars were excessively expensive to insure, increasing ownership costs, which was impacting sales. By releasing the unprofitable Tesla Insurance product, they could subsidize ownership costs making the cars more attractive to buy right now which pumped revenues immediately in return for a "accidental" write-down in the future.
That is not true. Since Tesla was losing money on their insurance to boost sales the customers were not paying for it since they were receiving a service for below cost.
The people paying were actually the retirement funds who fronted Tesla's cash reserves when they purchased Tesla stock and the US government paying for it in the form of more tax credits on sales that would not have otherwise materialized without this financial fraud. But do not worry, retirement funds and the US government may have lost, but it boosted Tesla sales and stock valuation so that Elon Musk could reach his KPIs to get his multiple tens of billions of dollars of payout.
The math should've mathed. Better data === lower losses right? They probably weren't able to get it to work quite right on the tech side and were eating fat losses during an already bad time in the market.
It'll come back.
Lemonade or Tesla if you find this, let's pilot, i'm a founder in sunnyvale, insurtech vertical at pnp
You'd be very surprised. Distribution works wonders. You could have a large carrier taking over Tesla's own vehicles in markets they care about. The difference then would be loss ratios on the data collection, like does LIDAR data really beat Progressive Snapshot?
The two are measuring data for different sources of losses for carriers.
Do you mean a terminal-based editor, like emacs, vim, neovim, or helix? (I quite like the latter, after having used all the former to some degree.)
Or do you mean line-editors? They have gotten impressively good. See rustyline (based on linenoise) and reedline (not a typo; developed by the Nushell team) for example. Way better than one might expect!
I love it. I have 40 files open in it right now - most of them .c source files with LSP and Treesitter running and it uses 250MB of RAM. Everything works instantly, Telescope is imo the new standard for file navigation (and navigation in general: grep, symbols even neovim shortcuts). Git integration is fantastic as well.
I have spent some time configuring it and probably will spend more when I start including more languages but imo it's worth it. You can configure everything but you can also find very nice defaults by running Kickstarter (or some heavier neovim "distro").
Microsoft has done great work with LSPs - I can now get great navigation/autocompletion/formatting/inline errors/warning combined with neovim navigation, light weight and fantastic tools/extensions.
One thing I haven't integrated yet is a debugger (gdb from the terminal is good enough for me), maybe that's something people are missing in neovim?
TL;DR is that they didn't clean the repo (.git/ folder), model just reward hacked its way to look up future commits with fixes. Credit goes to everyone in this thread for solving this: https://xcancel.com/xeophon/status/2006969664346501589
(given that IQuestLab published their SWE-Bench Verified trajectory data, I want to be charitable and assume genuine oversight rather than "benchmaxxing", probably an easy to miss thing if you are new to benchmarking)
> I want to be charitable and assume genuine oversight rather than "benchmaxxing", probably an easy to miss thing if you are new to benchmarking
I don't doubt that it's an oversight, it does however say something about the researchers when they didn't look at a single output where they would have immediately caught this.
Given the decrease in the benchmark score from the correction, I don't think you can assume they didn't check a single output. Clearly the model is still very capable and the model cheating its results didn't affect most of the benchmark.
Isn't it the opposite? From the link: Scores range from -100 to 100, where 0 means as many correct as incorrect answers, and negative scores mean more incorrect than correct.
Gemini 3 Flash scored +13 in the test, more correct answers than incorrect.
If you start from low levels, then yes, as long as you keep your blood levels in check. It would take a while to overdose it this way, but it's not impossible.
i cant find it now. It was an article that suggested you may underestimate your natural production, especially in summer, so its safer to use high doses for a period of 3 months or so with a break of the same duration, after all we are likely “accustomed “ to fluctuating supply through the year.
Technically you kind of get this in Nevada when using Tesla insurance and if you drive 100 % FSD. If you drive manually you are pretty much doxed for random Front collision Warning which is super sensitive
It might be that our current tokenization is inefficient compared to how well image pipeline does. Language already does lot of compression but there might be even better way to represent it in latent space
A lot of cool things are shot down by "it requires more compute, and by a lot, and we're already compute starved on any day of the week that ends in y, so, not worth it".
If we had a million times the compute? We might have brute forced our way to AGI by now.
It's kind of a shortcut answer by now. Especially for anything that touches pretraining.
"Why aren't we doing X?", where X is a thing that sounds sensible, seems like it would help, and does indeed help, and there's even a paper here proving that it helps.
The answer is: check the paper, it says there on page 12 in a throwaway line that they used 3 times the compute for the new method than for the controls. And the gain was +4%.
A lot of promising things are resource hogs, and there are too many better things to burn the GPU-hours on.
This has a ton of seemingly random assumptions, why can't we compress multiple latent space representations into one? Even in simple tokenizers token "and" has no right being the same size as "scientist".
Image models use "larger" tokens. You can get this effect with text tokens if you use a larger token dictionary and generate common n-gram tokens, but the current LLM architecture isn't friendly to large output distributions.
You don't have to use the same token dictionary for input and output. There's things like simultaneously predicting multiple tokens ahead as an auxiliary loss and for speculative decoding, where the output is larger than the input, and similarly you could have a model where the input tokens combine multiple output tokens. You would still need to do a forward pass per output token during autoregressive generation, but prefill would require fewer passes and the KV cache would be smaller too, so it could still produce a decent speedup.
But in the DeepSeek-OCR paper, compressing more text into the same number of visual input tokens leads to progressively worse output precision, so it's not a free lunch but a speed-quality tradeoff, and more fine-grained KV cache-compression methods might deliver better speedups without degrading the output as much.
Similar feeling. Seems it is good at certain things and if something doesnt work it want to do things simply and in turn becomes something that you didnt ask for and certain times opposite of what you wanted. On the other hand with codex certain time you feel the AGI but that is like 2 out of 10 sessions. This is primarily may be due to how complete the prompt and how well you define the problems.
reply