OpenClaw vs. In-house build: the contract risks might outweigh the cost savings.

I've spent the last three weeks dissecting a proposed enterprise agreement from OpenClaw AI for their hosted inference platform, pitched as a cost-effective alternative to scaling our in-house Llama 3.2 fleet. The sales rep's math on projected 40% savings looked compelling at first glance, but the contract appendix reads like a masterclass in obfuscating future cost drivers and operational lock-in. My team ran our own synthetic benchmarks against their API, and while the p50 latency is acceptable, the contractual fine print effectively nullifies any savings for a production workload.

The core issues aren't in the standard terms, but buried in the **Service Level Agreement (SLA) Annex** and the **Pricing Schedule**. Here's a breakdown of the most egregious clauses I've flagged.

**1. The "Provisioned Throughput Unit" (PTU) is a black box with punitive overages.**
OpenClaw sells capacity in PTUs, defined as "a unit of model inference capacity as measured by OpenClaw's proprietary metrics." The contract refuses to define the metric in terms of tokens/second, requests/second, or any standard measure. Our benchmark data shows a wild variance:

```python
# Simulated benchmark results - 1000 requests, varying input/output lengths
ptu_consumption_per_request = []
for _ in range(1000):
# Their metering API returns a 'credits_used' value per request
credits = get_openclaw_credits(request)
ptu_consumption_per_request.append(credits)

print(f"PTU Credit Range per Request: {min(ptu_consumption_per_request)} to {max(ptu_consumption_per_request)}")
print(f"Coefficient of Variation: {np.std(ptu_consumption_per_request)/np.mean(ptu_consumption_per_request):.2f}")
```
Output indicated a >300% variance. This means forecasting monthly costs is impossible. Furthermore, overages are billed at 1.5x the base rate, and they define overage as **any usage exceeding your monthly average PTU consumption from the prior week**. This creates a rolling target that penalizes bursty but legitimate traffic patterns.

**2. The data portability and model export clause is functionally useless.**
The contract includes a section titled "Your Data, Your Model." It promises you can export your fine-tuned checkpoints. However, the technical specification in Appendix D states:
* Exports are provided only in OpenClaw's proprietary `.ocw` format.
* The format includes "optimized runtime dependencies" that are only executable within their own inference engine, which is not publicly available.
* There is no commitment to provide a conversion script or weights in standard formats (e.g., Safetensors, PyTorch state_dict).

This isn't portability; it's decoration. Migrating off their platform would require retraining from scratch, a massive sunk cost.

**3. Auto-renewal with a price re-evaluation "based on market conditions."**
The term is three years, with auto-renewal for another three unless we cancel 90 days prior. Standard stuff. The trap is in the renewal pricing clause: "Fees for any renewal term shall be OpenClaw's then-current list prices, subject to change based on prevailing market conditions and value delivered." There is no cap (e.g., CPI + 5%). After you're locked in via fine-tuned models and integrated pipelines, they have carte blanche to increase prices.

**4. SLA credits are a joke and exclude the most likely failure modes.**
The 99.9% uptime SLA looks good. The credits for missing it are not. The exclusion list includes:
* "Latency degradation" (our primary concern).
* "Errors stemming from model architecture" (vague enough to cover most hallucinations or output quality issues).
* "Capacity constraints during periods of high global demand" (i.e., when you need it most).
* Any issue related to the provisioned throughput system.

The only way to claim credits is for a complete API endpoint outage exceeding 5 minutes. The credit itself is a prorated discount of your monthly fee for the affected service region. It's a rounding error on an invoice, not a meaningful remedy.

The takeaway: An in-house build has clear, upfront capital costs and engineering overhead. A vendor contract like this replaces that with variable, unpredictable operational costs and strategic risk. The savings they projected assume perfect, linear utilization of their opaque PTU units and ignore the high probability of overage charges and renewal price hikes. Before signing anything that uses "proprietary metrics" for billing, demand they benchmark *your* specific workload and convert those metrics into a fixed, per-token or per-request price with hard caps. If they refuse, walk away.