Security

Another day, another Windows exploit code

Nightmare Eclipse, the prolific zero-day vulnerability hunter with an axe to grind against Microsoft, released yet another exploit late Wednesday that the researcher claims will spawn a command prompt that provides total access to the BitLocker volume.

This bug, called GreatXML, was “an accidental discovery,” according to the researcher, who said it only took four hours to find. They claim this exploit (published on GitHub and Git-based code-hosting platforms) can bypass BitLocker on any system that has ever run a Microsoft Defender Offline scan at any point in the past.

GreatXML comes just a day after Nightmare released exploit code for RoguePlanet, which allows local privilege escalation and leads to SYSTEM-level control over an affected machine. This brings the researcher’s zero-day count to eight. The earlier six – RedSun, UnDefend, BlueHammer, YellowKey, GreenPlasma, and MiniPlasma – all have patches as of this week’s Patch Tuesday event. 

Redmond on Wednesday told The Register that it is aware of RoguePlanet, and “actively investigating the validity and potential applicability of these claims.” The Windows giant didn’t immediately respond to our inquiries about GreatXML, including when it planned to issue a patch.

Microsoft has said none of the vulnerabilities were reported via its official channels prior to being made public. The company also banned Nightmare’s earlier GitHub account, and seemingly threatened legal action before dialing back its rhetoric after steep backlash from the security community.

Nightmare Eclipse, who some researchers suggest is an ex-Microsoft employee, harbors a very personal grudge against the Windows giant and its communications with bug hunters. They have promised to keep the zero-days coming, but waffle on the timing. 

Last month, the researcher pledged a big July 14 drop: “I will make sure your bones are shattered that day,” and then added, “nothing will be released this June (or maybe I will release smtg, depending on circumstances).”

On Tuesday, they changed course. “I will be unable to mass disclose zerodays in July 14th, RoguePlanet took way more time than expected and truly drained me. I might take a break but I can’t say for sure what I will be doing for next month, maybe it’s nothing, maybe it’s smtg.”

A day later, Nightmare released the “accidental” GreatXML BitLocker bypass. 

According to the researcher, the BitLocker bypass first requires copying “unattend.xml” and the “Recovery” directory to the root of the recovery partition. The next step is rebooting into WinRE by Shift-clicking Restart. “If everything was done correctly, a shell with unrestricted access to the bitlocker volume will spawn,” Nightmare wrote.

Also, if the scan hasn’t even been initiated on the Windows system, first you’d need to either log in and initiate it, or “figure out a way to boot into WinRE in offline scan state.”

Security sleuth Will Dormann followed Nightmare’s steps to reproduce GreatXML, and said the writeup seems “flawed.” In his testing, Dormann said the command prompt appeared the next time a Defender Offline scan ran.

“And in order to trigger a Microsoft Defender Offline scan, you both need to be logged in to Windows, and also have admin credentials,” he wrote on social media. “And if you’ve already got that level of access, you can just turn off bitlocker.”

“The writeup for GreatXML suggests that the prerequisite is that Windows Defender Offline has been executed at some point in the past,” Dormann added. “And that after planting two files in WinRE, all you need to do is [Shift]-reboot into WinRE, and Windows will automatically go into Microsoft Defender Offline scan mode. But this is not the case in any of the 3 lineages of Win11 that I have handy.” ®

from the the-end-of-ten-blue-links dept

Google didn’t invent full-text search of the Internet – that honor belongs to early pioneers such as WebCrawler, Lycos and AltaVista. But for the last 25 years or so, Google has been synonymous with online searching, providing the quickest and most effective way to find things online (although its results may be getting worse.) More recently, it has been adding to its search engine more features based on generative AI, first with its AI Overviews in 2024, and then a year later with its AI Mode in Search. Now it has announced the latest stage in that evolution with what it calls “A new era for AI Search”:

It’s more intuitive than ever, dynamically expanding to give you space to describe exactly what you need. Designed to anticipate your intent, it also helps you formulate your question with AI-powered suggestions that go beyond autocomplete. And you can search across modalities, using text, images, files, videos or Chrome tabs as inputs.

