What actually carries across a model change, what does not, and the six setups teams use so nobody has to brief the same project again
Aug 14, 2026 · 13 min read
A team that regularly moves one piece of work between models needs the conversation, the files and the project instructions to belong to a workspace rather than to GPT, Claude or Gemini. A team where one or two people stay with a single model does not need that, and a written handoff document covers the occasional switch. The eight workspaces compared on the same criteria below are Playgram, WorkLLM, nexos.ai, Langdock, TeamAI, Aymo, Magai and TypingMind.
The reason a switch costs so much today is that each vendor keeps a good record of its own half of the work. A saved chat holds its earlier turns, a project holds its files, and none of it can be read from another company's account. So the work is not lost anywhere. It is split across four products, and the person switching is the only thing joining them up.
This guide sets out what carries across a model change and what does not, and it separates three things that get confused: the context window, a project workspace and stored memory. It costs out the six setups teams use to handle a switch, and ends with six tests to run before you move any real work.
You move research, requirements and review between models, rewriting the context each time.
Marketing, analysis and engineering each reach for a different model, and the brief gets pasted into all of them.
Work passes between people, and the next one cannot see what the earlier chats decided.
One or two people use a single model for nearly everything, and switch only for a second opinion.
The project is split across products that each keep a different part of it, and four separate costs come out of that split.
A person who needs GPT, Claude, Gemini and Grok needs four provisioned seats. As an example, those four team plans came to about $101 per person a month at July 2026 list prices. That total takes ChatGPT Business at $25, Claude Team at $25, Gemini Business at $21 and Grok Business at $301, 2, 3, 4. Read that as an illustration rather than a rate, because a cheaper mix is easy to assemble. Several of those seats also bundle the same capability twice, such as web search or document tools the team is already paying for in another plan. The shape holds at any total. Someone who switches into a model twice a month still pays for a full seat, because there is no smaller unit to buy. Zylo's 2025 index reports substantial waste on unused licenses across the organisations in its dataset, which is an argument for auditing seats rather than a forecast for any one team5.
A switch is seven steps, and the team does all of them by hand. You open another interface and find or rebuild the relevant thread. Then you paste the project brief, upload the source files again and re-enter the output rules. Last you explain which earlier decisions are settled, and check whether the new model supports the same tools. The last two are the ones that get skipped under time pressure, and skipping them is what produces an answer that argues against a choice the team already made.
Project context sits inside personal accounts, so prompts, decisions and outputs stay with the person who created them, and a teammate picking the work up opens an empty chat. Switching accounts inside one vendor does not join it up either7. Five separate things get called context, and only some of them move with the work. They are the earlier turns of a saved chat, files attached to a chat or a project, a project workspace, custom instructions, and memory stored for later conversations. A context window is none of them, because it is the material packed into one model request rather than anything kept afterwards6. The vendors' own memory features do not close the gap, because each is built for one person inside one product. ChatGPT Business personal memories are not shared with colleagues35, and Gemini's memory of past chats is not available to work or school accounts36. Exports give you an archive rather than a conversation another product can resume, at OpenAI11, Anthropic12 and Google alike13, and Magai is the only product in the shortlist that documents an importer14.
No single view shows which model was used for a piece of work, why, or what each product cost this month. So a question as simple as whether the team still needs all four plans has no easy answer. There is no shared retention policy and no way to cap spend before it happens. When someone changes tools or leaves, their prompts and history leave with them, and a new hire has to be added and later removed one vendor console at a time.
Five things to check on any candidate. The transfer behaviour in the first one is what vendors document least, so it usually decides the trial.
A person should be able to pick a different model without opening a blank conversation. The product should then say what the new model receives: earlier turns, attached files, project instructions and tool results. Vendors often document the switch and not its contents.
Model access is half the job. List what the team needs beyond chat: cited web research, document and spreadsheet work, image generation, code review, and chats that leave nothing behind. A gap here means buying a second product and splitting the context again.
Source files and instructions belong to a project rather than to one chat, and decisions have to stay available after that chat ends. Then a teammate opens the project instead of asking what was decided, and a new member reads the brief rather than being told it.
An admin should see who uses which models, cap spend before a bill arrives rather than explain one after, and set limits per person as well as across the team. Private work, project material and shared reference need boundaries drawn where your team has them.
Some people switch models daily and others twice a month, and a plan that forces a full-capacity seat on the occasional user prices that group out of the workspace. Check that someone can inspect and correct what memory saved, then price the shortlist at your headcount and at double it.
The multi-model workspaces a team is most likely to weigh up, judged on the same criteria. Where a vendor does not document something, the cell says so.
This table compares multi-model team workspaces with each other. The single-vendor plans a workspace replaces are priced further down, under 'Priced per seat', and are not rows here. Pricing is the lowest-priced paid plan that covers five users, at the monthly rate, so a product whose entry plan holds fewer than five people is shown on the plan that holds them. Each cell cites the page that documents that cell rather than one pricing page per row. Figures checked August 2026 against each provider's own pages, and cells marked 'a manual test is required' could not be confirmed from public documentation.
The same products on the criteria that decide daily use: what the workspace does besides chat, what it connects to, what an admin sees and can cap, and where your data goes.
These criteria decide daily use more than the model list does, and vendors document them very unevenly. 'Not publicly documented' means the official sources checked did not state it. It does not mean the feature is absent, so read those cells as questions to put to the vendor. Checked August 2026.
The published per-seat price of each major single-vendor team plan, billed monthly. A team that switches models often is usually paying for several of these at once.
Each one is a good product inside its own model family, and each one keeps its own record of the work. Prices change often and vary by annual against monthly billing and by region. Figures checked July 2026, so confirm current pricing with each provider before purchase. Sources are listed at the foot of this page.
Two of these appear on an invoice and two do not, which is why the switching cost is usually the last one a team measures.
Six realistic setups, from a written handoff through to a shared workspace. The workspace options come first because they are the subject of this guide.
The conversation, its attachments and the project instructions belong to the workspace, so changing model does not start over. What each product sends the new model varies, and several never say, which is why the shortlist above has a column for it.
Best for: Teams switching models inside ordinary chat work.
Strengths
Trade-offs
The same setup, plus decisions and reference material saved at a level the whole team can reach. It is the version that stops a group explaining the same project again. It is also the one with the most to check, because memory only helps when a person can see what was saved and who can read it.
Best for: Teams reusing the same decisions across people and projects.
Strengths
Trade-offs
No new product. The team agrees a standard handoff package, which is a short brief, a decision log, the source files and the latest approved output, and pastes it into the new chat on every switch. It works, and it costs nothing to start.
Best for: One to three frequent users making occasional switches.
Strengths
Trade-offs
Standardise on a single vendor and keep everything inside it. Context stops fragmenting immediately, because there is only one product holding it. What the team gives up is model choice, and for some work that is a real cost rather than a theoretical one.
Best for: Teams whose work is mostly solved inside one model family.
Strengths
Trade-offs
Buy the team plans the work needs and accept the switching cost. As an example, five people on all four of the plans priced above came to about $505 a month at July 2026 list prices, before any of the time spent re-briefing1, 2, 3, 4.
Best for: Teams that need each vendor's own tools.
Strengths
Trade-offs
Engineers build the workspace, so routing, retention and what gets resent on a switch are all decisions the team makes rather than reads in someone's documentation. The subscription cost turns into build and maintenance cost.
Best for: Engineering teams needing exact routing and retention behaviour.
Strengths
Trade-offs
A research-to-draft-to-review job with the project context set once. Every stage reads from it, so no model or person starts empty.
Every arrow passes through the shared context rather than between the models, because no model reads another one's internal state. Two stages the boxes cannot show. A person approves the draft before it ships, and sends unsupported claims back to the drafting stage. The approved output and the decision log then go back into the project, so the next teammate opens it rather than being briefed.
Memory is the part that decides whether a switch works tomorrow as well as today, and a demo makes every version of it look the same.
A context window is how much text a model reads in one request, and it empties when the chat ends. Memory is context stored outside the chat and pulled back into later ones, on another day or another model. A larger window does not give a team the second thing.
Some keep chat history and nothing more. Some let you attach files and build a knowledge base by hand. Some learn automatically but keep what they learn private to one person. Some save it where the whole team can reach it. Only the last stops a group explaining the same project again.
Shared memory needs boundaries: what belongs to one person, what belongs to a project and its members, and what the organisation should see. Products draw these lines differently and some draw only one, so ask which boundaries exist rather than assuming yours are reflected.
After a model change, can you see exactly which earlier turns, files, instructions and saved entries the new model received? If not, keep a visible decision log as the authoritative handoff, and check that someone can correct a wrong entry and stop exploratory work becoming permanent.
A vendor-neutral plan for the one behaviour a demo will not show you honestly. It takes about two weeks end to end.
List every AI subscription, who actually uses it, which projects sit inside each vendor, and the custom instructions and agents people rely on. Note which native integrations you would lose by consolidating, and which work needs a particular retention or hosting arrangement.
Use work the team already has that week, such as research into an article draft, customer discovery into requirements, spreadsheet analysis into a report, or a technical design into review. Prompts written for a demo make every product look good.
Give each candidate the same source package, then change the model inside one thread, change it after uploading several files, and change it after a web search. Have a teammate continue the project, remove a file or a saved decision, and export the finished project.
Count the repeated context explanations and repeated uploads, time to a first useful answer, manual edits needed, and whether sources and project instructions survived each switch. Record how long a new teammate took to pick up a live project.
Confirm the product does not train on your content, check how long it keeps data and in which countries the models run, and find the setting that removes access when someone leaves. Ask what happens to a person's project context on their last day, because a shared workspace makes that a real question rather than a policy one. Then price the shortlist at your current headcount, at three more people, and at double, because per-seat and usage-based plans cross over somewhere.
A team that switches models regularly should store the work outside whichever model is processing it. For occasional switches a written handoff package does the job and costs nothing. For repeated work across several people, a workspace that holds the thread, the files and the project instructions removes the step that keeps being repeated.
Four limits apply. Pricing, model availability and plan caps move fast, and two plans called Business are rarely the same purchase, so you cannot compare them by name. Stored memory only helps when a person can see what was saved and who can read it. Not everyone needs the same access. And a model change never guarantees identical behaviour, because models differ on file types, window sizes and how they read the same instructions.
So the real choice is not which model is best. It is where the project lives, who can reach it, and what the second model is actually given when the work moves. Test that on your own files for two weeks, with a real handover to a real teammate, because it is the one thing no demo will show you honestly.
Upgrade as needed, and only pay for what you actually use
Save ~17% with the annual plan
Pro
Perfect for small and medium teams
Unlimited users & infinite memory
Multi-LLM chats
Granular access control to models
EU data residency
Ultra
Best for large, growing teams
Unlimited users & infinite memory
Multi-LLM chats
Unlimited use of DeepSeek V4 Flash
Granular access control to models
Choose US or EU data residency
Enterprise
Get in touch
For organizations with advanced needs
Unlimited users & SSO
Priority Support
Unlimited use of DeepSeek V4 Flash
Granular access control to models
Choose US or EU data residency
30-days money back guarantee
Playgram will automatically choose the most cost-efficient model suitable for the task. It will be chosen by users in approximately 80% of requests. Your models for the remaining 20%:
If you bought each separately:
Related comparisons