Skip to content

Repository files navigation

Codex Reasoning Assistant

Introduction

This plugin first reads the active configuration and assesses whether it fits the task. It then selects one quality-sufficient GPT-5.6 model and reasoning-effort combination for each configuration segment, minimizes estimated successful-task Codex Credits, and uses blocking time only as a tie-breaker. The runtime is local and offline.

Routing policy

The router no longer locks one model family first. It matches every applicable versioned work class. Each class contains one model only, while a model may own several classes. The router chooses the lowest evidence-qualified member in each class, removes dominated expensive routes, and compares the class winners by estimated successful-task price. Reliable user-blocking time is used only when price intervals overlap.

The evidence catalog retains all 17 host-supported combinations. Runtime routing uses 10 candidates: 9 daily candidates plus 1 conditional candidate:

Luna: Low, Medium, High, XHigh
Terra: none
Sol daily: Low, Medium, High, XHigh, Max
Conditional: Sol Ultra

Luna Max and every Terra effort remain evidence-only combinations. In Sol work, High covers at most one of the five core task facts at level 3; two or more level-3 facts select XHigh, while compound level-2 risk remains High. Sol Max is selected only for an explicit Max floor or the fixed gpt-5.6-sol-xhigh route ID after an observed or user-reported quality failure in the same configuration segment. Ordinary difficulty cannot trigger Max. Sol Ultra remains the formal conditional combination for qualified independent critical-path parallel work. Capability position is recorded inside each work class; one fixed cross-model ladder no longer substitutes for classification and quality coverage. Each task-fact scope also has a separate minimum-execution boundary, which may equal recommended quality and may be lower only with independent evidence; there is no blanket downgrade.

Quality evidence is explicitly qualified, unqualified, or unknown; unknown evidence never passes through zero-valued defaults. Cost estimates are conservative lower/upper intervals covering main work, sub-agents, retries, rework, switches, and context recovery. An economic switch is justified only when the cheaper upper estimate plus switch overhead is below the current lower estimate. Official per-million-token Credits rates are Luna 5/0.5/30, Terra 50/5/300, and Sol 125/12.5/750 for uncached input/cached input/output. Broad policy intervals are priors, not measured task usage.

The current evidence version is 2026-08-14.1. All 17 recognized actual configurations use the same deterministic local router. Daily, conditional, and evidence-only status controls recommendation eligibility, not access to routing. The first lower minimum-execution path is deliberately narrow: Luna Medium may execute one low-ambiguity, low-impact, low-tool-state Luna clear-execution scope whose dependency and verification facts are both level 2, while Luna High remains the recommended-quality combination. Every other class still defaults minimum execution to recommended quality. Class-quality evidence, external capability/speed benchmarks, price priors, and measured protocol observations are source-labelled separately; protocol success proves only that the plugin can run stably, not task quality.

Runtime interface and lifecycle

The plugin exposes one local MCP tool with two phases:

  • start accepts the actual configuration and either one task-signal object or at most three ordered homogeneous work units. It always keeps the task preference independent from the active configuration. Every recognized actual configuration receives a normal route receipt and task execution target; there is no intermediate model switch performed only to reroute. The five normal outcomes remain: continue silently, continue despite overqualification, finish the current independent unit then switch, switch before work, or deliver a safe independent part then switch.
  • finalize classifies the reply as current work, discussion, draft, qualifying future work, or a formal Plan. It accepts either one task-signal object or up to three ordered work units and returns whether a recommendation is required and, when required, the unique model/effort.