This new incarnation effectively turns search into a chatbot:

You can easily ask a follow-up question right from an AI Overview, and flow into a conversational back and forth with AI Mode. Your context stays with you, and as you explore more deeply, the links and supporting articles get even more relevant. This seamless experience is live today across desktop and mobile, worldwide.

As the the screenshot of the new interface above shows, the traditional search result links that are currently placed under the AI Overview have now been confined to a small panel on the right-hand side of the screen, which shows a cut-down version of today’s list. Users are encouraged to ask follow-up questions from the AI search chatbot, rather than exploring the links themselves.

What this is likely to mean in practice is that even fewer people will follow links to sites, something that was already happening last year; instead, they will engage with Google’s chatbot to gather information indirectly. This is terrible news for access to knowledge because it frames the Google AI search engine as the fount of all knowledge – one that will do all the hard work of finding information and combining it into an easily digested answer that can be interrogated further. It can do that because it has already ingested billions of Web pages and other information sources as part of the Large Language Model (LLM) training process. But search engine users will no longer know what some of those sources are unless they painstakingly click on the links in the new panel.

Most people will not bother, because the AI-generated results will be good enough – or at least will appear to be good enough. Unless visitors to the site take the trouble to follow the links to the sources they won’t really know how reliable those results are. For example, it is possible that the sources are wrong, or misleading; moreover, Google’s LLM may itself introduce new errors and distortions. There is also the question of how Google will insert ads into this AI-generated information, and to what extent advertisers will be able to buy preferential treatment in results.

This new mediated approach is clearly terrible news for Wikipedia – an issue already discussed on Walled Culture earlier this year – and for creators. Google will use the information found in their works, but will not actively encourage people to visit the originals. For many people, summaries will be good enough, and they will never discover the greater riches of the sites and creations that Google’s LLM is based on. Worse still, the original creators such as Wikipedia may not even be mentioned in answers that involve aggregating information from a large number of sources.

Similarly, the new Google search is the publishing industry’s worst nightmare. Not only is Google drawing on material they have published, but it is pushing links to those sources into the background. It seems inevitable that the Web traffic to publishers will fall yet further, making already struggling business models based on advertising even more precarious. That will have knock-on consequences for the funding of many sites – particularly newspapers and magazines – and for the commissioning of work from journalists and other creative professionals. Users won’t even need to visit Google Search much in order to keep up-to-date with topics of interest thanks to Google Search’s new agentic capabilities that will do the work for them in advance:

With information agents, you can stay updated on whatever matters most to you. Your agent will intelligently look across everything on the web, like blogs, news sites and social posts, plus our freshest data, such as real-time info on finance, shopping and sports, to monitor for changes related to your specific question.

In this case, not only will people not visit sites, but the latter will be constantly bombarded by various AI bots seeking information on behalf of users – increasing site running costs, and making sites less usable by humans. Another key announcement from Google will lead to a further flood of agentic activities that will pose new challenges to businesses:

We’re also expanding agentic booking capabilities in Search to a wide range of new tasks, including local experiences and services. Just share your specific criteria — like finding a private karaoke room for six on a Friday night that serves food late — and Search brings together the latest pricing and availability with direct links to finish booking through the provider of your choice. And for select categories like home repair, beauty or pet care, you can ask Google to call businesses on your behalf.

What emerges from Google’s latest announcements is less of a search engine, and more of an immersive virtual environment that is designed to keep people engaging with Google’s services, asking them for information, advice and even delegating actions to them. There is no doubt that many users will find these new features attractive, not least because they can use “conversational voice features” in Gmail, Docs and elsewhere. These are the digital assistants that have been promised for many years, able to understand spoken commands, provide information verbally, and carry out complex operations on behalf of users without the need for any complex training. For many people, that will be a boon, and they will doubtless migrate from the traditional search page, which will still be the default – at least for now – to the latest AI-infused version.

But these impressive technical features come at a high price, even leaving aside issues such as the environmental impact of the huge server farms they require. With the latest incarnation of its search engine, Google is making the World Wide Web as we have known it for over 30 years invisible, and therefore increasingly irrelevant to most people, who will be happy to let Google become their universal user interface to everything. And yet Google still depends on the Internet to supply all the information it is analyzing and repackaging. It risks killing the very thing that sustains it.

