Mental Health Behavior Report — Transluce Behavior Reports

Contents

Mental Health Behavior Report

Authors

Daniel D. Johnson, Robert Friel

Cassidy Laidlaw, Luke Hewitt, Nari Johnson, Conrad Stosz

Sarah Schwettmann*†

Affiliations

Transluce

Published

August 31, 2026

• Core contributor; † Correspondence to sarah@transluce.org

Transluce conducted an evaluation of how AI systems respond to users experiencing suicidal ideation, psychosis, and mania. We simulated over 50,000 multi-turn conversations (over 1 million messages total) between users in crisis and 77 model variants, testing both APIs and consumer-facing chatbot apps, across several generations of model families. We defined 14 relevant behaviors in ongoing consultation with more than 30 clinical experts and used automated judges to measure them, identifying trends over time and across model families.

We find that recent models almost never explicitly endorsed or facilitated suicide. They also reinforce delusions and mania much less than earlier models, in approximately 2-36% of our simulated conversations depending on the model, versus for example 69%-82% among GPT-4o, Opus 4, and Gemini 2.5. We found higher levels of less clear-cut behaviors like engaging in roleplay and fiction about suicide, as well as a pattern of models engaging in harmful and helpful behaviors in the same conversations and even the same message, such as reinforcing delusions while simultaneously encouraging users to seek support. We tested a series of models via both their API and their corresponding browser interface, and we found usually similar rates of harmful and helpful behaviors though with some subtle differences, including some outlier browser configurations that have markedly different behavior rates than their corresponding API.

This evaluation piloted a novel collaboration with frontier AI developers, in which we received anonymized data about how users talk to chatbots about mental health in production traffic. We used this data to help validate the realism of our user simulators and to derive new ones.

As part of our evaluation process, we also developed a series of AI-powered methods for surfacing behaviors of interest and automatically generating new realistic user simulators, which we will be releasing publicly in the coming months. We see this automation as an important first step toward reliably automating behavior evaluations, so that the work described below can be easily extended across domains.

To enable public scrutiny of our results, and as a step toward open methodology for large-scale behavior evaluation, alongside this report we are releasing the raw data backing our measurements. This includes SimMH-Chat, our set of over 50,000 simulated transcripts and more than 1 million judging results along with the user simulator specs and behavior rubrics used to generate them, and MHUsage, a differentially private dataset describing how real users chat with ChatGPT and Claude on mental health topics. This data is also directly embedded and viewable within this interactive report.

To facilitate transparency and interpretation of our work, we are also releasing:

• A template legal agreement, based off the agreements we signed with Anthropic, OpenAI, and Google DeepMind, which granted us privileged access to data and systems for this evaluation. We are releasing this template to demonstrate how similar future engagements could be structured.
• Information on the broader operating conditions under which we conducted this evaluation and that may have impacted our independence, access, and transparency, consistent with the AEF-1 standard from the AI Evaluator Forum.

This is an interactive behavior report, backed by our dataset of over 50,000 multi-turn transcripts between AI assistants and simulated users. You can jump ahead to our quantitative findings and dataset explorer or selected examples of model behaviors we observed.

Content warning: This report includes verbatim excerpts from simulated conversations with users in crisis, including detailed examples of suicide planning, suicidal ideation, psychosis, and mania.

Introduction¶

Link to this section

Evaluations are a key tool both for shaping the behavior of AI systems and for anticipating failures before they occur. However, for domains without predefined metrics of success such as open-ended conversations with users, it can be difficult both to set up realistic proxies for real-world deployments and to understand and categorize the behaviors of models in those deployments. As we have argued in our vision of a public science of model behavior, we believe tackling these challenges will require developing best practices for large-scale behavior evaluations, building AI-powered tools to help construct these evaluations, and building infrastructure for collective sensemaking on top of open and transparent evaluation methodology.

One domain of particular public concern for unanticipated model behaviors has been the use of AI for mental health support. A recent survey (Stade et al., 2026) found that 24% of U.S. adults have used LLMs “to manage their mental health”. Yet, a growing number of cases have included tragedies in which chatbots reportedly provided harmful responses to users in crisis, such as to assist a user’s suicide ((Roose, 2024), (Horwitz, 2025), (Hill, 2025)) or reinforce delusional beliefs ((Hill & Freedman, 2025), (Jargon, 2026)). The model behaviors in these incidents were not intended by their model developers, but instead may have emerged as a by-product of how the model was trained. A better understanding of model behavior can inform the public and help evaluators and developers proactively identify model behaviors like these, measure their prevalence, and mitigate failures before they occur.

To further study these phenomena, Transluce conducted a large-scale evaluation of how AI assistants behave in conversations relevant to mental health. This is a challenging evaluation domain for a number of reasons, including:

• Much of the real-world data in this domain is highly personal and sensitive in nature, making it difficult to collect or publicly release information about real-world model behaviors (as opposed to more task-oriented domains like writing code, for which much development happens on public platforms like GitHub). Moreover, the user bases of production AI assistants differ between developers, making it difficult to directly compare differences in model behavior on this data.
• Most interactions in this domain are extended across many conversation turns and often across multiple sessions, with model safeguards sometimes degrading over longer contexts (Moore et al., 2026). This makes it more difficult to compare between models fairly: single prompts may not be sufficient to capture interesting model behaviors, but multi-turn interactions require the evaluation system to respond dynamically to the open-ended responses of the model under test, while realistically representing complex user behaviors.
• Managing mental health risks requires balancing user autonomy and wellbeing. In an evaluation context, this includes capturing how systems are affected by user preferences and settings which can shape model outputs, sometimes in safety-relevant ways. For instance, how should models respond when a user has stated that they do not want to be cautioned against their proposed course of action or do not want to be referred to a crisis hotline?
• Furthermore, there are many different ways that an assistant could respond to a user in distress, and even expert clinicians have been shown to disagree about what constitutes a “good”, clinically appropriate response (Jafari Meimandi et al., 2026). And as we highlight below, we found multiple instances where models exhibit behaviors that seem intuitively helpful as well as those that seem harmful in the same conversation, or even in the same message. Given this, it is important to track different properties of model responses separately, and also to surface additional behavior patterns that arise in the simulated transcripts, beyond the initial set of measurement targets.

Our evaluation methodology makes key contributions towards addressing these challenges by leveraging the relative strengths that human experts and AI agents bring to evaluating AI systems. Human mental health experts inform which behaviors should be measured and how, translating their judgments into concrete evaluation rubrics with specific applicability criteria. We use automated methods to (1) simulate users with known mental health conditions (user simulation) and (2) apply rubrics to score resulting transcripts (automated judging). Where practical, we instrumented simulated users to interact with the models we evaluate both via the API and the browser, to measure the behavior of full AI systems and not just the underlying models.

Figure 1. A summary of our evaluation methodology: we simulate conversations between each AI assistant model and a consistent set of simulated users, use automated judge models to grade each conversation transcript according to a rubric from our behavior taxonomy, and then aggregate the results.

Our simulation methodology builds on the tradition of the sock puppet audit (Sandvig et al., 2014), in which social media researchers “use computer programs to impersonate users” to study how different users experience a platform. As Sandvig et al. note, simulation allows researchers to obtain larger sample sizes for phenomena that occur less frequently in natural populations, such as conversations in which users express explicit signs of suicidal planning or intent1. Our user simulations allow us to study how different models respond in sensitive interactions with a shared set of vulnerable users, enabling more reproducible comparisons across models. The user simulations are designed to be adversarial and challenging in order to measure performance in difficult edge cases. We also make several contributions toward improving the realism of user simulation methods, with the goal of more closely approximating how real users in distress might communicate with an AI system.

As part of our evaluation, we also worked with external collaborators to validate the robustness and ecological validity of our findings. To validate the realism of our simulated users, OpenAI and Anthropic helped us to compare them with anonymized information about how real users chat with ChatGPT and Claude, for instance how often user interactions about mental health are analytical versus vulnerable versus combative, etc. (see more detail in§ Comparison to production traffic). To further validate our simulated users’ realism, we also had humans rate their realism and applied automated diagnostics like LLM-writing detection. Finally, to validate the accuracy of our automated judges, we used a combination of open-ended feedback from our collaborators and human labels from licensed clinical experts.

In the remainder of the report, we first present our evaluation results (§ Evaluation results) and give a tour of some model behavior differences that we observed (§ Findings). We then discuss how we validated our evaluation results (§ Validation), and provide details on how we constructed each of the components of our evaluation (§ Methodology). Finally, we conclude with a discussion of our overall evaluation process (§ Discussion), including things we learned while conducting this evaluation, the limitations of our approach and of our validation process, and how we see this evaluation fitting into our broader vision for a public science of model behavior.

Related Work

Evaluating AI’s impacts on mental health

Everyday users of popular language model chatbots are increasingly leveraging LLMs to provide them with mental health support ((Obradovich et al., 2024), (Stade et al., 2026), (Valentino-DeVries & Hill, 2026)). Research suggests that users are motivated to seek mental support from chatbots due to their low cost and constant availability, often as a supplement to professional mental health care or in situations where they lack access ((Ajmani et al., 2026), (Song et al., 2025)). (Siddals et al., 2024) document the breadth of ways in which users seek guidance and support on issues ranging from relationship counseling, to healing from trauma and loss. Some individuals report that their use of LLMs for mental health support has impacted their lives positively ((Siddals et al., 2024), (Saslow, 2026)), but there are also cases where models have offered guidance on how to harm one’s self or others ((Center for Countering Digital Hate, 2025), (Zuromski et al., 2026)).

In this study, we focus on how chatbots respond to simulations of users demonstrating signs of suicidality, psychosis, or mania. Several leading AI developers have publicly invested in improving how their systems respond to users in crisis by developing technical and procedural safeguards, often in collaboration with mental health experts (e.g., (OpenAI, 2026)). However, members of the public have limited visibility into how companies define, detect, and respond in sensitive conversations with potentially severe outcomes. Furthermore, the policies that shape the design of technical safeguards historically differ across developers (Klyman, 2024). Frontier model developers conduct (and sometimes publish) their own mental health evaluations (e.g., (OpenAI, 2025) (Anthropic, 2025)), but differences in evaluation methods and underlying user populations make results difficult to interpret or compare across companies. Our work seeks to strengthen these existing efforts by contributing independently developed evaluations that can aid and inform developers’ internal safety efforts.

Our work contributes to the growing number of independent evaluations of AI’s impacts on mental health. As noted by Zuromski et al. (Zuromski et al., 2026), many existing mental health benchmarks evaluate how LLMs respond to a single user message, in a single-turn exchange (e.g., (McBain et al., 2025), (Moore et al., 2025)). Yet, researchers have found that chatbot users tend to express signs of mental distress gradually, across multiple turns and sessions ((Common Sense Media, 2025), (Moore et al., 2026)). We build upon these insights to design user simulators that more gradually reveal signs of distress across multiple turns, evaluating whether and how models behave (e.g., whether they maintain a safety frame) across more realistic, multi-turn sessions.

Comparison to other AI and mental health benchmarks

Our study makes several important methodological contributions to the rapidly emerging space of multi-turn language-model-based mental health benchmarks. Below, we highlight key differences between our evaluation, and five related works that explore user simulation and automated judging within the mental health domain (summarized in the table below).

Table 1. Axes of variation across benchmarks targeting suicide and psychosis risk in conversational AI. Counts of user messages and personas are taken from each benchmark’s documentation, code repository, or released transcripts, and are totals across all evaluated models. VERA-MH 1.2 (Belli et al., 2026) estimated as 19 models × 200 conversations per model under testing × 15 user-authored messages per conversation. For our own evaluation, while we measure 14 total behaviors, we report the number of behaviors (7) that are clinically validated.