Six Hook events provide the mechanical adapter: SessionStart, SubagentStart, UserPromptSubmit, PreToolUse, PostToolUse, and Stop. The schema-11/frequency-dedup-v14 receipt stores the action, exact anonymous turn ownership, one same-turn reroute budget, one recovery-notice flag, current preferred and execution combinations, and—only for the two split actions—the later preferred and execution combinations plus the net-savings fact. After Desktop restarts into an updated plugin, a normal resume rebuilds current-contract state for an existing task and obtains a current-version route. SessionStart(source=compact) restores a receipt only when its schema and contract exactly match the current version, then injects one anonymous line containing only the action and model/effort combinations. Older schema or contract receipts are never promoted into current qualification decisions; they require a safe new route. UserPromptSubmit never blocks a user task. Before a valid start receipt exists, the injected contract requires the local router first. If Desktop drops both lifecycle-context paths in a resumed task, PreToolUse pauses the first ordinary business tool before execution and puts the same nonce and route contract directly in the model-visible denial reason. Codex documents additionalContext as the non-blocking path, so the plugin does not combine it with permissionDecision=deny. A stale nonce is rejected before reaching the router, and a state without a valid receipt requires one full new_or_changed route rather than same_segment. This initialization recovery is not an insufficient-capability decision; plain-text answers and user-requested task creation remain usable. Once a valid insufficient-capability switch_before_start receipt exists, business tools are denied until the configuration changes or the user explicitly overrides the current segment; finalize and override routes remain available so the user still receives a switch response. It denies an autonomous task without a valid continuing receipt only when the Hook payload explicitly identifies a Codex/assistant origin; unknown origin otherwise fails open because the official Hook contract defines no origin field. PostToolUse is the primary receipt path. If Desktop code mode omits its nested router event, the local MCP publishes a one-shot receipt containing only anonymous allowlisted fields, bound to the random route_id, deleted on first consumption, and expired after ten minutes. If the host retains an older MCP worker across plugin replacement, the next PreToolUse or Stop may instead read only the current turn's structured MCP completion from the bounded rollout tail; both fallbacks require the same random route_id and pass through the same strict anonymous adapter.

Continuity is evaluated once per new host turn_id, not once per user message. When an existing task resumes and Desktop does not deliver the SessionStart context to the next model request, the immediately following initial UserPromptSubmit reuses the same nonce and reinjects the current-version route; it is not misclassified as a same-turn supplement and adds no route call. After that initial prompt, same-turn supplements take a constant-time anonymous turn comparison, preserve the receipt and nonce, and make no router or separate model call. Codex may request at most one same-turn full route when its ordinary interpretation finds a material change to the task, risk, verification requirement, or independent segment. An excess router call alone is skipped; ordinary tools and the user-visible answer remain available. Continuity is not inferred from keywords.

Stop validates current-turn structured receipts and requires a returned model/effort pair to appear together exactly once. It does not scan fixed headings, recommendation wording, or “next step” keywords. It may request one correction for a missing finalize or inconsistent recommendation while instructing Codex to retain the complete answer. A second failure passes the answer through with one unverified warning.

A simple current load/active-status probe uses only the injected actual snapshot and one start/finalize pair. It does not read Memory, search plugin paths or caches, inspect source or installation parity, or create another task. This keeps the live check bounded while preserving the distinction between source, installation, host loading, and live behavior.

State files contain only bounded policy, configuration, route, action, finalize-classification, and retry fields. Their filenames and turn indices use HMAC-SHA-256 with a local random index key; raw prompts, replies, project paths, accounts, session IDs, and full task summaries are never persisted. Stale state is pruned after a short TTL.

Host operations hidden inside an outer exec that emits no observable Hook event remain outside mechanical interception. Source tests, installation state, host loading/trust, and real-session behavior are four separate acceptance layers.

Installation

Requirements: a Codex surface with plugin and lifecycle-hook support, Python 3.10+, and on Windows the standard py launcher on PATH.

codex plugin marketplace add richie-liu512/codex-reasoning-assistant --ref main

Install Codex Reasoning Assistant, trust its Hooks, and restart Codex Desktop. New tasks load it directly; existing tasks also rebuild current-version routing state when resumed after the restart. Disable duplicate reasoning-effort Hooks from other copies.

Development

python plugins/codex-reasoning-assistant/scripts/verify.py

This verifies structure, privacy, syntax, Hook commands, the local router, MCP transport, and tests. It does not prove installation, host loading, trust, or real task benefit.

See README.zh-CN.md, docs/reasoning-policy.md, PRIVACY.md, and SECURITY.md.

License

MIT License. LICENSE.zh-CN is an unofficial Chinese translation.

About

读取当前 Codex 模型与推理等级,按配置区段判断是否适合后续工作,并只在切换有实际价值时给出建议。 / Reads the active Codex model and reasoning effort, evaluates the next configuration segment, and surfaces only worthwhile switches.

Topics

Resources

Contributing

Security policy

Stars

1 star

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages