latitude vs galileo

Open-Source Observability and an Enterprise Eval Platform

Latitude, from Barcelona, shipped V2 in June 2026. It traces sessions, tools, memory and cost over OpenTelemetry with about 40 integrations; scores completed sessions with evaluations; lets humans annotate; alerts through monitors in-app, by email and in Slack; and, through Agent Dispatch, sends a coding agent to open a fix PR. The whole platform has been MIT-licensed since May 2026, and self-hosted installs use the same images as the cloud.

Galileo is built around evaluation. It ships 20+ out-of-box evals for RAG, agents, safety and security, custom evaluators, Luna-2 small evaluation models, and CLHF for improving a metric with human feedback. Its customers include Twilio, Comcast, HP and ServiceTitan. Cisco completed its acquisition of Galileo in May 2026, according to Splunk, and Galileo's technology is going into Splunk Observability's AI Agent Monitoring. Its release notes say that as of August 7, 2026, "Galileo is now Splunk Agent Observability"; this page keeps the Galileo name, still used on galileo.ai.

On a pricing page, they look like peers. In an architecture review, they are not: one is a system you can own outright; the other is an evaluation engine with an enterprise control layer on top.

Side by Side

Two rows point in opposite directions. Galileo can act on a live request and Latitude cannot. Latitude can be run entirely on your own servers for free and Galileo cannot, outside Agent Control. Most teams know which of those two matters to them before they finish reading the table.

A Judge That Disagrees with Your Reviewers

Every team that runs an LLM judge meets this week eventually. A support agent's "helpfulness" judge starts failing short answers that the support leads think are exactly right: the customer asked for a tracking number and got one. Reviewers stop trusting the score. Here is how each platform lets you fix the judge rather than ignore it.

1. Latitude: annotate, then realign

   Reviewers annotate a batch of sessions in Latitude, marking the short answers as good. What happens next depends on where the evaluation came from. If Latitude generated it from a signal, Latitude keeps it aligned to human judgment over time, so the annotations pull it back. If you wrote the LLM-judge prompt yourself, it "runs exactly as written", and the annotations become the evidence you use to rewrite it. Where the criterion can be made exact, a rule condition, "deterministic checks, free and instant", may replace the judge for part of the job.

2. Galileo: label five, retune the metric

   Reviewers give feedback on the records the metric got wrong. CLHF, Continuous Learning with Human Feedback, tunes the judge metric from as few as five annotated records, so the correction is a labelling task rather than a prompt rewrite. On Enterprise, Galileo can then distill the judge into a Luna-2 model to run it cheaply at volume.

3. The difference

   Both put reviewer judgment back into the score. Galileo makes it a short, managed loop on its own metrics. Latitude makes it a loop you can see and edit end to end, with the prompt, the annotations and the evaluation code all in a platform you could run yourself.

If your team has no one who wants to maintain judge prompts, Galileo's loop is less work. If your team wants to know exactly why a score moved, and to keep the judge in version control, Latitude's is more transparent.

How Each Builds an Evaluation

Latitude asks you to define what you are looking for, and offers three ways to do it. In its docs' words: "Set of conditions: deterministic checks, free and instant"; "LLM as judge: describe the behavior and let an LLM decide"; and "Custom script: JavaScript for anything the other two can't express". Evaluations can also be generated from signals Latitude has picked up. Each runs on completed sessions within its scope and sampling, and datasets built from real traces let you replay failures as regression tests before a fix ships.

Galileo asks you to pick from a library first. Its 20+ out-of-box evals cover RAG, agents, safety and security, including agentic metrics such as Tool Selection Quality, Tool Call Error Detection and Session Success, and custom evaluators encode what the library does not. The same metric that scores an offline run can score production traffic and, on Enterprise, become a guardrail, which is what its "offline evals become production guardrails" line means in practice.

The trade is the usual one between a toolkit and a catalogue. Latitude's rule conditions are the cheapest check either product offers, since they cost nothing to run, and nothing in Latitude is hidden from you. Galileo gets a team without evaluation experience to a meaningful score faster, and has more to say about agent-specific failure modes on day one.

Guardrails and Self-Hosting: Opposite Strengths

Latitude does not act at runtime. Its evaluations score sessions after they complete and never block or change a response. The word "guardrails" does appear in its product, but it refers to per-project limits on what Agent Dispatch may do, not to live traffic.

Galileo does act at runtime, with conditions. Its pricing page lists "Real-time guardrails" under Enterprise only, and Luna-2, which its docs pitch as fast enough for runtime protection, is Enterprise-only too. Outside Enterprise, the route is Agent Control, Apache-2.0 since March 2026, which checks LLM and tool inputs and outputs against a policy and returns deny, steer, warn, log or allow; you run its server yourself on PostgreSQL, and a centrally managed version for enterprise customers shipped in June 2026. Galileo Protect, the previous product, was deprecated in June 2026.

Self-hosting runs the other way. Latitude self-hosts free with Docker Compose on one host or a Helm chart on Kubernetes, on PostgreSQL with pgvector, ClickHouse, Redis, Temporal and an object store; its cloud runs in AWS eu-central-1. Galileo's hosted, VPC and on-prem deployments are an Enterprise option. For a European team that needs traces in the EU and has no Enterprise budget, that difference can settle the decision before any feature does.

Same Entry Price, Different Units

The near-identical headline prices hide different meters. Galileo meters traces, which is a unit you can count from your own logs; Pro is billed yearly, which the page presents as a 33% saving, and only Free is self-serve: Pro and Enterprise both start with "Book a Demo". Latitude meters credits, and its pricing page lists "What is a credit and how are they calculated?" without answering it there. Before comparing bills, ask Latitude what a credit is and check how Galileo counts a multi-step agent run.

Past the entry tier, the two diverge sharply. Latitude's answer to "we need more control" is to self-host the same code for free. Galileo's is an Enterprise contract, which is where its guardrails, Luna-2, VPC deployment and SSO all live.

Who Each Is Built For

Latitude's customer logos, among them PLANneD, Legalitas, Superlist and Waalaxy, are mostly growing European software companies, and its product fits a team that wants to own its tooling, fix failures fast and keep costs flat. It has also changed shape several times, from data apps to a prompt playground to agents to V2, which dropped the V1 prompt gateway; V1 keeps running for existing customers. That is history, not a verdict, but it is worth knowing if you are standardising for years.

Galileo is built for organisations with security reviews, many teams and the need to prove control, and its customer list shows it. Its new owner is a question to ask rather than guess about: the public facts are that the acquisition is complete and the technology is going into Splunk Observability. If you sign a multi-year agreement, ask what that means for the plans you are buying.