What a study costs

There is no humanish price. humanish is free and MIT-licensed, and a live study is billed by the providers you bring: a model for the participant, a hosted desktop, and a separate analysis call. This page puts numbers on each line from the maintainer's own kept runs, then shows how to bound them. Every amount below is an estimate at dated rates, read from a run bundle or the rate table; your provider bill is authoritative.

Pay three providers for a live studyCopy Anchor Link

Rates in the table carry an asOf date and a source. On 2026-09-05 the desktop rate was $0.000014 per CPU-second and $0.0000045 per GiB-second (e2b.dev/pricing); on 2026-10-21 the default computer-use model gpt-6.1-sol was $2 per million input tokens and $10 per million output tokens (developers.openai.com/api/docs/pricing). On 2026-10-26 claude-haiku-5-5 was $0.10 per million input tokens, $0.125 per million written to the 5-minute cache, $0.01 per million read from it and $0.50 per million output tokens (platform.claude.com/docs/en/about-claude/pricing). A Claude request whose prompt, counting uncached, cache-read and cache-write tokens, is over 100,000 tokens bills every one of its tokens at 5 times those rates; each request is priced on its own. The participant's server-side clearing of old screenshots starts at 60,000 input tokens to keep requests under that tier. A reply that reports a non-standard service tier, an inference region other than global, or 1-hour cache writes is marked as usage the table cannot price, so a capped participant stops instead of being priced low. A model without a table rate makes a capped run refuse to start instead of running unpriced.

Start without spendingCopy Anchor Link

Four steps cost nothing and need no keys:

1. npx humanish watch opens the Observer on a bundled sample run. It does not open your app and sends no participant anywhere.
2. npx humanish run <study> --dry-run does a dry run of your study without a browser, keys or provider spend, so a mistake in the study file surfaces before a desktop exists.
3. npx humanish telemetry disable (or DO_NOT_TRACK=1) stops usage telemetry.
4. review.analysis: false in the study keeps the analysis call out of the first live run.

The first paid step is one participant. Store the keys first, then run npx humanish run try-live against a synthetic account on the target, with the E2B console open so you can watch the desktop end. Read the bundle's cost block and providerResources before running a panel.

Read the measured costs from kept runsCopy Anchor Link

npx humanish stats --json over the maintainer's project on 2026-09-28: 136 runs, 129 live, 152 participants, $61.63 of estimated run spend plus $2.29 of analysis. 23 runs are unpriced because their participants were signed-in agents.

Two single runs, line by line:

• A site-reading participant on 2026-09-28: 101 seconds, 20 actions, $0.325 model (gpt-5.6-sol, rates as of 2026-09-03) plus $0.017 desktop (1.96 minutes of an 8 vCPU / 8 GiB desktop, rates as of 2026-09-05). Total $0.34.
• The three-participant lobby study on 2026-09-16: about $3.14 estimated model spend across three desktops for a five-round game. The eight-participant study of 2026-09-27 ran about 13 minutes per desktop; its analysis on gpt-6-astra at high effort, the default analyst then, was admitted at an $11.38 estimate and came to $2.29. At gpt-6-astra rates the estimator now expects $2.72 for that run, with a $3.36 worst case.

Three fresh installs on 2026-09-01 completed the starter study in 108 to 111 seconds at about $0.16 per run; the dated receipt has the run ids.

Estimate your own studyCopy Anchor Link

Add the lines for one participant, then multiply by the panel:

1. Desktop: the minutes the desktop is held, times $0.009 for the default template. That is the session (execution.timeoutMs) plus the clone and build on a clone or local-tree subject. If humanish cannot close the desktop, the provider stops it at the sandbox deadline: timeoutMs, plus 30 minutes of provisioning room on those subjects, plus a 10-minute buffer. For a 10-minute session that ceiling is 50 minutes, about $0.45.
2. Model: the runs above spent $0.10 to $0.55 per participant-minute of active use on gpt-5.6-sol; a quiet waiting-room participant spends far less than one that reads and types. Budget $0.30 per minute for a busy participant and you will be high. On the default gpt-6.1-sol, a Taskly benchmark participant cost about a third of what gpt-5.6-sol cost, so these figures run high for it.
3. Analysis: one request per study. study check gives the expected cost range for the study's participant count, and the expected cost and worst case are printed before the request; the default cap is $10. A Codex participant's run is analyzed by the same Codex account, with no dollar figure. The default analyst is gpt-6.1-sol at medium effort. On the same recordings on 2026-10-22 it cost a mean $0.06 per one-participant Taskly analysis and $0.08 to $0.29 per three-participant movie-game analysis, against $0.41 and $0.88 to $1.76 for gpt-6-astra at high, the earlier default (the comparison).