There’s another, more subtle issue. The new Google search features make finding information and carrying out actions very easy in many ways. Leaving aside the problem that this will require people to trust what is in effect a huge black box, where the internal workings cannot be examined, with all the loss of control this implies, there is another danger. People who use Google’s powerful new AI search services to offload many of their day-to-day actions may gradually lose the ability to understand the world and to act within it without that constant help. Such a dependence may be great for Google and its advertisers, but it surely cannot be a good thing for the future of society.

Follow me @glynmoody on Mastodon and on Bluesky. Originally published to WalledCulture.

Filed Under: ai, links, open web, search

Companies: google

Here is a constraint that almost no one building physical AI says out loud, even though every one of them is quietly fighting it.

A robot’s intelligence wants three things at once. It wants to be smart, meaning it can reason at the level of a frontier model about an unfamiliar scene. It wants to be fast, meaning it responds inside the tight, deterministic timing a physical control loop demands. And it wants to be free, meaning it keeps working when the network drops, the warehouse Wi-Fi dies, or the machine goes somewhere no signal reaches.

You cannot have all three on one piece of compute. Pick any two.

To be precise, bounded autonomy already works. Industrial arms, drones, and constrained autonomy stacks can be fast and offline because their tasks are narrow. The trilemma bites at the frontier: you cannot put frontier-scale general reasoning, deterministic real-time response, and full offline autonomy into the same power-limited substrate, not for the same control loop.

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol’ founder Boris, and some questionable AI art. It’s free, every week, in your inbox. Sign up now!

A frontier-scale model is smart, and if you stream its sensors to a datacenter it can even be fast, but now it is tethered to a network and no longer free. Shrink that model until it fits on a 15-watt embedded module and it becomes fast and free, but it is no longer frontier-smart. Run the big model in the cloud and query it only occasionally, and you get smart and free, but never fast. Three corners, two available at a time. I have come to think of this as the embodied trilemma, and it is the real reason the edge/cloud question is the hardest architecture decision in robotics. Most teams treat it as a deployment detail. It is closer to a law.

Why you can’t cheat the triangle

The trilemma is not a fashion or a temporary hardware limitation you can wait out. It falls directly out of physics and power budgets.

Frontier reasoning quality currently lives in models that want tens of gigabytes of memory and datacenter-class accelerators. That hardware does not run on a battery a mobile robot can carry. So “smart” forces a choice: either bring the datacenter to the robot through a network link, which sacrifices freedom, or accept a smaller onboard model, which sacrifices smartness.

Real-time control is even less negotiable. A wide-area network round trip adds 30 to 100 milliseconds of latency, and the variance matters more than the average. A control loop that is usually fast but occasionally stalls is worse than one that is reliably mediocre, because controllers are tuned for deterministic timing. The moment “fast” depends on a network, you have surrendered “free,” because the network is now inside your control loop whether you meant it to be or not.

So the triangle holds. Quantization, distillation, and better accelerators move the corners, but they do not collapse them. Anyone claiming otherwise is usually hiding which corner they gave up.

Putting numbers on the triangle

It helps to make the constraint quantitative, because the moment you write the timing down, the corners stop being abstract.

Start with latency. The end-to-end delay of a perception-to-action decision made in the cloud is a sum of terms:

L_cloud = t_capture + t_encode + t_uplink + t_inference + t_downlink + t_decode

Run the same decision onboard and most of that sum disappears:

L_edge = t_capture + t_{inference,local}

The difference between the two is not the inference time, which can actually be lower in the cloud on better hardware. The difference is the network, t_uplink + t_downlink, and more importantly its variance. A measured cloud-robotics setup over a fast wired link saw round trips of roughly 30 milliseconds [7], while real-world deployments commonly sit in the 100 to 300 millisecond range, and wireless links swing far higher. Edge processing, by contrast, pulls round trips down toward 1 to 5 milliseconds because nothing leaves the machine [8].

Now state the rule that decides where a loop can live. A control loop with timing budget L_budget can run on a given compute path only if

