Suitable models.
Useful results.
AI cost optimisation starts with your task: DAXS compares suitable models for call notes, knowledge searches or analysis and measures the cost per successfully completed work step.
A call note requires different capabilities from a difficult analysis.
After a customer call, an employee records a few approved key points. The aim is a short message covering the request, the agreed next step and outstanding questions. A smaller model may be sufficient for this bounded task. We test whether it is sufficient using typical, incomplete and contradictory inputs.
A complex code review or analysis of extensive documents has different requirements. A more capable model, more context or additional checks may make economic sense here. What matters is which solution reliably brings the task to the intended outcome.
What does a successfully completed task cost?
The calculation includes model usage, tools, search services, infrastructure, integration, support and necessary rework. This is divided by the number of genuinely usable results. An inexpensive individual request offers little benefit if employees have to correct or restart it repeatedly.
Choose the appropriate processing deliberately.
A router can allocate tasks according to defined criteria: data class, language, required tools, complexity, acceptable waiting time and budget. The rules need practical testing. A model name or an AI's high self-assessment is insufficient evidence of quality.
Escalation is a planned error path: ask for clarification, involve a person or use a suitable approved model. Protection requirements, provider restrictions and budget remain binding. A technical failure must not automatically send confidential inputs to an arbitrary alternative provider.
Less unnecessary context, suitable outputs and controlled retries.
Tokens and context
Inputs, conversation history, tool descriptions, retrieved text and outputs can affect usage. We select relevant excerpts and an appropriate response length. Sending entire document collections with every short question is rarely a useful default.
Prompt caching
Services that support it may process recurring, unchanged input sections more cheaply and quickly. Whether a cache hit occurs depends on the model and provider's rules. Caching replaces neither access checks nor secure separation of confidential contexts.
Batch processing
Tasks that do not require an immediate response may be suitable for grouped, asynchronous processing. This approach may be unsuitable for a message during a customer conversation, while it may fit planned document classification.
We also limit maximum output length, retries, tool calls and agent steps. When an error occurs, it must be clear whether another attempt is useful. An unbounded loop can incur costs without moving the task forward.
A gateway simplifies access and expands what needs assessment.
A direct provider API establishes a direct technical and contractual connection to the selected service. The application needs to integrate its authentication, limits, error handling and data options. Multiple direct integrations can make sense but require corresponding maintenance.
OpenRouter and comparable gateways can make multiple models and execution providers accessible through a shared interface. We distinguish Model routing between different models and provider routing for the same model. Data recipients, retention, permitted providers, functionality, possible fallback paths and billing need to fit each specific configuration.
A common API format does not guarantee identical tool use, structured outputs or quality. Provider changes are tested using the same tasks. The intermediary platform also forms part of the technical and data protection assessment. OpenRouter: provider routing (external link) — opens in a new tab.
An inexpensive draft still needs to be correct.
For the call note, we define in advance what a good output needs to contain: correct attribution to people, no invented commitments, a complete next step and a clearly identified open question. Missing details are flagged rather than filled in. Test cases also include dialect, abbreviations, typing errors and factual contradictions.
- Quality
- How many results are usable without factual correction? Which errors would be critical to the business? Writing quality and professional reliability are assessed separately.
- Rework
- How long does an employee need for review and correction? A cheaper model may become more expensive overall if it requires more correction.
- Speed
- Initial response and complete processing are measured separately. Queues, searches and tool steps contribute to actual waiting time.
- Availability
- What happens at usage limits, during outages or after a model change? An approved fallback and an understandable error state are part of the design.
- Security
- May this specific service process this data? A low price does not justify an impermissible data path. Permissions and approvals remain part of acceptance testing.
Assess local, API and hybrid options economically.
An API can suit fluctuating usage and specific model capabilities. Your own hardware may make sense with an appropriate workload and existing operational resources. Hybrid arrangements allocate tasks according to data requirements, quality and capacity. The decision requires comparison over the same period and expected usage.
- Local infrastructure: Purchase or rental, depreciation, electricity, cooling, space, storage, reserve capacity and any licences. Context and concurrent usage also matter for sizing.
- Ongoing operations: Updates, monitoring, outage handling, backup, security assessment and rollback if a model version proves unsuitable.
- Integration: Data preparation, interfaces, identity, permissions, test cases, documentation and adjustments when applications change.
- API usage: Usage charges including additional tools, search, storage and gateway costs; permitted limits and actual peak loads.
- Organisation: Training, approvals, human review and the consequences of incorrect results.
An existing flat-rate plan or licence may make additional usage more economical. Unnecessary waiting, lengthy contexts, rework and limited capacity remain real costs. Usage already paid for is no reason to retain an unsuitable architecture indefinitely.
For the technical side, see Local AI & LLM infrastructure and the practical article on load testing for a suitable test plan.
A pilot with a cost framework and traceable results.
DAXS can assess tasks and data paths, connect suitable models and establish a repeatable comparison. For each test, we record the model version, input volume, tool use, quality, processing time and necessary corrections. The result is a recommendation for the specific task — with stated limits and a practical next step.
During ongoing operations, usage and errors are analysed by task or application. Budget notifications, technical ceilings and permitted escalations are configured separately. A model update undergoes the same quality test before broad deployment; a provider or API outage requires a documented fallback.
We establish dependable figures from your actual usage and the terms verified at the time of the decision. Savings and example prices need to reflect those specific conditions.
AI security and data rights · Integrate tools and MCP · Script, workflow or AI agent?
Let's discuss your use case.
Which task should become easier, what data is involved and which systems do you already use? This defines a bounded starting point with clear review and decision stages.
Sources: OpenAI: cost optimisation (external link) — opens in a new tab · OpenAI: prompt caching (external link) — opens in a new tab · OpenAI: batch processing (external link) — opens in a new tab · OpenRouter: provider routing (external link) — opens in a new tab · OpenRouter: prompt caching (external link) — opens in a new tab
Product features, licences and specific settings are assessed for each environment. Examples and diagrams explain possible workflows.