Claude Dashboards vs Power BI

On 8 October 2026 Anthropic launched Claude Dashboards: you describe the dashboard you want, and Claude writes the queries, builds the page and, in Anthropic’s words, keeps it current as the data changes (a live dashboard re-runs its queries whenever someone opens, refreshes or filters it). It’s in beta, on paid Claude plans (Anthropic’s announcement).

As a Power BI developer my first question was obvious: is Claude a BI tool now? So I did what I always do with a new feature and built something real with it. I gave it a challenge dataset and a design brief in the afternoon, and by the next morning I had an eight-tab dashboard. I was pretty impressed by the output.

Then I checked it against Power BI, 30 capabilities in all, with every mark sourced and dated.

The short version: for building the report, Claude Dashboards keeps up with Power BI on most rows (maps are the gap). For running it as a platform (the semantic model, security, refresh, deployment and distribution) Power BI is miles ahead. And the more I dug in, the more the two looked like they fit together, because Claude Dashboards works best sitting on top of a good semantic model.

For simplicity, this article only compares Claude Dashboards with Power BI. Tableau is still very much a competitor (and Anthropic lists it as a “coming soon” place to send a dashboard on to), but three columns made the table too big to read.

What I built

The data is the ZoomCharts Power BI Challenge for September 2026: an e-commerce profitability workbook with 9,109 order lines across 2024 and 2025. I gave Claude the Excel file and the challenge brief, and told it to ignore the references to Power BI and ZoomCharts.

What came back has eight tabs in the brief’s order (Overview, Products, Returns, Promotions, Customers, Channels and markets, Fulfillment, Inventory) under one row of filters for year, region, channel and category. Every headline is a full sentence worked out from the data, and it updates with the filters. Click a category bar on the Products tab and it sets the dashboard’s Category filter; click it again to clear it.

You can open it yourself: E-commerce Profitability on Claude. One catch: you have to be signed in to Claude to see it at all. In a signed-out browser the page opens but stays empty (“Nothing on this dashboard yet”) and asks you to sign in to see the artifact’s data, which is why the recording is here. Signed in, any Claude account should do: its share settings say anyone signed in to Claude can read its data.

What it actually took

For the build I typed three messages: the prompt with the brief pasted in, “Go with all the recommendations.” and a small settings tweak. Here’s the prompt, word for word (typo and all):

make a dashboard from the e-commerce Excel file in this directory. If you need to change it to a CSV file, then you can do that. Ignore the Power BI project that is in this directory and start the dashbaord fresh. this is the design brief, ignore the references to power bi and ZoomCharts [the ZoomCharts challenge brief, pasted in full]

That’s the prompting effort, and it really was very little. The build effort is a different story, and it’s only fair to show it. I didn’t use the claude.ai chat for this one: I built it in Claude Code (Opus 5.5) with the Dashboard artifact type, and Claude Code split the work across four multi-agent workflows.

That’s 37 agents and 5,130 tool calls, within about 15 hours 16 minutes of my prompt (to when I asked how long it took). The final checks opened all eight tabs at 1440, 1024 and 420 px wide, in light and dark (48 runs), and matched 6,214 numbers to the data; then 40 filter scenarios matched another 4,748 numbers without a single mismatch.

And the tokens: across 4,065 API calls the build processed about 989 million tokens. Before that number scares you, 97% of it (959.6 million) was cache reads, which cost a fraction of fresh input. At Claude Opus 5.5 list prices on 15 October 2026 the whole build comes to US$357.62 (cache reads $191.92, cache writes $152.12, output $13.55, input $0.03). My Claude plan covered it, so I didn’t actually pay that, but it’s the honest figure for what the build used.

What a plain claude.ai run gets

So what do you get without any of that? I gave a fresh claude.ai chat, on my normal plan, the same Excel file and the same brief in a single prompt: the one above without the line about the Power BI project, plus “for any questions, go with recommendations” (so it never needed a follow-up) and a note to make a new artifact rather than update my first one. It was done in under an hour, against about 15 hours for my Claude Code build.

The short answer: a substantially worse report. To be fair to it, it got a lot right. It has the same eight tabs and the same four filters, and its headline figures match mine (€127.7K contribution margin, 19.4% margin, €640.4K net sales, €36.7K lost sales). You can open the plain run’s dashboard too, with the same sign-in catch.

Where it falls down is everything my setup checks for:

• It describes instead of telling. My dashboard leads every tab with a finding (“Electronics brought 35.1% of net sales but 5.0% of contribution margin”). The plain run has one summary sentence that stays at the top of every tab, and its captions say what a chart shows (“Units returned per unit shipped, and the return loss they caused”) rather than what it found.
• The layout has holes. Rows leave a third of the width empty, cards stretch over dead space, and two labels in the Overview’s bar chart are cut off. On the Customers tab the cohort chart runs right out of its card.
• It doesn’t check its own work by default. The Dashboard type tells Claude not to render or screenshot the dashboard unless you ask, so nothing looks at the page the way a reader will. My setup did the opposite: it opened every tab at three widths, in light and dark, and matched more than 10,000 numbers back to the data.

One thing it did backs up the JavaScript point below: it built a star schema in JavaScript. It attached all nine sheets as separate files, wrote a calc that joins every order line to its product, customer, market, promotion and the rest (its own comment calls them “the star schema’s relationships”), and then, just like mine, worked out every metric for every filter combination up front. That’s a semantic model, rebuilt by hand inside one dashboard.

So the caveat above holds up. The dashboard feature is the same in both runs (the plain run even had a newer release of it); the gap is everything around it.

Why the logic matters: JavaScript vs DAX

This is the bit Power BI people will care about. Click any number in a Claude dashboard and the Sources pane shows how it was worked out: the query, the transform and the result, the JavaScript behind it, or the file it was read from. That’s a great feature. Power BI shows authors the DAX behind a visual in Performance Analyzer, and Copilot with Fabric IQ can show DAX, but I couldn’t find a built-in way for a viewer to click a number and see its query.

Here’s what clicking Margin % (19.4%) on my dashboard shows:

Margin % itself is one line, row.margin_pct = ratio(row.contribution_margin, row.contribution_revenue), but that line sits inside a 148-line calc that works out every headline metric for every combination of the four filters’ values (each filter either “All” or one value). Here’s a trimmed excerpt; my /* ... */ notes mark what I cut:

dash.calc('kpis', {
  inputs: ['order_lines'],
  title: 'Headline figures',
  /* ... a one-line description ... */
  fn: (order_lines) => {
    // Summed metrics: calc column -> order_lines column.
    const SUMS = {
      gross_sales: 'GrossSales', /* ... */ net_sales: 'NetSales', /* ... */
      contribution_revenue: 'ContributionRevenue', /* ... */
      contribution_margin: 'ContributionMargin', /* ... 20 columns in all ... */
    };
    /* ... give every filter value an integer code ... */
    for (let i = 0; i < n; i++) {
      /* ... read this order line's values ... */
      for (let m = 0; m < 16; m++) {
        const g = (((m & 8 ? y : 0) * nR + (m & 4 ? r : 0)) * nC + (m & 2 ? c : 0)) * nK + (m & 1 ? k4 : 0);
        /* ... add the line to slice g ... */
      }
    }
    const ratio = (a, b) => (b ? a / b : null);
    /* ... one output row per slice ... */
      row.margin_pct = ratio(row.contribution_margin, row.contribution_revenue);
    /* ... then 2025 against 2024 for every 2025 slice ... */
  },
});

To be fair to Claude, that’s not padding. My dashboard’s data is an attached file, which a filter can’t re-query, so the page’s own code has to work out every slice up front. The plain claude.ai run landed on exactly the same structure. On a live query the database would do that work instead: a date, a search or a long list goes straight into the SQL, and short pick-one lists like these four filters become a GROUP BY that returns every option’s rows.

In Power BI the same number is three measures, and the model’s filter context handles every slicer for free:

Contribution Margin = SUM ( FactOrderLine[ContributionMargin] )
Contribution Revenue = SUM ( FactOrderLine[ContributionRevenue] )
Margin % = DIVIDE ( [Contribution Margin], [Contribution Revenue] )

I checked those names against a real model. With the workbook’s FactOrderLine sheet loaded into Power BI Desktop, the three measures return the same €127.7K, €657.2K and 19.4% as Claude’s dashboard; Margin % agrees to 14 decimal places.

Both express the same calculation. Only one of them can be read at a glance, reused by every report on the model and handed to the next developer, though.

Kurt Buhler made the same point after testing Claude Dashboards with Fabric. With a semantic model it worked well (his screenshot shows the DAX behind a number in the Sources pane), but with lakehouses, warehouses or local files it guessed metrics and business logic too often instead of asking. His conclusion is that a good semantic model matters more than ever, and my 148 lines of JavaScript agree with him!

Claude Dashboards vs Power BI at a glance

I checked 30 capabilities, in two halves: building the report, then running it as a platform. Every mark has a note and sources behind it, and they’re all in the full table at the bottom. Click any row to jump straight to its detail.

• Yes
• Partial (the full table says why)
• No

Look at where the marks land. In the top half Claude Dashboards gets six ticks to Power BI’s five: it wins on fitting the screen (one layout that reflows all the way down to a phone) and on showing the query behind a number, and maps are its gap. In the bottom half it’s two ticks, 14 partials and six crosses against Power BI’s 21 ticks, and six of those partials say the same thing: Claude has none of its own, so it borrows the capability from the data source.

How to read the marks

• Licences never lower a mark. What you need to buy is in the notes. Row 30 is the exception, since what a viewer pays is the whole point of it.
• Borrowed is partial. Where a platform has none of its own but uses a connected source’s capability, the mark is partial.
• Preview is partial, unless a generally available route does the job. Claude Dashboards being a beta doesn’t lower its own marks.
• Code that Claude writes counts. Claude’s filters, click-to-filter and drill are page code it writes on documented runtime features, rather than built-in defaults like Power BI’s slicers and cross-filtering. The runtime documents the mechanism they run on, so they get a tick.
• “Not documented” means the vendor’s docs say nothing either way.
• Every mark had to survive a sceptical Power BI developer and a sceptical Anthropic employee.

Cost and licensing: harder to compare than it looks

Row 30 (what someone has to pay to see the report) is partial on both sides, for different reasons. On Claude, nobody sees data without a Claude sign-in, and live data only reaches people inside the owner’s Team or Enterprise organisation. On Power BI, free viewing needs an F64 (or P) capacity or bigger; otherwise every viewer needs Pro or Premium Per User.

But I’d be careful lining those numbers up against each other. A Fabric capacity buys an organisation a lot more than a way to vibe code visuals: lakehouses and warehouses, Dataflow Gen2, Direct Lake and larger semantic models, Fabric Apps, Activator alerts and, from F64, free viewing for everyone. A Claude seat buys a general-purpose assistant that also happens to build dashboards. Neither price tag is really the price of a dashboard, so I haven’t tried to force a winner on this one.

So, should Power BI be worried?

Not really. I think the two end up working together.

For building the report, Claude Dashboards is already very good, at least with a mature setup behind it (the plain chat run was a lot weaker). My dashboard is genuinely useful, it reflows down to a phone and every number shows its working. For a quick, exploratory question (which is how Anthropic pitches it) that’s a great fit.

But the dashboard is the last step. The semantic model, RLS, refresh, deployment, lineage, sensitivity labels, subscriptions and embedding are Power BI’s half of the table, and Claude Dashboards has no version of its own for most of them. Its own template even notes that a query through a connector’s governed or semantic definitions gives the number people get when they ask elsewhere. In other words, the best Claude dashboard sits on top of a good semantic model, and building and running semantic models is exactly what Power BI is for.

The catch today is plumbing. Kurt reports that a live connection to a Fabric semantic model needs a remote MCP server, which you can host yourself, because Microsoft’s own remote MCP servers don’t currently work for live dashboards (Claude’s custom connector guide covers the Claude side). Once that gets easier, I can see plenty of teams using both: Power BI for the governed model and the reports everyone relies on, and Claude for quick questions on top of the same model.

---

Changelog

• 15 Oct 2026: published.

Appendix: the full comparison

Every capability with its marks, notes and sources, as of 15 October 2026. The marks follow the rules under How to read the marks. Each source key links straight to its page, and the full list is under the table.

Sources

Read on 10 October 2026, with Anthropic’s pages, the dashboard template, the Microsoft pages behind row 23 and the prices read on 15 October too. Keys without a public page link to their entry here.