Hi everyone! I’m working on the OpenAI CLI, which lets you use the OpenAI API from your terminal.
I’d love to hear how you use it and what would make it better. Are there workflows that are difficult, features you’d like, or bugs you’ve run into?
You can reply here or open an issue on GitHub: GitHub - openai/openai-cli: Official CLI for the OpenAI API · GitHub
Thanks for inviting developer feedback! I reviewed the repository, and it’s encouraging to see the ongoing improvements around project configuration, cost reporting, and workflow automation.
One area worth prioritizing is request reliability and predictable behavior, especially when the CLI is used in scripts, CI/CD pipelines, or AI-driven development workflows.
I noticed “Issue #345” (Free-text values for --input, --stop, --prompt and other union flags are parsed as YAML and silently rewritten · Issue #345 · openai/openai-cli · GitHub), which describes how free-text input can be silently interpreted as YAML, potentially changing the intended request.
I’d suggest two related improvements:
- Explicit input handling: Preserve literal text by default, and require explicit selection when structured JSON/YAML parsing is intended.
- Safe request preview (“–dry-run”): Allow developers to inspect and validate the final request payload locally before execution, without making an API call, while automatically redacting sensitive information.
These improvements could make OpenAI CLI more predictable, testable, and reliable, particularly as a component in larger automated workflows.
Thanks for the continued development and for actively listening to the community!
Hi @vguvvala and welcome to the community!
This is great, it simplifies lot of the admin and testing with a single command line tool.
One thing that’s always been lacking for me and I had to build myself is a model experimentation harness. So as new models and checkpoints come out, I want to be able to quickly evaluate. We could have something like this:
openai compare \
--models gpt-6.1-sol,gpt-5.6,gpt-6-astra \
--dataset test_cases.jsonl \
--metrics latency,cost,tokens \
--output results.json
Another interesting feature is to easily wrap/package all your config and prompts. If you are running something and you are happy with it, you can package the sampling parameters, model configuration, all your prompts, into a YAML file, and then version control that or take it with you.
At work I tend to use OpenAI models in cloud providers so it would be nice to have them as 1st class citizens rather than muck around with environment variables. So e.g. openai --provider bedrock --region XXXX and same for azure (and eventually GCP).
Thanks for the initiative @vguvvala!
A couple of things I’ve noticed, both from personal experience and other users’ reports:
1. Better visibility into reset expiration
It can be confusing to know exactly when resets expire, especially across different time zones.
- Perhaps
/usagecould show a list of available resets, their expiration timestamps, and a countdown in the user’s local time zone. - It might also be useful to display a small warning when opening the CLI if a reset is about to expire (within 24 hours, for example).
2. Per-thread usage information
Currently, /status shows the thread ID, but perhaps it could also show how many tokens that thread has consumed, in a way that’s easier to understand (and share).
- Some third-party tools already attempt to provide this, but having it natively in Codex CLI would be helpful.
- I’ve seen users report that a single task consumed their entire usage allowance, without really knowing why.
- Having more visibility into usage per thread could help users understand which activities consume more tokens and adjust their habits accordingly. The overall usage percentage is helpful, but it doesn’t tell the whole story.
- This could also help the community troubleshoot these reports. Currently, there often isn’t much we can do beyond directing users to support, since many different factors could explain why their usage limits were depleted.
@aprendendo.next this is actually related to OpenAI CLI not Codex CLI 
OpenAI CLI is a new tool released which basically provides a CLI for API requests. I guess you can have --usage etc.
like … I dunno … Codexometer ?
like … I dunno … Codexometer ?
Wouldn’t it be great if that was open source, free to download, well supported and had already gained a few GitHub stars from happy users … ? 
Hi @vguvvala. From an end-user’s perspective, @techsoft.ye’s request preview and @platypus’s saved configurations and model comparisons fit together.
What would help me is a clear link between the request I reviewed, what was actually sent, and the result. The existing JSON output and custom headers provide useful pieces. Could there be an optional structured run record that brings those together, including the CLI version, model requested and reported by the API, effective settings, request identifier, and any retries or incomplete results? Users would need control over what sensitive information is retained.
For example, after a model or CLI update, I would want to rerun the same sample inspection reports and check whether the required findings and uncertainties were still preserved. Cost and speed matter, but so does whether the result continues to meet the task’s requirements.
Making that record available to a separate checking process would help an organization retain control over approval and evaluation while using the CLI within its own workflows.
Oh, I see, my bad. Too many similar names haha
Ok sure but they are referring to this repo now: GitHub - openai/openai-cli: Official CLI for the OpenAI API · GitHub
Still, after moving the bloat, CLI is naturally referring to a tool that needs remembered command line interpreter arguments in order to work and run a 0-shot or single API task.
I prefer if a terminal-based tool, that it offers a prompt shell. Ruins the name CLI - and ruins piping and scripting that nobody would do with CLI.
Easier to chat.
(and yes, I could pump the stream output thru markdown-highlighting word wrap)
But work without GUI is a straightjacket. CLI is worse. Am I going to remember the cookbook example?:
openai batches list --limit 20 --max-items 20
openai batches retrieve --batch-id batch_example
openai --format json batches retrieve batch_example
Or just run 2kB of Python for the job (from 2024) that doesn’t require "openai" or my memory of command line args or transporting long IDs between those at all?
Naw, this is 2026, I’ve got another way available to avoid CLI pain to make batches calls almost faster than finding an old script in “/api/examples” - ask AI for my file name to be coded in the terminal.
Sorry about the image pastas instead of terminal text copied, but it lets you ignore me and my non CLI use that demonstrates more specialized terminal app is ready to be written by AI, with or without interactivity, faster than figuring out wget the openai-cli.
no worries haha, the names are pretty similar!
thanks for clarifying that!
thanks for sharing codexometer!
oh interesting, thanks for sharing the history!