The problem

Every serious agentic pipeline I run eventually hits the same wall: a single closed-source model provider becomes a single point of failure. Rate limits cap how much work you can push through in a week, prices climb, and availability can vanish overnight — the Fable model getting pulled out from under people who’d built entire workflows around it is the concrete example that made this real rather than hypothetical. Any team betting a production pipeline on one vendor’s weekly quota has the same exposure, just with a bigger bill attached. The instinct to reach for “just use a cheaper or more open model somewhere in the chain” is obvious. What’s not obvious is where in a pipeline that substitution actually holds up, and where it quietly breaks continuity you were relying on.

The approach

This one stayed a study note rather than turning into shipped code — it’s a deliberately small, low-priority research project I keep in CogitOS specifically to test an idea before I build on top of it. The core finding I wrote down: you can mix providers — Claude via Claude Code, Kimi via its Anthropic-compatible API — within one deterministic workflow, but you cannot carry a session across providers. What does carry across is a file. Pass context through markdown artifacts between pipeline nodes (plan.md, notes.md, a diff) and each node can run on whatever model fits that step, Claude for one, Kimi for the next, with no shared session required.

The interesting part is which step benefits from which model. I pulled together five sourced references — live benchmarks and orchestration teardowns from Cole Medin and IndyDevDan — and the pattern that shows up repeatedly is: put your expensive frontier model on the planning node, and let a cheaper workhorse model (Kimi K2.6, MiniMax) handle implementation and validation. One benchmark quantified it directly: upgrading the planner to Opus added +9 points average on a 70-point rubric; upgrading the implementer to Opus added nothing, actually −1. A second reference goes further, arguing agent calls and code execution should be separate nodes entirely — a build agent and a linter as distinct, testable steps connected by session ID, not a linter buried inside the agent’s own tool calls — because that’s what makes per-node provider swapping possible in the first place.

What I learned

The mental model I was implicitly using — “a workflow is one continuous session, and providers are interchangeable within it” — is wrong on both counts. Session continuity dies at the provider boundary; what survives is only what you deliberately write down for the next node to read. That’s not a workaround, it’s the actual architecture: markdown artifact handoffs are the API between models. And substitutability isn’t free everywhere in a pipeline — it’s cheap at the implementation step and expensive at the planning step, because planning quality is where reasoning differences between models actually show up in the output.

Where this could go

The natural next step is turning this from a note into a real node-based harness — something like Archon’s per-node provider config, where a workflow YAML names a model per step instead of one model for the whole run. That’s directly applicable beyond a solo pipeline: any team running agentic build/review/deploy workflows can put a frontier model on the planning or review gate and route the higher-volume implementation work to a cheaper or open-weight model, cutting cost without touching output quality where it matters. It’s also a resilience story, not just a cost one — spreading a pipeline across two or three providers for the same role (the “10-20 cloud providers host GLM, you only need 2-3 active” argument from the source material) means no single vendor’s rate limit or outage takes down a production pipeline. For an organization, that’s the difference between an AI workflow that’s a business dependency risk and one that degrades gracefully.