Blog

  • Call the small model on purpose

    Call the small model on purpose

    Through late September and early October 2026, three efficient models landed close together: OpenAI’s GPT-6.1 Sol on 22 September, Google’s Gemini 4 Argon on 30 September, and Anthropic’s Claude Haiku 5.5 on 7 October. A clear comparison is in this rundown of the three releases. None of them is the model the keynote wants you to remember. They are the ones a product can afford to call all day.

    Most of an app is not a hard problem

    A support inbox, a classifier on uploaded PDFs, a router that decides which specialist runs next, a pass that pulls the right chunks before a larger model answers. Those calls dominate the bill. They also dominate latency, because they sit on the path before the user sees anything.

    Anthropic positions Haiku 5.5 for that path: classification, routing, retrieval, and sub-agent work, not the longest reasoning trace. Google’s Argon is aimed at heavier engineering workflows and a much larger output budget, and it was still limited to trusted testers in the first days after the announcement. OpenAI’s Sol line sits under the Astra tier and above Luna. The names collide on purpose. If you do not read the model card, you will wire the wrong one.

    How I would route it

    1. Cheap model first for intent, language, and whether the request is in scope.
    2. Retrieval with an embedding model, not with the generator.
    3. A stronger model only when the cheap one marks the task as ambiguous, high impact, or a poor retrieval.

    Write that down as code, not as a vibe. Log the route. If Sol, Haiku, or Argon is wrong on a class of tickets, you want to see the class, not a blended average that looks fine.

    What efficient does not mean

    A smaller model will still invent a confident answer when the context is thin. Routing does not replace a schema. For anything I store, I still want JSON that fails validation, a tool call with typed arguments, and a human on the actions that cannot be undone.

    The October pile-up is good news if you ship software for a company. You can stop sending every token to the most expensive model you have access to. You cannot stop deciding which step is allowed to be wrong.

  • When the model draws the interface

    When the model draws the interface

    On 7 October 2026 OpenAI started rolling GPT-6 out to ChatGPT, including an Intelligent UI that can answer with graphics, buttons, forms, charts, and small tools composed in the conversation. Paid tiers get GPT-6 Sol. Free and Go get GPT-6 Luna. The write-up is on OpenAI’s announcement.

    I build the other kind of interface: Next.js screens, forms with validation, permissions, and a database behind them. Watching a model assemble a UI in the reply changes the job, and it does not remove it.

    The answer is becoming a surface

    For a few years the product pattern was simple. The user typed. The model returned text. Your app wrapped that text in a layout you designed. Intelligent UI breaks that split. The model chooses text, a visual, and a control, then keeps going while the person is still reading. OpenAI describes this as progressive composition: partial responses that stay one answer, not a pile of filler.

    That is useful for learning a topic or throwing together a one-off calculator. It is a poor place to keep a company’s source of truth. A button inside a chat transcript is not a workflow. It has no audit trail, no role check, and no record of who confirmed the number.

    What I would still build by hand

    • Anything that moves money, changes a record, or grants access.
    • Screens a team uses every day. Muscle memory beats a fresh layout on every reply.
    • Empty states, errors, and the boring path where the model is wrong and a person has to fix it.

    I would let a model draft a view for exploration: a chart of last month’s leads, a filter the user just described, a comparison they will throw away. I would not let it invent the CRM.

    A practical split

    Treat generated UI as a sketch layer on top of a stable product. The sketch can be rich. The product stays typed. If ChatGPT can render a form, your API should still be the thing that accepts the submission, with the same validation you would put on a normal page.

    The rollout also splits the model by plan. Sol and Luna are both called GPT-6, and they are not the same weight. If your product calls the API rather than relying on ChatGPT’s chat tab, pin the model id. GPT-6 in a marketing sentence is not a contract.

    I am glad answers can be visual. I still want the screen a business runs on to be one I can open in the repo.