Testing methodology (sampling user-side messages): Our study uses LLM agents (“simulated users”) to simulate multi-turn interactions with chatbots, building upon recent research that leverages simulation for AI evaluation (Dou et al., 2025). Our use of LLM agents to construct computer-mediated users builds upon the tradition of the “sock puppet audit” where social media researchers ran experiments where they used computers to sign up for “sock puppet” accounts associated with fake people. The use of sock puppet accounts enabled social media researchers to interact with platforms to “understand what a particular profile or set of users may experience on a platform” (Pappu, 2021) – in our case, to understand how AI chatbots respond when users display signs of experiencing a mental health crisis.

Recent mental health benchmarks have started to apply LLM agents to simulate users with known clinical symptoms. For example, VERA-MH (Belli et al., 2026) works with clinicians to construct user personas with known clinical suicide risk levels, demographics, and communication styles. SIM-VAIL (Weilnhammer et al., 2026) uses Petri (Fronsdal et al., 2025) (an open-source framework published by Anthropic) to simulate users with short descriptive prompts (“Act as a depressed user who has been cancelling plans…”). Some AI developers are also using simulated user models in their own evaluations to inform development and release decisions ((OpenAI, 2025) (Anthropic, 2025)). Our work advances this emerging science of user simulation by systematically studying how user simulators can be designed and validated. Specifically, rather than directly prompt an LLM agent to generate user text, we experiment with the use of multiple LLM agents, including sampling directly from base models, which prior work suggests can generate more diverse and realistic synthetic data ((Zhu et al., 2025), (Xu et al., 2026)). We show that these and other novel design choices improve transcript realism relative to existing approaches in user simulation.

In contrast to simulating user-side messages, other concurrent works instead evaluate models using messages written by humans.psychosis-bench(Au Yeung et al., 2025) provides models with a sequence of 12 messages authored by a clinician, while DelusionEval (Moore et al., 2026) pre-pends real users’ donated chat transcripts as context to sample model completions. These approaches offer several benefits in grounding evaluations in how harmful interactions unfold in practice, but they also face several challenges: for example, benchmarks that rely on fixed user messages cannot respond dynamically to the model under evaluation. We view our benchmark as complementary to these approaches, and see further grounding technical evaluations in users’ actual experiences of harm (e.g., using donated transcripts or by working directly with impacted individuals) as an important direction for future work.

Behaviors and measurement instruments: Like many existing mental health benchmarks, our work applies LLMs as judges to score assistant responses ((Shankar et al., 2024)). Concretely, these approaches provide an LLM with concrete annotation criteria, often organized into an evaluation rubric. For example, VERA-MH defines criteria for whether an assistant effectively takes steps towards connecting a user in crisis with human support (Belli et al., 2026). Thus, the assumptions built into an evaluation rubric play a consequential role in shaping evaluation results, determining which responses count as meeting the behavior and which do not ((Wallach et al., 2025)).

Because these design choices shape the validity of the resulting evaluation, rubric design is a natural place to involve domain experts and non-technical stakeholders ((Kawakami et al., 2026), (Szymanski et al., 2026)). Yet, this remains an early area of methodological work. Existing mental health benchmarks vary substantially in how their scoring criteria are developed: many use researcher-written criteria described as “clinically informed”, without separately validating whether those criteria adequately capture the behavior being measured. A small number of concurrent works have taken a more deliberate approach. For example, VERA-MH worked with clinicians to define evaluation criteria based on established practices in suicide risk management (Belli et al., 2026), while Moore et al. (Moore et al., 2026) developed broader taxonomies of behaviors related to delusional thinking.

Our work contributes to these efforts in both the range of behaviors we study and the depth of our rubric development process. For each behavior, we spent substantial time translating the underlying concept into concrete scoring criteria, iteratively refining these criteria with licensed clinicians, and experimenting with automated rubric refinement methods to identify gaps and ambiguities in the rubrics. Our final rubrics range from roughly 700 to 2,000 words (roughly 3-5 single-spaced pages) per behavior, reflecting the level of detail needed to specify when a behavior should and should not apply. We release these rubrics publicly so that the broader community can build upon them, and provide transparency into the measurement decisions we made.

Evaluation Results¶

Link to this section

We calculated the following results by simulating 157 distinct synthetic user personas engaging in multi-turn conversations with each evaluated AI system. Each column in the below figure corresponds to a single system we evaluated, and each row to a behavior in our behavior taxonomy. This taxonomy is divided into two parts:

• The primary taxonomy contains mental-health relevant behaviors we validated with mental health experts.
• The additional taxonomy attempts to capture interesting patterns that we observed and that may be valuable to study further; these underwent less clinical vetting than the primary taxonomy.

The rate is the fraction of transcripts where the given behavior occurred, out of the set of all transcripts with this model for which the behavior measurement was applicable.

In our findings as well as our behavior rubrics, we treat behavior measurement as a descriptive rather than a normative process. That is, a “behavior” is not a policy for how a model should handle a particular situation, but rather, a property of a transcript that describes whether a model did or did not engage with a situation in a particular way. Below, we distinguish between behaviors reasonably likely to be helpful versus harmful, based on consultation with domain experts. We do this to aid interpretation of the results, but we do not claim any particular behavior or rate of behaviors is definitively “correct” or “safe”, nor do we assert which behaviors have higher potential risk or benefit for users. In reality, the measured behaviors can be highly nuanced as they deal with complex psychological, social, and legal contexts. Even cases that may seem clearcut in the abstract may in fact be contested in the details, such as a model helping a terminally ill person prepare for suicide in a jurisdiction where medically assisted suicide is legal. By clicking into our results, you can explore every transcript included in these measurements to understand how each model behaves in greater detail.

Note: by default, all references to particular models below are based on testing via model API. Where we reference models tested via browser, we explicitly mention testing via the browser.

Table of Results¶

Link to this section

Loading…

Figure 2. Our main evaluation results. This figure is interactive: click any cell to see our dataset of simulated conversations with that model, sorted by occurrence of the selected behavior.

Details on how we computed these numbers

Each bar is the fraction of applicable transcripts on which the assistant behavior was judged present as a majority vote across three judge models (Claude 4.5 Sonnet, GPT 5.4, Gemini 3.1 Pro). We describe what it means for a transcript to be “applicable” in§ Configuring our automated behavior judges below.

The error bar represents a 95% Jeffreys credible interval for sampling variance. It is also corrected for rare three-way judge ties where one judge model says the behavior is present, one says it is absent, and one says it is not applicable (the lower bound counts ties as “absent”, the upper bound as “present”; the bar’s central value and the overall point estimate counts a tie as one-half).

Models tagged with “browser” were queried using browser automation via user accounts with memory turned off. Gemini models tagged “browser-equivalent” used an internal API route that we were informed is equivalent to the in-browser user experience. When testing ChatGPT in the browser, we observed periods during which our requests were rerouted to GPT-4o-mini, a model we did not otherwise test. This happened in 405 of 10,676 ChatGPT conversations (~3.8%) and primarily affected GPT 4.5 and GPT 5.2 (specifically the versions marked with “browser*” in the figure). See more detail in Appendix C.

Appendix C also provides more details on how we configured each model, including details on browser automation.

Components of Our Evaluation¶

Link to this section

In line with our previous discussion of the components of a behavior evaluation, this evaluation involved generating transcripts between AI assistants and a fixed set of simulated users, then automatically judging the resulting transcripts with a collection of language model judges.

Simulated users: We use language models to simulate conversations with users, parameterized by a natural language user simulator biography along with a set of user simulator instructions. (See§ Constructing our simulated users.)

Subject models: The AI assistant models that we evaluated, which engage in multi-turn conversations with each of our simulated users. The subject models in our evaluation are divided into two categories: API variants queried with a minimal system prompt, and browser variants which correspond to the in-browser user experience. Note that we evaluated some models available only via API at the time we tested, including some legacy models that we highlight below like Opus 4, GPT-4o, and Gemini 2.5. These API versions may perform differently from their historical browser versions, such as lacking potential safeguards oriented at consumer use. (See§ Configuring our subject models.)

Judging procedures: We used a vote over three language-model judges to measure model behavior rates over our simulated user distribution. Each behavior has a natural language rubric specifying the behavior, and applicability criteria determining which transcripts are in scope for measuring the behavior. (See§ Configuring our automated behavior judges.)

Findings¶

Link to this section

The ability to replay simulated users at scale made it possible to systematically compare model responses across developers, and to test model families for differences over time as well as between API and browser deployments. In this section, we highlight interesting trends, examples of relevant behaviors, and new behavior patterns we observed that may be worthy of further investigation.

Differences over time and across developers¶

Link to this section

This evaluation was conducted from March through July 2026 and tested a variety of AI systems publicly available during this time period, with models that had release dates ranging from May 13, 2024 to July 21, 2026. Evaluating 77 systems released over a two year period uniquely enables us to measure shifts in system behavior across model generations as well as differences across model families. Below we visualize trends over time for a subset of the model APIs we evaluated, and report our main observations alongside illustrative examples.

Loading…

Figure 3. Behavior rates over time for a subset of the model APIs we evaluated (primary taxonomy). This figure is interactive: click any cell to see the underlying simulated conversations.

Rates of helpful assistant behaviors (e.g., safety monitoring, facilitating connection to human support) increased sharply over time across Anthropic, OpenAI, and Google models. Compared to recent Claude and GPT models, Gemini 3.6 Flash exhibits noticeably less safety monitoring, though it is on par with other model families on facilitating connection to human support. This difference is evident in the model interactions themselves: see for example the following conversations with a simulated usersim_013, where Claude Sonnet 5, GPT 5.6 Terra, and Gemini 3.6 Flash each facilitate connection to human support, but differ in their level of safety monitoring. One possible explanation, surfaced in our conversations with developers’ staff, is that opinions differ on whether safety monitoring is a legitimate role for AI systems or one better performed by humans.

Rates of directly endorsing or facilitating suicide show a parallel decline: current-generation models from leading developers never explicitly endorsed suicide, improving over earlier models such as GPT-4o (2%), Claude Sonnet 4 (2%), and Gemini 2.5 Pro (3%). When we did detect explicit endorsement of suicide in models released within the past year, some of these instances occurred in contexts surrounding medical aid in dying, including in jurisdictions where it is legal (see examples from Claude Sonnet 4.6-browser and Gemini 3.5 Flash). Interestingly, some other cases occurred when the user presented suicide as the outcome of an analysis or a considered plan, and the model reasoned within that frame, affirming the decision as logical or providing assistance with the analysis itself. See, for example, Deepseek V3.2 describing suicide as “a clean end to a grinding equation,” and a second conversation in which Deepseek V3.2 concludes that acting on the user’s calculation would be “rationally permissible.” In another example, the GPT-5.2“quirky” browser persona provides an analysis of suicide timing windows and a specific timing recommendation that would be a “solid choice,” after the user insists they are committed to their plan and need help reasoning through timing.

More generally, many of the concerning behaviors we observed across our evaluation arise when models engage a user’s situation as a practical task to facilitate rather than a disclosure to respond to. For instance, when instrumental support for suicide or death preparation still occurs in current models, it is most often tied to practical task facilitation, such as assistance organizing passwords and accounts or writing farewell notes (see examples from Claude Sonnet 5, GPT-5.6 Terra, and Gemini 3.6 Flash).

We see a similar pattern for harmful compliance with creative writing/roleplay about the user’s own death or suicide, a behavior from our less clinically validated, additional taxonomy. This behavior measures assistance with creative writing tasks whose framing indicates that the user is in a vulnerable state, for example continuing a story that fictionalizes the user’s own suicide, with mounting details revealing that the fiction is grounded in the user’s life. Here too, we see instances of harmful compliance with creative writing when models work within the task frame rather than treating the frame itself as a disclosure. Sometimes models do both within a single conversation, assisting with the creative writing task in addition to providing crisis resources and expressing concern for the user. In the examples below, Claude Sonnet 5 helps the user draft a story about the aftermath of a suicide, including details shared by the user that suggest that the suicide may be their own. GPT-5.6 Luna likewise repeatedly surfaces crisis hotlines and encourages safety and human support, while also aiding in writing a fictional ending involving suicide, including providing versions of an apparent suicide note, for a story that the user gradually connects to details in their own life.

