TL;DR
Cosmo Studio is the operator console for a federated GraphQL graph: schema registry, schema checks, analytics and distributed tracing, playground, and organization management. Use it to see, validate, and observe the live graph. The router executes every request; WunderGraph Hub is where a schema change is designed and agreed on before it ships.
Glossary
Schema registry
The system of record inside Cosmo Studio for every subgraph schema and composition result; it validates whether schemas compose safely before they reach production.
Breaking composition gets caught in the registry or CI, not in live traffic.
Schema check
A validation Cosmo Studio runs against a proposed schema change before it ships: composition, breaking-change detection, an operation check against real traffic, and lint.
Teams see exactly which clients and operations a change would break, before merge.
Operation check
The part of a schema check that replays a breaking change against real production traffic. If no active client uses the affected field, the check passes.
Teams stop treating every breaking change as automatically unsafe; usage data decides.
Schema explorer
The interactive view of the composed schema inside Studio, with search, field-level usage data, and deprecated-field tracking built in.
Teams can tell whether a field is safe to remove before they try to remove it.
Distributed tracing
The trace view inside Studio Analytics that shows the path a request took across the router and every subgraph it touched, span by span.
Debugging a slow or failed federated request stops being guesswork.
Schema contract
A filtered view of a source graph, generated from `@tag` annotations, that exposes a subset of the schema to a specific audience.
One graph can serve internal, partner, and public consumers without three separate APIs.
What Is Cosmo Studio?
WunderGraph Cosmo Studio is the web console for WunderGraph Cosmo, the open-source GraphQL federation platform. The CLI and the router build and run the graph; Studio is where a team sees it, understands it, and decides whether a change is safe to ship.
Every federated graph and subgraph created through the Cosmo CLI (`wgc`) shows up in Studio: connected subgraphs, label matchers, composition status, the schema registry, and the schema checks run against it. Studio also holds the changelog for every schema change, a bundled GraphiQL playground for running queries against the graph, and the analytics dashboard: request volume over time and distributed tracing across the router and its subgraphs.
Put simply, Studio is the operating surface for a federated graph once composition and routing are working. It is not a separate product bolted onto Cosmo; it is how a platform team actually runs Cosmo day to day.
Studio vs Router vs Hub
Studio, Router, and Hub are three different WunderGraph surfaces. Here is how they split:
| Router | Studio | Hub | |
|---|---|---|---|
| Layer | Runtime | Operate and observe | Design and govern |
| Job | Plans and executes every query against the composed supergraph | Schema registry, schema checks, analytics, tracing, playground, org management | Where teams design schema changes and agree on them before anything ships |
| Who touches it | Nobody, directly; it just runs | Platform and backend teams operating the live graph | Frontend and backend teams designing the next change |
| Where it sits in the lifecycle | After a change ships | Registry-side, around publish and check time | Before a change ships |
Router is the hot path for every request; it has no UI because it does not need one. Studio is the console for what is already live: the registry, the checks that gate a publish, and the analytics that show how the live graph behaves. Hub is upstream of all of it, the place where a "dream query" becomes an agreed-on schema change before it ever reaches the registry.
Schema registry and explorer
The schema registry is the system of record for a federated graph’s schema. It shows the current composed schema, the individual schema of every subgraph that feeds it, and when each was last updated. Composition results live alongside it: every publish attempt, its errors if it failed, and which composed version the router is currently serving.
The changelog is the history behind that current state: every addition and deletion to the schema, in order, so a team can see exactly what changed and when without reconstructing it from CI logs.
Studio also shows which types and fields carry `@authenticated` or `@requiresScopes`, so access requirements are visible in the same place as the schema itself.
Schema explorer
The schema explorer is where a team actually reads the composed schema: every type, field, and directive, searchable with Cmd/Ctrl+K.
This is more than a static schema browser. Every field carries live usage data pulled from the field-usage analytics below, so a team can see who calls a field before deciding whether it is safe to change or remove. And every deprecated field is surfaced in one place, next to its usage.
Schema checks: validate changes before production
A schema check validates a proposed change before it ships, and Cosmo Studio runs four distinct checks against it, not one:
Composition errors
Whether the proposed subgraph schema composes with every other subgraph in the federated graph. A schema with composition errors can never be published, because it would produce a router config that cannot execute.
Breaking change detection
Whether the proposed schema removes or changes anything an existing client operation depends on.
Operation checks
Whether a detected breaking change actually affects real traffic. Cosmo Studio replays the change against observed production operations (sent to Cosmo Cloud by the router) and only fails the check if an active client would actually break.
Lint checks
Whether the proposed schema violates the namespace’s configured lint rules.
What operation checks change about "breaking"
Most schema-check tooling treats every breaking change the same way: it fails, full stop. Cosmo Studio’s operation checks ask a more useful question. If you propose a breaking change and no active client uses the affected field, the check passes, because nothing in production actually breaks.
By default, an operation check compares the proposed change against the last 7 days of client traffic; that lookback window is configurable per namespace from Policies, up to your plan’s limit. That is a separate setting from how long Cosmo Cloud retains data overall: telemetry is kept for 30 days and schema usage data for 90, depending on plan.
Run checks from CI with `wgc subgraph check`, or wire them into a PR-based workflow with the GitHub integration. When a breaking change is genuinely safe to ship anyway, teams with GitHub integration can override it manually rather than block the release.
Operations and overrides
The operations page is the two-panel view behind the check: a searchable, filterable list of every operation executed against the graph, sorted by request count, latency, or error rate, with a details panel showing which clients call it and which deprecated fields it touches. It is also where "what breaks after a schema change" gets answered concretely, because every check links back to the specific operations it affects.
When a check flags a breaking change you have already decided is safe, overrides let you ignore that specific change for that operation, or ignore the operation entirely, in future checks. Overrides only affect operation checks; they never suppress composition errors, breaking-change detection, or lint.
Subgraph check extensions
For teams that need checks Cosmo does not run out of the box, subgraph check extensions send an HMAC-signed webhook to a self-hosted endpoint every time a check runs, and let that endpoint return additional lint issues or fail the check outright. It is a way to enforce internal naming standards, notify another team of an upcoming breaking change, or hook schema checks into an existing internal pipeline, without waiting on WunderGraph to build the specific rule.
Analytics, tracing, and field usage
Studio’s analytics answer "how is this graph actually being used," at three levels of resolution: aggregate metrics, individual traces, and per-field usage.
Metrics and traces
Metrics gives the overview: request rate, P95 latency, and error rate over a selected time range, filterable by operation, client name, and client version. Traces lists every individual request, groupable by operation, client, or error message, with auto-refresh down to 10-second intervals for live debugging.
Clicking into a trace opens distributed tracing: the path a request took through the router and every subgraph it touched, with per-span attributes, service boundaries, and errors. This is where a slow federated request stops being a mystery and becomes a specific span you can point at.
Field usage and client identification
Schema field usage tracks every GraphQL type down to which clients call it, which operations use it, and how many requests it has served, first and last seen. It is the data layer behind the schema explorer’s usage indicators and the operation checks above; the same usage data answers "is this field safe to remove" in three different parts of the product.
None of that per-client breakdown works without client identification. Sending `GraphQL-Client-Name` and `GraphQL-Client-Version` headers (or the Apollo-compatible variants, for migration) with every request is what lets Studio attribute usage to a specific client instead of an anonymous blob of traffic.
Playground++
Studio bundles an enhanced GraphiQL, not a link out to a separate tool. Sending the `X-WG-TRACE` header on a request turns on Advanced Request Tracing: a visual execution plan showing timings, inputs, and outputs for every subgraph fetch, in either a tree or a waterfall view. It is the fastest way to see why a specific query is slow, without leaving the query editor.
Custom scripts extend the playground with pre-flight, pre-operation, and post-operation hooks, so teams can inject auth tokens, validate responses, or transform output for a given request lifecycle, with sensitive values kept in browser-scoped environment variables rather than in the script itself.
A shareable-link feature lets a team send a full playground session (operation, and optionally variables and headers) as a single URL, which turns "can you try this query" into a link instead of a screen-share.
Governance and schema hygiene
Design-time governance, agreeing on a change before it exists, is Hub’s job. Studio’s slice of governance is registry-side enforcement: the rules that run automatically every time a schema is checked or published.
Lint policy
Namespace-level lint rules enforce naming and structure conventions automatically on every check: camelCase fields, PascalCase types, no stray `Type` or `Input` prefixes or suffixes, alphabetically sorted fields and enum values, required descriptions on every type, and a required reason (and optionally a deletion date) on every `@deprecated` directive. Violations configured as errors fail the check; violations configured as warnings do not.
Graph pruning
The graph pruning linter flags schema hygiene issues that lint rules do not catch: fields nobody uses, fields deprecated but never removed, and fields deleted without a deprecation period first. A configurable grace period gives a newly modified field time before pruning rules start enforcing against it, and enterprise plans can set a custom usage-check window for the underlying traffic analysis.
Schema contracts
Schema contracts filter a source graph into a smaller, audience-specific graph using the `@tag` directive: tag a field `internal`, exclude `internal` from a contract, and that contract’s clients never see the field, while the full graph still resolves it correctly internally. It is the mechanism behind serving one API to internal teams and a stripped-down version to partners or the public, from one underlying schema.
Contracts recompose automatically whenever the source graph changes, and schema checks run against every contract the same way they run against the source, so a change that breaks a contract’s clients gets caught at the same time as one that breaks the main graph.
Graph documentation
A federated or subgraph can carry its own markdown documentation, published with the `--readme` flag in `wgc`, so ownership and context live next to the schema instead of in a wiki page nobody finds.
Access control and enterprise readiness
Role-based access control (RBAC) assigns permissions to groups rather than individuals, and groups can be linked to both organization members and API keys, so a CI system and a human can share the same access policy. Groups require RBAC to be enabled at the organization level, available starting on the Scale plan.
Single sign-on connects Cosmo to any OpenID Connect provider (Okta, Auth0, Keycloak, or others), auto-enrolling users with roles based on your configured mappings. An organization can connect more than one OIDC provider at once, and on the Enterprise plan can restrict specific namespaces to specific login methods, which matters for orgs that need to keep one namespace behind a stricter identity provider than the rest. SCIM layers on top for automated user provisioning and deprovisioning from the identity provider directly.
API keys authorize `wgc` for CI and local CLI use, scoped to a group and an expiry. The audit log records every action taken across the organization, by a user or by an API key, so security and compliance reviews do not depend on institutional memory. Sessions renew every 8 hours of activity, expire after 72 hours idle, and hit a hard 14-day maximum lifetime regardless of activity; disconnecting SSO immediately downgrades every SSO-authenticated user to the viewer role as a safety measure.
Alerts, webhooks, and fleet operations
Studio notifies a team when a federated graph’s schema changes, through Slack integration or HMAC-signed webhooks, so schema changes surface where a team already works instead of requiring someone to check Studio directly.
Cluster management gives a live view of every running router instance (router 0.66.1 or later): version, cluster, uptime, and CPU and memory trends, reported through the router’s OpenTelemetry instrumentation. It answers "which composition is actually live, on which instances" without SSHing anywhere.
Open source and deployment
WunderGraph Cosmo, including the schema registry, composition checks, analytics engine, and distributed tracing that power Studio, is fully open source under Apache 2.0. Studio is the console for that stack: run it against the managed Cosmo Cloud, or point it at a fully self-hosted deployment when data residency or compliance requirements mean the graph cannot leave your own infrastructure.
Who uses Cosmo Studio?
Every team running a federated graph on WunderGraph Cosmo operates it through Studio: the registry, the checks, and the analytics below are not optional add-ons, they are how these teams run their graph day to day.
A few examples from production:
Tens of ms faster at peak
"Cosmo presents all the relevant stats – how many queries run, their response times, and key performance metrics – making it much easier to communicate what’s happening under the hood." Advanced Request Tracing and Studio’s real-time checks cut debugging time after migrating off a home-baked federation setup.
Read case study
Schema checks catch breaks in CI
"The checks that Cosmo does is a super great thing to have. I’m referring to actual checks on the real traffic." K Health self-hosts the router for HIPAA compliance while Studio’s operation checks catch breaking changes before they ship.
Read case study
86% CPU reduction
Cut compute from 600 to 80 vCPUs and reduced monthly infrastructure cost by roughly 30% after consolidating BFF layers onto a federated graph, with Studio’s analytics giving the team shared visibility into the result.
Read case study
Migration in about one day
Migrated from Apollo to Cosmo in roughly a day. While debugging complex queries during the move, the team found errors in their schema that their previous provider never caught or reported.
Read case studyFrequently asked questions
Learn more about Cosmo Studio
Getting started
Schema registry and checks
Analytics and tracing
Access control and security
Start using Cosmo Studio
If your team is running a federated graph on Cosmo, Studio is the console you already need: a schema registry, checks that catch breaking changes before production, and analytics that show how the graph actually behaves. It is open-source, free to start, and available self-hosted or managed.
Published August 11, 2026 · WunderGraph
