Jev and SafeSocial arrive in WebBrain 36.8.0

WebBrain 36.8.0 ships two optional features that both use a small model to keep a larger system focused: Jev helps choose a browser operation, while SafeSocial classifies Instagram images on your device. They sound like variations on the same idea. In practice, they taught us a useful lesson: a small model can be excellent when the question is narrow, but adding one to a general browser loop does not automatically make the loop faster.

Two small models, two very different jobs

The headline for 36.8.0 is easy to summarize: Jev and SafeSocial are now available in WebBrain. The more interesting story is that they solve almost opposite problems.

Jev sits beside the main browser agent. It looks at a bounded, structured view of the page and can classify the next supported operation: click, fill, select, check, scroll, wait, or a possible completion. The larger model remains available for reasoning, visual input, unsupported controls, text generation, and verification. In other words, Jev is not a replacement brain. It is a fast decision layer around one.

SafeSocial is much narrower. It looks at an Instagram image or video poster and answers a small set of classification questions: does this look like romance and jealousy, luxury and status, travel and lifestyle, social FOMO, or another selected social-comparison category? If the score crosses the configured threshold, WebBrain can blur, hide, dim, or warn before you decide whether to reveal the image.

That difference matters. A classifier does not need to understand the whole task if the decision boundary is clear. A browser agent usually does.

Jev: a classifier plus an LLM

The simplest way to think about our Jev integration is classifier + LLM.

The browser state is converted into a compact inventory of observed controls. Jev classifies the next operation and, when needed, the target control from that inventory. If the chosen operation is filling a field, a language model still prepares the text value. If the page requires visual understanding, an iframe, a canvas, a file upload, an arbitrary keyboard widget, or an action outside the supported set, WebBrain falls back to the main model. A selected target is also bound to the observed document state and checked again before execution.

This arrangement is attractive for a reason: most browser steps are not open-ended writing. On a stable page, “click this visible button” is a much smaller question than “reason over the entire browser transcript, tool schema, and screenshot, then emit a valid tool call.” A specialist can answer that small question with a smaller output space.

But the sidecar has to pay for its own existence. WebBrain still has to observe the page, construct the bounded state, make the Jev request, validate the result, and decide whether the main model is needed. On a workflow that frequently changes pages, asks for screenshots, needs verification, or falls back to the main model, those extra steps can dominate.

The honest performance result

This is where our experience differs from the excitement around Jev integrations in the community.

The Browser Use Jev Ultrafast project reports a 25% lower median task time in a small matched Google Flights comparison: 9.450 seconds to 7.092 seconds. It also reports a large reduction in browser protocol calls, from a median of 1,092 to 101. The performance notes are unusually clear about the boundaries: six alternating runs, one task, one Chrome profile, three pairs, and no claim that this is a broad agent benchmark. The community discussion on X captures the same basic promise: Jev can make browser agents dramatically faster when the loop is shaped around indexed actions and a small helper model.

We did not get that performance gain from Jev in WebBrain.

That is not a claim that Jev is slow, or that the Browser Use result is wrong. It is a report about our workload and our architecture. In WebBrain, the main model often has to handle more than a clean action selection: screenshots, page interpretation, values that depend on the task, safety gates, stale-page recovery, completion evidence, and sites that do not fit the narrow structured-control path. Jev is useful when it can confidently take a small, supported step. It is less useful when the system has already paid for the observation and still needs the main model immediately afterward.

So the current 36.8.0 recommendation is modest: enable Jev if you want to experiment with a fast action sidecar and have a TypeSafe configuration available, but do not turn it on expecting a guaranteed speed multiplier. Measure your own tasks. The result may change as the state representation, fallback policy, and action coverage improve.

SafeSocial: the small model that fits the question

SafeSocial has a much friendlier performance story because its job is deliberately small.

It is an optional local multilabel image classifier, not a chat provider. SafeSocial is our homegrown model: we built the trigger classifier for WebBrain's social-comparison use case, then published it on Hugging Face so other projects can use it too. Enabling it downloads a 13.6 MB EfficientNet-Lite0 model from Hugging Face once and keeps it in the browser. The image classification runs on the device. It is off by default, and it only operates on Instagram images and video cover images.

This is an important distinction from a private feature checkpoint. The browser integration is ours, but the model is available as a standalone artifact. If you are building a feed filter, a browser extension, a batch-analysis tool, or another local-first experiment, you do not need to reproduce the WebBrain UI to try the classifier. Start with the public SafeSocial model, then make your own decisions about labels, thresholds, and presentation.

The current categories are designed around social-comparison triggers:

• Romance and jealousy
• Social FOMO
• Luxury and status
• Travel and lifestyle
• Body and beauty comparison
• Achievement and success
• Popularity
• Exclusivity and access

You choose which categories matter to you, adjust the score threshold, and choose what happens on a match. A filtered image can always be revealed. The classifier is not a safety guarantee; its scores are model estimates, and the feature is intentionally experimental.

The model is only about 13.6 MB, but the important part is not the file size by itself. The important part is that the model asks a question with a small answer space, at the moment an image enters your feed. It does not need to write a paragraph, navigate a site, infer a multi-step goal, or decide whether a task is complete. It needs to produce a useful enough label quickly.

For those moment-to-moment Instagram decisions, the simple classifier has been surprisingly effective in our hands. That is the kind of result we want from an optional feature: small enough to ignore if you do not need it, local enough to keep the classification on your device, and focused enough that we can explain what it does.

Why the contrast is useful

Jev and SafeSocial are both examples of the same broad engineering instinct: route a narrow decision to a smaller model instead of asking a general-purpose model to do everything.

The instinct is sound, but the economics are different.

For SafeSocial, the classifier replaces a decision that would otherwise require your attention. It runs at the edge of the feed, with a fixed set of labels and a local model that is small enough to download once. There is no need to wake a general LLM for every image.

For Jev, the classifier is inserted into a larger agent loop. It can reduce the burden on the main model, but it also adds a remote decision, a state-extraction path, validation, and fallbacks. It wins when those costs are smaller than the reasoning work it avoids. It loses, or simply breaks even, when the workflow is dominated by visual reasoning, page transitions, or verification.

This is also why “small model” is not a performance category by itself. The right questions are:

1. What is the exact decision boundary?
2. How often can the small model answer without a fallback?
3. Does preparing and validating its input cost less than the work it replaces?
4. What happens when it is uncertain?

SafeSocial has a clear answer to all four today. Jev is still an active experiment for our broader browser-agent workload.

What to expect in 36.8.0

Both features are optional.

Use Jev when you want to test the classifier-plus-LLM browser path on your own tasks. Keep the main model responsible for the parts that require reasoning, visual understanding, unsupported controls, and independent completion checks.

Use SafeSocial when you want a configurable buffer against selected Instagram comparison themes. It starts disabled, downloads its small model only when you prepare it, classifies locally, and lets you reveal anything it filtered.

The larger lesson from this release is pleasantly unglamorous: we shipped both features, measured them honestly, and got two different answers. Jev may become faster for WebBrain as the path gets narrower and more of the browser loop can be served by structured decisions. SafeSocial already demonstrates how far a simple, focused classifier can go when the question is small enough.

That is a good place to start.

Tags: #WebBrain #WebBrain368 #Jev #SafeSocial #TypeSafe #BrowserAgents #LocalAI #Instagram #ImageClassification