Workflow · October 12, 2026

Build a Model-Tiering Cost Plan for Your Codex Deployment: A Legal-Ops FinOps Prompt Workflow

✓ TestedDeveloperFor Developer

Time saved4 hours per quarterly review

The task

You run or maintain a Codex deployment for a team. Someone upstairs just read the LegalOn write-up and wants to know whether you can do the same thing. This workflow turns a messy task inventory into a defensible tiering plan (Astra / Sol / Luna), a monthly cost estimate, and a rollout memo you can send to engineering leadership.

Before AI

Normally this is a half-day exercise: pull a week of Codex telemetry, group runs by task type, look up token prices for each candidate model, build a spreadsheet with assumed input/output token splits, write a short recommendation, then revise it twice because someone questions the assumptions. Call it four hours of focused work for a thoughtful first pass.

The LegalOn case is a useful anchor — LegalOn cut estimated daily Codex costs by 65% while maintaining development speed by matching Astra, Sol, and Luna to tasks and managing budgets strategically — but the lesson generalizes. As one post-mortem put it, the useful lesson is not cheaper coding agents by default, but disciplined task routing, budget controls, and measuring speed before you cut. That's what this workflow produces: the routing plan and the numbers to defend it.

The workflow

1. Classify every recurring task by reasoning intensity

Paste your task inventory (from Codex logs, Jira labels, or just an honest list) into the first prompt. The model groups items into three tiers using the published guidance that Astra is recommended for complex reasoning and coding, Sol for a balance of capability and cost, and Luna for well-specified repeatable work.

Prompt

You are a FinOps analyst helping a developer tier their Codex workload across three OpenAI coding models:

- ASTRA — top-tier reasoning. Use for: architectural changes, novel debugging across unfamiliar code, cross-repo refactors, security-sensitive logic, anything where a wrong answer is expensive to catch later.
- SOL — balanced default. Use for: feature implementation inside a known codebase, non-trivial bug fixes, test authoring that requires understanding intent, code review of medium-complexity PRs.
- LUNA — light tier. Use for: docstrings, boilerplate, mechanical refactors, lint fixes, regenerating fixtures, well-specified one-shot edits, bulk renames, straightforward test scaffolding.

You will receive a task inventory below. Each row has: task_name, approx_runs_per_week, avg_input_tokens, avg_output_tokens, current_model, notes.

Produce a markdown table with columns: task_name | recommended_tier | why (one sentence) | risk_if_wrong (low/med/high) | confidence (low/med/high).

Rules:
- Default to SOL unless there is a specific reason to escalate or demote.
- Mark confidence LOW for any task where the notes are ambiguous or the token counts look off.
- Do not invent tasks. Only tier what is in the inventory.

Task inventory follows.

Sample input

task_name,approx_runs_per_week,avg_input_tokens,avg_output_tokens,current_model,notes
cross_repo_api_migration,8,45000,12000,astra,touches 4 services; auth changes
pr_review_backend,120,18000,3500,astra,standard review of 200-800 LOC PRs
pr_review_docs_only,40,6000,1200,astra,README and markdown changes
flaky_test_triage,25,22000,4800,astra,inspects logs plus test file
docstring_backfill,300,3500,900,astra,one function at a time
fixture_regeneration,60,8000,2500,astra,deterministic schema-driven
feature_impl_known_module,35,30000,8500,astra,within billing service, well-scoped
security_patch_review,6,38000,6000,astra,CVE triage and patch drafting
rename_symbol_bulk,80,5000,1800,astra,mechanical, grep-level
unknown_production_outage_debug,3,55000,15000,astra,novel, cross-system

2. Price the current and proposed state

Now the machine has a tiered table. Feed it the price card and have it build the before/after cost model. Keep the per-million-token rates as a variable the reader can edit — pricing drifts.

Prompt

Using the tiering table you just produced, build a monthly cost comparison between the CURRENT state (everything on Astra) and the PROPOSED state (the tier you recommended).

Assume 4.33 weeks per month. Use these placeholder per-million-token prices — flag clearly that the reader must verify current rates before relying on the number:

- ASTRA: $12.00 input / $48.00 output per 1M tokens
- SOL:   $2.50 input  / $10.00 output per 1M tokens
- LUNA:  $0.40 input  / $1.60 output  per 1M tokens

For each task compute:
monthly_cost = runs_per_week * 4.33 * ((avg_input_tokens/1e6)*input_price + (avg_output_tokens/1e6)*output_price)

