m3h

COVID happened. Money was aplenty. Then snapback happened. And there were many firings and cancelled projects.

There were a lot of products and ideas that felt great during ZIRP but stopped making sense post-ZIRP. That's my take.

I'm having a tough time using Opus to produce blog-grade writing. Claude produces jargon heavy, market-y language that no human would ever write, much less want to read. This issue exists even when I ask it to write internal reports or short memos. Opus is not working for writing in any task.

PS: I am not interest in the model's coding skills, only its ability to write or partner with me in writing.

You're looking for Poteto's /unslop which cleans up sloppy AI writing.

Someone made a Claude version of her skills:

https://github.com/michael-denyer/pstack-claude

Someone who until yesterday did not seem bothered by his technology being possibly used to bomb elementary girls school in another country seems to suddenly care about the repression of citizens in yet another country.

No, we don't buy your virtue signaling. And we certainly don't need your better-than-thou opinions on this year's "nightmare scenarios".

Is there a specific list of changes they made to the system prompt? They're claiming they removed 80% of it. That's quite substantial. It would be good to know what the model knows to do by training and what we need to avoid over-specifying in our system prompts.

Saying that "give Claude judgment" is too vague for agent implementors. Given the lack of specific details, my takeaway is that we need to go and review all context and rework prompts from prompts/descriptions from scratch until they pass the evals again.

A while back, I saw a similar feature land in Codex (I'm using the VS Code plugin) but it got removed quickly. What is the chance that an LLM recommended this same idea to the Claude PM or lead? I see LLMs across different providers converging on similar ideas or biases frequently.

> Kimi K3 is Kimi’s most capable model to date, with 2.8 trillion parameters.

This puts them on the top of the largest open models list:

  Kimi K3            2.8T
  DeepSeek-V4-Pro    1.6T (49B active)
  Kimi K2.6          ~1T (32B active)
  GLM-5.2            754B (40B active)
  DeepSeek-V3.2      685B
  Mistral Large 3    675B

That's one mighty large model! Moonshot is going to need the USD 500 million reportedly raised earlier this year to run this model.

The author shared their experience building the first version in a month: https://themackabu.dev/blog/js-in-one-month

And then the follow up few months later: https://themackabu.dev/blog/ant-part-two

I'm not sure what the economics of building a new runtime and ecosystem from scratch are but it seems we're already in a phase where individual developers are creating software which previously took a whole team. And its only getting started...

We have an official pelican on a bicycle from the OpenAI livestream:

https://imgshare.cc/mz9xwut3

The speed up numbers based on their testing:

    Codebase    | TypeScript 6 | TypeScript 7 | Speedup
    ------------|--------------|--------------|--------
    vscode      | 125.7s       | 10.6s        | 11.9x
    sentry      | 139.8s       | 15.7s        | 8.9x
    bluesky     | 24.3s        | 2.8s         | 8.7x
    playwright  | 12.8s        | 1.47s        | 8.7x
    tldraw      | 11.2s        | 1.46s        | 7.7x

Congratulations to the team for pulling off this feat while doing a responsible migration (looking at you, Bun).

Quick question: How does this affect downstream tools like tsdown and esbuild, which need to build the TypeScript codebase? Can I use TS 7 and current tsdown together?

When I reviewed the conversations affected by this issue, they did not always align with my feeling of "degraded output".

Some were definitely below par, and I recall having to iterate on the generated code more than I wanted to. However, it is only true for a very small number of conversations.

So we're looking at a small set of affected conversations, and even within that small set, only a few will have degraded output, likely because the model can compensate for the reasoning defect over the long conversation.

Indeed, it looks like my work has suffered from the clustering issue as well:

  reasoning_output_tokens    count    percent
  ━━━━━━━━━━━━━━━━━━━━━━━━━  ━━━━━━━  ━━━━━━━━━
                         0      873    28.5948
  ─────────────────────────  ───────  ─────────
                         8       64     2.0963
  ─────────────────────────  ───────  ─────────
                         9       60     1.9653
  ─────────────────────────  ───────  ─────────
                        11       54     1.7688
  ─────────────────────────  ───────  ─────────
                       516       48     1.5722
  ─────────────────────────  ───────  ─────────
                        12       45     1.4740
  ─────────────────────────  ───────  ─────────
                        10       43     1.4085
  ─────────────────────────  ───────  ─────────
                        17       40     1.3102
  ─────────────────────────  ───────  ─────────
                        13       38     1.2447
  ─────────────────────────  ───────  ─────────
                        14       36     1.1792

Created a script for this: https://github.com/thehappybug/codex-reasoning-token-check

Also, kudos to the Z.ai team for adding Linux support from day one.

Z.ai documents integrations with nearly all the popular CLI-based agents: https://docs.z.ai/devpack/tool/others

If you're already used to your TUI coding agent, you don't need the desktop agent. Although it is nice that it is there for folks who prefer the Codex App/Claude App UI approach.

Correct. Albeit the nuance here is that a more capable model might solve problems more efficiently and faster, possibly saving you tokens.

As with any new model, you won't know the real impact until you start using it for your workload.

I didn't realize GPT 5.3 Codex was that good.

OpenAI claims to have made their new Terra model as good as GPT 5.5, but with half the cost per intelligence. Hopefully, this will bring it closer to the price you're expecting (or even better considering GPT models have good acceptance/success rates according to benchmarks).

I think you should try an OpenAI model like GPT 5.5. It is better at following instructions and boundaries set during prompt. It feels like a more capable "agent assistant" than Claude models but without loss of intelligence.

Most of my work involves "Agentic engineering" instead of fire-and-forget. I like to stay involved during the planning as well as review and ask a lot more questions from the agent than I've seen others doing. In a way, I'm using the agent in a sort of "hyper auto-complete" mode to fill in the blanks (rather big blanks) once I've set out the requirements, scope and design (sometimes specific module boundaries). This works best for me.

Important to note: "Sonnet 5 is an upgrade to Sonnet 4.6, but it uses an updated tokenizer that changes how the model processes text to improve performance (this is similar to the tokenizer change we introduced with Claude Opus 4.7). The tradeoff is that the same input can map to more tokens: roughly 1.0–1.35× depending on the content type. The introductory pricing is set so that the transition to Sonnet 5 is roughly cost-neutral."

Why is Claude Sonnet 5 allowed to be released but OpenAI Terra not? Are they not the same class of models?

If GPT-5.6 preview is not available outside US government approved "trusted partners", I don't see how the General Available can be trusted later.

Who knows what they will fix, block or change in the model between the preview and GA time. Open models can't arrive soon enough.

Or we could simply hallucinate that the packages are there at the three houses.

Hallucinations all the way down...