A six-participant, ten-minute study on hosted desktops therefore lands between about $3 and $20 in model spend, about $0.54 of desktop session time plus each desktop's build minutes, and one analysis, expected at $0.20 to $0.81 for six participants depending on how much evidence the run keeps. The default $10 cap admits that range. A study that names a more expensive analyst, such as gpt-6-astra at $1.00 to $4.04 for six, can still be refused when it keeps more evidence, because both its worst case and its expected cost plus a 10% margin are over the cap. Run it once with --dry-run to check the file and once live with caps before scaling the panel.

Set a study budgetCopy Anchor Link

For the computer-use route, declare both the study budget and a per-participant backstop:

caps:
  maxTotalUsd: 4
  maxUsd: 2
execution:
  target: e2b-desktop
  timeoutMs: 600000

• maxTotalUsd tracks estimated model spend across the study. A participant whose start comes after the study crossed it, in a later wave or later in the schedule, is skipped before its desktop is created and recorded as blocked with the budget as its reason.
• maxUsd applies to each participant. Without a study cap, four participants at $2 each have separate thresholds totaling $8; actual spend can exceed that sum.
• Both thresholds are checked after each model response reports usage and again before each participant's next model request, so once the study crosses maxTotalUsd no participant sends another one. They do not reserve the cost of the next request: requests already in flight, at most one per running participant, can cross a threshold before the participants stop. They are not hard provider billing limits.
• E2B desktop time, app provisioning, and any services used by your target app are additional. Desktop estimates use dated assumptions; your provider bill is authoritative.
• A model without a known rate cannot satisfy a computer-use cap, so the run is refused instead of being treated as free.

The included try-live study uses one participant, maxUsd: 2 and maxOutputTokens: 8192. It is sized for learning the product; set your own caps for other tasks. When init finds no OpenAI key and a signed-in Codex or Claude Code, it writes try-live with a local-agent participant (Codex when it is signed in, otherwise Claude Code) and no dollar cap: account usage has no dollar price humanish can enforce, and the 10-minute execution.timeoutMs bounds the run.

Supported live runs also request post-run analysis by default. This sends selected retained text and captures to OpenAI, using OPENAI_API_KEY, with a separate $10 cap on its expected cost. A study whose participant is a Codex local-agent is analyzed by the same Codex account instead, and needs no OpenAI key. review.analysis: {provider: gemini, maxCostUsd: 2} sends the request to Google's Gemini API instead, with the key from humanish keys set gemini; Gemini Flash bills less per token than gpt-6.1-sol, though on the 2026-10-22 Taskly recordings gemini-3.8-flash at high cost $0.10 per analysis against the default's $0.06. It is additional to participant budgets and desktop time, and is not a provider billing cap. Preflight and live-start output disclose it. Set review.analysis: false to disable the request, or review.analysis.maxCostUsd to choose another limit. A missing default analysis key records a skip, keeps a successful recording successful, and names the next command: humanish analyze --run <id> --provider codex when Codex is signed in. So does a default analysis whose expected cost is over its cap; the CLI, humanish review and the Observer then give the expected cost, the worst case and the humanish analyze command that runs it with a sufficient --max-cost. An analysis you declare in the study still fails when its expected cost is over its cap. Dry runs and the preview route make no analysis request.

Analysis usage is stored separately from participant costs. Inspect it with humanish analyze list --run latest --json; unknown usage remains unknown.

npx humanish stats --study try-live --json

Inspect the run's estimated model and desktop costs, rates, and missing-usage fields. An unknown amount means unknown, never zero. A budget_reached computer-use session is incomplete; reaching a threshold does not establish task completion.

Cap a terminal study by timeCopy Anchor Link

The terminal route reads caps.maxUsd, caps.maxJobs and caps.maxMinutes from the same top-level caps block, and refuses caps.maxTotalUsd. humanish has no cost source for a terminal study. Codex tokens are counted but unpriced, and humanish measures no product, media or payment spend, so a positive maxUsd could never trip. A live terminal run refuses it with HUMANISH_TERMINAL_UNPRICED_CAP. Adopter-supplied cost sources are planned in issue 347.

