HALBACH

· MD

Compare eligible deployments by fully loaded cost per accepted task

Recommendation: Establish which configurations are permissible for the workload, benchmark them against common acceptance and service criteria, then compare their lifecycle economics. A token price or an EU hosting label cannot answer all three questions.

Cutoff: 9 October 2026, Europe/Berlin. Evidence status: source-backed method, not a completed procurement assessment or a measured provider ranking. Formulas and procedures below are our proposed implementation unless explicitly attributed.

1. We have a decision framework, not measured purchasing conclusions

Question Available in this pack Still required
What is the cost per task across providers? Cost taxonomy, accounting method and benchmark design Representative task runs, acceptance results, review time and applicable rates
Which deployments meet GDPR requirements? Assessment dimensions and primary guidance Workload-specific legal/security review, contracts and verified data flows
Where do correct token counts come from? Documented response fields and reconciliation approach Tested provider adapters, streaming coverage and billing cross-checks
Is owned infrastructure cheaper than a managed API? Lifecycle cost model and capacity considerations Hardware quotes, measured throughput/power, utilisation and operating effort

Existing break-even inputs in 05_deployment_and_market.md [local reference omitted] and the document-processing illustration in 06_roi_and_case_evidence.md [local reference omitted] are hypothetical. Do not present them as observed provider costs or Halbach customer results. No universal GDPR premium has been established.

2. Treat compliance and data constraints as eligibility gates

GDPR and DSGVO name the same regulation in English and German. A provider’s country of incorporation alone does not determine the permissibility of a particular processing arrangement. EDPB guidance explains that transfers outside the EEA require the applicable Chapter V conditions in addition to ordinary GDPR obligations, including an appropriate legal basis, security, minimisation and a processor contract where relevant. Adequacy decisions and appropriate safeguards are potential transfer routes. S34

Recommended assessment: review the exact service, model, endpoint, region, features, customer contract and data flows. Record the approving owner and unresolved conditions. This matrix organises the assessment; it is not a compliance certificate or exhaustive legal checklist.

Dimension Evidence to obtain Why it affects the decision
Workload and data Data categories, purpose, lawful basis, minimisation and privacy assessment Establish what processing is permitted and necessary
Controller/processor relationship AVV/DPA, responsibilities and contractual service scope Supplier marketing does not replace contractual obligations
Processing geography Inference, storage, logs, backups, support access and third-party tools Regional storage alone does not establish regional inference or all access paths
Retention and training use Default retention, feature exceptions, deletion, training opt-in/out and agreed amendments The chosen configuration may behave differently from the provider’s general policy
Subprocessors and transfers Current list, access arrangements, applicable transfer mechanism and assessments Review the actual processing chain, including observability services
Security and operations Access controls, encryption, incident handling, audit evidence and customer controls Evaluate the complete application, including self-hosted components
Service/model rights Model licence, permitted uses, availability and feature restrictions Technically available does not mean usable for the intended deployment

OpenAI’s current documentation distinguishes regional storage from regional processing, identifies endpoint/model eligibility, and excludes some system data from data residency. It also describes additional requirements for non-US regions. This is evidence about service configuration, not a conclusion that a Knauf deployment is compliant. S35

Decision rule: exclude configurations that do not meet the agreed requirements. Compare costs among eligible configurations. If a global configuration is included for a non-personal, approved workload, label that workload scope explicitly. EU hosting and self-hosting do not by themselves establish compliance of the entire application.

3. Benchmark business outcomes before publishing task-cost numbers

Proposed protocol:

  1. Define the task and acceptance rubric before running models. State how assisted completion and human review count.
  2. Assemble representative inputs, including German-language material, difficult cases, realistic document lengths and modalities. Use approved or suitably prepared data.
  3. Compare configurations on the same inputs and required service levels. Preserve model versions, prompts, tools and evaluation settings; document deliberate differences.
  4. Capture every attempt, retry, fallback, retrieval/tool operation, failed outcome and human intervention under a shared task_id.
  5. Measure cost, acceptance rate, review/rework time, end-to-end latency and capacity under realistic traffic, including peaks and idle periods.
  6. Apply effective contract rates and reconcile provider charges. For hardware, use the whole operating period’s resource costs and accepted outputs.
  7. Report low/base/high demand scenarios and uncertainty. Keep difficult task classes visible instead of averaging away systematic failures.
