What the Claude Code Artifacts update actually shipped
Straight up, this is the kind of update that changes what you can sell, not just how you work. The Claude Code Artifacts update brought live, shared dashboards and interactive workspaces to Team and Enterprise around June 18 2026, reported here: https://venturebeat.com/data/anthropics-claude-code-artifacts-update-brings-live-shared-dashboards-and-interactive-workspaces-to-enterprises .
Read that as an agency, not as a developer. The old story was: you build something, you hand over a file or a repo, the client says thanks and you both move on. The new story is: you build something that stays live, that the client and their team can open, share, and use. That is the difference between a deliverable and a destination.
If you have been running Claude Code well already - and the [pro workflow guide](/blog/how-to-use-claude-code-like-a-pro) covers the habits - this update is the part that turns your output into something a client logs into rather than something they download once and lose.
Static deliverable vs live artifact dashboard
The clearest way to see why this matters is to put the old deliverable next to the new one. The work to build them can be similar. What you can charge, and how long the relationship lasts, is not.
The same build, sold two different ways.
| Static deliverable | Live artifact dashboard |
|---|---|
| A file, export, or repo handed over once | A workspace the client logs into and uses |
| Goes stale the moment you send it | Stays current as data and inputs change |
| Client forgets it exists in a month | Client opens it weekly, sees your name on it |
| Flat fee, then the relationship ends | Natural retainer - it needs upkeep and updates |
| No shared visibility across their team | Shared across their team, used in their meetings |
How an agency turns a build into a live dashboard
Here is the move, concretely. You already build things for clients - a metrics view, a content tracker, an internal tool, a reporting layer. Instead of shipping it as a one-off, you ship it as a live artifact the client can open.
- Pick a deliverable the client already wants to look at repeatedly - reporting and dashboards beat one-time scripts.
- Build it as a live, shared artifact so their team can open and read it, not just you.
- Wire it to the real inputs so it reflects current state, not a frozen snapshot from launch day.
- Hand over the link, not a file. The deliverable is a place they go, not a thing they store.
- Put your maintenance and updates on a recurring scope, because a live thing needs tending.
The psychological shift for the client is the whole point. A file they downloaded is something they paid for once. A dashboard they open every Monday is part of how they run their business. The second one renews. The first one gets forgotten.
If you want to wire that dashboard to outside data sources cleanly, the [guide to MCP servers](/blog/what-are-mcp-servers-and-why-they-matter) is the right next read - that is how you feed a live artifact real, current inputs instead of static numbers.
Why a live artifact is a pricing conversation
This is where the money logic changes. A static deliverable is a flat-fee transaction. A live artifact is a relationship. Something that stays current has to be kept current, and keeping it current is recurring work you can scope and bill.
The honest framing for the client is simple. The build gets it live. The retainer keeps it accurate, adds the next view they ask for, and keeps it running as their needs change. That is not a tax. It is the difference between a dashboard that is right and one that quietly went stale three weeks after launch.
For how to actually put numbers on this - build fee versus monthly upkeep - work through [how to price a Claude Code agency project](/blog/how-to-price-a-claude-code-agency-project). A live artifact is the cleanest retainer argument you will get, so do not undersell it as a one-off.
The reliability test before you ship it live
A live artifact is more exposed than a file you emailed. The client can open it any time, including the moment it breaks. That raises the bar on reliability, and it is worth a short checklist before you hand over the link.
- Confirm the data the dashboard reads is something you control and can keep flowing.
- Make sure a broken input fails visibly inside the artifact, not silently with stale numbers.
- Set expectations on refresh cadence so the client knows how current the view is.
- Decide who on their team can see it before you share the link widely.
- Agree the upkeep scope in writing so a live thing does not become unpaid support.
Get those right and the live artifact does what a static file never could: it keeps your work in front of the client every week, and it gives you a clean reason to be on retainer rather than chasing the next one-off.
Which client builds make the best live artifacts
Not every build wants to be a live dashboard. The ones that do share a trait: the client benefits from looking at them more than once. A one-time migration script is not a dashboard. A view of how that migrated data is performing every week absolutely is. Pick the work where current state matters and you have your candidate.
A few that translate cleanly into a live artifact an agency can bill on a retainer:
- A reporting view that rolls up the numbers a client checks on a regular cadence anyway.
- An operations board the client's team reads in their own standups and meetings.
- A tracker for a project you are running for them, so status is always live, not emailed.
- A monitoring view that flags when something they care about drifts out of range.
- A research or competitor brief that refreshes on a schedule and stays current.
Notice the through-line. Each of these is something the client returns to, which is exactly why it earns a retainer rather than a flat fee. A thing you look at once is a purchase. A thing you look at every week is a subscription, and that is the relationship you want with an agency client.
There is a second reason these win. A build the client uses constantly is a build they ask to extend. They will want one more view, one more metric, one more cut of the data. With a static file, those requests are awkward - you delivered, you are done, why are they asking for more. With a live artifact, those requests are the point. Each one is scoped, quoted, and added to the same workspace, and your retainer grows because the client keeps finding new reasons to need it. The deliverable that gets used is the deliverable that keeps paying.
Operators inside the community are already turning builds into live, billable dashboards. If you want their setups and pricing scripts, [join the Claude Code Club](https://www.skool.com/claudecodeclub/about). More agency playbooks live on the [blog](/blog).
Frequently asked questions
What did the Claude Code Artifacts update add?
It brought live, shared dashboards and interactive workspaces to Team and Enterprise around June 18 2026, per https://venturebeat.com/data/anthropics-claude-code-artifacts-update-brings-live-shared-dashboards-and-interactive-workspaces-to-enterprises .
What tier do live, shared Artifacts require?
The reported live, shared workspace capability is a Team and Enterprise feature. Confirm your own plan tier before promising a client a live, shared dashboard.
Why is a live dashboard better than a file for an agency?
A file is a one-time handoff that goes stale. A live dashboard stays current, the client opens it repeatedly, and keeping it current is recurring work you can put on a retainer.
How do I price a live artifact dashboard?
Split it into a build fee and a monthly upkeep line from the start. The build gets it live, the retainer keeps it accurate. See /blog/how-to-price-a-claude-code-agency-project for the numbers.
How do I feed a live dashboard real data?
Connect it to your data sources, often through MCP servers, so it reflects current state instead of a frozen snapshot. See /blog/what-are-mcp-servers-and-why-they-matter .
Last reviewed by Duncan Rogoff on June 20, 2026