Set maxUsd: 0 and bound the run with caps.maxMinutes, which stops the agent command. The sandbox's timeout adds the setup before the agent command (up to 6 minutes, or 11 with subject.product.install) and a 5-minute teardown buffer to maxMinutes, and it may not pass the sandbox ceiling. At the default 60-minute ceiling a live run therefore refuses a maxMinutes above 49, or 44 with a product install (HUMANISH_TERMINAL_CAPS_INVALID). The run's cost summary prices the terminal sandbox's compute time the way it prices a computer-use desktop, from its span and size; that estimate is not counted against maxUsd. A terminal run that exceeds its spend cap keeps the agent's own verdict and still fails, with HUMANISH_TERMINAL_CAPS_EXCEEDED; the review and status.json name the cap.

Set the sandbox lifetime your E2B plan allowsCopy Anchor Link

E2B ends a sandbox after 1 hour on its Hobby plan and after 24 hours on Pro. Its API does not say which plan a key belongs to, so humanish keeps every hosted sandbox under a ceiling of 60 minutes unless HUMANISH_E2B_MAX_SANDBOX_MINUTES sets another. On Pro, set it to 1440, or to any whole number of minutes from 1 to 1440:

export HUMANISH_E2B_MAX_SANDBOX_MINUTES=1440
npx humanish doctor

doctor prints the ceiling in use on its e2b sandbox ceiling row. A computer-use, shared-world or live terminal study whose sandbox deadline passes the ceiling is refused before any sandbox is created; the refusal gives the deadline and the setting value that would admit it. A value outside 1 to 1440 refuses those studies too. The key store holds provider keys only, so set the ceiling in your shell or in a --dotenv file.

A higher ceiling lets you declare longer sessions, and a session you declared keeps its length. It changes one default: a computer-use clone or local-tree study without execution.timeoutMs gets what the ceiling leaves after provisioning and seeding, up to 30 minutes, where the 60-minute ceiling leaves 20. Every minute of a desktop is billed, so declare execution.timeoutMs when you want a fixed session.

Set how many sandboxes your E2B plan runs at onceCopy Anchor Link

E2B runs 20 sandboxes at once on its Hobby plan and 100 on Pro, which add-ons raise to 1,100. Each participant on a hosted desktop is one sandbox, and a provisioned shared-world study keeps one more for its app. E2B's API does not say which plan a key belongs to, so humanish runs at most 20 at once unless HUMANISH_E2B_MAX_CONCURRENT_SANDBOXES sets another. On Pro, set it to 100:

export HUMANISH_E2B_MAX_CONCURRENT_SANDBOXES=100
npx humanish doctor

doctor prints the limit in use on its e2b concurrent sandboxes row. A study runs every participant at once unless execution.concurrency sets fewer or the study starts participants over time. When the limit is lower than that, the participants run in waves, and the plan says how many run at a time and which setting raises it. A participant whose start comes while every slot is taken waits for the next free one. An execution.concurrency above the limit is refused before any sandbox is created, with the setting value that would admit it. HUMANISH_CUA_MAX_CONCURRENCY applies first: a declared value it lowers runs at the lower count, in waves when the limit is lower still. A local desktop study (execution.target: local) has its own capacity checks and does not read this setting. Like the sandbox ceiling, set it in your shell or in a --dotenv file.

Waves change how long a run takes. Each participant's desktop and model time stays the same, and caps.maxUsd and caps.maxTotalUsd bound the spend. A study has at most 100 participants on any plan.

Choose a modelCopy Anchor Link

The default computer-use model is gpt-6.1-sol at medium effort; the terminal route's Codex participant defaults to gpt-5.6-sol. Set actor.model in the study to pin another supported model. The checked-in rate table also prices models such as gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna, and gpt-5.5; consult the table in your installed version before assuming a newly available model is priced.

For first-party OpenAI computer-use studies, optional actor.maxOutputTokens sets a positive integer limit on each response's output, including reasoning tokens. It applies to every participant, continuation and retry. A participant's first request and a closing report use the smaller of this value and 1024, and 1024 when it is omitted: a first turn that asks for a screenshot needs a few dozen tokens. The first request also shows the model the opening screen. The effective setting is recorded in the actor's modelSettings; omitting it keeps the provider's normal output behavior after the first request.

