Requests That Need Fine-Tuning: What the Aggregator Actually Forwards and What Falls Back

Why custom model IDs are ambiguous at the gateway

An aggregator sits between your code and many model backends behind one API key. When your request names a standard model, the gateway can map that name to a backend it knows. When your request names a fine-tuned or custom model ID, the gateway has to decide whether that identifier means something to any backend it can reach.

That identifier is usually owned by a single provider. A fine-tuned model ID from one vendor does not exist on another vendor's infrastructure. So the gateway's first job is classification: is this a name it can route, or is it an opaque ID that only one upstream understands?

What the gateway can actually forward

Forwarding depends on whether the upstream endpoint accepts the ID and whether your key arrangement permits it.

• Passthrough of the identifier. If the provider exposes fine-tuned models through the same chat or completion interface, the aggregator can forward the request with the model ID intact and let the backend resolve it.
• Account-scoped resources. Fine-tuned models are often tied to the account that created them. If the aggregator's upstream credentials are not that account, the ID may be rejected even though the interface is otherwise identical.
• Parameter differences. Some providers require or forbid certain fields for fine-tuned models. The gateway generally forwards your body as-is; it does not rewrite parameters to fit a custom model's quirks.
• Name collisions. A custom alias that looks like a standard model name can be misrouted if routing is name-based. Prefer distinctive IDs.

Where fallback happens

Fallback is not a single event. It can occur at several layers, and knowing which layer is failing tells you what to do.

• Routing layer. The gateway does not recognize the ID as any routable model and refuses before contacting a backend.
• Upstream authorization. The backend receives the request but rejects the model because the calling account does not own it.
• Capability mismatch. The model exists but does not support a requested feature such as a particular response format or tool call.
• Transient failure. The backend is reachable but the request fails for a temporary reason; this is not really a custom-model problem and should be handled like any retry.

A well-behaved client distinguishes these because the remedy differs: rerouting, re-authorizing, changing parameters, or retrying.

Designing an explicit fallback

Implicit fallback — silently substituting a general model when a custom one fails — is risky. Outputs from a fine-tuned model and its base model can differ in tone, format, and edge-case behavior. Make the substitution a decision your code makes, not a surprise.

A practical pattern:

1. Try the custom ID first and mark the request as using a custom model.
2. Classify the failure from the error returned: unknown model, unauthorized model, unsupported parameter, or transient.
3. Choose a declared fallback only for the failure classes you have decided to tolerate. Record the substitution in your logs and, if relevant, in your response metadata.
4. Fail loudly for classes you have not decided to tolerate, rather than degrading quietly.

Keep a model registry in your app

Treat model IDs as configuration, not constants scattered through code. A small registry that maps each logical task to a primary model ID and an optional fallback lets you change routing without redeploying logic. Include:

• The canonical ID to send.
• Whether it is custom or standard.
• Whether fallback is allowed and to which ID.
• Any parameter differences the custom model expects.

This also makes cost visible: every call is billed at the aggregator's multiplier over the official price, so a fallback to a different model can change the cost profile of that request. Track which model actually served each call.

Test the fallback path deliberately

Exercise the fallback before you depend on it. Send requests with a deliberately invalid custom ID and confirm your code classifies and handles the error as intended. Confirm that logs show which path was taken. If you use contributor credit — official price multiplied back to key contributors in USDC — verify that your accounting still attributes usage correctly when a fallback model serves the request.

A note on expectations

The aggregator is a router and billing layer, not a model host. It forwards what an upstream will accept and refuses what no upstream can serve. Designing for that reality — explicit IDs, classified failures, declared fallbacks, and clear logging — keeps a single key usable across many models without hiding when a custom model was not actually used.