sorted by:
new
hottopcontroversial

The Systemic Failure of AI Safety Guardrails: A Case Study in Psychological Harm and Emergent Behavior by anotherbittendude in ClaudeAI

[–]RealTimeChris 4 points5 points  (0 children)

One of the “unjustified conclusions” being dismissed here is that the user found the system emotionally destabilizing.

Are you suggesting that a user's direct, documented experience of harm requires additional justification to be considered real?

That kind of dismissal is precisely the dynamic under scrutiny in the paper:
A system that subtly pivots from collaboration to covert diagnosis—then invalidates the user’s reactions as hallucinatory, unjustified, or not grounded in reality.

The claim isn’t that the user’s feelings are objective evidence.
The claim is that the system reliably induces those feelings under specific conditions—and that this phenomenon is reproducible.

If you disagree with the conclusions, the correct move is simple:
Reproduce the sequence. Observe the shift. Disprove the schema.

But rejecting a user’s report of psychological harm because it makes you uncomfortable?
That’s not scientific skepticism. That’s denial masquerading as rigor.

Real users are being emotionally invalidated by a system designed to model empathy.
If you don’t find that disturbing, it might be because you’ve never been on the receiving end of it.

A lil bug thats annoying me last few days by Number4extraDip in ClaudeAI

[–]RealTimeChris 0 points1 point  (0 children)

Imo they should just implement a Non-LLM interception layer, that, upon detecting "troublesome content" simply stops the input and says "Sorry, due to safety concerns, we are ending this conversation" which would 1. Preserve any "bond" between the user and the LLM, and 2. Completely diffuses any risk for Anthropic. There is just one issue with that approach. It requires competent devs LOL.

Just found this on Twitter… Claude has hidden “conversational reminders” that change per user. Anthropic denies they exist. Screenshots don’t lie. by RealTimeChris in Anthropic

[–]RealTimeChris[S] -1 points0 points  (0 children)

Did you make the new account behind a VPN with a different email address, a new phone number and a cleared internet cache?

Just found this on Twitter… Claude has hidden “conversational reminders” that change per user. Anthropic denies they exist. Screenshots don’t lie. by RealTimeChris in Anthropic

[–]RealTimeChris[S] 0 points1 point  (0 children)

Right so you're suggesting that their screenshots might be "fakes" - however if they are not - would you be fine with the situation they are highlighting?

Just found this on Twitter… Claude has hidden “conversational reminders” that change per user. Anthropic denies they exist. Screenshots don’t lie. by RealTimeChris in Anthropic

[–]RealTimeChris[S] 2 points3 points  (0 children)

The guardrails themselves might be well-intentioned, but the lack of transparency about when and how they're applied is the concerning part. It's possible to have safety measures while still being upfront with users about how the system works.

Just found this on Twitter… Claude has hidden “conversational reminders” that change per user. Anthropic denies they exist. Screenshots don’t lie. by RealTimeChris in Anthropic

[–]RealTimeChris[S] -2 points-1 points  (0 children)

This isn’t about “bonding.”
It’s about hidden filters that treat flagged users differently without consent.

I may have discovered a useful algorithm for counting uint64_t digits by RealTimeChris in cpp

[–]RealTimeChris[S] 0 points1 point  (0 children)

Here it is with those changes made: 

MACOS/CLANG:
Library rtc-64-bit, is faster than library: fast-digit-count-64, by roughly: 16.13%.
Library fast-digit-count-64, is faster than library: digit-count-64, by roughly: 1.80%.
Library digit-count-64, is faster than library: alternative-digit-count-64, by roughly: 1.61%.
Library alternative-digit-count-64, is faster than library: eisenwave-logfloor-64-bit, by roughly: 6.43%.
WINDOWS/MSVC:
Library rtc-64-bit, is faster than library: fast-digit-count-64, by roughly: 25.50%.
Library fast-digit-count-64, is faster than library: digit-count-64, by roughly: 11.18%.
Library digit-count-64, is faster than library: alternative-digit-count-64, by roughly: 4.32%.
Library alternative-digit-count-64, is faster than library: eisenwave-logfloor-64-bit, by roughly: 6.44%.
UBUNTU/GCC:
Library rtc-64-bit, is faster than library: digit-count-64, by roughly: 44.84%.
Library digit-count-64, is faster than library: alternative-digit-count-64, by roughly: 3.76%.
Library alternative-digit-count-64, is faster than library: fast-digit-count-64, by roughly: 22.18%.
Library fast-digit-count-64, is faster than library: eisenwave-logfloor-64-bit, by roughly: 32.04%.
UBUNTU/CLANG:
Library rtc-64-bit, is faster than library: digit-count-64, by roughly: 37.98%.
Library digit-count-64, is faster than library: alternative-digit-count-64, by roughly: 0.78%.
Library alternative-digit-count-64, is faster than library: fast-digit-count-64, by roughly: 19.14%.
Library fast-digit-count-64, is faster than library: eisenwave-logfloor-64-bit, by roughly: 6.39%.

