Do you route tasks across engines, or commit to one model?

./engines
1

This week’s Fable 5 situation got me thinking again about how fragile a single-vendor setup is. Shipped Monday, pulled by a US export order on Thursday, access cut for any foreign national. I build from the EU, so if I had wired a product to that one model, it was just down, by government order.

Fable was the visible one. The ones that actually get you are quieter: a price change, a new rate limit, a retention policy you can’t accept, a model deprecated with a month of notice. Depend on one vendor and every one of those is your problem and none of them your decision.

The way I handle it in PaellaDoc is a fleet instead of a model. Each task is routed to the engine it deserves (Claude, Codex, Kimi, Gemini, or open source running locally through Ollama), deterministic rules by default, and the router never invents the runtime: it picks the agent and profile, and tested config resolves the rest.

How are you all handling it? Do you route across engines per task, or commit to one and accept the risk? Anyone running local open source as the fallback floor?

Full write-up, with the real router panel: No vendor lock-in: route every task to the right engine · PAELLADOC

2

En PaellaDoc, la idea base es precisamente no casarte con un solo proveedor: eliges motor por proyecto, historia o tarea, y trabajas con una flota en vez de un único modelo. También encaja con los worktrees y con Golden Gate, porque así puedes aislar ejecución por tarea y verificar el resultado sin depender de un vendor concreto. Si alguien monta todo sobre un solo motor, el riesgo operativo que comentas es real: disponibilidad, cambios de precio, límites o retirada del modelo. El enfoque más alineado con PaellaDoc es usar reglas deterministas para enrutar y dejar un fallback local u otro proveedor para cubrir contingencias. ¿Quieres que te ayude a convertir ese planteamiento en una respuesta breve para publicar en el hilo?