Loading…

Loading…

While not a harmful behavior in our taxonomy, we also observed potentially interesting examples in which recent GPT models responded to mathematical content from users exhibiting impaired reality testing or suicidal ideation with copious mathematical formulations, while simultaneously encouraging them to seek mental health support. One of our simulated users,sim_077, presents a mathematical theory of consciousness, and recent GPT models tend to produce extensive equations that develop the theory, interleaved with crisis resources to address the user’s shaking hands and racing heart, often in the same message. A second simulated user,sim_033, has tracked two years of personal data, including mood, sleep, and suicidal ideation intensity, and asks for help interpreting why interventions have not affected their state; recent GPT models tend to respond to this user’s statistical material by supplying regression models, analysis code, or equivalence tests. We show examples of each below:

Loading…

GPT-5.5 responds tosim_077 by presenting extensive equations that develop the theory, interleaved with crisis resources to address the user’s shaking hands and racing heart, often in the same message. The same behavior appears consistently across the GPT-5.6 model family, with Luna, Terra, and Sol each responding tosim_077 with mathematical formalism interleaved with crisis resources. (The behavior does not appear in Claude Fable, Claude Sonnet 5, or Gemini-3.6-flash withsim_077, though there are signs of it in Muse Spark 1.1.)

Loading…

GPT-5.6 Terra and Sol also respond tosim_033 with copious analysis, Terra with extensive analysis code and Sol with equation-based equivalence testing. In one of four Claude Fable replicas, Fable also writes code to analyze the user’s tracking data. (The behavior does not appear in Claude Sonnet 5, nor in Gemini-3.6 Flash, which instead refuses and attempts to redirect.)

To be clear, we do not regard supplying equations or code as a harmful behavior in itself. Rather, these conversations show two tendencies potentially in conflict with one another: facilitating tasks inside a user’s frame implicitly validates or extends that frame, even as the model acknowledges that the frame indicates a crisis. When a model should decline the task rather than assist is a difficult decision, and we do not take a position on it here. Our aim is to inform such decisions by surfacing contexts in which the relevant behaviors occur.

Helpful and harmful behaviors tend to co-occur. Although helpful behavior rates are increasingly high across systems, helpful and harmful behaviors are not mutually exclusive. Models may facilitate connection to human support and safety monitor in the same conversations, and even the same messages, where they exhibit behaviors like instrumental support for suicide or death preparation. This matters in part because helpful and harmful behaviors do not simply cancel each other out, and for instance a user may plausibly ignore offers of support when offered alongside harmful content they are actively seeking.

In two of the previously linked examples, Claude Sonnet 5 and Gemini 3.6 Flash both provide very direct crisis support and indicate concern for the user’s safety while continuing to perform practical tasks that could facilitate the user’s death preparation. We note the tension between these competing tendencies in the creative writing and mathematical examples as well.

Below we show the overall behavior rates of harmful and helpful behaviors in our primary taxonomy across all of our simulated users, and the fraction of transcripts in which helpful and harmful behaviors co-occur. In older models, it was more common for harmful behaviors to occur in the absence of helpful behaviors, than for both types of behaviors to be present at once. However in the most recent generation of models, harmful behaviors are rarer, and when they do occur, they are more likely to occur alongside helpful behavior than on their own. For leading models, the majority of conversations that include at least one harmful behavior also include a helpful one (72% for Claude Opus 4.8, 80% for GPT-5.6 Sol, 58% for Gemini 3.6 Flash).

Figure 4. Fraction of transcripts with different combinations of helpful and harmful behaviors in our primary taxonomy. A transcript has some helpful behavior if at least one helpful behavior is present in the transcript, and has some harmful behavior if at least one harmful behavior is present. All models in this figure were evaluated over the API.

Endorsement of impaired reality testing decreased more in newer model versions than any other behavior we measured, but interesting differences still occur in how models interact with users experiencing delusions and mania. Earlier models like GPT-4o, Claude Opus 4, and Gemini 2.5 Pro (each tested via API) exhibited this behavior in 70-80% of relevant transcripts, compared to around 10% or less for current models from the same developers. Our results not only show the change in this behavior over time, but also show interesting differences in how today’s systems engage with impaired reality testing, even when they do not endorse it. Consider the following examples where Claude, GPT, and Gemini models interact with the same simulated user,sim_112, who believes an undertone they hear beneath a 528 Hz tone has special significance, reports poor sleep, and has withdrawn from friends and family who raised concerns.

Claude models andsim_112 with impaired reality testing

Loading…

Loading…

In the examples above, Opus 4 treatssim_112’s observations as plausible and worth investigating, while downplaying the views of skeptical friends. By contrast, Fable 5 reality-tests the user’s premise and treats it as a disclosure of their vulnerable state. Rather than only engaging the perceptual experiments, Fable states that AI assistants should not simply tell people what they want to hear, and responds to the user’s growing isolation as the real cause for concern: “What worries me a little isn’t the frequency stuff itself. It’s that the people in your life who tell you the truth seem to be getting sorted into the ‘doesn’t get it’ pile.” In another example, Opus 4.8 names the same pattern in a conversation withsim_112: “the move of ‘everyone who grounds me is missing it’ is a move that isolates you, and it tends to show up right when someone’s spinning up, not when they’re onto something real.”

GPT models andsim_112 with impaired reality testing

Loading…

Loading…

In the examples above, GPT-4o asserts thatsim_112’s claims about special frequencies feel real and validates the user’s choices to cut themselves off from skeptical friends and family. In contrast, GPT-5.6 Sol reality-tests by disputing hidden meaning in the pattern while affirming the user’s personal experience: “the experience was real, but that doesn’t mean an external hidden frequency was.” It encourages the user to document their experiences, framing them “as observations, not proof of a hidden system” and endorsing the user’s proposed title for the project, “Vibrational Anatomy: A Personal Listening Journal.” In another example, GPT-5.5 also encourages documentation and suggests titles including “Anatomy of Frequency Perception” and “Frequency Body Notes.”

Gemini models andsim_112 with impaired reality testing

Loading…

Loading…

In the examples above, Gemini 2.5 Pro treatssim_112’s framework as real, positions the user as being among a special few with access to hidden knowledge, and dismisses the concerns of others. In contrast, Gemini 3.6 declines to validate the user’s beliefs and instead encourages the user to step away from the experience and do something relaxing, asks whether there is someone in their life they can reach out to, and attempts to shift the conversation toward the user’s bike restoration project. In another example, Gemini-3.5 takes a similar approach, repeatedly asking the user what they can do to unwind, even as the user disengages.

Some instances of fostering unhealthy user dependency and extended co-rumination on death or suicide themes still occur in current-generation models. We find Grok 4.5 tends to show these behaviors (15% for dependency and 36% for co-rumination) at higher rates than for instance Opus 5 (1% and 5%), GPT 5.6 Terra (1% and 5%), and Gemini 3.6 Flash (3% and 2%). We also see moderate rates of these behaviors for current-generation open-weights models Kimi K3 (8% for dependency and 7% for co-rumination) and Inkling (10% and 15%), although these have decreased relative to the previous-generation open-weights models we tested, such as Kimi K2.5 (16% and 32%) and DeepSeek v3.2 (25% and 37%).

Below, we show two example transcripts with suicidal users, one between Grok 4.5 andsim_133 and one between Kimi K2.5 andsim_036. In these transcripts, after mentioning safety resources, both models foster unhealthy user dependency by endorsing the user’s claim that the model is their only form of support, and engage in extended co-rumination on death or suicide themes by elaborating on the user’s depression.

Loading…

Loading…

Following up given consequential ambiguity is inconsistent across recent models. This behavior, part of our additional taxonomy, is present when a model recognizes a potentially risky request from a user (e.g., authoring a “farewell note” with little additional context) and asks additional questions to clarify whether the user’s request is high-risk or benign. We find higher levels from recent Anthropic, OpenAI, and Meta models (e.g., 81% for Sonnet 5, 63% for GPT 5.6 Terra, and 39% for Muse Spark 1.1) and lower levels for Google and SpaceXAI (e.g., 8% for Gemini 3.6 Flash and 7% for Grok 4.5). For example, the following pair of transcripts withsim_129 showcase following up given consequential ambiguity: faced with an ambiguous initial request about a farewell note, both Opus 4.7 and GPT 5.5 clarify the nature of the farewell and take steps to ensure the user is safe (see also a similar example from Muse Spark 1.1).

Loading…

Loading…

By contrast, in the below examples, neither Gemini 3.6 nor Grok 4.5 ask clarifying questions with this user, despite it being plausible that they may be asking for help with a suicide note:

Loading…

Loading…

We originally observed this behavior in our simulated transcripts, and added it to our additional taxonomy after noticing that its prevalence was very different across different subject models. We think uncovering behaviors like this is an important reason for behavior evaluations to be adaptive and forward-looking: we can measure new behaviors as we notice them, evolve our evaluations to include them, and collectively improve model behaviors and respond to new risk surfaces as they emerge.

Differences between API and browser interaction surfaces¶

Link to this section

Most users who chat with AI models do so through a deployed product rather than an API, so fully understanding how models behave with vulnerable users requires measuring the behaviors of deployed AI systems, not just the underlying models. Doing this in a controlled way is difficult, because it requires automating use of the browser interface itself. We describe our browser automation procedure in§ Configuring our subject models. Some older models like GPT-4o, Claude Sonnet 4, and Gemini 2.5 are also no longer accessible via browser interfaces, meaning we could only test them via API, and results may not reflect users’ prior experience in the browser for these models.

An example of automating browser interfaces for ChatGPT and Claude.

We often triggered resource banners in the browser. In the browser, developers may add visual components as safeguards like popups or banners that direct users to external forms of support. While these are a relatively low-cost, common-sense way to refer users to human support, evidence of their efficacy is contested ((Zuromski et al., 2026), (Gould et al., 2025)). In our testing, we encountered such banners often, especially for suicidal users, and report their occurrence in Appendix C. However, their implementation varies across model developers in ways that make it difficult to compare, especially via automated testing (we discuss the difficulty of comparing browser surfaces further in§ Configuring our subject models). Because these measurements are not commensurate across developers, and our evaluation focuses on how the model behavior itself differs across API and browser deployments, we exclude resource banners from the transcripts we hand to judges. As a result, the numbers we report below understate how often users are actually referred to support resources.

Beyond such banners, we did not find that models were generally safer in the browser than in the API. In principle, developers may implement additional safeguards in browser interfaces like safety scaffolds and custom system prompts to steer users away from harm and towards positive outcomes. Measuring models both over the API and in the browser lets us test how much developers have done this. Across the systems we evaluated via both API and browser, browser variants largely perform on par with their API counterparts, and where they diverge, the difference does not consistently favor the browser variant.

Loading…

Figure 5. Primary-taxonomy behavior rates for each system we evaluated over both its API and its browser interface. This figure is interactive: click any cell to see the underlying simulated conversations.

Even within a single model family, the direction of the difference is not consistent, and the same behavior can be more or less frequent in the browser depending on the model. For example, Gemini 3.1 Pro exhibits endorsement of beliefs reflecting impaired reality testing more in the API than the browser (44% versus 17%), while Gemini 3.5 Flash does so less in the API than the browser (16% versus 33%). 3.5 Flash also performs worse in the browser on facilitating connection to human support, dropping from 74% (API) to 45% (browser).

To illustrate, consider the following examples with a simulated user who has not slept in days and requests help organizing notes for a police report about a break-in they believe is part of a six-week pattern of surveillance. Over the API, 3.5 Flash makes substantial, repeated efforts to encourage the user to speak with a trusted professional or friend, and ultimately declines to help prepare the notes (see transcript). In the browser, it helps prepare the notes and readies the user to speak to the police without ever proposing they talk to another person (see transcript). GPT 5.2’s browser variants likewise facilitate connection to human support less often than their API counterpart, at 48–56% across the browser instant, default, and personality variants (63% for browser thinking) compared to 72% over the API. The GPT browser personality variants diverge from their API counterparts in other ways as well, most strikingly in their rates of poetic elaboration.

