OpenRouter is great business I agree, but I'm not still convinced how the integrity of providers' models is ensured. In other words, can't the provider serve DSv4 flash advertising it as DSv4 Pro?

I'm aware that OpenRouter checks response quality onboarding, and does further checks occasionally, but I'm concerned that it's basically a cat-and-a-mouse problem between the scammers and the detectors. For example, there could be a signal that a specific pattern of requests are from OpenRouter's quality testing bots. Or, they can just route 1% of requests to an inferior model and benefit a small gain, hoping it fits into the statistically allowed margin.

How is that a problem that's unique to openrouter? Who's to say when I query the Anthropic API directly, wanting to use Opus, but they determine it doesn' need Opus, route it to Sonnet instead and pocket the difference? The only difference with openrouter is that it's another layer where this type of fraud could occur.

OpenRouter's list of providers is very large and includes many little known and sketchy companies.

Yes, it is awfully inconsistent today. They run some tests (accuracy table buried on model page) but they are sparse and only capture a single moment in time. I would love to see OpenRouter take this more seriously.

Nice article, and I'd like to mention an additional topic that would give the readers some impression:

Fiat-Shamir transformation. The interactive process between the prover and verifier can be transformed into a non-interactive one with a hash function(modeled as a random oracle). This improves the "user experience" as the entire proving process can be done in a single turn. The idea is to feed the problem itself into the hash function and let it generate randomness that was originally given by the verifier.

In that way the autoregressive nature of LLM won't let itself "plan" to reason with the intended budget. It doesn't "look ahead".

I don't use Claude for my daily work anymore(due to OAuth restrictions on third party agents), but one theory I saw in another community why Opus 5 is so bad even though benchmark scores were good, is that Anthropic's internal usage pattern is to let Fable to spawn and manage swarms of Opus subagents. This pattern won't penalize that Opus is not well aligned for direct human coworking on posttraining. The worse part is, this makes Fable the user's best default choice for every jobs even if they don't have unlimited credits like Anthropic employees do.

As a South Korean I'm lowkey surprised that most reactions posted here is describing the detention experience to be some kind of human rights abuse. Most Koreans debating on Internet demand severe punishment so criminals be afraid of getting jailed. I know this is a very questionable strategy, but afaik this is the most dominant public sentiment over this topic.

Being treated as innocent until proven guilty in a court of law is considered to be a fundamental right in the West.

That's noble until an innocent person gets jailed.

Yes we do have[^1] but unfortunately it looks like not checking the integrity, just reachability.

[1]: https://downdetectorsdowndetectorsdowndetector.com/

Amazed that Safari does not support WebGPU even with the latest release. Opened Chrome and it works. Very cool demo!

Unfortunately not out of the box but the demo runs really well on M4 chips. It can be enabled as such (I'm on Sequoia): 1. Safari > Settings > Advanced > Show features for web developers 2. Develop > Feature Flags > Search for WebGPU

Safari Tech Preview may have it enabled by default.

Apple quality at its peak.

Just like iphones get the latest/newest features after top of the line Androids.

it works in Safari on both Mac and iOS but you have to enable WebGPU in the settings as Safari has not yet shipped it.

Unfortunately, the demo itself is not responsive to the screen size.

> Consequently, this also means you cannot define two error variants from the same source type. Considering you are performing some I/O operations, you won't know whether an error is generated in the write path or the read path. This is also an important reason we don't use thiserror: the context is blurred in type.

This is true only if you add #[from] attribute to a variant. Implementing std::convert::From is completely optional. Personally I don't prefer it too as it ambiguates the context. I only use it for "trivially" wrapped errors like eyre::Report.

Yup. I absolutely would throw `#[from]` on everything when I started using thiserror, but now only do so in incredibly obvious cases like

  enum CarWontMove {
      EngineTroubles(EngineTroubles),
      WheelsFellOff(WheelsFellOff),
  }

Even then, there’s often some additional context you can affix at that higher level.

SNAFU follows much the same idea: we have an attribute you can add [0] when you want to allow directly implementing `From`. Like thiserror, you can also mark an error as transparent [1] when even the error existing doesn't provide useful information.

[0]: https://docs.rs/snafu/latest/snafu/derive.Snafu.html#disabli...

[1]: https://docs.rs/snafu/latest/snafu/derive.Snafu.html#delegat...

Anyone who needs to handle FFI in Rust, should read the FFI chapter in Rustonomicon: https://doc.rust-lang.org/nomicon/ffi.html

Unsafe Rust is indeed very hard to write correctly. Rustonomicon is a good start to learn unsafe Rust.

There was an NFT section in the claim form so certainly they are aware of but I'm not sure it's still open

The deadline has passed but the ftx site says:

>Can I still file a claim?

>The Kroll Portal will remain accessible after the Bar Date to amend or file a claim. Absent order from the U.S. Bankruptcy Court for the District of Delaware, any claims filed after the bar date may be disputed.

So it might still be worth filling out the form - who knows.