Colton Hayes

I keep downloading to-do apps, using them seriously for a week, and then forgetting the app exists.

So I m trying to figure out if that s a me problem or if some of these apps just become too much work.

Looking at Todoist and TickTick right now. They both seem capable enough, but I m less interested in who has more features.

Everyone uses AI now. To code. To write. To ship faster. But planning still feels stuck in the old days. Roadmaps get built on guesswork. Marketing means posting and hoping.

I am following spec driven development. I write the specs first. Every feature, every decision, ties back to it. It keeps me from drifting into random ideas mid build. My roadmap comes from that spec, not from gut feeling.

I use the same thinking for marketing. I write down what I'm building, who it's for, and why it matters. Before I post anything.

So I'm curious. How are you planning your roadmap right now? Do you have an actual system, or are you winging it like most of us?

The one where OpenAI's smartest models finally answer. Turns out we'd been calling one JSON field by a name they retired back when o1 shipped, and they were not shy about it.

Fixed

• 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.

Housekeeping