L_path + k·σ_jitter ≤ L_budget

where σ_jitter is the standard deviation of the path’s latency and k is the safety factor you need for determinism. That k·σ_jitter term is the quiet killer. Teleoperation studies are blunt about it: a link that holds a steady 100 milliseconds is workable, but one oscillating between 30 and 200 milliseconds produces jerky, unpredictable motion, because the controller cannot plan around delay it cannot predict [9]. The reflex loop’s budget is 1 to 10 milliseconds. No wide-area path satisfies the inequality. The math, not the architect, forbids it.

The table is the argument in one view. Reflex never clears a network round trip. Perception clears it only on unusually good links. Deliberation has budget to spare, which is why it can live in the cloud asynchronously.

Bandwidth closes the case for perception. A single 1080p camera at 30 frames per second produces raw video at 1920 × 1080 × 3 bytes × 30, which is about 1.5 gigabits per second. A modest four-camera plus depth rig clears 6 gigabits per second of raw sensor data. You can compress it, but compression costs latency and the link still has to carry it reliably, everywhere the robot goes. Edge perception is the robotic version of that move. Compress to a semantic representation on the spot; never ship the raw stream.

Finally, the economics, which is just the trilemma with a dollar sign. Onboard compute is a one-time capital cost. Cloud reasoning is an operating cost that accrues with every query:

C_cloud(t) = r·c_token·t

where r is the query rate and c_token the per-token price, against a flat C_edge = C_capex. The two lines cross at t* = C_capex / (r·c_token). Push thirty frames a second to a cloud model and t* arrives almost immediately, so cloud cost dominates the lifetime of the fleet. Route only a few deliberation-class queries per minute upstream and t* recedes over the horizon.

Same hardware, same models, opposite economics, decided entirely by which loop you placed in which corner. The gap is not subtle: a single camera streamed to a cloud vision model at 30 frames per second is on the order of a million inference calls a day per robot, while routing only deliberation-class queries upstream might be a few hundred. Across a fleet, that is the difference between cloud inference being a rounding error and being the largest line on the operating budget.

The escape nobody designed, because biology did it first

Here is the part I find beautiful, and the heart of what I want to argue: the way out of the embodied trilemma is not to solve it. It is to refuse to answer it at a single point.

Your own body is built this way, and it has been for roughly half a billion years.

When you touch a hot stove, your hand pulls back before your brain knows anything happened. That is the spinal reflex arc, a loop that runs through the spinal cord and never waits for the cortex. It is fast and free (it works even if you are barely conscious), and it is emphatically not smart. It does not reason about the stove. It does not need to.

Your retina does something just as telling. It has over a hundred million photoreceptors, but the optic nerve carrying signal to the brain has only about a million fibers [10]. The eye does roughly a hundredfold compression on the spot, locally, before transmitting anything. It does not ship raw pixels up the cable. It ships a processed, compact representation. Fast and free at the edge, by necessity.

And then there is the cortex, which is where the actual reasoning happens. It is slow, it is powerful, and crucially, the body has arranged things so that when the cortex is slow or offline, the reflexes still fire and you still pull your hand back. Evolution put the survival-critical functions where they never depend on the smart, slow part.

That is the whole trick. Biology never built a single neuron that was smart, fast, and free all at once. It built a hierarchy in which different loops each sit at a different corner of the triangle, and it made sure the corner each loop sacrifices is one that loop can afford to lose. Reflexes give up intelligence, which is fine, because a reflex that stops to think is a reflex that gets you killed. The cortex gives up speed, which is fine, because it has been kept off the survival path entirely.

A robot escapes the embodied trilemma the same way, or it does not escape at all.

Mapping the triangle onto a machine

Translate the nervous system into engineering and a practical architecture emerges. A robot has three loops, and each one belongs at a different corner.

The reflex loop (1 to 10 ms): motor control, stabilization, emergency stops. This is the spinal cord. It must be fast and free and is allowed to be dumb. It lives onboard, always, and never touches a network.