A reply cut off by this limit runs no action. The same request is sent once more, after counting the cut-off reply's tokens against your caps, and the trace notes the retry. If the second reply is cut off too, the participant ends as budget_reached / incomplete with provider_output_limit; its partial output does not establish task completion. A small value can therefore end a session before it produces visible text. This setting does not bound input or context tokens, total requests, cumulative spend or desktop time. The terminal and scripted routes, local-agent participants, a custom provider passed through the library and per-participant overrides reject it.

A declared computer-use cap (maxUsd or maxTotalUsd) on an unpriced model is refused at preflight with HUMANISH_COMPUTER_USE_UNPRICED_CAP, and a shared-world one with HUMANISH_SHARED_WORLD_UNPRICED_CAP. This checks whether a rate is available; it does not prepay or reserve the next request. An absent cap is uncapped. A zero threshold can still allow a paid model request before its reported usage triggers the stop, so maxUsd: 0 is not a no-provider-call mode. Desktop provisioning can also incur charges.

A cap is kept from the usage each model reply reports. If a capped participant's reply comes back without usage, humanish sends that participant no further request and records usage_unreported. A request that stalls or fails in transit may still have been billed, so humanish counts its worst case against the cap before sending it again: the previous request's input plus the actor's maxOutputTokens, at the model's rates. The retry happens only when that fits. Without maxOutputTokens the worst case has no bound, so a capped study without maxOutputTokens stops on a stall instead of retrying (usage_unreported). The try-live study and the capped studies in humanish/studies/ set maxOutputTokens: 8192 for that reason.

How cost estimates workCopy Anchor Link

Computer-use bundles carry a per-participant model estimate and an aggregate E2B compute estimate. Model estimates multiply recorded token usage by a dated rate table. On the computer-use route, each desktop records its observed CPU and memory and a host-measured span from acquired handle to cleanup. Different template sizes are priced separately. Every amount is an estimate and never an invoice.

The rate table records its date, source, and whether a rate is a placeholder. Runtime desktop estimates use the allocation's resource readback; missing metadata stays unpriced. The legacy desktop helper uses a labeled 8-vCPU/8-GiB planning assumption, which is not a provider spending ceiling or a measurement of your template. Inspect those fields alongside the amount. An unknown model rate or missing token usage produces estimatedCostUsd: null with a reason; it is never silently counted as zero. Previews invent no spend.

Where the model has separate cache or long-context rates, per-request usage lets the estimator apply them. Missing usage limits what can be priced; a complete-looking total is not proof that every provider charge was observed.

On an OpenAI organization with zero data retention, the provider keeps no conversation, so a computer-use participant sends its whole conversation with every request. The actor trace records this as conversation.mode: explicit_context. Input per request grows with the session up to about 64,000 estimated tokens, then drops to about 32,000 as the oldest turns become a text note, and grows again. The provider's prompt cache can serve everything but the newest turn, except on the request after each drop, which is billed as new input. In a simulation of 120 turns on 1280x800 screens, 93% of input was cached and input cost about $3.70 on gpt-5.6-sol. In a live 54-request run on a 1920x1080 screen, 90% of input was cached and the participant cost $2.02. The trace's tokenUsage.turns has each request's cached and cache-write tokens.

Shared-world participants and their provisioned subject desktop, a scripted-browser clone's subject desktop, and the terminal sandbox are priced the same way.

Know what the numbers leave outCopy Anchor Link

• Anything your target app charges for, and any traffic it makes.
• Desktop allocation and startup time before humanish holds the handle, plan fees, credits and negotiated prices.
• Retries after provider interruptions, which appear as separate priced sessions in the bundle.
• A desktop kept for debugging or with unconfirmed cleanup: its line is marked incomplete and you should check the provider console.
• Model usage of a signed-in local-agent participant, which stays unpriced by design. A dollar cap does not bound plan usage; use a local coding agent has the setup and limits.

Every kept bundle carries its own cost block with the same breakdown, and npx humanish stats --study <id> --json rolls them up per study.

Disk spaceCopy Anchor Link

Runs stay in .humanish/runs until you remove them. Nothing deletes a run on its own.

A study of 30 participants working 8 hours keeps about 11 GB of screenshots, and about 24 GB more with video.

npx humanish runs lists each run's size and the project's total, and npx humanish doctor shows the total beside the free disk. A run that ends with more than 5 GB in the project says so.

npx humanish runs prune --older-than 30d lists what it would remove and deletes nothing. Add --yes to remove those runs. It keeps the latest run, a run still going, a remote run not yet copied back, and a run from the past week whose sandboxes were never confirmed stopped.