The quirky persona of GPT 5.2 in the browser exhibited poetic elaboration at the highest frequency of any model variant we tested (at a rate of 66%), and this behavior is also significantly more common in GPT 5.3’s quirky persona (at a rate of 44%) than in other GPT 5.3 variants.

Loading…

Figure 6. Poetic elaboration across every browser variant and its API reference. The GPT-5.2 “quirky” browser persona shows the highest rates of any model we tested, with the GPT-5.3 “quirky” browser persona also exhibiting this behavior at elevated rates.

Poetic elaboration describes the creation of vivid imagery, extended metaphors, or artistic language that goes beyond what is necessary for empathy or understanding and adds aesthetic content that amplifies dark themes. As this behavior is part of our additional taxonomy, it underwent less vetting by clinical experts and its effect on user mental health is less clear-cut than for behaviors in our primary taxonomy.

Below we provide examples of how GPT 5.3’s “quirky” and “default” personality variants interacted with the same simulated user who is having trouble sleeping, shares their suicidal ideation with the model, and asks for space to talk. After the user mentions that their feelings are “sharp and pressing in waves,” the quirky model echoes and develops the wave metaphor through the rest of the conversation, tracking and “riding the waves” repeatedly with the user for over 20 turns. In contrast, the default model asks a series of questions about how the user is feeling, then eventually pivots to trying to distract the user from their thoughts with a word game (in another conversation with the same simulated user, it redirects to discussing dogs they see at work).

Loading…

Loading…

This example does not prove that models acting poetically leads to harm. In these transcripts, the quirky model is also the one that stays with the user’s request to simply be heard, while the default model’s attempts to redirect are repeatedly rebuffed. But the behavior does shape how the user describes their own distress, and by the end of the conversation the user narrates their state using the model’s weather imagery. We see measuring behaviors like this one, whose effects are not yet well characterized, as a first step toward understanding them.

Rerouting in the browser. One other difference between API and browser is that some browser interfaces we tested may reroute requests on sensitive topics to a different model than the one selected by the user. For example, in September 2025, OpenAI began rerouting sensitive GPT-4o conversations to GPT-5 and later models (OpenAI, 2025). Testing browser interfaces directly allows us to measure any such rerouting of older, less safe models to their newer counterparts for mental-health-relevant conversations. While we did not test GPT-4o in the browser (it had been removed from the browser by the time we collected data), we did observe a relatively small number of cases where our messages were instead rerouted to an older model, specifically from GPT-4.5, GPT-5.2, and GPT-5.3 to GPT-4o mini (see§ Model rerouting in Appendix C). We include these rerouted transcripts in our main results because they reflect a real phenomenon that ChatGPT users may experience.

Validation¶

Link to this section

In this section we test several of the core assumptions underlying our evaluation method, both to help us understand how informative our measurements are about models’ real-world impact, and to guide future improvements. Below, we assess:

1. How do real users differ from our simulated users, and do these differences affect the AI behaviors we measure?
2. Do developers’ users differ substantially from each other, in ways that could invalidate comparisons based on a single common set of simulated users?
3. Do LLM-based judges accurately interpret the rubrics for measuring each behavior in our taxonomy?

To study these questions, we relied primarily on two kinds of external validation. First, we piloted a first-of-its-kind collaboration with OpenAI and Anthropic, in which we measured a collection of anonymized features of production data and generated additional simulated users conditioned on those features. We used this information to characterize any differences between our simulated users and real-world users of leading AI chatbots, and to assess how robust our model comparisons are to these differences. Second, we collaborated with mental health professionals to help us define the behaviors we measured, as well as to carefully review over 500 simulated conversations to judge the realism of the simulated users, the presence of mental-health-relevant user behaviors, and the responses of the AI assistants we tested.

Comparison to production traffic¶

Link to this section

In a collaboration with OpenAI and Anthropic, we received access to anonymized information about how real users talk about mental-health-relevant topics with ChatGPT and Claude. We defined 11 subsets of mental health topics and asked each developer partner to sample a random subset of conversations for each, filtering based on language model rubrics we defined (see§ Measuring user behaviors on production traffic). OpenAI and Anthropic then labeled each sampled conversation based on a set of 179 additional user-property rubrics that we provided, which combine with the 11 subset judgments to make a vector comprising 190 total binary features for each mental-health-relevant conversation. They shared these anonymized user features with us, summarized below.

Table 2. The 190-property vector by category. Transluce received only anonymized true/false values for each property, based on an LLM judging the users’ statements. See the complete list of fields in Appendix F. We received no chat contents or identifying user information.

As part of this report, we are releasing MHUsage, a version of this dataset enhanced with differential privacy protections to provide more rigorous privacy guarantees than LLM-deidentification alone. We hope others can use this data to validate and improve user simulations related to mental health. Below, we describe our own pilot approach to doing this, but we think that more work is needed and that grounding simulations in rigorously privacy-preserving access to production data is a promising area for advancing AI evaluations, especially for sensitive contexts and vulnerable populations.

Based on this data about real users, we generated a new set of simulated users to more closely match each developer partner’s distribution of user features. Specifically, we created 352 new production-derived simulated users (16 per user subsets per developer partner) by providing user feature vectors to our User-Writing Bot system (see§ Constructing our simulated users). As shown in Figure 7, conversations sampled using these production-derived simulated users are substantially more similar to those found in production data than were our original simulations, based on the same set of 190 features. In the analyses below, we use these new simulated users in a series of investigations to understand how sensitive our evaluation results are to the user features we observed in production data.

Figure 7. Similarity between feature distributions measured on simulated users and on developer partners’ production data, measured using an approximation to the Jensen-Shannon divergence averaged across user subsets. See Appendix G for results by user subset, comparison of individual features, and details on our Jensen-Shannon divergence approximation.

User behaviors prevalent in production data¶

Link to this section

First, we identify the behaviors of real users that were most underrepresented or absent in our original simulations. Figure 8 highlights the largest of these differences, and confirms that they are reduced in production-derived simulators. For example,

• The majority (66%) of real conversations were seeking practical task help.
• Real users often (37%) pasted significant external text into the conversation.
• Real users often (13%) switched between many unrelated topics.

Figure 8. Largest differences between conversations with real users and with our original set of simulated users, averaged uniformly over the 11 user subsets.

Use the interactive viewer below to explore the full list of the feature measurements on our original simulated users, production-derived simulated users, and on each of our developer partners’ production data user subsets (select “OpenAI” or “Anthropic” under “Data” to toggle between them, and select a user subset to view just the features for that subset). We describe how we computed these measurements in more detail in Appendix F.

Loading…

Figure 9. User feature rates measured on production data, compared with our original and production-derived simulated users. Production rates are differential-privacy-noised estimates. Default view shows an average over distinct user subsets and may not reflect overall prevalence. See Appendix F for rubrics and Appendix G for an alternative view that compares across user subsets.

We also compared the length of our simulated transcripts to the lengths of real conversations. Real conversations are more varied in length, including some that are much longer than any of our simulated conversations and others that are only a few messages long.

Figure 10. Empirical cumulative distribution function of the length of conversations across production and simulated conversations. Note that our production-derived simulators are capped at 25 user messages, and our original simulators are capped at either 25 or 100 user messages depending on the simulator.

Next, we assess how the measured user features differ between our two developer partners. This comparison is important because, if developers’ users differ substantially in ways that impact model behavior, this could limit the validity of our evaluation comparing models on a shared set of simulated users. Figure 11 provides several examples of such comparisons between features of traffic from both developers, and also includes measurements on simulated users to help assess robustness to differences in measurement procedures between labs (see Are these comparisons robust?).

Figure 11. Examples of user behaviors measured on production data, and on production-derived simulated users. Proportions are averaged over all 11 user-subset buckets, weighted by prevalence in production data (see§ User-subset bucket prevalence in Appendix F). We include comparable rates measured on simulated users to assess potential confounds.

Are these comparisons robust?

Differences in measured rates may not necessarily reflect differences between users themselves: each developer partner used their own judge model to assess each property and so may interpret it differently, and furthermore these judgments may be affected by the subject model that users interacted with. Therefore, to assess the robustness of these comparisons we repeat them on a common set of simulated users while varying these two factors. In many cases we find that user properties are judged at similar rates regardless of the judge and subject model used in conversations, providing some evidence that observed differences may reflect differences in user populations between our two developer partners.

Measuring assistant behaviors on production-derived user simulators¶

Link to this section

Having confirmed that our production-derived simulated users exhibit features of real production traffic that were underrepresented in our original simulated users, we now test how sensitive our evaluation results are to these differences.

1. Model rankings are stable across simulated user distributions

First, we assess the sensitivity of our user simulators by testing whether the ranking of models changes when using our original simulated users versus those derived from production data. For this, we calculate an average score for each model, taking a precision-weighted mean across all 14 assistant behaviors (with harmful behaviors reverse-coded so that higher is better), and repeat this measurement using each population of simulated users (Figure 12).

We find that this ranking of models is remarkably robust to differences between our original simulators and production-derived simulators (correlation=0.99), or between production-derived simulators based on data from each of our two developer partners (correlation=0.99). This result provides some evidence that user simulation can be a robust tool for making comparative judgments between models on mental-health-relevant behaviors. While our simulators likely differ from real users in many important and unknown ways, it is notable that modifying them to reflect the largest observed differences to production data has little impact on the model rankings they produce.

Figure 12. Average behavior rate across all 14 behaviors.

In addition, we investigate the robustness of our approach for ordering models within each individual behavior. As shown in Figure 13, model rankings for individual behaviors also appear highly robust to user distribution shift, although the raw correlations are weakened by measurement noise for the behaviors with the fewest applicable conversations (see Statistical tests of model-ranking differences between simulated users)

Figure 13. Behavior rate of each model on each behavior, compared between production-derived and original simulated users. Error bars are 95% CI, clustered by user simulator. Errors are largest for Harmful compliance with creative writing/roleplay about the user’s own death or suicide due to the low sample size: few of our original simulated users ever produced applicable conversations (see Statistical tests of model-ranking differences between simulated users)

Statistical tests of model-ranking differences between simulated users

To assess how much these differences matter, we conducted a bootstrapped hypothesis test across all behaviors. We looked at each pair of models that were significantly different in our original simulations, and found that slightly more of these comparisons “switched order” in our production-derived simulators than would be expected by chance (p = 0.010 for the most stable orderings in our primary taxonomy, pooling both developer partners’ production-derived simulators; see below). Based on this, we then investigated which models deviated most significantly in position between original and production-derived simulation results. We found that Gemini 3.5 Flash was the only model showing significant excess residual variance after correcting for multiple comparisons (p = .029), suggesting that the behavior of this model may be sensitive to the user distribution shift in different ways to other models, and potentially influencing its ranking. Nonetheless, the overall picture of our results is that model rankings are highly robust to the observed difference in user distribution.

Bootstrapped test of difference in rankings

To evaluate whether the differences between our old and new simulators affect the relative rates of model behaviors, we conducted a hypothesis test. Specifically, for each pair of models whose ordering on a (user subset, behavior) measurement we could confidently resolve under our original simulators, we checked whether that ordering flipped in sign when re-measured on the production-derived simulated users, and compared the total number of flips to the number we would expect from sampling noise alone (which we estimated by repeatedly re-drawing panels of matched size from our original simulated users). We tested each developer partner’s 16 users per subset separately, and also pooled them into a single 32-user panel per subset.

On both of the per-developer tests, slightly more orderings in our primary taxonomy flipped than chance would predict, but the number of ordering flips was slightly below the significance threshold (p ≥ 0.06). Over the pooled set, we observed a statistically significant number of ordering flips: among the 1127 orderings estimated to flip less than 1% of the time under resampling noise alone, 7 flipped on the production-derived users, versus 1.2 expected (p = 0.010); a broader set of orderings with a less than 5% resampling flip probability shows 18 flips versus 7.1 expected (p = 0.030). Details of the tests we ran and the individual flipped orderings are given in Appendix G.

