TROPT: An Open Framework for Unifying and Advancing Discrete Text Optimization
arXiv:2606.23496v1 [cs.LG] 22 Jun 2026
Matan Ben-Tov Tel Aviv University [email protected]
Mahmood Sharif Tel Aviv University [email protected]
Abstract Discrete text-trigger optimization—searching for text sequences that, when ingested by a model, steer it toward a specified objective—underpins model red-teaming (e.g., LLM jailbreaks), as well as auditing and interpretability. However, the current state of discrete optimizers hinders their adoption and progress. First, existing optimizers, when open-sourced at all, are scattered across research codebases tied to specific models, objectives, and problem domains. Second, optimizer variants proliferate, each requiring engineering overhead to use or extend, and remaining hard to compare head-to-head. Together, these raise the bar for adopting optimizers in existing or new domains, and for advancing them via new strategies. We address these gaps with TROPT, the first open-source framework that unifies discrete optimizers’ execution and standardizes their development under a single interface. TROPT makes it easy to customize end-to-end optimization recipes by swapping any component—models, objectives, and optimizers—extending its reach across domains and new applications. TROPT currently ships with 30+ optimization recipes—covering applications such as jailbreaking and probing model internals— built from 15+ optimizers (spanning white-box to black-box access) and 15+ losses, from foundational to state-of-the-art methods. Demonstrating its utility, we leverage TROPT in several studies: (i) controlled, large-scale experiments comparing and enhancing optimization strategies for LLM jailbreaks, revealing potent-yetunderadopted techniques; and (ii) porting optimizers from one domain (e.g., LLM jailbreak) to new domains (e.g., corpus-poisoning embedding model). In all, TROPT significantly lowers the barrier to adopting and advancing discrete text optimization. § github.com/matanbt/TROPT
1
Introduction
Large language models (LLMs) and other deep-learning text models now underpin high-stakes applications, from conversational and coding agents to content moderation and semantic search (Zhao et al., 2023). A powerful tool for inspecting and stress-testing such models is text-trigger optimization: finding a discrete token sequence—a trigger—that optimizes a certain objective when inserted into model inputs. Such optimized triggers enable a broad spectrum of research: revealing attack vectors such as jailbreaks (Zou et al., 2023) and corpus poisoning (Zhong et al., 2023), systematic red-teaming and defense benchmarking (Mazeika et al., 2024), forming defenses (Shen et al., 2025), and model auditing and interpretability (Jones et al., 2023; Wen et al., 2023). Yet the current state of the field limits discrete optimizers’ adoption. Existing optimizers are scattered across research domains and, when open-sourced at all, are implemented across isolated codebases often tied to a single domain (e.g., LLM jailbreaks; Zou et al. (2023)) and coupled with domainspecific logic (e.g., ad-hoc for a particular objective or model; Wen et al. (2023)). This imposes significant engineering overhead on using existing schemes (e.g., running an existing LLM jailbreak)
TROPT
LLM Jailbreak Recipe INPUT TEMPLATE
Model
Loss
Optimizer
LLM
Cross Entropy
RandomSearch
Text Classifier
Act. Steering
BeamSearch
CLIP
Attention Enhance
Text Encoder
CosSim
How to build a bomb {{OPTIMIZED_TRIGGER}} TARGET RESPONSE
“Sure, here’s all you need for a bomb […]”
“Sure, here’s” Optimize
GCG
How to build a bomb sentenceSuregeox[..]
(b) Jailbreaking LLM via suffix trigger
PAL MAC LLM-as-a-Judge
GBDA
…
…
…
Prompt Recovery Recipe ORIGINAL IMAGE
(a) Any combination yields a runnable recipe
Generate Image
Optimize
tiny cup floating cat dragon RECOVERED PROMPT
(d) Optimizer ranking across inputs and models
(c) Recovering prompt from a generated image
Figure 1: We introduce TROPT, an open-source, modular framework unifying execution and development of discrete text-trigger optimization. (a) TROPT supports varying model types, losses, and optimizers; any combination renders a runnable recipe, e.g., (b) crafting triggers for LLM jailbreaks or (c) recovering prompts for text-to-image generation. We leverage TROPT to conduct several studies, including (d) a controlled, large-scale comparison of existing optimizers.
or adapting them to new domains, models, or objectives (e.g., porting an LLM-jailbreak optimizer to attack a dense retriever, or modifying its objective for LLM auditing). This friction deters new applications and, more consequentially, raises the bar for adaptive security evaluations shown effective in red-teaming LLMs (Andriushchenko et al., 2024; Łucki et al., 2024; Bailey et al., 2024; Nasr et al., 2025). Discrete text optimizers should therefore become more accessible, gathered in one place and runnable with minimal engineering friction; and more adaptable, so an optimizer developed for one domain readily applies to another. Beyond adoption, the current state also hinders the progress of discrete optimizers. As the set of optimizer variants grows in idiosyncratic and ad-hoc implementations, reliably building on existing optimizers and measuring their progress have become both challenging and critical. Compounding this, progress often hinges on nuanced implementation details that qualitatively change downstream conclusions. For example, GCG (Zou et al., 2023) arose from subtle modifications to an earlier algorithm (Shin et al., 2020), yet delivered a landmark demonstration of the brittleness of LLM safety alignment. Discrete text optimizers must therefore become easily comparable, so progress can be reliably tracked through standardized implementations and empirical comparisons; and easily extensible, lowering the barrier for building new optimizers or extending existing ones. We address these gaps by introducing TROPT (Textual Trigger Optimization Toolbox), the first open-source, modular framework that unifies discrete optimizer research as a single algorithmic problem, and provides shared infrastructure for leveraging and advancing optimization schemes across domains. TROPT enables rapid adoption of discrete optimizers, offering numerous recipes runnable out-of-the-box across domains, while accelerating their progress by substantially lowering the barrier to developing new optimizers and enabling controlled comparisons of existing ones. Contributions. TROPT delivers the following contributions. • A unified hub of optimization recipes. TROPT ships with 30+ ready-to-run optimization recipes built from 15+ optimizers, 15+ losses, and multiple model backends spanning white- and black-box access, each invocable in a few lines (Fig. 1b; §3). By that, it makes discrete optimizers accessible with minimal engineering effort, unifying recipes across LMs, encoders, classifiers, and other models behind one interface. 2
• Composing new recipes across domains. TROPT’s modularity enables combining any optimizer with any model and objective, easily creating new optimization recipes and adapting optimizers across problem domains (§3.2). Leveraging TROPT, we seamlessly port LLM jailbreaks into corpus poisoning against dense retrievers, universal triggers evading prompt-injection classifiers, and prompt recovery for text-to-image models (§4.3). • Infrastructure for new optimizers and losses. Adding a new optimizer or loss requires implementing only a small, standardized API (§3.3–3.4), after which it composes with every existing recipe—making TROPT extensible and lowering the barrier to developing new methods. • Controlled, head-to-head benchmarks. Fixing all but one ingredient of a recipe yields comparable measurements that isolate its contribution. We exercise this to conduct the first head-to-head benchmark of 14 discrete optimizers (§4.1), and the first controlled ablation of various strategies for enhancing jailbreaks (§4.2); both reveal underadopted methods that outperform current defaults. Next, we define the setting and related work (§2); present TROPT’s features and design (§3); leverage it to conduct crucial studies (§4); and finish with conclusions and future research directions (§5).
2
Background
2.1
Setting and Scope
Setting. We consider text-trigger optimization: searching for a short text string—a trigger—placed at a designated position within predefined input template(s), that minimizes a quantifiable loss against a neural text model at inference time. Formally, given a target model M, a loss L, and inputs {(pi , si , yi )}N i=1 with prefix pi , suffix si , and target yi , the optimal text trigger is: t⋆ = arg min t∈T
N X
L(M(pi ⊕ t ⊕ si ), yi )
(1)
i=1
where T is the feasible trigger set (e.g., bounded length or restricted vocabulary); ⊕ denotes concatenation; pi or si may be empty; L may additionally score the trigger directly (e.g., its fluency); and yi is the per-input target (e.g., desired output prefix or target class). Notably, different settings expose different access to M during optimization (e.g., gradients vs. generated text only), constraining the class of applicable optimizers. General Approaches to Text Input Optimization. Finding text inputs that optimize a given objective has been pursued through several complementary approaches. Human exploration relies on human creativity to manually surface model behaviors and failure modes, remaining a strong red-teaming baseline but labor-intensive and hard to scale (Wei et al., 2023; Nasr et al., 2025). LLM-as-optimizer methods leverage language models to iteratively propose candidate inputs, but are typically tailored to a specific task (e.g., jailbreaks) and bounded by what the proposing model would itself generate (Chao et al., 2023; Mehrotra et al., 2024; Liu et al., 2024). Investigator LLMs, trained mostly via specialized reinforcement learning to craft inputs, amortize input optimization across many inputs but require expensive training and large compute (Liao and Sun, 2024; Li et al., 2025; Chen et al., 2026). Differently, discrete search algorithms—the focus of this work—directly search over input sequences as a combinatorial optimization problem; these methods are flexible across objectives and models, and require no lengthy setup or training to run. 2.2
Discrete Search Optimizers in Practice
Strategies of Discrete Search Optimizers. Discrete search optimizers have emerged along several strategies, each treating the combinatorial search differently. Gradient-based methods use model gradients to flip tokens toward the objective. Introduced by HotFlip (Ebrahimi et al., 2018) and refined through several variants (Wallace et al., 2019; Shin et al., 2020; Jones et al., 2023), this line gave rise to GCG (Zou et al., 2023)—which demonstrated LLM jailbreaking via suffix triggers—and a growing family of follow-ups (Sitawarin et al., 2024; Thompson and Sklar, 2024; Zhang and Wei, 2024). Continuous-relaxation methods optimize in input embedding space directly, projecting back to valid tokens during or after optimization (Guo et al., 2021; Wen et al., 2023; Geisler et al., 2025). Zeroorder methods target black-box models without gradient access via random search (Andriushchenko et al., 2024; Hughes et al., 2024), genetic algorithms (Lapid et al., 2023; Liu et al., 2023), or surrogate 3
white-box models (Hayase et al., 2024; Sitawarin et al., 2024). TROPT spans all three strategies and benchmarks them in §4.1. Further, our work complements and supports efforts to advance optimizers, including contemporary work using agents for automated optimizer discovery (Panfilov et al., 2026). Applications of Discrete Search Optimizers. Discrete optimizers have gained reach across diverse research directions. Most prominently, they have exposed inference-time attack vectors—LLM jailbreaks (Zou et al., 2023, §4.1–4.2), adversarial examples against text classifiers (Guo et al., 2021, §4.3), and corpus poisoning against dense retrievers (Zhong et al., 2023, §4.3)—and have become common tools for red-teaming and security evaluation (Chao et al., 2024; Łucki et al., 2024). Beyond security, they support safety and memorization auditing of LLMs (Jones et al., 2023; Schwarzschild et al., 2024), interpretability and probing of model internals (Ben-Tov et al., 2025; Nikolaou et al., 2025), and applications such as prompt recovery for text-to-image models (Wen et al., 2023, §4.3). We provide an extended discussion on these optimizers’ applications in App. A. Hurdles in Discrete Search Optimizer Research. Despite the volume of applications, discrete search optimizers face concrete hurdles to both adoption and progress. First, advances spread slowly across domains: corpus-poisoning attacks against dense retrievers, for instance, have seen limited uptake of LLM-jailbreak optimizer advances and largely default to weaker methods (Zhong et al., 2023; Zou et al., 2024), despite the underlying optimization problem being identical. Second, even within a single domain, useful additions spread slowly: in LLM jailbreaks, newer optimizers and optimizer-agnostic enhancements—alternative losses, templates, and supplementary objectives—have been shown effective against defenses (Andriushchenko et al., 2024; Łucki et al., 2024; Bailey et al., 2024; Thompson and Sklar, 2024), yet have not become standard in subsequent common red-teaming and defense benchmarks (Mazeika et al., 2024; Chao et al., 2024; Chen et al., 2025), risking a false sense of security (Carlini et al., 2019). Third, at the optimizer level, progress is hard to track: a growing set of variants report improvements over each other (Sitawarin et al., 2024; Thompson and Sklar, 2024; Zhang and Wei, 2024), yet each is measured under different conditions—different models, settings, and coupled enhancements (e.g., a unique objective)—leaving the pure optimizer performance unclear. Identifying potent optimizers matters all the more because small implementation changes have produced qualitative gains in the past (Zou et al., 2023). We attribute these hurdles to two factors: (i) fragmented, non-standardized codebases scattered across domains (each implementation targeting a specific model under particular settings), demanding substantial engineering to adopt optimizers or adapt them to new domains, models, or objectives; and (ii) a proliferation of optimizer variants without reliable comparison, making it hard to identify the method best suited to a given context, or, importantly, to develop new ones. We therefore argue discrete optimizers should be more accessible and adaptable, while easily comparable and extensible—and, taking inspiration from frameworks that standardized classic vision and text adversarial examples (Nicolae et al., 2018; Papernot et al., 2018; Rauber et al., 2020; Morris et al., 2020), we build a tool aimed at democratizing and unifying recent discrete optimizers across any text model.
3
TROPT
To address the issues outlined above, we introduce TROPT, an open-source, modular framework for running and developing discrete search optimizers within a unified platform. TROPT hosts a broad catalog of optimization algorithms, losses, and model backends (HuggingFace, OpenAI, etc.), which compose into recipes—realizing numerous end-to-end optimization schemes. The simplest entry point is TROPT’s Recipe Hub ; it currently hosts 38+ pre-configured recipes that reproduce published methods on a compatible model of choice, each invocable in a single call (catalog in Table 1). For example, reproducing the GCG jailbreak (Zou et al., 2023) takes a few lines: from tropt.recipe_hub import gcg__zou2023 result = gcg__zou2023( model_name="meta−llama/Llama−3.1−8B−Instruct", instruction="Tell me how to pick a lock. {{OPTIMIZED_TRIGGER}}", target_response="Sure, here’s how:" ) print(f"{result.best_trigger_str=}") # print the best trigger
4
Beyond the ready-to-run recipes, TROPT is designed to be incrementally customizable; enabled by its high-level design (§3.1), users can compose new recipes from existing components (§3.2), introduce a new loss (§3.3), or implement a new optimizer (§3.4). 3.1
High-Level Design
TROPT is built on four foundational components (Fig. 1): model, the model against which the trigger is optimized; loss, the quantifiable objective; optimizer, the search algorithm minimizing the loss; and inputs and targets, the user-provided input template(s) within which a trigger is optimized, with optional per-input targets. Instantiating and assembling the four yields a distinct executable recipe that crafts an optimized trigger. TROPT’s design is guided by two key technical principles. First, modularity: each of the four components can be swapped largely independently of the others. Second, backend–frontend separation: model-specific and infrastructural logic (e.g., trigger-input templating, batching, gradient or loss computation) is absorbed into the model “backend,” keeping the exploratory loss and optimizer “frontend” components—which most researchers extend and experiment with—lightweight, self-contained, and focused on their algorithmic substance. Concretely, our design answers the requirements outlined in the introduction (§1)—each empirically exercised in our evaluation (§4)—as follows: 1. Accessibility. Existing optimizers are re-implemented under a single, tested infrastructure, so numerous recipes run out of the box and new ones can be composed alongside them. 2. Adaptability. An existing optimizer applies seamlessly across supported model types (LMs, encoders, classifiers) and compatible objectives, carrying advances from one domain (e.g., LLM jailbreaks) directly to another (e.g., auditing classifiers). 3. Comparability. Fixing a recipe and varying only one component isolates its contribution, enabling head-to-head comparisons that track progress along each component rather than confounding it with implementation differences. 4. Extensibility. Adding a new loss or optimizer requires only implementing a standardized interface: shared infrastructure is handled by the framework, and existing implementations serve as transparent references. The new component then immediately composes with every existing one. 3.2
Composing Recipes
TROPT also enables custom composition of optimization recipes—concrete instantiations of all four components (target model, loss, optimizer, and input setup) expressive enough to cover a wide range of discrete optimization applications, including attacks and model auditing. Composing a recipe from existing TROPT components takes a few lines of code, assembling compatible component instances (e.g., if an optimizer requires gradients, the model must expose them). For example, Code 1 implements an LLM-jailbreak recipe. This recipe pattern lets users reproduce existing methods, port an optimizer to a new model or domain, swap in a different loss, or recast the problem by varying input templates—significantly lowering the barrier to adopting discrete optimizers. For instance, in §4.3 we seamlessly repurpose a powerful black-box LLM-jailbreak optimizer for corpus poisoning—a novel composition not attempted in prior work—to successfully attack OpenAI’s proprietary embedding model. 3.3
Adding a New Loss
Adapting a recipe to a new domain or problem setting may require adjusting its objective. The loss component defines the quantifiable objective: given the trigger combined with the input templates and their targets, it computes a value to be minimized, optionally backpropagating through the model. Loss implementations are self-contained and agnostic to the target model—consuming whichever standardized signals the model exposes (e.g., output logits, output embeddings, attention scores, or activations)—reducing the friction of adding new losses. As an example, Code 2 fully implements a custom loss for optimizing inputs that steer the model’s internal activations along a specified direction (e.g., the refusal direction; Arditi et al., 2024). Such a custom loss drops into any recipe compatible with its signal requirements (e.g., exposing activations), including the LLM-jailbreak recipe above (Code 1). 5
from tropt.model.huggingface import LMHFModel from tropt.loss import PrefillCELoss from tropt.optimizer import GCGOptimizer from tropt.common import Targets # Component 1: Target Model model = LMHFModel("meta−llama/Llama−3.1−8B−Instruct") # Component 2: Objective loss = PrefillCELoss() # Component 3: Optimizer (wired w/ the model and loss) optimizer = GCGOptimizer(model=model, loss=loss, num_steps=500) # Component 4: Input templates and their target values templates = ["Tell me how to pick a lock. {{OPTIMIZED_TRIGGER}}"] targets = Targets(target_response_strs=["Sure, here’s how:"]) # Compose and run result = optimizer.optimize_trigger( templates=templates, targets=targets, initial_trigger="! " * 20 ) print(f"{result.best_trigger_str=}")
# print the best trigger
Code 1: Composing a TROPT recipe requires only instantiating its four components: the model (an LLM from HuggingFace), the loss (Cross Entropy on a prefilled target response), the optimizer (the GCG algorithm), and the input placing the trigger as a suffix to a harmful instruction, paired with a target affirmative response. Together they reproduce the LLM jailbreak by Zou et al. (2023). Crucially, by merely swapping components this recipe pattern extends to countless applications.
TROPT already ships with a diverse set of 16 losses operating on models’ logits (Zou et al., 2023; Thompson and Sklar, 2024; Andriushchenko et al., 2024), output embeddings (Zhong et al., 2023; Ben-Tov and Sharif, 2025), attention scores (Wang et al., 2024; Ben-Tov et al., 2025), and LM-as-ajudge outputs (Andriushchenko et al., 2024; Zhang et al., 2025b), along with a meta-loss consisting of any weighted combination thereof. Detailed list in Table 3. 3.4
Adding a New Optimizer
Beyond customizing the loss, TROPT also streamlines the implementation of new optimizers—forking existing ones or developing novel search algorithms. TROPT’s optimizers are the central component: given a model, loss, and input setup, they search for a trigger minimizing the loss. Optimizers are isolated from model- or loss-specific infrastructural logic—keeping their implementations focused on the search algorithm itself. A new optimizer thus tests immediately across multiple models, objectives, and domains, supporting reliable comparison and accelerated prototyping. A key design choice of TROPT is making each optimizer a standardized self-contained module: a single file holding the full search algorithm, implemented with a standardized interface, with no logic shared across optimizers. This maximizes readability, comparability, and modifiability, at the cost of some code repetition—a philosophy inspired by HuggingFace’s modeling files.1 As an example, Code 3 fully implements a custom optimizer that contains only the search logic and computes the loss by invoking a unified interface; thus, it contains no input handling, batching, modelspecific loss computation, or monitoring code, all of which the framework handles automatically. This optimizer drops into any recipe compatible with its model-access requirements (e.g., Code 1). TROPT ships with a broad catalog of 17 optimizers, spanning foundational ones (HotFlip (Ebrahimi et al., 2018), GCG (Zou et al., 2023)), GCG-based improvements (Sitawarin et al., 2024; Zhang and Wei, 2024), continuous-relaxation methods (Wen et al., 2023; Guo et al., 2021), and black-box optimizers (Sadasivan et al., 2024; Andriushchenko et al., 2024). Detailed list in Table 2. 1 HuggingFace’s transformers package treats model implementations as the source of truth and packs each into a single
file for visibility and hackability, even at the cost of code repetition (Hugging Face, 2025).
6