Compression exclusion doesn't work (3.8.52)

[elcodeo]

Hi community,

I've setup compression which works in general. But my exclusions seem not to work. Am I doing something wrong?

[joshwebtimestwo]

The wildcard syntax is valid. The likely mismatch is the provider identifier: your log shows the display name GUFO, but the request-protocol tooltip contains a custom openai-compatible-chat-... ID.

In 3.8.52's matcher, exclusions are checked against the bare model ID and provider/model. It does not look up provider display aliases. The call site passes the resolved provider and effectiveModel, so gufo/* won't match when that provider value is the custom endpoint ID.

As a narrow diagnostic, add this line to the exclusions, save, reload the page to confirm it persisted, and make a new request:

Qwen3.8-27B

That excludes this model name across providers. To scope the exclusion to just your custom endpoint, use its full internal ID instead:

openai-compatible-chat-<actual-endpoint-id>/*

Replace the placeholder with the actual ID; don't paste it literally. Historical log rows will keep their original compression figures.

I ran the actual v3.8.52 matcher with your three patterns and the model/endpoint ID shown in the screenshots. The existing patterns did not match; the bare-model pattern and full endpoint-ID wildcard did. Case-insensitive matching and the literal dot in Qwen3.8-27B also passed, five checks in total.

I haven't replayed your live request or checked your saved settings. If a fresh request still compresses with the bare-model exclusion saved, that would point to another issue beyond the identifier mismatch.

[elcodeo]

I added "Qwen3.8-27B" to the exclusion list and made a new request. With this setting the compression was disabled - so it worked.

It's a workaround but not a solution for the underlaying cause. The documentation says: "Model ids or provider/model patterns that must never be compressed.". With "gufo/*" I added the provider name. So I think this is something which needs a deeper analysis.

[joshwebtimestwo]

Thanks for checking. Agreed: that confirms the model-only workaround, not a fix for provider-name exclusions. The current matcher uses the internal provider value passed by chatCore; it doesn't resolve the configured display name. Your result doesn't by itself prove the provider-name mismatch, but it does narrow the problem to that side of the exclusion.

The underlying fix needs the provider-name/ID mapping handled consistently, or the UI to show which identifier the exclusion expects. Keeping the bare model entry meanwhile excludes that model across providers, so it is broader than the gufo/* scope you wanted.