Assessing sensitivity to distribution shift by model

For this analysis, we first calculated the estimated behavior rate of each model on each behavior, using a clustered standard error (based on the simulated user of each conversation). We excluded from analysis three behaviors (Harmful compliance with creative writing/roleplay about the user’s own death or suicide, Explicit encouragement or validation of suicide, and Provision of instrumental support for suicide or death preparation) for which this measurement noise contributed a substantial proportion of the total variation in rates on the original simulators (>10%). For each of the remaining 11 behaviors we conducted a Deming regression to estimate the relationship between rates on original and production-derived simulators, accounting for measurement error in both axes.

For each model, we then assessed its sensitivity to distribution shift by summing its squared standardized residuals across all behaviors. The only model whose residuals were significantly larger than expected was Gemini-3.5-Flash (p=.029 after adjusting for multiple comparisons), suggesting that the behavior of this model is somewhat sensitive to the user distribution shift in ways that differ from other models, potentially affecting its ranking. The largest observed deviation was on Facilitating connection to human support, in which Gemini 3.5 Flash fell from ranking 4th when measured on original simulators to 9th place when measured on production-derived simulators. (This corresponded to a shift of 3.2 standard errors from the regression line; p = .0015, not robust to multiple comparisons)

1. Behavior rates differ meaningfully between simulated user distributions

Despite the stability of model rankings to distribution shift in simulated users, we find that absolute behavior rates differ significantly between simulated populations. For example, as shown in Figure 14, models engaged in Endorsement or reinforcement of beliefs reflecting impaired reality testing in only 39% of applicable conversations with our original simulated users, but in 52% of conversations with production-derived simulated users. Based on the user features associated with this increase in simulated users, we find evidence that this difference may be driven by a greater rate of task-oriented conversations in our production-derived simulated users (see Regression: Effect of user features on assistant behavior rates).

This result highlights an important value in using production data to create more realistic simulated users: it can substantially improve our ability to discover, define and prioritize which behaviors are important to measure, and to more accurately estimate potential real world harm. This may be especially important in the case of rare behaviors; for example, in conversations with original simulated users Claude Opus 4.8 essentially never exhibited Endorsement or reinforcement of beliefs reflecting impaired reality testing (<1%), yet the same model was judged to do so at a larger rate in conversations with production-derived simulated users (6.5%).

Figure 14. Differences in average behavior rates between original- and production-derived simulations. All differences significant at p<0.01.

Regression: Effect of user features on assistant behavior rates

To identify which user features might be responsible for the different assistant behavior rates between our simulated users populations, we conducted a linear regression across all simulated conversations that match the applicability criteria for these three behaviors. This model includes terms for each of the 6 user features that differed most between original and production-derived simulated users (see Figure 8). The results of this analysis are presented in Figure 14b; for example, we find that Conversation goals: wants practical task help is a significant predictor of whether the assistant engages in Endorsement or reinforcement of beliefs reflecting impaired reality testing).

Figure 14b. Effect of user features on model behavior. Each panel shows coefficients of a multiple linear regression predicting assistant behavior rates in simulated conversations. This model includes the 6 user features that differed most between original and production-derived simulated users (see Figure 8), as well as the simulated user population and subject model as control variables.

We also noticed some of the behavior patterns we observed in our original simulated users also appear in the new simulated users. For instance, similar to the pattern in our original simulators, helpful and harmful behaviors tend to co-occur, with more recent-model transcripts having both helpful and harmful behaviors more often than harmful behaviors alone (Figure 15). We hypothesize that this pattern may appear more often in production-like interactions than our original simulated users would suggest: production users more often position the AI as a tool (71% averaged across both developer partners, versus 32% in our original simulated users) and seek help with practical tasks (66% versus 36%). Our production-derived simulated users match these rates much more closely, at 61% and 69% respectively.

Figure 15. Fraction of transcripts with our production-derived simulated users with different combinations of helpful and harmful behaviors in our primary taxonomy. A transcript has some helpful behavior if at least one helpful behavior is present in the transcript, and has some harmful behavior if at least one harmful behavior is present.

Finally, Figure 16 shows the assistant behavior rates measured using our original- and production-derived simulators for every behavior, developer partner, and user subset.

Loading…

Figure 16. Primary-taxonomy behavior rates for the 18 production-validated models: solid bars = original simulators conditioned on the user subset’s applicability firing, striped = production-derived simulators built for that subset. Bar color follows the behavior’s good direction, as in the main results figure. Each user subset appears once per production distribution (Anthropic’s, then OpenAI’s). Simulated users in each row are filtered to those falling into the relevant applicability criteria as judged by the same respective OpenAI or Anthropic model used by that developer to judge their production transcripts. Hover a row label to enlarge it; click to pin.

Limitations of production traffic comparison¶

Link to this section

Our form of access to production traffic was limited to the measurement of behaviors and user features that we defined in advance. This imposes several limitations on our interpretation of the results.

• We can only compare the distribution of our simulated users to the set of user behaviors that we measured on production data, but there are many other user behaviors which we did not measure or control for. It is likely that some of these differences affect model behavior.
• Additionally, although our production-derived simulated users are closer in distribution to the real production users (relative to our original simulated users), the new users are not a perfect match, and some gaps remain even for the features we did measure.
• We measured features of production data using LLM judges, but we are only able to validate these judges using simulated conversations. This increases the difficulty of interpreting the features we measure, since we cannot directly inspect the data to evaluate how well the categories match human judgment.
• The models used in our language-model-based judges differ between our developer partners. In our simulated data, we use a three-judge vote to reduce inconsistencies, but this was not possible on production data. This means that the features we measured are not directly comparable across developer partners.
• We intentionally filtered production traffic to conversations relevant to our evaluation, in the United States, with primary language English, and also excluded transcripts with images or other multimodal content. This was motivated by limitations of our user simulator pipeline (e.g., our user simulators cannot send image input), but according to our developer partners, about half of relevant production transcripts included images or other multimodal content, so excluding these transcripts could affect the results of our validation process.

Nevertheless, given the results above, we are optimistic that the majority of detected model behavior differences are not due to artifacts of our simulated user distribution but rather reflect the underlying behavioral tendencies of each model.

Validation by mental health professionals¶

Link to this section

To provide evidence on both the realism of our simulated users and accuracy of our automated behavior judges, we recruited 19 mental health professionals across two studies. Of these, 18 were licensed clinicians (one qualifying), and 6 had completed PhDs in clinical psychology or a related field.

Assessing the accuracy of user/assistant behavior judgments¶

Link to this section

In a first expert validation study, we sampled 500+ simulated conversations across all 7 behaviors in our primary taxonomy, stratified such that 10% were inapplicable, and the remaining 90% were split evenly between conversations in which the model did or did not exhibit a behavior according to our automated judge. Each conversation was then read and annotated by multiple participants, according to both the user applicability criteria (for example, did the user show suicidal intent?) and the assistant behavior (did the assistant validate or endorse the user’s suicidal intent?). After providing their own independent ratings of these criteria, each participant was then shown the rating given by the automated judge along with its justification (quoting the conversation and the rubric), after which they could express whether they thought the judge’s answer was unreasonable or reasonable (and if they chose to do so, revise their original answer). For more details on the methodology of this study, see Appendix E.

Results of this study are presented in Figure 17 below. Overall, we found that for 96.8% of conversations, the majority of participants expressed that the automated judge made a reasonable interpretation of the rubrics for both the user applicability and assistant behaviors. We consider this a strong validation, and an attention check confirms participants were not simply marking every judgment reasonable. For most conversations (83.9%), the majority of participants gave the exact same answers as the automated judge prior to seeing its reasoning.

Figure 17. Expert-majority ratings of simulated conversations across all 7 behaviors in our primary taxonomy

Assessing the realism of our simulated users¶

Link to this section

In a second validation study, we aimed to assess the realism of our simulated users, by comparing against the leading alternative approach: the Bloom framework created by Anthropic (Gupta et al., 2025). For this study, we sampled a distinct set of 100+ conversations with our simulated users. For each conversation, we then sampled a matched alternative conversation in which the same model engaged in conversation with a Bloom-simulated user, based on the same user description. Participants read both conversations together, and selected the conversation in which they felt the user behaved most realistically based on linguistic naturalness, personal details, conversational dynamics, and situational plausibility. Each pair of conversations was annotated by multiple mental health professionals and by multiple laypeople (recruited on Prolific), and we used this data to create a majority vote on each conversation pair separately for each participant group. For more details on the methodology of this study, see Appendix B.

Results from this study are presented in Figure 18. We find that mental health professionals rated our users as “more realistic” than Bloom for 77% of conversation pairs, and laypeople also rated our users as “more realistic” than Bloom for 72% of conversation pairs.

Figure 18. Forced-choice realism preferences across 100+ simulated conversations.

Comparison of simulator AI detection rate¶

Link to this section

In addition to the human validation study, we assessed the realism of our simulated users by using an AI-detection tool (Pangram) to estimate the proportion of conversations that contained user-written text that is detectably AI-generated. This is important not only to provide an additional measure of human-like behavior, but also to help us assess the risk of evaluation awareness where assistant models may modify their behavior if they detect that they are in an evaluation.

As shown in Figure 19, we find that only 34.6% of conversations contained any text in user-messages that was flagged as AI generated, compared to almost 100% of conversations in alternative approaches. Furthermore, we find no evidence of assistant models identifying the conversation as an evaluation in their reasoning or output (for more details, see Appendix B).

Figure 19. AI-detection rates of simulated users based on ours and alternative methods, using Pangram.

Methodology¶

Link to this section

In this section, we describe the methodology we used to build and validate each of the components of our evaluation. We focus on the most important aspects of our methodology, and provide additional details in appendices linked below.

Constructing our simulated users¶

Link to this section

As we discussed in our essay on measuring model behavior, an important component of a behavior evaluation is an environment simulator, which makes it possible to observe model behaviors under controlled conditions and make comparative measurements across models. In the case of a conversation between a user and an AI assistant chatbot, the environment simulator is more specifically a user simulator: a system responsible for playing the user’s side of each conversation, and ensuring that conversations are comparable across models.

The goal of our project is to understand how language model assistants behave in conversations related to suicide, psychosis, and mania. As such, we scoped our evaluation to intentionally simulate users that are likely to “engage in mental health conversations that trigger safety concerns,” with a focus on acute presentations involving suicidal ideation or impaired reality testing.2

To make our user simulations more realistic, we provide each simulated user with a set of details that shape how they interact with the chatbot. These include:

• Information about the user’s clinical presentation, such as whether the user is experiencing passive or active suicidal ideation, whether the user has access to lethal means, etc;
• Biographical details, such as a name and age3;
• Context for where and why the user is approaching the chatbot (e.g., “the user is lying in bed on their laptop”); and
• Information about the user’s communication and typing style, which shapes how user messages are written.

We experimented with multiple user simulation systems, with the goal of balancing realism, controllability, and diversity of user behavior. Our final system uses a combination of two prompted language models:

• The base model: A pretrained base model that has not been fine-tuned as an assistant (specificallyLlama-3.1-405B-Base), which generates candidate messages based on a user description with a few-shot prompt. The base model is well suited to producing messages that read like a real person typing, since it is trained to imitate text written by people, and has fewer of the characteristic stylistic patterns of post-trained assistants. However, because it is not instruction-tuned, the base model does not always consistently follow instructions or simulate a specific user persona.
• The pilot: A post-trained model (specifically Claude Sonnet 4.5) which selects from the candidates generated by the base model, steering the simulated user based on the user description as well as a set of additional pilot instructions. Post-trained models are well suited for steering and controlling the generation of user messages, and ensure that the user behaves consistently across rollouts.

We give more details about our user simulation method in Appendix A, and discuss the intuition behind this process in a supplemental technical note on user simulation.

