Logging

The Solwyn SDK emits diagnostic messages via Python's standard logging module under the solwyn logger. Configure verbosity like any other logger:

import logging

# See SDK warnings and errors (recommended)
logging.getLogger("solwyn").setLevel(logging.WARNING)

# See state transitions like circuit breaker recovery
logging.getLogger("solwyn").setLevel(logging.INFO)

# Silence the SDK entirely
logging.getLogger("solwyn").setLevel(logging.CRITICAL)

The SDK never logs prompt content, response content, or any customer text. See Privacy for the full guarantee.

Message reference

Every WARNING-, ERROR-, and INFO-level message the SDK emits is listed below with its meaning and recommended action. Messages with %s placeholders show the actual format string the SDK uses.

WARNING level

ERROR level

INFO level

Per-event ingest rejections

Available from SDK v0.1.7. When the reporter delivers a metadata batch, Solwyn Cloud responds with a per-event disposition list: events it cannot price — a model with no pricing entry, an unrecognized service tier — are rejected individually while the rest of the batch is recorded. The SDK reads those dispositions and surfaces them as WARNINGs on the solwyn.reporter logger (a child of solwyn, so the configuration at the top of this page covers it).

There is nothing to configure — no constructor params, kwargs, or environment variables. The feature is observed entirely through logging:

import logging

from openai import OpenAI
from solwyn import Solwyn

# Rejection warnings arrive on the standard `solwyn` logger
# (the reporter logs under `solwyn.reporter`).
logging.getLogger("solwyn").setLevel(logging.WARNING)

client = Solwyn(OpenAI(), api_key="sk_proj_...")

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hello!"}],
)

client.close()

# If the Solwyn API cannot price an event, the next flush logs one
# aggregated WARNING per distinct (code, model) — for example:
#
#   reporter.ingest_events_rejected: code=unknown_model model=vendor-x-1 count=2 message=Solwyn does not have pricing for model 'vendor-x-1'. File an issue at https://github.com/solwyn-ai/solwyn-python-sdk/issues or contact support — we typically add new models within 24h.

Each line carries four fields:

• code — a server-owned rejection code. Today the codes are unknown_model and unknown_service_tier; the set can grow without an SDK release, and an unfamiliar code is logged the same way.
• model — the model identifier as submitted (truncated server-side to 50 characters).
• count — how many events in the batch were rejected for this (code, model) pair.
• message — the server's human-readable guidance, logged verbatim and never parsed by the SDK.

Behavior notes:

• One line per distinct (code, model) per batch. A fleet stuck on a single unpriced model emits one WARNING per batch flush, not one per call.
• Rejected events are terminal. They are logged and dropped, never re-queued — resubmission would be rejected identically until a pricing entry lands server-side. Pricing fixes are an API-side deploy: once the entry exists, subsequent traffic prices automatically with no SDK upgrade or redeploy on your side. The rejected calls are not recovered retroactively.
• Accepted events in the same batch are unaffected. They are already durable server-side when the rejections are logged.
• Sync and async are identical. Solwyn and AsyncSolwyn reporters share the same rejection-logging code path.
• Fail-open. A malformed response body never interrupts reporting: the SDK falls back to the count-only acknowledgment and logs one reporter.ingest_response_unparseable WARNING. Ten consecutive unparseable bodies escalate to the reporter.ingest_response_unparseable_persistent ERROR; a single parseable body resets the counter.
• Logs only. There is no callback, hook, return value, or SDK-side metric for rejections. This is the post-call telemetry path — it plays no part in failover or circuit-breaker decisions.

These lines carry only the rejection code, model identifier, count, and the server's guidance message — never prompts, responses, or any customer text; the batch itself is content-free metadata. As defense in depth, the SDK escapes raw control characters in the server-echoed fields before logging, so the lines are safe to ship to log aggregators.

Filtering at the logger level

If you only want to act on a subset of messages, attach a filter:

import logging

class OnlyCircuitBreaker(logging.Filter):
    def filter(self, record):
        return "Circuit breaker" in record.getMessage()

logger = logging.getLogger("solwyn")
logger.setLevel(logging.INFO)
logger.addFilter(OnlyCircuitBreaker())

What is not logged

The SDK never logs:

• Prompt text or message content
• Response text or model output
• API keys (Solwyn or provider)
• Project IDs in error contexts where they could leak via aggregation

Exception messages from provider SDKs are not re-raised through the SDK's logger. They propagate to your code unchanged.