Startup Spotlight: Orchestra turns production traces into smaller models; 100x remains a claim

Why it matters

Orchestra is testing whether production AI spending can create an owned technical asset instead of a recurring API dependency. Its first-party studies show cost and latency gains on narrow tasks, while named customers, production savings, pricing and independent validation remain undisclosed; Dealroom reports a $125,000 YC investment, though the supplied company and YC materials contain no financing announcement.

Luis Manrique and Aamir Poonawalla, two former Instacart colleagues, founded Orchestra, an AI inference startup that aims to reduce the recurring cost of running applications on frontier models.

Orchestra sits between an application and providers such as OpenAI or Anthropic. It records selected production work and expert corrections, turns those examples into task-specific evaluations, and tests cheaper routes against the model a customer already trusts. Orchestra can improve the prompt, switch to another existing model or train an open-weight specialist. Traffic moves only after the candidate meets the customer's quality, cost and latency requirements, according to Orchestra.

The San Francisco operation entered Y Combinator's Summer 2026 batch as Understudy and introduced the Orchestra brand ahead of YC's September Demo Day. YC currently lists Orchestra as active, founded in 2026 and staffed by its two founders.

That two-person footprint makes the ambition unusually broad. Orchestra wants to control model evaluation, optimization, training and production routing without building frontier models. Manrique and Poonawalla argue in their YC company profile that customers should be "accumulating intelligence, not accumulating API bills."

Two careers built around optimization

Orchestra's company page identifies Manrique as employee number two at Gumloop, where he worked across go-to-market, forward-deployed engineering and data platforms. YC says he helped close approximately $2 million in Gumloop's first year.

Before Gumloop, Manrique was a principal product manager at Instacart, where YC says he led advertising machine-learning work and served as the first product manager for Carrot AI's consumer product. Earlier stops included Wildfire Interactive, which Google acquired, followed by roughly five years across Google's advertising machine-learning and programmatic platforms. He also co-founded Ones and Zeros, a text-to-SQL product built with transformers, and worked on television measurement infrastructure at VideoAmp.

That background gives Manrique direct experience with the task Orchestra now faces: persuading customers to place Orchestra inside a costly, production-critical system. The technical work matters only after Orchestra can convince a buyer to route live traffic through its gateway and provide enough examples to define what a successful response looks like.

Poonawalla supplies the infrastructure half of the pairing. He spent about a decade at Instacart and most recently led its ads-serving and infrastructure group as a senior software-development manager. YC credits him with work on Instacart's auction platform and experimentation systems. Orchestra also credits Poonawalla with leading Instacart's Curbside Pickup initiative as it grew from zero to approximately $4 billion in gross transaction value. His earlier roles included Microsoft and Pinterest, which he joined through Pinterest's acquisition of URX.

Poonawalla holds a master's degree in computer science from Georgia Tech and is returning to YC after building TapToLearn in the Winter 2012 batch. Orchestra is therefore being built by two founders who have already seen optimization systems operate at large consumer platforms, along with the organizational friction involved in changing production infrastructure.

Manrique has framed that experience as an advantage informed by years of prior decisions and mistakes. In Orchestra's original YC launch announcement, he described joining the accelerator at 38 and argued that repeat founders can understand YC's advice through years of prior decisions, customers and mistakes. Orchestra's product workflow applies that experience to an existing expense: observe the work behind a customer's model bill, evaluate cheaper candidates and replace expensive components when a narrow task supports the change.

A gateway that tries to make itself more valuable over time

The initial integration is deliberately familiar. Orchestra's platform documentation shows applications using existing OpenAI or Anthropic SDKs with an Orchestra-managed Understudy API key and gateway address. That setup is designed to place Orchestra in front of existing OpenAI- and Anthropic-compatible applications without rebuilding them around a new inference stack.

Once requests flow through the gateway, Orchestra's proposed loop has four stages: observe production traces and corrections, define an evaluation, improve the route, and deploy an approved change while retaining the old model as a fallback. Orchestra pitches the resulting specialist models as customer-owned assets.

The ownership pitch is central. A conventional frontier-model bill purchases responses. Orchestra wants the same spending to produce a reusable body of prompts, evaluations and weights specific to the customer's work. Repetitive workloads offer the best raw material because they produce enough comparable examples to measure whether a cheaper model has learned the task.

That focus also narrows Orchestra's practical market. Open-ended research, novel reasoning and low-volume tasks may continue to justify a frontier model. Structured operations, CRM actions, classification, extraction and repeated tool calls create clearer evaluation criteria and enough volume for optimization costs to pay back. Orchestra's public materials retain frontier models for exceptions and difficult cases.

Orchestra's platform page describes a sequence of improving instructions, comparing models on held-out work, and training new weights when the task warrants it.

The 100x headline is still ahead of the public evidence

