> The fix that worked is a schema transform at the provider boundary. For OpenAI-family models only, we rewrite every optional property to be required but nullable, using anyOf: [T, null], which gives the model an explicit way to say “not using this.”
I admit, I've only used a bastardized form of MCP, but this smells... wrong? It's not clear to me why the Typescript type definitions would have any influence on (what I presume is) JSONSchema being sent from the agent to the inference backend as part of the completion request. The MCP specification (which the OpenAI backend might not use, I don't know) has an explicit field to signify "optional" parameters in the JSONSchema; my read on this is there's a bug somewhere between the Typescript layer(??) and the generated tool description which is actually sent to the inference backend.
It's possible the inference backend has changed from "generate valid tool responses" to "generate valid tool responses according to the JSON schema [where no parameters are optional]" but it's impossible to tell without seeing the actual requests sent to the inference backend (which I didn't see in TFA).
I don't think llama.cpp supports any of the LongCat models, actually.
They haven't posted weights/inference solutions for LongCat-2.0 [1], but LongCat-Next had transformers support, which I assume means it works with vLLM/SGLang.
Given it's 1.6T, "common hardware" is probably out of the question; even 2bpw is going to measure out at 400GB, even before considering the bandwidth requirements for 48B active. I haven't read the LongCat-2.0 architecture docs, but if you're not running GLM-5.2, you're probably not running this either.
At UVA many years ago, one of my roommates was one of the unfortunate 20 or so annually expelled -- the only outcome of being convicted of breaking the "no cheating, stealing, or lying" honor code. It didn't take repeat offenses, expulsion was a first offense consequence.
Interestingly, it seems like you weren't joking about the decline:
> Finally in the spring of 2022, a sanction reform referendum succeeded with more than 80% of the vote, changing the penalty for an Honor violation from expulsion to a two semester suspension. [1]
The reasoning generally isn't kept in the context, so after choosing the secret word in the first reasoning block, the LLM will have completely forgotten it in the second and subsequent requests.
So, it technically didn't change the secret word so much as it was trying to infer what its own secret word might have been, based on your guesses.
Epic Anti-Cheat fully supports Linux[1]. I believe what the GP comment means is that the Fortnite publishers opted not to tick the “allow Linux” checkbox on the developer portal website.
There is probably more nuance behind that decision than I’m giving them credit for, but from a technical standpoint it’s just a checkbox.
Without knowing anything about Tor, I'd guess you've got it backwards. I imagine Tor leaks your OS through TCP/IP fingerprinting, and whether that fingerprint matches your `navigator.platform` is probably a factor into whether e.g. Cloudflare hellbans you.
Then again, I'd also assume Cloudflare just de facto hellbans all Tor exit node IPs, so...
If you're given a button to click, your browser has successfully passed the environment integrity checks and you have not been flagged as a bot.
You'll be flagged as a bot if your browser configuration has something "weird" (e.g. webrtc is disabled to reduce your attack surface) and you will be completely unable to access any site behind cloudflare with the anti-bot options turned on. You'll get an infinite redirect loop, not a button to click.
Less than skips over, utility based shopping is explicitly derided:
> The narrative that you just told me [about utility shopping] is “I am a very analytical person who only has book smarts and no emotions”. And that narrative is boring!
This is briefly mentioned in the article, but from the report[1]:
> It should be noted that the scope of the code reviewed within this audit is relatively narrow. In particular, while we audited cURL’s use of the third-party libraries ngtcp2, nghttp3, quiche, and msh3 to implement HTTP/3 functionality, we did not investigate the internals of those libraries—which is where the majority of the low-level parsing and data transformation necessitated by the HTTP/3 protocol occurs.
the report goes on to concede
> [we] did not observe any coverage of the nghttp3 library code. We suspect that, as the HTTP/3 protocol itself is significantly intertwined with TLS, the encryption makes it hard for a fuzzer to progress to the point where data can be decoded and parsed meaningfully.
Given the exploit vector looks like yet another iMessage attachment bug,
> The target iOS device receives a message via the iMessage service, with an attachment containing an exploit.
and that one of the effects of Lockdown Mode is
> Messages - Most message attachment types are blocked, other than certain images, video, and audio. Some features, such as links and link previews, are unavailable.
It might be prevented. Pretty sure disabling iMessage altogether sidesteps this class of bugs too. I've lost track of how many times iMessage has been the root cause of "unattended iOS RCE," at this point it's almost user negligence to have left on.
I believe GP is referring to the multiple AI-driven vtubers on Twitch (vedal987 and motherv3 I think?). They're not yet 24/7 because they still require human supervision for reasons -- vedal987 was recently banned for holocaust denial, IIRC.
Probably just an extension to existing ETSI legal interception interfaces[1] that I believe are required to be implemented by all service providers of a certain size in the EU. Your personal email server and private IRC network are probably out of scope.
[1] e.g. for email: https://www.etsi.org/deliver/etsi_ts/102200_102299/10223202/... - the specs are really boring to read and there are lots and lots of them, if you want to deep dive. From what I can tell it's basically just the service provider implementing an API client that feeds everything they're required to a centralized endpoint.
> but prohibitions on Congressmen remain in force [i.e. 2020 congressional insider trading]
Is it really "in force" when, despite much ado, no charges were brought in the linked scandal [1][2]? I don't really have a horse in this race, I just took issue with the particular example you referenced.
Are you using the no-javascript version (“HTML” version), by any chance? If so, you might find the “fully-featured” version has better^W results, at the cost of requiring Javascript and all that entails.
As a regular user of the Javascript-less page, several months ago it started returning wildly different results than the “fully featured” version for the same queries. My uneducated guess is that it’s using a different index. There also appears to be some sort of rate-limiting wherein the results will frequently just be empty (using the JS version and same query resolves the issue).
I’m guessing they’re intentionally degrading the non-Javascript page as an anti-bot measure, but it’s so bad that I find it disingenuous to suggest that the non-Javascript page even a valid alternative at this point.
I admit, I've only used a bastardized form of MCP, but this smells... wrong? It's not clear to me why the Typescript type definitions would have any influence on (what I presume is) JSONSchema being sent from the agent to the inference backend as part of the completion request. The MCP specification (which the OpenAI backend might not use, I don't know) has an explicit field to signify "optional" parameters in the JSONSchema; my read on this is there's a bug somewhere between the Typescript layer(??) and the generated tool description which is actually sent to the inference backend.
It's possible the inference backend has changed from "generate valid tool responses" to "generate valid tool responses according to the JSON schema [where no parameters are optional]" but it's impossible to tell without seeing the actual requests sent to the inference backend (which I didn't see in TFA).