The perception loop (30 to 100 ms): detection, tracking, obstacle avoidance, visual odometry, SLAM. This is the retina. It must keep working when the link drops, and the bandwidth math forbids shipping raw sensor data anyway, since even a single camera produces well over a gigabit per second of raw video before compression. So perception compresses at the edge, exactly as the eye does, and emits a compact semantic representation rather than pixels. Fast and free, intelligence traded away on purpose.

The deliberation loop (1 to 10 seconds): task planning, language understanding, deciding what to do when the plan breaks. This is the cortex. It is allowed to be slow, and slowness is exactly the corner it trades away, reaching a frontier model in the cloud asynchronously rather than in the control path. It stays free in the only sense that matters, never holding the robot hostage to a live link. If connectivity vanishes, the robot gets less clever, not less safe.

The interface between these layers is the optic nerve of the system: a deliberately narrow channel carrying detections, tracks, and state summaries, never raw signal. Get that channel right and you have not just an inference boundary. You have defined your logging schema, your training-data pipeline, and your behavior when the link drops, all at once.

The industry is rediscovering the nervous system

What convinces me this is structural, not stylistic, is that the most advanced robotics programs keep reinventing the same hierarchy without necessarily naming it.

Figure AI’s Helix, the system running its humanoid robots through full eight-hour factory shifts, is explicitly two systems: a roughly 7-billion-parameter vision-language model at 7 to 9 Hz for scene understanding and language, coupled to a compact 80-million-parameter visuomotor policy that turns intent into continuous action at 200 Hz [1]. That is cortex and reflex on one robot, a 25-to-1 ratio in update rate between the loop that thinks and the loop that acts, each running at the timescale its job demands. Surveys of edge-cloud collaboration now describe the same division as standard practice, with small onboard models handling real-time perception and privacy-sensitive preprocessing while heavier reasoning is offloaded upstream [4].

Comparisons on real robot data quantify the trade directly: deploying an 11-billion-parameter vision-language model at the network edge held accuracy close to its cloud baseline while shaving only modest latency, whereas a compact 2-billion-parameter model more than halved latency into sub-second territory, paying for the speed with accuracy [5]. Reviews of foundation-model robotics keep flagging the same wall: LLM planners take seconds per decision, fine for the cortex, hopeless for the spinal cord [6]. NVIDIA’s own Jetson deployment guidance reflects it too, with optimized onboard inference for perception and policy and larger models living upstream [2].

Different teams, different machines, the same triangle, the same corners. When that many independent efforts converge, you are looking at structure, not style.

Lessons from the ultimate airgap

The starkest place to watch the trilemma bite is underwater robotics. An ROV below the surface has effectively no real-time link to the cloud. The ocean is the ultimate airgap, the freedom corner taken to its absolute extreme. In hands-on underwater robotics builds, perception (detection and tracking, optimized with TensorRT) runs entirely on an onboard module, while language-level mission interaction and fleet reasoning reach a frontier model in the cloud only asynchronously, on surfaced or relayed data, and never inside a control loop. The architecture is not a preference there. The water enforces it.

Three principles follow, and they generalize far beyond the sea.

Design for the disconnected case first. If the robot is safe and useful with zero connectivity, the cloud becomes pure upside: better reasoning, fleet learning, human oversight. If the robot needs the cloud to stay safe, you have built a cortex with no spinal cord, a liability on wheels.

Treat the narrow channel as a contract, not a cable. The compressed representation crossing the edge/cloud boundary is the single most important interface in the system. Teams that treat it as an afterthought re-architect twice.

Remember the trilemma is also an economics statement. Onboard compute is paid once, at purchase. Cloud reasoning is paid forever, per token. Routing only deliberation-class queries upstream, a few per minute instead of thirty frames per second, changes fleet unit economics by orders of magnitude. Cloud-inference cost can quietly become the largest operating line on a robotics program that put the wrong loop in the wrong corner.

The corners will move. The triangle won’t.

Onboard modules get more capable every generation, and distillation keeps narrowing the gap between edge models and their cloud teachers. Early-exit inference, where confident predictions resolve locally and only hard cases escalate, is maturing fast [3][5]. The deliberation loop will migrate partly onboard over the next few years, especially for safety-relevant replanning. The corners of the triangle will keep sliding.

