Hacker News Reader

Comment by nater5000 | Hacker News Reader

For a site focused on technical users, seems like a lot of people in this thread are completely lost at the idea that a single service may offer multiple pieces of software dedicated to specific use-cases.

codex: OpenAI's agent harness. The thing you typically want to interact with when you want an agent powered by OpenAI models to do stuff on your machine. Abstracts the low-level functionality of their API so you don't have to worry about it.

openai-cli: A simple CLI exposing low-level operations against OpenAI's REST API. The thing you'd use for creating lower-level scripts to directly call the completions API, administer accounts, etc.

Honestly, this is obvious by the name alone. If it's not clear to you, then this isn't for you. No need to get worked up about OpenAI releasing a piece of software where you're not the audience.

View on HN

The difference is clear for some humans. I dig it.

This is not AX (agent experience) friendly (and for some humans here too).

There is no "why" or "when" to use it in the documentation. We humans need to figure out why this is needed at what occassion to AIs.

So my point here is the bad README.

If there is an ambiguous in the doc, and what you conside ris "obvious" is not obvious for some. It's a bad doc.

-----

If I were to use this, I first have to instruct, hey Codex, for low-level API calls to bypass your harness,

1. Read docs on OpenAI CLI: (and you provide why Codex would need it) 2. install OpenAI CLI 3. Call low level APIs: instruct when to do this over going thru codex harness

It supports json/jsonl output and verbose command/subcommand help; there's a lot of churn in "how do I create clis for AX" right now, I don't know if you can point to what's good or bad beyond "machine/digestible and progressively disclosed".

Recently did a quick experiment using four python cli libraries with codex, fairly big cli surface, well-typed code with docstrings, and the differences were negligible- it came down to those two qualities specifically, and the means to those ends didn't really matter. Obviously anecdata though.

Context for AX is highly debated for sure.

The "neg diff" you see is either your harness is so well done that it takes that crappy REAME without an issue or So bad that your Harness doesn't make a diff.

You need try another experiment with more better/specific README to see if it makes a diff. If it does, then yes, README sucks else your claim would be correct.

As your experiement was "quick", I cannot really buy into your experiement yet.

The code examples from their own website show the use of cURL and this CLI are roughly as verbose. Not sure I understand the need for maintaining a CLI.

    openai responses create \
      --model gpt-6-astra \
      --input "Write a short bedtime story about a unicorn." \
      --raw-output \
      --transform 'output.#(type=="message").content.0.text'

Versus

    curl https://api.openai.com/v1/responses \
      -H "Content-Type: application/json" \
      -H "Authorization: Bearer $OPENAI_API_KEY" \
      -d '{
        "model": "gpt-6-astra",
        "input": "Write a short bedtime story about a unicorn."
      }'

Presumably OpenAI CLI would handle OAuth

you've left off the equivalent of `--transform 'output.#(type=="message").content.0.text'` from your curl operation

I didn't leave anything off, this is a direct paste from OpenAI's docs

https://developers.openai.com/api/docs?lang=curl

One nice part is the ability to run `-h` and get all of the commands/args. I wish that existed for rest endpoints too :)

The second example is leaking API keys into the OS process tree.

Significantly improved discoverability. Also, I wonder how they handle errors:

    curl https://api.openai.com/v1/resposes \
    [...]
    "model": "gpt-6-astrai",
    [...]
    
    openai resposes create \
    --model gpt-6-astrai \
    [...]

Reply on news.ycombinator.com