EnPissant

> People have a stark reaction to the visual of a guy being 200 meters above the ground but the reality is if you're a circus acrobat and you're 10 meters up the air you're also likely dead or maimed if something goes wrong.

No, it's the large number of free soloists that have died. And the small number of circus performers who have died. People's intuitions about the relative risks are actually very accurate here.

You need to be specific! There are 2 lawyers with completely opposite hand sizes.

They say they do not compress the user messages, but yeah, it's purpose is to do very lossy compression of everything else. I'd expect it to be small.

Are you sure? For reasoning, encrypted_content is for sure actually encrypted.

I'm guessing that's ~26 decode tokens/s for 2-bit or 3-bit quantized Minimax-m2.1 at 0 context, and it only gets worse as the context grows.

I'm also sure your prefill is slow enough to make the model mostly unusable, even at smallish context windows, but entirely at mid to large context.

Maybe it's a model fine tuned for compaction?

> I think the delta may be an overloaded use of "turn"? The Responses API does preserve reasoning across multiple "agent turns", but doesn't appear to across multiple "user turns" (as of November, at least).

Yeah, I think you may be correct.

Thanks. That's really interesting. That documentation certainly does say that reasoning from previous turns are dropped (a turn being an agentic loop between user messages), even if you include the encrypted content for them in the API calls.

I wonder why the second PR you linked was made then. Maybe the documentation is outdated? Or maybe it's just to let the server be in complete control of what gets dropped and when, like it is when you are using responses statefully? This can be because it has changed or they may want to change it in the future. Also, codex uses a different endpoint than the API, so maybe there are some other differences?

Also, this would mean that the tail of the KV cache that contains each new turn must be thrown away when the next turn starts. But I guess that's not a very big deal, as it only happens once for each turn.

EDIT:

This contradicts the caching documentation: https://developers.openai.com/blog/responses-api/

Specifically:

> And here’s where reasoning models really shine: Responses preserves the model’s reasoning state across those turns. In Chat Completions, reasoning is dropped between calls, like the detective forgetting the clues every time they leave the room. Responses keeps the notebook open; step‑by‑step thought processes actually survive into the next turn. That shows up in benchmarks (TAUBench +5%) and in more efficient cache utilization and latency.

Thanks. I consider myself an insignificant or contemptible person or thing.

Also, everyone loves chess puns.

I don't think this is true.

I'm pretty sure that Codex uses reasoning.encrypted_content=true and store=false with the responses API.

reasoning.encrypted_content=true - The server will return all the reasoning tokens in an encrypted blob you can pass along in the next call. Only OpenaAI can decrypt them.

store=false - The server will not persist anything about the conversation on the server. Any subsequent calls must provide all context.

Combined the two above options turns the responses API into a stateless one. Without these options it will still persist reasoning tokens in a agentic loop, but it will be done statefully without the client passing the reasoning along each time.

Have you tried lower reasoning levels?

Do you own a dog house?

Yeah, they are really impressive for 4" drivers.

I currently have the 8020D + 7040A. It's pretty much perfect sound with room correction applied, but the 7040A is kind of big and ugly. I'd be willing to give up some low-end to simplify the setup. Also the sub performs the crossover, so it's a lot of cords: 2 cords for DAC -> Sub, and 2 cords for sub -> L/R. And these cords have to be really long for when I raise my desk because the sub has to go on the floor.

Not OP, but I have 2 8020D + a subwoofer.

If I had to do it all over again I would have 2 8030C and no subwoofer.

You are depicting this as some dramatic shift, but the Cato institute has always been anti-Trump.

It depends on your OS.

Linux and Windows are significantly better for both 1440p and 4k monitors. Both Linux and Windows have subpixel rendering and configurable font hinting for 1440p. And they both have fractional scaling UIs for 4k. macOS on the other hand only really looks acceptable on a 5k monitor.

I used to have the same complaint, and recently swapped to 4k monitors. I thought that would solve my zed font problems, but text presentation is still bad. In zed, it feels like there is significantly more spacing between each line compared to vscode (or any other text editor).

I know what a post history is. Obviously I was not asking someone to link to my profile.

My post history?

What exactly is my post history doing?

I’ve seen this claim a lot, but I’m skeptical. Has anyone actually published benchmarks showing a big speedup from using the NPU for prefill?

AMD’s own marketing numbers say the NPU is about 50 TOPS out of 126 TOPS total compute for the platform. Even if you hand-wave everything else away, that caps the theoretical upside at around ~1.6x.

But that assumes:

1. Your workload maps cleanly onto the NPU’s 8-bit fast path.

2. There’s no overhead coordinating the iGPU + NPU.

My expectation is the real-world gain would be close to 0, but I'd love to be proven wrong!

Then again, I have a RTX 5090 + 96GB DDR5-6000 that crushes the spark on prompt processing of gpt-oss-120b (something like 2-3x faster), while token generation is pretty close. The cost I paid was ~$3200 for the entire computer. With the currently inflated RAM prices, it would probably be closer to the dell.

So while I think the Strix Halo is a mostly useless machine for any kind of AI, and I think the spark is actually useful, I don't think pure inference is a good use case for them.

It probably only makes sense as a dev kit for larger cloud hardware.

I don’t think your problem is RGB instead of BGR. That’s just the compositor’s work area and your monitor never sees it (it includes an alpha channel). Have you tried KDE Plasma? It sounds like KWin uses 10-bit planes by default when available. Maybe Ubuntu’s compositor (Mutter?) doesn’t support 30 bit color or must be configured? Or maybe you need the nvidia driver >= 580.94.11 for VK_EXT_hdr_metadata (https://www.phoronix.com/news/NVIDIA-580.94.11-Linux-Driver)

Was it an 8k cable? Are you on wayland?

I asked claude to investigate:

  Your Display Configuration

  Both monitors are outputting 10-bit color using the ABGR2101010 pixel format.

  | Monitor                | Connector | Format      | Color Depth | HDR          | Colorspace |
  |------------------------|-----------|-------------|-------------|--------------|------------|
  | Dell U2725QE (XXXXXXX) | HDMI-A-1  | ABGR2101010 | 10-bit      | Enabled (PQ) | BT2020_RGB |
  | Dell U2725QE (XXXXXXX) | HDMI-A-2  | ABGR2101010 | 10-bit      | Disabled     | Default    |

* Changed the serial numbers to XXXXXXX

I am on Wayland and outputting via HDMI 2.1 if that helps.

EDIT: Claude explained how it determined this with drm_info, and manually verified it:

> Planes 0 and 3 are the primary planes (type=1) for CRTCs 62 and 81 respectively - these are what actually display your desktop content. The Format: field shows the pixel format of the currently attached framebuffer.

EDIT: Also note that I am slowbanned on this site, so may not be able to respond for a bit.

EDIT: You should try connecting with HDMI 2.1 (you will need a 8k HDMI cable or it will fall back to older standards instead of FRL).

EDIT: HDR on youtube appears to work for me. Youtube correctly indentifies HDR on only 1 of my monitors and I can see a big difference in the flames between them on this scene: https://www.youtube.com/watch?v=WjJWvAhNq34

It's not obvious how to interpret the output. I pasted it into chatgpt and it thinks I am using "Format: ABGR2101010" for both monitors (only 1 has HDR on) so I don't trust it.

EDIT: See my sibling comment.

I don't think this is true. I can go into my display settings in kde plasma and enable HDR and configure the brightness. I have a nvidia blackwell card.

I've never seen any significant difference in linear vs affine types.

To me it just seems like Rust has Linear types, and the compiler just inserts some code to destroy your values for you if you don't do it yourself.

I guess the only difference is that linear types can _force_ you to manually consume a value (not necessarily via drop)? Is that what you are going for?

Is this like JDate but for email?