Weekly update, Nov 13: Codex and Grok catch up in 0.19.3 and 0.19.4

[SamStull9007]

One improvement

New this week: Codex and Grok get the same optimizer, receipts and alerts as Claude Code. Two releases, 0.19.3 and 0.19.4 (both on npm and GitHub, Nov 13 US evening), came out of an audit of why the three tools were handled differently. Claude Code was built first and many features read Claude-only data. The optimizer itself arrived in 0.19.0 (Nov 9, GitHub only; that version never reached npm) and reached npm in 0.19.1. Seven releases have shipped since last week's update.

What changed for a Codex or Grok user:

• Pruning proposals reach Codex and Grok. The optimizer proposes MCP servers that no session in this repository called, and optimize capabilities --codex|--grok --apply <server> turns one off in the project's own config file (journaled, undoable, checked against codex mcp list / grok mcp list afterwards). Codex also keeps its three built-in candidates. Grok has no persistent setting that removes a built-in tool, so it proposes servers only.
• A correction. In 0.19.3 the Grok apply never took effect: Grok ignores a project server entry that has no command, so the command reported an error and rolled back (nothing was left changed). 0.19.4 writes an entry with a stub command that never runs, and copies nothing from your server's definition. Checked with the real CLI: grok mcp list shows the server off and a headless Grok session does not start it.
• Subagent receipts for Codex and Grok, in API-equivalent dollars (list prices, not a bill). Codex's is computed when the subagent stops. Grok writes a subagent's usage just after its stop hook, so its receipt is logged by the next hook.
• Fat-tool notice, fat-tool limit and starting-context alert for Codex and Grok (install --alerts), and Codex limit notifications (install --guard, then notify on).
• Fixes the audit turned up: a model pinned for Grok was applied to Claude spawns; the duplicate-spawn hold never fired for Codex (and Codex encrypts spawn_agent arguments, so it now compares the task name); results invented outcomes for past Grok blocks; Grok cost in report was about 1.8x too high; optimize capabilities --codex failed on Codex 0.169; doctor now asks Codex which hooks it trusts.

To pick up the new hooks after upgrading: run limitcast install --guard --alerts again, restart Claude Code, Codex and Grok, and approve the new hooks in Codex (/hooks).

Also since last week: 0.18.2 (mistyped options now fail with Unknown option instead of running the plain command; settings and cache files are written atomically), 0.18.3 (commands that change settings at the same moment no longer undo each other), and 0.19.2 (optimizer fixes: learned command replacements keep the verification check they replace, and a map from a dirty working tree no longer contaminates the cached one). The optimizer is opt-in; see the optimizer guide.

Checked in live sessions. I ran real Codex 0.169 and Grok 1.0.77 sessions in isolated homes with limitcast's hooks recording what the tools actually send. That is how the Grok defect and the Codex encryption showed up; unit tests had passed. Not verified: whether Codex or Grok display a hook's message to you, and interactive Grok folder trust.

Re-checked on Nov 13 with a clean checkout of the v0.19.4 tag, using isolated home and state directories: all 293 tests pass when run one file at a time (in one parallel run on a heavily loaded machine, a timing-sensitive lock stress test timed out; it passes alone, and GitHub Actions passed on the release commit on Linux and macOS, Node 20, 22 and 24). The six-case deterministic replay behaves as documented on both the tag and the tarball downloaded from npm:

Replay case (30 simulated tool calls)	Redirects	Expected
Same failing check, repeated	1	1
Same failing check, every event delivered twice	1	1
Failures that keep changing	0	0
Passing check	0	0
Read-only exploration	0	0
Ambiguous exit status	0	0

Replay uses simulated events, not a live model. It shows when the detector speaks up, not that a model follows the redirect. No token savings are claimed or measured.

One example

Actual output, run on November 13, 2026 against the v0.19.4 tag in a synthetic task: a real Codex 0.169 session in an isolated home was asked to start one subagent that reads a three-line text file. No real project, path or usage. This is the message limitcast's stop hook emits for you (never for the model); whether your terminal displays hook messages is one of the two things not verified above:

limitcast: that default subagent used 53k tokens, 1k of them new (2 calls): about $0.01 at API list prices.

Most of those tokens are cached reads, which is why only 1k are new. The dollar figure is what the tokens would cost at OpenAI's list price for the model, not what your plan charges. Claude Code receipts show a share of your 5-hour window instead, because Claude has a calibrated window; Codex and Grok have none.

From the maintainer's own machine. One person's real usage: not synthetic, and not a user result. This is limitcast optimize status in the maintainer's main working repository on November 13, 2026, counting sessions recorded since the optimizer was enabled in early November. Tool names, server names, paths and project names are left out.

Host	Sessions recorded	Capability-pruning proposals
Claude Code	194	193
Codex	144	2 (one built-in, one MCP server)
Grok	122	3 (all MCP servers)

No proposal has been applied, and no check-command facts have been learned (0), even with learning turned on. The proposals are suggestions: a capability is proposed only after it was declared but unused across at least five sessions in this repository. They show what pruning could remove here, not what it saved. Nothing was disabled, so there is no savings figure. In the home directory, --apply refuses on Codex and Grok, because the project config file there is your own user config; use limitcast trim --codex --apply or --grok --apply instead.

Codex and Grok used to show 1 and 0 here (0.19.2): the optimizer only looked at three Codex built-ins and nothing on Grok. The Claude column is unchanged at 193 even though the Claude tool catalog now holds 317 tools (the cap was raised from 200 to 400); proposals need five sessions of evidence, so newly seen tools cannot qualify yet.

For limitcast's own repository (140 tracked files, v0.19.4) the repository map fills its 6,000-character default budget. Injection stays off until you run limitcast optimize map on, so weigh that recurring context against the searching it saves.

One useful command

limitcast optimize capabilities --grok

Use --codex for Codex. Read-only preview: it lists the MCP servers (and, on Codex, built-in capabilities) the optimizer would propose turning off in this repository, and nothing else changes until you pass --apply <name>. Needs Node.js 20+, a Git repository, and at least five recorded sessions and ten prompts with the optimizer on (limitcast install --optimize, restart your coding tool; Codex asks you to review and trust the new hooks). limitcast optimize status shows the same proposals for all hosts, plus which features are on.

Output from limitcast 0.19.4 on November 13, 2026, in a synthetic one-file repository with an isolated home and state directory, so it shows a fresh setup with nothing recorded yet:

$ limitcast optimize capabilities --grok
{
  "host": "grok",
  "proposed": [],
  "applied": [],
  "keep": []
}

proposed is empty here because there is no evidence yet. A preview is a suggestion, not proof a hook fired live. Anything you apply can be undone with --undo, and LIMITCAST_ALLOW=1 bypasses the optimizer hooks.

One question

On Codex and Grok the optimizer now proposes idle MCP servers. If you try limitcast optimize capabilities --codex or --grok, did it propose servers you would really switch off? And would you rather it applied per project (what --apply does) or for all projects (what trim does)? Tell us your coding tool and what made you decide, without sharing prompts, logs, private names or paths.

Follow shipped releases with Watch → Custom → Releases and enable email delivery in your GitHub notification settings if you want release emails.