What if your server mutations automatically refreshed every query that cared?

Tag-based cache invalidation for TanStack Start, Query & Router. One invalidateTag() on the server. Every subscribed query updates. Every tab. Automatically.

$pnpm add @tanstack-tools/query-tags

See it in action How it works GitHub →

Manual cache invalidation doesn't scale

Every mutation must know about every query it affects. Add a query, update every mutation. Forget one? Stale data. Tags flip this: queries declare what data they need, and the server invalidates by meaning — not by key.

See the full comparison →

Try it now

30-second demo

Add a todo and watch both query panels update automatically. No invalidateQueries anywhere in the mutation code.

Live Demo— try it now

Get groceries

Buy a new phone

Finish the project

Todo Count

todos.list

Summary

3 total

todos.summary

Add a todo and watch both panels flash green simultaneously — zero manual invalidation

How it works

Three steps to automatic invalidation

Define tags

defineTags({
  todos: {
    list: () => ["todos"],
    byId: (id) => ["todo", id],
  }
})

Create a typed tag tree. Full autocomplete, compile-time safety.

Tag your queries

useQuery({
  queryKey: ['todos'],
  queryFn: fetchTodos,
  meta: { tags: [appTags.todos.list()] }
})

One line in meta. Or use withTags() for zero-boilerplate.

Invalidate from server

await tagInvalidation.invalidateTags({
  tags: [appTags.todos()]
})
// Every tagged query refreshes.

Server decides. Clients react. SSE delivers. Done.

Comparison

query-tags vs alternatives

How does it stack up against rolling your own or using Next.js revalidateTag?

Feature	Manual	Next.js revalidateTag	query-tags
Type-safe tag references	✕	✕	✓
Multi-tab sync	✕	✕	✓
Hierarchical invalidation	✕	✕	✓
Per-tenant scoping	✕	✕	✓
Route loader refresh	✕	✓	✓
Works with TanStack Query	✓	✕	✓
No framework lock-in	✓	✕	~
Debug tooling	~	✕	✓