API Cost Model and Financial Architecture¶
This document outlines the financial strategy, billing boundaries, and cost management policies for WorkWingman integrations.
Financial Architecture Overview¶
WorkWingman minimizes API liability while providing flexible scaling options between desktop and cloud editions:
| Deployment Mode | Key Origin | Primary Financial Liability | Metering & Tracking |
|---|---|---|---|
| Desktop App | Customer BYOK | Customer (Direct Vendor Billing) | Local token counters |
| Cloud Edition | GCP Secret Manager | Cloud Operator / Tenant | technical/cloud-finance-usage.md |
Desktop BYOK Strategy¶
- Zero API Liability: The desktop client BYOK model shields WorkWingman from third-party vendor charges, rate-limit liabilities, and unexpected usage spikes.
- Config-Gated Cost Controls: Paid features (such as Anthropic LLM models via
llm-harness) are gated behind explicit configuration controls. Customers cannot accidentally incur third-party vendor expenses without manually supplying valid API keys.
Cloud Edition Usage & Finance¶
- Centralized Runtime Execution: Cloud deployments run shared service infrastructure backed by secrets stored in GCP Secret Manager.
- Usage Tracking: Cloud execution metrics, token throughput, and financial reconciliation are governed by
technical/cloud-finance-usage.md.
Vendor Pricing & Quotas¶
- Anthropic Integration: Powers primary LLM capabilities through
llm-harness. TODO(verify): Confirm active token pricing tiers, prompt caching discount models, and default organizational rate limits.- Google OAuth & Docs Reader: Believed to fit free-tier Google API quotas (TODO(verify)) using PKCE sign-in flows.
TODO(verify): Confirm daily quota ceilings and API usage limits for Google Docs Reader services.
Cross-References¶
technical/byok-efficiency.md— Cost reduction through client-side caching and prompt optimization.technical/cloud-finance-usage.md— Infrastructure cost tracking and cloud ledger integration.