Weights & Biases Weave Pricing Now Lives Inside CoreWeave Forge

Weights & Biases pricing moved with the product. The current rate card is CoreWeave Forge, where Weave shares a commercial surface with the wider W&B toolset. A buyer staring at the page sees $0 for Free and Pro starting at $60 per month. Enterprise requires a sales conversation. The smaller line about ingested bytes deserves more attention because one verbose trace can carry prompts, responses, metadata, and evaluation fields.

TL;DR

• Weave Free includes 1 GB of ingestion each month.
• Pro starts at $60 monthly and includes 1.5 GB.
• CoreWeave lists added ingestion separately, so trace volume can matter more than the base plan.
• Weave observes and evaluates model activity. It is not an identity-aware authorization point for the request.

The current Forge plans

The CoreWeave Forge pricing page lists Free at $0 per month and Pro starting at $60 per month, billed monthly. Pro includes a 30-day trial and is described for organizations with fewer than 50 employees. Enterprise uses a custom plan.

Weave ingestion allowances differ by tier. The page lists 1 GB per month for Free and 1.5 GB per month for Pro. It also displays added ingestion at $0.10 per MB for Pro and $0.20 per MB for Enterprise. Those are vendor-published labels, so I would put the exact units into the purchase record rather than silently converting them into a guessed effective rate.

What Weave counts as ingestion

CoreWeave defines ingested bytes as trace data received and stored by Weave. That can include trace metadata, LLM inputs, LLM outputs, and fields an application explicitly logs. HTTP headers and data excluded from long-term storage fall outside that measure. The byte is counted once when received and stored.

The Weave product documentation describes tracing, evaluation, prompt and model management, monitoring, and feedback. A team can therefore increase the meter by recording more context, larger responses, tool arguments, or evaluation detail. Picture a dashboard trace with a 40-page contract pasted into one input field. The storage decision happened before anyone looked at the chart.

How to test likely ingestion before signing

Use a representative request rather than a blank pricing worksheet. Send the same request through the instrumentation settings the production application will use, then inspect the stored trace. Record the prompt and response size. Separately note any metadata or evaluation fields that the application adds. This makes the source of ingestion visible and gives procurement a repeatable unit to compare with the monthly allowance.

Run that check again with a deliberately large input, such as the 40-page contract example above. The purpose is to expose the settings that copy application context into storage. If headers are excluded from long-term storage, confirm that they do not appear in the retained trace. If a field should not be retained, remove it at the application logging layer before treating the resulting byte count as representative.

The purchase record should preserve the Forge plan label and published ingestion allowance. It should also preserve a link to the exact rate card used for approval. When the invoice arrives, compare the ingestion line with stored trace volume rather than the token-cost estimate. That review keeps the meters separate and gives finance a concrete record if usage changes after instrumentation settings are revised.

Cost tracking and invoice cost are different

Weave can estimate the cost of model calls from token use and provider prices. That feature answers what the model invocation cost. The Forge ingestion line answers what Weave stored. Combining the two numbers produces a false unit cost because they measure different events.

I would reject any procurement sheet that puts both under a column called "AI cost." Keep provider inference, Weave ingestion, Weave storage, and sandbox use as separate rows. The cost-tracking guide explains the model-call side; the Forge rate card governs the commercial plan.

The security boundary

Weave creates useful evidence about model behavior, but observation comes after an application decided to make the call. An enterprise still needs to decide which authenticated user or agent may send that prompt and which approved provider route it may use. It must also decide which data classes may cross that route. Our AI gateway guide explains that request boundary. The audit-log retention guide covers the separate evidence lifecycle.

A trace can say what the application reported. An independent policy decision records what the gateway permitted before the model received it. Buyers should test both records with the same request ID and verify that a blocked request never becomes a provider call.

DeepInspect

DeepInspect sits between authenticated users or agents and HTTP LLM endpoints. It evaluates identity and prompt policy for the selected route before forwarding the request, then writes a per-decision audit record. Weave can receive the resulting trace without becoming the authorization system.

Book a technical deep dive at deepinspect.ai.