name: codex-cost-estimate description: Use when the user wants a realistic codebase cost estimate, Codex ROI summary, or tweet-style terminal report for a finished or near-finished software project. Inspect the repo, size the product scope, estimate human rebuild cost, and present a concise Value per Codex Hour summary with explicit assumptions.
Codex Cost Estimate
Produce a realistic, stakeholder-ready estimate for rebuilding the current repository from scratch.
Workflow
- Inspect the actual repo before estimating.
- Identify product scope, major subsystems, integrations, deployment targets, tests, and documentation.
- Measure approximate code volume by language and by major area.
- Use git history if available to estimate Codex working sessions.
- Estimate senior-engineer rebuild hours.
- Convert engineering cost into solo, lean-startup, growth-company, and enterprise scenarios.
- Present the result in a compact terminal-style block.
What To Inspect
- Top-level docs like
README,context, product notes, API docs - App, API, shared packages, schema, migration, and deployment files
- Test files or absence of tests
- Git commit timestamps and commit count
Do not assume a specific stack or repo layout.
Estimation Rules
- Prefer realistic ranges over inflated numbers.
- Use current US market assumptions.
- If current market rates can be verified with available tools, use current sources; otherwise use conservative rate assumptions and label them as assumptions instead of claimed research.
- Treat ROI and Codex-hour estimates as heuristics, not precise accounting.
- If confidence is weak, say so in the assumptions.
- If no tests exist, call that out because production-ready cost is understated.
- If marketing sites or prototypes are in the repo, separate them from core product code when useful.
Baseline Heuristics
- Basic UI / CRUD: 30-50 LOC/hour
- Standard business logic: 20-30 LOC/hour
- Complex integrations / async systems: 15-25 LOC/hour
- Data-heavy / domain-heavy logic: 12-22 LOC/hour
- Native / systems work: 8-18 LOC/hour
- Test automation: 25-40 LOC/hour
Additional effort:
- Architecture / design: +15-20%
- Debugging / troubleshooting: +20-30%
- Refactoring / review: +10-15%
- Integration / validation: +15-25%
- Documentation / handoff: +5-10%
- Domain learning curve: +10-20% when specialized expertise is clearly required
Company Multipliers
Efficiency assumptions:
- Solo: 65%
- Lean startup: 55%
- Growth company: 45%
- Enterprise: 35%
Team multipliers:
- Solo: 1.0x
- Lean startup: 1.45x
- Growth company: 2.2x
- Enterprise: 2.65x
Codex ROI Heuristic
Estimate Codex active hours using:
- Git commit clustering within 4-hour windows
- File modification clustering if git is weak
- LOC fallback if history is not useful
Use this framing:
Value per Codex Houris estimated value produced, not literal billed output.- Round to readable numbers.
- Prefer understatement over hype.
Output Format
Return the final answer in a screenshot-friendly terminal-style block:
Value per Codex Hour:
| Value Basis | Total Value | Codex Hours | $/Codex Hour |
|-------------|-------------|--------------|---------------|
| Engineering only (avg) | $X | X hrs | $X/Codex hr |
| Full team (Growth Co) | $X | X hrs | $X/Codex hr |
Speed vs. Human Developer:
- Estimated human hours for same work: X hours
- Codex active hours: X hours
- Speed multiplier: Xx
Cost Comparison:
- Human developer cost: $X (at $Y/hr avg)
- Estimated Codex cost: ~$X
- Net savings: ~$X
- ROI: ~Xx
---
Grand Total Summary
| Metric | Solo | Lean Startup | Growth Co | Enterprise |
|--------|------|--------------|-----------|------------|
| Calendar Time | X | X | X | X |
| Total Human Hours | X | X | X | X |
| Total Cost | $X | $X | $X | $X |
The Headline
[One short paragraph summarizing Codex hours, engineering-equivalent value, and growth-company equivalent cost/time.]
---
Assumptions
1. [Assumption]
2. [Assumption]
3. [Assumption]
Guardrails
- Do not invent frameworks, integrations, or phases not found in the repo.
- Use explicit assumptions when inferring hourly rates or Codex hours.
- Separate core product estimate from optional supporting surfaces when that materially changes the number.
- For realism, prefer a conservative base estimate over a flashy one.