Osprey 1.1.0: Easier to Use, Extend, and Test
Written by
Juliet Shen
Published
Osprey spent its first release cycle proving it can carry trust and safety operations at scale, processing more than 50 million events a day in production at organizations like Bluesky and Discord as it encodes platform-specific rules and supports live investigations. With 1.1.0, we've turned our attention to how we could improve working in Osprey day to day.
We shaped this release around patterns we kept seeing during the 1.0 cycle. Investigators couldn't tell what rules and signals their own deployment was configured with unless they went and read the source in GitHub. The interface only came in a single light theme, which wears on anyone staring at it for a full shift. Teams that wanted to embed Osprey in a modern async Python codebase ran into a compatibility wall, and anyone benchmarking a change had to build their own load generator, so no two sets of numbers could be compared. None of this stopped Osprey from doing its job, but these were rough edges for users.
Here’s what’s new at a glance.
In the interface
Investigators spend their days inside Osprey, querying events, writing and debugging rules, and keeping the system healthy, and that's where much of this release lands.
One of the most requested quality-of-life improvements, dark mode, is here! Whether you work day or night—or just prefer using a dark style—Osprey will follow your system color scheme by default, with an override toggle in the top bar. Alongside it, the flat top-bar navigation has become a persistent left sidebar organized around how investigators commonly work: an Investigate section for querying and saved queries, a Manage section for rules and signals, and an Operate section for bulk jobs. The sidebar collapses to an icon rail when you need the horizontal space, and any page you don't have permission for simply isn't shown.
Two new reference pages answer a question adopters asked us constantly, which is how to quickly see what their Osprey instance is actually set up to do. The Rules Registry lists every rule loaded into the engine along with its source file, description, the signals it draws on, and how many other rules depend on it. During an incident it's a quick way to find which rule fired without leaving the interface, and it flags any rule that points at something that has been deleted. The Features Registry does the same for signals, so before you write a rule you can see what data is available to reference.
New building blocks for rules
Rule writers get four new built-in functions:
String slicing, which pulls out a substring by index and stays forgiving on out-of-range values instead of failing the rule
Integer parsing, which turns a string into a number and hands back a structured failure you can branch on rather than a crash
An experimental membership check, which tells a rule whether a user or entity falls in a named cohort so behavior can depend on it, for instance enforcing only against a treatment group
Action ID access, which makes the triggering action's identifier available inside evaluation so a rule can reference it without the caller passing it through by hand
Under the hood
For the engineers who support investigators and the people working in the codebase itself, several layers of the stack got attention.
The largest is a new runtime built for asynchronous programming in Python, aimed at teams who want to embed Osprey inside that kind of codebase. It can evaluate rules in parallel and treats async plugins as first-class, and a rule behaves identically whether it runs there or on the original runtime. That original runtime hasn't changed and stays the default and the supported path for production, so no one running Osprey today has to do anything. The new one is experimental, and we mean that: its plugin interface may still shift, and we'd rather integrators run it and tell us what breaks than wait for us to declare it finished, which is how it earns supported status.
Testing got easier too. Until now every performance-related pull request came with its own improvised load generator, which meant no two benchmarks measured the same thing. The release includes a reproducible load-testing harness that runs events through Osprey at a rate you set and reports latency percentiles, throughput, and error rates, so a reviewer can rerun the exact scenario a change claims to handle. Because it can generate serious load, it assumes a local environment by default and refuses to point itself at anything whose topic names look like production. Alongside the synthetic generator, the release includes ATProto plugins and rules that consume the AT protocol firehose over JetStream, which doubles as a reference for wiring up a live, non-Kafka event source and as a way to exercise Osprey under real, production-scale load rather than only synthetic traffic.
The metrics have deepened as well. Osprey now answers, without custom instrumentation, whether a given worker is healthy, whether a rule is firing the way it should, and which actions are failing at the moment. Every rule evaluation writes a structured audit entry you can reconstruct an incident from, and a new enforcement-gap metric surfaces the delay between an event arriving and its rule actually firing, which is often the earliest sign that Osprey is falling behind. Rounding things out, results can now be stored in Postgres, and the frontend build and contributor tooling are considerably faster and cleaner, which won't show up for anyone using Osprey but makes the project more pleasant to work on.
What’s coming next
Rules and queries in Osprey are written in SML, which is expressive but has a learning curve for a new team. This release lays the groundwork for asking Osprey questions in plain language. An early version of the interface was first demoed at TrustCon 2026 in San Francisco. The part that is available now is a stable extension point for connecting whichever large language model provider you prefer, whether that's OpenAI, Anthropic, or something you host yourself, without forking the codebase. A working Anthropic provider comes with the release as a reference, and the whole thing is opt-in: register nothing and Osprey behaves exactly as it does today.
Another experimental feature coming as a fast follow will open up rule editing inside the interface. When you draft or change a rule from the Rules Registry, Osprey logs it in a database table for Draft Rules, for further review and deployment. Nothing takes effect until the change is merged and the engine reloads, so who can change what stays exactly how it works in 1.0 today—but we hope this shows how we're planning to tackle rule authoring while enabling us to iterate on the UI as we receive feedback.
If you're already running Osprey
Osprey uses semantic versioning to label its releases; this release is what’s called a “minor release.” That means upgrading gets you the reference pages, the new metrics, and the new rule functions without changing how your deployment behaves. A rule that ran on 1.0 runs the same way on 1.1.0, the original runtime is still the default, and the new runtime, in-app rule editing, and query scaffolding are all opt-in and marked experimental.
Thank you to our contributors
Osprey is built in the open, and would not be possible without the community. First, a huge welcome to our many first-time contributors this release: @serendipty01, @regiscamimura, @lithium-powered, @bealsbe, @chimosky, @VINODvoid, @taobojlen, @reitblatt, @SemTiOne, and @vedarolap. And thank you to returning contributors @annebdh, @ayubun, @BinaryFiddler, @cassidyjames, @cmttt, @haileyok, @juanmrad, @julietshen, and @vinaysrao1.
If you'd like to help shape what comes next, browse the good first issues, drop into a biweekly Osprey Working Group meeting, or introduce yourself on Discord.
Get started
Osprey 1.1.0 is available now. To try the new reference pages, dark mode, and rule functions on a local instance, follow the Getting Started guide. Existing deployments can upgrade in place.
Osprey is one piece of ROOST's work on open source trust and safety infrastructure, alongside Coop and the ROOST Model Community. If you think safety tooling should be transparent, adaptable, and available to everyone, we'd love for you to try Osprey and help shape where it goes.