Claude Tag users report token billing and shared-memory concerns

• Anthropic shipped Claude Tag as a Slack-native, shared Claude instance for Team and Enterprise customers, where claudeai's launch post says teams can tag Claude into channels and claudeai's availability post says the beta is live now.
• The product's core change is shared context: claudeai's channel-memory description says one Claude serves everyone in a channel, while Boris Cherny's launch thread describes it as proactive, multiplayer, and persistent.
• Anthropic's answer to the obvious permission question is "agent identity": ClaudeDevs' explainer says Claude uses its own credentials in channels, and ClaudeDevs' audit-log post says admins can revoke that identity once across connected systems.
• Early reaction focused less on the Slack UI than on the billing model, with daniel_mac8's post about metered usage noting per-token billing for every message and random_walker's long thread arguing that shared memory and opaque costs could create lock-in.
• Anthropic is also pitching this as an internal workflow shift, not a small bot feature: claudeai's thread says its internal version now produces 65% of the product team's code, and Andrej Karpathy's post calls Claude Tag an "org-level harness."

You can read Anthropic's launch thread, skim the agent identity explainer thread, and check out best-practice tips from Thariq Shihipar. The weird bit is how much of the product is really access control: ClaudeDevs' permissions post frames setup around per-channel scoping, while Boris Cherny's sandbox note says each tagged thread gets its own sandbox that is thrown away when the work is done.

Anthropic launched Claude Tag as a Slack teammate that can be added to selected channels, connected tools, and codebases, then tagged into work inside a thread via the main launch post. claudeai's task-breakdown post says it can decompose work into stages, use its allowed tools, and return with outputs like pull requests, data analysis, or incident help.

The launch materials keep circling the same four properties, which also show up in

:

• Multiplayer: one Claude per channel, shared across teammates per claudeai
• Persistent context: it follows the channel and accumulates work context over time per claudeai
• Ambient behavior: it can proactively follow up on quiet threads and flag relevant updates per claudeai
• Async execution: it can keep working over hours or days after the initial tag per claudeai

That combination is why Karpathy's reaction pushes back on calling it a Slack bot and instead labels it an org-level harness.

The most concrete technical detail in the day-two discussion was Anthropic's permission model. According to ClaudeDevs' DM-versus-channel explanation, Claude acts as the user in one-on-one DMs, but in shared channels it acts as itself because there is no single teammate's permissions to borrow.

ClaudeDevs' connector examples says that means Claude can get its own GitHub account, Linear account, or warehouse service account. ClaudeDevs' audit-log post adds two operational consequences:

• Actions show up under Claude's own account in connected-system logs
• Revoking Claude's identity cuts access across connected systems once
• Shared channels do not expose a teammate's private files

Anthropic's setup story is also channel-scoped. ClaudeDevs' admin post says admins provision Claude once, then decide which channels get broad read access and which channels can touch more sensitive tools.

Claude Tag's stickiest feature is not the tagging syntax, it is the shared memory layer. claudeai's own description says a teammate can pick up where someone else left off because the channel shares one Claude and the system keeps accumulating context from that workspace.

That is exactly the part critics seized on. In random_walker's thread, the concern is that Claude becomes a repository for tacit team knowledge that ordinary users cannot directly inspect or edit, which turns memory from a model weakness into a source of product stickiness. Aaron Levie's post makes the upside case instead, arguing that a shared agent identity lets teams safely point Claude at common resources like Box, CRM data, analytics, and codebases.

Anthropic employees are already describing channel-specific behavior as a feature, not a side effect. Tobin South's post says different channels should be treated as different Claudes, and Thariq Shihipar's thread recommends introducing each channel's Claude with pinned instructions so its memory behaves more like a channel-level Claude.md.

The sharpest criticism landed on cost shape, not model quality. daniel_mac8 notes that Claude Tag is metered usage and bills per token for every message, while random_walker argues that a shared async coworker is harder to budget than a seat-based assistant because it can keep doing background work across an entire team.

Two specific worries showed up repeatedly in commentary:

• Spend becomes communal rather than attributable to one user's seat or session per random_walker
• Memory and workflows can accumulate inside Claude itself, which makes replacement harder over time as random_walker later put it, "a coworker that remembers everything and bills by the thought"

Not everyone bought the lock-in thesis. random_walker's follow-up also notes replies arguing that open-source scaffolds could copy the harness pattern quickly, and Karpathy's longer explanation says the hard part is not a hackathon prototype but getting tools, integrations, memory, security, and compute environments to work well enough for enterprise deployment.

Anthropic is selling Claude Tag with internal numbers and canned workflows, and the most concrete stat is repeated across multiple posts: claudeai and Cat Wu's post both say the internal version now produces 65% of the product team's code or pull requests.

The internal-use thread breaks that into specific patterns in ClaudeDevs' examples:

1. Incident response: Claude diffs deploys, proposes a fix, watches recovery, and resolves the page
2. Bug triage: it reproduces reports, finds the code path, writes a fix, and tags the owner
3. Dependent work: it waits on another task, then resumes days later with an updated PR
4. Postmortems: it reconstructs a timeline from the incident thread and files follow-ups
5. Background watchers: it monitors thresholds like prolonged CI failure and opens a fix when triggered
6. Metrics monitoring: it watches an A/B test, flags guardrail movement, and prepares a rollout PR

That is the strongest evidence for Karpathy's "org-level harness" framing in his post, because the product pitch is really a bundle of memory, tooling, monitoring, and permissioned execution wrapped in Slack.

One more implementation detail surfaced in replies after launch: Boris Cherny says tagging Claude in a channel spins up an instance with its own sandbox, where it can clone repos, write code, test, and compile in isolation, then discard that sandbox when the thread is done. The same post says permissions live per channel and instances are effectively one per thread.

A few reply-only details flesh that out further. Boris Cherny's commit-attribution reply says commit attribution is configurable by asking Claude to update its setting, and his reply about future surfaces says Slack is not the end state. Cat Wu's setup post also points to a dedicated permissions guide, which fits the broader story here: the differentiator is less "Claude in Slack" than the machinery that decides which Claude shows up, what it can reach, and how long that access lasts.