The control point
The hard stop belongs before the provider call.
Solwyn wraps the model client your application already uses. Before a supported request is sent, the SDK evaluates the project budget. When the configured enforcement condition is met, it raises a local exception and the request is not sent.
Solwyn checks the project budget in-process before every supported model call. Under budget, the call is sent directly to the provider. When the limit is reached, the SDK raises BudgetExceededError and the call is not sent. Prompt traffic always goes directly to the model provider; only usage metadata is sent asynchronously to the Solwyn dashboard.
Three steps between your agents and a runaway bill.
No new infrastructure. No gateway migration. No Solwyn-hosted proxy in the request path — just a wrapper around the client you already use.
Deploy an agent, cross your fingers, check the bill next month.
Deploy an agent whose next over-budget call is denied in your process, that fails over to your configured fallback, and that reports every dollar.
Failure modes
What happens when things break.
The SDK fails open by default: your agents keep running against cached limits. The one thing an outage never does is lift a hard cap that's already denying.
A local circuit breaker tracks provider health in your process and routes supported failures to your configured fallback — no network hop, works even if Solwyn's cloud is unreachable.
Usage metadata is batched and sent asynchronously — it never blocks or delays your model calls.
Your prompts never touch our servers.
Not by policy. By architecture.
Solwyn runs inside your process — your LLM calls go straight to the provider, and we're never in the path.
- ✓Token count
- ✓Model
- ✓Latency
- ✓Status
- ✓Project ID
- ✓Tags you attach
- ✕Prompts
- ✕Responses
- ✕System messages
- ✕Function calls
- ✕Conversation history
- ✕Tool arguments & payloads
- ✕Your provider API keys
Audit exactly what leaves your process — read the open-source SDK →
We can't leak what we never had.