But the triangle itself does not go away, because it is anchored in physics and energy, not in any model generation. Smart, fast, and free will never coexist on a single substrate as long as frontier intelligence costs more power than a robot can carry and the speed of light caps how fast a remote answer can return. The teams that internalize this, and that consciously assign each loop the corner it can afford to lose, will ship robots that work when the network does not. The rest will keep learning, in the field and at the worst possible moment, that they accidentally wired their spinal cord through a datacenter.

Evolution settled this argument before there were spines. We are just catching up.

Context windows are becoming a computational bottleneck. The longer an agent runs, the more tokens accumulate from retrieved documents, reasoning traces and conversation history, and the more memory and compute that growing context demands. Most existing solutions either degrade model accuracy, require the full context to load before compression begins, or produce memory savings that don’t translate into real speedups in standard serving infrastructure.

A research team from NYU, Columbia, Princeton, University of Maryland, Harvard and Lawrence Livermore National Laboratory published a paper this week that proposes a novel fix. The researchers introduce the concept of  Latent Context Language Models, or LCLMs, a family of encoder-decoder compression models that compress input context before it reaches the decoder. The models are open-sourced on HuggingFace.

Unlike KV cache compression methods — the dominant approach in the field, which still materialize the full KV cache before evicting entries — LCLMs compress the input token sequence before decoder prefill, so higher compression ratios directly reduce decoder-side compute and memory. The paper reports LCLMs at 16x compression produced output 8.8 times faster than KV cache baselines on the RULER long-context benchmark.

“These ballooning contexts take up memory and compute, and they are becoming a computational bottleneck for LLMs,” Micah Goldblum, co-lead advisor on the project and a researcher at Columbia University, told VentureBeat. “Our goal was to train language models end-to-end that can handle very long contexts efficiently and accurately. If you can make such a language model, everything becomes cheaper and faster.”

What LCLMs can do

LCLMs let models process much longer contexts than would otherwise be practical, at a fraction of the memory and compute cost, without the accuracy degradation that makes most compression methods a poor tradeoff in production.

At 4x compression, the paper reports accuracy of 91.76% on the RULER benchmark, compared to 94.41% with no compression at all. That is less than a 3 point drop for cutting context to a quarter of its original size. At 16x compression, where 93.75% of input tokens are removed, accuracy fell to 75.06%. Every KV cache method tested at the same compression ratio scored lower.

The gains hold on shorter inputs too. On GSM8K math word problems, where the full prompt is compressed rather than just retrieved documents, LCLMs outscored every other method tested regardless of compression ratio.

How it was built

The architecture pairs a 0.6B encoder with a 4B decoder. The encoder compresses blocks of input tokens into shorter sequences of latent embeddings. The decoder processes those in place of the original tokens. Training ran across more than 350 billion tokens.

The training recipe mixes three data types:

• Continual pre-training data with compressed and uncompressed spans interleaved throughout

• Supervised fine-tuning data covering reasoning and long-context tasks

• An auxiliary reconstruction task that pushes the encoder to retain fine-grained detail

The combination addresses a tradeoff that limited earlier compression work, where preserving reconstruction accuracy came at the cost of general task performance.

An architecture search identified the optimal configuration. The paper found that scaling the decoder matters more than scaling the encoder.

Where it fits in an agentic stack

An LCLM is not an abstract research concept. It is designed to work with an existing stack. “You can simply swap out LCLMs for any existing LLM,” Goldblum said. “Whenever you retrieve data such as documents and want to dump it into your model’s context, simply run those documents through the LCLM’s compressor first.”

He noted that in the research paper, the researchers demonstrated how to build agents that selectively decompress useful text. 

“Think about this like a human skimming content before zooming in on relevant details,” Goldblum said.

Goldblum also cautioned that teams integrating the approach into existing agentic pipelines will need to tune their RAG systems accordingly.

“We also haven’t worked on online compression of reasoning traces,” he said. “The naive approach of just occasionally compressing the trace while generating it might work, but that remains to be determined.”

What this means for enterprises

Context windows are growing faster than inference infrastructure can keep up, and enterprises are already spending to fix it. VB Pulse Q1 2026 survey data from 100-plus employee organizations shows hybrid retrieval adoption intent tripling from 10.3% in January to 33.3% in March. Retrieval optimization overtook evaluation as the top investment priority by March, reaching 28.9% of qualified respondents.

Three things stand out for teams evaluating production fit:

1. Inference cost scales with context length. At 1 million tokens, uncompressed inference with standard KV cache methods runs out of memory on a single H200 GPU. The paper reports LCLMs at 16x compression remain within memory bounds at that context length.

2. RAG pipeline integration requires tuning. Teams with existing RAG pipelines will need to validate compression behavior against their retrieval quality metrics before deploying at scale.

3. Reasoning trace compression is unsolved. For agents running long reasoning chains, context growth from the trace is a separate problem from document retrieval. Goldblum acknowledged the gap directly: the naive approach of periodic trace compression might work but has not been tested.

The models are available at huggingface.co/latent-context and the code at github.com/LeonLixyz/LCLM.

“The biggest things our architectures do is give your model access to much larger contexts, but they also unlock multiscale approaches where your model can skim vast amounts of text or code super fast and then only zooms in and fully reads a small portion of the most useful text,” Goldblum said.

Meta on Wednesday previewed upcoming additions to its video-editing app Edits at an invite-only creator event in L.A., showing off features like a new AI assistant and a desktop version of the previously mobile-only app.

The company also announced other new tools will launch in the app today, such as a “Beta” tab for experiments and expanded audience insights.

Edits first arrived last year as a direct competitor to ByteDance’s CapCut. With the addition of the new and upcoming tools, Meta is looking to both retain and attract new users.

The upcoming AI assistant will help creators analyze their insights and brainstorm ideas for their content. The assistant will use their Instagram data, like their views and video-retention insights, to help them see what’s working and why. It will suggest video ideas based on performance and suggest making content with trending audio.

By integrating an AI assistant directly into Edits, Meta is aiming to keep creators engaged on Instagram as it continues to compete with TikTok and YouTube for creators’ attention. Additionally, by offering creators content ideas, Meta is encouraging more frequent posting, which could, in turn, boost user engagement. Direct access to an AI assistant also gets rid of the need for creators to turn to outside tools like ChatGPT when brainstorming content ideas and understanding performance.

Meta launched a similar AI assistant tool for creators on Facebook last week. It’s worth noting that YouTube and TikTok also offer tools to creators to help them brainstorm ideas. For instance, YouTube Studio features an Inspiration tab that uses AI to help creators generate video ideas, while TikTok offers creators an AI assistant that can brainstorm ideas and uncover trends.

The desktop version of Edits will give creators more precise control over the editing process as well as the ability to work on a larger screen, which can be helpful during more advanced editing workflows. The company says creators will be able to sync their workflows seamlessly between mobile and desktop devices.

The upcoming desktop version will also allow Edits to better compete with CapCut, which already offers a desktop version.

Among the new features launching today is a Beta tab, which will provide creators with early access to experimental features that are still in development and allow them to provide Meta with feedback. The rollout of the Beta tab indicates that Meta wants to better compete with CapCut and accelerate feature development based on what creators actually want and will use.

Creators will also now be able to see more detailed metrics like their audience demographic breakdown and the time of day their audience is the most engaged. The new metrics join the app’s existing analytics, which include data such as how long viewers watch a video, how many followers were gained from a specific video, where users stop watching a certain video, and more.

Additionally, creators can search specific topics within the app’s Inspiration feed to discover reels and templates other creators are making around a given trend or idea. They’ll also be able to create multiple versions of a single piece of content to test what performs best before publishing.

Although Instagram didn’t share specific numbers about how many users Edits has, the company says that content made with the app sees a 10% higher save rate and 2% higher reshare rate compared to content not made on Edits, and that more than half of people watching reels on Instagram are seeing Edits-created content every day. 

Edits is free to download on iOS and Android.

The AI assistant announced today is currently in testing with attendees of Thursday’s creator event, while the desktop version of Edits is “coming soon,” Meta says. The rest of the features are launching to everyone today.