cost_per_accepted_task
  = total_relevant_cost_in_period / accepted_tasks_in_period

Include spend on unsuccessful attempts in the numerator. Report acceptance rate and rejected-task volume alongside the ratio. Use the same period, currency, allocation policy and tax treatment across alternatives. A system with no accepted tasks has no finite cost per accepted task.

For leadership, retain both direct inference cost and fully loaded workflow cost. Different tokenisers, output lengths and review requirements mean equal token prices do not imply equal task costs.

4. Read provider usage first, then apply provider-specific billing semantics

The request’s actual response usage is the starting point for attribution. Local tokenisation and preflight token-count services support estimation and admission decisions; label them separately from actual usage and invoiced expenditure. See 03_monitoring_and_attribution.md [local reference omitted] for the linked task/request/financial ledger.

Interface Fields within response usage Accounting treatment
OpenAI Responses input_tokens, output_tokens, total_tokens; input_tokens_details.cached_tokens, input_tokens_details.cache_write_tokens where supplied; output_tokens_details.reasoning_tokens Preserve totals and details. Details describe breakdowns, so do not blindly add them to the corresponding totals. Map them to the applicable model/tier’s price categories. S36
Anthropic Messages input_tokens, cache_creation_input_tokens, cache_read_input_tokens, output_tokens; cache creation TTL details when supplied Anthropic documents total input as the sum of the three separate input buckets. Price uncached input, cache writes and reads separately; preserve write TTL for the appropriate rate. S10
Bedrock Converse inputTokens, outputTokens, totalTokens, cacheReadInputTokens, cacheWriteInputTokens, cacheDetails when supplied Capture the exact response and check model/API-specific billing semantics. Optional cache fields are not a licence to sum all counters indiscriminately. S37
Self-hosted serving Serving response usage, model/tokeniser identity and engine/resource metrics where available These describe workload execution. Economic cost comes from paid resource time or owned infrastructure costs, not an unrelated API token tariff. Validate counters for the selected serving version.

Other interfaces, including OpenAI Chat Completions and provider-compatible gateways, can expose different field names or levels of detail. Build an explicit adapter for each interface; do not infer semantics from similar names.

Anthropic’s documented relationship is:

total_input_tokens = input_tokens
                   + cache_creation_input_tokens
                   + cache_read_input_tokens

By contrast, if a provider explicitly reports a total input count including a cached subset, subtract the cached subset before pricing uncached input. Do not add reasoning tokens to an output total that already includes them. Preserve raw usage so mappings can be audited when schemas change.

Proposed operational controls: collect provider-specific streaming usage events, deduplicate by request/attempt identity, and mark missing or incomplete usage rather than treating it as zero. Cancellations, failures and bypass traffic require financial reconciliation. Cost accounting should remain complete even if detailed traces are sampled.

Record at least: task/attempt/request IDs, owner, provider account/project, requested and actual model when exposed, model version, region, service tier, raw usage, price version/effective date, currency, outcome and review effort. Prompt bodies are not normally necessary for cost attribution.

5. Reconcile request estimates with the financial record

OpenAI documents organisation-level Usage and Costs APIs, including /v1/organization/usage/completions and /v1/organization/costs. These aggregate records support the financial view but cannot create a missing business-task identity. S38

Proposed process: aggregate request estimates by account, model/service, period and currency; compare against provider cost exports and invoices; explain credits, contract discounts, commitments, rounding, delayed charges, taxes and missing usage. Keep estimated consumption cost and actual payable expenditure as distinct fields. Apply a consistent currency and VAT policy.

Flag discrepancies and coverage explicitly. Do not silently force totals to match by distributing an unexplained difference across tasks. For providers without suitable exports, retain the invoice and state the attribution limits.

6. Include the full lifecycle when comparing owned, rented and managed inference

