croemer

Timeline

Resolved - This incident has been resolved. Thank you for your patience and understanding as we addressed this issue. A detailed root cause analysis will be shared as soon as it is available. Nov 04, 2026 - 11:50 UTC

Monitoring -The degradation affecting Actions has been mitigated. We are monitoring to ensure stability. Nov 04, 2026 - 11:43 UTC

Update - The degradation affecting API Requests, Git Operations, Issues and Pull Requests has been mitigated. We are monitoring to ensure stability. Nov 04, 2026 - 11:30 UTC

Update - We're currently working on mitigating elevated errors and intermittent failures affecting GitHub, including Pull Requests, Git Operations, and Issues. Some requests may fail or be delayed while we work to restore service. We'll provide another update as more information becomes available. Nov 04, 2026 - 11:17 UTC

Update - API Requests is experiencing degraded performance. We are continuing to investigate. Nov 04, 2026 - 11:11 UTC

Update - We're investigating elevated errors and intermittent failures affecting GitHub including Pull Requests, Git Operations, and Issues. We'll continue to keep users updated as we work toward mitigation. Nov 04, 2026 - 10:38 UTC

Update - Pull Requests is experiencing degraded availability. We are continuing to investigate. Nov 04, 2026 - 09:53 UTC

Update - Actions is experiencing degraded performance. We are continuing to investigate. Nov 04, 2026 - 09:50 UTC

Investigating - We are investigating reports of degraded performance for Git Operations, Issues and Pull Requests Nov 04, 2026 - 09:49 UTC

I completely lost my carefully drafted PR message. Aaargh. Now I'll always back it up as a copy in the future. So bloody annoying, at least they should store the draft in local storage somehow in my browser.

Domain registration doesn't mean that much. Many similar domains are already registered, eg python2shell.com is 5k aftermarket but js2shell.com is unregistered. Might not be a bad investment to register the .com for all the top PLs.

I'm not sure I've ever read a sentence like this before LLMs. Maybe I didn't pay attention, possible. I should do a search of pre-LLM writing for this construction.

I see, you're updating the graph with 3 weeks delay, that's a bit confusing. Now there are 4 days at least.

That code font is painful to read, no syntax highlighting and extremely pixelated. It's retro but an eyesore.

Dashboard was last updated on September 7, it started on September 5. Bug? Or no progress? It's linked in the blog post so would expect it to work: https://turbopuffer.com/v3

This one sentence sounds very LLMish:

> Object storage as the source of truth gave the economics, and tiered NVMe SSD/memory caches gave the performance.

Thanks for the tip! Set it up locally and it works!

Is there a Jev-like model I can run on my Mac? Something like Ollama? Or what's the best way to play with it? Is there a cheap/free API service eg on OpenRouter?

Oh cool, I missed that the raw data is available. I shall see if I can do the analysis myself then.

This seems like a poorly executed analysis of very interesting underlying data.

With this degree of average age variability they can't compare failure rates.

They should show us Kaplan-Meier (survival) curves not failure in this quarter.

Unless they set some datacenter on fire, not much in Q2 should be different vs Q1 for the same hard drive other than it being older.

Sure, internally, I'd do a better analysis controlled for age that shows if there are common failure rate increases but here they focus on model failure rates which is completely confounded by age differences.

For those outside US, in Europe I got "Service unavailable".

Switched on US VPN and it works.

Edit: Now it seems to work. Maybe it was a glitch. Or a US government agent is watching this page.

The title is misleading, they found 24 vulnerabilities in Android _apps_ not in Android itself. That's a big difference.

In their own words from the body:

> I’ve reported more than 20 vulnerabilities in Android applications

Pretty crazy that the model doesn't know that it needs to stop before it hits 128k output tokens. I guess it has no sense of how many tokens in it is? Wouldn't this be possible to work into the architecture?

This is evidence that Sonnet 5.5 wasn't yet trained on the HN comments from the Opus 5.5 release. Maybe Pelicanmaxing will lead to 127000 thinking tokens being used on Max.

Playing around with it for a few minutes, Sonnet 5.5 feels very fast, much quicker than Opus 5.5. Can't tell yet if it's a lot worse but the speed is definitely welcome.

Ah, I see, you mean "Jev cannot possibly be calibrated for everyone as there is always missing context".

I understood it as "It is impossible to calibrate Jev".

I typed some German and it was breaking up words so much more than English. Not really surprising given tokenizers are optimized for most commonly used text.

Here's the token efficiency of a corpus translated into various languages and tokenized with the latest OpenAI one:

  Language              Relative tokens
  --------------------------------------
  English                    1.00x
  Portuguese                 1.23x
  Chinese (Simplified)       1.25x
  German                     1.31x
  Spanish                    1.32x
  French                     1.37x
  Arabic                     1.38x
  Chinese (Traditional)      1.42x
  Korean                     1.47x
  Swahili                    1.49x
  Hindi                      1.57x
  Japanese                   1.66x
  Burmese                    3.16x
  Amharic                    5.78x
  Santali                   13.70x

Source: "Tokenizer Fairness in 2026", a reproduction/extension of Petrov, La Malfa, Torr & Bibi, "Language Model Tokenizers Introduce Unfairness Between Languages" (NeurIPS 2023), using FLORES-200.

https://github.com/partyfly/tokenizer-fairness-2026

TFA seems to be sloppy in writing, they should have kept the "meaning... [Some incorrect assumptions about GET]" out of the paragraph.

You're not missing anything. TFA really state this wrong assumption in their own voice.

> This access seems to have only allowed the agents to make ‘GET’ requests, meaning they could fetch and read websites, but not interact with them, submit forms, or send data to them

The authors of this (very interesting) analysis should really not state the sandbox's wrong assumptions in their own voice.

GET absolutely allows you to interact with sites. And of course GET can also send information. It's all up to the server that receives the GET to decide what it let's callers do with it.

Article says that it _can_ be calibrated, it just isn't out of the box. So the title seems contradicted by the body.

> If you want calibrated probabilities you’ll still need to recalibrate Jev’s probabilities on your own data. The good news is that is cheap. A few hundred labeled examples from your actual data can be enough to fit a Platt scaling on top of Jev’s scores.

Hah! You independently picked exactly the same sentences I flagged (I know you posted this 11min before me but the comment only appeared after I had submitted mine).

That's the standard annoying pattern though: "Rewrites are declared by the publisher, never inferred from overlap." and "NULL means dirty, and DELETE is the fence." - still the same LLMisms. I didn't expect them to disappear, but it's not a radical improvement either.

Of course it was exposed - not sure it's explicit or not. Why wouldn't HackerNews comments be part of the training data? And Simon's blog and the many discussions about Pelicans? It'd be hard to miss. Doesn't mean Anthropic has made this an explicit goal in training.

A demo video would be useful, so one can see what it does without having to run oneself.

Which is presumably why Debian developers voted to allow responsible use of LLMs.

Also had a bunch of typos so wasn't even LLM proof read (at least not final form).

I'm not sure I get what you mean.

There are commercial thermostats where the wax element itself is both the temperature sensor and the actuator, eg Thera-100 T1002W0.