We took a pipeline apart to find out where the money actually goes.
Document processing pipeline — 5,000 documents a month · four stages · built the way the quickstart teaches.Illustrative
Click a segment to see what ORXA does instead.
Every stage receives the whole accumulated state — the document, plus everything the previous stages said about it. By the last stage you are paying to re-send the same document for the fourth time.
◆Each stage receives its own inputs and nothing else. The fourth stage does not pay to re-read the first three.
Every tool result is returned into the model’s context in full, then carried forward for the rest of the run — whether or not anything downstream needs it.
◆The model writes a plan; the runtime executes it and moves data between tools directly. Only summaries and exceptions reach the model.
One model is chosen for the whole pipeline, so field extraction and format conversion run on the same expensive model as the judgement calls.
◆Each stage runs on the model built for it. The judgement stage keeps its capable model; the mechanical stages stop paying for depth they never use.
Five thousand near-identical extractions are issued as five thousand separate calls, at full interactive rates, because the pipeline was written as a chain.
◆Uniform bulk work is grouped into batches while a small agentic process prepares the next one. Batching is not a discount here — it changes the shape of the pipeline.
The output you actually wanted: extracted fields, validations, exceptions flagged.
◆Untouched. This is the part you meant to buy.
Every segment above is money the pipeline did not have to spend.
You address an orchestrator, not a model. It decides how to answer — and these are the decisions it makes.
The request becomes stages, each small enough to solve well on its own. Nothing gets handed a whole problem at once.
Each stage receives its own inputs, not the accumulated transcript of everything before it. This is the one that moved the most money.
Extraction and collection run on models built for that. The capable model is kept for the judgement, where it earns its price.
The model writes a plan; our runtime executes it. Tools pass data to each other directly and only summaries and exceptions come back.
Uniform high-volume work is grouped, while a small agentic process prepares the next batch. The pipeline changes shape rather than just running faster.
Memory and learned routing per orchestrator: better model choices, correct tool calls, self-healed errors. You do not pay for the same mistake twice.
The execution runtime underneath is open source and shipping today — the engine behind CombyCode DPE. Tools run as separate processes and pass data over pipes, which is why payload size stops being a token problem. The agent library it is built on,ORXA LLM-SDK, is MIT and on npm.
Read it, run it yourself, or let us host it. The first two do not need us.
ORXA speaks the OpenAI wire format. Change a base URL and a key; your SDK and your calls stay as they are.
Cost is checked before a call is made. Over budget means it is never sent — not a warning after the money is gone.
Which stage, how many tokens, what it cost. OpenTelemetry-shaped traces you can export.
Ready-made orchestrators at launch; your own, built around your agents, when the console ships.
Tasks, tool flows, skills, memory and files as first-class resources — everything the OpenAI shape cannot express.
Development, data analysis, document work, batch jobs. Not realtime chat — orchestration costs latency and we would rather say so.
ORXA API is in development. Join the waitlist for early access and locked-in pricing — and tell us which part you actually need, so we build that part first.