Cost family Owned local infrastructure Self-operated rented GPUs Managed API
Inference capacity Server/GPU acquisition, useful life and residual value Paid GPU hours, replicas and commitments Actual billable units, tiers and commitments
Energy and facilities Measured wall power, electricity tariff, cooling and rack/facility costs Normally embedded in rental; add only separately charged items Normally embedded in API price
Supporting infrastructure CPU/RAM, storage, networking, backups and tooling Contracted supporting resources and transfer charges Application infrastructure, retrieval, transfer and tooling
Resilience and spare capacity Redundancy, repair/spares, idle capacity and replacements Idle/warm-up hours, redundancy and minimum capacity Required dedicated capacity, minimums and customer-side resilience
Operating labour Deployment, updates, evaluations, security, monitoring, incidents and maintenance Same responsibilities within the rented/managed service boundary Customer-side integration, evaluations, monitoring, security and support
Complete workflow OCR, retrieval, other models, tools, human review and rework Same categories Same categories
Establishment and change Acquisition/setup, implementation, migration and training Implementation and migration Implementation and migration

Proposed monthly operating model for owned infrastructure:

monthly_hardware_allocation = (acquisition_cost - residual_value) / useful_life_months
monthly_energy = measured_IT_kWh × applicable_facility_factor × electricity_rate
monthly_total = hardware_allocation + energy + facilities + supporting_resources
              + operating_labour + maintenance + licences + workflow_cost
              + agreed_allocation_of_initial_implementation

Use a facility factor such as PUE only when appropriate to the measured boundary; do not multiply whole-facility energy by PUE again. Include idle power. Treat acquisition, residual value and useful life as explicit assumptions, not universal constants.

Separate cash and operating-cost views: a lifecycle investment appraisal includes acquisition cash flows, replacements, operating expenditure and residual value over the chosen horizon, with the agreed discount rate where applicable. Do not add full acquisition cash outlay and depreciation to the same total. Show financing costs according to the chosen appraisal convention.

For rented GPUs, use the rental charge instead of owned hardware depreciation and embedded energy. If a supplier bills power or networking separately, include those actual charges. For Halbach’s current rented-GPU setup, this is the relevant infrastructure branch.

Capacity must satisfy task quality, peak traffic and latency requirements with maintenance and redundancy included. Use successful tasks per paid hour and total period cost. Peak tokens/second from a benchmark cannot supply the production utilisation denominator.

Sensitivity should cover demand, task difficulty, review effort, usable throughput, operating labour, hardware life, energy and commercial rates. Real capacity is stepped: an extra replica can change the break-even abruptly. Do not extrapolate the simplified formula in chapter 05 beyond a measured capacity range.

7. Collect these inputs before naming a winner

Input Owner / source Current status
Representative workload and acceptance rubric Business owner plus evaluation team Not established for Knauf
Approved deployment configurations Privacy, security and procurement Not established
Rates, contracts and hardware quotations Procurement/provider documentation Comparison-specific quotes not collected
Actual calls, usage, retries and acceptance Instrumented application and benchmark No comparative run completed
Human review/rework effort Observed workflow and loaded labour assumptions Not measured
Hardware capacity, power and operating effort Load test, wall-power measurement, operations Not measured
Volume, peak demand and appraisal horizon Business, engineering and finance Not established

The workshop can confidently teach the method and show labelled scenarios. A provider ranking, quantified compliance premium or local-versus-cloud winner requires the missing inputs above. An educational comparison does not require disclosure of Halbach’s unpublished routing, architectures or kernels.

8. Coding-tool extension from the Navigara review

Keep three records separate: consumed units, actual charges and accepted outcomes. Client telemetry may be approximate, version-dependent or duplicated by a proxy; subscriptions also have seats, entitlements and overages. Reconcile the actual payable charge rather than adding an API-equivalent valuation to a seat invoice. The source-backed implementation caveat is in chapter 03 [local reference omitted]; the broader assessment is in chapter 10 [local reference omitted].

A locally installed analytics collector can still send analysis content to an external model endpoint. Navigara’s security documentation explicitly makes this boundary configurable. S53 Include analysis services in the eligibility and cost inventory. This review adds no provider benchmark, contract-specific compliance decision or populated hardware TCO.

Primary sources verified on 9 October 2026