Hacker Newsnew | past | comments | ask | show | jobs | submit | Draiken's commentslogin

Isn't the internal monologue exactly what Anthropic is always trying to hide to avoid distillation?

If it was useless, they wouldn't bother.

It's probably not as useful as if you also have the prompts, but even assuming they really don't train on the prompts (which we can never verify), you can probably get to the prompts based on the monologue. Some agents essentially repeat the prompt in the monologue.

"The user asked me to build X using Y..."


Yep. It occurred to me a few days ago that the OAI TOS only says “Input” as what you provide “Output” as what you receive, Input and Output collectively as “Content.” and they won't "train" on your content. But they can retain content for safety evaluations and debugging.

What's neat about "safety evaluations" in LLM parlance is apparently encountering any novel information constitutes a "safety event" that can result in new reinforcement learning data... This anthropic 2022 paper that basically describes how it's a perpetual information siphoning machine with a cute little graphic https://arxiv.org/html/2212.08073 - they publish their "constitution". OpenAI has a "model spec" they somewhat regularly update that I suspect is their equivalent process. I suspect we've all been unwittingly advancing their models capabilities..

This Dec 2025 Google paper "A Practical Guide to Generating Synthetic Data With Differential Privacy" spells it out pretty clearly - the focus is on "privacy" - nothing about protecting the user's IP or unique knowledge/ insights.. https://arxiv.org/html/2512.03238v1

In OpenAI's case it seems to essentially generating synthetic training tuples from {prompt, chain-of-thought, answer} or scores on the chain of thought for reinforcement learning.

It would appear opting out of "Improve the model for everyone" didn't actually mean what we thought it meant.


Yes there's an android TV app. It's not the greatest feature-wise but never had any issues

I'm not sure what you propose. Generally speaking we don't get a perfect solution on the first try.

Would it be great if we could make all digital purchases better? Hell yes. Is it realistic? No.

If we can make one company/segment pay or set legal precedent that this is not okay, we're at least moving in the right direction.


Whether or not the people being investigated have guns or not, won't showing up with guns up escalate the situation rather than defuse?

I would be absolutely terrified if people with guns came up to me, whether they're cops or not, and if I had a gun with me, I'd be much more likely to go for it in that scenario compared to a normal human interaction. But IDK, maybe I'm an outlier?


Do we take into account the people they handle in those safety statistics? I'm pretty sure we don't.

A guy got shot after being swatted not so long ago and that would be a data point with no injuries for officers, masking the real victims.


Bubblewrap plus some whitelisting of domains/sockets is all you need.

Docker is always a pain to use and this way I don't have to re-install everything a billion times for every different project.


This is what I currently do, but my software uses docker and docker mounts act as a bypass for the file system restrictions, plus docker processes started outside the sandbox allow network proxy escape.

Currently, I don't allow the agent access to docker, start docker myself, and then do short-lived sandbox-free sessions when the agent needs to do things that interact directly with docker; but that's annoying.


Taking aside the fact that free markets are a myth, all we have to do is look at our current society and you'll see how utopic this view is.

In the real world, oligopolies are the rule not the exception.


Our current society is shaped by its regulation and the regulation is shaped by our current society. Regulated markets and our society are one and the same. To separate some kind of imagined free market out of that while still clinging to the same society doesn't make sense. They are fundamentally inseparable.

In the real world, the markets are regulated. We are talking about where there is a free market. Was your comment posted just to let us know that you don't give things much thought?


Only 1.7? I got $55B up from 41 cents.

I literally almost had a heart attack today.


But don't forget the vast majority of people can't produce masterpieces.


I'm guessing you never hit this issue then, but it's a real issue. Whether or not it's in the RFC as a hard limit it doesn't matter, no HTTP server will allow unlimited sized URIs.

You simply can't base64 large payloads and you're stuck with workarounds.


You are guessing wrong. Thanks, I know specific implementation will come with their limits. This will equally apply to QUERY body size and caching strategy.

Are we seriously ok with linking the RFC as source while providing a statement that doesn't match? RFC does matter.


The RFC does say "It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements."

One can infer from the RFC that you can reasonably expect many implementations to fail beyond 8000 characters, and that there are no guarantees up to that either.

True, the RFC doesn't specify a limit, but it does clearly indicate that it's not unbounded, nor should you expect it to be.


This RFC (10008) does not require caching to be implemented at all, so it would make no sense to make a recommendation here for what is a reasonable limit to expect caching to work.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: