Nikita Zarubin

No more ghost notifications. Read your mail at work all day, come home, boot the other machine and Skim used to toast about every single message that arrived meanwhile, badge and all. It had the "already read" flag right there in its hands the whole time. It just... didn't look. Now it looks. Only mail the server still holds unread gets a toast.

The tray badge tells the truth on startup. It used to paint yesterday's unread count the instant the icon appeared, then quietly correct itself minutes later after a full folder sweep. Now the badge waits for the first inbox sync and shows the real number no stale flash, no "wait, where did those 12 go?"

Badge follows push, not the 5-minute poll. The IDLE-driven inbox sync the one that actually fires when mail lands never repainted the badge. Now it does, on success and on failure (offline still gets the cached count, just honestly).

Mailbox chat works again on gpt-5.6 models. Point the OpenAI-compatible provider at OpenAI with a gpt-5.6-* model and every single round that carried tools came back as a 400 and a wall of English error prose in the chat bubble. Retrying showed you the same wall. Very helpful. (#40)
The twist: Skim never sent reasoning_effort at all. The model reasons at medium on its own, then refuses its own default alongside our tools so nothing in our request even named the thing that broke it.

We still don't guess. No model-name regex, no "is this OpenAI?" sniffing the same base URL serves OpenRouter, Ollama, LM Studio, vLLM and whatever you typed in that box, and half of them would 422 on the "fix". So Skim sends nothing up front, waits for the endpoint to name the remedy in its own error, and retries exactly once with the value it asked for tools still attached, because answering without the search results would rather defeat the point.

Reasoning models on a custom OpenAI endpoint work again. Point the OpenAI-compatible provider at OpenAI itself, pick anything from the o-series or the GPT-5 family, and every single request died before the first token: Unsupported parameter: 'max_tokens' is not supported with this model. Use 'max_completion_tokens' instead. Which is a wonderfully clear error message to receive zero times, because you're in a chat window and all you see is that nothing happened.

The lazy fix would be to rename the field everywhere and move on. Except only about half of the OpenAI-compatible world speaks the new name: Mistral answers 422, and Ollama and llama-cpp-python ignore it in complete silence which doesn't fail your request, it just removes the ceiling on the answer. That's strictly worse than an error, because nobody ever finds out.

So Skim now opens with the name every server understands, and switches only for an endpoint that asks for the other one by name, in its own error and only when that error names both keys, which is what separates "use the other name" from "that number is too big". Cost: one rejected request the first time you talk to such an endpoint. No new settings, no model list to maintain, nothing for you to choose. Exactly the amount of thinking about this you should have to do: none.

Huge thanks to @ondrahracek for this one not just the fix, but a writeup that walked through what LangChain and goose each broke trying the obvious thing first, and two tests verified by mutation. Reviewing that was a genuine pleasure.