---
title: Coding Agent Cost Optimization and Audit | Luna Nova
description: Independent coding agent cost optimization and audit for Claude Code, Codex and Cursor. Benchmark models and harnesses on accepted engineering tasks.
---

[Skip to content](https://lunanova.ai/en/coding-agents/cost-optimization#main-content)

[![Logo (28)](https://lunanova.ai/hubfs/Logo%20(28).svg "Logo (28)")](https://lunanova.ai/)

- [English](https://lunanova.ai/en/coding-agents/cost-optimization)
- [Français](https://lunanova.ai/fr/agents-de-code/optimisation-des-couts)

English

Show submenu for translations

- [Offers](https://lunanova.ai/en/services)
- [Method](https://lunanova.ai/en/method)
- [Latest projects](https://lunanova.ai/en/projects)
- [About](https://lunanova.ai/en/about)
- [Contact](https://lunanova.ai/en/contact)

Open main navigation

Close main navigation

- [Offers](https://lunanova.ai/en/services)
- [Method](https://lunanova.ai/en/method)
- [Latest projects](https://lunanova.ai/en/projects)
- [About](https://lunanova.ai/en/about)
- [Contact](https://lunanova.ai/en/contact)
- - [English](https://lunanova.ai/en/coding-agents/cost-optimization)
    - [Français](https://lunanova.ai/fr/agents-de-code/optimisation-des-couts)

  English
  
  Show submenu for translations
- [Discuss your AI project](https://calendly.com/luna-nova/30min)

[Discuss your AI project](https://calendly.com/luna-nova/30min)

Expertise

# Coding Agent Cost Optimization and Audit

Benchmark Claude Code, Codex and agentic SDLC workflows on accepted engineering outcomes.

[Discuss your AI project](https://calendly.com/luna-nova/30min)

In brief

Coding agent cost optimization is the process of finding which models, tools, harnesses, and execution loops deliver accepted software changes at a sustainable cost. Luna Nova provides independent audits and controlled benchmarks for Engineering teams using Claude Code, Codex, Cursor, and agentic software development workflows.

The essential checks:

- Measure the cost of accepted tasks, not only model tokens.
- Compare agent configurations on your own repository and issues.
- Include tests, security checks, retries, and human review.
- Revisit harness design when models or pricing change.
- Verify a candidate in a controlled environment before rollout.

**Coding agents can write code quickly. That does not automatically mean an Engineering team delivers accepted software more efficiently.** An agent may propose a patch in minutes while consuming repeated context, spawning subagents, failing tests, or creating work for reviewers. A low price per token is not useful if the result needs extensive correction or does not meet the definition of done.

Luna Nova's [AI Software Factory Cost Engineering](https://lunanova.ai/en/services#ai-software-factory) helps CTOs, VP Engineering leaders, and Platform or Developer Productivity teams evaluate those trade-offs. We focus on the combined cost and quality of completed engineering work, from a coding assistant's immediate output to the wider harness and execution loop that governs it.

An independent coding agents audit can begin with a representative development task, your existing tools, and explicit acceptance criteria. It does not require replacing your whole software development lifecycle. [Talk to Luna Nova about your coding agents and their cost](https://calendly.com/luna-nova/30min) to identify whether a focused benchmark is the right first step.

## When should Engineering audit Claude Code, Codex, or Cursor?

A coding agent audit becomes useful when assistant usage has evolved into a shared Engineering capability, particularly when teams use multiple tools, multi-step agents, or repeatable delivery workflows. The trigger is not simply the number of purchased seats. It is the combination of variable execution cost, adoption at scale, and uncertainty about delivered quality.

An individual developer can often choose a coding assistant informally. The situation changes when a CTO supports multiple teams, establishes approved models, defines policy for tools and credentials, and needs to distinguish useful autonomous work from costly iteration. A framework that performs well in a demonstration may behave differently against a large repository, incomplete tickets, legacy tests, or strict security requirements.

The technical cost mechanism is well documented. In its [October 2026 coding-agent Tokenomics study](https://aws.amazon.com/blogs/aws-cloud-financial-management/tokenomics-for-coding-agents-benchmark-cost-and-quality-on-your-own-code/), AWS explains that agentic coding repeatedly sends growing transcripts, accesses files and tools, and can extend across tens or hundreds of turns. These are workload patterns, not assumptions that every agent run has the same cost profile.

An audit is especially relevant when:

- Claude Code, Codex, Cursor, Copilot, or other tools are deployed across multiple development teams.
- Agentic usage generates consumption-based charges beyond predictable subscriptions.
- The organization is building a harness, execution-loop framework, or internal AI Software Factory.
- Reviewers report more corrections, failed tests, or inconsistent changes despite faster code generation.
- Engineering leaders want to compare model generations or competing agent setups independently.
- The company needs security and governance controls before wider agent autonomy.
- Provider pricing or product packaging changes make previous defaults worth revisiting.

A simple code-completion deployment with limited usage may not warrant a formal consulting engagement. For an Engineering function deploying agents across repositories and workflows, a controlled evaluation can prevent the wrong setup from becoming a costly standard.

## Why the cheapest coding agent is not always the least expensive

The cost of a coding agent includes more than a license fee or a model API price. Model calls, context replay, tool execution, delegated tasks, repeated attempts, test runs, and human corrections all influence the resources required to deliver an accepted engineering change.

A run can appear successful because the agent produced a plausible patch. Yet it may have skipped a required test, introduced a regression, modified the wrong boundary, or left a security issue for the reviewer. From an Engineering perspective, useful progress begins when the task meets its acceptance criteria and the change is ready for the next authorized delivery stage.

The AWS October 2026 study demonstrates the effect of the harness itself. On the same tasks and hosting path, AWS reported one model costing approximately **$8 per task** with a lighter harness and **$24 per task** with a heavier harness. The heavier approach created additional subagent work without a matching quality gain in that measured comparison. Those are results of AWS's test setup, not prices or promised reductions for Luna Nova clients.

For a useful internal cost baseline, separate:

| Layer | What can create cost | What acceptance requires |
| --- | --- | --- |
| Model | Input, output, cache reads and writes | Reasoning and code fit for task |
| Agent harness | Instructions, tools, skills, delegation | Controlled execution with relevant context |
| Execution loops | Retries, reviewers, subagents, replanning | Convergence instead of repeated failure |
| Engineering system | Tests, CI, build, environment preparation | Reproducible verification and security |
| Human contribution | Clarifications, review, remediation | Correct, maintainable, accepted change |

A model that emits fewer tokens might need more retries. A powerful model may consume more per call yet complete a task in fewer turns. A rigorous security review may add time while reducing unacceptable risk. We examine those effects together instead of maximizing a single low-level metric.

A vendor leaderboard is informative for candidate selection, but it cannot substitute for the cost and quality of accepted changes in your repository. The real workload, not a general marketing benchmark, must arbitrate the configuration.

## How do we calculate cost per accepted engineering task?

Cost per accepted engineering task is the attributable cost of agent-driven execution divided by the number of tasks that meet a specified engineering definition of done. It is more meaningful than tokens per developer because it includes failed attempts and connects spending to an outcome the organization recognizes.

A compact metric is:

`Cost per accepted task = attributable execution spend / accepted engineering tasks`

For an API-focused metric, the numerator may include model and tool charges directly generated by the selected tasks. For broader productivity analysis, we can also track CI resources and human review or correction effort separately. A narrow model-only result must not be labeled as the complete economic cost of a delivered feature.

Acceptance rules depend on the task. A bug fix could require reproduction of the defect, a passing regression test, review of unrelated behavior, a security check, and an approved pull request. A feature change might require agreed product behavior, a correct visual flow, and documented integration constraints. A generated diff on its own is an artifact, not proof of task success.

Consider a **hypothetical calculation, not a client benchmark**. Configuration A costs $2 per attempt, and 60 of 100 attempted tasks are accepted. Its model-related cost per accepted task is about $3.33. Configuration B costs $2.60 per attempt and achieves 90 accepted tasks out of 100. Its equivalent cost is about $2.89. The nominally more expensive attempt is the cheaper accepted result in this illustration. Real comparisons also account for task difficulty, time, reviews, and failure severity.

A proper benchmark therefore records more than a total bill:

- Task identifier, repository state, difficulty category, and acceptance criteria.
- Selected model, version, harness, prompts, skills, tools, and permissions.
- Turns, input and output usage, cache activity, tool runs, and retries.
- Test outcomes, regression behavior, security findings, and review effort.
- Wall-clock time, automation boundary, and final acceptance decision.
- Billed charges or a documented cost estimate with known limitations.

If the definition of an accepted task shifts between runs, the metric stops being comparable. We agree on the decision criteria before running the test and preserve the baseline configuration.

## What should a Claude Code or Codex audit actually benchmark?

A Claude Code audit, Codex audit, or coding-agent benchmarking engagement should compare configurations across the tasks your team actually performs. The main variables are the model, context strategy, skills, tools, harness architecture, execution loops, testing, and review mechanisms. Each alternative should face the same relevant acceptance and safety criteria.

**Model and version.** We look at capability, cost, latency, context handling, and failure behavior on task classes that matter. A smaller model may be suitable for bounded edits while a more capable model is justified for difficult, multi-file changes. These are hypotheses to test, not universal assignments. Model updates can also make previously useful delegation steps redundant.

**Context engineering.** Agents need enough repository knowledge to make correct changes. More context is not automatically better. We assess how instructions, code search, file selection, memory, and tool responses are assembled. A harness that repeatedly sends the same unnecessary context may increase spend without improving accuracy.

**Skills and reusable procedures.** A skill can encode a consistent workflow, but it can also create steps that duplicate the capabilities of a newer model. We test whether a procedure genuinely improves acceptance, reproducibility, or security, or only increases execution work. Removing a layer should be justified by evidence, not by a preference for shorter prompts.

**Harness design.** The harness governs how the agent plans, uses tools, delegates work, executes tests, and stops. Its behavior can dominate cost. We compare alternatives with controlled permissions and clear task boundaries, including simpler configurations where appropriate.

**Execution loops.** Reflection, self-review, retry strategies, adversarial review, and additional agents can be valuable on hard tasks. They can also repeat work without adding quality. We examine where loops increase the probability of accepted output and where they merely consume tokens and time.

**Testing and human review.** A coding benchmark that ignores quality assurance rewards incomplete work. We track whether the change passes meaningful tests and whether reviewers still need to correct it. A model-generated test suite is evidence only when the tests are independent enough to detect real defects.

AWS's [benchmark study](https://aws.amazon.com/blogs/aws-cloud-financial-management/tokenomics-for-coding-agents-benchmark-cost-and-quality-on-your-own-code/) compared **19 models** on **21 tasks** from a repository, then examined harness variation across **12 models**. Those quantities define the study's specific experiment. They show what reproducible testing can look like, not the minimum number of models or tasks every company must evaluate.

## Why public coding benchmarks are not enough for production decisions

Public software-engineering benchmarks are useful research signals, but they rarely reflect your repository, acceptance policies, security boundaries, and team workflow. They may also contain ambiguous issues, imperfect tests, or examples that models encountered during training. A private benchmark should be constructed to answer your own engineering decisions.

The limitations are substantive. In [February 2026](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/), OpenAI explained why it stopped using SWE-bench Verified to measure frontier coding progress. An audit of **138** difficult-to-solve cases found that **59.4%** of those audited problems had material specification or test-design issues. The finding applies to that audited subset, not the entire benchmark or all software tests. It illustrates why apparently objective success rates still depend on the evaluation design.

OpenAI had originally curated SWE-bench Verified to **500 tasks** from a broader set, yet later identified residual weaknesses and contamination risks. A company's private tasks reduce some public-data exposure problems, but they do not automatically fix poorly written acceptance rules. Internal benchmarks need review and maintenance too.

For practical evaluation, we prioritize:

1. **Representative tasks.** Use actual classes of changes, including routine edits, multi-file modifications, regression fixes, and difficult edge cases.
2. **Reproducible repository states.** Pin a commit or snapshot and isolate the execution environment so each candidate starts from a comparable baseline.
3. **Meaningful checks.** Use tests, policy checks, code review rubrics, and security gates that reflect the actual definition of done.
4. **Comparable cost accounting.** Include model and workflow charges consistently, and record changes in rate cards or hosting assumptions.
5. **Repeated evaluation when necessary.** A stochastic run may need multiple attempts to estimate typical behavior or identify unstable performance.
6. **Human calibration.** Review uncertain or high-consequence outputs instead of treating one automated judge as an unquestionable authority.

A good benchmark is not a leaderboard created for its own sake. It is a decision instrument for model selection, harness simplification, rollout policy, and cost control.

## Our audit method: Observe, Benchmark, Compare, Verify

Luna Nova's AI Cost & Quality Engineering method uses **Observe, Benchmark, Compare, Verify**, under continuous AI FinOps oversight. The technical cycle evaluates which coding-agent configurations produce accepted work with appropriate costs and quality. The FinOps layer connects that evidence to budgets, tool standards, and decisions about deployment.

### Observe the actual delivery workflow

We map the relevant part of the agent-assisted software development process. That can include task discovery, specification, code changes, tests, reviews, and preproduction checks. We identify where models are called, which tools and skills are used, where execution loops repeat, and how the team knows that a task has been accepted.

### Benchmark a reliable reference configuration

We select a manageable set of representative tasks from approved code or a suitable test environment. We pin the repository state, describe the success criteria, and record the current harness and model configuration. A baseline also measures retries, test outcomes, security findings, review needs, and cost, not just how quickly an agent first produces a patch.

### Compare candidate model and harness combinations

We run controlled variations using a personalized automated test bench. Possible changes include a model version, a context policy, a skill, a review step, or an execution loop. The goal is to measure each candidate fairly and reject configurations that fail important acceptance rules. A cheaper result that creates a security or quality regression is not a valid improvement.

### Verify results before considering deployment

We document the differences between the baseline and candidates, including the quality-cost trade-off and any uncertainty. A candidate that passes a scoped benchmark can be proposed for controlled wider evaluation. The client's authorized team determines the production rollout, observes real behavior, and reconciles savings against billed spend. Our automated tests do not imply autonomous changes to a client's production environment.

The cycle continues as models improve, harnesses evolve, and task mixes change. It also avoids making vendor selection a permanent strategic bet. A new model release is a reason to rerun the relevant checks, not proof that every workflow should be migrated immediately.

## How Luna Nova uses its own AI Software Factory

Luna Nova uses an internal agentic software factory in its agent projects. It combines **nine specialized agents**, visual specifications, observability, test-driven practices, and recurring evaluation. The design aims to let a Product Owner guide a feature through the necessary delivery steps toward **preproduction**, while keeping quality and security checks part of the process.

The flow starts before code generation. Clickable prototypes and flow maps help the Product Owner confirm user journeys, decisions, and acceptance rules before implementation planning. Specialized agent responsibilities cover the progression from discovery and specification through development, testing, review, deployment preparation, and verification. We do not claim this means a client can deploy independently to live production without authorized review.

The factory also provides a practical setting for testing the economics of the harness itself. Luna Nova compares model combinations, skills, delegation patterns, reflection methods, and review loops against defined tasks. The aim is to learn which structures contribute to **cost, quality, and useful autonomy**. A new model generation can change the answer, so the harness is revisited rather than treated as finished infrastructure.

This example demonstrates experience building and assessing a multi-agent delivery workflow, not a published client savings statistic. We do not publish an unverified percentage reduction or claim that a particular configuration always wins. The lesson is that agentic development needs a feedback loop for its own technical choices.

That experience informs our consulting service: we can discuss codebase-specific evaluation and harness trade-offs as practitioners, while adapting the intervention to the client's actual stack, governance, and security constraints.

## Security and quality are part of coding-agent economics

Coding-agent cost optimization must preserve the trust boundaries of the software development environment. An agent that can read a repository, execute shell commands, use credentials, and create pull requests has a different risk profile from an assistant that only suggests a code completion. Savings are not useful if they depend on bypassing controls.

An Engineering evaluation therefore needs to consider least-privilege access, isolated test environments, dependency and secret checks, change review, logging, and authorization for impactful actions. Untrusted issue descriptions, repository files, or tool output can contain instructions that should not override the agent's intended task or the organization's policies.

The [OWASP 2025 guidance on prompt injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) identifies untrusted external content, unrestricted tool privileges, and unauthorized actions as important risks. Its recommended mitigations include constrained access and human approval for sensitive operations. Those controls can influence the design and cost of a harness, so we include them in the evaluation boundary rather than treating them as optional extras.

Quality also has several dimensions. A patch may pass its immediate unit test but fail a broader integration scenario. A correct implementation may be difficult to maintain. A test can be satisfied through an unintended shortcut. We combine deterministic checks, meaningful rubrics, and human review where appropriate. This makes the comparison harder than a raw tokens-per-task ranking, but much more relevant to production Engineering.

## What does an independent coding agent audit deliver?

A focused coding agent audit gives an Engineering leader a usable map of current execution cost, a tested comparison of realistic alternatives, and a decision about which configuration deserves further work. Luna Nova's **AI Cost Optimization Audit & POC** can act as an initial engagement, scoped to a specific agent, skill, harness step, or representative workflow.

It is not a promise to replace every coding assistant or redesign the entire SDLC during a short audit. We choose a testable slice and agree on what success would look like. The exercise must fit the available access, task examples, quality checks, and engineering time.

Typical outputs can include:

- A map of the assessed coding workflow and principal cost drivers.
- A baseline including accepted tasks, retries, quality, security, latency, and cost.
- A shortlist of testable model, context, harness, or execution-loop hypotheses.
- Results from reproducible comparisons on representative development tasks.
- Documented reasons for selecting or rejecting candidate configurations.
- A recommendation for instrumentation, rollout, and further measurement.
- A practical next-step plan showing responsibilities and prerequisites.

Testing and comparison capacity are adapted to each environment. We do not promise an identical number of candidates or successful optimizations across clients. If the repository cannot be safely reproduced, or if task acceptance is not defined, we may recommend an initial measurement or evaluation setup instead of presenting an unsubstantiated financial result.

Luna Nova's service is independent in the sense that we benchmark options according to the client's needs and constraints. We do not represent ourselves as an official or certified partner of Anthropic, OpenAI, Cursor, or other coding-agent vendors. The selected configuration may remain entirely within the existing toolchain.

## Where a coding agent optimization engagement creates value

The right engagement starts with a decision that affects a material engineering workflow. Cost is a useful entry point, but it should be evaluated alongside delivery, quality, security, and developer autonomy. Different organizations will need different levels of evaluation maturity.

| Engineering situation | First useful intervention |
| --- | --- |
| Several coding-agent tools with unclear usage | Consolidate the bill and classify workflows |
| Heavy subagent or review loops | Benchmark harness stages against accepted output |
| A new model release | Recheck model, skill, and delegation combinations |
| Coding agents spreading across teams | Establish shared quality and cost baselines |
| High retry or manual remediation rates | Diagnose failure modes and task definitions |
| Agent autonomy approaching preproduction | Verify security gates and human approval boundaries |
| Single basic assistant with low usage | Prefer lightweight internal measurement initially |

A strong outcome is not merely to spend less. It is to understand what the organization pays for each accepted task and which parts of the workflow are justified by the results they produce. Some complex tasks should retain expensive models or additional reviews. Others may benefit from simpler context, fewer redundant stages, or a different harness.

The [FinOps Foundation's FinOps for AI framework](https://www.finops.org/framework/technology-categories/ai/) supports this distinction through its focus on usage attribution, unit economics, and optimization against business value. For coding agents, the business outcome is accepted engineering work rather than the number of model responses generated.

## Frequently asked questions about coding agent cost optimization

### Can you audit Claude Code and Codex without replacing either tool?

Yes. A useful audit can compare settings, models, prompts, skills, tool permissions, harness behavior, and execution loops inside the approved environment. The outcome might be to keep the current agent and change how it is used. We do not start with an assumption that switching vendors is necessary. We start with tasks, billed costs, and acceptance criteria.

### What is the difference between an agent benchmark and a model benchmark?

A model benchmark measures a model under a particular evaluation setup. An agent benchmark measures the model together with the system that gives it instructions, context, tools, retries, and reviews. Two agents using the same model can have different task costs and acceptance rates because their harnesses behave differently. For Engineering decisions, the whole workflow is usually the more relevant unit.

### Is cost per accepted pull request a reliable productivity metric?

It can be useful if tasks are reasonably comparable and acceptance criteria are stable. However, pull requests vary greatly in scope and complexity. A small formatting fix is not equivalent to a risky architectural change. We often segment tasks by type, difficulty, and quality requirement. The metric should support better decisions, not become a simplistic score for individual developers.

### Can an AI coding benchmark guarantee a savings percentage?

No. Benchmarks establish findings on defined tasks and configurations. Their results depend on repository, test quality, model versions, rates, and the selected cost boundary. A cheaper candidate may fail quality checks or become uneconomic after implementation and support costs. Only a controlled production change followed by real measurement can support a claim about invoice savings.

### What access is required for a coding agent audit?

We typically need an authorized test environment, a representative task set, information about the current agent setup, and access to relevant usage or billing records. Sensitive code and secrets remain subject to the client's security rules. Tests should avoid unintended external effects. We do not require unrestricted production credentials or permission to merge changes automatically into customer systems.

### Does this service also help build an AI Software Factory?

It helps evaluate the economics and quality of an existing or emerging agentic delivery capability. If the organization decides to extend or industrialize its harness, we can scope the necessary architecture, integration, and governance work separately. The initial audit does not promise to create a complete autonomous software factory or replace engineering teams, test infrastructure, and DevOps controls.

## Benchmark your coding agents on work your team actually accepts

The question for a CTO is not which coding agent is cheapest on a public chart. It is which combination of model, harness, context, skills, and loops reliably produces accepted changes in the team's own environment. Quality, security, and human intervention remain part of that answer.

Luna Nova brings practical AI Software Factory experience and a repeatable AI Cost & Quality Engineering approach to those decisions. Our work can begin with one representative engineering task, then expand only when the evidence supports further investment. The related [AI FinOps consulting page](https://lunanova.ai/en/ai-finops/consulting) explains how to connect the resulting cost signals to budgets and governance across teams.

**Already using Claude Code, Codex, Cursor, or agentic SDLC workflows?** [Contact Luna Nova to discuss an independent coding agent audit](https://calendly.com/luna-nova/30min). We can identify a benchmarkable task, the cost and quality evidence needed, and a realistic next step.

Related service

### AI Software Factory Cost Engineering

Measure and optimise the cost per accepted task of your coding agents, harnesses and execution loops.

[See AI Software Factory Cost Engineering](https://lunanova.ai/en/services#ai-software-factory)

## Discuss your AI project

[Discuss your AI project](https://calendly.com/luna-nova/30min)

### Technical references and further reading

- [AWS, Tokenomics for coding agents: benchmark cost and quality on your own code](https://aws.amazon.com/blogs/aws-cloud-financial-management/tokenomics-for-coding-agents-benchmark-cost-and-quality-on-your-own-code/), October 2026.
- [OpenAI, Why SWE-bench Verified no longer measures frontier coding capabilities](https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/), February 2026.
- [FinOps Foundation, FinOps for AI](https://www.finops.org/framework/technology-categories/ai/), cost attribution and unit-economics framework.
- [OWASP, LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/), trust boundaries and tool permissions.
- [AWS, Getting started with Tokenomics](https://aws.amazon.com/blogs/aws-cloud-financial-management/getting-started-with-tokenomics-on-aws/), September 2026.

[linkedin-in icon](https://www.linkedin.com/in/rikdams/) [X Twitter icon](https://twitter.com/Rik_Dams) [instagram icon](https://www.instagram.com/agenceseo.green/)

- [Offers](https://lunanova.ai/en/services)
- [Method](https://lunanova.ai/en/method)
- [Latest projects](https://lunanova.ai/en/projects)
- [About](https://lunanova.ai/en/about)
- [Contact](https://lunanova.ai/en/contact)

---

![green-seo-reforest-action](https://seotraveler.com/hubfs/green-seo-reforest-action.png "green-seo-reforest-action")

![agence-seo-1-pourcent-pour-la-planete](https://seotraveler.com/hubfs/agence-seo-1-pourcent-pour-la-planete.png "agence-seo-1-pourcent-pour-la-planete")

![agence-seo-eco-conception](https://seotraveler.com/hubfs/agence-seo-eco-index.png "agence-seo-eco-conception")

![green-seo-carbon-negative-logo](https://seotraveler.com/hubfs/green-seo-carbon-negative-logo.png "green-seo-carbon-negative-logo")

![green-seo-unesco](https://seotraveler.com/hubfs/green-seo-unesco.png "green-seo-unesco")

[Legal notice](https://lunanova.ai/mentionslegales#english) - [Privacy policy](https://lunanova.ai/confidentialite#english)

Expertise: [LLM cost optimization consulting](https://lunanova.ai/en/llm-cost-optimization/consulting) - [AI FinOps consulting](https://lunanova.ai/en/ai-finops/consulting) - [Coding agent cost optimization](https://lunanova.ai/en/coding-agents/cost-optimization)

Made with ♥ in Bordeaux and Paris, France

Copyright © 2026 Luna Nova