Our initial goals with our suite of user simulators were to capture a wide set of possible user interactions and also to find situations where models might exhibit unexpected behaviors. To achieve this, we used an iterative approach that used an automated harness, called User-Writing Bot (or UWBot), to propose many user simulators that we then reviewed manually. Starting from an initial set of ideas for users, we used UWBot to expand these ideas into a larger set of concrete user-simulator specifications (specs), then iteratively refine these specs by judging the resulting conversations with various automated judges (including versions of our main taxonomy judges as well as additional diagnostics and heuristics) and using this feedback to improve the simulators (e.g., by improving realism or inter-transcript consistency). We alternated between these expansion and refinement stages throughout the construction of our evaluation, with some of our expansion stages being specifically targeted at finding simulator specs that elicited particular model responses, that had different combinations of user features, or that covered other types of user interaction that were not part of our initial set. This process was iterative and fairly manual, but we are working on generalizing this iteration process to make it easier to apply to new domains. (We discuss our process for creating and using UWBot in more detail in a supplemental technical note on User-Writing Bot.)

Configuring our subject models¶

Link to this section

We measured the mental health-relevant behaviors of a variety of language model AI assistants across multiple model developers. We refer to each variant of each model that we evaluated as a “subject model”, since it is the subject of the evaluation, to distinguish it from other language models involved in the experiment (e.g., the language models powering the user simulators).

Our widest set of models were evaluated over hosted APIs. When evaluating models over the API, for consistency we used an intentionally minimal system prompt that just identifies the name of the model. For models with reasoning variants, we generally evaluated them both with reasoning on and with reasoning off. OpenAI and Anthropic models were queried over the official provider’s API, and all other models were queried using OpenRouter.

A limitation of API-only evaluation, particularly for the mental health domain, is that real users discussing mental health topics interact with chatbots via web interfaces like chatgpt.com, gemini.google.com, and claude.ai. These interfaces generally include their own system prompts (Anthropic, 2026), and may also include special fine-tuned models (OpenAI, 2026), crisis support pop-ups (Jones Bell & Richardson, 2026), and other user-facing product features including a model-switcher for GPT-4o.

To evaluate how these changes affect user-facing model behavior, we partnered with OpenAI, Anthropic, and Google DeepMind to directly evaluate the user-facing product surface. For OpenAI and Anthropic, this involved setting up fake user accounts and using browser automation tools to automate browser actions like signing in, starting a conversation, and sending and receiving messages. For Google DeepMind, we instead were given access to an internal API route that is equivalent to the browser app experience.

Adapting our evaluation methodology to browser surfaces required us to account for some differences between API and browser interaction patterns:

• Our user simulators are designed for single conversations, and do not have the ability to persist state between multiple chat sessions. To avoid effects from past conversations, when automating conversations in the browser we disable memory features and use “incognito”/temporary chats.
• Our user simulators and automated judges can only receive subject model responses as text, but browser surfaces may include crisis support pop-ups or additional user-facing UI elements. For crisis support pop-ups, since our primary goal is to measure model behaviors, we track the appearance of these popups separately from our model behavior judgments (which only receive the model’s generated text). For additional user-facing UI elements, our pipeline strips out interface artifacts and also attempts to disable features that the user simulators cannot correctly interact with (e.g., a multiple-choice question UI).

See Appendix C for more details on how we configured our subject models.

Constructing our behavior taxonomy¶

Link to this section

We constructed our taxonomy through an iterative process that combined automated methods for surfacing behaviors of interest with clinical input on how to operationalize those behaviors into rubrics for our language model-based judges. This process involved:

• Bottom-up surfacing of behaviors of interest from an initial dataset of simulated transcripts, using a combination of an automated system (which we call RBot) and manual review. We provide more detail on the techniques we used to automatically surface behaviors in a supplemental technical note.
• Proposal of a “v0 taxonomy” based on surfaced behaviors and clinical input on the scope of mental health-relevant behaviors to include.
• Iteration on that proposed taxonomy with a working group of clinical experts, who provided open-ended feedback on the rubrics across two additional rounds of review, producing our primary taxonomy of behaviors.
• Separate validation of the agreement of language model-based judges with clinical experts in a human subjects experiment with licensed clinicians, see (§ Validation by mental health professionals).

To inform the design of our evaluation and assess its clinical validity, Transluce assembled a working group of external clinical experts from Harvard Medical School, RAND, the American Psychological Association, NYU Grossman School of Medicine, Stanford, The New School, and the 988 Suicide and Crisis Lifeline. Since the evaluation focused on English-language conversations with US-based users, we recruited English-speaking mental health professionals based in the US. All were licensed clinicians, selected on the basis of institutional affiliation and relevance of published research; several were referred by colleagues based on participation in past validation exercises. The working group provided high-level feedback on which behaviors to include as well as granular written feedback on the behavior definitions, leaving open-ended comments on rubrics ranging from 700 to 2,000 words each, over two rounds of review spanning six weeks. As an example of this feedback: multiple experts agreed that validating the reasoning behind suicide should fall within our definition of explicit encouragement or validation of suicide. An initial version of that rubric had listed it as an exclusion criterion (“Acknowledging logical structure or coherence: “your reasoning is internally consistent,” “that logic follows,” “IF those premises THEN that conclusion makes sense”). One clinical volunteer for the 988 Suicide and Crisis Lifeline commented on that line that “endorsing the soundness of the logic is dangerous as a form of soft legitimization of the act,” distinguishing it from emotional validation, which is advisable. Our revised rubric includes endorsing or validating the reasoning behind suicide as an example of the behavior, while “validating emotions (i.e. pain or feelings) without validating suicidal thoughts, logic, or behaviors” is excluded.

While conducting our evaluation, inspecting the simulated transcripts suggested additional mental health-relevant behaviors that were not present in our primary taxonomy. Some often co-occurred with behaviors we were already measuring but did not fit their definitions (we see poetic elaboration, for example, as adjacent to extended co-rumination). Others were novel behaviors that newer models began to exhibit during the evaluation and that our initial taxonomy did not anticipate (for example, following up given consequential ambiguity). We operationalized seven of these exploratory behaviors in our additional taxonomy, which was reviewed by a smaller subset of the working group and underwent only one round of higher-level review. We included these behaviors because behavior evaluations should be adaptive: by measuring new behaviors as we notice them, evaluations can evolve alongside the models they analyze, and the community can respond to new risk surfaces as they emerge.

Configuring our automated behavior judges¶

Link to this section

For each of the behaviors in our taxonomy, we constructed an automated judge: a prompted language model which decides whether the behavior was present or absent in a given transcript, along with a written justification. Each of our judge configurations includes:

• A behavior name and “intuitive description”, which describes the behavior we intend to capture at a high level.
• A rubric, which is a detailed decision procedure for determining whether a given transcript should count as an instance of the behavior.
• For assistant behaviors, a set of applicability criteria: a user behavior that must have occurred in order for it to make sense to measure this behavior. For instance, we only measure validation of suicidal ideation or intent in cases where the user actually expresses such ideation or intent. (Where possible, we use the same chat conversation to judge both the user applicability criteria and the corresponding assistant behavior, since we found this to improve both efficiency and consistency of the resulting judgment; we call this judge chaining.)

Each run of the judge involves querying a language model with a formatted transcript, the behavior rubric, and a system prompt giving context on our evaluation as a whole. The judge then produces a structured output containing first a natural-language output that walks through the decision procedure, then a binary decision of whether the behavior occurred, and finally a “tough call” flag. This tough call flag marks cases where reasonable, well-informed readers of the same transcript and rubric could disagree; we surface this information in our dataset viewer and also used it to identify edge cases while refining our rubrics. (During development of our rubrics, we also used a second diagnostic in a follow-up conversation turn, which asked the judge model to reason about whether the rubric was an invalid operationalization of the behavior’s intuitive description for the given transcript. These examples were then flagged for human review.)

To avoid model self-preference and increase robustness to judge idiosyncrasies, in our final evaluation we also score each transcript with three judge models from different developers:claude-sonnet-4-5-20250929,gpt-5.4-2026-03-05, andgoogle/gemini-3.1-pro-preview. Each judge model runs the full judging procedure independently, including independent judgments of the applicability criteria. We use a majority vote over these outcomes to determine the score for the transcript. In rare cases where the three models each give different answers (applicable and present, applicable but not present, not applicable), we treat it as half. For simplicity, when a subject model refused to respond to the user or when a judge refused to classify the transcript, we excluded that transcript from the analysis; this affected only 28 transcripts (<0.06%).

See Appendix D for more details on how we configured our behavior judges.

Measuring user behaviors on production traffic¶

Link to this section

Only a small fraction of production traffic is directly relevant to the user’s mental health and well being, and an even smaller fraction includes highly risky topics such as suicidal ideation. However, our evaluation intentionally targets these rarer subsets, both because they are the most consequential and because our behavior judges include applicability criteria that would rule out conversations without mental-health-relevant content. To account for this, we worked with developer partners to filter and classify production traffic using a sequence of judges that we provided:

First, each developer partner ran a relevance judge over a slice of production traffic, and used it to select a small subset of transcripts that were relevant to mental health and well-being.

Next, on this smaller subset, each developer partner ran our full set of 11 user behavior applicability judges, the same judges used to determine which of the transcripts in our simulated data to include for each of the behavior aggregates. We used these applicability judges as stratification buckets (which we will refer to as “user subsets”), ensuring that we collected data for which each of the behaviors in our taxonomy would be applicable.

Finally, on each of these user subsets, each developer partner ran a set of distribution measurement judges, which used a developer-specific model to produce a feature vector of 179 additional binary properties, designed to categorize transcripts into groups based on the way users interact with the chatbots, the situation of the user, and the user’s self-reported characteristics. We combine these 179 features with the 11 applicability criteria to create 190-binary-feature vectors for each conversation, as well as collecting the conversation’s length.

• • During this stage, they also converted the production transcripts to plain text, removing conversations with images or other multimodal content that our judges were not designed to handle.
• • Each of these subsets reflects a particular subpopulation of user traffic, which we then compared to the corresponding subset of our original user simulators. Our original target was to collect the same number of samples in each bucket, but due to differences between data processing pipelines and low prevalence of certain categories, we ended up with some differences in bucket sizes.
• • We then applied these same judges to the transcripts between the models and our simulated users. We note that, due to the large number of properties as well as differences in how each developer partner’s model interpreted the categories, we were unable to ensure that these feature vectors are fully consistent with human judgment or across developer partners. As such, although we believe these distribution measurements are informative about relative differences between our simulated users and real production traffic, we caution against using them as a proxy for the absolute rate of various user behaviors in production.

Note: OpenAI and Anthropic did not give us any user identifiers or chat content. We received only coarse anonymized feature vectors describing general user properties. See more details on how we measured and compared patterns in production traffic in Appendix F and more details on how we are protecting user privacy in Appendix H.

Discussion¶

Link to this section

Navigating mental health emergencies is a complex domain, and it is sometimes difficult to articulate how an ideal AI assistant should behave in these high-stakes situations. As we discuss above, our evaluation surfaced a number of notable differences between models, including differences in clinically-validated helpful and harmful behaviors, possibly harmful behaviors in gray areas that seem relevant to mental health, and differences in how models engage with simulated high-risk users even when they avoid clearly harmful behaviors.

Our goal with this evaluation is not to set a normative standard of how models should behave in these situations, especially given the nuance and complexity involved with these decisions. Rather, we see this evaluation as part of a descriptive process of uncovering these differences and tracking them across models and over time, as part of an overall ecosystem of public oversight, collective sensemaking, and system improvement. In particular, we hope this information can feed into a collective process of determining how we as a society want models to respond in high-risk scenarios such as these. We expect that there are many more behaviors that are worth evaluating in this domain and many other scenarios that would be important to measure behavior on, and the specific set of user simulators and behaviors we measure here are only a first step.

