If you listen to music the way a lot of people do these days - with a pair of wireless earbuds, from a Bluetooth speaker, or just blaring directly out of your phone - you will never notice a difference between Spotify's high-quality 320Kbps streams and its lossless audio. But, if you usually listen with wired headphones while working at your desk, or have a quality speaker from the likes of Bose that supports Spotify Connect, there actually is something to be gained here.

Comparing Spotify's normal quality streams (96Kbps) with the new 24-bit / 44.1kHz lossless FLAC files feels unfair. Even a relatively untrained ear should be able to hear …

Read the full story at The Verge.

I started using Warp as my default terminal some time ago, as it has useful tools — for example, time to run a shell command. Other products give you controllable tabbed terminals, but because Warp has written the UI from the ground up with Rust, it has a speed and intentional design that is impressive. Since then, Warp has gone big-time into LLM integration. Originally, I had little interest in that move until the “agentic era” started.

With agentic CLIs, suddenly the LLM has stepped away from the IDE, towards the humble terminal — right onto Warp’s patch.

To summarise what Warp Code offers, think of the different views you need to do simple tasks: file view, editor, diffs, etc. Now Warp gives those to you while coding with the LLM. Older developers will remember that guy or gal who can “do everything from Emacs”. Warp Code is moving in that direction, which we’ll talk about in an interview with Warp CEO Zach Lloyd below.

The Warp Code Changes

Starting with the familiar tabbed screen that we looked at in my review of Warp 2.0, we can see some new work already. At the top left, we have three new icons: </>, a magnifying glass, and a +/- sign.

This is access to the file tree, file search and changes view.

The query window at the bottom is slightly busier, with the terminal icon selected in blue (so Warp will interpret text as strictly OS commands) and we can see some extensive git commit stats and which model we are working with:

I’m going to continue using my simple Rails app for creating conversations, which I also used in my review of Augment CLI or “Auggie”. As before, we simply want to introduce more Bootstrap into one of the views.

Let’s start with a formal codebase indexing. We switch to “agent mode” and use the “/init” command, as we have in other Agent CLIs, to perform the same operation:

This is a more formal recognition of indexing, and I’ll let it start. It also invites me to start a WARP.md file. I can also instruct the agent directly with new Agent Profiles.

It takes time to go through this, then it allows me to inspect the WARP.md file, which collects a few of the important command tools for future use:

Working Through a Query

Let’s ask Warp if it can enhance one more Rails view with Bootstrap.

Looking at my app running, the Rails view of the Voices model uses nice Bootstrap buttons:

But the equivalent Archetypes view does not:

We don’t need to know anything about the models or indeed what these represent — we just need to ask Warp to change the archetype view. We could simply describe the class, but we can do better.

First we’ll use the file tree (on the left) to select the good example view, so we can refer to the file directly in the query. Note that the selected file view fills the right pane:

To supply what is called “agent context,” we can use the “@” symbol to specifically reference the two files. Let’s look at the query I used during the Auggie review:

“change the view file app/views/voices/show.html.erb so that it uses Bootstrap classes, using app/views/tags/show.html.erb as an example”

So apart from the different example and target, using the @ symbol I can create the query for Warp:

This allows me to capture the files directly, which happen to have the same name in Rails, just different view folders:

Let’s go with that. We get the usual diff view, which we can accept or reject:

Remember we have the “view changes” button, so we can come back to this any time. In fact, I can even see the git changes from the previous query I made for the Auggie review. (These take quite a few seconds to load at the moment.)

To wrap it all up, let’s just refresh the page on my app to confirm we are good:

The Direction of Warp

I’ve only touched on the new stuff in my review, but because Warp Code represents more of a breakout towards what Warp has described as the “Agentic Development Environment” (ADE) as opposed to a specific improvement in the mechanics of LLMs, I asked Zach Lloyd (Warp CEO) some questions to help see where this is all going.

David Eastman: I think Warp is now peculiarly vulnerable because you are moving into new (if familiar) territory. Other Agentic CLI products simply don’t have enough control right now over the shell/terminal to come very close to what you are doing with views. How are you going to pull the coding Overton window towards Warp?

Zach Lloyd: The UI features and what we can do at the view level is a huge differentiator, because we can build a different type of developer experience than a purely CLI-based tool that’s only able to output text and can’t take any mouse input.

Everyone else is retrofitting AI into their app, whether it’s a chat bar in VS Code or a CLI app. What we’re trying to design is what the UI should be for working with agents. As people see that they can have something that feels like a CLI-based agent, but lets them edit the output or review diffs like they’re reviewing a PR in GitHub, we’re going to get the primitives right in a way that’s very hard for apps with other UI constraints to do.

