Summary
There is no cost estimate or cost summary anywhere in the zwill CLI, even though the workflow guardrails emphasize showing likely cost before spending:
Do not run costly EDSL jobs until the user has seen the plan, prediction count, model list, and likely cost/time risk.
zwill gives you the prediction count but never a dollar/credit figure — not before the run, not after. edsl-run has --dry-run (validates the job) but does not price it, and its completion output contains no cost line. The only way to recover actual cost is to decompress the raw results and reverse-engineer it from response_probabilities_one_usd_buys in the model responses.
What I had to do this session
To calibrate cost before authorizing a ~2000-call run, I ran a 3-call smoke test, then decompressed *_results.json.gz and computed 1 / response_probabilities_one_usd_buys per row to get ~$0.0165/call → ~$33 projected. This worked but shouldn't be necessary.
Opportunity: the new ep CLI already does this
The ep CLI (EDSL) exposes native cost tracking that zwill could wrap or adopt:
ep costs # Track estimated and actual job costs
ep costs log --output costs.jsonl --estimated 1.25 --model gpt-4o --agents 10 --questions 5
ep costs log --output costs.jsonl --actual-from results.ep --note "pilot run"
ep results cost results.ep
There is also a .ep package format (results.ep, survey.ep, agent_list.ep, jobs.ep) with ep metadata / ep inspect / ep results cost. If zwill emitted/consumed .ep artifacts (or shelled out to ep costs/ep results cost), cost could become first-class.
Suggested fixes
- Print an estimated cost alongside the prediction count at export/approve time (via
ep costs-style estimation).
- Print actual cost in the
edsl-run completion envelope and in twin-results import (via ep results cost / --actual-from results.ep).
- Consider adopting the
.ep package format for exported jobs and imported results so ep costs/ep results cost/ep metadata work directly against zwill artifacts.
Summary
There is no cost estimate or cost summary anywhere in the
zwillCLI, even though the workflow guardrails emphasize showing likely cost before spending:zwillgives you the prediction count but never a dollar/credit figure — not before the run, not after.edsl-runhas--dry-run(validates the job) but does not price it, and its completion output contains no cost line. The only way to recover actual cost is to decompress the raw results and reverse-engineer it fromresponse_probabilities_one_usd_buysin the model responses.What I had to do this session
To calibrate cost before authorizing a ~2000-call run, I ran a 3-call smoke test, then decompressed
*_results.json.gzand computed1 / response_probabilities_one_usd_buysper row to get ~$0.0165/call → ~$33 projected. This worked but shouldn't be necessary.Opportunity: the new
epCLI already does thisThe
epCLI (EDSL) exposes native cost tracking thatzwillcould wrap or adopt:There is also a
.eppackage format (results.ep,survey.ep,agent_list.ep,jobs.ep) withep metadata/ep inspect/ep results cost. Ifzwillemitted/consumed.epartifacts (or shelled out toep costs/ep results cost), cost could become first-class.Suggested fixes
ep costs-style estimation).edsl-runcompletion envelope and intwin-results import(viaep results cost/--actual-from results.ep)..eppackage format for exported jobs and imported results soep costs/ep results cost/ep metadatawork directly againstzwillartifacts.