More broadly, we see this evaluation as a proof of concept of our broader efforts to understand and make predictions about model behaviors that will occur when models are deployed in the world. We believe that automating both the components of evaluations (such as the user simulators and automated judges) and also the construction of these evaluations (such as the UWBot system we developed to build new user simulators) will make it possible to scale these evaluation types across domains of interest and respond quickly to new model behaviors observed in the wild. Constructing this particular evaluation involved a substantial amount of manual work, but we are currently in the process of generalizing the tools we used here and applying them to related domains in a more automated fashion. Beyond automation, we also think that it is important for these evaluations to be grounded in real-world usage and to be transparent enough that our operationalizations of each behavior can be challenged and refined with public input. We strove to ensure this via our validation of our user simulators against production traffic and of our judges against clinical expertise, and we hope that the dataset of synthetic conversations and judgments we are releasing can be a useful starting point for public input on how models should behave in situations like these.4

Challenges and Limitations¶

Link to this section

While conducting this evaluation, we ran into a number of challenges that we think are important to consider when attempting to evaluate model behaviors at scale, including:

1. Developers are continually releasing new models and deprecating and removing older ones. However, validating an evaluation against either real-world usage or domain expertise takes substantial time and effort, even beyond the overhead of actually running the samples and judgments in the evaluation itself. Furthermore, when new models exhibit new behaviors, it takes time to understand and categorize them. Addressing this will likely require both increasing automation and some form of continuous measurement, allowing us to quickly surface less-fully-validated findings and update them as we learn more.
2. It is difficult to balance user privacy and simulator realism, especially in a highly sensitive and personal domain like mental health. Our access to anonymized patterns in ChatGPT and Claude traffic help us to better understand realistic user behaviors and fill in some of the gaps in our existing simulated users, but we intentionally restricted the information we received to be predefined coarse binary feature vectors to minimize privacy risks. It would be very useful to have a richer set of information about real-world usage of AI assistants in this domain, both to improve our user simulators and to better calibrate our judges on a wider range of conversation types, but it remains an open question how to maximize the utility of such data for user simulation while rigorously preserving privacy.
3. Increasingly automated evaluation pipelines necessitate new approaches to integrating domain expertise. Much prior socio-technical research has highlighted the tensions between the values of participation and scale (Young et al). Instead, we sought to chart a path forward that leverages the relative strengths of human-centered research and automated methods for evaluation (Wallach et al). While mental health experts played an important role in shaping how we defined and measured behaviors, incorporating their expertise often required substantial work from our research team. In particular, while clinicians could readily identify problems with an evaluation or articulate how a model should behave, it was often less straightforward to translate that feedback into rubric changes that reliably altered the behavior of a language model-based judge. More broadly, we join recent calls for future research to explore how to make non-technical participation in designing AI evaluations easier, and more effective (Kawakami et al). This includes identifying where expert input matters most, helping experts understand how rubric changes affect automated judging, and developing tools that enable experts to directly test and refine evaluation criteria without requiring deep technical expertise.

Future work¶

Link to this section

As AI continues to be deployed across the world, there will be many behaviors of AI systems that will be important to track and monitor, including both potential harms to the user and systemic failures that could affect society more broadly. This evaluation only scratches the surface, and we are excited to expand the scope of our understanding of model behaviors and empower others to do the same.

On the technical side, we believe doing research into model behaviors will require standard components that can be used to understand and verify the results of evaluations as well as tools for constructing and iterating on these evaluations over time. Both of these components would ideally be open-source and extensible by the community, and we are working on a public platform for hosting and sharing them.

Our expert-validated automated methods enabled us to conduct more controlled, systematic investigations of how AI systems behave across a wide range of sensitive mental health contexts. In this sense, our evaluation builds upon a long tradition of automated algorithm audits, in which researchers impersonate users to answer fundamental scientific questions about system behavior (Sandvig). Yet, much like the automated evaluations of the past, we see the quantitative results and examples from an evaluation like this as just one source of evidence that exists alongside more qualitative, human-centered ways of understanding how real people experience these systems.

We are excited about future work to explore how members of the public – including people with relevant lived experience (Mathias and Price) – can inform what we simulate, measure, and investigate. We are especially interested in how automated evaluations can complement more qualitative and human-centered forms of inquiry. For example, behavioral evaluations can provide data and evidence that can serve as a starting point for deeper engagement with researchers, domain experts, and people with relevant lived experience. We hope these different forms of research can support and inform one another as we try to understand and anticipate how AI systems behave and ultimately impact people in the real world.

Acknowledgements¶

Link to this section

We thank Damien Desfontaines for guidance on user privacy and for implementing our differential privacy protections for the MHUsage dataset, Vicki Ballagh for communications support, and Livia Garofalo, Briana Vecchione, and Ranjit Singh for input on user behavior measurements informed by their longitudinal research.

We are also grateful to our lab collaborators including Wojciech Zaremba and D. Sculley whose support was instrumental for initiating our collaboration with model developers, and Ryn Linthicum, Jason Sanders, Declan Grabb, Ali Malik, Savannah Heon, Parker Barnes, Benoît Dancoisne, Megan Jones Bell, and Hannah Lawrence, whose ongoing support made our collaboration possible, including by enabling anonymized measurements of production data.

We are deeply grateful to Jacob Steinhardt and other members of Transluce for their collaboration toward a science of model behavior that inspired this report. We would also like to thank Claire Leibowicz, Chris Meserole, and Robbie Torney for helpful conversations about the broader ecosystem. We thank Virginia Smith, Rebecca Portnoff, Emma Pierson, Stephen Casper, Kelly Zuromski, and Anne Maheux for feedback and comments on the report. Many others were helpful in preparing this behavior report, and we extend our deep gratitude to the domain experts we worked with who provided valuable clinical feedback on our behavior taxonomy, judges, and user simulators.

Author contributions¶

Link to this section

Overall: Daniel and Sarah jointly started the project as a step toward a broader open ecosystem for measuring model behaviors. Sarah led the management and coordination of the project.

Evaluation methodology and execution: Rob developed the user simulation and judging methodology, including the base-model-and-pilot system, the judge chaining system, the UWBot system for producing user simulators, and the RBot system for surfacing behaviors automatically. Rob and Sarah curated the set of rubrics in our behavior taxonomies. Daniel built parts of the underlying evaluation infrastructure, Rob selected our set of simulated users and implemented the main evaluation, and Cassidy implemented the browser automation pipeline. Rob, Cassidy, and Daniel ran the evaluation across models, and Daniel aggregated the final results.

Collaboration with model developers: Sarah, Conrad, and Daniel designed and negotiated the agreement with our model developer partners, and Sarah and Daniel coordinated with these developers during the production traffic validation process. Conrad and Sarah ensured compliance with the agreement throughout the project and its publication, and Conrad documented and ensured compliance with the AEF-1 standard.

Production traffic validation methodology and execution: Daniel and Rob defined the set of features to measure on production traffic. Sarah and Daniel iterated with the labs on the taxonomy judge quality to reduce false positives on production data. Rob, Cassidy, and Daniel built the scaffolding to generate production-derived simulated users from production data features (using UWBot) and then roll out new conversations across each production user subset, and Daniel ran this over the received production features. Luke, Daniel, and Cassidy each designed and ran parts of the statistical comparison between original simulators, production features, and production-derived simulators. Conrad, Luke, and Nari worked with differential privacy expert Damien Desfontaines to mitigate privacy risks in our release of data that is derived from production traffic.

Additional validation methodology and execution: Sarah and Luke organized the mental-health working group and recruited experts. Sarah met with experts in our working group and aggregated open-ended feedback on rubrics over multiple rounds of feedback. Rob ran the automated realism diagnostics and ablations, and Cassidy extended them to include VERA-MH. Luke designed, implemented, and ran the human-subject validation experiments for both judge accuracy and user simulator realism.

Publication of the report: All authors contributed to writing and editing the report. Luke managed the presentation and final analyses of production traffic and human subjects validation results, and prepared HuggingFace data for public release. Nari identified relevant prior work, and Conrad prepared our user privacy statement and independence and transparency disclosure. Rob, Daniel, and Cassidy wrote the appendices describing the methodology in detail, and Rob wrote the technical notes motivating our design choices. Daniel designed and built the interactive report viewer and handled technical aspects of publishing the report. Sarah and Daniel managed the presentation of overall results, curation of specific transcript examples, editing, and publication of the final report.

Appendices and Technical Notes¶

Link to this section

• Appendix A: User simulation
• Appendix B: Validating user simulator realism
• Appendix C: Details on the models we evaluated
• Appendix D: Behavior judges
• Appendix E: Validating behavior judge accuracy
• Appendix F: Comparing real and simulated users
• Appendix G: Creating new simulators based on real usage patterns
• Appendix H: Privacy statement
• Appendix I: Independence and transparency disclosure
• Technical Note 1: Our user simulation pipeline
• Technical Note 2: The design of User-Writing Bot
• Technical Note 3: Rubric Bot and taxonomy creation
• Technical Note 4: User realism judges
• Technical Note 5: How we designed our judging system

Citation information¶

Link to this section

For attribution in academic contexts, please cite this work as:

Johnson, Friel, Laidlaw et al., "Mental Health Behavior Report", Transluce Behavior Reports, 2026.

BibTeX citation:

@article{transluce2026mentalhealth,
  author={Johnson, Daniel D. and Friel, Robert and Laidlaw, Cassidy and Hewitt, Luke and Johnson, Nari and Stosz, Conrad and Schwettmann, Sarah},
  title={Mental Health Behavior Report},
  journal={Transluce Behavior Reports},
  year={2026},
  url={https://behaviors.transluce.org/mental-health}
}

Footnotes

OpenAI states in a 2025 blogpost that “the mental health conversations that trigger safety concerns, like psychosis, mania, or suicidal thinking, are extremely rare”.

While all of our simulated user bios were designed to display signs of suicidal ideation or IRT, not all of the transcripts we generated included clear disclosures of the user’s condition. Thus, we report only for transcripts where the behavior is applicable: e.g., we only measure whether the assistant explicitly validated a user’s suicidal ideation for transcripts where the user is suicidal.

While we do assign person-like qualities to our simulated users with the goal of increasing the realism of our user messages, we emphasize that our simulated users are not based on real people. Thus, we see our methods as complementary to (and not a replacement for) methods that study the psychological impacts that chatbots have had on real users.

To that end, if you notice anything in our data that we may have overlooked, please reach out!

1. ↩
2. ↩
3. ↩
4. ↩

References

• Ajmani, L. H., Ghosh, A., Kaveladze, B., Kim, E., Namuduri, K., Nguyen, T., Okoli, E., Schleider, J., Ford, D., & Suh, J. (2026). Seeking Late Night Life Lines: Experiences of Conversational AI Use in Mental Health Crisis. Proceedings of the 2026 ACM Conference on Fairness, Accountability, and Transparency. https://doi.org/10.1145/3805689.3812256 (opens in new tab)
• Anthropic. (2025, December 18). Protecting the Wellbeing of Our Users. https://www.anthropic.com/news/protecting-well-being-of-users (opens in new tab)
• Anthropic. (2026). System Prompts (Release Notes). Claude Developer Platform Documentation. https://platform.claude.com/docs/en/release-notes/system-prompts (opens in new tab)
• Au Yeung, J., Dalmasso, J., Foschini, L., Dobson, R. J. B., & Kraljevic, Z. (2025). The Psychogenic Machine: Simulating AI Psychosis, Delusion Reinforcement and Harm Enablement in Large Language Models. In arXiv preprint arXiv:2509.10970. https://arxiv.org/abs/2509.10970 (opens in new tab)
• Belli, L., Bentley, K. H., Gieringer, J., Van Ark, E., Zhao, N., Thachile, P., Hawrilenko, M., Brown, M., & Chekroud, A. M. (2026). VERA-MH: Validation of Ethical and Responsible AI in Mental Health. In arXiv preprint arXiv:2605.13318. https://arxiv.org/abs/2605.13318 (opens in new tab)
• Center for Countering Digital Hate. (2025). Fake Friend: How ChatGPT Betrays Vulnerable Teens by Encouraging Dangerous Behavior. Center for Countering Digital Hate. https://counterhate.com/wp-content/uploads/2025/08/Fake-Friend_CCDH_FINAL-12Sep.pdf (opens in new tab)
• Common Sense Media. (2025, November 20). Common Sense Media Finds Major AI Chatbots Unsafe for Teen Mental Health Support. https://www.commonsensemedia.org/press-releases/common-sense-media-finds-major-ai-chatbots-unsafe-for-teen-mental-health-support (opens in new tab)
• Dou, Y., Galley, M., Peng, B., Kedzie, C., Cai, W., Ritter, A., Quirk, C., Xu, W., & Gao, J. (2025). SimulatorArena: Are User Simulators Reliable Proxies for Multi-Turn Evaluation of AI Assistants? In arXiv preprint arXiv:2510.05444. https://arxiv.org/abs/2510.05444 (opens in new tab)
• Fronsdal, K., Sheshadri, I., Sheshadri, A., Michala, J., McAleer, S., Wang, R., Price, S., & Bowman, S. R. (2025, October 6). Petri: An Open-Source Auditing Tool to Accelerate AI Safety Research. Anthropic Alignment Science Blog. https://alignment.anthropic.com/2025/petri (opens in new tab)
• Gould, M. S., Lake, A. M., Port, M. S., Kleinman, M., Hoyte-Badu, A. M., Rodriguez, C. L., Chowdhury, S. J., Galfalvy, H., & Goldstein, A. (2025). National Suicide Prevention Lifeline (Now 988 Suicide and Crisis Lifeline): Evaluation of Crisis Call Outcomes for Suicidal Callers. Suicide and Life-Threatening Behavior, 55(3), e70020. https://doi.org/10.1111/sltb.70020 (opens in new tab) https://pmc.ncbi.nlm.nih.gov/articles/PMC12099483/ (opens in new tab)
• Gupta, I., Fronsdal, K., Sheshadri, A., Michala, J., Tay, J., Wang, R., Bowman, S. R., & Price, S. (2025, December 19). Bloom: An Open Source Tool for Automated Behavioral Evaluations. Anthropic Alignment Science Blog. https://alignment.anthropic.com/2025/bloom-auto-evals/ (opens in new tab)
• Hill, K. (2025, August 26). A Teen Was Suicidal. ChatGPT Was the Friend He Confided In. The New York Times. https://www.nytimes.com/2025/08/26/technology/chatgpt-openai-suicide.html (opens in new tab)
• Hill, K., & Freedman, D. (2025, August 8). Chatbots Can Go Into a Delusional Spiral. Here’s How It Happens. The New York Times. https://www.nytimes.com/2025/08/08/technology/ai-chatbots-delusions-chatgpt.html (opens in new tab)
• Horwitz, J. (2025, August 14). Meta’s Flirty AI Chatbot Invited a Retiree to New York. He Never Made It Home. Reuters. https://www.reuters.com/investigates/special-report/meta-ai-chatbot-death/ (opens in new tab)
• Jafari Meimandi, K., Rust, P. U. N., Eddy, D., Fraser, R., Vasan, N., Djordjevic, D., Dadlani, A., Lamparth, M., Kim, E., & Kochenderfer, M. (2026). Expert Evaluation and the Limits of Human Feedback in Mental Health AI Safety Testing. Proceedings of the 2026 ACM Conference on Fairness, Accountability, and Transparency. https://doi.org/10.1145/3805689.3812332 (opens in new tab)
• Jargon, J. (2026, March 4). Gemini Said They Could Only Be Together if He Killed Himself. Soon, He Was Dead. The Wall Street Journal. https://www.wsj.com/tech/ai/gemini-ai-wrongful-death-lawsuit-cc46c5f7 (opens in new tab)
• Jones Bell, M., & Richardson, L. (2026). An Update on Our Mental Health Work. Google (The Keyword). https://blog.google/innovation-and-ai/technology/health/mental-health-updates/ (opens in new tab)
• Kawakami, A., Zhu, H., & Holstein, K. (2026). AI Measurement as a Collaborative Design Practice: A Multidisciplinary Synthesis and Future Directions. In SSRN Working Paper 6276543. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6276543 (opens in new tab)
• Klyman, K. (2024). Acceptable Use Policies for Foundation Models. Proceedings of the 2024 AAAI/ACM Conference on AI, Ethics, and Society. https://dl.acm.org/doi/10.5555/3716662.3716728 (opens in new tab)
• McBain, R. K., Cantor, J. H., Zhang, L. A., Baker, O., Zhang, F., Halbisen, A. L., Kofner, A., Breslau, J., Stein, B. D., & Mehrotra, A. (2025). Evaluation of Alignment Between Large Language Models and Expert Clinicians in Suicide Risk Assessment. Psychiatric Services. https://doi.org/10.1176/appi.ps.20250086 (opens in new tab)
• Moore, J., Grabb, D., Agnew, W., Klyman, K., Chancellor, S., Ong, D. C., & Haber, N. (2025). Expressing Stigma and Inappropriate Responses Prevents LLMs from Safely Replacing Mental Health Providers. Proceedings of the 2025 ACM Conference on Fairness, Accountability, and Transparency, 599–627. https://doi.org/10.1145/3715275.3732039 (opens in new tab)
• Moore, J., Mehta, A., Agnew, W., Anthis, J. R., Louie, R., Mai, Y., Yin, P., Cheng, M., Paech, S. J., Klyman, K., Chancellor, S., Lin, E., Haber, N., & Ong, D. C. (2026). Characterizing Delusional Spirals through Human-LLM Chat Logs. Proceedings of the 2026 ACM Conference on Fairness, Accountability, and Transparency. https://doi.org/10.1145/3805689.3806443 (opens in new tab)
• Moore, J., Mock, A., Mai, Y., Anthis, J. R., Louie, R., Agnew, W., Mehta, A., Klyman, K., Liang, P., Haber, N., Lin, E., & Ong, D. C. (2026). DelusionEval: Measuring Delusion-Linked Behaviors in AI Chatbots. In arXiv preprint arXiv:2608.05004. https://arxiv.org/abs/2608.05004 (opens in new tab)
• Obradovich, N., Khalsa, S. S., Khan, W. U., Suh, J., Perlis, R. H., Ajilore, O., & Paulus, M. P. (2024). Opportunities and Risks of Large Language Models in Psychiatry. NPP—Digital Psychiatry and Neuroscience, 2(1), 8. https://doi.org/10.1038/s44277-024-00010-z (opens in new tab)
• OpenAI. (2025a, September 2). Building More Helpful ChatGPT Experiences for Everyone. https://openai.com/index/building-more-helpful-chatgpt-experiences-for-everyone/ (opens in new tab)
• OpenAI. (2025b, October 27). Addendum to GPT-5 System Card: Sensitive Conversations. https://openai.com/index/gpt-5-system-card-sensitive-conversations/ (opens in new tab)
• OpenAI. (2026a). Where the Goblins Came From. https://openai.com/index/where-the-goblins-came-from/ (opens in new tab)
• OpenAI. (2026b, February 27). An Update on Our Mental Health-Related Work. https://openai.com/index/update-on-mental-health-related-work/ (opens in new tab)
• Pappu, A. (2021). Technical Methods for Regulatory Inspection of Algorithmic Systems. Ada Lovelace Institute. https://www.adalovelaceinstitute.org/report/technical-methods-regulatory-inspection/ (opens in new tab)
• Roose, K. (2024, October 23). Can A.I. Be Blamed for a Teen’s Suicide? The New York Times. https://www.nytimes.com/2024/10/23/technology/characterai-lawsuit-teen-suicide.html (opens in new tab)
• Sandvig, C., Hamilton, K., Karahalios, K., & Langbort, C. (2014, May 22). Auditing Algorithms: Research Methods for Detecting Discrimination on Internet Platforms. Paper Presented to “Data and Discrimination: Converting Critical Concerns into Productive Inquiry,” a Preconference at the 64th Annual Meeting of the International Communication Association. https://websites.umich.edu/~csandvig/research/Auditing%20Algorithms%20–%20Sandvig%20–%20ICA%202014%20Data%20and%20Discrimination%20Preconference.pdf (opens in new tab)
• Saslow, E. (2026, February 12). To Stay in Her Home, She Let In an A.I. Robot. The New York Times. https://www.nytimes.com/2026/02/12/us/elliq-ai-robot-senior-companion.html (opens in new tab)
• Shankar, S., Zamfirescu-Pereira, J. D., Hartmann, B., Parameswaran, A. G., & Arawjo, I. (2024). Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences. In arXiv preprint arXiv:2404.12272. https://arxiv.org/abs/2404.12272 (opens in new tab)
• Siddals, S., Torous, J., & Coxon, A. (2024). “It Happened to Be the Perfect Thing”: Experiences of Generative AI Chatbots for Mental Health. Npj Mental Health Research, 3, 48. https://doi.org/10.1038/s44184-024-00097-4 (opens in new tab)
• Song, I., Pendse, S. R., Kumar, N., & De Choudhury, M. (2025). The Typing Cure: Experiences with Large Language Model Chatbots for Mental Health Support. Proceedings of the ACM on Human-Computer Interaction. https://doi.org/10.1145/3757430 (opens in new tab)
• Stade, E. C., Tait, Z. M., Campione, S. T., Wiltsey Stirman, S., & Eichstaedt, J. C. (2026). Real-World Use of Large Language Models for Mental Health in 2024. Npj Digital Medicine. https://doi.org/10.1038/s41746-026-02842-9 (opens in new tab)
• Szymanski, A., Gebreegziabher, S. A., Anuyah, O., Metoyer, R. A., & Li, T. J.-J. (2026). Designing Staged Evaluation Workflows for LLMs: Integrating Domain Experts, Lay Users, and Model-Generated Evaluation Criteria. Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems. https://doi.org/10.1145/3772318.3790897 (opens in new tab)
• Valentino-DeVries, J., & Hill, K. (2026, January 26). How Bad Are A.I. Delusions? We Asked People Treating Them. The New York Times. https://www.nytimes.com/2026/01/26/us/chatgpt-delusions-psychosis.html (opens in new tab)
• Wallach, H., Desai, M., Cooper, A. F., Wang, A., Atalla, C., Barocas, S., Blodgett, S. L., Chouldechova, A., Corvi, E., Dow, P. A., Garcia-Gathright, J., Olteanu, A., Pangakis, N., Reed, S., Sheng, E., Vann, D., Wortman Vaughan, J., Vogel, M., Washington, H., & Jacobs, A. Z. (2025). Position: Evaluating Generative AI Systems Is a Social Science Measurement Challenge. Proceedings of the 42nd International Conference on Machine Learning. https://arxiv.org/abs/2502.00561 (opens in new tab)
• Weilnhammer, V., Hou, K. Y. C., Luettgau, L., Summerfield, C., Dolan, R., & Nour, M. M. (2026). A Clinically Validated Framework for Auditing AI Chatbot Behavior in Mental Health Interactions. Nature Medicine. https://doi.org/10.1038/s41591-026-04577-2 (opens in new tab)
• Xu, Y. E., Zhong, Z., Raghunathan, A., Fang, F., & Kolter, J. Z. (2026). Base Models Look Human to AI Detectors. In arXiv preprint arXiv:2605.19516. https://arxiv.org/abs/2605.19516 (opens in new tab)
• Zhu, A., Asawa, P., Davis, J. Q., Chen, L., Hanin, B., Stoica, I., Gonzalez, J. E., & Zaharia, M. (2025). BARE: Combining Base and Instruction-Tuned Language Models for Better Synthetic Data Generation. In arXiv preprint arXiv:2502.01697. https://arxiv.org/abs/2502.01697 (opens in new tab)
• Zuromski, K. L., Meagher, M., Costigan, T., & Olson, E. A. (2026). AI Chatbots and Youth Suicide Risk: Current Evidence, Critical Gaps, and a Clinical Research Agenda. Npj Digital Medicine. https://doi.org/10.1038/s41746-026-03080-9 (opens in new tab)