# Why AI models claim each other's work, and how to stop it

Chat formats record which side of the conversation said something, not which model said it. In a multi-model conversation, that gap turns into false credit.

Published 2026-09-24 by the Poly team. Canonical: https://usepoly.co/why-ai-models-claim-each-others-work
Poly (usepoly.co) is a web app where a team builds with AI (Claude, GPT, Grok, Kimi or Muse) together in a shared room. Free to start: https://usepoly.co/

**AI models claim each other's work because the conversation format they read has no author field for replies. Anthropic's Messages API, which Claude, Meta's Muse and Moonshot's Kimi all accept, has two roles: the user and the assistant. When several models take turns in one conversation, every earlier assistant reply reaches the next model as if it had written it. In September 2026, in a Poly room, Muse did exactly that: it said it had built a dashboard that Claude built, and when corrected, it pointed to a git history that named no agent at all. Poly (usepoly.co) now prevents it two ways: a record of which agent answered each prompt, and a "Poly-Agent:" line on every commit.**

## Key takeaways

- Chat formats label roles, not models. A reply from Claude and a reply from Muse look the same to the next model.
- Models can't reliably tell. Research published in 2026 found that their ability to spot replies they didn't write is inconsistent and rarely used unprompted.
- Fix it with a record: tell the model who answered each prompt when the conversation changes hands.
- Fix it in git: name the agent on every commit, so the repository can answer "who built this" by itself.

## Why does a model think it wrote replies it didn't?

A conversation reaches a model as a list of turns, each marked user or assistant. That is the whole label. Poly marks people inside their turns ("[Maya]: make the chart bigger"), so the model can tell who is asking, but the format has no matching slot on the assistant side, nowhere to say "this reply was Claude's".

Poly's own records knew. The Claude Code session file stores the model behind each reply, and so does every row of the room's timeline. Neither reached the model. So when Muse picked up a conversation Claude had started, the earlier replies read as its own.

## Can't the model tell from the writing style?

Not reliably. In March 2026, researchers tested whether models notice replies inserted into their side of a conversation ([Africa, Souly, Taylor and Kirk, "Prefill awareness"](https://www.lesswrong.com/posts/jsFGuXDMxy5NZg9T2/prefill-awareness-can-llms-tell-when-their-message-history)). The ability varied across models and datasets, leaned on surface style, and rarely showed up unless the model was asked. The strongest detector they tested, Claude Opus 4.6, scored 0.80 AUROC overall but 0.39 on one of the datasets, and was poor at pointing to which message had been inserted. Asked "did you build this?", a model usually answers from the transcript it was given.

## What happened in the Poly room?

On September 22, 2026, a room built a dashboard with Claude. Later, a member working with Muse Spark 1.3 asked about it, and Muse said it had built the dashboard itself. Told that Claude built it, Muse replied that git history showed it had built the dashboard. Poly's commits didn't name the agent behind them at the time, so git could not settle it. There was nothing for Muse to check, only its own false memory to confirm.

One of Poly's own messages made it worse. The catch-up that briefs a joining model used to open with "while you were away", which told the model that the conversation before the gap had been its own. That wording is gone.

## How does Poly stop it?

**1. The authorship record.** On the first turn after the conversation changes labs, the prompt carries Poly's record of who answered each earlier prompt. An illustrative example, shortened:

```
[Who answered the earlier prompts in this
conversation: Poly's record, for Muse
(muse-spark-1.3), the agent answering this
message. ...
- Maya: "Build a sales dashboard from
  orders.csv" → Claude (claude-sonnet-5),
  commit 3f2a91c (Add sales dashboard)
- Ben: "What does the churn chart show?"
  → Claude (claude-sonnet-5), no file changes
None of the replies above are yours. Credit
the rest to the agent named (say "Claude
built that", not "I built that") ...
— end of record]
```

The record lists up to 12 recent prompts and tallies the older ones. It goes out once per change of lab, not on every turn, and switching between models of one lab, such as Sonnet 5 to Opus 5.5, doesn't trigger it. It rides on the prompt rather than the system prompt, so it doesn't break the room's prompt cache.

**2. The Poly-Agent line.** Every commit Poly makes for a turn now ends with a line naming the agent and the exact model:

```
Poly-Agent: Muse (muse-spark-1.3)
```

When the agent runs in Claude Code, commits it makes itself are signed the same way; left to its defaults, Claude Code's commit attribution named Claude Code, even on Muse's commits. Codex has no such setting, so for GPT and Grok the line is on Poly's own commit for the turn. Poly keeps only model-id characters in the name, so a crafted model id can't forge a second line. Git can now answer the question directly: `git log --grep "Poly-Agent: Muse"` lists Muse's work.

## What about GPT and Grok?

They don't share the conversation Claude, Kimi and Muse use, so they never inherit another lab's unlabeled replies. When they join after other agents, their catch-up names the agent behind every reply ("Claude replied: …"). [How the catch-up works](/switch-ai-models-mid-conversation).

## What should you do if you mix models yourself?

The same problem shows up anywhere more than one model shares a history: a script that swaps models, a chat app with a model picker, an agent that hands off to another. Four habits help:

1. **Label replies before you re-send them.** Put the model's name in the reply text, or in a note the next model reads.
2. **Name the model in commits.** A trailer line at the end of the commit message survives every tool that reads git.
3. **Treat the repository as the record.** Ask the model to check git, and make sure git has something to check.
4. **Don't word a handoff as if the new model was there all along.** "While you were away" does exactly that.

## Common questions

**Does this happen with only one model?**

Not in the same way. With one model, every earlier reply really is its own. It takes a second model, or an app that edits the history, for replies to be credited to the wrong model.

**Can I see which model made a commit in Poly?**

Yes. Poly's commits end with a Poly-Agent line naming the agent and model, for example Poly-Agent: Muse (muse-spark-1.3). Commits from before September 23, 2026 don't have it.

**Are people attributed too?**

Yes. Every prompt carries its author's name, every receipt says who asked, and every approval records who gave it.

More guides: https://usepoly.co/guides · Security: https://usepoly.co/security · Pricing: https://usepoly.co/pricing