Output three things, in order:

1. A per-task table: task | monthly_runs | current_cost_usd | proposed_cost_usd | delta_usd | delta_pct
2. A totals row with current, proposed, absolute savings, and percent savings.
3. A short "sanity check" paragraph: which 2-3 tasks drive most of the savings, and which demotions carry the most risk per dollar saved. If the total savings percentage looks implausibly high or low versus the LegalOn-style ~65% benchmark, say so and name the likely reason (e.g. workload is already light, or Astra is justified for most tasks).

Show the math inputs you used so the reader can audit. Round dollars to the nearest cent.

3. Write the rollout memo and guardrails

Last step turns the numbers into something you can actually send. This is where you encode the budget controls the LegalOn piece hints at — turning Fast mode off by default and capping budgets by business stage — adapted to whatever stages your org has.

Prompt

Draft a one-page rollout memo to engineering leadership proposing the tiering change. Use the per-task table and totals from the previous step as the evidence base — do not re-derive numbers, cite them.

Structure:

**Recommendation** (2 sentences — what to change, expected monthly savings in dollars and percent)

**What moves where** (3 bullets, one per tier, naming the task categories)

**Guardrails** (4 bullets):
- Default model for new/unlabeled tasks
- When to escalate from the default to Astra (concrete triggers, not vibes)
- Budget cap per developer per day, and what happens when hit
- Which tasks are explicitly OFF-LIMITS to Luna (list them)

**Rollout** (3 bullets): week-1 shadow mode, week-2 opt-in, week-3 default — with a measurable success criterion for each week (e.g. "PR cycle time within 10% of baseline").

**Known risks** (2-3 bullets): the demotions most likely to cause pain, plus the pricing assumption caveat.

Keep it under 350 words. Plain English. No marketing language. Assume the reader is a skeptical staff engineer.

Gotchas

The price card goes stale. The numbers in step 2 are placeholders. Pull current per-token rates from your OpenAI billing dashboard before you send the memo. The structure holds; the digits don't.
Garbage telemetry in, garbage tiering out. If your avg_input_tokens is a guess, confidence on every row downstream is a guess. A week of real Codex run logs beats a thoughtful estimate.
Luna demotions are where the bodies are buried. A "mechanical refactor" that occasionally touches auth code is not a Luna task. Read step 1's risk_if_wrong=high rows manually before shipping.
65% is a ceiling, not a target. LegalOn's number came from a workload heavy on tasks that didn't need Astra. If your team genuinely does mostly novel cross-system work, honest savings may be 15-25%. Don't force the number.
Reasoning effort matters as much as model choice. This workflow tiers by model only. Sol-at-high and Sol-at-medium are different cost profiles for the same model name — a second pass can tier reasoning effort within each tier.
The memo is a draft, not a decision. Have one engineer who disagrees with you read it before it goes to leadership.

Time saved

Roughly 4 hours per quarterly review, down to about 30 minutes of prompting plus review time. The savings come from skipping the spreadsheet build and the first two memo revisions — the model produces a defensible structure on the first pass. The dollar figure the memo produces is only as good as your token-usage inputs and your current price card, so treat the output as a starting draft for a human review, not a finished finance artifact.

Code


## What we got when we ran it

We executed every prompt above, in order, against the sample input (model: claude-sonnet-4-6). Outputs below are real and unedited apart from length truncation.

### Step 1 output

| task_name | recommended_tier | why | risk_if_wrong | confidence | |---|---|---|---|---| | cross_repo_api_migration | ASTRA | Touches 4 services with auth changes — a cross-repo refactor with security surface where mistakes are expensive and hard to catch post-merge. | high | high | | pr_review_backend | SOL | Standard 200–800 LOC backend PRs in a known codebase are the canonical SOL use case; ASTRA is overkill at 120 runs/week. | med | high | | pr_review_docs_only | LUNA | Markdown and README reviews require no code reasoning; mechanical language-level feedback is sufficient. | low | high | | flaky_test_triage | SOL | Requires reading logs and test intent across a known codebase — non-trivial but not cross-system or security-sensitive. | med | high | | docstring_backfill | LUNA | One-function-at-a-time docstring generation is the textbook LUNA task; high volume makes demoting this especially impactful. | low | high | | fixture_regeneration | LUNA | Deterministic and schema-driven — output is mechanically verifiable, making this safe for the lightest tier. | low | high | | feature_impl_known_module | SOL | Well-scoped feature work inside a known module (billing service) is exactly the SOL sweet spot. | med | high | | security_patch_review | ASTRA | CVE triage and patch drafting is security-sensitive logic where an under-reasoned answer has high downstream risk. | high | high | | rename_symbol_bulk | LUNA | Grep-level mechanical renames carry no reasoning requirement; LUNA handles bulk symbol changes cleanly. | low | high | |

