Train models for your #
recurring tasks.
Model APIs made it easier to add text generation, document extraction and other language tasks to an application. Developers could build a first version with a prompt and an API call.
Running those applications often requires repeated corrections. A document parser may misread the same field. A support tool may need the same wording changed before a reply can be sent.
Those corrections describe requirements specific to the application. We’re building Middleware to use that feedback to train models for tasks the application performs regularly.
Access to more models through an API
Teams can choose from hosted models and open-weight models, then compare their performance on the same workload. Open-weight models also allow developers to train and run versions suited to a particular task.
OpenRouter provides access to multiple providers through a common API. This reduces the integration work needed to compare models or switch providers.
Model selection still requires testing on your own inputs. A model that performs well on general benchmarks may need additional examples or training to handle your document formats, terminology or output requirements.
Context improves individual responses.
Context engineering involves selecting the instructions, documents, examples and tools a model receives for a request. These can supply current facts, explain required formats and let a model interact with an application.
For document extraction, context might include the expected fields and examples of correctly processed documents. It can improve a response without changing the model’s trained behavior. Once the task is complete, you can record whether the output was accepted, what needed correction and whether the task succeeded. Reviewed examples can then be used to train a model for similar work.
Middleware trains models from feedback.
Middleware receives calls from your application and lets you inspect model performance. We’re building it to use feedback from those calls to train open models for recurring tasks. You can use those models alongside your existing providers.
For example, a team processing invoices can use corrected field values as training examples. A model trained on those examples can be tested on new invoices to check whether it makes fewer extraction errors. Before using a trained model, its results need to be compared with the current model on examples outside the training set. This checks whether the change improves the task you need it to perform.
Middleware is intended to manage this training process through the API your application already calls. Teams can continue using their existing models and tools.
Teams should spend less time correcting repeated errors and maintaining a separate training pipeline for each task.