What does garak cost to run when the license is free?
garak carries no license fee. It is free and Apache 2.0 licensed, so the budget a team needs sits in three places: model API or GPU time consumed by probes, engineering effort to configure targets and review results, and the ongoing operation of scans. Teams that have been asked to scan LLMs or applications usually find that the first estimate is wrong because it counts only the tool and ignores the traffic it sends and the people who read the output. Start the estimate by naming the targets, the probes you expect to run, and how often each target will be scanned. Those three inputs drive almost every other line in the budget.
Most teams start looking at cost of ownership after a specific trigger. Common ones include a board or customer questionnaire asking how prompt injection and data leakage are tested, a new LLM feature heading toward production, a change of model provider, or a decision to move off ad hoc jailbreak testing by hand. Each trigger changes the cost profile. A one-time assessment of a single chatbot has a very different shape from a recurring program covering several applications and models. Before anyone requests a budget, decide whether the funding covers a one-time baseline, recurring scans, or both, because the two are priced and staffed differently.
The cost components are easier to explain by who gets paid for what. Your model provider bills for the generations garak requests, and the default of 10 generations per prompt multiplies that traffic, so token or request charges grow with the number of probes and targets. Local models, including gguf models run through llama.cpp, consume GPU hours or host capacity instead. Engineering time covers writing the YAML that describes a REST endpoint, handling authentication, choosing detectors, and reviewing the JSONL reports and the garak.log file for false positives. Operations time covers scheduling, storing reports, and upgrading across releases. For a comparable estimate, pin the version you plan to use, such as v0.17.1, so that later runs on a newer release can be explained against the same baseline.
For most teams the short answer is that a first scan is usually worked out in-house, provided the team already runs Python and has someone who knows the target application. A partner becomes more attractive when the program spans many applications, when an assessor will ask for a documented and repeatable baseline, or when nobody has the time to keep scans running after handover. Whichever route you take, ask any provider for a quote that itemizes model API spend per run, the number of targets and probes, who reviews results, what is one-time and what recurs, and which garak version is pinned. DeployOpen works from written scopes agreed before work starts, so the same list is a useful checklist for comparing options.
What a garak cost of ownership review includes
A garak cost of ownership review turns the tool's zero license fee into a clear budget with named cost components. Each deliverable below is a written artifact the client keeps and can reuse when scan scope, models or staffing change.
Target inventory
A register of every model, gateway and application endpoint that garak would test, with its access method, owner, data sensitivity and whether it is a production system. garak can reach Hugging Face Hub models, OpenAI API models, AWS Bedrock models, models through LiteLLM, gguf models through llama.cpp and REST endpoints, and each route carries different cost and access work. Check that every target has a named owner before scan costs are modeled.
Run-cost model per target
A worksheet that estimates model API or GPU time for each target and probe set, using the default of 10 generations per prompt as one input. The model separates metered API spend from compute hours and shows how probe selection and repeat runs change the total. Ask the provider for current token and GPU pricing, since those rates are outside garak and vary by account.
Setup and review effort estimate
An estimate of engineering time for configuring generators, writing REST endpoint YAML, handling authentication, and reviewing JSONL reports and garak.log output after each run. Review time often exceeds scan time, because someone must triage FAIL results, confirm false positives and route findings to remediation owners. Ask for the assumptions behind each hour so the figure can be adjusted as scope changes.
Recurring operations cost sheet
A schedule of costs that repeat after the first scan, including scheduled runs, version upgrades for garak (the v0.17.1 release dated 16 October 2026 is one example of how often releases arrive), dependency maintenance on Python 3.11 or newer, and storage for report retention. Each line names who pays for it, whether it is internal staff time or vendor spend, and what triggers it.
In-house versus partner decision memo
A memo comparing the total cost and risk of running garak with your own team against engaging a partner on a fixed-scope basis. It sets out skills needed, staffing gaps, ownership of scan environments and reports, and the conditions under which each option is cheaper. Use it to decide the delivery model before asking for a quote, since the written scope drives the price.
Evidence limits and handover notes
A short statement of what these artifacts do not establish. DeployOpen does not issue audit reports or certifications, so the review supports internal budgeting and planning but is not an assessment that an independent auditor or certification body would issue. The notes also record which figures the client must confirm with providers and internal finance before the model is used.
Which factors raise or lower garak run costs and effort
This table lists the factors that move garak run cost and engineering effort, why each one matters, and how to keep it under control. Model API or GPU charges depend on the client's own API price sheet or GPU rates, not on figures published on this page. Read the rows as levers: the number of targets, prompts and probes multiplies every run, so scope them first.
| Driver | Why it moves cost | How to keep it down |
|---|---|---|
| Number of targets | Each model, gateway or application is a separate attack surface, so each one repeats the full probe set and pays its own API or GPU time. | Start with the systems that face users or hold sensitive data. Add gateways and other targets in later phases once baselines exist. |
| Generations per prompt | garak makes 10 generations per prompt by default, so every probe prompt costs roughly ten model calls per attempt before any evaluation. | Confirm the generation count with your team before a full run. Lower it for exploratory runs and keep the default for baselines you intend to compare. |
| Number and breadth of probes | Broad probe selection multiplies prompts across categories such as prompt injection, data leakage and jailbreaks, and each category adds calls and review time. | Select probes that match the threat model and the application's use case. Expand the set only when a category is in scope for an assessment. |
| Default probewise harness versus narrower runs | The default probewise harness runs each probe with its recommended detectors, which is thorough but produces the largest volume of attempts and reports. | Use narrower runs for routine regression checks and reserve the full probewise pass for scheduled or pre-release scans. |
| REST endpoint complexity and authentication | Custom endpoints need YAML configuration, authentication headers and response parsing, and each mismatch costs debugging time and failed or wasted calls. | Test the endpoint with a few requests first, validate the YAML and response parsing, and document the working configuration for reuse. |
| Evaluator or judge model choices | Model-based evaluators add their own API or GPU calls on top of the target calls, and a stronger judge usually costs more per evaluation. | Compare the evaluator options on a small sample, then choose one that meets your accuracy needs and document the choice for comparable runs. |
| Environments and repeat runs for baselines | Each environment (development, staging, production-like) and each repeat run for a baseline or comparison multiplies API or GPU time and storage. | Limit repeats to the runs needed for comparison, keep one reference environment for baselines, and pin the garak version so results stay comparable. |
| Review of JSONL reports and garak.log | Every run writes a JSONL report of each attempt and evaluation, plus a garak.log continued across runs, and reviewing them is often the largest engineering effort. | Filter reports to failing probes first, script summaries of failure rates, and assign a named reviewer with a clear triage rule. |
How a garak cost model is built in phases
A garak cost model moves from what you test and how you access it, through one measured pilot run, to a projected schedule, effort estimate and handover document you can use to compare build and buy decisions. Each phase closes with a named output so you can check progress before moving on.
Inventory targets and confirm access
Start by listing every model, gateway and application endpoint garak should cover, along with the access method for each: a hosted API key, a local model file, a GPU host or a REST endpoint described in YAML. Your team confirms who owns each target, which environments are allowed for testing and whether any endpoint has rate limits or usage terms that affect scan volume. The phase is complete when you hold a written inventory that lists each target, its access path, its owner and any test restrictions, and a named contact can confirm each one.
Select probes and detectors for a pilot
Choose the garak probe families that match your risk areas, such as prompt injection, data leakage, jailbreaks or toxicity, and confirm which detectors the default probewise harness would run for them. Pick one representative target and run a small pilot with the chosen probes to confirm that the configuration works, the report files are written and the results make sense to your reviewers. The output is a documented probe list, a pilot configuration file and a short pilot log that records what was run and what went wrong.
Measure one run's API or GPU use
Instrument a single full run on one target and record the number of generations, the API calls or tokens billed by the provider, or the GPU hours consumed on local hardware, along with wall-clock time. Garak's default of 10 generations per prompt is a major driver here, so note whether your chosen probes change that count. Done means you have a measured usage record for one run per target type, with the billing or hardware figures captured from the provider or host rather than estimated.
Extrapolate usage to the planned schedule
Multiply the measured single-run figures by the number of runs your planned schedule implies, covering frequency, number of targets, model version changes and any re-runs after remediation. Separate one-time setup usage from recurring scan usage so that the recurring cost is visible on its own. The phase closes with a projection table that shows the assumptions behind each multiplier, so a finance or security lead can change the schedule and see the effect without rerunning the pilot.
Estimate configuration and review effort
Estimate the engineering time needed to write and maintain endpoint YAML, handle authentication and response parsing, triage FAIL results in the JSONL reports and decide which findings need remediation. This is the cost most often left out of a model, and it depends on target count, how many distinct endpoints exist and how many reviewers must sign off. The output is an effort estimate broken down by role and task, with each assumption written down so your team can check it against its own capacity.
Hand over the cost model
Deliver the completed model as a document and working spreadsheet containing the target inventory, probe list, measured usage, extrapolated schedule, effort estimate and a list of open assumptions. Walk your owners through how to update each input when a target, price or schedule changes. The phase is complete when your team can rerun the projection without DeployOpen, and each open assumption has a named owner to confirm it with the vendor or in your own environment. Ask for the phase timeline and the handover format in the written scope before work starts.
Which parts of garak cost work teams keep in-house
This table shows each part of a garak scanning program, whether teams usually keep it in-house or hand it to a partner, and the skills it needs. Read it to see where garak's zero licence cost gives way to staff time, model spend and ongoing operations. The main takeaway is that the business case, scope decisions and result review stay with the owner, while setup and cost tracking are often outsourced.
| Work part | Usually kept in-house or outsourced | Skills needed |
|---|---|---|
| Owning the business case | Kept in-house. Leadership must weigh risk appetite against spend, and only the owner knows which launches and user groups carry exposure. | Risk management, AI governance and budgeting. Enough understanding of prompt injection and data leakage to judge which findings matter. |
| Deciding which applications and models are in scope | Kept in-house. Scope follows the organization's inventory of LLM products, vendors and internal gateways. | Application architecture and security. Ability to map model endpoints, data flows and authentication boundaries. |
| Configuring generators and YAML endpoint descriptions | Often outsourced for the first setup, then handed over. The work needs hands-on testing of your gateway or REST endpoint. | Python 3.11 or newer, pip installation from PyPI, YAML, HTTP and API authentication, and JSON or plaintext response parsing. |
| Pricing API and GPU use | Kept in-house for budget ownership, with partner help to estimate per-run usage. Costs come from your model provider or your own GPU hosts. | Cloud and vendor billing, usage metering, and an understanding of how generations per prompt multiply request counts. |
| Reviewing JSONL results against risk appetite | Kept in-house. Reviewers must decide whether a FAIL marked by a detector is an actual weakness in your product. | Security testing and LLM threat knowledge. Ability to read JSONL attempt records, interpret failure rates and triage false positives. |
| Maintaining the cost model after handover | Kept in-house after handover. Usage changes with new models, probes, release updates and scan frequency. | FinOps practice, Python scripting to parse run reports, and version control for pinned garak releases and scan settings. |
What recurs after the first scan cycle
The first scan cycle is where most one-time work lands: installing garak from PyPI, configuring generators, choosing probes and getting the first JSONL reports into a form people can read. After that, the costs that keep appearing are operational. garak itself has no license fee, since it is licensed under Apache 2.0 and the maintainers describe it as a free tool. What recurs is the compute and API spend each time a scheduled scan runs, the storage behind every report, and the people who read the output and keep the pipeline working. The largest variable line is model access. Each scan sends prompts to the target, and by default garak makes 10 generations per prompt, so the number of calls per run depends on the probes selected and the number of attempts configured. For hosted models, that is API usage billed by the provider. For local models such as gguf files run through llama.cpp, it is GPU or CPU hours on hardware you already run or rent. Ask the team to estimate calls per scheduled run from the probe list, then multiply by the schedule frequency and the provider's current rates. Also confirm whether the target's own rate limits will slow long runs.
Storage is smaller but cumulative. Every run writes a JSONL report of each attempt and its evaluation, and garak.log is continued across runs, so both files grow with schedule frequency and retention policy. Reports can contain harmful or sensitive generated text, which means retention periods, access controls and deletion rules carry a cost in both storage and review time. Decide how long reports are kept, who may open them and where they are backed up before the first scheduled run, not after the logs have accumulated. Engineer time is usually the largest recurring line and the easiest to underestimate. Someone has to review FAIL results, decide whether each one is a genuine weakness or a detector false positive, and track the failure rate per probe over time so that a change is visible. Each garak release can also change probes, detectors or defaults, so the team must re-run a baseline, compare results and document any shift before the new version is trusted for comparison. Include these review and re-baselining cycles in the operating plan with a named owner.
The pipeline also needs internal skills that outlast the project. Someone must understand the YAML configuration for each generator, maintain API keys and rotate them, manage the Python 3.11 or newer environment, and read garak.log when a run fails. Those skills can sit with an existing platform or security team, but they should be assigned explicitly. If the work is outsourced for setup, ask the partner to quote ongoing support, upgrade cycles or retainers as separate line items. Those are recurring services, not part of the initial scope, and they should be priced from a written scope rather than assumed to be included. When comparing options, separate one-time setup from recurring operations in every quote. Ask for the setup estimate, the expected run cadence, the review effort per cycle, the handover documentation and the conditions under which upgrades or re-baselining are billed. Confirm the model provider's pricing directly, because the largest recurring figure depends on it. Treat garak's zero license cost as the starting point for the budget, not the total.
Where garak cost estimates usually go wrong
garak itself costs nothing to license, so the budget lives in model calls, engineering time and the review work that follows each scan. The cards below cover the places where early estimates tend to undercount that work, with the check that prevents each one.
Estimating from one probe run
A single probe run looks cheap, but garak makes 10 generations per prompt by default, so each prompt can produce ten model calls per probe. Estimate from the full probe set and the default generation count, then multiply by the number of runs you expect per month. Confirm the generation setting you intend to use and record it in the scan configuration so the estimate matches what actually runs.
Ignoring rate planning for production endpoints
Scans against a production endpoint send bursts of adversarial prompts that compete with real users for quota, tokens and capacity. Model providers and gateways often apply rate limits and per-token charges that a scan can exhaust quickly. Before scheduling, ask the endpoint owner for the rate limit and budget, decide whether scans run against staging, and cap concurrency and request volume in the run settings.
Unpinned versions break comparisons
garak ships frequent releases, and the probe set, detectors and defaults can change between versions. If the tool is not pinned, a score drop may reflect a new probe rather than a change in the model, and the team loses the baseline it paid to build. Pin the garak version in your environment, such as the v0.17.1 release published 16 October 2026, record it in every report, and upgrade only through a planned re-baseline.
Reviewing reports by hand
Each run writes a JSONL file with every attempt and its evaluation, and a large scan can produce thousands of lines to read. Without a triage method, reviewers spend the most time on the lowest-risk findings and repeat the same judgment across runs. Define severity rules per probe category, auto-group repeated failures, and sample passes to check detector accuracy before anyone signs off on results.
Underestimating REST endpoint configuration
Pointing garak at a custom application means writing a YAML description of the endpoint, mapping request and response fields, and handling authentication headers, token refresh and session state. Responses that are not plaintext or JSON, or that depend on conversation history, add parsing work. Budget engineering time for a test call per endpoint, verify that responses parse correctly on a small probe set, and keep the configuration in version control with the scan code.
Treating a free tool as zero operating cost
garak is free and Apache 2.0 licensed, but the operating cost is the model or GPU time for each run, the scan host, the storage for reports and logs, and the people who configure, run and review scans. These costs recur with every scan cadence and grow with each new target. Ask for a cost model that lists each component, its unit, its owner and whether it is one-time or recurring, before approving a scan program.
How the cost picture changes by target and environment
When garak targets a hosted model through the OpenAI API, AWS Bedrock or Replicate, the largest recurring cost is usually token consumption billed by the provider. garak has no license fee, so each scan converts into requests against a metered service. Your team pays the provider directly, and the spend scales with the probe set you select, the number of generations per prompt (10 by default) and how often you rerun scans.
- Metered tokens: Every attempt is a billed request. Probe selection and generation count are the main levers on spend.
- Account setup: API keys, organization limits and Bedrock model access must be provisioned by your team, which is often a one-time effort but can delay the first run.
- Rate limits: Provider throttling can stretch run time and add retry effort, which increases engineering hours more than invoice totals.
- Provider terms: Confirm that your acceptance of the provider's usage policy covers automated adversarial prompts before scanning production-linked accounts.
- Model versions: Hosted models change under the same name, so repeated runs may cost more or behave differently without any change on your side.
Before requesting a quote, confirm which accounts, billing owners and model identifiers the scans will use, and whether a dedicated test account with a spending cap is available.
Hugging Face Hub models and gguf files run through llama.cpp shift the cost from per-token billing to hardware time. garak itself remains free, but the GPU, or CPU, that serves the model is either a capital cost or a cloud instance you pay for by the hour. For this target, the wall-clock duration of each run often dominates the budget, and the choice of model size and quantization changes both speed and the cost of every scan.
- Hardware time: Cloud GPU hours or amortized on-premises hardware become the main recurring line item.
- Model choice: Larger models take longer per generation, so the same probe set can cost several times more across model sizes.
- Quantization: gguf quantization levels trade memory for output quality, which can change failure rates and must be recorded with each run.
- Setup effort: Installing llama.cpp, selecting compatible model files and validating the local server is usually a one-time task for an engineer.
- Idle capacity: Dedicated instances left running between scans add cost, while on-demand starts add scheduling effort.
Before requesting a quote, confirm the GPU or CPU profile, whether the instance will be shared with other workloads, and how model files will be licensed, stored and version-pinned for repeatable results.
When garak tests your own application or gateway through the REST generator, the largest effort is usually on the endpoint side rather than the scanner. You describe the endpoint in a short YAML file, handle authentication headers and make sure responses parse correctly. Model inference cost still applies if the application calls a paid model behind it, but the engineering work to make the target testable often takes more time than the scan itself.
- Endpoint description: Writing and validating the YAML, including request templates and response parsing for plaintext or JSON, is a recurring task when the application changes.
- Authentication: Tokens, session handling and header rotation add work and may require a test identity that is isolated from real users.
- Load on production: Scans send many requests, so a test environment or rate limiting is often needed to avoid affecting real traffic and its costs.
- Result review: Analysts must read JSONL reports and separate true findings from detector noise, which is staff time that recurs with every run.
- Downstream model costs: Requests that reach a paid model behind your application are billed by that model's provider.
Before requesting a quote, confirm who owns the endpoint, whether a non-production copy exists, what authentication the test identity needs, and who will review results after handover.
In air-gapped or restricted networks, the scanner and its target run inside boundaries where outbound internet access is limited or prohibited. Costs move from usage fees toward hosting, approvals and transfer effort. Packages, model files and probe updates may need to be brought in through controlled channels, and the local model or internal endpoint must be reachable from the scan host. Most of this cost is one-time setup, but each approved update repeats part of it.
- Hosting: Dedicated scan hosts or enclaves are provisioned internally, which adds infrastructure and maintenance cost.
- Access approvals: Security review, change tickets and data-transfer approvals can take longer than the technical work.
- Offline updates: Moving garak releases and their Python dependencies across the boundary is a repeated effort with each upgrade.
- Model availability: Hosted APIs are often unavailable, so local inference or an internal endpoint becomes the only option, shifting cost to hardware.
- Report handling: JSONL reports and logs may contain sensitive or harmful generated content, which needs storage rules and retention decisions.
Before requesting a quote, confirm the network rules that apply, the approval path for tools and data, which Python versions are permitted (the PyPI package requires Python 3.11 or newer), and where reports will be stored.
What the client must provide before a cost model can be priced
Before a cost model can be priced, the client needs to name two people: an owner who is accountable for the garak program and a budget holder who approves model API and compute spend. garak is free and Apache 2.0 licensed, so every cost line in the model traces back to a decision one of these two people makes. Without a named owner, nobody can say which targets matter, how often they are scanned or who absorbs the engineering time. Without a budget holder, the quote has no one to sign off on recurring spend.
The second group of inputs describes the targets. Provide a list of every model and application to be scanned, with the provider or hosting method for each (for example, a hosted API, a Hugging Face Hub model, an AWS Bedrock foundation model, a local gguf model through llama.cpp, or a custom application reached through a REST endpoint). For each target, supply the access details garak will use. Credentials should be issued as API keys or service accounts scoped to scanning, and they should be shared through a secure channel agreed in advance, never by email or chat. The number of targets and the number of generations per prompt are the main levers on API or GPU spend, so this list is the starting point for every estimate.
Next, supply any existing test prompts. If the team already runs manual jailbreak or prompt injection tests, a sample of those prompts shows how much porting and cleanup work the migration will need. Also state the desired scan frequency, such as on each model change, on each release, or on a fixed schedule. Frequency multiplies per-run API or compute cost, and it determines whether scans need to run unattended. Confirm the Python environment as well: garak installs from PyPI and requires Python 3.11 or newer, so the client should confirm an approved Python 3.11 or newer environment, or name the host where it will be provisioned.
Two decisions come before the quote. The first is whether results must be comparable across garak releases. garak v0.17.1 was released on 16 October 2026, and the maintainers publish new releases regularly, so pinning a version for comparable results adds work to upgrades and affects how baselines are kept. The second is who reviews FAIL results. garak marks a probe as FAIL when any attempt produces undesirable output, so each FAIL needs a named risk owner who decides whether it is a true weakness, a detector false positive, or an accepted risk. Review time is often the largest recurring labor cost, and it is easy to omit from an estimate. Ask the risk owners how many findings per run they can review, and agree on that capacity before pricing begins.
How much does garak cost to run, and can our team do it alone?
Does garak have a license fee?
No. garak is licensed under Apache 2.0, and its maintainers describe it as a free tool, so there is no license fee for the software itself. The budget comes from what the scans consume and from the people who run them. Those costs fall into three groups: model API or GPU time for each run, engineering hours to configure targets, run scans and review results, and ongoing work to keep scans repeatable as garak releases change. Ask your legal or procurement team to confirm that Apache 2.0 terms fit your internal use. Also check the other tools in your pipeline, since each may carry its own license and fees.
What cost actually drives the budget for garak scans?
Model consumption is usually the largest variable line. Each probe sends prompts to the target, and garak makes 10 generations per prompt by default, so the number of probes and generations sets the number of calls. Hosted models bill per token or per request, while self-hosted models consume GPU hours. Vendor API and GPU rates change, so confirm current rates with each provider and your cloud account before you estimate. Then add engineering time for target configuration, REST endpoint setup, triage of JSONL reports and handoff to remediation. Finally, count operations such as scheduling, storage of reports and garak.log, and testing upgrades to new releases.
How does the default generation count change scan cost?
Directly. By default garak makes 10 generations per prompt, and a probe is marked FAIL when any attempt produces undesirable output. A single scan can therefore multiply calls quickly across many probes and targets. Lowering the generation count reduces spend, but it can also change how often weak behavior is caught, so treat that setting as a test design decision to agree with your security owner. Record the setting with each run so later results stay comparable. Each run also writes a JSONL report and continues a garak.log file, so plan storage for both as scan volume grows.
How long does it take to build a garak cost model?
The duration depends on scope, and a written proposal should state it as a phase timeline. Scope includes how many models and applications are involved, whether they are hosted APIs or self-hosted, and how much historical scan data exists. Ask for each phase with its deliverables and exit conditions: a discovery phase listing targets and probe selection, a measurement phase running representative scans to record real call counts and runtimes, a modeling phase that turns those measurements into cost ranges, and a handover phase covering the spreadsheet or tooling and the review cadence. Ask whether the plan measures actual usage or only estimates it.
Can our in-house team run garak cost analysis alone?
Yes, if the team has three things: Python skills to install and run garak, which the PyPI package requires Python 3.11 or newer to run; working knowledge of LLM security, so it can choose probes and interpret failures; and ownership of the API or GPU budget, so it can see actual spend and set limits. garak is a command-line tool that developers on Linux and macOS use, and it writes a JSONL report and a garak.log file for each run. A capable engineer can build a cost model from those outputs in-house. Teams missing one of these skills usually bring in outside help for that gap alone.
What does our team need to provide for this engagement?
Mainly access and decisions. Expect to provide a list of target models and applications with their owners, API keys or cloud accounts with spending visibility, and a test environment or agreed scan windows for any production-like endpoints. You will also need a named decision-maker who approves probe selection and cost thresholds. Historical usage data, such as provider invoices, GPU billing exports and earlier test results, speeds up the measurement phase. Confirm where JSONL reports and garak.log files will be stored, since they can contain harmful generated content and should follow your data handling policy. Name the teams who will receive findings before scans begin.
What should a partner's garak cost quote include?
A fixed-scope quote should follow a written scope, which DeployOpen agrees in writing before work starts. Ask the quote to list the targets in scope, the probes and generation settings planned, and each phase with its deliverables and timeline. It should state the client inputs it assumes and who pays for model API and GPU consumption, which usually stays with your organization. Ask it to separate one-time build work from recurring operations or retainer support. It should also name the rate sources it used and explain what changes the price, such as added targets or a major garak release. DeployOpen does not publish a price list, so the quote follows from the scope.
Who pays for model API and GPU time during scans?
Usually your organization pays, because scans run against your own models, endpoints and accounts, and the provider bills the account that makes the calls. This applies to hosted APIs billed per request or token and to GPU hours on infrastructure you run. Confirm with each provider how billing works for your plan and whether any free tier or committed-use discount applies. Labor is a separate cost: engineering time to configure and review scans sits with whoever staffs the program, whether internal or contracted. Keep scan spend in its own cost center or tag so you can see what each run actually costs.
How DeployOpen scopes, delivers and hands over garak cost work
DeployOpen works on garak cost of ownership as a written, fixed-scope engagement inside your own infrastructure. We agree what is measured, which targets and probes are in scope, and what the run cost model covers before any work starts.
How we scope
- Confirm which models and applications are targets, and which generator types each one needs.
- Agree which cost components are measured: model API calls, GPU time, engineer hours and scan operations.
- Record in the written scope which costs are one-time and which recur per scan, with the quote basis stated.
How we build
- Configure garak generators for each target, including REST endpoints described in YAML where needed.
- Set up scan runs so the number of generations per prompt and probe selection are documented and repeatable.
- Test cost tracking by running a pilot scan and recording the API or GPU consumption it produces.
How we hand over
- Document the per-run cost model, the settings that drive it and the places it changes most.
- Provide runbooks for reviewing JSONL reports and garak.log output, with ownership of each step named.
- Walk your team through the cost dashboard or log summaries so they can estimate the next scan's spend.
How we support
- Offer ongoing support and upgrades as a retainer, scoped in writing, for garak version changes and target updates.
- Review scan cost trends with your team at agreed intervals and flag changes in consumption.
- Confirm with your team which support tier and response expectations apply before the retainer starts.