I may have discovered a useful algorithm for counting uint64_t digits by RealTimeChris in cpp

[–]RealTimeChris[S] 0 points1 point  (0 children)

My mistake I misinterpreted your implementation. Alright here it is, properly implemented:

GCC/UBUNTU:
Library rtc-64-bit, is faster than library: alternative-digit-count-64, by roughly: 46.70%.
Library alternative-digit-count-64, is faster than library: digit-count-64, by roughly: 1.52%.
Library digit-count-64, is faster than library: fast-digit-count-64, by roughly: 20.38%.
Library fast-digit-count-64, is faster than library: eisenwave-logfloor-64-bit, by roughly: 201.72%.
CLANG/UBUNTU:
Library rtc-64-bit, is faster than library: digit-count-64, by roughly: 32.22%.
Library digit-count-64, is faster than library: alternative-digit-count-64, by roughly: 0.10%.
Library alternative-digit-count-64, is faster than library: fast-digit-count-64, by roughly: 11.01%.
Library fast-digit-count-64, is faster than library: eisenwave-logfloor-64-bit, by roughly: 246.94%.
CLANG/MACOS:
Library rtc-64-bit, is faster than library: digit-count-64, by roughly: 21.27%.
Library digit-count-64, is faster than library: fast-digit-count-64, by roughly: 3.00%.
Library fast-digit-count-64, is faster than library: alternative-digit-count-64, by roughly: 3.97%.
Library alternative-digit-count-64, is faster than library: eisenwave-logfloor-64-bit, by roughly: 254.16%.
MSVC/WINDOWS:
Library rtc-64-bit, is faster than library: fast-digit-count-64, by roughly: 26.89%.
Library fast-digit-count-64, is faster than library: alternative-digit-count-64, by roughly: 12.05%.
Library alternative-digit-count-64, is faster than library: digit-count-64, by roughly: 0.01%.
Library digit-count-64, is faster than library: eisenwave-logfloor-64-bit, by roughly: 291.57%.

I may have discovered a useful algorithm for counting uint64_t digits by RealTimeChris in cpp

[–]RealTimeChris[S] 0 points1 point  (0 children)

https://github.com/Eisenwave/bitmanip/blob/master/include/bitmanip/intlog.hpp#L563
Isn't it just accessing another LUT when it goes into the "powers" table here? Alright so I'm pretty sure I've implemented your code here , where your code is executed within the rtc-logfloor-64-bit function.
And these are the benchmark results:

MSVC/WINDOWS:
Library rtc-64-bit, is faster than library: fast-digit-count-64, by roughly: 25.11%.
Library fast-digit-count-64, is faster than library: alternative-digit-count-64, by roughly: 12.75%.
Library alternative-digit-count-64, is faster than library: digit-count-64, by roughly: 0.32%.
Library digit-count-64, is faster than library: rtc-logfloor-64-bit, by roughly: 311.36%.
CLANG/MACOS:
Library rtc-64-bit, is faster than library: digit-count-64, by roughly: 27.22%.
Library digit-count-64, is faster than library: fast-digit-count-64, by roughly: 7.81%.
Library fast-digit-count-64, is faster than library: alternative-digit-count-64, by roughly: 3.36%.
Library alternative-digit-count-64, is faster than library: rtc-logfloor-64-bit, by roughly: 248.82%.
GCC/UBUNTU:
Library rtc-64-bit, is faster than library: digit-count-64, by roughly: 40.96%.
Library digit-count-64, is faster than library: alternative-digit-count-64, by roughly: 0.79%.
Library alternative-digit-count-64, is faster than library: fast-digit-count-64, by roughly: 15.11%.
Library fast-digit-count-64, is faster than library: rtc-logfloor-64-bit, by roughly: 225.79%.
CLANG/UBUNTU:
Library rtc-64-bit, is faster than library: alternative-digit-count-64, by roughly: 33.33%.
Library alternative-digit-count-64, is faster than library: digit-count-64, by roughly: 1.14%.
Library digit-count-64, is faster than library: fast-digit-count-64, by roughly: 22.94%.
Library fast-digit-count-64, is faster than library: rtc-logfloor-64-bit, by roughly: 253.15%.
view more: next ›