YC's listing says Orchestra can cut LLM costs by 100x. The supplied materials contain no customer deployment that verifies that ceiling. Orchestra's homepage presents a narrower Orchestra-run result: an optimized Orchestra model costing $0.000074 per task against a $0.000444 frontier baseline, which Orchestra describes as an 83.4% reduction.

The more useful evidence sits in Orchestra's published results, where methodology and shortcomings appear alongside the favorable numbers. These are first-party studies. No independent customer, technical evaluator or production deployment has publicly validated Orchestra's central cost-saving thesis in the supplied materials.

Orchestra's operations results page says its serving comparison covered 90 trajectories. A Fireworks-hosted Qwen3-8B route delivered median latency of 369 milliseconds, against 1,935 milliseconds for Sonnet 4.6, making the smaller route about 5.2 times faster. Orchestra reports a mean action-level score of 0.9630 for the smaller route against Sonnet's 1.0000, while strict-pass rates were 92.22% and 100%, respectively. The quality measures favored Sonnet.

The economics also depend on how costs are counted. On the same study, Orchestra reports token costs of $0.006617 for the Fireworks validation slice and $0.039969 for Sonnet. Once cold-start GPU time was included, the short Fireworks validation cost approximately $1.56. Orchestra says that loaded figure came from a small, temporary deployment and excluded idle capacity, deployment overhead and broader operating costs. The comparison shows why token prices alone cannot settle an infrastructure decision.

Orchestra's warehouse results page says a post-trained 30-billion-parameter open model labeled 39,962 non-empty YouTube comments for $2.81589975, compared with $12.483859 for Sonnet and $139.63146 for Opus. Orchestra calculates the corresponding cost ratios as 4.43x and 49.59x.

According to the same results page, the open route produced 13 parse failures, compared with zero for Sonnet and one for Opus. Orchestra says the study labeled broad sentiment, intent and explicit theater-attendance intent for comments in a Snowflake-backed warehouse. Orchestra measured model agreement on valid overlapping rows, with no human-labeled answer set, and cautions that agreement does not establish ground-truth accuracy. The page says its quoted model costs exclude fully loaded warehouse-compute costs.

Across the operations and warehouse examples, Orchestra reports evidence that narrow optimization can improve cost or latency while preserving much of the measured task performance. The studies do not establish a general 100x reduction, a production-wide quality guarantee or the full cost of building and maintaining each specialist.

Orchestra has not disclosed named production customers, measured customer savings, customer or revenue counts, production volume, or public pricing. YC's two-person listing is the only verified headcount available.

Orchestra is competing for control of the model decision

AI gateways are already a busy category. OpenRouter documents provider sorting by price, throughput or latency. Portkey documents conditional routing, fallbacks, caching and guardrails in its AI gateway. Braintrust documents automatic tracing of LLM calls, including latency, token usage and costs, while its evaluation tooling supports datasets and experiments. Baseten's autoscaling documentation includes scale-to-zero. Fireworks documents serverless inference priced per token and dedicated deployments billed by GPU-second.

Orchestra's pitch combines pieces that buyers can otherwise assemble across several vendors. Orchestra observes work, builds the evaluation, changes prompts or weights, and moves traffic when a candidate clears the agreed threshold. Orchestra's differentiation depends on whether that loop can run reliably with less human labor than an internal machine-learning group or a collection of specialized tools.

The word "neocloud" gives Orchestra a larger frame than Orchestra's current architecture requires. Orchestra's public integration routes applications through existing frontier providers, while services such as Fireworks may host specialist models. Orchestra is positioning itself as the control plane that decides where inference spending goes and what customer-specific assets get created along the way.

That control point can become valuable as model choice fragments. Application developers face changing prices, latency, context limits and tool-use behavior across frontier and open models. A trusted routing layer can redirect spending whenever a cheaper model becomes good enough. Orchestra goes one step further by trying to manufacture the cheaper option from the customer's own work.

Production trust will decide the outcome

Orchestra's optimization loop requires representative production examples, expert corrections and evaluations. That creates practical questions for buyers about which traces can be used, who can review them, how regressions are detected and which underlying model licenses permit the resulting deployment. The supplied materials do not establish how Orchestra handles those choices in a named customer environment.

Orchestra's two-person staff adds another execution constraint. Building model evaluation, training, production routing and sales capacity requires several disciplines from a team that currently consists only of Manrique and Poonawalla.

Dealroom reports a $125,000 seed investment from Y Combinator in June 2026. That database entry is not an Orchestra or YC financing announcement. YC's current standard deal offers accepted companies $500,000: $125,000 on a post-money SAFE for 7% and $375,000 on an uncapped SAFE with a most-favored-nation provision. The supplied company and YC materials do not establish Orchestra's total funding, investors beyond YC or valuation, leaving its runway and capacity to fund compute unclear.

Orchestra's strongest near-term case is smaller than its 100x slogan and more defensible. Manrique and Poonawalla are offering customers a way to treat recurring AI work as training data for their next, cheaper route. If they can make the transition safe, measurable and simple, the frontier API becomes a starting point instead of a permanent dependency.