Expose usage + model controls for -p (non-interactive) automation

[yaumoo]

Context

We're hitting Command Code from an automated multi-agent orchestrator that fans out coding tasks across several CLI agents (codex CLI, Claude Code, Command Code). The orchestrator picks an adapter per task and records token usage + cost + model for budgeting, audit, and savings telemetry (subscription vs. metered API).

Command Code is in the consideration as the open-weights path. We invoke it via commandcode -p <prompt> --skip-onboarding --yolo -t inside a per-task working directory, which works great — the agent runs, edits files, returns clean stdout. But three control surfaces that exist on codex exec and claude -p are missing on commandcode -p, which forces us to flag those dimensions as "unknown" on every run.

Filing one bundled ask because the three are tightly related (programmatic control of a non-interactive run).

Asks

1. Emit usage in -p output (highest impact for us)

claude -p --output-format json returns:

{
  "type": "result",
  "total_cost_usd": 0.1969,
  "usage": {
    "input_tokens": 4,
    "output_tokens": 8,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  },
  "num_turns": 1
}

codex exec persists similar info to ~/.codex/sessions/<date>/rollout-*.jsonl (event_msg records with type: 'token_count').

What we'd love from commandcode — either of these works:

• (preferred) commandcode -p --output-format json <prompt> that returns a final JSON line with at minimum { tokens: { input, output, cached? }, model, provider, plan_type? }.
• (alt) Persist usage in the session JSONL at ~/.commandcode/projects/<slug>/<sessionId>.jsonl so we can post-hoc read it the same way we read codex rollouts. Today the JSONL records role / content / timestamp / parentId / gitBranch / metadata.{source,version,messageId} — no usage/tokens/cost field anywhere across the captured sessions we've inspected.

A surprise we hit: -p --skip-onboarding --yolo -t mode doesn't seem to create a project dir entry at all for our system-tmp-rooted working directories (every other commandcode mode does). If usage lands in the project JSONL we'd also want -p mode to create it.

2. --model <id> flag on commandcode / commandcode -p

codex exec --model gpt-5-codex and claude -p --model sonnet accept a per-invocation model pin. Today the only way to switch Command Code's active model is the interactive /model slash command (or Alt+P quick switch), which is unreachable from -p.

Ask: accept --model <id> on the top-level CLI (and on -p), overriding ~/.commandcode/config.json's model field for the duration of the invocation. A COMMANDCODE_MODEL env var would also work and is arguably easier to wrap.

Use case: an orchestrator that picks the model per task can't currently pin commandcode the way it pins the other CLIs — it has to silently fall back to whatever the operator last selected via /model, which makes the open-weights lane the only one without per-task model control.

3. commandcode status --json (small but useful)

The interactive /context slash command shows context window usage. Surfacing status --json with { user, model, provider, plan_type, context_window, auth: 'oauth'|'api-key' } would let automation:

• detect the active model + plan without parsing TTY output
• record auth mode in session events so it can compute "saved vs. theoretical" cost (we do this for claude via JSON output: actual=0 / theoretical=0.1969 when running on subscription)

What we're shipping in the meantime

To be transparent about the workaround: our adapter currently emits a loud budget.unsupported-dimension skip log on every commandcode run for tokens, usd, tool-calls, and (when set) a per-task model override. We treat the open-weights run as untracked — better than silently fabricating an estimate. Tiktoken-based estimation is a fallback we'd rather avoid since GLM tokenization isn't byte-identical to GPT/Claude tokenizers.

CLI versions tested

• commandcode 0.25.13
• claude --version and codex --version for shape comparison
• macOS Tahoe 26.4.1 (darwin/arm64), Node 25.9.0

Happy to chat / file three separate issues

If you'd prefer three separate issues (-p --output-format json, --model flag, status --json) just say the word. Bundling here for context because they all serve the same automation use case.

Thanks for shipping Command Code — the /init AGENTS.md auto-load and the open-weights option are exactly what we needed for an automated open-weights lane.

[vipulgupta2048]

Thanks for reporting this. Our non-interactive does require a few updates. What multi-agent orchestrator are you using if you don't mind me asking? Are you recording stats and metrics for finding the best agent and figuring out the best harness for the job?

[yaumoo]

Its a custom orchestrator that I am building that is supposed to cover my whole development cycle with human gates as needed and it's provider agnostic so that I can switch in any harness for any step.

And your assumption is the main reason: i want to analyze the token effiency for certain tasks e.g. plan vs design vs implement and have a baseline and to validate my own biases (this also includes output validation).

Additionally I work on a couple of client projects and i want to be able to track cumulative costs for a certain project.