DE: In a related question, are you hoping that other products try to develop or extend the shell itself, so you at least have common marketing ground with the competition?

ZL: I’m a little split on this one. On one hand, we want ADEs to become a category, which is already kind of happening. If you look at Conductor, it’s probably the best other example of people building UIs on top of Claude Code.

Whether we want it or not, what’s actually happening is that the competition is already moving towards us. If you look at Cursor, for instance, they’re slowly stripping away a lot of the editing features and building something that looks a lot more like Warp.

DE: Given the heavy AI integration with Warp, are you just going to leave the basic tabbed shells to Ghostty, et al?

ZL: I’m still cool with people who want to just use Warp as a terminal, although our product focus has definitely moved away from that. There are threads online about this, where people are a little frustrated that we’re adding AI and they just want to use our terminal features, like the rich text editor and block output.

We’ve talked internally about not just making a “turn off AI” mode, but making a basic terminal mode or Warp Classic as a new binary. I still think it’s unlikely we’ll do two binaries, but I do think it’s quite possible that we’ll do something as part of the onboarding experience — just “I’m here for the terminal and I don’t like AI.” But overall, that’s really not our focus moving forward.

DE: You are clearly gunning for the modern version of the 90s Emacs or Vim, where the developer sets up their preferred layout and then lives in that setup for the whole time. Are you going to try to set up some community “plugin” development to support other views (e.g., git branch trees, etc)?

This is an awesome idea. I’ve never quite thought of it that way. If you look at the history of how these things evolved, I remember working in Emacs where I would have everything — a file tree, code editor, everything — all in Emacs. People do the same thing in Vim. The evolution went from those to IDEs, and I think it’s fair to say that now Warp is trying to continue that evolution with the ADE.

An ecosystem around it where people can plug in at the view layer is a super cool idea. I can’t really say in all honesty that we’re building it right this second, just because we have so many other things that we’re working on. But I actually love that idea and think it’s a smart place for us to invest in making Warp, the app itself, more accessible.

DE: To get into the position to have the backend control and the fast windowing, you have obviously worked hard on the Rust windowing control primitives. Is that now a separate sub-team within the Warp team? For those looking to hand you a CV, what do you look for?

The UI framework that we have, which is what we call the windowing primitives and the rendering engine, is pretty stable at this point.

The general policy that we’ve always had at Warp with respect to building features is that you build them end-to-end. So if you are building a feature that touches AI, for instance, you are building the UI for it, you’re building the prompting, and you’re building the evals — you’re responsible for the overall end-user experience.

When someone wants to come work at Warp, what I’m looking for is general problem-solving and CS skills and aptitude — someone who’s really smart, cares about what we’re building, wants to help developers, and is very product-focused. Meaning they have the ability to, when they’re building something, not just nerd out on the code, but always focus on: why am I building this thing? How should the feature work? Is it solving the end-user’s problem?

Some things we don’t look for: specific language knowledge, Rust experts, and heavy terminal users. We’re looking for people who want to help developers ship software more quickly.

David’s Conclusion

Warp is both defining its new Agentic Development Environment strategy, as well as competing in the new Agentic Era. Warp Code uses flexible views to get it nearer to that Emacs feel of a highly integrated system suitable for long-term development.

My feeling is that not only does Warp have the right technical background to deliver this, it is the right innovation to help move Agentic CLIs into deeper maturity.

The post Warp Code Gets Closer to an Emacs for the Modern AI Era appeared first on The New Stack.

In a project I'm part of, I found that we had some code that gzipped some requests before sending them to an external API. I found it because of some performance problems, especially with larger files. More specifically, we ran out of memory...

Here's the code:

internal async ValueTask<HttpRequestMessage> CreateRequest(Uri uri, Stream source)
{
    var outStream = new MemoryStream();
    await using (var zipStream = new GZipStream(outStream, CompressionMode.Compress, leaveOpen: true))
    {
        await source.CopyToAsync(zipStream);
        zipStream.Close();
    }
    outStream.Position = 0;

    var request = new HttpRequestMessage(HttpMethod.Post, uri)
    {
        Content = new StreamContent(outStream)
    };
    request.Content.Headers.ContentEncoding.Add("gzip");
    return request;
}

It was then used like this:

var uri = new Uri("https://dummy.localhost/some-endpoint");
var someLargeFile = File.Open("some-really-large-file.txt");
var request = await CreateRequest(uri, someLargeFile);

Usually, this code just worked. However, sometimes we needed to send a lot of these requests. And every time a request was sent, the gzipped content would be created in memory (thanks to the MemoryStream) before it would be sent. And since memory is a finite resource, the app would go boom.

My idea was that, surely, it should be possible to do the gzip compression on the fly instead?

I came up with the following:

public class GzipContent : HttpContent
{
    private readonly Stream _sourceStream;

    public GzipContent(Stream sourceStream)
    {
        _sourceStream = sourceStream;
        Headers.ContentEncoding.Add("gzip");
    }

    protected override async Task SerializeToStreamAsync(Stream stream, TransportContext? context)
    {
        await using var gzipStream = new GZipStream(stream, CompressionMode.Compress, leaveOpen: true);
        await _sourceStream.CopyToAsync(gzipStream);
    }

    protected override bool TryComputeLength(out long length)
    {
        length = -1;
        return false;
    }
}

You use it in the same way like this:

var uri = new Uri("https://dummy.localhost/some-endpoint");
var someLargeFile = File.Open("some-really-large-file.txt");
var request = await CreateRequest(uri, someLargeFile);

// ValueTask<> is used since the `CreateRequest` method is part of an interface and to make the benchmark more fair as well.
internal ValueTask<HttpRequestMessage> CreateRequest(Uri uri, Stream source)
{
    return ValueTask.FromResult(new HttpRequestMessage(HttpMethod.Post, uri)
    {
        Content = new GzipContent(source)
    });
}

Performance

I benchmarked this with a couple of different json files of different sizes. The GzipContent version runs a tad slower for smaller files, but it allocates way less, thus solving our memory problem. The bigger the file, the bigger the difference.

BenchmarkDotNet v0.15.2, macOS 26.0 (25A353) [Darwin 25.0.0]
Apple M4 Max, 1 CPU, 16 logical and 16 physical cores
.NET SDK 10.0.100-preview.7.25380.108
  [Host]   : .NET 9.0.7 (9.0.725.31616), Arm64 RyuJIT AdvSIMD
  .NET 9.0 : .NET 9.0.7 (9.0.725.31616), Arm64 RyuJIT AdvSIMD

Job=.NET 9.0  Runtime=.NET 9.0  InvocationCount=1  
UnrollFactor=1  

| Method       | Filename   | Mean        | Error     | StdDev    | Median      | Ratio | RatioSD | Allocated  | Alloc Ratio |
|------------- |----------- |------------:|----------:|----------:|------------:|------:|--------:|-----------:|------------:|
| MemoryStream | 64KB.json  |    238.5 us |   7.20 us |  19.96 us |    234.7 us |  1.01 |    0.11 |   27.69 KB |        1.00 |
| GzipContent  | 64KB.json  |    244.1 us |   7.87 us |  21.81 us |    239.1 us |  1.03 |    0.12 |    7.94 KB |        0.29 |
|              |            |             |           |           |             |       |         |            |             |
| MemoryStream | 128KB.json |    763.4 us |  25.93 us |  73.54 us |    737.8 us |  1.01 |    0.13 |  123.85 KB |        1.00 |
| GzipContent  | 128KB.json |    735.2 us |  14.62 us |  36.13 us |    730.6 us |  0.97 |    0.10 |    7.66 KB |        0.06 |
|              |            |             |           |           |             |       |         |            |             |
| MemoryStream | 256KB.json |    702.9 us |  13.99 us |  30.11 us |    701.1 us |  1.00 |    0.06 |  123.85 KB |        1.00 |
| GzipContent  | 256KB.json |    732.2 us |  13.12 us |  34.78 us |    731.1 us |  1.04 |    0.07 |    7.81 KB |        0.06 |
|              |            |             |           |           |             |       |         |            |             |
| MemoryStream | 512KB.json |  1,360.0 us |  27.13 us |  52.91 us |  1,354.7 us |  1.00 |    0.05 |  123.85 KB |        1.00 |
| GzipContent  | 512KB.json |  1,425.9 us |  28.31 us |  62.74 us |  1,431.2 us |  1.05 |    0.06 |     8.3 KB |        0.07 |
|              |            |             |           |           |             |       |         |            |             |
| MemoryStream | 1MB.json   |  2,663.8 us |  52.87 us | 144.73 us |  2,647.0 us |  1.00 |    0.08 |  252.03 KB |        1.00 |
| GzipContent  | 1MB.json   |  2,744.1 us |  54.47 us | 130.50 us |  2,732.7 us |  1.03 |    0.07 |    9.05 KB |        0.04 |
|              |            |             |           |           |             |       |         |            |             |
| MemoryStream | 5MB.json   | 12,914.2 us | 249.61 us | 324.56 us | 12,870.5 us |  1.00 |    0.03 | 2046.29 KB |       1.000 |
| GzipContent  | 5MB.json   | 12,802.1 us | 250.62 us | 234.43 us | 12,777.7 us |  0.99 |    0.03 |   16.28 KB |       0.008 |