This release represents a comprehensive transformation of the codebase from Codex to LLMX, enhanced with LiteLLM integration to support 100+ LLM providers through a unified API. ## Major Changes ### Phase 1: Repository & Infrastructure Setup - Established new repository structure and branching strategy - Created comprehensive project documentation (CLAUDE.md, LITELLM-SETUP.md) - Set up development environment and tooling configuration ### Phase 2: Rust Workspace Transformation - Renamed all Rust crates from `codex-*` to `llmx-*` (30+ crates) - Updated package names, binary names, and workspace members - Renamed core modules: codex.rs → llmx.rs, codex_delegate.rs → llmx_delegate.rs - Updated all internal references, imports, and type names - Renamed directories: codex-rs/ → llmx-rs/, codex-backend-openapi-models/ → llmx-backend-openapi-models/ - Fixed all Rust compilation errors after mass rename ### Phase 3: LiteLLM Integration - Integrated LiteLLM for multi-provider LLM support (Anthropic, OpenAI, Azure, Google AI, AWS Bedrock, etc.) - Implemented OpenAI-compatible Chat Completions API support - Added model family detection and provider-specific handling - Updated authentication to support LiteLLM API keys - Renamed environment variables: OPENAI_BASE_URL → LLMX_BASE_URL - Added LLMX_API_KEY for unified authentication - Enhanced error handling for Chat Completions API responses - Implemented fallback mechanisms between Responses API and Chat Completions API ### Phase 4: TypeScript/Node.js Components - Renamed npm package: @codex/codex-cli → @valknar/llmx - Updated TypeScript SDK to use new LLMX APIs and endpoints - Fixed all TypeScript compilation and linting errors - Updated SDK tests to support both API backends - Enhanced mock server to handle multiple API formats - Updated build scripts for cross-platform packaging ### Phase 5: Configuration & Documentation - Updated all configuration files to use LLMX naming - Rewrote README and documentation for LLMX branding - Updated config paths: ~/.codex/ → ~/.llmx/ - Added comprehensive LiteLLM setup guide - Updated all user-facing strings and help text - Created release plan and migration documentation ### Phase 6: Testing & Validation - Fixed all Rust tests for new naming scheme - Updated snapshot tests in TUI (36 frame files) - Fixed authentication storage tests - Updated Chat Completions payload and SSE tests - Fixed SDK tests for new API endpoints - Ensured compatibility with Claude Sonnet 4.5 model - Fixed test environment variables (LLMX_API_KEY, LLMX_BASE_URL) ### Phase 7: Build & Release Pipeline - Updated GitHub Actions workflows for LLMX binary names - Fixed rust-release.yml to reference llmx-rs/ instead of codex-rs/ - Updated CI/CD pipelines for new package names - Made Apple code signing optional in release workflow - Enhanced npm packaging resilience for partial platform builds - Added Windows sandbox support to workspace - Updated dotslash configuration for new binary names ### Phase 8: Final Polish - Renamed all assets (.github images, labels, templates) - Updated VSCode and DevContainer configurations - Fixed all clippy warnings and formatting issues - Applied cargo fmt and prettier formatting across codebase - Updated issue templates and pull request templates - Fixed all remaining UI text references ## Technical Details **Breaking Changes:** - Binary name changed from `codex` to `llmx` - Config directory changed from `~/.codex/` to `~/.llmx/` - Environment variables renamed (CODEX_* → LLMX_*) - npm package renamed to `@valknar/llmx` **New Features:** - Support for 100+ LLM providers via LiteLLM - Unified authentication with LLMX_API_KEY - Enhanced model provider detection and handling - Improved error handling and fallback mechanisms **Files Changed:** - 578 files modified across Rust, TypeScript, and documentation - 30+ Rust crates renamed and updated - Complete rebrand of UI, CLI, and documentation - All tests updated and passing **Dependencies:** - Updated Cargo.lock with new package names - Updated npm dependencies in llmx-cli - Enhanced OpenAPI models for LLMX backend This release establishes LLMX as a standalone project with comprehensive LiteLLM integration, maintaining full backward compatibility with existing functionality while opening support for a wide ecosystem of LLM providers. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Sebastian Krüger <support@pivoine.art>
3.7 KiB
AGENTS.md Discovery
LLMX uses AGENTS.md files to gather helpful guidance before it starts assisting you. This page explains how those files are discovered and combined, so you can decide where to place your instructions.
Global Instructions (~/.llmx)
- LLMX looks for global guidance in your LLMX home directory (usually
~/.llmx; setLLMX_HOMEto change it). For a quick overview, see the Memory with AGENTS.md section in the getting started guide. - If an
AGENTS.override.mdfile exists there, it takes priority. If not, LLMX falls back toAGENTS.md. - Only the first non-empty file is used. Other filenames, such as
instructions.md, have no effect unless LLMX is specifically instructed to use them. - Whatever LLMX finds here stays active for the whole session, and LLMX combines it with any project-specific instructions it discovers.
Project Instructions (per-repository)
When you work inside a project, LLMX builds on those global instructions by collecting project docs:
- The search starts at the repository root and continues down to your current directory. If a Git root is not found, only the current directory is checked.
- In each directory along that path, LLMX looks for
AGENTS.override.mdfirst, thenAGENTS.md, and then any fallback names listed in your LLMX configuration (seeproject_doc_fallback_filenames). At most one file per directory is included. - Files are read in order from root to leaf and joined together with blank lines. Empty files are skipped, and very large files are truncated once the combined size reaches 32 KiB (the default
project_doc_max_byteslimit). If you need more space, split guidance across nested directories or raise the limit in your configuration.
How They Come Together
Before LLMX gets to work, the instructions are ingested in precedence order: global guidance from ~/.llmx comes first, then each project doc from the repository root down to your current directory. Guidance in deeper directories overrides earlier layers, so the most specific file controls the final behavior.
Priority Summary
- Global
AGENTS.override.md(if present), otherwise globalAGENTS.md. - For each directory from the repository root to your working directory:
AGENTS.override.md, thenAGENTS.md, then configured fallback names.
Only these filenames are considered. To use a different name, add it to the fallback list in your LLMX configuration or rename the file accordingly.
Fallback Filenames
LLMX can look for additional instruction filenames beyond the two defaults if you add them to project_doc_fallback_filenames in your LLMX configuration. Each fallback is checked after AGENTS.override.md and AGENTS.md in every directory along the search path.
Example: suppose your configuration lists ["TEAM_GUIDE.md", ".agents.md"]. Inside each directory LLMX will look in this order:
AGENTS.override.mdAGENTS.mdTEAM_GUIDE.md.agents.md
If the repository root contains TEAM_GUIDE.md and the backend/ directory contains AGENTS.override.md, the overall instructions will combine the root TEAM_GUIDE.md (because no override or default file was present there) with the backend/AGENTS.override.md file (which takes precedence over the fallback names).
You can configure those fallbacks in ~/.llmx/config.toml (or another profile) like this:
project_doc_fallback_filenames = ["TEAM_GUIDE.md", ".agents.md"]
For additional configuration details, see Config and revisit the Memory with AGENTS.md guide for practical usage tips.