AMA: I run four frontier models behind one chat. Ask me the unglamorous parts.
I cofounded Zeplik, every frontier model in one chat, switchable mid conversation without losing context. Now building Arteza on the same idea for image, video, voice and music.
Most of what I've learned this year isn't the fun part. It's context handoff between providers who all format history slightly differently. It's pricing something whose underlying cost moves every few weeks. It's support tickets from people who don't believe the model actually switched, because the tone didn't change enough for them to notice.
Two things I'll defend and have been wrong about at different points: the cheap model in your router is usually the most expensive one you run, and breadth on a first screen reads as work rather than capability. We put 111 options on one screen and people left before making anything.
Ask me about multi provider infrastructure, routing, pricing AI products, or launching as a small team. I'll answer everything, including the ones where the honest answer is that we still haven't worked it out.
Replies
The unglamorous part I'd ask about: what actually breaks when you switch models mid-conversation. Not context loss in the storage sense — you clearly solved that — but the fact that a transcript shaped by one model's habits reads strangely to another. Model B inherits assertions it wouldn't have made, in a format it doesn't write in, and either doubles down or quietly contradicts the earlier turn.
Do you normalize the history before handing it over, or pass it through raw and accept the seam?
@ark_y_k Raw, with two exceptions. We strip the previous model's tool call traces, because every other provider reads them as instructions rather than history, and we drop the style scaffolding that only ever made sense for the model that wrote it. Everything else goes through untouched, because the moment we started rewriting assistant turns we were putting words in a model's mouth and people noticed the seam more, not less.
The seam you're describing is real but it isn't the expensive one. What actually costs us is model B accepting model A's framing instead of starting fresh, so you get depth on a premise nobody checked. Took three rewrites before a switch stopped changing the answer in ways nobody asked for, and the fix was mostly about what we removed, not what we added.
@asadmalik901 "The fix was mostly about what we removed" is the part I want to pull on, because it seems to cut against itself. Getting B to question A's framing sounds like it needs something added — a marker, a nudge, some signal that the premise came from elsewhere. If removing scaffolding was enough, that implies B was already inclined to check and something in the handoff was suppressing it.
Which would mean the style scaffolding wasn't just cosmetic. Written in B's own voice, A's turns stop reading as someone else's work and start reading as B's own prior commitments — and models don't relitigate their own conclusions. Strip the costume and the seam becomes visible enough for B to treat it as input rather than memory.
Is that roughly what happened, or did the three rewrites land somewhere else entirely? And does the same logic mean you'd never want a fully seamless handoff, even if you could build one?
@ark_y_k That's basically it, yeah. The costume was the problem. Two of the three rewrites went into adding exactly the marker you're describing, a line up front saying the earlier turns came from a different model, and it made things worse. B started hedging on everything, including the parts that were fine. Dropping the style scaffolding got the same effect without the hedging, because the seam does the work instead of an instruction.
And no, I don't want a seamless handoff. We shipped one for about a week in March and people trusted the output more than they should have. A visible seam is the cheapest signal a user gets that the thing answering now isn't the thing that answered before.