W&B Weave Review (2026)

What Weave is, and the one team it is clearly built for

W&B Weave is the LLM half of Weights & Biases. Tracing captures every LLM call with one line of instrumentation - the @weave.op decorator - producing searchable, versioned, shareable traces. Evaluations run scoring functions over datasets and produce comparison dashboards.

The instrumentation API is genuinely one of the best in the category. You decorate a function, and you are done. Custom scorers are ordinary Python functions, not a DSL or a framework you have to learn, and the built-in ones cover exact match, regex, model-graded and embedding similarity.

But the reason to choose Weave over anything else is narrower and more specific: lineage. If your team fine-tunes models in W&B Sweeps, those models appear in the same interface as the eval runs testing them. No AI-native observability tool can offer this, because none of them do training. Langfuse does not know what a Sweep is. That single fact is the whole argument, and it is a strong one for the teams it applies to.

For everyone else, the argument gets much weaker, and the pricing is why.

Billing: GB ingested, not spans or requests

Weave introduced a value metric that is genuinely different from the rest of the category. Where Datadog charges per span and LangSmith charges per seat plus traces, Weave bills data ingestion measured in GB of logged traces. This is distinct from the “tracked hours” metric W&B Models uses. Weave ingestion, W&B Inference and storage are billed monthly in arrears based on usage.

The practical consequence is easy to miss and expensive to get wrong: your bill scales with trace verbosity, not just traffic.

Two applications making identical numbers of requests can have wildly different Weave bills. A RAG system logging a long system prompt, ten retrieved document chunks and a lengthy completion produces an enormous trace payload. A classification endpoint logging a short prompt and a one-word answer produces a tiny one. Per-span pricing would treat these similarly. GB-based pricing does not.

If you are evaluating Weave, measure your average trace payload size in a trial before you model anything. Request counts will mislead you.

The second pricing issue is bundling. Weave sits inside the wider W&B per-seat subscription, and a fair criticism is that the per-seat maths subsidises ML experiment-tracking surfaces that an LLM-application team may never touch. If you are not training models, you are paying for a platform whose other half you will not open.

We have not published a per-GB rate or a per-seat figure here because we could not verify current numbers against W&B’s own pricing page with confidence. Treat the exact rates as not verified and check wandb.ai/site/pricing directly.

The CoreWeave acquisition

CoreWeave closed its acquisition of Weights & Biases for a reported $1.7 billion, folding the developer platform into its GPU cloud.

CoreWeave has pledged continued interoperability across infrastructure providers and models. We have no evidence contradicting that, and W&B has continued shipping - the platform reports more than 60 framework and SDK integrations as of May 2026, which is not the profile of a neglected product.

The open question is structural rather than observed. A GPU cloud now owns the tool many teams use to decide which models to train and where. That is not an accusation of anything; it is a conflict of interest worth naming in a review, and worth raising directly with their sales team if you are signing a multi-year commitment. Compare this with the Helicone situation, where the acquisition immediately produced maintenance mode - nothing like that has happened here, and Weave should not be tarred with it.

Where it is weaker than a dedicated eval platform

Weave’s evaluation tooling is good at comparison and analysis. It is less naturally suited to release gating.

You can run evals programmatically and act on the results, so a CI/CD quality gate is buildable. But the product’s centre of gravity is the comparison dashboard - understanding how run A differs from run B - rather than blocking a deploy when a score regresses. Critics note that teams needing trace-level scoring, CI/CD quality gates and a direct path from a production issue back to a regression test frequently add a second tool alongside Weave.

The other structural note is the data model. Traces are W&B-native, with OpenTelemetry available as a secondary ingest path rather than the primary representation. If portability matters - being able to leave without re-instrumenting - Langfuse and Arize Phoenix are more standards-centric.

Should you use it?

Use W&B Weave if you already run Weights & Biases for training and experiment tracking. The lineage between fine-tuning runs and the evals testing them is unmatched, the instrumentation is excellent, and you are already paying for the seats.

Don’t use it if you are an LLM-only team with no training workload, your traces are large and your budget is tight, or release-gating evals are your primary requirement.

Bottom line: an excellent product with an unusually narrow ideal customer. For W&B shops it is close to an automatic choice and we rate it accordingly. For everyone else, the bundled per-seat pricing and the hard-to-forecast GB ingestion metric make it an expensive way to buy tracing you could get from Langfuse for free. Measure your trace payload size before you decide.

---

Corporate status and billing model verified against public sources on 31 July 2026. Exact per-seat and per-GB rates could not be confirmed against primary pricing pages and are flagged as unverified. This is a researched directory entry - we have not yet instrumented this platform with our reference application.