*…output truncated at 250 words.*

### Step 2 output

## ⚠️ Rate Disclaimer All prices are illustrative placeholders. **Verify current OpenAI API pricing before making any procurement or budgeting decisions.** Rates used: ASTRA $12.00/$48.00, SOL $2.50/$10.00, LUNA $0.40/$1.60 (input/output per 1M tokens). --- ## Math Inputs (Audit Trail) ``` monthly_runs = approx_runs_per_week × 4.33 task_cost = monthly_runs × ((avg_input_tokens / 1e6 × input_price) + (avg_output_tokens / 1e6 × output_price)) ASTRA input_price = $12.00 ASTRA output_price = $48.00 SOL input_price = $2.50 SOL output_price = $10.00 LUNA input_price = $0.40 LUNA output_price = $1.60 ``` --- ## 1. Per-Task Cost Table | task_name | recommended_tier | monthly_runs | avg_input_tok | avg_output_tok | current_cost_usd | proposed_cost_usd | delta_usd | delta_pct | |---|---|---|---|---|---|---|---|---| | cross_repo_api_migration | ASTRA | 34.64 | 45,000 | 12,000 | $38.70 | $38.70 | $0.00 | 0.0% | | pr_review_backend | SOL | 519.60 | 18,000 | 3,500 | $196.27 | $23.64 | −$172.63 | −87.9% | | pr_review_docs_only | LUNA | 173.20 | 6,000 | 1,200 | $16.97 | $0.75 | −$16.22 | −95.6% | | flaky_test_triage | SOL | 108.25 | 22,000 | 4,800 | $53.49 | $8.17 | −$45.32 | −84.7% | | docstring_backfill | LUNA | 1,299.00 | 3,500 | 900 | $118.47 | $3.65 | −$114.82 | −96.9% | | fixture_regeneration | LUNA | 259.80 | 8,000 | 2,500 | $55.41 | $1.87 | −$53.54 | −96.6% | | feature_impl_known_module | SOL | 151.55 | 30,000 | 8,500 | $108.79 | $25.47 | −$83.32 | −76.6% | | security_patch_review | ASTRA | 25.98

*…output truncated at 250 words.*

### Step 3 output

# Proposed: Codex Model Tiering — Engineering Leadership Review **Date:** 2025-07 | **Author:** FinOps | **Status:** Pending Approval --- ## Recommendation We are running ten Codex task types exclusively on ASTRA; tiering them appropriately across ASTRA, SOL, and LUNA reduces projected monthly spend from **$685.31 to $160.89**, a saving of **$524.42 (76.6%)** with no tasks demoted beyond what their complexity warrants. We are asking for approval to execute a three-week phased rollout beginning next sprint. --- ## What Moves Where - **Stays on ASTRA (3 tasks):** `cross_repo_api_migration`, `security_patch_review`, `unknown_production_outage_debug` — auth changes, CVE triage, and novel cross-system debugging where a wrong answer is expensive to catch. - **Moves to SOL (3 tasks):** `pr_review_backend`, `flaky_test_triage`, `feature_impl_known_module` — non-trivial work inside known codebases where cost-per-call is high and ASTRA's reasoning depth isn't justified by the task scope. - **Moves to LUNA (4 tasks):** `docstring_backfill`, `fixture_regeneration`, `rename_symbol_bulk`, `pr_review_docs_only` — mechanical or deterministic tasks with verifiable outputs where volume makes ASTRA use simply wasteful. --- ## Guardrails - **Default for new/unlabeled tasks:** SOL. Any task not explicitly tagged routes to SOL until classified. - **Escalate to ASTRA when:** the task touches more than one service boundary, involves auth or secrets handling, has no existing test coverage to catch a wrong answer, or the developer has already iterated twice on SOL without resolution. - **Daily budget cap:** $4.00 per developer per day. On breach, the task queue pauses and the developer receives a Slack alert; no silent overrun. Cap can be overridden by a staff

*…output truncated at 250 words.*

Source: openai.com

More for Developer professionals →

Get the next one in your inbox

One daily brief. Every story gets a hype verdict.

No spam. Unsubscribe anytime.