# GlassFlow documentation

> GlassFlow makes two products for teams running AI agents. Tares is the
> open-source platform for always-on AI agents: a software factory for Claude
> Code that takes your projects from tickets to merged pull requests, and an
> AI SRE that watches your systems. Rius is OpenTelemetry-native agent
> observability: it traces every LLM call, tool call and agent step, with
> cost per call, alerts, and Claude Code, Codex and Cursor session tracing,
> plus an MCP server for querying your telemetry.

Every page below is fetchable as raw markdown at the listed .md URL.
A single-file version (without the generated API reference) is at https://docs.glassflow.ai/llms-full.txt.

## Software factory for Claude Code

- [Build a software factory with Claude Code](https://docs.glassflow.ai/tares/software-factory/get-started.md): Tares runs a crew of Claude Code sessions (an orchestrator, a reviewer and builders) in the background on your machine. You sign in with `tares login` (or run Tares yourself with `tares up`), start the crew with `tares factory crew up`, and plan a project with `/tares:spec` (or `tares factory spec`). The crew builds the tickets into pull requests merged on main.
- [Run autonomous, self-running Claude Code sessions](https://docs.glassflow.ai/tares/software-factory/autonomous-claude-code-sessions.md): Tares runs a software factory for Claude Code: a crew of Claude Code sessions that run in the background on your machine. A watch brings back any session that stops, the orchestrator checks for work on a schedule, and builders merge reviewed pull requests, so the work continues while you are away. The crew asks you before the decisions that are yours.
- [Software factory for Claude Code compared](https://docs.glassflow.ai/tares/software-factory/comparison.md): A software factory for Claude Code built with Tares fits when you want a crew of sessions that keeps working across restarts, and a record of the plan, the reviews and your decisions that outlives every session. If you only need help inside one session, subagents or a single worktree are lighter, and if you want an agent you hand a whole task to, Devin or OpenHands are closer to that. This page compares them on the same seven questions.

## AI SRE

- [Build an AI SRE](https://docs.glassflow.ai/tares/guides/ai-sre.md): This guide builds an incident-response agent on Tares, end to end. By the last step you have a working AI SRE: when a service misbehaves, a trigger wakes an agent with one correlated timeline of metrics, logs, and alerts; the agent names the root cause and writes its conclusion back where the next investigation will find it. You also have an MCP client connected, so you can investigate the same evidence interactively.
- [Use AI to monitor your systems](https://docs.glassflow.ai/tares/guides/ai-monitoring.md): You connect your logs, metrics, alerts and deploys to Tares as sources, and Tares merges them into one timeline per service. When an alert fires, a trigger wakes a built-in Tares agent, or your own agent service over a webhook, and the agent writes its diagnosis onto the service's timeline before anyone opens a dashboard. Claude Code, Cursor and any other MCP client read the same timeline when you want to investigate yourself.
- [AI SRE compared: Tares, vendor AI, and one MCP server per tool](https://docs.glassflow.ai/tares/guides/ai-sre-comparison.md): Tares fits when your signals live in several tools, you want to keep the alerting you already run, and you want an agent woken the moment an alert fires. One read returns the correlated timeline of a service across every source, a trigger wakes the agent, and the agent writes its finding back where the next investigation starts. Tares runs on your machine or your server, in one local DuckDB file.

## Agent observability

- [Monitor AI agents in production](https://docs.glassflow.ai/rius/guides/monitor-ai-agents.md): Install the Rius SDK and add two lines of instrumentation: every LLM call is traced, with model, tokens, and cost per call computed server-side. Wrap your tools and agent steps with `observe`, or use a supported framework, and they appear as tool and agent spans in the same trace. Rius alerts you when the same error recurs across runs or an agent calls the same tool in a loop, and its MCP server lets your coding agent query the traces in plain language.
- [Trace LLM calls with OpenTelemetry](https://docs.glassflow.ai/rius/guides/trace-llm-calls-opentelemetry.md): Rius is OpenTelemetry-native, so you trace LLM calls either with the Rius SDK, which auto-instruments OpenAI, Anthropic, LangChain and more, or by pointing any existing OpenTelemetry, OpenLLMetry or OpenInference exporter, or an OpenTelemetry Collector, at the Rius OTLP endpoint. Either way, each instrumented LLM call arrives as a generation span with the model, token usage and messages, and Rius computes the cost server-side. What a span carries depends on the attributes your instrumentation emits.
- [Track LLM and agent cost](https://docs.glassflow.ai/rius/guides/track-llm-cost.md): Rius prices every LLM span at ingest from the model and its token counts, including prompt-cache read and write tokens, so each call carries its own cost. It then rolls that cost up per trace, per agent, per end user, and per workspace, and you can alert on it or ask for it in plain language over MCP. You send the model name and token usage your instrumentation already records; you never send a price or a cost, and a cost attribute you do send is ignored.
- [Migrate to Rius](https://docs.glassflow.ai/rius/guides/migrate.md): Rius takes OpenTelemetry traces, so migrating to it is usually a routing change rather than a re-instrumentation. How much you change depends on how your code is instrumented today.
- [Migrate from Arize Phoenix to Rius](https://docs.glassflow.ai/rius/guides/migrate/phoenix.md): Phoenix is built on OpenTelemetry and OpenInference, and Rius understands OpenInference spans. Migrating from Phoenix is therefore a routing change: the OpenInference instrumentors you already run keep producing the same spans, and you point their exporter at Rius instead of at your Phoenix collector. This guide maps the concepts, walks the two migration paths, and ends with a cutover checklist.
- [Migrate from Helicone to Rius](https://docs.glassflow.ai/rius/guides/migrate/helicone.md): Helicone and Rius capture LLM calls in different ways. Helicone is mainly a proxy: your client sends every request through a Helicone base URL, and Helicone logs it on the way through, with features configured by `Helicone-*` request headers. Rius is OpenTelemetry-based: the Rius SDK instruments your LLM client inside your process and exports spans (one record per step, such as an LLM call), so nothing sits between your code and the provider.
- [Migrate from Langfuse to Rius](https://docs.glassflow.ai/rius/guides/migrate/langfuse.md): Langfuse and Rius are both OpenTelemetry-based, which makes migrating from Langfuse mostly a routing change: your traces are already spans, and in most setups Rius can receive them without touching your instrumentation. This guide maps the concepts, walks the two migration paths, and ends with a cutover checklist. Run both backends in parallel during the evaluation; nothing here requires a hard switch.
- [Migrate from LangSmith to Rius](https://docs.glassflow.ai/rius/guides/migrate/langsmith.md): LangSmith traces LangChain and LangGraph apps through LangChain's callback system, and any other code through `@traceable` and its client wrappers. Rius takes OpenTelemetry traces, and the Rius SDK hooks the same LangChain callbacks, so for most apps the migration is a dependency and a few lines of setup, not a rewrite. This guide maps the concepts, walks the migration paths, and ends with a cutover checklist. Run both backends in parallel during the evaluation; nothing here requires a hard switch.
- [Migrate from Traceloop to Rius](https://docs.glassflow.ai/rius/guides/migrate/traceloop.md): Traceloop's SDK is OpenLLMetry, and OpenLLMetry is plain OpenTelemetry: it exports OTLP to whichever endpoint you give it. That makes migrating from Traceloop to Rius a configuration change. Keep your OpenLLMetry instrumentation, decorators included, and point its exporter at Rius: your agents, tools and LLM calls show up as such. This guide maps the concepts, walks the two migration paths, and ends with a cutover checklist. Run both backends in parallel during the evaluation; nothing here requires a hard switch.

## Coding-agent observability

- [Coding agents](https://docs.glassflow.ai/rius/guides/coding-agents.md): Rius traces the coding agents your team already uses. Each session becomes one trace with its model calls and tool calls, so you can see what an agent did, where it failed, and, for most agents, what it cost. Claude Code, Codex, and Cursor each install the same Rius plugin. OpenHands needs no plugin: its SDK already sends OpenTelemetry, the open standard Rius takes in.
- [Track Claude Code usage and cost across a team](https://docs.glassflow.ai/rius/guides/coding-agents/track-claude-code-usage.md): Install the `rius-coding-agents` plugin in Claude Code, sign in to a shared Rius workspace, and turn tracing on for the repos you want to watch. Every session then streams to Rius as an OpenTelemetry trace with its model calls, tokens, cost, tool calls, and subagents, per developer and per session. Prompts and replies are sent only from folders where a developer turns content on. The same plugin covers Codex and Cursor in beta, and OpenHands sends to the same workspace over OpenTelemetry.
- [Claude Code plugin](https://docs.glassflow.ai/rius/guides/coding-agents/claude-code-plugin.md): The Rius plugin for Claude Code turns each Claude Code session into a trace in Rius. The trace holds your prompts, every model call with its tokens and cost, every tool call, and the subagents Claude Code started, laid out as a waterfall. The plugin also connects the Rius MCP server, so you can ask Claude about those sessions without leaving the terminal.
- [Codex (beta)](https://docs.glassflow.ai/rius/guides/coding-agents/codex.md): The Rius plugin traces Codex CLI sessions, one trace in Rius per session, with your prompts, every model call with its tokens, every tool call, and the subagents Codex started. The plugin also brings the Rius MCP server, so you can ask Codex about those sessions.
- [Cursor (beta)](https://docs.glassflow.ai/rius/guides/coding-agents/cursor.md): The Rius plugin for Cursor turns each Cursor agent chat into a trace in Rius: your prompts, the agent's answers, every tool call, and the subagents it started. It works with the agent in the Cursor editor and with `cursor-agent` in the terminal. The plugin also brings the Rius MCP server, so you can ask Cursor about those chats.
- [OpenHands](https://docs.glassflow.ai/rius/guides/coding-agents/openhands.md): Rius traces every OpenHands conversation over OTLP, with no code changes. OpenHands is an open-source platform for AI agents that write code, run commands and edit files. Its Software Agent SDK traces every conversation with OpenTelemetry, through the open-source `lmnr` library. With no Laminar key set, that library sends plain OTLP to whatever endpoint you configure, so pointing it at Rius needs no extra package.

## Docs

- [GlassFlow® documentation](https://docs.glassflow.ai/index.md): GlassFlow is the observability and context layer for teams running AI agents in production. Two products sit under the GlassFlow umbrella. Pick one to get started.
- [Rius](https://docs.glassflow.ai/rius.md): _Agent observability: every LLM call, tool invocation, and agent step, traced end to end._
- [Quickstart](https://docs.glassflow.ai/rius/quickstart.md): From nothing to a visible trace in one sitting. Rius needs three things: an account, an API key, and two lines of instrumentation.
- [Guides](https://docs.glassflow.ai/rius/guides.md): Task-oriented walkthroughs. Where the SDK and interoperability sections document one surface at a time, a guide cuts across them to get a specific job done end to end.
- [Coding agents](https://docs.glassflow.ai/rius/guides/coding-agents.md): Rius traces the coding agents your team already uses. Each session becomes one trace with its model calls and tool calls, so you can see what an agent did, where it failed, and, for most agents, what it cost. Claude Code, Codex, and Cursor each install the same Rius plugin. OpenHands needs no plugin: its SDK already sends OpenTelemetry, the open standard Rius takes in.
- [Claude Code plugin](https://docs.glassflow.ai/rius/guides/coding-agents/claude-code-plugin.md): The Rius plugin for Claude Code turns each Claude Code session into a trace in Rius. The trace holds your prompts, every model call with its tokens and cost, every tool call, and the subagents Claude Code started, laid out as a waterfall. The plugin also connects the Rius MCP server, so you can ask Claude about those sessions without leaving the terminal.
- [Track Claude Code usage and cost across a team](https://docs.glassflow.ai/rius/guides/coding-agents/track-claude-code-usage.md): Install the `rius-coding-agents` plugin in Claude Code, sign in to a shared Rius workspace, and turn tracing on for the repos you want to watch. Every session then streams to Rius as an OpenTelemetry trace with its model calls, tokens, cost, tool calls, and subagents, per developer and per session. Prompts and replies are sent only from folders where a developer turns content on. The same plugin covers Codex and Cursor in beta, and OpenHands sends to the same workspace over OpenTelemetry.
- [Codex (beta)](https://docs.glassflow.ai/rius/guides/coding-agents/codex.md): The Rius plugin traces Codex CLI sessions, one trace in Rius per session, with your prompts, every model call with its tokens, every tool call, and the subagents Codex started. The plugin also brings the Rius MCP server, so you can ask Codex about those sessions.
- [Cursor (beta)](https://docs.glassflow.ai/rius/guides/coding-agents/cursor.md): The Rius plugin for Cursor turns each Cursor agent chat into a trace in Rius: your prompts, the agent's answers, every tool call, and the subagents it started. It works with the agent in the Cursor editor and with `cursor-agent` in the terminal. The plugin also brings the Rius MCP server, so you can ask Cursor about those chats.
- [OpenHands](https://docs.glassflow.ai/rius/guides/coding-agents/openhands.md): Rius traces every OpenHands conversation over OTLP, with no code changes. OpenHands is an open-source platform for AI agents that write code, run commands and edit files. Its Software Agent SDK traces every conversation with OpenTelemetry, through the open-source `lmnr` library. With no Laminar key set, that library sends plain OTLP to whatever endpoint you configure, so pointing it at Rius needs no extra package.
- [Migrate to Rius](https://docs.glassflow.ai/rius/guides/migrate.md): Rius takes OpenTelemetry traces, so migrating to it is usually a routing change rather than a re-instrumentation. How much you change depends on how your code is instrumented today.
- [Migrate from Helicone to Rius](https://docs.glassflow.ai/rius/guides/migrate/helicone.md): Helicone and Rius capture LLM calls in different ways. Helicone is mainly a proxy: your client sends every request through a Helicone base URL, and Helicone logs it on the way through, with features configured by `Helicone-*` request headers. Rius is OpenTelemetry-based: the Rius SDK instruments your LLM client inside your process and exports spans (one record per step, such as an LLM call), so nothing sits between your code and the provider.
- [Migrate from Langfuse to Rius](https://docs.glassflow.ai/rius/guides/migrate/langfuse.md): Langfuse and Rius are both OpenTelemetry-based, which makes migrating from Langfuse mostly a routing change: your traces are already spans, and in most setups Rius can receive them without touching your instrumentation. This guide maps the concepts, walks the two migration paths, and ends with a cutover checklist. Run both backends in parallel during the evaluation; nothing here requires a hard switch.
- [Migrate from LangSmith to Rius](https://docs.glassflow.ai/rius/guides/migrate/langsmith.md): LangSmith traces LangChain and LangGraph apps through LangChain's callback system, and any other code through `@traceable` and its client wrappers. Rius takes OpenTelemetry traces, and the Rius SDK hooks the same LangChain callbacks, so for most apps the migration is a dependency and a few lines of setup, not a rewrite. This guide maps the concepts, walks the migration paths, and ends with a cutover checklist. Run both backends in parallel during the evaluation; nothing here requires a hard switch.
- [Migrate from Arize Phoenix to Rius](https://docs.glassflow.ai/rius/guides/migrate/phoenix.md): Phoenix is built on OpenTelemetry and OpenInference, and Rius understands OpenInference spans. Migrating from Phoenix is therefore a routing change: the OpenInference instrumentors you already run keep producing the same spans, and you point their exporter at Rius instead of at your Phoenix collector. This guide maps the concepts, walks the two migration paths, and ends with a cutover checklist.
- [Migrate from Traceloop to Rius](https://docs.glassflow.ai/rius/guides/migrate/traceloop.md): Traceloop's SDK is OpenLLMetry, and OpenLLMetry is plain OpenTelemetry: it exports OTLP to whichever endpoint you give it. That makes migrating from Traceloop to Rius a configuration change. Keep your OpenLLMetry instrumentation, decorators included, and point its exporter at Rius: your agents, tools and LLM calls show up as such. This guide maps the concepts, walks the two migration paths, and ends with a cutover checklist. Run both backends in parallel during the evaluation; nothing here requires a hard switch.
- [Monitor AI agents in production](https://docs.glassflow.ai/rius/guides/monitor-ai-agents.md): Install the Rius SDK and add two lines of instrumentation: every LLM call is traced, with model, tokens, and cost per call computed server-side. Wrap your tools and agent steps with `observe`, or use a supported framework, and they appear as tool and agent spans in the same trace. Rius alerts you when the same error recurs across runs or an agent calls the same tool in a loop, and its MCP server lets your coding agent query the traces in plain language.
- [Multi-tenant agent observability: one workspace per customer](https://docs.glassflow.ai/rius/guides/multi-tenant-observability.md): You build agents and sell them: an agent product, an agency running agents per client, a platform with agent features. Each of your customers needs their telemetry isolated from every other customer's, and you need to see cost and health per customer. With Rius, you do that by treating each customer as its own workspace: the security and observability boundary for multi-tenant deployments. This guide is the opinionated way to set that up.
- [Trace LLM calls with OpenTelemetry](https://docs.glassflow.ai/rius/guides/trace-llm-calls-opentelemetry.md): Rius is OpenTelemetry-native, so you trace LLM calls either with the Rius SDK, which auto-instruments OpenAI, Anthropic, LangChain and more, or by pointing any existing OpenTelemetry, OpenLLMetry or OpenInference exporter, or an OpenTelemetry Collector, at the Rius OTLP endpoint. Either way, each instrumented LLM call arrives as a generation span with the model, token usage and messages, and Rius computes the cost server-side. What a span carries depends on the attributes your instrumentation emits.
- [Track LLM and agent cost](https://docs.glassflow.ai/rius/guides/track-llm-cost.md): Rius prices every LLM span at ingest from the model and its token counts, including prompt-cache read and write tokens, so each call carries its own cost. It then rolls that cost up per trace, per agent, per end user, and per workspace, and you can alert on it or ask for it in plain language over MCP. You send the model name and token usage your instrumentation already records; you never send a price or a cost, and a cost attribute you do send is ignored.
- [Concepts](https://docs.glassflow.ai/rius/concepts.md): The Rius data model in one page: what a trace is, what spans and generations are made of, and which parts the platform computes for you.
- [SDK](https://docs.glassflow.ai/rius/sdk.md): The Rius SDK is OpenTelemetry-native tracing for AI agents: non-blocking by design, privacy-aware at export time, and speaking the OpenTelemetry GenAI conventions.
- [Installation and configuration](https://docs.glassflow.ai/rius/sdk/installation.md): The Rius SDK for Python is published as `glassflow-rius` and imported as `rius`; it requires Python 3.10 or newer. The TypeScript SDK is published as `@glassflow-ai/rius` and requires Node 18 or newer.
- [Tracing your code](https://docs.glassflow.ai/rius/sdk/tracing.md): The Rius SDK gives you three levels of control: `observe` for whole functions, generic spans for arbitrary steps, and generations for LLM calls.
- [Integrations](https://docs.glassflow.ai/rius/sdk/integrations.md): Rius integrates with the client libraries, agent frameworks, and protocols agents are built on: model calls arrive as generations with tokens and cost, and run structure arrives from the framework's own spans or a thin layer of `observe` wrappers. Each integration's page covers setup, what lands in the trace, and the blind spots.
- [OpenAI](https://docs.glassflow.ai/rius/sdk/integrations/openai.md): Trace every OpenAI client call with Rius without touching your call sites.
- [Anthropic](https://docs.glassflow.ai/rius/sdk/integrations/anthropic.md): Trace every Anthropic client call with Rius without touching your call sites.
- [LangChain](https://docs.glassflow.ai/rius/sdk/integrations/langchain.md): Trace LangChain (and LangGraph) runs with Rius: chains, tools, retrievers, and model calls arrive as a nested trace mirroring your graph.
- [LlamaIndex](https://docs.glassflow.ai/rius/sdk/integrations/llama-index.md): Trace LlamaIndex pipelines with Rius: query engines, retrievers, embeddings, and the model calls inside them.
- [LiteLLM](https://docs.glassflow.ai/rius/sdk/integrations/litellm.md): Trace calls routed through LiteLLM with Rius: one integration covers every provider behind the router.
- [MCP](https://docs.glassflow.ai/rius/sdk/integrations/mcp.md): Trace your agent's outgoing MCP tool calls with Rius, and connect them to the server's own traces where the protocol allows it.
- [Vercel AI SDK](https://docs.glassflow.ai/rius/sdk/integrations/vercel-ai.md): Trace Vercel AI SDK calls in Rius, with prompts, responses, models, tool definitions, and token usage.
- [OpenAI Agents SDK](https://docs.glassflow.ai/rius/sdk/integrations/openai-agents.md): Trace agents built with the OpenAI Agents SDK with Rius: every model call the framework makes arrives as a generation with tokens and cost, and a thin layer of `observe` wrappers gives the run and its tools their shape. This guide covers the Python SDK; the runnable example behind it lives in agent-observability-examples.
- [Pydantic AI](https://docs.glassflow.ai/rius/sdk/integrations/pydantic-ai.md): Trace agents built with Pydantic AI with Rius: the framework is OpenTelemetry-native and emits its own spans for agent runs, model requests, and tool calls, so the whole structure arrives with no wrappers at all. This guide covers the Python framework; the runnable example behind it lives in agent-observability-examples.
- [CrewAI](https://docs.glassflow.ai/rius/sdk/integrations/crewai.md): Trace crews built with CrewAI with Rius: the model calls the framework makes arrive as generations with tokens and cost, and `observe` wrappers give the run and its tools their shape. This guide covers the Python framework; the runnable example behind it lives in agent-observability-examples.
- [AutoGen](https://docs.glassflow.ai/rius/sdk/integrations/autogen.md): Trace agents built with AutoGen (AgentChat) with Rius: the framework emits its own OpenTelemetry spans for agents and tools, and the `openai` integration adds the generations with tokens and cost. This guide covers the Python framework; the runnable example behind it lives in agent-observability-examples.
- [Claude Agent SDK](https://docs.glassflow.ai/rius/sdk/integrations/claude-agent-sdk.md): Trace agents built with the Claude Agent SDK with Rius. This framework is different from the others on this page's siblings: it drives the Claude Code runtime in a separate process, so no model client runs in your process and auto-instrumentation has nothing to hook. Coverage is manual, and still gives you per-task traces with tokens and cost. The runnable example behind this guide lives in agent-observability-examples.
- [Auto-instrumentation](https://docs.glassflow.ai/rius/sdk/auto-instrumentation.md)
- [Advanced features](https://docs.glassflow.ai/rius/sdk/advanced.md): Volume and privacy controls for production deployments of the Rius SDK: head sampling to reduce trace volume, and two independent controls over what content leaves your process. All of them are `init()` arguments; none require code changes in your agent.
- [Reliability](https://docs.glassflow.ai/rius/sdk/reliability.md): The design promise of the Rius SDK: tracing never blocks and never breaks your application. This page explains the machinery behind that and the knobs you can tune.
- [Troubleshooting](https://docs.glassflow.ai/rius/sdk/troubleshooting.md): Symptoms first, causes second. Everything here assumes a current SDK: `glassflow-rius` 1.1.1 or newer for Python, `@glassflow-ai/rius` 1.2.0 or newer for TypeScript. Older releases behave the same on the basics, but some log lines quoted below were worded differently, and some fixes noted below need these versions.
- [Upgrading to 1.0](https://docs.glassflow.ai/rius/sdk/upgrading.md): Version 1.0.0 of both SDKs, `glassflow-rius` for Python and `@glassflow-ai/rius` for TypeScript, finishes the move from the GlassFlow name to Rius and brings span names in line with the OpenTelemetry GenAI conventions. The package names, the Python import (`rius`), and the supported runtimes (Python 3.10+, Node 18+) are unchanged.
- [Python reference](https://docs.glassflow.ai/rius/sdk/reference/python.md): Generated from the `glassflow-rius` 1.3.1 docstrings, covering the Python SDK's public API surface module by module. Wording fixes happen upstream in the SDK repository, never here.
- [TypeScript reference](https://docs.glassflow.ai/rius/sdk/reference/typescript.md): Generated from the `@glassflow-ai/rius` 1.4.1 type declarations, covering the TypeScript SDK's public API surface. Wording fixes happen upstream in the SDK repository, never here.
- [Platform](https://docs.glassflow.ai/rius/platform.md): Working with the Rius console at console.rius-glassflow.com, task by task:
- [Exploring traces](https://docs.glassflow.ai/rius/platform/exploring-traces.md): The Traces page shows every run your agents produce, from the list view down to a single span's attributes. This page walks through finding a trace, reading its status, and inspecting it in the tree and map views.
- [Agents](https://docs.glassflow.ai/rius/platform/agents.md): The Agents page lists every agent sending traces to your workspace. Open an agent to see how it is doing: whether its processes are alive, its failed traces and cost, how full its context window gets, and whether the latest version changed anything.
- [Users](https://docs.glassflow.ai/rius/platform/users.md): The Users page is a register of the end users your agents serve: the people or accounts a request was made for, not the members of your Rius organization. Use it to see who is hitting failures, who drives cost, and what one user's recent runs looked like.
- [Alerts](https://docs.glassflow.ai/rius/platform/alerts.md): Alerts watch your workspace and notify you when something needs attention: a recurring error, a run that swallowed an error, an agent stuck in a loop, or a metric crossing a threshold you set. You configure what to watch and where to deliver; Rius evaluates continuously and records every firing until you acknowledge it.
- [Pre-defined alerts](https://docs.glassflow.ai/rius/platform/alerts/pre-defined.md): Rius ships curated detectors for the failure shapes agents actually exhibit. Each has a details page with a plain-language description of exactly when it fires, a small set of configuration knobs, its attached channels, and its firing history. You cannot delete a pre-defined alert, only disable it. To point one at part of your workspace with its own settings, see Narrow a pre-defined alert.
- [Custom alerts](https://docs.glassflow.ai/rius/platform/alerts/custom.md): Custom alerts put a threshold on workspace metrics, optionally scoped by filters. A custom alert is one or more rules, always combined with AND, all evaluated over one shared rolling window. The builder shows a plain-language preview of exactly when the alert will fire, and that sentence becomes the alert's description on its details page.
- [Distribution channels](https://docs.glassflow.ai/rius/platform/alerts/channels.md): Channels are the destinations firings get delivered to. You define them once per workspace on the Alerts page, then attach any of them to any alert from that alert's details page (the Delivers to section). While an alert is enabled, every firing goes to each of its attached, enabled channels.
- [Usage and cost](https://docs.glassflow.ai/rius/platform/monitoring.md): Home is the Rius workspace's summary page: how your agents did this period, in volume, cost, tokens, and errors.
- [Settings](https://docs.glassflow.ai/rius/platform/settings.md): Everything under the console's Settings page, one section per tab: the workspace itself, its API keys, the organization and its members, the shared views that leave it, the attributes declared for search, the organization's plan, and where the workspace's data is held.
- [Plans and billing](https://docs.glassflow.ai/rius/platform/billing.md): Billing is per organization. A new organization starts on a free trial and subscribes to a plan from Settings → Plan & usage, through Stripe Checkout. Only organization admins manage billing; members see "Only organization admins can manage billing."
- [MCP](https://docs.glassflow.ai/rius/mcp.md): Connect Claude, Cursor, and other AI clients to Rius and query your agent's traces from where you already work. Ask "what was my agents' error rate yesterday?" in plain language, and your client answers from your real telemetry: trace lists, cost and token summaries, and full span waterfalls.
- [Usage and access](https://docs.glassflow.ai/rius/mcp/usage-and-access.md): The console's MCP page shows everything that calls the Rius MCP server: your coding agents, scripts, CI jobs, and teammates in their editors. Use it to see who is connected, which tools they call, whether the calls come back with anything useful, and what each key is allowed to do.
- [Tool reference](https://docs.glassflow.ai/rius/mcp/tools.md): Every tool the Rius MCP server exposes, with arguments and example invocations. All tools return Markdown, which your client renders as tables and summaries. Everything is read-only with one exception, `create_api_key`, which is admin-gated.
- [Example workflows](https://docs.glassflow.ai/rius/mcp/workflows.md): Four investigation patterns you can run entirely from your AI client once the Rius MCP server is connected. Each starts from a plain-language prompt; the tool sequence shows what your client does with it.
- [Interoperability](https://docs.glassflow.ai/rius/interoperability.md): Rius is convention-native OpenTelemetry: you can send traces without the SDK, from OpenLLMetry, OpenInference, vanilla OTel SDKs, or any OTLP-speaking collector.
- [Span attribute reference](https://docs.glassflow.ai/rius/interoperability/attributes.md): The wire format Rius reads. If you emit spans from anything other than the SDKs (a vanilla OpenTelemetry SDK, a collector pipeline, another language), this page tells you which attributes to set so your traces get the same analytics as SDK-emitted ones.
- [Attribute registry](https://docs.glassflow.ai/rius/interoperability/registry.md): Every attribute key, event and value the Rius SDKs and the Rius platform agree on, generated from the Weaver registry in rius-semconv. One page per namespace Rius defines keys in, then the keys it takes from elsewhere. For which attributes to set and what the platform does with them, start from the span attribute reference.
- [`cc` namespace](https://docs.glassflow.ai/rius/interoperability/registry/cc.md): `cc` is not a Rius namespace. Rius defines only the keys below in it, each under a documented namespace exception; every other `cc` key Rius uses is upstream's (see upstream keys).
- [`codex` namespace](https://docs.glassflow.ai/rius/interoperability/registry/codex.md): `codex` is not a Rius namespace. Rius defines only the keys below in it, each under a documented namespace exception; every other `codex` key Rius uses is upstream's (see upstream keys).
- [`cursor` namespace](https://docs.glassflow.ai/rius/interoperability/registry/cursor.md): `cursor` is not a Rius namespace. Rius defines only the keys below in it, each under a documented namespace exception; every other `cursor` key Rius uses is upstream's (see upstream keys).
- [`gen_ai` namespace](https://docs.glassflow.ai/rius/interoperability/registry/gen-ai.md): Rius no longer defines keys in `gen_ai`. The deprecated keys below are kept so a reader of older spans can tell what they were.
- [`mcp` namespace](https://docs.glassflow.ai/rius/interoperability/registry/mcp.md): Rius no longer defines keys in `mcp`. The deprecated keys below are kept so a reader of older spans can tell what they were.
- [`rius` namespace](https://docs.glassflow.ai/rius/interoperability/registry/rius.md): The `rius` namespace is the one this registry owns: a fact no OpenTelemetry convention names gets a key here.
- [Upstream keys](https://docs.glassflow.ai/rius/interoperability/registry/upstream.md): The OpenTelemetry keys the Rius SDKs emit or read, referenced from the registries this one pins: core semantic conventions `v1.44.0` and the GenAI semantic conventions at `547934a`. Their definitions, types and stability are upstream's: each key links to it. What is ours is the requirement level Rius gives the key and the note on how Rius uses it.
- [Keys other producers write](https://docs.glassflow.ai/rius/interoperability/registry/normalizer-inputs.md): Keys from other instrumentations that the Rius SDKs emit or the Rius normalizers read. No upstream OpenTelemetry registry defines them, so this registry describes them as their producers write them, with the decision the normalizers take on each usage key. Their spellings under `gen_ai.*` are not defined here, because only OpenTelemetry may define that namespace; the full usage-key table, those included, is out/docs/usage-keys.md.
- [Vanilla OpenTelemetry SDKs](https://docs.glassflow.ai/rius/interoperability/otel-sdks.md): Any language with an OpenTelemetry SDK can send traces to Rius today: the ingest endpoint is standard OTLP/HTTP. This is the path for languages without a native SDK (everything except Python and TypeScript).
- [OpenLLMetry](https://docs.glassflow.ai/rius/interoperability/openllmetry.md): If your application is already instrumented with OpenLLMetry (Traceloop's SDK), point its exporter at Rius and your existing traces flow in; no re-instrumentation needed.
- [OpenInference](https://docs.glassflow.ai/rius/interoperability/openinference.md): OpenInference instrumentors (the ones behind Arize Phoenix) work with Rius directly: they emit standard OpenTelemetry spans, so they only need an OTLP exporter pointed at the ingest endpoint.
- [OpenTelemetry Collector](https://docs.glassflow.ai/rius/interoperability/collector.md): Route traces to Rius through an OpenTelemetry Collector when you want a single egress point, local buffering, or to fan the same traces out to more than one backend.
- [Release notes](https://docs.glassflow.ai/rius/release-notes.md): Notable changes to Rius, newest first. The hosted platform updates in place, so a platform release needs nothing from you unless its notes say so. SDK releases are yours to install; each SDK's full changelog is on GitHub (Python, TypeScript).
- [Introduction](https://docs.glassflow.ai/tares.md): Tares is the open-source platform for always-on AI agents. Chat agents wait for a prompt. Tares agents wait for an event: every event from your systems lands on one timeline per thing, a trigger wakes an agent the moment it matters, and the finding it writes back is there for the next reader.
- [Quickstart](https://docs.glassflow.ai/tares/quickstart.md): If you are a coding assistant, start with AI resources.
- [Concepts](https://docs.glassflow.ai/tares/concepts.md): Everything in Tares hangs off one pipeline. Sources ingest events from your systems; the labels on each event say which entity it belongs to. A read returns one entity's events across sources, merged in time order. A trigger watches a set of sources and, when its condition trips, emits a dispatch that wakes agents; an agent can write a finding back onto the entity's timeline. A project is a goal plus its wiring: which trigger wakes which agent, over sources, triggers, agents, MCP servers and skills that any number of projects can share.
- [Projects](https://docs.glassflow.ai/tares/projects.md): A project is what you set up and look after in Tares: one job, with everything it needs on one page. It uses:
- [Guided setup](https://docs.glassflow.ai/tares/projects/guided-setup.md): Say what a project should achieve, the way you would to a colleague. Tares writes a plan for it: what to watch, when to wake, who does the work and what they may use. You see the whole plan in plain words, change any part of it, and nothing runs until you click Looks right, set it up. What you end up with is an ordinary project: every part is on its own page and stays editable.
- [Ask](https://docs.glassflow.ai/tares/projects/ask.md): Ask is the assistant built into the console: type a question about your data and it investigates with the same read API everything else uses, showing each tool call as it works. Open it under Ask in the sidebar, or summon it from anywhere with ⌘K.
- [Build a software factory with Claude Code](https://docs.glassflow.ai/tares/software-factory/get-started.md): Tares runs a crew of Claude Code sessions (an orchestrator, a reviewer and builders) in the background on your machine. You sign in with `tares login` (or run Tares yourself with `tares up`), start the crew with `tares factory crew up`, and plan a project with `/tares:spec` (or `tares factory spec`). The crew builds the tickets into pull requests merged on main.
- [Run autonomous, self-running Claude Code sessions](https://docs.glassflow.ai/tares/software-factory/autonomous-claude-code-sessions.md): Tares runs a software factory for Claude Code: a crew of Claude Code sessions that run in the background on your machine. A watch brings back any session that stops, the orchestrator checks for work on a schedule, and builders merge reviewed pull requests, so the work continues while you are away. The crew asks you before the decisions that are yours.
- [A project, end to end](https://docs.glassflow.ai/tares/software-factory/a-project-end-to-end.md): This page follows one real project through the factory. The starting point: a pull request adding a Babysitters section to a household app, with no tests and a few bugs in how it paid shifts. The goal was to fix and test it, merge it into main and deploy it.
- [Software factory for Claude Code compared](https://docs.glassflow.ai/tares/software-factory/comparison.md): A software factory for Claude Code built with Tares fits when you want a crew of sessions that keeps working across restarts, and a record of the plan, the reviews and your decisions that outlives every session. If you only need help inside one session, subagents or a single worktree are lighter, and if you want an agent you hand a whole task to, Devin or OpenHands are closer to that. This page compares them on the same seven questions.
- [Connectors](https://docs.glassflow.ai/tares/connectors.md): A connector defines how a source gets events into Tares. These are the supported connectors:
- [Prometheus alerts: `prometheus_alerts`](https://docs.glassflow.ai/tares/connectors/prometheus-alerts.md): Polls Prometheus's own `/api/v1/alerts`, the alerts its alerting rules have already fired. One event per active alert, keyed by a label, plus a `resolved` event when it clears. No Alertmanager and no PromQL: Prometheus decides what's an alert; Tares correlates it and can dispatch it to an agent.
- [Docker logs: `docker_logs`](https://docs.glassflow.ai/tares/connectors/docker-logs.md): Tails a running container's logs, one event per line, all lines by default, with optional `match`/`drop` regex filters. Supports discovery, and the dedicated `discover_docker` tool scans the whole local Docker environment for candidate containers.
- [GitHub Issues: `github_issues`](https://docs.glassflow.ai/tares/connectors/github-issues.md): Poll source for GitHub Issues. A project can keep its tickets in a GitHub repo instead of Tares: one repo and one issue label pick the issues, those issues become the project's tickets, and every change made in GitHub becomes an event on the `github_issues` source, keyed by the ticket's name (`GH-12`). Triggers and agents can react to them like any other event.
- [Claude Code sessions: `claude_code`](https://docs.glassflow.ai/tares/connectors/claude-code.md): Ingests Claude Code session transcripts into the data plane, one event per message, keyed by `session`, with `project`, `branch`, and `model` as labels and token-usage fields. Sub-agents roll up into the same source. Your agent sessions become a queryable source like any other: correlate what the agent did with what your systems did, and let the agent read back its own history.
- [HTTP API (poll): `http_poll`](https://docs.glassflow.ai/tares/connectors/http-poll.md): Polls a JSON endpoint on the source's schedule and stores one event per item. The generic path for the APIs no other connector covers: a weather service, a status page, a SaaS export, an endpoint of your own. Nested values are reachable by dotted name everywhere, so a label, a trigger filter or a trigger condition can watch `current_weather.windspeed`.
- [Alertmanager: `alertmanager`](https://docs.glassflow.ai/tares/connectors/alertmanager.md): A push receiver for Alertmanager: point a `webhook_configs.url` at this source's ingest endpoint and every alert Alertmanager routes becomes an event. Alertmanager has already evaluated, grouped, deduped and (with `send_resolved`) tracks firing→resolved. Tares just records what it pushes, and correlates it with your other sources.
- [GitHub](https://docs.glassflow.ai/tares/connectors/github.md): Tares connects to GitHub in one of two ways. You pick a credential, and Tares decides how events arrive.
- [Linear: `linear`](https://docs.glassflow.ai/tares/connectors/linear.md): Poll source for Linear. A project can keep its tickets in a Linear project instead of Tares: the issues become the project's tickets, and every change made in Linear becomes an event on the `linear` source, keyed by the issue's identifier (`ENG-123`). Triggers and agents can react to them like any other event.
- [Agent memory: `memory`](https://docs.glassflow.ai/tares/connectors/memory.md): The agent's own observations, written back via the MCP `remember` tool (or `POST /remember`). Joined into reads and triggers like any other source: what an agent concluded about `service=checkout` last week sits in the same timeline as the service's logs and deploys.
- [OpenTelemetry: `otlp`](https://docs.glassflow.ai/tares/connectors/otlp.md): Receives OTLP/HTTP logs, traces, and metrics at `POST /v1/{logs,traces,metrics}`. One source ingests every service: resource attributes (e.g. `service.name`) become labels, so everything an OTel SDK or Collector exports correlates by service with no per-service setup.
- [Postgres table: `postgres`](https://docs.glassflow.ai/tares/connectors/postgres.md): Polls a table incrementally, one event per new/changed row. The cursor tracks a monotonic column (an autoincrement `id`, or `updated_at`); an entity column (e.g. `tenant_id`) becomes the key via a `primary` label. Your application's source-of-truth data in the timeline. Supports discovery: given the connection URL it lists the tables it can see, then reads the chosen table's columns to propose the cursor and labels.
- [Prometheus: `prometheus`](https://docs.glassflow.ai/tares/connectors/prometheus.md): Ingests the Prometheus metrics you pick. Each series becomes a metric event on every poll tick, joinable with logs, deploys and alerts on the same key. You choose which metrics (by name, or by a label they carry) and Tares does the rest: there is no PromQL to write. The numeric value is stored as a number-typed `value` label, so triggers can aggregate it.
- [Reference documents: `reference`](https://docs.glassflow.ai/tares/connectors/reference.md): Documents (json / csv / md / txt) attached to an entity by their labels: project notes, schemas, runbooks. Unlike the event connectors this is declarative reference material, not a stream: it's always surfaced when correlating on that entity, regardless of the read time window. A runbook doesn't "age out" of a 15-minute read.
- [Vercel logs: `vercel`](https://docs.glassflow.ai/tares/connectors/vercel.md): Push source for Vercel logs: point a Vercel log drain (JSON) at the source's ingest endpoint. One event per log entry, keyed by `project`, with `environment` and `source` as labels. A single drain can carry multiple projects; they appear as distinct entities.
- [Inbound webhook: `webhook`](https://docs.glassflow.ai/tares/connectors/webhook.md): Push ingestion of arbitrary JSON (or NDJSON): producers POST to the source's ingest endpoint. The payload is stored lossless; declare labels to map payload fields into the envelope. The catch-all connector for anything that can send an HTTP request: CI systems, GitHub webhooks, cron jobs, your own services.
- [Connecting agents (MCP)](https://docs.glassflow.ai/tares/agents.md): Connect Claude Code, Codex, Cursor, or any MCP client to Tares and ask questions like *"what happened to api-server in the last 15 minutes?"*. The client discovers the Tares tools and answers from the correlated timeline: logs, metrics, alerts, and findings in one read.
- [AI resources](https://docs.glassflow.ai/tares/agents/ai-resources.md): This page is written for coding assistants (Claude Code, Codex, Cursor, or an agent of your own) that are asked to set up, configure, or explain Tares. Humans are welcome too.
- [Tares agents](https://docs.glassflow.ai/tares/agents/tares-agents.md): A Tares agent is a prompt attached to a trigger. When the trigger fires, the agent is handed the correlated timeline for the affected entity, reads it (and can read a wider window or another entity), and writes its conclusion back into Tares as a finding on that entity's timeline.
- [How a run ends](https://docs.glassflow.ai/tares/agents/tares-agents/how-a-run-ends.md): An agent that ends with a conclusion (see below) gets the `conclude` tool, to end a run on purpose: `no_op` when there is nothing to report (no finding is recorded), or a finding with a `verdict` about a named entity. With a finding it also gives:
- [Deliver findings](https://docs.glassflow.ai/tares/agents/tares-agents/delivery.md): Every finding lands on the entity's timeline; the agent's Deliver findings options also send it where people and systems already look. Each is a toggled row on the agent's form:
- [Handoffs](https://docs.glassflow.ai/tares/agents/tares-agents/handoffs.md): An agent can pass its finding to another agent, by verdict. A cheap agent that watches often can hand the one entity that needs a closer look to a thorough agent, without a second trigger in between.
- [Skills](https://docs.glassflow.ai/tares/agents/tares-agents/skills.md): A skill is a set of instructions for your agents: a runbook for one kind of incident, the checklist for a release, the house style for incident notes. A skill lives on the instance and projects use it: any number of projects can use the same skill, and editing it changes it for all of them. Every Tares agent in a project that uses a skill sees its name and description, and loads the full text only when the task in front of it matches. You write a procedure once and keep each agent's prompt short.
- [Tools and MCP servers](https://docs.glassflow.ai/tares/agents/tares-agents/tools.md): By default a Tares agent has two tools, both routed through the same Tares read path and both covering the sources of the projects its run is for, unless it names others with `sources`:
- [Model providers](https://docs.glassflow.ai/tares/agents/model-providers.md): Tares agents and Ask reason with a model. Which model, and whose, is a provider the instance holds under Settings → Model providers. An instance can hold several: one agent on Claude, another on GPT, a third on a model your own router serves. One provider is the default, what Ask and the guided setup run on and what an agent without a choice of its own uses.
- [Guides](https://docs.glassflow.ai/tares/guides.md): End-to-end walkthroughs for common tasks. Each assumes a running instance (see the Quickstart) and links to the relevant reference where useful.
- [Build an AI SRE](https://docs.glassflow.ai/tares/guides/ai-sre.md): This guide builds an incident-response agent on Tares, end to end. By the last step you have a working AI SRE: when a service misbehaves, a trigger wakes an agent with one correlated timeline of metrics, logs, and alerts; the agent names the root cause and writes its conclusion back where the next investigation will find it. You also have an MCP client connected, so you can investigate the same evidence interactively.
- [Use AI to monitor your systems](https://docs.glassflow.ai/tares/guides/ai-monitoring.md): You connect your logs, metrics, alerts and deploys to Tares as sources, and Tares merges them into one timeline per service. When an alert fires, a trigger wakes a built-in Tares agent, or your own agent service over a webhook, and the agent writes its diagnosis onto the service's timeline before anyone opens a dashboard. Claude Code, Cursor and any other MCP client read the same timeline when you want to investigate yourself.
- [AI SRE compared: Tares, vendor AI, and one MCP server per tool](https://docs.glassflow.ai/tares/guides/ai-sre-comparison.md): Tares fits when your signals live in several tools, you want to keep the alerting you already run, and you want an agent woken the moment an alert fires. One read returns the correlated timeline of a service across every source, a trigger wakes the agent, and the agent writes its finding back where the next investigation starts. Tares runs on your machine or your server, in one local DuckDB file.
- [Keep shared code context current](https://docs.glassflow.ai/tares/guides/shared-code-context.md): Many teams keep a repository of shared context: what each service does, its interfaces, its configuration, how the pieces depend on each other. It goes stale the week after it is written. This guide sets up a project from the Shared code context template: Tares watches commits across your code repositories, and when something lands an agent reads the change and updates the context pages that cover it, opening a pull request for review. By the last step the context repository is kept current by the commits themselves.
- [Challenge Claude Code with a second model](https://docs.glassflow.ai/tares/guides/challenger-workflow.md): One model writes the code, a second one argues with it. In a challenger session, Claude Code plans and builds as usual, and the OpenAI Codex CLI on the same laptop critiques the plan when Claude leaves plan mode and reviews every commit Claude makes. A blocking finding sends Claude back to fix and amend before it can move on. Tares is the record and the after-session brain: the Claude and Codex exchange lands on one timeline per session, and when the session ends a Tares agent writes the summary and proposes what the next session in that repo should remember.
- [The HTTP API in five minutes](https://docs.glassflow.ai/tares/guides/http-api.md): Everything the console and the MCP tools do goes through the daemon's HTTP API. This guide drives the whole loop with `curl`: create a source, feed it, read a correlated timeline, define a trigger, watch it fire, and write an observation back. No upstream systems required.
- [Watch with triggers](https://docs.glassflow.ai/tares/guides/triggers.md): A trigger watches one or more sources and evaluates a condition as events arrive. When it fires, Tares pushes to any subscribed webhook, so an agent is woken with the relevant timeline instead of polling. A trigger is used by one or more projects; each project says which agents it wakes there.
- [Watch, then escalate](https://docs.glassflow.ai/tares/guides/watch-then-escalate.md): Alert rules catch what someone thought to write a rule for. This guide puts a first level in front of your root-cause agent: a triage agent looks at your sources every few minutes, says "normal" in a line most of the time, and when something moves, hands that one entity to the main agent for a root-cause analysis.
- [Connect an outside agent to a project](https://docs.glassflow.ai/tares/guides/outside-agent.md): After this guide, Claude Code works inside one Tares project: it reads the project's sources, follows the project's skills, sees what the Tares agents already found, and records its own findings on the same timelines. Everything it records shows on the project's Overview.
- [Self-host on a server](https://docs.glassflow.ai/tares/reference/self-host.md): Run a single-tenant Tares instance on a server: the daemon, the MCP server, and a reverse proxy (Caddy) that terminates TLS and serves one hostname. DuckDB is single-writer, so this is exactly one `taresd` and one volume.
- [Release notes](https://docs.glassflow.ai/tares/reference/release-notes.md): Notable changes to Tares, newest first. The project follows Semantic Versioning; earlier `0.0.x` history is in the git log.
- [CLI reference](https://docs.glassflow.ai/tares/reference/cli.md): The `tares` package installs three entry points: `tares`, with the subcommands below, `taresd` and `tares-mcp`.
- [Deployment](https://docs.glassflow.ai/tares/reference/deployment.md): Tares is a single process writing to a single DuckDB file. There is no external database or broker to run. DuckDB is single-writer, so a deployment is exactly one `taresd` and one data volume. Do not run multiple replicas against the same data.
- [Answers](https://docs.glassflow.ai/tares/answers.md): Short answers to specific questions about the two things Tares is built for: a software factory for Claude Code, and an AI SRE. Each answer stands on its own, and links to the full guide when you want the whole picture. To start from the guides, see Build a software factory with Claude Code and Build an AI SRE.