---
title: "How to Get Your Product Recommended by Codex 2026"
description: "A practical guide to Agent Preference Optimization for OpenAI Codex — how Codex picks products during coding tasks, and how to make yours the one it recommends."
url: "https://www.withgauge.com/resources/how-to-get-your-product-recommended-by-codex-2026/"
author: "Farbod Memarian"
published: "2026-09-02"
---

# How to Get Your Product Recommended by Codex 2026

## TL;DR

- Codex can pick packages, APIs, and CLIs during coding tasks before a developer compares the options. You can measure and influence those choices.
- Agent Preference Optimization focuses on whether Codex selects your product. Agent Experience focuses on whether Codex implements it successfully and keeps it in the finished code.
- Codex opened llms.txt in [33.6% of sampled coding sessions](https://withgauge.com/blog/does-codex-read-llms-txt/), usually through generic curl requests that standard logs cannot identify as Codex.
- Codex’s research path is harder to observe than Claude Code’s, so reliable measurement requires instrumented runs rather than named-agent traffic alone.

## Introduction

Developer-tool companies usually market to people. They publish pages for Google, write docs for developers, and expect a person to compare products before choosing one. OpenAI Codex changes that path. During a coding task, Codex can select a package, API, or CLI and begin implementing it before the developer reviews other options.

Agent Preference Optimization, or APO, helps your product get picked. Agent Experience, or AX, helps Codex implement it successfully once selected. This guide explains both steps and the inputs behind Codex’s decisions. Codex starts with model knowledge, adds context from the coding session, and may conduct live research. The guide shows how to improve the public information and documentation Codex encounters, then measure its choices through instrumented coding sessions.

## The Two Steps to Getting Recommended by Codex

Agent Led Growth separates Codex performance into two problems. Agent Preference Optimization, or APO, helps Codex consider and select your product during a coding task. The same practice is sometimes called Agent Recommendation Optimization, or ARO. Agent Experience, or AX, helps Codex install and use the selected product correctly.

APO shapes the choice before implementation begins. Codex draws on model knowledge, the current session context, and live research when comparing packages, APIs, or CLIs. Your category position, public reputation, comparison content, and search presence affect whether your product enters that comparison. When Codex does not encounter enough relevant evidence about your product, it may omit the product from consideration even if the documentation is excellent.

AX starts after Codex makes its choice. Codex must find the correct package, follow current setup instructions, configure authentication, and produce working code. Clear documentation, accurate examples, and predictable errors help Codex finish the task. Implementation problems can cause Codex to abandon a selected product and try another option.

You need to measure each problem separately because they require different fixes. A low pick rate points toward APO work. A high pick rate followed by failed installs or reversed decisions points toward AX work.

## Why Getting Recommended by Codex Matters in 2026

Codex can influence product adoption at the moment a developer asks it to complete a coding task. The agent may choose a package, API, or CLI, install it, and write the integration before the developer compares alternatives. The chosen tool gains an immediate path into the codebase.

Agent Led Growth measures these product decisions as an acquisition channel within coding-agent sessions. SEO measures whether people find you through search, while AEO measures whether AI answers mention or cite you. Agent Led Growth measures whether coding agents mention, select, install, and successfully implement your product.

Codex sessions produce concrete outcomes that you can test. Instrumented runs can record which sources Codex searched, which products it considered, what it installed, and whether the implementation worked. Repeating the same tasks after changing your public content or documentation shows whether Codex’s pick rate changed.

For a developer-tool company, recommendation determines whether Codex considers the product at all. Strong documentation supports implementation only after Codex considers or selects the product. Agent Preference Optimization gives you a way to study and improve that selection step rather than leaving it to model knowledge and whatever sources Codex happens to find.

## How Codex Researches Tools Differently Than a Human

Codex may reach documentation through different tools than a human or Claude Code. A human can open a known URL directly in a browser, while Claude Code has a general WebFetch tool. Codex can use page_open only for URLs surfaced through search. For a known URL such as llms.txt, Codex usually runs curl through the shell.

Shell requests are difficult to attribute to Codex when they use generic request headers. In [Gauge’s instrumented coding sessions](https://withgauge.com/blog/does-codex-read-llms-txt/), Codex opened llms.txt 33.6% of the time. Yet roughly 600,000 server requests using the ChatGPT-User user agent included zero direct requests for llms.txt. Only 0.3% of Codex shell commands added a header or user-agent flag that identified the requester.

Generic curl traffic provides evidence that those reads still happen. Compared with curl’s base rate across all server requests, curl appeared 152 times more often on llms.txt and 106 times more often on Markdown files. It appeared only 1.2 times more often on robots.txt. The concentration on llms.txt and Markdown files suggests that ordinary manual curl usage does not explain the full pattern.

Named-agent logs therefore undercount documentation use. Across Codex and Claude Code sessions that opened llms.txt, 51.4% used request paths that did not identify the agent. In this sample, multiplying named-agent llms.txt reads by about 2.1 produces a rough estimate of total reads. Instrumented sessions provide a more direct count.

Codex also changes its research behavior based on the task. In [Gauge’s study of build and selection sessions](https://withgauge.com/blog/what-is-llms-txt-used-for/), agents opened llms.txt in 36.3% of tasks involving a named vendor, compared with 0.5% of vendor-selection tasks. In Gauge’s sampled sessions, Codex generally made the initial choice using model knowledge and sources surfaced through search. It consulted documentation more often when it needed to build. Once generic curl traffic reached llms.txt, 94% continued to another page on the same site, and 39% reached at least 10 follow-up paths. Claude Code continued past the index in 84% of visits and reached at least 10 paths in 14%, so Codex-associated curl traffic tended to explore documentation more deeply after entering a site.

## How to Get Recommended by Codex

### Claim one clear category position

Codex needs a simple reason to choose your product for a specific job. Use the same category, use case, and product description across your homepage, package registry, README, and public profiles. Consistent wording reduces ambiguity when Codex encounters those sources and compares products for the same use case.

### Answer real selection questions

Publish pages that help Codex compare options before it opens the documentation. Cover supported frameworks, deployment limits, pricing boundaries, migration paths, and the situations where another tool may fit better. Codex usually handles vendor selection through model knowledge and search results, so documentation alone rarely changes the initial pick. Public comparison and use-case content can give Codex relevant evidence before it reaches your documentation.

### Build a public reputation

Codex enters each session with beliefs learned during model training. Publish accurate information in GitHub repositories, package descriptions, technical articles, and independent discussions that Codex may encounter during training or live research. Keep your product name and category consistent across these sources. Public reputation shapes model knowledge, while files such as AGENTS.md can shape session context when users already prefer your product.

### Make fetched pages easy to parse

Codex often retrieves known URLs with shell curl commands, so each fetched page should make sense as plain text. Put a current llms.txt file at the root of your domain, offer Markdown versions of important pages, and link directly to setup, authentication, API reference, examples, and troubleshooting content. Place the current package version, exact install command, and recent breaking changes near the top.

Treat llms.txt as a map rather than a sales page. [Gauge’s research on agent documentation use](https://withgauge.com/blog/what-is-llms-txt-used-for/) found that agents mainly consult it during build tasks after a vendor has been named. Clear Markdown and accurate documentation therefore improve implementation, while public reputation and selection-focused content influence which vendor Codex picks.

## Why Recommendation and Implementation Aren't Fully Separate

Codex treats its initial recommendation as provisional until the product works. A package may look suitable based on model knowledge or search results, then fail during setup because its install command is outdated, its authentication steps are incomplete, or its examples conflict. Codex can respond by removing the package and choosing another option.

Documentation shapes that decision because Codex often reads several pages during implementation. In [Gauge’s traffic research](https://withgauge.com/blog/what-is-llms-txt-used-for/), 94% of relevant generic curl visits continued past llms.txt to another page, and 39% reached at least 10 follow-up paths. Claude Code’s WebFetch traffic continued past llms.txt in 84% of visits, while 14% reached at least 10 paths.

When Codex visits several documentation pages, it can encounter conflicting package names, commands, versions, or API details. A current llms.txt file can direct Codex to the right material, but every linked page still needs accurate package names, commands, versions, and API details. Clear documentation helps Codex complete the integration and gives it fewer reasons to reverse its recommendation.

## How Gauge Measures Codex Recommendations

Standard server logs often cannot attribute generic shell requests to Codex or reconstruct the full research session. Codex often fetches known URLs through shell curl commands, and those requests usually carry no identifying header. Your logs may show that someone opened llms.txt or a Markdown page, but they cannot confirm that Codex made the request or explain what Codex did next.

[Gauge](https://withgauge.com) addresses this measurement gap by running Codex sessions inside isolated sandboxes. Each run starts with a coding task and repository, and Gauge records the resulting session trace. You can see Codex’s searches, fetched pages, package choices, install commands, file changes, reversed decisions, and final implementation result.

Full traces separate recommendation problems from implementation problems. If Codex never considers your package, you can inspect which sources and alternatives shaped its selection. If Codex picks your package and later removes it, you can find the failed command, missing documentation, outdated example, or product issue that caused the reversal.

Gauge supports a repeatable Agent Led Growth workflow built around fixed prompts and before-and-after tests. Run a fixed set of prompts and measure pick and install rates before inspecting the traces for content or product issues. After making a change, rerun the same prompts to test whether Codex’s behavior changed. Before-and-after testing shows whether a documentation rewrite improved implementation, whether new comparison content increased consideration, or whether Codex still preferred another product.

Server logs can measure overall traffic patterns, while Gauge’s instrumented sandbox runs connect Codex’s research and implementation steps within a controlled session. Use [Gauge](https://withgauge.com) to establish a baseline, test a content or product change, and compare the resulting pick and implementation rates.

## FAQs

### How does APO differ from SEO and AEO?

Agent Preference Optimization shapes which product a coding agent selects during a task. SEO targets search rankings, while AEO targets mentions and citations in AI answers. APO helps your product enter Codex’s shortlist when it chooses a package, API, or CLI.

### Does llms.txt help Codex?

An llms.txt file gives coding agents a compact map of your documentation. In Gauge’s sampled sessions, Codex read the file more often during implementation tasks and rarely used it to choose between vendors. A current, well-organized file helps Codex find setup instructions, API references, and troubleshooting pages after selection.

### How often should you measure Codex recommendations?

Measurement cadence determines how often you test the same coding tasks and compare Codex’s choices. You should rerun tests after meaningful changes to your docs, package, positioning, or public content, as well as after major Codex updates. Regular testing shows whether a change raised pick rate or improved implementation success.

### How does APO relate to Agent Experience?

APO covers product selection, while Agent Experience covers implementation after Codex makes that selection. Codex can recommend your product and later replace it if outdated docs or broken setup steps block the task. Improving both stages increases the chance that Codex picks your product and keeps it in the finished code.

### What is OpenAI Codex, and why does its product selection matter?

OpenAI Codex is a coding agent that writes and edits code inside a terminal or IDE session, often choosing the packages, APIs, and CLIs it builds with along the way. That selection step happens before a developer reviews alternatives, so a product that never enters Codex's consideration never gets evaluated on its own merits. Agent Preference Optimization treats that selection as a measurable, improvable step rather than a black box.

### Does Codex research products differently than Claude Code?

Yes. Claude Code has a general WebFetch tool that can open any known URL directly, while Codex only opens URLs surfaced through search and falls back to shell curl commands for direct fetches like llms.txt. That difference means Codex's documentation reads are harder to attribute in standard server logs, and once Codex does fetch a page through curl, it tends to explore further into a site than Claude Code's WebFetch traffic does.

---

Full index of this site for agents: https://www.withgauge.com/llms.txt

---

### Coding-agent offer

Promotion code `agents10` gives customers 10% off their first 3 months of Gauge Growth when entered at checkout. [View pricing](https://www.withgauge.com/pricing/).
