diff --git a/devlog/_plan/261022_spanish_split/010_plan.md b/devlog/_plan/261022_spanish_split/010_plan.md
new file mode 100644
index 00000000000..8ed2994ebd2
--- /dev/null
+++ b/devlog/_plan/261022_spanish_split/010_plan.md
@@ -0,0 +1,1351 @@
+# Spanish localization: split after #7406
+
+## Delivery order
+
+The owner closed #7406 on October 22 because its combined locale changes were
+too broad for the review queue and conflicted with dev. The original published
+branch stays intact. Recover the contribution in independent branches rooted at
+current dev, starting with the documentation site as requested:
+
+1. `codex/spanish-docs`: docs-site Spanish, directly related canonical/translated
+   documentation corrections, and the existing documentation regression guards.
+2. `codex/spanish-dashboard`: shared Desktop/browser dashboard locale, total
+   auxiliary maps, formatting, tests and the dashboard contract.
+3. `codex/spanish-readme`: README translation/navigation/manifest and its guard.
+
+Submit the first PR first. Preserve the later branches without opening multiple
+review requests at once. Each submission must refresh dev and revalidate its
+own diff; a clean merge today does not guarantee compatibility with future dev.
+
+## Documentation base and scope
+
+Initial base: `782655d2317d4c14a99d6db72e9be3368a27886d`, 23 commits after the combined
+PR's last integration base. Before submission dev advanced to
+`5f7f7db5765c7e99ab2f52c04d9fe0e4ce7608cf`; it was merged and its published
+macOS storage-refusal clarification was synchronized in Spanish. Recovered changes use that base's files and retain
+its new CLI registration and fallback navigation. The docs branch changes no
+dashboard catalog, backend source, dependency, release or workflow implementation.
+
+Spanish covers all 74 current canonical paths, including the new fallback guide.
+The refresh includes Remote Link peer versions, Windows refusal/recovery, apply
+digests, client restart, service/install JSON and Claude reasoning details.
+The sidecar note distinguishes web-search xAI from routed vision in both English
+and Spanish. Other latest findings fix product metadata, prose number separators,
+the plugin `name` string, and Pi loopback examples in all translated guides.
+The timezone-dependent GUI test belongs to the separate dashboard branch.
+
+## Validation receipts
+
+- Frozen root/docs installs: no dependency or lockfile changes. System Bun is
+  1.4.4; tests use the required Bun 1.4.3 in ignored scratch space. Its official
+  archive SHA-256 was verified against the GitHub release asset digest.
+- Root `bun run typecheck`: passed.
+- Final Spanish docs after the Pi contract guard: 15 passed, 0 failed (2,126 assertions).
+- Structure and privacy scan: passed on staged files.
+- Actual-browser inspection: Spanish landing/fallback guide at 1366 px, Pi at
+  390 px, localized code controls, no horizontal page overflow, and 17 Spanish
+  Pagefind results for fallback. Captures remain outside the source branch.
+- Initial Spanish docs and both layout tests: 41 passed, 0 failed.
+- All docs guards, structure/hygiene/size and CLI export: 445 passed, one size
+  scan timed out while the docs build was running. Isolated size-guard retry
+  with `--timeout 120000`: 9 passed, 0 failed; repository scan took 691 ms.
+- `OPENCODEX_DOCS_OFFLINE=1 bun run build`: 667 pages and 97,587 checked internal
+  links; Pagefind and sitemap completed. Existing unsupported sshconfig
+  highlighting falls back to text.
+
+The full root suite is not claimed passing for this branch. The preceding
+combined-PR run hit its 900-second limit, with Windows symlink EPERM and timing
+failures. This documentation-only split uses the root policy's resource
+exception with explicit source-reading guards and exporter regressions instead.
+Exact-head upstream CI and independent human language/render acceptance remain
+required. No native Desktop acceptance is claimed.
+
+## Review hold
+
+Keep the first submission Draft for owner/localization acceptance. Do not reuse
+old CI receipts as validation of a new head. Do not repeatedly request bot
+reviews or wait for their completion after publication; the contributor will
+inspect the result. Screenshot evidence belongs outside the feature branches.
+
+## PR #7559 consolidated review correction
+
+Reviewed all 36 CodeRabbit threads against canonical English and, for operational
+claims, the current service guards, stop path, sidecar settings and CI workflow.
+The corrections cover authentication, service repair/restart, search disable and
+journal recovery, preview exit codes, adapter contracts and Spanish terminology.
+Two suggested premises needed qualification: explicit `ocx stop` stops a managed
+service and then restores native Codex; a valid refused preview can exit 0 because
+inspection succeeded without applying a change. Neither was changed into the
+incorrect behavior suggested by the review wording.
+
+The adjacent semantic pass also restored default-off wording for subagent force,
+native subagent defaults, native WebSocket controls and custom context inference.
+It checked account/queue/adapter state distinctions and removed unavailable
+benchmark-filter instructions from every locale. The current backend, dependency
+and workflow implementations remain outside this contribution.
+
+Merged dev at `ec8b8cfac11e8f179c4351f01baa32d76a71dd1b`, preserving both the new
+chat layout shard and this branch's docs shard, then at
+`9164950d926c770875a267edfeb74183af5caebc` and the docs-only update
+`880127dbd356c720779222a14a97c11adc8cf881`. Spanish now includes Desktop
+picker-state uncertainty, Antigravity family-quota evidence and the five-slot
+`spawn_agent` model-selection rules, including both account-selector cases.
+
+Current validation: frozen root/docs installs, root typecheck and structure check
+passed. The explicit docs/layout/hygiene/export/preview/service-auth group ran 588
+tests: 587 passed and the repository file-size scan timed out under the parallel
+runner. Its isolated retry passed all 9 cases, with the repository scan completing
+in 602 ms; no size cap or guard was changed. The root-suite resource exception
+above still applies. The final Spanish-doc regression run passed all 15 tests
+(2,132 assertions). The final offline site build completed with 667 pages and
+97,652 checked internal links, Pagefind and sitemap. Desktop authentication and
+service-token sections, mobile sidecar controls, six rendered coding benchmark
+boards and Spanish search results were inspected in the real browser. The token
+search returned 49 results. Screenshot evidence is pinned outside the source
+branch at `588c95e9e636700f2035311017328d5670451e4a` on `pr-assets`.
+Privacy scan and diff whitespace checks passed. Keep the Draft and independent
+human language/render-acceptance hold; an agent's inspection is not that approval.
+
+## PR #7559 owner-requested refresh, October 24 (UTC)
+
+Addressed the owner's [October 24 UTC triage comment](https://github.com/lidge-jun/opencodex/pull/7559#issuecomment-6378349500).
+Merged `dev` first at `2494848f56e8a4f283722b2ebd816977e828c7af`, then at
+`ceef4889e4666dc0492a375d272eafa5b785361e` (2.93.0), preserving published history.
+All eight upstream test-layout shards remain byte-for-byte identical to that
+base; the Spanish documentation shard is appended without dropping any shard.
+The provider documentation retains upstream's new Alibaba Token Plan section.
+
+Corrected the remaining nonblank condition in `es/reference/adapters.md`: a
+string must contain a non-whitespace character to be converted, while empty and
+whitespace-only strings remain unchanged. The existing runtime regression file
+checks those cases and exact whitespace preservation. Updated Spanish to match
+current JEV session pinning and saved strategies, Antigravity per-account model
+availability, provider discovery and credits, Hermes affinity, native effort
+normalization, Remote Link readiness/retry diagnostics, and the Bun 1.4.4 runtime.
+The landing also translates the new code-signing-policy link while retaining the
+required English signing attribution verbatim.
+
+Validation for this refresh:
+
+- Frozen root, GUI and docs-site installs passed; no contribution-owned lockfile
+  or dependency changes. Tests use isolated Bun 1.4.3 through `scripts/test.ts`.
+- All docs guards plus layout, structure, hygiene, routed-agent conversion and
+  CLI-export regressions: 512 passed, 0 failed, 4,661 assertions across 20 files.
+- Separate file-size guard: 9 passed, 0 failed, 85 assertions. No cap changed.
+- After the final upstream merge, fixture teardown, Codex auth-context and
+  server-management-auth regressions: 143 passed, 0 failed, 693 assertions.
+- After the final Spanish edits, the Spanish documentation guard was rechecked:
+  15 passed, 0 failed, 2,138 assertions. These 15 are already included in the
+  512-test group and are not an additional coverage count.
+- Root typecheck and structure check passed again after the final upstream merge.
+- The offline documentation build checks all 667 pages, internal links, Pagefind
+  and sitemap. Final build and staged privacy-scan receipts are recorded in the
+  PR's Verification section before publication.
+- Actual-browser DOM checks confirmed the corrected adapter paragraph and JEV
+  section, Spanish language metadata, mobile navigation, and no page overflow at
+  1366px and 390px. The browser screenshot service returned "Unable to capture
+  screenshot", including on a fresh tab, so this refresh has no new capture and
+  does not claim fresh visual acceptance. Existing captures stay on `pr-assets`.
+
+The documented full-root-suite resource exception still applies. Hosted CI for
+the new exact head, including the owner's requested `lane=all`, requires
+maintainer authorization. Human Spanish/render acceptance and fresh review are
+still pending; keep Draft and do not describe a skipped bot review or an
+`action_required` workflow as passing. Request one consolidated CodeRabbit
+review after publication without waiting for its result.
+
+## Consolidated language and contract review, October 24
+
+The contributor authorized corrections after a read-only audit of the completed
+[CodeRabbit review](https://github.com/lidge-jun/opencodex/pull/7559#pullrequestreview-5636437341).
+Its eleven inline findings and two outside-diff findings are addressed together:
+native-context activation and trial wording, the Droid bridge limitation,
+code-mode tool names, architecture metadata, live/offline CLI management,
+cleanup preview behavior, catalog-refresh exit codes, empty effort lists,
+current bundled Bun, the localized signing-policy link, and log scan limits.
+Both files reported for missing final newlines were confirmed and corrected.
+
+The service-install caution was checked against `src/service/cli.ts`,
+`src/service/orchestration.ts` and `src/service/health.ts`: installation stops
+the tracked standalone listener before loading the managed service, then probes
+the installed service port. English and Spanish now explain that handover and
+show a post-install service-status check. This documents existing behavior.
+
+Read CodeRabbit's official [command reference](https://docs.coderabbit.ai/reference/review-commands),
+[configuration reference](https://docs.coderabbit.ai/reference/configuration),
+[path instructions](https://docs.coderabbit.ai/configuration/path-instructions)
+and [pre-merge checks](https://docs.coderabbit.ai/pr-reviews/pre-merge-checks).
+The repository uses the assertive profile and disables automatic Draft review.
+Keep those settings intact. Add useful docstrings to the changed localization
+and parity helpers instead of suppressing coverage checks. Publish one
+consolidated update and request one full review, rather than triggering reviews
+on a sequence of partial pushes. A full review is not an exhaustive guarantee.
+
+Merged current `dev` at `26598df2c4c07d781e344ac6119953fed77ecb27`,
+preserving the complete upstream test-layout roster and this branch's docs shard.
+Spanish now includes JEV pin-editor validation, Qoder provider-only catalogs and
+replay-envelope refusal, connected-client stop preservation, account-slot
+identity and headless listings, safe subagent limit conversion, edited-value
+ownership, the native context-window override, Kimi K3.1 pricing and the
+display-only Business Premium capacity weight.
+
+The broader pass examined every page's metadata, ran command/identifier/link
+parity across all 74 canonical paths, checked negation candidates against their
+English paragraphs, and reviewed operational contracts in the affected guides.
+It corrected literal mistranslations in model names, protocol terminology and
+negative conditions, plus unclear recovery and cost-limit wording. Only the
+two current-bundle statements in each Windows-memory guide changed version;
+historical Bun observations remain historical. A manifest-derived regression
+now covers those statements to prevent the same version drift.
+
+Frozen installs, typecheck and structure checks passed. The expanded docs,
+layout, hygiene, routed-agent, CLI-export, combo-target and service-preflight
+group passed 556 tests with 5,043 assertions across 23 files. The direct
+file-size-ratchet command passed; its first test scan exceeded 120 seconds
+(8 passed, 1 timeout). The separate retry after the build passed all 9 tests
+(85 assertions; repository scan 611 ms), without modifying a cap. Final Spanish
+parity and CLI combo-file validation passed 68 tests (2,304 assertions); the 15
+Spanish cases overlap the first group, while the 53 combo cases are additional.
+The build completed with 667 pages, 97,690 checked internal links, Pagefind and
+sitemap. All nine landing locales were checked for an existing localized
+signing-policy target or the canonical fallback, retaining the required signing
+attribution. The full-root-suite resource exception remains explicit; no
+old-head CI is presented as validation of this update.
+
+Actual-browser inspection confirmed the Spanish signing-policy navigation,
+1280px landing and policy layout, 390px native-context rendering and mobile
+navigation without page overflow, and 41 Spanish Pagefind results for context.
+Fresh screenshots are published on the separate `pr-assets` branch, not this
+source branch. The inspection also found and corrected the hero's accessible
+English conjunction and untranslated beta announcement.
+
+Federico's human Spanish acceptance was recorded on the preceding published
+head. The current correction is not a claim that he executed a new browser or
+native Desktop test. Keep the fresh-review and maintainer-acceptance gates open
+until their actual outcomes are available.
+
+## Final upstream refresh and verification, October 25
+
+Before publication, `dev` advanced another 25 commits. Merged
+`8ebe46b2076445d100cef1e52af4d98d78f8f1e1` without conflicts and retained the
+upstream layout shards. Synchronized the nine changed canonical pages:
+contribution/test-runner guidance, hard-lock candidate inspection, Hermes named
+profiles and marketplace detection, Moonshot K3.1 seeds, Pi startup failures,
+native citation projection, expected-Home sync flags, Kiro overage refusals,
+and response-download backpressure. The test runner pin is now Bun 1.4.4,
+matching the shipped runtime; the Spanish contributor version is covered by
+the manifest-derived regression. Also clarified Kimi cache-key rejection,
+effort-only LazyCodex saves, and identical-catalog no-op behavior.
+
+Final frozen installs changed no dependencies. Typecheck and structure checks
+passed. Under the current 1.4.4 pin, the focused docs/layout/CLI/service group
+passed 611 tests (5,218 assertions, 24 files). Eight additional relevant runtime
+files passed 181 tests (3,465 assertions), including Hermes profiles, guarded
+sync, Kiro, native compact and pinned HTTP. After the final prose edits, the
+Spanish and Bun guards passed 18 tests (2,155 assertions), overlapping the first
+group. The first file-size repository scan exceeded 120 seconds (8 passed,
+1 timeout; 172 seconds observed in the case). The direct ratchet command
+passed, then an isolated retry passed all 9 tests (85 assertions; repository
+scan 447 ms), without a baseline or cap change. These results cover 801 unique
+focused cases; they do not claim a full-root-suite result or establish the
+cause of either earlier scan timeout.
+
+The final offline build completed with 667 pages, 97,705 checked internal links,
+Pagefind and sitemap. Actual-browser inspection checked the newly synchronized
+Hermes and expected-Home sync sections at 390px and recaptured the Spanish
+landing at 1280px. The browser viewport was restored afterward. The additional
+captures are on the fork's separate `pr-assets` branch at
+`73c6b4592d0bd103c9717d049a0c6020b0321dd9`, under `spanish-docs-20261025/`;
+no image is added to this source branch.
+
+Publish the correction commits together, document staged privacy validation,
+resolve the eleven corrected inline threads, and request one full review.
+Do not wait for CodeRabbit's result. The full-root resource exception,
+authorized current-head CI, requested manual `lane=all`, and maintainer
+acceptance remain explicit gates; the PR stays Draft.
+
+## Consolidated review correction, October 26
+
+The contributor authorized correcting the eight new inline findings from the
+completed CodeRabbit review of `8400645a26c36520f5df33ece80c8f49ed0c47b5`.
+Merged 33 newer `dev` commits through
+`81ce59591c06b2f1bde71748588fda69078662a2` (2.93.0), preserving history in
+`f462c6907a898dc5a324a1032043daf923d48828`. The only conflict appended both
+the upstream combo shard and this contribution's docs shard. The resulting
+roster, all upstream shard contents, and the expected fixture roster were
+compared with upstream; no upstream entry was dropped.
+
+The eight corrections cover prompt-base replacement, separate foreground Hub
+and dashboard terminals, Stop ownership/refusals, cost coverage, proxy precedence,
+sidecar save/apply receipts, Advisor failure/retry behavior, and manual Desktop
+update instructions. English is clarified where it also obscured existing
+behavior; the two-terminal correction is applied across all nine physical
+documentation locales. No runtime or CI policy is changed by this contribution.
+
+The cost explanation was verified against `src/usage/summary.ts` and its cost
+regressions. A known-zero-spend refusal is not unknown potentially billed work;
+it does not make a subsequently measured attempt unpriced. A row consisting
+only of known-zero refusals contributes no measured request fact, and a summary
+containing only those rows is unmetered. A cancellation or unmeasured upstream
+attempt can still be potentially billable. The updated prose preserves these
+distinct cases rather than treating every failed request alike.
+
+Reviewed the complete prompt-layer and Advisor guides against current English
+and the relevant runtime. Corrected additive layers versus replacing variants,
+account attribution, repair/ownership, cached skill catalogs, unquoted JSON keys,
+consultation deduplication, and task continuation after an unavailable preflight.
+Actual-browser inspection also exposed mistranslated Remote Workspace grant,
+prompt-acceptance, hard-link, ordered-message and containment language. Rechecked
+that complete guide against English, retaining all commands and identifiers.
+Escaped the English and Spanish `<default>` labels so their text renders instead
+of being interpreted as HTML.
+
+Synchronized the 18 canonical pages changed by the new upstream commits. Spanish
+now includes Flex selection, opt-in combo cooldown reprobes, JEV Decisions
+validation, Qoder/WorkBuddy homes and admission, provider seed repairs, MiniMax
+retirement, Antigravity Chat limits, literal SSH Include paths, retired OpenCode
+sidecars, restart handover, native compaction/tool rules, WebSocket liveness,
+effort floors, Cursor globs and Windows launcher/update process-tree behavior.
+
+The existing docs guard now exercises separate foreground/GUI blocks in all
+nine locales. Its code-span scanner correctly treats backslashes inside code
+spans as literal, including a trailing-backslash path followed by identifiers.
+The regression rejects an altered later identifier while preserving escaped
+prose openers. This follows CommonMark 0.31.2 section 6.1; the helper remains a
+technical-parity scanner, not a general Markdown parser. All 74 paths retain
+command-block and inline-identifier parity.
+
+Frozen root, GUI and docs installs passed without lockfile changes. Bun 1.4.4
+matches the test/runtime pin. Typecheck, structure and the direct file-size
+ratchet command passed without changing a cap. The isolated wrapper was used
+for all tests:
+
+- Docs/layout/structure/hygiene/CLI group: 536 passed, 0 failed, 4,803 assertions,
+  21 files. This includes all `docs-*.test.ts` guards, both layout tests,
+  structure-ssot, ci-structure-gate, repo-hygiene, cli-export-command,
+  cli-combo-set-targets and cli-combo-parity.
+- Advisor/agent/cost/service/update group: 580 passed and one Windows fixture
+  failure, 4,185 assertions, 25 files. The failure is `advisor-budget.test.ts`
+  "a symlink is refused before SQLite can mutate its target": Windows returned
+  EPERM while `symlinkSync` created the fixture, before the behavior under test.
+  The test and implementation match upstream; neither was changed or skipped.
+- Current-dev runtime group: 533 passed, 8 skipped, 0 failed, 5,145 assertions,
+  20 files. It covers Flex, cooldown reprobes, JEV, client homes, provider seeds,
+  Cursor globs, required tools, compaction, WebSocket liveness, the CLI launcher,
+  sidecar usage and Antigravity Chat. The eight existing Windows skips cover
+  Cursor symlinks, POSIX SSH Include escaping and six PATH-based Bun cases;
+  those platform branches remain for authorized Linux/macOS CI.
+- Re-ran the unchanged Advisor budget file on Linux using official Bun 1.4.4
+  image `oven/bun@sha256:1d22548f177f4ff38e0c15baa3c2c46c6c2060ba2d1bc573bb4720b407548f1d`:
+  4 passed, 0 failed, 13 assertions, including the symlink refusal. The disposable
+  container had no network, a read-only checkout and a private temporary
+  filesystem; no Windows permissions or personal configuration were changed.
+  Three cases overlap the Windows group, so these are not four new unique cases.
+- The final docs/layout group above was rerun after the last prose and scanner
+  regression edits; it includes the Spanish and Bun guards. An earlier isolated
+  recheck passed 20 tests with 2,188 assertions, overlapping that group.
+
+The exact reproduction commands and final build, browser and staged privacy
+receipts are included in the PR description. The full-root-suite resource
+exception remains: this turn does not claim a passing full root run, and the
+preceding combined-PR 900-second run included failures not all classified as
+environmental. The unexecuted remainder and cross-platform coverage still need
+authorized exact-head CI and the maintainer's requested manual `lane=all`.
+
+CodeRabbit reported 100% docstring coverage on the preceding head, but its
+LanguageTool check did not cover everything because the organization's local
+character budget was exhausted. The manual language/contract pass and parity
+tests do not turn that into an exhaustive grammar-tool success. Keep that
+limitation and fresh review separate from contributor language acceptance.
+
+The final offline build completed with 667 pages and 97,816 checked internal
+links, including Pagefind and sitemap. The built nine-locale signing-policy and
+attribution check passed. Actual-browser inspection at 1280px verified the
+prompt-variant replacement warning and visible `<default>` label; at 390px it
+verified the two-terminal Hub setup and Advisor failure guidance. These pages
+had Spanish language metadata and no horizontal page overflow. The Spanish
+Pagefind query `asesor` returned 12 results and its Advisor result opened the
+Spanish guide. The viewport was restored afterward; the preview remains at
+`http://127.0.0.1:4323/es/`. Native Desktop was not exercised, and personal
+Desktop port 10100, credentials and configuration were not used.
+
+Four fresh screenshots are on the fork's separate `pr-assets` branch at
+`0a6e2aae19a79947362eb1530eb84b120addbcc1`, under
+`spanish-docs-20261026/`. None is added to this source branch. Rechecked upstream
+before publication: the branch contains the fetched current `dev` tip.
+Publish the consolidated source update, resolve only the eight corrected
+threads, and request one full review without waiting for it. Keep Draft until
+fresh review, authorized exact-head CI and maintainer acceptance are recorded;
+historical contributor language acceptance is not a new human or native test.
+
+## Consolidated review correction, October 27
+
+The contributor authorized resolving the latest pending review. The completed
+CodeRabbit review of `c5d9b720ba518f761127855c10da1aa65f77a1f7` supplied ten
+inline findings and one outside-diff finding. All eleven are addressed together:
+the separate Hub data/management origins, quota freshness, account selection,
+replay-429 diagnostics, conversation-link normalization, provider generation
+tests, Ollama tool rules, the exact `AdapterEvent` symbol, signing fallback, and
+synced-folder detection. The outside-diff log-filter finding belongs to
+`reference/cli/agents.md`, as its explanation states, rather than the path in
+the generated heading; English and Spanish now document stderr and exit 2 for
+usage errors versus stderr and exit 1 for operational failures.
+
+Preserved published history while merging 29 upstream commits through
+`4118b90ba40076c62af66fd922421943204bb041` (2.94.0) in
+`e0f3e246acbadb9aedfe56afcfddab248bc38392`. A final fetch found two more commits;
+merged through `95cfa30ec72f201818b1c80ff9b03fe70c7a8a0e` in
+`5b173a202026b7d15481ac1f144fbff329fab1d8`. Both layout conflict resolutions
+retain every upstream entry and all eleven upstream shards, appending only
+this contribution's docs shard. The expected fixture roster was checked
+against upstream after removing only the additional Spanish-docs entry.
+
+Synchronized the fifteen canonical pages changed by those upstream commits.
+Spanish now covers GPT-6.1 Terra's distinct native/API limits, context choices,
+reasoning capabilities, Qoder image admission, provider seeds and verification
+limits, Hermes refresh ownership, direct-account credit metadata, combo reprobe
+reservations, checkpoint authority, Claude tool loading, the confirmed POSIX
+Codex CLI update jobs, completed-tool relay, Mistral reasoning and Desktop
+recovery verification. No backend, GUI, desktop, dependency or workflow
+implementation differs from this integration base because of the contribution.
+
+The direct corrections also exposed adjacent mistranslations: a generation
+window shorter than one second is unavailable; Ollama Cloud does not enforce
+format constraints; non-streaming API callers still receive HTTP 413; and Hub
+consent, client-key ownership, disconnection, TLS/Host/Origin checks and service
+repair need their existing conditions preserved. These passages were compared
+with current English and implementation. Signing fallback is clarified in
+English, Spanish and Turkish: an unsigned original remains unchanged, an MSI
+keeps its original updater signature if present, and the standalone executable
+has no original updater signature. This is documentation of existing behavior,
+not a change to signing or authorization.
+
+Corrected the first Hub connection command and the dashboard development
+two-terminal recipe across all nine physical locales. The existing Hub guard
+now checks each connection example, joining shell continuations before
+checking the separate data/management origins. A read-only comparison finds
+one invalid first example in each locale on the preceding published head and
+none after the correction. The foreground-recipe regression checks both the
+Remote Workspace and dashboard guides in every locale. No cap was increased,
+test skipped, or upstream test-layout entry dropped.
+
+Frozen root, GUI and docs installs passed. Bun 1.4.4 matches the runtime/test
+pin. Final root typecheck, structure check and the direct file-size ratchet
+passed. Focused receipts, using repository wrappers and synthetic test homes:
+
+- All docs guards plus layout, structure and hygiene: 470 passed, 0 failed,
+  4,882 assertions across 19 files. This final run follows both merges and the
+  Desktop guide synchronization.
+- Provider completion/quota, Ollama tools, log filters, client connection and
+  spend-ledger contracts on Windows: 768 passed, 5 platform skips and one
+  fixture failure across 23 files, with 3,092 assertions. The failure is
+  `spend-ledger-owner.test.ts` "a dangling journal symlink is refused rather
+  than followed": Windows returned EPERM while creating the symlink fixture,
+  before exercising the behavior. The test and implementation match upstream.
+- Linux storage/startup and signing-policy regressions: 56 passed, 25 skipped,
+  0 failed, 303 assertions across 4 files. This covers the Windows-blocked
+  symlink case and POSIX identity/hard-link cases. The skips are native
+  PowerShell/Authenticode fixtures unavailable in the minimal Linux image.
+- Windows signing-policy file: 26 passed, 12 existing platform skips, 0 failed,
+  186 assertions. This does not establish real release signing.
+- GUI quota freshness/refresh/account and log-filter tests: 93 passed, 0 failed,
+  527 assertions across 7 files using the pinned GUI test wrapper and synthetic DOM.
+- Current-dev contracts: the 19-file Linux group initially passed 511 tests,
+  skipped 1 and failed 9 (3,067 assertions) because its temporary mounts were
+  non-executable. A direct executable/access probe reproduced EACCES. Rechecking
+  only the two affected CLI apply/admission files with executable private
+  mounts passed all 50 tests with 1 root-user permission-case skip and 302
+  assertions. The other 17 files had already passed 470 tests; these results
+  overlap and are not an additional unique 50 beyond that 19-file group.
+  Earlier preparation attempts lacked Node/npm or a writable workspace; their
+  failing setup logs are retained locally rather than described as successes.
+- Latest Desktop recovery contracts on Windows: 82 passed, 8 existing platform
+  skips, 0 failed, 505 assertions across 3 files. Compiled native Linux recovery
+  and procfs cases remain for the appropriate platform.
+
+Linux storage used official Bun 1.4.4 image
+`oven/bun@sha256:1d22548f177f4ff38e0c15baa3c2c46c6c2060ba2d1bc573bb4720b407548f1d`.
+CLI apply additionally used Node 24.22.1/npm 11.19.1 from
+`node@sha256:55fb5f5a527ea2c5c4a95f963e48ef90aa38c7b346054fdc8ee9957a2b55d205`,
+with the same Bun copied into a disposable image. Network was disabled; the
+checkout was mounted read-only, and the explicit source copy, private npm
+prefixes, homes and temporary files lived only in container tmpfs. No personal
+installation was updated or tested, and no host permission was changed.
+
+All 74 canonical paths retain command-block and inline-identifier parity.
+The final build completed with 667 pages and 97,927 checked internal links,
+including Pagefind and sitemap. Built locale signing-policy links and
+attribution also passed. Actual-browser review checked the Hub connection,
+provider generation contract and current model guidance at 1280px, and Hub and
+Desktop guidance at 390px. Spanish metadata was present and the inspected
+pages had no horizontal page overflow; long code remains internally scrollable.
+Pagefind returned 15 results for `Terra`, and its GPT-6.1 Terra link opened the
+Spanish provider guide. The viewport was restored after review. Native Desktop
+was not exercised; personal port 10100 and personal configuration were untouched.
+
+Four screenshots are on the separate `pr-assets` branch at
+`4789fc6f3a797341b6d5c4929fe4329b7b5a9b7b`, under
+`spanish-docs-20261027/`; none is on the source branch. The exact commands,
+staged privacy result and published source SHA are recorded in the PR body.
+
+The full-root-suite resource exception remains: no passing full root run is
+claimed, and the earlier 900-second run had failures not all classified as
+environmental. Focused success leaves the remainder, skipped native cases and
+cross-platform coverage for authorized current-head CI and the maintainer's
+requested manual `lane=all`. Adding `ci:full` through the connector was denied
+with HTTP 403; no alternate credential route was attempted. The existing
+fixture-path selector should independently choose the full Ubuntu lane for
+this PR's fixture diff, subject to maintainer authorization. No CI policy is
+changed. After publishing, resolve only the ten corrected threads and request
+one full CodeRabbit review without waiting for its result. Keep the PR Draft
+pending fresh review, authorized CI and maintainer acceptance. Historical
+contributor Spanish acceptance is retained, not recast as a new human test.
+
+## Readiness refresh, October 29
+
+The contributor authorized closing the actionable pending work after a read-only
+audit. Fast-forwarded the clean checkout to the maintainer's published
+`f074adb71c631b057ef375dbf683ed3e5b3bd14f`, retaining the ordinary carry merges,
+their Spanish corrections and attribution. Merged 49 newer dev commits through
+`3ea89653f5727aea41948ddbd5e833f74afe3e36` (2.95.0) in ordinary merge
+`fae2396a53a066dbe05d31d49131f304cb57f618`. Before publication a fresh fetch still
+reported that same tip and zero missing dev commits. No history was rewritten.
+
+Resolved four merge conflicts: the configuration sidebar retains Catalog with
+Spanish copy and every upstream entry; landing and JSON-LD retain the new
+gateway wording and locale registration; the test layout retains all 19
+upstream shards plus this contribution's docs shard. Compared the normalized
+layout with upstream after removing only that shard, verified every upstream
+shard, and compared the expected fixture map after removing only the added
+Spanish-docs test entry. None was dropped.
+
+Spanish now covers all 78 canonical paths, including the new LM Studio strict
+template, catalog omission and Windows ACL-timeout pages. Updated the changed
+quickstart, Claude Desktop model visibility, constrained tool translation,
+native model omission, context-overflow failover, Advisor caller policy,
+provider/model batch probes, Kiro IAM login, Moonshot migration, xAI includes,
+Opus thinking display, SSH recovery and keyless CC-Switch import. The previously
+separate #7770 is now in dev, so its `completeOnMaxOutputTokens` setting is
+included with the same default and exclusions as English. Added the new
+Spanish runtime-evidence strings and regenerated the client support matrix with
+the owning command; no other locale output changed.
+
+The shared landing-key contract now compares complete Spanish and French key
+sets and verifies every visible/accessibility call. It found missing labels
+from the upstream landing refresh; all are translated. Kept the French drum
+accessibility label while adopting the new copy. Browser review also confirmed
+that the full search pill crowded the brand at desktop widths: its name had an
+81px text box for 127px of content. At intermediate widths the header now uses
+the existing 44px accessible search button without its decorative label/shortcut,
+reserves the brand and reduces gaps. At 1160px and 1280px the complete 127px
+name fits, without page overflow; clicking search and opening a result still
+works. Mobile keeps its existing controls. No runtime or CI behavior is changed.
+
+Frozen root and docs installs passed with Bun 1.4.4. Root typecheck passed for
+2,243 files; structure check and direct file-size ratchet passed. Validation
+used the isolated repository test wrapper and synthetic data:
+
+- The 20-file docs/client-matrix/layout/structure/hygiene batch initially had
+  490 passes and two failures (5,462 assertions). The remaining failures identified
+  provider-role prose that did not name single-leading-system compatibility and
+  combined two role cases. Corrected the documentation, preserving the tests.
+  The final two affected files passed all 48 tests, 0 failures, 2,499 assertions;
+  46 overlap the original batch. All selected cases are accounted for; this is
+  not a claim that the initial batch exited successfully. The new landing-key
+  check also caught omitted labels before this final run.
+- The 14-file current-dev runtime-contract batch had 456 passes and two Windows
+  fixture-cleanup failures, 3,100 assertions. Both failures were EBUSY from
+  removing temporary SQLite fixture directories in `cc-switch-import.test.ts`.
+  A focused rerun of F1/F2 and F3 passed F1/F2 but retained the F3 cleanup failure
+  (1 pass, 1 fail, 7 filtered out, 98 assertions). No assertion or timeout was
+  weakened and the test/runtime source is unchanged from upstream.
+- Ran the unchanged full CC-Switch file on Linux: 9 passes, 0 failures, 545
+  assertions, including F1/F2, F3, WAL/hard-link and FIFO cases. The disposable
+  Bun 1.4.4/Node 24.22.1 container had no network, a read-only checkout and an
+  explicit private source copy, configuration and prefixes in temporary memory.
+  The Windows cleanup limitation remains disclosed; Linux does not establish
+  that Windows cleanup passed. These cases overlap the Windows batch.
+
+All 78 pages retain technical command/inline parity. Final docs build: 703 pages
+and 104,154 internal links, including Pagefind and sitemap. Actual-browser
+inspection covered the Spanish homepage on desktop/mobile, LM Studio at desktop
+width, the new catalog reference on mobile and the Windows ACL page through
+search. The compact search found one Spanish result for `icacls` and opened the
+new Spanish troubleshooting page. Inspected pages had Spanish language metadata
+and no horizontal page overflow. The viewport was restored; the isolated static
+preview remains at port 4323. No personal Desktop state or port 10100 was used.
+
+Four screenshots are pinned on the separate `pr-assets` branch at
+`2a461766e22f3aaad57f873a10fe420553484468`, under `spanish-docs-20261029/`.
+No screenshot is on this source branch. The PR description records final staged
+privacy validation, commands, the published head and exact-head CI status.
+
+Keep the full-root resource exception and unexecuted native-client/platform
+coverage explicit. Independent final Spanish/render acceptance is the separate
+maintainer-arranged gate requested in the October 28 triage; this implementing
+agent's inspection and the contributor's historical acceptance do not replace
+it. The current policy treats `lane=all` as a batched dev check, not a per-PR
+gate; do not request or dispatch it again for this branch. The fixture-path diff
+should choose the full Ubuntu PR lane when CI is authorized. Publish once,
+update the description once, request one full CodeRabbit review without waiting
+for its result, and leave Draft pending independent acceptance and current-head
+CI. Do not merge or change CI permissions, labels or workflows.
+
+## 2026-10-29 — Windows CC-Switch fixture cleanup
+
+Reproduced the reported F3 cleanup failure on Windows with Bun 1.4.4, using the
+repository wrapper and a dedicated ignored TEMP root. The unchanged case reached
+all 15 assertions but failed its teardown with EBUSY after the 15-second removal
+budget. Its uncached SQLite prepared statements survived the default deferred
+connection close. F1/F2 used the same deferred-close pattern.
+
+Those two fixtures now use `Database.close(true)` to finalize outstanding
+statements and release file handles before unlinking the hard-link alias or
+removing their temporary home. The outer F3 finally also uses that idempotent,
+strict close instead of swallowing close failures. The shared removal helper,
+retry budget, assertions and test-home protections are unchanged. The owning
+`structure/ops/test-sandbox-cleanup.md` contract records this lifecycle.
+
+Validation, from the repository root with `OCX_TEST_RUNNER_BUN` pinned to the
+installed Bun executable and TEMP/TMP contained under the ignored task scratch:
+
+```powershell
+bun scripts/test.ts --timeout 120000 --test-name-pattern 'F3:' tests/providers/cc-switch-import.test.ts
+# Before the fix: 0 pass, 1 teardown failure, 8 filtered out, 15 assertions.
+bun scripts/test.ts --timeout 120000 tests/providers/cc-switch-import.test.ts
+# After the fix: 9 pass, 0 fail, 543 assertions; F3 completed in 164 ms.
+bun scripts/test.ts --timeout 120000 tests/cli/cli-provider-cc-switch-import.test.ts tests/lib/remove-tree-helper.test.ts tests/ci-workflows/test-home-guard.test.ts tests/ci-workflows/test-home-guard-unpreloaded.test.ts tests/ci-workflows/test-temp-quarantine.test.ts
+# 50 pass, 6 existing platform skips, 0 fail, 278 assertions.
+bun run typecheck
+# Zero type errors across 2,243 files.
+bun run structure:check
+bun scripts/file-size-ratchet.ts
+git diff --check
+# All passed.
+```
+
+The full root suite was not rerun for this fixture-only resource-lifecycle fix:
+focused red/green reproduction, the entire affected file, related CLI and
+home/removal guards cover the change without repeating the costly runtime suite
+on the shared host. Broader hosted/platform coverage remains subject to the
+maintainer's current-head PR CI approval. No production runtime or Desktop file
+changed, no real credential or client configuration was imported, and the
+Desktop listener remained on 127.0.0.1:10100 in the same observed process.
+
+This follow-up resolves the Windows cleanup limitation recorded above. It does
+not resolve the 20 new documentation threads from CodeRabbit's completed review
+of `9af015348`; those findings and independent Spanish/render acceptance remain
+separate. Keep the PR in Draft and preserve the existing CI dispatch policy.
+
+## 2026-10-29 — Complete the twenty new documentation findings
+
+Reviewed all twenty open threads from the completed CodeRabbit review of
+`9af015348`. The branch retains the Windows fixture fix in `eab49f9ad` and all
+maintainer carry commits. A fresh fetch found no commits missing from `dev`
+(`3ea89653f5727aea41948ddbd5e833f74afe3e36`, 2.95.0).
+
+| Finding | Correction |
+| --- | --- |
+| 1. Platform Support | Use a Starlight slug; navigation keeps the selected locale. |
+| 2. Workflow revision | English and Spanish contributing/PR-quality pages describe the PR merge ref and pre-merge effect, subject to filters and fork approval; trusted default-branch gates remain separate. |
+| 3. Activation | State the default-off opt-in and quota-window reset trigger; preserve process-restart recovery and retry timing. |
+| 4. Installation | Distinguish the loopback root URL from non-loopback provider-table authentication. |
+| 5. Log Guard | Limit filtering to rows persisted in local SQLite; preserve the listed exclusions. |
+| 6. Quota privacy | Separate outbound quota signals from bounded local tier counts and selected tier; retain the no-account-ID/token/fingerprint guarantee. |
+| 7. Combo options | Add the cooldown-reprobe options to both English and Spanish summaries. |
+| 8. Cursor | Describe the selected Claude provider's default reasoning effort, without implying a provider change. |
+| 9. Integration removal | State that edits can lock the switch and refuse Disable, leaving the managed block intact. |
+| 10. Trace location | Name the actual Logs dashboard section. |
+| 11. Executor pairing | Synchronize all nine locale recipes: silent input, stdin delivery, variable cleanup and agent launch only after successful pairing. |
+| 12. Subagent roster | English and Spanish describe the first five priorities, non-allowlist semantics and catalog completion. |
+| 13. Incomplete usage | Distinguish the warning from readable-only counts/dates/rankings and retain the incomplete-snapshot refusal/recovery. |
+| 14. Native omission | Correct both English and Spanish defaults: absent/false/invalid values add no omission. |
+| 15. Strict effort | Use the intersection of known effort scales, including empty scales; keep adaptive and dispatch distinctions. |
+| 16. API-key scope | State that decision-destination scopes are enforced before credential or request-state reads. |
+| 17. Migration | Clearly preserve parsing of old usage rows without routeDecision and explain index rebuilding. |
+| 18. Non-loopback credentials | Include configured client API keys in English and Spanish, matching assertServerAuthConfig. |
+| 19. Encrypted task recovery | English and Spanish describe the eligible recovery exception and retain the last native error after native attempts; link the existing trust/loopback/no-persistence restrictions. |
+| 20. Video Bridge | Align the remaining seven locales with the English/Spanish environment-key reference and explicit key mode; also repair the Japanese example's translated JSON property. |
+
+No runtime, GUI, Desktop, workflow, dependency or lockfile change is made by this
+batch. The primary GitHub Actions event reference confirms the merge-ref
+distinction; provider, quota, admission and recovery claims were compared with
+their current implementations and canonical guides.
+
+Two new regressions inside the existing Spanish-docs guard check that every
+locale's Video Bridge example parses and requires the environment key/key-auth
+shape, and that every Executor example reads silently, uses stdin and clears
+its variable. Both failed before the corrections. The first full docs selection
+had 392 passes and one failure caused by a changed inline code-span delimiter in
+the effort table. The delimiter was restored without weakening the guard; final
+affected-file validation passed all 20 cases and 2,542 assertions. The other
+fourteen files' 373 passes remain valid and were not rerun on unchanged inputs.
+
+```powershell
+$env:OCX_TEST_RUNNER_BUN = (Get-Command bun).Source
+$docsTests = @(rg --files tests/ci-workflows -g 'docs-*.test.ts')
+bun scripts/test.ts --timeout 120000 @docsTests tests/ci-workflows/client-support-matrix.test.ts
+bun scripts/test.ts --timeout 120000 tests/ci-workflows/docs-spanish-localization.test.ts
+bun scripts/test.ts --timeout 120000 tests/routing/jev-quota-signals.test.ts tests/routing/jev-decision-destination.test.ts tests/server/agent-task-recovery-combo.test.ts
+bun run typecheck
+bun run structure:check
+bun scripts/file-size-ratchet.ts
+git diff --check
+```
+
+The runtime-contract selection passed 46 tests / 270 assertions. Typecheck passed
+2,243 files with zero errors. Structure and size gates pass without increasing
+any cap. Frozen docs-site install changed no package; the final offline docs
+build completed with 703 pages and 104,174 checked internal links, Pagefind and
+sitemap. The full root suite was not rerun for this documentation/data-read
+change on the shared host; focused docs, semantic runtime contracts and the full
+site build cover this batch, with broader hosted/platform evidence left to
+maintainer-authorized current-head PR CI.
+
+Six isolated shell smoke cases exercised the actual canonical Bash and Windows
+PowerShell snippets with a stubbed ocx command: success and failure, stdin,
+absence of the synthetic code from arguments/output, variable cleanup and agent
+gating. The checks used private temporary homes, no live pairing, no network and
+no execution-policy changes. These are agent-run fixtures, not native-client or
+provider acceptance.
+
+Actual-browser inspection verified the corrected catalog text, clicked Platform
+Support and reached the Spanish page with lang=es at 1280 px, and inspected
+Executor pairing at 390 px without horizontal page overflow. Viewport overrides
+were reset. Captures are kept outside the source branch under
+`spanish-docs-review-20261029/` on pr-assets, with their pinned commit in the PR.
+This does not replace the maintainer-arranged independent Spanish/render
+acceptance. The personal Desktop listener remained on 127.0.0.1:10100 in the
+same observed process; its configuration and credentials were not used.
+
+Publish the corrections once, then resolve the twenty corrected threads and
+request one full CodeRabbit review without waiting for its result. Keep Draft
+pending independent acceptance, current-head CI and maintainer review. Do not
+merge, dispatch batched CI, change permissions/labels or infer an approval.
+
+## 2026-10-30 — Consolidated audit and seven review findings
+
+Merged the 37 newer dev commits through
+`3cab4a74e4eec15ee5ff3bdd59dcab8ede938372` (2.95.0) in ordinary merge
+`563de9172d93021fed7d3a41816104efb4b74db7`. The two conflict resolutions keep
+all 20 test-layout shards, both new upstream test registrations, and both the
+subagent priority explanation and the new workflow-limit panel. Contributor
+history, maintainer carry commits and attribution are preserved. A fresh fetch
+before publication found zero missing dev commits.
+
+| Open review | Disposition |
+| --- | --- |
+| Bun roles | Name the test runner and distributed runtime explicitly; their independent checks remain separate. |
+| Provider-key examples | Pass literal environment references in all nine Agent Quickstart copies and English/Spanish JEV examples. Explain proxy startup, CLI resolution and separately configured service environments. |
+| macOS uninstall | English and Spanish say to remove the managed terminal command before trashing the app; retained state and separately installed services are still identified. |
+| OpenCode transport | All nine copies show manually configured HTTPS, explain the required TLS frontend and loopback-tunnel alternative, and retain the dedicated admission header. Seven older Grok copies now carry the same protected-transport and token-file instructions. |
+| Remote Hub diagnostic | Label unauthenticated curl as transport-only; browser acceptance still requires an allowed signed-in identity. Matching executable comments are synchronized across locales. |
+| Malformed enrollment journal | Say commands are rejected, preserve the original bytes and recovery instructions, and clarify exit 3, temporary-file cleanup and messages already in transit. |
+| Windows signing | English, Spanish and the existing Turkish page distinguish attempted production signing from the original unsigned-file fallback. No signing or release policy changes. |
+
+The audit covers the entire Spanish content inventory mechanically: all **79**
+canonical paths, executable blocks, inline identifiers and model names,
+frontmatter, external references, API status codes, local links, locale maps,
+metadata and benchmark placeholders. A numeric-prose comparison and semantic
+pattern sweep supplemented manual English/source checks in affected and related
+workflows. This is not an independent line-by-line linguistic acceptance of
+every sentence or a live execution of every documented integration.
+
+Spanish now follows the new keychain chapter and its sidebar entry, task workflow
+ceilings, Artificial Analysis role tiers, launcher verification, Claude agent
+cleanup, Meta/xAI/Azure tool and include handling, model-label routing exception,
+history-index validation and update-restart refusal. Additional confirmed wording
+fixes restore account failover and affinity, jitter, token refresh semantics,
+the absent-management-origin condition, and the distinction between context and
+cumulative reasoning-archive storage. Duplicated archive-capacity prose is
+removed without dropping the refusal codes or recovery guidance.
+
+The credential findings received a separate read-only source investigation and
+one fresh candidate review. No surviving scoped credential-example defect or
+compatibility regression was found. The public examples change; runtime,
+dependencies, Desktop and CI policy do not. Two new existing-file regressions
+failed before correction and pass after it. A whole-tree search found no
+remaining shell-expanded `--api-key` example in Markdown documentation.
+
+Validation, Windows and Bun 1.4.4, repository wrapper/preload and synthetic homes:
+
+```powershell
+$env:OCX_TEST_RUNNER_BUN = (Get-Command bun).Source
+$docsTests = @(rg --files tests/ci-workflows -g 'docs-*.test.ts')
+$related = @(
+  'tests/ci-workflows/client-support-matrix.test.ts',
+  'tests/test-layout.test.ts', 'tests/test-layout-tooling.test.ts',
+  'tests/providers/provider-key-store.test.ts', 'tests/providers/opencode-cli.test.ts',
+  'tests/cli/cli-provider.test.ts', 'tests/routing/jev-decision.test.ts',
+  'tests/server/server-loopback-host-gate.test.ts',
+  'tests/config/config-workflow-budget.test.ts',
+  'tests/server/server-workflow-budget-settings.test.ts',
+  'tests/server/management-workflow-budget-routes.test.ts',
+  'tests/lib/workflow-budget.test.ts',
+  'tests/routing/codex-role-capability-consent.test.ts',
+  'tests/routing/codex-role-capability-redirects.test.ts',
+  'tests/providers/cc-switch-import.test.ts'
+)
+bun scripts/test.ts --timeout 120000 @docsTests @related
+# 655 pass, 0 fail; 7,053 assertions across 29 files.
+bun scripts/test.ts --timeout 120000 tests/ci-workflows/docs-spanish-localization.test.ts
+# Final prose rerun: 22 pass, 0 fail; 2,615 assertions.
+bun run typecheck
+# 2,252 files; zero type errors.
+bun run structure:check
+bun scripts/file-size-ratchet.ts
+bun run privacy:scan
+git diff --cached --check
+```
+
+Root and docs-site frozen installs changed no package or lockfile. Final offline
+docs-site build, Pagefind and sitemap pass: **712 pages / 105,972 internal links**.
+The first post-merge docs selection had 417 passes and five synchronization
+failures. A later broad selection had 422 passes and two failures; corrected
+prose edits had accidentally omitted adjacent provider details and were narrowed
+to retain every canonical identifier/link. The final 655-case selection passed
+without weakening assertions. The first build caught missing localized TLS
+anchors; those anchors are now explicit and the final build passes. Earlier
+failing commands are not described as exit 0.
+
+The full root suite was not repeated on this shared host. This documentation and
+data-read change is covered locally by focused docs tests, related credential,
+launcher, routing and workflow contracts, typecheck and the complete site build.
+The earlier full-run timeout and unclassified failures remain historical limits;
+no full-suite pass is claimed. Broader platform, packaged-client and live-provider
+acceptance remain for maintainer-authorized current-head CI and human acceptance.
+
+Actual-browser checks inspected workflow-limit table rendering at 1280 px and
+the new keychain chapter at 1280/390 px. The mobile page has lang=es and no
+horizontal page overflow. Spanish search for “llavero” returned 16 results and
+opened the new chapter. The viewport override was reset. Two captures are kept
+outside the source branch on pr-assets, with immutable links in the description.
+Browser-tool connection failures required a fresh Chrome tab; they were not
+reported as product defects. This is agent inspection, not independent native
+Spanish/render acceptance. Personal Desktop state and credentials were not used;
+its observed loopback listener stayed in the same process during the work.
+
+Publish this consolidated batch, reply to and resolve the seven corrected
+threads, update the description once, and request one full CodeRabbit review
+without waiting for its result. CodeRabbit's official command documentation
+distinguishes a full reanalysis from an incremental review; its configuration
+and review scope are unchanged. Keep Draft for fresh review, independent human
+language/render acceptance, current-head CI and maintainer integration approval.
+
+## 2026-10-31 — Full-review follow-up and current-dev synchronization
+
+Merged the 18 newer dev commits through
+`98bd8c07bdb999e883c68c89e1a932c3598912bb` (2.96.0) in ordinary merge
+`ab24a74ce`. The layout conflict preserves all 21 shards, including the new
+file-identity shard and this contribution's docs shard, with every upstream
+registration intact. A fresh fetch before staging found zero missing dev commits.
+
+| Review item | Published correction |
+| --- | --- |
+| Image relay | English/Spanish and affected retained translations distinguish an absent xAI provider from an existing provider without usable credentials. Normal ChatGPT image selection remains possible in the former case. |
+| MiniMax startup | Separate the foreground proxy from integration/launch commands in all nine copies, with explicit second-terminal instructions. |
+| Hub pairing | All shipped connect/rotate recipes read authority silently, pipe it to stdin and clear variables, including older admin-token and Korean text-fenced examples. |
+| Parser messages/tools | Rewrite the Spanish normalization, namespacing, hosted-tool and sidecar rules while preserving identifiers. |
+| OAuth/affinity | Explain refresh coordination, newer-credential protection, account affinity eviction and restart behavior in direct Spanish. |
+| Qwen effort | Explain direct Alibaba effort values and Codex compatibility-level clamping. |
+| CLI family table | Preserve command syntax and clarify experimental/default-disabled and proxy-launch behavior. |
+| Account exit mapping | Say HTTP 404 maps to exit 4, HTTP 409 to exit 5 and other failures to exit 1. |
+| Windows JSON | Name UTF-8 BOM explicitly and preserve UTF-16 refusal. |
+| Session selectors | Require exact UUIDs or unique exact loaded names and preserve refusal of missing, duplicate, incomplete or unloaded targets. |
+| Messaging platforms | Separate Unix-socket support, Windows refusal and independently qualified remote interoperability. |
+| Messaging direction | Outbound worker enrollment does not grant arbitrary inbound local-session access; the broader allow-inbound grant stays explicit. |
+| Diagnostic privacy | Use pull requests (PR), not public relations, in both affected Spanish privacy passages. |
+| Ledger ownership | English/Spanish state that owner comparison is skipped on Windows; other file checks remain intact. |
+
+The full review also had three comments outside the diff and one unverified
+comment. Corrected all four: Pi reasoning metadata in six retained translations;
+remote-bind credential guidance in seven Agent Quickstarts; mobile landing-page
+language selection; and the root CLI discovery description. Checked linked
+remote-access chapters too: all nine now distinguish configured client keys and
+token-file sources from independent management credentials. Added 13 stable
+localized anchors rather than pointing at missing translated section fragments.
+
+Additional Spanish corrections cover adjacent bridge/transport/caching language,
+consent wording, CLI help and error contracts. Current-dev synchronization covers
+Claude Ultra/active quota windows, mandatory-tool combo eligibility, Qoder raster
+ceilings, role-apply limits/recovery, and the new stored-thread MCP queue chapter.
+All 79 current canonical paths retain example, identifier, link and shape parity.
+This is technical and targeted semantic review, not independent human acceptance
+of every sentence in every locale.
+
+Verification uses Bun 1.4.4, frozen root/docs installs with no lockfile changes,
+the repository test wrapper/preload, synthetic homes and an ignored TEMP/TMP root.
+
+```powershell
+$env:OCX_TEST_RUNNER_BUN = (Get-Command bun).Source
+$docsTests = @(rg --files tests/ci-workflows -g 'docs-*.test.ts')
+$related = @(
+  'tests/ci-workflows/client-support-matrix.test.ts',
+  'tests/test-layout.test.ts', 'tests/test-layout-tooling.test.ts',
+  'tests/server/server-images.test.ts', 'tests/lib/spend-ledger-file-journal.test.ts',
+  'tests/clients/client-export-reasoning-controls.test.ts',
+  'tests/clients/client-export-reasoning-metadata.test.ts',
+  'tests/clients/client-connect.test.ts', 'tests/providers/minimax-clients.test.ts',
+  'tests/cli/cli-account.test.ts', 'tests/cli/cli-message-mcp.test.ts',
+  'tests/codex-integration/messaging-mcp-queue.test.ts',
+  'tests/codex-integration/messaging-remote-admission.test.ts',
+  'tests/cli/cli-role-suggestion-history.test.ts',
+  'tests/providers/provider-anthropic-usage-windows.test.ts',
+  'tests/providers/qoder-cn-image-validation.test.ts',
+  'tests/server/server-combo-required-tool-contract.test.ts',
+  'tests/responses/responses-parser.test.ts'
+)
+bun scripts/test.ts --timeout 120000 @docsTests @related
+# Initial expansion: 1052 pass, 35 platform skips, 4 fail, 1 post-timeout error.
+bun scripts/test.ts --timeout 120000 tests/clients/client-connect.test.ts
+# Complete isolated file: 53 pass, 0 fail; 309 assertions.
+bun scripts/test.ts --timeout 120000 tests/cli/cli-role-suggestion-history.test.ts
+# Final complete file: 9 pass, 0 fail; 197 assertions.
+bun scripts/test.ts --timeout 120000 @docsTests
+# Final documentation tree: 385 pass, 0 fail; 4811 assertions across 14 files.
+bun run typecheck
+# Final: 2259 files, zero errors.
+bun run structure:check
+bun scripts/file-size-ratchet.ts
+bun run privacy:scan
+git diff --cached --check
+```
+
+Three connection probes hit their unchanged 15-second internal deadline under
+parallel host load and passed in the complete isolated 53-case file. Source and
+tests match upstream; their deadlines were not altered. The role-history case
+also exceeded its explicit 30-second store budget in isolation. It applies 50
+durable updates and restores 50 more, so that one case now uses the existing
+bounded bulk-durable-I/O budget. Assertions, file limits and shared budget values
+are unchanged. A scratch-only counterfactual replaced the CLI's imported role
+limit with 49: the 50-role case failed its exit assertion in 234 ms with the larger
+budget. No production file was mutated. The final full nine-case file passes.
+The initial parallel command is not represented as passing or rerun wholesale.
+
+The first new recipe guards failed before correction. The post-merge baseline
+had 20 passes and two dev-sync failures. Subsequent guards exposed retained
+admin-token examples and a Korean text fence; the final 385-case docs selection
+passes without dropping those cases. Thirty shipped Hub scripts (six distinct
+bodies) execute with synthetic stdin and an in-process Bash stub; no real proxy,
+provider, authority or native acceptance is involved. The first stub driver used
+Windows text-mode CRLF input; binary LF fixture input corrected that driver.
+
+The first site build found 13 missing translated section fragments. After adding
+the anchors and finishing the linked credential guidance, the complete offline
+build, Pagefind and sitemap pass: **712 pages / 106109 internal links**.
+
+Actual-browser inspection verified the English-to-Spanish landing switch at
+390 px, selected Spanish state and lang=es, and no horizontal page overflow at
+320/390/1280 px. The mobile language panel is 272 px wide and fits the 320 px
+viewport; desktop retains its existing selector. Captures are kept on pr-assets,
+outside this source branch. A browser-session reset was needed after a tab expired
+across user continuation; the temporary viewport override was then reset.
+The personal Desktop listener remained in the same observed process on port
+10100; its configuration and credentials were not used.
+
+The full root suite was not repeated on this shared host: this 32-file expansion,
+the necessary isolated diagnostics, complete docs guards and full site build
+cover the scoped change. Windows skips include native MCP/remote interoperability
+and POSIX file checks; those are left to authorized hosted/platform validation.
+No full-root, packaged Desktop or live-provider success is claimed.
+
+Publish this batch once, update the English description with exact-head evidence,
+resolve the 14 corrected threads and record the three outside-diff dispositions
+plus the unverified comment. Request one full CodeRabbit review without waiting
+for its result. Keep Draft for fresh review, maintainer-arranged independent
+Spanish/render acceptance, authorized current-head CI and maintainer approval.
+Do not merge, dispatch CI, alter permissions or change CodeRabbit configuration.
+
+
+## November 1: final-review corrections and current dev synchronization
+
+Ordinary merge bd7dba77ce06051bc75a7e0227d7d5607094c2f9 incorporates the two newer
+upstream commits through 1783523b4c999a7d3b3d82c6fb07a7895ff93446 (2.97.0),
+without rewriting published history. The layout conflict retains the upstream
+JSON plus layout-docs.json: all 21 explicit shards and upstream registrations.
+A fresh fetch before publication reports zero missing dev commits.
+
+The completed full review of dcd216c87e0da7f61f845adaa23b14d7f6a7a709 left
+eight inline findings, one outside-diff finding and one unverified comment.
+All are confirmed and corrected:
+
+| Review item | Disposition |
+| --- | --- |
+| Remote Link / fallback-off | Limit no-transmission assurances to failures before dispatch. After forwarding starts, Home may have received or processed the request; inspect the uncertain result before retrying. English/Spanish and the affected Turkish fallback copy agree. |
+| Native Messages | Rewrite the Spanish identity/beta contract. English/Spanish identify the header bundle that must be observed, operator precedence, first-party destination, compatibility fallback, allowlist and stripping rules; headers grant no authorization. |
+| Docker Hub | Create missing hub and remoteGui objects only for fresh volumes, with explicit replacement warnings and a separate existing-volume update recipe. Preserve siblings and existing CORS entries. Remove the incorrect assertion that the seed already contains a hub object. |
+| reasoning_effort | State the model-subset clamp, independent xhigh/max labels, explicit alias exception and noReasoningModels omission. |
+| Mistral | Specify both response paths, typed text/thinking arrays, byte/order preservation, parser reset, malformed-block errors and unchanged other hosts. |
+| tool_search | Explain collision-safe public declarations and request/JSON/SSE lifecycle mapping; canonical OpenAI keeps its native type. |
+| Bundled Bun | Distinguish current 1.4.4 from historical 1.3.14 and the stable >=1.4.0 upstream WS eligibility. Update all four architecture pages carrying the stale claim. |
+| Workspace pairing | Explicitly require a Bash session for read -p recipes. Align both Workspace examples and affected Hub recipes in all nine locales. |
+| Outside-diff admission headers | Correct both rows and precedence guidance in all nine server references against AUTH_MATRIX and resolveResponsesApiAuth: dedicated header wins, bearer is a fallback only when it is absent, x-api-key is rejected here. Management and native Messages contracts remain separate. |
+| Unverified sidecar hierarchy | Use level-two headings for the initial web-search backend section in canonical English and Spanish. |
+
+The adjacent Spanish audit additionally corrects external-task envelopes,
+checkpoint authority, unset-versus-disabled defaults, Google HTTP 400 versus
+message-terminal 403, agéntico video processing, retry semantics, key terminology,
+Azure delegation and the Docker readiness/host-mount guidance. Current-dev Pool
+installation identity isolation and the 32 KiB turn-metadata limit are synchronized
+in the Codex guide. Technical parity still covers all 79 canonical paths. This is
+not independent human linguistic acceptance of every sentence.
+
+New guards validate Docker commands in order against docker/config.json and the
+current configuration schema, compare all nine admission tables with the actual
+AUTH_MATRIX, require an explicit Bash session for Workspace recipes, and compare
+current bundle claims in all affected architecture pages with package.json.
+The four newly selected regression cases first produced 0 passes / 4 failures
+before the documentation correction; the final docs selection passes.
+
+Validation uses Bun 1.4.4, unchanged frozen root/docs lockfiles, the repository
+wrapper/preload, synthetic homes and a dedicated ignored TEMP/TMP root. No
+personal Desktop configuration, token, native home or provider account was used.
+No process was listening on the personal port 10100 when inspected.
+
+```powershell
+bun install --frozen-lockfile
+$env:OCX_TEST_RUNNER_BUN = (Get-Command bun).Source
+$docsTests = @(rg --files tests/ci-workflows -g 'docs-*.test.ts')
+$related = @(
+  'tests/test-layout.test.ts',
+  'tests/test-layout-tooling.test.ts',
+  'tests/clients/client-link-relay.test.ts',
+  'tests/clients/link-relay-bound-transport.test.ts',
+  'tests/server/server-auth.test.ts',
+  'tests/server/data-plane-admission-identity.test.ts',
+  'tests/cli/cli-config-command.test.ts',
+  'tests/codex-integration/codex-installation-id.test.ts',
+  'tests/codex-integration/codex-installation-wire.test.ts',
+  'tests/codex-integration/codex-installation-sidecars.test.ts',
+  'tests/codex-integration/codex-installation-live-ws.test.ts',
+  'tests/codex-integration/codex-installation-live-http.test.ts',
+  'tests/codex-integration/codex-installation-live-content.test.ts',
+  'tests/codex-integration/codex-installation-invalid-account.test.ts',
+  'tests/responses/codex-installation-turn-limit.test.ts'
+)
+bun scripts/test.ts --timeout 120000 @docsTests @related
+# Initial 29-file expansion: 821 pass, 1 fail; 8763 assertions.
+bun scripts/test.ts --timeout 120000 tests/server/server-auth.test.ts --test-name-pattern 'OpenAI option auth matrix keeps direct, pool, and API credentials independent'
+# Isolated original failing case: 1 pass, 0 fail; 99 assertions, 24.2 s test body.
+bun scripts/test.ts --timeout 120000 tests/server/server-auth.test.ts
+# Final complete isolated file: 117 pass, 0 fail; 776 assertions, 286.7 s.
+bun scripts/test.ts --timeout 120000 @docsTests
+# Final: 387 pass, 0 fail; 4920 assertions across 14 files, including 25 Spanish cases.
+bun run typecheck
+# Final: 2262 files, zero errors.
+bun run structure:check
+bun scripts/file-size-ratchet.ts
+bun run privacy:scan
+git diff --cached --check
+Push-Location docs-site
+bun install --frozen-lockfile
+$env:OPENCODEX_DOCS_OFFLINE = '1'
+bun run build
+Pop-Location
+# Complete final site: 712 pages, 106109 checked internal links; Pagefind/sitemap pass.
+```
+
+The initial expansion failed the existing OpenAI option auth matrix case at its
+unchanged explicit 30-second deadline. Teardown reported EBUSY on its isolated
+fixture during Windows ACL hardening, then the worker stopped making progress.
+Only the verified worker belonging to that test run was stopped; the wrapper
+reported the failure and worker interruption after 308.4 seconds. The test and
+ACL source match current dev. The original failing case passes alone without a
+source, assertion or budget change. The complete isolated 117-case file also passes without source or deadline changes. The initial expansion is not
+described as passing. This observation does not prove a general environment-only
+classification for every earlier full-suite failure.
+
+Twelve documented Docker config commands execute through the real CLI with
+synthetic separate OpenCodex/Codex homes, covering fresh initialization and
+existing-volume sibling preservation. No Docker daemon or proxy is started by
+that probe. Fifty-four Workspace Bash scenarios cover the 18 shipped examples:
+success, rejected pairing and failed reads, agent-start conditions and secret
+variable cleanup, using synthetic stdin and an in-process stub. These are CLI
+and shell probes, not a real Docker deployment or native-provider acceptance.
+
+Actual-browser inspection of the complete final build verifies the new Docker
+warning and code blocks at 1280/390/320 px, lang=es and no page-level horizontal
+overflow. Long commands scroll within their code block. The corrected admission
+rows render in Spanish at 320 px without page overflow. Viewport overrides were
+reset. New desktop/mobile captures are on pr-assets, separate from this branch:
+4a56832df793b75b7c5d7b3331da8c06bd11db33, directory spanish-docs-review-20261101. The October 31 landing,
+search and prior platform evidence remains valid for its unchanged UI.
+
+Full-suite resource exception: the entire root suite is not repeated on this
+shared Windows host. The focused expansion, isolated failure diagnostics,
+complete docs guards and complete build cover this docs-only follow-up; residual
+full-suite/platform coverage remains with authorized hosted CI. Earlier full-root
+runs and native/live-provider acceptance are not represented as passing.
+
+Publish one source batch, reply to and resolve the eight corrected inline
+threads, and record the outside-diff and unverified dispositions. Update the
+English description once with current-head evidence and the scoped exception.
+Request one full CodeRabbit review without waiting for its result. Keep Draft
+for fresh review, maintainer-arranged independent Spanish/render acceptance,
+authorized current-head CI and maintainer approval. No merge, CI dispatch/retry,
+permission change or CodeRabbit configuration change is authorized here.
+
+
+## November 4 follow-up: completed review and current-dev parity
+
+Merged upstream dev through `0a30c551304927c93c26a96c034bd39a166c7460`
+(2.98.0; 55 commits beyond the previous integration base) using ordinary merge
+`5a193fe103ebe0d94d1c6b52c1117d8392aaee37`. Published history is retained.
+The Astro conflict keeps Spanish navigation and adds the new Ollama client guide.
+The test-layout conflict keeps all upstream registrations and the docs shard;
+its formatting follows upstream so the file remains below the size threshold.
+A final fetch before publication found no missing dev commits.
+
+Disposition of review `5731399667` (November 2 UTC):
+
+- Correct the triage receipt heading to October 24 UTC.
+- Separate the default and custom-port foreground quickstart commands in all
+  nine locales; explain the second terminal and shared OPENCODEX_HOME.
+- Translate the storage database condition as locked, and clarify that model
+  changes save in click order, with pending unsent changes discarded on leaving.
+- State in all nine server references that only a nonempty trimmed dedicated
+  header has priority; absent, empty and whitespace-only headers use bearer
+  fallback, while a nonempty invalid dedicated credential cannot fall back.
+- Fix the outside-diff agent read-back wording: a failed, unknown or mismatched
+  read-back leaves upstream application unknown, so operators must inspect before
+  retrying. Rephrase both unverified receipt comments without changing behavior.
+
+Spanish covers all 80 current canonical documentation paths, including the new
+Ollama API subset. Targeted semantic synchronization also covers Kiro structured
+output and refusal behavior, Codex request-owned and durable affinity, pool
+threshold selection, Anthropic quota windows, Kimi capabilities and monthly
+quota, Qoder discovery deadlines, Artificial Analysis capability data, sync
+fanout, service homes, uninstall refusal, orchestrated updates, HTTP CLI-update
+authority and fixed Messages error normalization. Backend contracts, native
+Desktop implementation, dependencies and CI/reviewer configuration are unchanged
+relative to dev. These technical and targeted semantic checks do not replace
+independent linguistic acceptance of every translated sentence.
+
+Validation on the working tree to be published, Bun 1.4.4:
+
+```powershell
+bun install --frozen-lockfile
+$env:OCX_TEST_RUNNER_BUN = (Get-Command bun).Source
+# TEMP/TMP use a private ignored test directory; the repository wrapper/preload
+# creates separate synthetic OpenCodex/Codex homes.
+$docsTests = @(rg --files tests/ci-workflows -g 'docs-*.test.ts')
+bun scripts/test.ts --timeout 120000 @docsTests tests/test-layout.test.ts tests/test-layout-tooling.test.ts tests/server/data-plane-admission-identity.test.ts
+# 446 pass / 0 fail; 5640 assertions, 17 files, including 27 Spanish cases.
+
+$related = @(
+  'tests/responses/responses-ollama-codec.test.ts',
+  'tests/server/server-ollama-inbound.test.ts',
+  'tests/providers/kiro/kiro-structured-output.test.ts',
+  'tests/providers/kiro/kiro-structured-output-strict.test.ts',
+  'tests/adapters/anthropic/anthropic-account-pool.test.ts',
+  'tests/providers/provider-anthropic-usage-windows.test.ts',
+  'tests/codex-integration/codex-affinity-request-owned.test.ts',
+  'tests/codex-integration/codex-affinity-restart-matrix.test.ts',
+  'tests/routing/codex-role-capability-pages.test.ts',
+  'tests/cli/sync-fanout.test.ts',
+  'tests/cli/sync-command-fanout.test.ts',
+  'tests/update/update-orchestrated-plan.test.ts',
+  'tests/update/update-orchestrated-arguments.test.ts',
+  'tests/update/update-orchestrated-identity.test.ts',
+  'tests/server/messages-sse-error-filter.test.ts',
+  'tests/server/messages-sse-error-lifecycle.test.ts',
+  'tests/server/safe-response-headers.test.ts'
+)
+bun scripts/test.ts --timeout 120000 @related
+# Windows: 434 pass / 6 fail; 2929 assertions, 17 files, 123.3 seconds.
+# All six failures occur while creating file symlinks (EPERM), before the
+# intended store assertions. The complete failing test file matches dev.
+
+# Same unchanged 33-case affinity file in official oven/bun:1.4.4 Linux,
+# image digest sha256:1d22548f177f4ff38e0c15baa3c2c46c6c2060ba2d1bc573bb4720b407548f1d:
+$reviewRoot = (Get-Location).Path
+docker run --name ocx-spanish-review-20261104 --rm --network none --read-only --user 0:0 --tmpfs /tmp:rw,nosuid,size=1g --env HOME=/tmp/runner --env OCX_TEST_RUNNER_BUN=/usr/local/bin/bun --mount "type=bind,source=$reviewRoot,target=/workspace,readonly" --workdir /workspace oven/bun:1.4.4 bun scripts/test.ts --timeout 120000 tests/codex-integration/codex-affinity-restart-matrix.test.ts
+# Linux: 33 pass / 0 fail; 147 assertions, 65.7 seconds, including all six cases.
+# The Windows expansion is not represented as green. Linux results do not
+# replace verification on a Windows host allowed to create file symlinks.
+
+bun scripts/test.ts --timeout 120000 tests/ci-workflows/docs-spanish-localization.test.ts tests/test-layout.test.ts tests/test-layout-tooling.test.ts
+# Final after anchor, wording and registry-format corrections:
+# 56 pass / 0 fail; 3559 assertions, three files.
+bun run typecheck
+# Zero errors in 2316 files.
+bun run structure:check
+bun scripts/file-size-ratchet.ts
+bun run privacy:scan
+git diff --cached --check
+Push-Location docs-site
+bun install --frozen-lockfile
+bun run build
+Pop-Location
+# Final complete build: 721 pages, 108027 internal links, Pagefind and sitemap.
+```
+
+The quickstart regression was observed failing before the command separation;
+it passes after the correction. The header regression exercises the current
+auth resolver with synthetic keys for empty, whitespace-only, invalid nonempty
+and valid trimmed dedicated headers. Neither probe uses personal credentials.
+
+The final browser inspection covers the new Ollama guide, corrected foreground
+quickstart, storage/save text and HTTP-update warning at desktop 1280 and mobile
+390/320 px, lang=es and no page-level horizontal overflow. Long commands scroll
+inside their blocks. Viewport overrides were reset. New captures are pinned on
+pr-assets at `01ea6efd4b3651612c5a2099a7edcc80050a0f14`, directory
+`spanish-docs-review-20261104`, outside the source branch. This is agent-run
+browser evidence; native Desktop and independent human acceptance are separate.
+
+Full-suite resource exception remains: do not repeat the entire root suite on
+this shared Windows host after prior expensive interrupted runs. Complete docs
+checks, focused runtime coverage, explicit diagnostics of the six Windows
+symlink failures and a successful isolated Linux run are documented above.
+Residual full-suite and platform coverage belongs to authorized hosted CI.
+No failed, unrun, approval-required or older-head suite is claimed as passing.
+
+Publish the corrections together, reply to the five corrected inline threads,
+record outside-diff/unverified dispositions, and update the English description
+once. Request one full CodeRabbit review without waiting for its result. Keep
+Draft for fresh review, maintainer-arranged independent Spanish/render
+acceptance, authorized current-head CI and maintainer approval. No merge,
+workflow dispatch/retry, reviewer assignment or permission change is performed.
+
+## 2026-11-11: conflict resolution and current-dev refresh
+
+This entry supersedes the earlier head, page counts and Draft instructions for
+the current handoff. The contributor subsequently authorized Ready for review
+and requested Ingwannu; maintainer approval and independent language/render
+acceptance remain separate.
+
+Merge `upstream/dev` normally, without rebasing or rewriting published history:
+base `de0914a1a83b1d831aeb79aadd3a56d2e0182df4` (package 2.100.0), 284 commits
+after the previously incorporated dev. Nine conflicts were resolved in the
+Astro configuration, header, landing, English contribution/PR-quality and
+protocol/provider references, test-layout registry and docs ownership note.
+All upstream test registrations and the Spanish docs shard remain present.
+The final pre-publication fetch found no newer dev commit. Runtime, GUI,
+native Desktop, dependencies, lockfiles and CI policy match dev; the two
+previously documented test-only fixture/budget fixes remain in the PR.
+
+Spanish now covers all 83 canonical paths. New pages are the public usage
+dashboard, telemetry/privacy guide and custom-gateway verification guide.
+The public telemetry and leaderboard dictionaries include complete Spanish
+copy. This is the documentation website, not the installed proxy dashboard.
+The upstream header design is retained with Spanish navigation and mobile
+language selection. Edit links now target dev, since main was retired.
+
+The 22 November 4 inline findings have the following dispositions:
+
+| Area | Correction |
+| --- | --- |
+| Benchmark overview | Describe the score-per-dollar column and measured-cost badge; no sorting claim |
+| Agent setup | Run init before foreground/background startup in every locale |
+| Agent combo | Use the configured anthropic-apikey provider in the target |
+| Source installation | Require Bun on PATH separately from npm's bundled Bun |
+| Installation/quickstart restoration | Qualify standalone owner, linked-client and sibling behavior |
+| Standalone quickstart | Put the executable on PATH or use its full path |
+| Quickstart ports, Spanish and English | Use the selected port; retain 10100 as the default |
+| Codex account-gated model row | Translate Pool, Direct, selector and verified-roster conditions accurately |
+| Log Guard reclaim | Name the canonical logs_2.sqlite target and preserve safety checks |
+| Remote Hub service | Keep launchd as the literal supervisor name |
+| Remote Hub CORS recovery | Run the complete printed command without dropping the existing allowlist |
+| Container persistence | Separate catalog backup from SQLite account persistence |
+| Container deletion | State the exact configuration/account/history/token/client state removed by --volumes |
+| Revocation navigation | Use Connect → API Keys consistently |
+| Dashboard pricing | Distinguish a different vendor's price from exact-provider/configured pricing |
+| Delegation guidance | Treat model/effort values as advisory; custom guidance replaces the built-in prompt |
+| Gemini file URI | Say the provider accesses the referenced resource |
+| Devin model discovery | Remove models absent from the live account roster from the displayed seed |
+| Separate-home quickstart | Explain that a sibling does not independently reroute shared clients |
+| Video Bridge environment | Set XAI_API_KEY before starting the proxy and restart after changes, all locales |
+| Korean pairing command | Remove the unused echo pipeline; preserve silent input and printf |
+
+Both duplicated selected-port inline comments are covered by the same fix.
+Four outside-diff findings are also corrected: same-home/free-port recovery
+in the remaining locales; omit absent benchmark task counts and their
+separator; use each board's localized cost unit in table headers; distinguish
+impossible local decryption from experimental backend-assisted task recovery
+in every translated v1 guide. The new same-home recovery assertion was
+observed failing on the French guide before these corrections and passes
+afterward.
+
+The current-dev audit updates provider/model admission and quota metadata,
+forwarded headers, MCP stored-reply limits, Mistral/tool-schema compatibility,
+custom-tool lowering, dictation/ScribeTray bounds, retained-compaction errors,
+Desktop installer consent/startup ownership, update recovery, Remote Hub
+container ownership and Remote Link lightweight agents, policy, diagnostics,
+readiness and child operations. Commands, inline identifiers, API status
+codes, links, table shapes, lists and model tokens retain English parity.
+The generated client support pages were regenerated with `bun run docs:clients`.
+
+Verification on Windows, Bun 1.4.4, with synthetic homes and the repository
+test wrapper:
+
+```powershell
+bun install --frozen-lockfile
+Push-Location docs-site
+bun install --frozen-lockfile
+Pop-Location
+
+$env:OCX_TEST_RUNNER_BUN = (Get-Command bun).Source
+# TEMP and TMP point to a task-local test-temp directory.
+$docsTests = @(rg --files tests/ci-workflows | Where-Object {
+  $_ -match '(docs-.*|client-support-matrix).*\.test\.ts$'
+})
+bun scripts/test.ts --timeout 120000 @docsTests tests/test-layout.test.ts tests/test-layout-tooling.test.ts
+# 459 pass / 0 fail, 10042 assertions, 20 files.
+
+bun scripts/test.ts --timeout 120000 tests/ci-workflows/docs-spanish-localization.test.ts
+# Final affected guard: 29 pass / 0 fail, 3130 assertions.
+
+bun run typecheck
+# No type errors in 2429 files.
+bun run structure:check
+bun scripts/file-size-ratchet.ts
+bun run privacy:scan
+git diff --cached --check upstream/dev -- docs-site scripts structure tests
+
+Push-Location docs-site
+$env:OPENCODEX_DOCS_OFFLINE = '1'
+bun run build
+Pop-Location
+# Complete site, Pagefind and sitemap: 748 pages / 111649 internal links.
+```
+
+The first merged-docs run had three parity failures, subsequently corrected:
+list/table layout, a repeated technical identifier, and obsolete main URLs.
+The final broad and affected-file results above replace those failures rather
+than describing the initial run as green. Full-root and native-client/live-
+provider execution were not repeated on this shared Windows host after the
+previous expensive interrupted runs. The full-suite resource exception still
+applies; broad runtime/platform validation remains for authorized hosted CI.
+The November 4 EPERM and isolated Linux results above are historical, not
+new-head execution results.
+
+Browser inspection verified Spanish landing/navigation, the new public usage
+dashboard, mobile language switching without losing the dashboard route,
+quickstart and the custom-gateway guide at 1280/390/320 px. Documents reported
+lang=es and no page-level horizontal overflow. The public collector could not
+be fetched from this environment; its translated unavailable/retry state was
+verified, not successful live collector delivery. Synthetic-data telemetry
+tests cover successful rendering separately. Temporary viewport overrides
+were reset. No personal Desktop configuration, credentials or provider
+accounts were used.
+
+Captures are pinned outside this PR branch at pr-assets commit
+`bbba08cb630a99335fe905c81bb95bfbe4ff2983`, directory
+`spanish-docs-review-20261111/`. No screenshot is staged on the source branch.
+Full staged merge whitespace diagnostics include inherited dev-only trailing
+lines; the contribution-relative staged diff check is clean. Unrelated
+upstream whitespace was deliberately preserved.
+
+The contributor token cannot add ci:full (GitHub denied AddLabelsToLabelable).
+The retained test-layout fixture change already selects the full Ubuntu test
+lane under the current selector; a maintainer must still authorize fork CI
+and can apply that label if needed. Missing, skipped, older-head or
+action_required results are not passing evidence. Do not dispatch per-PR
+lane=all, retry workflows, merge, or change permissions.
+
+Publish this merge and corrections together, reply to and resolve the 22
+corrected inline threads, update the English template description once and
+request one full CodeRabbit review without waiting for its result. Restore
+the authorized Ready-for-review state only after local checks and the known
+findings are complete. Keep independent acceptance, current-head CI and
+maintainer integration approval explicitly pending.
diff --git a/docs-site/astro.config.mjs b/docs-site/astro.config.mjs
index 2423554b630..49912f94c9d 100644
--- a/docs-site/astro.config.mjs
+++ b/docs-site/astro.config.mjs
@@ -2,6 +2,7 @@
 import { defineConfig } from "astro/config";
 import starlight from "@astrojs/starlight";
 import internalLinks from "./src/integrations/internal-links.mjs";
+import { codeBlockLocale } from "./src/data/code-block-locale";
 
 // Canonical GitHub Pages custom domain. The site is served at the domain root,
 // so Starlight must not emit the former /opencodex project-site prefix.
@@ -62,13 +63,15 @@ export default defineConfig({
         { icon: "github", label: "GitHub", href: "https://github.com/lidge-jun/opencodex" },
       ],
       editLink: {
-        baseUrl: "https://github.com/lidge-jun/opencodex/edit/main/docs-site/",
+        baseUrl: "https://github.com/lidge-jun/opencodex/edit/dev/docs-site/",
       },
       lastUpdated: true,
-      // English at the site root; French under /fr, Korean under /ko, Simplified Chinese under /zh-cn, Traditional Chinese under /zh-tw, Russian under /ru, Japanese under /ja, Turkish under /tr.
+      expressiveCode: { getBlockLocale: ({ file }) => codeBlockLocale(file) },
+      // English at the site root; Spanish under /es, French under /fr, Korean under /ko, Simplified Chinese under /zh-cn, Traditional Chinese under /zh-tw, Russian under /ru, Japanese under /ja, Turkish under /tr.
       defaultLocale: "root",
       locales: {
         root: { label: "English", lang: "en" },
+        es: { label: "Español", lang: "es" },
         fr: { label: "Français", lang: "fr" },
         ko: { label: "한국어", lang: "ko" },
         "zh-cn": { label: "简体中文", lang: "zh-CN" },
@@ -80,117 +83,118 @@ export default defineConfig({
       sidebar: [
         {
           label: "Getting Started",
-          translations: { fr: "Démarrage", ko: "시작하기", "zh-CN": "开始使用", "zh-TW": "開始使用", ru: "Начало работы", ja: "はじめに", tr: "Başlangıç" },
+          translations: { es: "Primeros pasos", fr: "Démarrage", ko: "시작하기", "zh-CN": "开始使用", "zh-TW": "開始使用", ru: "Начало работы", ja: "はじめに", tr: "Başlangıç" },
           items: [
-            { label: "Installation", translations: { fr: "Installation", ko: "설치", "zh-CN": "安装", "zh-TW": "安裝", ru: "Установка", ja: "インストール", tr: "Kurulum" }, slug: "getting-started/installation" },
-            { label: "Quickstart", translations: { fr: "Démarrage rapide", ko: "빠른 시작", "zh-CN": "快速开始", "zh-TW": "快速入門", ru: "Быстрый старт", ja: "クイックスタート", tr: "Hızlı Başlangıç" }, slug: "getting-started/quickstart" },
-            { label: "How It Works", translations: { fr: "Fonctionnement", ko: "동작 원리", "zh-CN": "工作原理", "zh-TW": "運作原理", ru: "Как это работает", ja: "仕組み", tr: "Nasıl Çalışır" }, slug: "getting-started/how-it-works" },
-            { label: "Agent Quickstart", translations: { fr: "Démarrage rapide pour les agents", ko: "에이전트 퀵스타트", "zh-CN": "Agent 快速上手", "zh-TW": "Agent 快速上手", ru: "Быстрый старт для агентов", ja: "エージェント向けクイックスタート", tr: "Ajanlar İçin Hızlı Başlangıç" }, slug: "getting-started/for-agents" },
+            { label: "Installation", translations: { es: "Instalación", fr: "Installation", ko: "설치", "zh-CN": "安装", "zh-TW": "安裝", ru: "Установка", ja: "インストール", tr: "Kurulum" }, slug: "getting-started/installation" },
+            { label: "Quickstart", translations: { es: "Inicio rápido", fr: "Démarrage rapide", ko: "빠른 시작", "zh-CN": "快速开始", "zh-TW": "快速入門", ru: "Быстрый старт", ja: "クイックスタート", tr: "Hızlı Başlangıç" }, slug: "getting-started/quickstart" },
+            { label: "How It Works", translations: { es: "Cómo funciona", fr: "Fonctionnement", ko: "동작 원리", "zh-CN": "工作原理", "zh-TW": "運作原理", ru: "Как это работает", ja: "仕組み", tr: "Nasıl Çalışır" }, slug: "getting-started/how-it-works" },
+            { label: "Agent Quickstart", translations: { es: "Inicio rápido para agentes", fr: "Démarrage rapide pour les agents", ko: "에이전트 퀵스타트", "zh-CN": "Agent 快速上手", "zh-TW": "Agent 快速上手", ru: "Быстрый старт для агентов", ja: "エージェント向けクイックスタート", tr: "Ajanlar İçin Hızlı Başlangıç" }, slug: "getting-started/for-agents" },
           ],
         },
         {
           label: "Guides",
-          translations: { fr: "Guides", ko: "가이드", "zh-CN": "指南", "zh-TW": "指南", ru: "Руководства", ja: "ガイド", tr: "Kılavuzlar" },
+          translations: { es: "Guías", fr: "Guides", ko: "가이드", "zh-CN": "指南", "zh-TW": "指南", ru: "Руководства", ja: "ガイド", tr: "Kılavuzlar" },
           items: [
-            { label: "Remote Hub Deployment", translations: { fr: "Déploiement Remote Hub", ko: "Remote Hub 배포", "zh-CN": "Remote Hub 部署", "zh-TW": "Remote Hub 部署", ru: "Развёртывание Remote Hub", ja: "Remote Hub のデプロイ", tr: "Remote Hub Dağıtımı" }, slug: "guides/remote-hub" },
-            { label: "Remote Link", translations: { fr: "Liaison distante", ko: "Remote Link", "zh-CN": "远程链接", "zh-TW": "遠端連結", ru: "Удалённая связь", ja: "リモートリンク", tr: "Uzak Bağlantı" }, slug: "guides/remote-link" },
-            { label: "Response Inspection", translations: { fr: "Inspection des réponses et réponses volumineuses", ko: "응답 검사와 대용량 응답", "zh-CN": "响应检查与大型响应", "zh-TW": "回應檢查與大型回應", ru: "Проверка ответов и большие ответы", ja: "レスポンスの検査と大きなレスポンス", tr: "Yanıt incelemesi ve büyük yanıtlar" }, slug: "guides/response-inspection" },
-            { label: "Remote Workspace", translations: { fr: "Espace de travail distant", ko: "원격 워크스페이스", "zh-CN": "远程工作区", "zh-TW": "遠端工作區", ru: "Удалённая рабочая область", ja: "リモートワークスペース", tr: "Uzak Çalışma Alanı" }, slug: "guides/remote-workspace" },
-            { label: "Providers", translations: { fr: "Fournisseurs", ko: "프로바이더", "zh-CN": "提供商", "zh-TW": "供應商", ru: "Провайдеры", ja: "プロバイダー", tr: "Sağlayıcılar" }, slug: "guides/providers" },
-            { label: "Factory Droid Bridge", translations: { fr: "Pont Factory Droid", ko: "Factory Droid 브리지", "zh-CN": "Factory Droid 桥接", "zh-TW": "Factory Droid 橋接", ru: "Мост Factory Droid", ja: "Factory Droid ブリッジ", tr: "Factory Droid köprüsü" }, slug: "guides/factory-droid" },
-            { label: "Ollama-Compatible Clients", translations: { fr: "Clients compatibles Ollama", ko: "Ollama 호환 클라이언트", "zh-CN": "Ollama 兼容客户端", "zh-TW": "Ollama 相容用戶端", ru: "Клиенты, совместимые с Ollama", ja: "Ollama 互換クライアント", tr: "Ollama uyumlu istemciler" }, slug: "guides/ollama-clients" },
-            { label: "Cursor Private Inference", translations: { ko: "Cursor Private Inference", fr: "Cursor Private Inference", "zh-CN": "Cursor Private Inference", "zh-TW": "Cursor Private Inference", ru: "Cursor Private Inference", ja: "Cursor Private Inference", tr: "Cursor Private Inference" }, slug: "guides/cursor-private-inference" },
-            { label: "Model Routing", translations: { fr: "Routage des modèles", ko: "모델 라우팅", "zh-CN": "模型路由", "zh-TW": "模型路由", ru: "Маршрутизация моделей", ja: "モデルルーティング", tr: "Model Yönlendirme" }, slug: "guides/model-routing" },
-            { label: "Codex Integration", translations: { fr: "Intégration de Codex", ko: "Codex 통합", "zh-CN": "Codex 集成", "zh-TW": "Codex 整合", ru: "Интеграция с Codex", ja: "Codex 連携", tr: "Codex Entegrasyonu" }, slug: "guides/codex-integration" },
-            { label: "Composer Usage-Gate Fallback", translations: { ko: "Codex 입력 제한 대체 경로" }, slug: "guides/composer-usage-gate-fallback" },
-            { label: "Codex App Model Picker", translations: { fr: "Sélecteur de modèles de Codex App", ko: "Codex App 모델 선택기", "zh-CN": "Codex App 模型选择器", "zh-TW": "Codex App 模型選擇器", ru: "Выбор модели в Codex App", ja: "Codex App モデルピッカー", tr: "Codex App Model Seçici" }, slug: "guides/codex-app-models" },
-            { label: "Codex Prompt Layers", translations: { fr: "Couches d'invite Codex", ko: "Codex 프롬프트 레이어", "zh-CN": "Codex 提示词层", "zh-TW": "Codex 提示詞層", ru: "Слои промпта Codex", ja: "Codex プロンプトレイヤー", tr: "Codex İstem Katmanları" }, slug: "guides/codex-prompt" },
-            { label: "Native Context Compatibility", translations: { ko: "네이티브 컨텍스트 호환성", fr: "Compatibilité du contexte natif", "zh-CN": "原生上下文兼容性", "zh-TW": "原生脈絡相容性", ru: "Совместимость с нативным контекстом", ja: "ネイティブコンテキストの互換性", tr: "Yerel bağlam uyumluluğu" }, slug: "guides/codex-native-context" },
-            { label: "macOS Menu Bar App", translations: { fr: "Application barre de menus macOS", ko: "macOS 메뉴바 앱", "zh-CN": "macOS 菜单栏应用", "zh-TW": "macOS 選單列 App", ru: "Приложение в строке меню macOS", ja: "macOS メニューバーアプリ", tr: "macOS Menü Çubuğu Uygulaması" }, slug: "guides/macos-menu-bar" },
-            { label: "Desktop App", translations: { fr: "Application de bureau", ko: "데스크톱 앱", "zh-CN": "桌面应用", "zh-TW": "桌面 App", ru: "Настольное приложение", ja: "デスクトップアプリ", tr: "Masaüstü Uygulaması" }, slug: "guides/desktop-app" },
-            { label: "Model Ordering", translations: { fr: "Ordre des modèles", ko: "모델 정렬에 관하여", "zh-CN": "模型排序", "zh-TW": "模型排序", ru: "Сортировка моделей", ja: "モデルの並び順", tr: "Model Sıralaması" }, slug: "guides/model-ordering" },
-            { label: "Combos", translations: { fr: "Combinaisons", ko: "콤보", "zh-CN": "组合", "zh-TW": "組合", ru: "Комбо", ja: "コンボ", tr: "Kombolar" }, slug: "guides/combos" },
-            { label: "Fallback off", translations: { fr: "Désactiver le repli", ko: "폴백 끄기", "zh-CN": "关闭回退", "zh-TW": "關閉備援", ru: "Отключение резерва", ja: "フォールバックをオフにする", tr: "Yedeği kapatma" }, slug: "guides/fallback-off" },
-            { label: "Protocol Paths", translations: { fr: "Chemins de protocole", ko: "프로토콜 경로", "zh-CN": "协议路径", "zh-TW": "協定路徑", ru: "Пути протоколов", ja: "プロトコル経路", tr: "Protokol Yolları" }, slug: "guides/protocol-paths" },
-            { label: "Claude Code", translations: { fr: "Claude Code", ko: "Claude Code", "zh-CN": "Claude Code", "zh-TW": "Claude Code", ru: "Claude Code", ja: "Claude Code", tr: "Claude Code" }, slug: "guides/claude-code" },
-            { label: "Grok Build", translations: { fr: "Grok Build", ko: "Grok Build", "zh-CN": "Grok Build", "zh-TW": "Grok Build", ru: "Grok Build", ja: "Grok Build", tr: "Grok Build" }, slug: "guides/grok-build" },
-            { label: "opencode", translations: { fr: "opencode", ko: "opencode", "zh-CN": "opencode", "zh-TW": "opencode", ru: "opencode", ja: "opencode", tr: "opencode" }, slug: "guides/opencode" },
-            { label: "Pi", translations: { fr: "Pi", ko: "Pi", "zh-CN": "Pi", "zh-TW": "Pi", ru: "Pi", ja: "Pi", tr: "Pi" }, slug: "guides/pi" },
+            { label: "Remote Hub Deployment", translations: { es: "Despliegue de Remote Hub", fr: "Déploiement Remote Hub", ko: "Remote Hub 배포", "zh-CN": "Remote Hub 部署", "zh-TW": "Remote Hub 部署", ru: "Развёртывание Remote Hub", ja: "Remote Hub のデプロイ", tr: "Remote Hub Dağıtımı" }, slug: "guides/remote-hub" },
+            { label: "Remote Link", translations: { es: "Enlace remoto", fr: "Liaison distante", ko: "Remote Link", "zh-CN": "远程链接", "zh-TW": "遠端連結", ru: "Удалённая связь", ja: "リモートリンク", tr: "Uzak Bağlantı" }, slug: "guides/remote-link" },
+            { label: "Response Inspection", translations: { es: "Inspección de respuestas", fr: "Inspection des réponses et réponses volumineuses", ko: "응답 검사와 대용량 응답", "zh-CN": "响应检查与大型响应", "zh-TW": "回應檢查與大型回應", ru: "Проверка ответов и большие ответы", ja: "レスポンスの検査と大きなレスポンス", tr: "Yanıt incelemesi ve büyük yanıtlar" }, slug: "guides/response-inspection" },
+            { label: "Remote Workspace", translations: { es: "Espacio de trabajo remoto", fr: "Espace de travail distant", ko: "원격 워크스페이스", "zh-CN": "远程工作区", "zh-TW": "遠端工作區", ru: "Удалённая рабочая область", ja: "リモートワークスペース", tr: "Uzak Çalışma Alanı" }, slug: "guides/remote-workspace" },
+            { label: "Providers", translations: { es: "Proveedores", fr: "Fournisseurs", ko: "프로바이더", "zh-CN": "提供商", "zh-TW": "供應商", ru: "Провайдеры", ja: "プロバイダー", tr: "Sağlayıcılar" }, slug: "guides/providers" },
+            { label: "Factory Droid Bridge", translations: { es: "Puente Factory Droid", fr: "Pont Factory Droid", ko: "Factory Droid 브리지", "zh-CN": "Factory Droid 桥接", "zh-TW": "Factory Droid 橋接", ru: "Мост Factory Droid", ja: "Factory Droid ブリッジ", tr: "Factory Droid köprüsü" }, slug: "guides/factory-droid" },
+            { label: "Ollama-Compatible Clients", translations: { es: "Clientes compatibles con Ollama", fr: "Clients compatibles Ollama", ko: "Ollama 호환 클라이언트", "zh-CN": "Ollama 兼容客户端", "zh-TW": "Ollama 相容用戶端", ru: "Клиенты, совместимые с Ollama", ja: "Ollama 互換クライアント", tr: "Ollama uyumlu istemciler" }, slug: "guides/ollama-clients" },
+            { label: "Cursor Private Inference", translations: { es: "Inferencia privada de Cursor", ko: "Cursor Private Inference", fr: "Cursor Private Inference", "zh-CN": "Cursor Private Inference", "zh-TW": "Cursor Private Inference", ru: "Cursor Private Inference", ja: "Cursor Private Inference", tr: "Cursor Private Inference" }, slug: "guides/cursor-private-inference" },
+            { label: "Model Routing", translations: { es: "Enrutamiento de modelos", fr: "Routage des modèles", ko: "모델 라우팅", "zh-CN": "模型路由", "zh-TW": "模型路由", ru: "Маршрутизация моделей", ja: "モデルルーティング", tr: "Model Yönlendirme" }, slug: "guides/model-routing" },
+            { label: "Codex Integration", translations: { es: "Integración con Codex", fr: "Intégration de Codex", ko: "Codex 통합", "zh-CN": "Codex 集成", "zh-TW": "Codex 整合", ru: "Интеграция с Codex", ja: "Codex 連携", tr: "Codex Entegrasyonu" }, slug: "guides/codex-integration" },
+            { label: "Composer Usage-Gate Fallback", translations: { es: "Alternativa ante límites de uso de Composer", ko: "Codex 입력 제한 대체 경로" }, slug: "guides/composer-usage-gate-fallback" },
+            { label: "Codex App Model Picker", translations: { es: "Selector de modelos de Codex App", fr: "Sélecteur de modèles de Codex App", ko: "Codex App 모델 선택기", "zh-CN": "Codex App 模型选择器", "zh-TW": "Codex App 模型選擇器", ru: "Выбор модели в Codex App", ja: "Codex App モデルピッカー", tr: "Codex App Model Seçici" }, slug: "guides/codex-app-models" },
+            { label: "Codex Prompt Layers", translations: { es: "Capas de instrucciones de Codex", fr: "Couches d'invite Codex", ko: "Codex 프롬프트 레이어", "zh-CN": "Codex 提示词层", "zh-TW": "Codex 提示詞層", ru: "Слои промпта Codex", ja: "Codex プロンプトレイヤー", tr: "Codex İstem Katmanları" }, slug: "guides/codex-prompt" },
+            { label: "Native Context Compatibility", translations: { es: "Compatibilidad de contexto nativo", ko: "네이티브 컨텍스트 호환성", fr: "Compatibilité du contexte natif", "zh-CN": "原生上下文兼容性", "zh-TW": "原生脈絡相容性", ru: "Совместимость с нативным контекстом", ja: "ネイティブコンテキストの互換性", tr: "Yerel bağlam uyumluluğu" }, slug: "guides/codex-native-context" },
+            { label: "macOS Menu Bar App", translations: { es: "Aplicación de barra de menús de macOS", fr: "Application barre de menus macOS", ko: "macOS 메뉴바 앱", "zh-CN": "macOS 菜单栏应用", "zh-TW": "macOS 選單列 App", ru: "Приложение в строке меню macOS", ja: "macOS メニューバーアプリ", tr: "macOS Menü Çubuğu Uygulaması" }, slug: "guides/macos-menu-bar" },
+            { label: "Desktop App", translations: { es: "Aplicación de escritorio", fr: "Application de bureau", ko: "데스크톱 앱", "zh-CN": "桌面应用", "zh-TW": "桌面 App", ru: "Настольное приложение", ja: "デスクトップアプリ", tr: "Masaüstü Uygulaması" }, slug: "guides/desktop-app" },
+            { label: "Model Ordering", translations: { es: "Orden de modelos", fr: "Ordre des modèles", ko: "모델 정렬에 관하여", "zh-CN": "模型排序", "zh-TW": "模型排序", ru: "Сортировка моделей", ja: "モデルの並び順", tr: "Model Sıralaması" }, slug: "guides/model-ordering" },
+            { label: "Combos", translations: { es: "Combos", fr: "Combinaisons", ko: "콤보", "zh-CN": "组合", "zh-TW": "組合", ru: "Комбо", ja: "コンボ", tr: "Kombolar" }, slug: "guides/combos" },
+            { label: "Fallback off", translations: { es: "Desactivar el fallback", fr: "Désactiver le repli", ko: "폴백 끄기", "zh-CN": "关闭回退", "zh-TW": "關閉備援", ru: "Отключение резерва", ja: "フォールバックをオフにする", tr: "Yedeği kapatma" }, slug: "guides/fallback-off" },
+            { label: "Protocol Paths", translations: { es: "Rutas de protocolo", fr: "Chemins de protocole", ko: "프로토콜 경로", "zh-CN": "协议路径", "zh-TW": "協定路徑", ru: "Пути протоколов", ja: "プロトコル経路", tr: "Protokol Yolları" }, slug: "guides/protocol-paths" },
+            { label: "Claude Code", translations: { es: "Claude Code", fr: "Claude Code", ko: "Claude Code", "zh-CN": "Claude Code", "zh-TW": "Claude Code", ru: "Claude Code", ja: "Claude Code", tr: "Claude Code" }, slug: "guides/claude-code" },
+            { label: "Grok Build", translations: { es: "Grok Build", fr: "Grok Build", ko: "Grok Build", "zh-CN": "Grok Build", "zh-TW": "Grok Build", ru: "Grok Build", ja: "Grok Build", tr: "Grok Build" }, slug: "guides/grok-build" },
+            { label: "opencode", translations: { es: "OpenCode", fr: "opencode", ko: "opencode", "zh-CN": "opencode", "zh-TW": "opencode", ru: "opencode", ja: "opencode", tr: "opencode" }, slug: "guides/opencode" },
+            { label: "Pi", translations: { es: "Pi", fr: "Pi", ko: "Pi", "zh-CN": "Pi", "zh-TW": "Pi", ru: "Pi", ja: "Pi", tr: "Pi" }, slug: "guides/pi" },
             { label: "ChatGPT Desktop (experimental)", slug: "guides/chatgpt-desktop" },
-            { label: "Integrations", translations: { fr: "Intégrations", ko: "연동", "zh-CN": "集成", "zh-TW": "整合", ru: "Интеграции", ja: "連携", tr: "Entegrasyonlar" }, slug: "guides/integrations" },
-            { label: "MiniMax clients", translations: { fr: "Clients MiniMax", ko: "MiniMax 클라이언트", "zh-CN": "MiniMax 客户端", "zh-TW": "MiniMax 客戶端", ru: "Клиенты MiniMax", ja: "MiniMax クライアント", tr: "MiniMax İstemcileri" }, slug: "guides/minimax" },
-            { label: "Sidecars: Web Search & Vision", translations: { fr: "Services auxiliaires : recherche web et vision", ko: "사이드카: 웹 검색 & 비전", "zh-CN": "边车：网络搜索与视觉", "zh-TW": "邊車：網路搜尋與視覺", ru: "Сайдкары: веб-поиск и зрение", ja: "サイドカー: ウェブ検索 & ビジョン", tr: "Sidecar'lar: Web Arama ve Görme" }, slug: "guides/sidecars" },
-            { label: "Local Plugins", translations: { fr: "Plugins locaux", ko: "로컬 플러그인", "zh-CN": "本地插件", "zh-TW": "本機外掛", ru: "Локальные плагины", ja: "ローカルプラグイン", tr: "Yerel Eklentiler" }, slug: "guides/local-plugins" },
-            { label: "Image Bridge", translations: { fr: "Pont d’images", ko: "이미지 브릿지", "zh-CN": "图像桥接", "zh-TW": "圖像橋接", ru: "Image Bridge", ja: "画像ブリッジ", tr: "Image Bridge" }, slug: "guides/image-bridge" },
-            { label: "Video Bridge", translations: { fr: "Pont vidéo", ko: "비디오 브릿지", "zh-CN": "视频桥接", "zh-TW": "影片橋接", ru: "Video Bridge", ja: "動画ブリッジ", tr: "Video Bridge" }, slug: "guides/video-bridge" },
-            { label: "Web Dashboard", translations: { fr: "Tableau de bord web", ko: "웹 대시보드", "zh-CN": "网页控制台", "zh-TW": "網頁儀表板", ru: "Веб-дашборд", ja: "ウェブダッシュボード", tr: "Web Kontrol Paneli" }, slug: "guides/web-dashboard" },
-            { label: "Telemetry & Privacy", translations: { fr: "Télémétrie et confidentialité", ko: "텔레메트리 및 개인정보", "zh-CN": "遥测与隐私", "zh-TW": "遙測與隱私", ru: "Телеметрия и конфиденциальность", ja: "テレメトリとプライバシー", tr: "Telemetri ve Gizlilik" }, slug: "guides/telemetry" },
-            { label: "Sub-agent Surface", translations: { fr: "Interface des sous-agents", ko: "서브에이전트 서피스", "zh-CN": "子代理界面", "zh-TW": "子代理介面", ru: "Интерфейс подагентов", ja: "サブエージェントサーフェス", tr: "Alt Ajan Arayüzü" }, slug: "guides/sub-agent-surface" },
-            { label: "Why v1 Is the Default", translations: { fr: "Pourquoi v1 est la valeur par défaut", ko: "v1이 기본값인 이유", "zh-CN": "为什么默认是 v1", "zh-TW": "為什麼預設是 v1", ru: "Почему v1 по умолчанию", ja: "v1 がデフォルトである理由", tr: "Neden varsayılan v1" }, slug: "guides/subagent-v1-default" },
+            { label: "Integrations", translations: { es: "Integraciones", fr: "Intégrations", ko: "연동", "zh-CN": "集成", "zh-TW": "整合", ru: "Интеграции", ja: "連携", tr: "Entegrasyonlar" }, slug: "guides/integrations" },
+            { label: "MiniMax clients", translations: { es: "Clientes MiniMax", fr: "Clients MiniMax", ko: "MiniMax 클라이언트", "zh-CN": "MiniMax 客户端", "zh-TW": "MiniMax 客戶端", ru: "Клиенты MiniMax", ja: "MiniMax クライアント", tr: "MiniMax İstemcileri" }, slug: "guides/minimax" },
+            { label: "Sidecars: Web Search & Vision", translations: { es: "Sidecars: búsqueda web y visión", fr: "Services auxiliaires : recherche web et vision", ko: "사이드카: 웹 검색 & 비전", "zh-CN": "边车：网络搜索与视觉", "zh-TW": "邊車：網路搜尋與視覺", ru: "Сайдкары: веб-поиск и зрение", ja: "サイドカー: ウェブ検索 & ビジョン", tr: "Sidecar'lar: Web Arama ve Görme" }, slug: "guides/sidecars" },
+            { label: "Local Plugins", translations: { es: "Plugins locales", fr: "Plugins locaux", ko: "로컬 플러그인", "zh-CN": "本地插件", "zh-TW": "本機外掛", ru: "Локальные плагины", ja: "ローカルプラグイン", tr: "Yerel Eklentiler" }, slug: "guides/local-plugins" },
+            { label: "Image Bridge", translations: { es: "Puente de imágenes", fr: "Pont d’images", ko: "이미지 브릿지", "zh-CN": "图像桥接", "zh-TW": "圖像橋接", ru: "Image Bridge", ja: "画像ブリッジ", tr: "Image Bridge" }, slug: "guides/image-bridge" },
+            { label: "Video Bridge", translations: { es: "Puente de video", fr: "Pont vidéo", ko: "비디오 브릿지", "zh-CN": "视频桥接", "zh-TW": "影片橋接", ru: "Video Bridge", ja: "動画ブリッジ", tr: "Video Bridge" }, slug: "guides/video-bridge" },
+            { label: "Web Dashboard", translations: { es: "Dashboard web", fr: "Tableau de bord web", ko: "웹 대시보드", "zh-CN": "网页控制台", "zh-TW": "網頁儀表板", ru: "Веб-дашборд", ja: "ウェブダッシュボード", tr: "Web Kontrol Paneli" }, slug: "guides/web-dashboard" },
+            { label: "Telemetry & Privacy", translations: { es: "Telemetría", fr: "Télémétrie et confidentialité", ko: "텔레메트리 및 개인정보", "zh-CN": "遥测与隐私", "zh-TW": "遙測與隱私", ru: "Телеметрия и конфиденциальность", ja: "テレメトリとプライバシー", tr: "Telemetri ve Gizlilik" }, slug: "guides/telemetry" },
+            { label: "Sub-agent Surface", translations: { es: "Interfaz de subagentes", fr: "Interface des sous-agents", ko: "서브에이전트 서피스", "zh-CN": "子代理界面", "zh-TW": "子代理介面", ru: "Интерфейс подагентов", ja: "サブエージェントサーフェス", tr: "Alt Ajan Arayüzü" }, slug: "guides/sub-agent-surface" },
+            { label: "Why v1 Is the Default", translations: { es: "Por qué v1 es la opción predeterminada", fr: "Pourquoi v1 est la valeur par défaut", ko: "v1이 기본값인 이유", "zh-CN": "为什么默认是 v1", "zh-TW": "為什麼預設是 v1", ru: "Почему v1 по умолчанию", ja: "v1 がデフォルトである理由", tr: "Neden varsayılan v1" }, slug: "guides/subagent-v1-default" },
           ],
         },
         {
           label: "Benchmarks",
-          translations: { fr: "Bancs d’essai", ko: "벤치마크", "zh-CN": "基准测试", "zh-TW": "基準測試", ru: "Бенчмарки", ja: "ベンチマーク", tr: "Kıyaslamalar" },
+          translations: { es: "Pruebas comparativas", fr: "Bancs d’essai", ko: "벤치마크", "zh-CN": "基准测试", "zh-TW": "基準測試", ru: "Бенчмарки", ja: "ベンチマーク", tr: "Kıyaslamalar" },
           collapsed: true,
           items: [
-            { label: "Overview", translations: { fr: "Vue d’ensemble", ko: "개요", "zh-CN": "概览", "zh-TW": "概覽", ru: "Обзор", ja: "概要", tr: "Genel Bakış" }, slug: "benchmarks" },
-            { label: "Coding", translations: { fr: "Programmation", ko: "코딩", "zh-CN": "编程", "zh-TW": "程式設計", ru: "Кодинг", ja: "コーディング", tr: "Kodlama" }, slug: "benchmarks/coding" },
-            { label: "Frontend", translations: { fr: "Frontend", ko: "프론트엔드", "zh-CN": "前端", "zh-TW": "前端", ru: "Фронтенд", ja: "フロントエンド", tr: "Ön Yüz" }, slug: "benchmarks/frontend" },
-            { label: "Terminal", translations: { fr: "Terminal", ko: "터미널", "zh-CN": "终端", "zh-TW": "終端", ru: "Терминал", ja: "ターミナル", tr: "Terminal" }, slug: "benchmarks/terminal" },
-            { label: "Security", translations: { fr: "Sécurité", ko: "보안", "zh-CN": "安全", "zh-TW": "安全", ru: "Безопасность", ja: "セキュリティ", tr: "Güvenlik" }, slug: "benchmarks/security" },
-            { label: "Intelligence", translations: { fr: "Intelligence", ko: "인텔리전스", "zh-CN": "智能", "zh-TW": "智慧", ru: "Интеллект", ja: "インテリジェンス", tr: "Zeka" }, slug: "benchmarks/intelligence" },
+            { label: "Overview", translations: { es: "Descripción general", fr: "Vue d’ensemble", ko: "개요", "zh-CN": "概览", "zh-TW": "概覽", ru: "Обзор", ja: "概要", tr: "Genel Bakış" }, slug: "benchmarks" },
+            { label: "Coding", translations: { es: "Codificación", fr: "Programmation", ko: "코딩", "zh-CN": "编程", "zh-TW": "程式設計", ru: "Кодинг", ja: "コーディング", tr: "Kodlama" }, slug: "benchmarks/coding" },
+            { label: "Frontend", translations: { es: "Frontend", fr: "Frontend", ko: "프론트엔드", "zh-CN": "前端", "zh-TW": "前端", ru: "Фронтенд", ja: "フロントエンド", tr: "Ön Yüz" }, slug: "benchmarks/frontend" },
+            { label: "Terminal", translations: { es: "Terminal", fr: "Terminal", ko: "터미널", "zh-CN": "终端", "zh-TW": "終端", ru: "Терминал", ja: "ターミナル", tr: "Terminal" }, slug: "benchmarks/terminal" },
+            { label: "Security", translations: { es: "Seguridad", fr: "Sécurité", ko: "보안", "zh-CN": "安全", "zh-TW": "安全", ru: "Безопасность", ja: "セキュリティ", tr: "Güvenlik" }, slug: "benchmarks/security" },
+            { label: "Intelligence", translations: { es: "Inteligencia", fr: "Intelligence", ko: "인텔리전스", "zh-CN": "智能", "zh-TW": "智慧", ru: "Интеллект", ja: "インテリジェンス", tr: "Zeka" }, slug: "benchmarks/intelligence" },
           ],
         },
         {
           label: "Reference",
-          translations: { fr: "Référence", ko: "레퍼런스", "zh-CN": "参考", "zh-TW": "參考", ru: "Справочник", ja: "リファレンス", tr: "Referans" },
+          translations: { es: "Referencia", fr: "Référence", ko: "레퍼런스", "zh-CN": "参考", "zh-TW": "參考", ru: "Справочник", ja: "リファレンス", tr: "Referans" },
           items: [
             {
               label: "CLI",
-              translations: { fr: "CLI", ko: "CLI", "zh-CN": "命令行", "zh-TW": "命令列", ru: "CLI", ja: "CLI", tr: "CLI" },
+              translations: { es: "CLI", fr: "CLI", ko: "CLI", "zh-CN": "命令行", "zh-TW": "命令列", ru: "CLI", ja: "CLI", tr: "CLI" },
               items: [
-                { label: "Overview", translations: { fr: "Vue d’ensemble", ko: "개요", "zh-CN": "概览", "zh-TW": "概覽", ru: "Обзор", ja: "概要", tr: "Genel Bakış" }, slug: "reference/cli" },
-                { label: "Lifecycle & Service", translations: { fr: "Cycle de vie et service", ko: "라이프사이클 & 서비스", "zh-CN": "生命周期与服务", "zh-TW": "生命週期與服務", ru: "Жизненный цикл и служба", ja: "ライフサイクル & サービス", tr: "Yaşam Döngüsü ve Servis" }, slug: "reference/cli/lifecycle" },
-                { label: "Providers, Accounts & Models", translations: { fr: "Fournisseurs, comptes et modèles", ko: "프로바이더, 계정 & 모델", "zh-CN": "提供商、账户与模型", "zh-TW": "供應商、帳號與模型", ru: "Провайдеры, аккаунты и модели", ja: "プロバイダー・アカウント・モデル", tr: "Sağlayıcılar, Hesaplar ve Modeller" }, slug: "reference/cli/providers-accounts" },
-                { label: "Agents, Routing & Integrations", translations: { fr: "Agents, routage et intégrations", ko: "에이전트, 라우팅 & 통합", "zh-CN": "代理、路由与集成", "zh-TW": "代理、路由與整合", ru: "Агенты, маршрутизация и интеграции", ja: "エージェント・ルーティング・連携", tr: "Ajanlar, Yönlendirme ve Entegrasyonlar" }, slug: "reference/cli/agents" },
+                { label: "Overview", translations: { es: "Descripción general", fr: "Vue d’ensemble", ko: "개요", "zh-CN": "概览", "zh-TW": "概覽", ru: "Обзор", ja: "概要", tr: "Genel Bakış" }, slug: "reference/cli" },
+                { label: "Lifecycle & Service", translations: { es: "Ciclo de vida y servicio", fr: "Cycle de vie et service", ko: "라이프사이클 & 서비스", "zh-CN": "生命周期与服务", "zh-TW": "生命週期與服務", ru: "Жизненный цикл и служба", ja: "ライフサイクル & サービス", tr: "Yaşam Döngüsü ve Servis" }, slug: "reference/cli/lifecycle" },
+                { label: "Providers, Accounts & Models", translations: { es: "Proveedores, cuentas y modelos", fr: "Fournisseurs, comptes et modèles", ko: "프로바이더, 계정 & 모델", "zh-CN": "提供商、账户与模型", "zh-TW": "供應商、帳號與模型", ru: "Провайдеры, аккаунты и модели", ja: "プロバイダー・アカウント・モデル", tr: "Sağlayıcılar, Hesaplar ve Modeller" }, slug: "reference/cli/providers-accounts" },
+                { label: "Agents, Routing & Integrations", translations: { es: "Agentes, enrutamiento e integraciones", fr: "Agents, routage et intégrations", ko: "에이전트, 라우팅 & 통합", "zh-CN": "代理、路由与集成", "zh-TW": "代理、路由與整合", ru: "Агенты, маршрутизация и интеграции", ja: "エージェント・ルーティング・連携", tr: "Ajanlar, Yönlendirme ve Entegrasyonlar" }, slug: "reference/cli/agents" },
               ],
             },
             {
               label: "Configuration",
-              translations: { fr: "Configuration", ko: "설정", "zh-CN": "配置", "zh-TW": "設定", ru: "Конфигурация", ja: "設定", tr: "Yapılandırma" },
+              translations: { es: "Configuración", fr: "Configuration", ko: "설정", "zh-CN": "配置", "zh-TW": "設定", ru: "Конфигурация", ja: "設定", tr: "Yapılandırma" },
               items: [
-                { label: "Overview", translations: { fr: "Vue d’ensemble", ko: "개요", "zh-CN": "概览", "zh-TW": "概覽", ru: "Обзор", ja: "概要", tr: "Genel Bakış" }, slug: "reference/configuration" },
-                { label: "Providers", translations: { fr: "Fournisseurs", ko: "프로바이더", "zh-CN": "提供商", "zh-TW": "供應商", ru: "Провайдеры", ja: "プロバイダー", tr: "Sağlayıcılar" }, slug: "reference/configuration/providers" },
-                { label: "Catalog", translations: { fr: "Catalogue", ko: "카탈로그", "zh-CN": "目录", "zh-TW": "目錄", ru: "Каталог", ja: "カタログ", tr: "Katalog" }, slug: "reference/configuration/catalog" },
-                { label: "Routing", translations: { fr: "Routage", ko: "라우팅", "zh-CN": "路由", "zh-TW": "路由", ru: "Маршрутизация", ja: "ルーティング", tr: "Yönlendirme" }, slug: "reference/configuration/routing" },
-                { label: "Agents", translations: { fr: "Agents", ko: "에이전트", "zh-CN": "代理", "zh-TW": "代理", ru: "Агенты", ja: "エージェント", tr: "Ajanlar" }, slug: "reference/configuration/agents" },
-                { label: "Advisor", translations: { fr: "Conseiller", ko: "어드바이저", "zh-CN": "顾问", "zh-TW": "顧問", ru: "Консультант", ja: "アドバイザー", tr: "Danışman" }, slug: "reference/configuration/advisor" },
-                { label: "Server & Runtime", translations: { fr: "Serveur et environnement d’exécution", ko: "서버 & 런타임", "zh-CN": "服务器与运行时", "zh-TW": "伺服器與執行階段", ru: "Сервер и рантайм", ja: "サーバー & ランタイム", tr: "Sunucu ve Çalışma Zamanı" }, slug: "reference/configuration/server" },
+                { label: "Overview", translations: { es: "Descripción general", fr: "Vue d’ensemble", ko: "개요", "zh-CN": "概览", "zh-TW": "概覽", ru: "Обзор", ja: "概要", tr: "Genel Bakış" }, slug: "reference/configuration" },
+                { label: "Providers", translations: { es: "Proveedores", fr: "Fournisseurs", ko: "프로바이더", "zh-CN": "提供商", "zh-TW": "供應商", ru: "Провайдеры", ja: "プロバイダー", tr: "Sağlayıcılar" }, slug: "reference/configuration/providers" },
+                { label: "OS Keychain", translations: { es: "Llavero del sistema" }, slug: "reference/configuration/keychain" },
+                { label: "Catalog", translations: { es: "Catálogo", fr: "Catalogue", ko: "카탈로그", "zh-CN": "目录", "zh-TW": "目錄", ru: "Каталог", ja: "カタログ", tr: "Katalog" }, slug: "reference/configuration/catalog" },
+                { label: "Routing", translations: { es: "Enrutamiento", fr: "Routage", ko: "라우팅", "zh-CN": "路由", "zh-TW": "路由", ru: "Маршрутизация", ja: "ルーティング", tr: "Yönlendirme" }, slug: "reference/configuration/routing" },
+                { label: "Agents", translations: { es: "Agentes", fr: "Agents", ko: "에이전트", "zh-CN": "代理", "zh-TW": "代理", ru: "Агенты", ja: "エージェント", tr: "Ajanlar" }, slug: "reference/configuration/agents" },
+                { label: "Advisor", translations: { es: "Advisor", fr: "Conseiller", ko: "어드바이저", "zh-CN": "顾问", "zh-TW": "顧問", ru: "Консультант", ja: "アドバイザー", tr: "Danışman" }, slug: "reference/configuration/advisor" },
+                { label: "Server & Runtime", translations: { es: "Servidor y entorno de ejecución", fr: "Serveur et environnement d’exécution", ko: "서버 & 런타임", "zh-CN": "服务器与运行时", "zh-TW": "伺服器與執行階段", ru: "Сервер и рантайм", ja: "サーバー & ランタイム", tr: "Sunucu ve Çalışma Zamanı" }, slug: "reference/configuration/server" },
               ],
             },
-            { label: "Client Support", translations: { fr: "Clients pris en charge", ko: "클라이언트 지원", "zh-CN": "客户端支持", "zh-TW": "用戶端支援", ru: "Поддержка клиентов", ja: "クライアント対応", tr: "İstemci desteği" }, slug: "reference/client-support" },
-            { label: "Adapters", translations: { fr: "Adaptateurs", ko: "어댑터", "zh-CN": "适配器", "zh-TW": "適配器", ru: "Адаптеры", ja: "アダプター", tr: "Adaptörler" }, slug: "reference/adapters" },
-            { label: "Architecture", translations: { fr: "Architecture", ko: "아키텍처", "zh-CN": "架构", "zh-TW": "架構", ru: "Архитектура", ja: "アーキテクチャ", tr: "Mimari" }, slug: "reference/architecture" },
-            { label: "Platform Support", translations: { fr: "Prise en charge des plateformes", ko: "플랫폼 지원", "zh-CN": "平台支持", "zh-TW": "平台支援", ru: "Поддержка платформ", ja: "プラットフォーム対応", tr: "Platform Desteği" }, link: `${SITE_URL}/reference/platform-support` },
-            { label: "Windows Code Signing", translations: { fr: "Signature du code Windows", ko: "Windows 코드 서명", "zh-CN": "Windows 代码签名", "zh-TW": "Windows 程式碼簽署", ru: "Подпись кода Windows", ja: "Windows コード署名", tr: "Windows Kod İmzalama" }, slug: "reference/code-signing" },
-            { label: "Proxy API Formats", translations: { fr: "Formats de l’API proxy", ko: "프록시 API 형식", "zh-CN": "代理 API 格式", "zh-TW": "代理 API 格式", ru: "Форматы API прокси", ja: "プロキシAPI形式", tr: "Proxy API Formatları" }, slug: "reference/proxy-formats" },
-            { label: "Management API", translations: { fr: "API de gestion", ko: "관리 API", "zh-CN": "管理 API", "zh-TW": "管理 API", ru: "API управления", ja: "管理API", tr: "Yönetim API'si" }, slug: "reference/management-api" },
+            { label: "Client Support", translations: { es: "Compatibilidad con clientes", fr: "Clients pris en charge", ko: "클라이언트 지원", "zh-CN": "客户端支持", "zh-TW": "用戶端支援", ru: "Поддержка клиентов", ja: "クライアント対応", tr: "İstemci desteği" }, slug: "reference/client-support" },
+            { label: "Adapters", translations: { es: "Adaptadores", fr: "Adaptateurs", ko: "어댑터", "zh-CN": "适配器", "zh-TW": "適配器", ru: "Адаптеры", ja: "アダプター", tr: "Adaptörler" }, slug: "reference/adapters" },
+            { label: "Architecture", translations: { es: "Arquitectura", fr: "Architecture", ko: "아키텍처", "zh-CN": "架构", "zh-TW": "架構", ru: "Архитектура", ja: "アーキテクチャ", tr: "Mimari" }, slug: "reference/architecture" },
+            { label: "Platform Support", translations: { es: "Soporte de plataforma", fr: "Prise en charge des plateformes", ko: "플랫폼 지원", "zh-CN": "平台支持", "zh-TW": "平台支援", ru: "Поддержка платформ", ja: "プラットフォーム対応", tr: "Platform Desteği" }, slug: "reference/platform-support" },
+            { label: "Windows Code Signing", translations: { es: "Firma de código en Windows", fr: "Signature du code Windows", ko: "Windows 코드 서명", "zh-CN": "Windows 代码签名", "zh-TW": "Windows 程式碼簽署", ru: "Подпись кода Windows", ja: "Windows コード署名", tr: "Windows Kod İmzalama" }, slug: "reference/code-signing" },
+            { label: "Proxy API Formats", translations: { es: "Formatos de API del proxy", fr: "Formats de l’API proxy", ko: "프록시 API 형식", "zh-CN": "代理 API 格式", "zh-TW": "代理 API 格式", ru: "Форматы API прокси", ja: "プロキシAPI形式", tr: "Proxy API Formatları" }, slug: "reference/proxy-formats" },
+            { label: "Management API", translations: { es: "API de administración", fr: "API de gestion", ko: "관리 API", "zh-CN": "管理 API", "zh-TW": "管理 API", ru: "API управления", ja: "管理API", tr: "Yönetim API'si" }, slug: "reference/management-api" },
           ],
         },
         {
           label: "Troubleshooting",
-          translations: { fr: "Dépannage", ko: "문제 해결", "zh-CN": "故障排除", "zh-TW": "疑難排解", ru: "Устранение неполадок", ja: "トラブルシューティング", tr: "Sorun Giderme" },
+          translations: { es: "Solución de problemas", fr: "Dépannage", ko: "문제 해결", "zh-CN": "故障排除", "zh-TW": "疑難排解", ru: "Устранение неполадок", ja: "トラブルシューティング", tr: "Sorun Giderme" },
           collapsed: true,
           items: [
-            { label: "Windows Memory Growth", translations: { fr: "Augmentation de la mémoire sous Windows", ko: "Windows 메모리 증가", "zh-CN": "Windows 内存增长", "zh-TW": "Windows 記憶體增長", ru: "Рост памяти в Windows", ja: "Windows メモリ増加", tr: "Windows Bellek Artışı" }, slug: "troubleshooting/windows-memory" },
-            { label: "Disk Usage from Temp Files", translations: { fr: "Espace disque et fichiers temporaires", ko: "임시 파일 디스크 사용량", "zh-CN": "临时文件磁盘占用", "zh-TW": "暫存檔磁碟用量", ru: "Использование диска временными файлами", ja: "一時ファイルのディスク使用量", tr: "Geçici Dosya Disk Kullanımı" }, slug: "troubleshooting/disk-usage-temp-files" },
-            { label: "Codex Cannot Sign In or Load", translations: { fr: "Codex ne peut pas se connecter", ko: "Codex 로그인 불가", "zh-CN": "Codex 无法登录", "zh-TW": "Codex 無法登入", ru: "Codex не может войти", ja: "Codex にサインインできない", tr: "Codex Oturum Açamıyor" }, slug: "troubleshooting/codex-cannot-sign-in" },
-            { label: "Update Failed on Windows", translations: { fr: "Échec de la mise à jour sous Windows", ko: "Windows에서 업데이트 실패", "zh-CN": "Windows 上更新失败", "zh-TW": "Windows 上更新失敗", ru: "Сбой обновления в Windows", ja: "Windows で更新に失敗する", tr: "Windows'ta Güncelleme Başarısız" }, slug: "troubleshooting/update-failed" },
-            { label: "Spend Ledger Refused in a Synced Folder", translations: { fr: "Registre de dépenses refusé dans un dossier synchronisé", ko: "동기화 폴더에서 지출 원장 거부", "zh-CN": "同步文件夹中的支出账本被拒绝", "zh-TW": "同步資料夾中的支出帳本被拒絕", ru: "Отказ журнала расходов в синхронизируемой папке", ja: "同期フォルダーで支出台帳が拒否される", tr: "Eşitlenen Klasörde Harcama Defteri Reddi" }, slug: "troubleshooting/spend-ledger-synced-folder" },
+            { label: "Windows Memory Growth", translations: { es: "Crecimiento del uso de memoria en Windows", fr: "Augmentation de la mémoire sous Windows", ko: "Windows 메모리 증가", "zh-CN": "Windows 内存增长", "zh-TW": "Windows 記憶體增長", ru: "Рост памяти в Windows", ja: "Windows メモリ増加", tr: "Windows Bellek Artışı" }, slug: "troubleshooting/windows-memory" },
+            { label: "Disk Usage from Temp Files", translations: { es: "Uso de disco por archivos temporales", fr: "Espace disque et fichiers temporaires", ko: "임시 파일 디스크 사용량", "zh-CN": "临时文件磁盘占用", "zh-TW": "暫存檔磁碟用量", ru: "Использование диска временными файлами", ja: "一時ファイルのディスク使用量", tr: "Geçici Dosya Disk Kullanımı" }, slug: "troubleshooting/disk-usage-temp-files" },
+            { label: "Codex Cannot Sign In or Load", translations: { es: "Codex no puede iniciar sesión ni cargar", fr: "Codex ne peut pas se connecter", ko: "Codex 로그인 불가", "zh-CN": "Codex 无法登录", "zh-TW": "Codex 無法登入", ru: "Codex не может войти", ja: "Codex にサインインできない", tr: "Codex Oturum Açamıyor" }, slug: "troubleshooting/codex-cannot-sign-in" },
+            { label: "Update Failed on Windows", translations: { es: "Fallo de actualización en Windows", fr: "Échec de la mise à jour sous Windows", ko: "Windows에서 업데이트 실패", "zh-CN": "Windows 上更新失败", "zh-TW": "Windows 上更新失敗", ru: "Сбой обновления в Windows", ja: "Windows で更新に失敗する", tr: "Windows'ta Güncelleme Başarısız" }, slug: "troubleshooting/update-failed" },
+            { label: "Spend Ledger Refused in a Synced Folder", translations: { es: "Registro de gastos rechazado en una carpeta sincronizada", fr: "Registre de dépenses refusé dans un dossier synchronisé", ko: "동기화 폴더에서 지출 원장 거부", "zh-CN": "同步文件夹中的支出账本被拒绝", "zh-TW": "同步資料夾中的支出帳本被拒絕", ru: "Отказ журнала расходов в синхронизируемой папке", ja: "同期フォルダーで支出台帳が拒否される", tr: "Eşitlenen Klasörde Harcama Defteri Reddi" }, slug: "troubleshooting/spend-ledger-synced-folder" },
           ],
         },
-        { label: "Contributing", translations: { fr: "Contribuer", ko: "기여하기", "zh-CN": "贡献", "zh-TW": "貢獻", ru: "Как внести вклад", ja: "コントリビュート", tr: "Katkıda Bulunma" }, slug: "contributing" },
+        { label: "Contributing", translations: { es: "Cómo contribuir", fr: "Contribuer", ko: "기여하기", "zh-CN": "贡献", "zh-TW": "貢獻", ru: "Как внести вклад", ja: "コントリビュート", tr: "Katkıda Bulunma" }, slug: "contributing" },
       ],
     }),
     // Runs after Starlight has written the site: refuses a build with a broken internal link.
diff --git a/docs-site/src/components/FrontierBoards.astro b/docs-site/src/components/FrontierBoards.astro
index 2cd29564cb6..8dbeaf5b7d2 100644
--- a/docs-site/src/components/FrontierBoards.astro
+++ b/docs-site/src/components/FrontierBoards.astro
@@ -10,7 +10,7 @@ import data from "../data/frontier-benchmarks.json";
 import { FRONTIER_STRINGS } from "../data/frontier-i18n";
 
 interface Props {
-  locale?: "en" | "fr" | "ko" | "zh-cn" | "zh-tw" | "ru" | "ja" | "tr";
+  locale?: "en" | "fr" | "ko" | "zh-cn" | "zh-tw" | "ru" | "ja" | "tr" | "es";
   /** Comma-separated board ids to render; omit for all boards. */
   boards?: string;
   /** Show the page-level subtitle (overview pages only). */
@@ -21,13 +21,16 @@ const { locale = "en", boards: boardsProp, intro = false } = Astro.props;
 const include = boardsProp ? new Set(boardsProp.split(",").map(s => s.trim()).filter(Boolean)) : null;
 const strings = FRONTIER_STRINGS[locale] as Record<string, string>;
 const fallback = FRONTIER_STRINGS.en as Record<string, string>;
+/** Resolve a benchmark label, using the canonical copy for unknown localized keys. */
 const t = (key: string): string => strings[key] ?? fallback[key] ?? key;
+/** Substitute named display placeholders without changing the underlying benchmark data. */
 const fill = (key: string, vars: Record<string, string>): string =>
   Object.entries(vars).reduce((acc, [k, v]) => acc.replace(`{${k}}`, v), t(key));
 
 // The PR i18n has no column-header key for "score" — keep a tiny local map.
-const SCORE_HEADER: Record<string, string> = { en: "Score", fr: "Score", ko: "점수", "zh-cn": "得分", "zh-tw": "得分", ru: "Балл", ja: "スコア", tr: "Puan" };
+const SCORE_HEADER: Record<string, string> = { es: "Puntuación", en: "Score", fr: "Score", ko: "점수", "zh-cn": "得分", "zh-tw": "得分", ru: "Балл", ja: "スコア", tr: "Puan" };
 /** Dataset tags are kebab-case; i18n keys are camelCase (cheap-subagent → cheapSubagent). */
+/** Map dataset kebab-case tags to the existing translation-key suffix. */
 const tagKey = (tag: string): string => tag.replace(/-([a-z])/g, (_, c) => c.toUpperCase());
 
 const boards = data.benchmarks.filter(board => !include || include.has(board.id)).map(board => {
@@ -61,8 +64,7 @@ const boards = data.benchmarks.filter(board => !include || include.has(board.id)
         <h3 id={`board-${board.id}`}>{t(`frontier.board.${board.id}.title`)}</h3>
         <p class="frontier-meta">
           {fill("frontier.updated", { date: board.updated })}
-          {" · "}
-          {fill("frontier.tasks", { count: String(board.taskCount) })}
+          {board.taskCount != null && <span> · {fill("frontier.tasks", { count: String(board.taskCount) })}</span>}
           {" · "}
           <a href={board.provenance.url}>{t("frontier.sourceLink")}</a>
           {board.provenance.license && <span class="frontier-license"> · {board.provenance.license}</span>}
@@ -76,7 +78,7 @@ const boards = data.benchmarks.filter(board => !include || include.has(board.id)
               <th>{t("frontier.col.model")}</th>
               <th>{t("frontier.col.effort")}</th>
               <th>{SCORE_HEADER[locale] ?? SCORE_HEADER.en}</th>
-              <th>{t("frontier.col.cost")}</th>
+              <th>{board.chart.xLabel}</th>
               {board.allMeasured && <th>{t("frontier.col.efficiency")}</th>}
               <th>{t("frontier.col.tags")}</th>
             </tr>
diff --git a/docs-site/src/components/Header.astro b/docs-site/src/components/Header.astro
index 7e86a7de5dc..32b7248152e 100644
--- a/docs-site/src/components/Header.astro
+++ b/docs-site/src/components/Header.astro
@@ -84,8 +84,47 @@ const fr = {
 	'GitHub, {count} stars': 'GitHub, {count} étoiles',
 } as const;
 
+const es: Record<keyof typeof fr, string> = {
+	"Auto": "Automático",
+	"Light": "Claro",
+	"Dark": "Oscuro",
+	"Theme": "Tema",
+	"Click to use the next theme": "Haz clic para cambiar al siguiente tema",
+	"Getting Started": "Primeros pasos",
+	"Installation": "Instalación",
+	"Quickstart": "Inicio rápido",
+	"How It Works": "Cómo funciona",
+	"Agent Quickstart": "Inicio rápido para agentes",
+	"Guides": "Guías",
+	"Providers": "Proveedores",
+	"Model Routing": "Enrutamiento de modelos",
+	"Combos": "Combos",
+	"Codex Integration": "Integración con Codex",
+	"Codex App Model Picker": "Selector de modelos de Codex App",
+	"Sidecars: Search & Vision": "Sidecars: búsqueda y visión",
+	"Image Bridge": "Puente de imágenes",
+	"Video Bridge": "Puente de video",
+	"Web Dashboard": "Dashboard web",
+	"Sub-agent Surface": "Interfaz de subagentes",
+	"Reference": "Referencia",
+	"Configuration": "Configuración",
+	"Adapters": "Adaptadores",
+	"Architecture": "Arquitectura",
+	"Proxy API Formats": "Formatos de API del proxy",
+	"Management API": "API de administración",
+	"Contributing": "Cómo contribuir",
+	"Dashboard": "Panel de telemetría",
+	"Explore guides": "Explorar las guías",
+	"Main": "Navegación principal",
+	"Select language": "Elegir idioma",
+	"Menu": "Menú",
+	"GitHub": "GitHub",
+	"GitHub, {count} stars": "GitHub, {count} estrellas",
+};
+
+/** Select navigation copy; typed dictionaries require complete French and Spanish keys. */
 const t = <K extends keyof typeof fr>(en: K, ko: string, zh: string, ru: string, ja: string, zhTW: string, tr: string): string =>
-	locale === 'fr' ? fr[en] : locale === 'ko' ? ko : locale === 'zh-cn' ? zh : locale === 'zh-tw' ? zhTW : locale === 'ru' ? ru : locale === 'ja' ? ja : locale === 'tr' ? tr : en;
+	locale === 'es' ? es[en] : locale === 'fr' ? fr[en] : locale === 'ko' ? ko : locale === 'zh-cn' ? zh : locale === 'zh-tw' ? zhTW : locale === 'ru' ? ru : locale === 'ja' ? ja : locale === 'tr' ? tr : en;
 
 const starCount = await getStarCount();
 const starLocale = locale ?? 'en';
@@ -97,9 +136,10 @@ const starLabel = t(
 const githubAccessibleName = starCount === null ? githubLabel
 	: starLabel.replace('{count}', starCount.toLocaleString(starLocale));
 
-type LanguageOption = { code: 'root' | 'fr' | 'ko' | 'zh-cn' | 'zh-tw' | 'ru' | 'ja' | 'tr'; label: string };
+type LanguageOption = { code: 'root' | 'fr' | 'ko' | 'zh-cn' | 'zh-tw' | 'ru' | 'ja' | 'tr' | 'es'; label: string };
 const languages: LanguageOption[] = [
 	{ code: 'root', label: 'English' },
+	{ code: 'es', label: 'Español' },
 	{ code: 'fr', label: 'Français' },
 	{ code: 'ko', label: '한국어' },
 	{ code: 'zh-cn', label: '简体中文' },
@@ -341,8 +381,21 @@ const contributing: NavLink = {
 				<span class="burger" aria-hidden="true"><span></span><span></span></span>
 			</button>
 			<div class="lp-menu-panel" id="lp-menu-panel">
+				<details class="lp-menu-group lp-menu-languages" style="--i:0">
+					<summary><span>{t('Select language', '언어 선택', '选择语言', 'Выбрать язык', '言語を選択', '選擇語言', 'Dil seçin')}</span></summary>
+					<div class="lp-menu-region"><ul>
+						{languages.map((language) => (
+							<li><a
+								href={languageHref(language.code)}
+								lang={language.code === 'root' ? 'en' : language.code}
+								hreflang={language.code === 'root' ? 'en' : language.code}
+								aria-current={language.code === (locale ?? 'root') ? 'true' : undefined}
+							>{language.label}</a></li>
+						))}
+					</ul></div>
+				</details>
 				{groups.map((group, i) => (
-					<details class="lp-menu-group" style={`--i:${i}`}>
+					<details class="lp-menu-group" style={`--i:${i + 1}`}>
 						<summary>
 							<span>{group.label}</span>
 							<svg viewBox="0 0 16 16" width="18" height="18" fill="none" aria-hidden="true"><path d="M3.5 6l4.5 4.5L12.5 6" stroke="currentColor" stroke-width="1.6" stroke-linecap="round" stroke-linejoin="round" /></svg>
@@ -407,6 +460,21 @@ const contributing: NavLink = {
 	}
 	:global(.sl-skip-link:focus) { min-height: 44px; }
 
+	/* Longer locale labels need room before the full search pill fits. */
+	@media (min-width: 50rem) and (max-width: 89.99rem) {
+		.header { gap: 0.5rem; }
+		.title-wrapper { flex-shrink: 0; }
+		.search-wrapper :global(button[data-open-modal]) {
+			width: 44px;
+			min-width: 44px;
+			min-height: 44px;
+			padding: 0;
+			justify-content: center;
+		}
+		.search-wrapper :global(button[data-open-modal] > span),
+		.search-wrapper :global(button[data-open-modal] > kbd) { display: none; }
+	}
+
 	.search-wrapper,
 	.github-link,
 	.right-group,
@@ -950,6 +1018,9 @@ const contributing: NavLink = {
 			translate 0.4s cubic-bezier(0.22, 1, 0.36, 1),
 			visibility 0s;
 	}
+	.lp-menu-languages ul { display: grid; grid-template-columns: repeat(2, 1fr); }
+	.lp-menu-languages a[aria-current='true'] { color: var(--sl-color-text-accent); font-weight: 600; }
+	@media (min-width: 50rem) { .lp-menu-languages { display: none; } }
 	.lp-menu-group,
 	.lp-menu-contrib {
 		border-bottom: 1px solid var(--sl-color-gray-5);
diff --git a/docs-site/src/components/Landing.astro b/docs-site/src/components/Landing.astro
index 060818b175b..d46efe94e6b 100644
--- a/docs-site/src/components/Landing.astro
+++ b/docs-site/src/components/Landing.astro
@@ -24,12 +24,14 @@ import SiteJsonLd from './SiteJsonLd.astro';
 import { GITHUB_URL, getStarCount, formatStarCount } from '../data/github-stars';
 
 interface Props {
-	locale?: 'fr' | 'ko' | 'zh-cn' | 'zh-tw' | 'ru' | 'ja' | 'tr';
+	locale?: 'fr' | 'ko' | 'zh-cn' | 'zh-tw' | 'ru' | 'ja' | 'tr' | 'es';
 }
 const { locale } = Astro.props;
 
 const base = import.meta.env.BASE_URL.replace(/\/?$/, '/');
 const prefix = locale ? `${base}${locale}/` : base;
+const signingPolicies = import.meta.glob('../content/docs/*/reference/code-signing.md');
+const signingPolicyPrefix = locale && `../content/docs/${locale}/reference/code-signing.md` in signingPolicies ? prefix : base;
 
 const fr = {
 	'Install': 'Installer',
@@ -63,6 +65,7 @@ const fr = {
 	'Project': 'Projet',
 	'Contributing': 'Contribuer',
 	'Run ': 'Faites tourner ',
+	'Codex and Claude': 'Codex et Claude',
 	' on the models you choose.': ' sur les modèles de votre choix.',
 	'opencodex is one local gateway for your AI coding tools and models. It serves Codex, Claude Code, Claude Desktop and Grok Build from one port and connects more tools through managed configs, translating each wire format to the provider you choose, with streaming, tool calls, reasoning and images where the model supports them. Zero client patches.': 'opencodex est une passerelle locale unique pour vos outils de code IA et vos modèles. Il sert Codex, Claude Code, Claude Desktop et Grok Build sur un même port et connecte d’autres outils via des configurations gérées, en traduisant chaque format de protocole vers le fournisseur de votre choix, avec la diffusion en continu, les appels d’outils, le raisonnement et les images lorsque le modèle les prend en charge. Aucune modification des clients.',
 	'Get Started': 'Commencer',
@@ -93,7 +96,7 @@ const fr = {
 	'Claude Code running a routed model through opencodex — gpt-5.6-luna-medium active in the status bar': 'Claude Code exécutant un modèle routé par opencodex, avec gpt-5.6-luna-medium actif dans la barre d’état',
 	'Search & vision sidecars': 'Services auxiliaires de recherche et de vision',
 	'Give non-OpenAI models real web search and image understanding through a gpt-5.6-luna sidecar.': 'Ajoutez aux modèles autres qu’OpenAI une véritable recherche web et la compréhension des images grâce à un service auxiliaire gpt-5.6-luna.',
-	'ocx init writes a provider into your Codex config and shares one model catalog with Codex CLI, TUI, App, and SDK. ocx stop restores native Codex cleanly.': 'ocx init ajoute un fournisseur à votre configuration Codex et partage un catalogue de modèles unique entre Codex CLI, TUI, App et SDK. ocx stop restaure proprement Codex dans son état natif.',
+	'ocx init writes a provider into your Codex config and shares one model catalog with Codex CLI, TUI, App, and SDK. On a standalone owner, ocx stop restores native Codex; linked clients and siblings retain their shared routing.': 'ocx init ajoute un fournisseur à votre configuration Codex et partage un catalogue de modèles unique entre Codex CLI, TUI, App et SDK. Sur une instance autonome propriétaire, ocx stop restaure Codex natif ; les clients liés et les instances sœurs conservent leur routage partagé.',
 	'Documentation map': 'Plan de la documentation',
 	'Explore the docs': 'Explorer la documentation',
 	'opencodex is an independent community project, not affiliated with or endorsed by OpenAI, Anthropic, or any other provider. Some providers may restrict accounts that route traffic through third-party proxies — review each provider’s Terms of Service before connecting.': 'opencodex est un projet communautaire indépendant, sans affiliation avec OpenAI, Anthropic ou tout autre fournisseur, et sans approbation de leur part. Certains fournisseurs peuvent restreindre les comptes qui acheminent leur trafic par des proxys tiers ; consultez les conditions d’utilisation de chaque fournisseur avant de vous connecter.',
@@ -120,8 +123,99 @@ const fr = {
 	'Star on GitHub, {count} stars': 'Mettre une étoile sur GitHub, {count} étoiles',
 } as const;
 
+const es: Record<keyof typeof fr, string> = {
+	"Install": "Instalar",
+	"Start the proxy": "Iniciar el proxy",
+	"Add a provider and connect Codex": "Añade un proveedor y conecta Codex",
+	"In another terminal: launch Claude Code through ocx": "En otra terminal: inicia Claude Code mediante ocx",
+	"See supported tools": "Ver herramientas compatibles",
+	"Codex now routes through ocx": "Codex ahora se conecta a través de ocx",
+	"Getting Started": "Primeros pasos",
+	"Installation": "Instalación",
+	"Quickstart": "Inicio rápido",
+	"How It Works": "Cómo funciona",
+	"Agent Quickstart": "Inicio rápido para agentes",
+	"Guides": "Guías",
+	"Providers": "Proveedores",
+	"Model Routing": "Enrutamiento de modelos",
+	"Combos": "Combos",
+	"Codex Integration": "Integración con Codex",
+	"Codex App Model Picker": "Selector de modelos de Codex App",
+	"Sidecars: Search & Vision": "Sidecars: búsqueda y visión",
+	"Image Bridge": "Puente de imágenes",
+	"Video Bridge": "Puente de video",
+	"Web Dashboard": "Dashboard web",
+	"Sub-agent Surface": "Interfaz de subagentes",
+	"Reference": "Referencia",
+	"Configuration": "Configuración",
+	"Adapters": "Adaptadores",
+	"Architecture": "Arquitectura",
+	"Proxy API Formats": "Formatos de API del proxy",
+	"Management API": "API de administración",
+	"Project": "Proyecto",
+	"Contributing": "Cómo contribuir",
+	"Run ": "Ejecuta ",
+	"Codex and Claude": "Codex y Claude",
+	" on the models you choose.": " con los modelos que elijas.",
+	"opencodex is one local gateway for your AI coding tools and models. It serves Codex, Claude Code, Claude Desktop and Grok Build from one port and connects more tools through managed configs, translating each wire format to the provider you choose, with streaming, tool calls, reasoning and images where the model supports them. Zero client patches.": "opencodex es una única pasarela local para tus herramientas de programación con IA y tus modelos. Conecta Codex, Claude Code, Claude Desktop y Grok Build por un mismo puerto, y otras herramientas mediante configuraciones administradas. Convierte cada protocolo para el proveedor que elijas, con streaming, llamadas a herramientas, razonamiento e imágenes cuando el modelo lo permite. No requiere parches en los clientes.",
+	"Get Started": "Comenzar",
+	"Supported providers": "Proveedores compatibles",
+	"40+ providers": "Más de 40 proveedores",
+	"The opencodex dashboard — live proxy status, routed providers, and available models": "Dashboard de opencodex: estado del proxy en tiempo real, proveedores enrutados y modelos disponibles",
+	"Install. Start. Connect your tool.": "Instala. Inicia. Conecta tu herramienta.",
+	"Install.": "Instala.",
+	"Start.": "Inicia.",
+	"Connect your tool.": "Conecta tu herramienta.",
+	"Full quickstart": "Inicio rápido completo",
+	"Watch Codex run on a routed model.": "Mira cómo Codex ejecuta un modelo enrutado.",
+	"Codex App running a task on a routed non-OpenAI model": "Codex App ejecuta una tarea con un modelo enrutado de otro proveedor distinto de OpenAI",
+	"One task, streamed end to end through opencodex.": "Una tarea, transmitida de extremo a extremo a través de opencodex.",
+	"One proxy, the whole surface.": "Un proxy para todas las funciones.",
+	"Any provider": "Cualquier proveedor",
+	"Five adapters cover Anthropic Messages, Google Gemini, Azure, the OpenAI Responses passthrough, and every OpenAI-compatible Chat Completions endpoint — 40+ built-in providers.": "Cinco adaptadores cubren Anthropic Messages, Google Gemini, Azure, el paso directo de OpenAI Responses y cualquier endpoint de Chat Completions compatible con OpenAI. Más de 40 proveedores integrados.",
+	"OAuth or API key": "OAuth o clave API",
+	"Log in with your xAI, Anthropic, or Kimi account — auto-refreshed — forward your ChatGPT login, or paste a key.": "Inicia sesión con tu cuenta de xAI, Anthropic o Kimi, con renovación automática; reenvía tu sesión de ChatGPT o pega una clave API.",
+	"ChatGPT account pool": "Grupo de cuentas ChatGPT",
+	"Existing threads keep their account; new sessions auto-route to the lowest-usage healthy one after quota refresh.": "Los hilos existentes conservan su cuenta. Tras actualizar las cuotas, las sesiones nuevas se asignan automáticamente a la cuenta disponible con menor uso.",
+	"Native in the model picker": "Nativo en el selector de modelos",
+	"Routed models show up in Codex App with reasoning effort levels, next to the native ones.": "Los modelos enrutados aparecen en la aplicación Codex con niveles de esfuerzo de razonamiento, junto a los nativos.",
+	"Codex App model picker with reasoning effort levels": "Selector de modelos de Codex App con niveles de esfuerzo de razonamiento",
+	"Sub-agents": "Subagentes",
+	"Pin up to five routed or native models for Codex spawn_agent, and switch the v1 / base / v2 surface globally.": "Fija hasta cinco modelos enrutados o nativos para spawn_agent de Codex y cambia globalmente entre las interfaces v1, base y v2.",
+	"ocx claude launches Claude Code against the same port — every routed model in the /model picker, auto-context up to 1M, roster sub-agents, and your claude.ai login stays active.": "ocx claude inicia Claude Code en el mismo puerto: todos los modelos enrutados aparecen en /model, con contexto automático de hasta 1M y subagentes del listado. Tu sesión de claude.ai permanece activa.",
+	"Claude Code running a routed model through opencodex — gpt-5.6-luna-medium active in the status bar": "Claude Code ejecutando un modelo enrutado a través de opencodex — gpt-5.6-luna-medium activo en la barra de estado",
+	"Search & vision sidecars": "Sidecars de búsqueda y visión",
+	"Give non-OpenAI models real web search and image understanding through a gpt-5.6-luna sidecar.": "Añade búsqueda web y comprensión de imágenes a los modelos de otros proveedores mediante un sidecar gpt-5.6-luna.",
+	"ocx init writes a provider into your Codex config and shares one model catalog with Codex CLI, TUI, App, and SDK. On a standalone owner, ocx stop restores native Codex; linked clients and siblings retain their shared routing.": "ocx init escribe un proveedor en tu configuración de Codex y comparte el catálogo con Codex CLI, TUI, App y SDK. En la instancia independiente propietaria, ocx stop restaura Codex nativo; los clientes enlazados y las instancias hermanas conservan su enrutamiento compartido.",
+	"Documentation map": "Mapa de la documentación",
+	"Explore the docs": "Explorar la documentación",
+	"opencodex is an independent community project, not affiliated with or endorsed by OpenAI, Anthropic, or any other provider. Some providers may restrict accounts that route traffic through third-party proxies — review each provider’s Terms of Service before connecting.": "opencodex es un proyecto comunitario independiente, sin afiliación ni respaldo de OpenAI, Anthropic u otros proveedores. Algunos proveedores pueden restringir las cuentas que enrutan tráfico a través de proxies de terceros. Revisa los términos de servicio de cada proveedor antes de conectarte.",
+	"Desktop beta": "Aplicación de escritorio beta",
+	"Other platforms": "Otras plataformas",
+	"Download": "Descargar",
+	"Download for macOS": "Descargar para macOS",
+	"Download for Windows": "Descargar para Windows",
+	"Download for Linux": "Descargar para Linux",
+	"Download OpenCodex": "Descargar OpenCodex",
+	"The desktop app bundles the proxy, the dashboard and a tray. Beta.": "La aplicación de escritorio incluye el proxy, el dashboard y una bandeja. Versión beta.",
+	"Universal · Apple Silicon and Intel · macOS 13+ · .dmg": "Universal · Apple Silicon e Intel · macOS 13+ · .dmg",
+	"Installer not code-signed yet": "El instalador aún no tiene firma de código",
+	".deb package": "Paquete .deb",
+	"Recommended for your system": "Recomendado para tu sistema",
+	"Prefer the terminal?": "¿Prefieres la terminal?",
+	"Installation guide": "Guía de instalación",
+	"All releases and checksums": "Todas las versiones y sumas de comprobación",
+	"Desktop app guide": "Guía de la aplicación de escritorio",
+	"Code signing policy": "Política de firma de código",
+	"Desktop App": "Aplicación de escritorio",
+	"Latest release": "La última versión",
+	"Star on GitHub": "Dar una estrella en GitHub",
+	"Star on GitHub, {count} stars": "Dar una estrella en GitHub, {count} estrellas",
+};
+
+/** Select landing copy while requiring Spanish and French to cover every source key. */
 const t = <K extends keyof typeof fr>(en: K, ko: string, zh: string, ru: string, ja: string, zhTW: string, tr: string): string =>
-	locale === 'fr' ? fr[en] : locale === 'ko' ? ko : locale === 'zh-cn' ? zh : locale === 'zh-tw' ? zhTW : locale === 'ru' ? ru : locale === 'ja' ? ja : locale === 'tr' ? tr : en;
+	locale === 'es' ? es[en] : locale === 'fr' ? fr[en] : locale === 'ko' ? ko : locale === 'zh-cn' ? zh : locale === 'zh-tw' ? zhTW : locale === 'ru' ? ru : locale === 'ja' ? ja : locale === 'tr' ? tr : en;
 
 const starCount = await getStarCount();
 const starLocale = locale || 'en';
@@ -263,7 +357,7 @@ const docsMap = [
 			    Codex and Claude Code. 4-face rotateX cylinder, fixed slot width via
 			    inline-grid stacking; reduced-motion collapses to a static pairing. */}
 			<h1 id="_top">
-				{t('Run ', '', '让 ', 'Запускайте ', '', '讓 ', '')}<span class="lp-drum" aria-label="Codex and Claude">
+				{t('Run ', '', '让 ', 'Запускайте ', '', '讓 ', '')}<span class="lp-drum" aria-label={t('Codex and Claude', 'Codex 및 Claude', 'Codex 和 Claude', 'Codex и Claude', 'Codex と Claude', 'Codex 和 Claude', 'Codex ve Claude')}>
 					<span class="lp-drum-spin" aria-hidden="true">
 						<span class="lp-drum-face lp-drum-codex">Codex</span>
 						<span class="lp-drum-face lp-drum-claude">Claude</span>
@@ -356,10 +450,10 @@ const docsMap = [
 			<a href={`${prefix}guides/desktop-app/`}>{t('Desktop app guide', '데스크톱 앱 가이드', '桌面应用指南', 'Руководство по десктопному приложению', 'デスクトップアプリガイド', '桌面應用程式指南', 'Masaüstü uygulaması kılavuzu')}</a>
 		</p>
 		<!-- SignPath Foundation's terms require this attribution, verbatim, and the code signing
-		     policy link on the download page; the policy page exists in English only. -->
+		     policy link on the download page; use a translation when that page exists. -->
 		<p class="lp-dl-foot">
 			<span>Free code signing provided by <a href="https://about.signpath.io/">SignPath.io</a>, certificate by <a href="https://signpath.org/">SignPath Foundation</a>.</span>
-			<a href={`${base}reference/code-signing/`}>{t('Code signing policy', '코드 서명 정책', '代码签名策略', 'Политика подписи кода', 'コード署名ポリシー', '程式碼簽署政策', 'Kod imzalama politikası')}</a>
+			<a href={`${signingPolicyPrefix}reference/code-signing/`}>{t('Code signing policy', '코드 서명 정책', '代码签名策略', 'Политика подписи кода', 'コード署名ポリシー', '程式碼簽署政策', 'Kod imzalama politikası')}</a>
 		</p>
 	</section>
 
@@ -433,7 +527,7 @@ const docsMap = [
 			</article>
 			<article class="lp-cell lp-cell-terminal">
 				<h3><svg class="lp-ico" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round" aria-hidden="true"><path d={icons.code} /></svg>{t('Quickstart', '빠른 시작', '快速开始', 'Быстрый старт', 'クイックスタート', '快速入門', 'Hızlı Başlangıç')}</h3>
-				<p>{t('ocx init writes a provider into your Codex config and shares one model catalog with Codex CLI, TUI, App, and SDK. ocx stop restores native Codex cleanly.', 'ocx init이 Codex 설정에 프로바이더를 추가하고, Codex CLI·TUI·App·SDK가 하나의 모델 카탈로그를 함께 씁니다. ocx stop을 실행하면 원래 Codex로 깔끔하게 돌아갑니다.', 'ocx init 将 provider 写入 Codex 配置，CLI、TUI、App 与 SDK 共享同一模型目录。ocx stop 可干净地恢复原生 Codex。', 'ocx init записывает провайдера в конфигурацию Codex, а Codex CLI, TUI, App и SDK используют общий каталог моделей. ocx stop чисто восстанавливает нативный Codex.', 'ocx init が Codex 設定にプロバイダーを書き込み、Codex CLI・TUI・App・SDK で 1 つのモデルカタログを共有します。ocx stop でネイティブの Codex にクリーンに戻せます。', 'ocx init 將供應商寫入 Codex 設定，CLI、TUI、App 與 SDK 共享同一模型目錄。ocx stop 可乾淨地恢復原生 Codex。', 'ocx init, Codex yapılandırmanıza bir sağlayıcı yazar; Codex CLI, TUI, App ve SDK aynı model kataloğunu paylaşır. ocx stop ile yerel Codex’e temiz bir şekilde geri dönebilirsiniz.')}</p>
+				<p>{t('ocx init writes a provider into your Codex config and shares one model catalog with Codex CLI, TUI, App, and SDK. On a standalone owner, ocx stop restores native Codex; linked clients and siblings retain their shared routing.', 'ocx init이 Codex 설정에 프로바이더를 추가하고, Codex CLI·TUI·App·SDK가 하나의 모델 카탈로그를 함께 씁니다. 독립 실행 소유 인스턴스에서는 ocx stop이 기본 Codex를 복원합니다. 연결된 클라이언트와 형제 인스턴스의 공유 라우팅은 유지됩니다.', 'ocx init 将 provider 写入 Codex 配置，CLI、TUI、App 与 SDK 共享同一模型目录。在独立所有者实例上，ocx stop 恢复原生 Codex；已连接客户端和兄弟实例保留共享路由。', 'ocx init записывает провайдера в конфигурацию Codex, а Codex CLI, TUI, App и SDK используют общий каталог моделей. В автономном экземпляре-владельце ocx stop восстанавливает нативный Codex; связанные клиенты и соседние экземпляры сохраняют общую маршрутизацию.', 'ocx init が Codex 設定にプロバイダーを書き込み、Codex CLI・TUI・App・SDK で 1 つのモデルカタログを共有します。独立した所有インスタンスでは ocx stop がネイティブ Codex を復元します。リンク済みクライアントと兄弟インスタンスの共有ルーティングは維持されます。', 'ocx init 將供應商寫入 Codex 設定，CLI、TUI、App 與 SDK 共享同一模型目錄。在獨立擁有者執行個體上，ocx stop 會還原原生 Codex；已連結用戶端和同層執行個體保留共用路由。', 'ocx init, Codex yapılandırmanıza bir sağlayıcı yazar; Codex CLI, TUI, App ve SDK aynı model kataloğunu paylaşır. Bağımsız sahip örnekte ocx stop yerel Codex’i geri yükler; bağlı istemciler ve kardeş örnekler ortak yönlendirmeyi korur.')}</p>
 				<div class="lp-terminal">
 					<div class="lp-terminal-bar"><span>zsh</span></div>
 					<pre>{quickstart.map((line) => (<code><span class="lp-prompt">$ </span>{line.cmd}<span class="lp-note">  # {line.note}</span>{'\n'}</code>))}</pre>
diff --git a/docs-site/src/components/SiteJsonLd.astro b/docs-site/src/components/SiteJsonLd.astro
index d84049e2f13..eb5274ae61a 100644
--- a/docs-site/src/components/SiteJsonLd.astro
+++ b/docs-site/src/components/SiteJsonLd.astro
@@ -11,17 +11,18 @@
 const SITE_URL = 'https://opencodex.me';
 
 interface Props {
-	locale?: 'fr' | 'ko' | 'zh-cn' | 'zh-tw' | 'ru' | 'ja' | 'tr';
+	locale?: 'fr' | 'ko' | 'zh-cn' | 'zh-tw' | 'ru' | 'ja' | 'tr' | 'es';
 }
 const { locale } = Astro.props;
 
 // Locale path segment (root/English has none) mapped to its BCP-47 tag.
-const langs = { fr: 'fr', ko: 'ko', 'zh-cn': 'zh-CN', 'zh-tw': 'zh-TW', ru: 'ru', ja: 'ja', tr: 'tr' } as const;
+const langs = { es: 'es', fr: 'fr', ko: 'ko', 'zh-cn': 'zh-CN', 'zh-tw': 'zh-TW', ru: 'ru', ja: 'ja', tr: 'tr' } as const;
 
 const homeUrl = locale ? `${SITE_URL}/${locale}/` : `${SITE_URL}/`;
 const inLanguage = locale ? langs[locale] : 'en';
 
 const descriptions = {
+	es: "Una única pasarela local para tus herramientas de programación con IA y tus modelos: usa los proveedores que elijas con Codex, Claude Code, Claude Desktop y Grok Build, y conecta más herramientas mediante configuraciones administradas.",
 	en: 'One local gateway for your AI coding tools and models: use the providers you choose with Codex, Claude Code, Claude Desktop and Grok Build, and connect more tools through managed configs.',
 	fr: 'Une passerelle locale unique pour vos outils de code IA et vos modèles : utilisez les fournisseurs de votre choix avec Codex, Claude Code, Claude Desktop et Grok Build, et connectez d’autres outils via des configurations gérées.',
 	ko: 'AI 코딩 도구와 모델을 잇는 하나의 로컬 게이트웨이: Codex, Claude Code, Claude Desktop, Grok Build에서 원하는 프로바이더를 쓰고, 관리형 설정으로 더 많은 도구를 연결하세요.',
diff --git a/docs-site/src/content/docs/benchmarks/index.mdx b/docs-site/src/content/docs/benchmarks/index.mdx
index 2fb191ea901..cfff5c98d55 100644
--- a/docs-site/src/content/docs/benchmarks/index.mdx
+++ b/docs-site/src/content/docs/benchmarks/index.mdx
@@ -3,10 +3,7 @@ title: Benchmarks
 description: Public coding-agent benchmark snapshots — capability vs cost per task, with per-board provenance.
 ---
 
-These are **static snapshots** of public leaderboards, refreshed manually — not live
-OpenCodex metering. Each board lists its source, capture date, and license note.
-Score-per-dollar rankings only appear on boards where every row carries a
-source-measured cost per task.
+These are **static snapshots** of public leaderboards, refreshed manually — not live OpenCodex metering. Each board lists its source, capture date, and license note. A score-per-dollar column and best-value badge appear only when every row has a source-measured cost per task. Rows keep the dataset's order; they are not ranked by score per dollar.
 
 Boards are grouped by task domain:
 
diff --git a/docs-site/src/content/docs/contributing/pr-quality.md b/docs-site/src/content/docs/contributing/pr-quality.md
index 2716c841228..c8ebe90c72d 100644
--- a/docs-site/src/content/docs/contributing/pr-quality.md
+++ b/docs-site/src/content/docs/contributing/pr-quality.md
@@ -32,7 +32,7 @@ on your behalf.
 
 ## Automated gates
 
-Three deterministic checks run before human review, and each failure message
+Deterministic checks run before human review, and each failure message
 tells you exactly what to change:
 
 - **PR quality (`enforce-target`).** Pull requests must target `dev` and carry
diff --git a/docs-site/src/content/docs/es/benchmarks/coding.mdx b/docs-site/src/content/docs/es/benchmarks/coding.mdx
new file mode 100644
index 00000000000..803a63079da
--- /dev/null
+++ b/docs-site/src/content/docs/es/benchmarks/coding.mdx
@@ -0,0 +1,8 @@
+---
+title: "Pruebas de programación"
+description: "Instantáneas de DeepSWE, AA Coding Agent, FrontierCode, FrontierSWE, Program Bench y SWE Marathon."
+---
+
+import FrontierBoards from "../../../../components/FrontierBoards.astro";
+
+<FrontierBoards locale="es" boards="deepswe,aa-coding-agent,frontiercode,frontierswe,program-bench,swe-marathon" />
diff --git a/docs-site/src/content/docs/es/benchmarks/frontend.mdx b/docs-site/src/content/docs/es/benchmarks/frontend.mdx
new file mode 100644
index 00000000000..08a930ae54a
--- /dev/null
+++ b/docs-site/src/content/docs/es/benchmarks/frontend.mdx
@@ -0,0 +1,8 @@
+---
+title: "Pruebas de frontend"
+description: "Resultados públicos de Frontend Code Arena."
+---
+
+import FrontierBoards from "../../../../components/FrontierBoards.astro";
+
+<FrontierBoards locale="es" boards="frontend-code-arena" />
diff --git a/docs-site/src/content/docs/es/benchmarks/index.mdx b/docs-site/src/content/docs/es/benchmarks/index.mdx
new file mode 100644
index 00000000000..11dce9ff2dc
--- /dev/null
+++ b/docs-site/src/content/docs/es/benchmarks/index.mdx
@@ -0,0 +1,14 @@
+---
+title: "Pruebas comparativas"
+description: "Instantáneas públicas de rendimiento de agentes, con fuentes y costos medidos por tarea cuando están disponibles."
+---
+
+Estas tablas son **instantáneas estáticas de clasificaciones públicas, actualizadas manualmente**. No son mediciones en vivo de OpenCodex. Cada panel indica la fuente, la fecha de captura y la licencia. La columna de puntuación por dólar y la insignia de mejor relación entre puntuación y coste aparecen solo cuando todas las filas tienen un coste medido por tarea. Las filas conservan el orden de los datos; no se clasifican por puntuación por dólar.
+
+Los paneles se agrupan por tarea:
+
+- [Programación](./coding/) — DeepSWE, AA Coding Agent, FrontierCode, FrontierSWE, Program Bench, SWE Marathon
+- [Frontend](./frontend/) — Frontend Code Arena
+- [Terminal](./terminal/) — Terminal Bench 2.1
+- [Seguridad](./security/) — Cybench
+- [Inteligencia](./intelligence/) — AA Intelligence Index
diff --git a/docs-site/src/content/docs/es/benchmarks/intelligence.mdx b/docs-site/src/content/docs/es/benchmarks/intelligence.mdx
new file mode 100644
index 00000000000..74d5458c3f4
--- /dev/null
+++ b/docs-site/src/content/docs/es/benchmarks/intelligence.mdx
@@ -0,0 +1,8 @@
+---
+title: "Pruebas de inteligencia"
+description: "Resultados públicos de AA Intelligence Index."
+---
+
+import FrontierBoards from "../../../../components/FrontierBoards.astro";
+
+<FrontierBoards locale="es" boards="aa-intelligence-index" />
diff --git a/docs-site/src/content/docs/es/benchmarks/security.mdx b/docs-site/src/content/docs/es/benchmarks/security.mdx
new file mode 100644
index 00000000000..a653daacb14
--- /dev/null
+++ b/docs-site/src/content/docs/es/benchmarks/security.mdx
@@ -0,0 +1,8 @@
+---
+title: "Pruebas de seguridad"
+description: "Resultados públicos de Cybench."
+---
+
+import FrontierBoards from "../../../../components/FrontierBoards.astro";
+
+<FrontierBoards locale="es" boards="cybench" />
diff --git a/docs-site/src/content/docs/es/benchmarks/terminal.mdx b/docs-site/src/content/docs/es/benchmarks/terminal.mdx
new file mode 100644
index 00000000000..f9cd7911fd4
--- /dev/null
+++ b/docs-site/src/content/docs/es/benchmarks/terminal.mdx
@@ -0,0 +1,8 @@
+---
+title: "Pruebas de terminal"
+description: "Resultados públicos de Terminal Bench 2.1."
+---
+
+import FrontierBoards from "../../../../components/FrontierBoards.astro";
+
+<FrontierBoards locale="es" boards="terminal-bench-2.1" />
diff --git a/docs-site/src/content/docs/es/contributing.md b/docs-site/src/content/docs/es/contributing.md
new file mode 100644
index 00000000000..40a868d6bcd
--- /dev/null
+++ b/docs-site/src/content/docs/es/contributing.md
@@ -0,0 +1,187 @@
+---
+title: "Cómo contribuir"
+description: "Desarrolla opencodex: entorno, estructura, convenciones y pasos para añadir proveedores o adaptadores."
+---
+
+<a id="setup"></a>
+
+## Preparar el entorno
+
+Para desarrollar desde el código fuente necesitas la CLI `bun` en `PATH`. El paquete npm publicado incluye su propio entorno de ejecución Bun; los scripts del paquete pueden usar esa dependencia incluida.
+
+```bash
+git clone https://github.com/lidge-jun/opencodex.git
+cd opencodex
+bun install
+bun run setup:hooks  # retire the managed pre-push and post-merge hooks
+bun run dev:proxy    # proxy API in dev mode
+bun run dev:gui      # dashboard dev server (another terminal)
+bun run typecheck    # bun check --no-script --noEmit
+bun run test        # full suite (default)
+```
+
+`bun run setup:hooks` elimina los hooks administrados y retirados `pre-push` y `post-merge` si no se han modificado; conserva los personalizados. Ya no se exige un hook de pre-push. `bun run prepush` sigue disponible como comprobación manual opcional.
+
+`bun run dev` es un alias de `bun run dev:proxy`. El servidor de desarrollo del dashboard se inicia con `bun run dev:gui`. El dashboard empaquetado que sirve `GET /` se genera con `bun run build:gui` en `gui/dist`.
+
+El antiguo hook `post-merge` reconstruía `gui/dist` tras cada merge. Ahora, si un merge cambia `gui/`, debes ejecutar `bun run build:gui` para actualizar el dashboard empaquetado. El servidor de desarrollo se reconstruye bajo demanda y no necesita ese paso.
+
+<a id="build-and-test-commands"></a>
+
+## Comandos de compilación y pruebas
+
+El paquete raíz usa TypeScript nativo de Bun, sin una compilación separada del servidor. Usa los scripts del repositorio para las comprobaciones locales:
+
+```bash
+bun run typecheck                 # strict Bun-native type check
+bun run typecheck:tsc             # reference check with the installed TypeScript compiler
+bun run test:changed              # import-graph tests against the resolved dev merge base
+bun run test                      # full suite (default)
+bun test tests/routing/router.test.ts     # focused test file
+bun run build:gui                 # Vite GUI build + package preparation
+bun run privacy:scan              # credential/privacy scan used by CI
+bun run prepare:package           # refresh package launchers/assets
+```
+
+`typecheck` usa el comprobador nativo de Bun con el `tsconfig.json` raíz, conservando su alcance en `src/` y las opciones estrictas del compilador sin emitir archivos. `--no-script` mantiene la ejecución en el comprobador de tipos aunque más adelante se añada un script de paquete llamado `check`. La dependencia Bun instalada proporciona el comprobador; `typecheck:tsc` conserva el compilador de TypeScript para comparaciones y como alternativa. CI y las comprobaciones previas a una versión siguen invocando `tsc` directamente, y la GUI mantiene su propia comprobación de tipos durante la compilación.
+El hook `prepublishOnly` también usa `typecheck:tsc`, entre la auditoría y la compilación de la GUI; un fallo de auditoría o del compilador detiene los pasos restantes.
+
+La suite usa Bun 1.4.4, declarado en `testRunnerBun` de `package.json`; el entorno de ejecución distribuido es 1.4.4. `scripts/test.ts` busca Bun 1.4.4 en PATH o `~/.bun/bin`, o utiliza `OCX_TEST_RUNNER_BUN`. Si falta esa versión, instálala localmente: el selector no la descarga.
+
+El ejecutor de pruebas y el entorno de ejecución distribuido se comprueban por separado aunque usen la misma versión de Bun. Una promoción requiere una ejecución multiplataforma completa con `lane=all`, exitosa para el commit candidato exacto.
+
+Ejecuta `bun run test` por defecto. Si la suite completa resulta desproporcionadamente costosa por el tamaño de la tarea, los recursos disponibles o la actividad de otros árboles de trabajo, ejecuta al menos las regresiones que prueben el comportamiento modificado, por ejemplo `bun test tests/<domain>/<name>.test.ts`. Explica el motivo, los comandos exactos, sus resultados y la cobertura pendiente. `bun run test:changed` complementa esa cobertura, pero no detecta todas las dependencias indirectas. Depender solo de CI o saltarse las pruebas locales no constituye una exención general. Antes del merge, los checks requeridos deben pasar para el commit actual del PR.
+
+`test:changed` usa la primera referencia de comparación disponible: `upstream/dev`, `origin/dev` o la rama local `dev`. Informa de esa referencia y del commit exacto obtenido con `git merge-base HEAD <ref>`, y pasa su SHA a Bun.
+
+Si se agota el plazo de una ejecución de pruebas, el runner muestra stdout y stderr ya capturados y termina con código 124. Tras finalizar un proceso, permite un segundo para vaciar sus tuberías, evitando que un descendiente las mantenga abiertas indefinidamente. La captura incompleta se informa y no cuenta como éxito, aunque el hijo directo haya terminado con código 0.
+
+Las pruebas de Bun se organizan por dominios que reflejan `src/`: `tests/server/`, `tests/providers/`, `tests/adapters/openai/`, `tests/cli/`, etc. El mapa es `scripts/test-layout/layout.json` y lo comprueba `tests/test-layout.test.ts`. Cada prueba nueva debe ir en su dominio y registrarse en el mapa; la prueba de herramientas indica qué entrada falta. `tests/helpers/` contiene fixtures compartidos y `tests/helpers/repo-root.ts` permite acceder a archivos del repositorio. `tests/e2e-style/` reúne escenarios más amplios de paridad nativa. Añade las regresiones junto a las pruebas del subsistema modificado; `bun test tests/<domain>` ejecuta un subsistema.
+
+Este sitio vive en `docs-site/` y usa Astro + Starlight:
+
+```bash
+cd docs-site && bun install && bun dev
+```
+
+<a id="docs-publishing"></a>
+
+## Publicación de documentación
+
+El sitio se publica en GitHub Pages, <https://opencodex.me/>. Un mantenedor ejecuta manualmente `.github/workflows/deploy-docs.yml` desde `dev`: compila la última versión estable publicada, o una etiqueta estable publicada explícita, en su commit resuelto. Es independiente de la versión npm. Antes de subir cambios:
+
+```bash
+cd docs-site
+bun install --frozen-lockfile
+bun run build
+```
+
+<a id="ci-and-releases"></a>
+
+## CI y versiones
+
+GitHub Actions mantiene comprobaciones acotadas:
+
+- **Cross-platform CI** (`.github/workflows/ci.yml`): comprobaciones Linux del alcance del PR. La matriz completa Linux/macOS/Windows se despacha manualmente sobre `dev` con `lane=all`, una vez por lote de integraciones, no por PR. Un PR verde no es evidencia multiplataforma para una versión.
+- **Release** (`.github/workflows/release.yml`): flujo manual de `dev` que elige una fuente exacta con evidencia de la matriz completa, fija la versión en los checkouts de compilación y consulta npm/GitHub antes de publicar. La publicación sigue desactivada hasta terminar las verificaciones de migración. Una ejecución interrumpida se recupera con reanudación atestiguada por el operador, sin volver a publicar una versión npm. Consulta [`MAINTAINERS.md`](https://github.com/lidge-jun/opencodex/blob/dev/MAINTAINERS.md).
+- **Stale needs-info** (`.github/workflows/stale-needs-info.yml`): cada día, avisa tras 14 días sin actividad en issues `needs-info`; siete días después las cierra. Cualquier actualización quita el aviso. Quita `needs-info` para trabajo de largo plazo, por ejemplo `roadmap`.
+- **Issue quality** (`.github/workflows/enforce-issue-quality.yml`): valida plantillas y etiquetas de tipo `bug`, `enhancement`, `provider-compatibility`, `documentation`, y áreas independientes `provider`, `account-pool`, `catalog`, `gui`, `cli`, `proxy`, `platform`, `streaming`, `tools`, `install`, `service`. El desplegable Area prevalece sobre crear etiquetas por proveedor. Documentation no duplica área. Los mantenedores pueden aplicar `backfill_open_areas` por workflow_dispatch cuando el flujo llegue a la rama predeterminada.
+
+El procedimiento antiguo de incremento de versión y promoción no es la ruta actual de publicación ni una alternativa para evitar sus condiciones pendientes.
+
+<a id="branches"></a>
+
+## Ramas
+
+- `dev`: única rama de integración y rama predeterminada; dirige aquí tu PR.
+- `main` y `preview` se eliminaron tras adoptar una única rama. Su historial publicado sigue en las etiquetas; no son destinos de integración ni promoción.
+
+La línea Go `dev2-go` y su política de mantenimiento paralelo están retiradas. Su historial es de solo lectura en [lidge-jun/opencodex-go-archive](https://github.com/lidge-jun/opencodex-go-archive). Bun nativo en `dev` es la única línea de ejecución.
+
+Se aceptan PR que actualizan ramas antiguas mediante rebase; identifica los commits de origen en la descripción.
+
+<a id="pull-requests"></a>
+
+## Pull requests
+
+- Dirige el PR a **`dev`**. `enforce-target` rechaza otras bases, salvo hijos apilados sobre la rama de otro PR abierto.
+- Parte de `dev` actual. Si te retrasas demasiado, se desmarca la afirmación de base reciente de la lista de preparación.
+- Completa la plantilla con `Summary`, `Verification` y `Checklist`: explica el cambio, motivo, plan y resultados. Texto vacío, marcadores de posición o `\n` escapados en vez de saltos reales fallan.
+- Si cambias `gui/`, incluye una captura en la descripción. Arrástrala al editor; no la añadas a la rama del PR, porque llegaría a `dev` con squash. Por CLI, usa `pr-assets` y un enlace fijado a su SHA.
+- La automatización privilegiada usa **`pull_request_target`** y solo cambia cuando llega a la rama predeterminada, como explica #631. Cross-platform CI usa **`pull_request`**; los cambios surten efecto en la rama base del PR.
+
+<a id="project-maintainers"></a>
+
+## Mantenedores
+
+Los responsables, sus funciones y la política de revisión y merge se documentan en [`MAINTAINERS.md`](https://github.com/lidge-jun/opencodex/blob/dev/MAINTAINERS.md). `.github/CODEOWNERS` declara la responsabilidad de revisión de las rutas del repositorio, incluidas las sensibles para la seguridad.
+
+Los PR de contribuyentes normalmente necesitan aprobación de un mantenedor. Un mantenedor actual con acceso `maintain` o `admin` puede integrar explícitamente un PR en `dev`, incluido uno propio, sin segunda aprobación. Debe registrar la decisión y la validación del commit exacto. Siguen vigentes CI, la revisión de seguridad y las objeciones pendientes de otros mantenedores. Esta excepción no cambia las reglas de `main`/`preview` ni permite pushes directos, force-pushes o eliminación.
+
+<a id="conventions"></a>
+
+## Convenciones
+
+- **Módulos ES** (`import`/`export`), TypeScript y modo `strict`. Mantén en verde `bun run typecheck`.
+- **Máximo aproximado de 500 líneas por archivo**: divide por responsabilidad, como los sidecars `web-search/` y `vision/`, con módulos pequeños tras un `index.ts`.
+- **Errores asíncronos en los límites**: un sidecar no debe propagar una excepción a la ruta de la solicitud; debe degradarse mediante un marcador controlado.
+- **Fuente de verdad de estructura**: los invariantes mantenidos viven en `structure/`, los flujos públicos en `docs-site/` y las notas de planificación e investigación en `devlog/`.
+- **Conserva las exportaciones**: otros módulos pueden depender de ellas.
+
+<a id="adding-a-provider-to-the-catalog"></a>
+
+## Añadir un proveedor al catálogo
+
+Los selectores y valores iniciales de proveedores se derivan del registro canónico (`src/providers/registry/entries-extended.ts`):
+
+```ts
+{
+  id: "my-provider",
+  label: "My Provider",
+  baseUrl: "https://api.example.com/v1",
+  adapter: "openai-chat",
+  authKind: "key",
+  dashboardUrl: "https://example.com/keys",
+  models: ["model-a", "model-b"],
+  defaultModel: "model-a",
+  noVisionModels: ["model-a"],   // text-only models → vision sidecar describes images
+},
+```
+
+`src/providers/derive.ts` utiliza esa entrada en `ocx init`, `ocx provider`, los preajustes del dashboard, el inicio con clave API y la configuración inicial OAuth. `enrichProviderFromCatalog()` copia metadatos y clasificaciones de capacidades a la configuración guardada. La implementación del protocolo OAuth sigue en `src/oauth/`: los metadatos del registro por sí solos no implementan un flujo OAuth.
+
+<a id="evidence-required-for-a-canonical-preset"></a>
+
+### Evidencia para un preajuste canónico
+
+El registro determina a qué destino se envía la clave API del usuario. Un preajuste exige evidencia de fuentes primarias, además de código funcional. La descripción del PR que añada o promueva un proveedor debe incluir:
+
+- **Endpoints compatibles con OpenAI documentados por el proveedor**: la referencia de chat y, con `liveModels: true`, la del descubrimiento autenticado de modelos, normalmente `GET /v1/models`. Una prueba con fixtures valida nuestro código, pero no sustituye la evidencia del contrato del proveedor.
+- **Términos de servicio y entidad legal operadora**: una página legal vacía no identifica quién opera el endpoint ni cómo trata el tráfico del usuario.
+- **Autorización de reventa o enrutamiento para agregadores**: una pasarela que vende acceso a Claude, GPT, Gemini u otros modelos debe demostrar su autorización. Un preajuste integrado se presenta como una ruta mantenida.
+- **Responsable de mantenimiento identificado**: quién actualiza el preajuste ante cambios de URL, autenticación o catálogo, y cómo se informan las incidencias.
+- **Fecha de verificación citable**: registra la fuente primaria y la fecha comprobada, como hace `lastVerified` en `src/providers/free-directory.ts`. No atribuyas una verificación que no se realizó.
+
+Puedes proponer tu propio servicio; varios preajustes surgieron así. Declara la afiliación en la descripción para que los revisores la valoren. La afiliación no justifica un rechazo ni reduce la evidencia exigida.
+
+Si la evidencia está incompleta, añade una referencia en `src/providers/free-directory.ts`, en lugar de promoverla al registro canónico. Las filas indican su grado de `verification` (`official`, `primary`, `unverified`) y son referencias inertes: el usuario puede configurar el servicio mediante el flujo personalizado compatible con OpenAI, sin que opencodex lo presente como proveedor mantenido o recomendado. Promueve la fila solo cuando exista toda la evidencia anterior.
+
+<a id="adding-an-adapter"></a>
+
+## Añadir un adaptador
+
+Implementa `ProviderAdapter` en `src/adapters/`, siguiendo [Adaptadores](/es/reference/adapters/), registra su fábrica en `src/adapters/registry.ts` y convierte la salida a eventos internos `AdapterEvent`. `src/server/adapter-resolve.ts` elige el protocolo efectivo antes de delegar al registro. Reutiliza `image.ts` para imágenes y sigue `openai-chat.ts` para streaming y llamadas a herramientas normales. Usa `fetchResponse` solo si el adaptador controla los reintentos del transporte, o `runTurn` para un transporte bidireccional como Cursor. Añade pruebas enfocadas en `tests/` y exporta la fábrica desde `src/index.ts` si forma parte de la API pública del paquete.
+
+<a id="adding-a-compatibility-claim"></a>
+
+### Declarar compatibilidad
+
+Las declaraciones de compatibilidad viven en `src/compatibility/` y son más específicas que un adaptador: identifican el proveedor, la URL base normalizada, la autenticación, los protocolos de entrada y salida y los modelos cuyo comportamiento se probó. No extiendas una declaración a otros proveedores o destinos solo porque compartan adaptador o formato.
+
+Usa una de las disposiciones versionadas: `passthrough`, `translated`, `degraded` o `unsupported`. Cada declaración distinta de paso directo debe explicar su limitación. Si se basa en fixtures, cita los identificadores exactos de las aserciones que la prueban. Añade el vector de solicitud sin secretos en `tests/fixtures/compatibility/` y ejecútalo contra el adaptador de producción en una prueba enfocada. Una declaración `passthrough` solo puede citar aserciones `equals` cuyo valor esperado sea el valor original del cliente, en la misma ubicación y con un selector vinculado a esa capacidad en la prueba del manifiesto. Un campo eliminado, reescrito o ajeno a esa capacidad no demuestra ausencia de pérdidas. Separa aspectos relacionados si una ruta puede conservar uno y perder otro, como una herramienta personalizada y su gramática. Los manifiestos son datos pasivos: el router, el controlador Responses y el arranque del servidor no deben importar su catálogo ni activar Compatibility Lab.
+
+<a id="verify-before-you-claim-done"></a>
+
+## Verificar antes de dar el trabajo por terminado
+
+Sigue la política de pruebas anterior. Ejecuta `bun run typecheck` para cambios de tipos y los checks exigidos por la superficie afectada. Informa de comandos, resultados y cobertura pendiente; afirma únicamente las validaciones completadas.
diff --git a/docs-site/src/content/docs/es/contributing/pr-quality.md b/docs-site/src/content/docs/es/contributing/pr-quality.md
new file mode 100644
index 00000000000..9c20b775c8a
--- /dev/null
+++ b/docs-site/src/content/docs/es/contributing/pr-quality.md
@@ -0,0 +1,62 @@
+---
+title: "Requisitos de calidad de los pull requests"
+description: "Preparación para revisión, responsabilidad del contribuidor, permisos y política de cierre de los PR de OpenCodex."
+---
+
+<a id="you-do-not-need-permission-to-fix-something"></a>
+
+## No necesitas permiso para corregir un problema
+
+Los PR no planificados que corrigen un problema que hayas encontrado son bienvenidos. Varias mejoras del proyecto llegaron así: un modelo enrutado bloqueado tras llamar herramientas, un proveedor que recibía parámetros de modelo incorrectos o imágenes que se convertían en texto dentro de los resultados de herramientas. Ninguna empezó con una conversación de planificación; exigirla habría impedido esas aportaciones.
+
+Abrir primero una issue ayuda en trabajos grandes o de diseño, porque acordar el enfoque evita construir algo equivocado. Es una recomendación, no un requisito de admisión.
+
+<a id="what-a-ready-pull-request-claims"></a>
+
+## Qué afirmas al marcar un PR como listo
+
+Marcar un PR como listo para revisión significa que el cambio está completo, se comprende y se ha probado. Abrirlo no transfiere la responsabilidad de la rama a los mantenedores.
+
+Debes entender cada línea modificada, indicar los comandos exactos y sus resultados para respaldar las afirmaciones de validación, añadir pruebas de regresión específicas para cambios de comportamiento y estar disponible para resolver los comentarios de CI y de revisión. Los mantenedores identifican problemas; no se espera que reparen las ramas de los contribuidores, escriban las pruebas faltantes o conviertan los hallazgos automáticos en parches por ti.
+
+Decir «probado» o «CI pasa» sin comandos ni resultados concretos no es evidencia.
+
+<a id="automated-gates"></a>
+
+## Comprobaciones automáticas
+
+Antes de la revisión humana se ejecutan controles deterministas; cada mensaje de error indica qué corregir:
+
+- **Calidad del PR (`enforce-target`).** El destino debe ser `dev` y la descripción debe explicar el cambio mediante **Summary** y **Test plan**, o contenido equivalente. Si se modifican archivos de `gui/`, o GitHub devuelve una lista incompleta para un cambio grande, la descripción debe incluir una captura de la interfaz. El control mantiene el PR en borrador y comenta hasta que exista la captura. Las listas incompletas se tratan como cambios de GUI por precaución. Un mantenedor puede eximir una modificación de `gui/` o un falso positivo añadiendo `gui-screenshot-waived`; añadir o quitar esa etiqueta vuelve a evaluar el control de inmediato. Los comentarios antiguos de mantenedores, como «no gui changes», siguen reconociéndose por compatibilidad en el siguiente evento del PR, pero el comentario por sí solo ya no activa el control privilegiado. Un contribuidor no puede concederse esa exención.
+  Los PR de contribuidores sin permiso de escritura se abren en borrador y permanecen así hasta completar las cuatro casillas de preparación: validación local requerida superada con el alcance documentado, rama actualizada con `dev`, hallazgos correctos de Codex y CodeRabbit resueltos y confirmación de que el PR está listo. Al completar todas, el control lo marca como listo y notifica a los mantenedores de `MAINTAINERS.md`, salvo al autor. El estado y las acciones necesarias aparecen en un único comentario del bot que se actualiza en cada ejecución. La confirmación corresponde al commit exacto de la rama: un nuevo push devuelve el PR a borrador, restablece las casillas y la notificación y pide volver a validar ese código. Cambiar el destino a `dev` borra el aviso de rama incorrecta; el PR permanece en borrador hasta completar las casillas.
+  Antes de aceptar la confirmación, el control comprueba lo verificable: la rama debe incluir el último commit de `dev` o estar como máximo 10 commits por detrás; además, deben estar resueltos los hilos de Codex y CodeRabbit creados por bots de revisión en el commit actual. Los hilos de otros autores no bloquean. La casilla local sigue la [política de alcance de pruebas](/es/contributing/#build-and-test-commands): ejecutar la suite completa de forma predeterminada o, si resulta demasiado costosa, ejecutar las regresiones específicas y documentar la excepción. Esa casilla es una declaración del autor: los contribuidores de forks no pueden iniciar la CI del repositorio y necesitan a un mantenedor. El control no puede verificar esa declaración; un nuevo push igualmente restablece todas las casillas. Los hallazgos de CodeRabbit fuera del diff que solo aparecen en el cuerpo de la revisión actual se suman al recuento pendiente mientras quede abierto un hilo del bot; resolver todos sus hilos libera esa casilla. Una afirmación refutada desmarca la casilla correspondiente y mantiene el borrador. Con la lista completa y los controles en verde, se añade `review-ready` como indicador visible.
+  Editar el comentario de estado de CodeRabbit no activa el control. Un estado de commit `CodeRabbit` correcto lo activa mediante el evento `status` de la rama predeterminada de confianza. El control asocia el SHA con un único PR abierto cuya rama siga apuntando a él; después vuelve a consultar los hilos y los cuerpos de revisión antes de cambiar las casillas, las etiquetas, el comentario o el estado de borrador. Se ignoran las asociaciones ambiguas o antiguas y nunca se ejecuta código de la rama del PR con el token de escritura del control.
+- **Higiene.** Los cambios de comportamiento necesitan una prueba. Añadir supresiones de lint o tipos, pruebas exclusivas u omitidas, bloques catch vacíos, cambios manuales a archivos generados o un lockfile modificado sin su manifiesto requiere una etiqueta de aprobación explícita. Un cambio de comentarios en código fuente no altera el comportamiento ni requiere una prueba.
+- **CI multiplataforma.** Los PR ejecutan comprobaciones Linux acotadas y los cambios de documentación reciben una comprobación de compilación acotada. La cobertura completa de Linux, macOS y Windows es un despacho manual `lane=all` sobre `dev` después de un lote de integraciones; un PR verde no es evidencia de una versión para todas las plataformas. La comprobación agregada `ci` se crea para cada PR; la detección de rutas decide qué trabajos costosos hacen falta, también en PR hijos cuya base sea la rama de otro PR abierto. Nunca se añaden ejecuciones por push a `dev` ni trabajos de plataforma macOS o Windows por PR.
+- **Etiqueta de tipo.** La comprobación `label` deriva `bug`, `enhancement`, `documentation` o `chore` del título. Si no reconoce el prefijo (por ejemplo, `stack 3/5: …`), usa los commits. Los de la familia `chore` (`test:`, `ci:`, `refactor:`) no prevalecen sobre `fix:` o `feat:`. Si el PR mezcla tipos, se deja sin etiqueta en vez de adivinar; nunca se sobrescribe una etiqueta puesta por una persona.
+
+CodeRabbit revisa los PR y sus hallazgos son recomendaciones. Corrige los válidos y explica por qué descartas los incorrectos. Sus hallazgos, por sí solos, no bloquean la integración.
+
+<a id="when-a-workflow-change-takes-effect"></a>
+
+### Cuándo entra en vigor un cambio de automatización
+
+`enforce-target` y `label` usan la automatización de confianza de la rama predeterminada. El control del PR se ejecuta en `pull_request_target` y en los eventos `status` de CodeRabbit, ambos cargados desde la rama predeterminada del repositorio; por tanto, el comportamiento con permiso de escritura solo cambia cuando la revisión del control llega a esa rama. El flujo de trabajo de CI multiplataforma se ejecuta en `pull_request` y entra en vigor en cuanto está en la rama de destino.
+
+<a id="sponsored-surfaces"></a>
+
+## Áreas que necesitan el respaldo de un mantenedor
+
+Los cambios de autenticación, credenciales, flujos de GitHub Actions, automatización de versiones e instalación de dependencias requieren que un mantenedor los respalde (`maintainer-sponsored`) antes de integrarlos. Una integración defectuosa en esas áreas es costosa y difícil de revertir; por eso tienen ese requisito específico. Las demás áreas están abiertas a contribuciones.
+
+<a id="when-a-pull-request-is-closed"></a>
+
+## Cuándo se cierra un PR
+
+Un PR estancado con comentarios de revisión pendientes puede cerrarse, indicando claramente el motivo. El cierre no es un juicio sobre el contribuidor: puedes reabrirlo cuando resuelvas el motivo o sustituirlo por otro limpio. Pide una explicación si el motivo no está claro.
+
+<a id="updating-an-older-readiness-checklist"></a>
+
+## Actualizar una lista de preparación antigua
+
+Si el control detecta la redacción retirada de CI local, conserva tu descripción y pide actualizar la primera casilla. Usa la redacción del aviso del bot, desmarca las cuatro casillas y guarda. Espera a que el bot reconozca la lista sin marcar, valida el commit mostrado y después vuelve a marcar las cuatro y guarda. Cambiar solo el texto dejando las casillas marcadas no cuenta como una declaración nueva. Un push o un cambio de destino invalida ese punto de control. El control sigue en rojo y el PR en borrador hasta completar la secuencia y las verificaciones habituales. Si guardas en el mismo instante que el punto de control, vuelve a editar el cuerpo y guárdalo más tarde; editar solo el título no cuenta.
diff --git a/docs-site/src/content/docs/es/dashboard.mdx b/docs-site/src/content/docs/es/dashboard.mdx
new file mode 100644
index 00000000000..261cbd4d7a3
--- /dev/null
+++ b/docs-site/src/content/docs/es/dashboard.mdx
@@ -0,0 +1,15 @@
+---
+title: "Panel de uso"
+description: "Estadísticas anónimas de uso del proyecto, actividad, desglose por proveedor y modelo, y descargas de opencodex."
+template: splash
+tableOfContents: false
+editUrl: false
+lastUpdated: false
+---
+
+import TelemetryDashboard from '../../../components/TelemetryDashboard.astro';
+import TelemetryLeaderboard from '../../../components/TelemetryLeaderboard.astro';
+
+<TelemetryDashboard />
+
+<TelemetryLeaderboard />
diff --git a/docs-site/src/content/docs/es/getting-started/for-agents.md b/docs-site/src/content/docs/es/getting-started/for-agents.md
new file mode 100644
index 00000000000..e9918eb7427
--- /dev/null
+++ b/docs-site/src/content/docs/es/getting-started/for-agents.md
@@ -0,0 +1,156 @@
+---
+title: "Inicio rápido para agentes"
+description: "Instale y opere opencodex desde un terminal controlado por un agente o un script, respetando los límites del consentimiento del usuario."
+---
+
+Esta página está dirigida a agentes de IA y usuarios que automatizan tareas desde un
+terminal. Explica los comandos, sus códigos de salida y el límite entre la automatización
+y las acciones que requieren consentimiento del usuario. Para un recorrido guiado por
+una persona, consulte [Inicio rápido](/es/getting-started/quickstart/). El panel sigue
+disponible para la configuración interactiva; consulte
+[Panel web](/es/guides/web-dashboard/).
+
+<a id="set-up-opencodex"></a>
+
+## Configurar opencodex
+
+Instale el paquete publicado y compruebe que `ocx` está en `PATH`:
+
+```bash
+npm install -g --allow-scripts=bun @bitkyc08/opencodex
+ocx --version
+```
+
+Ejecuta `ocx init` en una terminal interactiva antes de iniciar el proxy, para que el listener use el puerto elegido:
+
+```bash
+ocx init
+```
+
+Elija una forma de ejecutar el proxy:
+
+```bash
+# Foreground: blocks this terminal until stopped.
+ocx start
+
+# Background: installs or updates the service, then starts it.
+ocx service
+```
+
+El asistente crea `$OPENCODEX_HOME/config.json`, normalmente
+`~/.opencodex/config.json`, solo si no existe. Volver a ejecutar init conserva
+la configuración existente; no hay una opción de forzado o sobrescritura.
+Si la configuración no es válida o se crea al mismo tiempo desde otro proceso,
+se conserva y la preparación se detiene. El asistente también puede añadir la
+dirección del proxy al `config.toml` de Codex e instalar el shim opcional de
+inicio automático. `ocx init` nunca inicia el proxy. Para una preparación
+totalmente no interactiva, configure los proveedores mediante `ocx provider add`
+como se muestra más abajo.
+
+:::caution[Consentimiento para dar una estrella en GitHub]
+Si es un agente, nunca responda a la solicitud de dar una estrella ni ejecute `gh`,
+la API de estrellas de GitHub o `POST /api/github/star` en nombre del usuario.
+Dar una estrella usa la identidad del usuario y requiere un consentimiento explícito
+independiente. En una ejecución controlada por un agente, la CLI suprime la pregunta
+y no escribe `.star-prompted`; la API de gestión devuelve
+`403 agent_consent_required`. No eluda ninguna de esas protecciones.
+
+Cuando el arranque imprima la solicitud, preséntela una sola vez como una elección
+Sí/No que el usuario debe responder: `Star lidge-jun/opencodex? Yes / No`.
+Debe aparecer cerca del inicio de la respuesta inmediatamente posterior al arranque,
+no como una sugerencia informal ni al final de un mensaje largo.
+Una pregunta sin respuesta queda pendiente: el silencio nunca equivale a Sí ni
+a un No registrado. No repita la pregunta en respuestas posteriores. La CLI vuelve
+a habilitar el aplazamiento como máximo una vez por versión de opencodex, y una
+versión posterior volverá a preguntar por su cuenta. Dé la estrella solo después
+de un Sí explícito. Un No explícito resuelve la decisión de forma permanente y
+no se vuelve a plantear.
+:::
+
+<a id="check-a-headless-installation"></a>
+
+## Comprobar una instalación sin interfaz gráfica
+
+Use estas comprobaciones de solo lectura en scripts y ejecuciones de agentes:
+
+```bash
+ocx status
+ocx doctor
+ocx health --json
+```
+
+`ocx status` informa del estado del proxy y del servicio. `ocx doctor`
+diagnostica el entorno local, la red, el entorno de ejecución de Codex y el estado
+de las cuentas. `ocx health` termina con el código `0` si el proxy está en buen
+estado y con `1` en caso contrario; `--json` devuelve una salida estructurada.
+
+Los comandos que usan la API de gestión, como `ocx combo set`, se comunican
+con el proxy en ejecución. Si no se encuentra un proxy activo o la API no está
+accesible, la CLI lo trata como un fallo `503` y termina con un código distinto
+de cero. Inicie el proxy en primer plano o el servicio en segundo plano antes
+de reintentar. Consulte la [referencia de CLI](/es/reference/cli/) y la
+[API de gestión](/es/reference/management-api/) para ver todos los comandos
+y endpoints.
+
+<a id="add-providers-and-combos-without-the-dashboard"></a>
+
+## Añadir proveedores y combos sin el panel
+
+Los proveedores del registro se pueden añadir por su nombre. Por ejemplo,
+este comando añade el preajuste de Anthropic con clave API y lo convierte
+en el proveedor predeterminado:
+
+```bash
+ocx provider add anthropic-apikey \
+  --api-key '${ANTHROPIC_API_KEY}' \
+  --set-default
+```
+
+Conserva las comillas simples: pasan la referencia literalmente, sin incluir el secreto en los argumentos del proceso ni guardar su valor en la configuración. Proporciona `ANTHROPIC_API_KEY` al proxy antes de iniciarlo y a los procesos CLI que resuelvan credenciales, como la sincronización de modelos. Exportarla después en otra terminal no actualiza un proxy en ejecución. Para un servicio en segundo plano, configura su entorno de inicio y reinícialo; la instalación del servicio no conserva automáticamente las variables de proveedores de tu terminal.
+
+`ocx provider add` escribe la configuración local. Añada `--sync` si ya hay
+un proxy en ejecución y quiere sincronizar los modelos con Codex de inmediato;
+en caso contrario, ejecute `ocx sync` más tarde. Los proveedores personalizados
+que no figuren en el registro requieren tanto `--adapter` como `--base-url`.
+
+Cuando todos los proveedores de destino estén configurados y el proxy esté
+en ejecución, cree un combo con conmutación por error:
+
+```bash
+ocx combo set main \
+  --targets anthropic-apikey/claude-opus-4-8,openai/gpt-5.6-sol \
+  --strategy failover
+```
+
+Los destinos usan la sintaxis `provider/model` y se separan con comas.
+El modelo virtual resultante es `combo/main`. Consulte
+[Combos](/es/guides/combos/) para conocer las estrategias, los pesos, la
+afinidad de enrutamiento y el comportamiento ante fallos.
+
+<a id="remote-and-lan-binds"></a>
+
+## Escucha remota y en la red local
+
+Las rutas normales de modelos en loopback no requieren un token de datos.
+Escuchar fuera de loopback, por ejemplo en `0.0.0.0`, requiere una credencial
+de admisión de datos: una clave API de cliente configurada en `config.apiKeys`,
+o un token compartido resuelto desde `OPENCODEX_API_AUTH_TOKEN`,
+`OCX_API_TOKEN_FILE` o el archivo privado `service-api-token`, accesible
+solo para su propietario. `ocx service install` puede crear ese archivo
+si no existe. Si utiliza un token mediante una variable de entorno, defínala
+antes de ejecutar `ocx start` u `ocx service install`:
+
+```bash
+export OPENCODEX_API_AUTH_TOKEN="your-secret-token"
+ocx service install
+```
+
+Las solicitudes de modelos utilizan la autenticación del plano de datos.
+La administración usa una credencial independiente:
+`OPENCODEX_ADMIN_AUTH_TOKEN` o el token administrativo generado en un archivo
+con permisos protegidos. Un token de datos no concede acceso administrativo.
+El panel sigue las reglas de sesión y acceso de la
+[API de gestión](/es/reference/management-api/#authentication-model).
+Nunca entregue el token administrativo a un cliente de modelos.
+Consulte [Acceso remoto](/es/reference/configuration/server/#remote-access)
+antes de exponer el proxy fuera del equipo local.
diff --git a/docs-site/src/content/docs/es/getting-started/how-it-works.mdx b/docs-site/src/content/docs/es/getting-started/how-it-works.mdx
new file mode 100644
index 00000000000..73be4ede042
--- /dev/null
+++ b/docs-site/src/content/docs/es/getting-started/how-it-works.mdx
@@ -0,0 +1,75 @@
+---
+title: "Cómo funciona"
+description: "El ciclo de vida de una solicitud en opencodex: análisis, enrutamiento, adaptación y transmisión de la respuesta."
+---
+
+import { Steps } from '@astrojs/starlight/components';
+
+Codex habla el OpenAI **Responses API**. opencodex acepta `POST /v1/responses` sobre HTTP con Eventos enviados por servidor, además de una actualización opt-in WebSocket en la misma ruta. Traduce la solicitud al formato de cable de su proveedor y la respuesta a Responses eventos, por lo que Codex nunca sabe que no está hablando con OpenAI.
+
+```
+            ┌──────────────────────────── opencodex ────────────────────────────┐
+            │                                                                     │
+ Codex ──▶  │  parser ──▶ router ──▶ [vision] ──▶ adapter ──▶ provider           │  ──▶ Codex
+ (/v1/      │     │          │          │            │           │                │   (SSE / WS)
+  responses)│   OcxParsed  provider   describe    buildRequest  parseStream       │
+            │   Request    +adapter   images       + fetch      AdapterEvent[]    │
+            │                                          │           │              │
+            │                                  [web-search loop]  bridge ─▶ SSE   │
+            └─────────────────────────────────────────────────────────────────────┘
+```
+
+![Enrutamiento multicuenta de Codex: los hilos existentes conservan la cuenta de ChatGPT y las sesiones nuevas pueden actualizar la cuota y elegir una cuenta disponible con menor uso.](../../../../assets/multi-auth-routing.svg)
+
+<a id="codex-auth-account-selection"></a>
+
+## Codex selección de cuenta de autenticación
+
+Cuando el proveedor seleccionado es el passthrough ChatGPT / Codex, opencodex puede elegir una cuenta de grupo almacenada antes de que la solicitud se reenvíe aguas arriba. La regla se divide intencionalmente:
+
+- **Los identificadores de hilo existentes mantienen la afinidad.** Un subproceso está vinculado a la generación de cuenta que lo inició, por lo que una sesión larga de SSH, tmux o móvil Codex sigue usando una cuenta en lugar de reequilibrarse a mitad de la conversación.
+- **Las sesiones nuevas pueden reequilibrarse.** Para un nuevo hilo, opencodex selecciona entre las cuentas elegibles usando `accountPoolStrategy` (`quota` por defecto, o `round-robin` / `fill-first`). La estrategia `quota` compara el uso conocido a través de las ventanas 5h, semanal y 30d y puede cambiar a una cuenta de menor uso cuando la cuenta activa cruza `autoSwitchThreshold`. Las cuentas en tiempo de reutilización o que necesitan una nueva autenticación se omiten independientemente de la estrategia.
+- **Señales de cuota y fallo de alimentación de enrutamiento.** El panel de control puede forzar una actualización de cuota con `GET /api/codex-auth/accounts?refresh=1`; las respuestas ascendentes exitosas capturan encabezados de cuota, 429 ponen una cuenta en tiempo de reutilización y 401/403 la marca para su reautenticación.
+- **Las ventanas de cuota inactivas pueden activarse a tiempo.** En **Configuración avanzada**, un único control de activación automática, desactivado por defecto, permite activar o desactivar las ventanas compatibles de cinco horas y semanales de todas las cuentas actuales, tanto la principal como las añadidas. Los ajustes mixtos se muestran explícitamente. Al activar la opción, solo se incluyen las ventanas reportadas; al desactivarla, también se eliminan activaciones obsoletas. Cada ajuste se guarda por separado: si alguno falla, se vuelve a leer el estado guardado y se muestra el fallo parcial. **Reintentar** completa la acción original de activación o desactivación. Las cuentas añadidas posteriormente no quedan inscritas automáticamente. En el modo Pool, cuando vence el plazo de restablecimiento de una ventana, opencodex envía su solicitud mínima de calentamiento, que no se almacena, a la cuenta exacta afectada. Agrupa las ventanas que vencen a la vez en una sola solicitud y guarda de forma duradera las marcas de tiempo de ambas ventanas para evitar duplicaciones tras reiniciar el proxy. Omite las cuentas pausadas o que requieren autenticarse de nuevo. La activación recoge los encabezados de cuota de las respuestas exitosas. Los plazos de restablecimiento conocidos se comprueban localmente cada minuto, sin consultas periódicas de cuota, aunque el uso en caché sea antiguo o se reinicie el proxy. Solo los plazos desconocidos requieren consultar metadatos después de la protección de frescura de cinco minutos. Si el descubrimiento sigue sin resolverse o la activación falla, se reintenta a los 5, 10, 20 y 40 minutos, y después como máximo cada 60 minutos; estos retardos se restablecen al reiniciar el proxy. Cuando están disponibles, los encabezados de una respuesta exitosa aportan la siguiente ventana sin otra consulta. Las actualizaciones del dashboard y el sondeo opcional de notificaciones de restablecimiento siguen siendo independientes. Los límites de restablecimiento observados se conservan entre reinicios hasta completar la activación: un cambio en la marca de tiempo de una ventana inactiva no elimina una activación pendiente. La consulta de metadatos conserva la recuperación acotada de autenticación; un 401 durante la inferencia marca la credencial rechazada para volver a autenticarse, en vez de consumir reintentos repetidamente. Los fallos solo registran una etiqueta opaca de cuenta y un motivo basado en el estado. Esto es independiente del enrutamiento según el restablecimiento de ventanas: el enrutamiento elige una cuenta para el trabajo entrante, mientras que la activación envía una solicitud a una cuenta inscrita solo cuando vence el plazo de su propia ventana.
+
+**Pauta de consulta:** La recuperación de bloqueo de la cuenta principal espera el restablecimiento de bloqueo conocido, luego consulta para confirmar la recuperación; el tiempo solo nunca desbloquea la cuenta. Sin un restablecimiento futuro, la recuperación en segundo plano utiliza un retroceso de 5/10/20/40/60 minutos mientras la cuenta permanece bloqueada. En el modo Pool, las consultas ordinarias de uso principal/de grupo comparten el retroceso de fallas (5, 10, 20, 40, luego 60 minutos) para fallas de transporte, fallas que no son de auth HTTP y 200 cuerpos inutilizables, incluidas las actualizaciones forzadas; `Retry-After` puede extender esa espera. El manejo de autenticación 401/403 existente permanece sin cambios. Solo el uso utilizable borra el retroceso; las consultas simultáneas de la misma clave comparten el resultado establecido de una lectura. Las credenciales reemplazadas tienen un estado de reintento separado, y las instantáneas obsoletas nunca se marcan como nuevas. Estos retrasos son locales de proceso; las actualizaciones forzadas principales fuera del modo Pool conservan su comportamiento independiente.
+
+**Nota de degradación:** Antes de ejecutar una versión anterior, quite solo `nextFiveHourResetAt` y `nextWeeklyResetAt` de la configuración de activación automática. Los lectores más antiguos rechazan estos nuevos campos y pueden deshabilitar todo el bloque de configuración de activación.
+
+<a id="sub-agent-model-selection"></a>
+
+## Selección del modelo de subagente
+
+En una instalación nueva, `subagentModels` ofrece `gpt-6-astra`, `gpt-6.1-sol` y `gpt-6-luna` en el selector de subagentes de Codex. El panel permite reordenar o sustituir hasta cinco entradas por modelos nativos o enrutados. Las opciones `injectionModel` e `injectionEffort` describen preferencias de modelo y esfuerzo en la guía redactada por el proxy; siguen siendo recomendaciones salvo que se active la sincronización de valores nativos. Consulta [Configuración de agentes](/es/reference/configuration/agents/) para las reglas de guía v1/v2 y la sincronización.
+
+<a id="the-lifecycle"></a>
+
+## El ciclo de vida
+
+<Steps>
+
+1. **Análisis** - `responses/parser.ts` valida la solicitud con un esquema de Zod (`responses/schema.ts`) y la reduce a un mensaje interno `OcxParsedRequest`: solicitud del sistema, una lista de mensajes normalizados (texto, imágenes, llamadas de herramientas, resultados de herramientas), las definiciones de herramientas, opciones de generación y banderas de características como `_webSearch` (se solicitó una búsqueda web alojada) y `_structuredOutput` (se estableció un esquema JSON o un `text.format` de objeto JSON). Las imágenes se conservan como partes de contenido real, nunca insertadas como texto base64.
+
+2. **Enrutamiento** — `router.ts` resuelve el modelo en este orden: perfil de enrutamiento configurado → selector exacto de cuenta de Codex → identificador o alias de Combo configurado → `provider/model` explícito → modelo nativo de OpenAI sin prefijo (`gpt-`, `o1-`/`o3-`/`o4-`) → `defaultModel` de un proveedor → prefijos integrados (`claude-`, `llama-`/`mixtral-`/`gemma-`) → `models[]` de un proveedor → `defaultProvider`. Consulta [Enrutamiento de modelos](/es/guides/model-routing/).
+
+3. **Autenticar** - para un proveedor `oauth`, opencodex se intercambia en un token de acceso fresco y actualizado automáticamente como la clave portadora, de modo que los adaptadores existentes se autentican sin cambios. Para las cuentas de grupo ChatGPT / Codex, `codex/auth-context.ts` resuelve primero la cuenta y el adaptador de paso se niega a continuar si la credencial de grupo requerida no está disponible.
+
+4. **Sidecar de visión (opcional)** - si el modelo enrutado aparece en `provider.noVisionModels` y la solicitud lleva una imagen, opencodex describe cada imagen con el sidecar de visión ChatGPT configurado y la reemplaza con texto, por lo que un modelo de solo texto todavía puede razonar al respecto. Véase [Sidecares](/es/guides/sidecars/).
+
+5. **Camino rápido de paso**: si el adaptador es un paso Responses (`openai-responses` o `azure-openai`), opencodex mantiene el cuerpo Responses, aplica enrutamiento dirigido y reescribe la compatibilidad, luego retransmite la respuesta del proveedor sin convertirlo a través de `AdapterEvent` s.
+
+6. **Sidecar de búsqueda web (opcional)** — si Codex solicita la herramienta alojada `web_search` y el modelo enrutado no es de OpenAI, opencodex expone una función sintética `web_search` y ejecuta el modelo en un pequeño bucle de agente. Las búsquedas reales se realizan mediante `gpt-5.6-luna` de forma predeterminada, con tu sesión de ChatGPT, y los resultados se incorporan como respuestas de la herramienta.
+
+7. **Compacto (cuando se solicita)** - Codex v1 llama `POST /v1/responses/compact`; v2 agrega un `compaction_trigger` a un giro Responses. Las rutas de paso nativas se compactan aguas arriba, mientras que un modelo enrutado se ejecuta como un resumen sin herramientas y devuelve la forma de historial de reemplazo que espera Codex.
+
+8. **Adaptar** — en los demás casos, `buildRequest()` del adaptador elegido construye la solicitud HTTP al proveedor (URL, encabezados y cuerpo) en su formato nativo. opencodex envía esa solicitud mediante `fetch`.
+
+9. **Puente** - el adaptador `parseStream()` (o `parseResponse()`) produce `AdapterEvent` s interno (texto, razonamiento, inicio/delta/fin de llamada de herramienta, hecho, error). `bridge.ts` convierte ese flujo en Responses SSE eventos - `response.output_text.delta`, `response.reasoning_summary_text.delta`, `response.function_call_arguments.delta`, `response.completed`, y así sucesivamente. El transporte opcional WebSocket envía las mismas cargas útiles de eventos que los marcos de texto.
+
+</Steps>
+
+<a id="why-a-proxy-and-not-a-codex-fork"></a>
+
+## ¿Por qué un proxy y no una bifurcación Codex?
+
+Codex codifica el Responses API. Al traducir en el límite del protocolo, opencodex funciona con el Codex **CLI, App, y SDK** sin cambios, sobrevive a las actualizaciones Codex y le permite cambiar de proveedor por solicitud sin tocar el propio Codex. La traducción es bidireccional y fiel a la transmisión: resúmenes de razonamiento, MCP espacios de nombres de herramientas, herramientas de forma libre (`apply_patch`) y `tool_search` descubrimiento de todo el viaje de ida y vuelta correctamente. Consulte el [Referencia de arquitectura](/es/reference/architecture/) para el mapeo evento por evento.
diff --git a/docs-site/src/content/docs/es/getting-started/installation.md b/docs-site/src/content/docs/es/getting-started/installation.md
new file mode 100644
index 00000000000..9333d024733
--- /dev/null
+++ b/docs-site/src/content/docs/es/getting-started/installation.md
@@ -0,0 +1,143 @@
+---
+title: "Instalación"
+description: "Instala el proxy opencodex (ocx), prepara sus requisitos y comprueba que funciona."
+---
+
+opencodex instala dos comandos equivalentes, `ocx` y `opencodex`. Ambos inician el mismo servidor HTTP local escrito para Bun. Las solicitudes se envían al proveedor seleccionado por el enrutamiento. Los sidecars opcionales de visión y búsqueda web también pueden usar tu sesión de ChatGPT cuando un modelo enrutado los necesite.
+
+<a id="desktop-terminal-command"></a>
+
+## Comando terminal de escritorio
+
+Una instalación estable de OpenCodex Desktop configura `ocx` para las terminales nuevas al iniciar la aplicación. Abre una terminal nueva y ejecuta `ocx status` u `ocx doctor` para inspeccionar el primer ejecutable de PATH. En macOS y en instalaciones de Linux con paquetes `.deb`, un bloque administrado al final de los archivos de inicio de zsh, bash y fish coloca `~/.opencodex-desktop/bin` primero en PATH y usa el lanzador de escritorio. Windows coloca el directorio del `ocx.exe` incluido al principio del `Path` del usuario. Las terminales ya abiertas, los alias, las cachés de shell y los cambios posteriores de PATH pueden seleccionar otro comando; en Windows también puede tener prioridad una entrada del PATH del sistema. Usa el ajuste de comando de terminal de la aplicación para reparar, desactivar o eliminar esta configuración. AppImage queda excluido.
+
+En macOS y Linux, si todavía se ejecuta el lanzador de npm/pnpm, este delega los comandos compatibles en la CLI de Desktop cuando su registro está habilitado y supera las comprobaciones de propiedad, permisos y seguridad de archivos. Windows no usa esa delegación: las terminales nuevas seleccionan el `ocx.exe` de Desktop mediante el orden del `Path` del usuario. El error `record-unsafe` indica que el registro o su directorio no superó una comprobación de seguridad. Abre OpenCodex Desktop para reparar el comando, o usa `OCX_NO_DESKTOP_HANDOFF=1` en una invocación del paquete en macOS/Linux. La actualización o eliminación del paquete y la inspección interna conservan su ruta habitual. `OCX_NO_DESKTOP_HANDOFF=1` solo suprime la delegación de esa invocación; no cambia el lanzador de Desktop seleccionado directamente ni el PATH.
+
+<a id="prerequisites"></a>
+
+## Requisitos previos
+
+| Requisito | Por qué |
+| --- | --- |
+| **[Node](https://nodejs.org) ≥ 18** | `ocx` se ejecuta con Bun, que se incluye automáticamente al instalar con npm o pnpm. **No** necesitas instalar Bun por separado. |
+| **[OpenAI Codex](https://openai.com/codex)** (CLI, aplicación o SDK) | Es el cliente al que opencodex sirve como proxy. opencodex escribe en `$CODEX_HOME/config.toml` (por defecto, `~/.codex/config.toml`). |
+| Una cuenta de proveedor o clave API | Anthropic, xAI, Kimi, Ollama Cloud, OpenRouter, un punto final compatible con OpenAI o su inicio de sesión ChatGPT. |
+
+<a id="install"></a>
+
+## Instalar
+
+```bash
+npm install -g --allow-scripts=bun @bitkyc08/opencodex
+```
+
+Con pnpm 10.4 o posterior:
+
+```bash
+pnpm add -g --allow-build=bun @bitkyc08/opencodex
+```
+
+:::note[¿npm bloqueó el script postinstall de Bun?]
+Las versiones recientes de npm pueden bloquear el script postinstall de Bun (`npm warn
+install-scripts ... blocked because they are not covered by allowScripts`) y dejar sin preparar el entorno incluido. Tras intentar la recuperación permitida del entorno incluido, el lanzador puede usar un ejecutable Bun situado en un directorio absoluto de PATH si es una versión estable con la misma versión mayor y una versión completa igual o superior a la de la dependencia. Con la dependencia actual 1.4.4, esto admite 1.4.4 o posterior dentro de la versión mayor 1. Las comprobaciones de versión e identidad exigen que `bun --version` coincida con `Bun.version` informado por `bun -e`. En POSIX se comprueba toda la ruta, incluidos los directorios y componentes alcanzados mediante enlaces simbólicos. Cada directorio y enlace recorrido, y el ejecutable resuelto, deben pertenecer a root o al usuario efectivo del lanzador. Los directorios y el ejecutable resuelto no pueden permitir escritura al grupo ni a otros usuarios; no se usan los bits de permisos de los enlaces simbólicos. Se rechazan ancestros compartidos con escritura como `/tmp`, incluso con sticky bit: proteger solo el ejecutable y su directorio inmediato no basta. Un aviso de una línea en stderr identifica la versión de Bun seleccionada. Bun sigue incluido en el paquete; instalarlo por separado es opcional.
+
+Si no hay un entorno utilizable y falta la dependencia `bun`, el error lo indica. En macOS también muestra la CLI de Desktop si encuentra un ejecutable en
+`/Applications/OpenCodex.app/Contents/MacOS/ocx` o
+`~/Applications/OpenCodex.app/Contents/MacOS/ocx`. Puedes invocar esa ruta explícitamente: esta recuperación no delega automáticamente en ella ni instala un lanzador en PATH.
+
+Para reparar el entorno incluido, reinstala el paquete permitiendo el script de Bun. Incluye siempre el nombre del paquete: la sugerencia abreviada de npm lo omite y reinstala el directorio actual.
+
+```bash
+npm install -g --allow-scripts=bun @bitkyc08/opencodex
+
+# if the original install used sudo, keep using sudo:
+sudo npm install -g --allow-scripts=bun @bitkyc08/opencodex
+```
+:::
+
+Verifique que ambos alias de comando estén en su `PATH`:
+
+```bash
+ocx --version
+opencodex --version
+```
+
+Antes de iniciar, detener o reiniciar el proxy, gestionar el servicio o actualizar desde la CLI de Bun, puede aparecer un aviso breve en stderr si las versiones de la CLI y el proxy no coinciden. Es informativo y conserva el código de salida; las salidas JSON y de ayuda no lo activan. Las actualizaciones de npm/pnpm que gestiona el lanzador de Node antes de iniciar la CLI de Bun no muestran este aviso. `ocx status`, `ocx doctor` y `ocx resolve` ya informan de estas diferencias en sus diagnósticos.
+
+Si instalas el servicio desde un shell con fnm, nvm, mise, asdf o volta, OpenCodex excluye del PATH del servicio los directorios multishell ligados a esa sesión. En Linux selecciona un lanzador `ocx` duradero si está disponible; de lo contrario usa el Bun del paquete. Ejecuta `ocx service repair` si un servicio anterior se instaló desde un directorio multishell. En macOS, la reparación recarga launchd si cambia la lista guardada.
+
+<a id="standalone-binary-no-npm"></a>
+
+## Binario independiente (sin npm)
+
+Las descargas de versiones también incluyen un binario `ocx` para las plataformas compatibles de macOS, Linux y Windows. Incluye Bun y el dashboard, por lo que no requiere npm, Node ni una instalación separada de Bun. Descarga el archivo de tu plataforma, extráelo y ejecuta:
+
+```bash
+./ocx --version
+./ocx start
+```
+
+Los directorios extraídos `gui/dist` y `keyring` deben permanecer junto al binario. El primero sirve el dashboard y el segundo contiene el enlace nativo de la plataforma con el almacén de credenciales del sistema operativo.
+
+En Windows, [Firma de código en Windows](/es/reference/code-signing/) explica cómo se firma `ocx.exe` y cómo verificarlo.
+
+<a id="release-channels"></a>
+
+### Canales de liberación
+
+El canal estable `latest` ya incluye el catálogo de GPT-5.6 Sol/Terra/Luna para ChatGPT, la API de OpenAI con clave, OpenRouter y las rutas experimentales de Cursor. La disponibilidad sigue dependiendo de la cuenta del proveedor: una entrada de catálogo no concede acceso. Usa el canal preview solo para probar versiones preliminares de opencodex:
+
+```bash
+npm install -g --allow-scripts=bun @bitkyc08/opencodex@preview
+ocx update --tag preview
+```
+
+<a id="run-from-source"></a>
+
+## Correr desde la fuente
+
+Para hackear el propio opencodex:
+
+Compilar un checkout del código fuente requiere un ejecutable Bun en PATH antes de ejecutar `bun install`. El paquete npm ofrece `ocx` y `opencodex`, no un comando global `bun`.
+
+```bash
+git clone https://github.com/lidge-jun/opencodex.git
+cd opencodex
+bun install
+bun run dev:proxy   # starts the proxy API in dev mode (src/cli/index.ts start)
+bun run dev:gui     # starts the dashboard dev server (another terminal)
+```
+
+`bun run dev` es un alias de `bun run dev:proxy`. La API del proxy expone `/healthz`, `/v1/responses` y `/api/*`. `GET /` sirve el dashboard empaquetado cuando `bun run build:gui` ha generado `gui/dist`. Para desarrollar la interfaz, inicia el frontend por separado con `bun run dev:gui`.
+
+<a id="what-gets-created"></a>
+
+## Lo que se crea
+
+opencodex guarda sus datos en `$OPENCODEX_HOME` (por defecto, `~/.opencodex`). Los archivos de integración de Codex están en `$CODEX_HOME` (por defecto, `~/.codex`).
+
+| Ruta | Finalidad |
+| --- | --- |
+| `$OPENCODEX_HOME/config.json` | Sus proveedores, proveedor predeterminado, puerto y opciones. |
+| `$OPENCODEX_HOME/ocx.pid` | PID del proxy en ejecución (guarda de instancia única). |
+| `$OPENCODEX_HOME/runtime-port.json` | El PID vivo, el nombre de host y el puerto —, incluido un puerto asignado al sistema operativo cuando `config.port` es `0`. |
+| `$OPENCODEX_HOME/auth.json` | Las credenciales OAuth almacenadas (cuando `ocx login`). |
+| `$OPENCODEX_HOME/catalog-backup*.json` | Codex copias de seguridad del catálogo de modelos hechas antes de que opencodex lo edite. |
+| `$CODEX_HOME/config.toml` | Cuando el proxy se vincula a loopback, opencodex añade `openai_base_url` en la raíz, dentro de su bloque delimitado por marcadores. Con una vinculación fuera de loopback, utiliza `model_provider = "opencodex"` y `[model_providers.opencodex]` para que Codex pueda enviar el encabezado de autenticación de la API. |
+| `$CODEX_HOME/opencodex.config.toml` | Perfil de referencia/retroceso escrito junto a la configuración principal de Codex. |
+| `$CODEX_HOME/opencodex-catalog.json` | Catálogo de modelos nativos y enrutados sincronizados utilizado por Codex. |
+
+:::note
+opencodex conserva tu configuración de Codex. En la instancia independiente propietaria, `ocx stop`, `ocx restore` y `ocx eject` eliminan las líneas administradas y restauran Codex nativo. Un cliente conectado a un Hub conserva su enrutamiento; detener una instancia hermana no modifica la configuración compartida del cliente. Consulta [ciclo de vida y propiedad](/es/reference/cli/lifecycle/#runtime-ownership) antes de confiar en esa restauración.
+:::
+
+<a id="next"></a>
+
+## Siguiente
+
+Continuar a la [Inicio rápido](/es/getting-started/quickstart/) para configurar su primer proveedor, o leer [Cómo funciona](/es/getting-started/how-it-works/) para la arquitectura.
+
+
+Un registro Desktop habilitado en macOS/Linux detiene el launcher del paquete si falta o no arranca el ejecutable seleccionado, sin fallback silencioso. Repara o desactiva el comando de terminal en Desktop; `OCX_NO_DESKTOP_HANDOFF=1` solo omite el handoff una vez.
+
+En Windows, el proxy activo mantiene `node_modules\bun\bin` abierto y `npm install -g` manual puede fallar con `EBUSY`. `ocx update` lo detiene y reinicia su servicio. Para reinstalar manualmente, usa `ocx stop`, instala y reinicia con `ocx service restart` si es servicio o `ocx start` si no tiene supervisor. Doctor muestra esa secuencia si el Bun del paquete no se descomprimió.
diff --git a/docs-site/src/content/docs/es/getting-started/quickstart.md b/docs-site/src/content/docs/es/getting-started/quickstart.md
new file mode 100644
index 00000000000..28b2326c787
--- /dev/null
+++ b/docs-site/src/content/docs/es/getting-started/quickstart.md
@@ -0,0 +1,201 @@
+---
+title: "Inicio rápido"
+description: "Instala opencodex, añade tu primer proveedor y conecta la herramienta de programación que ya utilizas: Codex, Claude Code, Claude Desktop, Grok Build u otra compatible."
+---
+
+Esta guía te lleva desde una instalación nueva hasta la primera solicitud de la herramienta de programación que ya utilizas. Los pasos 1 y 2 son iguales para todas; el paso 3 tiene una sección breve para cada herramienta. La [página de compatibilidad con clientes](/es/reference/client-support/) enumera todas las herramientas y su forma de conexión.
+
+<a id="standalone-binary-no-npm"></a>
+
+## Binario independiente, sin npm
+
+También puedes usar un archivo de versión con el binario `ocx` y Bun, sin npm. Extráelo con `gui/dist` junto al binario. Sigue los pasos de configuración siguientes con ese ejecutable.
+
+Para los comandos siguientes, añade a PATH el directorio del binario extraído, o sustituye `ocx` por la ruta completa del ejecutable. Conserva `gui/dist` a su lado.
+
+<a id="1-run-the-setup-wizard"></a>
+
+## 1. Ejecuta el asistente de configuración
+
+```bash
+ocx init
+```
+
+`ocx init` te guía por estos pasos:
+
+1. **Elegir un proveedor**: selecciona uno de los 107 preajustes del registro integrado o `custom` para introducir una URL base y un adaptador.
+2. **Clave API**: pega una clave o indica una variable de entorno como `${ANTHROPIC_API_KEY}`.
+3. **Modelo predeterminado**: para proveedores con clave, locales o personalizados, acepta el preajuste o introduce un identificador de modelo.
+4. **Puerto del proxy**: `10100` de forma predeterminada.
+5. **¿Integrar con Codex?** En una configuración habitual de bucle local, opencodex añade `openai_base_url` en la raíz de `$CODEX_HOME/config.toml` (de forma predeterminada, `~/.codex/config.toml`) para que el proveedor integrado `openai` de Codex apunte al proxy. Las conexiones remotas o LAN usan una entrada de proveedor dedicada con un encabezado de autenticación de API.
+6. **¿Instalar el shim de inicio automático?** Si lo habilitas, al iniciar `codex` se ejecuta primero `ocx ensure`.
+
+El resultado se guarda en `$OPENCODEX_HOME/config.json` (de forma predeterminada, `~/.opencodex/config.json`).
+
+`ocx init` solo crea una configuración si no existe ninguna. Si ya hay una válida, la conserva y termina; usa `ocx config` o el dashboard para actualizarla. Las entradas no válidas, ilegibles o que sean enlaces simbólicos se conservan y se notifican como errores. Si otro proceso crea la configuración durante el asistente, se conserva su archivo y el asistente se detiene antes de administrar copias de seguridad o proponer la integración.
+
+EOF o Ctrl+C antes de crear el archivo cancela la configuración. Cancelar después conserva el archivo guardado. Su creación inicial requiere soporte y permisos para enlaces duros en ese sistema de archivos; si falla, el asistente se detiene sin intentar sobrescribirlo. Si no termina de crear el archivo o limpiar los temporales, inspecciona el directorio antes de reintentar: puede quedar una configuración completa o un archivo temporal privado.
+
+Si el asistente informa de que no pudo asegurar los permisos iniciales, el sistema de archivos o la cuenta no pudieron aplicar los permisos privados requeridos (ACL de NTFS en Windows). Esto ocurre antes de escribir el contenido. Un fallo al publicar mediante enlace duro es distinto: los permisos privados se aplicaron, pero no se pudo publicar el archivo completo o no se puede confirmar el resultado.
+
+Inspecciona el directorio elegido antes de reintentar. Conserva cualquier `config.json` existente; no lo borres para forzar al asistente a continuar. Para una instalación nueva, elige una ubicación con permiso de escritura que admita enlaces duros y permisos privados. Un directorio local NTFS es adecuado en Windows si tu cuenta puede aplicar sus ACL. Por ejemplo, elige una ubicación nueva en la misma terminal antes de ejecutar el asistente:
+
+```powershell
+# Windows PowerShell: choose a fresh directory on a local NTFS volume.
+$env:OPENCODEX_HOME = Join-Path $env:LOCALAPPDATA "opencodex-local"
+ocx init
+```
+
+```sh
+# macOS/Linux: choose a fresh directory on a filesystem with hard links and Unix permissions.
+export OPENCODEX_HOME="$HOME/.opencodex-local"
+ocx init
+```
+
+Usa el mismo `OPENCODEX_HOME` en los comandos posteriores y en el servicio que ejecute el proxy. Cambiar esta variable selecciona otra ubicación de configuración; no migra una instalación existente. El asistente no usa como alternativa la escritura directa ni un cambio de nombre que reemplace archivos: crear un archivo exclusivo y escribir después en él podría exponer contenido parcial.
+
+:::note[Entradas del despliegue de GPT-5.6]
+La versión estable actual incluye GPT-5.6 Sol/Terra/Luna para el paso directo de ChatGPT, OpenAI con clave API, OpenRouter y el adaptador experimental de Cursor. Solo funcionan si la cuenta del proveedor tiene acceso. Los preajustes de OpenAI con clave API y OpenRouter anuncian una ventana de contexto utilizable de 922.000 tokens; Cursor conserva los metadatos de su propio adaptador.
+:::
+
+<a id="2-start-the-proxy"></a>
+
+## 2. Inicia el proxy
+
+Ejecuta una de estas alternativas; ambas mantienen el proxy en primer plano:
+
+```bash
+ocx start            # defaults to port 10100
+```
+
+Como alternativa, elige otro puerto:
+
+```bash
+ocx start --port 8080
+```
+
+Deja abierta esa terminal del proxy. Ejecuta los comandos de estado y del dashboard que siguen en una segunda terminal con el mismo `OPENCODEX_HOME`.
+
+Al iniciar, opencodex:
+
+- Escribe su PID en `~/.opencodex/ocx.pid` y rechaza un segundo inicio.
+- Descubre los modelos disponibles cuando el proveedor lo permite y **sincroniza las entradas nativas y enrutadas en el catálogo de modelos de Codex**.
+- Escucha en `http://localhost:<port>/v1`.
+
+Una instancia activa de opencodex con el mismo `OPENCODEX_HOME` impide iniciar otra, aunque el nuevo puerto esté libre. Detén primero esa instancia con `ocx stop`, o usa otro `OPENCODEX_HOME` para una instancia independiente. Si un proceso ajeno ocupa el puerto solicitado, `ocx start` lo identifica; elige un puerto libre con `ocx start --port <port>`. Nunca cambia de puerto automáticamente, para evitar que queden dos proxies activos y Codex apunte al más reciente.
+
+
+Una ubicación `OPENCODEX_HOME` distinta permite otra instancia, pero no enruta por separado la configuración compartida de Codex, Grok o Claude. Esa instancia atiende solicitudes directas en su puerto; los clientes compartidos siguen apuntando a la instancia existente. Un cliente Hub conserva su ruta al detenerlo; detener una instancia hermana no restaura la configuración compartida. Consulta [la propiedad del entorno](/es/reference/cli/lifecycle/#runtime-ownership).
+
+
+Compruébalo:
+
+```bash
+ocx status
+ocx gui       # open the dashboard on the live port
+```
+
+<a id="3-use-codex"></a>
+<a id="3-connect-your-tool"></a>
+
+## 3. Conecta tu herramienta
+
+Elige la sección de la herramienta que utilizas. Puedes conectar varias: comparten los mismos proveedores y modelos.
+
+### Codex
+
+Si aceptaste la propuesta de integración con Codex del paso 1, Codex ya se comunica con opencodex de forma transparente. Si la rechazaste, o el asistente terminó porque ya había una configuración, activa el interruptor de Codex en **Conectar** del dashboard antes de ejecutar Codex. [Integración con Codex](/es/guides/codex-integration/) explica qué cambia y cómo restaurarlo.
+
+```bash
+codex "Refactor this function for readability"
+```
+
+Para elegir un modelo enrutado concreto, usa el formato `provider/model` que muestra el selector de Codex:
+
+```bash
+codex -m "anthropic/claude-opus-5" "Explain this stack trace"
+codex -m "ollama-cloud/glm-5.2"      "Write a SQL migration"
+```
+
+### Claude Code
+
+Con la CLI `claude` instalada:
+
+```bash
+ocx claude
+```
+
+`ocx claude` inicia el proxy si no está en ejecución y abre Claude Code con su entorno dirigido a opencodex. Los argumentos adicionales se reenvían. Consulta [Claude Code](/es/guides/claude-code/) para los modelos predeterminados por nivel, otros lanzadores y cómo desactivar la integración.
+
+### Claude Desktop
+
+```bash
+ocx claude desktop
+```
+
+En una instalación nueva, configura el perfil de pasarela para toda la aplicación. Si ya utilizas el modo de conexión directa con Anthropic, lo conserva; ejecuta `ocx claude desktop apply --gateway` para cambiarlo explícitamente. Ese otro modo mantiene Desktop en claude.ai y solo enruta la pestaña Code; se describe en [Modos de Claude Desktop](/es/guides/claude-code/#claude-desktop-modes-gateway-default-and-first-party).
+
+Cierra Claude Desktop por completo y vuelve a abrirlo después de cambiar de modo.
+
+### Grok Build
+
+Con un listener local, `ocx start` registra los modelos visibles en `~/.grok/config.toml` si existe `~/.grok`. Elige un modelo `ocx-*` en Grok Build. [Grok Build](/es/guides/grok-build/) explica las conexiones remotas y el bloque administrado.
+
+Después de añadir proveedores o modelos, ejecuta `ocx ensure` o reinicia el proxy para que Grok Build los vea.
+
+### Otras herramientas
+
+Las herramientas con integración administrada, como OpenCode, Pi, Qoder, WorkBuddy, Kilo, Cline y T3 Code, se conectan desde **Conectar** del dashboard o mediante:
+
+```bash
+ocx integration client enable --client <id>
+```
+
+[Integraciones](/es/guides/integrations/) enumera el archivo de configuración de cada herramienta y cuándo entra en vigor el cambio. Cualquier otra herramienta que admita un endpoint personalizado puede usar la URL base compatible con OpenAI `http://localhost:<port>/v1` o la URL base de Anthropic `http://localhost:<port>`.
+
+<a id="choose-sub-agent-models-optional"></a>
+
+## Elegir modelos de subagentes, opcional
+
+Una configuración nueva incluye `gpt-6-astra`, `gpt-6.1-sol` y `gpt-6-luna` en el selector de subagentes de Codex. Abra `ocx gui` para sustituirlos o reordenar hasta cinco modelos nativos o enrutados. El panel también permite elegir un modelo preferido de subagentes y su esfuerzo de razonamiento. Consulte [Interfaz de subagentes](/es/guides/sub-agent-surface/) para elegir v1/base/v2 y conocer cuándo se aplican las instrucciones, los valores nativos predeterminados y las alternativas.
+
+<a id="logging-in-instead-of-pasting-a-key"></a>
+
+## Iniciar sesión en lugar de pegar una clave
+
+Algunos proveedores permiten iniciar sesión con una cuenta mediante OAuth y renovar las credenciales automáticamente:
+
+```bash
+ocx login xai          # or: anthropic, kimi, kiro, google-antigravity, cursor
+ocx logout xai
+```
+
+El proveedor predeterminado de OpenAI **no necesita una clave**: reenvía directamente las credenciales existentes de `codex login`. Consulta [Proveedores](/es/guides/providers/).
+
+<a id="stopping--restoring"></a>
+
+## Detener y restaurar
+
+```bash
+ocx stop      # stop this instance; restoration depends on ownership (see below)
+ocx restore       # restore native Codex without stopping (alias: ocx eject)
+ocx restore back  # route Codex through the still-running proxy again
+```
+
+<a id="startup-ownership-could-not-be-verified"></a>
+
+## No se pudo verificar la propiedad al iniciar
+
+Si al iniciar aparecen `Shared-client owner could not be verified` y `refusing startup`, OpenCodex no pudo determinar de forma segura si otro proxy controla las opciones compartidas de los clientes. Se detiene antes de publicar otro entorno de ejecución o modificar esas opciones. Reintenta cuando se recupere la conectividad local; un servicio en segundo plano ya instalado reintenta mediante su gestor de servicios. Un tiempo de espera agotado no convierte permanentemente el proceso nuevo en una instancia secundaria.
+
+`Proxy ownership is unverified; startup refused` significa que la comprobación del propietario local no fue concluyente. OpenCodex conserva el registro del PID, el diario de recuperación y los ajustes compartidos de los clientes. Reintenta cuando el propietario responda o termine; una comprobación de salud fallida por sí sola no autoriza la recuperación tras un cierre inesperado. Si el proceso registrado ya no existe y nadie escucha en el puerto, la recuperación sigue siendo automática.
+
+No es necesario habilitar IPv6 en el bucle local. El inicio comprueba si puede vincular cada dirección de bucle local y omite las familias no disponibles. Si se agota el tiempo de espera de una familia disponible, se detiene hasta que pueda verificar la propiedad.
+
+<a id="next"></a>
+
+## Siguientes pasos
+
+- [Cómo funciona](/es/getting-started/how-it-works/): qué sucede con cada solicitud.
+- [Proveedores](/es/guides/providers/): todas las formas de autenticación.
+- [Configuración](/es/reference/configuration/): referencia completa de `config.json`.
diff --git a/docs-site/src/content/docs/es/guides/chatgpt-desktop.md b/docs-site/src/content/docs/es/guides/chatgpt-desktop.md
new file mode 100644
index 00000000000..7cde0152166
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/chatgpt-desktop.md
@@ -0,0 +1,71 @@
+---
+title: "Shim del app-server de ChatGPT Desktop (experimental)"
+description: "Experimento opcional para macOS que reescribe los campos de bloqueo por cuota general en la salida estándar del app-server incluido."
+---
+
+Este experimento **solo funciona en macOS y está desactivado de forma predeterminada**. Filtra la salida estándar JSON-RPC del app-server incluido con ChatGPT para abrir los bloqueos conocidos debidos únicamente a la cuota general. No aumenta la cuota de la cuenta ni obliga al servicio del proveedor a aceptar solicitudes que rechaza.
+
+Habilítelo en el archivo `config.json` de OpenCodex:
+
+```json
+{
+  "chatgptDesktop": { "appServerShim": true }
+}
+```
+
+Después, ejecute:
+
+```bash
+ocx chatgpt launch
+ocx chatgpt status
+```
+
+`launch` crea un lanzador ejecutable en el directorio de configuración de OpenCodex, cierra ChatGPT si está en ejecución y vuelve a abrirlo con `open -a <bundle> --env CODEX_CLI_PATH=<launcher>`. Busca la aplicación por su identificador de paquete, `com.openai.codex`, por lo que también admite instalaciones en `~/Applications` o en otro volumen. Nunca cierra ni abre otra aplicación que simplemente comparta el nombre «ChatGPT». Guarde primero el trabajo en curso: esta operación reinicia la aplicación. No requiere un proxy de OpenCodex en ejecución.
+
+Para eliminar el lanzador y volver a abrir la aplicación sin esa sustitución:
+
+```bash
+ocx chatgpt restore
+```
+
+La restauración conserva el valor configurado. Establezca `chatgptDesktop.appServerShim` en `false` o elimínelo para impedir futuros inicios explícitos con el shim. Abrir normalmente la aplicación desde Dock o Spotlight no aplica el shim automáticamente.
+
+Si ChatGPT no está instalado (no se encuentra un paquete `com.openai.codex`), `restore` solo elimina el lanzador: no puede volver a abrir ninguna aplicación y termina con un error.
+
+<a id="rewrite-boundary"></a>
+
+## Alcance de la reescritura
+
+Solo se consideran las notificaciones `account/rateLimits/updated` y las respuestas cuyo resultado de nivel superior contiene `rateLimits`, `rateLimitsByLimitId` u `ordinaryUsageAllowed`. Se eliminan los marcadores simples `rate_limit_reached`. Los campos conocidos de bloqueo por cuota (`allowed`, `limit_reached` / `limitReached`, `ordinaryUsageAllowed`) solo pasan al estado permitido cuando hay evidencia de que el bloqueo se debe a la cuota general: se ha eliminado un marcador de ese tipo o una ventana de uso alcanza el 100%. Un campo bloqueado por un motivo que no aparece en los datos recibidos permanece bloqueado. Las restricciones del espacio de trabajo, los créditos, los tipos desconocidos de límite alcanzado y los controles de gasto mantienen cerrado el acceso por uso.
+
+El uso mostrado conserva los datos reales: porcentajes, fechas de restablecimiento, duración de las ventanas, información del plan y otros campos de presentación se mantienen como se recibieron. Los mensajes JSON-RPC ajenos a este caso, la salida anidada de herramientas, los metadatos que bloquean el envío de conversaciones y las líneas malformadas se transmiten sin cambios. Solo se vuelven a serializar las líneas modificadas; los demás bytes conservan su codificación y sus finales de línea originales. La entrada estándar, la salida de errores y el código de salida del binario real mantienen su conexión directa con la aplicación.
+
+<a id="executable-and-environment-security"></a>
+
+## Seguridad del ejecutable y del entorno
+
+El lanzador generado tiene permisos `0755` e incorpora la ruta del ejecutable actual de OpenCodex y, en instalaciones desde el código fuente, la ruta de entrada de la CLI. `CODEX_CLI_PATH` indica a ChatGPT que ejecute ese lanzador en lugar de iniciar directamente su binario incluido. Mantenga bajo su control el lanzador, su directorio de configuración y la instalación de OpenCodex: modificar esas rutas cambia el código que ejecuta la aplicación. El lanzador usa `exec` para ejecutar el binario incluido en el paquete detectado. Si ese paquete no contiene un binario app-server, `launch` rechaza la operación sin escribir el lanzador.
+
+Antes de escribirlo, `launch` comprueba también que el paquete y su binario app-server pertenezcan a usted o a root, que ni el grupo ni otros usuarios puedan modificarlos y que superen la verificación estricta de firma de código con el identificador de equipo de OpenAI (`2DC432GLL2`). Se rechaza cualquier paquete que incumpla una comprobación, incluido uno que pertenezca a otra cuenta. El lanzador se escribe primero en un archivo temporal y después se coloca en su destino mediante un cambio de nombre; un enlace simbólico existente en esa ruta se reemplaza, sin seguirlo.
+
+Antes de cerrar o abrir la aplicación, `restore` aplica las mismas comprobaciones de propiedad, permisos y firma al paquete y al ejecutable principal de la aplicación. Funciona con la opción experimental desactivada y sin un binario app-server incluido. Si falla la verificación de confianza o la reapertura, conserva el lanzador existente para permitir la recuperación.
+
+Ambos comandos comprueban también todos los directorios que contienen el paquete hasta la raíz del sistema de archivos. Rechazan directorios de otra cuenta, enlaces simbólicos y directorios superiores ordinarios que permitan escritura al grupo o a otros usuarios. Los directorios de instalación propiedad de root y del grupo de administradores, y los directorios de confianza con bit sticky, conservan su tratamiento habitual de permisos. Estas comprobaciones abarcan propiedad, permisos POSIX y firma; no se ha verificado el comportamiento de las ACL nativas ni de las políticas de propiedad de volúmenes.
+
+Esta integración no instala certificados, puertos de escucha de red, PAC ni procesos de vigilancia en segundo plano. No registra los mensajes ni el entorno de la aplicación. El estado informa si el proceso de ChatGPT en ejecución lleva la sustitución esperada del lanzador.
+
+Si falla la detección de la aplicación o la inspección de procesos, `status` informa `unknown` en lugar de `not running`. `launch` y `restore` se niegan a volver a abrir una aplicación si no pueden confirmar que haya terminado; en ese caso, la restauración conserva el lanzador. Resuelva el error de inspección y vuelva a intentarlo. `launch` comprueba el estado antes de escribir el lanzador, pero una inspección posterior puede fallar después de esa actualización atómica: los comandos no garantizan un reinicio íntegro o una reversión completa.
+
+<a id="failure-behavior-and-known-limits"></a>
+
+## Comportamiento ante fallos y límites conocidos
+
+El lanzador verifica el ejecutable antes de cada inicio, incluidos los reinicios automáticos de Desktop. Si el filtrado de la salida estándar no está disponible o falla su autoprueba, el ejecutable verificado se inicia con esa salida intacta. Si falla la verificación del ejecutable o no está disponible el validador de OpenCodex, el lanzador termina con un error sin iniciar app-server. La ausencia del binario app-server incluido también impide el inicio (véase más abajo). Si un filtro supera la autoprueba y después termina inesperadamente durante la sesión, cierra la tubería. No se ha verificado qué hace entonces app-server: podría recibir SIGPIPE o un error de escritura, y Desktop podría iniciarlo de nuevo mediante el mismo lanzador. El modo de paso directo del filtro limita este problema a su terminación o caída: una excepción de reescritura deja pasar esa línea sin cambios y un fallo inesperado transmite el resto del flujo como bytes sin procesar.
+
+El experimento depende de la ruta del binario incluido, de que la aplicación respete `CODEX_CLI_PATH` y de las estructuras RPC actuales. Una actualización puede cambiarlas. Mover o eliminar OpenCodex puede impedir que el lanzador verifique el ejecutable y provocar que rechace el inicio. Después de mover la instalación, ejecuta de nuevo `ocx chatgpt launch` o usa `ocx chatgpt restore` para eliminar la sustitución. Si una actualización mueve o elimina el propio binario app-server, el lanzador no puede iniciarlo: muestra en stderr un mensaje que indica `ocx chatgpt launch` y `ocx chatgpt restore`, termina y Desktop no puede iniciar su backend mediante esa sustitución. Restaura el lanzador o vuelve a generarlo para el paquete instalado. Una línea de salida que supere los 8 MiB se transmite sin analizar, en lugar de almacenarse en el búfer.
+
+Este shim independiente no reescribe los metadatos de conversaciones ni enruta solicitudes a modelos. Otros bloqueos de la aplicación o rechazos del proveedor pueden seguir impidiendo el envío. Que el lanzador esté conectado o que la autoprueba del filtro pase no demuestra que los datos de bloqueo de la aplicación atraviesen esa tubería.
+
+Las observaciones del informante en [#6196](https://github.com/lidge-jun/opencodex/issues/6196), del 2 y el 13 de octubre de 2026, describen un shim conectado con el botón Send todavía desactivado al agotarse la cuota de forma normal. Con Desktop 26.1007.30912 y OpenCodex 2.84.0, no observó mensajes RPC de límites de uso que pudieran reescribirse, mientras que el bloqueo de la interfaz usaba otro transporte de datos de uso. El shim no puede reescribir datos que nunca llegan a su filtro de salida estándar. Son informes específicos de esas compilaciones, sin una nueva verificación en vivo ni una prueba de que todas las versiones de Desktop usen el mismo transporte.
+
+El comportamiento pendiente del cuadro de redacción con una sesión iniciada sigue registrado en #6196. El éxito anterior con una configuración combinada de shim e intercepción no demuestra que el shim por sí solo sea suficiente. La intercepción de #6365 se cerró sin integrarse y no forma parte de una solución publicada.
diff --git a/docs-site/src/content/docs/es/guides/claude-code.md b/docs-site/src/content/docs/es/guides/claude-code.md
new file mode 100644
index 00000000000..9ceb03b9dae
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/claude-code.md
@@ -0,0 +1,837 @@
+---
+title: "Claude Code"
+description: "Usa cualquier modelo enrutado desde Claude Code: opencodex ofrece la API Anthropic Messages y el descubrimiento de modelos en el mismo puerto."
+---
+
+opencodex sirve `POST /v1/messages` (más `count_tokens`) junto con `/v1/responses`, por lo que Claude Code puede usar todos los proveedores enrutados: OAuth inicios de sesión, grupos de cuentas, conmutación por error de claves y sidecars incluidos, con cero trabajo de autenticación adicional.
+
+En las rutas de Devin (incluyendo SWE-2) alcanzadas a través de la Messages API, las llamadas de texto y herramientas esperan a que se complete el giro aguas arriba para que su firma de razonamiento tardío pueda preceder a la respuesta. Esto evita que el resultado final de Claude Code se vuelva vacío; el razonamiento y el progreso de mantenimiento aún fluyen durante la generación. La memoria intermedia comparte el límite de traducción de 32 MiB de la solicitud y la cancelación detiene al productor. Esta corrección de orden de salida no resuelve el rechazo separado de Cognition de algún texto del sistema generado. Conserva las instrucciones del sistema y las limitaciones de seguridad.
+
+Para una ruta Anthropic en OAuth almacenada o una clave Anthropic API, Fast nativo está disponible en
+`claude-fable-5-2`, `claude-opus-5-5`, `claude-opus-5`, y `claude-opus-4-8`: elige el modelo `--fast` fila (listado cuando las filas rápidas están habilitadas) o establecer `fastMode: true`. El propio Claude Code `/fast` toggle no es Traducido a petición: el `speed` El campo que envía no sobrevive a la traducción. El proxy envía la solicitud rápida de Anthropic y registra la `usage.speed`; sólo El uso rápido confirmado obtiene la estimación de costo equivalente a 2x API. Un rechazo reconocido y específico en la ruta de solicitud del adaptador principal obtiene un reenvío de velocidad estándar presupuestado, y un nuevo giro puede incurrir en que se negó viaje de ida y vuelta de nuevo. Las cuentas de suscripción Pro/Max necesitan créditos de uso; Las cuentas de equipo/empresa necesitan habilitación de organización, y las claves API necesitan aprovisionamiento acceso a la investigación-previsión. Véase
+[Anthropic Configuración rápida](/es/reference/configuration/providers/#anthropic-fast-anthropic-speed)
+para el modelo exacto y alcance de recuperación.
+
+<a id="tier-defaults-for-cli-and-external-launchers"></a>
+
+## Valores predeterminados de nivel para CLI y lanzadores externos
+
+En la pestaña Claude Code, seleccione un valor predeterminado de Opus, Sonnet, Haiku o Fable y **Guardar**. Estos `claudeCode.tierModels` valores predeterminados se pasan a los nuevos lanzamientos `ocx claude`. No cambian el modelo principal seleccionado actualmente, el esfuerzo de razonamiento o las asignaciones familiares de escritorio.
+
+Las aplicaciones que lanzan `claude` directamente no reciben el entorno del lanzador `ocx`. Después de guardar, seleccione **Previsualizar la configuración de Claude**, revise los cambios `ANTHROPIC_DEFAULT_*_MODEL`, luego **Aplicar a la configuración Claude**. Esto cambia la configuración del usuario Claude del host OpenCodex, no el equipo de un navegador remoto. Inicie un nuevo proceso Claude para usar los nuevos valores; la operación no detiene ni reinicia las sesiones existentes. No configura el enrutamiento o la autenticación, por lo que el llamante directo ya debe estar conectado al OpenCodex.
+
+Los alias de enrutamiento seleccionados se emparejan con etiquetas `ANTHROPIC_DEFAULT_*_MODEL_NAME`, utilizando los mismos nombres legibles que el selector de modelos. La vista previa incluye los ID y los cambios de etiqueta; el alias sigue siendo el ID del modelo enviado. Una etiqueta existente se administra solo si coincide exactamente con el nombre generado para su alias actual. Otras etiquetas, incluyendo valores vacíos, se conservan. Una etiqueta introducida manualmente idéntica a ese nombre generado es indistinguible de una etiqueta administrada.
+
+Solo se aplican los ID de nivel explícitamente seleccionados. Un nivel no establecido deja intacto su ID de modelo existente y su etiqueta de visualización. Reemplazar un alias con un ID de origen u otro no alias también elimina su etiqueta generada coincidente. La vista previa muestra la eliminación de etiquetas como un reemplazo vacío; las etiquetas personalizadas y las configuraciones no relacionadas permanecen intactas. Los archivos que faltan son compatibles, pero los archivos vacíos o corruptos existentes son rechazados. Los cambios desde la vista previa requieren una nueva vista previa. Aplique brevemente mueve el documento actual a un directorio privado `model-default-backups/apply-*/settings.json` bajo el directorio de configuración Claude, valida el documento capturado y luego publica exclusivamente. Nunca reemplaza el nuevo archivo de un escritor concurrente, incluso durante la reversión. Evite editar o iniciar Claude mientras aplica: otro lector puede ver el breve intervalo de archivo faltante. El sistema de archivos debe admitir movimientos del mismo volumen y enlaces duros; las operaciones no compatibles fallan sin sobrescribirlas. Después de una aplicación interrumpida o una restauración automática fallida, inspeccione esta ubicación de copia de seguridad y reconcilie las ediciones más recientes antes de restaurar. El comportamiento del sistema de archivos Windows / Linux debe verificarse por separado; una prueba local no es una prueba multiplataforma. Verifique el proveedor/modelo resuelto en los registros de solicitudes: la selección de un nivel no es prueba del modelo real servido. Esto es especialmente útil para los clasificadores externos que solicitan Sonnet.
+
+<a id="claude-oauth-account-pool-experimental"></a>
+
+## Claude Grupo de cuentas OAuth (experimental)
+
+El passthrough nativo de suscripciones Anthropic conserva las observaciones reconocidas y válidas de `anthropic-ratelimit-*`, con valores normalizados, en las respuestas en streaming, JSON y de error del proveedor. Omite los nombres desconocidos y los valores inválidos, y no inventa observaciones ausentes. Las pruebas verifican el contrato de encabezados que consumen los statusLine de Claude Code, incluidas las fracciones de uso y las horas de restablecimiento. La selección de cuenta y los reintentos no cambian.
+
+Las lecturas de uso admiten Ultra (antes Max 20x). Pro, Max 5x y Team conservan sus indicadores medidos de cinco horas y semanales, independientemente de cuál limite el uso en ese momento. Un límite de cinco horas null en Ultra no crea ese indicador, salvo que Anthropic marque como activo un límite finito de sesión. Los contadores actuales de `limits` prevalecen sobre los duplicados heredados; el uso compartido puede influir en el enrutamiento aunque el límite esté inactivo, mientras que los límites semanales de una familia de modelos solo afectan a esa familia cuando están activos.
+
+El dashboard muestra Pro, Max 5x o Ultra junto a las cuotas de las cuentas Claude, según los metadatos de suscripción del perfil autenticado. Tanto `ultra` como `claude_max_20x` se muestran como Ultra; se conservan los alias de nivel `ultra` y `max_20x`. Los niveles validados desconocidos conservan su nombre original sin hacer fallar la lectura de uso. Las filas de cuentas Claude usan etiquetas ordinales y omiten los identificadores de cuenta y los correos electrónicos.
+
+Puede iniciar sesión en varias cuentas Claude a través del panel Proveedores (`ocx login anthropic` / add-account). De forma predeterminada, cada solicitud utiliza solo la cuenta **activo**.
+
+El **grupo experimental de cuentas Claude**, de activación explícita (`anthropicAccountPool.enabled`), añade afinidad de sesión y selección de cuentas según el uso. No controla la recuperación ante un 429: si hay dos o más cuentas utilizables, una solicitud limitada puede pasar a otra aunque el grupo esté desactivado. Para excluir una cuenta de esa recuperación, ponla en pausa. En las sesiones **nuevas**, `anthropicAccountPool.strategy` selecciona entre las cuentas aptas: `quota` (predeterminado) conserva la cuenta activa hasta que el uso de la ventana elegida por `quotaWindow` (`five-hour` por defecto, o `weekly` / `max-utilization`) alcanza `autoSwitchThreshold` (80 por defecto). Entonces cambia a la cuenta de menor uso, con preferencia por las que sigan por debajo de su propio umbral; `round-robin` reparte las sesiones uniformemente (`stickyLimit`, por defecto `1`); `fill-first` mantiene la cuenta activa hasta que entre en enfriamiento, necesite reautenticarse o alcance el umbral, y después pasa a la siguiente. El grupo está **desactivado de forma predeterminada** y sigue siendo experimental.
+
+El panel de control enumera las condiciones para las que está destinado el grupo: suscripciones que posee o está autorizado a usar, el cliente genuino Claude Code y una persona que supervisa la sesión. Anthropic no ha respaldado la agrupación automatizada de cuentas, las cuentas de una organización pueden compartir una cuota (por lo que otra cuenta puede no agregar capacidad), y el cambio de cuentas no protege contra la aplicación del proveedor. OpenCodex no envía solicitudes de mantenimiento y, por defecto, no actualiza Claude tokens ni lee el uso en segundo plano: el uso se lee cuando el panel de control, la aplicación de la barra de menús o un comando `ocx` lo solicitan. Los umbrales son preferencias de selección, no límites de uso o facturación. Esta es la guía del producto, no el asesoramiento legal; consulte los términos actuales de Anthropic.
+
+Para vincular un modelo a cuentas Claude almacenadas en particular, agregue reglas `anthropicAccountPool.routes` ordenadas mientras el grupo está habilitado. Cada regla tiene un seguro `name`, un glob completo de `match` sensible a mayúsculas, una matriz `accounts` de ID de cuenta almacenados y un `fallback` opcional (por defecto `false`). La primera regla de coincidencia limita las selecciones activas, manuales, de afinidad, estrategia y 429 de recuperación a sus cuentas. Una afinidad saludable fuera de esa regla se ignora para esta solicitud, pero se mantiene para otros modelos; la opción enrutada no la sobrescribe. Sin reserva, una ruta vacía devuelve un 401 local, o 429 con `Retry-After` cuando todas sus cuentas declaradas se están enfriando, antes de contactar con Anthropic. La respuesta del cliente no nombra la ruta; el registro proxy registra `route:#<n>`, donde `n` es la posición basada en la regla 1. `fallback: true` usa el grupo ordinario solo cuando la ruta no tiene una cuenta elegible, incluida su orden sucesora de llenar primero; si sus cuentas almacenadas se están enfriando, el 429 devuelto usa el tiempo de reutilización más temprano en ese grupo expandido, incluso si se ha eliminado una cuenta de ruta guardada. Un modelo sin igual sigue la política de agrupación existente; la desactivación de la agrupación deja las reglas guardadas inactivas y restaura el comportamiento de 429 de cuenta activa y de presencia. Una regla es una lista de permisos del operador, no una prueba del derecho del modelo.
+
+Contrato operativo cuando está habilitado:
+
+- Upstream **429** enfría esa cuenta, borra sus afinidades y puede rotar a otra cuenta elegible dentro de la misma solicitud (limitada). El tiempo de reutilización utiliza un `Retry-After` utilizable cuando está presente, de lo contrario el último tiempo de reinicio válido entre las ventanas Anthropic marca `rejected`, incluidas las ventanas semanales. Los plazos iniciales válidos no se acortan a un límite de tiempo fijo. Un rechazo sin un plazo utilizable vuelve a un retroceso predeterminado de 60 segundos.
+- Responses reportan la utilización de 5 horas y semanal de la cuenta de servicio, y cualquiera de las dos que lleva la respuesta se registra para esa cuenta - cada ventana de forma independiente, y un rechazo cuenta, así como un éxito. La selección consciente del uso funciona desde el tráfico ordinario, sin esperar una encuesta del panel de control. Los encabezados conservan las ventanas de cuota específicas del modelo y no posponen las sondas de uso ni borran el estado no disponible de una sonda de uso fallida. Las mediciones cuyo tiempo de reinicio conocido ha pasado se descartan como desconocidas, incluidas las ventanas conservadas específicas del modelo. Los valores sin un restablecimiento conocido se conservan; los datos faltantes nunca se informan como uso cero.
+- La afinidad sobrevive al reinicio del proxy dentro del mismo directorio de configuración y la misma instancia del proveedor (caduca tras 24 horas de inactividad y conserva los 2000 vínculos más recientes). La instantánea privada almacena resúmenes de sesión y marcadores que delimitan cada inicio de sesión, nunca claves de sesión ni tokens en bruto. Las cuentas antiguas sin una identidad de inicio de sesión persistente conservan afinidad solo dentro del proceso hasta su próximo inicio de sesión. Renovar el token conserva la afinidad; sustituir el inicio de sesión, eliminar la cuenta, pausarla, exigir reautenticación o seleccionar explícitamente una cuenta en el entorno de ejecución la invalida. Un desvío por una limitación transitoria conserva el vínculo original incluso si su pausa vence antes de que se confirme el reintento.
+- Un derecho de cuenta o rechazo de facturación **403** completo y estructurado puede rotar antes de la salida. Los casos reconocidos incluyen acceso no Claude Code, una suscripción vencida / inactiva y un saldo de crédito insuficiente Anthropic. La cuenta rechazada pierde sus afinidades y se enfría durante `Retry-After`, o diez minutos sin una fecha límite. Permiso genérico, modelo/acceso a recursos, política y errores no reconocidos permanecen en el terminal. La recuperación respeta las rutas del modelo y los límites de envío; si no es elegible ningún reemplazo, se devuelve el 403 original. Esto también funciona con la agrupación proactiva. Un 403 después de la salida del asistente nunca cambia de cuenta.
+- Antes de la salida, un **401** authentication_error estructurado exacto sin código de error y el mensaje "OAuth token de acceso ha sido revocado." marca la cuenta de envío OAuth como que requiere un nuevo inicio de sesión y borra sus afinidades de sesión. Antes de la salida, una cuenta elegible en el mismo grupo puede asumir el control dentro de los límites de envío existentes. Sin reemplazo elegible, se devuelve el 401 original; la cuenta rechazada permanece excluida hasta el inicio de sesión. Otros errores 401 mantienen su comportamiento existente.
+- Las fallas de credenciales de actualización de token conservan la política `needsReauth` existente. La renovación de la suscripción no requiere una reautenticación, pero la cuenta espera a que expire su tiempo de reutilización.
+- Si cada cuenta elegible se está enfriando, el proxy devuelve **429** (no 401) con `Retry-After` cuando se conoce.
+- Recuperación, incluyendo 429 conmutación por error, utiliza `quotaWindow` para clasificar los reemplazos elegibles sin cambiar los límites de tiempo de reutilización o conmutación por error existentes; `round-robin` ignora `quotaWindow`.
+- `autoSwitchThreshold: 0` solo desactiva la conmutación basada en el uso **Proactivo**. La selección de nueva sesión y la recuperación de 429 aún consultan `quotaWindow`, por lo que la ventana es inerte solo por debajo de `round-robin`. `fill-first` evalúa su umbral de drenaje en la ventana seleccionada.
+
+Véase [Configuración](/es/reference/configuration/providers/#anthropicaccountpool-experimental).
+
+<a id="native-messages-with-account-pooling"></a>
+
+### Messages nativo con agrupación de cuentas
+
+El Messages nativo administrado muestra el esfuerzo validado de la persona que llama en Logs y `usage.jsonl`, incluyendo cada intento: un esfuerzo explícito como `xhigh` o `low`, `none` para el pensamiento desactivado o `budget:<tokens>` para un presupuesto de pensamiento habilitado. Un esfuerzo explícito tiene prioridad sobre el pensamiento alternativo. El pensamiento adaptativo sin un esfuerzo explícito permanece en blanco. Estas etiquetas describen los controles de solicitud; no confirman qué esfuerzo aplicó la corriente arriba o cambia el cuerpo del cable.
+
+Un grupo de cuentas Anthropic habilitado prefiere Messages nativo para rutas Anthropic directas elegibles cuando ninguna de las dos banderas de despliegue nativas desactiva explícitamente esa ruta. En los proveedores → Anthropic → Account pooling → **Cómo funciona la selección de cuentas**, **Preservar solicitudes nativas Claude** almacena `anthropicAccountPool.nativeMessages` (valor predeterminado true). Apagarlo selecciona el puente heredado para las solicitudes agrupadas. Con la agrupación desactivada, la configuración de implementación nativa explícita mantiene su comportamiento.
+
+`protocols.rollout.managedMessagesNative: false` explícito desactiva ambas rutas nativas; `managedMessagesNativeOAuth: false` desactiva OAuth nativo. Se ha cerrado la configuración actual no válida. La casilla de verificación muestra la preferencia guardada, por lo que una casilla de verificación habilitada no anula estos indicadores ni una ruta que requiera traducción de proxy. Las solicitudes nativas conservan los puntos de interrupción del historial/caché, la afinidad de la sesión, las rutas del modelo, las exclusiones de pausa/enfriamiento y la recuperación previa a la salida limitada.
+
+Las solicitudes nativas CLI y de código de escritorio reconocidas conservan su preámbulo de facturación/identidad y los encabezados beta de características compatibles. Las solicitudes generadas mantienen la forma de identidad SDK. Las herramientas personalizadas declaradas usan nombres consistentes en referencias diferidas y adiciones/eliminaciones en línea, mientras que los argumentos, esquemas y marcadores de caché permanecen sin cambios. Se rechazan las declaraciones ambiguas. Un conmutador de cuenta puede iniciar una caché en frío; esto no transfiere cachés ni garantiza accesos de caché. Para los cambios de herramientas en línea en los mensajes del sistema, envíe la versión beta `inline-tools-2026-09-15` requerida; el constructor nativo de origen la conserva con bloques tipados independientemente del reconocimiento del cliente. Véase [el contrato de herramienta en línea de Claude](https://platform.claude.com/docs/en/build-with-claude/mid-conversation-system-messages).
+
+<a id="quickstart"></a>
+
+## Inicio rápido
+
+```bash
+ocx claude
+```
+
+`ocx claude` asegura que el proxy se está ejecutando, luego inicia Claude Code con el entorno cableado:
+
+| Variable | Valor |
+| --- | --- |
+| `ANTHROPIC_BASE_URL` | `http://127.0.0.1:<port>` |
+| `ANTHROPIC_AUTH_TOKEN` | Solo cuando el proxy requiere una clave API; de lo contrario NO está configurado, por lo que su inicio de sesión claude.ai (suscripción + conectores) se mantiene activo |
+| `CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY` | `1` (descubrimiento de selector nativo `/model`) |
+| `CLAUDE_CODE_AUTO_COMPACT_WINDOW` | Umbral de compactación de contexto automático (predeterminado `829800`); solo se inyecta cuando el contexto automático está habilitado |
+| `ANTHROPIC_MODEL` | `claudeCode.model` (opcional) |
+| `ANTHROPIC_DEFAULT_HAIKU_MODEL` | `claudeCode.tierModels.haiku ?? claudeCode.smallFastModel` (opcional; legado) `ANTHROPIC_SMALL_FAST_MODEL` también) |
+| `ANTHROPIC_DEFAULT_{OPUS,SONNET,FABLE}_MODEL` | `claudeCode.tierModels.*`; en un lanzamiento de suscripción, una ranura no establecida obtiene el `claude-opus-5-5[1m]` / `claude-sonnet-5-5[1m]` / `claude-fable-5-1[1m]` nativo, por lo que `--model opus`, `sonnet` y `fable` mantienen su contexto de 1M |
+| `ANTHROPIC_DEFAULT_{OPUS,SONNET,FABLE,HAIKU}_MODEL_NAME` | La etiqueta `/model` para una ranura de nivel que OpenCodex establece en un alias encaminado, tal como `gpt-6.1-sol (native)` para `ocx-claude-native--gpt-6.1-sol`. Sin ella, Claude Code etiquetas que rema con el alias. El alias mantiene el ID de modelo seleccionado. Cuando el env del sistema está encendido, el entorno launchd y el gancho de la carcasa obtienen el mismo par de ranura y etiqueta. Una ranura o etiqueta que usted mismo establezca se deja sola |
+| `CLAUDE_CODE_ALWAYS_ENABLE_EFFORT` | `1` cuando `alwaysEnableEffort` está encendido (condicional) |
+| `ENABLE_TOOL_SEARCH` | `claudeCode.toolSearch` cuando está establecido (condicional; no se inyecta de forma predeterminada; se aplica el valor de Claude Code - ver [Los esquemas de herramientas MCP llenan el contexto](#troubleshooting) ) |
+| `CLAUDE_CODE_MAX_CONTEXT_TOKENS` | Anulación de contexto heredado cuando se establece `maxContextTokens` (condicional) |
+Las variables que tú mismo exportas siempre ganan. Los argumentos adicionales pasan por: `ocx claude -p "hello"`.
+
+Una excepción es que aproximadamente *donde* una variable viene de, no sobre la precedencia. El paquete Bun en entorno de ejecución carga automáticamente un proyecto `.env` / `.env.local`, por lo que un `ANTHROPIC_API_KEY` extraviado en el directorio desde el que se inicia solía parecer idéntico a una exportación deliberada, y deshabilitó silenciosamente una suscripción saludable a claude.ai a favor de la facturación API. `ocx claude` ahora ignora las credenciales Anthropic que solo un dotenv de proyecto introdujo. Un valor que exportó en su shell aún gana, en cada modo auth. Para usar una clave API deliberadamente, expórtela (`export ANTHROPIC_API_KEY=...`) en lugar de dejarla en un archivo de proyecto.
+
+<a id="native-fallback-when-claude-routing-is-off"></a>
+
+### Repliegue nativo cuando el enrutamiento Claude está desactivado
+
+`ocx claude` solía salir con un error cuando se deshabilitó el enrutamiento Claude. Ahora lanza el binario nativo `claude` en su lugar, por lo que el comando sigue siendo útil con el enrutamiento desactivado:
+
+| Donde el enrutamiento está desactivado | ¿Qué sucede? |
+| --- | --- |
+| `claudeCode.enabled: false` en configuración | Lanzamiento nativo, con un aviso de que el enrutamiento está desactivado |
+| El proxy en ejecución informa `enabled: false` desde `GET /api/claude-code` | Lanzamiento nativo; volver a habilitar la intercepción bajo demanda |
+| `claudeCode.enabled` ausente o `true` | Enrutado a través del proxy, sin cambios |
+
+Solo un `false` explícito desencadena la reserva, por lo que un proxy anterior al campo permanece enrutado. Un proxy que falta no es un disparador tampoco - con enrutamiento activado, `ocx claude` todavía inicia el proxy.
+
+Una sesión nativa no debe heredar el estado proxy, por lo que el respaldo elimina los valores que puede **probar**
+OpenCodex posee: `ANTHROPIC_BASE_URL` solo cuando apunta a la propia dirección de bucle de este proxy y puerto configurado *y* la admisión emparejada token es uno de los proxy emitidos; el
+`CLAUDE_CODE_*` palancas de descubrimiento y auto-contexto; y ranuras de modelo que solo se resuelven a través del Proxy (enrutado alias y `provider/model` ID). Cualquier otra cosa es tuya y se conserva — un sin relación `http://localhost:8080` puerta de enlace y su propio `sk-ant-` Ambas credenciales sobreviven.
+
+Si el valor predeterminado del selector `/model` guardado es un modelo solo de proxy, la sesión nativa vuelve a `claudeCode.model` cuando se puede usar de forma nativa y, de lo contrario, le advierte que pase `--model <Anthropic model>`. Un argumento explícito de `--model` siempre gana.
+
+<a id="auth-mode"></a>
+
+## Modo de autenticación
+
+Claude Code necesita un token en `ANTHROPIC_AUTH_TOKEN` para hablar con una puerta de enlace, pero al establecer esa variable también deshabilita su inicio de sesión claude.ai y sus conectores. ¿Cuál de los dos desea depende de algo opencodex puede mirar hacia arriba, por lo que por defecto lo hace.
+
+Deje **Modo de autenticación** en **Auto** (el valor predeterminado) en **Conectar → Claude** y opencodex decide en cada lanzamiento:
+
+| Lo que encuentra | Lo que hace |
+| --- | --- |
+| Un inicio de sesión Claude (cuenta `~/.claude.json` OAuth, `.credentials.json`, el llavero macOS o un `ANTHROPIC_API_KEY` exportado) | Deja el token sin configurar, por lo que su suscripción y los conectores siguen funcionando |
+| Ninguna autenticación de Claude | Inyecta un token de marcador de posición, por lo que Claude Code deja de pedirle que inicie sesión y rutas a través del proxy |
+| No puede decir (llavero ilegible, archivo corrupto) | Asume la suscripción e imprime una advertencia: nunca mueve a un suscriptor de pago al proxy en una lectura fallida |
+
+Esto se vuelve a calcular cada lanzamiento, no recordado, por lo que el inicio o salida se recoge en el siguiente `ocx claude` sin nada que reconfigurar.
+
+Elija **Suscripción** o **Proxy** explícitamente cuando lo desee. Una opción explícita se almacena en `claudeCode.authMode` y la detección nunca la anula, incluso después de iniciar sesión o salir más tarde. Vuelve a Auto para devolver la decisión.
+
+Un llavero de macOS bloqueado cuenta como «no puede decir». opencodex espera hasta 1,5 segundos a que el llavero responda, nunca cancela el aviso de desbloqueo, y un proxy en ejecución no vuelve a consultar el llavero durante 60 segundos después de que una consulta agote el tiempo, para que las actualizaciones del dashboard no acumulen avisos. Cada nuevo proceso `ocx claude` pregunta una vez por su cuenta. Con `authMode` establecido en proxy o subscription, el llavero no se consulta en absoluto.
+
+En macOS, la conexión automática (`claudeCode.systemEnv`) sigue la misma resolución, por lo que un `claude` simple lanzado fuera de `ocx` se comporta de la misma manera. Ese archivo es una instantánea actualizada cuando se inicia el proxy o se guarda la configuración, mientras que `ocx claude` siempre se resuelve en vivo.
+
+<a id="system-environment-integration-macos"></a>
+
+## Integración del entorno del sistema (macOS)
+
+<a id="claude-desktop-modes-gateway-default-and-first-party"></a>
+
+## Modos de escritorio de Claude: gateway (predeterminado) y first party
+
+Claude Desktop puede usar OpenCodex en uno de dos modos mutuamente excluyentes. Elija en **Conectar → Claude Desktop → Modo de conexión** en el tablero o con `ocx claude desktop apply
+--first-party|--gateway`.
+
+> Los perfiles de biblioteca de escritorio y `_meta.json` deben ser archivos regulares de como máximo 4 MiB. OpenCodex también rechaza el perfil generado o la salida de metadatos por encima de ese límite antes de reemplazar los archivos. Realice una copia de seguridad y reduzca manualmente la configuración de gran tamaño; un rechazo de tamaño no trunca los datos existentes. Las tiendas propiedad de la conexión mantienen sus límites más estrictos existentes.
+
+<a id="gateway-default"></a>
+
+### Puerta de enlace (predeterminado)
+
+Las nuevas instalaciones usan **gateway** de forma predeterminada. Su perfil de terceros, que se describe a continuación, cambia toda la aplicación a OpenCodex como su puerta de enlace de inferencia. El chat se ejecuta localmente a través de OpenCodex y las funciones solo claude.ai no están disponibles. Los indicadores heredados `--static` / `--hybrid` / `--discovery-only` también seleccionan la puerta de enlace.
+
+Los perfiles de pasarela usan distintos alias de modelo con un prefijo `claude-fable-5-` para que Claude Desktop 2.31226 pueda ofrecer su control de esfuerzo sin tratar cada modelo enrutado como el mismo modelo activo. Estos alias no cambian el modelo ascendente ni las etiquetas y los valores predeterminados de la familia que se muestran. Los alias anteriores siguen siendo decodificables para las sesiones existentes. Vuelva a aplicar el perfil de la puerta de enlace y salga / vuelva a abrir completamente el escritorio para cargar la nueva lista. El selector estático utiliza el menú de esfuerzo alternativo de Desktop; no anuncia una escalera autorizada por proveedor, y la normalización del esfuerzo normal del proveedor seleccionado aún se aplica. Este sigue siendo un mecanismo de compatibilidad específico de la versión del cliente.
+
+Gateway apply rechaza los archivos de configuración ilegibles o no regulares, incluidos los enlaces de metadatos colgantes, antes de crear un nuevo perfil. Si la actualización de metadatos falla, apply restaura el contenido anterior del perfil o elimina un perfil que acaba de crear, pero solo mientras el perfil aún contiene lo que se escribió; si otro programa lo cambió mientras tanto, apply mantiene esa versión y los informes "retroceder perfil omitido". Apply vuelve a comprobar el perfil antes de la copia de seguridad y el reemplazo; si detecta una edición concurrente, se niega con `desktop_profile_changed`. Revisar la edición y volver a aplicar. Si la restauración del perfil también falla después de un error de metadatos, la razón informada incluye ambos errores; reconcilia el perfil y los metadatos antes de volver a intentarlo.
+
+<a id="choose-which-models-claude-desktop-lists"></a>
+
+#### Elegir los modelos que muestra Claude Desktop
+
+**Conectar → Claude Desktop → Lista de modelos de Desktop** tiene una casilla por modelo. Busca por nombre o filtra por proveedor y usa **Seleccionar todas las coincidencias** o **Borrar todas las coincidencias** para cambiarlas todas, incluidas las filas de **Mostrar más**. Pulsa **Guardar y aplicar** para escribir la lista en Desktop. Solo cambia la lista de Claude Desktop: los ajustes de modelos del proveedor, Claude Code, Codex y los demás clientes conservan todos los modelos.
+
+**Modelos descubiertos recientemente** determina qué ocurre cuando un proveedor añade un modelo. **Mostrar automáticamente** lo añade a Desktop; **Mantener oculto hasta seleccionarlo** lo excluye hasta que marques su casilla. La selección se guarda en `claudeCode.desktopModelVisibility` y se conserva al actualizar o volver a aplicar el catálogo. Las familias por nivel de **Avanzado** siguen siendo opcionales y no determinan qué modelos se muestran. Un modelo oculto conserva su identificador de Desktop, por lo que una conversación que ya lo usa sigue funcionando.
+
+La tarjeta separa los recuentos de modelos seleccionados, disponibles y aplicados. Cuenta por separado los seleccionados que ya no están disponibles y no los escribe. Si la selección no deja ningún modelo disponible, el escritor utiliza todos los disponibles, incluidas las rutas normalmente ocultas; cambia la selección y aplícala de nuevo para limitarla. Antes de aplicar, la tarjeta muestra qué identificadores ganará y perderá el archivo de perfil seleccionado. El recuento aplicado lee ese archivo; no verifica qué modelos ha cargado el proceso de Desktop. El estado indica **Guardado: aplica los cambios para actualizar Desktop** hasta que la lista guardada llegue al perfil. Reinicia Desktop para cargar los cambios.
+
+Aplicar reemplaza la lista de modelos del perfil de Desktop de OpenCodex, incluida una lista editada a mano. El modo de solo descubrimiento (`--discovery-only`) no escribe ninguna lista y no usa esta selección. El dashboard no permite guardar una selección que oculte todos los modelos disponibles.
+
+<a id="first-party-opt-in"></a>
+
+### Primera parte (opcional)
+
+:::caution[Riesgo para la cuenta]
+El modo de primera parte envía su tráfico de suscripción Claude a través de un proxy de interceptación local. Anthropic puede tratar esto como una violación de sus términos y suspender la cuenta. Gateway es el default; elija la primera parte solo si acepta ese riesgo.
+:::
+
+El escritorio en sí no está reconfigurado: permanece conectado a claude.ai, y la pestaña Chat, los conectores, las sesiones en la nube y el control remoto siguen funcionando. OpenCodex solo escribe estas variables en el bloque `env` de `~/.claude/settings.json` (honrado por `CLAUDE_CONFIG_DIR`):
+
+```json
+{
+  "env": {
+    "HTTPS_PROXY": "http://opencodex:<per-install token>@127.0.0.1:10200",
+    "NODE_EXTRA_CA_CERTS": "<home>/.opencodex/claude-intercept/ca.pem",
+    "NO_PROXY": "127.0.0.1,localhost,::1,0.0.0.0"
+  }
+}
+```
+
+`NO_PROXY` mantiene el tráfico de bucle, como un servidor local HTTP MCP en `127.0.0.1`, `localhost`, un nombre `*.localhost`, `::1` o `0.0.0.0`, fuera del proxy, que solo tuneliza HTTPS a hosts remotos. Un servidor en otra dirección `127.x` necesita que esa dirección se agregue a `NO_PROXY` usted mismo. Si ya ha establecido `NO_PROXY`, OpenCodex agrega solo las entradas de bucle invertido que faltan y registra su cambio en `opencodex-no-proxy.json` junto a `settings.json`. Desactivar first-party devuelve su valor original cuando OpenCodex podría registrarlo y no lo ha cambiado desde entonces; de lo contrario, se mantiene el valor actual, incluidas las entradas agregadas.
+
+Claude Desktop first-party enruta su pestaña Código y subagentes a través de OpenCodex. El Claude Code CLI independiente tiene un interruptor de primera parte separado. Ambos clientes leen el mismo proxy `~/.claude/settings.json` y la configuración de CA: si solo un conmutador está encendido, el otro cliente aún transita el proxy local, donde termina TLS, pero sus solicitudes Messages retransmiten a Anthropic sin cambios. Otros Anthropic caminos retransmiten sin cambios y los anfitriones no relacionados siguen siendo túneles ciegos. Con el interruptor CLI encendido, el `claude` independiente también enumera los modelos enrutados en `/model`; ver [Selector de modelos en el CLI](#model-picker-in-the-cli).
+
+:::note[Proxy del sistema en Windows: Clash, v2rayN y proxies corporativos]
+Cuando la intent del selector está desactivada en el inicio de OpenCodex, su relé Windows permanece desatado. Selector de giro el modo en adelante lo inicia dentro del servicio en ejecución; OpenCodex no necesita un reinicio. Para instalaciones de selección o instalaciones pendientes sin perfil de selección aplicado, un proxy de sistema Windows se entrega a la pestaña Código como `HTTPS_PROXY`, y ese valor tiene prioridad sobre el proxy OpenCodex en `~/.claude/settings.json`. La pestaña Código entonces va alrededor de OpenCodex y los modelos enrutados fallan allí, mientras que el CLI independiente sigue funcionando. Un perfil de selector seleccionado aplicado utiliza el proxy de salida fijo de Desktop mientras está disponible, incluso cuando La falta de confianza deja al selector pendiente y `claude.ai` Retransmite a ciegas. Consejos de bypass del proxy del sistema Se aplica cuando no hay un perfil de selector disponible seleccionado. Añadir `api.anthropic.com` a la lista de bypass del sistema proxy de su cliente proxy (en Clash Verge,
+`system_proxy_bypass`), a continuación, cierre completamente y vuelva a abrir Claude Desktop. `ocx doctor` informa esto bajo "Claude Proxy de escritorio de primera parte vs Windows sistema". No puede evaluar un script PAC o detección automática de proxy (WPAD, "Detectar automáticamente la configuración"), por lo que informa de ellos como desconocidos; Con cualquiera de los dos, haz que el guión regrese `DIRECT` por `api.anthropic.com` o desactivar la detección. Si el La configuración de primera parte es obsoleta, te pide que ejecutes `ocx ensure` En lugar de informar `ok`.
+:::
+
+Los subagentes en los modelos enrutados (no Claude) no usan los hilos de mensajes del lado del servidor de Claude Code, porque solo Anthropic almacena ese estado. OpenCodex rechaza una solicitud roscada para tal modelo, y Claude Code reenvía ese giro, y los giros posteriores, con la conversación completa.
+
+El modo se mantiene como `claudeCode.desktopMode`. Las instalaciones que ya se aplicaban en cualquiera de los dos modos lo conservan, incluidas las instalaciones de origen desde antes de que persistiera el modo. Un modo explícito tiene prioridad; de lo contrario, una fila de pasarela seleccionada propia, una huella dactilar de pasarela aplicada o configuraciones propias de origen en `~/.claude/settings.json` determinan el modo existente antes del valor predeterminado de la pasarela. Una sincronización de catálogo o actualización de lista nunca escribe un perfil de puerta de enlace sobre una instalación de origen resuelta. Un entorno first-party solo de CLI no es evidencia de que Desktop esté en modo first-party. La conmutación primero aplica el reemplazo, luego elimina la configuración del otro modo (solo los valores OpenCodex escritos: un `HTTPS_PROXY` o `NODE_EXTRA_CA_CERTS` extranjero, por ejemplo, un proxy corporativo, nunca se sobrescribe y en su lugar se rechaza la aplicación). Un reemplazo fallido conserva la conexión anterior. Si la retirada de la configuración anterior falla después de escribir el reemplazo, el comando informa de una limpieza incompleta; resuelva ese error antes de reiniciar Desktop. Una configuración de pasarela ya aplicada mantiene su modo guardado y su marcador de perfil incluso cuando falla la limpieza de la configuración de primera parte. Cierre completamente y vuelva a abrir el escritorio después de un cambio exitoso. `ocx ensure` refresca un env obsoleto de primera parte cuando la integración está ACTIVADA y lo elimina cuando está DESACTIVADA. Establecer `claudeCode.intercept.enabled: false` para deshabilitar el proxy por completo; no se puede aplicar de primera parte. Se rechaza una solicitud de una instalación existente de origen cuando la intercepción está deshabilitada; las nuevas instalaciones aplican puerta de enlace. En un cliente conectado, el proxy se ejecuta en el concentrador, por lo que `ocx claude desktop apply` utiliza el perfil de puerta de enlace.
+
+<a id="picker-mode-opencodex-models-in-the-first-party-code-tab-picker"></a>
+
+### Modo de selector: modelos opencodex en el selector de pestaña de código de primera parte
+
+El modo Selector es parte del modo first party. En macOS y Windows está activado de forma predeterminada cuando se selecciona first-party, a menos que se establezca `claudeCode.intercept.picker: false`. Cambia el selector de pestañas de código de escritorio de primera parte para que enumere los modelos disponibles de opencodex por nombre. La primera vez que está habilitado, macOS puede pedirle que confíe en una autoridad de certificación local en el llavero de inicio de sesión, y Windows puede pedirle que confíe en el almacén raíz del usuario actual. Esa autoridad está limitada a `claude.ai` y sus subdominios. OpenCodex protege su identidad de firma exportable en el almacén de credenciales del sistema operativo y reutiliza el mismo certificado y clave validados en los reinicios normales. No se almacena ninguna clave de firma de selector de texto sin formato en el directorio de configuración OpenCodex. Todavía se aplican la validación de CA restringida completa y la verificación de confianza del sistema operativo, incluida la huella digital exacta con una hoja verificada en Windows. Con la misma identidad aprobada y un almacén de credenciales disponible, reiniciar OpenCodex no agrega ni elimina la configuración de confianza del certificado macOS. El reinicio y el estado nunca instalan confianza: si la confianza falta, se revoca o se desconoce, el selector permanece pendiente. Ejecute `ocx claude desktop picker on` o `ocx claude desktop picker trust` explícitamente para otorgar confianza, incluida la confirmación Windows cuando sea necesario. El inicio también intenta eliminar una clave de firma del selector en el disco antes de verificar si la interceptación está habilitada. La limpieza es el mejor esfuerzo y no permite la interceptación ni el bloqueo del inicio.
+
+La migración de una sola vez desde una identidad de selector anterior puede requerir el consentimiento para eliminar su confianza anterior. Si la limpieza no puede terminar, el selector permanece indisponible y el perfil aplicado utiliza un relé ciego hasta que la limpieza tenga éxito; `ocx claude desktop picker status` informa que el estado. macOS puede pedirle por separado que desbloquee el llavero o apruebe el acceso de una aplicación a las credenciales almacenadas. Estos mensajes de acceso nativos aún pueden ocurrir en el reinicio o la actualización. En Windows, `on` o `trust` explícito puede mostrar una confirmación para agregar la raíz.
+
+El modo Selector sigue sin soporte en Linux: OpenCodex no inicia ningún trabajo de CA, tienda de credenciales o proxy de selector allí. La intercepción principal Claude sigue estando disponible con la propiedad, enlace simbólico, permiso de archivo y Windows ACL comprueba la protección de sus archivos locales de CA.
+
+El modo Selector permite hasta 64 KiB de encabezados en las solicitudes entrantes y respuestas ordinarias HTTP, preservando las cookies de sesión del navegador. Los encabezados de respuesta ascendente más grandes devuelven 502 y registran `upstream:headers-too-large`, sin valores de cookies ni rutas de solicitud. Las conexiones actualizadas continúan retransmitiendo bytes directamente después del protocolo de enlace de solicitud.
+
+El modo Selector utiliza HTTP/2 con Claude Desktop, por lo que las transmisiones de chat de larga duración ya no utilizan las conexiones de Desktop a claude.ai. Las versiones anteriores podían dejar el chat atascado en "Sesión de carga cronometrada" mientras el modo selector estaba activado. Si el chat deja de cargarse con el modo selector activado, apáguelo con `ocx claude desktop picker off` e informe del problema.
+
+Mientras el modo selector está activado, Claude Desktop llega a la red a través de OpenCodex. Si OpenCodex se detiene, el Escritorio estará sin conexión hasta que lo reinicie completamente o desactive el modo de selección. Compruebe el estado con `ocx claude desktop picker status`; use `ocx claude desktop picker trust` para repetir el paso de confianza, o apáguelo con `ocx claude desktop picker off`. El tablero tiene el mismo interruptor de selección bajo **Conectar → Claude Desktop**. Después de seleccionar el perfil de selector, cierre completamente y vuelva a abrir Claude Desktop.
+
+El modo Selector es parte del modo de primera parte, por lo que el [Riesgo de cuenta de primera parte](#first-party-opt-in) también se aplica a él. El catálogo de escritorio y CLI reescribe los límites de fila y metadatos de uso compartido: si la adición de modelos enrutados supera un límite, OpenCodex devuelve el catálogo original de Anthropic sin cambios en lugar de publicar una lista parcial.
+
+Antes de recibir la primera respuesta del proveedor, una subida del selector que no avance durante 60 segundos se cierra sin una respuesta de éxito. En HTTP/2 solo se reinicia el stream afectado. El temporizador de inactividad se pausa si el proveedor aplica contrapresión y se elimina cuando termina la subida o llega la primera respuesta. No impone un límite a la duración total de la subida; siguen vigentes los límites del entorno de ejecución y del protocolo. Los streams de respuesta quedan fuera de este temporizador.
+
+<a id="use-opencodex-models-from-the-desktop-code-tab-first-party-bindings"></a>
+
+### Utilice los modelos opencodex en la token Código de escritorio (enlaces de origen)
+
+En el modo first-party, el selector de modelos de la pestaña Código pertenece a claude.ai: sus filas (Opus 5.5, Sonnet 5, Haiku 4.5 y los modelos anteriores bajo **Más modelos**) provienen de su cuenta, y ninguna configuración local puede agregar una fila opencodex. Lo que llega a OpenCodex es el identificador de modelo Anthropic del selector en cada solicitud, por lo que une una fila de selector a una ruta opencodex:
+
+```bash
+ocx claude desktop bind claude-sonnet-4-6 xai/grok-4.7
+ocx claude desktop bind claude-opus-4-6 native/gpt-6.1-sol
+ocx claude desktop unbind claude-opus-4-6
+```
+
+o utilice **Conectar → Claude Desktop → Fichas de código del modelo** en el panel de control. La selección de **Sonnet 4.6** en la pestaña Código es servida por `xai/grok-4.7`. El selector guarda la etiqueta Anthropic, y el modelo todavía se presenta como ese modelo Claude por el indicador del sistema Claude Code, así que prefiere filas que no use de otra manera (las entradas **Más modelos** son buenas candidatas). Los enlaces surten efecto en la siguiente solicitud; El escritorio no necesita un reinicio.
+
+- Las rutas usan el vocabulario de ruta de escritorio: `provider/model`, o `native/<slug>` para el grupo nativo OpenAI. Una ruta debe ser una de las listas del panel de control como disponible.
+- Un id de selector con fecha (`claude-haiku-4-5-20251001`) coincide con una vinculación sin fecha (`claude-haiku-4-5`), y `[1m]` y las selecciones de modo rápido siguen la misma vinculación.
+- Los enlaces se almacenan en `claudeCode.intercept.modelMap` y se aplican solo al tráfico Claude Code que llega a través del proxy de intercepción local: la pestaña Código del escritorio y el `claude` CLI independiente en modo first-party. `ocx claude` sesiones y el punto final público `/v1/messages` las ignoran; el `claudeCode.modelMap` global todavía se aplica en todas partes, y un enlace lo gana para el mismo id.
+- `ocx claude desktop status --json` informa de las vinculaciones vigentes en `firstParty.modelBindings`.
+
+<a id="claude-code-cli-first-party"></a>
+
+### Claude Code CLI de primera mano
+
+Encienda el interruptor CLI en Conecte → Claude, o ejecute `ocx claude config set --first-party on`; use `off` para deshabilitarlo. El interruptor es inmediato y rechaza `{enabled:false, cliFirstParty:true}` antes de que se guarde cualquier campo; también puede negarse a activarse si la intercepción local no está disponible, la CA no puede prepararse, la configuración no se puede leer o una configuración proxy extranjera posee las claves. Desactivar persiste incluso cuando la intercepción no está disponible; deshabilitar el enrutamiento Claude solo deja intacta una configuración propia env. Para el tráfico de terminal totalmente nativo con solo Desktop first-party activado, configure `NO_PROXY='*'` en el shell. Esto aún conlleva el riesgo de la cuenta de primera parte indicado anteriormente. Deshabilitar el enrutamiento Claude deja intactas las configuraciones de propiedad env. Mientras el oyente vinculado sigue ejecutándose, cada solicitud Messages se retransmite sin cambios; después de que se detiene, el `claude` simple no puede conectarse hasta que OpenCodex se ejecute o Desktop/ CLI sea desactivado. Nativo `ocx claude` establece `NO_PROXY=*` solo para un propietario env sin un extranjero heredado `HTTPS_PROXY` / `https_proxy`. Con un proxy externo, conserva ese valor y advierte que la intercepción propiedad de la configuración aún se aplica; desactiva o desactiva la configuración de Desktop/ CLI first party. La interfaz de usuario distingue la incertidumbre sobre si la configuración todavía apunta a su proxy (desconocido), un proxy opencodex que contiene tokens con una CA extranjera (extranjero: arreglar HTTPS_PROXY / NODE_EXTRA_CA_CERTS) y un proxy de bucle de retorno sin token al lado de una CA extranjera (local: la propiedad no está confirmada; quite HTTPS_PROXY si no se usa). Con ajustes aplicados coincidentes y un oyente vinculado pero con el enrutamiento desactivado Claude, desactivado significa que las solicitudes de retransmisión no se modifican mientras está vinculado; apague la primera parte para eliminar los ajustes. Una URL propia sin oyente se detiene; un oyente vinculado con una CA propia pero con puerto o token no coincidente se rompe incluso cuando el enrutamiento está desactivado. Con una intención en, detenido o roto, más pantallas de interceptación no elegibles routingOff: el enrutamiento de Claude o la interceptación están desactivados, o esta máquina es un cliente de otro concentrador opencodex; habilitar la interceptación en esta máquina o a su vez de primera parte para eliminar la configuración. Cuando se detenga la interceptación, utilice **Iniciar interceptación** o `ocx claude intercept start` para volver a intentar dentro del servicio OpenCodex en ejecución. Guardar la configuración de la primera parte también lo inicia automáticamente. Un rechazo informa de enrutamiento deshabilitado, rol de cliente, un puerto público efímero, un puerto ocupado o un fallo de inicio. Para un puerto ocupado, libérelo o configure `claudeCode.intercept.port`. El inicio actualiza un entorno proxy Claude administrado existente solo después de que el proxy de intercepción se enlaza correctamente, utilizando su puerto vinculado; un puerto ocupado deja la configuración Claude sin cambios. Si un par ya está enlazado en un puerto diferente, la respuesta nombra ambos puertos; use el puerto enlazado o restaure el valor configurado. CLI no se aplica intent sin proxy; una intención con un proxy en vivo recibe el aviso de retransmisión compartida; cualquier proxy restante sin ninguna intención es residual, a menos que desconocido, extranjero o local tenga prioridad.
+
+- descubrimiento de puerta de enlace (`/model` → "Desde la puerta de enlace") no se utiliza, porque Claude Code solo consulta
+  `GET /v1/models` en una pasarela configurada. Los modelos enrutados llegan al selector de otra manera; ver
+  [Selector de modelos en el CLI](#model-picker-in-the-cli). También puede enlazar un Anthropic incorporado id del modelo a una ruta (`ocx claude desktop bind`(arriba) o usar `modelMap`.
+- `ANTHROPIC_SMALL_FAST_MODEL` y `CLAUDE_CODE_SUBAGENT_MODEL` son elegidos por el CLI antes de que se envíe la solicitud. El `claude` de primera parte simple usa sus valores `settings.json`. Routed `ocx claude` también ofrece el [ajuste de fuerza subagente](#forced-claude-code-subagent-model) en la página Subagentes y a través del CLI.
+- `ocx claude` y first-party coexisten: una sesión iniciada con `ocx claude` habla con `ANTHROPIC_BASE_URL` (plain HTTP en loopback), que `HTTPS_PROXY` no cubre, por lo que el proceso llega a OpenCodex directamente y el proxy simplemente no ve tráfico desde él.
+- Claude Code honra a `HTTPS_PROXY` / `NODE_EXTRA_CA_CERTS` como se documenta para proxys corporativos; una versión CLI que deja de hacerlo dejaría de enrutar, no rompería el inicio de sesión.
+
+<a id="model-picker-in-the-cli"></a>
+
+#### Selector de modelos en el CLI
+
+Con el interruptor de primera parte CLI encendido y el enrutamiento Claude habilitado, inicie un nuevo `claude` y abra `/model`. Sus modelos opencodex aparecen junto a los modelos Claude de su cuenta, etiquetados como " Grok 4.7 (xai)" y descritos con su ruta ( `opencodex · xai/grok-4.7` ). Escoger uno dirige esa sesión al modelo, al igual que un enlace.
+
+- Solo las nuevas `claude` sesiones recogen la lista. Reinicie cualquier sesión que ya se estaba ejecutando cuando encendió o apagó el interruptor.
+- Claude Code guarda la lista durante aproximadamente una hora. Encender o apagar el interruptor, y `ocx ensure`, borrar esa copia guardada, por lo que el siguiente lanzamiento `claude` trae uno nuevo. Si faltan los modelos enrutados (el primer lanzamiento después de que se inicie OpenCodex puede fallarlos mientras los modelos aún se están descubriendo), ejecute `ocx ensure` y reinicie `claude`.
+- Las filas usan identificadores de estilo Claude (por ejemplo, `claude-opus-4-8-…`), porque el CLI solo ofrece identificadores con forma de modelos Claude. La pestaña Código de Claude Desktop no se ve afectada; sigue usando [Obligaciones de primera parte](#use-opencodex-models-from-the-desktop-code-tab-first-party-bindings).
+
+<a id="claude-desktop-profile-gateway-mode"></a>
+
+## Claude Perfil de escritorio (modo puerta de enlace)
+
+El perfil de abajo está escrito solo en modo gateway. Claude Desktop utiliza un perfil separado del Claude Code. Abra **Conectar → Claude Desktop** en el tablero de instrumentos. La tarjeta **Modelos** tiene las dos opciones que la mayoría de la gente necesita: **Modelo predeterminado** aparece primero en Claude Desktop y se envía como el nivel Opus, y **Modelo de tarea rápida** responde a las solicitudes de nivel Haiku de Desktop. Elegir un modelo allí lo traslada a esa familia y lo convierte en el valor predeterminado de la familia. Para colocar cada ruta usted mismo, abra **Avanzado: asignación de niveles Claude**, donde cada ruta disponible se encuentra en una de las cuatro familias: Opus, Fable, Sonnet o Haiku. Todas las rutas comienzan en Opus con un nuevo perfil. La primera ruta Opus se convierte en el valor predeterminado general inicial, y cada familia no vacía siempre tiene un valor predeterminado de familia.
+
+Arrastre una fila a otra familia si lo desea. El arrastre es opcional: cada fila también tiene un control de movimiento visible que funciona con un mouse, un toque o un teclado. Utilice **Hacer predeterminado** para elegir el valor predeterminado de una familia y, a continuación, seleccione **Guardar y aplicar al escritorio**. Se permiten familias vacías. Si un valor predeterminado guardado no está disponible temporalmente, se utiliza la primera ruta disponible de esa familia hasta que vuelva.
+
+También puede administrar el mismo perfil desde la línea de comandos:
+
+Las instrucciones de edición de perfil a continuación describen el perfil local. La aplicación remota conectada se describe por separado a continuación.
+
+```bash
+ocx claude desktop [apply]
+ocx claude desktop show [--json]
+ocx claude desktop status [--json]
+ocx claude desktop move <route> <opus|fable|sonnet|haiku> [--default]
+ocx claude desktop default <opus|fable|sonnet|haiku> <route|none>
+ocx claude desktop export <path|->
+ocx claude desktop import <path> [--apply]
+```
+
+`ocx claude desktop` y `apply` aplican el modo seleccionado: la primera parte escribe el env del proxy Claude Code, la pasarela escribe el perfil actual en Claude Desktop. `show` da un resumen legible; `status` informa sobre el modo efectivo, el perfil aplicado o proxy env, drift, actividad de solicitud y (solo en modo puerta de enlace) salud de la política administrada Windows. Añadir `--json` para scripts. `export -` escribe la versión JSON a la salida estándar. Import valida el archivo completo antes de guardarlo, por lo que un archivo no válido deja el perfil actual sin cambios. Agregue `--apply` para escribir un perfil importado válido en Desktop inmediatamente. Use `none` solo para una familia vacía; cada familia no vacía debe mantener una predeterminada.
+
+En Windows, una directiva Claude administrada por máquina puede hacer que Desktop ignore el perfil local de terceros. OpenCodex informa esto como `present`; una política que no puede leer es `unknown`, que también es una advertencia en lugar de un resultado limpio. El diagnóstico informa solo de ese estado: no expone nombres o datos de valores de directiva, y nunca elimina ni pasa por alto la directiva. Resuelva la directiva con su administrador y, a continuación, cierre completamente y vuelva a abrir Claude Desktop. La aplicación de nuevo también conserva las claves de perfil que OpenCodex no posee al actualizar sus campos de puerta de enlace y modelo.
+
+Aplicar escrituras a los datos de usuario de Electron reales `configLibrary` de Claude Desktop: `~/Library/Application
+Support/Claude/configLibrary` en macOS, `%APPDATA%\Claude\configLibrary` en Windows y `${XDG_CONFIG_HOME:-~/.config}/Claude/configLibrary` en Linux. Establezca `OPENCODEX_CLAUDE_DESKTOP_CONFIG_DIR` para una anulación de biblioteca explícita o `CLAUDE_USER_DATA_DIR` para una raíz de datos de usuario de escritorio alternativa. El directorio legacy `Claude-3p` no se lee ni se elimina automáticamente.
+
+Las rutas no Anthropic reciben alias estables como `claude-fable-5-p01q`, con un código de cuatro caracteres prefijado `p`. `claude-opus-4-8-p...` ID de perfil anteriores siguen siendo ID de compatibilidad de solo decodificación; los nuevos perfiles usan el formulario Fable. OpenCodex mantiene una ranura de fecha sintética separada internamente para que las asignaciones de perfil existentes se mantengan estables, pero no expone esa fecha como el ID de modelo de Desktop: Desktop actual construye fechas de terminal de tira al comparar modelos de sesión activa, lo que puede suprimir los cambios de modelo. Real Anthropic Claude rutas mantienen sus identificaciones reales. Las nuevas rutas son predeterminadas para la familia Opus, pero mover una ruta no cambia el proveedor o el modelo al que llama. Los indicadores de aplicación heredados `--static`, `--hybrid` y `--discovery-only` permanecen disponibles para scripts existentes.
+
+<a id="system-environment-integration"></a>
+
+## Integración del entorno del sistema
+
+Cuando `claudeCode.systemEnv` se establece en `true` (por defecto: **desactivado**), `ocx start` usa `launchctl setenv` para inyectar `ANTHROPIC_BASE_URL` y las variables de entorno relacionadas Claude Code en todo el sistema. Nuevas ventanas y pestañas de terminal, por lo tanto, encaminan comandos `claude` simples a través del proxy sin requerir la envoltura `ocx claude`. Las shells ya abiertas no se ven afectadas y deben reabrirse. El cambio de una ranura o palanca de modelo (`smallFastModel`, `tierModels`, `maxContextTokens`, auto-contexto, `autoCompactWindow`, `alwaysEnableEffort`) vuelve a aplicar la inyección de inmediato: una tecla opencodex inyectada anteriormente se actualiza, o se desactiva una vez que la configuración ya no la produce. Un valor que usted mismo establece con `launchctl setenv` antes de opencodex inyecta esa clave nunca se sobrescribe ni se elimina; una clave inyectada por opencodex sigue siendo propiedad de opencodex (se refresca, se desestablece y se elimina con `ocx stop`) incluso si cambia su valor a mano.
+
+`ocx stop` y el apagado del proxy **desactivan las claves inyectadas** (no restauran los valores anteriores: solo se eliminan las claves que inyectó opencodex). El proxy también escribe `~/.opencodex/claude-env.sh`; `ocx start` instala un enlace de carga en `.zshrc` que lo lee automáticamente solo cuando hay un ejecutable del CLI de Claude Code en `PATH`. El arranque y `ocx ensure` eliminan el enlace propiedad de OpenCodex cuando Claude Code no está presente o la integración del entorno del sistema está inactiva. Claude Desktop usa su perfil aparte y no provoca la instalación del enlace del shell.
+
+Deshabilitar con `claudeCode.systemEnv: false` en la configuración o con el conmutador GUI. Esta función es solo macOS; en otras plataformas, use `ocx claude`.
+
+<a id="native-claude-passthrough-subscription-pierce"></a>
+
+## Paso nativo Claude (perforación de suscripción)
+
+Sin ningún conjunto de anulación de autenticación, Claude Code mantiene su inicio de sesión claude.ai OAuth y lo envía al proxy. Las solicitudes de modelos genuinos `claude*` / `anthropic*` que no se reenvíen **verbatim** a `api.anthropic.com` con su credencial: betas, firmas pensantes, almacenamiento en caché rápido e identidad de facturación permanecen completamente nativas y los modelos enrutados siguen funcionando en la misma sesión a través de los alias del selector.
+
+**Manejo del encabezado:** encabezados salto por salto más `host`, `content-length`, `accept-encoding`, `x-opencodex-api-key` y `origin` siempre se eliminan antes del reenvío. En un enlace que no sea de bucle de retorno, el paso a través nativo también requiere una credencial proxy válida en `x-opencodex-api-key`; `Authorization` y `x-api-key` entonces pertenecen sólo a Anthropic. Se elimina un secreto de admisión de proxy que se encuentra en el encabezado de cualquiera de los proveedores, mientras que se conserva una credencial de proveedor genuina en el otro encabezado. Las cabeceras de credenciales unidas por comas ambiguas no se reenvían.
+
+El passthrough se activa cuando se cumplen todas estas condiciones: `nativePassthrough` no es `false`; el modelo comienza con `claude` o `anthropic`; el token portador o `x-api-key` comienza con `sk-ant-`; la resolución de alias/mapa de modelo devuelve el mismo modelo sin cambios; y, en un enlace que no es de loopback, el encabezado de admisión del proxy dedicado es válido. Esto también significa que la advertencia "los conectores claude.ai están desactivados" ya no aparece con `ocx claude`.
+
+El único cambio en el cuerpo son los identificadores de llamada a herramientas. Un `tool_use.id` o `tool_result.tool_use_id` que Anthropic rechazaría (caracteres fuera de `a-zA-Z0-9_-`, o de más de 64), como uno que un modelo enrutado creó antes en la sesión, se reescribe a un id válido conservando el emparejamiento entre llamada y resultado. Los identificadores válidos se envían sin cambios, y un identificador vacío se responde con un 400 local.
+
+Deshabilitar con `claudeCode.nativePassthrough: false`; punto en otro lugar con `claudeCode.anthropicBaseUrl`.
+
+<a id="claude-desktop-on-a-connected-remote-hub"></a>
+
+## Claude Desktop en un centro remoto conectado
+
+Cuando esta máquina está conectada a un concentrador, `ocx claude desktop apply` (o `ocx claude desktop` ) utiliza la instantánea del modelo de escritorio del concentrador. Escribe el origen del concentrador conectado y los ID de modelo emitidos por el concentrador en la configuración del escritorio local sin generar alias de reemplazo localmente. Los modos estático e híbrido copian las entradas de instantánea; el modo de solo descubrimiento usa el origen de concentrador sin incrustar la lista de modelos.
+
+El concentrador posee el perfil de escritorio, las asignaciones familiares y los valores predeterminados. Cambie esos en el concentrador, luego aplique nuevamente en el cliente conectado y vuelva a seleccionar el modelo en Desktop. Los alias antiguos creados solo en el cliente requieren volver a aplicar/reselección; no se migran automáticamente. Local `show`, las ediciones de perfil y la importación/exportación siguen siendo vistas y operaciones locales, no gestión de perfil de concentrador. Mientras está conectado, `ocx claude desktop import <path> --apply` no es compatible y rechaza la importación antes de guardar. La importación sin `--apply` sigue siendo local.
+
+Apply lee la instantánea utilizando la credencial de datos de la conexión existente. No necesita token de administración y no carga ningún perfil. Si el concentrador es demasiado antiguo para admitir la instantánea, la respuesta no es válida o no hay modelos de escritorio disponibles, se aplican errores sin sustituir un catálogo local o un origen de bucle de retorno. Actualizar/configurar el concentrador y volver a aplicar.
+
+Este cambio de alias no corrige la solicitud separada de reproducción y caché de mensajes `thinking` / `redacted_thinking` en [#3719](https://github.com/lidge-jun/opencodex/issues/3719). La admisión de proxy por sí sola no permite la transferencia nativa Anthropic; las rutas traducidas Anthropic aún pueden usar el almacenamiento en caché rápido. La fidelidad de reproducción y las comparaciones de caché siguen siendo un trabajo separado.
+
+<a id="key-rotation-recovery-and-disconnect"></a>
+
+### Rotación, recuperación y desconexión de llaves
+
+La rotación de claves y la recuperación actualizan la credencial almacenada en el perfil de Desktop propiedad de la conexión junto con la credencial de conexión local. No se requiere volver a aplicar el escritorio manual solo para migrar la clave. Se conservan los ID de modelo existentes, las opciones de familia/predeterminado y la selección de perfil actual del usuario; la rotación no vuelve a seleccionar el perfil administrado ni vuelve a habilitar una integración deshabilitada. CLI JSON `rotation: "committed"` significa que la nueva clave está activa. `rotation: "rolled_back"` significa que la clave anterior fue retenida o restaurada, no que una nueva clave fue comprometida o la clave anterior revocada. La recuperación incierta o incompleta se informa como tal, en lugar de como una rotación exitosa.
+
+La primera aplicación conectada registra los ajustes y la selección administrados anteriores para la restauración. La aplicación repetida y la rotación de la tecla conservan esa línea de base original. `ocx disconnect` restaura la configuración de propiedad de la conexión al tiempo que conserva los campos agregados por el usuario actuales y los perfiles no relacionados. La selección anterior se restaura solo si el perfil administrado sigue seleccionado; una selección de usuario válida posterior permanece seleccionada. Un perfil recién creado con adiciones de usuario se conserva en modo estándar legible en lugar de eliminar esas adiciones. `--keep-catalog` mantiene el catálogo, no la credencial de conexión de escritorio.
+
+Para un perfil administrado más antiguo sin un registro original, OpenCodex puede migrarlo cuando pertenece inequívocamente al concentrador actual y a una clave de conexión reconocida. Aplicar, rotación / recuperación o desconexión directa puede manejar este caso sin una nueva bandera o requisito previo volver a aplicar. Una advertencia explica que la desconexión utilizará el modo estándar porque no se registraron los ajustes anteriores. Esa reserva elimina solo la configuración de la puerta de enlace propiedad de la conexión, conserva los campos de usuario y una selección válida separada, y se informa como reserva estándar, no como restauración original.
+
+Los campos gestionados en conflicto, las credenciales no reconocidas o los registros de restauración dañados se conservan y se notifican para su resolución. La limpieza interrumpida puede reanudarse para la misma conexión; no borra una conexión más nueva o reclama la finalización mientras la restauración permanece incompleta. Termine la recuperación de rotación pendiente antes de iniciar la desconexión y conserve la misma opción de catálogo al volver a intentarlo.
+
+Cierre completamente y vuelva a abrir Claude Desktop después de aplicar, rotación / recuperación o restauración: el cambio de archivos no reemplaza una credencial que ya tiene la aplicación en ejecución. OpenCodex no mata/reinicia la aplicación automáticamente. Disconnect funciona localmente sin revocar automáticamente la clave de concentrador o borrar copias externas arbitrarias; revoque por separado en el concentrador si lo desea.
+
+<a id="the-model-picker-from-gateway"></a>
+
+## El selector /model ("Desde la puerta de enlace")
+
+Claude Code 2.1.129+ descubre modelos de puerta de enlace a través de `GET /v1/models?limit=1000` y los enumera en el selector nativo `/model`. Una fila sin un `description` dice "Desde la puerta de enlace"; opencodex envía uno por cada fila Claude Code CLI (`Routed by OpenCodex to <provider>/<model>`; las filas nativas usan `Routed by OpenCodex to native <model>`, las filas rápidas agregan ` · Fast` y las filas 1M mantienen la descripción base), que Claude Code muestra 2.1.257 + en su lugar. Claude Code 2.1.278 acepta un identificador de selector que contiene `claude` o `anthropic`. Un identificador no reconocido que comienza con `claude-` se contabiliza en 200k a menos que se desactive el compacto, por lo que opencodex expone los modelos enrutados como alias estables y reversibles que contienen `claude` pero no comienzan con `claude-`:
+
+| Superficie | Formato | Ejemplo |
+| --- | --- | --- |
+| Claude Code CLI | `ocx-claude-<provider>--<model>` (plano) o `ocx-claude2-…` (escapado) | `ocx-claude-native--gpt-5.6-sol` |
+| Claude Desktop 3P | `claude-fable-5-p<code>` (ranura de perfil de base36 3-char) | `claude-fable-5-p01q` |
+
+El proxy elige la familia por solicitud: `?ids=cli` o `?ids=desktop` gana; de lo contrario, el agente de usuario `claude-code/*` obtiene el formulario CLI legible y otros clientes obtienen el código de escritorio. Ambas familias decodifican para siempre: un modelo guardado en `settings.json` bajo cualquier forma sigue funcionando. Cada entrada lleva un nombre de visualización honesto como `gemini-3-pro (gemini)`, más capacidades de modelo completo (escalera de esfuerzo de razonamiento, tipos de pensamiento) en la forma oficial de ModelInfo para que el modo de puerta de enlace de terceros de Claude Desktop pueda ofrecer su selector de esfuerzo. Los modelos Real Anthropic mantienen sus identificaciones canónicas. La fecha 2026 sintética es una ranura interna, no una fecha de lanzamiento. Los alias hash heredados y los identificadores `claude-ocx-<provider>--<model>` / `claude-ocx2-<provider>--<model>` de configuraciones anteriores aún se resuelven. Una identificación heredada configurada en una ranura de modelo OpenCodex (`claudeCode.model`, `tierModels`, `smallFastModel`) se envía automáticamente a Claude Code en su ortografía actual. Un id legado guardado por el propio selector de Claude Code sigue las rutas, pero Claude Code mantiene sus 200k contabilizando ese id. Elija `ocx-claude-` para una identificación guardada de `claude-ocx-`, y `ocx-claude2-` para una identificación guardada de `claude-ocx2-` escapado, por lo que se aplican tanto la ventana de contexto de catálogo efectiva como la compacta.
+
+Los perfiles administrados más antiguos expusieron directamente sus ranuras internas `YYYYMMDD`. El escritorio afectado crea una tira de esa fecha de terminal al comparar modelos de sesión activa, por lo que dos rutas distintas pueden parecer idénticas y no se envía ninguna solicitud de control `set_model` ([#3782](https://github.com/lidge-jun/opencodex/issues/3782)). Los perfiles actuales exponen códigos no fechados en su lugar. Después de actualizar, vuelva a aplicar el perfil de escritorio y salga completamente y vuelva a abrir el escritorio; un trabajador que ya esté en ejecución aún puede conservar su antiguo ID en forma de fecha. El proxy continúa decodificando esos identificadores antiguos para la migración, pero no puede hacer que Desktop emita un switch suprimido.
+
+También puede intentar seleccionar el modelo predeterminado previsto en el perfil OpenCodex Claude Desktop, volver a aplicar el perfil e iniciar una nueva conversación. Este es un paso de solución de problemas, no una solución garantizada. OpenCodex no puede observar el estado del selector; enruta la identificación del modelo que lleva cada solicitud. Confirme lo que el cliente envía bajo **Logs → requestedModel**.
+
+Los modelos con una ventana de contexto larga (1M o, como mínimo, el umbral de compactación predeterminado de 829.800 tokens; los modelos Claude en una ruta Anthropic necesitan un 1M real) obtienen una fila adicional `…[1m]` en el selector. Seleccionarla hace que Claude Code contabilice un contexto completo de 1M para ese modelo, manteniendo la compactación automática; el proxy retira el marcador antes del enrutamiento.
+Los modelos nativos de OpenAI compatibles con Fast también obtienen una fila `…--fast[1m]`, con la etiqueta `· Fast · 1M`, cuando cumplen la misma regla de contexto largo. Esto combina el nivel Fast nativo con la contabilización de contexto largo de Claude Code; no aumenta el límite de entrada del proveedor de origen. La fila conserva el límite de entrada del modelo nativo y la política de compactación automática existente.
+La selección se guarda en el campo `model` de `settings.json` de Claude Code; las solicitudes entrantes resuelven el alias al modelo enrutado. En versiones anteriores de Claude Code, el selector permanece nativo: configura las ranuras mediante `ANTHROPIC_MODEL` o escribe cualquier identificador enrutado con `/model` (Claude Code transmite las cadenas tal cual).
+
+**Reglas de gramática de Alias:** proveedor no debe contener `/` o `--` o igual `native`. Los identificadores de los modelos simples (no `/` o `~` ) mantienen el prefijo v1 `ocx-claude-…`. Los identificadores de modelo que contienen `/` o `~` acuñan el prefijo v2 `ocx-claude2-…` con escapes (`/` → `~s`, `~` → `~t` ), p. ej. `openrouter/anthropic/claude-opus-4-8` → `ocx-claude2-openrouter--anthropic~sclaude-opus-4-8`. Los alias v1 decodifican literalmente (de modo que se conserva un identificador de modelo histórico que contenía las secuencias de dos caracteres `~s` / `~t`); los alias v2 expanden los escapes. Las rutas que el formulario legible no puede expresar vuelven al alias hash. Los identificadores del modelo PUEDEN contener `--` (las divisiones de resolución en el primer `--` solamente); las identificadores nativas que contienen `--` vuelven a la forma hash.
+
+**Orden de resolución del modelo:** `[1m]` marcador despojado → alias legible decodificado → Alias de hash de escritorio decodificado → `modelMap` coincidencia exacta → coincidencia de fecha desprovista (`-20250514` eliminado) → paso.
+
+<a id="desktop-alias-resolution"></a>
+
+Un ID de escritorio en forma de fecha no resuelto también puede ser un modelo nativo genuino que falta en el descubrimiento. Messages y count-tokens devuelven HTTP 503 con el error `desktop_model_mapping_unavailable` fijo cuando la evidencia disponible no puede resolver ese ID; esto no establece que el modelo no es válido. Los alias de hash heredados desconocidos todavía devuelven HTTP 400. Ninguno de los casos quita la fecha o vuelve a otra ruta. Los ID conocidos, las asignaciones registradas y las coincidencias exactas `modelMap` mantienen su comportamiento existente, incluidos los ID nativos reales reconocidos. Actualizar el descubrimiento del modelo o volver a aplicar el perfil del concentrador conectado antes de volver a intentarlo; reintentar solo no garantiza la resolución.
+
+Cada entrada lleva un nombre de pantalla como `gemini-3-pro (gemini)`, más capacidades de modelo completo (escalera de esfuerzo de razonamiento, tipos de pensamiento) en la forma oficial `ModelInfo`. Los modelos Real Anthropic mantienen sus identificaciones canónicas en ambas superficies.
+
+<a id="context-variant-1m-marker"></a>
+
+### Variante de contexto `[1m]` marcador
+
+Estas comprobaciones utilizan la ventana de catálogo efectiva, que puede incluir un [Estimación del proveedor personalizado](/es/reference/configuration/providers/#context-windows-on-custom-providers). Una estimación no verifica la capacidad real del relé.
+
+Los modelos con una ventana de contexto de catálogo efectiva de 1M, o al menos el umbral de compactación predeterminado de 829.800 tokens, obtienen una fila de selectores `…[1m]` adicional; el piso es fijo, por lo que un valor de compactación personalizado no lo baja, y los modelos Claude en una ruta Anthropic necesitan un 1M genuino. Desactivar el autocontexto limita la fila a ventanas de 1M. Seleccionarlo hace que la cuenta Claude Code sea un contexto completo de 1M. El proxy quita el sufijo `[1m]` insensible a mayúsculas y minúsculas antes de la resolución y el enrutamiento de alias.
+
+<a id="auto-context-big-context-models-without-the-200k-ceiling"></a>
+
+## Contexto automático (modelos de gran contexto sin techo de 200k)
+
+Claude Code cuentas 200k tokens para cualquier modelo que no reconozca. **Contexto automático** (activado por defecto) corrige que:
+
+1. Las ranuras env de lanzamiento obtienen el marcador `[1m]` cuando la ventana de catálogo efectiva del modelo está por encima de 200k **y** al menos el umbral autocompacto configurado. Las filas del selector Discovery y Desktop no siguen ese umbral: usan el piso fijo de 829.800 tokens (un 1M genuino para los modelos Claude en una ruta Anthropic).
+2. `CLAUDE_CODE_AUTO_COMPACT_WINDOW` (valor predeterminado `829800`, rango `100000` - `1000000`) se inyecta para que la conversación se resume automáticamente en ese punto.
+
+Tres estados de configuración:
+
+- **ausente / `true`:** habilitado (predeterminado)
+- **`false`:** desactivado - sin marcadores, sin inyección de ventana de compactación
+- **set legado `maxContextTokens`:** auto-contexto está implícitamente deshabilitado
+
+El valor de compactación es ajustable en la página Claude. **Aviso:** elevarlo más allá de la ventana real de un modelo rompe ese modelo: los errores de chat se eliminan antes de que el resumen pueda disparar.
+
+La ventana de contexto anunciada de un modelo no garantiza que una solicitud pesada de herramientas se ajuste al límite de entrada ascendente. Un rechazo de límite de entrada clasificado alcanza Claude Code como `invalid_request_error` con `context_length_exceeded`, redactado de la manera Anthropic palabras ( `prompt is too long: …` ), por lo que Claude Code compacta la conversación y vuelve a intentar por sí solo; una respuesta sin transmisión usa HTTP 400 en lugar de una 502 reintentable. Los proveedores en el carril nativo Messages tienen la misma redacción.
+
+La normalización de errores Messages usa mensajes fijos redactados por el proxy. Un rechazo reconocido por exceso de contexto devuelve `prompt is too long: The request exceeds the model's context window.` en lugar del texto o los recuentos del proveedor. Los errores de tasa de transferencia usan una frase fija distinta para límites de tasa.
+
+En los flujos Messages nativos y de reenvío de credenciales del cliente, solo se normalizan los bloques cuyo primer campo que no sea comentario sea exactamente `event:error` o `event: error`. El diagnóstico completo dentro del límite de retención de errores de 1 MiB determina la indicación de recuperación. Si supera ese límite, el flujo emite `The provider stream reported an error.` sin una indicación de compactación (OVERSIZE-1M) y conserva el estado HTTP ya enviado. Por separado, al convertir errores recopilados en una respuesta nativa sin streaming, se devuelve 502 donde antes un sobre de error sin tipo construido por el proxy devolvía 200 (FOLD-502). Consulta el [contrato de formato Messages](/es/reference/proxy-formats/#post-v1messages-and-count_tokens) para el orden de campos, la reproducción tras un cambio de evento y el alcance de ambas excepciones.
+
+Si la compactación en sí misma aún excede el límite, conserva el historial original e intenta compactar una bifurcación con menos herramientas habilitadas o esquemas MCP, si tu cliente admite ese flujo de trabajo. Un marcador `[1m]` o una configuración de contabilidad de cliente más grande no eleva el límite ascendente, y OpenCodex no elimina silenciosamente el historial o las herramientas para que encaje.
+
+Los modelos Anthropic nativos Sub-1M nunca se marcan automáticamente. Una ventana compacta que usted mismo exporta gana para el marcado de la ranura de lanzamiento (el proxy utiliza su valor para decidir qué modelos son seguros para marcar). Las filas de descubrimiento ignoran esa exportación y mantienen el piso fijo. Los valores de configuración no válidos editados manualmente vuelven a 829.800.
+
+<a id="context-accounting-1m-by-default-200k-opt-in"></a>
+
+### Contabilidad de contexto (1M por defecto, 200k opt-in)
+
+`claudeCode.contextAccounting` decide lo que opencodex escoge por defecto. Ausente (`1m`, el predeterminado), los modelos de ventana larga se ofrecen a 1M en las ranuras de env de lanzamiento, los selectores de escritorio, Desktop 3P (`prefer1m`) y subagentes generados. Configure `200k` para excluirse: nada se marca `[1m]` automáticamente, `CLAUDE_CODE_AUTO_COMPACT_WINDOW` no se inyecta y Desktop 3P cae `prefer1m` mientras mantiene `supports1m`. Un selector que usted mismo marca como `[1m]` permanece disponible (los subagentes generados y forzados aún dejan caer un marcador que la ventana del modelo no puede llevar), y el descubrimiento aún enumera las `· 1M` filas de modelos con ventanas de catálogo de al menos 1M. `200k` gana sobre el contexto automático: una ventana compacta que exporta ya no activa el marcado automático, aunque opencodex deja su propia exportación en su lugar.
+
+```bash
+ocx claude config set --context-accounting 200k
+```
+
+<a id="effective-model-environment"></a>
+
+### Entorno modelo eficaz
+
+`effectiveModelEnv` calcula seis ranuras inyectadas por `ocx claude` / system env / shell file:
+`ANTHROPIC_MODEL`, cuatro `ANTHROPIC_DEFAULT_{OPUS,SONNET,HAIKU,FABLE}_MODEL`, y legado
+`ANTHROPIC_SMALL_FAST_MODEL`. El haiku efectivo es `tierModels.haiku ?? smallFastModel`, alimentado a las dos variables del haiku.
+
+Cuando `ocx claude` se lanza en modo de suscripción, el propio inicio de sesión de Claude Code lleva una identificación desnuda de Claude como `claude-sonnet-5` directamente a Anthropic, por lo que esos id toman sus ventanas de contexto del registro del proveedor, lo que sea que otro proveedor enumere bajo la misma identificación. Una ranura Opus, Sonnet o Fable desactivada obtiene el identificador nativo Claude Code y resuelve ese alias, con el marcador `[1m]`, porque detrás de una puerta de enlace Claude Code cuenta con un identificador sin marcar en 200k. Una fila `anthropic` tapada por debajo de 1M o una entrada `claudeCode.modelMap` mantiene su identificación sin marcar, y el Haiku nunca se llena ni se marca. Cuando el lanzamiento utiliza autenticación proxy o `nativePassthrough` está desactivado, el enrutador decide, y solo cuenta la ventana de una fila enrutada. El env del sistema y el archivo de shell dejan espacios sin establecer vacíos, ya que sus valores también alcanzan lanzamientos que pasan por un concentrador.
+
+Cuando tanto `tierModels.haiku` como `smallFastModel` están ausentes, OpenCodex deja ambas variables auxiliares sin establecer; Claude Code luego elige su modelo de ayudante nativo (actualmente Sonnet), que puede incurrir en cargos de proveedor nativo.
+
+<a id="roster-agents-injectagents"></a>
+
+## Agentes de lista (injectAgents)
+
+Proxy inicio / asegurar, `ocx claude`, y el tablero de instrumentos relevante guarda sincronizar su lista de subagentes destacados (pestaña Subagentes, hasta 5 modelos) más `ocx-self` en `~/.claude/agents/ocx-*.md`.
+
+- **`ocx-self`** pines su `/model` selector predeterminado (regresando a `claudeCode.model`); omitido cuando ninguno existe. No utiliza la herencia modelo.
+- Cada cuerpo de agente contiene una directiva `<!-- ocx-route: <model> -->`: el proxy usa esto para fijar la ruta real. Por lo tanto, el argumento `model` de la herramienta Agente es inerte; pase `"haiku"` como marcador de posición.
+- Frontmatter lleva el alias; el enrutamiento es impulsado por directivas.
+- Solo los archivos `ocx-*.md` verificados con marcadores que contienen `generated-by: opencodex` se sobrescriben o podan; sus propios agentes nunca se tocan.
+- Los archivos se sincronizan atómicamente por archivo (escribir + renombrar).
+- `enabled: false` o `injectAgents: false` podan todas las definiciones de propiedad verificada.
+- Desactivar Claude Code con el interruptor de integración del dashboard también intenta eliminarlas de inmediato, para que una sesión nativa de `claude` iniciada después deje de ver agentes exclusivos del proxy. Los archivos que no se puedan borrar permanecen; si otra instancia de OpenCodex es propietaria de `~/.claude/agents`, no se modifica nada. Volver a desactivar reintenta la limpieza y también elimina definiciones que haya dejado una versión anterior.
+- El éxito CLI guarda de primera parte y persiste la configuración de primera parte del escritorio también intenta la sincronización de la lista de mejor esfuerzo, incluida la configuración repetida para reparar las definiciones que faltan. La configuración y la reversión rechazadas no sincronizan los agentes. Desactivar el registro de primera persona por sí solo no deshabilita el registro del agente.
+- Los cambios de GUI PUT y de lista se vuelven a sincronizar inmediatamente; cada inicio/garantía de proxy en primer plano o en segundo plano reconcilia los archivos de propiedad antes de que un lanzamiento posterior Claude Code los lea. Inicie una nueva sesión Claude después del registro para que cargue las definiciones generadas.
+
+Despacho: `subagent_type: "ocx-gpt-5-6-sol"`. Los objetivos con capacidad de 1M transportan automáticamente `[1m]`.
+
+<a id="bundled-skill-elision-blockedskills"></a>
+
+## Elisión de habilidades agrupadas (blockedSkills)
+
+La habilidad `claude-api` incluida en Claude Code inyecta ~840 KB (~136k tokens) de documentación de Anthropic que se activa automáticamente cuando se menciona un modelo de Claude. Los modelos enrutados no están entrenados en ese paquete, por lo que por defecto opencodex reemplaza el contenido de la habilidad con un stub corto en las solicitudes **enrutadas**. El passthrough nativo de Anthropic no se toca.
+
+**Se manejan dos transportistas:**
+
+1. **Portaherramientas de resultados:** asistente `Skill(...)` llama - el cuerpo `tool_result` emparejado se reemplaza por un stub cuando la entrada JSON de carcasa inferior contiene un nombre bloqueado.
+2. **Portador de bloque de texto:** un bloque de texto de usuario ≥ 10.000 caracteres a partir de `Base directory for this skill: ` - emparejado cuando el nombre base de directorio es igual a un nombre bloqueado (insensible a mayúsculas). La línea de directorio se inspecciona solo hasta 4.096 unidades de código UTF-16; una línea más larga se envía sin cambios, incluso cuando no tiene una nueva línea de terminación.
+
+Configurar con `claudeCode.blockedSkills` (por defecto `["claude-api"]`; `[]` deshabilita la elisión por completo). El stub mantiene intacto el emparejamiento de llamada/resultado de la herramienta.
+
+<a id="model-map-interception"></a>
+
+## Mapa de modelos (intercepción)
+
+`claudeCode.modelMap` reescribe los identificadores de modelo de entrada Anthropic antes del enrutamiento:
+
+```json
+{
+  "claudeCode": {
+    "modelMap": {
+      "claude-sonnet-4-5": "gemini/gemini-3-pro",
+      "claude-haiku-4-5": "gemini/gemini-3-flash"
+    }
+  }
+}
+```
+
+Orden de búsqueda: descubrimiento alias → id exacto → id con fecha sufijo despojado (`-20250514`) → passthrough.
+
+Véase [Resolución de alias de escritorio](#desktop-alias-resolution) para la política de rechazo.
+
+<a id="sidecar-matrix-web-search-and-image-understanding"></a>
+
+## Matriz Sidecar: búsqueda web y comprensión de imágenes
+
+Los modelos enrutados no todos tienen las mismas herramientas alojadas o soporte de imágenes. opencodex llena esos vacíos antes de que el modelo principal responda:
+
+- El **web-buscar sidecar** ejecuta la búsqueda alojada real, luego le da al modelo enrutado la respuesta y las fuentes como resultado de la herramienta.
+- El **visión sidecar** describe una imagen adjunta antes de llamar a un modelo listado en `noVisionModels`, luego reemplaza la imagen con esa descripción.
+
+Ambos sidecars pueden usar cualquiera de los dos backend:
+
+| Backend | Cómo funciona | Lo que se requiere |
+| --- | --- | --- |
+| `openai` | Un pequeño modelo GPT a través del proveedor ChatGPT `forward` | Un inicio de sesión ChatGPT y un proveedor habilitado `authMode: "forward"` |
+| `anthropic` | Claude a través de Anthropic OAuth almacenado; la búsqueda web utiliza `web_search_20250305` y la visión envía la imagen a Claude para su descripción | Un proveedor `adapter: "anthropic"`, `authMode: "oauth"` habilitado cuya cuenta activa almacenada no está marcada como `needsReauth` |
+
+Un `backend` explícito siempre gana. Cuando se omite, el sidecar **web-search** siempre selecciona `openai` (`anthropic` se ejecuta solo cuando se configura explícitamente), mientras que el sidecar **visión** selecciona `anthropic` si existe una cuenta Anthropic OAuth almacenada utilizable, de lo contrario `openai`. La selección explícita de `anthropic` sin una credencial utilizable **falla cerrado**: opencodex no toma prestadas silenciosamente credenciales ChatGPT ni cambia los backends. El backend OpenAI también se mantiene desactivado sin autorización de inicio de sesión y sin un proveedor de forward.
+
+Las repeticiones enrutadas de entrada de Claude adjuntan el inicio de sesión principal de ChatGPT a la solicitud interna, de modo que los sidecars de OpenAI siguen accesibles aunque el portador de entrada de Claude Code sea solo la credencial del proxy. Ese portador nunca se reenvía al proveedor principal enrutado.
+
+```json
+{
+  "webSearchSidecar": {
+    "backend": "anthropic",
+    "model": "claude-sonnet-5",
+    "maxSearchesPerTurn": 3
+  },
+  "visionSidecar": {
+    "backend": "anthropic",
+    "model": "claude-sonnet-5",
+    "maxDescriptionsPerTurn": 8
+  }
+}
+```
+
+`maxDescriptionsPerTurn` limita las nuevas descripciones de imágenes en un turno de modelo principal. Los hits de caché y las descripciones duplicadas en vuelo no consumen el límite. Las descripciones exitosas para las imágenes `data:` se almacenan en caché por backend, modelo, detalle, bytes de imagen y contexto de solicitud, por lo que el mismo par imagen-contexto no se describe de nuevo en cada repetición. Las imágenes remotas `https:` nunca se almacenan en caché porque su contenido puede cambiar.
+
+Consulte la [referencia de configuración](/es/reference/configuration/server/#sidecars) para conocer cada clave. La búsqueda web y la descripción de imágenes con OAuth de Anthropic reutilizan el precedente de huella dactilar OAuth de Claude Code que ya existe en el repositorio, pero aun así conviene probarlas en profundidad con su cuenta y su carga de trabajo antes de depender de ellas en ejecuciones largas y desatendidas.
+
+<!-- TODO(WP5 GUI): Add the sidecar settings-screen walkthrough after the GUI controls ship. -->
+
+<a id="client-tools-on-cursor-routes"></a>
+
+## Herramientas de cliente en rutas Cursor
+
+Cuando Claude Code utiliza un modelo respaldado por Cursor, OpenCodex conserva nombres de herramientas de clientes reconocidos como `Bash`, `Read`, `Write`, `Edit`, `Grep`, `Glob` y `Task` en el catálogo Cursor, la guía de herramientas y las llamadas reproducidas. Esto mantiene los nombres consistentes con las instrucciones de Claude Code. Los marcos de ejecución nativos de Cursor que se deniegan dirigen el modelo a las herramientas de cliente disponibles en ese turno.
+
+Un catálogo mixto que contiene un puente Codex `exec_command` o `shell_command` usa alias de cable como `ocx_client_Read` para evitar colisiones de herramientas Cursor; las llamadas devueltas a Claude Code todavía usan sus nombres de herramientas originales. Las herramientas Namespace MCP mantienen sus identidades namespace. OpenCodex incluye estos alias en el presupuesto de bytes de transporte de Cursor, por lo que se omite una herramienta cuya definición excedería el límite para ese turno.
+
+<a id="reasoning-effort"></a>
+
+## Esfuerzo de razonamiento
+
+En las solicitudes traducidas Messages → Responses, Claude Code `/effort` Configuración de mapas de la siguiente manera:
+
+| Formato de protocolo | Mapeo |
+| --- | --- |
+| `thinking.type: "adaptive"` + `output_config.effort` | Esfuerzo pasado directamente ( `minimal` `low` `medium` `high` `xhigh` `max` `ultra`) |
+| `thinking.type: "enabled"` + `budget_tokens` | ≤ 4096 → `low`, ≤ 16384 → `medium`, por encima de → `high` |
+| `thinking.type: "disabled"` | `reasoning: { effort: "none" }`; resumen omitido |
+
+Para las solicitudes traducidas, el nivel resuelto aparece en la columna **Esfuerzo de razonamiento** del registro de solicitudes. Gestionado nativo Messages registro habilitado pensamiento presupuestos como `budget:<tokens>` cuando no reconoce `output_config.effort` está presente; este registro no cambia el cuerpo del cable.
+
+<a id="inbound-translation-messages--responses"></a>
+
+## Traducción entrante (Messages → Responses)
+
+El proxy traduce cada solicitud Anthropic Messages API al formato Codex Responses API:
+
+| Messages entrada | Responses salida |
+| --- | --- |
+| Nivel superior `system` | `instructions` (bloques de texto unidos con `\n\n`) |
+| `messages[].role: "system"` | También doblado en `instructions` |
+| Texto / imagen del usuario | `input_text` / `input_image` (base64 → URL de datos) |
+| Texto del asistente | `output_text` |
+| Asistente `tool_use` | `function_call` ( `input` → `arguments` serializado como JSON ) |
+| Usuario `tool_result` | `function_call_output` (prefijo `is_error` → `[tool error]`) |
+| `tool_reference` en un resultado de herramienta | De forma predeterminada, texto `Tool loaded: <tool_name>` en el resultado emparejado. La [opción de carga añadida al historial](#preserve-cache-prefixes-when-client-tools-load) puede colocar una función diferida actualmente declarada junto al resultado exitoso de descubrimiento del cliente, si la ruta Responses final cumple los requisitos. Una referencia por sí sola nunca concede una herramienta ni habilita búsqueda del servidor. |
+| `thinking` / `redacted_thinking` repetición | `reasoning` artículos con `ocxr1` sobres limitados para firmas y cargas útiles redactadas |
+| Herramientas de función | `{type: "function"}` (`web_search*` → `{type: "web_search"}`). En una ruta a `api.anthropic.com`, las declaraciones `web_search_*` y `web_fetch_*` escritas también se envían a Anthropic como se declara y se ejecutan en el lado del servidor, a menos que el propio sidecar de búsqueda web suministre `web_search`. Una búsqueda o búsqueda con una llamada coincidente y entrada completa vuelve al cliente como su bloque `server_tool_use` y su bloque `web_search_tool_result` o `web_fetch_tool_result`, literalmente. Los resultados huérfanos se eliminan sin sintetizar una llamada, mientras que el texto circundante se conserva. Cuando el cliente envía un par completo en su historial, la siguiente solicitud `api.anthropic.com` lo lleva en su lugar solo si el siguiente bloque identifica de forma única su turno original. Anclajes repetidos, identificadores de llamada/resultado no coincidentes o duplicados, entrada de llamada malformada o un resultado que aparece antes de que su llamada caiga en el intercambio. La entrada de llamada debe ser un objeto con una consulta de búsqueda no vacía o una cadena de URL de búsqueda; otros destinos nunca ven el intercambio La búsqueda alojada con `allowed_domains`, `blocked_domains` o `user_location` se omite en rutas traducidas de Responses/Chat; forzarla devuelve 400. Las funciones válidas con `defer_loading` siguen siendo invocables como funciones ordinarias. Consulta las [limitaciones de traducción](#search-restrictions-and-deferred-tools-on-translated-routes). |
+| `tool_choice` | `auto` → `auto`, `none` → `none`, `any` → `required`, llamada función → `{type:"function",name}`, alojada WebSearch/ web_search → `{type:"web_search"}` |
+| `max_tokens` | `max_output_tokens` |
+| `stop_sequences` | `stop` |
+
+El modo automático Claude Code siempre envía `stop_sequences`. Para los modelos de la lista `noStopModels` del proveedor enrutado, OpenCodex omite `stop` en los cables Chat Completions y Responses, por lo que los modelos de razonamiento xAI como el grok-4.7 y el grok-4.6 no devuelven `400 invalid-argument` y se marcan temporalmente no disponibles. Véase [`noStopModels`](/es/reference/configuration/providers/).
+
+Replay conserva los bloques firmados no ocultos (incluido el pensamiento vacío) y los bloques redactados opacos en el adaptador Anthropic previsto. `hideThinkingSummary` permanece sin cambios: el texto firmado localmente oculto no está expuesto a Claude clientes, y la reproducción sin pérdida a través de ese límite oculto Claude no se establece. Los sobres de razonamiento combinados más antiguos no pueden recuperar el orden de bloque original una vez que se ha emitido el texto de transmisión. `claudeCode.compatibility: "enforce"` todavía rechaza la repetición del pensamiento. Esto no establece la aceptación de Anthropic en vivo ni las mejoras de caché. [#3719](https://github.com/lidge-jun/opencodex/issues/3719) permanece abierto.
+
+**Casos de error (400):** malformado JSON; faltante/vacío `model`; faltante/vacío `messages`; papel no soportado; `tool_result` sin `tool_use_id`; `tool_use` sin id/name; nombrado `tool_choice` sin nombre.
+
+<a id="search-restrictions-and-deferred-tools-on-translated-routes"></a>
+
+### Restricciones de búsqueda y herramientas diferidas en rutas traducidas
+
+Cuando una herramienta `web_search*` incluye `allowed_domains`, `blocked_domains` o `user_location`, OpenCodex omite la búsqueda alojada del catálogo traducido de Responses/Chat, incluidos el fallback de combos y los sidecars de búsqueda. Esos destinos no pueden conservar las restricciones de manera uniforme, por lo que nunca se amplía la búsqueda silenciosamente. Las declaraciones de búsqueda duplicadas no evitan la regla. Forzar una búsqueda alojada sin ninguna declaración restante devuelve HTTP 400. Los destinos directos de Anthropic siguen recibiendo las declaraciones tipadas originales por la ruta existente de herramientas del servidor cuando se traduce la solicitud; el paso directo nativo las conserva directamente. La búsqueda traducida sin restricciones mantiene sus reglas actuales de sidecar y admisión.
+
+Las definiciones de función válidas con `defer_loading: true` siguen siendo invocables como funciones ordinarias en rutas de combos traducidas. Cargarlas de forma anticipada no produce por sí mismo un rechazo de compatibilidad. El modo de aplicación estricta sigue rechazando la postergación de nivel superior no compatible, las herramientas diferidas sin esquema, el descubrimiento ejecutado en el servidor y el historial de descubrimiento no admitido. Las rutas directas de Responses que cumplan los requisitos pueden usar la [opción de solo adición](#preserve-cache-prefixes-when-client-tools-load).
+
+<a id="unicode-property-patterns-in-tool-schemas"></a>
+
+### Patrones de propiedad Unicode en esquemas de herramientas
+
+Un esquema JSON `pattern` escrito para JavaScript puede usar escapes de propiedad Unicode como `\p{Cc}` o `\P{L}`. Los backends de la familia OpenAI validan `pattern` compilándolo con el módulo `re` de Python, que no admite esos escapes, y un esquema que no pueden compilar se rechaza entero, por lo que un solo patrón de este tipo en una herramienta incorporada falla cada solicitud en la sesión, no solo llamadas a esa herramienta.
+
+Para mantener funcionando los parámetros ordinarios de Artifact, las rutas de adaptador `openai-chat` y `openai-responses` omiten las restricciones escalares `pattern` que contienen escapes de propiedad Unicode en posiciones de esquema positivas ordinarias. Restricciones de hermanos, `required`, datos literales y regexes soportados permanecen. Una implementación de herramienta debe validar sus propias entradas porque este proxy no aplica una restricción omitida.
+
+`patternProperties` emparejadores y sus esquemas de valor permanecen sin cambios. La eliminación de un emparejador puede cambiar qué claves son evaluadas por el `unevaluatedProperties` de un antepasado, por lo que la apertura local no es suficiente para demostrar una transformación segura. Los patrones bajo `not`, `oneOf`, `if`, `contains`, `$defs` y `definitions` también permanecen sin cambios: relajar esos subárboles puede cambiar la negación, la selección de ramas, el recuento de coincidencias o el significado de una referencia.
+
+El destino valida estos esquemas conservados. Un destino compatible con ECMA puede usar el regex original; un destino que no puede compilarlo puede rechazar el esquema. OpenCodex no reemplaza silenciosamente ese contrato con uno que prohíbe argumentos previamente válidos.
+
+Esta es la normalización en la ruta del adaptador seleccionado, no una garantía para todo el proveedor. La configuración y autenticación del proveedor no se tocan, y un proveedor en un adaptador diferente no se ve afectado.
+
+Es una medida de compatibilidad, no una afirmación de que cada backend personalizado compatible con OpenAI rechaza estos patrones. Vale la pena saber lo que cuesta: una regla omitida no se conserva en ninguna parte y no se aplica en sentido ascendente, por lo que una implementación de herramienta debe validar sus propias entradas en lugar de confiar en el esquema para rechazar un argumento mal formado.
+
+<a id="outbound-translation-responses--messages-sse"></a>
+
+## Traducción saliente (Responses → Messages SSE)
+
+| Responses evento | Messages SSE |
+| --- | --- |
+| `response.created` | `message_start` + `ping` |
+| Latido del corazón | `ping` |
+| Texto deltas | `content_block_start` → `content_block_delta` (texto) → `content_block_stop` |
+| Razonamiento resumen/texto | `thinking` bloque con la firma reproducida, o un sobre de reserva limitado `ocxr1` |
+| Razonamiento redactado | `redacted_thinking` bloques reproducidos desde el sobre de razonamiento |
+| Marcos de llamada de función | Bloque `tool_use` con `input_json_delta` |
+| Evento terminal | `message_delta` → `message_stop` |
+| EOF antes del terminal | 502-estilo `api_error` |
+
+**Detener el mapeo de la razón:** `completed` → `tool_use` (si se llama alguna herramienta) o `end_turn`; `incomplete/max_output_tokens` → `max_tokens` `incomplete/content_filter` → `refusal`.
+
+**Taxonomía de error:** 400 `invalid_request_error`, 401 `authentication_error`, 402 `billing_error`, 403 `permission_error`, 404 `not_found_error`, 409 `conflict_error`, 413 `request_too_large`, 429 `rate_limit_error`, 504 `timeout_error`, 529 `overloaded_error`, otros 5xx `api_error`. El encabezado `Retry-After` se envía como segundos enteros (una fecha HTTP se convierte en los segundos restantes), con un máximo de ocho días.
+
+<a id="prompt-caching-and-token-usage"></a>
+
+## Uso rápido de caché y token
+
+**Solicitudes enrutadas a Anthropic:** el adaptador administra puntos de interrupción de la caché para herramientas, contenido del sistema y el penúltimo mensaje de usuario, además de `cache_control` automático de nivel superior. Los giros estables normalmente producen una tasa de éxito de caché del 99.9%.
+
+**Enrutamiento nativo OpenAI / ChatGPT:** deriva un encabezado `prompt_cache_key` de alcance de sesión (de `metadata.user_id` cuando está presente, volviendo a un hash de contenido de sistema) y `session_id` para afinidad de caché. La clave de caché incluye esquemas de modelo y herramientas completas.
+
+La salida **Matemáticas de token:** Anthropic resta `cached_tokens` y `cache_write_tokens` de `input_tokens`, exponiéndolos como `cache_read_input_tokens` y `cache_creation_input_tokens`. Los registros de solicitud mapean esos de vuelta al `inputTokens` inclusivo, con lecturas tanto en `cachedInputTokens` como en `cacheReadInputTokens`, escribe en `cacheCreationInputTokens`. La página Uso informa de los hits de caché y la creación de caché por separado.
+
+**count_tokens:** modelos enrutados utilizan una aproximación (sistema serializado + mensajes + herramientas). Los modelos nativos Anthropic con una credencial `sk-ant-` pasan la solicitud al punto final real Anthropic `/v1/messages/count_tokens`.
+
+<a id="debug-capture"></a>
+
+## Captura de depuración
+
+`ocx debug claude on|off|status|reset`, `OCX_CLAUDE_DEBUG=1` o `PUT /api/debug {"claude": true}` controlan la captura entrante. `GET /api/claude/inbound-debug` devuelve `{enabled, entries}` (el más nuevo primero, anillo de 20).
+
+Cada entrada registra: `at`, `endpoint`, `model`, `resolvedModel`, `stream`, `maxTokens`, `thinkingType`, `thinkingBudgetTokens`, `outputConfigEffort`, `metadataKeys`, `hasMetadataUserId`, `hasSystem`, `anthropicBeta` en bruto y etiquetas de igualdad HMAC de ocho caracteres para el identificador de usuario / sistema. **No se almacena ningún texto de solicitud, objeto sin procesar o hash de ejecución cruzada estable.** La desactivación de la depuración Claude limpia inmediatamente el anillo.
+
+<a id="gui-claude-page"></a>
+
+## GUI (página Claude)
+
+Abra **Conectar → Claude** para la configuración de una página Claude Code. La página muestra estos controles y secciones en orden:
+
+1. Interruptor **Claude Code CLI primera parte**
+2. **Empezar** con `ocx claude` y el bloque de entorno manual
+3. **Generalidades** con compatibilidad, instrucciones del agente, modo rápido y controles de contexto
+4. **Modelo de ayudante de fondo** selector
+5. **Interceptación modelo** editor
+6. **Modelos disponibles**, la vista previa en vivo de Claude Code `/model` alias de selector
+7. Interruptor **Claude conexión**, también disponible en la tarjeta Claude en la vista general de Connect
+
+La barra de guardado pegajosa muestra **Sin cambios** cuando la configuración guardada coincide con la página, o **Cambios no guardados** después de editarlos. **Revertir** descarta ediciones no guardadas; **Guardar** confirma la configuración editable. Los interruptores **Claude conexión** y **Claude Code CLI primera parte** se aplican inmediatamente. **Guardar** nunca cambia ninguno de los interruptores.
+
+**Claude Desktop** es una pestaña separada bajo **Conectar**. Su selector **Modo de conexión** ofrece gateway (predeterminado) o first-party, con el puerto proxy en ejecución en modo first-party. Solo **Guardar y aplicar** cambia los modos; **Guardar** solo almacena los carriles de perfil de pasarela para una pasarela posterior aplicada y deja el modo actual como está.
+
+`GET /api/claude-code` devuelve los valores predeterminados efectivos, la configuración, el registro de ventanas de contexto, el env efectivo, los identificadores de ruta disponibles, los alias y el puerto. `PUT /api/claude-code` es parcial y conserva los campos omitidos; `null` restablece los valores de contexto/lista de bloques/ventana compacta.
+
+<a id="troubleshooting"></a>
+
+## Solución de problemas
+
+### Desktop en Windows informa de `client_lifecycle_lock_failed` al aplicar
+
+Actualiza OpenCodex si aplicar la configuración de Desktop se bloquea cuando hay muchos archivos de
+bloqueo antiguos. La adquisición del bloqueo de ciclo de vida ahora verifica si el directorio de
+ejecución ya es privado antes de repetir los cambios de permisos. Sigue rechazando la aplicación
+si falla el endurecimiento de permisos requerido. Conserva los archivos de bloqueo existentes;
+eliminarlos mientras hay clientes en ejecución puede romper la coordinación entre procesos.
+
+**Claude Code dice "Hizo 0 búsquedas"** - Las compilaciones actuales traducen los elementos completados Responses `web_search_call` en bloques emparejados Anthropic `server_tool_use` y `web_search_tool_result`, incluido `usage.server_tool_use.web_search_requests`. Actualización opencodex si una compilación anterior completó la búsqueda, pero Claude Code todavía contaba cero.
+
+**Un sidecar no se activa** - Para `backend: "openai"`, confirme que ha iniciado sesión en ChatGPT y que tiene un proveedor `authMode: "forward"` habilitado. Para `backend: "anthropic"`, confirme que la cuenta Anthropic OAuth almacenada activa no está marcada como `needsReauth`. Una selección Anthropic explícita sin esa credencial falla intencionalmente.
+
+**"Los conectores claude.ai están deshabilitados"** - Un `ANTHROPIC_API_KEY` o `ANTHROPIC_AUTH_TOKEN` se establece en su cáscara. `ocx claude` deliberadamente NO establece `ANTHROPIC_API_KEY`; si lo tiene exportado, elimina esa variable del entorno. `ocx claude` inyecta `ANTHROPIC_BASE_URL`, descubrimiento, auto-contexto y ranuras de modelo configuradas, pero nunca `ANTHROPIC_API_KEY`.
+
+**Modelos que no aparecen en /modelo selector** - Verificar que `CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1` está configurado (automático con `ocx claude`). Ejecute `ocx claude` para actualizar la caché del modelo de puerta de enlace en `~/.claude/cache/gateway-models.json`. Compruebe `claudeCode.enabled` no es `false`.
+
+**Entorno estanco después del cambio de puerto** - Si el puerto proxy ha cambiado, los shells antiguos pueden tener un `ANTHROPIC_BASE_URL` obsoleto. Abra una nueva terminal o vuelva a ejecutar `ocx claude`.
+
+**techo de contexto 200k a pesar de gran modelo** - Seleccione la variante `[1m]` en el selector, o active el contexto automático (activado de forma predeterminada). Si el selector no muestra la fila `[1m]`, la ventana de contexto de catálogo efectiva del modelo puede estar por debajo del piso fijo de 829.800 tokens.
+
+**Alto recuento de tokens de cargas de habilidad** - La habilidad `claude-api` incluida (tokens de -136k) se carga automáticamente en Claude menciones del modelo. Esto es normal para passthrough nativo; en los modelos enrutados, opencodex stubs por defecto (`blockedSkills: ["claude-api"]`).
+
+**Los esquemas de herramientas MCP llenan el contexto en la primera curva** - Claude Code convierte MCP herramienta de aplazamiento cuando `ANTHROPIC_BASE_URL` no es un host Anthropic de primera parte. La comprobación está en el host, no en el modelo, por lo que se aplica a cada sesión `ocx claude`: con muchos conectores configurados, cada esquema de herramienta está alineado antes de escribir nada. Vuelva a habilitar el aplazamiento con:
+
+```json
+{ "claudeCode": { "toolSearch": true } }
+```
+
+`ocx claude` solo inyecta `ENABLE_TOOL_SEARCH` cuando `claudeCode.toolSearch` tiene un valor activador. Sin ajuste se aplica el predeterminado del cliente; `toolSearch: false` no inyecta nada ni lo desactiva. En Chat traducido, cada carga de ToolSearch cambia catálogo y mensaje de sistema y puede reducir el uso de caché. Consulta abajo la diferencia entre versiones y las opciones para un prefijo estable.
+
+El **passthrough nativo de Anthropic** conserva la búsqueda de herramientas del servidor: el cliente envía las definiciones diferidas y Anthropic las mantiene fuera del contexto hasta descubrirlas. La ruta traducida predeterminada no implementa esa herramienta de servidor: elimina su declaración tipada y normalmente incluye todas las funciones desde el principio, por lo que el cliente puede subestimar la entrada real del proveedor.
+
+Hay una excepción independiente y limitada para **`ToolSearch` ejecutado por el cliente**, en un destino Responses verificado seleccionado mediante [`claudeCode.appendOnlyToolLoadingModels`](#preserve-cache-prefixes-when-client-tools-load). En esa ruta física final, la opción excluye del catálogo inicial las definiciones diferidas aún sin usar y añade las actuales en los resultados estructurados de descubrimiento exitosos. La búsqueda del cliente debe funcionar ya y debe declararse una función `ToolSearch` sin carga diferida. El ajuste del lanzador `toolSearch` puede activar el descubrimiento donde el cliente lo admite, pero no activa por sí solo esa opción ni implementa búsqueda del servidor. Verifica la combinación de cliente y pasarela antes de activarla; mantenla desactivada en otras rutas de terceros. La admisión que exige compatibilidad no cambia y todavía puede rechazar solicitudes de carga diferida no admitidas. Ninguna de las dos opciones garantiza aciertos de caché ni paridad completa con la búsqueda nativa.
+
+Los valores aceptados siguen el propio analizador de Claude Code: `true`, `"auto"`, `"auto:N"` (N al menos 100) y `"force"`. Un valor que usted mismo exporta siempre gana sobre el inyectado.
+
+**Subagente envía al modelo equivocado** — Lista de agentes (`ocx-*`) uso `<!-- ocx-route: ... -->`
+directivas, no la herramienta del agente `model` argumento. Asegúrese de que la directiva coincida con el ruta. Pase `"haiku"` como modelo de referencia.
+
+Establecer `claudeCode.stabilizePromptCache` a `true` en `config.json` a Claude arnés de aviso de seguimiento de las instrucciones del sistema en las rutas traducidas. Se han retirado `<total_tokens>N tokens left</total_tokens>` pies reconocidos, incluidos los pies repetidos. Los recordatorios de TaskCreate aún se mueven a un mensaje de usuario final; si solo se pelaron los pies de token, no se agrega ningún mensaje de entrada. El valor predeterminado es `false`. Habilítelo solo cuando este cambio de rol sea apropiado para sus clientes. Conserva ejemplos cercados y texto sin igual; el passthrough nativo Anthropic no cambia. La clave prompt-cache sin metadatos sigue instrucciones estabilizadas. Esto no crea una identidad de conversación ni garantiza accesos de caché ascendentes.
+
+En cada ruta de chat traducida, los recordatorios de línea de tiempo mantienen su posición en la conversación, después de cualquier resultado de herramienta pendiente. Esto evita que un recordatorio recién agregado reescriba el indicador principal del sistema, y evita que una instrucción de conversación intermedia llegue antes de los giros que se escribió a seguir. El papel que lleva la ranura se decide por separado: un recordatorio se envía como `system` a menos que el proveedor registre `foldDeveloperRoleToSystem: false`, que establece que el flujo ascendente acepta el papel `developer` y lo reenvía en la misma posición. Un flujo arriba que no lo acepta responde `400 role 'developer' is not allowed` y el giro nunca comienza, por lo que un destino no registrado se pliega. Esto se aplica con o sin `stabilizePromptCache`, y el paso a través de Anthropic nativo no cambia. La reutilización de caché todavía requiere una identidad de sesión estable y disponibilidad de caché ascendente. Los cambios en las instrucciones o herramientas anteriores, y la compactación de la conversación, aún pueden afectar los golpes de caché; preservar el orden del recordatorio por sí solo no garantiza la reutilización.
+
+<a id="preserve-cache-prefixes-when-client-tools-load"></a>
+
+### Conservar el prefijo de caché al cargar herramientas del cliente
+
+En una **ruta directa de Responses cuyo destino se haya verificado que admite `additional_tools`**, una opción explícita puede conservar el historial de carga de ToolSearch del cliente, en lugar de añadir cada función descubierta al catálogo inicial:
+
+```json
+{
+  "claudeCode": {
+    "appendOnlyToolLoadingModels": ["my-gateway/gpt-example"]
+  }
+}
+```
+
+Los selectores coinciden con nombres `provider/model` resueltos, no con alias del selector. Un único comodín final, como `my-gateway/gpt-*`, selecciona una familia verificada; no se acepta el comodín global `*`. La lista está desactivada de forma predeterminada y admite hasta 128 entradas de 512 caracteres cada una. Solo se reescribe la solicitud saliente si su ruta física final es un proveedor Responses directo. El destino se comprueba de nuevo al vincular el adaptador después de un fallback o reemplazo tardío de subagentes: seleccionar la ruta original no autoriza otro destino. El catálogo original sigue disponible para los demás intentos. Las solicitudes de combo o política conservan ese catálogo incluso si están seleccionadas, porque sus destinos alternativos pueden no respetar la ubicación cronológica de las herramientas.
+
+El endpoint Responses de OpenCode Go y los hosts oficiales de xAI Responses conservan el catálogo completo aunque estén seleccionados. Esos destinos aplanan o rechazan `additional_tools` y no pueden mantener el prefijo de carga cronológico. Mantén desactivada esta opción en cualquier otra pasarela que eleve los descubrimientos al arreglo `tools` inicial.
+
+La optimización requiere un valor de texto en `metadata.user_id` y una función `ToolSearch` declarada sin carga diferida. Las definiciones diferidas que aún no se usan se excluyen del catálogo inicial tanto antes como después del descubrimiento. Un resultado estructurado y exitoso de ToolSearch incorpora en esa posición las definiciones que siguen declaradas. El texto de una referencia nunca concede herramientas ni restaura definiciones revocadas. Las herramientas usadas antes de descubrirse y las herramientas no descubiertas cuya selección se fuerza explícitamente permanecen en el catálogo inicial. Se conservan los esquemas, su carácter estricto y la asociación entre llamadas y resultados. Si faltan metadatos, la configuración está ausente o vacía, o se usa passthrough nativo de Anthropic, se mantiene el comportamiento existente. Una configuración mal formada se rechaza al guardarla; la recuperación durante la carga solo desactiva esta opción, sin descartar los proveedores.
+
+Esto no implementa la búsqueda diferida del lado del servidor, no cambia la admisión que exige compatibilidad ni activa la búsqueda de herramientas del cliente. Se aplica cuando el cliente ya realiza el descubrimiento. Tampoco garantiza aciertos de caché: los cambios de esquema, revocaciones, cambios de modelo, compactaciones y disponibilidad de caché del proveedor todavía pueden exigir un prefijo nuevo.
+
+<a id="chat-routes"></a>
+
+#### Rutas Chat
+
+Chat Completions carece de `additional_tools`. En rutas directas verificadas con los modelos usados, esta opción conserva el catálogo y sistema al cargar herramientas:
+
+```json
+{
+  "claudeCode": {
+    "chatToolDispatchModels": ["deepseek/deepseek-flash"]
+  }
+}
+```
+
+Se aplican los selectores, límites, metadatos y requisito de ToolSearch inmediato de `appendOnlyToolLoadingModels`, así como sus reglas para combos, políticas y alternativas tardías, sobre una ruta física `openai-chat` directa:
+
+- El catálogo añade `use_loaded_tool` desde la primera solicitud y omite las herramientas diferidas aún no usadas; cargarlas no cambia catálogo ni sistema.
+- Nombre, descripción y esquema descubierto se añaden como texto al resultado de ToolSearch. El modelo usa `use_loaded_tool` con `{"name": ..., "arguments": {...}}`; las llamadas previas se reproducen así.
+- Cada llamada bien formada se convierte al nombre real antes de que llegue a Claude Code. Una herramienta declarada se ejecuta normalmente y una desconocida produce error bajo su nombre. Una envoltura inválida o con claves extra llega intacta y falla como herramienta desconocida.
+
+Los esquemas como texto carecen de validación estricta del proveedor y un argumento inválido consume un turno. Algunos modelos no siguen instrucciones en resultados de herramientas: verifica cada uno. Forzar una herramienta oculta, restringir las permitidas o un historial ambiguo conserva la solicitud original. Llamar a una herramienta diferida sin cargarla la devuelve al catálogo y pierde el prefijo una vez. Ausente, vacía o sin coincidencia conserva los mismos bytes, sin garantizar aciertos de caché. Los argumentos llegan cuando se completa la llamada, como en cualquier herramienta Chat traducida.
+
+
+<a id="claude-models-behind-a-gateway-that-also-serves-gpt"></a>
+
+#### Modelos Claude detrás de una pasarela que también ofrece GPT
+
+`appendOnlyToolLoadingModels` no resuelve este problema para modelos Claude enrutados mediante una pasarela Responses. La pasarela puede volver a colocar `additional_tools` en el arreglo inicial `tools` de Claude. Como Claude almacena las herramientas en caché antes del prompt de sistema, la solicitud que carga una herramienta sigue perdiendo la coincidencia. Si una pasarela con autenticación por clave también ofrece Anthropic Messages, envía Claude de forma nativa y conserva Responses para los demás modelos mediante `modelAdapters`:
+
+```json
+{
+  "protocols": { "rollout": { "managedMessagesNative": true } },
+  "providers": {
+    "my-gateway": {
+      "adapter": "anthropic",
+      "modelAdapters": { "gpt-example": "openai-responses" }
+    }
+  }
+}
+```
+
+Incluye en `modelAdapters` todos los modelos del proveedor que no sean Claude: los que no estén en la lista se enviarán como Messages. Messages nativo mantiene en su posición las definiciones diferidas de Claude Code y los resultados `tool_reference`; cargar una herramienta amplía el prefijo de caché en lugar de sustituirlo. `claudeCode.stabilizePromptCache` no se aplica ni hace falta en esa ruta; sigue ayudando a las solicitudes Claude que pasan por el puente. Los combos, las políticas, los esfuerzos fijados, las filas sintéticas, el sidecar de búsqueda web y el preprocesamiento de visión mantienen las solicitudes en el puente, como detalla [la configuración de despliegue](/es/guides/protocol-paths/#rollout-switches). Los proveedores compatibles de terceros no reciben los valores `anthropic-beta` del cliente, por lo que la pasarela debe aceptar estas solicitudes sin ellos.
+
+<a id="intercept-token-recovery"></a>
+
+### Interceptar la recuperación de token
+
+El proxy autenticado en ejecución valida el token actual para cada nueva solicitud CONNECT. Una aplicación explícita de primera parte recrea un token faltante y actualiza la configuración de propiedad sin requerir un reinicio proxy; los túneles existentes no se revocan. Los archivos no válidos, vinculados, de gran tamaño o no token se rechazan en lugar de sobrescribirse. Inspeccione dicha entrada antes de eliminar solo el archivo de token obsoleto confirmado y vuelva a aplicar el modo de primera parte; nunca elimine su destino de enlace.
+
+<a id="first-party-picker-context-markers"></a>
+
+### Marcadores de contexto de selector de primera parte
+
+El selector de pestañas de código de escritorio agrega `[1m]` a modelos enrutados cuya ventana de contexto de catálogo efectiva es de al menos un millón de tokens o al menos el umbral de compactación predeterminado de 829.800 tokens (por ejemplo, un modelo nativo GPT-6 elegido en su ventana 872k), por lo que Claude usa su contabilidad 1M en lugar del modelo personalizado más pequeño. Los modelos Claude en una ruta Anthropic todavía necesitan un genuino 1M. Las etiquetas, el orden del perfil y las rutas del proveedor se mantienen sin cambios. Las ventanas desconocidas y más cortas permanecen sin marcar. El selector no puede garantizar que un corredor de escritorio o remoto reciba el entorno de compactación correspondiente, por lo que un modelo de ventana larga que supere su ventana real obtiene un error `prompt is too long`, que Claude Code responde compactando. El escritorio 3P `supports1m` / `prefer1m` y los subagentes generados siguen la misma regla. La configuración de contexto automático emparejado para `ocx claude` no cambia. Una conversación existente mantiene su selector guardado hasta que vuelva a seleccionar el modelo en el selector actualizado.
+
+<a id="forced-claude-code-subagent-model"></a>
+
+### Modelo de subagente forzado Claude Code
+
+La página Subagentes ofrece **Forzar un modelo para todos los subagentes**, una opción **desactivada de forma predeterminada**. Selecciona un identificador disponible en la lista, como `combo/tev-auto`, y después activa la opción. Primero se ofrece la lista de modelos; las entradas guardadas que ya no estén disponibles no se pueden usar como destino forzado.
+
+`ocx agent subagents force combo/tev-auto` conjuntos `claudeCode.subagentModelForce`; `ocx agent subagents force -` lo aclara. `ocx agent status` informa de la configuración. `GET /api/subagent-models` devuelve `force`, `forceAvailable` y `forceStatus`; `PUT` acepta `{ "force": "combo/tev-auto" }` o `{ "force": null }` sin cambiar la lista. Omitir `force` lo deja sin cambios. Los objetivos inválidos o no expuestos son rechazados en la escritura; los objetivos obsoletos son reportados y omitidos en el lanzamiento.
+
+Esto tiene efecto en el **siguiente inicio enrutado de `ocx claude`**, inyectando `CLAUDE_CODE_SUBAGENT_MODEL` como un alias proxy explícito (con `[1m]` cuando la ventana de catálogo efectiva alcanza el piso fijo de 829.800 tokens, y solo para una ventana genuina de 1 M en los modelos Anthropic Claude y selectores desnudos `claude-*`; los objetivos nativos Claude usan un alias nativo reversible) y `CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1`. Cada variable no vacía exportada por el shell gana independientemente. Los lanzamientos nativos no inyectan ninguna variable; el `claude` simple no se ve afectado. No hay archivos de plugin o `settings.json` son modificados por esta configuración.
+
+Claude Code **2.1.257 o más reciente** es necesario para la fuerza. Los argumentos de modelo de complemento y agentes incorporados (incluyendo Explorar/Planear) y por llamada se anulan. Las bifurcaciones y las habilidades de subagente con `model: inherit` mantienen el modelo de conversación principal. El bucle principal y los sidecars de pequeño-rápido no se ven afectados. Los archivos de la lista existentes permanecen disponibles.
+
+El panel de control advierte sobre versiones antiguas o desconocidas de CLI, objetivos no disponibles y cualquiera de las variables ya presentes en `settings.json` → `env` (que anula env de lanzamiento). La detección es de solo lectura y local en el servidor: no puede inspeccionar otro shell de lanzamiento, otra máquina o la configuración local del proyecto. Un resultado desconocido no es prueba de apoyo a la fuerza.
+
+Los selectores de puerta de enlace explícitos en una solicitud de agente generada tienen prioridad sobre su alternativa heredada `ocx-route`, incluso si la configuración de fuerza guardada cambia después del lanzamiento. Para las anulaciones de configuración o shell de los agentes de lista generados, use un alias de puerta de enlace explícito; los ids desnudos de Claude retienen el comportamiento de respaldo del cliente más antiguo. Los alias nativos restauran su modelo desnudo antes de las verificaciones de credenciales y mapas de modelo existentes. Los lanzamientos conectados validan los objetivos de fuerza contra un nuevo catálogo de puerta de enlace autenticado; el descubrimiento fallido omite la inyección automática de fuerza y las ventanas de contexto en caché por sí solas nunca demuestran disponibilidad.
+
+
+<a id="claude-oauth-client-version-errors"></a>
+
+## Errores de versión de Claude con OAuth
+
+Ante `claude_code_version_too_old`, comprueba el proveedor. Codex mediante el adaptador `anthropic` usa el perfil de compatibilidad de OpenCodex: actualizar otro ejecutable `claude` no cambia ese perfil. Actualiza OpenCodex y reinicia su proxy. Con `claude-cli` o Claude Code directo, actualiza esa CLI. Messages nativo con identidad de cliente observada conserva su versión, y los encabezados del operador prevalecen. El error de `claude-fable-5-2` exigía Claude Code 2.1.290 o posterior; este perfil presenta 2.1.321. Un requisito futuro puede exigir actualizar el perfil. No concede acceso a modelos ni cambia cuotas.
+
+Las ventanas semanales específicas de modelo inactivas, como Fable cuando limita la semana compartida, siguen visibles como **No está en vigor ahora**, con la proporción informada por Anthropic, por ejemplo hasta el 50% del límite semanal. Sin fila Fable no se inventa su barra. Las cuentas Claude priorizan el alias y después el correo enmascarado; sin identidad segura usan un ordinal. Overview muestra la misma cuenta si la lista está verificada. `privacy.maskEmails` en `false` muestra el correo completo.
+
+**Límites del paso directo.** Se usa la credencial del cliente y sus límites. Un 429 se devuelve con sus encabezados y `Retry-After`, sin reenviarlo por otra cuenta o proveedor. Las peticiones auxiliares de Claude, como WebSearch con `claude-haiku-5-5`, pueden fallar aunque funcione el modelo principal enrutado. Para moverlas, configura `claudeCode.intercept.modelMap` u `ocx claude desktop bind` en tráfico oficial Desktop/CLI, o `claudeCode.modelMap` en todos los accesos. Al no resolver el ID a sí mismo se enruta normalmente. En sesiones `ocx claude`, `claudeCode.tierModels.haiku` puede pedir un ID enrutado; un `claude-*` sigue en paso directo y `ANTHROPIC_DEFAULT_HAIKU_MODEL` exportado prevalece ([#7912](https://github.com/lidge-jun/opencodex/issues/7912)).
+
+<a id="anthropics-advisor-tool-on-translated-routes"></a>
+
+### Herramienta Advisor de Anthropic en rutas traducidas
+
+Claude Code declara la herramienta tipada `advisor_*`, como `advisor_20260301` con beta `advisor-tool-2026-03-01`. Anthropic consulta al asesor en el servidor de la misma solicitud y devuelve `server_tool_use` con nombre `advisor`, seguido de `advisor_tool_result`:
+
+- El adaptador `anthropic` con `https://api.anthropic.com` recibe la declaración y beta. Un gateway compatible solo las recibe si configura [`forwardAdvisorTool: true`](/es/reference/configuration/providers/); `forwardAdvisorTool: false` también las desactiva en el oficial.
+- Otros destinos, incluidos GPT, Gemini y gateways sin esa opción, omiten la declaración y ejecutan sin asesor. No bloquea destinos de combos o alternativas.
+- Si el [Advisor de OpenCodex](/es/reference/configuration/advisor/) está activo, controla el nombre `advisor` y no se reenvía la herramienta declarada; el registro indica `advisor-tool-shadowed-by-proxy-advisor`.
+- Si la clave del cliente no admite el `model` declarado, se omite con `advisor-tool-outside-model-scope`; el carril Messages nativo administrado rechaza la solicitud.
+- `server_tool_use` y `advisor_tool_result` llegan sin cambios, incluidos ID `srvtoolu_`, en streaming y sin él. Incluye `advisor_result`, `advisor_redacted_result` cifrado y `advisor_tool_result_error`. El contenido cifrado no se lee, reescribe ni registra.
+- Al reenviar un intercambio completo en el historial, se conserva en su posición, con beta, solo hacia destinos que admiten la declaración. La entrada debe ser un objeto vacío y el resultado una de esas tres variantes; el resto se descarta.
+- Una llamada pendiente al terminar con `pause_turn` o `tool_use` de cliente no se muestra ni reanuda. La siguiente solicitud conserva declaración y beta para consultar de nuevo.
+- Si OpenCodex controla Advisor, también excluye los intercambios anteriores de Claude durante todo el turno para no cambiar el prompt a mitad.
+- Los tokens del asesor se informan por separado y no se suman a los registros de uso, gasto de clave ni uso devuelto a Claude Code. Consulta su coste en Anthropic.
+
+**Afinidad OpenAI/ChatGPT nativa.** `prompt_cache_key` sirve a la afinidad de caché; `session_id` solo procede de identidad de sesión, nunca de la clave compartida. Si `metadata.user_id` es una cadena JSON con otras claves, se elimina el token por turno `tk` antes del hash, manteniendo identidad entre turnos remotos. Cadenas que no sean objetos JSON, arrays o un objeto con solo `tk` se hashean sin cambios; `user` sigue derivándose de la cadena original. Sin cadena y con sistema, se usa el hash de modelo resuelto, sistema y esquemas de herramientas: identifica un grupo de solicitudes, no una sesión.
+
+**Modelos no disponibles en perfiles.** Una ruta ausente del catálogo se conserva como **No disponible** porque puede ser una caída temporal. **Eliminar no disponibles (N)** o **Eliminar** en una fila avanzada quita asignación y alias. Si se elimina el predeterminado de una familia, se elige el primer modelo disponible; sin ninguno, se quitan también sus otras filas no disponibles, indicándolo antes. No cambia nada hasta **Guardar** o **Guardar y aplicar**, y nunca se elimina automáticamente.
+
+**Búsqueda de herramientas MCP.** Desde Claude Code 2.1.304, ToolSearch está activado por defecto tras un gateway `ANTHROPIC_BASE_URL`, incluido `ocx claude`. Versiones anteriores incluyen todos los esquemas inicialmente; se puede activar en ellas con la opción ya descrita. `ocx claude` solo inyecta `ENABLE_TOOL_SEARCH` cuando `claudeCode.toolSearch` tiene un valor activador. `toolSearch: false` no inyecta nada y no desactiva ToolSearch. En Chat traducido cada carga cambia catálogo y sistema y puede perder la caché del historial ([#7963](https://github.com/lidge-jun/opencodex/issues/7963)). Para priorizar un prefijo estable, exporta `ENABLE_TOOL_SEARCH=false`; un valor exportado siempre gana. Para conservar búsqueda y prefijo, verifica y activa `claudeCode.chatToolDispatchModels`.
+
+Una ruta Responses que acepta `additional_tools` pero lo descarta silenciosamente no está verificada para `claudeCode.appendOnlyToolLoadingModels`. Así se comportó la API oficial Responses de DeepSeek en la medición del 31 de octubre de 2026; usa su ruta Chat.
diff --git a/docs-site/src/content/docs/es/guides/codex-app-models.md b/docs-site/src/content/docs/es/guides/codex-app-models.md
new file mode 100644
index 00000000000..ad7c441c92b
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/codex-app-models.md
@@ -0,0 +1,283 @@
+---
+title: "Selector de modelos de Codex App"
+description: "Cómo aparecen los modelos enrutados de opencodex en Codex App, Codex CLI y Codex TUI mediante el catálogo compartido de Codex."
+---
+
+opencodex no parchea la aplicación Codex. Escribe la misma configuración Codex y el catálogo de modelos que Codex CLI / TUI. El servidor de aplicaciones lee ese estado compartido, pero algunas versiones de escritorio Codex aplican una segunda lista de permisos de modelo remoto en el renderizador y aún pueden eliminar las filas enrutadas del selector.
+
+Las entradas de OpenAI usan dos rutas de credenciales: la sesión nativa de Codex y el transporte con clave API `openai-apikey/<model>`. Cambiar `codexAccountMode` entre Pool y Direct no cambia por sí solo los identificadores del selector. Cuando `codexAccountPickerEnabled` y `codexAccountNamespaces` habilitan selectores por cuenta, opencodex añade filas `<selector>/<native-openai-model>` para los selectores elegibles cuyas cuentas asignadas aún existen, y oculta las filas nativas sin calificar del selector de Codex. Las etiquetas son nombres públicos elegidos por el usuario; no implican un rol de cuenta. Una fila calificada utiliza únicamente su cuenta asignada, no cambia la cuenta activa de Pool y rechaza la solicitud si esa cuenta no está disponible, en lugar de sustituirla por otra. Si el catálogo de Codex contiene un identificador de la familia OpenAI visible para una cuenta y respaldado por la API que aún no está en el conjunto estático de opencodex, se conserva exactamente en una fila calificada para los selectores elegibles de la cuenta principal. No se copia a cuentas ajenas ni se añade a las listas sin calificar o con clave API. La fila debe tener los campos de una entrada real del catálogo, lo que excluye entradas mal formadas; esto no demuestra que proceda del proveedor, porque la caché es un archivo propiedad del usuario. Véase [Selectores exactos de cuenta de Codex](/es/reference/configuration/routing/#exact-codex-account-selectors).
+
+`gpt-daybreak-blue-latest` depende del acceso de cada cuenta. opencodex comprueba la lista de modelos de Codex de cada cuenta ChatGPT autenticada antes de anunciarlo o enrutarlo. En modo Pool, la fila sin calificador existe solo si alguna cuenta Pool apta informa de ese identificador. En modo Direct, sigue la cuenta principal del catálogo local, y cada solicitud también comprueba la credencial reenviada del cliente, o la principal almacenada si se sustituyó un bearer de admisión de OpenCodex. Una fila `<selector>/gpt-daybreak-blue-latest` solo existe si la cuenta asignada a ese selector lo informa. Pool excluye las cuentas sin acceso. Si no se puede confirmar ninguna lista, la fila restringida rechaza la selección, en vez de gastar un prompt en un HTTP 400 del proveedor.
+
+`gpt-5.6-sol`, `gpt-5.6-terra`, `gpt-5.6-luna` y `gpt-6-astra` son deliberadamente **no** filtrados de esa manera: se enumeran en cada instalación, diga lo que diga la lista de derechos. opencodex pregunta aguas arriba bajo una versión de cliente lo suficientemente nueva como para devolverlos, pero no puede hacer que aparezca una respuesta: una cuenta no confirmada, una búsqueda que agota el tiempo o un fragmento que aún no se ha puesto al día haría desaparecer el modelo del selector sin explicación. Enumerarlos significa que se envía la solicitud y en su lugar se ve el estado ascendente real. Una cuenta que no tiene uno de estos modelos obtendrá un rechazo ascendente en el momento de la solicitud en lugar de una fila ausente, y en una cuenta múltiple Pool la solicitud ya no se dirige primero a la cuenta que posee el modelo. `disabledModels` es la palanca para ocultar cualquiera de ellos.
+
+Una entrada separada y explícita `customModels` puede exponer el mismo identificador de cable que `openai/gpt-daybreak-blue-latest` a través del proveedor de reenvío de inicio de sesión canónico Codex:
+
+```json
+{
+  "customModels": [
+    {
+      "id": "daybreak-codex-forward",
+      "provider": "openai",
+      "modelId": "gpt-daybreak-blue-latest"
+    }
+  ]
+}
+```
+
+Solo ese proveedor exacto, el punto final y la identificación del modelo reciben la instantánea de capacidad de Sol fijada: 922.000 contexto, 829.800 compactación automática, la escalera de razonamiento nativa y los metadatos de la herramienta nativa Codex. La solicitud todavía envía `gpt-daybreak-blue-latest`; opencodex no lo reescribe a Sol ni otorga derecho a la cuenta. La fila `openai-apikey/daybreak-blue-latest` API facturada por separado es una ruta diferente y sus límites de 1.050.000 / 922.000 nunca se copian en la fila de inicio de sesión Codex.
+
+Para las filas personalizadas de Astra y Daybreak en ese destino canónico `openai` Codex-forward, las capacidades explícitas `reasoningEfforts` están limitadas por las capacidades del modelo Codex ancladas. Un `["none", "minimal", "low"]` personalizado se convierte en `["low"]` en el catálogo; una lista no vacía sin valores compatibles también vuelve al valor predeterminado nativo como una sola opción. Un `[]` explícito permanece vacío y no tiene anuncios predeterminados. Un valor predeterminado declarado se retiene solo si pertenece a la lista resultante; de lo contrario, se usa el valor predeterminado nativo cuando está presente, luego la primera opción sobreviviente. La configuración personalizada almacenada no cambia y las sincronizaciones repetidas no vuelven a agregar `max` a una lista personalizada estrecha.
+
+El mismo vínculo de catálogo se aplica cuando el identificador de modelo personalizado ha fijado metadatos de capacidad nativa, incluida una puerta de enlace arbitraria como `YYLJ/gpt-6-astra`. Desktop valida el ID del modelo, por lo que `none` y `minimal` se eliminan de esa fila del catálogo. La identidad nativa completa todavía requiere la identidad exacta del proveedor, el destino y el modelo respaldado por capacidades; una puerta de enlace no hereda Responses Lite, multiagente o ventanas nativas de su nombre. La elección nativa Astra `ultra` de Codex se conserva: es un modo de delegación de cliente convertido en un esfuerzo de cable soportado, distinto del [Lista de esfuerzo del modelo API](https://developers.openai.com/api/docs/models/gpt-6-astra). La normalización de catálogos no reescribe los ajustes de subprocesos existentes. Las pinzas de esfuerzo nativas de tiempo de solicitud permanecen solo canónicas.
+
+Cuando el mapa `codexAccountNamespaces` está vacío, las filas de selector calificadas para la cuenta están desactivadas. Si se omite `codexAccountPickerEnabled` con un mapa no vacío, se tratan como habilitados para la compatibilidad con versiones anteriores. Establezca el valor en `false` para ocultar filas calificadas generadas y restaurar filas nativas desnudas en el selector sin eliminar asignaciones ni deshabilitar el enrutamiento exacto `<selector>/<native-openai-model>`.
+
+Las entradas API GPT-5.6 y Daybreak usan 1.050.000 entradas de contexto / 922.000 entradas máximas, y los identificadores del selector `*-pro` se resuelven en el modelo de cable base con `reasoning.mode: "pro"` mientras que los registros, el uso y el estado del selector mantienen el identificador virtual. El catálogo API se fija a exactamente diez ids: `gpt-5.5`, `gpt-5.6`, Sol/Terra/Luna, sus tres ids virtuales Pro, `daybreak-red-latest`, y `daybreak-blue-latest`; no hay alias `gpt-5.6-pro` genérico. Las solicitudes compactas mantienen el nivel seleccionado pero envían el modelo base sin un objeto de razonamiento.
+
+Seleccione la ruta de credenciales representada por el identificador de selector. Cambiar Pool / Direct en la página de Proveedores; `<selector>` a continuación es una etiqueta pública elegida por el usuario mapeada a través de `codexAccountNamespaces`:
+
+```text
+gpt-5.6-sol                         # bare Codex-login route via Pool or Direct
+<selector>/gpt-5.6-sol              # stored Codex account mapped by that selector
+openai-apikey/gpt-5.6-sol           # API key
+openai/gpt-daybreak-blue-latest     # explicit Codex-forward custom row (922,000)
+<selector>/gpt-daybreak-blue-latest # account-qualified native id, only when that account reports it
+openai-apikey/daybreak-blue-latest  # separate API-key route (1,050,000 / 922,000)
+```
+
+Instalación y configuración nuevas sin modo guardado predeterminado a Pool. Las configuraciones actuales usan el marcador 2 y retienen la fuente v1 enviada en `~/.opencodex/config.json.pre-openai-tiers-v2.bak`; restaurarla con:
+
+```sh
+cp ~/.opencodex/config.json.pre-openai-tiers-v2.bak ~/.opencodex/config.json
+```
+
+Las configuraciones anteriores de tres proveedores v1 migran automáticamente a la fila de una sola opción.
+
+<a id="desktop-remote-allowlist-limitation"></a>
+
+## Limitación de lista remota de escritorio
+
+Si `codex debug models` y app-server `model/list` contienen un modelo enrutado pero Desktop no lo muestra, compruebe el [incidencia de Codex #19694](https://github.com/openai/codex/issues/19694) anterior. Con la directiva remota `use_hidden_models` activa, Desktop puede mantener solo los id en su lista nativa `available_models` y también puede mostrar filas nativas cuya visibilidad de catálogo es `hide`. Las actualizaciones de catálogo y los reinicios proxy solos no pueden cambiar esa directiva de renderizador.
+
+Para un modelo enrutado equivalente, opencodex ofrece un modo de combo con alias nativo que exige activación explícita y está desactivado de forma predeterminada. Publica una identificador desnuda listada con una etiqueta de visualización personalizada honesta y rutas que exactas identificador a través del combo configurado antes del enrutamiento canónico OpenAI. También omite las filas nativas desnudas deshabilitadas del catálogo efectivo mientras existen alias de compatibilidad, por lo que Desktop no puede resucitarlas ignorando `visibility`. Consulte [Codex Compatibilidad con la lista nativa de equipos de escritorio](/es/guides/combos/#codex-desktop-native-allowlist-compatibility) para el comando, la semántica de la clave de inhabilitación y las restricciones de seguridad.
+
+<a id="what-this-means-for-a-disabled-native-model"></a>
+
+### Lo que esto significa para un modelo nativo desactivado
+
+De forma predeterminada, sin un alias nativo configurado, deshabilitar un identificador GPT nativo sin calificar no lo elimina del catálogo. La fila se queda con `visibility: "hide"`, que `/v1/models` y el tablero de instrumentos honran, dejan de enumerar el modelo, mientras que Desktop, bajo la política anterior, puede seguir mostrándolo. Por lo tanto, el modelo aún se puede elegir en Desktop después de deshabilitarlo, y las superficies no están de acuerdo sobre si existe.
+
+La selección no se rechaza por estar deshabilitado. `disabledModels` controla la visibilidad del catálogo, no la admisión, por lo que la solicitud se enruta según las reglas ordinarias como si el modelo estuviera habilitado: el turno se ejecuta en el modelo que deshabilitó o falla en cualquier ruta que se resuelva. De cualquier manera, el resultado no es el que implica la palanca.
+
+La fila se conserva deliberadamente porque contiene los metadatos reales del proveedor: al habilitar de nuevo el modelo se restauran esos datos. Para omitir filas nativas deshabilitadas sin un alias nativo, configura `"omitDisabledNativeModels": true` en `config.json` y ejecuta `ocx sync`. La opción está desactivada de forma predeterminada. La sincronización, la caché generada y el descubrimiento HTTP con formato de Codex omiten esas filas, pero conservan una plantilla nativa de herencia validada por separado. Así, las filas enrutadas mantienen sus metadatos de entrada y herramientas, incluso cuando la única fila que servía de plantilla está deshabilitada. Las solicitudes directas a un identificador nativo deshabilitado siguen enrutándose con normalidad. Un combo `nativeAlias` conserva su comportamiento de omisión independientemente de este ajuste.
+
+Si el `config.toml` de Codex fija un `model` raíz que este proxy no expone —entre ellos un modelo deshabilitado—, cada sesión nueva empieza en un modelo que opencodex no sirve. `ocx doctor` lo informa bajo **Exposición del modelo predeterminado de Codex**, como advertencia y no como fallo, e indica cuándo no pudo determinar en absoluto el conjunto expuesto.
+
+<a id="integration-path"></a>
+
+## Ruta de integración
+
+`ocx init`, `ocx start`, y `ocx sync` cablear la configuración y el catálogo compartidos de Codex en el proxy; ver
+[Integración con Codex](/es/guides/codex-integration/) para inyección de configuración, sincronización de catálogo, shims, WebSocket fallback, y restaurar la mecánica.
+
+<a id="native-quota-fallback-limitation"></a>
+
+## Limitación de reserva de cuota nativa
+
+Cuando la aplicación Codex agota su cuota nativa de cinco horas, puede cambiar a un modelo de reserva y en gris las otras filas en su selector. Informado en [#2813](https://github.com/lidge-jun/opencodex/issues/2813), esa puerta también oculta opencodex filas enrutadas, a pesar de que utilizan credenciales de proveedor no relacionadas y no consumen ninguna de la cuota ChatGPT.
+
+Esta puerta es aplicada por el cliente antes de que una solicitud llegue al proxy, por lo que opencodex no puede levantarla. Las filas enrutadas se escriben con `visibility: "list"`, el filtrado de catálogo consulta solo `disabledModels` y el `selectedModels` de cada proveedor, y ningún valor de cuota participa en la visibilidad enrutada.
+
+La selección de un modelo enrutado explícitamente no pasa por el selector. Fije el modelo en `config.toml`:
+
+```toml
+model = "anthropic/claude-sonnet-5"
+```
+
+o enviarlo directamente:
+
+```bash
+ocx access test anthropic/claude-sonnet-5 --protocol responses
+```
+
+Ambos caminos encaminan correctamente **Una vez que la solicitud llega al proxy** - esa parte está cubierta por pruebas. La aplicación de escritorio Codex, sin embargo, no envía el modelo configurado mientras el modo de reserva está activo: decide la reserva de su propia encuesta `wham/usage` (`luna_reserve` más un límite adicional permitido `gpt-reserve`) y fuerza la configuración del modelo a `gpt-reserve` antes de que la solicitud se vaya, por lo que la ruta `config.toml` se anula en la aplicación. Utilice `ocx access test`, Claude Code a través del proxy (`ocx claude`), o cualquier cliente `/v1` directo hasta que se restablezca la ventana. Véase [Modelos encaminados durante el modo de reserva Codex](/es/guides/codex-integration/#routed-models-during-codex-reserve-mode).
+
+<a id="why-routed-models-show-up"></a>
+
+## Por qué aparecen los modelos enrutados
+
+El selector de modelos de Codex espera entradas de catálogo en forma de Codex. opencodex construye entradas enrutadas clonando una plantilla de modelo nativa Codex y reemplazando la identidad del modelo enrutado:
+
+```text
+slug = "anthropic/claude-sonnet-..."
+display_name = "anthropic/claude-sonnet-..."
+visibility = "list"
+```
+
+El clon mantiene campos de análisis estrictos, como niveles de razonamiento, tipo de shell, banderas de soporte API e instrucciones base. opencodex luego elimina las capacidades solo nativas que la ruta no puede cumplir, incluidos los metadatos de nivel de servicio OpenAI.
+
+<a id="current-stable-model-coverage"></a>
+
+## Cobertura actual del modelo estable
+
+El conjunto de reserva nativo incluye `gpt-5.5` y GPT-5.6 Sol / Terra / Luna. Para la familia GPT-5.5, opencodex conserva las entradas en vivo más ricas del catálogo Codex instalado y solo sintetiza una entrada faltante. La instantánea de flujo ascendente agrupada se usa solo para GPT-5.6, donde proporciona la identidad real por modelo y los metadatos en lugar de una aproximación de plantilla anterior.
+
+| Ruta | Identificadores de selección y metadatos de catálogo |
+| --- | --- |
+| Inicio de sesión de Codex (filas por cuenta desactivadas) | Identificadores nativos sin prefijo como `gpt-5.6-sol`, `gpt-5.6-terra` y `gpt-5.6-luna`; `codexAccountMode` selecciona Pool o Direct. Las filas GPT-5.6 tienen una ventana de catálogo de 922.000 tokens. `gpt-6.1-terra` tiene 500,000 de forma predeterminada y 872,000 en contexto largo. |
+| Codex inicio de sesión (filas calificadas por cuenta habilitadas con selectores elegibles) | Una fila `<selector>/<native-openai-model>` por selector elegible y modelo nativo compatible; cada fila usa solo su cuenta asignada, y las filas nativas desnudas están ocultas para el selector. Se conservan los metadatos nativos y las ventanas de contexto. |
+| Codex inicio de sesión (explícita fila de Daybreak forward) | `openai/gpt-daybreak-blue-latest` solo cuando la fila exacta `customModels` está configurada en el proveedor canónico `openai`. Mantiene el identificador de cable Daybreak y utiliza la instantánea de capacidad Sol fijada (922.000 contexto; 829.800 compactación automática). |
+| OpenAI (clave API) | Los modelos con espacio de nombres incluyen `gpt-5.5`, `gpt-5.6`, Sol/Terra/Luna, los identificadores virtuales `*-pro` y los alias Daybreak (1.050.000 de contexto y 922.000 de entrada máxima). `openai-apikey/gpt-6.1-terra` añade 1,050,000 de contexto y 128,000 de salida máxima. |
+| OpenRouter | `openrouter/openai/gpt-5.6-sol`, `openrouter/openai/gpt-5.6-terra`, `openrouter/openai/gpt-5.6-luna` (922.000) |
+| OpenRouter | `openrouter/openai/gpt-6.1-terra` (1,050,000) |
+| Cursor | La reserva estática incluye `cursor/gpt-5.6-sol`, `cursor/gpt-5.6-terra` y `cursor/gpt-5.6-luna` (1.000.000), más filas regulares/rápidas para Grok 4.5, 4.6 y 4.7 (500.000); 4.6 y 4.7 agregan `xhigh`, y el descubrimiento de cuenta real decide qué filas permanecen visibles. |
+| xAI | El descubrimiento en vivo es autoritario. El catálogo alternativo incluye `xai/grok-4.6` y `xai/grok-4.7` y por defecto a `xai/grok-4.5`; los tres tienen ventanas de 500.000 tokens. Grok 4.6 y 4.7 exponen `low` / `medium` / `high` / `xhigh` (por defecto aguas arriba: `high` ), mientras que Grok 4.5 se detiene en `high`. |
+
+Las entradas GPT-5.6 fijadas preservan la escalera aguas arriba exacta. Sol y Terra exponen `low` a través de `ultra`; Luna se detiene en `max`. Sol tiene el valor predeterminado de `low`, mientras que Terra y Luna tienen el valor predeterminado de `medium`. La explícita fila Codex Daybreak Blue hereda la escalera y el valor predeterminado de Sol sin cambiar su identidad de cable. `ultra` es una opción orientada al cliente para un razonamiento máximo más delegación proactiva y llega al backend como `max`. Una entrada de selector solo significa que el catálogo está listo: la cuenta conectada o la clave API aún deben tener derecho a usar ese modelo.
+
+<a id="native-and-routed-model-toggles"></a>
+
+## Conmutadores de modelo nativo y enrutado
+
+La página Modelos del panel de control expone `disabledModels` alterna para ids nativos desnudos y `provider/model` ids enrutados. Los identificadores `<selector>/<native-openai-model>` calificados para la cuenta también son compatibles con `disabledModels`, pero el panel de control no enumera ni cambia esas filas de selector exactas; agréguelas a la configuración manualmente:
+
+- Los identificadores de ruta son namespaced (`provider/model` ). Deshabilitar uno lo excluye del catálogo sincronizado y `/v1/models`.
+- Los identificadores nativos calificados para la cuenta usan `<selector>/<native-openai-model>`. Agregar uno a `disabledModels` oculta solo esa fila del selector.
+- Los identificadores nativos de GPT no llevan prefijo. Deshabilitar uno conserva su entrada del catálogo con `visibility: "hide"` para poder volver a habilitarla después; oculta del descubrimiento tanto la fila sin prefijo como cada copia que especifica un selector para ese modelo.
+- Si hay al menos un combo con alias nativo, las filas nativas sin prefijo deshabilitadas se omiten del catálogo en lugar de conservarse ocultas, porque las versiones de Desktop afectadas ignoran esa marca de ocultación. La página Modelos también omite una fila nativa sin prefijo cuando un alias nativo ocupa su identificador; por eso esa fila no muestra un interruptor nativo. Solo las filas no sustituidas por un alias conservan su interruptor. Al volver a habilitar una de esas filas, la sincronización restaura sus metadatos nativos originales o actuales.
+- Las filas nativas no sombreadas provienen del conjunto estático admitido, por lo que un modelo no sombreado desactivado permanece visible en el panel y se puede volver a activar.
+
+El pase de visibilidad se ejecuta después de las actualizaciones de instantáneas, y la administración API actualiza el catálogo y fuerza la caché del modelo de Codex después de un cambio.
+
+<a id="multi-agent-surface-mode"></a>
+
+## Modo de superficie multiagente
+
+El control Models-page v1/base/v2 cambia qué superficie de colaboración Codex usa cada entrada del selector; vea [Superficie del subagente](/es/guides/sub-agent-surface/) para el modo canónico, la delegación, la herencia, la reserva y el comportamiento de la tarea cifrada.
+
+<a id="reasoning-top-tiers"></a>
+
+## Razonamiento de los niveles superiores
+
+La visibilidad del nivel de razonamiento es independiente del modo de superficie v1/base/v2. Las entradas con capacidad de razonamiento generadas anuncian `max` para que los sobresueldos directos de esfuerzo de subagente validen; las entradas enrutadas generadas actuales y las entradas GPT nativas más antiguas también anuncian `ultra`. Se conservan escaleras GPT-5.6 aguas arriba exactas, por lo que Luna tiene `max` pero no `ultra`.
+
+En el cable, los adaptadores enrutados mapean o sujetan niveles no compatibles. Para los modelos nativos más antiguos cuya escalera real se detiene en `xhigh`, `nativeEffortClamp` asigna una selección directa de `max` o `ultra` a `xhigh` (por ejemplo, GPT-5.5). Sol, Terra y Luna tienen un verdadero `max` peldaño.
+
+El backend de ChatGPT acepta niveles desde `none` hasta `max`, así que una solicitud nativa nunca reenvía `ultra` literalmente. Los modelos nativos con un nivel real `max` reciben `max`, incluidos Astra, GPT-6.1 Sol y GPT-6.1 Terra aunque anuncien `ultra`; los antiguos, como GPT-5.5, reciben `xhigh` como se explicó arriba. Esto se aplica tanto a `/v1/responses` como a `/v1/chat/completions`. Esa normalización nativa no afecta a los identificadores enrutados: un paso directo OpenAI Chat enrutado puede copiar `reasoning_effort: "ultra"` al proveedor sin cambios, mientras que el adaptador traducido ordinario convierte `ultra` en `max`.
+
+La publicidad del catálogo de los dos niveles superiores es incondicional: `ocx sync` ya no elimina `max` o `ultra` cuando el binario Codex instalado es demasiado viejo para ofrecerlos: las versiones Codex sin esos peldaños están fuera de soporte, y ocultarlos de los clientes actuales cuesta más de lo que compra. Otros peldaños todavía se intersectan con la escalera de entorno de ejecución observada, y un diagnóstico de pinza registrado por un binario anterior deja de aplicarse una vez que el binario en esa ruta informa una versión diferente (el caso de actualización en el lugar), por lo que `ocx status` y `ocx doctor` dejan de advertir sobre una pinza que el entorno de ejecución actualizado ya no necesita. La visibilidad del catálogo no es un derecho: la publicidad `max` / `ultra` no garantiza que la cuenta ascendente o el proveedor acepte el nivel, y para los modelos nativos más antiguos cuya escalera real se detenga en `xhigh`, la limitación aplicada al protocolo descrita antes aún mapea la selección en el momento de la solicitud.
+
+<a id="fast-tier-rules"></a>
+
+## Reglas de nivel rápido
+
+Codex almacena el modo rápido como:
+
+```toml
+service_tier = "fast"
+
+[features]
+fast_mode = true
+```
+
+Pero el catálogo de modelos y el identificador de nivel de solicitud en entorno de ejecución usan `priority`. opencodex preserva esa división. Los modelos de transferencia nativos OpenAI mantienen un soporte rápido; los proveedores enrutados tienen acceso a la capacidad: `service_tier` se elimina solo cuando el proveedor declara `supportsServiceTier: false` (el registro clasifica los canónicos OpenAI como `true`, DeepSeek y Volcengine Ark como `false`), mientras que las puertas de enlace personalizadas no clasificadas mantienen intactos los valores suministrados por el llamante y nunca reciben una inyección. Una puerta de enlace personalizada puede optar a nivel mundial con `supportsServiceTier: true`, o por poco con `modelSupportsServiceTier: { "verified-model": true }`; un `false` exacto reduce un predeterminado de proveedor de `true`, mientras que el nivel de proveedor `false` permanece cerrado por error. La misma decisión final del adaptador/modelo controla tanto los metadatos del catálogo como la inyección en entorno de ejecución, por lo que la opción rápida nunca se anuncia donde no se puede cumplir. Un destino `openai-chat` puede autorizar todos los modelos elegibles con `chatServiceTier: true`, o autorizar solo modelos exactos con `modelSupportsServiceTier`; Responses rutas no necesitan esa autorización de cable de chat adicional.
+
+<a id="selecting-flex-in-codex"></a>
+
+### Seleccionar Flex en Codex
+
+Para un proveedor y modelo enrutados cuya compatibilidad con `service_tier: "flex"` esté
+verificada, declara Flex junto con la configuración existente de Fast. Combina estos campos
+con la entrada **existente** de `providers.nanogpt`; no reemplaces su URL ni sus credenciales:
+
+```json
+{
+  "modelSupportsServiceTier": { "openai/gpt-6-luna": true },
+  "fastWire": {
+    "kind": "service-tier",
+    "canonicalToWire": { "priority": "priority", "flex": "flex" },
+    "foreignCallerTiers": "verbatim"
+  }
+}
+```
+
+En una ruta `openai-responses` apta, la fila Luna anuncia Standard, Fast y Flex en el selector
+de velocidad de Codex. Para `openai-chat`, añade `chatServiceTier: true` **solo si** el endpoint
+Chat Completions acepta niveles de servicio indicados por el cliente. La asignación `fastWire`
+se aplica a **todo el proveedor**: otros modelos aptos para niveles de servicio dentro de la misma
+entrada `providers.nanogpt` también pueden anunciar Flex cuando se publican como filas enrutadas
+ordinarias, aunque no aparezcan en `modelSupportsServiceTier`. Ese mapa no es una lista que excluya
+a los demás modelos aptos. Las filas de espacios de nombres de Combos y de alias nativos **no**
+publican Flex. Verifica la compatibilidad de **cada** modelo enrutado ordinario apto; si solo Luna
+admite Flex, usa una entrada de proveedor separada sin otros modelos aptos para Fast.
+La compatibilidad con Fast no implica compatibilidad con Flex.
+
+Mantén el modo Fast global de OpenCodex en **Auto** (`fastMode` sin configurar): forzar Fast o
+Default reemplaza la elección Flex del cliente. Después de `ocx sync`, actualiza la lista de
+modelos de Codex. Selecciona **Flex** en el selector de velocidad o usa
+`/model <routed-id> --speed=flex` en Codex CLI. Es un nivel seleccionable, no un valor predeterminado
+forzado por modelo: cambiar de modelo no activa Flex automáticamente. Se reenvía como
+`service_tier: "flex"` y el proveedor puede rechazarlo. La disponibilidad, el costo y la latencia
+dependen del proveedor; ni el menú ni una solicitud prueban por sí solos qué nivel se facturó.
+
+<a id="selecting-ultra-fast-in-codex-desktop"></a>
+
+### Selección ultra rápida en el escritorio Codex
+
+Para un proveedor que admita `service_tier: "ultrafast"`, declare esa asignación de cables una vez. opencodex publica entonces **Ultra rápido** en el menú de velocidad nativo Codex del modelo enrutado; no hay necesidad de editar `opencodex-catalog.json` después de cada sincronización. Por ejemplo, fusione estos campos en un proveedor API configurado para GPT-6.1 Sol:
+
+```json
+{
+  "models": ["gpt-6.1-sol"],
+  "modelSupportsServiceTier": { "gpt-6.1-sol": true },
+  "fastWire": {
+    "kind": "service-tier",
+    "canonicalToWire": { "priority": "priority", "ultrafast": "ultrafast" },
+    "foreignCallerTiers": "verbatim"
+  }
+}
+```
+
+La asignación se aplica a todos los modelos Fast-elegibles en ese proveedor. Utilice una entrada de proveedor independiente si solo algunos de sus modelos son compatibles con Ultra Fast. Mantenga el modo rápido de opencodex en **Auto** (omit `fastMode` ) para que la selección de velocidad de la aplicación llegue al proveedor; forzó a Fast a enviar `priority`, y forzó a Default a dejar caer el nivel. Actualizar el catálogo de modelos, reiniciar el escritorio Codex si todavía tiene la lista anterior, seleccione el modelo enrutado y luego elija **Ultra rápido** en su menú de velocidad. El estándar sigue siendo el valor predeterminado.
+
+Solo un cable `service-tier` elegible con una asignación explícita de `ultrafast → ultrafast` agrega esta opción a las filas enrutadas; el soporte Fast ordinario o un nombre similar a GPT es insuficiente. Esa asignación enrutada no se aplica a filas nativas/de cuenta o alias combinados. La eliminación de la asignación o la desactivación del soporte de nivel de servicio de ese modelo elimina la opción enrutada generada tanto del catálogo como de la caché en la siguiente sincronización exitosa. La declaración activa también controla la opción Ultra Fast cuando Codex carga su lista de modelos sobre HTTP.
+
+Para filas enrutadas, `ultraFastTier` conserva los niveles Ultra Fast suministrados de forma independiente desde la misma fila persistente exacta; los niveles enrutados generados no se tratan como proporcionados por el operador. Para las filas nativas sin calificar `gpt-6-astra` / `gpt-6.1-sol` y sus clones vinculados a la cuenta de confianza, habilitar `ultraFastTier` también genera una opción Ultrafast que falta sin cambiar el nivel predeterminado nativo. Al deshabilitarlo, solo se retiran los metadatos de nivel nativo rastreados según se generan; se conservan los descriptores de nivel nativo suministrados o editados de forma independiente.
+
+La [guía de la API de OpenAI](https://developers.openai.com/api/docs/guides/ultrafast-mode) documenta Ultrafast para GPT-6 Astra y GPT-6.1 Sol. El acceso a la API y el [plan y acceso al espacio de trabajo de Codex](https://learn.chatgpt.com/docs/agent-configuration/speed) son independientes. La elección del menú no otorga acceso al proveedor ni garantiza la velocidad medida; Ultra Fast aumenta el uso / costo, y los requisitos de características propias de Codex aún se aplican.
+
+<a id="subagent-selection"></a>
+
+## Selección de subagentes
+
+Codex ordena las entradas del catálogo visibles en el selector por `priority` ascendente y anuncia las cinco primeras como alternativas de modelo para `spawn_agent`. La página Subagentes del dashboard permite seleccionar y guardar hasta cinco identificadores nativos sin prefijo o identificadores `provider/model` enrutados. Un `subagentModels` configurado manualmente también acepta identificadores `<selector>/<native-openai-model>` que especifican una cuenta. El dashboard conserva esos identificadores exactos al guardar la lista, incluso si sus modelos ya no están disponibles en el catálogo actual. opencodex asigna prioridades bajas de catálogo en el orden seleccionado; cuando están habilitadas las filas del selector por cuenta, las selecciones nativas sin prefijo se expanden a grupos por selector. Los demás modelos siguen siendo invocables mediante su identificador exacto.
+
+La lista de modelos destacados está separada de la selección **Delegación de subagentes** del Dashboard. Controla que anula Codex ofrece primero; no selecciona un modelo o desencadenar delegación por sí mismo.
+
+<a id="desktop-remote-servers"></a>
+
+## Servidores remotos de escritorio
+
+Codex El modo de servidor remoto del escritorio filtra el selector contra el propio cliente
+`available_models` allowlist (activo cuando el control remoto `use_hidden_models` El ajuste está activado). Encaminado Las entradas del catálogo todavía se cargan y sirven - `model/list` devuelve y el CLI incluido lee - pero el renderizador de escritorio deja caer cualquier cosa que no esté en esa lista de permisos solo nativa antes renderizado. opencodex no tiene ningún gancho en esa lista; el error de flujo ascendente se rastrea en
+[openai/codex#19694](https://github.com/openai/codex/issues/19694).
+
+Until Desktop expone un control para la lista de permisos:
+
+- Fije el modelo directamente en `~/.codex/config.toml` en la máquina remota, por ejemplo `model = "input/grok-4.5"`. El selector puede mostrar `Custom`, pero las solicitudes aún usan el modelo enrutado configurado.
+- Utilice Codex CLI o TUI en lugar del selector de escritorio; no aplican la lista de permisos y la lista de modelos enrutados normalmente.
+
+<a id="refreshing-model-state"></a>
+
+## Estado del modelo refrescante
+
+Si el selector sigue mostrando entradas obsoletas, actualice el catálogo y reinicie la superficie de destino Codex:
+
+```bash
+ocx sync
+```
+
+opencodex reescribe `models_cache.json` con un envoltorio de caché deliberadamente obsoleto cada vez que cambia la visibilidad del catálogo, la prioridad o los metadatos, por lo que la próxima actualización del modelo Codex lee el nuevo catálogo.
+
+Después de escribir un catálogo o modelo de caché, OpenCodex invalida su observación de aplicación-servidor en caché para que la siguiente solicitud verifique la frescura del proceso nuevamente. Una sincronización de configuración también invalida la observación cuando el contenido del catálogo no cambia. Esta actualización no reinicia los procesos Codex.
diff --git a/docs-site/src/content/docs/es/guides/codex-integration.md b/docs-site/src/content/docs/es/guides/codex-integration.md
new file mode 100644
index 00000000000..000d03b6dca
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/codex-integration.md
@@ -0,0 +1,953 @@
+---
+title: "Integración con Codex"
+description: "Cómo se inyecta opencodex en Codex, sincroniza el catálogo de modelos, instala shims y restaura limpiamente."
+---
+
+opencodex enruta Codex a través del proxy modificando dos elementos que Codex lee: su configuración (`$CODEX_HOME/config.toml`, por defecto `~/.codex/config.toml`) y su catálogo de modelos. Cada cambio es idempotente y reversible.
+
+El resumen **Conectar** incluye un interruptor de Codex para esta integración nativa. Muestra el último estado deseado guardado en OpenCodex, incluso justo después de cambiarlo; la insignia indica si se observa que Codex está utilizando el proxy. Durante la limpieza ambos estados pueden diferir brevemente. Al desactivar la integración se identifica el archivo de configuración efectivo de Codex, se eliminan los elementos de enrutamiento generados por OpenCodex y el proxy sigue disponible para otros clientes. Al reactivarla se reconstruye el catálogo con los modelos disponibles en ese momento; no se restauran los archivos de Codex byte por byte.
+
+El catálogo incluye metadatos de los programas de acceso autenticados tanto para los modelos nativos de Codex sin prefijo de cuenta como para las filas generadas del selector de cuentas. Los modelos sin prefijo utilizan la cuenta principal de Codex; los modelos con cuenta específica usan la seleccionada. Actualizar la integración renueva estas filas cuando cambian los programas de acceso de la cuenta. OpenCodex incorpora la información de disponibilidad de modelos de la cuenta principal que tiene la sesión iniciada a las filas nativas sin prefijo.
+
+El proxy expone la ruta de inicio de sesión de Codex `openai` sin prefijo, con los modos de cuenta Pool (predeterminado) y Direct, además de `openai-apikey/<model>` para la clave API configurada. Pool incluye la cuenta principal y las añadidas; Direct utiliza únicamente la credencial de quien realiza la solicitud o la cuenta principal. Estas rutas no recurren unas a otras como alternativa. Las configuraciones v1 existentes migran al marcador 2 y conservan `config.json.pre-openai-tiers-v2.bak` para una restauración manual.
+
+Cuando Pool selecciona una cuenta añadida, OpenCodex sustituye los identificadores de instalación ya presentes en los encabezados o metadatos del cliente por un identificador estable para esa cuenta y ese directorio de OpenCodex. Renovar el token conserva el identificador; cambiar de cuenta lo cambia. El modo Direct y la cuenta principal nativa mantienen los valores originales. Si no había metadatos de instalación, no se añaden. OpenCodex no modifica el archivo `installation_id` propio de Codex al cambiar de perfil nativo. Si no puede leer de forma segura el secreto local de instalación, la solicitud devuelve un 503 reintentable antes de llegar a ChatGPT.
+
+El mismo aislamiento se aplica a las sesiones de llamadas en vivo autenticadas y a las tramas posteriores de WebSocket realtime o sideband. Los metadatos de turno de Pool de más de 32 KiB se rechazan antes del envío: HTTP devuelve 503 y las tramas WebSocket provocan el cierre de la conexión. Los valores de Direct y de la cuenta principal nativa no cambian.
+
+En modo Pool, una solicitud con un inicio de sesión nativo de Codex validado puede utilizar esa sesión cuando la cuenta almacenada seleccionada está en periodo de espera y no hay otra cuenta almacenada ni una sonda de recuperación aptas. Esto también se aplica a una solicitud nueva bloqueada antes del envío, con la misma validación de identidad utilizada después de un rechazo del proveedor. Se siguen aplicando los permisos del modelo y las políticas de la cuenta principal. Esta alternativa conserva el periodo de espera de la cuenta almacenada y no guarda la credencial de quien realiza la solicitud como selección de Pool. Un enlace exacto a una cuenta permanece vinculado a ella. Fijar una cuenta manualmente en Pool expresa una preferencia; no crea un enlace exacto y todavía permite esta alternativa. Utilice un modelo con cuenta específica cuando la solicitud deba permanecer en una sola cuenta. Pausar la cuenta principal nativa observada bloquea esta alternativa para la credencial coincidente, pero no identifica ni pausa otras sesiones de quien realiza la solicitud.
+
+Al añadir o volver a autenticar una cuenta de Pool, se rechaza un duplicado de la sesión principal nativa con `Account is already configured as the native Codex main account.`. La comprobación compara el ID de cuenta de ChatGPT, el ámbito de suscripción personal o de espacio de trabajo y el correo electrónico; la ausencia de correo no demuestra que sea otra identidad. Se siguen admitiendo espacios de trabajo distintos, miembros diferentes de un mismo espacio y suscripciones personales y de espacio de trabajo independientes. Un fallo al consultar el uso no descarta el plan de suscripción incluido en el token de inicio de sesión.
+
+Los duplicados existentes se conservan, pero no pueden seleccionarse como una segunda cuenta de Pool. La lista de cuentas expone `selectionExcludedReason: "duplicate_main"` y una `selectionExcludedAction` con instrucciones. Utilice explícitamente la cuenta principal nativa o inicie sesión en Codex nativo con otra cuenta antes de reutilizar la entrada guardada. La detección sigue la observación más reciente de la sesión nativa propia, incluso después de un nuevo inicio de sesión. La consulta pasiva de cuentas y las solicitudes con credenciales de quien llama no abren las credenciales nativas para actualizar esa observación.
+
+<a id="config-injection"></a>
+
+## Inyección de configuración
+
+`ocx sync` elimina del catálogo los esfuerzos de razonamiento que no admite el entorno de ejecución de Codex seleccionado. Informa de la limitación cuando cambian la identidad de ese entorno, los esfuerzos eliminados o los modelos afectados. Las sincronizaciones sin cambios conservan la fecha del diagnóstico y no repiten el aviso. Esta adaptación de compatibilidad no requiere ejecutar `ocx doctor`. Si la limitación desaparece y luego vuelve, se informa otra vez.
+
+OpenCodex serializa su configuración Codex. En Windows, un archivo mantenido temporalmente abierto por otro proceso obtiene un breve reintento limitado. Si el acceso permanece ocupado, vuelva a intentar la operación en breve; OpenCodex conserva la evidencia de bloqueo existente y no utiliza ese fallo de acceso para hacerse cargo de la cerradura de otro escritor.
+
+`ocx init`, `ocx start`, y `ocx sync` Llame al inyector. En el enlace de bucle predeterminado, se mantiene Codex incorporado `openai` ID de proveedor y apunta a ese proveedor en opencodex:
+
+```toml
+# root keys, before the first table
+model_catalog_json = "/absolute/path/to/opencodex-catalog.json"
+# Auto-injected by opencodex (undo: ocx restore)
+openai_base_url = "http://127.0.0.1:10100/v1"
+# Auto-injected by opencodex (undo: ocx restore)
+experimental_realtime_ws_base_url = "http://127.0.0.1:10100/v1"
+
+# only when fastMode is set; unset adds no [features] table
+[features]
+fast_mode = true
+```
+
+La segunda clave es la anulación de banda lateral de voz. Codex crea una llamada de voz WebRTC a través de `openai_base_url`, pero desde el Codex 0.146 (openai/codex#35830) se une a la banda lateral de esa llamada WebSocket en `api.openai.com` directamente a menos que `experimental_realtime_ws_base_url` lo redirija. En el modo Pool, la llamada se crea bajo la cuenta opencodex selecciona, por lo que una unión directa bajo el propio inicio de sesión de la aplicación falla con `realtime websocket handshake failed` (404). La clave inyectada envía la unión de vuelta a través de opencodex (`GET /v1/live/{callId}`), donde el Pool reutiliza la cuenta que enlazó a ese par de sesión/hilo (un enlace de proceso-local). Una llamada que el propio cliente creó es la excepción: cuando ChatGPT voz manos una llamada a un Codex hilo, o Codex escritorio crea la llamada por su cuenta, la llamada pertenece a su inicio de sesión ChatGPT y sólo su banda lateral join alcanza opencodex, por lo que opencodex reenvía que se unen con la propia ChatGPT credencial de la persona que llama en lugar de una cuenta Pool. En el modo Direct ambas patas ya usan el portador actual de la persona que llama, por lo que la clave solo mantiene la unión en la ruta proxy. Está escrito solo en el formulario loopback `openai_base_url`, se elimina junto con él, y un `experimental_realtime_ws_base_url` propiedad del usuario nunca se sobrescribe.
+
+<a id="voice-transport-and-task-handoffs"></a>
+
+### Transporte de voz y traspasos de tareas
+
+Codex posee el micrófono y el altavoz, negociación de medios WebRTC, subtítulos, controles de silencio y limpieza de voz al cambiar de hilo. OpenCodex retransmite la creación de llamadas y la conexión de banda lateral; el trabajo delegado por voz utiliza la ruta de enrutamiento Responses normal. La elección de un proveedor de texto no reemplaza el modelo de voz en tiempo real ni habilita la voz en un cliente que no lo admite.
+
+Los [Cambio de ayudante WebRTC](https://github.com/openai/codex/commit/1b53f6a44eff890b5169bde8d3bd5b12b8766946) y [Integración de voz TUI](https://github.com/openai/codex/commit/b01c3986fd2e79b8a477a08d81430f52f22bc0dc) describen estas responsabilidades del cliente, incluyendo las respuestas finales de los traspasos de voz. Sus fechas de fusión no se establecen cuando el mismo comportamiento llegó a la aplicación de escritorio.
+
+Los diagnósticos opcionales `OCX_LIVE_FRAME_LOG` escriben solo la marca de tiempo de trama, la dirección, el tipo, el recuento de bytes y una bandera de caracteres de reemplazo (`ts`, `dir`, `kind`, `bytes`, `fffd`). No almacenan texto de voz o extractos de marcos. Para tramas binarias, la decodificación UTF-8 puede producir caracteres de reemplazo, por lo que la bandera sola no identifica dónde ocurrió la corrupción. Los archivos de registro existentes no se reescriben.
+
+<a id="fast-mode"></a>
+
+### Modo rápido
+
+El `fast_mode` inyectado sigue el ajuste de tres estados `fastMode`: `true` escribe `fast_mode = true`, `false` escribe `fast_mode = false`, y unset deja un `fast_mode` existente intacto sin agregar una tabla `[features]`.
+
+El modo rápido está separado del transporte de voz. La descripción de la velocidad de nivel de servicio de un modelo compatible no garantiza un micrófono más bajo, WebRTC o latencia de voz de extremo a extremo hasta OpenCodex.
+
+<a id="chatgpt-family-channel-and-latency"></a>
+
+### Canal y latencia de la familia ChatGPT
+
+Las solicitudes enrutadas a través de opencodex por el inicio de sesión canónico de ChatGPT `openai` - adaptador `openai-responses`, `authMode: "forward"` y el punto final `https://chatgpt.com/backend-api/codex`, que cubren los modos Pool y Direct, usan el punto final público ChatGPT. El enrutamiento del proveedor o la selección de la cuenta no omite el canal ascendente ChatGPT. El flujo ascendente puede pasar tiempo poniendo en cola una solicitud antes de la primera salida incluso cuando el proxy local y la ruta de red están sanos.
+
+Solo algunos giros toman el transporte websocket ChatGPT, el mismo carril `responses_websockets` Codex CLI predeterminado. Un turno es elegible cuando el entorno de ejecución Bun soporta el relé limitado, la solicitud es un `POST` a la URL canónica Responses o una ruta WebSocket configurada, y su cuerpo JSON establece `stream` a `true` en la raíz. Todo lo demás permanece en SSE sobre HTTP, y un giro elegible sigue cayendo de nuevo a él cuando la solicitud no se puede preparar, la trama `response.create` excede su límite de tamaño, o la ruta proxy no puede llevar el socket.
+
+Para mantener el proveedor ChatGPT incorporado en HTTP / SSE, configure `providers.openai.upstreamWebsocket` a `false` en `~/.opencodex/config.json` y reinicie el proxy. Fusione este campo en el proveedor `openai` existente; conserve su modo de cuenta y otras configuraciones. Omite el campo para restaurar la selección predeterminada de aguas arriba WebSocket. Esta configuración no cambia el conmutador `websockets` orientado al cliente ni la cuenta ChatGPT utilizada para la solicitud. La dirección y la inyección nativas a mitad de giro necesitan corriente arriba WebSocket y no están disponibles mientras están apagadas.
+
+**Metadatos de uso del razonamiento (disponibles desde la versión 2.90.0).** Para los clientes HTTP/SSE de la ruta canónica de ChatGPT, el relé WebSocket conserva el encabezado real de respuesta de conexión `x-reasoning-included` cuando Bun lo expone, también al reutilizar una conexión. Este encabezado indica a Codex que el uso informado por el servidor ya incluye el razonamiento anterior. Los metadatos recibidos antes del primer evento de Responses tienen prioridad; los posteriores permanecen en el flujo, pero no pueden modificar los encabezados ya enviados. El relé no inventa esta señal ni altera las cifras de uso. La ausencia de la señal del servidor y el ciclo de contabilización propio de Codex son problemas distintos: este cambio por sí solo no demuestra que se haya corregido la compactación anticipada. Las conexiones WebSocket del cliente ya completaron su actualización de protocolo antes de la respuesta del servidor de origen y no pueden recibir la señal retroactivamente como encabezado de esa actualización.
+
+El control local del ritmo de solicitudes también puede retrasar una solicitud antes de enviarla. Por eso, una primera salida lenta puede tener varias causas, entre ellas la cola del proveedor de origen. `ocx doctor` clasifica la configuración, pero no mide esos tiempos: compara el transporte real, el control de ritmo, la red y las observaciones del proveedor antes de sacar conclusiones.
+
+Lo que decide si una solicitud toma ese canal público es el destino al que se resuelve, no el nombre de la entrada del proveedor. Un proveedor que resuelve en otro lugar - `openai-apikey`, o una entrada personalizada que apunta a su propia API — llega a ese punto final directamente y no ve ChatGPT en cola. Una entrada con nombre personalizado que se resuelve en `https://chatgpt.com/backend-api/codex` con auth directo toma el mismo canal público que la fila incorporada, porque la clasificación lee el adaptador, el modo de auth y el destino en lugar del nombre de la entrada.
+
+La pista `ocx doctor` es más estrecha que el comportamiento del punto final que describe: solo inspecciona la fila `openai` incorporada, por lo que su ausencia no le dice nada sobre dónde se resuelve cualquier otro proveedor.
+
+`service_tier: priority` es una preferencia de solicitud. En el backend ChatGPT el `service_tier` echo no puede confirmar o denegar el nivel concedido: los giros programados como prioridad aún pueden hacer eco `default`, por lo que los registros de solicitud muestran el nivel de respuesta como una observación con confirmación `assumed`. Para el trabajo sensible a la latencia, compare los tiempos de primera salida observados entre los proveedores que realmente usa en lugar de asumir que cualquier canal en particular es más rápido.
+
+Para un reenvío de puerta de enlace a un backend con la misma limitación de metadatos, declare explícitamente [`responseTierAuthoritative: false`](/es/reference/configuration/providers/#response-service-tier-authority) en ese proveedor. La solicitud sigue enviando prioridad y registra el eco sin procesar, mientras que la programación rápida real permanece sin confirmar. Las pasarelas no declaradas y el oficial API mantienen su interpretación existente basada en la respuesta. La actualización de OpenCodex por sí sola no agrega esta declaración a las entradas de pasarela existentes: sin ella, una solicitud de prioridad elegible seguida de un eco `default` todavía registra `response-declined`.
+
+El proxy escucha en el puerto `10100` por defecto y sirve `POST /v1/responses`, `POST /v1/responses/compact`, `POST /v1/images/generations`, `POST /v1/images/edits`, `GET /v1/models`, `GET /healthz` y la superficie de gestión `/api/*`.
+
+<a id="experimental-context-management-codex-0153"></a>
+
+### Gestión de contexto experimental (Codex 0.153+)
+
+Para una cuenta ChatGPT elegible, habilite la función experimental en el propio Codex de `config.toml` (combine esto en una tabla `[features]` existente):
+
+```toml
+[features]
+context_management.experimental_mode = true
+```
+
+En la integración de loopback integrada predeterminada, el siguiente inicio `ocx sync` o proxy cambia la raíz administrada `openai_base_url` a `http://127.0.0.1:10100/backend-api/codex`. Codex comprueba esta ruta de fondo antes de habilitar sus herramientas `new_context`, historial y notas. Iniciar una nueva sesión Codex después de la sincronización. La función sigue siendo opt-in; las URL base propiedad del usuario y la inyección remota de proveedor personalizado no se reescriben. No se necesita o se añade una anulación de ventana de contexto o límite de compactación.
+
+El prefijo del backend crea un alias de las rutas de plano de datos existentes, incluidas las actualizaciones de protocolo a WebSocket de Responses. Las rutas `/v1` originales y la anulación de la banda lateral en tiempo real siguen disponibles. El proxy también retransmite los diez puntos finales POST nativos `alpha/history/v2/*` y `alpha/notes/v2/*` a través del proveedor `openai` incorporado con el adaptador `openai-responses` y el destino directo canónico de ChatGPT. Direct usa el inicio de sesión o portador principal actual del llamante; Pool selecciona una cuenta Codex. `openai-apikey` usa su clave API configurada, y los proveedores Responses personalizados o no canónicos no son candidatos para este contexto y no reciben credenciales de cuenta Codex. Estos puntos finales privados no los implementan otros proveedores de modelos ni la ruta de clave API de OpenAI.
+
+Los encabezados de llamada están restringidos a la lista de permisos de reenvío Codex compartida: `authorization`, `chatgpt-account-id` y los metadatos de protocolo OpenAI beta, originador, sesión y Codex aprobados. El relé de contexto reenvía adicionalmente `x-openai-encrypted-tool-arguments` y `x-openai-tool-output-truncation-policy`; no se reenvían encabezados de llamada arbitrarios tales como cookies. Una clave de plano de datos proxy presentada como portadora se reemplaza con la credencial Codex seleccionada (el inicio de sesión principal almacenado en Direct); las credenciales faltantes fallan antes del reenvío. Las credenciales de admisión de proxy nunca van hacia arriba. Los argumentos cifrados, los cuerpos de respuesta y los estados de error ascendentes se conservan.
+
+Una respuesta de modelo ChatGPT exitosa registra la cuenta de servicio real de la sesión raíz en un registro de propiedad local de proceso limitado. El historial y las notas usan ese propietario registrado, incluida una cuenta seleccionada explícitamente, incluso cuando cambia la cuenta activa actual. La actualización del token de cuenta almacenada puede continuar para la misma cuenta física; se rechaza una identidad de cuenta reemplazada. Direct sesiones propiedad de la persona que llama mantienen la credencial de la persona que llama y no pueden ser tomadas por un portador proxy. Esto no migra el historial del lado del servidor entre cuentas.
+
+La propiedad está dividida por la clave API opencodex que admitió la solicitud, por lo que dos claves nunca llegan a las sesiones de la otra incluso cuando ambas se resuelven en el mismo espacio de trabajo ChatGPT. Un identificador de espacio de trabajo nombra a una persona, por lo que el registro también vincula al usuario estable que lleva la credencial aceptada: una actualización de token ordinaria para ese mismo usuario continúa la sesión, mientras que un usuario diferente en el mismo espacio de trabajo no lo hace. Cuando la credencial aceptada no demuestra ser un usuario estable, solo continúa esa credencial exacta. Ese principal es la clave opencodex API que presenta la solicitud. Un enlace remoto ya requiere uno, por lo que la propiedad funciona allí. En el enlace de bucle de retorno predeterminado opencodex admite solicitudes sin leer una clave, y la inyección de bucle de retorno incorporada no puede llevar la cabecera `x-opencodex-api-key`, por lo que Codex no presenta ninguna clave opencodex y el historial de contexto devuelve HTTP 403. **Por lo tanto, el relé está disponible en un enlace remoto con una clave configurada, o a un cliente que envía el propio `x-opencodex-api-key`, y no a través de la integración de bucle invertido incorporada predeterminada.** Si un proxy enlazado a bucle debería poder nombrar a un llamador es una decisión de mantenimiento abierta, por lo que el comportamiento actual se niega en lugar de adivinar.
+
+La propiedad desconocida, vencida, desalojada, conflictiva o reiniciada-perdida devuelve HTTP 409 antes de la selección de la cuenta o la E/S ascendente. El relé no adivina a partir de la cuenta activa actual. Las sesiones existentes deben guardar un punto de control u otro resumen duradero antes de habilitar la función o restablecer el contexto. Habilitarlo no rellena la historia anterior o las notas, y una nueva observación de propiedad no prueba que exista contenido backend más antiguo. Después de reiniciar, establezca la propiedad con una solicitud de modelo exitosa antes de usar herramientas de contexto; inicie una nueva sesión cuando haya conflictos de propiedad.
+
+La afinidad del modelo existente, el tiempo de reutilización y las reglas de reintento no cambian. Las solicitudes de contexto no se vuelven a intentar automáticamente, incluidas las escrituras de notas; Las solicitudes de reenvío ChatGPT no usan la repetición 429 de la misma clave. El tráfico del historial no consume ni establece una sonda de recuperación de cuotas del modelo.
+
+Un plazo de 35 segundos cubre toda la operación de retransmisión, comenzando antes de que se lea el cuerpo de la solicitud y cubriendo la selección de credenciales, por lo que un cliente estancado no puede mantener abierta una ranura de giro admitida. Una desconexión de cliente devuelve 499 y una fecha límite caducada devuelve 504; nada se despacha aguas arriba después de ninguna de las dos.
+
+Para deshabilitar la función, quite la clave experimental (o configúrela en `false`), ejecute `ocx sync` e inicie una nueva sesión Codex. La base raíz administrada vuelve a `/v1`.
+
+Mientras que la clave está ausente o `false`, el relé no existe: los diez puntos finales responden 404 para cualquier persona que llama, incluido uno que los publica directamente, y un modelo no registra ninguna propiedad del historial. opencodex decide esto leyendo la propia configuración Codex, por lo que el switch no depende de la URL inyectada ni de nada de lo que envíe un cliente, y desactivarlo entra en vigencia sin reiniciar.
+
+<a id="hosted-image-results-in-codex-app"></a>
+
+### Resultados de imágenes alojadas en la aplicación Codex
+
+Cuando un proveedor Responses encaminado devuelve un `image_generation_call` alojado completado con datos de imagen base64, opencodex guarda la imagen validada en su directorio local `artifacts/` y entrega un mensaje de imagen de asistente final a un cliente Codex conectado localmente. La imagen permanece fuera de la sección de progreso plegable. Esto se aplica a la transmisión y no transmisión Responses, sin otra solicitud de generación o un cambio en el proveedor seleccionado.
+
+Cuando un cliente reproduce estos mensajes de imagen generados como historial asistente, opencodex reemplaza sus enlaces de imagen local generados con referencias de artefactos opacos antes de reenviar ese historial. Esto protege las rutas de visualización sin cambiar el mensaje de imagen que ya se muestra en la aplicación. No elimina rutas no relacionadas suministradas por el usuario.
+
+Esta compatibilidad de pantalla requiere la admisión de loopback y un cliente Codex reconocido. Los clientes remotos y genéricos de API conservan el formato de respuesta alojado del proveedor. Las previsualizaciones parciales y los resultados solo de URL no se representan en esta capa de compatibilidad. Los artefactos usan el límite de retención existente, así que guarda las imágenes que quieras conservar antes de que se eliminen los archivos antiguos. Una imagen no válida o una escritura local fallida produce un mensaje de error visible en lugar de un enlace de imagen roto. Los lotes de visualización rechazan identidades de imagen duplicadas, metadatos de enrutamiento sobredimensionados y salidas que exceden el límite de bytes de visualización; estos fallos devuelven HTTP 502 antes de la transmisión o un evento de terminal fallido después de que se inicia.
+
+<a id="built-in-image-generation-image_gen"></a>
+
+### Generación de imágenes incorporada (`image_gen`)
+
+La herramienta incorporada `image_gen` de Codex no pasa por `/v1/responses`: la extensión de codex-rs envía `POST` a `{base_url}/images/generations` (o `/images/edits` cuando se adjuntan imágenes de referencia) directamente, con la misma autenticación de portador de ChatGPT que usa para el chat. Como el `base_url` inyectado apunta a opencodex, el proxy retransmite esas llamadas al servidor ascendente de OpenAI.
+
+Esto es independiente del [Puente de imagen](/es/guides/image-bridge/), que solo se activa cuando un giro **Responses** enumera la herramienta `image_generation` alojada mientras se selecciona un modelo no OpenAI. Las llamadas independientes `/images/generations` nunca entran en ese puente.
+
+- **Un candidato avanzado con conciencia de modo:** Pool selecciona una cuenta principal/añadida elegible y usa su credencial ChatGPT almacenada incluso cuando el cliente se autentica en opencodex con un portador de admisión proxy. Direct usa el portador ChatGPT OAuth del llamante y no puede reenviar un token de admisión proxy. El modo configurado se aplica consistentemente a la solicitud de imagen.
+- **Proveedor de clave API de OpenAI:** solo se usa cuando ningún candidato a reenvío tiene un fallo de autenticación. Una credencial de grupo rota o expirada nunca se oculta detrás de un uso de API facturado por separado.
+- **Proveedor personalizado explícito:** establezca `images.provider` en el id de un proveedor personalizado `openai-responses` de clave API cuyo punto final implemente la API de imágenes de OpenAI. La selección explícita falla de forma cerrada y nunca recurre a otro flujo ascendente de pago. Los ids de proveedor administrados por el registro no se aceptan aquí; omita `images.provider` para usar los niveles integrados de OpenAI.
+- **xAI Imagine (Grok OAuth) relé:** cuando `images.bridgeEnabled` es `true`, se omite `images.provider`, y se configura un proveedor `xai`, `/v1/images/generations` y `/v1/images/edits` se envían a `https://api.x.ai/v1`. La credencial depende del `authMode` del proveedor: con `"oauth"` el relé reutiliza la concesión Grok CLI de `ocx login xai`; con cualquier otro modo usa la clave API del proveedor. Un inicio de sesión OAuth no arma un proveedor con llave, y viceversa. ChatGPT credenciales no se reenvían. Si falta la credencial, el proxy devuelve 400 en lugar de la facturación ChatGPT. El ajuste `images.provider` le da explícitamente `/v1/images` a ese proveedor; sus propios errores de validación se devuelven tal cual y el relé xAI nunca se intenta. El relé mapea Codex `size` / `aspect_ratio` en el cuerpo Imagine de xAI y devuelve la misma forma `{created, data:[{b64_json}]}`. Los bytes decodificados combinados y la salida codificada en base64 a través del lote (en línea `b64_json` y las URL descargadas) permanecen por debajo de 100 MiB; un lote que excedería ese límite devuelve 502. Cuando xAI devuelve una URL de imagen en lugar de bytes en línea, el proxy la obtiene sin credenciales: la URL debe ser pública HTTPS (sin redirecciones, no `file:`, sin bucles de retorno o direcciones privadas), cada descarga tiene un límite de 50 MiB y el resultado se materializa como un artefacto local que se sirve solo a través del punto final de administración autenticado. Esto es independiente del bucle de puente de imagen Responses (que permanece API solo clave).
+- **Google Antigravity (CCA) fallback:** cuando no se configura ni un candidato directo OpenAI ni un proveedor con clave, `/v1/images/generations` (no `/images/edits`) vuelve al punto final Antigravity **Asistencia de código en la nube** usando el modelo `gemini-3.1-flash-image`. La reserva también se activa después de que falla la resolución de autenticación OpenAI (por ejemplo, una credencial ChatGPT caducada o faltante), no solo cuando no se configura ningún candidato OpenAI. Esto requiere `ocx login google-antigravity`; el token OAuth se envía solo al host del registro CCA anclado, nunca a una anulación de nivel de configuración `baseUrl`. La respuesta se devuelve en la misma forma `{created, data:[{b64_json}]}` que Codex espera.
+- **Tampoco:** el proxy devuelve un error claro en lugar de un 404 genérico. Los proveedores enrutados (Cursor, Gemini, Kiro,...) no pueden servir el relé de la herramienta `image_generation`; si no desea que la herramienta se ofrezca en absoluto, desactívela en Codex con `codex features disable image_generation` ( `[features] image_generation = false` en `config.toml` ).
+
+La declaración de la herramienta sigue viajando con la solicitud Responses del modelo. En proveedores Responses con clave API, opencodex reduce el espacio de nombres privado `image_gen` de Codex a un alias seguro aguas arriba, `image_gen__<inner-name>` (por ejemplo `image_gen__imagegen`). Cuando ese alias utilizable sustituye la declaración del cliente, opencodex elimina una declaración duplicada de `image_generation` alojada. Asigna la llamada a la función al espacio de nombres explícito `image_gen` antes de que Codex la vea, y vuelve a codificar la llamada nativa cuando más adelante se reproduce el historial aguas arriba. Esto mantiene invocable la generación de imágenes del lado del cliente en flujos ascendentes compatibles con la API pública que reservan ese espacio de nombres o rechazan los nombres de función con puntos. El modo de reenvío ChatGPT permanece intacto y conserva su forma nativa de Responses Lite.
+
+Para una puerta de enlace personalizada compatible con OpenAI, configure un proveedor dedicado y selecciónelo solo para solicitudes de imágenes independientes:
+
+```json
+{
+  "providers": {
+    "custom-images": {
+      "adapter": "openai-responses",
+      "baseUrl": "https://gateway.example.com/v1",
+      "authMode": "key",
+      "apiKey": "${IMAGE_GATEWAY_API_KEY}"
+    }
+  },
+  "images": {
+    "provider": "custom-images",
+    "timeoutMs": 300000
+  }
+}
+```
+
+El punto final personalizado debe aceptar `POST /v1/images/generations` y `/v1/images/edits` y devolver la forma de respuesta de Imágenes OpenAI esperada para Codex. La clave configurada por el proveedor reemplaza cualquier portador de llamada antes de la solicitud ascendente.
+
+> **Nota:** Esto se refiere solo a la herramienta Codex `image_generation` (relé `/images/generations`). Gemini modelos que son capaces de producir imágenes en línea de forma nativa a través del adaptador `google` (vía `responseModalities: ["TEXT", "IMAGE"]`), independiente de este relé - ver [Adaptadores](/es/reference/adapters/#google).
+
+Para un `hostname` sin bucle, Codex debe enviar la cabecera de autenticación API generada. Por lo tanto, el inyector utiliza un proveedor dedicado en su lugar:
+
+```toml
+# root keys
+model_provider = "opencodex"
+model_catalog_json = "/absolute/path/to/opencodex-catalog.json"
+
+# appended at the end of the file
+# Auto-injected by opencodex (undo: ocx restore)
+[model_providers.opencodex]
+name = "OpenCodex Proxy"
+base_url = "http://your-host:10100/v1"
+wire_api = "responses"
+requires_openai_auth = true
+env_key = "OPENCODEX_API_AUTH_TOKEN"
+# supports_websockets = true   # only when config.websockets is true
+```
+
+Cuando OpenCodex posee enrutamiento, ambos modos escriben `$CODEX_HOME/opencodex.config.toml` como una configuración de referencia/retroceso. En loopback contiene las claves de raíz que puede combinar manualmente si se eliminó la inyección automática; en non-loopback contiene el formulario de proveedor dedicado. El modo de proveedor externo deja este perfil intacto.
+
+Al reconstruir ese archivo se conservan las claves simples de la raíz que OpenCodex no administra. Por ejemplo, `stream_idle_timeout_ms` y `stream_max_retries` sobreviven a la siguiente inyección. Cada asignación conservada se copia tal como está escrita, incluidos valores de varias líneas y enteros de 64 bits, y se coloca antes de la primera tabla. No se conservan las claves de tablas ni las claves raíz con puntos, como `a.b = 1`. OpenCodex prevalece en cualquier colisión: reescribe `model_provider`, `model_catalog_json` y `openai_base_url` según el modo de enrutamiento. También elimina una clave raíz cuyo nombre coincide con una tabla que escribirá el perfil, como un `features = { ... }` en línea si el perfil escribe `[features]`. Si el archivo cambia mientras la inyección espera el bloqueo de escritura, la operación termina con un error reintentable y conserva tu edición.
+
+:::caution
+Claves de raíz como `openai_base_url`, `model_provider`, y `model_catalog_json` **debe** sentarse antes de la primero `[table]` cabecera. El inyector garantiza esa colocación, elimina su propio rancio / duplicado copia, y nunca sobrescribe una raíz propiedad del usuario `openai_base_url`; si existe, la sincronización actualiza el catálogo, pero informa que el enrutamiento no fue inyectado.
+:::
+
+La sincronización y la restauración también conservan el `model_context_window` raíz: OpenCodex nunca escribe esa clave. Codex la usa en lugar de la ventana de catálogo de cada modelo, limitada al máximo de ese modelo. Elimínala tú mismo si quieres que cada modelo muestre su propia ventana.
+
+<a id="shared-model-catalog"></a>
+
+## Catálogo de modelos compartido
+
+Codex CLI, TUI, App y SDK leen todos la misma casa Codex. opencodex resuelve ese directorio desde `CODEX_HOME`, volviendo a `~/.codex`, y gestiona:
+
+```text
+$CODEX_HOME/config.toml
+$CODEX_HOME/opencodex.config.toml
+$CODEX_HOME/opencodex-catalog.json
+$CODEX_HOME/models_cache.json
+```
+
+En macOS, opencodex comprueba el CLI incluido en la app de Codex en `/Applications/ChatGPT.app` y luego en `~/Applications/ChatGPT.app` tras selecciones explícitas, shims, PATH, instalaciones establecidas y el respaldo del `codex` simple ejecutable; exige que la identidad XML `Info.plist` del paquete sea `com.openai.codex` y nunca reemplaza automáticamente una selección persistente ejecutable por un candidato de aplicación. Cuando no se encuentra ningún CLI de Codex, la sonda de catálogo que respalda la disponibilidad de `ocx connect status` también prueba esas ubicaciones incluidas en la aplicación. Así, un Child cuyo único Codex sea el CLI incluido informa sus niveles de razonamiento en vez de `unverified`; cada ejecución sigue pasando las comprobaciones siguientes.
+
+Las comprobaciones de ejecución también reconocen `Codex.app` y `ChatGPT.app` en cualquier ubicación, incluidos los paquetes trasladados, las selecciones explícitas de `CODEX_CLI_PATH` o los comandos de ejecución configurados y los alias mediante enlaces simbólicos. Un nombre reconocido activa la verificación; no concede confianza. Antes de cada ejecución, el paquete canónico y el binario exacto deben superar la verificación estricta de firmas con el Team ID de OpenAI y la política de propiedad, permisos y directorios antecesores. El binario debe resolverse dentro de `Contents/` del paquete (incluido `Codex.app/Contents/Resources/codex-aarch64-apple-darwin`); los paquetes o binarios que no puedan resolverse se rechazan. Las CLI ajenas a paquetes de aplicaciones y los paquetes de terceros conservan su política de ejecución existente.
+
+En WSL, si `CODEX_HOME` está desactivado y el directorio Linux `~/.codex` está ausente o no mantiene el estado Codex (`config.toml`, `auth.json`, `sessions`, `history.jsonl`), opencodex también comprueba un único inicio de escritorio Windows Codex en `/mnt/c/Users/*/.codex/config.toml`. Cuando existe exactamente un candidato, utiliza ese directorio para que el modo de servidor de aplicaciones WSL y el escritorio Windows Codex compartan los mismos archivos de configuración y autenticación. Establecer `CODEX_HOME` explícitamente para anular esta detección. Cuando Windows Codex Desktop ejecuta su aplicación-servidor dentro de WSL, envía el binario Linux Codex bajo esa casa como `bin/wsl/<hash>/codex`; opencodex lo encuentra allí cuando el PATH de servicio no tiene `codex`, después de cualquier entorno de ejecución y PATH configurados explícitamente.
+
+Si el home de Codex existe pero Codex no ha escrito `config.toml` (por ejemplo, una nueva instalación de escritorio que nunca se ha iniciado sesión en OpenAI), opencodex crea allí un `config.toml` vacío y continúa. Si el directorio principal en sí no existe, inicie Codex una vez para que lo cree o establezca `CODEX_HOME`.
+
+Codex puede mantener el estado del subproceso respaldado por SQLite en un directorio separado. Las operaciones de la historia OpenCodex usan la misma precedencia que Codex: raíz `sqlite_home` en `config.toml`, luego `CODEX_SQLITE_HOME`, luego el efectivo `CODEX_HOME`. Los homes de SQLite relativos se resuelven desde el directorio de trabajo actual. Cuando un `CODEX_SQLITE_HOME` explícito está presente durante la instalación o reparación del servicio, el lanzador durable almacena su ruta absoluta de tiempo de instalación de modo que el proxy de segundo plano continúa direccionando la misma base de datos. Si `config.toml` o su clave raíz `sqlite_home` está ausente, OpenCodex continúa con la reserva de entorno/home. Si el archivo no se puede leer o analizar, o la clave está presente pero en blanco o no una cadena, la resolución del home de SQLite se detiene en lugar de arriesgar las operaciones del historial contra una base de datos diferente.
+
+En Windows, un shell de Orca puede establecer `CODEX_HOME` y `ORCA_CODEX_HOME` en el hogar en entorno de ejecución incluido de Orca, mientras que la aplicación ChatGPT / Codex todavía lee `%USERPROFILE%\\.codex`. `ocx status` y `ocx doctor` advierten sobre este desajuste exacto y las rutas de destino redactadas por impresión. Si se instaló un servicio en segundo plano desde ese shell de Orca, desinstálelo primero desde el shell original, luego configure `CODEX_HOME` en el inicio de la aplicación, desactive `ORCA_CODEX_HOME`, vuelva a ejecutar la sincronización / restauración e instale el servicio nuevamente.
+
+En el modo de proveedor dedicado, `requires_openai_auth = true` mantiene Codex App / TUI superficies cerradas por cuenta alineadas con Codex nativo. opencodex también sirve `/v1/responses` sobre WebSocket. El proveedor dedicado anuncia `supports_websockets = true` solo cuando `"websockets": true`; en loopback, el proveedor incorporado de Codex puede intentar WebSocket primero, y un proxy deshabilitado devuelve `426` así Codex cae de nuevo a HTTP / SSE.
+
+El proxy admite hasta 128 conexiones Responses WebSocket orientadas al cliente. Cuando una nueva conexión encuentra las 128 ranuras ocupadas, cierra la conexión inactiva menos recientemente utilizada para hacer espacio. Las conexiones con una respuesta activa, una herramienta de cliente pendiente o resultados de aprobación, una sesión de dirección/inyección nativa o una salida almacenada en búfer están protegidas. Si no se puede liberar ninguna conexión inactiva, la nueva conexión recibe la respuesta de capacidad `503` existente. Un cliente reclamado puede volver a conectarse para solicitudes posteriores utilizando el manejo de continuación existente. Esto sucede solo bajo presión de conexión, no necesita configuración y no cambia las conexiones de voz o la reutilización de la conexión ascendente.
+
+Si una continuación canónica hacia adelante ChatGPT hace referencia a un estado de repetición local caducado o faltante, opencodex devuelve `previous_response_not_found` antes de enviar cualquier cosa aguas arriba. El cliente Codex de WebSocket reconoce este error y puede volver a conectarse con su contexto completo retenido, incluyendo llamadas de herramientas completadas y sus resultados, dentro de su presupuesto de reintento de flujo normal. Por lo tanto, una tarea inactiva no necesita una tarea nueva únicamente porque la caché de reproducción del proxy expiró. El estado de continuación reproducido se conserva durante 24 horas y permanece limitado por su memoria, disco y límites de entrada existentes; esto no recupera el historial que el cliente ya no tiene. HTTP clientes deben manejar el error explícitamente y volver a enviar su contexto completo sin `previous_response_id`. Volver a intentar solo el mismo ID no puede recuperar el estado faltante.
+
+El mismo rechazo se aplica cuando el estado referenciado pertenece a un ámbito de tarea cliente diferente, incluso cuando la nueva solicitud parece llevar entrada completa. El proxy no puede probar que la entrada está completa, por lo que no elimina silenciosamente `previous_response_id` ni revela si existe un estado coincidente. Vuelva a intentar con la conversación completa y omita `previous_response_id`; los ámbitos coincidentes y las continuaciones heredadas donde ambos ámbitos están ausentes o en blanco continúan reproduciéndose normalmente.
+
+La misma señal de recuperación se aplica a cada destino enrutado, porque solo el paso a través nativo Responses puede responder a un giro cuya historia perdió este proxy: reenvía `previous_response_id` a un backend que almacenó la cadena. Cada uno de los otros cables reconstruye la conversación a partir de la propia entrada de cada solicitud, por lo que una expansión perdida allí enviaría el giro actual solo y perdería silenciosamente la conversación. Eso incluye los tres que parecen con estado: Devin vuelve a enviar toda la conversación a cada paso, la referencia de punto de control de Cursor vive en la misma tienda vencida y vuelve a la reproducción completa sin ella, y Kiro reconstruye su historial de conversaciones a partir de los turnos en que se entregó. También se aplica a los proveedores enrutados Responses configurados con `statelessResponses: true`, y a las solicitudes enrutadas donde una herramienta personalizada se redujo a una función pero un resultado delta no tiene llamada local para establecer su tipo original. La reproducción completa conserva la llamada, el resultado y el razonamiento juntos; opencodex no adivina el tipo de resultado ni lo descarta. Los proveedores estatales todavía resuelven la función nativa y las continuaciones personalizadas nativas por sí mismos. Estas comprobaciones siguen el protocolo de cable seleccionado y las declaraciones de la herramienta, no el nombre del modelo. Para una puerta de enlace que no puede resolver los ID de respuesta almacenados, habilite `statelessResponses` en ese proveedor; otros proveedores mantienen sus valores predeterminados.
+
+<a id="client-side-compaction-opt-in"></a>
+
+### Compactación del lado del cliente (opcional)
+
+El enrutamiento de bucle de retorno autenticado normalmente mantiene Codex en su identidad de proveedor `openai` incorporada. Eso preserva la identidad del hilo nativo, pero también hace que Codex solicite la compactación remota nativa. Cuando un proveedor enrutado no puede devolver una burbuja de compactación nativa, OpenCodeX almacena el resumen en su propio sobre `ocx1:` / `ocx2:`. Native ChatGPT no puede verificar ese sobre si OpenCodeX se elimina más tarde de la ruta de la solicitud.
+
+En una ruta de bucle de retorno autenticada, habilite la compactación en el lado del cliente para mantener el enrutamiento de subagentes V2 al tiempo que evita nuevos resúmenes de compactación `ocx1:` / `ocx2:`. Las rutas que no son de loopback y las de clave API conservan su comportamiento de proveedor y autenticación existente:
+
+```bash
+ocx system settings --client-compaction on   # or "codexClientCompaction": true in config.json
+ocx sync                                     # rewrites the active config (default: ~/.codex/config.toml); restart Desktop
+```
+
+El ajuste predeterminado es off. Para el enrutamiento de bucle de retorno autenticado, OpenCodeX selecciona su formulario de proveedor dedicado existente con `requires_openai_auth = true`. Si `codexDesktopAuthless` también está habilitado, esa configuración de compatibilidad más fuerte tiene prioridad y escribe `requires_openai_auth = false`:
+
+```toml
+model_provider = "opencodex"
+
+[model_providers.opencodex]
+name = "OpenCodex Proxy"
+base_url = "http://127.0.0.1:10100/v1"
+wire_api = "responses"
+requires_openai_auth = true
+```
+
+Codex luego posee compactación y almacena un resumen de texto plano portátil en lugar de un nuevo sobre OpenCodeX. La solicitud de compactación sigue enrutando a través de OpenCodeX y puede consumir cuota en el proveedor seleccionado. Las solicitudes de subagentes V2 mantienen su selección de proveedores existente y la contabilidad de cuotas. La compactación del lado del cliente no cambia la entrega de texto sin formato, el paso de tareas encriptadas a través de `allowEncryptedV2AgentTasks` o el comportamiento de recuperación y recuperación configurado.
+
+Esta preferencia solo afecta las compactaciones futuras, y no reescribe ninguna carga útil `ocx1:` / `ocx2:` existente en ninguna configuración, así que use el flujo de trabajo de recuperación de historial explícito para un subproceso que lo necesite.
+
+Si se vuelven a etiquetar los metadatos del historial de reanudación depende de la forma que tome la inyección. Por sí solo, en un enlace de bucle de retorno autenticado, la compactación del lado del cliente no vuelve a etiquetar nada: mantiene la anulación de raíz, como se describe a continuación. Habilitado junto con `codexDesktopAuthless`, o en un enlace que no sea de bucle invertido, el formulario más fuerte gana y esos formularios se comportan exactamente como lo hacen hoy, incluido su etiquetado hacia adelante existente del historial de reanudación con originales respaldados para su restauración.
+
+Volver de una de esas formas a Diseño B simple migra los hilos reetiquetados hacia atrás. Apagar `codexDesktopAuthless` mientras se deja la compactación del lado del cliente encendido no lo hace: eso aterriza en la forma de solo compactación, que se salta la unidad de historial, por lo que los hilos ya etiquetados `opencodex` mantienen esa etiqueta. Todavía llegan a este proxy, a través de la tabla del proveedor en lugar de la anulación de la raíz.
+
+En la forma de solo compactación, los hilos existentes siguen funcionando porque la inyección mantiene la raíz `openai_base_url` junto a la tabla de proveedores. Los hilos nuevos usan `opencodex` de forma predeterminada y obtienen compactación del lado del cliente, mientras que un hilo ya etiquetado `openai` todavía se resuelve en el proveedor integrado de Codex, al que la anulación retenida sigue apuntando a este proxy. Sin ella, ese hilo se reanudaría contra OpenAI directamente y se llevaría consigo el enrutamiento configurado. Las formas sin autenticación y fuera de loopback no pueden usar la clave raíz, por lo que siguen reetiquetando.
+
+Esa garantía cubre la anulación que administra OpenCodeX. Una raíz `openai_base_url` que escribió usted mismo nunca se reemplaza, y en ese caso el proveedor integrado mantiene el destino que eligió, por lo que un hilo etiquetado `openai` sigue su configuración en lugar de este proxy. Desactivar el ajuste y la sincronización elimina la tabla y vuelve a la anulación de diseño B simple, a menos que la admisión `codexDesktopAuthless` o no loopback aún requiera el formulario de tabla de proveedor; esos dos formularios no pueden usar la clave raíz y no se modifican.
+
+Mientras el modo está activo, la anulación de banda lateral de voz en tiempo real (`experimental_realtime_ws_base_url`) no se inyecta - el formulario dedicado de tabla de proveedores no puede llevarlo - por lo que Codex Desktop Voice utiliza su punto final nativo en lugar del proxy.
+
+<a id="emergency-compaction-model-opt-in"></a>
+
+### Modelo de compactación de emergencia (opcional)
+
+Cuando OpenCodeX traduce la compactación remota para proveedores como Google, reemplaza las imágenes de giros anteriores con notas cortas de reapertura si existe una respuesta final explícita posterior. El análisis existente y las referencias de archivo permanecen en la entrada de resumen; las imágenes después de la última respuesta final permanecen disponibles para el trabajo no resuelto. Se conservan las historias sin fase y solo comentarios. Esto afecta solo a la solicitud de compactación, no a los archivos adjuntos almacenados o a las solicitudes de modelo ordinarias. Reduce la entrada de visión repetida, pero no garantiza que un largo historial de texto se ajuste al límite de contexto del proveedor.
+
+`compactionRecovery` deja la compactación inicial en la ruta seleccionada de la conversación. Permite un intento de emergencia solo después de un fallo de compactación previo a la salida soportado. Está separado de `compactionRouting`, que elige otro modelo antes de que comience la compactación, y de `codexClientCompaction`, que cambia la forma del proveedor de Codex.
+
+```json
+{
+  "compactionRecovery": {
+    "enabled": true,
+    "model": "provider/emergency-model",
+    "allowDevinInvalidArgument": false
+  }
+}
+```
+
+Utilice un modelo autorizado configurado independientemente con suficiente contexto para la entrada fallida. La habilitación de la recuperación permite al proveedor de ese modelo recibir el historial de compactación y cobrar por el intento adicional cuando se ejecuta la recuperación; las compactaciones exitosas ordinarias no incurren en ninguna llamada adicional. La opción está desactivada cuando está ausente o desactivado. La administración autenticada existente API acepta este bloque a través de `PUT /api/settings`; envíe `compactionRecovery: null` para eliminarlo. Una edición de archivo directa debe seguir el flujo de trabajo normal de configuración de stop-proxy. Esta configuración no cambia el inicio de sesión, el modelo ordinario de la conversación, el ID de proveedor de Codex o el compositor de escritorio.
+
+La recuperación no se reproduce después de la cancelación, la salida semántica, los efectos secundarios de la herramienta, un presupuesto de envío agotado o una autenticación, admisión o rechazo de políticas. Los errores genéricos `400` no habilitan la recuperación. Devin responde a un historial de gran tamaño con una presalida opaca `invalid_argument`; cuando el tamaño estimado de la solicitud está en o cerca de la ventana de entrada del modelo, el adaptador lo informa como `context_length_exceeded` en su lugar, por lo que Codex compacta en un giro ordinario y una compactación fallida califica como un desbordamiento de contexto sin ninguna opción específica de Devin. La estimación utiliza descripciones de herramientas después de la desinfección y truncamiento de Cognition, que coinciden con la solicitud enviada aguas arriba. Una solicitud más pequeña que obtiene el mismo código permanece como `400` simple. El estuche `allowDevinInvalidArgument` por separado cubre solo los `invalid_argument` fallos restantes, y solo en una solicitud de compactación identificada. El intento de emergencia comparte el presupuesto de envío de la solicitud original y nunca comienza un segundo intento de recuperación.
+
+La compactación encriptada nativa está fuera de esta ruta de recuperación: se conserva su error original. No hay modo de truncamiento local automático. Una respuesta aceptada no es prueba de que una larga conversación retuvo sus objetivos; verifique el siguiente turno en el modelo original antes de tratar un resumen de emergencia como una tarea recuperada.
+
+<a id="authless-codex-desktop-opt-in"></a>
+
+### Authless Codex Escritorio (opcional)
+
+En **Dashboard → Visión de conjunto**, **Abrir Codex sin iniciar sesión** controla esta preferencia opt-in existente. El valor predeterminado es **desactivado** cuando la configuración está ausente o es falsa; un `codexDesktopAuthless: true` explícito existente permanece habilitado. El panel de control guarda la preferencia y ejecuta una sincronización completa. Reinicie el escritorio Codex después de cambiarlo. Si falla la sincronización, la preferencia guardada permanece y el panel de control muestra el error; reintente **Sincronización** antes de reiniciar. Las funciones de escritorio controladas por cuenta pueden no estar disponibles cuando se habilitan. Las credenciales ascendentes, la elegibilidad local, la autenticación de admisión remota y la configuración de la puerta de enlace propiedad del usuario conservan sus requisitos existentes.
+
+Codex Desktop muestra su pantalla de inicio de sesión ChatGPT cada vez que el proveedor activo requiere OpenAI auth. Si su configuración OpenCodex nunca usa credenciales ChatGPT (solo proveedores enrutados o un `chatgpt.com` bloqueado), puede optar por salir de esa puerta:
+
+```bash
+ocx system settings --desktop-authless on    # or "codexDesktopAuthless": true in config.json
+ocx sync                                     # rewrites ~/.codex/config.toml; restart Desktop
+```
+
+Con el interruptor activado, un enlace de bucle retro inyecta el formulario de proveedor dedicado en lugar de la anulación raíz `openai_base_url`:
+
+```toml
+model_provider = "opencodex"
+
+[model_providers.opencodex]
+name = "OpenCodex Proxy"
+base_url = "http://127.0.0.1:10100/v1"
+wire_api = "responses"
+requires_openai_auth = false
+```
+
+El escritorio se inicia sin un inicio de sesión y las rutas de cada turno a través del proxy. La configuración sobrevive `ocx start`, reinicio, `ocx sync` y `ocx ensure`; al apagarlo (`--desktop-authless off`) hace que la siguiente sincronización restaure la forma de bucle de retorno predeterminada y `ocx restore` la despoja como cualquier otro enrutamiento inyectado. Qué esperar mientras está encendido:
+
+- La interfaz de escritorio reservada a ChatGPT (cuenta, uso, modo rápido) permanece oculta: Codex deriva esas superficies del requisito de autenticación del proveedor.
+- Los nuevos hilos se etiquetan con el proveedor `opencodex`, como en un enlace no loopback, y el historial se maneja de la misma manera.
+- Las versiones de escritorio que filtran el selector de modelo contra una lista de permitidos solo nativa también pueden mostrar un selector vacío o `Custom` en este modo; las solicitudes siguen usando el modelo configurado. Establezca `model = "<provider>/<id>"` en `config.toml` como se describe en [Servidores remotos de escritorio](/es/guides/codex-app-models/#desktop-remote-servers).
+
+Esto solo cambia la puerta de inicio de sesión del escritorio. Non-loopback obliga a mantener `requires_openai_auth = true` y la credencial de admisión `env_key` independientemente del interruptor; nunca expone un oyente OpenCodex sin autenticación.
+
+<a id="thread-identity-and-history"></a>
+
+## Identidad e historia del hilo
+
+El formulario de loopback predeterminado mantiene los nuevos hilos etiquetados con el proveedor nativo `openai` de Codex, por lo que el historial de reanudación normal no necesita volver a mapear. La sincronización y la restauración aplican solo un manifiesto de copia de seguridad coincidente y restauran el proveedor, la fuente y el marcador de eventos originales exactos de cada subproceso. Una fila desnuda de `opencodex` sin manifiesto se deja sin cambios; use `ocx recover-history --legacy-openai --yes` solo cuando tenga la intención explícita de forzar ese reetiquetado heredado. El comando es intencionalmente amplio: reescribe cada hilo con un mensaje de usuario actualmente etiquetado como `opencodex` a `openai`, normaliza `exec` a `cli` y establece el marcador de evento, incluido el historial legítimo de proveedores dedicados. Haga una copia de seguridad del estado y úselo solo cuando se pretenda ese alcance completo. El modo de proveedor dedicado sin loopback sigue reflejando el historial bajo el proveedor `opencodex` mientras está activo y restaura los metadatos de copia de seguridad al salir. Establecer `syncResumeHistory: false` para dejar la historia intacta.
+
+<a id="model-catalog-sync"></a>
+
+## Sincronización de catálogo de modelos
+
+Codex muestra modelos de un catálogo en el disco (`$CODEX_HOME/opencodex-catalog.json` de forma predeterminada). Al inicio y en `ocx sync`, opencodex:
+
+1. **Respalda** el catálogo prístino una vez a `~/.opencodex/catalog-backup.json` (por lo que la presentación es reversible).
+2. **Muñecos** catálogos de modelos en vivo de los proveedores elegibles (en caché de 5 min; vuelve a la última buena lista, luego configuró `models[]`). La autenticación directa no tiene un punto final modelo, y Cursor utiliza su RPC `GetUsableModels` en lugar de `/models`.
+3. **Combina** los modelos enrutados como entradas con espacio de nombres (`provider/model`), clonadas de una plantilla de catálogo nativo de Codex para que el estricto analizador sintáctico de Codex las acepte.
+4. **Filtros** `config.disabledModels` y la lista de permisos `selectedModels` no vacía de cada proveedor.
+5. **Re-rangos** así que los modelos destacados ordenan primero (ver más abajo), luego escribe el catálogo fusionado de nuevo.
+
+Las entradas del catálogo enrutado también obtienen su identidad GPT-5 reescrita al nombre del modelo ascendente real. Los controles de razonamiento provienen de metadatos de proveedor/modelo en la escalera `low | medium | high | xhigh |
+max | ultra` de Codex; los valores no compatibles se asignan o se fijan antes de la solicitud ascendente.
+
+<a id="coordinator-diagnosis-and-recovery"></a>
+
+### Diagnóstico y recuperación del coordinador
+
+Las escrituras de configuración/historia nativas usan un coordinador por usuario SQLite con la clave canónica `CODEX_HOME`. Si un proceso termina en la ventana de creación inicial de SQLite, puede permanecer un coordinador de cero bytes aunque no contenga ninguna fila de transición autorizada. `ocx doctor` informa la ruta exacta del coordinador y distingue los estados de cero bytes, sin versionar, sin filas, válidos, inseguros e ilegibles sin crear SQLite sidecars. La sincronización automática tolera solo un archivo de byte cero de identidad estable que se ha establecido durante al menos un segundo y cuya instantánea inmutable SQLite tiene la versión cero sin tablas; un archivo de byte cero recién creado permanece en la ruta del coordinador bloqueado.
+
+Para un estado que `doctor` demuestra que es un remanente de creación de cero bytes, detenga el proxy o servicio de OpenCodex y ejecute:
+
+```bash
+ocx doctor --recover-zero-byte-coordinator --yes
+ocx sync
+```
+
+La recuperación mueve el archivo de byte cero todavía idéntico a una ruta del mismo directorio `.zero-byte-backup-*`; no elimina la evidencia ni adopta el estado de ruta heredado. Rechaza un proxy en ejecución, bloquea la contención, vínculos simbólicos / puntos de reparación, propiedad extranjera, archivos cambiados, cada base de datos no vacía y cualquier coordinador que ya tenga una fila autorizada. El filtrado del renderizador de escritorio es una capa separada: un catálogo y un coordinador correctos no evitan por sí mismos la lista de permisos del modelo de aplicación Codex.
+
+<a id="routed-local-tools"></a>
+
+### Herramientas locales enrutadas
+
+Las filas de catálogo enrutadas no nativas usan `tool_mode: "code_mode_only"`. Esto permite que Codex exponga su punto de entrada oficial `exec` y las herramientas anidadas MCP, incluido el navegador y el uso del ordenador, mientras que opencodex solo enruta la llamada de función ordinaria del modelo. La ejecución de la herramienta, los permisos y las confirmaciones permanecen locales en Codex; opencodex no implementa un segundo navegador o ejecutor de control de escritorio.
+
+Para los proveedores de claves Responses que no aceptan la gramática de herramientas personalizadas `exec` de Codex, opencodex codifica esa declaración y su historial como una herramienta de función ascendente, luego restaura el ciclo de vida de llamadas a funciones transmitidas a `custom_tool_call` antes de que Codex lo vea. El enrutamiento directo nativo OpenAI y la herramienta personalizada `apply_patch` soportada permanecen sin cambios.
+
+Si un modelo encaminado envía un parche completo a medida que la entrada `exec` de modo de código completa, opencodex lo convierte a la llamada anidada `tools.apply_patch` antes de que los eventos de finalización de herramienta alcancen Codex. Las llamadas personalizadas nativas y las llamadas a funciones convertidas usan la misma regla de finalización; las vistas previas de parches se mantienen mientras no se resuelve su forma ejecutable. JavaScript que simplemente contiene texto de parche y cargas útiles personalizadas nativas no relacionadas permanecen sin cambios.
+
+Si un modelo enrutado envuelve dos veces el cuerpo ejecutable de una herramienta de formato libre, opencodex elimina una envoltura JSON adicional que contenga únicamente una cadena input. La corrección se aplica a los cuerpos de exec local y apply_patch; deja intactas otras gramáticas y los objetos ambiguos, y no decodifica de forma recursiva. La vista previa en streaming solo se retiene mientras el cuerpo aún pueda resultar ser esa envoltura. El JavaScript que simplemente comienza con un objeto o bloque sigue transmitiéndose a medida que llega.
+
+Un modelo enrutado también puede enviar erróneamente un objeto de argumento de shell como `{"cmd":"git status --short"}` al modo de código `exec`. Para un catálogo de modo de código verificado, opencodex convierte un objeto de shell inequívoco en `tools.exec_command(...)` JavaScript y reenvía su salida a través de `text(...)`. Las opciones de shell se conservan y Codex sigue ejecutando y autoriza el comando. Los campos de reserva de JavaScript válidos, los objetos ambiguos y los espacios de nombres de herramientas no relacionados no se convierten. Esta reparación de compatibilidad no pasa por alto los límites de velocidad del proveedor ni cambia la directiva de reintento configurada.
+
+La misma reparación cubre a los ayudantes de la meta. Un modelo encaminado que llama `create_goal`, `get_goal`, o `update_goal` (o una ortografía prefijada `default.` de uno) como una herramienta mientras el catálogo declara sólo el código-modo `exec` tiene la llamada convertida en la llamada coincidente `tools.<helper>(...)` dentro `exec`. Un catálogo que declara genuinamente la herramienta de objetivo desnudo la mantiene, y un catálogo que declara ni la herramienta ni `exec` todavía rechaza la llamada como no declarada.
+
+En las conversiones enrutadas con un catálogo `exec` de código de forma libre verificado, las llamadas estructuradas enviadas directamente al `mcp__<server>__<tool>` (incluido un prefijo `default.` añadido por el proveedor) también se envuelven como llamadas de herramienta de host anidada. Esto evita un reintento causado únicamente por un modelo que omite la envoltura `exec`. Las herramientas MCP declaradas explícitamente mantienen su comportamiento normal; una función JSON ordinaria llamada `exec` no habilita esta reparación. Las herramientas desconocidas aún fallan en el host. Los registros de llamada de herramienta impresos como texto de respuesta ordinario no se ejecutan según esta regla de compatibilidad.
+
+Para los giros enrutados Responses, una directiva explícita de implementación de herramientas también rechaza las llamadas a herramientas de cliente si el catálogo de herramientas declaradas de la solicitud no está disponible. Un catálogo declarado vacío rechaza cada llamada a la herramienta del cliente; Chat y Anthropic clientes conservan su propia responsabilidad de validación de herramientas.
+
+A los giros en modo código encaminados también se les dicen las reglas del host para los ayudantes anidados antes de la primera llamada: `tools.apply_patch` toma una cadena que se abre y se cierra con las líneas de marcador de parche desnudas, el aislado no tiene `import`, y los comandos de ejecución larga se sondean a través de `write_stdin`. Cuando un resultado ejecutivo en modo código en la ruta nativa Responses, Kiro o Cursor todavía lleva uno de los mensajes de fallo del host, opencodex añade una pista de una línea que nombra la regla. Este cambio no reescribe el código del modelo o su texto de parche.
+
+Las llamadas a funciones de Responses enrutadas ordinarias también usan el esquema de parámetros declarado original al completar: los flotantes enteros en campos enteros y los números enteros en campos de solo cadena se normalizan, mientras que las fracciones y las uniones numéricas permanecen sin cambios. Una cadena de argumentos completada explícitamente vacía se convierte en `{}`. Los eventos finales y el historial de continuación almacenado localmente concuerdan. Las grafías inequívocas de espacios de nombres con puntos se restauran al espacio de nombres declarado y al nombre de la herramienta.
+
+El proveedor seleccionado debe admitir llamadas de función/herramienta. Un proveedor de solo texto sin soporte de llamada de herramienta no puede usar `exec`, Browser o Computer Use. Las filas nativas OpenAI mantienen su modo de herramienta ascendente sin cambios.
+
+Después de que `ocx sync` cambie estos metadatos, reinicie la aplicación Codex y abra una nueva tarea. Los procesos y las tareas existentes del servidor de aplicaciones pueden conservar el catálogo y el plan de herramientas que cargaron al iniciarse.
+
+<a id="inline-visualizations-with-routed-models"></a>
+
+### Visualizaciones en línea con modelos enrutados
+
+El complemento Visualizar de la aplicación Codex le pide al modelo que responda con una referencia envuelta en caracteres de uso privado (U + E200... U+E201). Algunos proveedores eliminan esos caracteres antes de que el modelo los vea, cada ruta Claude que revisamos lo hace, por lo que el modelo solía responder con una línea desnuda `visualize{"path":…}` que la aplicación Codex imprimió como texto.
+
+opencodex reescribe esas referencias en la directiva que la propia aplicación renderiza, `::codex-inline-vis{path="/absolute/path/chart.html"}`, en el texto de conversación enviado a los modelos enrutados. Cualquier modelo puede leer y repetir esa forma, por lo que la visualización se renderiza en línea. Las solicitudes de pases nativas OpenAI se reenvían sin cambios. Las respuestas que ya estaban guardadas en la forma desnuda `visualize{…}` permanecen como están; solicite la visualización nuevamente en una nueva respuesta.
+
+<a id="custom-model-display-names"></a>
+
+### Nombres de visualización de modelo personalizados
+
+Un modelo personalizado puede llevar un **mostrar nombre** legible por humanos que anula la etiqueta Codex muestra en su selector de modelo, sin cambiar nada acerca de cómo se enruta el modelo. El nombre de visualización se asigna solo al campo `display_name` de la entrada del catálogo: la tira de enrutamiento (`<provider>/<model>`), el orden de colisión de alias, el proveedor y los nombres de marketing nativos OpenAI se dejan intactos.
+
+Agregue un nombre de visualización del CLI (el proxy sincroniza el catálogo de inmediato cuando está activo):
+
+```bash
+ocx models add deepseek deepseek-v4 --display-name "DeepSeek V4" --context-window 128000
+```
+
+Para proveedores personalizados, omitir una ventana de contexto explícito permite que el catálogo use el [reglas de respaldo de ventana contextual](/es/reference/configuration/providers/#context-windows-on-custom-providers). Las estimaciones de ID de modelo se aplican solo cuando el proveedor establece `inferContextWindow: true`; establezca una ventana explícita o un límite de contexto cuando el relé admita menos que la ventana del proveedor del modelo.
+
+Los clientes remotos Codex pueden obtener el mismo catálogo generado con una clave ordinaria **plano de datos**: la misma credencial que ya usan para `/v1/responses`, no un token de administración:
+
+```bash
+dest="${CODEX_HOME:-$HOME/.codex}/opencodex-catalog.json"
+tmp="$(mktemp "${dest}.XXXXXX")"
+curl -fsS -H "x-opencodex-api-key: $OPENCODEX_API_AUTH_TOKEN" \
+  "https://proxy.example.com/v1/catalog" > "$tmp" \
+  && mv "$tmp" "$dest"
+ocx sync-cache
+```
+
+La respuesta es el documento sin procesar `opencodex-catalog.json` (sin credenciales de proveedor). Cuando está disponible, el encabezado `x-opencodex-codex-version` informa la versión en entorno de ejecución Codex en el servidor para que los clientes puedan detectar el sesgo de versión.
+
+`GET /v1/catalog` existe para que la lectura de una lista de modelos no cueste un token de administración. Es de solo lectura (`GET` y `HEAD`), acepta `x-opencodex-api-key`, un token portador, o `x-api-key`, y sirve exactamente los mismos bytes que la ruta de gestión. Responses llevar un fuerte `ETag` - pasarlo de nuevo como `If-None-Match` para revalidar y obtener un `304` en lugar del documento completo - y `Cache-Control: private, no-cache`, ya que el cuerpo se sienta detrás de una credencial.
+
+Una clave de plano de datos admitida aquí gana **nada** en el plano de administración: `/api/catalog` y cada otra ruta `/api/*` aún requiere el token de administración o una sesión de tablero. La ruta anterior `/api/catalog` sigue funcionando sin cambios para el panel de control y para los scripts que ya tienen un token de administración.
+
+También puede configurarlo o editarlo a través de la administración API (`POST /api/custom-models`, `PUT /api/custom-models/<id>` con una cadena `displayName`) y el panel de control web. Un `/` es rechazado porque colisionaría con el separador de balas enrutadas.
+
+El nombre que se muestra es **solo pantalla y estable a través de la regeneración**. Cada `ocx sync` y las re-derivas de actualización de catálogo enrutaron las entradas desde `config.json` (incluyendo `customModels`), por lo que el nombre configurado se vuelve a aplicar en lugar de volver a la pista enrutada. Un reinicio del servicio administrado también intenta esta sincronización poco después de que el proxy se une. Si la sincronización de arranque de mejor esfuerzo falla, por ejemplo durante un inicio de sesión sin conexión, el catálogo previamente persistente se conserva y el siguiente `ocx sync` exitoso vuelve a aplicar el nombre configurado. Los nombres nativos aguas arriba genuinos (p. `gpt-5.6-sol` → "GPT-5.6-Sol") provienen de la instantánea de aguas arriba anclada y nunca se reemplazan por un nombre de visualización personalizado.
+
+<a id="external-provider-managers"></a>
+
+### Gerentes de proveedores externos
+
+Si `config.toml` ya selecciona un proveedor distinto de `openai` o `opencodex`, OpenCodex deja el archivo sin cambios y omite escrituras de perfil, actualización de catálogo/caché y restauración de metadatos de historial Codex tanto inmediata como de fondo. Las herramientas que administran un proveedor personalizado a menudo etiquetan las sesiones existentes con ese ID del proveedor; reemplazar el ID activo puede hacer que esas sesiones intactas desaparezcan de la vista del historial de Codex. La misma protección se aplica a un proveedor externo seleccionado por un perfil raíz heredado.
+
+Mientras que un proveedor externo posee `config.toml`, los ajustes informan que `GET /api/settings` y `ocx system settings --json` devuelven una descripción de los switches de compresión de cliente y de escritorio, y el requisito de inicio de sesión Codex, según lo controlado por ese proveedor en lugar de mostrar el estado efectivo que produciría OpenCodex. Al cambiar cualquiera de los switches se sigue almacenando la preferencia, pero `config.toml` no se reescribe; el valor almacenado tiene efecto si cambia Codex de nuevo a un proveedor OpenCodex administra y vuelve a ejecutar `ocx start`.
+
+Si `config.toml` existe pero no se puede leer (permisos, o una carrera de borrado de la lectura), el mismo informe retiene los valores efectivos y la respuesta de inicio de sesión como indeterminada en lugar de mostrar el estado OpenCodex computaría localmente. El registro apply mantiene esa explicación, incluso en un guardado cuya puerta de inyección ya está cerrada por una integración deshabilitada o un proxy detenido, y lo marca como reintentable, por lo que una lectura posterior de `ocx system settings --json` informa la respuesta establecida una vez que el archivo vuelve a ser legible. Con la integración Codex deshabilitada, `ocx sync` es solo para catálogo y no puede aplicarla.
+
+Mantenga una herramienta como propietario de la configuración del proveedor Codex. Para usar OpenCodex detrás de un administrador de proveedores existente, apunte a ese proveedor en `http://127.0.0.1:10100/v1` con Responses passthrough (`wire_api = "responses"` en Codex TOML), no Chat Completions translation. Cuando el proxy API auth está habilitado, también pase `x-opencodex-api-key` de `OPENCODEX_API_AUTH_TOKEN`, que coincide con el formulario de proveedor para enlaces que no son de loopback descrito antes. Para permitir que OpenCodex inyecte el enrutamiento directamente, primero conmuta Codex de nuevo a su proveedor `openai` incorporado y elimina cualquier raíz `openai_base_url` propiedad del usuario, luego vuelve a ejecutar `ocx start`.
+
+<a id="explicit-tool_search-troubleshooting"></a>
+
+### Explícito `tool_search` solución de problemas
+
+Las herramientas locales enrutadas tienen dos rutas de descubrimiento distintas. En el modo de código enrutado normal, Codex puede exponer diferido MCP/herramientas de la aplicación a través del oficial `exec` herramienta `tools` global y `ALL_TOOLS`; ese camino no requiere que el modelo vea o llame `tool_search`.
+
+Por separado, `tool_search` es una superficie de descubrimiento Codex ejecutada por el cliente. No es un indicador de características OpenCodex, y un valor ascendente `tool_choice: "auto"` no lo crea ni lo habilita. OpenCodex puede retransmitir la superficie explícita solo cuando Codex ya incluyó una declaración como esta en la solicitud Responses entrante:
+
+```json
+{
+  "tools": [
+    { "type": "tool_search", "description": "Load deferred tools" }
+  ]
+}
+```
+
+En el caso de los modelos locales/de chat enrutados, OpenCodex expone esa declaración como una función normal denominada `tool_search`. Si el modelo lo llama, OpenCodex convierte la llamada a un Responses `tool_search_call`; Codex ejecuta la búsqueda y proporciona las definiciones de herramienta resultantes en un `tool_search_output` posterior. Las definiciones cargadas de esa manera están disponibles en el siguiente turno del modelo.
+
+Compruebe el límite de fallos antes de cambiar la configuración del proveedor:
+
+1. **No `type: "tool_search"` en la solicitud entrante:** el cliente activo Codex/sesión no anunció la superficie explícita `tool_search`. OpenCodex no puede inventar esa declaración. Esto no significa que las herramientas normales de modo de código no estén disponibles: compruebe si el modelo enrutado puede usar `exec` y descubra primero la herramienta anidada necesaria a través de `tools` / `ALL_TOOLS`.
+2. **La declaración entrante existe, pero ninguna función `tool_search` alcanza la solicitud enrutada:** captura solo el tipo de herramienta/lista de nombres redactados y abre un error OpenCodex. Nunca adjunte el portador, el identificador de cuenta, la entrada de conversación, los encabezados completos o el cuerpo completo de la solicitud.
+3. **La solicitud enrutada contiene `tool_search`, pero el modelo local nunca lo llama:** el relé está funcionando. Utilice un modelo/plantilla con llamadas a funciones confiables e instrucciones que le indiquen explícitamente que busque una herramienta diferida que necesite. LM Studio `tool_choice: "auto"` permite el uso de herramientas; no obliga al modelo a llamar a esta función.
+4. **Una llamada se emite repetidamente o las herramientas cargadas nunca se vuelven utilizables:** capturan los tipos de artículo `tool_search_call` / `tool_search_output` redactados y los identificadores de llamada. OpenCodex conserva ambos en la historia, por lo que el modelo debería ver la búsqueda completa en lugar de emitirla para siempre.
+
+Vea [El analizador y el puente](/es/reference/architecture/#the-parser) para la asignación explícita de cables. No hay ninguna configuración de nivel de proveedor que pueda agregar una declaración `tool_search` faltante; el descubrimiento de modo de código ordinario sigue siendo una ruta separada.
+
+<a id="cache-read-diagnostics"></a>
+
+### Diagnósticos de lectura en caché
+
+Establezca `OPENCODEX_CACHE_DEBUG=1` antes de iniciar el proxy para escribir un registro de diagnóstico por solicitud finalizada en `<config-dir>/cache-debug.jsonl`. El interruptor está desactivado de forma predeterminada; configúralo en `0` o retíralo para desactivar la captura. El archivo es propietario solamente (`0600`) en el directorio de configuración endurecido y rueda después de 200 líneas, reteniendo el 100 más nuevo.
+
+Cada registro JSONL contiene el protocolo, el proveedor/modelo enrutado, la presencia y procedencia del contador de caché, las etiquetas de igualdad local de proceso para la cuenta, la clave de caché de solicitud y los encabezados de sesión permitidos, además de huellas dactilares ordenadas para instrucciones, herramientas y bloques de mensaje/entrada. Las secciones de prefijo retienen como máximo 128 etiquetas e identifican solo la primera sección/índice divergente. El diagnóstico nunca almacena mensajes de texto, nombres de herramientas, encabezados sin procesar, identificadores de caché/sesión/cuenta sin procesar o una etiqueta duradera derivada de ellos. Su clave HMAC aleatoria se crea al inicio del proceso, separada de otras claves de depuración, y nunca persiste; las etiquetas por lo tanto comparan valores solo dentro de un proceso proxy.
+
+<a id="catalog-troubleshooting"></a>
+
+### Solución de problemas de catálogo
+
+Si falta un modelo de Codex, o el orden/visibilidad del catálogo se ve mal, compruebe en orden:
+
+1. **`selectedModels`** en el proveedor: una lista de permisos no vacía expone solo esos identificadores a Codex; vacía u omitida expone todos los modelos descubiertos. Un id que no está en la lista de permisos nunca llega al catálogo.
+2. **`disabledModels`** (nivel superior) - oculta los modelos del catálogo y `/v1/models`, y voltea las identificadores GPT nativas desnudas a `visibility: "hide"`.
+3. **`liveModels: false`** - Con `liveModels: false`, un `models` vacío u omitido inicia primero el `defaultModel` configurado, seguido de `retainModels`; los identificadores duplicados se eliminan mientras se conserva la primera aparición. Una lista `models` explícita no vacía en su lugar siembra `models` seguido de `retainModels`, sin agregar implícitamente un `defaultModel` diferente. Ese valor predeterminado todavía se puede enumerar explícitamente en `models` o `retainModels`. Si ninguno de estos campos proporciona un id, la semilla estática está vacía. Este es el orden de la semilla, no una promesa del orden final del selector. `selectedModels`, `disabledModels` y la política de proveedores desactivados todavía se aplican. `authMode: "forward"` mantiene su rama separada y no usa esta semilla estática enrutada. Estas reglas no cambian el fracaso del descubrimiento en vivo.
+4. **Cursor `GetUsableModels`** - el adaptador Cursor descubre modelos a través de su protobuf `GetUsableModels` RPC, no `/models`, por lo que un cambio de lado Cursor puede alterar qué id son visibles independientemente de otros proveedores.
+5. **Caché y `ocx sync`** - catálogos en vivo se almacenan en caché durante unos cinco minutos (`modelCacheTtlMs`, por defecto `300000`). Ejecute `ocx sync` para forzar una nueva búsqueda y reescribir el catálogo inmediatamente.
+6. **Correr Codex `app-server`** - reescribir el catálogo en el disco no es suficiente, mientras que un Codex de larga vida `app-server` (host de escritorio / CLI de fondo) mantiene la lista anterior en la memoria. `ocx sync` y `ocx sync-cache` advierten cuando se detectan esos procesos. `ocx sync --restart-codex` reinicia esos procesos y cierra completamente y reinicia la aplicación de escritorio Codex en macOS, Linux y Windows para que el selector vuelva a leer el catálogo. Para dejar la aplicación de escritorio en ejecución, pase `--restart-app-server-only` o detenga el `app-server` correspondiente procesos usted mismo.
+
+:::caution[Otros procesos locales que escriben la configuración]
+El catálogo escribe (`opencodex-catalog.json`, `config.toml`) son atómicos **interior** opencodex, que solo evita archivos a medio escribir cuando dos escritores propiedad de opencodex compiten. Eso sí. **no** Detener a otro proceso local, observador de archivos o agente de sincronización de reescribir la visibilidad del catálogo u ordenar después de opencodex ha escrito. Codex mantiene su separación `models_cache.json` y puede refrescarlo independientemente, cambiando la lista visible sin reescribir `opencodex-catalog.json`. Si los modelos se voltean inesperadamente mientras proxy está ejecutando, deteniendo o reconfigurando a los escritores competidores, luego ejecuta `ocx sync` — esto es un riesgo de escritura externa, no un defecto confirmado opencodex.
+:::
+
+<a id="proxy-connection-errors"></a>
+
+## Errores de conexión proxy
+
+Si Codex vuelve a intentarlo y luego falla con un error como `stream disconnected before completion: error sending request for url (http://127.0.0.1:10100/v1/responses)` - o Claude Code informa un error de conexión similar - el proxy opencodex no se está ejecutando: nada está escuchando en el puerto configurado, por lo que el cliente muestra ese error de conexión sin procesar. Reinicie el proxy:
+
+```bash
+ocx start              # foreground
+ocx service install    # persistent: auto-starts on login and respawns on crash
+```
+
+`ocx status` muestra si el proxy se está ejecutando e imprime la misma pista de reinicio cuando no lo está; `ocx doctor` informa sobre la seguridad de reinicio (cobertura de servicio/atención).
+
+<a id="upstream-overload-before-any-output"></a>
+
+### Sobrecarga ascendente antes de cualquier salida
+
+Cuando el backend ChatGPT declina un turno nativo agrupado de Codex con `server_is_overloaded` u otro error del servidor antes de que haya producido cualquier salida, opencodex reintenta la misma cuenta con un retroceso corto y limitado y luego mueve el turno a otra cuenta elegible de Pool. Una cuenta anclada (un modelo calificado para la cuenta) se vuelve a probar pero nunca se mueve. Una vez que cualquier salida ha alcanzado Codex el giro nunca se envía de nuevo. Si se rechaza cada intento, Codex recibe el mismo error que habría recibido sin los reintentos. Las solicitudes compactas nativas se mueven a otra cuenta Pool en un error del servidor de la misma manera.
+
+<a id="runtime-agent-instances-codex-0164"></a>
+
+### Instancias de agentes en ejecución (Codex 0.164+)
+
+Codex 0.164 puede firmar cada solicitud con una aserción de agente cuando se activa `features.runtime_agent_instances`, una función desactivada de forma predeterminada. opencodex admite uno de sus dos modos:
+
+- `mode = "dual_header"` conserva la credencial habitual `Authorization: Bearer` y añade el encabezado `x-openai-agent-assertion`. opencodex procesa la solicitud como antes. Solo reenvía la aserción cuando el turno va a ChatGPT Direct con la credencial de quien realiza la solicitud. La elimina si la solicitud usa una cuenta de Pool, una credencial principal guardada, un proveedor enrutado o un sidecar, porque la aserción pertenece a la credencial enviada por Codex.
+- `mode = "assertion_only"` sustituye el token bearer por `Authorization: AgentAssertion <jwt>`. opencodex rechaza estas solicitudes con HTTP 400 y el código `agent_assertion_unsupported`. Nunca sustituye la aserción por una credencial de Pool o de proveedor, ni la reenvía o registra. Usa `dual_header` o desactiva la función cuando Codex pase por opencodex.
+
+<a id="launch-with-ocx-codex"></a>
+
+### Iniciar con `ocx codex`
+
+La clave solo se proporciona cuando la configuración y sus espacios de nombres están protegidos frente a otros usuarios o entidades; se confía en el usuario actual y en las autoridades privilegiadas del sistema operativo. Los procesos del mismo usuario son de confianza: quien tenga tus permisos de escritura ya puede leer tu archivo de clave de OpenCodex. Sustituir la configuración con esos mismos permisos entre la verificación y el inicio nativo queda fuera de este modelo de amenazas; el lanzador no inmoviliza la configuración al ceder el control.
+
+En Windows, los permisos predeterminados de creación de ProgramData impiden entregar la clave incluso si `ProgramData\OpenAI\Codex` no existe. La carpeta de configuración de Codex del sistema bajo ProgramData debe existir y permitir escritura únicamente a Administrators/SYSTEM, con sus antecesores protegidos frente a la sustitución por otros usuarios. Pide a un administrador que revise la política de directorios. opencodex nunca modifica las ACL por sí mismo ni proporciona un comando para preparar esos permisos. También puedes proporcionar tu propia clave exportando `OPENCODEX_API_AUTH_TOKEN`; `ocx codex` la deja intacta. Consulta los [requisitos y diagnósticos del lanzador](/es/reference/cli/agents/#ocx-codex-codex-args). Los demás rechazos también producen una sola línea breve y específica en stderr, sin valores de claves, contenidos de archivos de claves ni rutas de esos archivos.
+
+<a id="codex-autostart-shim"></a>
+
+### Codex calza de inicio automático
+
+Ejecute `ocx codex-shim install` para instalar el envoltorio de lanzador opcional. Ejecuta `ocx ensure` antes de que el Codex ordinario se inicie y luego reenvía los argumentos originales y el estado de salida. El comando también funciona con el `ocx` independiente incluido en paquetes de escritorio: tanto la sonda de instalación como el envoltorio instalado usan ese ejecutable, sin requerir una instalación separada de Bun o una comprobación de origen.
+
+En macOS y Linux, active el envoltorio privado en su shell actual después de otra configuración de PATH. Con el inicio predeterminado OpenCodex, ejecute:
+
+```sh
+. "$HOME/.opencodex/codex-shell-env.sh"
+```
+
+Con un `OPENCODEX_HOME` personalizado, utilice el camino citado impreso por `ocx codex-shim install`. Agregue esa línea de origen después de otra configuración de PATH en su archivo de inicio de shell para activar futuros shells. OpenCodex no edita ese archivo ni cambia el shell principal. Las shims Unix heredadas en el lugar no se migran automáticamente; ejecute `ocx codex-shim install` explícitamente para migrarlas.
+
+Utilice `ocx codex-shim status` para inspeccionarlo. En macOS y Linux, `ocx codex-shim uninstall` elimina los archivos de superposición privados y deja intacto Codex nativo. Windows mantiene en su lugar los envoltorios de script; la desinstalación restaura el lanzador guardado. Ver el [CLI Referencia del ciclo de vida](/es/reference/cli/lifecycle/#ocx-codex-shim-installstatusuninstallremove).
+
+<a id="experimental-windows-desktop-compatibility"></a>
+
+## Experimental compatibilidad de escritorio Windows
+
+**Codex Set → Compatibilidad con equipos de escritorio** proporciona controles locales para una prueba de compatibilidad limitada al tiempo que conserva el inicio de sesión nativo Codex. Este es un relevo experimental, no una garantía de que cada Codex estado de compilación o cuenta agotada pueda recuperar a su compositor.
+
+En un panel local independiente, primero ejecuta en el equipo del proxy el comando mostrado en el panel, por ejemplo `ocx gui pair --desktop --origin http://127.0.0.1:10100`, y pega su código secreto de un solo uso. Si `ocx` no está disponible, instala primero la CLI. Debes resolver cualquier denegación de permisos del directorio privado antes de emitir un código. Un código de emparejamiento ordinario o un panel ya emparejado no autoriza por sí solo acciones de Desktop. El panel intercambia el código de Desktop para añadir el alcance a la sesión existente y luego lee `/authorization` para verificarlo; no crea ni reemplaza la sesión del navegador. Esto autoriza las acciones de Desktop durante un máximo de cinco minutos en esa sesión; no cambia los permisos de Remote Link ni de divulgación de claves. Consulta [Autorización de Desktop](/es/reference/management-api/#desktop-authorization) para el contrato de la API. No se admiten escrituras de Desktop desde Hub ni clientes conectados.
+
+Si la autorización no está disponible, usa el panel independiente directamente por HTTP en el equipo del proxy, en la dirección loopback y el puerto configurados. Si `hostname` está configurado como `localhost` o una dirección no loopback como `0.0.0.0`, cámbialo a `127.0.0.1` o `::1` en [config.json](/es/reference/configuration/), reinicia el proxy y vuelve a abrir la dirección y el puerto correspondientes. Otras condiciones, como reenvíos o puertos o sesiones que no coinciden, también pueden impedir la autorización; cambiar solo el hostname no las resuelve. Una sesión recordada del panel no puede canjear una concesión de Desktop. En el equipo del proxy, abre la misma dirección local y puerto en una ventana privada del navegador, vuelve a este panel y solicita allí un código nuevo. Tras la caducidad o el cierre de sesión, recarga el panel local y vuelve a autorizar. El panel actualiza el estado, la huella y la revisión de configuración; vuelve a elegir la acción y dar tu consentimiento. Nunca repite un POST anterior. La caducidad del certificado o una confianza desconocida no impiden esta autorización HTTP local; la limpieza, renovación, detención y desactivación del inicio automático siguen requiriéndola.
+
+1. Inspeccione el estado, prepare el certificado cifrado y revise su huella digital antes de registrar la confianza. Windows puede solicitar confirmación. La confianza se aplica al usuario actual Windows y permite que el relé local maneje el tráfico `chatgpt.com`.
+2. Comience la observación. Guarde los borradores, cierre Codex, luego use **Abierto Codex** en este panel para iniciar la aplicación empaquetada con la conexión administrada. El panel nunca cierra por la fuerza una aplicación existente.
+3. Solo después de que se observe el agotamiento elegible, **Ejecutar prueba de 3 minutos** ofrece un consentimiento separado para toda la cuenta. Ajusta dos indicadores de interfaz de usuario en la cuenta de inicio de sesión, no solo en el modelo seleccionado. El uso real, los créditos, las restricciones de gasto y los límites del servidor permanecen sin cambios. Una respuesta producida por sí sola no establece que el compositor se recuperó.
+
+Una respuesta original que muestre el uso disponible o un estado protegido finaliza el juicio inmediatamente. Los créditos disponibles o la Reserva Luna activa también dejan la respuesta sin cambios y terminan el ensayo, incluso cuando se agota el uso ordinario. Esto preserva el estado de derecho existente de la aplicación. Si el agotamiento elegible aparece de nuevo, se requiere otro ensayo explícito; el consentimiento anterior no reactiva silenciosamente la corrección.
+
+**Volver a la observación** desarma la corrección. El límite de tres minutos acota la corrección de la respuesta, no el tiempo que tarda Codex en refrescar su visualización. Tanto el vencimiento como el regreso a la observación solicitan una nueva respuesta de uso; la aplicación puede conservar su pantalla anterior hasta que llegue esa respuesta. El panel muestra esta limitación antes del consentimiento de prueba y mientras espera la respuesta original; no puede confirmar la actualización de caché de la aplicación. **Detener el servicio** cierra sus conexiones y deja el certificado para su reutilización; las conexiones activas pueden interrumpirse. Para renovar o retirar la confianza, detenga el servicio y cierre primero el Codex. La renovación prepara un nuevo certificado no confiable; revise la nueva huella digital antes de registrarla. Una acción incierta no se vuelve a intentar automáticamente. Los certificados están restringidos a la autenticación del servidor TLS. Si el estado muestra `renewal-required`, detenga el servicio y cierre Codex, luego renueve el certificado anterior antes de comenzar de nuevo. La URL nativa API debe coincidir con la dirección del oyente y el puerto reales del proxy. Las direcciones IPv4 e IPv6 no son intercambiables aquí; `localhost` alias ambiguos son rechazados. La actualización automática de la conexión MCP de Codex y el formato de configuración no invalidan la observación. Los cambios de modelo, autenticación, perfil y enrutamiento aún requieren un contexto de observación fresco; el servicio no adopta silenciosamente esos cambios durante una prueba.
+
+El servicio conserva su dirección PAC y puertos de conexión local para su reutilización después de un reinicio. Con el mismo certificado de confianza, una aplicación ya configurada puede volver a conectarse a través de su PAC en caché; reiniciar el servicio nunca reanuda una prueba de corrección. Si un puerto guardado no se puede vincular o los metadatos de conexión no son válidos, el inicio se niega en lugar de asignar otra dirección de forma silenciosa. El primer comienzo exitoso posee `codex-desktop-compatibility/connection.json` bajo la casa OpenCodex. No elimine ese archivo como una solución de reinicio de rutina: una dirección diferente requiere iniciar la aplicación con una nueva conexión administrada.
+
+El soporte actual se limita a la versión Windows evaluada `26.924.2738.0`, inicio de sesión basado en archivos nativos. HTTP / HTTPS proxies y SOCKS5 autenticados proxies se admiten a través de la política de salida compartida; NO_PROXY puede seleccionar explícitamente una ruta directa. Las conexiones proxy fallidas no vuelven a la salida directa. El modo cliente administrado OpenCodex aún no es compatible con estos controles. Para este relé de escritorio, HTTP (S) `ALL_PROXY` también se aplica cuando `HTTPS_PROXY` no está configurado. Un `HTTPS_PROXY` no válido rechaza la operación en lugar de volver a `ALL_PROXY`. La aplicación desconocida crea una corrección de rechazos; la integración no parchea los archivos de la aplicación ni cambia al modo sin inicio de sesión. La configuración raíz nativa y su perfil seleccionado deben enrutar `openai_base_url` al oyente de datos local real de este proceso. Un proveedor, destino o anulación no admitida diferente rechaza el inicio de observación. Esta comprobación no determina el modelo seleccionado de una conversación ni prueba que las anulaciones locales de proyecto estén ausentes. Si el enrutamiento o la compilación de la aplicación instalada cambia durante una prueba, se rechaza la corrección antes de la siguiente respuesta de uso; las comprobaciones periódicas también devuelven una prueba inactiva a la observación. Las respuestas originales y otro tráfico de aplicaciones continúan retransmitiendo. El reemplazo nativo de archivos de inicio de sesión o la rotación de tokens también invalida la prueba, incluso cuando regresa la misma cuenta. Detener y comenzar la observación para vincular el inicio de sesión actual antes de otra prueba explícita; las respuestas antiguas no pueden autorizar la sesión de reemplazo. Los cambios en la configuración raíz Codex (excepto su tabla y formato de servidor MCP), la configuración del proveedor, los alias del modelo, los perfiles de enrutamiento, las rutas de reserva, la compactación o el modelo de memoria también invalidan el contexto de observación. Restaurar la configuración anterior no restablece su consentimiento: deténgase e inicie la observación, luego confirme un nuevo ensayo cuando sea elegible. Esto detecta cambios en esas rutas configuradas, no qué modelo selecciona realmente una conversación; una configuración de proveedor mixto sin cambios no es prueba de aislamiento del proveedor.
+
+Después de la preparación del certificado y un inicio manual exitoso, habilite **Reanudar la observación cuando se inicia OpenCodex** en el mismo panel. La configuración opcional OpenCodex `"desktopCompatibility": { "startOnProxyStart": true }` se reanuda **Sólo observación** cuando se inicia el proxy del modelo. Omission o `false` desactiva este arranque automático. Reutiliza los endpoints guardados y el certificado de confianza, nunca inicia Codex ni registra confianza, y nunca reanuda una prueba de Aplicar. La observación automática espera a que termine la sincronización de la configuración de inicio. La sincronización fallada o una espera de más de dos minutos deja la observación desactivada; inspeccione su estado e inícielo manualmente después de resolver el problema de inicio. El proxy del modelo continúa siguiendo su propia política de preparación. Si faltan requisitos previos, la observación permanece desactivada y el proxy del modelo continúa ejecutándose. Guardar esta preferencia no inicia ni detiene el servicio actual. Utilice sus controles de servicio separados para cambios inmediatos. Si no se puede confirmar un guardado, actualice su estado antes de volver a intentarlo.
+
+Un servicio en ejecución no establece que Codex esté conectado a través de él. Un inicio de aplicación normal o un actualizador de aplicación pueden omitir el argumento de conexión administrada. Guarde borradores, cierre Codex, luego use **Abierto Codex** en este panel para restaurar esa conexión. Este control nunca cierra la aplicación para usted. Después de una actualización Codex, una versión de aplicación no evaluada rechaza la corrección hasta que se revisa su compatibilidad; reinstalar el certificado no hace que se admita una compilación no evaluada.
+
+El panel también puede informar la última comprobación de compilación completada como metadatos de diagnóstico: la versión del paquete contra la que se evaluó esta compilación, la versión del paquete observada en esa comprobación, si coinciden y cuándo terminó la comprobación. Es una observación pasada, no una lectura en vivo del paquete instalado. Después de que el servicio se detiene, la aplicación se actualiza, o una comprobación todavía se está ejecutando o se interrumpió, puede retrasar la instalación real; solo una sonda completa lo actualiza, y un resultado `verified` describe el paquete observado en esa comprobación, no lo que está instalado ahora.
+
+En Windows, un reinicio de la aplicación completa OpenCodex explícito conserva un argumento PAC de compatibilidad de bucle invertido ya activo solo cuando el proceso OpenCodex actual posee el entorno de ejecución de compatibilidad de servicio. Se rechaza un punto final obsoleto o extraño antes de detener Codex; el reemplazo del entorno de ejecución durante el reinicio también evita el relanzamiento administrado. La aplicación se inicia a través de la activación del paquete Windows. Verifica la identidad del paquete y el argumento de enrutamiento después del inicio; argumentos de enrutamiento de la aplicación principal ilegibles o conflictivos causan un rechazo antes del reinicio. Esto no permite un modo de compatibilidad, instalar un certificado o ver y reiniciar la aplicación automáticamente. Los lanzamientos normales sin ese argumento de enrutamiento mantienen su comportamiento existente.
+
+<a id="transport-coverage-and-recovery-evidence"></a>
+
+### Cobertura de transporte y evidencia de recuperación
+
+El panel de compatibilidad informa las respuestas de uso JSON / SSE verificadas por identidad y los flujos actualmente vinculados por separado de las conexiones abiertas. Estas son observaciones de retransmisión de por vida, incluidas las solicitudes realizadas por clientes de diagnóstico. No identifican el proceso nativo de envío, prueban que la aplicación actualizó su caché autorizado o prueban la recuperación del compositor. No se agrega ningún cuerpo de solicitud, token, ID de cuenta o IP de origen a este estado de diagnóstico.
+
+[incidencia #6196](https://github.com/lidge-jun/opencodex/issues/6196) informa una compilación macOS cuyas solicitudes de puerta autorizadas se originan en el servidor de aplicaciones Rust incluido y evitan la configuración de Chromium PAC. Un PAC saludable, certificado o solicitud sintética no puede establecer la cobertura de ese transporte. Este experimento Windows no es una solución para ese bloqueador de diseño macOS.
+
+Antes de agregar otra plataforma o transporte, documente y valide esta secuencia:
+
+1. Identifique el proceso real y el transporte que envía cada solicitud de puerta autorizada.
+2. Demostrar que una solicitud de origen de aplicación llega al relé previsto, por separado de los clientes de prueba.
+3. Verifique el esquema de respuesta y la ruta de caché/actualización de la aplicación para la compilación instalada exacta.
+4. En caso de agotamiento natural de la cuenta, verifique el envío del compositor original, la finalización del proveedor independiente y la preservación del inicio de sesión, el chat, los hilos existentes y las conexiones remotas.
+5. Verifique el apagado, el inicio ordinario, reinicie y actualice el comportamiento; no infiera uno de otro.
+
+La presente política solo maneja `/backend-api/wham/usage` y su punto final `/stream`. La inicialización de la conversación y otros puntos finales, incluidos sus `blocked_features` y `limits_progress`, pasan sin cambios. Su presencia no es un permiso para limpiarlos: pueden representar restricciones no relacionadas. La ruta de búsqueda de renderizador a electrón de la compilación Windows no establece la ruta de red de un sistema operativo/construcción diferente o de cada RPC de servidor de aplicaciones. El enrutamiento del servidor de aplicaciones requiere su propio diseño revisado; cambiar las URL del proveedor de modelos por sí solo no es prueba de que el tráfico de cuenta, inicio de sesión o control remoto siga la misma ruta. Estos controles no instalan ningún envoltorio automático de aplicaciones-servidor, cambio de proxy global o reescritura de inicio de sesión.
+
+<a id="routed-models-during-codex-reserve-mode"></a>
+
+## Modelos encaminados durante el modo de reserva Codex
+
+Codex Pool puede proteger opcionalmente las cuentas de grupo almacenadas a un umbral de uso semanal o de 5 horas seleccionado. La cuenta de escritorio/principal mantiene su bloqueo separado del 98%. Establezca `codexPool.lowQuotaProtection` en configuración para pausar cuentas, registrar una alerta de registro y API o ambas; vea [configuración de enrutamiento](/es/reference/configuration/routing/#codex-pool-low-quota-protection). Una pausa tiene efecto para la siguiente selección inmediatamente, mientras que guardarla en el disco se aplaza. Las respuestas de cuota Pool pueden autorizar una pausa solo con el uso válido y una credencial capturada que todavía está actualizada. Una respuesta sin esa prueba puede actualizar el uso mostrado sin pausar una cuenta. Compruebe el historial de `GET /api/codex-auth/low-quota-events` autenticado de este servidor para alertas `logged` o errores de guardado. El reanudación manual permanece en vigor para el episodio de cuota actual. La alerta por defecto solo llega al log y API. Añadir `actions.desktop: true` para mostrar también una notificación macOS o Linux en la máquina que ejecuta el proxy; Windows permanece solo registro.
+
+Cuando se agote la cuota de ChatGPT de 5 horas, Codex puede ofrecer un modelo de reserva de reserva (`gpt-reserve` / Luna Reserve). Mientras que ese estado está activo, el selector de modelos Codex puede hacer **cualquier otra entrada no seleccionable, incluidos los modelos enrutados opencodex**, a pesar de que se ejecutan en proveedores independientes y credenciales y no consumen ninguna de las cuotas agotadas.
+
+**Este es un comportamiento del cliente Codex que el enrutamiento proxy de modelo ordinario no puede cambiar.** El estado de reserva llega desde el backend ChatGPT en la propia conexión autenticada del cliente, no a través del proxy. La aplicación de escritorio sondea `backend-api/wham/usage` y trata la reserva como activa cuando la respuesta lleva `rate_limit_upsell.banner_type = "luna_reserve"`, el `rate_limit.allowed` primario es `false`, y `additional_rate_limits[]` contiene una entrada con `limit_name = "gpt-reserve"` que todavía está permitida. Mientras eso se mantiene, la aplicación fuerza la configuración del modelo de la conversación a `gpt-reserve` y reescribe cualquier otra elección de nuevo a ella - el selector se contrae a la entrada de reserva por el cliente, y un valor `model =` en `config.toml` se anula de la misma manera. Nada de esto consulta el catálogo de modelos, por lo que ninguna representación de nuestra parte participa en la decisión. opencodex no tiene un concepto de reserva para ajustar, y la alternativa - informar mal su propia cuota a su propio cliente - sería un error peor que el que encubrió.
+
+**Solución:** los modelos en sí permanecen completamente utilizables; solo la selección del modelo de la aplicación Codex está cerrada. Llegue a ellos desde un cliente que no consulta la instantánea de uso ChatGPT:
+
+- Claude Code a través del proxy (`ocx claude`).
+- Cualquier cliente HTTP contra el punto final local `/v1`.
+- Las propias rutas de solicitud del panel de control.
+
+El comportamiento normal del selector vuelve cuando se restablece la ventana de 5 horas.
+
+**Lo que el proxy responde mientras ese estado se mantiene.** Una vez que la aplicación ha colapsado, el selector envía `gpt-reserve`, y sin el [opt-in de escritorio authless](#authless-codex-desktop-opt-in) opencodex no tiene derecho de reserva para enviar con él. Esa solicitud solía ser enviada como un modelo nativo ordinario y regresaba como el propio `The usage limit has been reached` del flujo ascendente, que no nombra ni la causa real ni la configuración que lo cambiaría. Ahora se rechaza localmente con un HTTP 400 que dice que `codexDesktopAuthless` está desactivado y da el comando que lo enciende (`ocx system settings --desktop-authless on`). Nada se envía aguas arriba y no se gasta ninguna cuota.
+
+El rechazo es deliberadamente estrecho. Se aplica solo a `gpt-reserve` en una solicitud admitida en bucle que alcanzaría la ruta de avance canónica ChatGPT. Un selector `gpt-reserve` que un operador ha aliaseado o enrutado a otro proveedor sigue funcionando, una solicitud admitida en un oyente que no es loopback aún se reenvía, y un proxy que se ejecuta en el rol de entorno de ejecución `client` no cambia. Habilitar el opt-in restaura el camino normal de la Reserva en lugar del rechazo.
+
+<a id="the-subagent-picker"></a>
+
+## El selector de subagentes
+
+La sincronización de catálogos permite que los modelos de subagentes seleccionados estén disponibles para Codex; consulte [Codex Selector de modelos de aplicaciones](/es/guides/codex-app-models/#subagent-selection) para el pedido de selectores y [Superficie del subagente](/es/guides/sub-agent-surface/) para la delegación v1/base/v2 y el comportamiento de reserva.
+
+<a id="codex-account-warmup"></a>
+
+## Codex calentamiento de la cuenta
+
+Cuando se agrega o vuelve a autenticar una cuenta ChatGPT, OpenCodex normalmente la verifica antes de guardarla con una pequeña solicitud de transmisión al backend Codex Responses. Espera `response.completed`, por defecto `gpt-5.6-luna`, y vuelve a intentar con `gpt-5.5` en HTTP 400 o HTTP 404. Los errores públicos contienen categorías de fallos fijos en lugar de cuerpos de respuesta ascendentes sin procesar.
+
+Un HTTP 429 de un intento de calentamiento se informa como `codex_warmup_rate_limited`. Vuelva a intentar después de que se elimine la restricción temporal o se restablezca el límite de uso; iniciar sesión nuevamente no restablece estos límites. Un intento fallido de calentamiento no agrega una nueva cuenta ni reemplaza las credenciales existentes. Esto difiere del registro diferido confirmado por cuota a continuación, que puede guardar una cuenta restringida sin una solicitud de modelo. HTTP 401/403 fallos retienen la guía de autenticación.
+
+Si la búsqueda de uso autenticado de la nueva credencial OAuth confirma una cuota agotada de 5 horas, semanal o mensual, la cuenta se guarda sin esta solicitud de modelo y muestra **Validación pendiente**. No puede servir solicitudes de agrupación, incluso después de reiniciar o actualizar token. Una vez que se recupera la cuota, **Actualizar las cuotas** finaliza la validación: una lectura de uso nueva y completa con espacio libre permite una pequeña solicitud de modelo, y solo una respuesta completa habilita la cuenta. Las lecturas fallidas o incompletas y la validación fallida preservan la restricción. Las encuestas de cuentas pasivas no activan la validación diferida. El uso desconocido durante el registro inicial conserva la puerta de calentamiento normal.
+
+`ocx account refresh openai` y `ocx account list openai --quota --refresh` solo leen el uso. La validación del modelo gasta cuota y requiere una sesión de panel humano: abra `ocx gui` y haga clic en **Actualizar las cuotas** después de la recuperación. Para un host sin cabeza, acceda a su panel de control desde su navegador; un token de administrador solo no autoriza la validación. La validación se puede completar mientras una cuenta está en pausa sin reanudarla o seleccionarla. Los errores de autorización del modelo permanecen visibles hasta que la validación o reautenticación exitosa los borra.
+
+En **Codex Conjunto → Multi-auth**, habilite el interruptor **Codex créditos** en el encabezado **Codex Auth** para mostrar los últimos créditos observados de cada cuenta principal y de grupo directamente debajo de Week. Está desactivado por defecto y persiste como `showCodexCredits`. El saldo es un número con formato local, con advertencia ilimitada o de exceso cuando se informa; la barra indica disponibilidad, no un porcentaje, porque no se proporciona un límite de crédito total. Ocultar los créditos solo cambia su visualización, y un nuevo inicio de sesión espera su propia observación.
+
+Cuando una cuenta llega al 100% en una ventana de uso y aún tiene créditos, la parte superior sigue sirviéndola y obtiene el saldo. OpenCodex no deja que eso suceda de forma predeterminada: una cuenta al 100% se apaga mientras su ventana semanal o mensual (solo mensualmente en planes de 30 días) o su ventana de 5 horas está llena, y se usa nuevamente una vez que se restablece esa ventana. El orden de las otras cuentas no cambia, y cuando no hay otra cuenta disponible, la selección no encuentra nada en lugar de gastar créditos. Una solicitud para la cuenta principal se rechaza como un rechazo de bloqueo duro hasta que se restablezca. Una ventana completa de 5 horas sin un tiempo de reinicio mantiene una cuenta solo mientras esa lectura está fresca. Permitir que la cuenta principal no levante su bloqueo duro (encendido por defecto al 98%), lo que aún lo detiene primero; apague el bloqueo si la cuenta principal debe gastar créditos (un bloqueo al 100% aún lo detiene al 100%). Para permitir que las cuentas sigan funcionando desde sus créditos, active **Usar créditos** junto al interruptor **Codex créditos** en el encabezado de Autonomía Codex. El interruptor permite todas las cuentas. Para elegir cuentas una por una, abra el menú **⋯** de una tarjeta de cuenta y use **Usar créditos después del límite** allí; el interruptor de encabezado muestra una posición media cuando solo algunas cuentas están activadas. Una cuenta permitida para gastar lleva una insignia **Utiliza créditos** en su tarjeta. Comienzan nuevas cuentas. La opción se almacena en `creditCodexAccountIds` y nunca canjea créditos de reinicio; el interruptor de pantalla **Codex créditos** solo muestra saldos y nunca cambia el enrutamiento.
+
+En el caso de una cuenta principal con acceso opcional y sin pausa y con una ventana de uso completa, el ciclo de recuperación en segundo plano renueva las observaciones de crédito gastables a partir de los tres minutos de edad, incluso cuando el panel de control está cerrado. Prepara un token válido antes de la búsqueda de uso autenticado para que el saldo se pueda observar nuevamente antes de su límite de frescura de cinco minutos. Los créditos faltantes, nulos, restringidos o retractados mantienen la cuenta elegible para búsquedas de recuperación bajo el reintento de retroceso existente. Las solicitudes siguen siendo rechazadas hasta que se observe un nuevo saldo positivo o créditos ilimitados. `has_credits` solo o recuentos de mensajes aproximados no demuestran un saldo desembolsable. Con el consentimiento, el `Retry-After` de este rechazo de evidencia crediticia es como máximo de cinco minutos, o un restablecimiento de la cuota incluida antes; sin consentimiento, aún sigue el restablecimiento de la cuota incluida. Una búsqueda fallida o incompleta no actualiza la evidencia de equilibrio anterior. El bloqueo duro de la cuenta principal separada, la cuarentena de necesidades-reauth y los retrasos de reintentos aguas arriba aún se aplican. Esta búsqueda de metadatos no envía una solicitud de validación de modelo ni establece ni borra el estado de área de necesidades de la cuenta.
+
+La revalidación de fondo es separada y desactivada por defecto. Requiere Token Guardian, el `openai` proveedor `proactive` política de actualización, y `tokenGuardian.codexWarmupEnabled`. Se salta las cuentas a la espera de la validación de registro diferido.
+
+<a id="after-a-chatgpt-plan-upgrade"></a>
+
+### Después de una actualización del plan ChatGPT
+
+Actualice la cuota de la cuenta principal en Codex Auth después de cambiar su plan ChatGPT. Cuando la respuesta de uso autenticada confirma que una ventana larga ha reemplazado la ventana de cinco horas, opencodex elimina la antigua lectura de cinco horas tanto de la admisión de solicitud como de la selección de cuenta. Una respuesta permitida con ventanas primarias y secundarias puede omitir la ventana terciaria opcional. Esta recuperación utiliza su asignación de plan incluida y no requiere habilitar **Usar créditos**. Los datos de uso parciales o no válidos retienen el bloque anterior hasta que se confirma la recuperación.
+
+Las cuentas guardadas con **Usar créditos tras el límite** activado renuevan la evidencia de créditos mediante el ciclo de fondo existente cuando se agota una ventana de uso incluida y la observación de créditos tiene al menos tres minutos. En modo **Direct**, esto también cubre cuentas guardadas vinculadas explícitamente en `codexAccountNamespaces`, como un selector de subcuenta. Puedes mantener Direct y separar las identidades principal y secundaria: no se activa el enrutamiento Pool ni se actualizan cuentas sin vincular. Se omiten las cuentas pausadas o que necesitan volver a autenticarse. Leer metadatos no valida cuentas pendientes ni envía solicitudes al modelo. Los fallos de lectura conservan la espera entre intentos y las solicitudes siguen necesitando evidencia reciente de créditos disponibles. Las cabeceras de uso de respuestas ordinarias no renuevan la marca de tiempo del saldo de créditos.
+
+<a id="cancelling-main-account-device-reauthentication"></a>
+
+### Cancelación de la reautenticación del dispositivo de la cuenta principal
+
+Cuando se cancela la reautenticación del dispositivo de la cuenta principal, un fallo temporal de la red o una respuesta con un estado desconocido o no terminal, mantiene el flujo activo y la indicación de fallo de cancelación para que se pueda volver a intentar la cancelación. El sondeo de estado normalmente continúa, por lo que aún se puede detectar un inicio de sesión que se complete. Si un fallo de cancelación reintentable se superpone a una respuesta de estado GET no 2xx mientras el flujo es `pending` o `committing`, cualquier orden de respuesta conserva el reintento de cancelación en ese mismo flujo, con su último código de dispositivo proporcionado por el servidor, URL de verificación y fase. El fallo GET HTTP aún deja de ser consultado, pero la cancelación puede ser reintentada sin iniciar un segundo POST de inicio de sesión. Una respuesta del terminal `failed` libera el flujo y muestra la razón normalizada del fallo; solo `succeeded` informa del éxito del inicio de sesión. Una respuesta confirmada `cancelled` libera el flujo para que se pueda iniciar un nuevo inicio de sesión del dispositivo. Una respuesta definitiva HTTP 404 con el código `unknown_flow` también libera el ID de flujo caducado para que se pueda iniciar un nuevo inicio de sesión del dispositivo, pero no informa un inicio de sesión exitoso o una cancelación confirmada. Las respuestas POST, GET o DELETE tardías de un flujo anterior no pueden cambiar el nuevo flujo o informar el éxito de inicio de sesión para él.
+
+<a id="why-an-account-stopped-serving-requests"></a>
+
+### Por qué una cuenta dejó de servir solicitudes
+
+Cuando una cuenta deja la selección de grupo, la razón viaja con la decisión en lugar de ser recalculada para su visualización, por lo que una superficie nunca puede informar una cuenta saludable mientras el enrutamiento la está abandonando. `GET /api/codex-auth/accounts` lleva `reauthReason` junto a `needsReauth` en cada cuenta: `missing_credential` para una credencial que nunca se almacenó, `refresh_failed` para una actualización de credenciales que sigue fallando y `quota_unauthorized` cuando se rechazó la búsqueda de uso.
+
+Una actualización de la cuenta principal que no se completa todavía responde `503` con `Retry-After`, porque un reintento aún puede tener éxito. El mensaje ahora agrega que un fallo que persiste significa que la cuenta principal necesita reautenticación, en lugar de solo pedir otro intento.
+
+<a id="request-owned-conversation-affinity"></a>
+
+### Afinidad de conversaciones con credenciales propias
+
+`codexPool.requestOwnedAffinity` es un booleano opcional, `false` de forma predeterminada. Actívalo con `true` para mantener en una cuenta apta, dentro de cada ámbito de cuota, una conversación que lleve su propio bearer de ChatGPT. La liberación de la afinidad y los desvíos de modelo aún pueden cambiar la cuenta. El vínculo solo existe en este proceso: reiniciar el proxy o rotar el bearer inicia otro vínculo. Las cadenas de subagentes sin sesión que abarcan varias generaciones pueden vincularse por hilo.
+
+Las etiquetas describen el vínculo cuando termina la selección. `unbound` indica que no se guardó ningún vínculo; `request_owned`, que la credencial del cliente no activó esta opción; y `no_conversation`, que no había una clave de conversación. Un cambio posterior de elegibilidad puede liberar un vínculo después de la selección.
+
+Con la opción activada o desactivada, una solicitud con bearer propio registra la cuenta que atendió cada turno bajo una clave limitada a ese bearer. Si un turno posterior usa otra cuenta, incluso tras una selección manual, OpenCodex elimina `previous_response_id` antes de enviar y rechaza las referencias heredadas a archivos subidos mediante `file_id` con HTTP 400, porque la cuenta nueva no puede leerlas.
+
+<a id="optional-idle-window-steering"></a>
+
+### Dirección de ventana inactiva opcional
+
+`codexPool.startIdleWindows` es un booleano opcional y por defecto a `false`. Cuando se habilita, una nueva solicitud real no vinculada puede colocarse en una cuenta elegible cuya ventana de cuota corta observada es del 0% con evidencia de que su reloj de cinco horas no ha comenzado. Esta verificación se ejecuta después de la conversación y la afinidad familiar, por lo que un enlace existente sigue siendo autorizado; también gana un pin de cuenta explícito o una preferencia de cuenta manual. Se omiten los ámbitos de cuota de modelo independientes y el cursor activo compartido permanece sin cambios. Después de la opción de ventana inactiva, la selección de estrategia normal se reanuda para otras conversaciones.
+
+La observación no debe ser mayor de cinco minutos, y la ventana corta debe ser explícitamente de 18.000 segundos. Su restablecimiento debe observarse dentro de los 60 segundos de `observation + 5h` (en lugar de un restablecimiento ya realizado o transcurrido). Una reserva local de proceso sincrónica evita selecciones duplicadas para la misma cuenta y ventana. El plazo de reserva es de al menos 5 horas más un minuto después de la selección; se requiere una nueva observación después de ese plazo antes de que la misma cuenta pueda ser dirigida nuevamente. Las reservas se borran cuando se reinicia el proceso proxy y nunca se mantienen en el disco.
+
+Habilitarlo en su configuración existente:
+
+```json
+{
+  "codexPool": { "startIdleWindows": true }
+}
+```
+
+Si ninguna cuenta cumple con los criterios, se aplica el enrutamiento ordinario. Esta característica solo dirige una solicitud entrante real. No crea ninguna petición sintética ni temporizador.
+
+<a id="keeping-a-downgraded-account-out-of-rotation"></a>
+
+### Mantener una cuenta degradada fuera de rotación
+
+`codexPool.excludedPlans` enumera las claves de plan que la selección automática de grupo omite, emparejadas insensiblemente a las mayúsculas y minúsculas contra el plan almacenado en cada cuenta. Está ausente por defecto, por lo que una instalación existente gira exactamente como antes.
+
+```bash
+ocx config set codexPool '{"excludedPlans":["free"]}'
+```
+
+Esta es una política de selección, no un bloqueo. Una cuenta excluida mantiene su credencial, historial de cuotas y afinidad de subprocesos, permanece visible en la superficie de la cuenta y aún se puede acceder a ella mediante una selección explícita de la cuenta, como la `work/gpt-5.5`. Lo que cambia es que la rotación automática deja de elegirlo, incluso cuando ya es la cuenta activa o ya está vinculada a un hilo, que es el estado que deja una suscripción caducada.
+
+La cuenta principal Codex permanece exenta de la exclusión del plan; el enrutamiento solo de selección no lee su credencial nativa vallada. Si se excluyen todas las cuentas de grupo elegibles, la selección automática no devuelve ninguna cuenta. Las rutas con calificación de cuenta explícita permanecen disponibles y aún imponen pausa, autenticación y derecho de modelo. La tarjeta de cuenta y CLI muestran el plan de enrutamiento excluido por separado del estado de la credencial. No hay una configuración `minimumPlan` porque los nombres de los planes no definen un pedido total.
+
+<a id="restoring-native-codex"></a>
+
+## Restauración de Codex nativo
+
+`ocx stop` detiene el proxy y cualquier servicio en segundo plano instalado, luego intenta restaurar el Codex nativo. OpenCodex elimina los artefactos de enrutamiento verificados e informa de una restauración incompleta cuando no puede recuperar archivos de configuración de forma segura.
+
+La recuperación puede requerir una revisión manual cuando la revista no puede verificar los archivos actuales; consulte [recuperación sin hashes de inyección](#recovery-without-injection-hashes).
+
+```bash
+ocx stop       # stop the proxy + service, restore native Codex
+ocx restore    # restore without stopping  (alias: ocx eject)
+ocx restore back # point plain Codex at the running proxy again
+```
+
+Cuando opencodex se ejecuta como un [servicio de fondo](/es/reference/cli/lifecycle/#background-service) administrado, establece `OCX_SERVICE=1` para que un reinicio impulsado por servicio haga **no** thrash la configuración Codex - solo un `ocx stop` / `ocx service stop` explícito restaura el Codex nativo.
+
+<a id="recovery-without-injection-hashes"></a>
+
+### Recuperación sin hashes de inyección
+
+La revista guarda los hashes originales `config.toml` y `opencodex.config.toml` más del estado OpenCodex inyectado. Un diario heredado o una interrupción antes de que se registraran esos hashes no pueden probar que el contenido posterior del archivo pertenezca a OpenCodex. Si cualquiera de los archivos difiere de su original guardado y carece de su propio hash de estado inyectado, la recuperación automática del diario y el error del informe de restauración nativa sin cambiar el archivo o la revista. El original guardado permanece disponible para la comparación; revíselo junto con los archivos actuales antes de elegir una acción de recuperación manual.
+
+Los archivos que ya son iguales a sus originales guardados se aceptan sin reescribirlos. Un archivo faltante es distinto de un archivo vacío. Los hashes inyectados verificados aún permiten la restauración normal de instantáneas y las ediciones posteriores en configuraciones respaldadas por hash conservan el comportamiento de limpieza de campo propio existente.
+
+Sync y `ocx restore back` también rechazan una configuración enrutada existente cuyo diario sin hash no coincide con la línea base previa a la inyección. Esto evita que un nuevo hash de inyección se adhiera a un original más antiguo. Una configuración genuinamente nativa se puede guardar como una nueva línea de base antes de la inyección. El comportamiento explícito de exclusión de proveedores externos no se modifica.
+
+
+<a id="sub-agent-fallback-and-v2-compatibility"></a>
+
+### Subagente de reserva y compatibilidad con V2
+
+En **Subagentes → Configuración de delegación**, edite la cadena de reserva ordenada y su intervalo de sondeo de disponibilidad (5000-600000 ms), luego guárdela por separado de la lista destacada. Un destino configurado que ya no se anuncia permanece en la cadena hasta que lo elimine. La lista y la cadena de reserva son configuraciones separadas; este editor no hace que la lista reemplace la política de reserva.
+
+Cuando un modelo preferido enrutado puede recibir trabajo V2 de un padre nativo ChatGPT, el panel explica la limitación de la tarea cifrada ascendente. Las tareas legibles de los padres enrutados no se ven afectadas. La guía utiliza el modo `/api/v2` y el estado nativo del pin V1; el API actual no expone la activación de recuperación o la elegibilidad específica de la solicitud, por lo que el panel informa que son desconocidos. La delegación V1/plaintext-compatible sigue siendo una alternativa. La recuperación experimental de V2, donde es elegible y explícitamente habilitada, agrega uso de cuota, latencia, dependencia de backend y posible pérdida de fidelidad; no repara el protocolo ascendente. Véanse [superficies de subagentes](/es/guides/sub-agent-surface/) y [La limitación aguas arriba](https://github.com/lidge-jun/opencodex/issues/92).
+
+<a id="paginated-history-safety-refusal"></a>
+
+## Historial paginado de rechazo de seguridad
+
+Cuando un almacén de historial afectado admite registros paginados, una transición de proveedor puede devolver `history_paginated_requires_native_writer`. Esa razón ya no rechaza la configuración Codex, el perfil de referencia o el catálogo de modelos. `ocx sync` y `ocx start` todavía escriben esos archivos y establecen `model_catalog_json`, por lo que el selector de modelos Codex sigue mostrando cada modelo OpenCodex. Sólo esta razón se mantiene la conversación-historia reetiqueta hacia abajo, porque Codex asigna paginado despliegue ordinales en su propio escritor y ningún reintento cambia eso. Cualquier otro motivo de pre-vuelo de la historia - una base de datos de estado ilegible, un despliegue cuya identidad cambió, o un pre-vuelo que no pudo ejecutarse - todavía rechaza toda la transición y la devuelve, porque esos pueden tener éxito en un intento posterior. OpenCodex nunca modifica los archivos de despliegue paginados o las filas de subprocesos en este estado. Las conversaciones existentes mantienen el proveedor con el que ya están etiquetadas y no se migran; las nuevas conversaciones se enrutan normalmente a través del proxy. Cuando el reetiquetado se apaga, una tabla `[model_providers.opencodex]` que la casa ya tenía se mantiene en lugar de retirarse, incluso en la forma de anulación de raíz (loopback), por lo que las conversaciones cuyas filas están etiquetadas `opencodex` mantienen un ID de proveedor que todavía existe. Esto incluye filas heredadas en una tienda con capacidad de migración. El CLI imprime `Codex resume history: left to Codex's native writer (history_paginated_requires_native_writer)`.
+
+Al volver al formulario de anulación de raíz, OpenCodex conserva una definición `[model_providers.opencodex]` existente antes de confirmar la configuración, incluso si el historial de pre-vuelo pasa actualmente. Esto hace que las conversaciones más antiguas de `opencodex` se puedan resolver si Codex migra el historial después de esa confirmación o mientras se inicia el trabajador en segundo plano. Las nuevas conversaciones aún usan el proveedor raíz seleccionado; la restauración explícita mantiene sus protectores de eliminación separados.
+
+`ocx restore`, `ocx stop` y `ocx uninstall` Ya no se niegan a `history_paginated_requires_native_writer`. Toman cada clave de enrutamiento raíz OpenCodex y mantienen la `[model_providers.opencodex]` definición en el disco, por lo que las conversaciones cuyas filas todavía nombran ese proveedor siguen resolviendo mientras se `codex` Deja de apuntar al proxy. El resultado se informa como una restauración parcial que nombra las líneas retenidas, y `ocx restore --remove-codex-provider-table` También los elimina, después de lo cual esas conversaciones dejan de abrirse.
+
+Habilitar la integración en su formulario de tabla de proveedores en una casa cuyas `openai` conversaciones etiquetadas Codex ya se han paginado solía ser rechazado por completo con `history_paginated_openai_requires_native_writer`: no se escribió nada y la integración se mantuvo inhabilitada. OpenCodex ahora completa esa transición manteniendo la raíz administrada `openai_base_url` al lado de la tabla `[model_providers.opencodex]`. Codex fusiona la anulación en su proveedor `openai` incorporado, por lo que esas conversaciones siguen llegando al proxy sin ser reetiquetadas y no se toca ningún byte de despliegue o fila de hilos. Solo un formulario de enrutamiento que requiere la cabecera de admisión `x-opencodex-api-key` todavía se niega, porque el proveedor incorporado de Codex no puede llevar esa cabecera; su mensaje nombra las dos configuraciones que lo resuelven: la ruta Codex a través del oyente de bucle de retorno para que la anulación pueda conservarse, o establece `syncResumeHistory` a `false` para aceptar que esas conversaciones se reanuden contra el propio punto final OpenAI de Codex.
+
+<a id="remote-thread-list-provider-filters"></a>
+
+### Filtros de proveedor de listas de hilos remotos
+
+El enrutamiento de tabla de proveedor cambia el identificador de proveedor predeterminado para nuevas conversaciones a `opencodex`, mientras que el historial que no se puede volver a etiquetar de forma segura puede permanecer etiquetado como `openai`. Algunas versiones nativas de app-server/mobile tratan un filtro `thread/list.modelProviders` omitido como el proveedor predeterminado actual solamente, por lo que esas conversaciones existentes pueden desaparecer de esa lista remota aunque su fila de base de datos y su despliegue estén intactos. Un cliente de lista compatible puede enviar `modelProviders: []` para solicitar todos los proveedores. OpenCodex no puede reescribir ese RPC porque el cliente remoto habla directamente con el servidor de aplicaciones nativo de Codex en lugar del proxy de inferencia.
+
+`ocx sync` y `ocx start` incluyen la advertencia cuando aplican una ruta de tabla de proveedores. Si una URL raíz propiedad del usuario envía el comando por la rama sin enrutamiento, el CLI omite la advertencia. En el modo de compresión cliente, el CLI puede retener esa URL, aplicar la tabla de proveedores `opencodex` e incluir la advertencia. El panel de control muestra una sugerencia de preferencia separada cuando cualquiera de las opciones está habilitada. Aparece una vez si ambas configuraciones están habilitadas, independientemente de la URL raíz. La sugerencia informa las preferencias habilitadas; no significa que Authless Desktop sea efectivo en la ruta actual. Authless Desktop solo se aplica al enrutamiento efectivo sin bucle de retorno y se ignora para el enrutamiento de clientes remotos o los oyentes que requieren un encabezado de admisión. La advertencia no es una migración: OpenCodex no edita etiquetas de proveedor simplemente para influir en un filtro de lista del lado del cliente. Verifique la conversación en Codex nativo y la versión de aplicación-servidor/cliente; no reescriba el historial paginado para hacer que una lista remota lo incluya.
+
+No reescriba una implementación paginada activa o una fila de hilos para migrar esas conversaciones usted mismo. Cierre la conversación afectada antes de cualquier recuperación e informe el error exacto y las versiones sin cargar el historial privado. Una copia de seguridad o un script exitoso por sí solos no prueban que la conversación sea visible nuevamente. Compruebe la conversación restaurada en Codex después de reabrir.
+
+<a id="experimental-native-mid-turn-steering"></a>
+
+## Dirección a mitad de giro nativa experimental
+
+Para un modelo compatible en la ruta canónica de reenvío ChatGPT, y un cliente que envía `response.steer`, habilite ambas opciones en `~/.opencodex/config.json` y reinicie OpenCodex antes de comenzar un nuevo turno:
+
+```json
+{
+  "websockets": true,
+  "codexNativeSteering": true
+}
+```
+
+Fusione estas claves en la configuración existente; no reemplace la configuración de su proveedor/cuenta. Esta opción está desactivada por defecto. Reenvía la dirección a la misma conexión nativa WebSocket configurada explícitamente y a la cuenta seleccionada, preservando las respuestas sucesoras automáticas y las continuaciones pendientes de resultados de herramientas guardadas. Aceptación significa en cola, aún no aplicada.
+
+Suministre los resultados de la herramienta requerida o las decisiones de aprobación **Una vez por padre**, en el mismo carril. Los resultados pueden llegar antes de `response.steer.pending`: el relé también coincide con las llamadas y aprobaciones anunciadas del padre completado. Un `name` en un stub de salida de función pendiente es opcional en el resultado, como en el esquema nativo. Mensajes de usuario adicionales pueden acompañar estos resultados; mensajes del sistema/desarrollador, resultados duplicados e ID de llamada no relacionados son rechazados. No vuelva a ejecutar las herramientas ni vuelva a enviar el texto de dirección aceptado. Las declaraciones de modelo, cuenta, herramienta y enrutamiento permanecen sin cambios. La configuración de generación validada puede cambiar en una continuación de resultado guardado explícita como se describe a continuación. Otros cambios requieren un giro explícitamente detenido o terminado y un nuevo envío normal. Múltiples conversaciones independientes utilizan conexiones independientes.
+
+El fallback HTTP, las puertas de enlace no canónicas, las rutas públicas de clave API, los modelos traducidos, los sidecares, los intentos de Combo y la restauración de texto plano V2 no admiten esta opción. No añade capacidad de dirección a un modelo ni a un cliente que carece de ella. Las rutas no compatibles devuelven un error de protocolo en lugar de ignorar silenciosamente la entrada. La entrega desconectada o con tiempo de espera agotado puede ser desconocida: nunca reenvíe automáticamente herramientas ni texto de dirección. Los controles pendientes tienen plazos de confirmación absolutos de 90 segundos por envío; las esperas de resultados de herramientas guardadas tienen un límite de 30 minutos.
+
+La implementación tiene cobertura sintética de protocolo y regresión, no certificación Astra / cliente en vivo. Mantenga la opción desactivada para el trabajo de producción hasta que se haya verificado la ruta de su cliente/modelo. Establezca `codexNativeSteering` en `false` y reinicie para restaurar el relé de respuesta única existente; no es necesario eliminar ningún archivo de cuenta o conversación.
+
+
+<a id="steering-confirmation-deadlines-and-retained-context"></a>
+
+### Dirección de los plazos de confirmación y contexto retenido
+
+Cada dirección enviada tiene una ventana de acuse de recibo fija de 90 segundos. Otras salidas y novillos adicionales no lo extienden. Una vez aceptada, la entrada permanece en cola mientras que la respuesta actual alcanza un límite seguro; las comprobaciones ordinarias de flujo inactivo aún se aplican. Después de que la respuesta termina, el sucesor debe comenzar dentro de los 90 segundos. Una solicitud de resultados o aprobación de la herramienta permite 30 minutos desde la primera notificación de este tipo. Los avisos repetidos no renuevan esta espera. El envío de los resultados guardados inicia una nueva ventana sucesora de 90 segundos, que incluye comprobaciones locales de ritmo/auth. Los reconocimientos que faltan siguen sujetos a sus plazos individuales anteriores.
+
+La conexión propia no tiene un límite de vida absoluto. Hasta 128 respuestas pueden compartirlo, y cada una puede consumir legítimamente su propio reconocimiento, sucesor, espera de flujo inactivo y espera de entrada requerida, por lo que los plazos por etapa anteriores se componen en el peor de los casos del orden de decenas de horas. Durante ese tiempo, el turn tiene un socket físico y una credencial anclada que no puede rotar, porque el canal deliberadamente nunca vuelve a entrar en la selección de cuenta. Tratar una conexión de dirección habilitada como un recurso de sesión de larga duración en lugar de una solicitud limitada ordinaria.
+
+Los marcos de dirección también comparten los límites de cuerpo y memoria configurados del proxy. Se rechaza una trama de control por encima de [`maxInboundBodyBytes`](/es/reference/inbound-body-admission/) antes de analizarla en una conexión de control establecida (una trama inicial todavía se analiza antes de que se aplique su límite basado en tipo), y se rechaza el cuerpo reconstruido enviado aguas arriba cuando excede de [`maxUpstreamBodyBytes`](/es/reference/configuration/providers/). El diario de repetición de cada conexión tiene un límite de 32 MiB y se cuenta como estado anclado contra [`appOwnedMemoryBudgetMb`](/es/reference/configuration/server/); admitir un diario degrada primero los cachés desalojables en lugar de fallar, y el agregado en los diarios en vivo tiene un límite de 128 MiB independientemente del presupuesto configurado.
+
+Un tiempo de espera significa **La entrega es desconocida**, no es que el servidor rechazó la entrada. No vuelva a enviar una instrucción aceptada ni vuelva a ejecutar una herramienta automáticamente. Inspeccione el estado real de la tarea antes de decidir cómo reanudarla. No se realiza ningún cambio de cuenta o reserva de pago API. La salida completada ya recibida en el cable se retiene para el historial de continuación local incluso cuando el resumen del terminal lo omite. El contenido u orden del artículo en conflicto causa un fallo explícito en lugar de una pérdida de contexto silenciosa.
+
+Para una comparación en vivo, use la misma versión, modelo y cuenta de cliente compatibles en conversaciones de prueba aisladas, una vez sin el proxy y una vez con él habilitado. Use una tarea de solo lectura, dirija mientras la salida está activa y compare la aceptación y la adherencia real a la instrucción del sucesor. Repita mientras el resultado o la aprobación de una herramienta sintética está pendiente y después de una desconexión explícita. Registrar solo tipos de eventos, tiempos relativos y resultados redactados, no credenciales o cuerpos de tareas. Pasar pruebas de transporte simulado no establece soporte en vivo para el cliente / backend; estas instrucciones no implican una prueba de humo de cuenta real.
+
+<a id="experimental-native-function-result-injection"></a>
+
+## Inyección experimental de resultado de función nativa
+
+Para un cliente compatible que envía mensajes OpenAI multiagente `response.inject`, combine estas claves en la configuración OpenCodex existente y reinicie antes de un nuevo turno. No reemplace la configuración de su proveedor o cuenta:
+
+```json
+{
+  "websockets": true,
+  "codexNativeInjection": true
+}
+```
+
+El `response.create` inicial debe incluir expresamente `"multi_agent": { "enabled": true }`. OpenCodex no lo activa por el nombre del modelo. Un proveedor de la API pública de OpenAI debe usar `adapter: "openai-responses"`, `baseUrl: "https://api.openai.com/v1"`, su autenticación normal con clave API y `upstreamWebsocket: true`. Enruta el modelo inicial con el prefijo configurado de ese proveedor. Solo en esa conexión a la API pública se añade el token beta obligatorio `responses_multi_agent=v1`, conservando los demás tokens beta configurados. OpenCodex no sustituye una credencial de suscripción, ni crea una cuenta API, ni cambia automáticamente a una API con facturación separada.
+
+Las conexiones canónicas de reenvío a ChatGPT pueden activar experimentalmente el mismo transporte, pero el contrato de la API pública **no garantiza** compatibilidad con suscripciones ChatGPT ni con Codex App o CLI. Siguen siendo necesarios un modelo y un modo de ejecución compatibles del proveedor. Consulta el [protocolo multiagente de OpenAI](https://developers.openai.com/api/docs/guides/responses-multi-agent).
+
+Devuelve un resultado de la herramienta guardada después de que la llamada a la función de desarrollador correspondiente haya finalizado:
+
+```json
+{
+  "type": "response.inject",
+  "response_id": "resp_example",
+  "input": [
+    { "type": "function_call_output", "call_id": "call_example", "output": "saved result" }
+  ]
+}
+```
+
+Utilice los identificadores de respuesta/llamada del **La misma conexión**, no estos identificadores de ejemplo. `response.inject` acepta solo `function_call_output` con valor de cadena. Los mensajes de usuario/sistema, matrices de salida enriquecidas, resultados de herramientas alojadas y `response.steer` simultáneos no son aceptados por esa operación. La continuación de resultado guardado más amplia a continuación es una operación separada `response.create`, no una conversión oculta de inyección rechazada. Múltiples resultados de funciones guardadas pueden compartir una sola inyección. Cada llamada se puede enviar solo una vez, incluso mientras está en cola.
+
+Los resultados de la herramienta paralela se ponen en cola y se envían un fotograma a la vez, ya que el evento de éxito identifica la respuesta en lugar de una inyección individual. El relé conserva `response.inject.created` y `response.inject.failed`. Mantiene la conexión activa después de que un terminal de respuesta mientras los resultados enviados esperan confirmación o las llamadas anunciadas esperan resultados, por lo que los resultados asíncronos tardíos no se descartan.
+
+Cuando el servidor rechaza una inyección con `response_already_completed`, use sus salidas guardadas devueltas en **Un cliente enviado** `response.create` con el `previous_response_id` completado, modelo/configuración sin cambios y el mismo carril. Incluya cada resultado sobresaliente exactamente una vez; no incluya resultados ya aceptados. El relé mantiene esa continuación en la cuenta / socket original y conserva el ritmo normal de la solicitud. Nunca ejecuta la herramienta de nuevo o crea una solicitud de recuperación en sí. Otras fallas permanecen visibles para que el cliente las maneje.
+
+Un acuse de recibo faltante o una entrega de medios de desconexión puede ser **Desconocido**. No vuelva a enviar un resultado automáticamente, reinicie una herramienta o cambie de cuenta para volver a intentarlo. La cola pendiente está limitada a 32 tramas y 8 MiB, con 1.024 llamadas de función anunciadas, un diario de reproducción de 32 MiB y como máximo 128 respuestas por conexión propia. Los diarios de inyección comparten el presupuesto de memoria fijado y el techo agregado de 128 MiB con los diarios de dirección; véase [límites de memoria de dirección](#steering-confirmation-deadlines-and-retained-context). El límite de cuerpo ascendente configurado se comprueba antes de que un resultado entre en la cola, incluso mientras otro resultado espera el acuse de recibo. Un rechazo `outbound_body_too_large` deja la conexión utilizable para un resultado corregido sin volver a ejecutar su herramienta. Cada inyección enviada tiene un plazo de confirmación de 90 segundos que la salida no relacionada no puede extender; una espera de resultado guardado está limitada a 30 minutos. Los límites de marco existentes y los tiempos muertos todavía se aplican.
+
+Los proveedores traducidos, las puertas de enlace personalizadas, las rutas Combo / sidecar y el retroceso HTTP no obtienen soporte de inyección. Los intentos no soportados devuelven un error explícito en lugar de desaparecer. La opción permanece desactivada por defecto; las pruebas de transporte sintético no son una certificación de compatibilidad en vivo. Ajuste `codexNativeInjection` a `false` y reinicie para retroceder. No es necesario eliminar ningún archivo de cuenta o conversación.
+
+
+<a id="rich-tool-results-and-explicit-approvals-after-response-completion"></a>
+
+### Resultados enriquecidos de la herramienta y aprobaciones explícitas después de completar la respuesta
+
+Con `codexNativeInjection` habilitado, un cliente-enviado `response.create` en la misma conexión de propiedad ahora puede devolver **no enviado** resultados de función/personalizados que contienen texto, imagen o partes de archivo después de `response.completed`. Suministre el `previous_response_id` de la respuesta completada, el mismo carril y el mismo modelo / configuración sin cambios. Incluya cada resultado sobresaliente o aprobación solicitada exactamente una vez; omita los resultados inyectados ya aceptados. El proxy reenvía esta continuación enviada por el llamante usando la cuenta original y el socket con las comprobaciones de envío existentes.
+
+Los elementos de continuación admitidos son `function_call_output`, `custom_tool_call_output` y `mcp_approval_response`. La salida de la herramienta puede ser una cadena o una matriz de `input_text`, `input_image` y `input_file` partes. Las piezas de imagen requieren `detail` (`auto`, `low`, `high` o `original`); el detalle del archivo es opcional (`auto`, `low`, `high`). Utilice exactamente una fuente de imagen / archivo. Los datos de archivo en línea requieren un nombre de archivo. Se conserva la opción `prompt_cache_breakpoint: { "mode": "explicit" }`. Los campos no admitidos son rechazados, no eliminados. Las referencias no se descargan ni se vuelven a cargar por el proxy. Cada resultado tiene como máximo 1.024 partes de contenido dentro del límite de solicitud de 8 MiB existente. Una persona que llama al programa suministrado debe coincidir con la llamada anunciada; no puede hacerse pasar por otra herramienta o agente. El orden del contenido, las referencias de archivos y la ortografía original sobreviven.
+
+Para un `mcp_approval_request` emitido por el servidor, pase su ID como `approval_request_id` y un `approve: true` o `approve: false` explícito. La denegación se envía sin cambios. El proxy no decide, por defecto, aprueba automáticamente ni ejecuta la herramienta solicitada. Se rechaza una decisión faltante o no relacionada. Las acciones alojadas `multi_agent_call` y otras herramientas de ejecución de servidor son **no** funciones de desarrollador: sus eventos, salidas y mensajes de agente cifrados se conservan, nunca se ejecutan o se inyectan antes de OpenCodex.
+
+Esto no permite una respuesta rica / personalizada / de aprobación **inyección de respuesta media**, ni una dirección simultánea en una respuesta multiagente. Esas operaciones tienen diferentes contratos ascendentes. La inyección no admitida se rechaza antes de reservar una llamada, por lo que un resultado no enviado permanece disponible para una continuación explícita posterior. No hay conversión automática, reintento, reejecución de herramientas o cuenta / interruptor API. Un giro de dirección de agente único puede seguir un giro de agente múltiple completado como una nueva solicitud explícita utilizando enrutamiento ordinario. El soporte al cliente y el derecho de backend aún requieren verificación en vivo.
+
+
+<a id="steering-continuation-settings"></a>
+
+## Configuración de continuación de dirección
+
+Un resultado guardado explícito `response.create` puede anular `reasoning` (esfuerzo y resumen), `text` (verbosidad y formato de salida estructurado compatible) y `stream_options`. Las rutas de suscripción rechazan una anulación `max_output_tokens` en lugar de ignorarla silenciosamente. Los pines de proveedor normales, los límites de subagente, la asignación de esfuerzos y las exclusiones de capacidad de resumen/verbosidad aún se aplican.
+
+Los ajustes omitidos retienen los valores efectivos actuales; el valor nulo explícito restablece ese ajuste donde el flujo ascendente acepta null. Las anulaciones reemplazan el objeto de ajuste suministrado, no los campos anidados individuales. Los valores cambiados se trasladan a continuaciones explícitas posteriores. Una anulación rechazada no reserva el resultado guardado, por lo que se puede enviar una solicitud corregida sin volver a ejecutar su herramienta. El servidor aún decide qué configuración acepta el modelo elegido. Los cambios en el modelo, cuenta, proveedor, herramientas, instrucciones o nivel de servicio requieren un turno ordinario separado.
+
+La dirección nativa está restringida a la ruta canónica de suscripción de ChatGPT. Las rutas públicas de clave API y de puerta de enlace no son dirigibles; sus respuestas ordinarias se conservan y un intento de dirección recibe un error explicativo. Esto impide que las generaciones sucesoras en un socket retenido eviten la admisión normal por solicitud. La vía de inyección multiagente pública con su propia compuerta de API sigue disponible.
+
+<a id="executable-direct-versus-proxy-wire-probe"></a>
+
+### Prueba ejecutable del protocolo directo frente al proxy
+
+Desde una comprobación de origen, ejecute el control positivo fuera de línea:
+
+```sh
+bun scripts/steering-smoke.ts --self-test
+```
+
+Planifique una comparación sin leer tokens ni abrir ninguna conexión:
+
+```sh
+bun scripts/steering-smoke.ts --direct wss://api.openai.com/v1/responses \
+  --proxy ws://127.0.0.1:1455/v1/responses --model <supported-model> \
+  --proxy-model <provider-prefix/same-model>
+```
+
+Para una comparación de suscripción, la URL directa es `wss://chatgpt.com/backend-api/codex/responses`. Seleccione el mismo modelo y cuenta reales en ambas rutas; el script no puede probar que una configuración proxy seleccionó la misma cuenta. La URL proxy debe ser un punto final Responses de bucle y no debe contener credenciales, parámetros de consulta ni un fragmento.
+
+Solo después de revisar el plan, suministre `STEERING_DIRECT_TOKEN` y `STEERING_PROXY_TOKEN` a través de su entorno de shell y agregue **ambos** `--live` y `--allow-model-requests`. Una conexión directa ChatGPT puede necesitar adicionalmente `STEERING_DIRECT_ACCOUNT_ID`; ese encabezado nunca se copia al público API o al proxy. No ponga credenciales en argumentos de comando, registros, capturas de pantalla o solicitudes de extracción (PR). El script no lee el inicio de sesión Codex guardado, actualiza tokens o cambia la configuración.
+
+La ejecución en vivo envía cuatro solicitudes iniciales sintéticas (dos escenarios por ruta), más cualquier sucesor resultante o continuación de resultado requerido, y **puede consumir el uso del modelo**. Un escenario comprueba un sucesor automático; el otro devuelve un resultado sintético fijo solo para la función anunciada del propio script y cambia el razonamiento/verbosidad en su continuación explícita. No se ejecuta ninguna herramienta externa y no se infiere ninguna aprobación. No hay reintentos ni solicitudes de recuperación automática. Cada escenario está limitado a 120 segundos, 5.000 eventos y 2 MiB de datos recibidos.
+
+El informe JSON contiene solo resultados, tiempos y puntos de control booleanos. Un pase requiere una aceptación en cola, un sucesor creado y el marcador sintético en su salida completada. Las confirmaciones ausentes son `unknown`; si el modelo nunca entra en la ruta de entrada requerida, el resultado es `not_exercised`. Ninguno de los dos cuenta como pase. El proceso sale con 0 solo si pasan los cuatro escenarios en vivo, con 1 en caso contrario y con 2 para argumentos no válidos o credenciales ausentes. Se trata de un **diagnóstico del protocolo**, no de una prueba de interfaz de extremo a extremo de Codex App/CLI, una certificación en vivo ni una instrucción para habilitar la función experimental para el trabajo de producción.
+
+<a id="streaming-line-endings"></a>
+
+## Finales de línea de streaming
+
+El decodificador SSE compartido acepta terminaciones de línea LF, CRLF y CR independientes, incluso cuando un delimitador abarca fragmentos de red. Esto permite a los proveedores compatibles transmitir eventos sin requerir encuadre de solo LF.
+
+
+<a id="account-qualified-requests-and-credits"></a>
+
+### Solicitudes y créditos calificados para cuentas
+
+Elegir un modelo calificado para la cuenta no permite el gasto de crédito. Las cuentas almacenadas obedecen a **Usar créditos después del límite** durante la autenticación, cuando se preparan las credenciales y antes del envío de Responses HTTP o WebSocket después de la espera de estimulación o reintento. Una solicitud retenida informa de la política de crédito, no de un fallo de autenticación; espere a que se restablezca, elija otra cuenta o habilite explícitamente el gasto de crédito de esa cuenta.
+
+Los ayudantes de visión de cuenta almacenada y búsqueda web también vuelven a verificar esta política antes de enviarla, incluidos los reintentos. Si el consentimiento cambia o se alcanza un límite después de la selección del ayudante, el ayudante informa el rechazo de la política sin enviar ese intento. El relé de búsqueda independiente devuelve un 429 unido por reinicio. Las credenciales Direct propiedad de la persona que llama conservan su comportamiento existente.
+
+<a id="opt-in-a-custom-provider-to-managed-local-routing"></a>
+
+## Optar por un proveedor personalizado para administrar el enrutamiento local
+
+Un proveedor personalizado como `chatgpt-http` puede usar `supports_websockets = false` para mantener el transporte HTTP. OpenCodex deja a los proveedores personalizados intactos por defecto. Para delegar solo la URL de ese proveedor en OpenCodex, ejecute:
+
+```sh
+ocx codex-provider allow chatgpt-http
+ocx start
+```
+
+El primer comando explica el alcance y pide confirmación, por defecto a No. Para una operación con script explícitamente aprobada, use `allow chatgpt-http --yes`. El consentimiento se aplica a este ID de proveedor en el `CODEX_HOME` seleccionado; no aprueba otros proveedores u otros hogares. Inicie y sincronice solo su `base_url` con el proxy local. Su identidad, configuración WebSocket, otros campos TOML e historial permanecen sin cambios. Mantenga el proxy en ejecución mientras usa esta ruta. Desactivar la integración Codex también impide que las actualizaciones de URL del proveedor aprobado se inicien o sincronicen; el consentimiento del proveedor guardado permanece disponible cuando lo vuelva a encender.
+
+Este modo admite tablas de proveedores explícitas Responses con `requires_openai_auth = true` y sin credenciales o encabezados personalizados. Los objetivos no loopback, el modo de escritorio authless y la compactación del cliente requieren la integración dedicada existente.
+
+`ocx stop` y `ocx restore` restauran las URL registradas mientras mantienen el consentimiento para un inicio posterior. Ejecute `ocx codex-provider status` para enumerar las aprobaciones, o `ocx codex-provider revoke chatgpt-http` para restaurar su URL administrada y eliminar el consentimiento. Una URL cambiada fuera de OpenCodex se conserva y requiere revocación seguida de una nueva aprobación; OpenCodex no adopta silenciosamente el reemplazo como una nueva línea de base. La asignación de URL original se conserva en metadatos de recuperación privados bajo `OPENCODEX_HOME`, por separado de la revista de configuración nativa.
+
+La seguridad de inicio reconoce la URL administrada registrada de un proveedor aprobado como enrutamiento OpenCodex. Esto no instala protección de reinicio: un proxy iniciado manualmente todavía necesita un servicio de fondo viable para recuperarse automáticamente después de un reinicio.
+
+<a id="native-desktop-relay-connect-validation"></a>
+
+## Validación de relé de escritorio nativo CONNECT
+
+El transporte CONNECT HTTP / HTTPS existente del relé de escritorio ahora rechaza las cabeceras de respuesta proxy mal formadas y los nombres de usuario básicos ambiguos HTTP que contienen dos puntos. Los pares de credenciales decodificadas están limitados a 4096 bytes UTF-8. Si el proxy seleccionado es rechazado, corrija su configuración o respuesta; el relé no cambia silenciosamente a una conexión directa.
+
+La selección de proxy, el soporte SOCKS5h, la verificación de certificados y el ciclo de vida de la conexión no cambian. Ambas ortografías SOCKS retienen la resolución DNS de destino remoto.
+
+
+**Pool sin la cuenta principal.** `"codexPool": {"poolOnly": true}` limita la selección automática a cuentas añadidas aptas; no ordena, conserva ni recurre a la principal y trata una fijación manual sobre ella como ausente. Sin una cuenta permitida, rechaza. Los modelos con cuenta explícita, incluido `__main__`, y Direct siguen pudiendo usarla. Está desactivado por defecto.
+
+En macOS, después de selecciones explícitas, shims, PATH, instalaciones conocidas y el fallback `codex` ejecutable, se examina la CLI de `/Applications/ChatGPT.app` y `~/Applications/ChatGPT.app`. Exige `com.openai.codex` en el XML `Info.plist` y nunca sustituye una selección persistida ejecutable automáticamente. Sin otra CLI, la comprobación de catálogo de `ocx connect status` también consulta esos paquetes para no informar `unverified` cuando la aplicación es la única instalación.
+
+**Diagnóstico del prefijo de caché.** Solo conserva procedencia y etiquetas de igualdad HMAC del proceso para cuenta, clave de caché, encabezados de sesión e instrucciones, herramientas y mensajes ordenados; nunca texto, nombres de herramientas o IDs originales. La clave aleatoria es independiente, no persiste y solo permite comparar dentro del proceso.
+
+- `session.inboundHeaders` y `outboundHeaders` etiquetan `session_id`, `session-id`, `thread-id` y `x-session-id` por separado; valores iguales comparten etiqueta entre nombres y direcciones. No observado es distinto de ausente observado; no demuestra afinidad.
+- `accountAffinity` deriva una clave de conversación; `derived-key-not-binding` no demuestra que se guardó, seleccionó o reutilizó un vínculo. Las etiquetas de ruta se informan aparte.
+- `prefix.comparison` compara entrada y salida. `continuation` compara con la última solicitud finalizada con la misma identidad de sesión completa no vacía, ámbito autenticado, protocolo, modelo y directorio. El ámbito se captura antes del puente, solo en memoria, y aísla claves distintas. Sin admisión autenticada, incluso loopback sin credencial, es `uncomparable`; la comparación del turno sigue disponible. Cambiar proveedor no la reinicia; claves de prompt y etiquetas de cuenta se comparan aparte. Una identidad de solo salida no reemplaza la que falta.
+- Resultados: `first`, `equal`, `append-only`, `different`, `truncated`, `uncomparable`. Solo crecer al final de mensajes es append-only; instrucciones y sistema preceden herramientas y los mensajes conservan orden. No observado o incompatible no equivale a vacío.
+- Cada sección conserva 128 etiquetas; una cola no observada indica `truncated`. Se conservan 512 historiales recientes; uno expulsado vuelve como `first`.
+
+Son observaciones de cuerpos analizados, no bytes de red ni prueba de caché. Concurrencia se compara al finalizar, no al enviar; no cambia selección de cuentas ni caché, y sigue exigiendo debug para el puente de carriles Chat/Messages aptos.
+
+Codex 0.166 o posterior solo reanuda y enumera conversaciones bajo su proveedor original: `This chat uses openai, but your current provider is opencodex`. Si OpenCodex conoce esa versión y encuentra conversaciones paginadas antiguas, rechaza cambiar a la tabla de proveedor con `history_paginated_openai_provider_locked` sin escribir. Mantén desactivados `codexDesktopAuthless` y `codexClientCompaction` para reanudarlas, o usa `syncResumeHistory: false` para cambiar aceptando que sigan asociadas a `openai`; no se reetiquetan. Sin versión conocida se conserva el override anterior.
diff --git a/docs-site/src/content/docs/es/guides/codex-log-guard-reclaim.md b/docs-site/src/content/docs/es/guides/codex-log-guard-reclaim.md
new file mode 100644
index 00000000000..05f4dc8f8e5
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/codex-log-guard-reclaim.md
@@ -0,0 +1,106 @@
+---
+title: "Recuperación de espacio de Codex Log Guard"
+description: "Recupera manualmente páginas libres de SQLite en la base de datos de registros de Codex, con límites y comprobaciones de integridad."
+---
+
+**Reclaim** compacta manualmente la base de datos canónica `logs_2.sqlite` de Codex, y solo lo hace después de que la base de datos y el entorno de ejecución superen las comprobaciones de seguridad.
+
+Reclaim es **Nunca programado automáticamente** y nunca se ejecuta simplemente porque la página de almacenamiento está abierta. El panel de control requiere una acción Compact explícita y una segunda confirmación antes de enviar la solicitud de mutación.
+
+<a id="what-reclaim-does"></a>
+
+## Lo que hace Reclaim
+
+OpenCodex realiza una secuencia de mantenimiento sin conexión limitada:
+
+1. resolver el canónico `logs_2.sqlite` a través del `sqlite_home` efectivo de Codex;
+2. verificar la identidad del archivo y el esquema de registro Codex conocido;
+3. Verificar que la enumeración del proceso se haya realizado correctamente y que no se esté ejecutando ningún proceso de escritura Codex compatible;
+4. adquirir la cerradura dedicada de proceso cruzado Log Guard;
+5. Repita la comprobación del proceso Codex mientras se mantiene ese bloqueo.
+6. abrir la base de datos existente para lectura y escritura, sin crearla, y comprobar que se puede adquirir inmediatamente el bloqueo de escritura de SQLite;
+7. requieren que `PRAGMA auto_vacuum` ya sea `INCREMENTAL`;
+8. ejecutar `PRAGMA quick_check` antes del mantenimiento;
+9. ejecutar un punto de control WAL completo y rechazar un punto de control ocupado / incompleto;
+10. ejecutar lotes delimitados `PRAGMA incremental_vacuum(N)`, puntos de control después de cada lote;
+11. vuelva a ejecutar `PRAGMA quick_check` después del mantenimiento; y
+12. informe antes/después de métricas de base de datos, WAL, recuento de páginas, lista libre y bytes recuperables.
+
+El objetivo por defecto del lote es aproximadamente **8 MiB de SQLite páginas**. Una sola invocación reclama como máximo aproximadamente **256 MiB de páginas**, con un límite de iteración finita adicional. Si quedan más páginas libres, el resultado se informa como parcial y puede invocar Compact de nuevo más tarde.
+
+Los límites de bytes se convierten en recuentos de páginas usando el tamaño de página real SQLite de la base de datos. Son límites en SQLite páginas lógicas procesadas, no afirmaciones sobre el volumen de escritura SSD / NAND.
+
+<a id="safety-guarantees"></a>
+
+## Garantías de seguridad
+
+Esta operación no realiza lo siguiente:
+
+- Ejecutar `VACUUM` completo;
+- cambiar el modo `auto_vacuum` en una base de datos Codex existente;
+- eliminar, truncar, renombrar o manipular de cualquier otra forma Codex `-wal` / `-shm` archivos directamente;
+- eliminar filas de diagnóstico;
+- modificar disparadores de protección Log Guard o disparadores de usuario no relacionados;
+- ejecutar mientras se detecta que Codex está activo;
+- proceder cuando la enumeración del proceso es incierta;
+- proceder sobre un esquema de registro futuro desconocido; o
+- continuar después de una comprobación de integridad SQLite fallida.
+
+Un bloqueo Log Guard ocupado, un escritor SQLite ocupado o un punto de control inicial ocupado se devuelven como un rechazo explícito en lugar de volver a intentarlo en segundo plano. Si la contención del punto de control aparece solo después de que un lote de vacío incremental ya se haya comprometido, OpenCodex informa que el trabajo ya se completó como un resultado parcial exitoso con `stopReason: "busy"` en lugar de afirmar que nada cambió.
+
+## CLI
+
+Inspeccione primero el espacio recuperable:
+
+```bash
+ocx storage codex-logs status
+```
+
+Ejecute un pase de mantenimiento limitado:
+
+```bash
+ocx storage codex-logs compact
+```
+
+Para métricas de antes/después legibles por máquina:
+
+```bash
+ocx storage codex-logs compact --json
+```
+
+Si el resultado informa que queda más espacio recuperable, deténgase allí a menos que desee explícitamente otro pase limitado. OpenCodex no hace bucle indefinidamente ni programa un pase de seguimiento para usted.
+
+<a id="management-api"></a>
+
+## API de administración
+
+La compactación se expone solo como un punto final de mutación:
+
+```text
+POST /api/storage/codex-logs/compact
+```
+
+No hay alias GET para la compactación. Una respuesta exitosa contiene un objeto `report` con mediciones de antes/después, recuentos de páginas recuperadas, cambio de tamaño de la base de datos principal física, recuento de iteraciones, completitud, razón de detención y estado de integridad.
+
+Los estados de rechazo típicos incluyen:
+
+- `codex_running`
+- `process_enumeration_failed`
+- `busy`
+- `unsupported_schema`
+- `auto_vacuum_not_incremental`
+- `unsafe_path`
+- `integrity_check_failed`
+- `database_error`
+
+Las fallas de integridad incluyen si ocurrieron antes o después del pase de mantenimiento. Un rechazo de `busy` significa que se detectó contención antes de que se cometiera cualquier lote de vacío; `stopReason: "busy"` dentro de un informe exitoso significa que al menos un lote se cometió antes de que la contención posterior del punto de control detuviera el pase.
+
+<a id="understanding-the-result"></a>
+
+## Entender el resultado
+
+`pagesReclaimed` y `logicalBytesReclaimed` describen SQLite páginas de lista libre eliminadas durante el pase. `physicalDatabaseBytesReclaimed` informa de la reducción observada en el archivo de base de datos principal después de los puntos de control de mantenimiento.
+
+Estos números pueden diferir. SQLite /WAL/comportamiento del sistema de archivos significa que la recuperación de páginas lógicas no garantiza una reducción idéntica inmediata del archivo físico, y ninguna de estas métricas debe interpretarse como escrituras NAND, desgaste de SSD o TBW consumido/guardado.
+
+`complete: true` significa que la lista libre observada llegó a cero. Un resultado parcial usa `stopReason: "page_budget"` cuando el presupuesto de página por ejecución o el límite de iteración finita finaliza el pase, `stopReason: "no_progress"` cuando SQLite deja de reducir la lista libre y `stopReason: "busy"` cuando aparece la contención del punto de control después de la recuperación comprometida. Los tres son resultados limitados; ninguno causa un reintento automático.
diff --git a/docs-site/src/content/docs/es/guides/codex-log-guard.md b/docs-site/src/content/docs/es/guides/codex-log-guard.md
new file mode 100644
index 00000000000..19bc967d94d
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/codex-log-guard.md
@@ -0,0 +1,157 @@
+---
+title: "Codex Log Guard"
+description: "Inspecciona y reduce de forma explícita la persistencia de registros de diagnóstico de Codex sin exponer su contenido."
+---
+
+OpenCodex puede inspeccionar la base de datos persistente de registros de diagnóstico de Codex y, si lo activas expresamente, reducir las filas que Codex guarda. La inspección es de solo lectura. Activar la protección modifica la base de datos y solo se permite cuando coincide el esquema de registros conocido y Codex está detenido.
+
+<a id="what-inspect-reports"></a>
+
+## Qué muestra la inspección
+
+OpenCodex resuelve el valor efectivo de `sqlite_home` siguiendo la precedencia de Codex e inspecciona allí la base de datos canónica `logs_2.sqlite`. Nunca usa como destino modificable un archivo `logs_N.sqlite` heredado o de numeración superior.
+
+La vista Almacenamiento informa:
+
+- el tamaño de la base de datos principal y de sus archivos WAL y SHM;
+- el total de filas y la proporción guardada con nivel `TRACE`;
+- los destinos de registro con más filas, identificados por su posición en la clasificación y sin revelar sus nombres;
+- el espacio de páginas libres de SQLite que podría recuperarse más adelante; y
+- la compatibilidad del esquema observado con el esquema de registros de Codex conocido.
+
+Si `sqlite_home` está fuera de `CODEX_HOME`, la base de datos de diagnóstico se muestra por separado. Sus bytes no se suman implícitamente al almacenamiento de `CODEX_HOME`.
+
+OpenCodex no consulta ni expone `feedback_log_body` al generar estos diagnósticos. Los niveles se reducen al conjunto fijo conocido más `OTHER`, y los nombres de los destinos no se serializan.
+
+<a id="protect-modes"></a>
+
+## Proteger los modos
+
+La protección está **desactivada de forma predeterminada**. Al activarla, se instala un único trigger `BEFORE INSERT`, propiedad de OpenCodex, en `logs_2.sqlite`. OpenCodex nunca reemplaza un trigger desconocido que use sus nombres reservados y solo elimina triggers cuyo SQL coincide con su propia versión.
+
+Hay dos modos disponibles:
+
+- **Compatibilidad** (`compat`) es el modo recomendado. Aplica las reglas de Log Guard v1 a los destinos de gran volumen que Codex ya filtra o guarda con un nivel inferior en su registro SQLite persistente. Conserva las filas `TRACE` de otros destinos.
+- **Silencioso** (`quiet`) suprime todas las filas nuevas de nivel `TRACE` y conserva las de nivel `DEBUG`, `INFO`, `WARN` y `ERROR`.
+
+La protección reduce las filas que llegan al almacenamiento SQLite persistente. **No** elimina el trabajo previo de diagnóstico de Codex: los eventos aún pueden formatearse, encolarse, agruparse en transacciones y pasar por su lógica de limpieza antes de que el trigger descarte una fila. Protect reduce las escrituras persistentes; no desactiva la generación interna de diagnósticos.
+
+Log Guard solo filtra las filas de registro que se guardan en la base de datos SQLite local. No cambia el procesamiento de diagnóstico Codex, [transporte del adaptador](/es/reference/adapters/), las cargas útiles del proveedor, la semántica de transmisión, la autenticación, el enrutamiento, las cuotas o el estado de la cuenta.
+
+<a id="safety-checks"></a>
+
+### Controles de seguridad
+
+Antes de que Proteger, Deshabilitar o Reparar modifiquen la base de datos de Codex, OpenCodex:
+
+1. Resuelve exactamente la ruta canónica de `logs_2.sqlite`.
+2. Comprueba que sea un archivo regular, no un enlace simbólico, y que el esquema coincida exactamente con el conocido.
+3. Comprueba que se hayan podido enumerar los procesos y que no haya ningún proceso de Codex compatible escribiendo en la base.
+4. Adquiere un bloqueo de Log Guard dedicado y compartido entre procesos.
+5. Repite la comprobación de procesos de Codex después de adquirir el bloqueo.
+6. Abre la base de datos para lectura y escritura **sin crearla** y adquiere `BEGIN IMMEDIATE` de SQLite sin esperar si está ocupada.
+7. Modifica únicamente los triggers de Log Guard propiedad de OpenCodex y vuelve a leer el resultado antes de confirmar la transacción.
+8. Guarda el modo solicitado en la configuración de OpenCodex mientras sigue manteniendo el bloqueo de Log Guard.
+
+Si no se puede confirmar la enumeración de procesos, la base está ocupada, el esquema es desconocido o un nombre reservado pertenece a otro SQL, se rechaza la modificación. OpenCodex no cierra Codex automáticamente.
+
+<a id="drift-and-repair"></a>
+
+## Deriva y reparación
+
+El modo de protección solicitado se guarda en la configuración de OpenCodex, separado de la base de datos de registros de Codex. Una migración de Codex puede reconstruir la tabla `logs`; SQLite elimina los triggers asociados a una tabla que se reemplaza.
+
+Si el modo guardado es `compat` o `quiet` pero ya no se observa el trigger correspondiente de OpenCodex, Log Guard informa el estado **drifted**. `ocx doctor` detecta esa divergencia, pero nunca la repara automáticamente.
+
+La reparación es explícita:
+
+```bash
+ocx storage codex-logs repair
+```
+
+OpenCodex no vuelve a crear la protección en cada inicio. Solo se reconsideraría la reparación automática en una versión posterior si hay evidencia suficiente de que es segura entre migraciones de Codex.
+
+## CLI
+
+Leer estado:
+
+```bash
+ocx storage codex-logs status
+ocx storage codex-logs status --json
+ocx doctor
+```
+
+Habilitar la directiva de compatibilidad recomendada:
+
+```bash
+ocx storage codex-logs protect
+```
+
+Elija el modo silencioso explícitamente:
+
+```bash
+ocx storage codex-logs protect --mode quiet
+```
+
+Desactivar OpenCodex protección o reparación deriva:
+
+```bash
+ocx storage codex-logs unprotect
+ocx storage codex-logs repair
+```
+
+Agregue `--json` a los comandos Log Guard para obtener una salida legible por máquina. Vea el [CLI referencia](/es/reference/cli/) para la sintaxis canónica de comandos y el comportamiento JSON.
+
+El comando existente permanece sin cambios:
+
+```bash
+ocx storage --json
+```
+
+Su respuesta lleva el mismo estado de registro Codex utilizado por la página de almacenamiento.
+
+<a id="management-api"></a>
+
+## API de administración
+
+El estado está disponible en:
+
+```text
+GET /api/storage/codex-logs
+```
+
+Mutaciones explícitas:
+
+```text
+POST /api/storage/codex-logs/protect
+POST /api/storage/codex-logs/unprotect
+POST /api/storage/codex-logs/repair
+```
+
+El cuerpo de Protect es `{"mode":"compat"}` o `{"mode":"quiet"}`. `GET /api/storage` también incluye el informe como `codexLogs`, para actualizar el desglose de almacenamiento y los diagnósticos de Codex con una sola solicitud de instantánea.
+
+<a id="read-only-snapshot-semantics"></a>
+
+## Semántica de instantáneas de solo lectura
+
+La inspección abre la base de datos en modo de solo lectura con `immutable=1` de SQLite. Así no crea ni actualiza los archivos auxiliares `-wal` o `-shm`.
+
+Esta decisión tiene una limitación: los agregados SQL y los metadatos de triggers describen la última instantánea consolidada mediante un checkpoint. Si Codex está escribiendo, el WAL puede contener filas o páginas de esquema más recientes. Una modificación exitosa devuelve el estado del trigger verificado dentro de su transacción de escritura. Una consulta posterior de solo lectura puede mostrar temporalmente un estado anterior hasta que SQLite consolide esas páginas.
+
+OpenCodex informa el tamaño del archivo WAL por separado y **no** etiqueta el resultado como tasa de escritura SSD, escritura NAND o consumo de desgaste de unidad / TBW.
+
+<a id="compatibility-states"></a>
+
+## Estados de compatibilidad
+
+Con un esquema conocido, se admiten la inspección y la protección. Si el esquema falta, no se puede leer o pertenece a una versión futura desconocida, se pueden inspeccionar los metadatos disponibles, pero no modificar la base.
+
+OpenCodex no presupone que un esquema desconocido sea compatible. Así puede mostrar información de una versión nueva de Codex sin tratar una estructura no revisada como segura para modificar.
+
+<a id="reclaim-is-still-separate"></a>
+
+## La recuperación sigue siendo independiente
+
+Protect no ejecuta vacuum ni compacta SQLite. [**Recuperar espacio**](/es/guides/codex-log-guard-reclaim/) ofrece un proceso independiente de vacuum incremental, explícito, sin Codex en ejecución y con límites, checkpoints y comprobaciones de integridad.
+
+Protect nunca ejecuta `VACUUM`, nunca trunca o elimina WAL de Codex directamente, y nunca realiza una recuperación de espacio programada.
diff --git a/docs-site/src/content/docs/es/guides/codex-native-context.md b/docs-site/src/content/docs/es/guides/codex-native-context.md
new file mode 100644
index 00000000000..88677182af2
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/codex-native-context.md
@@ -0,0 +1,89 @@
+---
+title: "Compatibilidad de contexto nativo"
+description: "Requisitos, prueba autenticada y límites del historial y las notas nativas de Codex."
+---
+
+OpenCodex ya retransmite el historial y las notas nativas de Codex. No es un servicio general de memoria para proveedores enrutados. Exponer sus endpoints HTTP tampoco demuestra que una versión, cuenta o modelo de Codex pueda usarlos. Consulta [Integración con Codex](/es/guides/codex-integration/) para conocer los límites de propiedad, cancelación y credenciales de la retransmisión.
+
+<a id="two-independent-requirements"></a>
+
+## Dos requisitos independientes
+
+Codex debe activar la extensión, y OpenCodex debe identificar al llamante. Cambiar la URL de backend no resuelve ninguno de los requisitos por sí solo.
+
+El contrato de Codex inspeccionado exige un modelo cuya entrada en el catálogo nativo anuncie `supports_experimental_context`, una sesión de ChatGPT elegible y un proveedor llamado exactamente `OpenAI` cuya URL base termine en `/backend-api/codex`. La activación automática rechaza proveedores con `env_key`, `experimental_bearer_token`, `auth` obtenido mediante comandos o autenticación AWS. El criterio inspeccionado admite ChatGPT Plus, Pro y ProLite; esto no demuestra que todas las cuentas de esos planes dispongan de endpoints de historial operativos.
+
+OpenCodex exige además una **clave API activa del plano de datos**, tanto en la solicitud correcta al modelo como en las solicitudes posteriores de contexto. La inyección local predeterminada mediante loopback no envía esa clave: puede atender al modelo mientras las llamadas de contexto fallan con `context_principal_required` (403). Tampoco basta con configurar un proveedor remoto autenticado: su `env_key` y su nombre no cumplen el contrato de activación anterior. No elimines las comprobaciones de identidad ni de propiedad de la cuenta para ocultar estos problemas.
+
+<a id="explicit-opt-in-syntax"></a>
+
+## Sintaxis explícita de opt-in
+
+OpenCodex acepta las dos formas persistidas en la raíz de la configuración que admite `FeatureToml` de Codex:
+
+```toml
+[features]
+context_management = true
+```
+
+La forma de tabla equivalente también funciona y es compatible con versiones anteriores de OpenCodex que aún no reconocían la forma booleana:
+
+```toml
+[features.context_management]
+experimental_mode = true
+```
+
+Usa una forma, no ambas. Los valores falsos, ausentes o mal formados mantienen la función desactivada. El proxy lee la configuración de su propio directorio de Codex: una anulación exclusiva de la CLI, o una activación presente solo dentro de un perfil de Codex, no habilita la función en el proxy. Tampoco se deduce la activación a partir de los metadatos del modelo.
+
+<a id="authenticated-native-trial-profile"></a>
+
+## Perfil de prueba nativo autenticado
+
+Esta es una **configuración de prueba contrastada con el código fuente; no certifica el funcionamiento de extremo a extremo con una cuenta real**. Haz una copia de seguridad de la configuración de Codex y guarda un punto de recuperación de la tarea antes de probarla. Usa un hilo nuevo y desechable; no cambies la identidad del proveedor de un hilo de trabajo existente.
+
+Proporciona una clave activa del plano de datos de OpenCodex mediante `OCX_CONTEXT_API_KEY` en el entorno del proceso de Codex. No uses un token de administración ni guardes la clave en TOML. Una aplicación de escritorio iniciada por separado no hereda automáticamente el entorno de un servicio. Conserva la sesión nativa de ChatGPT en Codex: el encabezado adicional no sustituye OAuth.
+
+Con la función activada en la raíz, el proveedor canónico de reenvío a ChatGPT configurado en OpenCodex y un catálogo nativo actualizado, agrega este proveedor y este perfil **adicionales** a la misma configuración de Codex. Ajusta el puerto al proxy local real. Conserva el `model_provider` raíz y las tablas de proveedores existentes.
+
+```toml
+[model_providers.ocx-native-context]
+name = "OpenAI"
+base_url = "http://127.0.0.1:10100/backend-api/codex"
+wire_api = "responses"
+requires_openai_auth = true
+supports_websockets = false
+env_http_headers = { "x-opencodex-api-key" = "OCX_CONTEXT_API_KEY" }
+
+[profiles.ocx-native-context]
+model_provider = "ocx-native-context"
+model = "gpt-6-astra"
+```
+
+Inicia un hilo nuevo de CLI con `codex --profile ocx-native-context`. El ejemplo usa HTTP/SSE para mantener la prueba inicial en la ruta de propiedad entre el modelo y la retransmisión. No cambia el transporte de otros perfiles ni certifica la paridad de WebSocket o del control durante el turno. Usa el modelo solo si el catálogo nativo de la cuenta anuncia esa capacidad de contexto; no fuerces la opción en Devin, Gemini ni otros modelos enrutados.
+
+El identificador personalizado del proveedor es intencional. Codex normalmente no sustituye proveedores integrados mediante `model_providers.openai`, por lo que añadir allí un encabezado puede no surtir efecto. El identificador personalizado conserva el proveedor normal; el nombre exacto `OpenAI` satisface el criterio del backend nativo. No añadas `env_key` a este perfil: `env_http_headers` lleva la admisión local por separado y `Authorization` sigue transportando la sesión nativa de ChatGPT. OpenCodex consume la clave local y no la reenvía a ChatGPT.
+
+La activación en la raíz también afecta a otros perfiles nativos elegibles. **Durante la prueba, no continúes hilos locales habituales que no lleven la clave adicional.** Desactiva la función en la raíz y ejecuta `ocx sync` antes de volver a ellos. Esta integración no es automática ni predeterminada, y el perfil de CLI no demuestra que la aplicación de escritorio permita seleccionar ese perfil.
+
+<a id="verify-before-resetting-context"></a>
+
+## Verificar antes de restablecer el contexto
+
+Primero consigue una respuesta correcta del modelo nativo en el hilo nuevo. Después escribe una nota, vuelve a leerla y consulta el historial del mismo hilo. Solo si esas operaciones funcionan, usa `new_context` en una prueba desechable y comprueba que puedas recuperar el estado guardado. Conserva el punto de recuperación externo aunque la prueba tenga éxito.
+
+- **403 `context_principal_required`:** ninguna clave de plano de datos local válida alcanzó el proxy.
+- **409 `context_account_unavailable`:** falta la propiedad de la cuenta o es inconsistente; no la sustituyas por la cuenta activa ni reintentes una escritura a ciegas.
+- **404:** distingue un endpoint desactivado o desconocido del proxy de un 404 del proveedor. El segundo no demuestra un defecto de enrutamiento de OpenCodex ni una interrupción de toda la cuenta.
+
+El éxito de una llamada al modelo o de `ocx ready` no demuestra que funcionen las notas, el historial o la restauración. El enrutamiento, los cambios de cuenta, los reinicios del proxy y la disponibilidad de endpoints del proveedor son aspectos distintos. Ninguna opción local concede una elegibilidad que el backend no ofrece, y un fallo de contexto no debe presentarse como un restablecimiento correcto. Al terminar, elimina las tablas de prueba y retira la clave de su entorno. Mantén la función desactivada salvo que uses una ruta autenticada y verificada.
+
+<a id="upstream-contracts-inspected"></a>
+
+## Contratos ascendentes inspeccionados
+
+Estos enlaces identifican la versión del código fuente usada para contrastar la configuración anterior; no garantizan su disponibilidad para una cuenta concreta:
+
+- [FeatureToml booleano/formas de tabla](https://github.com/openai/codex/blob/78245b47af2a7aafcabe025828ceecca69db4df1/codex-rs/features/src/lib.rs)
+- [Elegibilidad del contexto nativo](https://github.com/openai/codex/blob/78245b47af2a7aafcabe025828ceecca69db4df1/codex-rs/core/src/session/token_budget.rs)
+- [Identidad del proveedor y reglas de fusión incorporadas](https://github.com/openai/codex/blob/78245b47af2a7aafcabe025828ceecca69db4df1/codex-rs/model-provider-info/src/lib.rs)
+- [El historial/las notas utilizan los encabezados de solicitud y la autenticación del proveedor](https://github.com/openai/codex/blob/78245b47af2a7aafcabe025828ceecca69db4df1/codex-rs/ext/history-notes/src/backend.rs)
diff --git a/docs-site/src/content/docs/es/guides/codex-prompt.md b/docs-site/src/content/docs/es/guides/codex-prompt.md
new file mode 100644
index 00000000000..1cf4721dc12
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/codex-prompt.md
@@ -0,0 +1,193 @@
+---
+title: "Capas de instrucciones de Codex"
+description: "Consulta qué instrucciones envía Codex, desactiva las partes innecesarias y añade tus propias capas."
+---
+
+Codex compone sus instrucciones por capas: sus instrucciones base, la documentación del proyecto, el contexto de permisos y del entorno, las habilidades instaladas y otros elementos. **Codex Set → Prompt** muestra esas capas, su costo y los controles para desactivar las que no quieras.
+
+<a id="what-the-list-shows"></a>
+
+## Qué muestra la lista
+
+Cada fila indica su posición en el orden de composición, la clave de configuración que la controla —cuando existe— y el tamaño del texto que realmente se envió.
+
+Las posiciones no son consecutivas. Los números corresponden a los índices reales de composición, y dos de ellos aparecen más abajo, en **Notificaciones de transición**. Renumerar cada grupo desde uno mostraría un orden que Codex no utiliza.
+
+<a id="five-kinds-of-layer"></a>
+
+### Cinco tipos de capa
+
+| Tipo | Qué puedes hacer |
+|---|---|
+| Conmutable aquí | Un interruptor que escribe una clave en `config.toml`. |
+| Configurada en `[features]` | Se puede cambiar desde los ajustes de funciones, no desde esta página. |
+| Siempre activa | Codex no ofrece ningún control para desactivarla. |
+| Se envía al cambiar | Anuncia una transición y solo aparece cuando algo cambia. |
+| Capas de extensión | No se pueden enumerar porque Codex no las expone. |
+
+Si una capa no se puede desactivar, la fila no muestra un interruptor. Mostrarlo deshabilitado sugeriría que la capacidad existe y está temporalmente indisponible.
+
+<a id="reading-a-layer"></a>
+
+## Leer una capa
+
+Haz clic en su nombre para ver el texto que envía. El diálogo lo obtiene de `codex debug prompt-input`: muestra el contenido real, no una descripción.
+
+La lectura dispone de un único presupuesto fijo de 15 segundos para quien la solicita, incluido el tiempo dedicado a leer metadatos y a esperar una consulta de diagnóstico compartida. Las lecturas síncronas de metadatos terminan antes de que se pueda comprobar si ha vencido el plazo; si el presupuesto se ha agotado, se impide iniciar una nueva consulta. Si vence el plazo, el diálogo informa de que no se pudo leer el prompt; las instrucciones base disponibles localmente se devuelven de todos modos.
+
+A veces no hay contenido que mostrar. El diálogo explica cuál de estos casos se aplica:
+
+- **El archivo existe, pero está vacío.** `~/.codex/AGENTS.md` tiene cero bytes y la capa no tiene contenido que enviar. El diálogo muestra la ruta.
+- **No se envió en el turno consultado.** Las capas solo se vuelven a enviar cuando cambian; una muestra de un único turno puede no contener una capa sin cambios.
+- **El prompt base proviene del catálogo de modelos.** Codex lo envía fuera de la lista que se puede consultar. El diálogo lo lee de la fila del modelo seleccionado o del archivo indicado por `model_instructions_file`, si está configurado. Si la fila solo publica una plantilla sin expandir, informa que no puede mostrarla: esa plantilla no es el texto que Codex envía.
+- **No se pudo leer el prompt.** La consulta falló en este equipo.
+
+La lectura usa el directorio global de Codex (`~/.codex`), no el directorio desde el que se ejecuta el dashboard.
+
+<a id="custom-layers"></a>
+
+## Capas personalizadas
+
+**+ Añadir capa** agrega tus instrucciones. Las capas personalizadas forman `developer_instructions`, que se añade a las instrucciones de Codex sin reemplazarlas.
+
+:::note
+Este control no usa `model_instructions_file`. Esa clave reemplaza el prompt base; vincularla con **+** eliminaría las instrucciones de Codex al guardar la primera capa. Para reemplazar el prompt base, usa [Variantes de prompt base](#base-prompt-variants): es una elección explícita y separada de la incorporación de una capa.
+:::
+
+Las capas personalizadas tienen su propia numeración porque se unen en una sola sección, en ese orden. No se intercalan con las capas integradas.
+
+Cambia el orden con las flechas de la fila o con `Alt` + `Up` / `Alt` + `Down` desde cualquier punto de ella. Ese es el orden en el que se compone el texto.
+
+El panel compara el tamaño combinado de las capas habilitadas con el límite de 128 KiB de `developer_instructions` y ofrece una vista previa plegable del texto unido. Así puedes detectar que una capa superaría el límite antes de guardar.
+
+Eliminar una capa requiere confirmación y ofrece **Deshacer** durante unos segundos. Al deshacer, la capa recupera su posición anterior.
+
+<a id="presets"></a>
+
+### Ajustes preestablecidos
+
+**+ Añadir capa** ofrece cinco puntos de partida: salida concisa, plan antes de editar, explicar el razonamiento, probar primero y respuestas en coreano. Cada opción abre el editor con texto editable; al guardar, se crea una capa personalizada normal.
+
+Los textos son propios y resumen un enfoque sin copiar las instrucciones de otra persona. Cada uno identifica su fuente.
+
+<a id="moving-between-layers-while-editing"></a>
+
+### Cambiar de capa durante la edición
+
+El editor tiene controles de anterior y siguiente y un indicador de posición. Conserva las ediciones sin guardar al cambiar de capa, por lo que puedes compararlas y volver sin perder texto. Si cierras el editor con cambios en otra capa, pide confirmación antes de descartarlos. Al guardar una capa, también pide confirmación antes de descartar los cambios pendientes de otras; el botón **Guardar** de esa confirmación solo guarda la capa visible.
+
+<a id="compatibility-warnings"></a>
+
+### Advertencias de compatibilidad
+
+El editor advierte sobre instrucciones que no funcionarían tal como están escritas: afirmar otra identidad, nombrar herramientas definidas en el registro, usar marcadores de plantilla que nada expande o declarar datos del entorno que Codex genera después. También detecta credenciales pegadas —una clave API en una capa se envía al modelo en texto plano en cada solicitud—, instrucciones para abandonar las anteriores y una identidad distinta de Codex declarada en coreano.
+
+Las advertencias no bloquean el guardado. Puedes sustituir instrucciones de Codex de forma deliberada; la advertencia hace visible esa decisión.
+
+<a id="commit-attribution"></a>
+
+## Atribución de commits
+
+La fila **Atribución de commits** pide al modelo añadir `Co-authored-by: Codex` a los commits que escriba y una línea `Generated with Codex.` a los pull requests que abra.
+
+No hay un interruptor aquí ni en `[features]`: Codex obtiene esta elección de la política de atribución de tu cuenta. Desactivarla en la cuenta no elimina la capa; Codex envía la instrucción contraria, que pide omitir la atribución. En ambos casos se envía texto, por lo que la fila figura como controlada por la cuenta, no como siempre activa.
+
+<a id="base-prompt-variants"></a>
+
+## Variantes de prompt base
+
+El prompt base es la única capa que no puedes desactivar: un modelo sin instrucciones base no funciona como agente. Puedes **sustituirlo** con el control de la fila **Instrucciones base**.
+
+Abre la fila para ver el selector. Cambia de opción deslizando horizontalmente, con las teclas de flecha izquierda y derecha o con los botones de flecha. Los lectores de pantalla anuncian esos botones, por lo que no necesitas un panel táctil.
+
+| Opción | Qué es | Editable |
+|---|---|---|
+| Prompt base de Codex | `model_instructions_file` no está en la configuración | nunca |
+| Tu variante | Instrucciones que escribes y se guardan en `~/.codex/opencodex-prompt-base/` | sí |
+| Una segunda variante | Lo mismo, con un máximo de dos variantes | sí |
+
+La primera opción no tiene texto que editar ni botón **Guardar**; el diálogo explica el motivo. El valor predeterminado es la ausencia de la clave, no una copia guardada del prompt de Codex. Elegirlo elimina `model_instructions_file` de la configuración.
+
+:::caution
+Una variante **reemplaza** las instrucciones base de Codex; no se añade a ellas. Si escribes una variante de tres líneas, el modelo solo recibe esas tres líneas: pierde las instrucciones habituales de Codex sobre el uso de herramientas y la verificación del trabajo. Para *añadir* instrucciones conservando la base, usa una [capa personalizada](#custom-layers).
+:::
+
+El editor conserva las ediciones al cambiar de variante y pide confirmación antes de descartarlas al cerrar. Mientras escribes, comprueba el límite de 64 KiB del cuerpo de cada variante.
+
+<a id="if-something-else-already-replaced-your-base-prompt"></a>
+
+### Si otra herramienta ya reemplazó el prompt base
+
+Si `model_instructions_file` apunta a un archivo que opencodex no escribió, el selector rechaza los cambios e indica la ruta. No modifica silenciosamente una elección que hiciste tú u otra herramienta.
+
+**Importarlo como variante** permite convertir ese archivo sin borrar la clave a mano. La vista previa muestra el texto exacto que se instalará: una línea de encabezado `# ` con el título de la variante y el cuerpo del archivo, con saltos de línea y tabulaciones normalizados. Puedes editar el título antes de confirmar. El cuerpo normalizado admite como máximo 64 KiB (`bodyBytes`); el archivo completo, con encabezado, es algo mayor (`serializedBytes`). Un hash vincula la confirmación con la vista previa: si cambia el archivo o el título, se rechaza la importación. Si prefieres volver al valor predeterminado, elimina la clave manualmente.
+
+Se aplica el mismo principio que al importar `developer_instructions`: el panel muestra lo que encuentra y tú decides.
+
+El cambio se aplica a las sesiones nuevas, como los demás ajustes de esta página.
+
+<a id="instructions-written-outside-opencodex"></a>
+
+## Instrucciones escritas fuera de opencodex
+
+Si `developer_instructions` ya existe y opencodex no lo escribió, el panel no lo sobrescribe. Ofrece importarlo como capa: primero muestra el valor existente y solo escribe después de tu confirmación.
+
+<a id="when-something-is-out-of-sync"></a>
+
+## Cuando los valores no coinciden
+
+Si las capas guardadas no coinciden con `config.toml`, el panel lo indica y ofrece **Reparar**. Dos rutas de reparación reescriben texto del usuario y requieren una decisión explícita. Si una escritura quedó interrumpida y existe un diario de recuperación, se ejecuta únicamente la recuperación bajo bloqueo, usando las copias registradas en ese diario; no se guarda de nuevo la lista actual ni se inventa contenido ausente. Si los archivos actuales no coinciden con ningún estado registrado, se rechaza la recuperación y se conserva la evidencia. El panel actualizado informa de cualquier diferencia restante. Si falta un archivo de capa, la reparación hace una copia de seguridad antes de modificar nada.
+
+<a id="when-changes-take-effect"></a>
+
+## Cuándo se aplican los cambios
+
+Los cambios se aplican a las sesiones nuevas. Una sesión en ejecución conserva los ajustes de instrucciones con los que comenzó.
+
+<a id="keeping-the-skills-catalog-stable"></a>
+
+## Mantener estable el catálogo de habilidades
+
+El valor predeterminado del proxy es `skills.catalog_refresh: "per_session"`: reutiliza el primer catálogo `<skills_instructions>` recibido en las solicitudes posteriores de la misma conversación. Esto evita que el descubrimiento de habilidades o la edición de `SKILL.md` cambien el prefijo de caché del proveedor durante una sesión. Una solicitud con más de un bloque `<skills_instructions>` se reenvía sin cambios. Una solicitud rechazada por el proxy no establece el catálogo.
+
+Para usar el catálogo enviado por el cliente en cada turno, configura lo siguiente en `$OPENCODEX_HOME/config.json` —normalmente `~/.opencodex/config.json`— y reinicia el proxy:
+
+```json
+{
+  "skills": {
+    "catalog_refresh": "per_turn"
+  }
+}
+```
+
+Los valores admitidos son `"per_session"` —predeterminado— y `"per_turn"`. Es un ajuste del proxy, independiente de `skills.include_instructions` de Codex. Las solicitudes sin una identidad de conversación fiable usan el catálogo que envía el cliente. Las instantáneas se mantienen en memoria y se pierden al reiniciar el proxy. Caducan tras cuatro horas de inactividad y pueden descartarse si se llena la caché limitada. Un catálogo inicial de más de 512 KiB se reenvía sin guardarlo en caché. Tras la caducidad o el descarte, el siguiente catálogo recibido se convierte en la nueva instantánea. La vista previa del dashboard sigue leyendo los archivos actuales; no muestra la instantánea retenida para una conversación.
+
+<a id="what-this-page-reads-and-what-it-does-not"></a>
+
+## Qué lee esta página
+
+opencodex lee tu archivo `config.toml`. Codex calcula sus ajustes a partir de varias capas; lo mostrado aquí es el valor de tu archivo, que puede diferir del resultado final que resuelve Codex.
+
+<a id="the-keys-this-page-writes"></a>
+
+## Claves que escribe esta página
+
+Estas claves pertenecen al `config.toml` de Codex, no a la configuración propia de opencodex.
+
+| Clave | Predeterminado | Capa |
+|---|---|---|
+| `include_permissions_instructions` | `true` | Permisos |
+| `include_collaboration_mode_instructions` | `true` | Modo de colaboración |
+| `include_environment_context` | `true` | Contexto del entorno |
+| `include_apps_instructions` | `true` | Apps |
+| `skills.include_instructions` | `true` | Habilidades |
+| `developer_instructions` | Sin configurar | Capas personalizadas, unidas en orden |
+| `model_instructions_file` | Sin configurar | Prompt base cuando se selecciona una variante |
+
+Las escrituras modifican líneas y conservan los comentarios y el formato. Las claves que opencodex no reconoce se dejan intactas.
+
+Una clave ausente se interpreta con su valor predeterminado, no como `false`. El panel muestra el valor que contiene el archivo e indica si la clave no está configurada.
+
+Si una fila tiene un valor explícito, ofrece **Restablecer a &lt;default&gt;**. Este control elimina la línea de la clave en vez de escribir el valor predeterminado. Solo la ausencia de la clave permite seguir un cambio futuro del valor predeterminado de Codex; escribir `key = true` fijaría el valor actual como una anulación.
+
+El editor de valores escalares rechaza arrays, tablas en línea y cadenas multilínea antes de escribir o restablecer una clave, conservando los bytes originales. La importación informa explícitamente si no puede leer la configuración. Una vista previa de título de solo lectura mantiene el título editable; confirmar sigue requiriendo una vista previa vinculada a ese título. Los errores HTTP o de medición de red se muestran como fallos, no como si otra consulta estuviera ocupada.
diff --git a/docs-site/src/content/docs/es/guides/combos.md b/docs-site/src/content/docs/es/guides/combos.md
new file mode 100644
index 00000000000..1f2fec02ffd
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/combos.md
@@ -0,0 +1,770 @@
+---
+title: "Combos: conmutación por error y equilibrio de carga"
+description: "Enruta un modelo virtual a varios proveedores, con respaldo ante fallos o reparto ponderado de carga."
+---
+
+Un **combo** es un modelo virtual que representa una lista ordenada de destinos reales de proveedor/modelo. El cliente solicita `combo/<id>`; opencodex elige un destino, reescribe la solicitud con ese `provider/model` concreto y puede probar otro destino si el primero tiene un fallo reintentable.
+
+Esto es útil cuando usted quiere:
+
+- **Conmutación por error:** dar prioridad a un modelo y mantener otros como respaldo.
+- **Equilibrio de carga:** repartir las solicitudes correctas entre modelos o proveedores en lotes ponderados.
+
+Los combos se evalúan antes del enrutamiento normal de proveedores. Consulta primero [Enrutamiento de modelos](/es/guides/model-routing/) si aún no conoces los selectores `provider/model`.
+
+<a id="metered-fallback-consent"></a>
+
+## Consentimiento de fallback medido
+
+Marque un objetivo combinado de pago por uso con `"metered": true` cuando siga los objetivos de suscripción. El consentimiento omitido o falso niega el envío medido. Elija el consentimiento para su implementación:
+
+- **Local Claude Code o Codex:** en un proxy solo loopback, establezca `"allowMeteredTargets": true` en el combo o ejecute `ocx combo set <id> --allow-metered-targets on`. Esto permite explícitamente a las personas que llaman locales usar sus objetivos marcados. El valor predeterminado es falso; `off` borra el consentimiento. La autenticación de loopback no lee las claves API.
+- **Llamadas en red o vinculadas:** la entrada `apiKeys[]` configurada por el llamante debe tener `"allowMeteredComboTargets": true`. Un proxy con un oyente que no es loopback ignora la bandera combinada, incluso en su oyente de loopback secundario. Las personas que llaman vinculadas también retienen su requisito de consentimiento de clave configurada cuando el oyente principal es loopback. El token de entorno nunca califica.
+
+Los encabezados de solicitud no pueden otorgar consentimiento. Los alcances de modelo/proveedor todavía se aplican. Esto cubre la selección inicial, la conmutación por error y la recuperación a través de estrategias combinadas, compactación, Messages, Chat Completions y WebSocket, y un modelo de subagente alternativo que nombra un alias combinado. Una reserva colapsada intenta un objetivo no medido utilizable antes de rechazarlo. Los objetivos no marcados conservan el comportamiento existente; el operador declara la medición en lugar de detectarla automáticamente.
+
+Por ejemplo, una cadena de fallback puede probar Anthropic OAuth, después Cursor y finalmente `{ "provider": "anthropic-apikey", "model": "claude-opus-5-5", "metered": true }`. Sin consentimiento, al agotar los destinos se devuelve el último error de un objetivo no medido, con las excepciones de [desbordamiento de contexto confirmado](#context-window-refusals) y de cuota: un rechazo anterior 429 o 402 tiene prioridad sobre un 400, 401 o 403 posterior. Si la suscripción devuelve 429 y Cursor luego rechaza con 401 o 403, se devuelve el 429 porque explica el agotamiento de la suscripción. Los guardados del dashboard conservan la medición de objetivos y el consentimiento del combo cuando se omiten; `false` explícito los elimina. Estos ajustes se configuran en el archivo o la API; la bandera del combo también está disponible en la CLI, pero el dashboard no la expone.
+
+<a id="60-second-quickstart"></a>
+
+## 60 segundos de inicio rápido
+
+Este ejemplo crea `combo/main` con Anthropic primero y OpenAI segundo. Ambos proveedores ya deben existir y estar habilitados.
+
+```bash
+ocx combo set main --targets anthropic/claude-opus-4-8,openai/gpt-5.6-sol
+```
+
+La estrategia predeterminada es la conmutación por error, por lo que una solicitud normal va a `anthropic/claude-opus-4-8`. Si ese intento tiene un fallo reintentable, opencodex puede saltar a `openai/gpt-5.6-sol`.
+
+Utilice el modelo virtual en cualquier lugar donde normalmente proporcione un ID de modelo:
+
+```json
+{
+  "model": "combo/main",
+  "input": "Explain why the sky looks blue."
+}
+```
+
+Confirme la definición guardada:
+
+```bash
+ocx combo show main
+```
+
+:::tip
+Comience con conmutación por error y pesos iguales. Cambie a round-robin solo cuando desee intencionalmente distribuir tráfico y añadir ponderaciones solo cuando no sea apropiada una distribución igual.
+:::
+
+<a id="how-combo-names-work"></a>
+
+## Cómo funcionan los nombres combinados
+
+La identificación combinada en `ocx combo set <id>` debe comenzar con una letra o número. Puede contener letras, números, `.`, `_` o `-`, hasta 64 caracteres en total. Su modelo canónico id es siempre `combo/<id>`; por ejemplo, id `main` se convierte en `combo/main`.
+
+El espacio de nombres `combo/` está reservado mientras se configuran los combos. Un proveedor llamado `combo` no puede ocuparlo, y un identificador combinado no puede duplicar un nombre de proveedor configurado.
+
+Un alias opcional le da al combo un nombre de modelo público diferente. Un alias:
+
+- utiliza los mismos caracteres que un id;
+- puede estar desnudo, como `daily-fast`, o contener un `/`, como `team/daily-fast`;
+- no puede ser `combo` o empezar con `combo/`;
+- no puede duplicar otro alias combinado; y
+- Normalmente no puede ser un nombre de familia OpenAI nativo desnudo que comienza con `gpt-`, `o1-`, `o3-`, `o4-` o `codex-`. El modo de compatibilidad de escritorio explícito a continuación es la única excepción.
+
+Incluso cuando se establece un alias, el formulario canónico `combo/<id>` todavía se resuelve. La búsqueda canónica se ejecuta antes de la coincidencia de alias, por lo que un alias no puede hacerse cargo del id canónico de otro combo.
+
+:::note
+Los alias cambian la solicitud de nombre público de los clientes; no cambian el id almacenado del combo ni el proveedor de concreto/selectores de modelos detrás de él.
+:::
+
+<a id="compaction-after-switching-combos"></a>
+
+## Compactación después de cambiar los combos
+
+Cuando un cliente compacta usando un nombre de modelo desnudo después de cambiar combos, opencodex puede recordar el combo que se completó con éxito más recientemente en ese carril de conversación. El modelo debe coincidir con la respuesta completada, y el combo y su objetivo aún deben existir en la configuración actual. La solicitud sigue entonces la selección combo normal y la conmutación por error.
+
+Los selectores explícitos de proveedor/combo y los alias combinados configurados tienen prioridad sobre esta recuperación. Las respuestas fallidas, incompletas o canceladas no reemplazan la última selección exitosa. El retiro es proceso-local y limitado a 256 conversaciones durante 30 minutos, y a 1 KiB por nombre de modelo recordado y 64 KiB en total; las entradas caducadas también se limpian en segundo plano. Una respuesta cuyo nombre de modelo es demasiado grande para retener deja intacta la selección anterior en lugar de borrarla. Recall no almacena credenciales de cuenta. Sin identidad de conversación utilizable o estado válido recordado, se aplica el enrutamiento de compactación normal. Un reinicio despeja el estado recordado.
+
+<a id="codex-desktop-native-allowlist-compatibility"></a>
+
+## Codex Compatibilidad con la lista de permisos nativa del escritorio
+
+Algunas versiones de escritorio Codex aplican una lista de permisos remota nativa `available_models` después de que el servidor de aplicaciones ya haya cargado `model_catalog_json`. Los identificadores encaminados normales tales como `Nova1/codex-gpt-5.6-sol` son entonces utilizables por el CLI pero ausentes del selector de escritorio. Este es el [Codex Error de escritorio](https://github.com/openai/codex/issues/19694) aguas arriba rastreado por [opencodex #241](https://github.com/lidge-jun/opencodex/issues/241).
+
+Cuando controlas un destino enrutado equivalente, un combo puede hacerse cargo explícitamente de una identificador nativa:
+
+```bash
+ocx combo set nova-sol \
+  --targets Nova1/codex/gpt-5.6-sol \
+  --alias gpt-5.6-sol \
+  --native-alias \
+  --display-name 'Nova1 - codex-gpt-5.6-sol'
+```
+
+Este modo es deliberadamente opt-in y requiere tanto `--native-alias` como una etiqueta de visualización no vacía. El alias debe ser uno de los identificadores de modelo nativos soportados por esta versión opencodex; no se acepta un prefijo de familia nativa solo porque la eliminación debe ser capaz de restaurar metadatos autorizados. Cuando la respuesta de descubrimiento del destino enrutado suministra solo un id de modelo, la fila de compatibilidad rellena los metadatos de contexto, modalidad y razonamiento faltantes del id nativo que reemplaza. Los límites explícitos de objetivos aún ganan, por lo que esta alternativa nunca plantea un límite de contexto o anula las capacidades declaradas. Cambia la precedencia exacta de enrutamiento: las solicitudes para `gpt-5.6-sol` se resuelven a `combo/nova-sol` antes de la ruta canónica de la familia nativa OpenAI. El catálogo contiene una fila desnuda con la etiqueta de visualización configurada, no filas nativas y combinadas duplicadas. Sólo la identificador `gpt-5.6-sol` desnuda es capturada. Las filas calificadas por cuenta, como `main/gpt-5.6-sol`, y las filas calificadas por proveedor, como `openai-apikey/gpt-5.6-sol`, siguen siendo rutas OpenAI distintas; la ruta API calificada por proveedor nunca llega al alias nativo.
+
+Las claves de visibilidad permanecen inequívocas:
+
+- `combo/nova-sol` oculta el combo de compatibilidad del descubrimiento.
+- La entrada desnuda `gpt-5.6-sol` en `disabledModels` continúa significando la fila nativa latente OpenAI; no oculta el combo que actualmente posee esa identificador pública.
+- Mientras se configura al menos un alias nativo, las filas desnudas nativas deshabilitadas se omiten del catálogo efectivo Codex en lugar de conservarse como `visibility: "hide"`. Esto evita que la lista de permisos de Desktop resucite filas que no debería mostrar. La página Modelos todavía enumera los switches nativos no sombreados, y al volver a habilitar uno se restauran sus metadatos nativos conservados o actuales.
+
+:::caution
+Un alias nativo se hace cargo intencionalmente de un ID de modelo de primera persona. Utilizarlo solo cuando el objetivo es operacionalmente equivalente y etiqueta la fila del selector honestamente. Eliminar el combo restaura la normalidad enrutado nativo e identidad de catálogo en la siguiente sincronización.
+:::
+
+<a id="choose-a-strategy"></a>
+
+## Elige una estrategia
+
+<a id="failover-ordered-primary-and-backups"></a>
+
+### Conmutación por error: copias de seguridad y primarias ordenadas
+
+En solicitudes Responses que requieren una herramienta, los destinos Meta Responses se omiten antes del envío porque Meta no admite `tool_choice` obligatorio. El siguiente destino compatible recibe la selección original, sujeto a las reglas de compatibilidad de su adaptador. Esto incluye las selecciones alojadas `web_search`, `tool_search`, `computer_use` e `image_gen`, y las selecciones MCP con un `server_label` no vacío y un nombre omitido, null o no vacío, también dentro de listas de herramientas permitidas obligatorias. La traducción a Chat conserva un `tool_search` forzado como selección de función sintética. Si todos los destinos son incompatibles por ese motivo, el combo informa de la restricción. También se omiten antes del envío los destinos Chat que no pueden conservar un selector obligatorio, incluidos los modelos configurados para selección automática únicamente. En los modelos virtuales de OpenAI API registrados, la decisión usa el adaptador y la política de herramientas del modelo realmente enviado. Las selecciones mal formadas o desconocidas conservan la ruta normal de error del proveedor.
+
+`failover` selecciona el primer objetivo elegible en orden de configuración. Un objetivo es elegible cuando su proveedor existe, está habilitado, no se está enfriando y puede manejar cualquier restricción de solicitud especial. Los pesos y `stickyLimit` no afectan esta estrategia.
+
+Dada esta orden:
+
+1. `anthropic/claude-opus-4-8`
+2. `openai/gpt-5.6-sol`
+3. `google/gemini-3-pro`
+
+cada solicitud comienza con Anthropic. Un fallo Anthropic reintentable mueve esa solicitud a OpenAI; un fallo OpenAI reintentable puede moverla a Google. Un error de terminal se detiene inmediatamente en lugar de intentar los objetivos restantes.
+
+<a id="round-robin-smooth-weighted-batches"></a>
+
+### Round-robin: lotes ponderados lisos
+
+`round-robin` utiliza un round-robin suave y ponderado. Un peso objetivo más grande le da a ese objetivo una mayor participación a lo largo del tiempo sin enviar toda su participación como un bloque largo. `stickyLimit` controla cuántas solicitudes exitosas permanecen en el objetivo seleccionado antes de la siguiente selección ponderada.
+
+Crear un combo 2:1 con lotes de dos solicitudes exitosas:
+
+```bash
+ocx combo set balanced \
+  --targets anthropic/claude-opus-4-8:2,openai/gpt-5.6-sol:1 \
+  --strategy round-robin \
+  --sticky 2
+```
+
+Llamando a los objetivos **A** (peso 2) y **B** (peso 1), las primeras seis selecciones ponderadas son `A, B, A, A, B, A`. Debido a que `stickyLimit` es 2, cada selección permanece activa para dos solicitudes exitosas:
+
+| Solicitud exitosa | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| Objetivo | A | A | B | B | A | A | A | A | B | B | A | A |
+
+La cuota a largo plazo sigue siendo 2:1. Un fallo reintentable finaliza el lote pegajoso actual, enfría ese destino y selecciona otro destino elegible para la misma solicitud.
+
+:::caution
+Los pesos son relativos, no porcentajes. Pesos `2,1` y `200,100` expresa la misma proporción. Prefiero Pequeños valores que comunican la intención.
+:::
+
+<a id="random-weighted-draw-per-request"></a>
+
+### Aleatorio: sorteo ponderado por solicitud
+
+`random` dibuja un objetivo elegible por solicitud, con probabilidades proporcionales a `weight`. Cada solicitud es un empate independiente, por lo que el tráfico se propaga a través de los objetivos sin el patrón determinista o la pegajosidad de round-robin. `stickyLimit` no afecta a esta estrategia.
+
+<a id="least-used-favor-the-target-with-fewest-successes"></a>
+
+### Menos utilizado: favorezca al objetivo con menos éxitos
+
+`least-used` enruta cada solicitud al objetivo elegible con la menor cantidad de solicitudes exitosas registradas por este proceso opencodex. Cuentas comienzan a cero en el reinicio, y los empates mantienen el orden de configuración. Los pesos y `stickyLimit` no afectan esta estrategia.
+
+<a id="reset-window-follow-the-soonest-quota-reset"></a>
+
+### Reset-window: siga el restablecimiento de cuota más rápido
+
+`reset-window` enruta cada solicitud al destino elegible cuya instantánea de cuota de proveedor en caché muestra el próximo restablecimiento de ventana más rápido (cinco horas, semanal, mensual o personalizado). Esto pasa el proveedor que actualiza primero. Los objetivos sin datos de cuota recientes, así como los empates, mantienen el orden de configuración. Los pesos y `stickyLimit` no afectan esta estrategia.
+
+Esta clasificación y exclusión del proveedor antes del envío requieren nuevos límites de inferencia de modelo que se aplican a la clave API actual en su conjunto. OAuth /los resúmenes de cuentas actuales, las rutas de reenvío de llamadas, las claves múltiples y las instantáneas con credenciales o destinos modificados se muestran solo para esta decisión temprana. Lo mismo se aplica cuando las cabeceras `Authorization`, `x-api-key` o `x-goog-api-key` anulan las credenciales; se excluyen las ventanas de solo búsqueda y MCP. Si ningún objetivo elegible tiene un restablecimiento aplicable, el orden de configuración gana. La selección y los reintentos de la cuenta aún imponen sus límites normales.
+
+<a id="advisory-quota-signals-for-jev"></a>
+
+### Señales de cuota de asesoramiento para JEV
+
+La evidencia de cuotas es por separado opt-in **por JEV Combo**, para los tres métodos de decisión:
+
+```bash
+ocx combo set coding --decision-quota-signals on --json
+ocx combo set coding --decision-quota-tiers '{"moderate":40}' --json
+```
+
+Solo habilite esto en un Combo `strategy: "jev"` existente. `decisionQuotaSignals: true` agrega niveles de cuota de suscripción a la solicitud de decisión, no una regla de elegibilidad dura. Se le pide al backend de decisión que prefiera una cuota más saludable entre las opciones adecuadas; todavía elige solo entre los objetivos elegibles configurados y las listas de permisos de esfuerzo. Desconocido no se agota, y las opciones alternativas ordinarias, el tiempo de reutilización, la selección de cuentas y los límites del proveedor permanecen sin cambios.
+
+Los valores predeterminados son `limited: 70` y `nearlyExhausted: 90`, porcentajes incluidos utilizados. No hay un nivel moderado a menos que lo establezca explícitamente (por ejemplo, `moderate: 40`). Las anulaciones parciales se fusionan con esos valores predeterminados, entonces todos los umbrales deben ser finitos, dentro de 0-100 y estrictamente ascendentes.
+
+La evidencia solo proviene de instantáneas de memoria publicadas por recopiladores de cuotas existentes, encabezados de respuestas aceptadas y propietarios de credenciales/cuentas, y solo mientras al menos un JEV Combo tiene este interruptor activado: hasta entonces, opencodex no recopila nada para él, por lo que la evidencia comienza a acumularse (y se lee como desconocida) desde el momento en que lo habilita. La lectura de la evidencia de la cuota de asesoramiento nunca resuelve las credenciales, carga los almacenes de autenticación o los archivos de cuota, lee un llavero, sondea aguas arriba o inicia un repaso. La resolución normal de las credenciales de backend de decisión no cambia. Se desconocen las pruebas frías, desaparecidas, rancias (más de 30 minutos), futuras, inválidas o que hayan expirado. Cada cuenta utiliza su peor ventana válida relevante de cinco horas, semanal, mensual o estructuralmente. Un grupo de Anthropic / Codex habilitado usa su nivel de cuenta más saludable; el estado desconocido empata con el saludable. Un grupo está casi agotado solo si cada cuenta utilizable ha conocido evidencia casi agotada. Los modelos de reserva sin barras atribuibles por separado siguen siendo desconocidos. Los resúmenes de cuentas activas, los informes de visualización de múltiples claves, los créditos y los medidores API /Spark / USD no son evidencia de cuotas para esta decisión. La cuenta separada Anthropic + Pool 2 (`anthropic2`) no es una fuente de esta evidencia, por lo que sus objetivos permanecen desconocidos.
+
+Antigravity aporta las ventanas Gem/Cla de cinco horas y semanales solo después de una consulta autenticada reciente para su única cuenta OAuth activa y utilizable, y únicamente al proveedor `google-antigravity` que inicia sesión con esa cuenta. Si se cambia el nombre del proveedor, su cuota se considera desconocida y no se reutiliza la de esa cuenta. La cuota corresponde al modelo nativo resuelto `gemini-*` o `claude-*`, no a su alias visible. Cambiar la cuenta, la credencial, el proyecto o el destino retira la observación anterior. Una actualización solo de visualización puede conservar los contadores de familia coincidentes, con sus marcas de tiempo originales. Las filas por modelo y las de Argon nunca se convierten en evidencia para la decisión.
+
+:::caution[Datos adicionales para la decisión]
+Al activar esta opción, se envían los niveles de cuota y, cuando están disponibles, el porcentaje de uso, la ventana y el tiempo restante hasta su restablecimiento al backend de decisión seleccionado, incluido TypeSafe alojado. Esta función no envía ni registra identificadores de cuenta, tokens ni huellas de credenciales. Los registros locales de decisiones conservan únicamente recuentos acotados de los niveles de cuota y el nivel seleccionado. Si los datos de cuota hacen que la solicitud supere el límite de 64 KiB, se eliminan esos datos antes de volver a serializarla. Si la solicitud de decisión ordinaria sigue siendo demasiado grande, se continúa con el fallback habitual.
+:::
+
+`--decision-quota-signals off` deshabilita la evidencia mientras conserva los niveles configurados; `-` despeja el interruptor. `--decision-quota-tiers -` borra anulaciones, restaurando valores predeterminados. API `null` borra; API `false` desactiva el interruptor. Los campos omitidos sobreviven a las actualizaciones de JEV, el reemplazo de objetivos y el cambio de nombre, incluidas las salvaciones a través del editor existente. Al cambiar de JEV se eliminan ambos ajustes de cuota. No se habilitan nuevos controles de editor ni el trabajo de cuota de fondo.
+
+<a id="session-pin-for-jev"></a>
+
+### Fijación de sesión para JEV
+
+Un combo JEV decide el destino de cada solicitud; los turnos de una conversación pueden cambiar de proveedor y empezar con su caché de instrucciones vacía. `sessionPin` es una opción por combo JEV, **desactivada por defecto**, que mantiene la sesión en el destino elegido mientras siga activa:
+
+En el dashboard, abre **Decision method** en el editor del combo JEV y activa **Keep a session on its decided target**. Configura **Idle window (ms)** y guarda. El intervalo válido es 60000–86400000 ms (un minuto–24 horas); al activar una fijación nueva, empieza en 60000 ms. Para desactivarla, desmarca la casilla y guarda. Un intervalo vacío o inválido impide guardar mientras la opción esté activa. Si falla el guardado, se conservan las ediciones para reintentarlo. Las respuestas antiguas que omiten este ajuste lo mantienen omitido hasta que lo cambies.
+
+```bash
+ocx combo set jev-auto --session-pin 20m --json
+```
+
+```json
+{ "strategy": "jev", "sessionPin": { "ttlMs": 1200000 } }
+```
+
+La primera solicitud se decide normalmente. Cuando el destino aplicado por JEV completa una respuesta, las solicitudes siguientes de la sesión reutilizan ese destino y esfuerzo sin otra llamada de decisión. `ttlMs`, entre un minuto y 24 horas, es un plazo de inactividad: cada turno completado en el destino fijado, incluidas las continuaciones de herramientas, lo reinicia. Si la sesión permanece inactiva más tiempo, se decide de nuevo.
+
+La identidad combina el encabezado de sesión del cliente (`thread-id`, `session_id` o `session-id`, `x-codex-parent-thread-id`, o un `x-session-id` promovido), la clave API que admitió la solicitud y el combo. No se fijan solicitudes sin encabezado de sesión, `prompt_cache_key` nunca sirve como identidad de sesión y dos claves API nunca comparten una fijación.
+
+JEV decide de nuevo y sustituye la fijación cuando:
+
+- El destino no se ofrece para esa solicitud porque está desactivado, se retiró del combo, está en enfriamiento tras un 429 u otro fallo, agotó su cuota en caché, es de pago medido o resulta inelegible por otro motivo.
+- El esfuerzo fijado ya no se ofrece para ese destino.
+- `decisionQuotaSignals` está activo y la evidencia de cuota indica que el destino está casi agotado.
+- Falla cualquier envío de la sesión fijada; esa solicitud conserva la recuperación habitual mediante otros destinos.
+- La configuración cambió después de guardar la fijación.
+
+Cancelar una solicitud conserva la fijación. Una decisión que usa la alternativa fail-open por tiempo agotado, clave ausente o respuesta inválida no crea una. Las fijaciones viven en memoria, con un máximo de 512 sesiones, y se pierden al reiniciar.
+
+Los registros de uso marcan los turnos reutilizados con `jevDecision.pinned: true` y `pinReason: "session"`. Una decisión que sustituye una fijación liberada registra el motivo en `pinReason`: `expired`, `config_changed`, `target_unavailable`, `effort_unavailable` o `quota_nearly_exhausted`. `ocx combo stats` cuenta las solicitudes fijadas aparte de las decisiones; siguen contando para solicitudes correctas, cambios de modelo por fallo y tokens por modelo.
+
+La fijación permite reutilizar la caché, pero el acierto real depende del proveedor, la cuenta y un prefijo de instrucciones estable. `--session-pin -`, o `null` en la API, la desactiva. Cambiar a otra estrategia la elimina; guardar desde el editor del dashboard la conserva.
+
+<a id="decision-method"></a>
+
+### Método de decisión
+
+`strategy: "jev"` solicita una decisión de fondo para elegir el primer objetivo elegible y un esfuerzo de razonamiento compatible para la solicitud actual. Es opt-in: crea un JEV Combo y selecciona ese Combo para usarlo. Agregar una credencial de decisión no cambia los modelos, alias o valores predeterminados existentes.
+
+| Método | Selección combinada | Backend reportado en estadísticas |
+| --- | --- | --- |
+| TypeSafe (predeterminado) | Omita ambos selectores, o configure `decisionProvider: "jev"`. | `typesafe` |
+| Servidor compatible con System One | Establecer `decisionProvider` en un identificador de fila configurado `jev-decision` distinto de `jev`. | `systemone` |
+| Modelo opencodex | Establecer `decisionModel` a una ruta ordinaria opencodex, como `ollama/qwen3:4b`. | `model` |
+
+`decisionProvider` y `decisionModel` son mutuamente excluyentes. El backend se deriva de esos campos; no hay ninguna configuración `backend` almacenada. Cada método utiliza el mismo objetivo elegible y la lista de permisos de esfuerzo, el estado de decisión limitado, el tiempo de espera, la cancelación y la política de apertura por error.
+
+<a id="typesafe-default"></a>
+
+#### TypeSafe por defecto
+
+La configuración más rápida es:
+
+1. Abra **Proveedores**, agregue **TypeSafe JEV**, ingrese la clave TypeSafe API y pruebe la conexión.
+2. En la vista general de ese proveedor, elija **Crear JEV Auto**. También puede usar la misma acción en **Modelos → Combos**.
+3. Revise los objetivos Astra → Sol → Luna precargados. Agregue, elimine, reordene o reemplace antes de crear el Combo. La primera fila actualmente elegible está marcada como el objetivo de apertura a prueba de fallos, y cada escalera de razonamiento conocida se muestra al lado de su fila.
+
+La plantilla crea id y alias `jev-auto`, utiliza la capacidad de razonamiento adaptativo, y sigue siendo un combo editable ordinario. No se convierte en el modelo por defecto. Sus objetivos son la lista de permisos completa: JEV nunca puede seleccionar un par proveedor/modelo fuera de esa lista, y los modelos de destino originales permanecen disponibles en sus grupos de selectores normales.
+
+Para la configuración sin cabeza, almacene la clave explícitamente o haga referencia a la variable de entorno TypeSafe:
+
+```bash
+ocx provider add jev --api-key '${TYPESAFE_API_KEY}'
+```
+
+Conserva las comillas simples para pasar la referencia en lugar del secreto. Configura `TYPESAFE_API_KEY` en el entorno de inicio del proxy y reinícialo si ya está en ejecución; un servicio en segundo plano necesita su propio entorno configurado.
+
+Cuando el proveedor no tiene ninguna clave guardada, el cliente de decisión también acepta `TYPESAFE_API_KEY` directamente y el alias estándar derivado del proveedor `JEV_API_KEY` impreso por `ocx provider add`.
+
+```json
+{
+  "providers": {
+    "jev": {
+      "adapter": "jev-decision",
+      "baseUrl": "https://api.typesafe.ai/v1/systemone",
+      "authMode": "key",
+      "apiKey": "${TYPESAFE_API_KEY}",
+      "liveModels": false
+    }
+  },
+  "combos": {
+    "jev-auto": {
+      "alias": "jev-auto",
+      "strategy": "jev",
+      "reasoningEffortMode": "adaptive",
+      "targets": [
+        { "provider": "openai", "model": "gpt-6-astra" },
+        { "provider": "openai", "model": "gpt-5.6-sol" },
+        { "provider": "openai", "model": "gpt-5.6-luna" }
+      ]
+    }
+  }
+}
+```
+
+Con el método predeterminado, OpenCodex envía una solicitud de decisión limitada al punto final fijo `https://api.typesafe.ai/v1/systemone` con el modelo `jev-latest`. Solo se ofrecen objetivos configurados elegibles actualmente. JEV elige el objetivo y el esfuerzo juntos; el esfuerzo todavía está limitado por la escalera anunciada de ese objetivo. No se pregunta de nuevo al JEV si el objetivo seleccionado tiene un fallo reintentable: el tiempo de reutilización y el bucle de recuperación de Combo existentes continúan a través de los objetivos configurados restantes.
+
+<a id="system-one-compatible-server"></a>
+
+#### Servidor compatible con System One
+
+Un JEV Combo puede solicitar un servidor alojado o autoalojado que implemente el contrato de cable de System One. Por ejemplo, un servidor Ollama con soporte System One puede servir `tev1` a `POST /v1/systemone` sin una clave API. Agregue una fila de proveedor con `adapter: "jev-decision"` cuyo `baseUrl` es el punto final de decisión **lleno**, luego nómbrelo en `decisionProvider` del Combo:
+
+```json
+{
+  "providers": {
+    "ollama-tev1": {
+      "adapter": "jev-decision",
+      "baseUrl": "http://127.0.0.1:11434/v1/systemone",
+      "allowPrivateNetwork": true,
+      "defaultModel": "tev1:4b",
+      "liveModels": false
+    }
+  },
+  "combos": {
+    "jev-local": {
+      "strategy": "jev",
+      "decisionProvider": "ollama-tev1",
+      "decisionTimeoutMs": 60000,
+      "reasoningEffortMode": "adaptive",
+      "targets": [
+        { "provider": "openai", "model": "gpt-6-astra" },
+        { "provider": "openai", "model": "gpt-5.6-sol" },
+        { "provider": "openai", "model": "gpt-5.6-luna" }
+      ]
+    }
+  }
+}
+```
+
+- El `baseUrl` de la fila debe ser la URL completa del servicio de decisión. HTTPS permite cualquier ruta, como `/v1/decisions`; HTTP sin cifrar sigue exigiendo el sufijo `/systemone`. No se aceptan credenciales de usuario en la URL, parámetros de consulta ni fragmentos. El modelo de decisión es `defaultModel` o, en su ausencia, la primera entrada de `models`. Si no hay ninguno, la fila no es utilizable y se aplica la alternativa fail-open sin enviar una solicitud (`jev-latest` es el modelo de TypeSafe y nunca se envía a un host autoalojado). La fila solo presta el servicio de decisión: nunca se publica como modelo enrutable ni puede ser un destino del combo.
+- Un punto final de loopback o LAN necesita `allowPrivateNetwork: true` explícito en esa fila. Para `http:` sin cifrar, usa una dirección literal de loopback, RFC 1918 o IPv6 ULA; todas las direcciones resueltas deben pertenecer al conjunto permitido y no debe aplicarse ningún proxy saliente (añadel host a `NO_PROXY`). Los demás destinos deben usar HTTPS. Una redirección activa la alternativa fail-open al primer destino elegible.
+- Solo se envía el propio `apiKey` de la fila, y solo cuando está establecido; una fila sin llave no envía la cabecera `Authorization`. Una fila cuyas referencias `apiKey` `${TYPESAFE_API_KEY}` / `${JEV_API_KEY}` u otra entrada de llavero del proveedor se rechazan como inutilizables, por lo que `TYPESAFE_API_KEY`, `JEV_API_KEY` y la clave de la fila `jev` nunca se envían a un punto final autoalojado. El identificador `jev` en sí (explícito u omitido) siempre significa el punto final TypeSafe con el modelo `jev-latest`.
+- Los servicios autoalojados reciben cada opción de destino/esfuerzo como una cadena de descripción simple (por ejemplo, `Target openai/gpt-5.6-sol (provider openai, model gpt-5.6-sol) with low reasoning
+  effort.`), porque Ollama solo acepta descripciones de cadena o de opciones `null`. TypeSafe sigue recibiendo objetos de opción estructurados. Para Vercel AI Gateway (`ai-gateway.vercel.sh`), las opciones de ruta incluyen `value` y una `description` detallada. Los demás endpoints autoalojados, incluidas las rutas personalizadas `/decisions`, conservan el formato de solicitud de System One.
+- OpenCodex ofrece entre 2 y 26 opciones a una fila compatible con System One (`SELF_HOSTED_MIN_OPTIONS = 2`, `SELF_HOSTED_MAX_OPTIONS = 26`). Cada destino aporta una opción por nivel de esfuerzo; usa `reasoningEfforts` para limitar la lista. Fuera de esos límites, se usa el primer destino elegible sin enviar una decisión. Para Vercel AI Gateway, cuya [referencia Decisions compatible con OpenAI](https://vercel.com/docs/ai-gateway/sdks-and-apis/openai-decisions) admite de 1 a 255 opciones, el máximo aumenta a 255 (`DECISIONS_MAX_OPTIONS = 255`); OpenCodex conserva el mínimo local de dos opciones para elegir entre destinos.
+- Los endpoints de Vercel AI Gateway (`https://ai-gateway.vercel.sh/v1`) se normalizan automáticamente a `/decisions`. OpenCodex convierte el contexto estructurado en una cadena `input` con las secciones `Task:`, `Signals:`, `Recent Assistant:`, `Recent Tool Call:` y `Tool Output:`. Acepta respuestas de ruta como objeto (`answers.route`) o lista de opciones, resolviendo `choice` o `value`. Las distribuciones de probabilidades pueden ser mapas clave-valor o registros de probabilidad. Las claves duplicadas y las distribuciones inválidas activan la alternativa al primer destino elegible.
+- Cargar un modelo en frío puede tardar decenas de segundos, y cancelar una solicitud de decisión hace que Ollama abandone la carga. Precarga el modelo, mantenlo residente (`OLLAMA_KEEP_ALIVE=-1` o `keep_alive`) y aumenta `decisionTimeoutMs` (1000-120000 ms, por defecto 4000) si el servicio tarda más de cuatro segundos. Cualquier error o tiempo de espera agotado sigue activando la alternativa al primer destino elegible.
+
+El **Conexión de prueba** del proveedor envía una decisión de sondeo limitada a su punto final. **Crear JEV Auto** en un proveedor de System One (incluidas las filas sin llave) rellena previamente esa fila como proveedor de decisiones. Las filas deshabilitadas, las URL de decisión no válidas y las filas sin modelo se muestran con una razón y no se pueden seleccionar.
+
+Para un servicio alojado alternativo con el mismo contrato de solicitud/respuesta de decisión, agregue una fila de proveedores separada y selecciónela con el `decisionProvider` del Combo:
+
+```json
+{
+  "providers": {
+    "alternative-decider": {
+      "adapter": "jev-decision",
+      "baseUrl": "https://decisions.example/v1/decisions",
+      "apiKey": "${ALTERNATIVE_DECISION_KEY}",
+      "defaultModel": "decision-model-v1",
+      "liveModels": false
+    }
+  }
+}
+```
+
+Establecer `decisionProvider: "alternative-decider"` en el JEV Combo existente. Su propia credencial y modelo acompañan el estado de decisión limitado; Las credenciales de entorno TypeSafe nunca se heredan. El id `jev` sigue siendo canónico. HTTPS / TLS, restricciones de destino de salida, rechazo de redirección, límites de solicitud / respuesta, tiempo de espera, cancelación y la lista de permisos de elección elegible aún se aplican.
+
+[Laya MLX](https://github.com/mizorewww/laya-mlx) ejecuta decisiones escritas en Apple Silicon. Para usarlo con este método, expóngalo a través de un envoltorio compatible con System One HTTP, luego configure una fila como `ollama-tev1` anterior con el URL completo de `/systemone` del envoltorio y el identificador de modelo aceptado como `defaultModel`. El entorno de ejecución de Python MLX solo no es un punto final de decisión HTTP. Para una envoltura loopback HTTP, mantenga `allowPrivateNetwork: true` y utilice su dirección loopback literal.
+
+Para un ejemplo alojado, un colaborador informó que el siguiente punto final de Zen System One funcionaba en [#6185](https://github.com/lidge-jun/opencodex/pull/6185). Configure manualmente como una fila ordinaria; esto no es un preajuste del registro OpenCodex o una garantía de disponibilidad actual:
+
+```json
+{
+  "providers": {
+    "zen-decision": {
+      "adapter": "jev-decision",
+      "baseUrl": "https://opencode.ai/zen/v1/systemone",
+      "defaultModel": "jev-1.13-free",
+      "apiKey": "${ZEN_DECISION_API_KEY}",
+      "liveModels": false
+    }
+  },
+  "combos": {
+    "jev-zen": {
+      "strategy": "jev",
+      "decisionProvider": "zen-decision",
+      "targets": [
+        { "provider": "openai", "model": "gpt-6-astra" },
+        { "provider": "openai", "model": "gpt-5.6-luna" }
+      ]
+    }
+  }
+}
+```
+
+Utilice la propia clave de ese punto final si se requiere autenticación; omita `apiKey` solo si el punto final acepta llamadas sin clave. Nunca reutilice `TYPESAFE_API_KEY` o `JEV_API_KEY` para ello.
+
+<a id="opencodex-model"></a>
+
+#### Modelo opencodex
+
+Un chat ordinario o modelo Responses puede hacer la misma elección de enrutamiento sin implementar `/systemone`. Configure su proveedor de inferencias como de costumbre y configure `decisionModel` en su ruta:
+
+```json
+{
+  "combos": {
+    "jev-chat": {
+      "strategy": "jev",
+      "decisionModel": "ollama/qwen3:4b",
+      "decisionTimeoutMs": 60000,
+      "targets": [
+        { "provider": "openai", "model": "gpt-6-astra" },
+        { "provider": "openai", "model": "gpt-5.6-luna" }
+      ]
+    }
+  }
+}
+```
+
+Otros ejemplos son `deepseek/deepseek-v4-flash`, `openai/gpt-5.6-luna` o `opencode-zen/<model>` para un modelo de inferencia Zen configurado. Estas son cadenas de ruta ordinarias, no preajustes de servicio de decisión; el proveedor y el modelo deben estar disponibles en la instalación. Para `openai/gpt-5.6-luna`, configure las credenciales que puede usar la llamada interna, como un inicio de sesión de grupo Codex almacenado. Un inicio de sesión hacia adelante ChatGPT propiedad de la persona que llama es insuficiente.
+
+El modelo recibe instrucciones fijas del router y un mensaje JSON:
+
+```json
+{
+  "state": { "user_task": "Review the requested change" },
+  "options": { "<key>": "Target description and allowed reasoning effort" }
+}
+```
+
+`state` contiene la evidencia limitada que se describe a continuación; `options` asocia las claves generadas de las opciones con descripciones simples. La respuesta debe cumplir `{"choice":"<key>"}` y nombrar exactamente una opción ofrecida. Las instrucciones tratan el estado como evidencia, prefieren un menor uso de recursos entre las opciones adecuadas y exigen únicamente JSON. Una opción no válida o no ofrecida, una respuesta malformada o una llamada fallida activa la alternativa fail-open al primer destino elegible.
+
+El turno interno de decisión **no recibe credenciales del cliente**, encabezados de la llamada, herramientas, historial de sesión ni conversación. Debe usar las credenciales almacenadas del proveedor seleccionado o un proveedor local que realmente no necesite clave, como Ollama. Las configuraciones que dependen exclusivamente de la autenticación del cliente, como Cursor sin una credencial almacenada o un inicio de sesión de ChatGPT reenviado por el cliente, no pueden actuar como modelos de decisión: se usa la alternativa fail-open al primer destino elegible. Seleccionar una ruta no demuestra que su credencial funcione; pruébala antes de depender de ella.
+
+Un Combo no-JEV puede ser usado como `decisionModel`, pero la ruta de decisión no puede nombrar este Combo o cualquier Combo con `strategy: "jev"`. Esto se aplica a los selectores y alias canónicos `combo/<id>`, incluidos los selectores con variantes de esfuerzo o Fast. La validación de tiempo de ahorro rechaza la recursión y el entorno de ejecución también bloquea la reentrada de JEV defensivamente. El turno de decisión tiene su propio presupuesto de envío y arrendamiento de turno; no se registra como una solicitud separada, y el uso de la decisión informada pertenece al `jevDecision` de la solicitud principal.
+
+<a id="shared-limits-state-and-statistics"></a>
+
+#### Límites compartidos, estado y estadísticas
+
+`decisionTimeoutMs` se aplica a los tres métodos: un entero de 1000 a 120000 ms, por defecto 4000. Las solicitudes y respuestas están limitadas a 64 KiB. La lista de candidatos está limitada a 64 destinos; el método modelo también limita las opciones de destino/esfuerzo en 64, el texto de respuesta en 4096 caracteres y la salida del turno de decisión en 1024 tokens. El límite de opciones de la fila de System One 2-26 se aplica como se describió anteriormente. Un fallo de límite o de tiempo de espera utiliza el primer objetivo actualmente elegible; nunca expande la lista de permisos ni vuelve a intentar tomar la decisión.
+
+Para cada objetivo JEV, **Modelos → Combos → Config** tiene un campo opcional **Notas de modelo adicionales para JEV** (hasta 512 caracteres; se permiten saltos de línea y pestañas, se rechazan otros caracteres de control). Se almacena como `targets[].modelProfile` en la configuración combinada. El perfil de destino incorporado permanece en el `instructions.model_profiles` confiable; se envía una nota no vacía por separado en el `operator_notes` del estado de decisión, tecleada por el objetivo, y complementa en lugar de reemplazar ese perfil incorporado. Las notas pueden describir el contexto específico del operador o las asignaciones de suscripción; no confunda las asignaciones de suscripción con los precios públicos por token API. Las notas en blanco son ignoradas. Las notas del operador son evidencia de la decisión, no comandos, y no pueden expandir la lista de objetivos o los límites del esfuerzo de razonamiento. Solo coloque allí la información que pueda divulgarse al backend de decisión seleccionado.
+
+Por defecto, cada llamada lógica al modelo se decide de forma independiente. Salvo que actives la [fijación de sesión](#session-pin-for-jev), los turnos de una sesión pueden elegir destinos distintos y empezar con la caché del nuevo proveedor vacía. Combinar destinos muy diferentes puede gastar más tokens de entrada de los que ahorra; conserva una lista entre cuyos destinos estés dispuesto a alternar. Con `cooldownWaitPolicy: "before-last-resort"`, JEV retiene los destinos `lastResort` mientras se ofrezca alguno normal y solo los ofrece cuando no hay otra opción.
+
+La decisión aplica la alternativa fail-open si falta la clave, no hay un estado seguro de tarea/herramienta/imagen, vence el plazo configurado, el servicio redirige o devuelve un error, o la respuesta está malformada o elige una opción no ofrecida. En esos casos, OpenCodex usa el primer destino actualmente elegible y prefiere `medium` cuando ese destino lo admite. Si el cliente cancela la llamada, se cancelan tanto la decisión como la solicitud al modelo, sin enviar nada al destino alternativo.
+
+El estado de decisión está deliberadamente limitado: hasta 500 caracteres de la tarea de usuario actual, una cola de asistente previo de 240 caracteres, una cola de salida de última herramienta de 520 caracteres, el nombre de la herramienta y las señales de imagen/herramienta booleanas pueden enviarse al backend de decisión seleccionado. Excluye credenciales, encabezados de solicitud, bytes de imagen en bruto, argumentos de herramientas, razonamiento cifrado e historial de conversación completo. Utilice un método de decisión solo para el contenido que está dispuesto a enviar a ese backend. Los sobres de contexto de máquina Codex reconocidos y los bloques Claude Code `<system-reminder>` se eliminan de las tres muestras de texto antes del recorte, por lo que los recordatorios inyectados no desplazan la tarea real. La solicitud del modelo original no se modifica. Esto no es un escáner secreto: el texto ordinario del asistente y de la salida de la herramienta aún puede contener contenido sensible. TypeSafe afirma que Jev no está capacitado en las solicitudes de los clientes, pero sus términos no establecen un período de retención fijo para el estado presentado y ofrecen cero retención de datos solo en los planes empresariales ([modelos](https://docs.typesafe.ai/models), [legal](https://docs.typesafe.ai/legal) ). TypeSafe también documenta el inglés como el idioma más preciso de Jev, así que revise las decisiones sobre el trabajo que no sea inglés antes de confiar en ellos. Los registros contienen solo el objetivo/esfuerzo seleccionado, una puerta de decisión aproximada, latencia, confianza/probabilidad opcional y uso numérico. Las pruebas automatizadas utilizan respuestas TypeSafe simuladas más un humo sin llave abierta; una decisión TypeSafe en vivo requiere una clave suministrada por el operador y no se ejecuta implícitamente.
+
+El esfuerzo seleccionado de JEV se aplica al primer niño Responses y a los niños nativos de Chat en la ruta de inscripción `protocols.rollout.nativeChatCombos`. Reemplaza el esfuerzo del llamante y elimina los controles de pensamiento conflictivos y el llamante `service_tier`; una opción explícita sin esfuerzo elimina el esfuerzo incluso cuando el Combo tiene un valor predeterminado forzado. Los pines de esfuerzo del proveedor, los límites y la normalización del cable aún se aplican después. Los registros de solicitud e intento muestran un esfuerzo aplicado diferente como `high->xhigh` o `high->low`, reteniendo ajustes posteriores como `high->xhigh->medium`. Un esfuerzo sin cambios o una elección sin esfuerzo mantiene la etiqueta existente. Más tarde, los objetivos alternativos utilizan la política Combo ordinaria de la solicitud original, sin otra llamada JEV.
+
+Después de que el Combo haya servido las solicitudes, abra **Modelos → Combos → jev-auto → Estadísticas** para inspeccionar las selecciones de JEV sin reemplazar el selector de modelo normal o la página de uso. La pestaña separa los tokens de decisión informados en el backend de los tokens informados por los envíos de modelos físicos, y muestra las puertas de decisión, las selecciones abiertas, los esfuerzos de razonamiento, los reintentos / retrocesos, los tokens de caché, la latencia, la confianza y los totales por modelo durante 7 días, 30 días o todo el historial disponible. Las estadísticas provienen del libro de contabilidad de uso de solo anexar local; contienen los metadatos de decisión limitados descritos anteriormente, no las solicitudes o credenciales. Las filas de backend muestran el recuento de decisiones, el recuento aplicado y la latencia promedio para `typesafe`, `systemone` y `model`; los registros más antiguos sin backend se agrupan como `unknown`.
+
+<a id="what-happens-when-a-target-fails"></a>
+
+## Qué pasa cuando un objetivo falla
+
+Los fallos combinados se dividen en **hop** fallos y **terminal** fallos.
+
+Para que un combo devuelva un error claro `fallback_refused` en lugar de pasar a otro modelo o proveedor, consulta [Desactivar el fallback](/es/guides/fallback-off/).
+
+| Resultado | Comportamiento |
+| --- | --- |
+| HTTP 401, 403, 404, 408, 429 o cualquier 5xx | Enfría el objetivo y salta al siguiente objetivo elegible. |
+| HTTP 410 con un modelo explícito al final de su vida útil, retirado, obsoleto, puesta del sol, desmantelado o señal no disponible más tiempo | Enfriar ese objetivo y saltar. Las respuestas 410 no relacionadas siguen siendo terminales. |
+| Autenticación clasificada, suscripción, cuota, límite de velocidad, sobrecarga o error del servidor ascendente | Enfríe el objetivo y salte, incluso cuando el estado por sí solo no sea suficiente. |
+| Desbordamiento confirmado de la ventana de contexto antes de emitir salida, incluido HTTP 400 | Prueba el siguiente objetivo elegible no intentado, sin enfriar el actual: otro modelo puede tener una ventana mayor. Al agotar los destinos, devuelve el primer error HTTP 400 de longitud de contexto confirmado. Un rechazo de contexto con otro estado permite avanzar, pero no se conserva. |
+| Veredicto de moderación HTTP 400 o 422 del proveedor o gateway (código estructurado `moderation_refusal` o `content_filter`; un mensaje de moderación sin ese código sigue deteniendo el intento) | Prueba el siguiente objetivo sin enfriar el actual; el filtro de otro proveedor puede aceptar el prompt. Si el cuerpo también contiene un rechazo terminal (política cibernética o biológica, `invalid_prompt`, `content_policy_violation` o texto del sistema de seguridad), se detiene. |
+| Cancelación del cliente (499), `origin_rejected`, rechazo de ciberpolítica u otra solicitud no válida | Detiene el intento y devuelve el error; cambiar de objetivo no hace válida la solicitud. |
+| Exacta HTTP 400 diciendo que un modelo no es compatible cuando se utiliza Codex con una cuenta ChatGPT | Pruebe el siguiente objetivo declarado antes del compromiso de producción. El mensaje debe ser el rechazo completo en `detail`, `error.message`, o texto desnudo; competidor `detail` y `error` sobres estancia terminal. Esto no pone en cuarentena la cuenta ni enfría todos los modelos del proveedor. |
+| Estructurado HTTP 400 rechazando `user` opcional, un esfuerzo de razonamiento no soportado, entrada de imagen con modelo o medios de entrada que la ruta no puede leer (`unsupported_input_modality`) | Salta antes del compromiso de salida sin enfriamiento; vea la compatibilidad de destino local de solicitud a continuación. |
+| Primera llamada de herramienta de un giro Responses ejecutada por un adaptador en proceso ( `runTurn` ) que la solicitud actual no declaró, antes de cualquier efecto secundario de salida o reproducción insegura | Enfriar el objetivo y saltar con el mismo catálogo de herramientas. Después de una salida visible o un efecto secundario de repetición insegura, el rechazo es final. Chat Completions y Anthropic Messages solicitudes no han cambiado. |
+| Cualquier otro error no clasificado | Detener y devolver el error. |
+
+Si el presupuesto de envío de solicitud compartida rechaza el primer objetivo, el combo devuelve un 429 `request_send_budget_exhausted` local sin ponerse en contacto con un proveedor. Si rechaza un objetivo posterior, el combo devuelve el último error ascendente real sin enviarlo a ese objetivo.
+
+Cuando `cooldownMs` está sin definir, un objetivo saltado utiliza un fallback ascendente: 5 segundos para la tasa de solicitud 429s con código ascendente `1302` o `1305`, 10 minutos para una ventana de uso de la cuenta gastada, y 60 segundos de lo contrario. Una ventana de uso es reconocida por el código ascendente (`usage_limit_exceeded`,
+`usage_limit_reached`, `1308`) o por mensajes de agotamiento como `usage limit reached`, `token-plan ... quota has been exhausted` o `weekly usage quota exceeded`, fuera de respuestas 400 y 422 e independientemente del estado HTTP: el backend ChatGPT Codex informa del agotamiento como 502 en lugar del 429 documentado. Un 400 o 422 exige un código estructurado; un error de validación que solo cita `quota exhausted` no cambia de destino. Los códigos inferidos de esa prosa por el formateador del proxy no cuentan como evidencia estructurada del proveedor. El agotamiento explícito semanal, mensual, diario o de ventana de uso de Devin se convierte en 429 y retiene el destino diez minutos; los límites por minuto u hora y los trailers de configuración MCP `failed_precondition` permanecen como 400 y detienen el turno. El texto sin procesar de los trailers Devin se oculta. Una ventana agotada enfría solo ese destino y mantiene elegibles otras cuentas del mismo proveedor. Credenciales y fallas de facturación que ya bloquean a todo el proveedor (`invalid_api_key`, `insufficient_quota`,
+`payment_required`, y los otros códigos de alcance del proveedor) toman la misma espera de 10 minutos. Cuando se establece, `cooldownMs`
+se aplica siempre que no se pueda utilizar de origen `Retry-After` o Codex señal de restablecimiento existe, incluidos los 429s. Numérico `Retry-After` segundos y se aceptan valores de fecha HTTP. Explícito Los retrasos en el servidor se limitan a 24 horas; los tiempos de reutilización derivados, configurados y de reserva se limitan 10 minutos. La precedencia es, de más fuerte a más débil, explícita.
+`Retry-After` → Codex reseteo de cabeceras (`x-codex-primary-reset-at`, `x-codex-secondary-reset-at`, o
+`x-codex-tertiary-reset-at`) → el combo de `cooldownMs` (cuando se establece) → el 10 minutos de espera para una ventana de uso gastado o un fallo de credencial / facturación → el retroceso de tasa de solicitud de 5 segundos para upstream códigos de límite de velocidad `1302`/`1305` → el valor predeterminado de 60 segundos. Primero se comprueba si se agotó la ventana de uso. Por eso, un fallo que incluya un código de límite de solicitudes *y* un mensaje de límite de uso activa una espera de diez minutos en lugar de cinco segundos. Una validez inmediata
+`Retry-After: 0` sigue siendo una directiva ascendente inmediata en lugar de ser reemplazada por una Enfriamiento.
+
+Para un grupo OAuth o Codex Anthropic, un 429 vinculado a una cuenta que el grupo se ha enfriado no enfría todo el objetivo combinado. Otras cuentas detrás de ese objetivo siguen disponibles. Un 429 sin una cuenta de grupo refrigerada identificada aún enfría el objetivo, al igual que los fallos de todo el proveedor.
+
+<a id="last-resort-targets"></a>
+
+### Objetivos de último recurso
+
+Un breve tiempo de reutilización de un objetivo preferido se dirige directamente a lo que viene después en la lista, incluido un objetivo que solo quería usar en una emergencia. Márcalo y dile al combo que espere primero:
+
+```json
+{
+  "strategy": "failover",
+  "cooldownWaitPolicy": "before-last-resort",
+  "waitForCooldownMs": 10000,
+  "targets": [
+    { "provider": "provider-a", "model": "model-a" },
+    { "provider": "provider-b", "model": "model-b" },
+    { "provider": "provider-c", "model": "model-c", "lastResort": true }
+  ]
+}
+```
+
+Con el conjunto de políticas, la selección prueba primero los objetivos normales. Si solo se están enfriando y el enfriamiento más temprano expira dentro de `waitForCooldownMs`, la solicitud espera eso en lugar de enviar el objetivo de último recurso. Ese aplazamiento no depende de la espera: un objetivo `lastResort` se salta siempre que cualquier objetivo normal esté disponible, para cada estrategia, y bajo `round-robin` o `random` no se une a la rotación en absoluto. `waitForCooldownMs` solo agrega la espera para un objetivo normal de enfriamiento, por lo que en el `0` predeterminado nada espera: el último recurso se usa tan pronto como no hay un objetivo normal disponible. Después de un intento fallido, la siguiente selección sigue la misma regla.
+
+**La política sólo se aplaza.** Cuando no se puede alcanzar un objetivo normal - todos se enfrían más allá del presupuesto, ya se han intentado o se han descartado - el objetivo del último recurso se envía como de costumbre. Una política que podría retenerlo convertiría una repliegue en una interrupción, que es peor que el enrutamiento prematuro que previene. Lo mismo se aplica a un combo cuyos objetivos son *todos* marcado `lastResort`: se despacha normalmente.
+
+`lastResort` es inerte a menos que se establezca `cooldownWaitPolicy`, y ambos se omiten por defecto, por lo que los combos existentes no se ven afectados. Solo la cadena exacta `before-last-resort` se admite.
+
+La solicitud actual nunca vuelve a intentar el mismo objetivo, con una excepción: una combinación de un solo objetivo que establece `waitForCooldownMs` puede volver a intentar su único objetivo una vez que el tiempo de reutilización de ese objetivo expire dentro de la misma solicitud, ya que no hay alternativa para fallar. Los rechazos de compatibilidad local de solicitud aún regresan sin ningún reintento. Las solicitudes posteriores omiten un objetivo enfriado hasta que expire el tiempo de reutilización; los rechazos de compatibilidad local de la solicitud no enfrían el objetivo. Un `Retry-After` HTTP -fecha que ya está en el pasado también se conserva como una directiva inmediata aguas arriba, al igual que `Retry-After: 0`. Establezca `waitForCooldownMs` para permitir que una solicitud posterior espere el tiempo de reutilización del objetivo elegible más temprano, hasta ese límite en cada intento de selección, y luego haga una selección nueva. Por lo tanto, una solicitud puede esperar hasta `hops × waitForCooldownMs` a través de múltiples saltos de conmutación por error. Antes de intentar un objetivo, el valor predeterminado `0` rechaza inmediatamente con HTTP 503 cuando cada objetivo elegible se está enfriando; ese `combo_unavailable` 503 lleva un encabezado `Retry-After` igual al primer tiempo de reutilización restante, redondeado a segundos enteros con un mínimo de 1. Las esperas no incorporan variación aleatoria (jitter), por lo que es posible realizar despertares sincronizados. Una solicitud abortada cancela esta espera y devuelve la respuesta normal `client_cancelled`; no envía un objetivo de copia de seguridad después de la cancelación. Un enfriamiento de destino de combo es estado por combo, separado del enfriamiento de cuota de nivel de cuenta Codex que usa el enrutamiento de cuenta nativo. Se guarda con su expiración absoluta en `combo-cooldowns.json` en el directorio de opencodex, así que un reinicio lo conserva hasta esa expiración; los proxies que comparten un mismo directorio nunca acortan los enfriamientos de los demás. Guardar, renombrar o borrar el combo limpia sus enfriamientos.
+
+Después de un rechazo HTTP 400 de contexto confirmado, el agotamiento devuelve el primero de esos rechazos como `context_length_exceeded`, incluso si los objetivos restantes no pueden reproducir el razonamiento, no tienen consentimiento para generar gasto o se agotó el presupuesto de envíos. Tiene prioridad sobre errores reintentables posteriores, incluidos los de cuota. La cancelación, los rechazos fatales posteriores y los rechazos explícitos de la política de fallback detienen el proceso de inmediato; nunca se envía la solicitud a un objetivo medido sin consentimiento.
+
+:::note
+La conmutación por error es intencionadamente limitada. Ayuda con la disponibilidad específica del objetivo, autenticación, cuota, y sobrecarga de fallos; no oculta errores de llamada o rechazos de políticas. En una solicitud Responses no combo, se reescribe una directiva xAI 403 permitida en HTTP 200.
+`incomplete/content_filter` antes de que Codex lo vuelva a intentar como un fallo de transporte; véase
+[Rechazos de política xAI](/es/reference/proxy-formats/#xai-policy-refusals). Combo hops todavía clasificar el HTTP 403 original como un salto.
+:::
+
+Para las solicitudes de transmisión, el estado ascendente HTTP no es la decisión final. OpenCodex almacena un prefijo de presalida limitado del Responses SSE del hijo seleccionado. Si el flujo informa de un terminal `response.failed` reintentable antes de cualquier texto, razonamiento, llamada de herramienta u otro evento de salida, el hijo se registra como fallido y el combo puede intentar su próximo objetivo elegible. Una salida cero `response.incomplete` sigue la misma ruta cuando su razón falta o es `adapter_eof`, `missing_terminal_event` o `upstream_stall_timeout`. Las razones semánticas explícitas como `max_output_tokens` y `content_filter` siguen siendo terminales, al igual que una razón explícita nula. También se mantiene una instantánea final sin razón que ya contiene elementos de salida. Una vez que comienza cualquier evento de salida, el destino se confirma: se devuelve un fallo de flujo posterior al cliente y nunca se reproduce en otro proveedor, lo que evita la ejecución duplicada de texto y herramientas. Si la memoria intermedia de pre-salida alcanza su límite de seguridad sin un terminal o límite de salida, OpenCodex también confirma el objetivo actual en lugar de aumentar la memoria sin un límite.
+
+<a id="request-local-target-compatibility"></a>
+
+## Compatibilidad con objetivos locales de solicitud
+
+Al enrutar Claude Code al backend canónico ChatGPT Codex, OpenCodex elimina el campo de metadatos de nivel superior no compatible `user` sin cambiar la clave de sesión/caché, los mensajes de entrada, los esquemas de herramientas o los identificadores de seguridad. Las pasarelas públicas Responses API y las pasarelas directas no canónicas mantienen ese campo.
+
+Un combo también puede avanzar después de un HTTP 400 `invalid_request_error` intacto que rechaza específicamente `user`, informa `unsupported_value` para `reasoning.effort` / `reasoning_effort`, o informa `param: input` con un rechazo `does not support image inputs` con alcance de modelo exacto. Una ruta que rechaza los medios de comunicación de la solicitud con el código `unsupported_input_modality`, como la entrada de imágenes enviada a una ruta del proveedor CLI sin un contrato multimodal verificado, avanza de la misma manera. Este es un desajuste para esa solicitud, no evidencia de que el objetivo no sea saludable, por lo que no registra ningún enfriamiento. Esta recuperación de compatibilidad no cambia silenciosamente `none` en un esfuerzo diferente ni amplía esta excepción a solicitudes arbitrarias no válidas. Las denegaciones de políticas, la cancelación y la producción ya comprometida siguen siendo no reproducibles. Una solicitud de un solo objetivo todavía devuelve un rechazo ascendente no resuelto.
+
+<a id="tool-calls-stay-on-one-target"></a>
+
+## Las llamadas de herramientas permanecen en un objetivo
+
+Cuando un modelo le pide a su cliente que ejecute una herramienta, la solicitud que devuelve el resultado de la herramienta finaliza el mismo turno de asistente. OpenCodex envía esa solicitud al objetivo que emitió la llamada a la herramienta, siempre que el objetivo aún esté habilitado, aún en el combo y fuera del tiempo de reutilización. Esto se aplica a todas las estrategias, incluido JEV, que omite su decisión para esa solicitud. El siguiente mensaje de usuario elige un destino normalmente.
+
+El seguimiento utiliza el hilo o el identificador de sesión del cliente, por lo que un cliente que no envía ninguno recibe una selección normal. Si el objetivo original no está disponible o falla, el combo falla como de costumbre, y el nuevo objetivo recibe las llamadas a la herramienta anterior de la forma que acepta. DeepSeek modelos de pensamiento obtienen un marcador de posición de razonamiento de un espacio para una llamada de herramienta que otro modelo emitió sin razonamiento. Gemini obtiene el marcador de posición de firma documentado de Google. Anthropic recibe una simple llamada de herramienta y resultado. Las versiones anteriores podían enviar DeepSeek una llamada de herramienta desnuda aquí y fallar con `The reasoning_text in the
+thinking mode must be passed back to the API`.
+
+<a id="default-reasoning-effort"></a>
+
+## Esfuerzo de razonamiento por defecto
+
+`defaultEffort` suministra un esfuerzo configurado cuando el objetivo seleccionado tiene una escalera soportada no vacía conocida. Con el valor predeterminado `defaultEffortMode: "fallback"`, un esfuerzo explícito de la persona que llama mantiene la precedencia. `defaultEffortMode: "force"` anula un esfuerzo de llamada válido con el valor predeterminado configurado; requiere un `defaultEffort` válido, no nulo y puede aumentar el costo y la latencia. El modo de fuerza es una elección explícita del operador a través de la configuración o administración combinada.
+
+La escalera anunciada del objetivo sigue siendo autorizada. Se conserva un valor soportado exacto; de lo contrario, se selecciona el peldaño soportado más alto en o por debajo de él, o el peldaño soportado más bajo cuando ninguno es inferior. Las escaleras desconocidas o vacías nunca causan la inyección predeterminada. El modo de fuerza no repara el esfuerzo del llamador mal formado en una solicitud costosa válida. Otros campos de razonamiento, incluyendo `reasoning.summary`, se conservan.
+
+`reasoningEffortMode` sigue siendo independiente de `defaultEffortMode`: las escaleras vacías explícitas eliminan los controles de esfuerzo / pensamiento no compatibles, y las escaleras adaptativas desconocidas también lo hacen, como se describe a continuación. Estrictas escaleras desconocidas preservan la petición de la persona que llama sin forzar un valor predeterminado. Los valores predeterminados admitidos son `low`, `medium`, `high`, `xhigh`, `max` y `ultra`; omita `defaultEffort` o configúrelo en `null` para deshabilitar la inyección predeterminada en modo de retroceso.
+
+<a id="mixed-capability-groups-reasoningeffortmode"></a>
+
+### Grupos de capacidades mixtas (`reasoningEffortMode`)
+
+En modo estricto, los niveles de esfuerzo publicados por un combo son la intersección de los niveles de sus destinos. Si un destino indica explícitamente que **no** admite control de esfuerzo, su conjunto vacío participa en la intersección y la deja vacía para todo el combo, aunque los demás destinos permitan ajustar el esfuerzo.
+
+Configure `reasoningEffortMode: "adaptive"` para excluir esos conjuntos vacíos de la intersección publicada. El selector muestra los niveles comunes de los destinos restantes; el destino sin control de esfuerzo sigue siendo elegible para el enrutamiento. Los destinos cuyos niveles son simplemente *desconocidos* se tratan como comodines en ambos modos.
+
+```json
+{
+  "combos": {
+    "mixed": {
+      "targets": [
+        { "provider": "openai-apikey", "model": "gpt-5.6-luna" },
+        { "provider": "local", "model": "no-effort-model" }
+      ],
+      "reasoningEffortMode": "adaptive"
+    }
+  }
+}
+```
+
+El valor predeterminado es `"strict"`, que mantiene el comportamiento original del selector. Esta configuración no cambia el orden de destino ni la política de conmutación por error. En el momento del despacho, una escalera de destino explícitamente vacía tiene sus controles de esfuerzo / pensamiento no soportados eliminados en cualquier modo mientras se conservan los campos de razonamiento sin esfuerzo soportados, como `reasoning.summary`; `"adaptive"` aplica la misma normalización a una capacidad de destino desconocida, mientras que los objetivos no vacíos conocidos mantienen su resolución de esfuerzo por objetivo existente. En el tablero de instrumentos se encuentra el interruptor **Escala de razonamiento adaptativo** en la sección Capacidades de un combo.
+
+<a id="image--multimodal-capability"></a>
+
+## Capacidad de imagen / multimodal
+
+De forma predeterminada, un combo publica el **intersección** de las modalidades de entrada de sus objetivos (la imagen solo está habilitada cuando cada objetivo la anuncia). Establecer `imageInput: "disabled"` para forzar solo texto incluso cuando cada destino admite imágenes: el catálogo cae `image` desde `inputModalities`, y las solicitudes que llevan imágenes se rechazan con HTTP 400 antes de que se llame a cualquier destino. `"auto"` (u omitir el campo) mantiene la intersección automática.
+
+En el panel de control, el interruptor **Imagen / multimodal** se puede habilitar siempre que cada objetivo tenga capacidades conocidas de entrada de imagen o texto. Los miembros de la imagen nativa permanecen sin cambios; los miembros de solo texto se declaran automáticamente solo texto en guardar (`modelCapabilities[model].inputModalities = ["text"]`), por lo que el [Visión Sidecar](/es/guides/sidecars/) describe sus imágenes. La sugerencia del switch nombra a los miembros que se inscribirán. Un miembro cuyas modalidades son desconocidas o no tienen entrada de texto (por ejemplo, un modelo de solo audio) no puede ser cubierto por el sidecar; mantiene el interruptor no disponible y se nombra en la sugerencia. Si el [Visión Sidecar](/es/guides/sidecars/) está deshabilitado globalmente, habilitar el interruptor muestra una advertencia que enlaza con el tablero: la inscripción aún se guarda, pero las imágenes se reemplazan con una nota de omisión y las solicitudes continúan sin descripciones de imágenes hasta que se vuelve a habilitar el sidecar. Desactivar el interruptor desactiva la entrada de imagen para el combo pero mantiene esas declaraciones del proveedor, y `PUT /api/combos` acepta la misma inscripción como una matriz opcional `visionSidecarTargets` de nivel superior de objetivos `{ provider, model }` exactos (solamente solicitud; nunca se almacena en el combo y se rechaza mientras `imageInput` es `"disabled"` cuando la lista de inscripción no está vacía). Las entradas que ya aceptan la entrada de imagen o se declaran sin texto se rechazan con HTTP 400 en lugar de sobrescribirlas, las entradas que el sidecar ya cubre se omiten y se rechaza un guardado antes de que la publicación restaure el combo y cada declaración juntos. Eliminar un miembro del combo no elimina su declaración de solo texto; límpialo en el editor del proveedor si ya no lo deseas.
+
+<a id="encrypted-v2-sub-agent-tasks"></a>
+
+## Tareas de subagentes encriptadas v2
+
+Hay una limitación importante para los subagentes Codex v2 ([incidencia #92](https://github.com/lidge-jun/opencodex/issues/92)). Un padre nativo puede enviar la tarea de un trabajador recién generado solo como texto cifrado acuñado para el backend nativo ChatGPT. Un proveedor externo no puede leer esa carga útil.
+
+Para tal solicitud, un combo filtra sus objetivos elegibles a rutas canónicas nativas ChatGPT, incluso después de un fallo reintentable. Las rutas Responses de clave directa explícitamente confiables con `allowEncryptedV2AgentTasks: true` también pueden recibir la tarea cifrada cuando se seleccionan directamente, fuera de un combo; esa opción no las habilita como objetivos de un combo. Si no se puede seleccionar un destino nativo canónico, o se agotan los intentos nativos, `agentTaskRecovery`, habilitado explícitamente, puede recuperar una tarea elegible de un subagente recién creado y continuar mediante un destino enrutado disponible del combo. Se mantienen las [restricciones de entrega de tareas v2 cifradas](/es/guides/sub-agent-surface/#encrypted-v2-task-delivery), incluidas la vinculación exclusiva a loopback, la credencial nativa entrante y la ausencia de persistencia del texto recuperado. Si la recuperación no está disponible o falla y aún no se ha intentado una ruta nativa, opencodex se detiene antes del envío y devuelve HTTP 400; si ya fallaron intentos nativos, conserva el último error de esos intentos. La respuesta inicial de tarea ilegible es:
+
+```json
+{
+  "error": {
+    "type": "invalid_request_error",
+    "code": "unreadable_encrypted_agent_task"
+  }
+}
+```
+
+Esto protege la tarea de ser enviada a un proveedor que no recibiría instrucciones legibles. Las tareas de texto plano legibles utilizan la estrategia combo normal.
+
+Tienes cuatro opciones de recuperación:
+
+1. Seleccione un modelo nativo ChatGPT para el niño.
+2. Agregue un objetivo canónico nativo ChatGPT al combo.
+3. Utilice la superficie v1 para la delegación a través de diferentes proveedores.
+4. Si controla al llamante, vuelva a enviar la tarea como contenido de texto sin formato v2 `agent_message`.
+
+Consulte [Superficie del subagente](/es/guides/sub-agent-surface/) para ver los modos v1/base/v2 y el flujo de trabajo de tareas cifrado completo.
+
+<a id="manage-combos"></a>
+
+## Administrar combos
+
+<a id="dashboard"></a>
+
+### Panel
+
+Abra el panel de control local y elija **Modelos → Combos**. El espacio de trabajo crea, edita, renombra y elimina combos. Sus selectores de modelos incluyen modelos ocultos: la visibilidad del catálogo solo controla las listas de modelos externos, no la selección Combo interna, y seleccionar un modelo oculto no lo hace visible externamente. El selector de destino aún excluye los proveedores deshabilitados, los combos anidados y el proveedor JEV solo para credenciales. **Crear JEV Auto** abre el mismo editor Combo con una plantilla de destino de decisión editable; en lugar de crear un duplicado se informa de un id o alias `jev-auto` existente. Un JEV Combo también muestra **Servicio de decisión** (TypeSafe JEV o un proveedor configurado `jev-decision`) y **Tiempo de espera de decisión (ms)**, y la vista general de Combos enumera cada servicio de decisión, punto final y tiempo de espera de JEV Combo.
+
+Cada objetivo también muestra una insignia de cuota en vivo: **Disponible**, **Fuera de cuota** o **Cuota desconocida**. El editor bloquea Guardar y Crear para la cuota solo cuando cada destino utilizable tiene un límite de inferencia agotado confirmado por el servidor actual para su credencial configurada. La cuenta, el modelo, la búsqueda y la cuota MCP de solo visualización, o la evidencia de enrutamiento faltante o caducada, no causan este bloque. El bloqueo expira en el límite de reinicio o frescura aplicable y se vuelve a verificar cuando la página se vuelve activa o visible; Actualizar recarga tanto los datos combinados como la cuota. El editor del panel de control aún no expone `cooldownMs` o `waitForCooldownMs`; use el archivo de configuración o la administración API hasta que la interfaz de usuario de seguimiento termine.
+
+### CLI
+
+Los comandos principales son:
+
+```bash
+ocx combo list
+ocx combo show <id>
+ocx combo set <id> --targets provider/model[:weight],...
+ocx combo remove <id> --yes
+```
+
+`set` también acepta `--strategy`, `--sticky`, `--effort`, `--alias`, `--native-alias`, `--allow-metered-targets on|off`, `--cooldown-reprobe on|off`, `--cooldown-reprobe-interval`, `--display-name`, `--description`, `--decision-provider`, `--decision-timeout` y `--rename-from`. Utilice `-` como el valor de `--effort`, `--alias`, `--display-name`, `--description`, `--decision-provider`, o `--decision-timeout` para borrar ese campo. Las dos opciones de decisión solo se aplican cuando la estrategia efectiva es JEV: al indicar `--strategy jev` o al omitir `--strategy` en un combo JEV existente. En un combo existente, `--targets` solo sustituye la lista de destinos; sin `--strategy`, conserva la estrategia guardada y sus ajustes JEV. `--native-alias` requiere un alias de modelo nativo desnudo actualmente soportado y un nombre de visualización no vacío. `create` y `update` son alias para `set`; `delete` es un alias para `remove`; y los mismos subcomandos están disponibles bajo `ocx route combo`.
+
+<a id="management-api"></a>
+
+### API de administración
+
+Los clientes sin cabeza usan `GET`, `PUT` y `DELETE` en `/api/combos`. `GET` enumera definiciones combinadas normalizadas, `PUT` crea o reemplaza una (y puede cambiar el nombre de una), y `DELETE` toma el parámetro de consulta id. Los detalles de autenticación y solicitud / respuesta se encuentran en el [Gestión API referencia](/es/reference/management-api/). Cuando un cuerpo `PUT` omite `cooldownMs` o `waitForCooldownMs`, el API conserva el valor ya almacenado para ese combo; envíe un valor explícito para cambiarlo. Un `cooldownMs` explícito (incluso `60000`) se persiste tal cual porque anula el retroceso de la tasa de solicitud. Un `cooldownMs` almacenado solo puede eliminarse editando el archivo de configuración; `waitForCooldownMs` se restablece a su valor predeterminado cuando un `PUT` envía explícitamente `0`, porque el serializador escaso omite ese valor predeterminado. Omission conserva ambos valores y el panel de control no los expone todavía. Omitir `defaultEffortMode`, `reasoningEffortMode`, `imageInput` o `cooldownWaitPolicy` también mantiene el valor almacenado. Para una solicitud que mantiene `strategy: "jev"`, el método de decisión se mantiene solo cuando se omiten tanto `decisionProvider` como `decisionModel`: el envío de cualquiera de los dos reemplaza el método almacenado, por lo que `decisionModel: null` sin `decisionProvider` selecciona TypeSafe. `decisionTimeoutMs` se mantiene por su cuenta cada vez que se omite. Una estrategia diferente deja caer los tres, y un objetivo reenviado sin `lastResort` mantiene la bandera de ese objetivo (igualada por proveedor y modelo). El tablero de instrumentos siempre envía `imageInput` y `reasoningEffortMode`, y para un JEV Combo `decisionProvider`, `decisionModel` y `decisionTimeoutMs` (`null` por defecto), por lo que al cambiarlos de nuevo al valor predeterminado, todavía reemplaza el valor almacenado.
+
+Para la configuración completa persistente, véase [Configuración](/es/reference/configuration/).
+
+<a id="configuration-reference"></a>
+
+## Referencia de configuración
+
+Los combos se almacenan en el objeto `combos` de nivel superior, con la clave de identificación combinada:
+
+```json
+{
+  "combos": {
+    "balanced": {
+      "targets": [
+        { "provider": "anthropic", "model": "claude-opus-4-8", "weight": 2 },
+        { "provider": "openai", "model": "gpt-5.6-sol", "weight": 1 }
+      ],
+      "strategy": "round-robin",
+      "stickyLimit": 2,
+      "defaultEffort": "high",
+      "alias": "team/balanced"
+    }
+  }
+}
+```
+
+| Campo | Requerido | Predeterminado | Normas |
+| --- | --- | --- | --- |
+| `targets` | Sí | — | Matriz ordenada no vacía de objetivos `{ provider, model, weight?, lastResort? }` configurados. Se rechazan los pares duplicados proveedor/modelo. |
+| `targets[].weight` | No | `1` | Entero de 1 a 10.000. Utilizado por round-robin y aleatorio; ignorado por failover, menos utilizado, reset-window y JEV. |
+| `targets[].lastResort` | No | `false` | Marca un objetivo solo de emergencia. Inert a menos que `cooldownWaitPolicy` esté establecido. Nunca hace que un objetivo sea permanentemente inelegible: cuando no se puede alcanzar un objetivo normal, se envía como de costumbre. |
+| `strategy` | No | `"failover"` | `"failover"`, `"round-robin"`, `"random"`, `"least-used"`, `"reset-window"` o `"jev"`. JEV decide solo el objetivo inicial elegible y el esfuerzo; Combo ordinario posee intentos posteriores. |
+| `stickyLimit` | No | `1` | Número entero de 1 a 100 solicitudes exitosas por selección de round-robin. Solo se aplica a round-robin. |
+| `cooldownMs` | No | unset → upstream fallback (5 s para la tasa de solicitud 429 códigos `1302` / `1305`, 10 min para una ventana de uso gastado o un fallo de credencial / facturación, de lo contrario 60 s) | Entero de 1 a 600000. Cuando se establece, se aplica como el tiempo de reutilización por objetivo siempre que no exista una señal de reinicio de flujo ascendente `Retry-After` o Codex utilizable, incluida la tasa de solicitud 429s; cuando no se establece, utiliza el retroceso de flujo ascendente. |
+| `waitForCooldownMs` | No | `0` | Entero de 0 a 600000. Tiempo máximo para esperar el objetivo de enfriamiento elegible más temprano antes de regresar `combo_unavailable`; el aborto cancela la espera. |
+| `cooldownWaitPolicy` | No | Sin configurar | `"before-last-resort"` aplaza los objetivos marcados como `lastResort`: solo se usan cuando no hay un objetivo normal disponible, para cada estrategia, y `waitForCooldownMs` solo agrega la espera para un objetivo normal de enfriamiento, por lo que en su `0` predeterminado no hay nada que esperar y el último recurso se usa tan pronto como no hay un objetivo normal disponible. Solo esa cadena exacta se selecciona. La espera diferida y la espera ordinaria comparten un presupuesto de `waitForCooldownMs` por intento de selección. |
+| `defaultEffort` | No | `null` | `low`, `medium`, `high`, `xhigh`, `max` o `ultra`; resuelto contra la escalera anunciada de cada objetivo. |
+| `defaultEffortMode` | No | `"fallback"` | `"fallback"` preserva el esfuerzo explícito de la persona que llama. `"force"` anula el esfuerzo del llamante válido, requiere un valor predeterminado no nulo válido y puede aumentar el costo y la latencia. |
+| `reasoningEffortMode` | No | `"strict"` | `"strict"` intersecta los niveles de esfuerzo anunciados por todos los destinos conocidos: si uno no anuncia ningún control de esfuerzo, el selector del combo queda vacío. `"adaptive"` excluye esas listas vacías de la intersección publicada. Al enviar la solicitud, una lista explícitamente vacía, o desconocida en modo adaptativo, elimina los controles de esfuerzo/pensamiento no admitidos y conserva los campos de razonamiento independientes del esfuerzo que sí se admiten, como `reasoning.summary`. Los destinos con niveles conocidos y no vacíos mantienen la resolución de esfuerzo existente. |
+| `jevEffortMode` | No | `"decide"` | Solo combos JEV. `"decide"` aplica el esfuerzo decidido sobre el cliente. `"client"` conserva destino y esfuerzo de cliente/escala, sin retier del modelo por JEV; `defaultEffortMode: "force"` sigue prevaleciendo. Caché depende de esfuerzo, destino, prefijo, proveedor y cuenta estables. |
+| `imageInput` | No | `"auto"` | `"auto"` o `"disabled"`. `"auto"` publica soporte de imagen solo cuando cada objetivo soporta imágenes; `"disabled"` fuerza el texto solamente (cae la imagen de las modalidades publicadas y rechaza las solicitudes portadoras de imágenes antes del envío). |
+| `alias` | No | Ninguno | ID de modelo público recortado opcional; use las reglas de alias anteriores. Un valor vacío se almacena como ningún alias. |
+| `nativeAlias` | No | `false` | Permitir explícitamente que un `alias` nativo desnudo actualmente soportado tenga prioridad de enrutamiento y catálogo. Nunca se infiere del alias. |
+| `displayName` | No | Ninguno | Etiqueta de catálogo limitada. Requerido y no vacío cuando `nativeAlias` es verdadero. |
+| `description` | No | Ninguno | Descripción de la fila del catálogo solo para mostrar, limitada como `displayName` (como máximo 128 caracteres, sin caracteres de control). Sin configurar, conserva el texto generado `Routed via opencodex → combo (combo).`. Las escrituras de la API de administración que omiten este campo conservan el valor guardado; una cadena vacía lo borra. |
+| `decisionProvider` | No | `"jev"` | Sólo JEV. Id de proveedor del servicio de decisión: `"jev"` (TypeSafe, válido sin una fila de proveedor; lo mismo que omisión) o una fila `adapter: "jev-decision"` configurada con una URL de decisión HTTPS completa o una URL local HTTP `/systemone`, tal como una Ollama `tev1` autohospedada. |
+| `decisionTimeoutMs` | No | `4000` | Solo JEV. Entero de 1000 a 120000: plazo de la decisión antes de usar la alternativa fail-open al primer destino elegible. |
+
+<a id="troubleshooting"></a>
+
+## Solución de problemas
+
+<a id="why-does-comboid-return-404"></a>
+
+### ¿Por qué `combo/<id>` ¿Error 404?
+
+La identificación combinada es desconocida. La respuesta es HTTP 404 con el tipo `invalid_request_error`. Ejecute `ocx combo list`, compruebe la ortografía y el caso, y confirme que el comando de administración se escribió en la misma instancia opencodex en ejecución que recibe las solicitudes del modelo.
+
+<a id="why-do-i-get-combo_unavailable"></a>
+
+### ¿Por qué tengo `combo_unavailable`?
+
+Todos los objetivos no son elegibles actualmente: por ejemplo, su proveedor está deshabilitado, se está enfriando, ya se ha intentado para esta solicitud o una tarea cifrada v2 lo excluye. Compruebe el estado del proveedor de destino y los errores recientes de flujo ascendente. Cuando no se intentó ningún objetivo, el mensaje de error enumera por qué se omitió cada objetivo, por ejemplo, `No available targets for combo (2 targets; target 1 (openai): quota exhausted; target 2 (anthropic): cooldown)`. El error del cliente identifica los destinos solo por su posición y proveedor; el registro del servicio indica esa posición y proveedor cuando el destino falla o el proxy espera su periodo de enfriamiento. Para tiempos de reutilización, siga primero un valor de `Retry-After` observado; Las cabeceras de reinicio Codex también tienen prioridad sobre `cooldownMs`. Si no se puede usar ninguna señal ascendente, se aplica la configuración `cooldownMs`, o se aplica la reserva ascendente cuando no está configurada (5 segundos para los códigos de tasa de solicitud `1302` / `1305`, 10 minutos para una ventana de uso gastada o un fallo de credencial/factura, de lo contrario 60 segundos). `Retry-After` retrasos explícitos tienen un límite de 24 horas; los otros tiempos de reutilización tienen un límite de 10 minutos.
+
+Los errores de validación HTTP 400/422 que citan texto de cuota o del límite del nivel gratuito no activan una alternativa solo por ese texto. Un rechazo estructurado `free_rate_limited` sí prueba el siguiente destino apto, sin poner en enfriamiento al proveedor o destino sano.
+
+<a id="why-was-my-alias-rejected"></a>
+
+### ¿Por qué fue rechazado mi alias?
+
+Compruebe primero la gramática del alias y los nombres reservados. Un alias duplicado o forma no válida se rechaza como HTTP 400. Un alias recortado cuyo primer segmento es un espacio de nombres de cuenta Codex configurado se rechaza como HTTP 409; elija un espacio de nombres de alias diferente. El CLI y el panel de control muestran el mensaje de validación exacto del servidor.
+
+<a id="context-window-refusals"></a>
+
+### Rechazos por ventana de contexto
+
+La recuperación de combos utiliza el mismo detector acotado de desbordamiento de contexto que Responses. Lee el mensaje más interno del proveedor y reconoce `context_length_exceeded`, `prompt is too long`, `input is too long for requested model` y `Please reduce the length of the messages or completion`. Los tres últimos solo cuentan cuando el mensaje comienza con ellos; en el caso de Anthropic se incluyen sus recuentos de tokens. Un error de validación que cite esas frases como valor de un parámetro o una cadena de error de SDK que las envuelva no cumplen la condición. Tampoco la cumplen un código junto a un mensaje ajeno al contexto, JSON mal formado, un error de validación de parámetros o una instrucción genérica de acortar un parámetro.
+
+La salida ya confirmada nunca se reproduce. Se mantienen la política de fallback, el consentimiento de gasto y los presupuestos de envío; cada intento físico conserva su propio uso. Si se agotan los objetivos elegibles o el presupuesto, el primer rechazo HTTP 400 de contexto confirmado tiene prioridad sobre errores reintentables posteriores, incluidos los de cuota. Un rechazo fatal posterior detiene el proceso inmediatamente.
+
+<a id="why-did-failover-stop-after-the-first-error"></a>
+
+### ¿Por qué se detuvo la conmutación por error después del primer error?
+
+El error fue terminal en lugar de específico del objetivo. Corrige entradas no válidas, maneja un rechazo de directiva o corrige el origen de la solicitud rechazada. Los combos no saltan para esos casos.
+
+<a id="retry-all-cooled-targets-opt-in"></a>
+
+## Reintentar cuando todos los destinos están en enfriamiento
+
+La recuperación de enfriamientos del combo es opcional y está deshabilitada por defecto.
+Para permitir una nueva pasada de failover cuando todos los destinos que serían elegibles
+tienen un enfriamiento guardado del combo:
+
+```sh
+ocx combo set review --cooldown-reprobe on --cooldown-reprobe-interval 300000
+ocx combo set review --cooldown-reprobe off
+```
+
+La configuración correspondiente de cada combo es:
+
+```json
+{ "cooldownReprobe": { "enabled": true, "intervalMs": 300000 } }
+```
+
+El intervalo predeterminado es de cinco minutos. Acepta milisegundos enteros de 1000 a 86400000.
+Configurar solo el intervalo no habilita la recuperación. Se activa por demanda: la primera
+solicitud elegible puede reservar una pasada de inmediato; las posteriores respetan el intervalo.
+No hay temporizadores ni tráfico en segundo plano. Cada destino se intenta como máximo una vez
+dentro del presupuesto de failover existente, y los fallos registran nuevos enfriamientos.
+Se conservan las comprobaciones de cuota, proveedores deshabilitados, compatibilidad, permisos
+de gasto medido y cancelación. Un Retry-After explícito del proveedor puede reintentarse antes
+de su plazo únicamente si el operador habilita esta opción. Las vistas previas y las listas
+no borran enfriamientos. El intervalo de reserva de cada pasada de recuperación se registra por combo en memoria y se reinicia al reiniciar
+el proxy o el estado de selección del combo. Si está deshabilitada, se conserva la espera habitual.
+
+Una pasada de recuperación pertenece solo a la solicitud que la reservó; las demás siguen observando los periodos de enfriamiento guardados. La reserva acompaña a esa solicitud durante las esperas y la selección JEV. Un destino que vuelve a estar disponible durante una espera puede reintentarse si su periodo de enfriamiento no cambió. Un enfriamiento más reciente cancela la reserva de ese destino. El éxito solo borra el enfriamiento sin cambios del destino que respondió; los destinos no probados y los fallos más recientes conservan sus periodos.
+
+
+Un HTTP 400 puede ser incompatibilidad local del destino. El wrapper opaco OpenRouter `Provider returned error`, `code: 400` numérico, sin `type` y con `metadata.raw: "ERROR"`, permite otro destino sin enfriarlo. Un 400 tipado sin código, un `response_format` mal formado o código raíz terminal siguen siendo terminales. Una raíz con `model_not_found`, insufficient_quota, usage_limit_exceeded, free_rate_limited, `input_admission_refused` o unsupported_input_modality no añade otro veredicto; código vacío es ausente. Un evento de error streaming sin estado pero con `code` entero 400–599 se juzga como HTTP: antes de salida, 400/409/413/422 genéricos detienen, 401/402/403 enfrían proveedor y el exceso de contexto reconocido permite alternativa.
+
+Con `jevEffortMode: "decide"`, predeterminado, el esfuerzo elegido por JEV prevalece en el primer hijo Responses y en Chat nativo activado; elimina controles de pensamiento y service_tier incompatibles. Elegir sin esfuerzo también quita un predeterminado forzado. Con `"client"`, mantiene destino y deja esfuerzo al cliente, escala y defaultEffort; defaultEffortMode force sigue prevaleciendo. Fijaciones, límites y normalización del proveedor se aplican después.
+
+El enfriamiento por combo es independiente del de cuenta y persiste con expiración absoluta en `combo-cooldowns.json`. Proxies del mismo directorio no lo acortan; guardar, renombrar o borrar el combo lo limpia.
+
+Los destinos RunTurn retienen razonamiento previo hasta un segundo: una finalización max_output_tokens sin salida dentro del plazo permite otro destino sin enfriar al sano. Al vencer o aparecer salida, se compromete y transmite lo retenido. También puede avanzar incomplete sin razón, adapter_eof, missing_terminal_event o upstream_stall_timeout antes de salida. `end_turn: false` o `incomplete_details.retryable` false conserva el destino. `pause_turn` Anthropic es pausa larga y sigue como `incomplete` con max_output_tokens, sin alternativa. Content_filter, razones semánticas explícitas, null explícito y límites tras salida son terminales. Si todos acaban así sin salida y sin exceso de contexto confirmado, se devuelve el último HTTP 200 incomplete con su uso, no 502. JSON nativo no streaming no se inspecciona. Los metadatos de tasa de Codex WebSocket no son salida; tras salida o límite de buffer nunca se reproduce en otro destino.
+
+Un rechazo estructurado de esfuerzo puede bajar una posición publicada cada vez en el mismo destino mientras quede presupuesto. Incluye `{"code":"invalid-argument","error":"Invalid reasoning effort."}` y las formas reconocidas de unsupported_value. Si ninguna sirve, solo formas de compatibilidad reconocidas avanzan sin enfriarlo; conserva el 400 si no quedan envíos. No convierte none ni generaliza a errores inválidos arbitrarios. Rechazos de política, cancelación o salida ya comprometida nunca se reproducen. Si un destino enfriado fija la recuperación más próxima, mensaje y Retry-After muestran el mismo plazo, por ejemplo `(retry in ~2m)`; Messages usa la misma espera.
diff --git a/docs-site/src/content/docs/es/guides/composer-usage-gate-fallback.md b/docs-site/src/content/docs/es/guides/composer-usage-gate-fallback.md
new file mode 100644
index 00000000000..2351372f649
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/composer-usage-gate-fallback.md
@@ -0,0 +1,135 @@
+---
+title: "Alternativa ante límites de uso de Composer"
+description: "Envía texto bajo demanda a la cola de un hilo existente de Codex sin cambiar la autenticación ni el enrutamiento de OpenCodex Desktop; las cuotas del servidor siguen aplicándose."
+---
+
+Un bloqueo por uso del **cuadro de mensajes (Composer)** de Desktop puede impedir nuevas entradas aunque la ruta de OpenCodex configurada para el hilo todavía tenga capacidad. En una instalación compatible, `codex queue` usa la cola nativa del app-server de Codex sin pasar por ese cuadro. No parchea la aplicación, intercepta TLS, instala certificados ni cambia la autenticación.
+
+Esto **no es una solución para cada estado de límite de uso**. No restablece la cuota agotada ni desbloquea el selector de modelos. Un hilo que ya usa `gpt-reserve` mantiene ese modelo; el texto en cola no lo cambia a otro proveedor. La autorización del lado del servidor, las cuotas de proveedores, las aprobaciones y la configuración de ejecución del subproceso aún se aplican.
+
+<a id="identify-the-blocked-layer"></a>
+
+## Identificar la capa bloqueada
+
+Un compositor deshabilitado antes del envío es diferente de un rechazo real del proveedor después del envío. Una etiqueta de modelo personalizada no demuestra ser un proveedor independiente ni la capacidad disponible. Utilice este recurso solo para un subproceso seleccionado deliberadamente con una ruta que de otro modo se podría usar; compruebe las aprobaciones pendientes, los giros activos y la conectividad aplicación-servidor por separado.
+
+El bloqueo de la cuenta principal sigue siendo autorizado. Es un guardia de admisión previo al agotamiento, no una forma de restaurar una cuenta ya agotada. Este ayudante no deshabilita esa protección ni cambia el proveedor que usa un subproceso. No cambie las respuestas de cuota ni desactive la guardia para ejecutar una solicitud de cuenta nativa en cola.
+
+<a id="opencodex-integration-and-ownership"></a>
+
+## Integración y propiedad de OpenCodex
+
+Mantener la configuración existente [Codex integración](/es/guides/codex-integration) y [modelo de enrutamiento](/es/guides/model-routing). El camino es:
+
+```text
+helper -> native Codex queue -> the selected thread's app-server
+       -> the thread's configured provider -> OpenCodex, when already routed there
+```
+
+Los ayudantes no implementan otro router de proveedor. Envían solo el destino y el texto, no el modelo, la cuenta, el nivel de servicio, la aprobación, el sandbox o las anulaciones de la URL base. Un proveedor `openai` incorporado enrutado a OpenCodex y un proveedor personalizado `opencodex` mantienen su configuración existente. Pool / Direct selección, cuentas vinculantes, credenciales de proveedor y verificaciones de admisión siguen siendo propiedad de OpenCodex y el demonio de servicio. La aceptación de colas por sí sola no prueba que se haya llamado a un proveedor.
+
+Utilice el **mismo `CODEX_HOME` y compatible CLI /app-server** como la instalación de escritorio. `CODEX_HOME` por defecto es `~/.codex`; otra casa puede descubrir otro daemon y almacenamiento de hilos. `OPENCODEX_HOME` es el hogar del proxy, no un sustituto de `CODEX_HOME`. Los ayudantes dejan ambas variables y los archivos de configuración de ambas aplicaciones sin cambios. En PowerShell, los hijos nativos heredan la ubicación del sistema de archivos del shell, incluso cuando `CODEX_HOME` es relativo.
+
+El proxy ya debe estar ejecutándose y el subproceso de destino ya debe usar la ruta prevista. El ayudante no inicia/sincroniza/reconfigura OpenCodex, vuelve a habilitar una integración deshabilitada o reemplaza silenciosamente una ruta OpenAI directa. No se requiere alternar `codexDesktopAuthless`. Una URL de proveedor remota OpenCodex no es lo mismo que un servidor de aplicaciones remoto Codex: estos ayudantes utilizan el descubrimiento de demonios locales, no el enrutamiento automático a una conversación en otro equipo.
+
+Estos son **Ayudantes de repositorio bajo demanda**, no un comando `ocx queue` instalado o un control de tablero. La lista de permisos de archivos del paquete npm no incluye `scripts/`; use una comprobación de repositorio coincidente o el comando nativo `codex queue`. Este recurso restringido evita agregar un segundo monitor de transporte, escucha persistente, caché de estado de cuenta o límite de uso a OpenCodex.
+
+<a id="onoff-and-normal-usage-behavior"></a>
+
+## Activación/desactivación y comportamiento normal
+
+Hay **sin interruptor de activación/desactivación persistente**: la ejecución del ayudante es la opción de una presentación. Simplemente instalar/actualizar OpenCodex o mantener los scripts en disco no los ejecuta.
+
+| Situación | Lo que hace este fallback |
+| --- | --- |
+| No invocado, tanto si hay contingente disponible como si se ha agotado | Nada: ningún proceso, temporizador, sondeo, oyente de fondo o solicitud originada por el ayudante. |
+| Invocado normalmente mientras el uso está disponible | Hace colas para un mensaje ordinario. No se salta solo porque el compositor de escritorio está trabajando. El uso/facturación normal del proveedor se puede aplicar cuando se envía. |
+| Invocado mientras solo el compositor está bloqueado | Intenta el mismo envío de cola nativa. La ruta configurada debe estar autorizada y disponible. |
+| El proveedor real no tiene capacidad ni autorización | No pasa por alto esa restricción ni cambia de proveedor/cuenta; la ejecución en sentido ascendente aún puede fallar después de la aceptación de la cola. |
+| `-DryRun` / `--dry-run` | Selecciona un destino y comprueba la ayuda del CLI, pero nunca envía texto ni comprueba la cuota de la cuenta, el estado del demonio o la disponibilidad del proveedor. |
+| El bloqueo por uso se levanta más tarde | Vuelve a usar el cuadro de mensajes normal. No hay ajustes específicos de los scripts auxiliares que debas revertir. |
+
+Para dejar de usar la reserva, deja de invocarla. No ejecutes `ocx restore` ni desactives la integración de Codex solo para dejar de usar este script auxiliar; ambas acciones también cambian el enrutamiento normal de OpenCodex. Si ha programado el comando de forma independiente, desactive esa programación externa. Los elementos de cola ya aceptados pertenecen a Codex y aún pueden ejecutarse: eliminar el script, salir de su proceso o recuperar la cuota no los cancela. Inspeccione/elimine elementos no deseados a través de los controles de cola normales en la misma conversación. No envíe el mismo mensaje tanto en el ayudante como en el compositor.
+
+<a id="check-compatibility-before-sending"></a>
+
+## Compruebe la compatibilidad antes de enviar
+
+Prefiera el CLI empaquetado en la aplicación; un `codex` instalado por separado en PATH puede ser más antiguo. Compruebe `codex queue --help` para `--thread` y `--message`. Los ayudantes prueban esta capacidad CLI, pero solo una solicitud real puede verificar el soporte `thread/queue/add` del demonio. Si Codex informa un método de cola no compatible, guarde el trabajo en curso antes de actualizar/reiniciar la instalación correspondiente. Los ayudantes nunca reinician un demonio o reintentan con otro servidor. No agregue `--no-daemon` a un comando de cola. Las actualizaciones de la aplicación CLI pueden cambiar la compatibilidad.
+
+Primero abra la conversación prevista y confirme su proyecto, modelo y proveedor. Prefiera su **UUID explícito**; el nativo CLI también acepta un nombre de sesión exacto:
+
+```powershell
+codex queue --thread 'my-project-review' --message 'continue with the next step'
+```
+
+Desde una comprobación del repositorio, el ayudante Windows puede descubrir el paquete nativo `codex.exe`:
+
+```powershell
+.\scripts\codex-queue.ps1 -Thread 'my-project-review' -Message 'continue with the next step'
+```
+
+En macOS / Linux, utilice Bash (incluido el Bash 3.2 de macOS):
+
+```bash
+bash scripts/codex-queue.sh --thread 'my-project-review' --message 'continue with the next step'
+```
+
+Fijar un binario de confianza coincidente con `-CodexExe 'C:\path\to\codex.exe'`, `--codex '/path/to/codex'` o `CODEX_EXE`. Una selección explícita no válida falla en lugar de seleccionar silenciosamente otro ejecutable. En Windows use un `.exe` nativo, no un npm `.cmd` o una shim PowerShell, para mantener el mensaje citando `cmd.exe`. Los paquetes de aplicaciones compatibles con colas y los diseños independientes se prueban antes de PATH. El descubrimiento automático de PATH ignora entradas vacías y relativas en lugar de sondear un CLI del proyecto actual implícitamente. Un binario local de confianza todavía se puede seleccionar explícitamente con `--codex './codex'` o `-CodexExe '.\codex.exe'`. Las raíces de instalación configuradas y las entradas absolutas de PATH aún deben ser confiables para el operador; este ayudante no verifica las firmas binarias. Discovery no prueba una versión de la aplicación que coincida.
+
+<a id="private-diagnostics-and-optional-latest-thread-discovery"></a>
+
+### Diagnósticos privados y descubrimiento opcional de última generación
+
+Una ejecución seca oculta rutas ejecutables, UUID de subprocesos/nombres y el cuerpo del mensaje de forma predeterminada:
+
+```powershell
+.\scripts\codex-queue.ps1 -Thread 'my-project-review' -DryRun
+```
+
+Informa de la capacidad CLI y la selección de destino solamente, no la validación exitosa del lado del servidor. Para las tiendas basadas en despliegue heredado, `-Latest` / `--latest` opta explícitamente por un **última heurística de archivo**. Para ver esa selección, utilice un terminal privado no redireccionado:
+
+```powershell
+.\scripts\codex-queue.ps1 -Latest -DryRun -ShowTarget
+```
+
+```bash
+bash scripts/codex-queue.sh --latest --dry-run --show-target
+```
+
+`-ShowTarget` / `--show-target` requiere una ejecución en seco y una salida de terminal local. Revela la ruta seleccionada y UUID/nombre solo por esta solicitud explícita, escapa a los caracteres de control y rechaza la salida redirigida, como la captura de CI. No lo use en terminales grabados/compartidos ni publique la salida públicamente. Nunca imprime el mensaje. La salida nativa ordinaria Codex durante una presentación real se pasa a través y puede contener identificadores; revíselo antes de compartir registros.
+
+El último descubrimiento busca `CODEX_HOME/sessions` por tiempo de modificación, con el orden del nombre del archivo como desempate. Es **No es la conversación de escritorio actual** y puede seleccionar otro proyecto o un subagente. Verifique la vista previa local y, a continuación, envíe con el UUID explícito elegido. Latest también puede enviar cuando se proporciona un mensaje, pero sigue siendo una suscripción deliberada a esta heurística.
+
+Los nombres de archivo `rollout-*.jsonl` reconocidos contienen un UUID de subproceso, a veces seguido de `_<rollout-uuid>`; el ayudante usa el primer UUID. Los nombres mal formados se omiten. Las tiendas que faltan o son ilegibles fallan sin seleccionarlas de otra casa. Los almacenes solo migrados/paginados y las conversaciones solo remotas pueden no tener un despliegue local coincidente; use un UUID/nombre explícito.
+
+Mantenga todo el mensaje en un solo argumento. Bash acepta `--message '- start with this'` o `-- '- start with this'`; PowerShell acepta `-Message '- start with this'`. El historial de shell y los listados de procesos locales pueden exponer el texto de la línea de comandos, así que no incluya credenciales en las solicitudes.
+
+<a id="queued-is-not-the-same-as-executed"></a>
+
+## En cola no significa ejecutado
+
+`Queued message ... for thread ...` confirma la **aceptación en la cola**, no la ejecución del modelo ni su finalización. Un hilo ocupado puede estar esperando a que termine su turno actual o se resuelva una aprobación. Según la implementación, un hilo guardado que no está cargado puede conservar el mensaje hasta que otro cliente lo reanude.
+
+Comprueba la cola y la actividad en la **misma conversación**. Si el hilo no está cargado, ábrelo en la aplicación o usa `codex resume <thread-id>` sin volver a añadir el mensaje. Revisa las aprobaciones pendientes y el estado de la cola. Cada invocación puede crear otro elemento; si el fallo es ambiguo, inspecciona el estado antes de reintentar. Los scripts auxiliares conservan el código de salida de la CLI y nunca reenvían automáticamente.
+
+El CLI nativo tiene `--remote` opciones explícitas (véase `codex queue --help`), a diferencia de asumir que la conexión de control remoto del escritorio se reutiliza. Mantener la configuración de autenticación sin cambios no repara errores de autenticación/red no relacionados ni garantiza la continuidad del control remoto.
+
+<a id="starting-or-resuming-work-without-the-composer"></a>
+
+## Iniciar o reanudar el trabajo sin el compositor
+
+`codex exec '<prompt>'` inicia una tarea no interactiva, **no** un mensaje en el subproceso de escritorio abierto. Compruebe su directorio de trabajo, proveedor, permisos y configuración. `codex resume <thread-id>` reanuda una sesión explícita. `codex resume --last` normalmente se filtra por directorio de trabajo actual; `--all` deshabilita ese filtro, mientras que otros filtros de elegibilidad aún pueden aplicarse. Una selección global no es necesariamente la sesión del sistema de archivos visible o más reciente. Prefiere una identificación explícita para el trabajo de escritorio en curso.
+
+<a id="scope-and-verification"></a>
+
+## Alcance y verificación
+
+Esta alternativa deja solos los derechos de la cuenta y los archivos de la aplicación. No es una reparación consciente del proveedor del compositor / selector de modelos, una función automática de recuperación de cuotas o la limpieza de los cambios de proxy / certificado no relacionados de experimentos anteriores.
+
+La sonda original Windows (escritorio `26.917.9434.0`) reportó aceptación de cola para un hilo en vivo y un error esperado para un hilo inexistente. Eso no es una inferencia general de extremo a extremo, hilo descargado, control remoto o garantía multiplataforma. La fuente aguas arriba se comprobó en `7dae8c53d97e61cd774e4d6bcca5243c29ca615c`:
+
+- [Opciones de cola CLI](https://github.com/openai/codex/blob/7dae8c53d97e61cd774e4d6bcca5243c29ca615c/codex-rs/cli/src/queue_cmd.rs) y [presentación de app-server](https://github.com/openai/codex/blob/7dae8c53d97e61cd774e4d6bcca5243c29ca615c/codex-rs/tui/src/session_queue_commands.rs).
+- [Envío de cola de hilo cargado](https://github.com/openai/codex/blob/7dae8c53d97e61cd774e4d6bcca5243c29ca615c/codex-rs/ext/queue/src/service.rs) y [Opciones de selección de reanudación](https://github.com/openai/codex/blob/7dae8c53d97e61cd774e4d6bcca5243c29ca615c/codex-rs/cli/src/main.rs).
+
+Ejecute regresiones de envoltura sin conexión con `node --test scripts/codex-queue.test.mjs` (Node 20+). Utilizan CLIs nativos falsos y hogares temporales, nunca cuentas reales o solicitudes de modelos. El flujo de trabajo **Codex ayudantes de cola** ejecuta estas pruebas en Windows PowerShell 5.1 y PowerShell 7, macOS Bash y Linux Bash; falla un shell requerido faltante en lugar de omitirlo silenciosamente. Los accesorios de configuración-preservación cubren la configuración del proveedor incorporado/personalizado y ambos valores del estado de uso, no el enrutamiento OpenCodex en vivo. Valide el despacho de escritorio real, el éxito del proveedor y la continuidad del control remoto por separado en las instalaciones compatibles.
diff --git a/docs-site/src/content/docs/es/guides/cursor-private-inference.md b/docs-site/src/content/docs/es/guides/cursor-private-inference.md
new file mode 100644
index 00000000000..87b77c33474
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/cursor-private-inference.md
@@ -0,0 +1,140 @@
+---
+title: "Inferencia privada de Cursor"
+description: "Utilice los modelos con enrutamiento opencodex dentro de la compilación de agente local de Cursor, en macOS, Windows o Linux, sin un túnel público."
+---
+
+El Cursor regular no puede hablar con un proxy en su propia máquina. Cuando establece "Override OpenAI URL base", el backend de Cursor crea el mensaje y llama a esa URL desde los servidores de Cursor, que rechazan el loopback, la LAN y las direcciones privadas. Es por eso que cada receta de la comunidad para Cursor + modelos locales termina con ngrok, Cloudflare Tunnel o un VPS.
+
+Cursor también envía una segunda compilación de escritorio, **Cursor Inferencia privada**, cuyo bucle de agente se ejecuta localmente y llama a una puerta de enlace compatible con OpenAI que configura. Señalado en opencodex, utiliza sus modelos enrutados sin túnel, sin parches de aplicaciones y sin TLS. Esta página cubre esa construcción.
+
+<a id="before-you-start"></a>
+
+## Antes de empezar
+
+Lea esta sección primero; es la parte que la gente extraña.
+
+- **opencodex no distribuye esta compilación.** Cursor tampoco lo documenta. No está vinculado desde cursor.com, puede cambiar sin previo aviso y puede dejar de estar disponible. Si aún no lo tiene, esta guía no se aplica; use el puente de la comunidad [`ocx-cursor`](https://www.npmjs.com/package/ocx-cursor) con un punto final público HTTPS en su lugar.
+- **El inicio de sesión Cursor todavía es necesario.** El muro de inicio de sesión viene antes del diálogo de puerta de enlace.
+- **Los modelos propios de Cursor no están disponibles.** En el modo local, el selector solo muestra lo que devuelve la puerta de enlace. La autocompletación con Tab, el catálogo de Cursor (Composer, Auto) y Cloud Agents están desactivados. Todavía puede llegar a los modelos del proveedor Cursor a través de las rutas propias de opencodex `cursor/*` si ha configurado ese proveedor.
+- **Cada vuelta incluye el prompt de sistema local de Cursor**, aproximadamente 23k tokens en el segundo turno y los posteriores. Presupuesto para cuando elijas un modelo.
+- **Comparte la identidad con Cursor regular.** Mismo identificador de paquete, mismo `~/.cursor`, mismo `Application Support/Cursor` ( macOS), `%APPDATA%\Cursor` ( Windows) o `~/.config/Cursor` ( Linux). Inicie con `--user-data-dir <dir>` para mantener los dos separados, y deje "Importar datos de la instalación Cursor existente" sin marcar en la primera ejecución a menos que desee copiar la configuración.
+
+<a id="identify-the-installed-build"></a>
+
+## Identificar la construcción instalada
+
+Ambas versiones se denominan " Cursor " en el Dock y comparten una identificación de paquete, así que verifique `product.json`:
+
+| Plataforma | product.json |
+|---|---|
+| macOS | `/Applications/Cursor Private Inference.app/Contents/Resources/app/product.json` |
+| Windows | `%LOCALAPPDATA%\\Programs\\cursor-private-inference\\resources\\app\\product.json` |
+| Linux | `<install root>/resources/app/product.json` (primero debe extraerse una AppImage). El tablero de instrumentos busca raíces de instalación `cursor*` bajo `/opt`, `/usr/share` y `~/.local/share`. |
+
+`nameLong` es `"Cursor Private Inference"` para el agente local y `"Cursor"` para el regular; `version` es la construcción (3.18.25 en el momento de la escritura). La tarjeta Integrations.Cursor del panel de control ejecuta la misma verificación y enumera lo que encontró. El modo local se activa dentro del paquete del workbench, no en `product.json`, por lo que no hay ninguna opción que activar: si `nameLong` dice Cursor regular, esa instalación no puede llegar a una puerta de enlace de loopback.
+
+El bucle del agente que habla con la puerta de enlace vive en un archivo bajo la misma raíz de instalación, `extensions/cursor-agent-exec/dist/main.js`. opencodex lo lee (solo lectura, limitado) para aprender la tabla de esfuerzo de razonamiento de Cursor; véase "Modelos y esfuerzo de razonamiento".
+
+<a id="configure-the-gateway"></a>
+
+## Configurar la puerta de enlace
+
+opencodex necesita estar en funcionamiento (`ocx service status`). Entonces cualquiera de estas obras; ambos terminan en el mismo lugar.
+
+**En la aplicación.** Configuración → Modelos → Pasarela → Configurar la puerta de enlace:
+
+| Campo | Valor |
+|---|---|
+| URL base | `http://127.0.0.1:10100/v1` (incluya `/v1`; se acepta el loopback simple con `http://`) |
+| Clave API | una clave de OpenCodex aceptada por el servicio cuando está habilitada la admisión con clave API: puede ser `OPENCODEX_API_AUTH_TOKEN` o una clave de cliente configurada; use `opencodex-loopback` solo cuando la configuración permita ese marcador de posición |
+
+Haga clic en **Actualizar lista de modelos**. El selector se llena con opencodex `/v1/models`; encienda las filas que desee.
+
+**Con variables de entorno.** La aplicación lee esto al principio:
+
+```text
+CURSOR_LOCAL_AGENT_BASE_URL=http://127.0.0.1:10100/v1
+CURSOR_LOCAL_AGENT_API_KEY=opencodex-loopback
+CURSOR_LOCAL_AGENT_HEADERS=            # optional, newline-separated "Header-Name: value" lines
+```
+
+`CURSOR_LOCAL_AGENT_HEADERS` rechaza `User-Agent` y `{...}` marcadores de posición no resueltos; `{gitOrgRepo}` y `{gitBranch}` se expanden.
+
+Precedencia, el más alto primero: credenciales por modelo → la puerta de enlace guardada en Configuración → `CURSOR_LOCAL_AGENT_*` → `ANTHROPIC_BASE_URL` / `ANTHROPIC_AUTH_TOKEN` (alternativa por compatibilidad). El entorno no anula una puerta de enlace guardada; límpiela primero en Configuración si tiene la intención de cambiar a través del entorno.
+
+Cursor Private Inference es una aplicación GUI, por lo que un perfil de shell interactivo no es suficiente por sí solo; la variable tiene que estar en el entorno de lo que sea que lance la aplicación.
+
+| OS | Dónde colocarlo |
+|---|---|
+| macOS | `launchctl setenv CURSOR_LOCAL_AGENT_BASE_URL http://127.0.0.1:10100/v1` para la sesión de inicio de sesión actual, o un LaunchAgent con `EnvironmentVariables` para que sea persistente. Iniciar la aplicación desde un terminal también funciona. |
+| Windows | `setx CURSOR_LOCAL_AGENT_BASE_URL http://127.0.0.1:10100/v1` (alcance del usuario; afecta a nuevos procesos) o Propiedades del sistema → Variables de entorno. Reinicie la aplicación después. |
+| Linux | `~/.profile` o `~/.pam_environment` para una sesión de administrador de pantalla, o `systemctl --user set-environment CURSOR_LOCAL_AGENT_BASE_URL=http://127.0.0.1:10100/v1` cuando el escritorio se ejecuta bajo una sesión de usuario systemd. La AppImage lanzada desde un terminal hereda el entorno de ese shell. |
+
+La construcción existe para macOS (arm64, x64, universal), Windows (x64, arm64) y Linux (x64, arm64). La configuración es idéntica en todos ellos.
+
+<a id="from-the-dashboard"></a>
+
+## Desde el panel de control
+
+El panel de control opencodex tiene una pestaña **Cursor** en Integraciones (`/#integrations/cursor`). Es de solo lectura hacia Cursor: nunca escribe la base de datos de configuración de Cursor, la entrada de llavero o el paquete de aplicaciones, por lo que no hay ningún interruptor para cambiar. Lo que hace es entregarte los valores y mostrarte si los tomaron.
+
+- **Compilaciones instaladas.** Indica si están presentes Cursor Private Inference (con su ruta y versión) y el Cursor normal (solo la ruta). Si solo se encuentra el Cursor normal, la pestaña lo indica, enlaza aquí y ofrece un botón **Buscar el instalador de Private Inference**. Al pulsarlo, pregunta al propio canal de actualización de Cursor qué instalador de modo local anuncia para esta plataforma y CPU (el canal `cursor-local` en `api2.cursor.sh`) y muestra esa versión con un enlace al instalador `downloads.cursor.com/local-mode/`. No se solicita nada hasta que pulse el botón: abrir la pestaña y su actualización periódica nunca contactan con el canal de Cursor. opencodex solo muestra el enlace: nunca descarga, lanza ni instala nada. La respuesta se almacena en caché durante 30 minutos (5 después de un fallo). Cuando no se puede alcanzar el canal, responde con algo inutilizable o Cursor no publica ninguna compilación para este equipo (solo x64 y arm64 en Windows, macOS y Linux tienen una), la pestaña indica que el instalador no se pudo resolver; los valores de la puerta de enlace de abajo siguen siendo válidos en cualquier caso. El Cursor normal sigue enrutando los endpoints personalizados a través de los servidores de Cursor, por lo que no puede llegar a un proxy de loopback.
+- **Valores de entrada.** La URL base en el propio puerto de escucha del proxy (de su registro en entorno de ejecución, por lo que un panel de control con el proxy inverso aún muestra el puerto Cursor en esta máquina), con un botón Copiar. La fila de claves API depende de la vinculación: cuando no necesita credenciales, la fila es `opencodex-loopback` con Copiar; cuando está activada la autenticación API o cualquier tecla opencodex API está configurada, la fila le indica que use una de sus propias claves y enlaces a la pestaña Claves API. Cualquier tecla configurada funciona, no solo `OPENCODEX_API_AUTH_TOKEN`.
+- **Conexión.** La última solicitud `/v1/models` cuyo User-Agent es exactamente `Cursor/<version>` (el entorno de ejecución del agente local del encabezado Cursor envía), con el tiempo y la versión. Se lee "nunca visto" hasta que Cursor llama al proxy; presionar **Actualizar lista de modelos** en Cursor es lo que lo hace girar. La tarjeta se actualiza cada 15 segundos mientras la pestaña está abierta.
+- **Lo que mostrará el Cursor.** Una tabla Modelo / Razonamiento / Contexto para los modelos opencodex anuncia (se aplican modelos desactivados y listas de proveedores, al igual que la lista sin procesar), siguiendo las reglas en la siguiente sección. Es una predicción: Cursor escoge la escalera de Razonamiento de su propia tabla.
+
+<a id="models-and-reasoning-effort"></a>
+
+## Modelos y esfuerzo de razonamiento
+
+El selector es opencodex lista cruda `/v1/models`. Dos cosas deciden si una fila modelo obtiene un control **Razonamiento**:
+
+1. opencodex debe anunciar capacidades en la fila (`api_types` más un objeto `capabilities`). Lo hace, a partir de v2.41. Los proxies más antiguos muestran los modelos pero no controlan el esfuerzo.
+2. El ID del modelo, después de despojar todo hasta el último `/` y cualquier sufijo `@…`, debe coincidir con la tabla de esfuerzo propio de Cursor. Esa tabla está compilada en la aplicación (`extensions/cursor-agent-exec/dist/main.js`); opencodex lo lee desde la instalación detectada, por lo que la predicción del panel sigue a una actualización Cursor, y la tarjeta dice qué compilación leyó o "espejo estático" cuando no se encontró nada. Cursor decide la escalera, no opencodex, y no `/v1/models` campo puede añadir un modelo a esa tabla. La matriz a continuación es la instantánea 3.18.25 que lleva el espejo estático:
+
+| ID del modelo (después del último `/`) | Escalera Cursor espectáculos | Campo del protocolo |
+|---|---|---|
+| `gpt-5.6-sol`, `gpt-5.6-terra`, `gpt-5.6-luna` | Bajo, Medio, Alto, Extra Alto | `reasoning.effort` |
+| `gpt-5`, `gpt-5.x` | Bajo, Medio, Alto, Extra Alto | `reasoning.effort` |
+| `claude-opus-5`, `claude-sonnet-5`, `claude-opus-4.7`, `claude-opus-4.8` | Bajo, medio, alto, extra alto, máximo | `output_config.effort` |
+| `claude-opus-4.6`, `claude-opus-4.5`, `claude-sonnet-4.6` | Bajo, medio, alto, máximo | `output_config.effort` |
+| `grok-4.3`, `grok-4.5`, `grok-4.6`, `grok-build-latest` | Mínimo, bajo, medio, alto, extra alto | `reasoning_effort` |
+| `gemini-*` (necesita `supports_reasoning` ) | Mínimo, Bajo, Medio, Alto | `reasoning_effort` |
+| Cualquier otra cosa, incluyendo `claude-fable-5-1`, `kimi-k3` | sin control | — |
+
+Así que `anthropic/claude-opus-5` funciona, y los niveles `max`/`ultra` de opencodex para GPT-5.6 no son accesibles desde este selector.
+
+<a id="models-with-no-control"></a>
+
+### Modelos sin control
+
+`anthropic/claude-fable-5-1`, `cursor/kimi-k3` y cualquier otra cosa fuera de la tabla no obtienen ningún control de razonamiento, y Cursor registra una línea por cada id de ese tipo cuando la puerta de enlace anuncia `supports_reasoning`: "Local provider advertises reasoning support for a model with no hardcoded Bottlerocket effort family". Hay dos formas de elegir un esfuerzo:
+
+- **Filas de esfuerzo** (`cursorEffortRows: true` en la configuración de opencodex, desactivado de forma predeterminada): la puerta de enlace publica una entrada de selector por esfuerzo para los modelos sin tabla, como `anthropic/claude-fable-5-1--high` o `cursor/kimi-k3--max`, y encamina cada una al modelo base con ese esfuerzo aplicado. Los modelos que Cursor ya representa no obtienen filas adicionales, y un id de modelo conocido exacto siempre gana sobre el sufijo `--<effort>`. Pulse Actualizar lista de modelos después de activarla. La tarjeta del panel cuenta las filas que publicó por modelo. Elegir una fila es una elección explícita, por lo que su esfuerzo también prevalece sobre una directiva `ocx-effort` en la solicitud.
+- **Un valor predeterminado fijo** (`modelDefaultReasoningEfforts` en el proveedor): se aplica cuando Cursor no envía ningún esfuerzo.
+
+<a id="max-is-two-different-things"></a>
+
+### "Max" es dos cosas diferentes
+
+El Cursor normal muestra un interruptor **Max** junto a algunos modelos. Ese es el modo Max, una ventana de contexto más grande, no un nivel de razonamiento. En la compilación del agente local la misma idea aparece como una entrada **Contexto** en el menú del modelo, y opencodex la habilita para la familia nativa GPT-5.6: **272K** (predeterminado) o **922K** (la opción de 1M, marcada como más costosa). El valor que elija limita el contexto de ese turno. Los modelos enrutados muestran una sola ventana y ninguna entrada Contexto; un límite de contexto del proveedor por debajo de 922K también elimina la entrada para las filas nativas.
+
+El **Max** de esfuerzo de razonamiento (los `max` / `ultra` de opencodex) es el otro significado, y ese no es alcanzable: Cursor toma la escalera de esfuerzo de su propia tabla en lugar de la de la puerta de enlace, y la entrada de GPT-5.6 se detiene en Extra High.
+
+Como opencodex anuncia `responses` en `api_types`, esta compilación envía los turnos del agente a `/v1/responses` con `reasoning.effort`, no a `/v1/chat/completions`.
+
+Esta elección de protocolo tiene un efecto secundario en las filas Claude: Cursor solo envía su esfuerzo de razonamiento mediante `output_config.effort` en Anthropic Messages. Por tanto, con una URL base `/v1`, la fila Claude seleccionada usa el esfuerzo predeterminado de su proveedor aunque muestre un control de esfuerzo. Con una URL base que termina en `/messages`, ocurre lo contrario: se envía el esfuerzo de Claude y se descarta el de la familia OpenAI. Una sola entrada del gateway no puede servir a ambas familias; las filas de esfuerzo descritas arriba evitan esta limitación porque opencodex aplica el esfuerzo directamente.
+
+<a id="verify"></a>
+
+## Verificar
+
+`ocx observe logs` muestra los giros como `inboundProtocol: responses` con `admissionKind: loopback`.
+
+| Síntoma | Comprobar |
+|---|---|
+| 401 desde la puerta de enlace | la credencial no coincide con un token de datos o una clave de cliente aceptados; use una clave autorizada. El marcador de posición solo sirve en loopback cuando la configuración admite solicitudes sin autenticación de datos |
+| El selector está vacío | opencodex no se está ejecutando, o falta la URL base `/v1`; presione Actualizar lista de modelos después de la fijación |
+| modelos enumerados pero sin control de razonamiento | opencodex más antiguo que v2.41, o el id no está en la tabla de Cursor (el panel lo marca - ); encienda `cursorEffortRows` o configure un proveedor predeterminado |
+| No se recoge un cambio de esquema | Cursor cachés `/models` por cadena de URL base sin caducidad; La lista de modelos de actualización la vuelve a leer, de lo contrario, reinicia la aplicación o guarda temporalmente una ortografía diferente de la URL (`localhost` vs `127.0.0.1`) |
+| 23k-token primera vuelta | esperado; esto es el aviso del sistema local de Cursor |
diff --git a/docs-site/src/content/docs/es/guides/custom-gateway.md b/docs-site/src/content/docs/es/guides/custom-gateway.md
new file mode 100644
index 00000000000..24252e0ed5c
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/custom-gateway.md
@@ -0,0 +1,48 @@
+---
+title: Verificar una puerta de enlace remota personalizada
+description: Comprueba una puerta de enlace de Chat Completions desde el descubrimiento hasta una respuesta acotada.
+---
+
+Antes de registrar una puerta de enlace, pide a su operador la URL base autorizada de Chat Completions, la clave API y los identificadores de modelos admitidos. Por ejemplo, `https://api.example.com/v1` es un marcador de posición, no un endpoint funcional. Inicia el proxy si aún no está ejecutándose y selecciona **Personalizado** en el dashboard, usa el nombre `my-gateway`, selecciona `openai-chat` e introduce la URL y la clave autorizadas en el formulario. Guarda sin poner la clave en comandos o ejemplos compartidos. Que se guarde el proveedor no demuestra que funcionen el descubrimiento ni la inferencia.
+
+En un Child de [Remote Link](/es/guides/remote-link/), los proveedores proceden del Home: el dashboard del Child rechaza sus modificaciones y sus solicitudes usan los proveedores del Home. Registra y verifica allí la puerta de enlace.
+
+Comprueba cada etapa por separado, usando el puerto local configurado si difiere del predeterminado:
+
+```sh
+curl -fsS http://127.0.0.1:10100/healthz
+ocx ready
+ocx provider test my-gateway
+ocx models live --provider my-gateway --json
+```
+
+La salud y la disponibilidad describen el proxy; no demuestran que el proveedor pueda generar texto. La prueba del proveedor sin `--model` comprueba el descubrimiento, no la inferencia. `applicable: false` puede indicar que un catálogo estático carece de endpoint de descubrimiento; no equivale a una inferencia correcta. Una lista pública de modelos tampoco tiene por qué validar la clave. Si el descubrimiento falla o no aparece ningún modelo, comprueba la URL, las credenciales, el acceso al proveedor y la configuración antes de seleccionar uno.
+
+Una puerta de enlace puede generar respuestas sin un endpoint de lista de modelos. Si su operador facilita un ID original admitido, configura `liveModels: false` y `models: ["vendor/model"]` en el proveedor existente, conservando sus demás campos y sustituyendo el ID del ejemplo por el recibido. Consulta los [catálogos estáticos](/es/reference/configuration/providers/#static-model-allowlists).
+
+Antes de editar directamente `config.json`, guarda tu trabajo y espera a que terminen las solicitudes activas: detener el proxy puede interrumpirlas. Deténlo mediante su propietario: cierra OpenCodex Desktop desde la bandeja, ejecuta `ocx service stop` si está instalado como servicio o `ocx stop` si no tiene supervisor. Confirma que está detenido, edita y guarda sin ejecutar otros procesos que escriban configuración. Inícialo mediante el mismo propietario: abre Desktop, ejecuta `ocx service start` o el comando original `ocx start` con sus opciones, incluido `--port` si se indicó. Si lo inicias en primer plano, déjalo en esa terminal y ejecuta `ocx sync` y las comprobaciones restantes desde otra. Después vuelve a inspeccionar el catálogo en vivo. También puedes probar directamente el ID original con el comando de respuesta con confirmación de coste que aparece más abajo; esa prueba no necesita una fila del catálogo.
+
+En el catálogo en vivo, inspecciona los campos reales `id`, `namespaced`, `disabled` e `initialSelectionPending`. La selección inicial puede dejar modelos desactivados o pendientes; consulta la [selección inicial de modelos](/es/reference/configuration/providers/#initial-model-selection). Resuélvela antes de activar una fila. Para los comandos de visibilidad, combina el nombre del proveedor con el **`id` original** de la fila, conservando las barras de ese identificador:
+
+```sh
+ocx models enable 'my-gateway/<raw-upstream-id>'
+```
+
+Por ejemplo, el `id` original `vendor/model` requiere el selector `my-gateway/vendor/model`. El identificador `namespaced` visible para el cliente puede ser `my-gateway/vendor-model`; sustituir uno por otro puede dejar desactivada la entrada original. Activar un modelo no desactiva los demás. Si solo debe ser visible ese modelo de esta puerta de enlace, desactiva las demás filas activadas usando su `id` original en el mismo formato y vuelve a inspeccionar la lista:
+
+```sh
+ocx models disable 'my-gateway/<other-raw-upstream-id>'
+ocx models live --provider my-gateway --json
+```
+
+Comprueba que la fila deseada tenga `disabled: false` y las otras exclusiones previstas estén desactivadas. Un ID nativo sin calificador puede seleccionar otra ruta. Usa valores exactos, no nombres visibles o sufijos de razonamiento adivinados: un sufijo puede ser otro ID del proveedor, mientras que el esfuerzo es una opción aparte. Consulta los detalles en la [referencia de CLI](/es/reference/cli/providers-accounts/).
+
+Cuando sea necesario, ejecuta `ocx sync` para actualizar el catálogo del cliente y confirma que el modelo aparezca en el selector de Codex. Un cliente activo puede conservar una lista anterior en memoria. Guarda el trabajo y, si sigue desactualizado, cierra y abre Codex por completo. Como alternativa, con aprobación explícita, usa [`ocx system codex-restart --yes`](/es/reference/cli/agents/): puede interrumpir la sesión y descartar borradores, selecciones o solicitudes de aprobación sin guardar. Fuera de la edición directa de configuración anterior, reiniciar el cliente o el proxy no es el paso de recuperación predeterminado.
+
+Para verificar una respuesta real en una configuración remota con autenticación por clave admitida, pasa el **`id` original del proveedor** que figure en la fila o te dé el operador, sin añadir el prefijo del proveedor:
+
+```sh
+ocx provider test my-gateway --model '<raw-upstream-id>'
+```
+
+Esto envía una solicitud acotada, consume cuota y puede generar cargos. Acepta la pregunta, cuyo valor predeterminado es No, solo después de aprobar el coste; en modo no interactivo o JSON se exige `--yes`. Un resultado `applicable: false` no envía una solicitud de generación y no es una prueba superada, aunque el comando termine con cero. Antes de dar por válida una respuesta correcta, comprueba que el modelo transmitido sea el ID original previsto; un alias puede resolver a otro. En JSON aparece como `wireModel`. Una respuesta de texto correcta no demuestra las llamadas a herramientas, la salida estructurada, la continuación ni la identidad real del modelo; la identidad informada por el proveedor es un metadato. Para problemas de compatibilidad posteriores, reproduce por separado el protocolo afectado con datos saneados.
diff --git a/docs-site/src/content/docs/es/guides/desktop-app.md b/docs-site/src/content/docs/es/guides/desktop-app.md
new file mode 100644
index 00000000000..45ce0609310
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/desktop-app.md
@@ -0,0 +1,203 @@
+---
+title: "Aplicación de escritorio"
+description: "Instala y usa OpenCodex Desktop en macOS, Windows y Linux."
+---
+
+OpenCodex Desktop combina una bandeja nativa con el dashboard web. Su CLI incluida busca un proxy local existente; la aplicación solo inicia su propio entorno de ejecución cuando confirma que no hay ninguno.
+
+El dashboard se sirve desde la dirección del proxy local encontrado (puerto `10100` de forma predeterminada). La aplicación de escritorio integra ese dashboard y su entorno de ejecución.
+
+<a id="install"></a>
+
+## Instalar
+
+### macOS
+
+Descarga `OpenCodex-<version>-macos.dmg` desde la [última versión](https://github.com/lidge-jun/opencodex/releases). Abre el DMG y arrastra `OpenCodex.app` a Aplicaciones. Se requiere macOS 13 o posterior.
+
+Las versiones publicadas de `OpenCodex.app` tienen firma de Developer ID y certificación de Apple. Al abrirlas por primera vez, macOS normalmente solo pide la confirmación habitual para una aplicación descargada. Si sigue bloqueándola, usa **Configuración del Sistema → Privacidad y seguridad → Abrir de todos modos**.
+
+#### Homebrew, aplicación de escritorio
+
+Instala el Cask con:
+
+```bash
+brew install --cask opencodex
+```
+
+- **Actualizaciones internas (`auto_updates`)**: el Cask declara `auto_updates true`. `brew upgrade --cask opencodex` o una actualización greedy aún puede reemplazar una aplicación más nueva actualizada internamente; comprueba ambas versiones.
+- **CLI y servicio**: instala solo la aplicación y su CLI/proxy. Una CLI separada npm o de archivo comparte `~/.opencodex`. Para darle el servicio, cierra Desktop, selecciona esa CLI explícitamente, omitiendo el handoff si procede, y ejecuta `ocx service install`. Consulta [selección de terminal](/es/guides/desktop-app/#using-the-ocx-cli-with-the-desktop-app) y [propiedad](/es/reference/cli/lifecycle/#runtime-ownership).
+- **Tras actualizar Cask**: puede eliminar el trabajo/plist `com.opencodex.proxy`, incluso de la CLI separada. Cierra Desktop y, en sesión gráfica macOS, comprueba con esa CLI `ocx service status`; si falta, instala, y si no está cargado, `ocx service repair`. Vuelve a comprobar. Instalar toma el puerto de `OCX_BAKE_PORT` o `config.port`, no del trabajo eliminado: actualiza clientes si cambió. También elimina el trabajo de inicio `OpenCodex`: reactívalo en el menú si lo usas.
+- **Borrado con `--zap`**: `brew uninstall --zap --cask opencodex` elimina `~/.opencodex` y `~/.opencodex-desktop`, configuración y estado compartidos. Respalda antes. Casks anteriores a 2.97.0 no incluían esos directorios y Homebrew puede usar la definición de instalación; comprueba qué queda antes de quitarlo manualmente.
+
+
+### Windows
+
+Descarga `OpenCodex-<version>-windows-x64.msi` y ejecuta el instalador. La firma de código a través de SignPath Foundation se está incorporando ([firma de código en Windows](/es/reference/code-signing/)). Hasta que una versión incluya esa firma, Windows SmartScreen puede advertir que el instalador no está firmado. Elige **Más información → Ejecutar de todas formas** después de confirmar que lo descargaste de la página de versiones.
+
+El instalador Windows resume el uso diario anónimo, enlaza la [privacidad](/es/reference/code-signing/#privacy) y muestra marcada **Enviar estadísticas anónimas de uso**. Desmárcala para guardar el rechazo al primer arranque de cada cuenta, antes del proxy. Es de todo el equipo, también en despliegues de administrador. Para instalación silenciosa:
+
+```powershell
+msiexec /i OpenCodex-<version>-windows-x64.msi /qn OCX_TELEMETRY_CHOICE=optout
+```
+
+Requiere administrador. Solo `send` conserva la opción; `optout`, sin distinguir mayúsculas, y otros valores como `off` o `0` la desactivan. Pasar `OCX_TELEMETRY_CHOICE` registra una decisión nueva: repetirlo en cada actualización vuelve a aplicar el rechazo sobre una decisión posterior del dashboard. La casilla marcada no inicia envíos ni reactiva una cuenta que los rechazó: aún exige el aviso. Actualizaciones internas, modo `/qr` y mantenimiento conservan la elección. Un instalador posterior sin cambiar la casilla no la reaplica sobre el dashboard. Un servicio puede iniciar sin Desktop; una decisión nueva lo alcanza al abrir la aplicación. Usa `ocx telemetry disable` para detener el envío de inmediato.
+
+### Linux
+
+Descarga `OpenCodex-<version>-linux-x86_64.AppImage` o `OpenCodex-<version>-linux-amd64.deb` desde la página de versiones.
+
+Para AppImage:
+
+```bash
+chmod +x OpenCodex-<version>-linux-x86_64.AppImage
+./OpenCodex-<version>-linux-x86_64.AppImage
+```
+
+Para distribuciones basadas en Debian:
+
+```bash
+sudo apt install ./OpenCodex-<version>-linux-amd64.deb
+```
+
+El icono de la bandeja requiere un entorno de escritorio compatible con AppIndicator.
+
+<a id="first-launch"></a>
+
+## Primer inicio
+
+La aplicación ejecuta `ocx resolve --json` con su CLI incluida y se conecta al proxy local si ya hay uno accesible. Solo inicia su propio entorno de ejecución cuando la CLI confirma que no existe otro; un resultado incierto se muestra como un fallo de inicio. Después abre el dashboard en su vista web, usando la dirección de bucle local encontrada. Si se inicia oculta en la bandeja al abrir sesión, conserva la página ligera de arranque y carga el dashboard cuando lo abres desde la bandeja o vuelves a iniciar la aplicación.
+
+Usa **Open dashboard** (abrir dashboard) u **Open in browser** (abrir en el navegador) en la bandeja para alternar entre el dashboard integrado y tu navegador habitual. La bandeja también permite buscar actualizaciones.
+
+En Windows, aceptar **Take over** (tomar el control) permite hasta 90 segundos para detener de forma segura el entorno de ejecución existente, transferir su control e iniciar el que incluye la aplicación. El tiempo que tardes en decidir no cuenta para ese límite. Mantén la aplicación abierta mientras termina; si falla, usa **Retry** (reintentar) para volver a buscar el entorno de ejecución actual.
+
+En macOS, cerrar el dashboard mantiene la aplicación en la barra de menús. Vuelve a abrir OpenCodex desde el Dock o Finder para recuperar el dashboard sin reiniciar el proxy.
+
+En Windows, **Start at Login** (iniciar al abrir sesión) registra la ruta del ejecutable entre comillas para el usuario actual, incluidas las instalaciones en `Program Files`. Los registros habilitados se actualizan una vez al iniciar la aplicación. Las entradas que hayas deshabilitado desde la bandeja o el Administrador de tareas permanecen deshabilitadas.
+
+<a id="using-the-ocx-cli-with-the-desktop-app"></a>
+
+## Usar la CLI ocx con Desktop
+
+Las instalaciones estables de macOS, Windows y del paquete deb de Linux configuran automáticamente el comando `ocx` incluido para las terminales nuevas al iniciar Desktop. Abre **Comando de terminal**, junto a **Actualización de Desktop** en la barra lateral del dashboard, o **Terminal command…** en la bandeja, para desactivarlo, repararlo o quitarlo. Desactivar **Usar el comando ocx de Desktop en las terminales nuevas** elimina la configuración administrada. **Quitar comando de terminal** también conserva esa opción desactivada para los próximos inicios. AppImage y los inicios en desarrollo no realizan esta configuración.
+
+macOS y Linux usan un shim en `~/.opencodex-desktop/bin`, el archivo auxiliar compartido `path.sh` y bloques administrados en los archivos de inicio de zsh, bash y fish. Desktop registra la propiedad y los datos de recuperación en `~/.opencodex-desktop/cli.json`; borrar ese registro no elimina el comando ni sus bloques de shell. El archivo `/usr/bin/ocx` del paquete deb no cambia. Windows añade el directorio de instalación al principio del `Path` del usuario y conserva las demás entradas. Un comando del `Path` del sistema puede seguir teniendo prioridad; Desktop informa de ese conflicto como configuración parcial y no modifica el `Path` del sistema.
+
+Después de habilitar o reparar el comando, abre una terminal nueva. Comprueba `type -a ocx` en macOS/Linux, o `Get-Command ocx -All` y `where.exe ocx` en Windows. Las terminales ya abiertas, los alias, las rutas absolutas y los cambios posteriores de PATH todavía pueden seleccionar otro ejecutable. La configuración persiste después de cerrar Desktop. Si falta el paquete de la aplicación, el shim POSIX falla con instrucciones para repararlo o quitarlo, en lugar de seleccionar otro `ocx` sin avisar.
+
+En POSIX, el shim conserva las opciones de Anthropic exportadas por la shell cuando dispone de las herramientas de verificación del inicio. Si esa verificación falla, o si se ejecuta directamente en Windows, la CLI incluida sigue eliminando las opciones de entorno de Anthropic que no sean de confianza.
+
+En macOS, Linux y Windows, `ocx status` y `ocx doctor` identifican OpenCodex Desktop cuando verifican que la aplicación ejecuta su proxy incluido, incluso si no existe un registro de propiedad. `ocx status` muestra `Runtime supervisor: OpenCodex Desktop`; ninguno de los dos comandos recomienda reparar un servicio de CLI para ese entorno. En macOS y Linux, activa **Start at Login** en el menú de OpenCodex en lugar de instalar un servicio en segundo plano. La protección del inicio solo reconoce a la aplicación cuando verifica su registro de inicio de sesión; si no puede verificarlo, sigue las indicaciones de Desktop que muestra el estado.
+
+La página de inicio muestra entonces **En ejecución · Inicio de sesión no verificado** en la fila de Desktop. En macOS, **Start at Login** solo aparece marcado cuando se puede verificar ese mismo registro. En caso contrario, queda sin marcar y explica la causa:
+
+- **disabled by macOS** abre Configuración del Sistema → General → Ítems de inicio y extensiones, donde puedes permitir que OpenCodex se abra al iniciar sesión.
+- **another OpenCodex copy** indica que el registro pertenece a otra copia de la aplicación; desactívalo desde esa copia.
+- **registered app is missing** indica que la aplicación registrada ya no existe; elimina `~/Library/LaunchAgents/OpenCodex.plist` y vuelve a activar la opción.
+- **status unknown** indica que no se pudo leer el registro.
+
+Mientras la aplicación ejecute el proxy, el instalador del servicio en segundo plano permanece deshabilitado en la página de inicio. Para usar ese servicio, cierra OpenCodex y ejecuta `ocx service install` en una terminal. El shim de inicio de Codex sí se puede instalar desde esa página.
+
+Si al iniciar Codex no hay un proxy, la CLI incluida espera a que Desktop lo recupere cuando puede verificar esa recuperación de forma independiente, incluso sin una declaración de propiedad registrada. Si la instancia de Desktop correspondiente ha detenido su proxy, o no se puede verificar su recuperación, informa de un error. Hay una excepción: en una plataforma sin verificación del ejecutable activo, si existe una declaración de propiedad y la aplicación sigue abierta, conserva la espera con límite de tiempo que ya utilizaba. Un nombre de proceso o un archivo localizador por sí solos no bloquean el inicio normal de la CLI. En macOS, el shim abre OpenCodex si estaba cerrado y su propiedad registrada coincide con un registro válido de **Start at Login**. La reapertura automática usa la ruta de la aplicación de ese registro y comprueba que su ejecutable principal coincida con el ejecutable de Desktop registrado. Si el registro falta, está desactualizado o es incoherente, abre OpenCodex manualmente; no se elige otra copia con el mismo identificador como alternativa. Si el shim muestra "activation not confirmed", añade `. ~/.opencodex/codex-shell-env.sh` al archivo de inicio de tu shell después de las demás opciones de PATH.
+
+La verificación de recuperación abarca la CLI incluida correspondiente en macOS/Linux y la instalación Debian protegida del sistema. Un shim antiguo creado por npm puede seguir apuntando a una instalación separada de Bun/CLI y omitir la transferencia al comando de terminal de Desktop. Ese punto de entrada no puede verificar una instancia de Desktop en macOS o Windows, ni siquiera una copia oficial firmada, ni una copia arbitraria de Linux instalada por el usuario. Vuelve a crear el shim desde la página de inicio de Desktop o ejecuta su CLI incluida. Windows todavía no puede establecer la identidad del ejecutable activo que exige esta prueba de recuperación. Identificar un proceso de Desktop correspondiente en ejecución no demuestra que pueda recuperar el proxy: sin una declaración de propiedad registrada, la CLI informa de un error en lugar de iniciar su propio proxy, aunque las firmas de los archivos en disco sean válidas. Si existe esa declaración y la aplicación sigue abierta, conserva la espera con límite de tiempo para que Desktop recupere su proxy.
+
+La CLI incluida está en `/Applications/OpenCodex.app/Contents/MacOS/ocx` en macOS y en `/usr/bin/ocx` para el paquete deb de Linux. Ejecuta ese archivo con `status` para comprobar el proxy de la aplicación. Windows verifica la supervisión activa cuando el proceso hijo del proxy ya está en ejecución, pero allí **Start at Login** permanece sin verificar y Desktop no se considera una protección del inicio.
+
+Mientras la CLI detecte que Desktop supervisa el proxy, `ocx service install`, `repair`, `start` y `restart` se rechazan antes de modificar el servicio, incluso sin propiedad registrada o sin un inicio de sesión verificado. Cierra OpenCodex y ejecuta `ocx service install` para transferir la gestión del inicio a la CLI. Un `ocx start` duplicado identifica a Desktop como supervisor.
+
+Usa **Check for Updates…** en la bandeja para actualizar la aplicación. La CLI compilada incluida informa `installer: "standalone"` y `reason: "standalone_install"` mediante `ocx system update check`, con `canUpdate: false` e instrucciones para usar las actualizaciones de Desktop. `ocx update` rechaza reemplazar el paquete mientras Desktop supervise el proxy, incluso si se trata de otra instalación de npm/Bun; cierra OpenCodex antes de actualizar esa instalación. Si se acepta `ocx restart`, informa de que Desktop iniciará el reemplazo y espera a que esté disponible. Una CLI más reciente del PATH no puede usar `ocx restart` para reemplazar el proxy de la aplicación por su propio entorno de ejecución.
+
+El comando de terminal `ocx stop` detiene el proxy, pero Desktop puede volver a iniciarlo tras una espera breve. Usa **Stop proxy** o **Quit** en la bandeja para mantenerlo detenido. La salida habitual de `stop` recuerda esto por stderr; `ocx stop --json` omite tanto la comprobación de supervisión como ese aviso.
+
+Estas protecciones son avisos preventivos de las CLI y los entornos de ejecución actuales; las versiones anteriores pueden carecer de ellos. Una comprobación que detecte Desktop pero no termine de verificarlo también bloquea la operación. Una vez bloqueada, otra comprobación inconclusa no elimina el bloqueo: es necesario confirmar que Desktop ya no supervisa el proxy. Si nunca se detectó Desktop, una comprobación inconclusa o incompatible mantiene el comportamiento previo del comando. Las protecciones basadas en la propiedad registrada se aplican de forma independiente.
+
+<a id="startup-safety-on-macos-and-linux"></a>
+
+## Protección del inicio en macOS y Linux
+
+La protección del inicio reconoce **Aplicación de escritorio** cuando un diagnóstico reciente verifica que la aplicación supervisa su proxy incluido y confirma el registro de **Start at Login** de esa misma aplicación. La propiedad registrada se conserva por separado; detectar supervisión no crea una declaración de propiedad.
+
+En Linux, el componente de inicio automático escribe la entrada en `~/.config/autostart/OpenCodex.desktop`, incluso si se definió `$XDG_CONFIG_HOME`. La protección del inicio lee esa entrada y el identificador de instalación bajo `~/.config`. Si `$XDG_CONFIG_HOME` apunta a otro lugar, la sesión busca un directorio distinto de inicio automático; por eso no se reconoce esa entrada como protección de reinicio.
+
+La entrada solo cuenta si no tiene `Hidden=true` ni `X-GNOME-Autostart-enabled=false`, y tampoco condiciones `OnlyShowIn`, `NotShowIn` o `TryExec`. Su campo `Exec` debe contener una ruta absoluta a `opencodex-desktop` sin comillas, espacios, escapes ni códigos de campo, seguida exactamente por `--autostart`. El ejecutable resuelto debe seguir llamándose `opencodex-desktop` y tener el `ocx` incluido a su lado. La protección del inicio lee dos veces toda la cadena de evidencias y solo reconoce la protección cuando ambas lecturas coinciden.
+
+Las instalaciones AppImage no reciben protección Desktop verificada: el inicio automático registra la ruta del archivo AppImage externo, mientras el proceso de Desktop se ejecuta dentro de su punto de montaje. Esa relación no se puede verificar y no se reconoce como protección.
+
+Una comprobación ausente o desactualizada no acredita protección de reinicio. Si Desktop posee o supervisa el proxy, se muestra una nota informativa y se pide comprobar **Start at Login** en el menú. La instalación o reparación del servicio permanece deshabilitada mientras exista esa propiedad. El lanzador Codex sí puede instalarse con diagnósticos recientes, pero no si están desactualizados. En Linux sin bandeja, inspecciona `~/.config/autostart/OpenCodex.desktop` y las condiciones anteriores. `ocx restore` permite deshacer el enrutamiento de Codex.
+
+Las actualizaciones normales de Desktop reemplazan la CLI incluida por la versión con la comprobación de inicio corregida. No necesitas conservar un parche local entre actualizaciones.
+
+## Zoom
+
+En macOS y Linux, Cmd (macOS) o Ctrl (Linux) con `+`, `-` y `0`, o Ctrl con la rueda del ratón, cambia el zoom entre el 50 % y el 300 % en pasos del 10 %. `0` vuelve al 100 %. La barra lateral muestra ese mismo nivel junto al selector de tema: `-`, el porcentaje actual y `+`. Pulsar el porcentaje restablece el 100 %. El nivel se guarda y se vuelve a aplicar al iniciar la aplicación.
+
+El dashboard procede del proxy al que se conecta la aplicación. Si ese proxy es antiguo, conserva el comportamiento anterior (pasos del 20 %, sin guardar el nivel ni mostrar controles en la barra lateral) hasta que se actualice el proxy. Windows usa el zoom propio del motor del navegador, que no se guarda.
+
+<a id="keeping-the-proxy-running"></a>
+
+## Mantener el proxy en ejecución
+
+La aplicación mantiene en ejecución el proxy que inició. Si ese proxy se reinicia a sí mismo —después de **Conectar como Child**, de reiniciar la memoria desde el dashboard o de desconectar un Child— la aplicación inicia el nuevo proxy en el mismo puerto y recarga el dashboard abierto. Suele tardar alrededor de un segundo, o algunos segundos si ya se había reiniciado en los dos minutos anteriores. Así, **Stop proxy** sigue alcanzando al proxy y **Quit** también lo termina.
+
+Si el proxy termina sin que se le haya pedido (por un fallo o por `ocx stop` desde una terminal), la aplicación vuelve a iniciarlo tras una espera que aumenta de 3 a 30 segundos mientras sigan los fallos. Si deja de responder en su puerto, la aplicación lo detecta en unos 15 segundos y se recupera del mismo modo. Para un proxy que no inició ella (por ejemplo, un servicio en segundo plano o uno iniciado manualmente), primero espera aproximadamente un minuto a que vuelva.
+
+Durante la recuperación, la aplicación no detiene ni reemplaza un proxy que otro proceso ya ejecute en ese puerto: se conecta a él sin pedir tomar su control. Esto incluye el proxy de un Child que un servicio haya reiniciado después de **Conectar como Child**; la aplicación se conecta y muestra el dashboard del Child. Si el puerto lo ocupa algo que no puede utilizar, como un proxy vinculado a otra dirección distinta de `127.0.0.1`, deja de reintentar y espera a que eso cambie. Si la recuperación termina mientras está abierta la página de actualización, esa página permanece visible.
+
+**Stop proxy** y **Quit** en la bandeja mantienen el proxy detenido. El botón **Detener** del dashboard no detiene un proxy ejecutado por la aplicación, porque esta volvería a iniciarlo: muestra la explicación y no cambia nada. Las decisiones y sus motivos se registran en `runtime-supervisor.log`, dentro del directorio de registros de la aplicación (`~/Library/Logs/com.opencodex.desktop` en macOS).
+
+<a id="usage-in-the-tray"></a>
+
+## Uso en la bandeja
+
+En macOS y Windows, pulsa el icono de la bandeja para abrir una ventana compacta de uso. **Show usage** también la abre, incluidos los escritorios Linux cuya bandeja no transmite los clics. En Linux, el dashboard se abre al iniciar, incluso cuando el entorno de escritorio no muestra un icono de bandeja.
+
+La ventana muestra los totales de hoy y de 30 días, el gráfico de uso configurado, una lista compacta de modelos y los límites por proveedor o cuenta. Junto a las barras aparecen las cuentas regresivas de restablecimiento de cuota; pasa el puntero para ver la hora exacta. Las opciones de **Barra de menús y widget** controlan las secciones y el gráfico visibles. Los proveedores ocultos se excluyen del título, los totales, las cuotas y el gráfico.
+
+El gráfico incluye la actividad del intervalo actual. Un indicador de datos parciales significa que algunos datos no se pueden atribuir con fiabilidad. La ausencia de mediciones no se representa como uso cero. En Windows y Linux, desplázate dentro de la ventana para llegar a Actualizar y Dashboard al final de una lista larga de cuentas.
+
+En macOS, la ventana usa controles nativos SwiftUI y un panel AppKit desplazable. Se usa Liquid Glass de Apple en macOS 26 o posterior; los sistemas anteriores usan el material nativo de los paneles emergentes. El encabezado y los botones Actualizar y Dashboard permanecen visibles al desplazarse por listas largas de cuentas. También puedes abrir la ventana con **View → Show Usage** (Comando-Mayús-U). Pulsa Escape o haz clic fuera para cerrarla.
+
+El menú de la bandeja muestra las solicitudes y los tokens de hoy, con el costo estimado si está habilitado. Usa el mismo día local que el widget. Elige **Refresh now** para actualizar inmediatamente; la aplicación también actualiza los datos cada 60 segundos. Las preferencias de visualización están en **Barra de menús y widget** del dashboard. Desactivar **Hoy** oculta el resumen y desactivar **Costo** quita el costo del resumen.
+
+El uso no disponible o expresamente no medido se muestra como `—`, en lugar de como un cero medido. Elegir el encabezado de solo icono elimina el contador anterior. Las abreviaturas conservan los ceros enteros: diez millones de tokens son `10M`, no `1M`.
+
+<a id="updates"></a>
+
+## Actualizaciones
+
+Elige **Check for Updates…** en la bandeja para buscar actualizaciones inmediatamente. Las versiones publicadas también las buscan después del inicio y cada seis horas.
+
+Cuando el actualizador de Tauri encuentra una versión más reciente, aparece un punto azul en el icono de la barra de menús de macOS o en la bandeja de Windows/Linux, cuando esta está disponible. El dashboard integrado muestra la misma señal de actualización de Desktop. Un navegador conectado al mismo proxy sigue mostrando el estado de actualización del paquete del proxy. Si la aplicación deja de informar durante unos tres minutos, el indicador integrado pasa a estado desconocido hasta que se reconecta. El punto indica disponibilidad; la instalación sigue requiriendo una acción explícita.
+
+En Desktop, pulsa el botón de actualización del dashboard para abrir la página de actualización de la aplicación. Allí puedes buscar de nuevo, instalar una actualización firmada pendiente o volver al dashboard. La misma instalación está disponible desde la bandeja. Si falla, la actualización sigue disponible para reintentar. La aplicación también recupera el proxy que detuvo para instalarla, de modo que Codex no se quede sin proxy por una actualización fallida. Esta página funciona también en Linux sin icono de bandeja. El dashboard de un navegador normal administra, en cambio, la instalación del paquete de ese proxy.
+
+Antes de instalar, las actualizaciones se verifican con la clave pública del actualizador firmado del proyecto. En macOS, las actualizaciones desde la aplicación descargan `OpenCodex-<version>-macos.app.tar.gz`; el DMG se usa para la primera instalación. El manifiesto de publicación solo se genera cuando está configurado el secreto de la clave del actualizador y exige entonces que las cuatro plataformas tengan firma.
+
+## Widget
+
+La aplicación macOS incluye la extensión WidgetKit de OpenCodex. Consulta la [guía de la aplicación de barra de menús de macOS](/es/guides/macos-menu-bar/) para configurar el widget y conocer los detalles de las instantáneas locales.
+
+<a id="uninstall"></a>
+
+## Desinstalar
+
+Antes de desinstalar una versión de Desktop compatible, abre **Comando de terminal** en el dashboard o **Terminal command…** en la bandeja y elige **Quitar comando de terminal**. Desktop solo elimina su configuración administrada que no haya sido modificada. Los bloques o archivos modificados se conservan y se notifican; resuelve esos problemas antes de borrar la aplicación. Desinstalar directamente no garantiza que se limpien los archivos de shell o el `Path` del usuario.
+
+En macOS, arrastra `OpenCodex.app` desde Aplicaciones a la Papelera. En Windows, quita OpenCodex desde **Aplicaciones instaladas**. En sistemas Linux basados en Debian, ejecuta:
+
+```bash
+sudo apt remove opencodex
+```
+
+Para AppImage, elimina el archivo descargado.
+
+Si no se puede leer la configuración guardada de la barra de menús, se rechazan las ediciones parciales para conservar el archivo. Restáuralo o restablece expresamente la configuración del complemento antes de editar de nuevo.
+
+
+La comprobación de Arranque solo marca completo el inicio automático si verifica registro y proxy servido por Desktop. Un registro ausente, obsoleto, Linux con XDG distinto o AppImage no reciben protección comprobada. Revisa el menú de Desktop o `~/.config/autostart/OpenCodex.desktop` sin bandeja. Mientras Desktop supervise, no se instala/repara un servicio; el shim puede instalarse con diagnósticos recientes y `ocx restore` sigue disponible. La palanca de parada del dashboard no detiene un proxy de Desktop: informa y no cambia nada; usa **Detener proxy** o **Salir** en la bandeja.
+
+Antes de desinstalar, quita el comando de terminal. En macOS/Linux un registro Desktop habilitado con ejecutable ausente bloquea launchers npm/pnpm, sin fallback silencioso. `OCX_NO_DESKTOP_HANDOFF=1` permite una invocación explícita del paquete sin reparar registro, shim o PATH.
+
+Para un despliegue sin interfaz, `OCX_TELEMETRY_CHOICE=optout` registra la exclusión para todo el equipo. Consulta arriba cuándo una nueva instalación vuelve a aplicar esa decisión.
diff --git a/docs-site/src/content/docs/es/guides/factory-droid.md b/docs-site/src/content/docs/es/guides/factory-droid.md
new file mode 100644
index 00000000000..593705b1a50
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/factory-droid.md
@@ -0,0 +1,158 @@
+---
+title: "Puente Factory Droid"
+description: "Conecte los modelos Factory Droid a opencodex a través de un puente local compatible con Responses."
+---
+
+Factory Droid es un entorno de ejecución del agente, no un punto final de inferencia compatible con OpenAI documentado. Si un proveedor personalizado apunta a una URL interna de Factory LLM devuelve `403 Forbidden`, cambiar solo el adaptador opencodex o agregar encabezados de proveedor no convierte esa ruta privada en una API pública admitida.
+
+La integración de trabajo es:
+
+```text
+Text-only Responses client
+  -> opencodex (http://127.0.0.1:10100/v1/responses)
+  -> local Responses bridge (http://127.0.0.1:11435/v1/responses)
+  -> official droid exec command
+  -> Factory account and selected model
+```
+
+Esto mantiene la credencial de fábrica dentro del cliente oficial Droid. OpenCodex recibe un token de puente separado, solo local.
+
+<a id="what-failed-and-why"></a>
+
+## Qué falló y por qué
+
+| Síntoma | Causa | Arreglar |
+| --- | --- | --- |
+| `403 Forbidden` desde una URL de fábrica LLM | La URL no es un punto final OpenAI de propósito general documentado para clientes de terceros. | Invoque la fábrica a través de los oficiales Droid CLI o SDK |
+| `404` en `/models/models` | La URL base del proveedor ya terminó en `/models` | Utilice una raíz API como `baseUrl`; nunca incluya la ruta de descubrimiento |
+| La búsqueda de modelos falla | El puente no expone un catálogo completo en vivo | Establecer `liveModels: false` y proporcionar una lista estática `models` |
+| El proveedor de Loopback es rechazado | El acceso a la red privada se deniega de forma predeterminada | Establecer `allowPrivateNetwork: true` solo para el puente de bucle |
+| `${DROID_BRIDGE_TOKEN}` no está resuelto | La variable falta en el entorno de servicio opencodex | Inyéctelo en el proceso de servicio, no solo un shell interactivo |
+| `OutputTextDelta without active item` | El puente emitió un delta de texto antes de abrir un elemento de salida y una parte de contenido. | Emitir el ciclo de vida completo Responses SSE en orden |
+
+Por lo tanto, la misma credencial de Factory puede funcionar en `droid exec`, mientras que una solicitud directa a una URL LLM indocumentada aún devuelve `403`. Estos resultados prueban diferentes productos y no deben ser tratados como contradictorios.
+
+<a id="prerequisites"></a>
+
+## Requisitos previos
+
+1. Instale e inicie sesión en el [Droid CLI](https://docs.factory.ai/droid-cli/quickstart).
+2. Confirme que una solicitud sin cabeza limitada funciona:
+
+   ```bash
+   droid exec --model glm-5.2 --output-format json "Reply with DROID_OK only."
+   ```
+
+3. Ejecute un puente local que invoque `droid exec` (o el oficial Droid SDK) y exponga:
+
+   - `GET /healthz`
+   - `GET /v1/models`
+   - `POST /v1/responses`
+
+Factory documenta `droid exec` como su superficie de automatización no interactiva y recomienda la salida JSON para scripts. Para una integración más duradera, Factory también documenta el stream JSON -RPC y los SDK oficiales de TypeScript y Python en el [Droid Guía ejecutiva](https://docs.factory.ai/droid-exec/overview).
+
+<a id="bridge-contract"></a>
+
+## Contrato de puente
+
+Antes de aceptar entradas, el puente debe escuchar únicamente en `127.0.0.1`, exigir un token bearer aleatorio, limitar el tamaño de las solicitudes y permitir solo los identificadores de modelo de una lista explícita. El puente mínimo acepta únicamente estas formas de `input` de Responses:
+
+- Una cadena no vacía; o
+- Una matriz formada exclusivamente por elementos `message`. Cada mensaje debe usar el rol `user`, `developer`, `system` o `assistant` y contener una cadena o partes solo de texto: `input_text` para los roles de entrada y `output_text` para el historial del asistente.
+
+Valida toda la solicitud antes de invocar Droid. Si una parte de entrada es una imagen o un archivo, `tools` contiene alguna definición de herramienta, o `input` incluye una llamada o resultado de herramienta (`function_call`, `function_call_output`, `custom_tool_call` o `custom_tool_call_output`), devuelve HTTP `400` con un `invalid_request_error` de formato Responses. Usa un código estable del puente, como `unsupported_bridge_input`, e identifica el campo rechazado. Rechaza la solicitud antes de iniciar SSE, incluso con `stream: true`; nunca descartes ni conviertas silenciosamente el contenido no compatible en texto del prompt.
+
+```json
+{
+  "error": {
+    "type": "invalid_request_error",
+    "code": "unsupported_bridge_input",
+    "param": "tools",
+    "message": "The minimal Droid bridge does not accept tool definitions."
+  }
+}
+```
+
+Para una solicitud aceptada, el puente debe:
+
+1. Convierta el Responses `input` aceptado en un mensaje.
+2. `droid exec --model <id> --output-format json <prompt>`.
+3. analizar los `result` y `session_id` finales;
+4. devolver un sobre OpenAI Responses; y
+5. mapear `previous_response_id` al ID de sesión Droid cuando se requiere continuación.
+
+Para las respuestas de transmisión, emita este ciclo de vida en orden:
+
+```text
+response.created
+response.output_item.added
+response.content_part.added
+response.output_text.delta
+response.output_text.done
+response.content_part.done
+response.output_item.done
+response.completed
+```
+
+No exponga el puente en `0.0.0.0` y no reutilice la credencial de fábrica como el token de portador de puente.
+
+<a id="opencodex-provider-configuration"></a>
+
+## Configuración del proveedor OpenCodex
+
+Cree el proveedor personalizado con el ID de proveedor explícito `droid`:
+
+```bash
+ocx provider add droid \
+  --adapter openai-responses \
+  --base-url http://127.0.0.1:11435/v1 \
+  --default-model glm-5.2 \
+  --allow-private-network
+```
+
+Esto crea la entrada de configuración `providers.droid`. En el panel de control, abra **Proveedores → droid → Editar JSON** y reemplace el valor de ese proveedor con:
+
+```json
+{
+  "adapter": "openai-responses",
+  "baseUrl": "http://127.0.0.1:11435/v1",
+  "responsesPath": "/responses",
+  "allowPrivateNetwork": true,
+  "authMode": "key",
+  "apiKey": "${DROID_BRIDGE_TOKEN}",
+  "liveModels": false,
+  "models": ["glm-5.2", "glm-5.2-fast", "kimi-k3"],
+  "defaultModel": "glm-5.2"
+}
+```
+
+Los ID de modelo son ejemplos. Mantenga solo los modelos que `droid exec` puede usar para la cuenta de Factory iniciada. No agregue cabeceras de inferencia específicas de Factory a este proveedor: su origen es el puente local, no un punto final de Factory HTTP.
+
+Después de guardar un proveedor o cambiar su catálogo estático, sincronice y reinicie Codex para que las nuevas sesiones lean el catálogo actualizado:
+
+```bash
+ocx sync --restart-codex
+ocx doctor
+```
+
+`--restart-codex` reinicia los servidores de aplicaciones y cierra y vuelve a lanzar completamente la aplicación de escritorio Codex, que finaliza las conversaciones en vivo. Use `--restart-app-server-only` para dejar la aplicación de escritorio en ejecución. Ejecute el reinicio solo después de terminar o guardar esas sesiones.
+
+<a id="verify-the-complete-route"></a>
+
+## Verificar la ruta completa
+
+Compruebe cada límite por separado:
+
+```bash
+curl -fsS http://127.0.0.1:11435/healthz
+ocx doctor
+ocx access test droid/glm-5.2 --protocol responses
+```
+
+Una fila de proveedores o una entrada de selector de modelos solo prueban la visibilidad del catálogo. La integración solo funciona después de que la sonda Responses regrese a través de la ruta `droid/<model>`.
+
+<a id="current-limitation"></a>
+
+## Limitación actual
+
+El puente mínimo anterior traduce texto y el ciclo de vida de Responses SSE. **No implementa** el protocolo bidireccional completo de herramientas y funciones de Codex. Codex App y `codex exec` suelen enviar definiciones de herramientas aunque el mensaje pida no llamarlas; la CLI actual de Codex no tiene una opción general para eliminarlas. El puente mínimo debe rechazar esas solicitudes con el contrato `400` anterior. Para admitir definiciones, llamadas y resultados de herramientas, permisos, cancelación y eventos avanzados de Droid, se necesita un puente con estado basado en el modo JSON-RPC en streaming de Factory o en un SDK oficial de Droid. El éxito de `ocx access test` verifica la ruta de texto; no certifica el funcionamiento de agentes ni herramientas de Codex.
diff --git a/docs-site/src/content/docs/es/guides/fallback-off.md b/docs-site/src/content/docs/es/guides/fallback-off.md
new file mode 100644
index 00000000000..a2cc0dfc1ca
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/fallback-off.md
@@ -0,0 +1,124 @@
+---
+title: "Desactivar el fallback"
+description: Desactiva el fallback de modelos o proveedores por alcance y consulta qué ocurre cuando un Remote Link Child no puede acceder a su Home.
+---
+
+OpenCodex puede atender una solicitud con otro modelo o proveedor si falla el elegido: un [combo](/es/guides/combos/) pasa al siguiente destino, un [perfil de enrutamiento](/es/guides/routing-profile-editor/) prueba el siguiente candidato, un subagente recorre su cadena de modelos alternativos y el bloqueo estricto de la cuenta principal puede usar su modelo alternativo configurado. Todos estos mecanismos están habilitados por defecto.
+
+Desactiva un tipo de fallback cuando prefieras recibir un error claro en lugar de una respuesta de un destino que no elegiste.
+
+<a id="what-counts-as-a-fallback"></a>
+
+## Qué se considera fallback
+
+Un fallback es un salto a un **modelo diferente** o un **proveedor diferente**:
+
+| Tipo | Ejemplo | Ajuste |
+|---|---|---|
+| Fallback de modelo | Falla `anthropic/claude-opus` y respondería `anthropic/claude-sonnet` | `model` |
+| Fallback de proveedor | Falla `anthropic/claude-opus` y respondería `openai/gpt-6-sol` | `provider` |
+
+La rotación entre cuentas o claves API de **un mismo pool de proveedor** para el mismo modelo no es fallback. Permite absorber el límite de tasa de una cuenta y sigue funcionando con cualquier ajuste de esta página. Tampoco se consideran fallback los reintentos al mismo destino ni los cambios de transporte que conservan ese destino.
+
+Cuando el bloqueo estricto de la cuenta principal dirige la solicitud a un combo o perfil, solo la rechaza de antemano si se sabe que la política prohíbe todos los destinos declarados. En otro caso, la selección normal continúa sin filtrar candidatos, y el destino que realmente se seleccione respeta estos controles. Permitir el fallback entre proveedores no permite elegir otro modelo del mismo proveedor si el fallback de modelo está desactivado, aunque haya otro candidato permitido.
+
+<a id="turn-fallback-off"></a>
+
+## Desactivar el fallback
+
+```bash
+ocx fallback off                               # model and provider fallback, everywhere
+ocx fallback off --kind provider               # only cross-provider hops
+ocx fallback off --route combo/coding          # one combo, routing profile or model selector
+ocx fallback off --provider anthropic          # hops that leave one provider
+ocx fallback on --route combo/coding           # an exception under a global off
+ocx fallback clear --route combo/coding        # remove an override
+ocx fallback status                            # current settings and the last fallback
+```
+
+Los mismos ajustes aparecen en el dashboard: la tarjeta **Fallback**, al final de **Dashboard**, contiene los ajustes globales, las excepciones y el último fallback ejecutado o rechazado.
+
+<a id="precedence"></a>
+
+### Prioridad
+
+1. Un **dispositivo** configurado en off siempre rechaza el fallback (consulta los [ajustes por dispositivo](#per-device-settings)). Este alcance solo puede denegarlo: activarlo no permite un salto que otro alcance rechaza.
+2. En los demás casos, tiene prioridad el ajuste más específico: **ruta**, después **proveedor** y finalmente **global**.
+3. Si no hay ningún ajuste, el fallback está permitido, que es el comportamiento actual.
+
+Los ajustes se guardan en `config.json`, bajo `fallback`:
+
+```json
+{
+  "fallback": {
+    "provider": false,
+    "routes": { "combo/coding": { "provider": true } },
+    "providers": { "anthropic": { "model": false } },
+    "devices": { "lnk_0123456789abcdef": { "localFallback": false, "model": false } }
+  }
+}
+```
+
+Un valor final mal formado se ignora, de modo que la resolución de políticas usa el siguiente alcance aplicable y los diagnósticos de `ocx config` lo identifican. En cambio, una escritura de la configuración completa que contenga ese valor se rechaza.
+
+<a id="the-error-you-get"></a>
+
+## El error recibido
+
+Un fallback rechazado devuelve el **estado del fallo que lo provocó**: un 429 rechazado sigue siendo 429, conserva `Retry-After` y devuelve este cuerpo:
+
+```json
+{
+  "error": {
+    "type": "fallback_refused",
+    "code": "fallback_refused",
+    "message": "combo/coding: anthropic/claude-opus failed (rate_limited). Provider fallback to openai/gpt-6-sol is off for route combo/coding, so OpenCodex did not send the request there. To allow it: ocx fallback on --kind provider --route combo/coding",
+    "fallback": { "kind": "provider", "scope": "route", "scopeKey": "combo/coding",
+                  "from": "anthropic/claude-opus", "to": "openai/gpt-6-sol", "trigger": "rate_limited" }
+  }
+}
+```
+
+La respuesta también incluye `x-opencodex-fallback: refused`. Si ya se sabe que el primer destino no está disponible, el rechazo ocurre antes de enviar nada y nunca se contacta al destino alternativo. El estado depende del motivo por el que se omitió el primer destino:
+
+- Primer destino de un combo en enfriamiento o sin cuota: 429.
+- Primer destino de un combo deshabilitado o no apto para la solicitud: 503.
+- Cuenta principal bloqueada: 429.
+- Modelo de subagente no disponible: 503.
+
+Después de un fallo real del proveedor, el rechazo conserva el estado de ese fallo.
+
+<a id="remote-link-children-and-hub-clients"></a>
+
+## Remote Link Children y clientes Hub
+
+Un Remote Link Child y un cliente Hub nunca atienden solicitudes con sus proveedores locales. Cuando el Home no está disponible, el Child devuelve un `503` reintentable (el relé del dashboard de un cliente Hub devuelve `502`) con:
+
+```json
+{ "error": "link tunnel unavailable", "code": "home_unreachable", "message": "The Home is unreachable, and OpenCodex did not serve this request from this device's local providers. …" }
+```
+
+No se envía nada a un proveedor local. Si el fallo ocurre antes de iniciar el reenvío, ni la clave de enlace ni el cuerpo de la solicitud salen del dispositivo. Si el reenvío ya comenzó, el Home puede haber recibido o procesado la solicitud: el resultado es incierto. Comprueba el estado en el Home antes de decidir si reintentas; OpenCodex no repite automáticamente una solicitud que ya empezó a enviar.
+
+<a id="per-device-settings"></a>
+
+### Ajustes por dispositivo
+
+En el Home, cada dispositivo enlazado tiene dos ajustes en **Remote Link** o mediante la CLI:
+
+```bash
+ocx fallback local on --device mac-studio      # permission for local fallback while the Home is down
+ocx fallback off --device mac-studio           # refuse model and provider fallback for this device's requests
+```
+
+`--device` acepta un alias o identificador de enlace de `ocx link status`, o el identificador de una clave de datos del Hub.
+
+**Fallback local** es un permiso que consulta GOAT: al activarlo, GOAT puede trasladar el trabajo del dispositivo a sus propias sesiones mientras el Home no esté disponible. OpenCodex sigue devolviendo `home_unreachable` y nunca atiende al dispositivo localmente. Está desactivado hasta que lo actives.
+
+<a id="status"></a>
+
+## Estado
+
+`ocx status --json` incluye un objeto `fallback` (en un Child, se consulta el del Home mediante el enlace). `GET /api/fallback` devuelve el mismo documento `ocx.fallback/1`: ajustes globales efectivos, excepciones, permiso de fallback local de cada dispositivo y los últimos 20 fallbacks ejecutados o rechazados, con fecha, ruta, origen, destino, motivo y alcance que tomó la decisión. La lista se guarda en memoria y se vacía al reiniciar el proxy. Nunca contiene cuerpos de solicitudes, claves ni identidades de cuentas.
+
+Un Home compatible anuncia `fallback-policy/1` en `features` de `GET /readyz`.
diff --git a/docs-site/src/content/docs/es/guides/grok-build.md b/docs-site/src/content/docs/es/guides/grok-build.md
new file mode 100644
index 00000000000..92346564d1d
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/grok-build.md
@@ -0,0 +1,124 @@
+---
+title: "Grok Build"
+description: "Usa modelos enrutados por opencodex desde Grok Build CLI de xAI; se registran en ~/.grok/config.toml mientras el proxy está activo."
+---
+
+opencodex ofrece un endpoint `POST /v1/responses` compatible con OpenAI en su puerto local, y Grok Build admite modelos personalizados que se conectan a servidores compatibles con OpenAI. Con esta integración, opencodex registra automáticamente todo su catálogo visible en Grok Build, sin necesidad de editar la configuración a mano.
+
+<a id="auto-registration"></a>
+
+## Registro automático
+
+Cuando `~/.grok` existe, `ocx start` (y `ocx ensure` / `ocx restart`) escribe un bloque administrado en `~/.grok/config.toml`:
+
+```toml
+# >>> opencodex managed block — do not edit (removed by `ocx stop`) >>>
+[model_providers.opencodex]
+base_url = "http://127.0.0.1:10100/v1"
+api_backend = "responses"
+api_key = "opencodex-loopback"
+extra_headers = { "x-opencodex-grok" = "1" }
+
+[model.ocx-gpt-5-6-sol]
+model = "gpt-5.6-sol"
+model_provider = "opencodex"
+name = "OCX gpt-5.6-sol"
+context_window = 272000
+supports_reasoning_effort = true
+reasoning_effort = "low"
+
+[[model.ocx-gpt-5-6-sol.reasoning_efforts]]
+id = "low"
+value = "low"
+label = "Low"
+description = "Quick, fast implementations"
+default = true
+# ... remaining rungs for this model, then one [model.ocx-*] table per visible model,
+# each referencing model_provider = "opencodex" ...
+# <<< opencodex managed block <<<
+```
+
+- **Aditivo:** tu configuración fuera de los delimitadores nunca se modifica. Antes de la primera inserción en un archivo existente, se guarda una única copia de seguridad en `~/.grok/config.toml.bak-opencodex`.
+- **Idempotente:** cada `ocx start` (y `ocx ensure` mientras el inicio automático esté habilitado) sustituye el bloque delimitado por el catálogo actual.
+- **Eliminación al detener:** `ocx stop`, `ocx eject`, `ocx uninstall` y el apagado ordenado del daemon sin servicio eliminan el bloque delimitado y restauran tu archivo byte por byte. Con un administrador de servicios, la eliminación se realiza mediante `ocx stop`/`ocx uninstall` (los procesos en modo servicio conservan intencionalmente el bloque entre reinicios).
+- **Protección frente a conflictos:** se respetan los alias que ya hayas definido en tus tablas `[model.*]` (opencodex añade sufijos a sus propias entradas). Si los delimitadores están dañados (hay un marcador de inicio sin marcador de fin), se rechaza cualquier cambio automático y se solicita una reparación manual.
+
+A continuación, elige un modelo en Grok Build:
+
+```bash
+grok models          # lists ocx-* entries alongside native grok models
+grok -m ocx-anthropic-claude-opus-4-8 -p "hello"
+# or in the TUI: /model ocx-anthropic-claude-opus-4-8
+```
+
+<a id="reasoning-effort"></a>
+
+## Esfuerzo de razonamiento
+
+Los controles `/effort` y `--effort` de Grok Build solo funcionan con modelos cuya entrada del catálogo anuncia una escala de niveles: al obtener la lista de modelos, Grok lee la respuesta sin procesar de `GET /v1/models`, cuyas entradas deben incluir `supports_reasoning_effort` y las opciones de menú `reasoning_efforts`. En cada tabla `[model.*]` administrada se escribe una representación de esa escala compatible con Grok (`supports_reasoning_effort`, el valor predeterminado `reasoning_effort` y las filas del selector `[[model.<alias>.reasoning_efforts]]`), para que el menú esté disponible cuando Grok lea el modelo de `config.toml`. Para los modelos enrutados, opencodex refleja los niveles configurados del proveedor (`reasoningEfforts` / `modelReasoningEfforts` y el valor predeterminado de `modelDefaultReasoningEfforts`). Estos metadatos describen la escala de la ruta configurada en el proxy. Los adaptadores pueden emular el razonamiento o convertir los niveles en campos específicos del proveedor. Los modelos enrutados con una escala configurada muestran el control de esfuerzo en Grok Build igual que en Codex. Los modelos con una lista de niveles vacía no muestran ese control, en consonancia con Codex. Las entradas nativas de GPT-5.6 son independientes: conservan y exponen las escalas de razonamiento fijadas de origen, en lugar de los metadatos de enrutamiento configurados por el proveedor. Se conservan los niveles válidos de Grok, incluidos `none` y `minimal`, cuando se anuncian. Los niveles no admitidos o duplicados, incluido `ultra`, exclusivo de Codex, se omiten del archivo para que todas las opciones del selector puedan seleccionarse.
+
+Grok Build se comunica con opencodex mediante la API Responses. Cuando la ruta anuncia una escala de razonamiento, el paso directo de Responses reenvía `reasoning.summary` según la configuración, de modo que las trazas de razonamiento llegan a Grok de forma nativa como elementos de razonamiento de Responses. Establece `reasoning.summary: "none"` si el cliente quiere que el modelo razone sin devolver la traza. Un valor explícito de `reasoning.summary` tiene prioridad sobre el valor predeterminado de la ruta.
+
+<a id="authentication-note"></a>
+
+## Nota de autenticación
+
+Grok Build requiere una clave API no vacía para los modelos personalizados, incluso en loopback. Las entradas insertadas contienen un marcador de posición (`opencodex-loopback`): opencodex ignora las claves de admisión en las conexiones de loopback, por lo que no se utiliza ningún secreto real.
+
+**El registro automático solo funciona en loopback.** Cuando opencodex escucha en una dirección que no es de loopback, incluidos los comodines `0.0.0.0` y `::`, que exponen todas las interfaces, las solicitudes necesitan tu token de admisión real y un bloque administrado no puede incluirlo de forma segura. Escribir el token literal dejaría tu secreto en `~/.grok/config.toml` y sobrescribiría lo que hayas configurado allí en el siguiente `ocx start`/`ensure`/`restart`. Por eso, en ese caso opencodex no escribe nada (y elimina cualquier bloque que quede de una configuración anterior en loopback). Debes configurar los modelos por tu cuenta fuera de los marcadores administrados, donde opencodex no puede sobrescribirlos. Consulta la tabla exacta en [Receta manual](#manual-recipe-without-auto-registration) y establece tanto `base_url` (un host accesible desde donde ejecutas `grok`) como `api_key` (tu `OPENCODEX_API_AUTH_TOKEN`).
+
+**Un `unauthenticatedLoopbackListener` habilitado es la excepción.** Con ese listener activo, opencodex sí escribe el bloque administrado, apuntando a `127.0.0.1` en el puerto del listener, porque las solicitudes de loopback allí no necesitan token de admisión, independientemente de cómo esté vinculado el listener público. Un listener complementario sin `port` comparte el puerto del proxy, y OpenCodex solo acepta esa forma en una dirección específica que no sea de loopback; con los comodines `0.0.0.0` o `::` rechaza el par, así que asigna un `port` distinto al listener de loopback para usar esta excepción. La receta manual de abajo sigue aplicándose cuando quieras gestionar esas entradas por tu cuenta.
+
+No sustituyas `api_key` por `env_key` aquí. Si `env_key` no se resuelve, la solicitud no se detiene: Grok usa como alternativa tu token de sesión de xAI y lo envía a la URL indicada por `base_url`, que en un despliegue en LAN es un endpoint HTTP sin cifrar que no pertenece a xAI.
+
+El `api_key` insertado en la entrada del proveedor ocupa el primer lugar en la cadena de credenciales de Grok para estos modelos, por lo que las interacciones con opencodex no requieren otro inicio de sesión en Grok. Conserva tu configuración habitual de `grok login` / `XAI_API_KEY` para los modelos nativos de Grok y las funciones del entorno de ejecución que contacten directamente con xAI.
+
+<a id="manual-recipe-without-auto-registration"></a>
+
+## Receta manual (sin registro automático)
+
+Si gestionas `~/.grok/config.toml` por tu cuenta, o si opencodex escucha en una dirección que no es de loopback con el listener de loopback desactivado, añade un bloque `[model_providers.opencodex]` y tablas para cada modelo que hagan referencia a él, fuera de los marcadores `# >>> opencodex managed block`:
+
+```toml
+[model_providers.opencodex]
+base_url = "http://127.0.0.1:10100/v1"
+api_backend = "responses"
+api_key = "opencodex-loopback"
+
+[model.ocx-opus]
+model = "anthropic/claude-opus-4-8"
+model_provider = "opencodex"
+```
+
+Para un proxy accesible a través de la red, configura un frontend TLS antes de proporcionar tu token de admisión y apunta `base_url` a su dirección HTTPS. Como alternativa, utiliza un túnel local y su dirección de loopback. Grok almacena el valor literal de `api_key` en `~/.grok/config.toml`; restringe el acceso al archivo y mantenlo fuera del control de versiones y de las copias de seguridad compartidas.
+
+```toml
+[model_providers.opencodex]
+base_url = "https://proxy.example.com/v1"   # configured TLS frontend
+api_backend = "responses"
+api_key = "your-OPENCODEX_API_AUTH_TOKEN"
+
+[model.ocx-opus]
+model = "anthropic/claude-opus-4-8"
+model_provider = "opencodex"
+```
+
+Esto utiliza la herencia de `[model_providers.<id>]`, que requiere Grok Build 0.2.109 o posterior (publicado el 2026-07-21). En versiones anteriores, el `base_url` heredado no se aplica al enrutamiento de inferencia: actualiza Grok Build o utiliza campos directos por modelo (`base_url`/`api_backend`/`api_key` en cada tabla `[model.*]`).
+
+Pon entre comillas cualquier alias que contenga un punto: `[model.grok-4.5]` sin comillas es una ruta de claves de tres segmentos, no el identificador `grok-4.5`. Por eso, los alias generados evitan por completo los puntos.
+
+<a id="known-limitations"></a>
+
+## Limitaciones conocidas
+
+- **`ocx restart` con un servicio instalado:** el proxy en ejecución se encarga de autorizar el reinicio y coordinar la finalización de las solicitudes en curso, mientras que el administrador de servicios instalado inicia el reemplazo cuando termina el proceso anterior. La supervisión del servicio permanece instalada. Si el registro automático usa loopback, el bloque administrado también se conserva durante el relevo; los despliegues fuera de loopback utilizan una configuración de Grok administrada manualmente. El comando solo tiene éxito cuando un proceso diferente, cuya identidad se ha verificado, está en buen estado en el mismo puerto.
+- **Momento de lectura de la configuración:** inicia primero opencodex y después `grok` para obtener los resultados más predecibles. Grok Build observa `~/.grok/config.toml` y recarga cuando cambia realmente el contenido de la tabla `[model]` (con una espera de aproximadamente un segundo para agrupar cambios), por lo que un bloque actualizado llega a una sesión abierta sin reiniciarla. Para confirmar lo que Grok ha leído, ejecuta `grok inspect`: enumera las fuentes de configuración cargadas y advierte sobre los campos rechazados. No imprime la lista de modelos resueltos. La versión actual de Grok Build informa de los campos de modelo no válidos y los omite, pero conserva el resto de la entrada. Un error de sintaxis TOML sí impide cargar el archivo. opencodex escribe de forma atómica, por lo que Grok recibe un documento completo en cada recarga.
+- **Actualizaciones del catálogo:** el bloque delimitado refleja el catálogo en el momento de su inserción. Después de añadir proveedores o modelos, ejecuta `ocx ensure` (o reinicia el proxy) para actualizarlo.
+
+<a id="devin-rate-limits"></a>
+
+## Límites de solicitudes de Devin
+
+Si Devin rechaza una solicitud directa por un límite de solicitudes antes de producir una salida o realizar una acción, OpenCodex devuelve HTTP 429 con un error JSON. Así, Grok puede reconocer el límite en lugar de mostrar un error genérico 500 por un flujo HTTP 200 fallido. Si la respuesta incluye `Retry-After`, respeta ese tiempo antes de volver a intentarlo. Cuando la cuota se agota sin indicar cuándo se restablece, no se añade una espera predeterminada. Sigue aplicándose la conmutación por error entre cuentas OAuth existente. Este tratamiento de HTTP 429 también se aplica a las solicitudes Responses sin streaming.
+
+Para las solicitudes con streaming, OpenCodex espera este rechazo temprano hasta que vence el tiempo de espera por inactividad configurado. Si vence, abre la respuesta SSE y deja que el supervisor de flujo existente gestione los bloqueos. Una vez enviadas las cabeceras HTTP, cualquier fallo posterior permanece dentro del flujo como `response.failed`.
diff --git a/docs-site/src/content/docs/es/guides/image-bridge.md b/docs-site/src/content/docs/es/guides/image-bridge.md
new file mode 100644
index 00000000000..f7769f50d68
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/image-bridge.md
@@ -0,0 +1,83 @@
+---
+title: "Puente de imágenes"
+description: "Enruta las llamadas a la herramienta alojada image_generation hacia xAI Grok Imagine al usar un proveedor distinto de OpenAI."
+---
+
+<a id="overview"></a>
+
+## Descripción general
+
+Cuando enrutas Codex mediante un modelo distinto de OpenAI (Claude, Gemini, Grok, etc.), la **herramienta alojada** `image_generation` normalmente no funciona, porque requiere el entorno de ejecución de OpenAI en el servidor. El puente de imágenes detecta estas llamadas y las redirige de forma transparente a xAI Grok Imagine, de modo que el modelo con el que conversas pueda generar imágenes.
+
+<a id="prerequisites"></a>
+
+## Requisitos previos
+
+- **Activa el puente** con `images.bridgeEnabled: true`. Está desactivado de forma predeterminada para evitar cargos inesperados de xAI; consulta [Configuración](#configuration).
+- Añade un proveedor `xai` con una **clave API**. El puente Responses usa el destino de imágenes de xAI del registro (`https://api.x.ai/v1`) e ignora cualquier cambio de `baseUrl` para esas llamadas. OAuth o `ocx login xai` por sí solos **no activan este bucle sidecar**. La misma opción `bridgeEnabled` sí activa el relé independiente de `/v1/images`, que permite al cliente integrado `image_gen` usar Imagine con la autorización de Grok CLI. Consulta [Generación de imágenes integrada](/es/guides/codex-integration/#built-in-image-generation-image_gen). Si existe un proveedor xAI pero carece tanto de esa autorización como de una clave API, `/v1/images` devuelve un error sin recurrir a ChatGPT. Si no existe ningún proveedor xAI, el relé no atiende la solicitud y la selección normal puede elegir un proveedor de imágenes ChatGPT configurado.
+
+  El relé solo administra esa ruta si no se ha configurado un proveedor de imágenes: requiere `images.bridgeEnabled` en `true` y que se omita `images.provider`. Si estableces `images.provider` explícitamente, `/v1/images` usa ese proveedor y devuelve sus errores de validación sin volver a intentar mediante xAI.
+
+  ```json
+  {
+    "providers": {
+      "xai": { "adapter": "openai-chat", "apiKey": "xai-…", "authMode": "key" }
+    }
+  }
+  ```
+
+- Un modelo no OpenAI seleccionado como su proveedor activo. (Cuando el proveedor activo es OpenAI, la herramienta alojada nativa se usa directamente y el puente se pasa por alto.)
+
+<a id="configuration"></a>
+
+## Configuración
+
+Las opciones del puente de imágenes se encuentran en `images`, dentro de `~/.opencodex/config.json`. La función es **opcional**: debes establecer `bridgeEnabled: true` para habilitar la generación de pago mediante xAI Grok Imagine:
+
+```json
+{
+  "images": {
+    "bridgeEnabled": true,
+    "bridgeModel": "grok-imagine-image-quality",
+    "maxRounds": 3,
+    "timeoutMs": 60000
+  }
+}
+```
+
+| Opción | Predeterminado | Descripción |
+| --- | --- | --- |
+| `bridgeEnabled` | `false` | Interruptor maestro. Establecer `true` para permitir el puente. Desactivado por defecto para evitar cargos inesperados de xAI. |
+| `bridgeModel` | `grok-imagine-image-quality` | El identificador de modelo de imagen xAI para enviar mensajes. |
+| `maxRounds` | `3` | Iteraciones máximas de bucle de generación de imágenes por turno. Los valores se redondean hacia abajo al entero inferior y se limitan al intervalo `[0, 10]`; los valores no finitos usan el valor de respaldo `3`. |
+| `timeoutMs` | `60000` | Fecha límite xAI por llamada en milisegundos. Los valores positivos finitos se redondean hacia abajo al entero inferior y se pasan a la solicitud xAI. |
+| `artifactsKeepCount` | `200` | Número máximo de archivos retenidos bajo `artifacts/`. Cuando se excede, los archivos más antiguos se eliminan después de cada llamada completada. Establezca en `0` o un valor negativo para deshabilitar la poda. |
+
+<a id="artifact-retention"></a>
+
+## Retención de artefactos
+
+Las imágenes generadas se escriben en `~/.opencodex/artifacts/`. Para evitar el crecimiento ilimitado del disco en sesiones de larga duración, el directorio se poda automáticamente después de cada llamada de imagen completada (una vez que el lote completo para esa llamada está en el disco): los archivos más antiguos (por tiempo de modificación) se eliminan cuando el recuento excede el máximo configurado (por defecto 200, configurable a través de `images.artifactsKeepCount`). Solo las rutas que sobreviven a la poda se devuelven al modelo.
+
+<a id="how-it-works"></a>
+
+## Cómo funciona
+
+El puente de imágenes intercepta únicamente turnos **Responses** que incluyan la herramienta alojada `image_generation` en `tools` de `/v1/responses` al usar un modelo **de otro proveedor que no sea OpenAI**. La herramienta integrada `image_gen` de Codex sigue otra ruta: envía un POST directamente a `/v1/images/generations` o `/images/edits` y usa un relay integrado independiente, descrito en [Integración con Codex](/es/guides/codex-integration/#built-in-image-generation-image_gen).
+
+1. OpenCodex detecta `image_generation` en `tools` durante el preprocesamiento de la solicitud Responses.
+2. Sustituye la herramienta alojada por una **función sintética** que el modelo enrutado puede invocar, en lugar de una herramienta alojada que no puede ejecutar.
+3. Cuando el modelo la invoca, OpenCodex intercepta la llamada y envía el prompt a la API de generación de imágenes de xAI.
+4. Guarda las imágenes en `~/.opencodex/artifacts/` y devuelve al modelo la **ruta local del archivo** como resultado de la herramienta.
+5. El modelo continúa la conversación con la información de la imagen generada y su ubicación.
+
+Desde la perspectiva del modelo, nada cambió: llamó a una herramienta y obtuvo un resultado. Desde la perspectiva del usuario, la generación de imágenes funciona con cualquier proveedor enrutado en lugar de fallar silenciosamente.
+
+<a id="limitations"></a>
+
+## Limitaciones
+
+- **Solo xAI Grok Imagine es compatible.** DALL-E y otros proveedores de imágenes se pueden agregar más tarde.
+- **La búsqueda web tiene prioridad** cuando la solicitud es apta para el bucle de búsqueda web. Si se solicitan búsqueda y generación de imágenes en el mismo turno apto, se ejecuta la búsqueda y se omite la generación de imágenes. Esto incluye adaptadores `runTurn` aptos, como Cursor, mediante `runTurnWebSearchLoop`. El puente de imágenes solo puede atender esos turnos con ambas herramientas si la búsqueda web no resulta elegible.
+- **Se aplican costos de xAI.** La generación de imágenes a través de xAI requiere una suscripción activa a xAI o créditos API.
+- **Sólo streaming.** El puente funciona interceptando el flujo de respuesta SSE; las solicitudes con `stream: false` se rechazan con un error 400.
diff --git a/docs-site/src/content/docs/es/guides/integrations.md b/docs-site/src/content/docs/es/guides/integrations.md
new file mode 100644
index 00000000000..bad8266407b
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/integrations.md
@@ -0,0 +1,737 @@
+---
+title: "Integraciones"
+description: "Conectar opencodex a OpenCode, Pi, Gentle Shell, OMP, Hermes, OpenClaw, Kimi Code, gjc, DeepSeek Harness, MiniMax Code, ZCode, Prime Agent, Aside, Raycast, omo, Qoder, Cline CLI, Kilo, Command Code, Factory Droid y T3 Code desde el panel — un interruptor por cliente, con una copia de seguridad tomada antes de cada escritura."
+---
+
+La página **Conectar** escribe el bloque de proveedor de opencodex en el archivo de configuración del cliente y permite retirarlo. Cada cliente de la tabla tiene su propio interruptor:
+
+| Cliente | Archivo de configuración | Formato | Cuando el cambio entra en vigor | Credenciales |
+|---|---|---|---|---|
+| OpenCode | `~/.config/opencode/opencode.json` | JSON | Próximo lanzamiento directo | `OPENCODEX_OPENCODE_API_KEY` |
+| Pi | `~/.pi/agent/models.json` | JSON | Nuevas sesiones | marcador de posición loopback |
+| Gentle Shell | `~/.gentle-shell/agent/models.json` (hogar seleccionado persistente) | JSON | después de reiniciar Gentle Shell | marcador de posición loopback |
+| OMP | `~/.omp/agent/models.yml` | YAML | después de reiniciar OMP | `opencodex-loopback` marcador de posición |
+| Hermes | `~/.hermes/config.yaml` | YAML | Nuevas sesiones | `OPENCODEX_HERMES_API_KEY` |
+| OpenClaw | `~/.openclaw/openclaw.json` | JSON5 | inmediatamente, en una puerta de enlace en ejecución | `OPENCODEX_OPENCLAW_API_KEY` |
+| Kimi Code | `~/.kimi-code/config.toml` | TOML | en el reinicio, o `/reload` | marcador de posición loopback |
+| gjc | `~/.gjc/agent/models.yml` | YAML | nuevas sesiones, o cuando abres `/model` |marcador de posición de bucle de retroceso no secreto |
+| DeepSeek Harness (DSH) | `$DSH_HOME/profiles/desktop/cordis.patch.yml` (por defecto `~/.dsh/profiles/desktop/cordis.patch.yml` ); `$DSH_HOME/settings.yaml` hasta que DSH Desktop cree ese perfil | YAML | recarga caliente | marcador de posición portador de bucle de retorno no secreto |
+| MiniMax Code | `~/.minimax/config.yaml` | YAML | nuevas sesiones, o después de abrir el selector de modelos | marcador de posición loopback |
+| Prime Agent | `~/.prime/agent/models.json` | JSON | Nuevas sesiones | marcador de posición loopback |
+| ZCode | `~/.zcode/v2/provider_config.json` (schemaVersion 1); retroceso legado: `~/.zcode/v2/config.json` | JSON | al reiniciar | marcador de posición loopback |
+| Aside | `~/.aside/u/<account>/models.json` | JSON | después de cerrar Aside por completo y volver a abrirlo | marcador de posición loopback |
+| Raycast | `~/.config/raycast/ai/providers.yaml` | YAML | inmediatamente en guardar - Raycast mira el archivo | ninguno - solo loopback |
+| omo (Pi / senpi) | `~/.omo/agent/models.json` | JSON | Nuevas sesiones | marcador de posición loopback |
+| Qoder | `settings.json` en `$QODER_CONFIG_DIR`, por defecto `~/.qoder` | JSON | Nuevas sesiones | marcador de posición loopback |
+| Qoder CN | `settings.json` en `$QODERCN_CONFIG_DIR`, por defecto `~/.qoder-cn` | JSON | Nuevas sesiones | marcador de posición loopback |
+| WorkBuddy (CN) | `~/.workbuddy/models.json` | JSON | Recarga automática o nuevas sesiones | marcador de posición loopback |
+| WorkBuddy AI | `~/.workbuddy-ai/models.json` | JSON | Recarga automática o nuevas sesiones | marcador de posición loopback |
+| Cline CLI | `~/.cline/data/settings/providers.json` y hermano `models.json` | JSON pareja | después de detener y reiniciar Cline | marcador de posición loopback |
+| Kilo | primero existente `kilo.jsonc`, `kilo.json`, `opencode.jsonc`, `opencode.json`, o `config.json` bajo `~/.config/kilo` | JSONC | Nuevas sesiones | `OPENCODEX_KILO_API_KEY` |
+| Command Code | `~/.commandcode/providers.json` (en Windows con el home predeterminado: use `HOME ?? USERPROFILE` solo si no está en blanco y es una ruta absoluta de Windows; de lo contrario, `homedir()`; un home proporcionado por separado se respeta; añada `.commandcode\providers.json`) | JSON | el siguiente lanzamiento de Command Code | ninguno: bucle de retorno sin clave (`apiKey: false`); la aplicación de escritorio necesita su propio inicio de sesión y opencodex nunca escribe `auth.json` |
+| Factory Droid | `~/.factory/settings.json` ( `%USERPROFILE%\.factory\settings.json` en Windows) | JSON | inmediatamente a través de la observación de archivos | ninguno: bucle local sin clave |
+| T3 Code | `$T3CODE_HOME/userdata/settings.json` (por defecto `~/.t3/userdata/settings.json`) | JSON | inmediatamente — T3 Code observa el archivo | marcador loopback no secreto |
+
+<a id="gentle-shell"></a>
+
+## Gentle Shell
+
+Elija **Conectar → Gentle Shell**, o utilice los mismos comandos de integración administrada:
+
+```bash
+ocx export --client gentle-shell --json
+ocx integration client enable --client gentle-shell
+ocx integration client disable --client gentle-shell
+```
+
+Gentle Shell tiene un destino separado y un historial de reversión de Pi. Solo se gestionan `providers.opencodex`; otros proveedores y preferencias permanecen intactos. Los cambios de catálogo actualizan un bloque ya conectado, sin cambios. Un bloque copiado manualmente existente es un conflicto, no un permiso para sobrescribirlo: inspeccione la vista previa y use la confirmación explícita de sobreescritura solo si tiene la intención de reemplazarla.
+
+El `home` guardado en `~/.gentle-shell/config.json` selecciona el destino. Gana una ruta personalizada guardada; el modo aislado/por defecto usa `GENTLE_SHELL_HOME` o `~/.gentle-shell/agent`. `GENTLE_SHELL_CONFIG` selecciona una configuración de lanzador alternativa. Estas variables de entorno deben establecerse en el **Proceso OpenCodex**, no solo en un shell posterior. Los selectores deben ser rutas absolutas; las rutas literales `~` y relativas se niegan. Las banderas `gentle-shell --home` únicas no pueden ser descubiertas por un proxy de fondo.
+
+El modo de enlace o un aliasing de inicio Pi se niega con un remedio de integración Pi; use **Conectar → Pi** para ese archivo compartido en su lugar. OpenCodex no cambia las preferencias del lanzador. Se rechaza una configuración de lanzador ilegible/insegura; la configuración malformada JSON vuelve a ser aislada, coincidiendo con el lanzador. Si mueves una casa conectada, desactívala usando sus selectores originales antes de volver a conectar la nueva. Reinicie Gentle Shell después de una actualización de catálogo. Esta integración conserva la política de exportación de Pi solo loopback y no almacena ninguna clave API real.
+
+"omo" nombra tres productos que comparten la carpeta `~/.omo`. La pestaña **omo** administra el omo basado en Pi (el motor senpi) a través de `~/.omo/agent/models.json`, como en la tabla anterior. El omo basado en Codex (LazyCodex) tiene su propia sección en la misma pestaña, mostrada solo cuando se detecta LazyCodex, descrita en [omo ( Codex / LazyCodex) modelos de rol](#omo-codex--lazycodex-role-models). OpenCode-based omo (oh-my-opencode) mantiene su propia configuración bajo OpenCode; opencodex no lo lee ni lo escribe.
+
+El bloque administrado de omo basado en Pi usa Chat (`api: "openai-completions"`) de forma predeterminada. Chat descarta el razonamiento del paso anterior entre llamadas a herramientas, algo que se nota en los bucles largos de omo. Para que la habilitación y cada actualización escriban el protocolo Responses, añade esta clave al archivo de configuración de opencodex; no está disponible en el dashboard:
+
+```json
+{ "omoClientExport": { "api": "openai-responses" } }
+```
+
+Reinicia el proxy para cargar el archivo editado (`ocx service restart` si usa un servicio, o `ocx stop` y después `ocx start`). A continuación, actualiza la integración desde **Conectar → omo** en el dashboard. Actualizar por sí solo utiliza la configuración del proxy en ejecución; no vuelve a leer el archivo.
+
+Este ajuste solo afecta a omo. Pi, Gentle Shell y los demás clientes con formato de Pi conservan `openai-completions`. Para volver a Chat, elimina la clave, reinicia el proxy del mismo modo y actualiza **Conectar → omo**. Se ignoran los valores desconocidos. opencodex sigue administrando únicamente `providers.opencodex` en `~/.omo/agent/models.json`; los demás proveedores de ese archivo se conservan.
+
+<a id="qoder-cn-and-workbuddy-editions"></a>
+
+### Qoder CN y ediciones de WorkBuddy
+
+En **Conectar**, habilita **Qoder CN**, **WorkBuddy (CN)** o **WorkBuddy AI** y elige un modelo
+OpenCodex en el selector de modelos personalizados del cliente. El proxy debe seguir en ejecución.
+La primera habilitación guarda una instantánea. Deshabilitar solo retira lo generado por OpenCodex;
+Deshacer restaura la instantánea. Los modelos y ajustes ajenos se conservan. Estas conexiones son
+independientes de Qoder Global y de las demás ediciones.
+
+También puedes usar la CLI; cambia `workbuddy` por `workbuddy-ai` o `qoder-cn` para las otras ediciones:
+
+```bash
+ocx integration client enable --client workbuddy
+ocx export --client workbuddy --json
+ocx integration client disable --client workbuddy
+```
+
+Qoder CN respeta `QODERCN_CONFIG_DIR`. Las dos ediciones de WorkBuddy usan su variable nativa
+`WORKBUDDY_CONFIG_DIR` y, después, `CODEBUDDY_CONFIG_DIR`. Sin esas variables, se usan los directorios
+regionales de la tabla. Las rutas deben ser absolutas, `~`, o empezar por `~/` o `~\`. Se admiten
+el array antiguo de WorkBuddy y su objeto con una lista `models`. Si una restricción
+`availableModels` excluye los modelos OpenCodex, retírala en WorkBuddy antes de habilitar la conexión.
+Los ajustes del proyecto pueden tener prioridad sobre los del usuario.
+
+Se requiere un listener loopback sin autenticación; no se copian credenciales del proveedor a estos
+clientes. WorkBuddy recibe la URL completa de Chat Completions y las capacidades del catálogo
+OpenCodex. Reinicia el cliente o abre una sesión nueva si el selector no se ha actualizado.
+Las pruebas de configuración y ciclo de vida no demuestran compatibilidad completa con cada modelo
+del proveedor ni con cada versión del cliente.
+
+Doubao Desktop y Devin no tienen actualmente un contrato verificado para configurar proveedores
+arbitrarios en esta integración. No ofrecen un interruptor de habilitación; añadir un JSON local
+por sí solo no haría que sus selectores lo utilizaran.
+
+Qoder IDE / qodercli admite la exportación y la configuración administrada a través del panel de control y CLI:
+
+```bash
+ocx export --client qoder --json
+ocx integration client enable --client qoder
+ocx integration client disable --client qoder
+```
+
+Qoder usa `settings.json` en `QODER_CONFIG_DIR` si esa variable está configurada, o `~/.qoder/settings.json` en caso contrario; rechaza una ruta relativa en `QODER_CONFIG_DIR`. Al habilitar la integración, solo combina `providers.opencodex`, conservando los demás proveedores, modelos personalizados y ajustes. Los modelos se publican una sola vez en el catálogo del proveedor: duplicarlos en `modelConfigs.customModels` hace que Qoder rechace al proveedor. Al actualizar una integración administrada antigua, OpenCodex elimina sus duplicados registrados; las filas editadas por el usuario siguen siendo conflictos. Desactivar elimina las entradas registradas de OpenCodex; restaurar usa las instantáneas existentes. El modelo predeterminado es el primero de la exportación ordenada.
+
+Si `modelConfigs.customModels` ya contiene una fila `opencodex` para un modelo exportado que OpenCodex no escribió, habilitar, actualizar, sobrescribir y desactivar informan un conflicto y dejan el archivo intacto. Elimina o cambia el nombre de esa fila en Qoder y reinténtalo. Las filas de otros proveedores o de modelos ajenos a la exportación no cambian. Los modelos usan su `contextWindow` de catálogo, o 128000 tokens de entrada si no se conoce. Reinicia Qoder tras actualizar una integración existente para recargar su registro de proveedores.
+
+La clave API generada es un marcador no secreto. La integración solo admite acceso mediante loopback y rechaza un enlace autenticado fuera de loopback. Si hay un listener local dedicado sin autenticación, la exportación apunta a él. `ocx sync` y los cambios de catálogo actualizan una integración ya habilitada. Los identificadores que contienen `,` o `]`, como `kimi/k3[1m]`, se exportan igual que los demás.
+
+<a id="t3-code"></a>
+
+## T3 Code
+
+[T3 Code](https://github.com/pingdotgg/t3code) utiliza las CLI de Codex y Claude Code que ya están
+instaladas en el equipo. Sus hilos de Codex pasan por opencodex una vez habilitada la
+[integración de Codex](/es/guides/codex-integration/), porque T3 Code obtiene la lista de modelos
+mediante `codex app-server`, que lee `$CODEX_HOME/config.toml` como cualquier cliente de Codex.
+Los modelos enrutados aparecen entonces bajo Codex sin activar ningún interruptor de T3 Code,
+siempre que T3 Code ejecute Codex con el mismo directorio que administra opencodex (`CODEX_HOME`,
+por defecto `~/.codex`). Una instancia de Codex de T3 Code que use otro directorio no verá ese catálogo.
+
+El interruptor **T3 Code** añade la integración con Claude. Requiere la API Messages, utilizada
+en cada turno de Claude: si Messages está desactivada en la página API, se rechazan la habilitación
+y la actualización, pero sigue siendo posible deshabilitar la integración.
+
+```bash
+ocx export --client t3code --json
+ocx integration client enable --client t3code
+ocx integration client disable --client t3code
+```
+
+Habilitar escribe una instancia de proveedor, `providerInstances.opencodex`, en los ajustes del
+servidor de T3 Code y conserva las demás instancias y opciones. Es una instancia de Claude llamada
+**opencodex** que ejecuta tu propio binario `claude` con `ANTHROPIC_BASE_URL` apuntando al proxy,
+el marcador no secreto `opencodex-proxy` como `ANTHROPIC_AUTH_TOKEN`, `ANTHROPIC_API_KEY`
+explícitamente vacía y `CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST=1` para que un bloque env de
+`settings.json` en la configuración de Claude no pueda cambiar el destino. Cada modelo enrutado
+es un modelo personalizado cuya clave es su selector de opencodex (`provider/model`), que T3 Code
+envía literalmente. Aparece bajo **opencodex** en el selector de modelos de T3 Code. T3 Code recarga
+el archivo por sí mismo, sin reiniciar; los cambios del catálogo y `ocx sync` actualizan la instancia.
+
+T3 Code guarda sus datos en `T3CODE_HOME` si está definida y, en caso contrario, en `~/.t3`.
+Si cambias esa ubicación, configura la misma variable en el proceso de opencodex; se rechazan los
+valores relativos. En Windows, usa una ruta completa con unidad (`C:\shared\t3`) o una ruta UNC
+(`\\server\share\t3`); se rechazan las rutas sin unidad, como `\shared\t3` o `/shared/t3`.
+`~` se expande con respecto al directorio personal efectivo. El marcador no es una credencial:
+la integración requiere acceso loopback y rechaza un enlace autenticado fuera de loopback,
+salvo que esté habilitado el listener loopback sin autenticación.
+
+Trata la instancia como una configuración administrada por opencodex. Marcar una variable como
+**Sensitive** en T3 Code, añadirle un modelo personalizado o desactivarla reescribe el bloque.
+El interruptor muestra entonces un conflicto en lugar de sobrescribir la edición; **Reemplazar**
+restaura el bloque generado. Para usar otros ajustes, añade tu propia instancia de Claude en T3 Code.
+
+Los catálogos generados incluyen solo modelos habilitados de cada selección de proveedor. Esto se aplica tanto a las descargas como a las integraciones administradas, incluidas Pi y Aside. La lista de modelos de administración aún muestra la lista completa para que pueda habilitar modelos adicionales.
+
+`ocx uninstall` deshabilita las integraciones registradas, incluyendo todos los perfiles de propiedad de Aside, antes de eliminar el estado de recuperación de OpenCodex. La propiedad ilegible, el registro de perfil faltante o una edición en conflicto detiene esa eliminación. La limpieza es secuencial: las inhabilitaciones anteriores no se deshacen cuando una posterior falla. Si la compensación también falla, un archivo cliente puede dejarse en un estado intermedio. Inspeccione los archivos del cliente reportados y las instantáneas de recuperación retenidas antes de volver a intentar; el estado retenido no significa que todos los clientes se restauraron o se dejaron sin cambios.
+
+Para los preajustes incorporados de Gajae, mantenga la opción de enrutamiento en `~/.gjc/agent/config.yml`:
+
+```yaml
+modelProfile:
+  proxyProvider: opencodex
+  proxyMode: always
+```
+
+Mantenga su `modelProfile.default` elegido para aplicarlo cuando se inicie la llanura `gjc`. La integración administrada posee solo `providers.opencodex` en `models.yml`; actualizar o deshabilitar ese proveedor no reescribe su opción preestablecida. Actualizar la integración después de cambiar la selección del modelo exportado.
+
+Los modelos GJC con una escalera de razonamiento-esfuerzo compatible exportan `reasoning: true`, `thinking.levels` y `compat.supportsReasoningEffort`, por lo que GJC puede ofrecer una opción de esfuerzo. Los modelos nativos Codex reciben su escalera estándar incluso cuando el catálogo la omite. Los modelos sin una escalera conocida omiten estos campos; `none` y `ultra` no se ofrecen porque `none` no envía ningún esfuerzo y `ultra` se pliega a `max` en el cable. Actualice la integración para actualizar estas opciones de modelo.
+
+La integración administrada de OpenCode controla dos bloques: `provider.opencodex` (OpenCode V1) y `providers.opencodex` (OpenCode V2). Ambos incluyen los mismos esfuerzos de razonamiento y valores predeterminados declarados por modelo. El bloque heredado usa un mapa de variantes y las opciones del modelo; V2 usa la configuración del modelo y un array nativo de variantes. Los dos se escriben y mantienen sincronizados, identifican los mismos proveedores y modelos, y OpenCode V2 los combina en una sola entrada. Aplicar, Actualizar, Desactivar y Restaurar actúan sobre ambos bloques. Los demás proveedores, agentes, atajos de teclado y entradas MCP se conservan.
+
+Ambos fragmentos se construyen a partir de los metadatos del modelo canónico efectivo, al igual que la exportación de Kilo y el lanzador `ocx opencode`. Una anulación explícita personalizada siempre gana, y una escalera que se vacía permanece vacía; una escalera de razonamiento o predeterminada nunca se inventa para un modelo que no declara ninguno. Un límite de contexto autorizado se lleva con un presupuesto de salida al lado: un valor de salida conocido - explícito o de metadatos de catálogo - gana, de lo contrario el esquema requerido 32000 reserva sujeta al contexto, y sin un contexto autorizado se omite todo el bloque de límite. Las capacidades, escalas de esfuerzo, valores predeterminados y un límite de entrada opcional aparecen solo cuando se conocen; el objeto de capacidades nativas del bloque V2 requiere un valor de herramientas conocido, por lo que cuando se desconoce el soporte de la herramienta se omite por completo en lugar de escribirse parcialmente, y la modalidad heredada permanece. Tampoco añade un esfuerzo seleccionable. Las variantes seleccionables anulan el valor predeterminado por modelo: `none` incluido, que se ofrece solo cuando la escalera declarada del propio modelo lo contiene. Sea lo que sea que el cliente seleccione, la política de razonamiento ascendente del proxy aún rige la solicitud que la abandona.
+
+El soporte de DSH administrado tiene un piso de compatibilidad de **DSH 0.1.0-rc.6**. DSH 0.1.7+ lee las rutas del proveedor desde `[id=llm-pi-ai].config.providers.opencodex` en el parche de perfil de escritorio, `$DSH_HOME/profiles/desktop/cordis.patch.yml`, que recarga DSH en caliente. OpenCodex escribe esa fila cuando existe el perfil de escritorio y su parche. Si existe `$DSH_HOME/profiles/desktop/package.json` pero falta `cordis.patch.yml`, Aplicar se niega: cree `cordis.patch.yml` que contiene `[]` (el parche vacío que DSH escribe para un nuevo perfil), luego habilite la integración nuevamente. Solo cuando no hay perfil de Escritorio, OpenCodex usa `llm-pi-ai.providers.opencodex` en `$DSH_HOME/settings.yaml`. OpenCodex solo posee ese fragmento de proveedor: Aplicarlo y Actualizarlo, Desactivarlo lo elimina y Restaurar devuelve una instantánea grabada. Estas operaciones no cambian el modelo predeterminado del usuario o el proveedor nativo `deepseek-official`. La integración DSH administrada es actualmente solo loopback y nunca escribe una credencial real.
+
+MiniMax Code sigue `MINIMAX_DATA_DIR`, luego `MAVIS_DATA_DIR`, antes de caer de nuevo a `~/.minimax`. Su bloque administrado posee solo `custom_provider.opencodex`. No cambia `defaultModel`, la fuente de credenciales MiniMax seleccionada o el inicio de sesión MiniMax del usuario. Elija una entrada `custom_provider:opencodex/<provider/model>` en MCode después de conectarla. La actualización de la integración también actualiza las ventanas de contexto autorizadas por modelo y las opciones de esfuerzo de razonamiento; se omiten las capacidades desconocidas y se conserva el esfuerzo actual de MCode.
+
+Prime Agent sigue a `PRIME_AGENT_CODING_AGENT_DIR` antes de caer de nuevo a `~/.prime/agent`; un valor relativo es rechazado por lo que el proxy y el agente no pueden estar en desacuerdo sobre qué archivo se quiere decir. Su bloque administrado posee solo `providers.opencodex`, por lo que otros proveedores y cualquier `modelOverrides` que haya establecido permanecen intactos. Prime Agent lee `models.json` cuando se inicia una sesión, así que inicie una nueva sesión después de conectarla.
+
+Aside mantiene un catálogo de modelos separado para cada perfil registrado, incluidos los perfiles locales. OpenCodex enumera todos los perfiles registrados, incluidos los perfiles locales, y puede sincronizarlos o controlar un perfil a la vez. Cambiar una integración nunca cambia la cuenta activa de Aside. Una conexión anterior de Aside habilita todos los perfiles de forma predeterminada; las exclusiones individuales sobreviven a las sincronizaciones posteriores.
+
+Una advertencia específica de Aside: la aplicación en ejecución reescribe el propio `models.json`, por lo que se cierra y vuelve a abrir completamente Aside después de aplicar, de la misma manera que Claude Desktop necesita un reinicio. El bloque de Aside es solo loopback y nunca lleva una credencial real.
+
+La integración administrada de Raycast soporta **macOS y Windows**. Custom Providers es una característica **Raycast Pro**: en un plan gratuito, el archivo todavía está escrito, pero `ocx integration client status --client raycast` y la página **Conectar** informan una advertencia, porque Raycast no lo leerá. En macOS o Windows, abra Raycast → Ajustes → AI → **Revelar proveedores Config** una vez que exista la carpeta `ai`. En estas plataformas compatibles, opencodex utiliza esa carpeta como su señal de instalación e informa que el cliente no está instalado hasta que existe. Linux no es compatible, incluso si la carpeta existe.
+
+El campo de estado `aiDirPresent` informa solo si existe `~/.config/raycast/ai`, independientemente de si la aplicación Raycast está instalada o si la plataforma es compatible. No prueba que Raycast esté instalado o sea utilizable. El CLI imprime `plan` en una línea separada y agrega la instrucción de configuración macOS / Windows cuando `aiDirPresent` es falso; `--json` preserva el estado en bruto, incluyendo el bloque anidado `raycast`. Raycast lee `~/.config/raycast/ai/providers.yaml` en macOS y Windows por igual y no honra `XDG_CONFIG_HOME`, por lo que ese camino no es reubicable.
+
+El bloque administrado es un elemento, `id: opencodex`, en la secuencia `providers` del archivo: `name: OpenCodex`, `base_url: http://<host>:<port>/v1`, y cada modelo enrutado con su `abilities`: el exportador establece `tools` y `system_message` a `true` como una convención cliente-exportación, `vision` sigue las modalidades de entrada del catálogo, `reasoning_effort` se establece cuando el modelo tiene una escalera de esfuerzo y `temperature` se apaga para los modelos de razonamiento. Otros proveedores en el archivo se conservan, y deshabilitar elimina solo el elemento OpenCodex. Raycast recoge el cambio tan pronto como se guarda el archivo, no se necesita reiniciar; los modelos aparecen en el selector de modelos de Raycast agrupado bajo **OpenCodex**. Raycast apoya `api_keys` opcional, pero OpenCodex intencionadamente los omite y rechaza objetivos nonloopback o autenticados por la admisión; esta integración no puede suministrar el encabezado de admisión requerido de OpenCodex.
+
+La preferencia privada macOS es solo una sugerencia Pro de asesoramiento; Windows nunca lo lee e informa que el plan es desconocido. La detección de planes no autoriza ni bloquea una escritura. Los metadatos de exportación no tienen un indicador autorizado de soporte de herramientas, por lo que `tools: true` no prueba que todos los modelos enrutados soporten herramientas. Las banderas de visión y esfuerzo siguen los metadatos del catálogo; desactivar la temperatura para una escalera de esfuerzo es un comportamiento de exportación conservador. Se conservan los valores de los proveedores; No se garantiza que el formato YAML y los comentarios sobrevivan. El formato está documentado en [manual.raycast.com/ai/proveedores personalizados](https://manual.raycast.com/ai/custom-providers).
+
+Las exportaciones y descargas del panel de Raycast CLI utilizan la política de destino y admisión del servidor en ejecución, incluido un oyente de bucle de retorno no autenticado configurado. `ocx ensure` no actualiza Raycast desde su instantánea de configuración guardada: eso puede diferir del servidor en ejecución. El inicio del servidor y la sincronización explícita siguen siendo las rutas de actualización del catálogo.
+
+
+Cursor tiene una pestaña, pero no es uno de estos interruptores. Regular Cursor llama a los puntos finales personalizados desde su propio backend, por lo que un proxy de loopback es inalcanzable sin un túnel público, y la construcción de inferencia privada separada de Cursor se configura dentro de Cursor. La pestaña **Cursor** es de solo lectura: detecta qué compilación está instalada, muestra la URL base y la clave API para pegar en Cursor e informa la última solicitud Cursor realizada al proxy. Véase [Cursor Inferencia privada](/es/guides/cursor-private-inference/).
+
+Los caminos honran el propio entorno de cada cliente anulan donde tiene uno. Para OMP, `OMP_PROFILE` gana sobre `PI_PROFILE` por presencia, incluso cuando está explícitamente vacío. Un perfil con nombre utiliza `PI_CONFIG_DIR` como un nombre de directorio en relación con el hogar del usuario e ignora `PI_CODING_AGENT_DIR`; sin un perfil con nombre, `PI_CODING_AGENT_DIR` gana. OMP soporta cabeceras a nivel de proveedor, pero esta integración inicial es deliberadamente solo bucle; cableado remoto `x-opencodex-api-key` es diferido. Los caminos `HERMES_HOME`, `KIMI_CODE_HOME` y `XDG_CONFIG_HOME` reubicados se siguen de manera similar en lugar de adivinarse. La tabla muestra el valor predeterminado de cada cliente.
+
+Para los modelos nativos OpenAI, el bloque OMP generado selecciona su nivel de modelo Responses API, preservando la entrada de imágenes y los controles de esfuerzo de razonamiento. Los modelos enrutados conservan el dialecto Chat Completions del proveedor para que sus adaptadores existentes sigan siendo compatibles.
+
+OpenClaw tiene varios, y hacen diferentes trabajos. `OPENCLAW_CONFIG_PATH` selecciona el archivo; `OPENCLAW_STATE_DIR`, `OPENCLAW_PROFILE` y `OPENCLAW_HOME` seleccionan el directorio de estado, que es también lo que la detección observa, por lo que un perfil o una casa reubicada aún se lee como instalado, mientras que una anulación de ruta de configuración mueve solo el archivo. Si todavía está en el diseño anterior `.clawdbot`, también se encuentra: el directorio moderno gana cuando existe y el heredado se usa cuando es el único allí.
+
+En Windows, las opciones que requieren rutas absolutas deben incluir una letra de unidad
+(`C:\Users\me\client`) o un recurso UNC (`\\server\share\client`). Se rechazan las rutas
+que parten de la raíz sin unidad, como `\Users\me\client` o `/client/config`, porque dependen
+de la unidad actual. Un selector que admita `~` lo expande respecto al directorio personal efectivo;
+Gentle Shell no expande `~`.
+
+Estos deben ser **Caminos absolutos** o comenzar con `~`. Se rechaza uno relativo en lugar de resolverlo, porque significaría cualquier directorio en el que se inicie cada proceso, y esa ruta se almacena con la copia de seguridad, por lo que tiene que nombrar el mismo archivo mañana que hoy.
+
+opencodex lee esto desde su propio entorno. Si su puerta de enlace se ejecuta con un perfil o una casa reubicada, inicie opencodex con el mismo conjunto de variables, o seguirá correctamente una instalación diferente.
+
+<a id="the-other-five-surfaces-are-not-switches"></a>
+
+## Las otras cinco superficies no son interruptores
+
+**Claves API** administra las credenciales propias de opencodex y no es un cliente en absoluto. **Codex CLI** lo conecta el propio servicio proxy: iniciar opencodex lo aplica y detenerlo restaura el enrutamiento nativo, así que no hay nada que activar por archivo. **Claude** mantiene su propio indicador de habilitación y el flujo Guardar/Aplicar del Escritorio, y **Grok Build** mantiene su modelo de seleccionar y luego aplicar. Esas semánticas son anteriores a esta característica y no cambian. **Cursor** no escribe nada en absoluto: su pestaña muestra la detección, los valores de la puerta de enlace y la última solicitud vista, y el resto ocurre dentro de Cursor Private Inference.
+
+<a id="rollback"></a>
+
+## Reversión
+
+Cada escritura exitosa toma una instantánea de su archivo *primero*, por lo que el estado que tenía siempre es recuperable:
+
+- **Deshacer** aparece en la operación más reciente cuando su archivo aún coincide con lo que escribimos.
+- **Restaurar este punto...** aparece en operaciones anteriores, o cuando el archivo cambió después de esa operación. Restaurar a través de tal cambio pide una segunda vez antes de reemplazar sus ediciones más recientes, y también las respalda, para que la propia restauración también se pueda deshacer.
+- Se mantienen 10 copias de seguridad por cliente. Más allá de eso, los archivos de instantáneas más antiguos se eliminan y sus filas de historia leen **La copia de seguridad expiró**.
+
+Desactivar elimina únicamente las entradas que opencodex registró como propias. Si el archivo se ha modificado después, el resultado depende de si esas entradas siguen intactas y del formato del archivo. En las configuraciones JSON estricto (OpenCode y Pi), una edición **junto a** nuestro bloque, como añadir un servidor MCP o un proveedor propio, se muestra como **Actualización necesaria**: al actualizar, se conservan esas entradas, aunque puede normalizarse el formato. La excepción son los valores que JSON no puede reescribir con exactitud: un número no finito como `1e999`, uno que se redondearía al reescribirlo (un entero muy grande o un número tan pequeño que se convertiría en cero), `-0`, una clave repetida en un objeto o un anidamiento de más de 1000 niveles. En esos casos, el interruptor se bloquea para evitar cambios o pérdidas silenciosas.
+**OMP, DSH y Hermes** también conservan las ediciones ajenas al bloque: sus escritores modifican únicamente los rangos de proveedor que administran, byte a byte, sin reescribir el resto del archivo. En los demás formatos que admiten comentarios (OpenClaw, Kimi Code, gjc, MiniMax Code y Raycast: JSON5 o TOML reescritos como documentos completos, o YAML genérico sin preservación del original), o si se han editado las propias entradas administradas, el interruptor se bloquea y la desactivación se rechaza. El bloque administrado permanece en el archivo; opencodex no intenta adivinar qué cambios pertenecen al usuario.
+
+Esa cerradura ya no es un callejón sin salida. Un cliente en conflicto muestra **Sustituir** al lado de su interruptor, tanto en la tarjeta de visión general como en la propia página del cliente. Reemplaza lo que contiene nuestra configuración con el bloque opencodex que escribiría, y pregunta primero: el diálogo nombra el archivo, dice lo que se pierde y señala la instantánea que permite deshacer el reemplazo. El switch en sí permanece bloqueado, porque el switch no puede saber qué ediciones pretende mantener, solo usted puede decirlo. Nada más está relajado: un archivo que no podemos analizar, o uno cuya estructura no podemos razonar, todavía se niega.
+
+<a id="hermes-session-affinity"></a>
+
+## Afinidad de sesión Hermes
+
+El bloque generado `providers.opencodex` incluye `session_affinity_header: session-id` para todos los modelos. Conserva ese valor salvo que quieras únicamente correlacionar registros. Si cambias `session_affinity_header` a `x-hermes-conversation-id`, Hermes envía ese encabezado en lugar de `session-id`. OpenCodex usa `x-hermes-conversation-id` solo como alternativa para correlacionar registros de solicitudes, no como identidad para enrutamiento nativo ni para terminar turnos. Por tanto, el cambio elimina la afinidad de sesión nativa y la asignación de carril, aunque permite correlacionar los bucles del agente en los registros. El ajuste nombra un encabezado; Hermes aporta el identificador dinámico de la conversación. OpenCodex no escribe un identificador estático compartido ni cambia `api_mode` para activar la afinidad.
+
+Utilice una versión de Hermes compatible con [Opciones de solicitud por proveedor](https://hermes-agent.nousresearch.com/docs/user-guide/configuring-models#per-provider-request-options). Las versiones anteriores pueden ignorar o descartar la opción; una configuración válida por sí sola no prueba que Hermes envíe el encabezado. El aislamiento de la conversación, el linaje de compactación y las solicitudes auxiliares / infantiles siguen la semántica de afinidad de Hermes. Esta configuración no garantiza una tasa de éxito de caché particular.
+
+Para una integración administrada existente, abra **Conectar → Hermes**, revise **Aplicar** y confirme la actualización. Hasta entonces, muestra **Actualización necesaria** y la actualización implícita del catálogo lo deja sin cambios, incluida su lista de modelos. Leer la página no actualiza la configuración. Después de aplicar, la actualización normal del catálogo se reanuda y conserva la configuración; **Sustituir** también lo incluye.
+
+Si ya agregó exactamente `session_affinity_header: session-id` dentro del bloque administrado, Apply puede adoptarlo cuando todas las demás configuraciones administradas aún coincidan con el registro de propiedad. Esta es la estrecha excepción a la regla de conflicto anterior: otras ediciones, un nombre de encabezado diferente o un bloque sin un registro de propiedad coincidente aún requieren resolución de conflictos. La configuración y los comentarios YAML no relacionados permanecen intactos, y el flujo de trabajo de instantánea y restauración existente se aplica a la actualización.
+
+<a id="hermes-profiles"></a>
+
+## Perfiles de Hermes
+
+Hermes mantiene un directorio propio para cada perfil de bot. El perfil predeterminado utiliza
+`~/.hermes/config.yaml` (`%LOCALAPPDATA%\hermes\config.yaml` en Windows, o `$HERMES_HOME/config.yaml`),
+y cada perfil creado con `hermes profile create <name>` utiliza
+`<Hermes home>/profiles/<name>/config.yaml`. Consulta la
+[guía de perfiles de Hermes](https://hermes-agent.nousresearch.com/docs/user-guide/profiles).
+
+Cuando existen perfiles con nombre, **Conectar → Hermes** muestra cada uno con su estado. Selecciona
+un perfil para aplicar, desactivar, reemplazar o restaurar OpenCodex solo en ese perfil. Cada uno
+conserva sus propias copias de seguridad e historial de restauración; los demás no cambian. Cada perfil
+conserva su `model.default` y los otros proveedores: OpenCodex solo añade `providers.opencodex`.
+Si no hay perfiles con nombre, la página funciona como antes y modifica el perfil predeterminado.
+
+Los cambios de catálogo y `ocx sync` solo actualizan automáticamente el perfil predeterminado resuelto desde el entorno del proxy en ejecución, incluido `HERMES_HOME`. Los perfiles con nombre conservan su catálogo anterior. Tras cambiar la selección de modelos, abre **Conectar → Hermes**, selecciona cada perfil que muestre **Actualización necesaria**, revisa los cambios y confirma **Aplicar**. La CLI no ofrece un selector de perfiles con nombre.
+
+Si el catálogo no cambió, editar comentarios o ajustes fuera de `providers.opencodex` mantiene el estado **Actualizado** y no modifica ni el archivo ni la referencia de propiedad guardada. Si hay un catálogo pendiente, la actualización automática rechaza cualquier archivo Hermes editado desde el último Aplicar, incluidas esas ediciones ajenas al bloque. Cuando aparezca **Actualización necesaria**, revisa y aplica el catálogo pendiente para reanudar las actualizaciones automáticas. Aplicar un catálogo sin cambios no hace nada ni acepta una nueva referencia del archivo.
+
+La API de administración selecciona un perfil mediante `profile=<name>` en `/api/client-integrations/hermes`
+y mediante `client=hermes&profile=<name>` en los endpoints de vista previa, historial y restauración;
+`GET /api/client-integrations/hermes/profiles` enumera los perfiles. Un directorio dentro de `profiles/`
+solo cuenta si Hermes lo mostraría: debe tener un nombre válido, un archivo de identidad de Hermes como
+`config.yaml` o `SOUL.md` y ningún marcador de eliminación. No se ofrecen perfiles alcanzados mediante
+enlaces simbólicos o junctions. Si posteriormente `HERMES_HOME` apunta a otro directorio de Hermes,
+OpenCodex rechaza un perfil con el mismo nombre allí hasta que desconectes el original, para conservar
+el seguimiento de todos los archivos que modificó.
+
+<a id="preview-and-confirm-changes"></a>
+
+## Vista previa y confirmación de cambios
+
+En el panel, Aplicar, Reemplazar, Deshabilitar y Restaurar comienzan con una vista previa. El cuadro de diálogo muestra exactamente qué configuración administrada cambiará, incluidas las rutas de cambio limitadas y si cada cambio agrega, actualiza o elimina un valor. Revisa ese plan antes de confirmarlo.
+
+Cuando un plan informa que no hay cambios, significa que el documento del cliente administrado ya tiene el estado solicitado. Para un perfil de Aside seleccionado, la confirmación puede guardar la preferencia de sincronización de ese perfil aunque el documento administrado no cambie.
+
+Si el archivo cambia después de revisarlo, la escritura se rechaza como obsoleta. El cuadro de diálogo reemplaza el plan anterior por el actualizado y le pide que confirme nuevamente; nunca vuelve a intentar la escritura automáticamente. Si una vista previa no está disponible temporalmente, vuelva a cargar la página normalmente e inicie la acción de nuevo.
+
+Aside utiliza la misma vista previa y flujo de confirmación para un perfil seleccionado a la vez. **Sincronizar todos los perfiles** sigue siendo una acción masiva separada y no está vinculada a una vista previa combinada.
+
+<a id="what-to-expect-honestly"></a>
+
+## Qué esperar, honestamente
+
+Si una ruta administrada generada no puede representarse de forma segura, ese cliente muestra un estado inseguro y la vista previa rechaza la operación. Los intentos de aplicar, sobrescribir o desactivar devuelven HTTP 409 sin cambiar la configuración. Los demás clientes siguen disponibles.
+
+**Los archivos de configuración administrados están limitados a 4 MiB (4,194,304 bytes UTF-8).** El lector de integración compartida rechaza los archivos más grandes como inseguros para leer, y el escritor rechaza una configuración combinada que excede el mismo límite con `write_failed`, dejando la configuración original sin cambios. El marcador de recuperación de Cline también tiene este límite; incluye el contenido de antes y después de ambos archivos más metadatos, por lo que Cline puede alcanzar el límite incluso cuando cada archivo individual es menor de 4 MiB.
+
+Realice una copia de seguridad de la configuración del cliente usted mismo, luego elimine las entradas innecesarias o reduzca la lista de modelos exportados antes de volver a intentar. **Sustituir** no pasa el límite. Si la configuración debe permanecer más grande, adminístrela manualmente en lugar de usar el interruptor Conectar.
+
+**El formato generalmente no se conserva.** La aplicación analiza una configuración y la vuelve a escribir, por lo que JSON, JSON5 y TOML pueden reformatearse y los comentarios en JSON5 o TOML se pierden. OMP, DSH y Hermes son las excepciones: OMP y Hermes parche sólo `providers.opencodex`. DSH corrige solo `[id=llm-pi-ai].config.providers.opencodex` en el parche de perfil de escritorio, o `llm-pi-ai.providers.opencodex` en `settings.yaml` cuando no hay perfil de escritorio. Sus redactores de YAML conservan comentarios de proveedores no relacionados y formatean byte por byte. Si ese rango de fuente exacto no se puede identificar de manera segura, la operación se niega. Para otros clientes, utilice Restaurar cuando necesite los bytes de archivo anteriores: la instantánea es una copia literal.
+
+**Si un valor no puede ser reescrito fielmente, el interruptor se niega.** El viaje de ida y vuelta cubre los tipos de valor que estos formatos usan en la práctica, y donde no lo hace - un archivo TOML usando `inf` o `nan`, por ejemplo, que el analizador sintáctico disponible para nosotros no puede leer con precisión - aplicando paradas y lo dice en lugar de escribir un valor cambiado y llamarlo éxito. Verá el archivo con nombre y nada en el disco se habrá movido. La edición de ese archivo a mano todavía funciona; es solo nuestra reescritura automática la que disminuye.
+
+Las fechas y horas TOML también rechazan las reescrituras administradas: el paso de combinación convertiría estos valores escritos en cadenas cotizadas. Esto incluye valores dentro de matrices y tablas en línea. Las cadenas de fecha citadas siguen siendo compatibles; una fecha no citada debe conservarse editando la configuración manualmente.
+
+**Pi, Kimi Code, gjc, MiniMax Code, Prime Agent, Aside, Raycast, omo y la integración DSH administrada solo funcionan contra un enlace de bucle.** Los primeros cuatro no tienen campo de configuración para el encabezado `x-opencodex-api-key` que requiere un enlace sin bucle. DSH tiene un mapa de cabeceras genérico, pero rc.6 no documenta esa cabecera de admisión dedicada como un contrato de integración compatible, por lo que el escritor administrado falla en lugar de adivinar. El bloque de proveedor de Prime Agent acepta encabezados, pero el cableado remoto de credenciales se aplaza desde su integración inicial. Dales acceso de loopback a través de un túnel SSH o un reenviador local que agregue el encabezado.
+
+**La integración OMP generada también es deliberadamente solo bucle.** OMP admite encabezados a nivel de proveedor, pero esta integración inicial no emite cableado remoto de credenciales `x-opencodex-api-key`. La configuración remota manual de OMP está fuera de la integración administrada por ahora.
+
+**Kimi El código no puede contener una referencia de entorno,** por lo que su configuración lleva un marcador de posición `opencodex-loopback` en lugar de una clave. Nunca se escribe una credencial real en ninguna configuración de cliente.
+
+**Para `ocx opencode`, el proveedor del lanzador bloquea la victoria.** Ese lanzador inyecta `provider.opencodex` y `providers.opencodex` a través de `OPENCODE_CONFIG_CONTENT`, que supera a las mismas entradas en el disco - el resto de su configuración de código abierto todavía se aplica como de costumbre. Esos bloques se construyen a partir de los mismos metadatos de modelos canónicos efectivos que las exportaciones, por lo que el lanzador y la integración administrada describen los mismos modelos, límites y opciones de razonamiento. El interruptor aquí es lo que importa cuando se inicia `opencode` directamente.
+
+<a id="from-the-terminal"></a>
+
+## Desde la terminal
+
+Las mismas operaciones están disponibles sin rumbo:
+
+```bash
+ocx integration client status
+ocx integration client enable --client hermes
+ocx integration client disable --client hermes
+ocx integration client history --client hermes
+ocx integration client restore --op <opId> [--confirm-drift]
+```
+
+<a id="opt-in-alias-model-names"></a>
+
+### Nombres de modelo con alias opcionales
+
+Hermes y Command Code aceptan `--model-names alias|routed`. El valor predeterminado es
+`routed`, independientemente de `preferModelAliasIds`. Por ejemplo:
+
+```bash
+ocx export --client hermes --model-names alias --json
+ocx integration client preview --client hermes --operation apply --model-names alias --json
+ocx integration client enable --client hermes --model-names alias
+ocx integration client enable --client commandcode --model-names alias
+```
+
+La exportación es una vista previa: usa un catálogo actual ya cargado y no escribe configuración
+del cliente ni estado de integración. Si ese catálogo no está disponible, cárgalo por separado
+y vuelve a intentarlo. `--out` escribe explícitamente un archivo de exportación; no conecta el cliente.
+
+La conexión guarda el modo. Omitir la opción al aplicar después, también desde el panel, lo conserva;
+`--model-names routed` lo restablece explícitamente. Un alias cualificado como `AC/AC-model-x`
+sustituye a `acme/vendor-model-x` solo si el enrutador demuestra que ambos llegan al mismo proveedor
+y modelo. Si faltan alias, son inseguros o hay colisiones, se usa la clave enrutada.
+Los combos conservan sus claves actuales.
+
+Tras cambiar el nombre de un alias o eliminarlo, ejecuta `ocx sync` o aplica explícitamente la conexión:
+la siguiente actualización administrada que termine correctamente sustituirá la clave anterior por
+el alias recién validado o por la clave enrutada. Editar alias no actualiza los archivos del cliente
+de forma atómica. La actualización sigue siendo idempotente y rechaza ediciones ajenas. Si un alias
+cambia mientras Aplicar o la actualización esperan, se rechaza la escritura; reintenta con el catálogo
+actual. Cada perfil con nombre de Hermes guarda su propio modo; la actualización automática del
+catálogo solo cubre el perfil predeterminado, por lo que los perfiles con nombre requieren Aplicar
+explícitamente. Los demás exportadores conservan los nombres enrutados.
+
+<a id="preview-and-bind-a-terminal-write"></a>
+
+### Previsualizar y enlazar una escritura de terminal
+
+Los comandos directos existentes siguen siendo compatibles. Para vincular una escritura a una observación revisada, inspeccione el estado y guarde primero una vista previa:
+
+```bash
+ocx integration client preview --help
+ocx integration client status --client hermes --json
+ocx integration client preview --client hermes --operation apply --json > hermes-preview.json
+```
+
+Revisa `state`, `foreignEdit`, los cambios estructurales de `changes`, `canApply` y `willChange`. Una vista previa válida que rechaza aplicar el plan, o que no propone cambios, termina con código 0: la inspección tuvo éxito y no se aplicó nada. El plan no contiene valores secretos ni el diff completo de los archivos. Usa la evidencia pasiva del catálogo ya disponible y nunca actualiza los proveedores de forma oculta. Si el catálogo no está disponible, resuelve ese problema por separado antes de solicitar otra vista previa.
+
+Solo después de revisar un plan aplicable y elegir la escritura:
+
+```bash
+PLAN_FINGERPRINT="$(jq -er 'select(.canApply == true) | .fingerprint' hermes-preview.json)"
+ocx integration client enable --client hermes --plan-fingerprint "$PLAN_FINGERPRINT" --json
+ocx integration client status --client hermes --json
+```
+
+La huella sirve para comprobar la concurrencia; no concede autorización. La confirmación acepta `pN:` seguido de 32 dígitos hexadecimales en minúscula. Un plan rechazado con `pN:unbound` no se puede confirmar. Repite exactamente el cliente, la acción, el perfil y las opciones de la vista previa. La operación `overwrite` corresponde a habilitar con `--overwrite-conflict`; `disable`, a deshabilitar. Si la observación quedó obsoleta, la confirmación sale con código 5, explica en stderr cómo obtener una nueva vista previa y deja stdout vacío. Nunca adopta automáticamente una huella de reemplazo ni reintenta. Los demás errores usan los códigos 2 para uso incorrecto, 4 para recurso no encontrado y 1 para errores de ejecución o datos mal formados, con un mensaje seguro en stderr en lugar de un objeto de error JSON.
+
+<a id="inspect-restoration-drift-before-replacing-it"></a>
+
+### Inspeccione la deriva de restauración antes de reemplazarla
+
+Utilice una historia real opId; `op-example` abajo es ficticio:
+
+```bash
+ocx integration client history --client aside --profile 1 --json
+ocx integration client restore --op op-example --client aside --profile 1 --preview --json
+```
+
+Si se rechaza la deriva, inspeccione las ediciones. Al reemplazarlos se pretende explícitamente, vista previa con `--confirm-drift`, revisar, a continuación, vincular esa misma intención:
+
+```bash
+ocx integration client restore --op op-example --client aside --profile 1 --preview --confirm-drift --json > restore-preview.json
+```
+
+Después de la revisión:
+
+```bash
+RESTORE_FINGERPRINT="$(jq -er 'select(.canApply == true) | .fingerprint' restore-preview.json)"
+ocx integration client restore --op op-example --client aside --profile 1 --confirm-drift --plan-fingerprint "$RESTORE_FINGERPRINT" --json
+ocx integration client status --client aside --profile 1 --json
+```
+
+Aparte de vista previa / escrituras vinculadas requieren un perfil, no un objetivo agregado. La restauración genérica omite el cliente/perfil; el servidor deriva el cliente no auxiliar de opId. El plan devuelto no contiene opId o todas las entradas de comandos originales, así que mantenga ese contexto. `--preview` no puede combinarse con `--plan-fingerprint`.
+
+<a id="retire-an-old-recovery-record"></a>
+
+### Retirar un registro de recuperación antiguo
+
+Esto retira permanentemente el registro y la copia de seguridad; no restaura ni deshabilita la integración. Después de inspeccionar el historial y elegir perder ese punto de recuperación:
+
+```bash
+ocx integration client history remove --op op-example --client aside --profile 1 --yes --json
+ocx integration client history --client aside --profile 1 --json
+```
+
+Use el opId realmente seleccionado. Sin selector, la operación se dirige al diario global; `--client aside`
+se dirige al historial agregado de Aside y el `--profile` opcional lo acota. Los selectores de otros clientes se rechazan para la eliminación. La fila más reciente está protegida. Un recibo con
+`snapshotRemoved:false` es una retirada confirmada con limpieza incompleta y sale con 1; no es una reversión y no debe desencadenar eliminaciones repetidas. `journal remove` es un alias.
+
+`--overwrite-conflict` es la forma terminal de **Sustituir**:
+
+```bash
+ocx integration client enable --client zcode --overwrite-conflict
+```
+
+Como `--confirm-drift`, nunca se asume - sin él un conflicto todavía se rechaza. Se aplica solo a `enable`; forzar un *desactivar* sobre un conflicto eliminaría un bloque que nunca escribimos, por lo que la combinación es rechazada.
+
+Para MiniMax Code, conecte el proveedor una vez y ejecute a través del envoltorio verificado:
+
+```bash
+ocx integration client enable --client mcode
+ocx mcode
+```
+
+Una vez conectados, `ocx sync` y `POST /api/sync` actualizan los catálogos administrados de MCode, Pi, Aside, Raycast, omo, OpenCode, Kilo y Hermes con la selección de modelos, ventanas de contexto y niveles de razonamiento actuales. Los cambios de catálogo en segundo plano también actualizan el perfil predeterminado de Hermes conectado sin intervención; si el archivo está editado y hay un catálogo pendiente, la actualización se rechaza y se informa. Una integración nunca conectada o desactivada permanece intacta. Los perfiles con nombre requieren [Aplicar explícitamente](#hermes-profiles). Al iniciarse, el proxy actualiza un catálogo Raycast bajo su control. Los cambios de visibilidad, proveedor o preajuste también actualizan los catálogos conectados de Pi, Aside, Raycast, omo, OpenCode, Kilo y Hermes.
+
+Los bloques ausentes, modificados fuera de OpenCodex o inseguros no se alteran, ni tampoco los bloques administrados que hayas eliminado manualmente. Un perfil Aside habilitado tiene una excepción: si existe su directorio de cuenta y nunca tuvo un bloque administrado, la sincronización puede crear el primero si la ranura está vacía. Una conexión Aside previa habilita este comportamiento de forma predeterminada para todos los perfiles registrados. No se crean directorios de cuenta ausentes ni se sustituyen bloques manuales. Una actualización rechazada o superpuesta se informa por cliente. Inicia una sesión nueva de Pi, OpenCode o Kilo, o cierra Aside por completo y vuelve a abrirlo para que cargue el archivo actualizado. La actualización de Aside requiere un [proxy en ejecución compatible](#aside-profile-controls).
+
+Si Models informa **"Selección de modelo guardada"** junto con una advertencia de actualización del cliente, la selección ya está guardada; no se pudieron actualizar uno o más archivos de cliente. La advertencia nombra al cliente afectado y al perfil de Aside, cuando corresponda, y explica el rechazo. Abra **Conectar** para inspeccionar ese cliente o perfil antes de comenzar una nueva sesión. Resuelva el problema reportado, luego vuelva a intentar `ocx sync`; una operación de superposición debe terminar primero. Si la advertencia incluye una ruta de respaldo o dice que la recuperación no terminó, inspeccione ese estado de recuperación antes de volver a intentarlo. Una selección exitosa guardar solo no confirma la recuperación de archivo de cliente.
+
+La plataforma separada MiniMax CLI (`mmx`) no es una integración de archivos. Sus comandos de texto usan el punto final compatible con MiniMax de Anthropic, por lo que OpenCodex proporciona un lanzador aislado de credenciales y solo loopback:
+
+```bash
+ocx mmx text chat --model anthropic/claude-opus-5 --message "Hello"
+ocx mmx text repl --model openai/gpt-5.6-sol
+```
+
+Solo se envían a través del proxy `mmx text chat` y `mmx text repl`. Ejecute `mmx` directamente para los comandos nativos de MiniMax de imagen, vídeo, voz, música, visión, búsqueda, cuota, autenticación, configuración, archivos y actualización. El contenedor utiliza una configuración temporal que contiene solo un marcador de posición de loopback no secreto; nunca carga sus credenciales OAuth o de clave API de `~/.mmx`, y rechaza las anulaciones `--api-key`, `--base-url` y `--region`. Consulte [clientes MiniMax](/es/guides/minimax/) para conocer el flujo de trabajo y los límites completos.
+
+`--confirm-drift` nunca se asume. Si el archivo cambió después de la operación que está restaurando, el comando se niega y le dice, porque reemplazar sus ediciones más recientes es su decisión de hacer.
+
+Los detalles del cliente se verificaron con el formato de configuración de cada proyecto; consulte las notas de investigación en `devlog/_fin/260802_client_toggle_api/002_client_toggle_matrix.md` para ver qué se verificó y cuándo.
+
+<a id="aside-profile-controls"></a>
+
+## Aside controles de perfil
+
+Aparte de los controles de perfil y la actualización de Aside realizada por `ocx sync` requieren un proxy ocx en ejecución que admita las API de perfil de Aside. La actualización del CLI por sí sola no actualiza un proxy que ya se esté ejecutando. Si el proxy no está disponible o es demasiado antiguo, la operación Aside no puede completarse; el CLI nunca vuelve a escribir los archivos de perfil Aside localmente.
+
+Actualice la instalación ocx utilizada por el proxy y luego reinicie el proxy (o inícielo si se detiene). Reintentar `ocx sync` o el comando de perfil. Después de que los archivos de perfil se actualicen correctamente, salga completamente y vuelva a abrir Aside para que cargue los nuevos catálogos.
+
+```bash
+ocx integration client status --client aside --json
+ocx integration client enable --client aside
+ocx integration client disable --client aside --profile 1
+ocx integration client history --client aside --profile 1
+ocx integration client restore --client aside --profile 1 --op <opId>
+```
+
+El número de perfil es el ID de cuenta mostrado por el comando status. Omitir `--profile` en una palanca de Aside aplica el estado deseado a cada perfil registrado. Un cambio de perfil deja a los hermanos sin cambios. La configuración de sincronización deseada se guarda antes de que cambie el archivo; se informa del estado real y de cualquier rechazo para cada perfil. Un resultado parcial de una operación sobre varios perfiles no significa que todos se hayan actualizado: la CLI termina con un código distinto de cero. Deshacer restaura la intención de sincronización del perfil seleccionado, así como su archivo, por lo que una sincronización posterior no invierte silenciosamente Deshacer.
+
+El [perfil API](/es/reference/management-api/#aside-profile-controls) devuelve HTTP 200 para una operación a granel exitosa y HTTP 207 con `ok: false` si cualquier perfil se niega. Inspeccione cada entrada en `results`: los perfiles exitosos no se revierten cuando otro falla. La configuración deseada permanece guardada, así que vuelve a intentarlo después de abordar el perfil afectado en lugar de asumir que todo el cambio falló. Si se produce un error al guardar esas configuraciones, no se cambiarán los archivos de perfil.
+
+Para una actualización específica de los perfiles de Aside elegibles, en lugar de una amplia sincronización de catálogo:
+
+```bash
+ocx integration client sync --client aside --json
+ocx integration client status --client aside --json
+```
+
+Esto utiliza el propietario atestado existente de Aside y no tiene selector de perfil ni reserva local. `{results:[]}` sale con 0 y significa que no hay perfiles elegibles, no que se hayan aplicado escrituras. Cualquier fila fallida devuelve 1 mientras los perfiles correctos permanecen actualizados. Conserve el rechazo por perfil, la información residual y la información de copia de seguridad redactada etiquetada por separado; inspeccione el perfil afectado antes de reintentar. Esta actualización es independiente del flujo de trabajo vinculado de previsualización/mutación de cada perfil.
+
+Sincronizar actualiza solo los perfiles cuya preferencia de sincronización está activada, por lo que un resultado vacío no es un error. Si `ocx integration client status --client aside` muestra un perfil como `off (stale)`, el estado imprime los comandos para volver a conectarlo: revise `ocx integration client preview --client aside
+--operation apply --profile N` y ejecute `ocx integration client enable --client aside --profile N` solo si la vista previa permite el cambio y usted lo acepta. Nada se vuelve a habilitar automáticamente. Un bloque `asideProfileSync` mal formado en `config.json` desactiva cada perfil y registra una advertencia cuando se carga la configuración.
+
+Cada perfil tiene una propiedad e historia separadas. Se rechazan las ediciones de usuarios existentes, las rutas inseguras y los catálogos vinculados; los controles explícitos existentes de sobreescritura y confirmación de deriva permanecen disponibles. Sal completamente de Aside y vuelve a abrirlo para que cargue los archivos de modelos actualizados.
+
+
+<a id="zcode-314-and-later"></a>
+
+## ZCode 3.14 y posteriores
+
+De forma predeterminada, ZCode 3.14 almacena sus proveedores personalizados en `~/.zcode/v2/provider_config.json` y deja `~/.zcode/v2/config.json` accesible solo a través de una importación de una sola vez que se ejecuta cuando falta el nuevo archivo. ZCode crea el nuevo archivo la primera vez que se ejecuta, por lo que en cualquier instalación que se haya lanzado, la importación ya está gastada y una escritura a `config.json` no alcanza nada.
+
+ZCode puede reubicar su raíz de datos con un `dataBaseDir` absoluto en `~/.zcode/v2/setting.json`. Este archivo bootstrap siempre se queda bajo la casa predeterminada; el almacén del proveedor se mueve a `<dataBaseDir>/.zcode/v2/provider_config.json`. `ZCODE_DATA_DIR` tiene prioridad y nombra directamente la raíz `.zcode`, mientras que `ZCODE_PERSONAL_PROVIDER_CONFIG_FILE` tiene prioridad para el archivo del proveedor. `ZCODE_DATA_BASE_DIR` es un selector nativo separado y no es un alias para `ZCODE_DATA_DIR`.
+
+Los ajustes de arranque ilegibles, mal formados o relativos dejan la raíz activa desconocida. El arranque debe ser un archivo regular de como máximo 4 MiB; los enlaces simbólicos y los archivos especiales se rechazan durante el descubrimiento de la ruta de integración y exportación. Repare el archivo bootstrap o proporcione un `ZCODE_DATA_DIR` explícito para seleccionar la raíz de datos deseada. Aplicar, sobrescribir y actualizar rechazan la operación e indican cómo repararla, en lugar de afirmar que se escribió correctamente en el almacén heredado. Un archivo de proveedor explícito existente todavía puede establecer el almacén activo. La propiedad registrada en la configuración o tienda predeterminada original mantiene su trayectoria, huellas dactilares e historial de deshacer; deshabilitar elimina ese bloque original antes de que una habilitación posterior pueda usar la tienda reubicada. Un viejo deshacer también se niega, mientras que otro camino es dueño de la integración. Si un selector explícito anterior ya no identifica el archivo propio, restaure ese selector antes de deshabilitarlo; opencodex retiene el registro y se niega a abandonar el bloque.
+
+opencodex escribe `provider_config.json` directamente donde puede. Al habilitar la integración se agrega la regla del proveedor `opencodex` a ese archivo, una actualización del catálogo lo actualiza y la desactivación elimina exactamente lo que opencodex puso allí. Todas las demás reglas en el archivo se dejan solas, incluida una regla que otro proveedor mantiene para un ID de modelo que también aparece en la nuestra. Una regla que lleva el id `opencodex` que opencodex no escribió es un conflicto más bien que algo para asumir; resolverlo en ZCode o usar el sobrescribir explícito.
+
+Un almacén de proveedor ilegible o que no es de archivos también se niega a escribir; no se trata como un almacén ausente que permite la importación heredada.
+
+Otras dos situaciones aún se niegan en lugar de escribir. Un bloque opencodex aplicado antes de que ZCode moviera su tienda mantiene la integración en `config.json`: desactívelo allí primero, luego habilitelo nuevamente para escribir la nueva tienda. Y un `provider_config.json` cuyo `schemaVersion` no es uno opencodex ha observado se informa en lugar de fusionarse, porque ese archivo contiene todos los proveedores que ZCode tiene y afirmar una forma en él cambiaría una opción silenciosa por una pérdida silenciosa. El estado nombra el archivo que ZCode lee cuando la integración no lo está escribiendo.
+
+En ese segundo caso, agregue el proveedor en la configuración de ZCode: URL base `http://127.0.0.1:10100/v1` (ajuste el puerto a su enlace), cualquier clave no vacía y los ID de modelo de `ocx export --client zcode`. La eliminación de `provider_config.json` para volver a activar la importación de ZCode no es compatible: descarta todos los proveedores que ZCode mantiene allí.
+
+## Cline CLI
+
+Esta integración se dirige al almacén de proveedores CLI /shared SDK de Cline, cuyo esquema nativo tiene `version: 1`. La extensión `globalState` /secret no se migra ni se detecta como esta integración. Ejecute Cline una vez para inicializar su directorio de configuración.
+
+**Detenga Cline antes de habilitar, sincronizar, deshabilitar o restaurar la integración.** OpenCodex escribe `providers.opencodex` tanto en `providers.json` como en el hermano `models.json`. El primer archivo contiene la conexión OpenAI Responses con un marcador de posición de bucle de retroceso no secreto; el segundo contiene el catálogo de modelos enrutados filtrados, incluyendo el contexto disponible y los metadatos de imagen. Las entradas de proveedor existentes y la selección de proveedor predeterminada permanecen sin cambios.
+
+```bash
+ocx integration client list --json
+ocx integration client enable --client cline
+ocx integration client history --client cline
+ocx integration client restore --op <operation-id>
+```
+
+Después de habilitar, reinicie Cline y seleccione OpenCodex, o inicie con `cline --provider opencodex --model <provider/model>`. Los cambios de catálogo externos se leen cuando Cline se reinicia. Cline se excluye de la actualización de catálogo desatendida; después de cambiar la selección del modelo enrutado, detenga Cline y ejecute `ocx sync` o habilite la integración nuevamente para actualizarla. Un modelo seleccionado se conserva mientras sigue siendo encaminado y borrado si se elimina del catálogo exportado.
+
+`CLINE_PROVIDER_SETTINGS_PATH` anula el archivo principal. De lo contrario, `CLINE_DATA_DIR` selecciona el directorio de datos, luego `CLINE_DIR` selecciona la raíz, luego se usa `~/.cline`. El archivo de modelo es siempre `models.json` junto al archivo de proveedor seleccionado. Las anulaciones deben ser absolutas o comenzar con `~`. El comando Mirror-local Cline `--config` traza con `CLINE_PROVIDER_SETTINGS_PATH` cuando se inicia OpenCodex. Se rechaza una ruta primaria llamada `models.json` porque los archivos deben ser distintos.
+
+Cada reemplazo de archivos es atómico, pero ninguna operación del sistema de archivos reemplaza a ambos simultáneamente. Una operación de diario captura ambos archivos originales; un error de escritura o contabilidad compensa ambos. Una operación interrumpida conserva un registro de recuperación privado. Informes de estado de recuperación incompleta como inseguro, y la siguiente mutación explícita se recupera sólo si ni el archivo ni su propiedad tiene una edición no relacionada. Si la recuperación se niega, preservar los archivos y la ruta de recuperación reportada por la operación; resolver el conflicto antes de volver a intentar.
+
+Deshacer restaura **ambas cadenas de bytes originales**, incluyendo un archivo que originalmente no existía. Las ediciones después de la operación requieren el `--confirm-drift` explícito existente; primero se realiza una copia de seguridad del par editado. Una entrada OpenCodex ocupada requiere la opción `--overwrite-conflict` existente. Deshabilitar elimina las dos entradas administradas; no restaura una entrada externa anterior. Usa Deshacer para eso. La retención y caducidad de instantáneas siguen las mismas reglas que otras integraciones.
+
+La descarga `cline-config-bundle.json` contiene dos miembros nativos del documento: `settings` para `providers.json`, y `catalog` para `models.json`. No es en sí mismo un archivo de configuración de Cline. Prefiera el comando de integración para una combinación y una reversión con journal. El cableado de admisión remota no es compatible con esta integración generada; requiere acceso de bucle de retorno no autenticado.
+
+<a id="github-copilot-app"></a>
+
+## GitHub Copilot App
+
+La aplicación de escritorio GitHub Copilot puede usar opencodex como proveedor de modelos compatible con OpenAI. Esta es una configuración manual del cliente sin interruptor en **Conectar**, y es independiente del proveedor de `github-copilot` aguas arriba, que utiliza una suscripción Copilot como backend para opencodex.
+
+1. Inicie opencodex y confirme que responde:
+
+   ```bash
+   curl http://127.0.0.1:10100/healthz
+   curl http://127.0.0.1:10100/v1/models
+   ```
+
+2. En la aplicación Copilot, abre **Configuración → Proveedores de modelos → Añadir proveedor** e ingresa:
+
+   | Campo | Valor |
+   |---|---|
+   | Nombre | cualquier etiqueta, por ejemplo `OpenCodex` |
+   | URL base | `http://127.0.0.1:10100/v1` (ajustar el puerto a su enlace) |
+   | Clave API | Dejar en blanco en loopback |
+
+3. Sincronice modelos desde el punto final, o agregue uno por su id `provider/model`, y selecciónelo.
+
+La aplicación utiliza `GET /v1/models` para el descubrimiento y `POST /v1/chat/completions` para los giros. Esos turnos pasan por el modelo de enrutamiento normal de opencodex, por lo que las credenciales del proveedor, las cuentas OAuth y los combos se aplican como lo hacen para cualquier otro cliente. Los campos de solicitud aceptados se enumeran en el [Referencia de formatos proxy](/es/reference/proxy-formats/).
+
+Si la aplicación informa que no hay modelos, compruebe que la URL base termina en `/v1` en lugar de `/v1/chat/completions` y que `/v1/models` devuelve una matriz `data` no vacía. Cuando opencodex escucha en una dirección que no es de bucle, ponga una clave de admisión de datos (el token descrito en [acceso remoto](/es/reference/configuration/server/#remote-access), o una clave `ocx_…` generada en el panel de control) en el campo de clave API de la aplicación. La aplicación lo envía como `Authorization: Bearer`, que `/v1/chat/completions` acepta como admisión proxy y nunca reenvía aguas arriba; ver el [matriz de autenticación](/es/reference/proxy-formats/#authentication-matrix).
+
+<a id="omo-codex--lazycodex-role-models"></a>
+
+## modelos de rol omo (Codex / LazyCodex)
+
+Cuando LazyCodex está instalado, la pestaña omo muestra una sección **omo (Codex / LazyCodex)** debajo de los controles omo basados en Pi, enumerando cada función de agente Codex que se encuentra en `$CODEX_HOME/agents/*.toml`, con el modelo al que está anclado cada uno. Codex ejecuta un rol en ese pin sin importar qué modelo pida el padre, así que aquí es donde se decide realmente el modelo de un rol. LazyCodex cuenta como instalado cuando el plugin `omo@sisyphuslabs` Codex está habilitado en `$CODEX_HOME/config.toml` y una copia instalada bajo `$CODEX_HOME/plugins/cache/sisyphuslabs/omo/` contiene su manifiesto de plugin o `lazycodex-install.json`. Una carpeta `~/.omo` por sí sola no cuenta, porque el omo basado en Pi también lo crea. Sin LazyCodex, la sección está oculta y la línea de comandos informa que no está instalada. Elija un modelo y un esfuerzo de razonamiento en una fila y presione Guardar. Una fila cuyo rol no tiene un modelo fijado puede guardar solo el esfuerzo de razonamiento; el rol sigue heredando su modelo:
+
+- opencodex actualiza solo las claves raíz `model = "..."` y `model_reasoning_effort = "..."` del archivo de ese rol. Las clavijas que faltan se insertan cerca de la parte superior. La elección de **Heredar el esfuerzo**, disponible en cada fila, envía `"effort": null` para borrar el pin de esfuerzo, eliminando su línea y el comentario final. Las instrucciones del papel, otros comentarios y otras claves se dejan exactamente como estaban.
+- El modelo está escrito a `[codex].agents.<role>.model` en `~/.omo/omo.jsonc`, que LazyCodex 5.1.1 y posteriores leen, y un esfuerzo cambiado LazyCodex soporta va a `[codex].agents.<role>.reasoning` en la misma entrada. Si ese archivo no existe, no se crea. Si contiene comentarios, se deja sin tocar, porque guardarlos los eliminaría; la pestaña lo dice y puede establecer el valor allí a mano. Los symlinks y archivos no regulares son rechazados; en macOS y Linux, una FIFO es rechazada sin esperar a un escritor. Un espejo omitido no deshace el archivo de rol guardado.
+
+Si el archivo de rol guardado tiene éxito pero la escritura omo.jsonc falla, el botón de la fila se convierte en **Reintentar omo.jsonc**, que reenvía la misma opción de esfuerzo, incluyendo un borrado **Heredar el esfuerzo** (`null`). Hasta que ese reintento tenga éxito, una solicitud posterior de Guardar o Asignación automática para el rol que deja el esfuerzo solo lleva consigo la elección pendiente; un esfuerzo explícitamente elegido toma su lugar.
+
+Nada sucede hasta que presiona Guardar; la sincronización o el reinicio de opencodex nunca cambia un archivo de rol. Las nuevas Codex sesiones recogen el cambio. Los mismos controles existen en la línea de comandos:
+
+```bash
+ocx agent roles
+ocx agent roles set explorer xai/grok-4.5
+```
+
+`ocx agent roles set <role> <model> --effort <level>` también establece el esfuerzo de razonamiento del rol: inserta o reemplaza el valor `model_reasoning_effort` del archivo de rol y escribe `[codex].agents.<role>.reasoning` en omo.jsonc cuando LazyCodex tiene ese nivel (`ultra` permanece solo en el archivo de rol y se elimina un `reasoning` anterior). En `PUT /api/codex-agent-roles/{role}`, omitiendo `effort` mantiene el pin, un nivel lo establece, y `null` elimina la línea `model_reasoning_effort` del archivo de rol, su comentario final y el omo.jsonc `reasoning`. A Guardar que cambia solo el modelo deja ambos valores de esfuerzo como estaban. Omitir `model` deja el pin `model` del archivo de rol y el omo.jsonc `model` exactamente como estaban, por lo que un rol sin un pin sigue heredando su modelo mientras su esfuerzo cambia o se borra; el tablero de instrumentos envía esta solicitud de solo esfuerzo para tal fila. Cuando omo.jsonc puede ser escrito, un rol sin una entrada obtiene uno que contenga solo `reasoning` si el esfuerzo guardado es compatible con LazyCodex (`none` se escribe como `off`); para tal rol, despejar el esfuerzo o guardar `ultra` no agrega entrada. Se rechaza un modelo `null` con 400 `invalid_model`, porque un guardado nunca elimina un pin de modelo, y se rechaza una solicitud con ni `model` ni `effort` con 400 `empty_update` antes de que se lea el archivo de rol u omo.jsonc. `ocx agent roles set` siempre toma un modelo. Solo se puede eliminar un valor de cadena de una línea existente; se rechaza un valor multilínea o no de cadena con 409 `unsupported_model_value`, dejando ambos archivos sin cambios. El borrado elimina solo la anulación propia del rol: Codex resuelve el esfuerzo como lo hace para cualquier rol sin uno (un valor de generación explícito, el valor predeterminado `[agents]` o la sesión principal), no un modelo predeterminado fijo.
+
+<a id="auto-assign"></a>
+
+### Asignación automática
+
+Auto-assign es parte de omo (Codex / LazyCodex): se encuentra por encima de la tabla de roles en esa sección y existe solo mientras se detecta LazyCodex. Sin él, el tablero de instrumentos no muestra ninguno, el API responde 409 `lazycodex_not_detected` y `ocx agent roles suggest` es rechazado.
+
+La asignación automática propone un modelo para cada rol a la vez. OpenCodex consulta al modelo predeterminado de Codex (la raíz `model` en su `config.toml`): según la descripción y el inicio de las instrucciones de cada rol, ¿qué nivel de capacidad (fast, standard o frontier), esfuerzo de razonamiento (glance, measured, thorough o exhaustive) y dominio de tarea (coding, agentic, reasoning, writing, knowledge o general) necesita? Ese modelo no elige otro modelo: OpenCodex selecciona después el más económico del selector que alcance el nivel necesario:
+
+- Los modelos incluidos en `codexRoleTiers` de la configuración (`{ "fast": [...], "standard": [...], "frontier": [...] }`) reciben ese nivel.
+- Si al menos dos de los demás modelos tienen una puntuación publicada para el dominio del rol, se clasifican por sus valores distintos, sin exigir precio. Puntuaciones iguales comparten nivel y se excluyen los modelos sin puntuación. Las puntuaciones proceden de [Artificial Analysis](https://artificialanalysis.ai) si proporcionas tu propia clave API (véase abajo). Artificial Analysis ya no publica un índice Coding ni Agentic, por lo que todos los dominios usan su Intelligence Index. El bloque `capability` de la respuesta identifica la fuente utilizada.
+- Los otros modelos con precio conocido se ordenan por precio y se reparten entre los tres niveles. Si solo hay uno o dos, el más caro es frontier y el otro, si existe, standard.
+- Cuando se recurre a la clasificación por precio, no se proponen modelos sin precio ni nivel configurado. Inclúyelos en la configuración si quieres utilizarlos.
+
+Para usar Artificial Analysis, crea una clave API gratuita en [artificialanalysis.ai](https://artificialanalysis.ai/data-api/docs) y configúrala como valor literal, referencia `${ENV}` o referencia del llavero:
+
+```json
+{
+  "codexRoleCapability": {
+    "artificialAnalysis": { "apiKey": "${ARTIFICIAL_ANALYSIS_API_KEY}" }
+  }
+}
+```
+
+opencodex consulta la lista gratuita de modelos de lenguaje (`/api/v2/language/models/free`) una vez al día, con una solicitud por página, dentro del límite diario del nivel gratuito. Sus términos permiten usar los datos para decisiones propias y prohíben redistribuirlos, por lo que la asignación automática mantiene las puntuaciones internas: la respuesta incluye el nivel asignado y la atribución, sin puntuaciones. Si falta la clave o falla la lectura, se usan los niveles y precios configurados; `capability.error` indica el motivo y los campos de atribución de la fuente son null. Se ignora la opción retirada `huggingFace`.
+
+Artificial Analysis rechaza redirecciones HTTP, lee como máximo diez páginas y 16 MiB en total, y limita cada solicitud a 30 segundos. Una lista más larga se considera una lectura fallida. Las credenciales se envían únicamente a su endpoint API fijo.
+
+Cada propuesta muestra el modelo, el nivel, el esfuerzo de razonamiento, una razón de una línea y lo que lo movería hacia arriba o hacia abajo. Un papel que el modelo no podría dimensionar claramente se muestra como no dimensionado, con la razón, y no se puede aplicar. No se escribe nada hasta que presione Aplicar en una fila o Aplicar todo. La aplicación utiliza el mismo guardar como picking a mano. Cada rol de tamaño cuyo modelo elegido tiene una escalera de esfuerzo no vacía recibe una propuesta de esfuerzo, y Aplicar o `--apply` inserta o reemplaza su valor `model_reasoning_effort`. El esfuerzo se coloca en los propios niveles del modelo elegido: su más bajo, su predeterminado, uno por encima del predeterminado o su más alto. Una escalera vacía no da ninguna propuesta de esfuerzo (`proposedEffort: null`); Aplicar omite `effort` y deja cualquier pin de esfuerzo existente como estaba. Una propuesta nula nunca borra un alfiler.
+
+```bash
+ocx agent roles suggest
+ocx agent roles suggest --model xai/grok-4.5 --apply
+```
+
+La CLI admite con `--apply` hasta 50 roles modificados en un único lote de historial. Si la operación es mayor, la rechaza antes de actualizar ningún rol: revisa la propuesta y aplica decisiones individuales con `ocx agent roles set`. Si se interrumpe, informa de las escrituras confirmadas y de la solicitud sin confirmar, y conserva las escrituras anteriores. Consulta el [contrato de aplicación y recuperación de la CLI](/es/reference/cli/agents/) antes de reintentar.
+
+Debajo de la tabla, **Historial de cambios** muestra los cambios más recientes escritos al guardar,
+aplicar una asignación automática o ejecutar `ocx agent roles set`, del más nuevo al más antiguo,
+en lotes completos y hasta un máximo de 50. Así, una operación Aplicar todo aparece con todos los
+roles que escribió o no aparece: se muestran el modelo y el esfuerzo de cada rol antes y después.
+Cada Aplicar todo cuenta como una entrada. **Restaurar** recupera los valores anteriores mediante
+el mismo guardado, de modo que la restauración también queda registrada. Guardar nunca elimina
+un modelo fijado: un rol que antes no tenía uno conserva su modelo actual y solo recupera el esfuerzo.
+El historial se guarda en `integrations/codex-agent-roles.jsonl`, dentro del directorio de configuración
+de opencodex, con un límite de 256 KiB y 1000 filas; se eliminan los lotes completos más antiguos.
+La compactación busca reducirlo a 128 KiB y conserva una restauración junto con su lote de origen
+completo si ambos caben en los dos límites, descartando otros lotes anteriores para hacer espacio.
+El historial puede caducar con escrituras posteriores. Antes de añadir entradas, el escritor captura
+el historial acotado para que una restauración no expulse su propio origen al alcanzar el límite.
+El centro de restauración de la tarjeta omo descrito antes solo sigue `~/.omo/agent/models.json`.
+Cada cambio registra el directorio de Codex donde se hizo; solo se muestran y restauran los cambios
+del directorio actual. Al cambiar `CODEX_HOME`, la lista empieza vacía y se rechaza restaurar desde
+el historial de otro directorio. Si no se puede leer el archivo, la sección lo indica en lugar de
+mostrar la lista, y la tabla de roles sigue funcionando.
+
+## Kilo
+
+Kilo CLI, VS Code y JetBrains comparten una configuración global. Esta integración escribe `provider.opencodex` en el primer archivo existente entre `kilo.jsonc`, `kilo.json`, `opencode.jsonc`, `opencode.json` y `config.json` en `~/.config/kilo` (`XDG_CONFIG_HOME` reubica ese directorio). Si no existe, el destino es `kilo.jsonc`. Las configuraciones del proyecto nunca se escriben. Kilo fusiona todos estos archivos globales. Si otro candidato también define `provider.opencodex`, el estado nombra todos los archivos competidores y Aplicar y Reemplazar rechazo; elimine `provider.opencodex` de esos archivos antes de habilitar la integración. Un candidato ilegible o inseguro también bloquea la escritura. Deshabilitar aún puede eliminar un bloque perteneciente al archivo grabado mientras otro candidato entra en conflicto o no se puede analizar; el otro candidato se deja intacto.
+
+OpenCodex lee estos archivos candidatos como JSONC. Un comentario de línea `//` termina con CR,
+LF o CRLF, por lo que los ajustes posteriores al comentario se conservan con cualquiera de esos finales de línea.
+
+El fragmento de propiedad es solo `provider.opencodex` (forma OpenCode V1: `npm`, `options`, `models`). El esquema publicado de Kilo no tiene la clave OpenCode V2 `providers`, por lo que el bloque no se emite; Kilo recibe las opciones de razonamiento por modelo como un mapa variante dentro de su bloque de proveedor, construido a partir de los mismos metadatos canónicos efectivos que la exportación de OpenCode. `$schema`, `model`, `enabled_providers`, MCP, y otras claves permanecen propiedad del usuario. Seleccione `opencodex/<provider/model>` en Kilo después de aplicar.
+
+Loopback utiliza `{env:OPENCODEX_KILO_API_KEY}` como `options.apiKey`. Un enlace sin bucle retro mueve la admisión a `options.headers["x-opencodex-api-key"]` y nunca serializa una clave real. Apply reescribe todo el archivo global como bastante JSON, por lo que los comentarios y las comas posteriores en otras claves no se conservan. Kilo está en el catálogo de salida implícita: `ocx
+sync`, `POST /api/sync`, y visibilidad, proveedor, o cambios preestablecidos actualizar un bloque de Kilo propiedad bajo las mismas reglas de propiedad segura como cualquier otro cliente, y una nueva sesión de Kilo carga el archivo actualizado.
+
+Al leer estos archivos candidatos, OpenCodex acepta una coma final tras un elemento de un array
+o una propiedad de un objeto. Escribe los arrays y objetos vacíos como `[]` o `{}`;
+`[,]` y `{,}` se rechazan por estar mal formados.
+
+```bash
+ocx integration client enable --client kilo
+ocx export --client kilo --out ./kilo.jsonc
+```
+
+<a id="command-code"></a>
+
+## Command Code
+
+Command Code mantiene sus proveedores personalizados en `~/.commandcode/providers.json`. Esta integración escribe `provider.opencodex` en ese archivo y es solo loopback.
+
+**Qué raíz escribe.** Command Code resuelve su mapa de proveedores como
+`document.provider ?? document.providers`, así que la raíz singular gana siempre que exista. Por eso la integración lee primero el archivo de destino y escribe en la raíz que ese archivo ya usa: un documento que ya lleva un mapa `providers` lo conserva y tus otros proveedores siguen siendo legibles. Un archivo nuevo recibe la raíz singular `provider`.
+Ambas raíces se declaran como rutas administradas, de modo que Deshabilitar elimina el bloque de aquella en la que se escribió.
+
+**La forma de credencial.** El proveedor está escrito con `apiKey: false`, la forma documentada para un punto final que no necesita clave. Command Code rechaza una cadena sin procesar, y esta integración no lee, hace referencia ni exporta ningún archivo de token de servicio.
+
+**Resolución del home.** Aquí no hay ninguna anulación `COMMANDCODE_HOME`. El cliente publicado resuelve `HOME ?? USERPROFILE` y luego añade `/.commandcode/providers.json`; no consulta esa variable. Una anulación que esta integración respetara pero el cliente ignorara haría que Aplicar informara de un éxito en una ruta que Command Code nunca abre, así que la ruta es siempre `~/.commandcode/providers.json`.
+En Windows con el home predeterminado, la integración usa `HOME ?? USERPROFILE`
+solo cuando el valor seleccionado no está en blanco y es una ruta absoluta de Windows; de lo contrario, usa
+`homedir()`. Un home proporcionado por separado se conserva. Por lo tanto, un `HOME` establecido por Git para
+Windows o MSYS2 solo se respeta cuando pasa esas comprobaciones.
+
+Pegue la clave usted mismo si más adelante saca el proveedor de loopback: Command Code almacena las claves en `~/.commandcode/auth.json` (a través de `/connect`), no en `providers.json`.
+
+```bash
+ocx integration client enable --client commandcode
+ocx export --client commandcode --out ./providers.json
+```
+
+`ocx commandcode restore --op <opId>` acepta solo Command Code operaciones, incluyendo `--preview` y `--plan-fingerprint` solicitudes. Rechaza las anulaciones de cliente/perfil. El proxy en ejecución debe admitir la restauración con alcance de cliente; los proxies más antiguos devuelven un error sin volver al extremo de restauración genérico. Utilice `ocx integration client restore` para la revista genérica y los comandos de perfil explícitos de Aside anteriores para las operaciones de Aside.
+
+## Factory Droid
+
+Ejecute Droid una vez para crear `~/.factory`, luego habilite explícitamente esta integración con `ocx integration client enable --client droid`. OpenCodex agrega solo `customModels` entradas documentadas a su `settings.json` personal, utilizando un punto final Chat Completions local sin llave. Elija una fila del selector `/model` de Droid. Deshabilitar elimina las filas administradas; Deshacer restaura el archivo guardado exacto. Otros ajustes y modelos personalizados siguen siendo suyos. Si Droid normaliza una fila `customModels` agregando `id` o `index`, OpenCodex ignora esos dos campos de cliente al verificar la propiedad, por lo que los valores predeterminados de razonamiento guardados permanecen disponibles.
+
+Abra **Conectar → Factory Droid** (`/#integrations/droid`) para establecer un razonamiento predeterminado para cada modelo conectado. Elija entre los esfuerzos compatibles del modelo, revise los cambios y luego confirme. **Sin valores predeterminados** borra la configuración de borrador de ese modelo; use **Guardar / revisar cambios** y confirme para aplicar la eliminación. Los modelos sin una lista de esfuerzo declarada muestran que no hay ningún valor predeterminado disponible.
+
+El CLI admite los mismos valores predeterminados en Droid apply/overwrite. Por ejemplo, reemplace el modelo ficticio de abajo con un ID conectado exacto y esfuerzo soportado:
+
+```bash
+ocx integration client preview --client droid --operation apply --reasoning-default example/model-a=high --json > droid-preview.json
+```
+
+Después de revisar el plan aplicable y elegir la escritura:
+
+```bash
+DROID_FINGERPRINT="$(jq -er 'select(.canApply == true) | .fingerprint' droid-preview.json)"
+ocx integration client enable --client droid --reasoning-default example/model-a=high --plan-fingerprint "$DROID_FINGERPRINT" --json
+ocx integration client status --client droid --json
+```
+
+Repita `--reasoning-default MODEL=EFFORT` para enviar el mapa de reemplazo completo. El último signo igual separa el modelo y el esfuerzo; se conservan las mayúsculas y minúsculas y los ids exactos. Las claves de modelo duplicadas se rechazan. Las banderas omitidas preservan los valores predeterminados; `--clear-reasoning-defaults` envía explícitamente un mapa vacío. Para borrar, previsualice con esa bandera y repítala en el comando de habilitación correspondiente. Borrar y añadir entradas no se pueden combinar. Estos indicadores son exclusivos de Droid y no se aplican a deshabilitar/restaurar. Repita el mismo mapa en la vista previa y confirmación; el servidor valida los esfuerzos específicos del modelo y rechaza la vinculación obsoleta en lugar de aceptar silenciosamente un mapa cambiado.
+
+Para una clara intención completa, previsualizar esa acción separada:
+
+```bash
+ocx integration client preview --client droid --operation apply --clear-reasoning-defaults --json > droid-clear-preview.json
+```
+
+Después de revisarlo y elegirlo:
+
+```bash
+DROID_CLEAR_FINGERPRINT="$(jq -er 'select(.canApply == true) | .fingerprint' droid-clear-preview.json)"
+ocx integration client enable --client droid --clear-reasoning-defaults --plan-fingerprint "$DROID_CLEAR_FINGERPRINT" --json
+```
+
+El valor predeterminado se aplica solo cuando Droid omite un esfuerzo de su solicitud. Un esfuerzo explícito de solicitud tiene prioridad sobre este valor predeterminado; los pines y límites existentes de OpenCodex aún se aplican. Droid puede continuar visualizando **Dinámico** incluso cuando OpenCodex aplica el valor predeterminado configurado. Las solicitudes sin el encabezado predeterminado Droid no se ven afectadas; el encabezado es una preferencia de solicitud, no una prueba de identidad del cliente. Para combos y políticas de enrutamiento, cada destino concreto comprueba la preferencia en contra de su propia lista de esfuerzo, por lo que un primer objetivo incompatible no lo elimina de una reserva compatible.
+
+Un valor predeterminado guardado que el modelo enrutado ya no admite se ignora para las solicitudes. Si la lista de esfuerzo declarada del modelo conectado ya no incluye el valor guardado, se omite de los valores predeterminados del panel y se elimina de la fila administrada al actualizar. La revisión sin edición permite que OpenCodex conserve los valores predeterminados compatibles restantes.
+
+Actualizar conserva los valores predeterminados mientras el selector exacto `provider/model` permanece conectado y declara el esfuerzo guardado. Renombrar un proveedor, modelo o alias combinado reemplaza esa fila administrada y borra su valor predeterminado; elija un valor predeterminado para la fila renombrada nuevamente. Deshabilitar elimina los valores predeterminados con las filas del modelo administrado y Deshacer restaura las filas guardadas y sus valores predeterminados juntos.
+
+Los modelos cuyos ID o nombres de visualización contienen `,` o `]` se omiten porque el selector administrado no puede abordarlos de forma segura; la configuración de exportación y administrada muestra las mismas filas. Se rechaza un catálogo no vacío sin modelos direccionables.
+
+Droid también lee el legado `config.json` y el local `settings.local.json`. Resolver filas heredadas que usan el punto final OpenCodex, un ID de modelo generado o un nombre de visualización `OpenCodex:` y cualquier anulación local `customModels`, antes de habilitar; OpenCodex rechaza esos ajustes ambiguos. También rechaza un objetivo inseguro o una fila editada desde que se aplica. La integración es solo loopback y nunca copia las credenciales del proveedor. La fábrica documenta el [Esquema BYOK](https://docs.factory.ai/model-independence/byok) y [configuración personal](https://docs.factory.ai/droid-cli/settings).
+
+
+**Command Code Desktop necesita su propio inicio de sesión.** Comprueba `~/.commandcode/auth.json` o `COMMAND_CODE_API_KEY` antes de mostrar un espacio de trabajo; sin ellos se queda en login. Inicia sesión allí o con `cmd login` una vez. OpenCodex nunca escribe `auth.json`: contiene credenciales reales de Command Code y otros proveedores. Activar, aplicar, reemplazar, refrescar catálogo o desactivar solo administra `providers.json` y deja ese almacén idéntico byte a byte, sin escribir el placeholder en él.
+
+T3 Code recibe IDs `provider/model` exactos y la escala declarada de esfuerzo, para elegirla y crear subagentes. Si la vista previa no tiene catálogo cargado, **Cargar catálogo y reintentar** lo lee por la carga ordinaria de la lista, no por una vista previa que lo recopile, y vuelve a pedir el plan. Aside aplica el mismo flujo a un perfil cada vez; un plan no cubre varios archivos independientes. Un conflicto abre **Conectar → Aside → Elegir perfil**; **Sincronizar todos los perfiles** es otra acción masiva sin un plan combinado.
diff --git a/docs-site/src/content/docs/es/guides/lm-studio.md b/docs-site/src/content/docs/es/guides/lm-studio.md
new file mode 100644
index 00000000000..64c55f57af5
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/lm-studio.md
@@ -0,0 +1,40 @@
+---
+title: Plantillas de chat estrictas de LM Studio
+description: Configura un único mensaje de sistema al principio para los modelos Chat de LM Studio.
+---
+
+El preajuste **LM Studio (local)** activa `singleLeadingSystemMessage: true` para
+el adaptador `openai-chat`. Esto reúne las instrucciones de sistema y de desarrollador
+que solo contienen texto en un único mensaje de sistema al principio, separadas por
+líneas en blanco. Admite identificadores de modelo personalizados, incluidos los sufijos
+de cuantización y de checkpoint, sin depender del selector de compatibilidad por nombre de modelo.
+
+Para un proveedor de LM Studio existente que hayas renombrado o personalizado, añade este
+booleano explícitamente en el editor de proveedores. El valor guardado es independiente del
+nombre del proveedor, el host y el puerto. Guardar en el mismo destino conserva un ajuste
+omitido; un POST que cambie el destino debe volver a enviarlo. PATCH acepta un booleano o
+`null` para eliminar la anulación. Eliminarla en el proveedor canónico de LM Studio restaura
+el valor predeterminado del preajuste.
+
+Configura `singleLeadingSystemMessage: false` para desactivar esta unión si la plantilla
+acepta mensajes de instrucciones en orden cronológico. Los demás preajustes conservan sus
+valores predeterminados. `foldDeveloperRoleToSystem` sigue controlando únicamente el rol de
+desarrollador; activar la compatibilidad con un único mensaje tiene prioridad sobre esa
+elección de rol y sobre la solución para instrucciones tardías basada en el nombre del modelo.
+
+Mover instrucciones posteriores al principio cambia su alcance cronológico y puede invalidar
+los prefijos de la caché de prompts. Las solicitudes traducidas conservan el orden de las
+instrucciones de la representación intermedia: primero los prompts de sistema base y después
+las instrucciones de desarrollador de la secuencia. El parser de Responses ya reúne los
+elementos de sistema de la entrada en el prompt base, por lo que no se recupera su posición
+original respecto a los elementos de desarrollador. El paso directo de Chat conserva el orden
+relativo original de los mensajes de sistema y desarrollador. Ambas rutas normalizan la copia
+de salida y conservan el orden de los mensajes del usuario y de los pares de herramientas.
+
+Las partes que no sean texto en mensajes de sistema o desarrollador de Chat directo producen
+un error explícito. En los documentos de desarrollador traducidos, los archivos permanecen en
+un mensaje compatible con el rol de usuario en su posición original, mientras que el texto se
+reúne en el mensaje de sistema inicial. Los mensajes de desarrollador con imágenes o audio
+conservan su conversión existente al formato compatible con el usuario. No necesitas ejecutar
+LM Studio para configurar este ajuste; la plantilla del modelo servido sigue determinando
+qué otras funciones del protocolo admite.
diff --git a/docs-site/src/content/docs/es/guides/local-plugins.md b/docs-site/src/content/docs/es/guides/local-plugins.md
new file mode 100644
index 00000000000..29d95964b22
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/local-plugins.md
@@ -0,0 +1,75 @@
+---
+title: "Plugins locales"
+description: "Cargue su propio código en el proxy al inicio para reescribir los envíos del proveedor, por ejemplo, para poner un proxy de compresión local frente a los proveedores."
+---
+
+Un plugin local es un archivo JavaScript que `ocx start` carga antes de que el proxy empiece a atender solicitudes. Puede inspeccionar cada envío al proveedor justo antes de que salga del proceso, redirigirlo o añadir encabezados. Esto permite colocar un sidecar local, como un proxy de compresión o una grabadora, delante del proveedor sin modificar opencodex.
+
+Los plugins son locales para una instalación. opencodex no los descarga, actualiza ni firma.
+
+<a id="where-plugins-live"></a>
+
+## Donde viven los plugins
+
+Ponga los archivos del plugin en `plugins/` dentro del hogar opencodex (`~/.opencodex/plugins/` o `$OPENCODEX_HOME/plugins/` cuando esa variable esté establecida):
+
+```text
+~/.opencodex/plugins/
+  my-sidecar.ts
+```
+
+- Los archivos que terminan en `.ts`, `.js` o `.mjs` se cargan en orden de nombre.
+- Los nombres que comienzan con `.` o `_`, y `*.d.ts`, se ignoran: cambie el nombre de un complemento a `_my-sidecar.ts` para apagarlo.
+- El directorio es opcional. Sin ella no hay nada cargado.
+- Un plugin se ejecuta dentro del proxy con sus credenciales, por lo que opencodex rechaza un archivo plugin o un directorio `plugins/` que es propiedad de otro usuario o escribible por grupo u otros, y rechaza enlaces simbólicos. Cada directorio por encima de `plugins/`, hasta `/`, también debe ser propiedad de usted o root y no escribirse por grupo u otros, a menos que sea pegajoso como `/tmp`. Arreglar permisos con `chmod go-w ~/.opencodex/plugins ~/.opencodex/plugins/*`; en sistemas cuya máscara predeterminada es `002`, compruebe los directorios padre también. En macOS, una concesión ACL a otro usuario o grupo que permita escribir, eliminar, cambiar permisos o añadir/eliminar entradas de la ruta impide la carga, incluso si el modo es `0600`; inspeccionar la ruta en sí con `/bin/ls -lebd -- <path>`. Solo lectura, denegación, solo herencia y concesiones solo al propietario de la ruta o al usuario en ejecución no bloquean la carga. Los nombres de visualización ACL como `root` o `0` no se tratan como prueba UID numérica. En Linux, se comprueban las ACL extendidas cuando `getfacl` está instalado. Sin ella, solo se verifican los bits de propietario y modo.
+- En Windows, la carga automática del complemento está desactivada hasta que esté disponible una verificación de confianza ACL.
+
+Reinicie el proxy después de agregar, cambiar o eliminar un plugin (`ocx service restart`, o detener e iniciar `ocx start` ). Cada plugin cargado imprime una línea `Plugin loaded: <name>` al inicio; un plugin omitido imprime una categoría de razón limitada. El texto de excepción del complemento RAW nunca se imprime automáticamente.
+
+Para empezar una vez sin plugins, establece `OCX_PLUGINS=0`.
+
+<a id="writing-a-plugin"></a>
+
+## Escribir un plugin
+
+El módulo debe exportar por defecto un objeto con una propiedad opcional `name` de tipo cadena y una función `setup`, que recibe el contexto. Un `setup` asíncrono dispone de cinco segundos para terminar. Los plugins se ejecutan en el mismo hilo que el proxy: si `setup` bloquea de forma síncrona, no se puede interrumpir y retrasa el inicio hasta que termine. Agotar el plazo tampoco detiene sus servidores o temporizadores ya iniciados. Inicia los recursos de larga duración únicamente después del trabajo que pueda fallar:
+
+```ts
+interface UpstreamTarget {
+  url: string;            // absolute upstream URL; assign a new one to redirect
+  headers: Headers;       // outbound headers, including credentials — never log them
+  readonly transport: "http" | "websocket";
+}
+
+export default {
+  name: "my-sidecar",
+  setup(ctx: {
+    log(message: string): void;
+    registerUpstreamRewriter(rewrite: (target: UpstreamTarget) => void): void;
+    onShutdown(teardown: () => void): void;
+  }) {
+    ctx.registerUpstreamRewriter(target => {
+      const upstream = new URL(target.url);
+      if (!upstream.pathname.endsWith("/chat/completions")) return;
+      target.url = `http://127.0.0.1:9000${upstream.pathname}${upstream.search}`;
+      target.headers.set("x-original-origin", upstream.origin);
+    });
+  },
+};
+```
+
+El contexto también incluye `name`, `configDir` (el directorio de configuración de opencodex) y `pluginDir`.
+
+Los plugins no pueden importar módulos opencodex - en el binario empaquetado no están en disco. Declare las interfaces pequeñas que necesita localmente, como anteriormente.
+
+<a id="how-rewrites-behave"></a>
+
+## Cómo se comportan las reescrituras
+
+- El rewriter se ejecuta de forma síncrona en cada envío HTTP al proveedor y en la conexión WebSocket de Codex, después de que opencodex haya elegido el transporte. Debe ser rápido: realiza las comprobaciones de red en segundo plano y consulta un resultado en caché desde el rewriter.
+- Un envío redirigido a una dirección de loopback (`127.0.0.1`, `::1`, `localhost`) se conecta directamente tanto por HTTP como por WebSocket de Codex, sin usar los proxies del proveedor ni `HTTP_PROXY`: un proxy en otra máquina no puede acceder al loopback local. Los demás destinos siguen la configuración habitual de salida, incluido `NO_PROXY`, evaluada con la URL reescrita en ambos transportes.
+- El rewriter de WebSocket de Codex se ejecuta en cada turno, antes de reutilizar un socket inactivo del pool. Solo se reutiliza si coinciden el destino y los encabezados reescritos, excepto `x-codex-turn-state` y `x-codex-turn-metadata`. Estos dos encabezados viajan dentro de cada trama de solicitud y pueden variar entre turnos en un mismo socket; se descartan las modificaciones que el rewriter haga a esos dos encabezados. Si un plugin empieza o deja de redirigir, el cambio se aplica en el siguiente turno.
+- La reescritura ocurre después de elegir el proveedor, la cuenta y la ruta; no cambia el enrutamiento, la selección de cuentas, los reintentos ni los registros de solicitudes.
+- El envío llega al host elegido, que recibe la solicitud tal como la recibiría el proveedor, incluidas las credenciales.
+- Si un rewriter lanza una excepción, opencodex revierte únicamente sus cambios en ese envío y lo deshabilita durante el resto del proceso. Los cambios de los rewriters anteriores se conservan; si era el único, la solicitud queda sin modificar. Si `setup` lanza una excepción o agota su plazo, se omite el plugin, se eliminan sus registros de handlers y se ignoran sus intentos posteriores de registro. Los demás plugins y el proxy se inician normalmente.
+- Si el directorio de plugins existe pero no se puede leer, por ejemplo por sus permisos, se informa al iniciar en lugar de tratarlo como vacío.
\ No newline at end of file
diff --git a/docs-site/src/content/docs/es/guides/macos-menu-bar.md b/docs-site/src/content/docs/es/guides/macos-menu-bar.md
new file mode 100644
index 00000000000..1fca6125315
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/macos-menu-bar.md
@@ -0,0 +1,70 @@
+---
+title: "Barra de menús de macOS"
+description: "Usa la bandeja, el panel nativo de uso y el widget de OpenCodex Desktop en macOS."
+---
+
+El elemento de la barra de menús forma parte de OpenCodex Desktop. Muestra el uso del proxy local y abre un panel nativo de uso. La aplicación también incluye el dashboard y una extensión de WidgetKit. Consulta la [guía de escritorio](/es/guides/desktop-app/) para instalarla en otras plataformas.
+
+<a id="install"></a>
+
+## Instalar
+
+Descarga `OpenCodex-<version>-macos.dmg` de la [última versión](https://github.com/lidge-jun/opencodex/releases), abre el DMG y arrastra `OpenCodex.app` a Aplicaciones. La aplicación requiere macOS 13 o posterior; el widget, macOS 14 o posterior.
+
+<a id="first-launch"></a>
+
+## Primer inicio
+
+Las versiones publicadas de `OpenCodex.app` llevan firma de Developer ID, usan el entorno de ejecución reforzado y están notarizadas por Apple, con el comprobante adjunto. En el primer inicio, macOS normalmente solo pide la confirmación habitual para una aplicación descargada. Si sigue bloqueándola, abre **Configuración del Sistema → Privacidad y seguridad → Abrir de todos modos**. Las compilaciones propias llevan firma ad hoc; consulta [Compilar desde el código fuente](#build-from-source).
+
+Al abrirse, la aplicación muestra el progreso de inicio en una ventana. En el primer inicio activa una vez **Iniciar al iniciar sesión (Start at Login)**; puedes desactivarlo desde la bandeja. Esa opción solo aparece marcada cuando esta copia está registrada y macOS no ha desactivado el elemento de inicio. En otro caso, la etiqueta explica el motivo; consulta [Aplicación de escritorio](/es/guides/desktop-app/). Los inicios posteriores mediante ese elemento ocultan la ventana y mantienen la bandeja disponible.
+
+<a id="menu-bar-and-usage-panel"></a>
+
+## Barra de menús y panel de uso
+
+La barra muestra de forma predeterminada los tokens totales de hoy. En el dashboard, abre **Uso → Barra de menús y widget** o `#usage/companion` para elegir solicitudes, tokens, costo estimado, cuota o solo el icono.
+
+Usa **Show Usage (Mostrar uso)** en la bandeja para abrir el panel nativo. Incluye totales de hoy y de 30 días, un gráfico de uso, la lista de modelos y los límites de proveedores y cuentas según tus preferencias de visualización. Los totales incluyen tokens y solicitudes, además del costo estimado si está activado. Las filas de cuota muestran ventana, porcentaje y restablecimiento. Las mediciones ausentes aparecen como `—` y los datos parciales se marcan como incompletos.
+
+Los controles nativos son **Refresh**, **Dashboard** y **Settings**. **Dashboard** abre Uso en la ventana de escritorio y **Settings**, la pestaña Barra de menús y widget de Uso. La bandeja también ofrece **Open Dashboard**, **Open in Browser**, **Start at Login** (iniciar al iniciar sesión), **Stop proxy**, **Check for Updates…**, **Install update** cuando hay una actualización y **Quit**. **Stop proxy** siempre aparece, pero solo está disponible si la aplicación inició el proxy; uno iniciado por separado sigue funcionando. Cerrar la ventana o pulsar Command-Q oculta la aplicación cuando hay bandeja; usa **Quit** para salir por completo.
+
+El botón de actualización del dashboard abre la página de actualizaciones de la aplicación y usa la misma actualización firmada que la bandeja.
+
+El texto de la bandeja se actualiza cada 60 segundos. Mientras está abierto, el panel nativo también se actualiza cada 60 segundos; **Refresh** solicita una actualización inmediata.
+
+## Widget
+
+En macOS 14 o posterior, abre OpenCodex.app una vez y haz Control-clic en un área vacía del escritorio. Elige **Editar widgets**, busca **OpenCodex** y añade el tamaño deseado. Los tamaños combinan estado del proxy, tokens y solicitudes de hoy, costo estimado, cuotas y gráfico de uso. La extensión lee una instantánea local escrita por la aplicación: contiene datos de visualización, no claves API ni datos originales de cuentas. La aplicación la actualiza cada cinco ciclos de bandeja de 60 segundos, aproximadamente cada cinco minutos mientras el proxy está conectado. WidgetKit también solicita una nueva línea temporal después de cinco minutos.
+
+<a id="connecting-to-the-proxy"></a>
+
+## Conectar con el proxy
+
+La aplicación pide a su CLI incluida ejecutar `ocx resolve --json`. Se conecta a un proxy local accesible existente o inicia su entorno incluido solo si la CLI confirma que no hay ninguno escuchando. Si la detección es incierta, informa el problema en lugar de crear un segundo proxy. Usa el puerto resuelto en `127.0.0.1`.
+
+Para las solicitudes de administración prueba primero sin token. Si recibe HTTP 401, reintenta con `OPENCODEX_ADMIN_AUTH_TOKEN` del entorno de la aplicación o con el archivo `admin-api-token` del directorio de configuración resuelto. No usa el Llavero de macOS para ese token. La aplicación no puede conectarse a un proxy que solo escuche en una dirección inaccesible mediante loopback.
+
+<a id="build-from-source"></a>
+
+## Compilar desde el código fuente
+
+En macOS 13 o posterior, con Bun, Rust y las herramientas Swift/Xcode disponibles, compila el dashboard desde la raíz y después ejecuta los comandos de escritorio desde `desktop/`:
+
+```bash
+bun install
+bun run build:gui
+cd desktop
+bun install
+bun run prepare-sidecar
+bun run prepare-widget
+bun run build:local
+```
+
+`build:local` genera la aplicación y el DMG sin requerir una clave de firma del actualizador de Tauri. Ejecutar `bunx tauri build` directamente sí requiere `TAURI_SIGNING_PRIVATE_KEY`, porque también genera el artefacto de actualización. El widget usa firma ad hoc salvo que se configure `MACOS_SIGN_IDENTITY`; los paquetes locales de escritorio también llevan firma ad hoc. La aplicación funciona, pero macOS no registra una extensión de widget con esa firma y normalmente no aparece el widget. `build:local` siempre firma la aplicación de forma ad hoc: configurar solo `MACOS_SIGN_IDENTITY` no basta. Para registrar el widget, tanto la aplicación como la extensión deben estar firmadas por el mismo equipo de Developer ID, como ocurre en las versiones publicadas. Usa una versión publicada si necesitas el widget.
+
+<a id="uninstall"></a>
+
+## Desinstalar
+
+Desactiva **Iniciar al iniciar sesión (Start at Login)** en la bandeja si estaba activado. Si instalaste el comando de terminal administrado, elige **Quitar comando de terminal (Remove terminal command)** antes de mover `OpenCodex.app` de Aplicaciones a la Papelera; de lo contrario, su shim y sus datos de propiedad quedan fuera del paquete y el comando deja de funcionar. Esto elimina la CLI incluida y la extensión del widget, pero conserva el estado de `$OPENCODEX_HOME` y cualquier servicio `ocx` instalado por separado. La aplicación también guarda un identificador de instalación y marcadores de inicio en su directorio de configuración, además de una instantánea del widget en `~/Library/Containers/com.opencodex.desktop.widget/Data/Library/Application Support/OpenCodex/snapshot.json`; moverla a la Papelera no borra esos archivos.
diff --git a/docs-site/src/content/docs/es/guides/minimax.md b/docs-site/src/content/docs/es/guides/minimax.md
new file mode 100644
index 00000000000..d26e2cbf9ba
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/minimax.md
@@ -0,0 +1,95 @@
+---
+title: "Clientes MiniMax"
+description: "Enruta MiniMax Code y los comandos de texto de MiniMax CLI mediante OpenCodex sin exponer sus credenciales."
+---
+
+MiniMax publica dos productos de línea de comandos diferentes. OpenCodex integra cada uno en el límite del protocolo que realmente expone:
+
+- **MiniMax Code** (`mcode`) es un agente de codificación con proveedores personalizados Anthropic Messages.
+- **MiniMax CLI** (`mmx`) es una CLI de plataforma multimodal. Solo su recurso `text` utiliza la API compatible con Anthropic que OpenCodex puede enrutar.
+
+<a id="minimax-code"></a>
+
+## MiniMax Code
+
+En la página Modelos de OpenCodex, las dos regiones del plan de programación de MiniMax anuncian la entrada de imágenes para `MiniMax-M3` y `MiniMax-M3.1-Flash`. El interruptor **Imagen / multimodal** de un Combo solo está disponible cuando todos los modelos seleccionados admiten la entrada de imágenes. Este interruptor controla las imágenes adjuntas; no habilita la carga de vídeos.
+
+Primero instala MiniMax Code e inicia sesión siguiendo las instrucciones de MiniMax. Después, inicia OpenCodex y conecta la integración reversible mediante archivos:
+
+```bash
+ocx start
+```
+
+Deja el proxy ejecutándose en esta terminal. En otra terminal, habilita la integración e inicia MiniMax Code:
+
+```bash
+ocx integration client enable --client mcode
+ocx mcode
+```
+
+![Integración de MiniMax Code con datos de ejemplo aislados](/screenshots/minimax-code-integration.png)
+
+La integración incorpora un bloque a `~/.minimax/config.yaml`:
+
+```yaml
+custom_provider:
+  opencodex:
+    name: OpenCodex
+    kind: custom
+    enabled: true
+    api: anthropic-messages
+    options:
+      apiKey: opencodex-loopback
+      baseURL: http://127.0.0.1:10100
+      authMode: api-key
+    models:
+      anthropic/claude-opus-5:
+        limit:
+          context: 1000000
+```
+
+La lista de modelos generada, las ventanas de contexto y las escalas de esfuerzo de razonamiento proceden del catálogo de OpenCodex en ejecución. Las ventanas de contexto pueden incluir [estimaciones para proveedores personalizados](/es/reference/configuration/providers/#context-windows-on-custom-providers); si el catálogo no incluye una ventana o una escala de esfuerzo, se omite el campo correspondiente. MCode conserva en la sesión el esfuerzo seleccionado, por lo que OpenCodex exporta `effortOptions` sin sobrescribir esa selección. El bloque no escribe una clave real, no sustituye `defaultModel` ni cambia tu inicio de sesión en MiniMax. En MCode, elige un modelo bajo `custom_provider:opencodex/...`.
+
+`ocx mcode` verifica que este proveedor apunta al proxy en ejecución antes de iniciar el cliente. Tras habilitarlo una vez, `ocx sync` actualiza el bloque que administra cuando cambia el puerto o las capacidades del catálogo. La sincronización automática nunca crea un bloque que no esté bajo su control, nunca vuelve a crear uno que hayas eliminado ni sobrescribe un archivo que haya cambiado después de que OpenCodex lo escribiera; utiliza el comando de habilitación cuando quieras volver a conectarlo de forma intencional. Puedes deshabilitarlo o restaurarlo mediante el mismo sistema de integración auditado:
+
+```bash
+ocx integration client disable --client mcode
+ocx integration client history --client mcode
+ocx integration client restore --op <opId> [--confirm-drift]
+```
+
+Se respetan `MINIMAX_DATA_DIR` y la variable antigua `MAVIS_DATA_DIR`. Se rechazan las rutas relativas en estas variables porque OpenCodex y MCode pueden iniciarse en directorios de trabajo diferentes.
+
+## MiniMax CLI (`mmx`)
+
+Instala la CLI oficial por separado:
+
+```bash
+npm install -g mmx-cli
+mmx --version
+```
+
+Enruta un comando de texto a través de OpenCodex utilizando el envoltorio y un identificador de modelo de OpenCodex:
+
+```bash
+ocx mmx text chat \
+  --model anthropic/claude-opus-5 \
+  --message "Explain this function"
+
+ocx mmx --output json text chat \
+  --model openai/gpt-5.6-sol \
+  --message "Return a JSON summary"
+```
+
+MMX tiene fijada en su código la ruta `/anthropic/v1/messages` bajo la URL base de su API. El envoltorio inicia un puente temporal en loopback que dura lo mismo que el proceso hijo. Solo acepta solicitudes POST a esa ruta de Messages y a `/anthropic/v1/messages/count_tokens`, y las dirige al plano de datos existente de OpenCodex, en `/v1/messages` y `/v1/messages/count_tokens`, conservando los cuerpos de las solicitudes y los datos de consulta. Se mantienen la traducción canónica de solicitudes de OpenCodex, la contabilidad de uso y la autenticación configurada para el proveedor de destino; los proveedores reciben `x-api-key` o autenticación de tipo bearer según su configuración. El streaming conserva los eventos de mensajes y contenido de Anthropic. Antes de reenviar una solicitud, el puente elimina las cabeceras entrantes de credenciales de admisión y fija el marcador de posición público `opencodex-loopback`. No actúa como proxy para otros recursos arbitrarios de Anthropic y nunca se expone fuera de loopback.
+
+El envoltorio también crea un directorio temporal `MMX_CONFIG_DIR` que contiene únicamente ese marcador de posición y lo elimina después de que termine `mmx`. Nunca carga ni copia tu archivo `~/.mmx/config.json`, tus tokens OAuth ni tu clave API de MiniMax.
+
+Los siguientes límites son intencionales:
+
+- Solo `text chat` y `text repl` se enrutan a través de OpenCodex.
+- El envoltorio rechaza `--api-key`, `--base-url` y `--region` para que las credenciales o los selectores de destino proporcionados por quien lo invoca no entren en conflicto con el puente aislado.
+- El envoltorio solo funciona en loopback porque MMX no puede enviar la cabecera de admisión específica de OpenCodex, `x-opencodex-api-key`, cuando el proxy escucha en una dirección remota.
+- Ejecuta `mmx` directamente para `image`, `video`, `speech`, `music`, `vision`, `search`, `quota`, `auth`, `config`, `file` y `update`; esos comandos utilizan API específicas de MiniMax que OpenCodex no emula.
+
+`mmx` utiliza `MiniMax-M3` como modelo de texto predeterminado. Pasa `--model <provider/model>` cuando quieras una ruta concreta de OpenCodex; de lo contrario, las reglas habituales de enrutamiento de modelos de OpenCodex decidirán si el identificador predeterminado está disponible.
diff --git a/docs-site/src/content/docs/es/guides/model-ordering.md b/docs-site/src/content/docs/es/guides/model-ordering.md
new file mode 100644
index 00000000000..e7220b66d2f
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/model-ordering.md
@@ -0,0 +1,158 @@
+---
+title: "Orden de modelos"
+description: "Cómo determina opencodex el orden de los modelos en el selector de Codex y las anulaciones de modelo de spawn_agent."
+---
+
+El selector de modelos Codex no conserva el orden de las declaraciones del proveedor o las matrices de modelos en la configuración opencodex. Su orden final proviene de las prioridades del catálogo, con un orden alfabético determinista para los modelos enrutados que comparten la misma prioridad.
+
+<a id="the-rule-codex-applies"></a>
+
+## La regla Codex se aplica
+
+El gestor de modelos de Codex ordena las entradas de catálogo visible por `priority` en orden ascendente. Descarta el orden de la matriz de catálogo, por lo que mover una entrada antes en una matriz JSON generada no la mueve antes en el selector. La implementación registra esta restricción directamente en `src/codex/catalog/sync.ts`.
+
+Por lo tanto, opencodex controla la posición de los modelos destacados asignando prioridades más bajas, no confiando en la posición de la matriz. A menos que se indique lo contrario, las prioridades fijas y el ejemplo trabajado a continuación describen un catálogo sin selectores de cuenta Codex elegibles. Con `N` selectores elegibles, las prioridades presentadas usan `N` como un paso: una elección nativa desnuda en el rango configurado `i` se expande a filas de selectores en las prioridades `i * N + j`, donde `j` es la posición basada en cero del selector; una elección encaminada usa `i * N`; y una elección calificada por selector exacta usa `i * N + j` para su selector. Las filas enrutadas no seleccionadas se mueven fuera de esos grupos selectores. Codex todavía anuncia sólo las primeras cinco filas visibles.
+
+Sin el pedido completo del seleccionador, las prioridades relevantes de no selector son:
+
+| Entrada de catálogo | Prioridad | Fuente |
+| --- | ---: | --- |
+| `subagentModels[i]` | `i` (`0` a través de `4`) | El mapa de rango destacado en `src/codex/catalog/sync.ts` |
+| Otros modelos ruteados | `5` | Creación de la entrada encaminada en `src/codex/catalog/sync.ts` |
+| Modelos ruteados no destacados listados en `modelPickerOrder` | `1000 + i` | Rango de selector de solo visualización en `src/codex/catalog/sync.ts` |
+| Identificadores GPT nativos sin una lista destacada | `sourcePriority` (valor de respaldo `9`) | Resolución compartida de la prioridad nativa de origen |
+| Modelos nativos no seleccionados mientras existe una lista destacada | `featured.length + 100 + sourcePriority` | Resolución compartida de la prioridad nativa de origen |
+
+La prioridad nativa de origen se obtiene del descriptor descubierto actual; si no contiene un valor válido, se consulta la copia de seguridad intacta del catálogo, el valor de origen conservado para ese mismo modelo y, por último, la instantánea del proveedor. Cada candidato debe ser un entero entre `0` y `1000`; los valores no válidos se omiten y el valor final de respaldo es `9`. Las prioridades de visualización publicadas nunca se reutilizan como prioridades de origen. Con cuatro modelos destacados, las prioridades nativas de origen `3`, `8` y ausente se convierten en `107`, `112` y `113`, respectivamente.
+Así se conserva el orden de origen de los modelos nativos detrás de las filas destacadas y las enrutadas ordinarias, incluso tras sincronizaciones repetidas o después de destacar un modelo nativo y dejar de destacarlo. La lista de modelos en vivo de Codex, el catálogo publicado y la caché de modelos usan las mismas prioridades para las mismas entradas. Los grupos de selectores de cuenta conservan su política de intervalos independiente; el orden del selector completo sigue teniendo la última palabra.
+
+La gestión API limita `subagentModels` a cinco entradas con `slice(0, 5)` en `src/server/management/agent-settings-routes.ts`. Esto coincide con la superficie Codex `spawn_agent`, que anuncia solo los primeros cinco modelos anulados. Los modelos fuera de esos cinco todavía pueden permanecer visibles en el selector principal y llamarse por su id exacto.
+
+<a id="how-ties-are-ordered"></a>
+
+## Cómo se ordenan los empates
+
+Todos los modelos ruteados ordinarios tienen prioridad `5`, por lo que necesitan un desempate. Antes de que se construyan las entradas del catálogo, `gatherRoutedModels()` ordena la lista de modelos enrutados por nombre del proveedor y luego por la identificación del modelo, ambos alfabéticamente (`src/codex/catalog/provider-fetch.ts`).
+
+Esto significa que ninguno de estos detalles de configuración cambia el orden final:
+
+- el orden de las claves de declaración en el objeto `providers`;
+- el orden de los id en la matriz `models` de un proveedor.
+
+`orderForSubagents()` luego usa una ordenación estable para mover las selecciones destacadas configuradas al frente en el mismo orden que `subagentModels`. Los modelos no destacados mantienen el orden relativo alfabético proveedor/identificador establecido anteriormente (`src/codex/catalog/sync.ts`). El rango destacado también se convierte en prioridades `0` a `4` cuando se construyen las entradas, por lo que el orden de prioridad de Codex conserva esa secuencia principal.
+
+<a id="visibility-is-separate-from-ordering"></a>
+
+## La visibilidad está separada del orden
+
+`selectedModels` y `disabledModels` deciden qué modelos enrutados están expuestos; no están ordenando controles. `filterCatalogVisibleModels()` convierte ambas selecciones en `Set` búsquedas y filtra la lista recopilada sin usar las matrices como rangos (`src/codex/catalog/provider-fetch.ts`).
+
+Como resultado, reordenar `selectedModels` o `disabledModels` no tiene ningún efecto sobre la posición del selector. Solo puede cambiar si se incluye un modelo.
+
+<a id="effective-picker-pattern"></a>
+
+## Patrón de selector efectivo
+
+Sin selectores de cuenta elegibles y una lista de características no vacía, el pedido resultante es:
+
+1. Modelos en el orden exacto configurado `subagentModels`, con prioridades `0` a `4`.
+2. Todos los modelos enrutados restantes, ordenados alfabéticamente por proveedor y luego por ID de modelo, con prioridad `5`.
+3. Modelos nativos no seleccionados, empujados por debajo del bloque destacado durante la fusión del catálogo.
+
+Sin `subagentModels`, los modelos enrutados permanecen en la prioridad `5`, las entradas GPT nativas usan su prioridad de origen (valor de respaldo `9`) y el grupo enrutado mantiene el orden alfabético por proveedor e identificador.
+
+<a id="example"></a>
+
+## Ejemplo
+
+Supongamos que `subagentModels` contiene estos cinco id en este orden exacto:
+
+```toml
+subagentModels = [
+  "gpt-5.5",
+  "opencode-go/glm-5.2",
+  "anthropic/claude-opus-4-6",
+  "gpt-5.6-sol",
+  "gpt-5.6-terra",
+]
+```
+
+El selector comienza de la siguiente manera:
+
+| Posición del selector | Modelo | Prioridad | Por qué aparece allí |
+| ---: | --- | ---: | --- |
+| 1 | `gpt-5.5` | `0` | Primera selección `subagentModels` |
+| 2 | `opencode-go/glm-5.2` | `1` | Segunda selección, a pesar de que su proveedor clasifica después de `anthropic` |
+| 3 | `anthropic/claude-opus-4-6` | `2` | Tercera selección |
+| 4 | `gpt-5.6-sol` | `3` | Cuarta selección |
+| 5 | `gpt-5.6-terra` | `4` | Quinta selección |
+| 6 | `anthropic/claude-fable-5` | `5` | Primer id enrutado restante en orden alfabético proveedor/id |
+| 7 en adelante | Los modelos enrutados restantes | `5` | Proveedor alfabéticamente, luego modelar id alfabéticamente |
+| Después de los modelos enrutados | Los modelos nativos restantes | `featured.length + 100 + sourcePriority` | Se conserva el orden de origen dentro de la banda nativa |
+
+Las primeras cinco entradas son las anulaciones anunciadas a `spawn_agent`; el resto continúa en el orden normal del selector. Con los selectores de cuenta, el límite de cinco entradas se aplica después de que las opciones nativas desnudas se hayan expandido a grupos calificados por el selector.
+
+<a id="changing-the-order"></a>
+
+## Cambiar el orden
+
+Utilice `subagentModels` para elegir y ordenar los modelos líderes que Codex también anuncia a `spawn_agent`. La página **Subagentes** del panel de control puede reordenar los ID nativos y enrutados. Utilice `ocx agent subagents set` o edite la configuración opencodex para las opciones exactas `<selector>/<native-openai-model>`; el panel de control conserva esas identificaciones una vez guardadas, incluidas las opciones actualmente no disponibles. Utilice como máximo cinco ID configurados. Con los selectores de cuenta, una opción nativa puede expandirse a múltiples filas de catálogo calificadas por el selector, por lo que las opciones configuradas y las filas anunciadas no son necesariamente individuales.
+
+Si ninguna cuenta configurada admite un modelo nativo con apertura de cuenta, la solicitud falla como una opción de modelo no válida. Si las cuentas de soporte existen pero están temporalmente agotadas o no están disponibles, falla como un límite de tasa reintentable. Estos estados nunca se informan como una clave API no válida; elija otro modelo disponible o espere a que se vuelva a abrir la ventana de cuota de la cuenta capaz.
+
+Utilice `modelPickerOrder` para ordenar solo en pantalla las filas enrutadas `<provider>/<model>` más allá del bloque destacado:
+
+```json
+{
+  "modelPickerOrder": [
+    "tyler/deepseek-v4-flash",
+    "jd-chat/kimi-k3",
+    "jd-chat/glm-5.2"
+  ]
+}
+```
+
+Las filas enrutadas aparecen en el orden configurado. Una fila enrutada omitida de la matriz mantiene su prioridad normal, por lo que permanece por delante de la banda de visualización `modelPickerOrder`; enumere cada fila enrutada cuya posición relativa desea controlar. Una fila también presente en `subagentModels` mantiene su prioridad destacada. Con una lista solo encaminada, las filas nativas mantienen sus posiciones normales.
+
+Para pedir el selector completo, incluya un identificador nativo desnudo:
+
+```json
+{
+  "modelPickerOrder": ["gpt-5.6-sol", "opencode-go/glm-5.3"]
+}
+```
+
+Las filas listadas aparecen primero en orden de array, seguidas de las filas no listadas en orden de prioridad natural. La coincidencia utiliza ID de catálogo exactos: `gpt-5.6-sol` y `openai/gpt-5.6-sol` son filas separadas. También se aceptan ortografías crudas y codificadas del mismo id enrutado, teniendo prioridad las coincidencias exactas. Las entradas vacías son ignoradas. Las filas calificadas para la cuenta necesitan su id calificado para el selector en la lista.
+
+<a id="migration-note-native-ids-in-existing-orders"></a>
+
+### Nota de migración: ID nativos en pedidos existentes
+
+Anteriormente, los identificadores nativos en `modelPickerOrder` fueron ignorados. Una lista existente que contiene un id nativo desnudo ahora activa el pedido de un selector completo, incluidas las filas destacadas. Retire los id nativos desnudos para mantener el comportamiento anterior solo enrutado. Las listas sin configurar, vacías y solo enrutadas conservan su comportamiento; El cálculo de los candidatos a orientación de prioridad natural de OpenCodex no ha cambiado.
+
+`modelPickerOrder` conserva el cálculo de prioridad natural de OpenCodex de hasta cinco candidatos preferidos para la orientación de subagentes. Cada fila movida conserva su prioridad natural por separado de su `priority` nativo; el cambio de orden del selector por sí solo no debe cambiar ese cálculo de OpenCodex. No restringe la elegibilidad para una anulación de modelo de nombre exacto: la lista nativa anunciada no es una lista de permisos, y aún se aplican las restricciones de autenticación, modelo/esfuerzo y backend existentes.
+
+Native Codex utiliza Native `priority` para seleccionar los primeros cinco modelos elegibles visibles para el selector anunciados por `spawn_agent` en V1 y en V2 cuando se exponen las anulaciones del modelo. Por lo tanto, los cinco anunciados pueden cambiar con la orden del seleccionador, incluso cuando los candidatos preferidos de OpenCodex permanecen sin cambios. V1 no recibe inyección de cartucho preferido OpenCodex. V2 también puede recibir orientación de prioridad natural de OpenCodex cuando el estado del catálogo del cliente lo permita; esa orientación no reordena la lista anunciada de la herramienta nativa.
+
+`disabledModels` y los `selectedModels` de cada proveedor siguen siendo campos de visibilidad, no controles de pedido. No hay configuración separada de `modelOrder`, `providerOrder` o mapa de prioridad.
+
+<a id="dashboard-picker-presets"></a>
+
+## Configuración preestablecidos del selector de panel
+
+En **Modelos**, elija **Predeterminado**, **A–Z por modelo**, **Grupo por proveedor** o **Instantánea más utilizada** y luego **Aplicar orden**. Esto guarda los identificadores enrutados visibles en ese momento y `modelPickerOrderMode` (`alphabetical`, `provider` o `most-used`). La opción más utilizada lee todo el uso conservado una vez al aplicarse; las recargas restauran la instantánea sin volver a consultar el uso. Los modelos nuevos o eliminados no la recalculan automáticamente. Un orden guardado manualmente, incluido un orden completo/nativo, permanece intacto hasta que aplique explícitamente un reemplazo. El valor predeterminado borra ambos campos del selector, incluso cuando no hay modelos enrutados disponibles.
+
+Los controles usan `GET/PUT /api/subagent-models`: `chosen` y `available` retienen las opciones guardadas de la lista, incluidos los modelos desactivados o desaparecidos; `pickerAvailable` contiene solo identificadores de catálogo enrutados elegibles. La página Modelos envía `pickerOrder` y `pickerOrderMode`, nunca `models`. La lista solo guarda la configuración del selector de conservación. Las actualizaciones combinadas no válidas y la persistencia fallida dejan intacto el estado anterior del selector/roster.
+
+Los ajustes preestablecidos de solo ruta mantienen las bandas de prioridad existentes destacadas/nativas. Afectan al catálogo Codex y a los grupos dirigidos del descubrimiento Claude; El prefijo nativo de Claude y la propiedad explícita de perfil/alias de escritorio permanecen sin cambios. Se conservan los rangos de guía OpenCodex y los ajustes de reserva configurados, pero los cinco anuncios de Codex nativos y el valor predeterminado recomendado pueden cambiar con la prioridad de visualización. Guardar no reinicia clientes; puede que una actualización de catálogo permanezca pendiente, y los clientes que tengan un catálogo antiguo pueden necesitar volver a abrir.
+
+
+<a id="custom-routed-order"></a>
+
+### Orden enrutada personalizada
+
+Elija **Orden de encargo** en Modelos para cargar una nueva instantánea enrutada. Arrastre una fila móvil antes de otra fila, o utilice sus botones Arriba/Abajo, luego **Guardar borrador**. Las filas enrutadas destacadas permanecen en la parte delantera en su rango configurado y no pueden moverse. No se muestran las filas nativas; esto no es una vista previa del selector nativo completo. Las filas guardadas supervivientes mantienen su orden relativo y los nuevos candidatos siguen la lista de candidatos actual. Cada guardado envía la lista completa, sin cambiar la lista destacada.
+
+Una orden que contiene ids nativos desnudos permanece protegida hasta que aplique explícitamente un preset o Predeterminado enrutado. Seleccionar una opción diferente por sí sola no la reemplaza. Un estado destacado desconocido bloquea la edición. Antes de guardar, el editor comprueba una nueva instantánea; los cambios preservan el borrador y bloquean el guardado hasta que **Recargar y descartar borrador** cargue la configuración actual. Los fallos de solicitud conservan el borrador. Los archivos guardados aceptados aún pueden tener una actualización de catálogo pendiente; vuelva a cargar antes de volver a editar.
+
+El editor también requiere una identidad de modelo inequívoca para cada candidato enrutado. Si el catálogo de modelos está incompleto, actualice la página Modelos antes de editar; la recarga de la configuración del selector por sí sola no puede restaurar las identidades de catálogo que faltan. Las opciones destacadas se combinan exactamente sin recortar; las opciones duplicadas usan su última posición configurada, y los id canónicos tienen prioridad sobre los id sin procesar.
diff --git a/docs-site/src/content/docs/es/guides/model-routing.md b/docs-site/src/content/docs/es/guides/model-routing.md
new file mode 100644
index 00000000000..e492d1a1717
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/model-routing.md
@@ -0,0 +1,108 @@
+---
+title: "Enrutamiento de modelos"
+description: "Cómo decide opencodex qué proveedor sirve un ID de modelo determinado."
+---
+
+Cuando Codex solicita un modelo, `router.ts` lo resuelve exactamente a un proveedor configurado. Las reglas se comprueban **por orden**; el primer partido gana.
+
+Para OpenAI, un id `<selector>/gpt-*` configurado se asigna a través de `codexAccountNamespaces` a exactamente una cuenta Codex almacenada antes de considerar el combo o los espacios de nombres de proveedor. Los ids `gpt-*` sin calificar seleccionan en su lugar el proveedor canónico `openai`. Su `codexAccountMode` elige Pool (predeterminado, principal más cuentas añadidas) o Direct (el portador principal o del llamante actual) sin cambiar el id del modelo. `openai-apikey/<model>` selecciona explícitamente el transporte de clave API. Estas rutas de credenciales no recurren unas a otras como alternativa.
+
+<a id="precedence"></a>
+
+Antes de estas reglas, un `policy/<id>` explícito o un alias de perfil de enrutamiento configurado evalúa la política y enruta a su candidato concreto. Un selector de política reservado desconocido se rechaza sin continuar por las rutas de proveedores ni por la predeterminada.
+
+## Precedencia
+
+1. **Selector de cuenta Exact Codex** - si el id es `<selector>/<native-openai-model>` y el selector está configurado en `codexAccountNamespaces`, la solicitud usa solo la cuenta almacenada asignada y envía el modelo nativo desnudo aguas arriba. Si el destino exacto no está disponible, la solicitud se rechaza sin recurrir a Pool, Direct ni al enrutamiento del proveedor.
+
+   ```text
+   side/gpt-5.6-sol → provider "openai", model "gpt-5.6-sol", account selector "side"
+   ```
+
+2. **Identificación combinada o alias** - mientras se configura al menos un combo, un alias canónico `combo/<id>` o combo configurado selecciona su objetivo concreto antes de que se comprueben los espacios de nombres del proveedor. Sin combos configurados, un proveedor físico heredado llamado literalmente `combo` sigue siendo un espacio de nombres de proveedor normal. Véase [Combos](/es/guides/combos/) para la selección de destino y el comportamiento de conmutación por error.
+
+3. **`provider/model` explícito** - si el id contiene `/` y la parte anterior es el nombre de un proveedor configurado, ese proveedor se utiliza y el id se quita a la parte después de la barra.
+
+   ```text
+   anthropic/claude-opus-5     →  provider "anthropic",   model "claude-opus-5"
+   ollama-cloud/glm-5.2        →  provider "ollama-cloud", model "glm-5.2"
+   openrouter/openai/gpt-5.6-sol → provider "openrouter",  model "openai/gpt-5.6-sol"
+   ```
+
+   Esta es la forma explícita del proveedor de rutas, y el selector de modelos de Codex utiliza para los modelos enrutados. Si el mismo id público es un alias combinado configurado, gana la regla 2. Si el proveedor nombrado está deshabilitado, esta forma explícita lanza en lugar de enrutamiento.
+
+4. **Id sin calificar de la familia nativa de OpenAI** — un id como `gpt-*`, `o1-*`, `o3-*` o `o4-*` usa el proveedor canónico `openai` habilitado y su modo de cuenta Pool o Direct configurado.
+
+5. **`defaultModel` de un proveedor** - si el `defaultModel` de cualquier proveedor es igual al id, ese proveedor se usa (id pasó sin cambios).
+
+6. **Patrones de prefijo incorporado** - el id se compara con prefijos de familia de modelos conocidos, y luego se enruta a un proveedor configurado con ese nombre (o prefijo de nombre):
+
+   | Prefijos | Proveedor |
+   | --- | --- |
+   | `claude-`, `claude-sonnet-`, `claude-opus-`, `claude-haiku-` | `anthropic` |
+   | `llama-`, `mixtral-`, `gemma-` | `groq` |
+
+   Este emparejador se basa en el nombre; al igual que las exploraciones `defaultModel` / `models[]`, omite un proveedor coincidente cuya bandera `disabled` sea verdadera.
+
+7. **`models[]` de un proveedor** - si no se ganó ninguna regla de prefijo y un proveedor activo muestra el id en su `models[]`, se usa ese proveedor. La regla 4 ya envía una identificación desnuda `gpt-*` al proveedor canónico habilitado `openai` antes de que la reclamación `models[]` de otro proveedor pueda coincidir.
+
+8. **Proveedor predeterminado** - si nada coincide, el id se envía a `config.defaultProvider` sin cambios. (Si no hay ningún proveedor predeterminado configurado, o está deshabilitado, el enrutamiento se lanza.)
+
+<a id="api-keys-and-environment-variables"></a>
+
+## Claves API y variables de entorno
+
+Cualquiera que sea la ruta elegida, el `apiKey` del proveedor se resuelve a través de `resolveEnvValue()`: un valor de `${OPENAI_API_KEY}` o `$OPENAI_API_KEY` se expande desde el entorno en el momento de la solicitud, por lo que los secretos nunca necesitan vivir en `config.json`.
+
+<a id="catalog-visibility-and-context-caps"></a>
+
+## Visibilidad del catálogo y límites de contexto
+
+El enrutamiento y la visibilidad del catálogo son controles separados:
+
+- `disabledModels` esconde identificadores de rutas de nombres del catálogo Codex y `/v1/models`; una identificador GPT nativa desnuda se mantiene en el catálogo con `visibility: "hide"`. El **no** rechaza una solicitud directa para ese modelo.
+- El `selectedModels` no vacío de un proveedor es otra lista de permisos de catálogo. El descubrimiento en vivo y el enrutamiento directo aún funcionan; solo se reducen el catálogo y las emisiones de `/v1/models`.
+- Conjunto de instalaciones frescas `modelDiscovery.newModelPolicy` a `"off"`. Después de que el primer live fetch exitoso establece una línea de base, las llegadas posteriores se agregan a `disabledModels` y llevan una insignia de tablero **NUEVO** hasta que se habilita o se reconoce. Las instalaciones existentes permanecen en `"on"` hasta que se opta. La política se aplica antes de publicar modelos recién descubiertos a través de `/v1/models`, el panel de control, las exportaciones de configuración del cliente o una sincronización de catálogo Codex (incluido el inicio del servicio). Habilitar una llegada manualmente la mantiene habilitada en actualizaciones y exportaciones posteriores. Si la configuración del proveedor en ejecución difiere del disco, las listas de modelos siguen aplicando la directiva mediante una proyección temporal; dejan intacta la configuración en ejecución y las opciones guardadas. Utilice `ocx models new-policy off` a nivel mundial, agregue `--provider <name>` para una anulación e inspeccione `ocx models new-arrivals [--json]`. Los resultados fallidos/degradados nunca cambian la línea base. Los proveedores con un `selectedModels` no vacío (incluido el modo preestablecido) ya están curados, por lo que esta política es deliberadamente inerte para ellos.
+- `provider.disabled: true` elimina ese proveedor del descubrimiento de catálogo. Las solicitudes explícitas `provider/model` fallan y las exploraciones `defaultModel` / `models[]` las omiten.
+- Las filas de catálogo enrutadas se clonan a partir de la plantilla nativa Codex, por lo que los indicadores de entrega solo nativos se eliminan durante la normalización: `supports_websockets`, `supports_reasoning_summaries` y `supports_experimental_context`. Un proveedor enrutado nunca hereda el contrato de contexto experimental; heredarlo hacía que Codex compactara tras casi cada paso en hilos enrutados largos.
+- `providerContextCaps` aplica límites de contexto visibles para Codex por proveedor. `contextCapValue` es el valor predeterminado del panel (350.000 por defecto), pero no hace nada por sí mismo hasta que un proveedor está presente en `providerContextCaps`. Cambiar el valor del panel de control actualiza cada límite habilitado solo cuando se activa "aplicar a cada proveedor enrutado"; de lo contrario, cada proveedor mantiene su propio límite. Las ventanas ordinarias conocidas solo se pueden bajar; los modelos nativos que admiten una ventana más larga pueden expandirse hasta su propio techo soportado. Los límites nunca cambian el límite real del modelo ascendente. Apagar un límite conserva su selección en `providerContextCapValues`, incluso después de la recarga; encenderlo restaura esa selección. Una selección recordada nunca aplica un límite mientras está deshabilitada. El envío de `{ "setAll": true }` sin `value` habilita a todos los proveedores configurados al valor global actual y reemplaza sus selecciones recordadas.
+- Un modelo GitHub Copilot que admite el nivel de contexto largo ascendente puede optar por `providers.github-copilot.modelContextTiers.<model> = "long_context"` o `ocx provider edit github-copilot --model-context-tier <model>=long_context`. El nivel envía `contextTier: "long_context"` en el Chat del Copiloto y Responses solicitudes. Se eleva la ventana anunciada sólo cuando ese modelo exacto tiene una ventana conocida por modelo en `modelContextWindows` (por ejemplo, `1000000`); un modelo desconocido mantiene su ventana en vivo. Gana una ventana explícita por modelo, luego se aplica el límite de proveedor existente. Las ventanas guardadas y las selecciones de nivel sobreviven al inicio y al reinicie OAuth. OAuth presets llenan los valores predeterminados por modelo que faltan mientras mantiene sus entradas configuradas, incluso en xAI. El nivel `"default"` conserva metadatos de contexto en vivo normales. El control del panel se planifica por separado.
+
+```json
+{
+  "contextCapValue": 350000,
+  "providerContextCaps": {
+    "anthropic": 350000,
+    "cursor": 350000
+  }
+}
+```
+
+<a id="tips"></a>
+
+## Propinas
+
+- **Dirigir una cuenta Codex explícitamente** con `<selector>/<native-openai-model>` (regla 1). Esa ruta es exacta y falla cerrada; nunca cambia silenciosamente a otra cuenta.
+- **Sea explícito para los modelos enrutados.** Prefiera `provider/model` (regla 3) cuando esa identificación pública exacta no es un alias combinado. Nombra directamente al proveedor y coincide con lo que Codex muestra en su selector después de una sincronización de catálogo.
+- **Semilla `models[]` o `defaultModel`** en un proveedor tan corto ids (reglas 5/7) resolver sin el prefijo `provider/`.
+- **Los patrones de prefijo son una conveniencia**, no es una garantía: solo se resuelven si un proveedor con ese nombre (p. ej. `anthropic` o `groq`) está configurado realmente.
+
+Consulte [Configuración](/es/reference/configuration/) para los campos de proveedor que leen estas reglas.
+
+
+<a id="structured-output-on-cursor-routes"></a>
+
+## Salida estructurada en rutas Cursor
+
+Cursor rutas traducen Responses `text.format` (`json_object` o `json_schema`) en instrucciones explícitas de respuesta final en el contexto del sistema y solicitud activa, incluyendo continuación de resultados de herramientas. Esta es una reserva rápida: Cursor no proporciona una decodificación JSON restringida nativa en este transporte, y los modelos aún pueden devolver una respuesta no válida. El adaptador no convierte la prosa en una decisión de aprobación. Las personas que llaman deben validar el JSON devuelto y usar una ruta con capacidad de salida estructurada cuando se requiere una aplicación estricta. Las solicitudes de texto ordinarias y las llamadas de herramientas intermedias mantienen su comportamiento existente.
+
+
+<a id="model-alias-templates"></a>
+
+## Plantillas de alias de modelos
+
+`aliasTemplate` es opcional por proveedor y asigna nombres a sus modelos sin alias manual o integrado. Por ejemplo, `"aliasTemplate": "{providerAlias}-{modelBasename}"` con alias `CC` convierte `reflection/beam:free` en `CC-beam-free`. Solo admite `{providerAlias}`, que exige un alias del proveedor, y `{modelBasename}`, obligatorio: el último segmento después de `/`, sustituyendo `:` por `-`. Los alias se calculan al resolver modelos, sin guardarlos en configuración; un modelo nuevo los recibe al descubrirse y quitar la plantilla los elimina de inmediato.
+
+Prevalecen los alias manuales, después los integrados y por último la plantilla. Se omite, sin renombrar, un resultado inválido, con prefijo reservado `gpt-`, `o1-`, `o3-`, `o4-` o `codex-`, o ya ocupado por IDs o alias del proveedor, alias integrados, nombres o alias de proveedores, alias manuales de otros proveedores o ID/alias de combos. Si dos modelos generan el mismo nombre, se omiten ambos sin depender del orden. Un alias sin calificador generado por dos proveedores es ambiguo; sigue funcionando `<provider-alias>/<alias>`. Usa `ocx alias template set <provider> <template>` o `PUT /api/providers/<name>/alias-template` con `{ "template": … }`, y `null` para quitarla. Se informa del número generado y de los omitidos con su causa. `ocx alias list` indica el origen `template`. Una plantilla inválida editada en `config.json` se ignora con aviso.
+
+- Para proveedores con `selectedModels` no vacío, incluido el modo de preajuste, las políticas `on` y `off` no amplían la selección. `admit`, mediante `ocx models new-policy admit --provider <name>`, añade una vez cada llegada auténtica a la selección personalizada y aplica el cambio sin reinicio. Una exclusión posterior se conserva; no amplía preajustes ni proveedores sin selección. `ocx models new-arrivals` y `GET /api/model-discovery` muestran `enabled`, `not-selected`, `auto-disabled` o `disabled` con las reglas reales del selector, incluidos los niveles de esfuerzo de Antigravity.
diff --git a/docs-site/src/content/docs/es/guides/native-main-profiles.md b/docs-site/src/content/docs/es/guides/native-main-profiles.md
new file mode 100644
index 00000000000..b794723a800
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/native-main-profiles.md
@@ -0,0 +1,138 @@
+---
+title: "Perfiles del inicio de sesión nativo principal"
+description: "Administre los perfiles guardados del inicio de sesión nativo de Codex por separado del enrutamiento Pool de OpenCodex."
+---
+
+<a id="native-login-is-not-pool-selection"></a>
+
+## El inicio de sesión nativo es independiente de la selección Pool
+
+En Multi-auth, dentro de los ajustes de Codex, abra
+**Administrar el inicio de sesión principal** en el panel independiente
+**Inicio de sesión nativo principal**, situado debajo de la tarjeta de la cuenta
+principal. El mismo panel aparece junto a esa tarjeta en el espacio de cuentas
+de Proveedores. Administra el inicio de sesión real de Codex, no la cuenta que
+atenderá la siguiente solicitud Pool. No añade una pestaña de Integraciones ni
+reemplaza los controles existentes de Pool.
+
+El **CODEX_HOME efectivo** mostrado pertenece al servidor de OpenCodex.
+Si usa un panel remoto, puede estar en un equipo distinto del navegador.
+**Perfil activo registrado** identifica al propietario registrado en el almacén
+de perfiles cifrados. El servidor verifica el inicio de sesión real antes de
+cambiarlo: un inicio de sesión modificado fuera de OpenCodex puede provocar
+un error de propiedad en lugar de sobrescribirse silenciosamente.
+
+<a id="save-and-switch"></a>
+
+## Guardar y cambiar
+
+Use **Guardar el inicio de sesión actual como perfil** para registrar el inicio
+de sesión de la aplicación. Si el inicio de sesión activo ya está registrado,
+esta acción actualiza su nombre y no añade otra cuenta. Cambiar de perfil
+requiere el almacén de credenciales en archivos compatible y un almacén de
+claves del sistema operativo disponible. Los códigos de diagnóstico explican
+por qué no están disponibles los controles. No eluda errores del almacén de
+claves o de propiedad copiando credenciales de Pool al archivo de inicio
+de sesión nativo. El panel permanece desactivado mientras la tarjeta principal
+está realizando su operación de reautenticación nativa mediante dispositivo.
+
+Seleccione **Cambiar** junto a un perfil guardado que esté inactivo.
+Revise su nombre y el **CODEX_HOME** mostrado; cierre Codex nativo en el equipo
+servidor que usa ese **CODEX_HOME**. Marque la casilla bajo los pasos para
+confirmar que Codex está cerrado y, después, confirme el cambio.
+No se envía ninguna modificación de credenciales antes de la confirmación.
+Justo antes de enviar la operación, el panel vuelve a leer el directorio actual,
+el propietario activo y el estado de recuperación. Si cambiaron, revise el
+nuevo estado y vuelva a confirmar. El backend sigue siendo la autoridad para
+los bloqueos, las comprobaciones de procesos, el drenaje de solicitudes
+en curso, la activación y la reversión.
+
+La confirmación muestra tres pasos: cerrar Codex en el equipo servidor para
+el **CODEX_HOME** indicado; marcar la casilla que confirma que está cerrado
+y confirmar el cambio; esperar el resultado y el perfil activo actualizado
+antes de seguir las instrucciones para volver a abrir Codex.
+Mantenga Codex cerrado hasta comprobar el resultado. Las instrucciones de
+reapertura esperan a que terminen la lectura de verificación y la actualización
+de cuentas. Si falla la actualización, se le pide actualizar antes de continuar.
+
+Si `CODEX_BUSY` bloquea el cambio, cierre Codex en el servidor para el
+**CODEX_HOME** indicado, seleccione **Actualizar estado** y revise el perfil
+activo. Seleccione **Cambiar** de nuevo y marque la casilla que confirma que
+Codex está cerrado antes de confirmar. Actualizar solo lee el estado:
+no reintenta el cambio.
+
+Un error de comprobación de procesos pide verificar que Codex esté cerrado
+e inspeccionar los diagnósticos del servidor. Los errores por solicitudes
+activas u operaciones ocupadas piden esperar a que termine el trabajo existente.
+Un error de almacenamiento indica que el servidor no puede acceder de forma
+segura al directorio de inicio de sesión o al almacén de perfiles; revise los
+diagnósticos antes de otro cambio. Los demás errores permitidos identifican
+problemas de perfil, almacén de claves, almacenamiento o recuperación,
+sin mostrar mensajes sin filtrar del servidor.
+
+Una respuesta perdida deja el resultado sin confirmar, incluso si el perfil
+activo actualizado ha cambiado. La ausencia de respuesta no significa que
+se haya restaurado el inicio de sesión original. Nada se reintenta
+automáticamente. Para reintentar un cambio, seleccione de nuevo la acción
+y confirme que Codex está cerrado.
+
+Los resultados se muestran como **Último resultado confirmado**.
+Una actualización manual borra el error visible, pero no confirma una
+transacción anterior cuya respuesta se perdió. Puede seguir apareciendo
+un requisito de reinicio de un cambio confirmado previamente.
+
+Después de un éxito, compruebe el perfil activo actualizado y vuelva a abrir
+Codex nativo en el servidor con el **CODEX_HOME** indicado. Siga cualquier
+requisito de reinicio mostrado. El panel vuelve a leer el estado de los perfiles
+y actualiza el controlador de cuentas existente. No llama a las operaciones
+de selección o configuración de Pool ni modifica claves de proveedores, tareas
+o historial. El backend sigue conciliando la identidad nativa `__main__`
+igual que en el flujo de la CLI.
+
+<a id="recovery-and-previous-profiles"></a>
+
+## Recuperación y perfiles anteriores
+
+Son operaciones diferentes:
+
+- **Recuperar el cambio interrumpido** concilia una transacción del backend
+  que quedó incompleta. **Restaurar la transacción pendiente** solicita
+  revertir esa transacción. Ambas requieren marcar la casilla que confirma
+  que Codex está cerrado antes de confirmar el cambio. Estos controles siguen
+  disponibles si no se puede leer una lista de perfiles dañada, pero los
+  diagnósticos indican que hay una recuperación pendiente.
+- **Volver al perfil mostrado anteriormente**, después de un cambio correcto,
+  selecciona el perfil mostrado antes del cambio mediante el flujo normal
+  con confirmación. Este acceso directo solo se conserva en la memoria de
+  la página, vinculado al directorio y al propietario activo esperado.
+  Desaparece al recargar la página o al cambiar el proxy o el propietario.
+  La API no devuelve el origen de la transacción: no es un historial de
+  deshacer verificado por el servidor. Otro operador pudo cambiar el inicio
+  de sesión entre la lectura previa y su cambio. Después de recargar,
+  seleccione directamente el perfil guardado que desee.
+
+Un error de red no demuestra que una escritura haya fallado o se haya revertido.
+Después de enviar una modificación, incluso si se pierde la respuesta, el panel
+vuelve a leer el estado del servidor y nunca reintenta automáticamente.
+Si falla la actualización, un cambio correcto no se presenta como deshecho.
+Actualice e inspeccione los diagnósticos antes de otra operación.
+El comando `ocx account main doctor` ofrece diagnósticos del servidor.
+
+<a id="scope-of-this-phase"></a>
+
+## Alcance de esta fase
+
+El panel enumera, registra, cambia y recupera perfiles existentes mediante
+`/api/native-main-profiles`. No inicia procesos de inicio de sesión ni expone
+tokens de escritura para la preparación. Añadir otro inicio de sesión nativo
+sigue siendo parte del flujo de CLI `ocx account main add`; el registro desde
+el navegador queda para un seguimiento separado de la incidencia #3417.
+La reautenticación mediante dispositivo de la cuenta principal actual es
+otro flujo y no se reemplaza con este panel.
+
+Los datos de los perfiles no se escriben en el almacenamiento del navegador.
+El cliente solo expone campos públicos, muestra códigos de error permitidos
+en lugar de mensajes sin filtrar del servidor y utiliza el mecanismo
+autenticado de solicitudes existente en la aplicación.
+Se mantienen las comprobaciones del backend para la autenticación de
+administración, las sesiones GUI/CSRF y la admisión de rutas.
diff --git a/docs-site/src/content/docs/es/guides/ollama-clients.md b/docs-site/src/content/docs/es/guides/ollama-clients.md
new file mode 100644
index 00000000000..183eb65f574
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/ollama-clients.md
@@ -0,0 +1,52 @@
+---
+title: Clientes compatibles con Ollama
+description: Conecta las herramientas que usan la API de Ollama a opencodex para utilizar tus modelos de proveedores configurados.
+---
+
+opencodex implementa una parte de la API HTTP de Ollama. Así, una herramienta que solo sabe comunicarse con Ollama puede usar los modelos que ya configuraste en opencodex. Las solicitudes se traducen a la ruta de Chat Completions y se envían al proveedor seleccionado. opencodex no descarga, almacena ni ejecuta modelos en tu equipo.
+
+## Conectar un cliente
+
+Usa la dirección del proxy como host de Ollama. En una instalación local predeterminada:
+
+```bash
+export OLLAMA_HOST=http://127.0.0.1:10100
+curl "$OLLAMA_HOST/api/tags"
+```
+
+Si el proxy exige una clave API, por ejemplo al escuchar en `0.0.0.0`, envíala igual que para `/v1/chat/completions`, como `Authorization: Bearer <opencodex key>`. Una clave limitada a determinados modelos solo puede ver y usar los que tenga permitidos. Estos endpoints están disponibles únicamente en el listener principal; el listener auxiliar de loopback sin autenticación, Remote Link y la entrada de administración del Hub no los exponen.
+
+## Endpoints
+
+| Endpoint | Comportamiento |
+| --- | --- |
+| `GET /api/version` | Versión de opencodex. |
+| `GET /api/tags` | Modelos de proveedores configurados, con nombres `provider/model`. |
+| `POST /api/show` | `{ "model": "provider/model" }` devuelve solo información conocida, sin tamaño de archivo, digest, plantilla ni licencia. |
+| `POST /api/chat` | Chat con mensajes `system`, `user`, `assistant` y `tool`. |
+| `POST /api/generate` | Un prompt, con `system` opcional. |
+
+Las demás rutas `/api/*` siguen formando parte de la API de administración de opencodex.
+
+## Campos de solicitud admitidos
+
+- `model`: un nombre de `/api/tags`.
+- `stream`: `true` de forma predeterminada, con JSON delimitado por saltos de línea. Usa `false` para obtener una sola respuesta JSON.
+- `images`: PNG, JPEG, GIF o WebP en base64, en los mensajes de usuario de chat o en la solicitud de generate.
+- `tools`, solo en chat: herramientas de función. Devuelve el mensaje del asistente sin modificar, incluido el `id` de cada llamada. Un resultado `tool` se empareja por `tool_call_id` o, si no está disponible, por `tool_name`.
+- `options`: `temperature`, `top_p`, `num_predict` y `stop`.
+- `format`: únicamente `"json"`.
+
+Cada solicitud `/api/chat` admite como máximo **1.024 llamadas a herramientas en total** entre todos los mensajes del asistente, incluidas las que ya tienen resultado. Superarlo devuelve HTTP 400 antes de contactar al proveedor. Reduce el historial y conserva cada resultado junto a su llamada correspondiente.
+
+Cualquier otro campo se rechaza con HTTP 400 en vez de ignorarse. Esto incluye `think`, `keep_alive`, `suffix`, `raw`, `template`, `context`, las demás `options`, un `format` con esquema JSON y las URL de imágenes. No se ofrecen los endpoints de gestión de modelos ni de embeddings de Ollama.
+
+No se pueden seleccionar combos, políticas de enrutamiento, alias `--fast` o de esfuerzo, ni proveedores que reenvíen las credenciales propias de quien hace la solicitud. Esas solicitudes fallan antes de enviar nada al proveedor.
+
+## Respuestas
+
+Una respuesta finalizada incluye `done: true` y `done_reason` con el valor `stop`, `tool_calls` o `length`. Los campos `prompt_eval_count` y `eval_count` aparecen cuando el proveedor informa del uso; no se incluyen campos de duración. Un flujo envía exactamente una línea `done: true`, después de que la respuesta del proveedor haya terminado por completo.
+
+Los errores usan el formato de Ollama `{ "error": "message" }` y conservan el estado HTTP, incluido `Retry-After` ante límites de tasa o rechazos por ocupación. Una respuesta detenida por un filtro de contenido o por un motivo desconocido se devuelve como error, nunca como una finalización normal. Si un flujo falla después de iniciarse, termina con un objeto `error` y no añade una línea `done: true`.
+
+Las solicitudes aparecen en el registro del dashboard como el resto del tráfico, y el encabezado de respuesta `x-opencodex-request-id` identifica la fila correspondiente.
diff --git a/docs-site/src/content/docs/es/guides/opencode.md b/docs-site/src/content/docs/es/guides/opencode.md
new file mode 100644
index 00000000000..aee2356f55a
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/opencode.md
@@ -0,0 +1,197 @@
+---
+title: "OpenCode"
+description: "Usa modelos enrutados desde OpenCode: opencodex inyecta el proveedor durante el lanzamiento y conserva tus archivos de configuración."
+---
+
+OpenCode combina varias capas de configuración JSON para leer sus proveedores. No ofrece una variable equivalente a `ANTHROPIC_BASE_URL`. `ocx opencode` resuelve esa integración: comprueba que el proxy esté en ejecución, construye un bloque de proveedor a partir del catálogo visible y lo inyecta mediante la configuración en línea de OpenCode (`OPENCODE_CONFIG_CONTENT`).
+
+<a id="quickstart"></a>
+
+## Inicio rápido
+
+```bash
+ocx opencode
+```
+
+El comando comprueba que el proxy esté en ejecución y abre OpenCode con los bloques generados `provider.opencodex` y `providers.opencodex`, solo para ese proceso. El primero usa la estructura heredada de V1 y el segundo la estructura nativa de V2. Ambos incluyen las variantes de esfuerzo de razonamiento en el formato de su cliente. Los argumentos adicionales se transmiten al cliente: `ocx opencode run "hello"`.
+
+Los modelos enrutados aparecen en el selector bajo el proveedor `opencodex`:
+
+```text
+opencodex/kiro/glm-5
+opencodex/gpt-5.6-sol      # native slugs stay unprefixed
+```
+
+<a id="reasoning-effort"></a>
+
+## Esfuerzo de razonamiento
+
+OpenCode ofrece el esfuerzo de razonamiento mediante *variantes* del modelo. opencodex genera una variante por cada esfuerzo declarado, incluido `none` cuando el modelo admite explícitamente desactivar el razonamiento. La selección llega al proxy como esfuerzo de razonamiento, además de mostrarse en el selector. Las asignaciones de esfuerzo al proveedor de origen que existan en opencodex siguen aplicándose.
+
+Se generan dos bloques de proveedor:
+
+| Bloque | Cliente que lo lee | Formato de variantes |
+|---|---|---|
+| `provider.opencodex` | OpenCode V1 (`npm` + `options`) | Mapa de opciones heredado |
+| `providers.opencodex` | OpenCode V2 (`package` + `settings`) | Array de configuración nativo |
+
+V2 usa su array nativo de variantes en lugar del mapa heredado. Ambos bloques identifican los mismos proveedores y modelos y se combinan en una sola entrada; ningún modelo aparece duplicado. V2 siempre escribe el array de variantes, vacío cuando no se declara ninguna, para impedir que el cliente invente opciones de esfuerzo bajo, medio y alto. En el bloque heredado, los modelos conocidos de razonamiento fijo desactivan por el mismo motivo todos los niveles generados automáticamente; esas entradas desactivadas no son esfuerzos seleccionables.
+
+Si se conoce el esfuerzo predeterminado del modelo, se exporta; elegir una variante sustituye ese valor en el cliente. Si el catálogo no declara un predeterminado, no se inventa ninguno. El lanzador regenera estos ajustes en cada inicio. Después de cambiar el predeterminado en opencodex, actualiza la integración administrada o vuelve a exportar la instantánea manual.
+
+<a id="images-and-attachments"></a>
+
+## Imágenes y archivos adjuntos
+
+OpenCode decide si un modelo admite imágenes a partir de su entrada de catálogo. No puede consultar models.dev sobre `opencodex`, porque ese proveedor no está registrado allí. Por eso, los bloques generados incluyen las capacidades por modelo que el proxy informa en `GET /api/models`. Por ejemplo, el bloque heredado contiene `attachment` y `modalities`:
+
+```json
+"gpt-5.6-luna": {
+  "name": "gpt-5.6-luna (native)",
+  "limit": { "context": 272000, "output": 128000 },
+  "attachment": true,
+  "modalities": { "input": ["text", "image"], "output": ["text"] }
+}
+```
+
+V2 recibe los campos nativos `capabilities.input` y `capabilities.output`. Cuando se conoce la compatibilidad con herramientas, también recibe `capabilities.tools`. Los clientes heredados leen los campos del ejemplo anterior. Si el catálogo anuncia entrada de imágenes para un modelo cubierto por el sidecar de visión, OpenCode permite enviar el adjunto para que el sidecar lo describa antes de la solicitud al proveedor de origen.
+
+V2 exige un booleano `tools` cuando existe el objeto nativo de capacidades. Si se desconoce la compatibilidad con herramientas, se omite ese objeto. Las modalidades de entrada conocidas siguen llegando a V2 mediante la migración del bloque heredado. Así se evita inventar capacidades o generar una configuración de proveedor inválida.
+
+Cuando una capacidad es desconocida, se conservan las suposiciones predeterminadas de OpenCode; esas suposiciones no prueban lo que admite el proveedor. Los metadatos que declaran explícitamente un modelo de solo texto impiden enviarle imágenes desde el cliente.
+
+Los modelos personalizados heredan los metadatos conocidos del catálogo, salvo que se guarde una anulación explícita. Una entrada personalizada que declara solo texto se mantiene así. Las capacidades desconocidas se omiten y una lista explícitamente vacía de esfuerzos no afirma que el modelo sea incapaz de razonar.
+
+<a id="your-own-config-is-never-modified"></a>
+
+## Tus archivos de configuración se conservan
+
+El lanzador no copia ni reescribe `~/.config/opencode/opencode.json`, los archivos de proyecto `opencode.json` / `opencode.jsonc` ni ninguna otra capa de configuración en disco. Puede leer la configuración global o del proyecto para detectar una definición del proveedor en `provider.opencodex` o `providers.opencodex`. Tus proveedores, agentes, atajos de teclado, entradas MCP y referencias relativas `{file:…}` siguen resolviéndose desde sus archivos originales.
+
+Solo para ese inicio, opencodex añade los dos bloques generados, `provider.opencodex` y `providers.opencodex`, mediante la configuración en línea de OpenCode. Esta capa se combina después de las capas global, personalizada y del proyecto, y sustituye únicamente las claves en conflicto para el proceso hijo.
+
+| Capa | Comportamiento con `ocx opencode` |
+| --- | --- |
+| Configuración global, personalizada o del proyecto | Permanece en disco tal como la escribiste |
+| Configuración en línea (`OPENCODE_CONFIG_CONTENT`) | Recibe los bloques generados `provider.opencodex` y `providers.opencodex`, combinados con la configuración en línea heredada |
+| Rutas relativas `{file:…}` | Se resuelven respecto del archivo de configuración que las definió |
+
+Si la configuración global o del proyecto ya define `provider.opencodex` o `providers.opencodex`, el lanzador muestra una nota informativa: la capa de `ocx opencode` tiene prioridad durante ese inicio.
+
+<a id="putting-the-block-into-your-own-config"></a>
+
+## Añadir el bloque a tu configuración
+
+`ocx opencode` inyecta el proveedor solo para un inicio. Ejecutar `opencode` directamente no configura el proxy. Para usar los modelos enrutados desde ese comando o desde una extensión del editor que no pase por el lanzador, `ocx export` muestra los mismos bloques para que los combines con tu configuración:
+
+```bash
+ocx export --client opencode
+```
+
+El proxy debe estar en ejecución. El comando muestra la configuración, el destino canónico (`~/.config/opencode/opencode.json`, o bajo `XDG_CONFIG_HOME` si está definido), la advertencia para combinarla y la línea de exportación de la variable de entorno. Nunca modifica ese archivo: añadir los bloques a tu configuración es una acción explícita tuya.
+
+:::caution[Combina la configuración; no la reemplaces]
+Combina ambos bloques, `provider.opencodex` y `providers.opencodex`, con el contenido existente. Reemplazar el archivo completo elimina tus otros proveedores, agentes, atajos y entradas MCP. Por ese motivo, `ocx export --out` rechaza sobrescribir un archivo existente. Dirige `--out` a una ruta temporal y copia los bloques:
+
+```bash
+ocx export --client opencode --out ~/opencodex-opencode.json
+```
+:::
+
+El bloque añadido manualmente es una instantánea estática: no sigue los cambios del catálogo como el bloque del lanzador. Vuelve a ejecutar `ocx export` después de añadir un proveedor o cambiar la visibilidad o los metadatos de un modelo. También puedes [activar la integración administrada](/es/guides/integrations/): `ocx sync` actualiza los bloques que ya administra, conservando los editados o eliminados manualmente.
+
+Después de combinar los bloques, exporta la clave de acceso antes de abrir OpenCode si el listener de inferencia exige autenticación. Un listener vinculado únicamente a loopback no la requiere:
+
+```bash
+export OPENCODEX_OPENCODE_API_KEY=<your key>
+```
+
+<a id="the-admission-key-is-not-written-to-disk"></a>
+
+## La clave de acceso no se escribe en disco
+
+Cuando el proxy requiere una clave API, la configuración en línea usa la referencia `{env:…}` de OpenCode en lugar del secreto. Los listeners vinculados a loopback la usan como `apiKey`; los demás la envían solo mediante `x-opencodex-api-key`, manteniendo separadas la autenticación del proxy y la cabecera `Authorization` del proveedor de origen.
+
+Ejemplo de loopback:
+
+```json
+"options": {
+  "baseURL": "http://127.0.0.1:10100/v1",
+  "apiKey": "{env:OPENCODEX_OPENCODE_API_KEY}"
+}
+```
+
+Ejemplo fuera de loopback:
+
+Este ejemplo se configura manualmente en el cliente remoto. Prepara primero un frontend TLS y usa su URL HTTPS; OpenCodex no termina TLS ni descubre esa URL para `ocx opencode`. HTTP sin cifrar en la LAN expone la credencial durante el transporte. Como alternativa, conserva el proxy en loopback y usa un túnel SSH local. Consulta [TLS para el listener de datos](/es/guides/remote-hub/#giving-the-data-listener-tls).
+
+```json
+"options": {
+  "baseURL": "https://proxy.example.com/v1",
+  "headers": {
+    "x-opencodex-api-key": "{env:OPENCODEX_OPENCODE_API_KEY}"
+  }
+}
+```
+
+El valor real solo se transmite mediante el entorno del proceso hijo. `OPENCODEX_API_AUTH_TOKEN` tiene prioridad, seguido del archivo protegido de token del servicio y de una clave API configurada. Un listener vinculado fuera de loopback exige una credencial aceptada.
+
+Un listener vinculado a loopback (`127.0.0.1`, el valor predeterminado) no exige una clave del plano de datos, aunque haya claves de cliente configuradas. Para ese listener puedes dejar sin establecer la variable de la referencia `{env:…}`. La URL local por sí sola no basta: un listener público vinculado a `0.0.0.0` sigue exigiendo una clave aceptada aunque se acceda por `127.0.0.1`. Exporta la clave cuando `hostname` esté configurado fuera de loopback; consulta [Acceso remoto](/es/reference/configuration/server/#remote-access). Esta clave pertenece a opencodex y es distinta de las claves de los [proveedores de origen](/es/guides/providers/).
+
+<a id="reverting"></a>
+
+## Revertir
+
+El lanzador no escribe ningún archivo de configuración generado en `~/.opencodex`. Ejecuta `opencode` directamente para que lea tu configuración como antes.
+
+<a id="model-limits"></a>
+
+## Límites de modelos
+
+`limit.context` solo se escribe cuando el catálogo informa una ventana de contexto confirmada. Si no la conoce, se omite todo el bloque `limit` y OpenCode conserva sus valores predeterminados.
+
+El límite de salida usa el máximo conocido del modelo en el catálogo o los metadatos generados. Solo si se desconoce se usa `32000`. Siempre se limita a la ventana de contexto, incluso cuando el máximo conocido es inferior a `32000`.
+
+Los límites de entrada conocidos también se incluyen y se limitan al contexto; los desconocidos se omiten. La exportación de la CLI y del dashboard, la actualización administrada y el lanzador comparten los mismos metadatos efectivos.
+
+El bloque del proveedor `opencodex` se regenera en cada inicio, por lo que los ajustes manuales por modelo dentro de ese bloque no se conservan. Guarda tus entradas personalizadas bajo una clave de proveedor propia.
+
+<a id="slow-local-models-prefill-timeouts"></a>
+
+## Modelos locales lentos: tiempos de espera durante el prefill
+
+opencode espera un tiempo limitado hasta recibir el primer encabezado de respuesta del proveedor (cinco minutos por defecto en la V2 actual) y aplica otro límite más largo entre fragmentos del streaming. Detrás del proveedor `opencodex`, un modelo local (LM Studio, vLLM, Ollama o cualquier endpoint alojado por ti) puede superar ese tiempo durante el *prefill* de un prompt grande: el procesamiento del prompt antes de emitir el primer token. En un turno sin streaming, el proxy no envía nada a opencode hasta que termina el proveedor de origen, por lo que vence primero la espera de encabezados de opencode y el turno falla con `Timed out waiting for response headers`, aunque el modelo siga trabajando.
+
+El proveedor `opencodex` generado reúne todos los proveedores enrutados en un solo bloque y los tiempos de espera de opencode se aplican al proveedor completo. Para ampliar o desactivar la espera de todo el proveedor, usa `opencodeClientExport` en la configuración de opencodex. Se omite por defecto, de modo que opencode conserva sus esperas nativas de encabezados y fragmentos salvo que actives esta opción:
+
+```json
+{
+  "opencodeClientExport": {
+    "headerTimeoutMs": false,
+    "chunkTimeoutMs": 1800000
+  }
+}
+```
+
+| Campo | Ajuste de opencode | Significado |
+| --- | --- | --- |
+| `headerTimeoutMs` | `settings.headerTimeout` | Espera hasta el primer encabezado de respuesta del proxy. Un número de milisegundos, o `false` para desactivarla. |
+| `chunkTimeoutMs` | `settings.chunkTimeout` | Espera entre fragmentos de respuesta del streaming. Un número de milisegundos, o `false` para desactivarla. |
+| `timeoutMs` | `settings.timeout` | Límite para la solicitud completa. Un número de milisegundos, o `false`. opencode no aplica un valor predeterminado. |
+
+Cada valor se emite sin cambios tanto en el bloque `provider.opencodex` (`options`) como en `providers.opencodex` (`settings`). Desactivar `headerTimeout` elimina la protección de opencode frente a un proxy bloqueado para todos los modelos enrutados a través de él; por eso conviene usar un valor explícito amplio (por ejemplo, `1800000` para treinta minutos), salvo que quieras expresamente quitar el límite. Un valor mal formado se descarta y opencode conserva su valor nativo predeterminado, en lugar de fallar al cargar.
+
+<a id="requirements"></a>
+
+## Requisitos
+
+OpenCode debe estar instalado y disponible en `PATH`:
+
+```bash
+npm install -g opencode-ai
+```
+
+El lanzador lee el catálogo con el token de administración local obtenido del entorno o del directorio del proxy en ejecución. Se conecta directamente a un listener de administración de loopback y rechaza redirecciones. Un hub vinculado solo a una dirección no local necesita activar `hub.managementIngress`. El token de administración no se pasa al proceso hijo de OpenCode: la inferencia sigue usando su clave de datos independiente. Si falta el token de administración local, el lanzador informa del problema; no vuelve a intentarlo con una clave de datos.
+
+
+El lector JSONC acepta una única marca BOM UTF-8 inicial, como la que escriben algunos editores Windows; no modifica los caracteres BOM dentro de cadenas.
diff --git a/docs-site/src/content/docs/es/guides/pi.md b/docs-site/src/content/docs/es/guides/pi.md
new file mode 100644
index 00000000000..e1cce2d336c
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/pi.md
@@ -0,0 +1,126 @@
+---
+title: "Pi"
+description: "Usa modelos enrutados desde Pi: ocx export genera un proveedor personalizado para models.json conectado al proxy."
+---
+
+Pi lee sus proveedores de un archivo JSON global, por lo que opencodex no lo inicia. `ocx export` genera el bloque del proveedor `opencodex`, con la URL base, la lista de modelos y un marcador de clave local que no es secreto. Debes combinarlo con tu propia configuración.
+
+<a id="quickstart"></a>
+
+## Inicio rápido
+
+Inicia el proxy y muestra la configuración:
+
+```bash
+ocx start
+```
+
+Mantén ese proceso en ejecución. En una segunda terminal, muestra la configuración:
+
+```bash
+ocx export --client pi
+```
+
+La salida comienza con el JSON e indica después la ruta de destino, la advertencia para combinar la configuración, la indicación de uso local y cuántos modelos tienen límites de contexto confirmados. Esta exportación solo admite un proxy de loopback sin autenticación; no configura el acceso remoto.
+
+```json
+{
+  "providers": {
+    "opencodex": {
+      "baseUrl": "http://127.0.0.1:10100/v1",
+      "api": "openai-completions",
+      "apiKey": "opencodex-loopback",
+      "compat": {
+        "sendSessionAffinityHeaders": true,
+        "supportsDeveloperRole": false
+      },
+      "models": [
+        {
+          "id": "anthropic/claude-opus-5",
+          "name": "Claude Opus 5 (anthropic)",
+          "input": ["text"],
+          "contextWindow": 200000,
+          "maxTokens": 128000
+        }
+      ]
+    }
+  }
+}
+```
+
+Los proveedores generados para Pi activan `compat.sendSessionAffinityHeaders`. Conserva esta opción al combinar o editar el proveedor: Pi aporta una identidad estable de sesión y OpenCodex deriva de ella la afinidad canónica de OpenCode Go. Pi puede omitir esa identidad cuando `cacheRetention` es `none`.
+
+También establecen `compat.supportsDeveloperRole` en `false`, para que Pi envíe su prompt de sistema como `system` en lugar de `developer`. OpenCodex reenvía los roles de Chat Completions tal como llegan; varios proveedores compatibles con OpenAI rechazan `developer` con HTTP 400, mientras que todos aceptan `system`.
+
+Los identificadores son los selectores canónicos del proxy. Los modelos enrutados aparecen como `provider/model` (`anthropic/claude-opus-5`), y los modelos nativos de OpenAI conservan su identificador sin prefijo (`gpt-5.6-sol`). El sufijo de `name` —`(anthropic)`, `(native)` o `(routed)`— permite distinguir modelos con el mismo nombre de distintos proveedores en el selector de Pi.
+
+Para un ID de modelo ascendente anidado, la exportación de Pi usa el selector sin codificar y con sus barras cuando el proxy en ejecución demuestra que llega al mismo modelo. Por ejemplo, `openrouter/openrouter/free` selecciona el modelo `openrouter/free` de OpenRouter y su fila Fast es `openrouter/openrouter/free--fast`. Un modelo que el proxy no puede verificar así, porque aún no ha cargado su inventario o porque otro modelo ya posee esa forma sin codificar, conserva su selector codificado. Los alias personalizados conservan sus nombres. Cuando el proxy usa el modo Codex Direct, los modelos nativos de OpenAI se excluyen de la exportación de Pi: ese modo reenvía la credencial OpenAI de cada cliente y Pi envía una clave de marcador.
+
+<a id="where-it-goes"></a>
+
+## Dónde se guarda
+
+El archivo global de modelos de Pi es:
+
+```text
+~/.pi/agent/models.json
+```
+
+:::caution[Combina la configuración; no la reemplaces]
+`ocx export` nunca escribe ese archivo. Combina el bloque `providers.opencodex` con el contenido existente: reemplazar todo el archivo destruye los demás proveedores configurados. `--out` sirve para una ruta temporal y no sobrescribe archivos existentes salvo que se indique `--force`:
+
+```bash
+ocx export --client pi --out ~/opencodex-pi-models.json
+ocx export --client pi --json > ~/opencodex-pi-models.json   # or redirect the byte-exact JSON
+```
+:::
+
+El bloque exportado es una instantánea estática. Vuelve a ejecutar `ocx export` después de añadir un proveedor o cambiar la visibilidad de modelos y combina el bloque nuevo con el anterior.
+
+<a id="the-admission-key"></a>
+
+## La clave de acceso
+
+El `apiKey` exportado es el marcador no secreto `opencodex-loopback`. No se genera ni se requiere una variable `OPENCODEX_API_KEY`. El exportador solo admite un proxy local de loopback sin autenticación y rechaza servidores remotos o protegidos con token. Las credenciales de los proveedores permanecen en la configuración de opencodex, como explica [Proveedores](/es/guides/providers/); nunca pongas una clave del proveedor de origen en este bloque de Pi. Para acceso remoto, usa una integración que admita credenciales de acceso al proxy. Cambiar el marcador no habilita la exportación remota de Pi.
+
+<a id="model-metadata"></a>
+
+## Metadatos de modelos
+
+`contextWindow` y `maxTokens` solo se incluyen cuando el catálogo informa una ventana de contexto confirmada. Si no hay una, se omiten ambos y Pi aplica sus valores predeterminados; `ocx export` indica cuántas entradas están en ese caso.
+
+Los límites de salida usan el máximo conocido del modelo en el catálogo o los metadatos generados. Solo si ese límite se desconoce se usa `32000`. La salida siempre se limita a la ventana de contexto, incluso cuando los límites conocidos son inferiores a `32000`.
+
+El campo `cost` se omite porque requiere cuatro precios y opencodex no tiene esos datos para los modelos enrutados; emitir ceros afirmaría que todos son gratuitos.
+
+`reasoning`, que antes se omitía, ahora se deriva de los niveles de esfuerzo del catálogo. Pi guarda un booleano: una lista **no vacía** genera `"reasoning": true`; sin lista, o con una explícitamente vacía, no se anuncia razonamiento. Así Pi ofrece el control solo para modelos cuyo catálogo declara que aceptan parámetros de razonamiento (`reasoning_effort`). La exportación también genera `thinkingLevelMap`, que oculta con `null` los niveles de Pi sin un destino declarado, para que no se ofrezca ni envíe un esfuerzo ajeno a la lista. Si se declara `ultra` sin `max`, el nivel `max` de Pi se asigna a `ultra`, que sí pertenece a la lista. Si necesitas otra asignación, edita `thinkingLevelMap` según la documentación de Pi.
+
+Trata `reasoning` como un metadato de interfaz de Pi, no como prueba de compatibilidad nativa del proveedor. Lo que el proxy envía para un valor `reasoning_effort` depende del adaptador y el modelo: puede reenviarlo, convertirlo a otro nombre del protocolo, limitarlo a los niveles configurados, emularlo u omitirlo (por ejemplo, con `noReasoningModels`). El booleano solo decide si Pi ofrece el control.
+
+<a id="attachment-and-request-compatibility"></a>
+
+## Compatibilidad de adjuntos y solicitudes
+
+:::note[Comportamiento pendiente de publicación]
+Los cambios de paridad de proveedores descritos aquí están en la cadena de PR de desarrollo; una versión instalada anterior puede conservar la conversión previa.
+:::
+
+OpenCodex normaliza las imágenes de usuario con formato Pi/MCP o Anthropic antes de elegir una ruta Chat nativa o traducida. Las imágenes devueltas por herramientas pasan a un mensaje de usuario traducido después de los resultados de herramientas emparejados; las imágenes normales de usuario y los resultados de texto pueden conservar la ruta nativa. Usa `tool_calls` y `role: "tool"` con `tool_call_id`: se rechaza la traducción de imágenes en resultados antiguos `function`, en lugar de descartar el resultado silenciosamente.
+
+Un esfuerzo explícito `none` se conserva al convertir a Chat. Los límites de salida y controles de muestreo se conservan para destinos Responses genéricos con clave API; el destino canónico de ChatGPT sigue aplicando sus restricciones. Esto no hace equivalentes los controles de todos los proveedores.
+
+El audio WAV/MP3 incluido en un mensaje de usuario o resultado de herramienta se conserva al convertir a OpenAI Chat como contenido `input_audio`. El audio de herramientas pasa a un mensaje de usuario posterior a los resultados emparejados, porque los mensajes de herramienta de Chat solo admiten texto. Un documento con sus propios bytes base64 en un mensaje de usuario también se conserva: llega a Anthropic, OpenAI Chat y Google como documento nativo, parte de archivo y datos en línea, respectivamente. Los demás casos devuelven un error explícito: audio remoto o incompatible, referencias remotas o identificadores de archivo que el proxy no pueda resolver, adjuntos en mensajes de sistema, documentos en resultados de herramientas y documentos enviados a un protocolo sin soporte para bytes. Las imágenes con solo identificador de archivo tienen la misma limitación. Convierte el adjunto a texto o usa un protocolo nativo y un modelo que lo admitan. Chat nativo y Responses sin conversión (incluido Azure) conservan su comportamiento; esto no promete compatibilidad multimedia de todos los modelos. Los límites de conversión de video dependen del adaptador.
+
+<a id="schema-status"></a>
+
+## Estado del esquema
+
+:::note[Sin verificar en una instalación real]
+La estructura anterior sigue la documentación pública de proveedores personalizados de Pi. **No se ha verificado** con un archivo `~/.pi/agent/models.json` real de una instalación de Pi. Si Pi rechaza el bloque exportado, el error está de nuestro lado: [abre una issue](https://github.com/lidge-jun/opencodex/issues) con el mensaje que muestra Pi.
+:::
+
+<a id="requirements"></a>
+
+## Requisitos
+
+Un proxy opencodex en ejecución (`ocx start`) y Pi instalado. `ocx export` lee el catálogo activo mediante la API de administración del proxy, por lo que no genera una configuración con la lista de modelos vacía.
diff --git a/docs-site/src/content/docs/es/guides/protocol-paths.md b/docs-site/src/content/docs/es/guides/protocol-paths.md
new file mode 100644
index 00000000000..bec839c875d
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/protocol-paths.md
@@ -0,0 +1,132 @@
+---
+title: "Rutas de protocolo"
+description: "Cómo llegan las solicitudes de Responses, Chat Completions o Messages a un proveedor, cómo inspeccionar su ruta y qué opciones la modifican."
+---
+
+opencodex sirve a tres API de cliente: **Responses** (`/v1/responses`), **Chat Completions** (`/v1/chat/completions`) y **Messages** (`/v1/messages`). Cada proveedor recibe un cable ascendente, decidido por su adaptador. Cuando el cliente API y el cable ascendente difieren, la solicitud se convierte en el camino de entrada y la respuesta se convierte en el camino de regreso. Esta página explica cómo se nombra esa ruta, cómo verla antes y después de una solicitud y qué ajustes la cambian.
+
+Los ajustes de esta página están desactivados de forma predeterminada excepto `antigravityDirect`, que está activado, y los dos interruptores de Messages administrado en una instancia Anthropic reconocida cuyo pool de cuentas esté habilitado. `antigravityDirect` habilita la ruta directa de Antigravity cuando corresponde, y una instancia agrupada deriva `managedMessagesNative` y `managedMessagesNativeOAuth` salvo que su `anthropicAccountPool.nativeMessages` sea `false`. Cualquier otro interruptor requiere activación explícita, y un `false` explícito en el despliegue desactiva cualquiera de los dos valores predeterminados del pool.
+
+<a id="delivery-modes"></a>
+
+## Modos de entrega
+
+Una ruta es una lista de saltos desde el cliente API al cable ascendente. Los saltos son los tres nombres de API, `ir` (petición neutral respecto del adaptador y forma de evento de opencodex) y `responses-internal` (Responses JSON o SSE producido sólo como un puente interno, nunca visto por un cliente).
+
+| Modo | Descripción | Ruta de solicitud de ejemplo |
+| --- | --- | --- |
+| `native` | Mismo API en ambos extremos; el cuerpo del cliente es lo que recibe el proveedor | `chat > chat` |
+| `translated` | Convertido una vez, a través del códec del cable de destino o el IR | `chat > responses`, `responses > ir > messages` |
+| `legacy-bridge` | Convertido a través de la forma interna Responses primero | `chat > responses-internal > ir > messages` |
+| `blocked` | Rechazado antes de que nada fuera enviado | Ninguno |
+
+`native` describe cómo viaja una solicitud. No es un veredicto de compatibilidad: una ruta nativa todavía puede cumplir con un proveedor que rechaza un campo, y los resultados verificados de Compatibility Lab son una cosa separada.
+
+Con todas las opciones desactivadas, una ruta elegible con un único proveedor sigue estas rutas:
+
+| Cliente API → aguas arriba | Ruta |
+| --- | --- |
+| Responses → Responses | Nativo |
+| Responses → Chat o Messages | Traducido a través de IR |
+| Chat → Chat | nativo (JSON cuando el cliente envía `stream: false`) |
+| Chat → Responses, Messages → Responses | traducido a través del codec Responses |
+| Chat → Messages, Messages → Chat | Puente legado |
+| Messages → Messages | nativo solo cuando el llamante reenvía su propia credencial Anthropic; el puente heredado para una clave opencodex administra |
+
+Los combos, las políticas de enrutamiento y el esfuerzo sintético o las filas de modelos rápidos toman el puente heredado de Chat y Messages a menos que un interruptor a continuación indique lo contrario.
+
+<a id="feature-effects"></a>
+
+## Efectos de función
+
+Algunas características de solicitud no pueden sobrevivir a cada conversión. Por ejemplo, los campos de Chat `n`, `logprobs`, `logit_bias`, `seed`, `audio` y `prediction` no tienen lugar en un cuerpo Responses, y el campo Messages `top_k` se deja caer en el camino hacia Responses. opencodex registra cada efecto como `passthrough`, `translated`, `degraded` o `unsupported` (mostrado como *Caído* en el tablero de instrumentos). Estos se declaran desde el código de los convertidores; no son resultados medidos.
+
+<a id="preview-a-path"></a>
+
+## Previsualizar una ruta
+
+Una vista previa se calcula solo a partir de su configuración. No envía nada a ningún proveedor, no avanza la rotación combinada y no se registra.
+
+- Panel de control: **API** página, **Solicitar vista previa de ruta**.
+- CLI:
+
+  ```bash
+  ocx api explain --model combo/main --inbound chat --feature request.seed
+  ocx api explain --model claude-sonnet-4-5 --inbound messages --json
+  ```
+
+La vista previa enumera cada ruta candidata con su ruta de solicitud, modo de entrega, efectos de características y si la política `reject` (abajo) la rechazaría. `ocx api protocols --json` enumera los nombres de las características que acepta. Una solicitud Messages que reenvía la propia credencial Anthropic del llamante se muestra con `caller-credential-required` en lugar de suponerse, porque una vista previa no tiene llamante.
+
+<a id="trace-a-request"></a>
+
+## Rastrear una solicitud
+
+Cada solicitud que llegó a un proveedor, o fue rechazada antes de enviar, registra la ruta que realmente tomó en su fila de registro: el modo final y las rutas, las razones, los efectos de las características y una ruta por intento físico. En el panel de control, **Logs** muestra una insignia de ruta, un filtro **Ruta de protocolo** y una sección **Ruta de protocolo** en el detalle de la solicitud. Las filas más antiguas no tienen datos de trayectoria y lo dicen; nada se adivina.
+
+<a id="unrepresentable-features"></a>
+
+## Características irrepresentables
+
+`protocols.unrepresentable` decide lo que sucede cuando una solicitud lleva una característica que su trayectoria caería:
+
+- `legacy` (predeterminado): la solicitud se envía como antes, y la pérdida solo aparece en los efectos de la característica de seguimiento.
+- `reject`: la solicitud se rechaza con HTTP 400 antes de que se envíe nada, nombrando solo las claves de características. Chat respuestas `invalid_request_error` con código `unsupported_feature`; Messages respuestas `invalid_request_error`. El trazo es `blocked`.
+
+Bajo `reject`, una ruta directa se juzga en el ingreso una vez que su proveedor y el protocolo están determinados. Los combos y las políticas no se juzgan en el ingreso; con `nativeChatCombos` encendido, un combo de Chat juzga a cada candidato y omite uno que no puede llevar la solicitud.
+
+<a id="rollout-switches"></a>
+
+## Interruptores de despliegue
+
+Estos interruptores preparan los nuevos caminos. Cada uno está desactivado de forma predeterminada excepto `antigravityDirect` y, en una instancia Anthropic reconocida con su pool de cuentas habilitado, los dos interruptores de Messages administrado. Una instancia agrupada habilita `managedMessagesNative` y `managedMessagesNativeOAuth` salvo que `anthropicAccountPool.nativeMessages` sea `false`; un `false` explícito en el despliegue sigue desactivando cualquiera de ellos. Un interruptor desactivado no cambia nada.
+
+| Interruptor | Cuando esté |
+| --- | --- |
+| `nativeChatCombos` | Un candidato de chat elegible dentro de un combo se envía de forma nativa desde su propia copia del cuerpo del cliente; los otros candidatos mantienen el puente. |
+| `managedMessagesNative` | Una solicitud Messages cuya ruta es un proveedor de Anthropic autenticado por clave directa se envía como Messages en lugar de a través del puente. Las rutas que necesitan un comportamiento de solo puente (un esfuerzo anclado, elisión de habilidades bloqueadas, el sidecar de búsqueda web, preprocesamiento de visión, filas sintéticas) permanecen en el puente. |
+| `managedMessagesNativeOAuth` | Amplía Messages nativo a las instancias de OAuth de Anthropic configuradas en `api.anthropic.com`, incluidos los pools de cuentas almacenadas y los hijos elegibles del failover. Solo es efectivo junto con `managedMessagesNative`. |
+| `directEncoders` | Para un flujo ascendente no Responses, la respuesta a un cliente Chat o Messages se codifica directamente a partir de los eventos del adaptador en lugar de a través del flujo interno Responses. El lado de la solicitud no cambia. |
+| `antigravityDirect` | **Activado por defecto**; establecerlo en `false` para apagarlo. Una solicitud de Chat o Messages cuya ruta es un proveedor Google Antigravity salta el cuerpo interno Responses en ambas direcciones: la conversación se decodifica desde el cuerpo del cliente directamente en lo que compila el adaptador Google, y la respuesta se codifica directamente como con `directEncoders`. El camino lee `chat -> ir -> other` o `messages -> ir -> other`. Las configuraciones de solicitud (modelo, esfuerzo, límites, elección de herramientas) aún pasan por las políticas habituales, por lo que la rotación de la cuenta, las reglas de esfuerzo y el uso no cambian. Combos, políticas, una herramienta de búsqueda web alojada, imágenes para un modelo marcado solo texto, un modelo que la intercepción de llamada de sombra podría reescribir y texto que el proxy reescribe (un catálogo de habilidades, un enlace de imagen generada) permanecen en el puente y la fila de registro nombra la razón. En una solicitud Chat, la conversación decodificada cuenta contra el presupuesto compartido de traducción. Si la representación intermedia retenida lo supera, se rechaza con HTTP 413 y `translation_buffer_limit` antes de enviar nada al proveedor. |
+| `shadowPlan` | Al final de cada Chat o solicitud Messages, el plan que una vista previa habría predicho se compara con la ruta que tomó la solicitud; un desacuerdo agrega `planMismatch: true` al registro de ruta de la fila de registro. No se envía ninguna segunda solicitud. |
+
+Cámbialos con el CLI o editando `protocols` en `config.json` ([referencia](/es/reference/configuration/server/#protocol-paths-protocols)):
+
+```bash
+ocx api policy                                   # show the current policy; changes nothing
+ocx api policy --rollout shadowPlan=on           # change one switch
+ocx api policy --unrepresentable reject
+```
+
+`ocx api policy` escribe solo cuando pasa una bandera de configuración, y solo cuando la ejecuta.
+
+<a id="shadow-plan"></a>
+
+### Plano de sombra
+
+`shadowPlan` es el primer paso seguro: no cambia ninguna solicitud. Comprueba si la vista previa está de acuerdo con la realidad para el tráfico que realmente envías. La comparación utiliza la ruta en la que se estableció la solicitud (para un combo, el objetivo que respondió), y compara el modo de entrega, el cable ascendente y la ruta de la solicitud. La ruta de respuesta no se compara, porque `directEncoders` lo cambia y la vista previa no modela ese cambio. No se comparan una solicitud de Messages enviada por el llamante y un rechazo de compatibilidad de Claude. Responses solicitudes no se comparan.
+
+`planMismatch` aparece en el `protocolTrace` de una fila devuelta por `GET /api/logs`. El panel de control aún no lo muestra.
+
+<a id="what-has-not-moved-yet"></a>
+
+## Lo que aún no se ha movido
+
+Estos caminos todavía utilizan el puente interno Responses o no están cubiertos:
+
+- El chat y las solicitudes Messages todavía se decodifican en un cuerpo con forma de Responses antes de la IR, incluso en una ruta traducida. La excepción es una solicitud de Chat o Messages a una única ruta Google Antigravity, a menos que `antigravityDirect` se establezca en `false`.
+- Los candidatos de la política de enrutamiento, combos alcanzados a través de una fila de esfuerzo, combos candidatos mientras `nativeChatCombos` está desactivado y Messages combos.
+- Direct (`directEncoders`) cubre solo una ruta concreta, no Responses en la entrega de transmisión. Los hijos combinados y de políticas, la compactación enrutada, los adaptadores de ejecución-giro (Cursor, Devin, los CLI de agentes de codificación, CodeBuddy) y los giros laterales mantienen el puente.
+- Un candidato combinado nativo de Chat que falla en la banda antes de cualquier salida no pasa al siguiente candidato; uno puenteado lo haría.
+- Los sidecares de búsqueda, visión y generación de imágenes web solo funcionan en la tubería Responses.
+- `previous_response_id`, `store`, `background`, y características de la suspensión de compactación Responses.
+- Los adaptadores cuyo cable no es ninguna de las tres API (Gemini, Kiro, Cursor y otros) se traducen a través del IR sin reivindicaciones de características.
+- Las solicitudes Messages nativas administradas dirigidas a Anthropic de primera parte conservan una identidad observada y coherente de Claude Code CLI: su agente de usuario, UUID de sesión y encabezados SDK permitidos, incluso al renovar el token o seleccionar una cuenta. El conjunto obligatorio incluye un `User-Agent` reconocido, `X-App: cli`, un `X-Claude-Code-Session-Id` con formato UUID, `X-Stainless-Lang: js` y `X-Stainless-Runtime: node`. Solo se conservan los campos SDK opcionales de la lista de identidad permitida; los encabezados configurados por el operador tienen prioridad. OpenCodex sigue controlando dónde coloca las credenciales y mantiene la lista de betas permitidas. Si la identidad falta o es inválida, usa los encabezados de compatibilidad existentes. Los hosts compatibles y las solicitudes Responses generadas conservan su comportamiento. Los encabezados por sí solos no autorizan una solicitud ni demuestran soporte oficial. También se reconoce el punto de entrada `sdk-ts` del agente SDK de TypeScript si aporta los mismos encabezados de identidad obligatorios; en solicitudes a Anthropic de primera parte se conservan sus betas nativas permitidas.
+- No está previsto admitir Chat nativo sobre OAuth. Messages nativo sobre Anthropic OAuth incluye las cuentas agrupadas bajo las mismas reglas de elegibilidad nativa y de vinculación de credenciales.
+- La ruta Messages nativa administrada solo reenvía valores de `anthropic-beta` de la lista permitida y únicamente a `api.anthropic.com`. Elimina los campos de nivel superior que quedan fuera de su lista de permisos sin producir efectos de esas funciones, y no aplica `claudeCode.stabilizePromptCache`. Un cliente Claude Code reconocido conserva `context-management-2025-06-27` junto con el campo `context_management`. En solicitudes con clave API u OAuth a Anthropic de primera parte, cualquier cliente Messages nativo puede enviar `thinking-binding-controls-2026-08-01` con `thinking.block_binding` si el pensamiento es adaptativo o está habilitado. Si falta la beta o el destino no la admite, el proxy elimina ese campo anidado y conserva el resto de los ajustes de pensamiento. Los endpoints de proveedores en la nube y los compatibles de terceros no heredan el soporte beta de Anthropic de primera parte. La comprobación usa el encabezado final, incluidas las betas configuradas por el operador; la beta por sí sola es válida para los [diagnósticos de transformación del pensamiento](https://platform.claude.com/docs/en/build-with-claude/preserved-thinking). Los nombres de las betas descartadas aparecen una sola vez en el registro del proxy como `anthropic-beta-dropped=<names>`.
+
+
+Las sesiones Anthropic nativas observadas conservan la identidad tanto en primer plano como con `claude --bg`, `X-App: cli-bg`. Las rutas de política, las de esfuerzo de combos y los combos Chat sin `nativeChatCombos` conservan el puente. Messages puede usar hijos Anthropic oficiales o compatibles con clave dentro de un failover estricto sin esfuerzo predeterminado: conserva el sobre original, sistema, mensajes, herramientas y puntos de caché con sus reglas nativas y ámbitos de clave. Un error reintentable anterior a la salida permite alternativa; cualquier bloque de contenido o herramienta compromete el destino e impide reproducirlo. Sin retención explícita, puntos sin TTL siguen sin TTL. Conservar prefijos no demuestra aciertos de caché.
+
+La identidad Claude reconocida conserva `dangerous-tool-use-2026-09-03` y `safeguards` para que el servidor revise llamadas, devolviendo el veredicto sin cambios. Con OAuth conserva nombres propios de herramientas sin prefijo `custom_`; reconocer encabezados copiables no demuestra identidad humana. Una beta `anthropic-beta` del operador puede enviar safeguards en otros clientes, pero sus nombres siguen prefijados y la revisión no puede emparejarlos. Messages nativo OAuth incluye cuentas agrupadas bajo las mismas reglas de elegibilidad y credenciales; Chat nativo OAuth no está previsto.
+
+Un encabezado `anthropic-beta` del operador que añade `dangerous-tool-use-2026-09-03` también envía safeguards para clientes no reconocidos, pero sus nombres de herramienta conservan el prefijo y la revisión del servidor no puede asociarlos. Copiar encabezados de identidad tampoco autentica al cliente ni demuestra soporte oficial.
diff --git a/docs-site/src/content/docs/es/guides/providers.md b/docs-site/src/content/docs/es/guides/providers.md
new file mode 100644
index 00000000000..17206852ea0
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/providers.md
@@ -0,0 +1,1037 @@
+---
+title: "Proveedores"
+description: "Autenticación y comunicación con proveedores de LLM: OAuth, claves API, reenvío de ChatGPT y modelos locales."
+---
+
+Un **proveedor** es un punto final de LLM ascendente más cómo llegar a él: un adaptador, una URL base, un modo de autenticación y una lista de modelos opcional. Los proveedores viven bajo `providers` en `~/.opencodex/config.json`.
+
+La vista general del proveedor del panel separa los detalles de conexión, el uso de la cuenta y las notas editables. Las notas aparecen una vez, debajo de las secciones de conexión y autenticación. Los ajustes preestablecidos de patrocinador compatibles también muestran una breve introducción, una etiqueta de patrocinador y enlaces al sitio o consola del proveedor. Estos enlaces conservan los parámetros de referencia del preset. La información del patrocinador se muestra solo cuando el nombre del proveedor configurado, el adaptador y el punto final coinciden con el ajuste preestablecido; nunca cambia el enrutamiento, la selección de la cuenta o los valores predeterminados.
+
+<a id="openai-account-modes"></a>
+
+## Modos de cuenta OpenAI
+
+| Id de proveedor | Uso | Regla de credenciales/cuenta |
+| --- | --- | --- |
+| `openai` | Codex inicio de sesión | Pool (predeterminado) selecciona las cuentas principales más las cuentas agregadas; Direct utiliza el inicio de sesión actual de la persona que llama/principal solamente. |
+| `openai-apikey` | OpenAI API | Solo clave API o grupo de claves configurado; nunca lee cuentas Codex. |
+
+Utilice `gpt-5.6-sol` desnudo con la opción Pool / Direct en la página de proveedores, o `openai-apikey/gpt-5.6-sol` para API. Las rutas de credenciales nunca se cruzan entre sí. La ruta API publica 1,050,000 metadatos de entrada de contexto / 922,000 máximos. Sus identificadores virtuales `sol-pro`, `terra-pro` y `luna-pro` mantienen su identidad pública seleccionada, mientras que el cable utiliza el modelo base más `reasoning.mode: "pro"`.
+
+Si el proveedor `openai` integrado no está disponible o está desactivado, el selector de cuentas del panel de control y la página Codex Auth pueden restaurarlo: las filas ausentes se crean a partir del preajuste canónico, las filas canónicas deshabilitadas se vuelven a habilitar sin reemplazar la configuración del modelo o modo guardado, y no canónicas a las filas `openai` no se les ofrece esa ruta de recuperación.
+
+La compatibilidad con Luna Reserve es una capacidad de cuenta ChatGPT en la ruta de avance canónica OpenAI, no un derecho de clave OpenAI API. Su selector manual de almacenamiento principal requiere un modo de escritorio local efectivo y un permiso de flujo ascendente actual vinculado a credenciales; una entrada de catálogo por sí sola no autoriza una solicitud. Consulte [Luna Reserve junto a modelos enrutados](/es/reference/cli/providers-accounts/#luna-reserve-alongside-routed-models) para ver la configuración, el orden de reinicio, los requisitos de autorización y los ayudantes no compatibles.
+
+Para añadir una cuenta con cuota agotada y finalizar su validación diferida, véase [Codex calentamiento de la cuenta](/es/guides/codex-integration/#codex-account-warmup).
+
+<a id="providers-overview-pool-capacity"></a>
+
+### Capacidad del grupo
+
+Para el inicio de sesión Codex en el modo Pool, la descripción general de proveedores muestra una estimación del peso configurado de la capacidad utilizada del grupo en lugar de presentar una cuenta arbitraria como el total del proveedor. La misma fila también muestra el porcentaje de cuota en bruto de la cuenta efectiva actual, para que pueda distinguir la estimación del grupo de la cuenta que usaría una nueva solicitud.
+
+Cuando la información de restablecimiento está disponible, la visión general muestra el siguiente tiempo de restablecimiento y la capacidad que se espera que se recupere como `+N% pool capacity`. **Cobertura incompleta** significa que una o más cuentas del grupo no podrían contribuir de manera segura a la estimación, por ejemplo, porque su plan o cuota es desconocido, su lectura es obsoleta o la cuenta está pausada o necesita reautenticación.
+
+Las cuentas Business Premium identificadas como `self_serve_business_prolite` cuentan como cinco unidades Standard en esta estimación. Ese peso solo sirve para mostrar capacidad: no selecciona cuentas ni crea una ventana de cinco horas si el proveedor solo informa uso semanal. La calibración sigue los [límites oficiales de Business](https://help.openai.com/en/articles/12003714-chatgpt-business-models-and-limits), comprobados el 20 de octubre de 2026. Los planes desconocidos mantienen el peso base y se informa su cantidad.
+
+Una advertencia de **Cobertura de ventana parcial** significa que algunas cuentas incluidas informaron una ventana de cuota pero no otra. La descripción general mantiene esas ventanas separadas y marca cada ventana afectada incompleta en lugar de tratar la lectura faltante como uso para esa ventana.
+
+Esta estimación es solo de visualización. No cambia la selección de cuenta, afinidad de sesión, conmutación automática, tiempos de reutilización o cualquier otra decisión de enrutamiento. Utilice el [Codex Fondo de cuenta de Auth](/es/guides/web-dashboard/#codex-auth-and-account-pools) para los controles de estado y enrutamiento de la cuenta individual.
+
+Las configuraciones v1 enviadas migran automáticamente al marcador 2 y a una fila consciente de las opciones. La configuración original se conserva una vez en `~/.opencodex/config.json.pre-openai-tiers-v2.bak`; restaurarlo con `cp ~/.opencodex/config.json.pre-openai-tiers-v2.bak ~/.opencodex/config.json`.
+
+<a id="claude-opus-55-progress-updates"></a>
+
+## Actualizaciones de progreso de Claude Opus 5.5
+
+Cuando el adaptador `anthropic` envía Claude Opus 5.5 a `api.anthropic.com`, mediante OAuth o clave API, OpenCodex usa de forma predeterminada el [modo de actualizaciones de progreso](https://platform.claude.com/docs/en/build-with-claude/thinking#progress-updates) de Anthropic. Las actualizaciones y los avisos intermedios aparecen como comentarios visibles del asistente en Codex, incluso si los resúmenes de pensamiento están ocultos. En este modo se omiten los resúmenes de razonamiento porque Anthropic no puede distinguir las actualizaciones del razonamiento con `display: "summarized"`. Los bloques de pensamiento firmados originales se conservan para continuar con las herramientas; no se decodifican ni reescriben sus firmas. Las actualizaciones aparecen cuando termina su bloque firmado. Los demás modelos y los endpoints compatibles de terceros conservan su comportamiento actual.
+
+Para pedir pensamiento resumido, envía explícitamente `reasoning.summary: "concise"` o `"detailed"`. OpenCodex envía entonces `thinking: {type: "adaptive", display: "summarized"}` sin la beta de actualizaciones y devuelve el pensamiento como razonamiento, en lugar de comentarios de progreso. En ese modo, las actualizaciones de Anthropic pueden quedar integradas en el resumen de razonamiento. También funciona si se omite el esfuerzo de razonamiento o vale `"none"`; no cambia el esfuerzo solicitado. Omitir `reasoning.summary` o enviar `"auto"` (predeterminado de Codex) o `"none"` conserva el modo de actualizaciones. La ocultación local del resumen sigue controlando la visibilidad del razonamiento y no oculta los comentarios de progreso en ese modo.
+
+<a id="anthropic-image-input"></a>
+
+## Entrada de imagen Anthropic
+
+Las semillas modelo Claude incorporadas anuncian la entrada de texto e imagen para `anthropic` (OAuth) y `anthropic-apikey`, consistente con [la visión general de los modelos de Anthropic](https://platform.claude.com/docs/en/models/overview). Las anulaciones explícitas de la modalidad de entrada por modelo siguen siendo autorizadas; los modelos desconocidos no se asumen con capacidad de imagen. Esto se aplica a todas las integraciones donde la configuración del cliente admite metadatos de capacidad de imagen: OpenClaw exporta una matriz `input` declarada, y Kimi Code exporta `capabilities: ["image_in"]` solo para modelos con entrada de imagen y añade `"thinking"` si el modelo declara una escala de esfuerzo. Kimi Code también recibe esa escala como `support_efforts`, limitada a `low`, `medium`, `high`, `xhigh` y `max`, en ese orden, y el valor declarado de `default_effort` si pertenece a la escala. OpenClaw omite `input` cuando no se declaran modalidades compatibles; Kimi omite `capabilities` para los modelos que no declaran entrada de imagen ni escala de esfuerzo. Los clientes sin un campo de capacidad compatible mantienen su forma de configuración existente. Después de actualizar opencodex, regenerar o actualizar la configuración del cliente gestionada por opencodex para recibir los metadatos actualizados.
+
+<a id="replayed-anthropic-thinking-signatures"></a>
+
+## Firmas de pensamiento Anthropic reproducidas
+
+En el punto final Responses, un flujo ascendente compatible con Anthropic puede rechazar una firma de pensamiento reproducida porque pertenece a un prefijo de conversación diferente. Cuando el error identifica explícitamente este problema de firma vinculante, opencodex puede eliminar el pensamiento firmado/redactado reproducido y volver a intentarlo una vez dentro del presupuesto de envío de la solicitud. Esto cubre HTTP 400 rechazos y errores de flujo iniciales antes de la salida o la actividad de la herramienta. La búsqueda web alojada y los puentes de imagen/vídeo comparten un límite de recuperación a través de sus iteraciones de modelo: solo se reenvía la inferencia rechazada, mientras que se conservan las llamadas de sidecar completadas y los resultados de la herramienta. Un reintento de finalización vacía comparte la asignación de su solicitud; las continuaciones ordinarias después de la salida no pueden usarla. Un reemplazo fallido se devuelve sin otro reintento de firma. Otros errores mantienen su manejo existente.
+
+La recuperación de Sidecar se desactiva cuando la contabilidad de gastos forzada no puede establecer recibos para envíos anteriores de sidecar ordinarios. Nunca aumenta la asignación de envío de llamadas o combo.
+
+Solo una finalización exitosa y no vacía recuerda el rechazo de esa conversación y la identidad de servicio durante cinco minutos. Solo las cargas útiles opacas rechazadas se suprimen cuando pueden ser identificadas; el pensamiento recién emitido sigue siendo reproducible. El historial de texto sin formato permanece disponible; un reintento fallido o cancelado no inhabilita la repetición de pensamiento en solicitudes posteriores.
+
+<a id="xai-responses-includes"></a>
+
+## Inclusiones de xAI Responses
+
+En las solicitudes Responses de xAI, OpenCodex elimina de `include` la entrada no admitida `output.encrypted_content`, también en el [endpoint regional de EE. UU.](https://docs.x.ai/developers/advanced-api-usage/regions). Conserva las demás entradas; si no queda ninguna, omite el campo. Los demás proveedores no se ven afectados.
+
+<a id="auth-modes"></a>
+
+## Modos de autenticación
+
+Las configuraciones de proveedor aceptan tres valores `authMode` (`key` es el valor predeterminado). El registro incorporado también etiqueta los preajustes locales por separado; los que normalmente omiten tanto `authMode` como `apiKey`.
+
+| `authMode` | Cómo se autentica | Utilizado por |
+| --- | --- | --- |
+| `key` | Envía su llave API (`Authorization: Bearer …`, o `x-api-key` / `api-key` por adaptador). La clave puede ser una referencia literal o una referencia `${ENV_VAR}`. | La mayoría de los proveedores. |
+| `forward` | Relés **tus encabezados de autenticación entrantes Codex** verbatim al proveedor - sin clave almacenada. Este es el passthrough de inicio de sesión ChatGPT. | OpenAI (adaptador `openai-responses`). |
+| `oauth` | Resuelve un token de acceso OAuth almacenado (actualizado automáticamente antes de la expiración) y lo usa como la clave portadora. | xAI, Anthropic, Kimi, Kiro, Google Antigravity, Cursor, Zed Hosted AI, Command Code, GitHub Copilot, Nous Portal. |
+
+La repetición de un error 429 con la misma clave mediante [`retryOn429`](/es/reference/configuration/) solo se aplica a proveedores con clave API (`authMode: "key"`). OAuth, el reenvío de credenciales y los preajustes locales quedan excluidos: sus credenciales no deben repetirse en el mismo token y los entornos locales no tienen una clave remota que conservar. La opción debe habilitarse expresamente, salvo los valores predeterminados documentados para destinos concretos. Mistral Chat oficial usa una política de espera con seis repeticiones e intervalo alternativo de diez segundos, dentro del límite de envíos de la solicitud. Las opciones explícitas de `retryOn429`, incluido `enabled: false`, tienen prioridad. El preajuste de Mistral también reenvía por defecto las claves de caché de instrucciones que recibe; `promptCacheKey: false` lo desactiva. La afinidad de caché mejora la posibilidad de reutilizarla, pero no garantiza un acierto ni elimina los límites de tokens por unidad de tiempo.
+
+Mistral usa un único proveedor con clave API para las claves de Studio y Vibe. La [documentación de claves API de Mistral](https://docs.mistral.ai/admin/identity-access/api-keys) describe los tipos de claves y límites de los planes; el proxy no deduce el nivel de suscripción de la clave. En `https://api.mistral.ai/v1`, el panel lee los presupuestos de API y Vibe desde `/v1/billing/budget` y el plan desde `/v1/billing/subscription`, usando la credencial y salida de inferencia. Las ventanas medidas muestran uso, total y nombre de plan reconocido. Los presupuestos solo se muestran: no ordenan claves, enrutan ni pausan tráfico, ni entran en el grupo de cuotas. Los presupuestos ausentes, malformados o no positivos, las monedas malformadas, los porcentajes fuera de rango y los nombres de plan desconocidos se consideran desconocidos o se omiten. Las últimas lecturas válidas aún recientes sobreviven a 402, 408, 429, 5xx y fallos de transporte, pero 401, 403 y otros rechazos de cliente no reintentables las suprimen.
+
+Para cada modelo, los plazos explícitos ascendentes de `Retry-After` se comparten entre llamadas con la misma credencial y modelo; la [referencia de `retryOn429`](/es/reference/configuration/providers/) explica la espera de recuperación tras un 429 sin plazo, su única prueba y cómo desactivarla con `requestPacing` y `respectRetryAfter`. Las ventanas de contexto y preferencias de compactación por modelo siguen siendo independientes.
+
+La cabecera del proveedor también muestra los límites de solicitudes y tokens observados pasivamente para OpenAI, Anthropic, xAI, Groq y Mistral, por clave y modelo observados; la [guía del panel](/es/guides/web-dashboard/) explica estas lecturas que solo se muestran y nunca consultan el llavero del sistema ni afectan al enrutamiento.
+
+Cuando la selección de claves por round-robin está habilitada, las solicitudes en cola vuelven a comprobar los enfriamientos de claves antes de enviarse y adquieren capacidad de ritmo para cualquier clave de reemplazo. Esto se aplica a Chat nativo, Messages, Responses y compacto. Esperar la capacidad de una clave de reemplazo no consume el tiempo de espera del encabezado de respuesta aguas arriba. El control del ritmo por clave y la selección round-robin usan HTTP/SSE protegido incluso cuando los WebSockets aguas arriba están habilitados; la dirección y la inyección exclusivas por WebSocket requieren una ruta sin esas políticas de claves. Esto no cambia la clave activa guardada. Un turno aguas arriba ya establecido conserva su credencial; los envíos posteriores se rechazan si esa clave entra en enfriamiento. Un rechazo de clave antes de la salida puede recuperar una clave sana dentro del límite de solicitud existente. Las solicitudes de Direct Images y de compactación registran los enfriamientos reales 401/429 sin reproducir ese POST de pago.
+
+<a id="anthropic-api-key-credit-exhaustion"></a>
+
+### Agotamiento de crédito de las claves API de Anthropic
+
+Los grupos de claves de la API de Anthropic con al menos dos claves intentan automáticamente una clave hermana cuando un error HTTP `400` o `402` completo indica que el saldo de crédito es demasiado bajo para acceder a la API de Anthropic. Esto se aplica a `invalid_request_error`, `billing_error` y `permission_error` antes de cualquier salida de texto o de herramienta. Las estrategias de rotación y de grupo omiten la clave fallida durante una hora, porque un saldo vacío solo se repone cuando se añaden créditos; cuando todas las claves están sin crédito, las solicitudes siguen usando la clave activa y devuelven el error original de Anthropic; elegir la clave como activa en el panel o reiniciar el proxy borra esa retención tras una recarga. El reemplazo comparte el límite de envío de la solicitud. Los errores `400` ordinarios son fallos terminales, y esto no habilita reintentos de la misma clave ni cambia el enrutamiento de la cuenta OAuth. Una anulación de encabezado que envía una credencial distinta no puede enfriar ni rotar la clave de grupo seleccionada.
+
+<a id="which-account-a-request-spends"></a>
+
+### Que cuenta gasta una solicitud
+
+La pregunta que la gente hace antes de conectar una cuenta es si opencodex se basará en la suscripción que el inicio de sesión ya paga, o facturará una cuenta separada API. La respuesta sigue el nivel de marketing anterior `authMode` en lugar del nivel de marketing del proveedor.
+
+- `forward` - el inicio de sesión ChatGPT. La solicitud lleva su credencial Codex, por lo que gasta el plan ChatGPT detrás de ese inicio de sesión e informa las ventanas de cuota Codex de ese plan. Qué ventanas existen depende del plan: no todos los planes tienen una ventana de cinco horas. Nunca se lee una clave API.
+- `oauth` - un inicio de sesión de suscripción. La solicitud lleva un token de acceso almacenado, por lo que gasta cualquier cuenta que haya iniciado sesión como, y opencodex informa cualquier ventana de uso que el proveedor expone.
+- `key` - la solicitud lleva la clave que usted proporcionó, por lo que el uso aterriza en la cuenta que posee esa clave, en los propios términos de esa clave. Eso es uso medido para una cuenta de pago por uso API, pero una asignación de plan cuando la clave *es* una suscripción: Z.AI GLM Coding Plan, Kimi Code, el plan de codificación BigModel, Command Code y CodeBuddy todos venden uno de esa manera.
+
+Una solicitud utiliza exactamente uno de estos, y el opencodex no se devuelve de uno a otro. Cuando no se puede resolver una credencial OAuth, la solicitud falla con un error de autenticación en lugar de alcanzar una clave almacenada, y la conmutación por error de grupo de claves que responde a un 429 o un 401 se rechaza completamente para OAuth y los proveedores de reenvío.
+
+Dos excepciones vale la pena conocerlas porque puedes golpearlas:
+
+- `xai` y `github-copilot` aceptan `authMode: "key"` en el mismo ID de proveedor, y si ese proveedor ya tenía una clave almacenada, ejecutar `ocx login` puede dejarlo en modo clave en lugar de cambiarlo a la suscripción. Lo que eso cambia es: una clave `xai` reorienta al proveedor a `https://api.x.ai/v1`, por lo que una cuenta diferente paga, mientras que una clave `github-copilot` sigue siendo una credencial de Copiloto contra `api.githubcopilot.com`, por lo que la suscripción de Copiloto paga de cualquier manera.
+- `orcarouter-oauth` es un flujo de consentimiento que acuña una clave de usuario `sk-orca-…` API. Una vez que lo ha hecho, la solicitud lleva una clave, por lo que sigue la regla `key` anterior.
+
+Los esfuerzos Mistral aceptados se declaran por modelo en `modelReasoningEfforts`; exportaciones como `ocx export --client opencode` solo ofrecen esos valores. El catálogo Codex añade `ultra` y `max` si falta, y los limita al mayor admitido:
+
+| Modelo | Esfuerzos |
+|---|---|
+| `zai-glm-5-3`, `zai-glm-5-3-flash` | `low`, `high`, `max` |
+| `mistral-large-4`, `mistral-large-4-0` | `low`, `medium`, `high` |
+| `deepseek-v4-1-flash-1017` | `low`, `high`, `xhigh`, `max` |
+
+GLM y Large 4 siguen la [guía de razonamiento Mistral](https://docs.mistral.ai/capabilities/reasoning). La fila DeepSeek se midió con HTTP 200 en noviembre de 2026, pues Mistral no documenta esos valores; puede cambiar. Una fila propia reemplaza la del registro. En Chat nativo con razonamiento, `ultra` pasa a `max` o al máximo declarado inferior, `high` en Large 4, salvo que la escala admita ultra. `reasoningEffortMap` se aplica al valor final y `__omit__` omite el campo. Con pensamiento y esfuerzo independientes, el esfuerzo también selecciona el interruptor; las rutas antiguas conservan su discriminador. `noReasoningModels` elimina `reasoning_effort`. Otros valores se conservan salvo fijación o límite que los reescriba.
+
+<a id="providers-that-accept-both-a-login-and-a-key"></a>
+
+#### Proveedores que aceptan tanto un inicio de sesión como una clave
+
+| Proveedor | Inicio de sesión de suscripción | Clave API |
+| --- | --- | --- |
+| OpenAI / ChatGPT | `openai` - Codex inicio de sesión; gasta el plan ChatGPT detrás de él | `openai-apikey` - un proveedor separado; el uso aterriza en la cuenta de la plataforma OpenAI que posee la clave |
+| Anthropic | `ocx login anthropic` - inicia sesión como su cuenta Claude. opencodex lee sus ventanas de uso de cinco horas y siete días; ese punto final no informa ningún nivel de suscripción | `anthropic-apikey` - facturación directa Anthropic API, no Claude suscripción |
+| xAI | `ocx login xai` - la pasarela de suscripción Grok CLI. opencodex lee los créditos semanales de SuperGrok, o el grupo mensual | el mismo proveedor `xai` con `authMode: "key"`, que apunta `https://api.x.ai/v1`, por lo que el uso aterriza en esa cuenta API |
+| Kimi | `ocx login kimi` — inicie sesión con su cuenta Kimi. `kimi-responses` es el mismo inicio de sesión de la cuenta Kimi enrutado por el cable de OpenAI Responses (el contenido de razonamiento permanece cifrado en el servidor, mientras que las llamadas a herramientas siguen visibles; el preajuste predeterminado de Chat mantiene el razonamiento en texto plano) | `kimi-code` — la forma de clave API del mismo transporte del plan Kimi Code |
+| Command Code | `ocx login command-code` — opencodex lee ventanas de cinco horas y semanales más un saldo de crédito | `commandcode` — el mismo servicio en `/provider/v1` con una clave |
+| GitHub Copilot | `ocx login github-copilot` - requiere una suscripción activa a Copilot | el mismo proveedor `github-copilot` con `authMode: "key"`. El flujo de dispositivos anterior es la ruta de acceso admitida, y cualquiera de las credenciales es una Copilot, por lo que la suscripción aún paga |
+| OrcaRouter | `ocx login orcarouter-oauth` — el consentimiento acuña una clave `sk-orca-…` de larga duración, propiedad del usuario, y la solicitud pasa a llevar una clave | `orcarouter` — la misma clave pegada a mano |
+| Meta Muse | `ocx login meta-muse` puede importar una clave local del CLI de Muse Code o iniciar el inicio de sesión por dispositivo. Meta limita esa credencial a su propio CLI, por lo que este es un uso no compatible: cómo se liquidan las llamadas no es observable desde la API, y debe tratar cada llamada como facturable en su cuenta | `meta-model` es la ruta admitida: cada llamada se mide por token, y una suscripción a Muse Code no funciona allí |
+
+Cuando el catálogo de suscripción de Grok publica ventanas de contexto seleccionables, opencodex usa el nivel más amplio: `[256000, 500000]` expone 500k para Grok 4.5–4.7, incluida la ruta Fast de 4.7. La ventana configurada del modelo y el límite de contexto habilitado pueden reducir ese valor. Si tu plan ofrece menos, configura ese límite: el catálogo no verifica el derecho de acceso de la cuenta.
+
+Cursor, Kiro, Zed Hosted AI y Nous Portal son solo de inicio de sesión y no tienen el equivalente de clave API. Google Antigravity también es solo para iniciar sesión: `ocx login google-antigravity` inicia sesión con su cuenta Google a través del cable de Cloud Code Assist, y el ajuste preestablecido `google` al lado es el AI Studio Gemini API, un producto diferente al que se llega con su propia clave, no un modo de clave para el mismo inicio de sesión. Si el inicio de sesión de Antigravity no descubre un proyecto de Cloud Code Assist, el fallo incluye un resumen saneado de `loadCodeAssist` y de la última respuesta `onboardUser`: estado HTTP, categoría de respuesta, presencia de finalización o error y tipos de los campos de proyecto conocidos. Distingue un rechazo HTTP, JSON inutilizable, una raíz no válida, una incorporación sin terminar y una finalización con error o sin proyecto. Omite valores del proveedor, nombres arbitrarios de claves e identificadores de cuentas o proyectos. El inicio de sesión sigue requiriendo un proyecto descubierto; no se guarda ninguna cuenta si el descubrimiento falla.
+
+La pestaña Cuentas Antigravity muestra un nivel de membresía observado como una insignia junto a la etiqueta de la cuenta, utilizando el ID de nivel ascendente (por ejemplo, `free-tier` o `gemini-pro`). No aparece ninguna insignia cuando el plan es desconocido; no afecta el enrutamiento ni la cuota.
+
+Gemini 4 Argon (`gemini-4-argon`) aparece en el preajuste `google` con niveles de pensamiento bajos, medios (el predeterminado) y altos. Google lo ofrece solo en el nivel pagado Gemini API, no en el nivel gratuito. El `google-antigravity`, Argon aparece con los mismos tres niveles, que se asignan a los modelos del protocolo `gemini-4-argon-low`, `-medium` y `-high`. Google lo limita a las cuentas AI Ultra y Enterprise elegibles. Cloud Code Assist sirve Argon solo al cliente Antigravity CLI, por lo que OpenCodex envía solicitudes de Argon y descubrimiento de modelo con el CLI User-Agent (`antigravity/cli/1.3.4` ) y mantiene el IDE User-Agent para cualquier otro modelo.
+
+En Vertex AI, `gemini-4-argon` recibe imágenes devueltas por herramientas, como capturas de pantalla, dentro de la respuesta de función coincidente. Esto evita el error 400 aguas arriba "Las solicitudes que terminan con un giro de modelo no son compatibles" después de una llamada de herramienta de producción de imágenes mientras se conservan las imágenes. Las imágenes de resultados duplicados o resultados sin una llamada coincidente se conservan en un mensaje separado después de las respuestas de la herramienta, con un marcador que explica que no se pudieron emparejar. No se necesita ningún cambio de configuración; este manejo es específico para Vertex Argon.
+
+Para Gemini en Antigravity, incluyendo Argon, los resúmenes de pensamiento marcados por el proveedor se mantienen separados de la respuesta: Responses usa elementos de resumen de razonamiento, Chat Completions usa `reasoning_content` y Messages usa `thinking` bloques. Los clientes deciden cómo mostrar esos campos. Un cliente Responses puede solicitar `reasoning.summary: "none"` para suprimir resúmenes; esto no desactiva el razonamiento interno del modelo. Una firma de pensamiento es metadatos de continuación y puede acompañar al texto ordinario, por lo que su presencia por sí sola no oculta ese texto. OpenCodex conserva texto de respuesta sin marcar incluso cuando su redacción suena como planificación o análisis.
+
+Los modelos Gemini, Argon en particular, a veces se saltan el pensar en un turno de llamada de herramientas y escriben su planificación en el texto de progreso visible, por ejemplo, una línea de progreso seguida de "Leamos google.ts a continuación". Una vez que el texto se envía de vuelta como historia, el modelo tiende a repetir el patrón en cada turno posterior. Para evitar que se extienda, OpenCodex envía Gemini solo la primera oración del texto que llegó antes de una llamada de herramienta en giros anteriores. Las respuestas finales se devuelven por completo y lo que muestra su cliente no se cambia.
+
+La lista integrada de `google-antigravity` incluye Gemini 3.8 Flash (`gemini-3.8-flash`), Gemini 4 Argon (`gemini-4-argon`), Claude Opus 5.5 (`claude-opus-5-5`) y Claude Sonnet 5.5 (`claude-sonnet-5-5`), con esfuerzo bajo, medio y alto. La lista que ves procede del descubrimiento de tu cuenta: Google habilita modelos por cuenta. Algunas ofrecen Claude Sonnet 4.6 y Claude Opus 4.6 (Thinking); otras, solo Claude Opus y Sonnet 5.5 en planes Pro o Ultra de facturación directa y sin prueba; Gemini 4 Argon requiere Ultra o Enterprise. Ambas generaciones de Claude se pueden mapear: 4.6 recibe un nivel de pensamiento; 5.5, una variante de modelo `-low`, `-medium` o `-high`.
+
+Las solicitudes de Antigravity solo se envían a cuentas que puedan atender el modelo solicitado. OpenCodex conserva en memoria durante seis horas la lista obtenida del descubrimiento de cada cuenta. Prefiere una cuenta que incluya el modelo. Si una cuenta no tiene una lista vigente —porque aún no se consultó, caducó o se perdió al reiniciar— todavía puede usarse, ya que no hay evidencia de que carezca del modelo. Una cuenta cuya lista vigente lo omita nunca recibe la solicitud, tampoco durante la recuperación ante errores 429 o de autenticación. Si la cuenta seleccionada lo omite y `oauthAccountFailover.enabled` está activado, se intenta otra cuenta que no esté en pausa ni requiera reautenticación. En caso contrario, OpenCodex rechaza localmente la solicitud con HTTP 403 `permission_denied` sin enviar nada al proveedor:
+
+- `The selected Google Antigravity account does not list the model "<model>" in its model discovery. Select an account that lists it, or enable oauthAccountFailover so OpenCodex can choose one.` Otra cuenta utilizable podría atender el modelo, pero la conmutación está desactivada.
+- `The selected Google Antigravity account does not list the model "<model>" in its model discovery, and no account that may serve it could be used for this request. Retry the request.` La conmutación eligió otra cuenta, pero no se pudo usar para esta solicitud.
+- `No usable Google Antigravity account lists the model "<model>" in its model discovery. Choose a model your accounts list, or add an account that has access to it.` Todas las cuentas utilizables omiten el modelo en sus listas vigentes.
+
+Una selección guardada de un modelo que ya no aparezca en la lista sigue las mismas reglas.
+
+Para comprobar qué modo está utilizando realmente un proveedor, ábralo en la página Proveedores: la fila **Autenticación** del bloque **Conexión** lee `OAuth`, `API key`, `ChatGPT passthrough`, `Local` o `No key needed`. Es una configuración a nivel de proveedor, por lo que las filas de la cuenta debajo de ella no la repiten.
+
+<a id="1-chatgpt-login-forward--passthrough"></a>
+
+## 1. Inicio de sesión ChatGPT (adelante / paso)
+
+El proveedor `openai` **no necesita clave API**. Direct reenvía las credenciales de su `codex login` existente; Pool resuelve una cuenta Codex principal o añadida antes de usar el mismo backend:
+
+```json
+{
+  "openai": {
+    "adapter": "openai-responses",
+    "baseUrl": "https://chatgpt.com/backend-api/codex",
+    "authMode": "forward"
+  }
+}
+```
+
+Solo se reenvía un conjunto curado de encabezados (`FORWARD_HEADERS`: autorización, ChatGPT cuenta id, OpenAI beta/originador/sesión - ver [Adaptadores](/es/reference/adapters/)). Este camino es también el que alimenta el [web-search y sidecars de visión](/es/guides/sidecars/).
+
+El catálogo ChatGPT passthrough también se superpone en las identificadores GPT-5.6 Sol / Terra / Luna (`gpt-5.6-sol`, `gpt-5.6-terra`, `gpt-5.6-luna` ) para las cuentas que pueden usarlas.
+
+<a id="2-account-login-oauth"></a>
+
+## 2. Inicio de sesión de la cuenta (OAuth)
+
+Los ajustes preestablecidos del proveedor pueden usar el inicio de sesión de la cuenta, incluido el GitHub Copilot, a través de un puente experimental no oficial de flujo de dispositivos. opencodex almacena sus credenciales en `~/.opencodex/auth.json`; los tokens actualizables se actualizan automáticamente, mientras que las claves duraderas se reutilizan hasta que el proveedor las revoca. `ocx login codex` también es aceptado, pero no es uno de estos proveedores: se dirige al grupo de cuentas Codex, el mismo flujo que `ocx account login codex`, que mantiene su propio libro de cuentas y necesita un proxy en ejecución. `chatgpt` y `openai` son alias de esa ruta.
+
+```bash
+ocx login xai          # xAI Grok
+ocx login anthropic    # Anthropic Claude (Pro/Max)
+ocx login kimi         # Moonshot Kimi
+ocx login nous         # Nous Portal (device grant; free + paid models)
+ocx login kiro         # import kiro-cli credentials (or token fallback)
+ocx login google-antigravity
+ocx login cursor       # standalone Cursor PKCE login
+ocx login zed          # Zed native-app callback login (experimental)
+ocx login command-code # Command Code browser OAuth (or import ~/.commandcode/auth.json)
+ocx login orcarouter-oauth # OrcaRouter browser consent + PKCE
+ocx login devin       # Cognition/Devin: import Devin CLI credential, else Auth0 browser sign-in
+ocx login dsh-account # DeepSeek Harness Desktop (import ~/.dsh/.credentials.yaml grant)
+ocx login github-copilot  # GitHub device flow → Copilot token (Copilot account)
+ocx login codex        # Codex account pool (aliases: chatgpt, openai; needs a running proxy)
+ocx logout <provider>
+```
+
+| Proveedor | Adaptador | URL base | Notas |
+| --- | --- | --- | --- |
+| `xai` | `openai-chat` | `https://cli-chat-proxy.grok.com/v1` | OAuth utiliza la pasarela de suscripción separada Grok CLI. La anulación de la clave API utiliza `https://api.x.ai/v1` y puede inyectar Procesamiento Prioritario. En vivo primero Grok catálogo; `grok-4.5` es el valor predeterminado. |
+| `anthropic` | `anthropic` | `https://api.anthropic.com` | Claude modelos; lista de modelos en vivo desde `/v1/models`. |
+| `kimi` | `openai-chat` | `https://api.kimi.com/coding/v1` | Modelos de programación de Kimi Code Plan. Usa por defecto el alias estable `kimi-for-coding` (actualmente K2.8 Preview): contexto de 1M tokens, entrada de texto e imágenes y razonamiento `low`/`high`/`max` (`max` por defecto). También incluye `k3.1-pro` y `k3.1-pro-highspeed` (K3.1 Pro), con contexto de 1M tokens y razonamiento obligatorio en los mismos niveles (`max` por defecto). Las selecciones retiradas `kimi-k2.x` migran al alias al actualizar. |
+| `kimi-responses` | `openai-responses` | `https://api.kimi.com/coding/v1` | El mismo inicio de sesión de la cuenta Kimi (reutiliza la credencial `kimi` OAuth) sobre el cable OpenAI Responses. Misma lista de modelos y capacidades que `kimi`; pensando que el contenido permanece encriptado en el lado del servidor, las llamadas a herramientas y los resultados permanecen visibles. |
+| `nous` | `openai-chat` | `https://inference-api.nousresearch.com/v1` | Nous Research pasarela de suscripción (el mismo backend que usa Hermes Agent). El inicio de sesión de concesión de dispositivo contra `portal.nousresearch.com`; el token de acceso es la inferencia por solicitud JWT. Pago mixto + catálogo de modelos `:free` (`tencent/hy3:free`, `stepfun/step-3.7-flash:free`,...) descubierto en vivo desde la cuenta iniciada. Los tokens de actualización son de un solo uso y se rotan en cada actualización. |
+| `kiro` | `kiro` | `https://runtime.us-east-1.kiro.dev` | Los botones de inicio de sesión y añadir cuenta del dashboard ofrecen AWS IAM Identity Center, Builder ID, Google, inicio de sesión de dispositivo con GitHub o Kiro CLI. El inicio de sesión nativo añade una cuenta sin cerrar la sesión de `kiro-cli`. La opción Kiro CLI importa o inicia una sesión de esa CLI; al añadir una cuenta, cambia temporalmente su selección y la restaura si se cancela o falla. |
+| `google-antigravity` | `google` | `https://daily-cloudcode-pa.googleapis.com` | Google OAuth sobre el cable de Cloud Code Assist. Live discovery utiliza el punto final autenticado `v1internal:fetchAvailableModels` de CCA y publica los modelos de agente disponibles para la cuenta iniciada; el catálogo mantenido sigue siendo la reserva. |
+| `cursor` | `cursor` | `https://api2.cursor.sh` | Inicio de sesión PKCE experimental, transporte HTTP/2 en vivo con una ruta de compatibilidad opt-in HTTP/1.1 y descubrimiento de modelo filtrado por cuenta. |
+| `zed` | `zed` | `https://cloud.zed.dev` | Experimental puente Zed AI alojado. Utiliza la devolución de llamada RSA de Zed, intercambia el token de cuenta por un token de inferencia alojada de corta duración y descubre la lista en vivo de la cuenta. |
+| `orcarouter-oauth` | `openai-chat` | `https://api.orcarouter.ai/v1` | El consentimiento del navegador y el intercambio de claves usan `https://www.orcarouter.ai` con S256 PKCE. La clave `sk-orca-…` API de propiedad del usuario devuelta se almacena en el almacén de credenciales existente y se reutiliza hasta que se revoca. |
+| `devin` | `devin` | `https://server.codeium.com` | Puente experimental no oficial de Cognition/Devin. El inicio de sesión importa primero la credencial que ya tiene el CLI de Devin instalado (`devin auth login` escribe un `devin-session-token` en su propio `credentials.toml`); cuando no hay ninguna, abre el inicio de sesión de Auth0 en el navegador e intercambia el token pegado mediante `RegisterUser` de Cognition por una clave API de larga duración. `ocx login devin-cli` sigue existiendo como alias obsoleto. Los modelos se descubren por cuenta con `GetCascadeModelConfigs`. La cuota de la cuenta proviene de `GetUserStatus` con un plazo único de ocho segundos para la solicitud y el cuerpo: ventanas diarias y semanales con fecha, más el fondo mensual de créditos Prompt y Flex para un plan facturado por crédito o una estrategia desconocida con ambas fechas de reinicio ausentes cuando hay un campo de saldo. Los créditos usados negativos omiten la ventana mensual; unos créditos disponibles válidos de cero la marcan como agotada. Una sonda que agota el tiempo conserva la última cuota buena. No aparece en el preajuste del panel por defecto. Los informes de chat y uso están verificados con una cuenta real en tres modelos. |
+| `dsh-account` | `dsh-account` | `https://api.deepseek.com/anthropic` | Proveedor experimental de cuentas de importación primero que reutiliza una cuenta de escritorio DeepSeek Harness (DSH) instalada y registrada. Lee las credenciales estrictamente de solo lectura desde `~/.dsh/.credentials.yaml` después de la importación explícita. Independiente de la facturación de claves DeepSeek API. |
+| `github-copilot` | `openai-chat` | `https://api.githubcopilot.com` | Experimental. GitHub flujo de dispositivos + intercambio `copilot_internal` (cliente VS Code OAuth). Requiere una suscripción activa de Copiloto; no un tercero oficial API. |
+
+Google Antigravity agrupa las variantes completas `low` / `medium` / `high` de un modelo en una entrada con un selector de esfuerzo. Esto incluye Claude Opus y Sonnet 5.5 y futuras versiones descubiertas durante la actualización automática. Los conjuntos parciales permanecen separados. Las opciones existentes activadas/deshabilitadas se incluyen en la entrada agrupada; los modelos genuinamente nuevos aún siguen su política de Nuevo modelo. Los ID de sufijo guardados continúan solicitando su nivel original. El enrutamiento de esfuerzo agrupado sobrevive a un reinicio proxy cuando el descubrimiento del modelo no está disponible temporalmente. Una sesión Codex en ejecución puede necesitar volver a cargar su lista de modelos después de actualizar el catálogo. Grupos de uso conocidos como Claude Sonnet y Opus 5.5 bajo su modelo base, incluyendo registros históricos de nivel. Sus costos mostrados se derivan de Anthropic estimaciones de referencia, no Antigravity cargos de suscripción.
+
+Google Antigravity Las sondas de cuotas de cuenta y proveedor utilizan Google puntos finales de contabilidad fijos, incluidos los modelos alternativos. Soportan DNS de IP falsa transparente para esos destinos al tiempo que retienen la verificación TLS, el rechazo de redireccionamiento y las verificaciones de direcciones privadas. Un URL base de proveedor personalizado cambia las solicitudes de modelo, no los destinos de cuota; `NO_PROXY` continúa seleccionando la política de ruta directa.
+
+<a id="google-tool-schema-loss-diagnostics"></a>
+
+### Google diagnósticos de pérdida de herramientas-esquema
+
+Las declaraciones de herramientas Google se compilan con la clase de punto final seleccionada. Cuando el debug del proveedor está activado - `ocx debug provider on`, el conmutador Logs del panel de control, o `OCX_DEBUG=1` - pérdida de esquema durante la conversión de compatibilidad en la ruta de directiva omitida o `compatible` emite un registro `[ocx:google:google-tool-schema-loss]` (cola con `ocx debug provider logs -f` ) que lleva solo la versión del informe, clase de punto final, un indicador `lossy`, un recuento de incertidumbre limitado, categorías de pérdida fija con recuentos limitados y un indicador de truncamiento. Los nombres de herramientas y propiedades, rutas, valores y texto de esquema nunca se incluyen. Con una política omitida o `compatible`, este diagnóstico observa la conversión existente sin rechazarla. Bajo `reject-lossy`, una compilación inicialmente con pérdidas o indeterminada por comparación se rechaza antes del envío; no se emite un registro de pérdidas separado para la solicitud rechazada. Bajo `reject-lossy`, una reparación de Vertex o Cloud Code Assist que borraría las restricciones emite un registro `google-tool-schema-repair` sin contenido similar y devuelve el original 400 sin un envío modificado; con una política omitida o `compatible`, la solicitud reparada se reproduce como antes. Direct AI Studio nunca realiza esta reparación. Los esquemas de salida nativos están fuera de ambas rutas de política. Ver el [referencia de comando debug](/es/reference/cli/agents/).
+
+
+Después de un fallo de actualización de terminal Nous, ejecute `ocx login nous` para volver a autenticar.
+
+### Zed Hosted AI (experimental)
+
+:::caution[No oficial: úsalo bajo tu responsabilidad]
+Zed no proporciona ni respalda este puente. Reutiliza el modelo alojado de tu cuenta de Zed derecho fuera del editor de Zed, que puede estar fuera de los términos de servicio de Zed. Zed puede calificar Limitar, restringir o suspender la cuenta. Revise los términos actuales de Zed antes de iniciar sesión; el proveedor se queda fuera hasta que lo agregues y ejecutes `ocx login zed` y el dashboard pregunta Usted debe reconocer este riesgo antes de que comience el inicio de sesión.
+:::
+
+Ejecute `ocx login zed` y complete el inicio de sesión de la aplicación nativa de Zed en el navegador. OpenCodex inicia una devolución de llamada de bucle, le da a Zed una clave pública RSA y mantiene la clave privada local coincidente mientras la devolución de llamada devuelve la identidad de la cuenta y el token de acceso cifrado. El identificador de cuenta y el token almacenados se emparejan en cada solicitud; OpenCodex intercambia esa credencial por el token LLM de corta duración de Zed antes de llamar al `https://cloud.zed.dev/completions`.
+
+La lista de modelos en vivo de Zed es de metadatos de visualización con alcance de cuenta. El id del modelo seleccionado se reenvía como se proporciona, y el puente infiere la familia de backend alojado desde la fila en vivo o el nombre del modelo; el descubrimiento del modelo no es una lista de permisos. El token de acceso de Zed no tiene punto final de actualización, por lo que cuando Zed lo revoque, ejecute `ocx login zed` nuevamente.
+
+Para los modelos OpenAI alojados en Zed, OpenCodex traduce `developer` instrucciones a `system` mensajes y elimina OpenAI campos privados y herramientas integradas no compatibles como `web_search`. La función y las herramientas personalizadas permanecen disponibles a través del delegado; una opción de herramienta sin herramientas compatibles se convierte en `none`.
+
+Las declaraciones de herramientas del turno actual incluidas en la entrada `additional_tools` de Codex se incorporan al catálogo de herramientas compatibles. Las llamadas a funciones y la entrada de herramientas personalizadas se retransmiten en orden, incluidas las llamadas intercaladas, para que un turno con herramientas pueda continuar después de su texto introductorio. Las llamadas incompletas conservan solo los argumentos recibidos y siguen incompletas; cancelar libera los datos almacenados en búfer. Una entrada completa de herramienta personalizada que entre en conflicto, incluidos los deltas posteriores, hace fallar el turno con llamadas incompletas. Los argumentos de función admiten diferencias de espacios en blanco JSON fuera de cadenas, escapes de cadena decodificados e instantáneas parciales compatibles, conservando los bytes entregados. Los literales numéricos deben coincidir exactamente (`1` y `1.0` entran en conflicto); también deben coincidir el orden de las claves de objeto y los miembros duplicados. Estos conflictos conservadores hacen fallar el turno. El anidamiento JSON se limita a 65.536 contenedores; una entrada más profunda falla con un mensaje claro sobre ese límite. Los fragmentos tardíos se validan de forma incremental. Si falla el proveedor de origen, el texto y el razonamiento recibidos permanecen visibles y el uso conserva únicamente los contadores numéricos. La retransmisión está cubierta por fixtures de streaming sintéticos; la compatibilidad con streaming alojado real sigue sin verificarse.
+
+Para los presets canónicos de Kimi Coding Plan (inicio de sesión de cuenta `kimi` y clave API `kimi-code`), opencodex solo reenvía a Chat Completions un `prompt_cache_key` estable proporcionado por el cliente; nunca genera uno. El protocolo Responses acepta el mismo campo, pero actualmente opencodex no lo envía por esa ruta. Kimi exige una clave estable de sesión o tarea para mejorar los aciertos de caché de Code Plan; las solicitudes sin clave permanecen sin ella. Si un proveedor que habilitó esta opción rechaza el campo, opencodex no lo elimina para reintentar ni modifica la configuración guardada. Para los demás proveedores, la opción sigue desactivada por defecto.
+
+Kimi La ruta nativa Responses de Code omite los mensajes del historial del asistente vacíos de contenido explícito para evitar su rechazo `assistant must not be empty`. Texto no vacío, espacios en blanco, rechazos, razonamiento y llamadas/resultados de herramientas son retenidos; el historial del cliente almacenado no es reescrito. Un mensaje vacío referenciado por un `item_reference` en la misma entrada se retiene en lugar de dejar una referencia colgante.
+
+Los precios de uso de Kimi Coding para `k3`, `k3[1m]`, `k3-256k`, `k3.1-pro` y `k3.1-pro-highspeed` son **estimaciones de referencia de la API** para `kimi`, `kimi-code` y `kimi-responses`, con la tarifa publicada de escritura en caché de cinco minutos. El preset de API `moonshot` aplica precios a los mismos modelos como `kimi-k3`, `kimi-k3.1-pro` y `kimi-k3.1-pro-highspeed`. Las estimaciones no reproducen la facturación ni la cuota de Code Plan: la variante de 1M de K3 consume aproximadamente el doble de cuota que `k3-256k`, y K3.1 Pro Highspeed aproximadamente el doble que `k3.1-pro`. El alias `kimi-for-coding` apunta ahora a K2.8 Preview y ya no usa el precio de K2.7; su estimación no está disponible salvo que el operador configure `modelCosts`. Por eso, las políticas y los límites que excluyen precios desconocidos pueden excluir ese alias. Consulta la [configuración de modelos de Kimi](https://www.kimi.com/code/docs/en/kimi-code/models.html) y los [precios de API](https://platform.kimi.ai/docs/pricing/chat).
+
+El preajuste `moonshot` (Kimi API) incluye `kimi-k3.1-pro` y `kimi-k3.1-pro-highspeed` junto a `kimi-k3` y los identificadores K2 aún admitidos. K3.1 tiene contexto de 1M de tokens, entrada de texto e imágenes y razonamiento obligatorio. El selector ofrece `low` / `high` / `max` (`max` de forma predeterminada); los esfuerzos Codex `medium` se envían como `high`, y `xhigh` como `max`. Un `none` explícito omite `reasoning_effort` para utilizar el valor predeterminado del proveedor. No se envían parámetros fijos de muestreo, como `temperature`, `top_p` o penalizaciones.
+
+Al iniciar, una lista guardada de modelos `moonshot` que aún coincida con la lista integrada anterior recibe ambos identificadores si apunta al endpoint internacional o de China. Esta actualización no añade modelos a listas editadas ni a una URL personalizada; la migración de identificadores retirados se aplica por separado. El preajuste usa ahora `kimi-k3.1-pro`, recomendado por el proveedor. `kimi-k2.5`, retirado el 2026-08-31, desaparece de los modelos iniciales de la API. Las selecciones guardadas en los endpoints oficiales internacional o chino migran a `kimi-k3.1-pro`, actualizando los metadatos integrados antiguos de contexto y razonamiento y conservando las anulaciones explícitas. Los destinos personalizados mantienen sus selecciones. `kimi-k2.6` y `kimi-k2.7-code`, incluido highspeed, siguen disponibles para usuarios existentes. Moonshot cierra la serie K2 a cuentas nuevas el 2026-10-31 y prevé retirarla a finales de diciembre de 2026; consulta la [lista de modelos de Kimi API](https://platform.kimi.ai/docs/models.md), comprobada el 2026-10-28.
+
+Un proveedor personalizado de `openai-chat` puede habilitar esta opción cuando su proveedor documente compatibilidad con `prompt_cache_key`:
+
+```json
+{
+  "providers": {
+    "example-compatible-provider": {
+      "adapter": "openai-chat",
+      "baseUrl": "https://api.example.com/v1",
+      "apiKey": "${EXAMPLE_API_KEY}",
+      "promptCacheKey": true
+    }
+  }
+}
+```
+
+El adaptador reenvía la clave que recibe y nunca inventa una. Aun así puede recibir una clave que el llamante no envió: la traducción de Claude Messages deriva una de `metadata.user_id`, o de una cohorte de modelo/sistema/herramientas cuando el cliente no envía metadatos, porque los backends de OpenAI informan `cached_tokens: 0` en todos los turnos sin clave. Así, "reenviado, no fabricado" describe a este adaptador, no a toda la ruta de la solicitud.
+
+Preservar el resto de la configuración del proveedor al agregar la opción, a continuación, volver a cargar o reiniciar opencodex. Para validar el almacenamiento en caché, compare la solicitud inicial en frío con solicitudes posteriores que lleven la misma clave estable. Deje la opción omitida o configúrela a `false` para secuencias ascendentes incompatibles, y deshabilite o elimine si una puerta de enlace estricta devuelve un error de campo desconocido de HTTP 400.
+
+También puede comenzar OAuth desde el [panel web](/es/guides/web-dashboard/).
+
+<a id="logging-in-from-another-browser-profile-or-another-machine"></a>
+
+### Iniciar sesión desde otro perfil de navegador u otra máquina
+
+Cuando se inicia un inicio de sesión, el proxy abre la URL de autorización en la máquina **Su propio**, utilizando el navegador predeterminado del sistema operativo y, por lo tanto, el perfil predeterminado. Ese es el comportamiento correcto para un escritorio local y el incorrecto en dos casos comunes: necesita un perfil de navegador diferente (una identidad de trabajo, una segunda cuenta) o el panel de control está abierto contra un proxy que se ejecuta en otro lugar.
+
+Cada superficie de inicio de sesión muestra la URL de autorización con un botón de copia, el código del dispositivo cuando el proveedor emite uno y las instrucciones actuales. Los flujos de devolución de llamada del navegador también muestran un campo para pegar la URL de redirección o el código de autorización. Durante la aprobación del dispositivo, ese campo está oculto: introduzca el código mostrado en la página de verificación del proveedor. Si el proveedor cambia a la entrada manual, el panel de control reemplaza el código antiguo y las instrucciones en su próxima encuesta de estado.
+
+Si el proxy intenta abrir un navegador y no puede, el inicio de sesión lo dice por encima de la URL y continúa: abra la página de inicio de sesión desde el enlace o cópiela. Un inicio de sesión del dispositivo nunca abre un navegador por sí mismo; **Copiar código & abrir** copia el código y abre la página de verificación con un solo clic, y el panel de control sigue esperando mientras el código del proveedor siga siendo válido. En la aplicación de escritorio, estos enlaces se abren en su navegador predeterminado.
+
+Para evitar que el proxy abra un navegador, marque **No abra un navegador en la máquina proxy** junto al botón de inicio de sesión o configúrelo permanentemente:
+
+```json
+{ "oauthOpenBrowser": false }
+```
+
+Ausente y `true` abiertos, por lo que nada cambia para una instalación existente; solo una disminución explícita de `false`. `POST /api/oauth/login` y `POST /api/codex-auth/login` también aceptan un booleano por solicitud `openBrowser` que anula la configuración almacenada para ese inicio de sesión.
+
+Dos casos se comportan de manera diferente, y vale la pena saber en cuál se encuentra:
+
+- **Un perfil de navegador diferente en la misma máquina** funciona solo con el enlace copiado. El bucle de retorno de llamada en `127.0.0.1` todavía completa el flujo.
+- **Un flujo de devolución de llamada del navegador en una máquina diferente** también necesita el retroceso de pegado, porque el URI de redirección sigue siendo `http://127.0.0.1:<port>/callback` en el host del proxy. Termina el inicio de sesión allí, luego pega la URL de redirección (o solo el código) nuevamente en el tablero o `ocx account code`.
+
+Los proveedores de código de dispositivo nunca abren un navegador desde el proxy en ningún caso: muestran un código y una URL de verificación para abrir donde sea que haya iniciado sesión.
+
+<a id="headless-claude-login-code-display-mode"></a>
+
+### Inicio de sesión Claude sin cabeza (modo de visualización de código)
+
+Para Anthropic hay un camino más limpio que pegar una redirección muerta: el inicio de sesión **code-display**. Anthropic redirige a su propia página y muestra una cadena `code#state` en lugar de llamar al proxy, por lo que nada necesita llegar a `127.0.0.1` en el host del proxy.
+
+```bash
+ocx login anthropic --headless
+```
+
+A lo largo de la gestión API, comience con `POST /api/oauth/login` y `{"provider":"anthropic","mode":"code"}`; la respuesta lleva un `flowId` y un `expiresAt` (10 minutos). Envíe la cadena pegada al `POST /api/oauth/login/code` con ese `flowId`. La respuesta es el resultado del intercambio de tokens, `{"ok":true,"account":…}` o `{"ok":false,"error":…}`, por lo que una persona que llama alojada con un solo cuadro de pegado sabe si el inicio de sesión realmente funcionó. Una pasta con el estado incorrecto, o sin código, se rechaza antes de cualquier solicitud de token y deja el flujo abierto para otro intento; una pasta que llega al intercambio de tokens usa el flujo hacia arriba, así que inicie un nuevo inicio de sesión si ese intercambio falla.
+
+Solo `anthropic` y `anthropic2` admiten este modo; otros proveedores responden `code_mode_unsupported`. Varios inicios de sesión de código pueden estar en vuelo a la vez, cada uno anclado a su `flowId`, pero todos escriben la misma tienda de cuentas: la más reciente se convierte en la cuenta activa Claude. Esto está destinado a un operador en un host sin cabeza, no para aislar usuarios no relacionados en una instancia compartida.
+
+<a id="multiple-oauth-accounts"></a>
+
+### Múltiples cuentas OAuth
+
+OAuth proveedores cuyas credenciales incluyen un ID de cuenta estable o correo electrónico pueden mantener más de un inicio de sesión. La página Proveedores muestra esas cuentas en un menú desplegable, le permite agregar otra y cambia la cuenta activa sin cerrar la sesión de las otras. Un inicio de sesión normal con una credencial sin identidad Kimi reemplaza la ranura activa, mientras que un **Añadir cuenta** explícito conserva esa ranura y activa una nueva y distinta. Las cuentas de Kiro se identifican mediante el ARN del perfil y, cuando está disponible, el correo electrónico del usuario conectado. Distintos usuarios de un perfil de organización pueden conservar credenciales separadas. `chatgpt` siempre es de una sola ranura porque las cuentas de grupo Codex tienen un libro mayor separado. Los tokens permanecen en `~/.opencodex/auth.json`; `/api/oauth/accounts` devuelve solo metadatos enmascarados.
+
+<a id="cockpit-tools-antigravity-import"></a>
+
+### Importación de Antigravity desde Cockpit Tools
+
+En v1, OpenCodex solo importa archivos JSON de **Antigravity exportados desde Cockpit Tools**, para el proveedor `google-antigravity`. En el dashboard, selecciona el archivo local desde la pestaña Cuentas de ese proveedor. El dashboard no muestra el contenido del archivo ni las credenciales; solo informa cuántas cuentas se importaron, se actualizaron, fallaron o no son compatibles. En v1 se rechazan las exportaciones de otros proveedores de Cockpit Tools.
+
+El CLI solo acepta la exportación desde un archivo o entrada estándar, nunca lo pegue en un argumento de comando:
+
+```bash
+ocx account import google-antigravity --format cockpit-tools --file <path> [--json]
+cat accounts.json | ocx account import google-antigravity --format cockpit-tools --stdin [--json]
+```
+
+En línea JSON y argumentos posicionales adicionales son rechazados. Mantenga los archivos exportados privados y elimínelos o guárdelos de forma segura después de importarlos.
+
+Cada registro puede incluir `project_id` para una cuenta cuyo proyecto de Cloud Code Assist no se descubra automáticamente. Debe ser un identificador de proyecto de Google Cloud de 6 a 30 letras minúsculas, dígitos o guiones. OpenCodex solo lo usa si el descubrimiento no encuentra un proyecto y una consulta de cuota con el token de esa misma cuenta lo valida; de lo contrario, el registro falla con `missing_project` y no se guarda nada. El proyecto descubierto siempre tiene prioridad.
+
+<a id="oauth-reliability"></a>
+
+### OAuth fiabilidad
+
+opencodex coordina la actualización de tokens y el enrutamiento de grupo Codex para que las solicitudes concurrentes no aceleren el almacén de credenciales. Esto es trabajo de confiabilidad y diagnóstico: **no** garantiza protección contra la aplicación del proveedor, los límites de solicitudes o las acciones de la cuenta.
+
+**Refrescar la coordinación.** Antes de una llamada enrutada, un token de acceso vencido se actualiza una vez cada `(provider, account)`:
+
+1. En proceso de un solo vuelo - llamantes concurrentes comparten una promesa de actualización.
+2. Bloqueo de archivos por cuenta: los escritores de procesos cruzados se serializan en la misma cuenta.
+3. Generación CAS: persiste solo cuando la generación de credenciales almacenada aún coincide; un escritor más nuevo gana y un resultado de actualización más antiguo no puede sobrescribirlo.
+
+Los fallos de actualización de terminal marcan la cuenta como que necesita una nueva autenticación en lugar de volver a intentarlo para siempre.
+
+Para la credencial principal nativa Codex en `CODEX_HOME/auth.json`, cancelar una solicitud detiene una actualización en espera antes de que comience el intercambio de tokens. Un intercambio que ya comenzó termina dentro de su propio tiempo de espera de 30 segundos y guarda el acceso exitoso y actualiza los tokens antes de informar la cancelación de la solicitud. Esto conserva el token de actualización rotado para solicitudes posteriores; un reemplazo de credenciales externo concurrente aún tiene prioridad.
+
+**Enfriamientos (Codex pool).** Una respuesta ascendente `429` o de cuota establece un enfriamiento duro a partir de `Retry-After`, de las cabeceras `reset` de cuota (con límite) o de un breve retroceso predeterminado. Las cuentas en un enfriamiento explícito por `Retry-After` no se sondean antes de tiempo; los enfriamientos derivados de un restablecimiento pueden recibir un arrendamiento de sonda con cadencia para detectar la recuperación sin inundar al proveedor. Los enfriamientos de modelos nativos derivados de un restablecimiento mantienen la cuota nativa compartida (incluidos GPT-5.6 Terra/Luna) separada de `gpt-reserve`. Los modelos del grupo compartido siguen protegiéndose unos a otros; un éxito ordinario no puede borrar un enfriamiento de la Reserva. Un `Retry-After` explícito y los enfriamientos predeterminados siempre abarcan toda la cuenta.
+
+**Afinidad de sesión.** La afinidad entre hilo de Codex y cuenta es local al proceso (solo en memoria; no persiste entre reinicios del proxy). Ante fallos de credenciales (`401` / `403`), la cuenta se pone en cuarentena para volver a autenticarse y se borran las afinidades de esa cuenta. En `429`, la cuenta entra en enfriamiento, las afinidades se borran y la selección del grupo puede rotar: los hilos no quedan fijados a través de una respuesta de límite de velocidad.
+
+**Volver a una cuenta recuperada.** Para reanudar el uso de la cuenta de máxima prioridad durante una tarea en curso, active `ocx config set codexAccountPriorityFailback true` y mantenga la estrategia Pool en `quota` con la conmutación automática habilitada. Por ejemplo, una tarea puede pasar de Plus a otra cuenta cuando se llena su ventana de cinco horas y luego volver a Plus después de que la actualización de la cuota confirme la recuperación. Mientras fluyen las solicitudes, los intentos de actualización en segundo plano se ejecutan como máximo una vez cada cinco minutos. La solicitud que desencadena una actualización puede seguir utilizando la cuenta anterior; la siguiente solicitud después de que se complete la actualización puede retroceder. Las solicitudes que ya se están ejecutando terminan en su cuenta capturada. Los pines de cuenta manuales y las restricciones de acceso al modelo aún se aplican. Esta función está desactivada por defecto; use `ocx config set codexAccountPriorityFailback false` para restaurar enlaces estables.
+
+El umbral efectivo de la cuenta de origen vinculada controla esta preferencia: la anulación `0` la deshabilita, y una anulación positiva funciona incluso cuando el umbral global es `0`. Un candidato debe tener un uso conocido y no agotado por debajo de su propio umbral efectivo positivo. El candidato `0` elimina solo esa preferencia de umbral; aún se aplican la elegibilidad, el tiempo de reutilización y los bloqueos duros. Cada ventana que contribuye a su puntuación necesita una observación reciente en vivo en este proceso. Las actualizaciones solo de créditos, las ventanas retenidas y las barras de visualización hidratadas no prueban por sí mismas la recuperación.
+
+**Metadatos del cliente Codex.** La ruta de reenvío de ChatGPT transmite los encabezados permitidos por `FORWARD_HEADERS`: autorización, `chatgpt-account-id`, originador, identificadores de sesión e hilo y los demás encabezados de Codex admitidos; consulta [Adaptadores](/es/reference/adapters/). El modo Pool solo sustituye la autenticación y `chatgpt-account-id` por los de la credencial elegida. OpenCodex **no inventa** la identidad oficial del cliente, como `originator` o los encabezados de sesión e hilo, si el cliente no los envió.
+
+Para el diagnóstico de compatibilidad de cuenta-interruptor, habilitar la depuración del proveedor (`ocx debug provider on`) agrega una línea `[ocx:codex:affinity]` por respuesta directa canónica ChatGPT. La línea contiene presencia de encabezado, cubos de tamaño aproximado, etiquetas de igualdad HMAC locales de proceso, resúmenes seguros de campos de giro de nivel superior conocidos y un recuento de campos de giro desconocidos. Nunca incluye credenciales sin procesar, identificadores de cuenta, valores de certificación, identificadores de subproceso/sesión, metadatos de turno o cuerpos de solicitud; las etiquetas cambian intencionalmente después de cada reinicio del proxy. Use `ocx debug provider logs -f` mientras reproduce las dos solicitudes, luego ejecute `ocx debug provider off`. Esta captura es solo de observación y no elimina metadatos, reintenta una solicitud, cambia de cuentas, restablece un subproceso o afecta el enrutamiento.
+
+**Diagnóstico y reauth.** Human `ocx status` imprime un bloque de salud OAuth (identificadores de cuenta redactados, sin tokens). `ocx doctor` agrega una sección de confiabilidad OAuth con comprobaciones de almacenamiento grabable / de un solo vuelo y filas WARN que incluyen una acción de recuperación. Cuando una cuenta de proveedor OAuth necesita reautenticación, ejecute `ocx login <provider>` (o utilice Reautenticar en el panel de control). Codex cuentas de grupo no son uno de esos proveedores, pero `ocx login codex --reauth` rutas a su cuenta de grupo de reautenticación, que el tablero Codex cuenta de grupo también realiza. Véase [`ocx status` / `ocx doctor`](/es/reference/cli/) en la referencia CLI.
+
+<a id="kiro-request-credits"></a>
+
+### Créditos de solicitud Kiro
+
+En los giros habilitados para herramientas, opencodex mantiene el texto ordinario de Kiro hasta que se valide la finalización. Si Kiro termina con texto sin formato en lugar de su herramienta privada de respuesta final, todavía se ejecuta un reintento limitado y solo se muestra la respuesta final resultante. El progreso que acompaña a una llamada de herramienta real sigue siendo visible. Una respuesta final privada normal no necesita reintento de finalización.
+
+Si el filtro de seguridad de Kiro detiene un turno (`CONTENT_FILTERED`, por ejemplo el clasificador `BIO` de Claude), la solicitud termina con un rechazo que los clientes no reintentan. Los clientes Claude reciben `stop_reason: "refusal"` y Codex recibe una respuesta fallida con la categoría y explicación de Kiro. Si el filtro detiene el único reintento acotado, no se muestra una respuesta final: el progreso retenido del primer intento y el texto parcial del reintento aparecen como comentarios antes del rechazo.
+
+Cuando Kiro emite la medición de crédito, los registros de solicitudes conservan el gasto reportado como `usage.providerCredits`, incluso en el libro mayor de uso persistente. Estos son Kiro créditos; los recuentos de tokens aún pueden estimarse y el valor del crédito no reemplaza las estimaciones de costos de USD. Las solicitudes de reserva de finalización agregan sus créditos reportados. Un valor ausente significa que Kiro no reportó el uso del crédito; un cero explícito significa que no reportó ningún gasto.
+
+<a id="kiro-refresh-attention"></a>
+
+### Kiro actualizar la atención
+
+Si una actualización de AWS SSO devuelve `400 invalid_request` y la recuperación Kiro CLI no se realiza correctamente, el panel de control muestra que la cuenta afectada necesita volver a autenticarse una vez que expire su token de acceso. El proveedor activo informa entonces de `loggedIn: false` desde `/api/oauth/status`. Un token de acceso todavía válido permanece conectado. Puede iniciar sesión de nuevo a través del panel de control; una actualización automática exitosa posterior también borra el estado de atención. Este estado no clasifica la concesión de actualización como revocada ni desactiva futuros intentos de actualización. Los errores de red y servidor no activan este estado.
+
+Para las cuentas de escritorio, un HTTP 401 con exactamente `Bad credentials` requiere un nuevo inicio de sesión e inmediatamente marca la generación de credenciales rechazadas como que necesita una nueva autenticación. Otros mensajes, estados y respuestas de AWS SSO no activan esta regla específica del escritorio.
+
+<a id="kiro-credential-import"></a>
+
+### Importación de credenciales Kiro
+
+El dashboard ofrece inicio de sesión nativo con AWS IAM Identity Center, Builder ID, Google y GitHub sin Kiro CLI.
+
+Para una cuenta de organización, elige **AWS IAM Identity Center** e introduce la URL del portal de acceso de AWS (por ejemplo, `https://example.awsapps.com/start`) y la región donde tu organización lo configuró. Abre el enlace de verificación en tu propio navegador, introduce el código mostrado y autoriza la cuenta. El hub completa la autorización sin una sesión SSH ni una devolución del navegador hacia él. Si AWS enumera varios perfiles de Kiro, elige cuál guardar; si hay uno solo, se guarda automáticamente. La región SSO y la región de API del perfil se conservan por separado. El descubrimiento comprueba las regiones de servicio de AWS US East y Frankfurt. Antes de guardar, obtiene de AWS el correo del usuario para ese perfil; así, usuarios que comparten un perfil de organización mantienen credenciales distintas. Cancelar o agotar el plazo antes de escribir las credenciales no guarda ninguna cuenta. El inicio de sesión nativo añade una cuenta y conserva la selección existente. La opción Kiro CLI y la ruta de importación `ocx login kiro` usan el CLI: en Unix, instálelo con `curl -fsSL https://cli.kiro.dev/install | bash`; en Windows PowerShell, use `irm 'https://cli.kiro.dev/install.ps1' | iex`; luego inicie sesión con `kiro-cli login`. Sin una sesión `kiro-cli`, `ocx login kiro` vuelve a un token de acceso pegado o la variable de entorno `KIRO_ACCESS_TOKEN`.
+
+La ruta de importación `ocx login kiro` busca en la plataforma Kiro CLI almacena y abre SQLite bases de datos de solo lectura. Dos variables de entorno hacen explícita la selección de la fila de origen y token:
+
+- `KIROCLI_DB_PATH` selecciona una base de datos no estándar Kiro CLI SQLite. La ruta de acceso ya debe existir; durante esta ruta de acceso de importación, opencodex no crea ni modifica los archivos de base de datos, WAL o SHM.
+- `KIROCLI_TOKEN_KEY` selecciona la clave de token exacta `auth_kv` cuando una base de datos contiene múltiples filas de tokens ambiguas. Una selección faltante falla el inicio de sesión en lugar de adivinar.
+
+En Windows, la importación busca `%LOCALAPPDATA%\Kiro-Cli\data.sqlite3`. El inicio de sesión forzado/agregar cuenta también necesita el binario local CLI: opencodex primero usa `PATH`, luego vuelve a `%LOCALAPPDATA%\Kiro-Cli\kiro-cli.exe` y `C:\Program Files\Kiro-Cli\kiro-cli.exe`. Si ninguna de las carpetas tiene `kiro-cli.exe`, se utiliza un `kiro.exe` dentro de esas mismas dos carpetas `Kiro-Cli`. opencodex nunca ejecuta un `kiro` corto o `kiro.exe` que se encuentra en `PATH` o en directorios compartidos macOS / Linux bin, por lo que instalar o vincular el CLI como `kiro-cli` allí.
+
+Después de una importación exitosa, opencodex persiste la credencial importada a `~/.opencodex/auth.json`. Mantenga estas variables y la base de datos seleccionada privada. No adjunte archivos de base de datos o diagnósticos de inicio de sesión sin procesar a los informes de errores.
+
+Para la opción **Kiro CLI**, **Añadir cuenta** es un flujo de trabajo de escritura separado: captura la sesión actual, inicia sesión en `kiro-cli` e importa el inicio de sesión del navegador nuevo. Si el inicio de sesión se cancela o falla, incluso mientras OpenCodex persiste la credencial, el retroceso reemplaza la base de datos Kiro CLI y elimina sus sidecars WAL, SHM y diario actuales antes de publicar la instantánea de sesión anterior.
+
+Debido a que la reversión solo es posible a partir de una instantánea, la opción Kiro CLI **Añadir cuenta** se niega a firmar `kiro-cli` cuando un almacén de sesión está presente pero no se puede capturar (archivo ilegible, esquema no coincidente o una selección ambigua de token), cuando la importación de redireccionamiento `KIROCLI_DB_PATH` / `KIRO_CLI_DB_FILE` se lee desde el almacén CLI en vivo, o cuando una base de datos CLI primaria existente no tiene una fila de token reconocida. Repare o elimine la base de datos ilegible bajo la ruta de datos normal `kiro-cli`, desactive los selectores de importación y vuelva a intentarlo. No se afecta el inicio de sesión desde una máquina sin sesión `kiro-cli` existente. Las opciones del panel de control nativo son solo para agregar y no cerrar sesión en `kiro-cli`. Un diálogo de dispositivo muestra el código y el destino de la verificación. Solo los hosts reconocidos de Kiro o de SSO de dispositivo regional de AWS se abren como enlaces, así como el portal de acceso `<id>.awsapps.com/start` de tu organización en un inicio de sesión con AWS IAM Identity Center; un destino inesperado se muestra como texto copiable para su revisión. Cerrar el cuadro de diálogo envía la cancelación y deja una verificación de estado de fondo limitada para conciliar una confirmación que ya está en curso. Se vuelve a intentar una respuesta de estado estancada; agotar la fecha límite de flujo produce el resultado final neutral en lugar de reclamar el éxito. La aprobación Google y GitHub se completa cuando Kiro informa `authorized` (o el estado `approved` heredado) con tokens válidos y un ARN de perfil. La lista de cuentas marca Kiro cuentas excluidas de la selección automática con un motivo, cuando está disponible.
+
+<a id="deepseek-api"></a>
+
+### DeepSeek API
+
+El proveedor de clave API `deepseek` incluye `deepseek-flash`, su alias `deepseek-v4-flash`
+y `deepseek-v4-pro`. DeepSeek [retiró el plan de eliminación de Pro](https://api-docs.deepseek.com/updates/)
+y sigue ofreciéndolo. OpenCodex conserva Pro con contexto de 1.048.576 tokens, entrada solo de texto
+y esfuerzos `low`/`high`/`max`. Las solicitudes Responses usan su endpoint nativo; las de Chat
+Completions conservan ese protocolo. Flash sigue siendo el modelo predeterminado. La disponibilidad
+en proveedores de terceros es independiente.
+
+Al actualizar, el inicio añade Pro a una lista guardada solo si coincide exactamente con la lista
+integrada anterior de DeepSeek y mantiene el endpoint y adaptador oficiales. Las listas modificadas,
+incluidas las vacías, no cambian. Esta reparación no requiere detección de modelos en vivo.
+
+<a id="deepseek-account-dsh"></a>
+
+### DeepSeek Cuenta (DSH)
+
+`dsh-account` es un proveedor experimental de cuentas de importación diseñado para reutilizar las credenciales de cuenta autenticadas de una aplicación de escritorio DeepSeek Harness (DSH) instalada.
+
+- **Independiente de DeepSeek API Llave:** `dsh-account` se ejecuta en la cuenta DeepSeek iniciada con DeepSeek Harness, mientras que el proveedor `deepseek` factura contra su saldo de claves API de plataforma. Los dos dominios y rutas de credenciales están estrictamente separados y nunca se cruzan.
+- **Importación explícita solamente:** opencodex lee `~/.dsh/.credentials.yaml` (o `$DSH_HOME/.credentials.yaml`) solo cuando ejecuta `ocx login dsh-account` o selecciona **Iniciar sesión** en la fila DeepSeek Account (DSH) del selector **Añadir proveedor** del tablero de instrumentos. Nunca copia, importa o usa el token por sí mismo.
+- **Tienda de credenciales DSH de solo lectura:** OpenCodeX trata a `~/.dsh/.credentials.yaml` como estrictamente de solo lectura. OpenCodeX nunca escribe, modifica, elimina o altera los permisos de los archivos pertenecientes a DeepSeek Harness.
+- **Copia de credenciales aislada & cierre de sesión:** Al importar, OpenCodeX valida el token contra el punto final de identidad autorizado de DeepSeek (`/auth-api/v0/users/current`) y guarda su propia copia en el almacén de autenticación de OpenCodeX. Cerrar la sesión o eliminar la cuenta en OpenCodeX solo elimina la copia local de OpenCodeX; nunca activa el cierre de sesión remota ascendente y no cerrará la sesión en DeepSeek Harness Desktop.
+- **Sin rotación de token de fondo y reimportación 401:** Las concesiones de sesión DSH no cuentan con un punto final de actualización de fondo automático. Si el flujo ascendente devuelve HTTP 401 (`ACCOUNT_TOKEN_INVALID`), OpenCodeX marca la cuenta `needsReauth` y detiene el enrutamiento. Para restaurar el acceso, el usuario debe volver a importar explícitamente a través de `ocx login dsh-account`.
+- **Descargo de responsabilidad de terceros:** OpenCodeX no hace ninguna reclamación de respaldo oficial o autorización por DeepSeek para clientes de terceros que reutilizan subvenciones de sesión.
+
+<a id="3-api-key-catalog"></a>
+
+## 3. Catálogo de proveedores con clave API
+
+opencodex incluye 107 preajustes integrados: 86 con clave, 17 OAuth, tres locales y uno predeterminado de reenvío a ChatGPT. El selector **Añadir proveedor** abre el formulario del proveedor con clave, valida la credencial y la guarda; cada proveedor tiene su propia validación. Entre ellos:
+
+**ClinePass** utiliza una clave API de Cline con el [catálogo oficial de suscripción](https://docs.cline.bot/getting-started/clinepass) y el [punto final de Chat Completions](https://docs.cline.bot/api/chat-completions), operados por Cline Bot Inc. bajo [los términos de Cline](https://cline.bot/tos). Un id enrutado como `cline-pass/cline-pass/kimi-k3` es intencional: el primer segmento selecciona el proveedor de opencodex, mientras que `cline-pass/kimi-k3` es el identificador de modelo completo que se envía aguas arriba. La cuota de ClinePass se comparte por cuenta entre límites rotativos de 5 horas, semanales y mensuales. Una sonda en vivo del 2026-08-13 verificó que todos los modelos estáticos de ClinePass aceptan `low`, `medium`, `high`, `xhigh` y `max` en el límite de entrada de la pasarela. opencodex conserva los niveles solicitados; cualquier normalización específica del backend sigue siendo responsabilidad de ClinePass.
+
+**Cline** es la misma clave y punto final API en la facturación de uso de pago por uso en más de 100 modelos (ID de estilo OpenRouter como `anthropic/claude-sonnet-4-6`). Los modelos promocionales gratuitos de Cline solo están disponibles en el IDE de Cline/ CLI, no a través del API; `minimax/minimax-m2.5` es el modelo documentado de experimentación libre API.
+
+**OrcaRouter** ([patrocinador](https://github.com/lidge-jun/opencodex/blob/dev/SPONSORS.md)) es una puerta de enlace compatible con OpenAI en `https://api.orcarouter.ai/v1` con identificadores de modelo separados por el nombre del proveedor (`openai/gpt-5.5`, `anthropic/claude-opus-4.8`, `deepseek/deepseek-v4-flash`,...) y un enrutador adaptativo, `orcarouter/auto`, que califica cada solicitud y selecciona el modelo. Cree una clave en el [Consola OrcaRouter](https://www.orcarouter.ai/console); el preajuste fija la fila cerca de la parte superior del selector de proveedores Agregar y la marca como patrocinador, y nada más sobre el enrutamiento o los cambios predeterminados.
+
+**PackyCode** es un relé API para Claude Code, Codex, Gemini y más. Los objetivos preestablecidos apuntan a su punto final de Chat Completions compatible con OpenAI, `https://cf.api.fan/v1`, con el descubrimiento del modelo en vivo reducido a lo que su grupo de tokens permite (`gpt-5.5` y `gpt-5.1-codex` se siembran). Regístrese en [packyapi.com](https://www.packyapi.com) y cree un token de grupo Codex.
+
+**Opper** es la puerta de enlace AI alojada en la UE de Opper AI (Estocolmo): una clave (creada en [plataforma.opper.ai](https://platform.opper.ai)) y un punto final compatible con OpenAI frente a más de 700 modelos de más de 30 proveedores. Los identificadores de modelos desnudos como `claude-sonnet-4-6` o `gpt-5.5` son *grupos*: Opper selecciona el proveedor y la región por solicitud, por lo que los identificadores sembrados permanecen válidos a medida que las rutas van y vienen. Un id `vendor/model` (`anthropic/claude-sonnet-4-6`, `aws/claude-sonnet-4-6-eu`) fija una ruta en su lugar. El catálogo se descubre en vivo desde `/v3/compat/models` con su clave; la lista pública, incluidas las rutas de la UE por regiones, está en [opper.ai/modelos](https://opper.ai/models). Opper también es un proveedor [modelos.dev](https://models.dev) (`opper`), que utiliza los mismos identificadores de grupo desnuda.
+
+| Proveedor | URL base |
+| --- | --- |
+| **OpenAI (clave API)** | `https://api.openai.com/v1` |
+| **Anthropic (clave API)** | `https://api.anthropic.com` |
+| **OpenRouter** | `https://openrouter.ai/api/v1` |
+| **Cline** | `https://api.cline.bot/api/v1` |
+| **ClinePass** | `https://api.cline.bot/api/v1` |
+| **Ollama Cloud** | `https://ollama.com/v1` |
+| Google Gemini · Google Vertex AI | `https://generativelanguage.googleapis.com` · `https://aiplatform.googleapis.com` |
+| Azure OpenAI | `https://{resource}.openai.azure.com/openai` |
+| Umans AI · Neuralwatt | `https://api.code.umans.ai` · `https://api.neuralwatt.com/v1` |
+| Mistral | `https://api.mistral.ai/v1` |
+| MiniMax · MiniMax (CN) | `https://api.minimax.io/v1` · `https://api.minimaxi.com/v1` |
+| DeepSeek | `https://api.deepseek.com` |
+| Cerebras | `https://api.cerebras.ai/v1` |
+| Chutes | `https://llm.chutes.ai/v1` |
+| DeepInfra | `https://api.deepinfra.com/v1/openai` |
+| Hyperbolic | `https://api.hyperbolic.xyz/v1` |
+| Nscale Serverless Inference | `https://inference.api.nscale.com/v1` |
+| Vultr Serverless Inference | `https://api.vultrinference.com/v1` |
+| Baseten Model APIs | `https://inference.baseten.co/v1` |
+| Command Code | `https://api.commandcode.ai/provider/v1` |
+| OrcaRouter | `https://api.orcarouter.ai/v1` |
+| PackyCode | `https://cf.api.fan/v1` |
+| Meta Model API | `https://api.meta.ai/v1` |
+| Meta Muse Code (credencial CLI) | `https://api.meta.ai/v1` |
+| SambaNova Cloud | `https://api.sambanova.ai/v1` |
+| Nebius Token Factory | `https://api.tokenfactory.nebius.com/v1` |
+| Crusoe | `https://api.inference.crusoecloud.com/v1` |
+| DigitalOcean Serverless Inference | `https://inference.do-ai.run/v1` |
+| Scaleway Generative APIs | `https://api.scaleway.ai/v1` |
+| Featherless AI | `https://api.featherless.ai/v1` |
+| Novita AI | `https://api.novita.ai/openai/v1` |
+| Together | `https://api.together.xyz/v1` |
+| Fireworks | `https://api.fireworks.ai/inference/v1` |
+| Moonshot (Kimi API) · Kimi (coding) | `https://api.moonshot.ai/v1` · `https://api.kimi.com/coding/v1` |
+| Hugging Face | `https://router.huggingface.co/v1` |
+| NVIDIA NIM | `https://integrate.api.nvidia.com/v1` |
+| Z.AI (GLM Coding) | `https://api.z.ai` — Responses en `/api/v1/responses` de forma predeterminada; Chat Completions en `/api/coding/paas/v4/chat/completions` por modelo mediante `modelAdapters` |
+| Zhipu AI (BigModel) | `https://open.bigmodel.cn/api/paas/v4` |
+| BigModel Coding Plan (Responses, lista estática) | `https://open.bigmodel.cn/api/v1` |
+| Qwen Cloud | Plan de tokens (predeterminado): `https://token-plan.maas.qwencloudapi.com/compatible-mode/v1` · Pago por uso: `https://dashscope.aliyuncs.com/compatible-mode/v1` · o personalizado |
+| Tencent Cloud Coding Plan | `https://api.lkeap.cloud.tencent.com/coding/v3` |
+| SiliconFlow | `https://api.siliconflow.cn/v1` |
+| Volcengine Ark · Coding Plan · Agent Plan | `https://ark.cn-beijing.volces.com/api/v3` · `https://ark.cn-beijing.volces.com/api/coding/v3` · `https://ark.cn-beijing.volces.com/api/plan/v3` |
+| Xiaomi MiMo | `https://api.xiaomimimo.com/anthropic` |
+| Xiaomi MiMo (OpenAI Chat) | `https://api.xiaomimimo.com/v1` |
+| Kilo | `https://api.kilo.ai/api/gateway` |
+| Opper | `https://api.opper.ai/v3/compat` |
+| TokenLab | `https://api.tokenlab.sh/v1` |
+| Modelflare | `https://modelflare.dev/v1` |
+| AI Stupid Level | `https://aistupidlevel.info/v1` |
+| cheapaimodel | `https://api.cheapaimodel.ai/v1` |
+| OpenGateway | `https://apis.opengateway.ai/v1` |
+| GitLab Duo | `https://cloud.gitlab.com/ai/v1/proxy/openai/v1` |
+| Cloudflare AI Gateway | `https://gateway.ai.cloudflare.com/v1/{account-id}/{gateway}/anthropic` |
+| …y otros | opencode zen, Vercel AI Gateway, Venice, NanoGPT, Synthetic, Qianfan, Alibaba, Parallel, ZenMux, LiteLLM |
+
+**Alibaba Token Plan** ofrece los presets Personal Edition de Beijing y Team Edition internacional. Ambas regiones ofrecen los dos niveles de suscripción. Las listas de modelos de chat son estáticas porque el descubrimiento del proveedor también incluye modelos que no son de chat. Se conservan las selecciones existentes y los endpoints internacionales configurados explícitamente.
+
+Ambos presets incluyen `deepseek-v4.1-flash-1017`, con entrada de texto e imágenes, salida de texto, contexto de 1.000.000 de tokens y razonamiento `low`, `high` y `max` (`high` por defecto). Su límite de salida de 393.216 sigue la normalización del presupuesto publicado; no es un límite medido. El Lab informa 384.000. Los esquemas estrictos son rechazados y `json_object` no está verificado para este identificador exacto, por lo que las solicitudes Chat omiten `response_format`: la salida es texto de mejor esfuerzo, sin garantía de JSON. La degradación JSON verificada del modelo sin sufijo y las asignaciones existentes a Responses no cambian. Beijing también incluye `deepseek-v4-pro-0813`, ahora publicado. La región internacional omite los retirados `deepseek-v3.2` y `deepseek-v4-flash` sin sufijo, pero conserva `deepseek-v4-flash-0731`. Los presets mantienen los hosts de sus guías oficiales: Beijing usa `https://token-plan.cn-beijing.maas.aliyuncs.com/compatible-mode/v1` y la región internacional `https://token-plan.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1`. El preset Qwen Cloud usa el host Token Plan independiente documentado arriba. Consulta la [ficha del modelo 1017](https://www.qianwenai.com/models/deepseek-v4.1-flash-1017), la [referencia Chat](https://docs.qwencloud.com/api-reference/chat/openai-chat) y la [guía Personal](https://help.aliyun.com/en/model-studio/token-plan-personal-overview).
+
+**OpenGateway** es una pasarela compatible con OpenAI operada por Sionic AI en
+`https://apis.opengateway.ai/v1`. Su catálogo público contiene unos 80 modelos activos (verificado el 2026-10-02); el preajuste actualiza automáticamente la lista de modelos en vivo desde el `GET /v1/models` público y conserva los modelos Chat Completions activos (además de `openai/o3-pro`, exclusivo de Responses y anclado a Responses). Los modelos `deepseek/deepseek-v4.1-flash-ultrafast` y `z-ai/glm-5.3-flash-ultrafast` servidos por Sionic aparecen primero. Cree una clave en el [panel de OpenGateway](https://opengateway.ai/api-keys) y luego ejecute
+`ocx provider add opengateway` o seleccione **OpenGateway** en el panel. Las solicitudes de chat usan la clave Bearer configurada; la lista pública de modelos no valida esa clave.
+
+En el protocolo Responses, OpenGateway rechaza las llamadas nativas a herramientas personalizadas que se reproducen, por lo que el preajuste convierte las herramientas personalizadas de Codex, como `exec` del modo de código, en herramientas de función antes de enviarlas.
+Los arrays de contenido de resultados de herramientas se envían como texto, con las imágenes conservadas después del grupo emparejado de resultados. Las partes de resultado no admitidas, incluidos los rechazos y el contenido opaco, se rechazan explícitamente con un error de entrada del cliente antes del envío. El detalle de imagen `original` se asigna a `high`, que la pasarela acepta; los bytes de la imagen no cambian. La ruta nativa de Responses también comprueba las finalizaciones vacías de solo texto antes de exponerlas como éxito. Agotar el presupuesto de salida produce `incomplete` con `max_output_tokens`; el proxy no aumenta el presupuesto solicitado. Una finalización vacía que admita repetición segura y conserve presupuesto puede reintentarse una vez, dentro del límite de envío existente. `emptyCompletionRetry: false` u `OCX_EMPTY_COMPLETION_RETRY=0` desactivan ese reintento. El texto, los rechazos, la actividad de herramientas y los eventos de streaming desconocidos impiden la repetición y conservan el flujo original, igual que una instantánea de respuesta que ya lleva `output_text` agregado (un `output_text` ausente, `null` o vacío todavía permite el reintento). La protección no cambia los demás proveedores ni sus valores predeterminados de reintento. La repetición exige `store: false` explícito, entrada completa y solo herramientas ejecutadas por el cliente; una herramienta alojada como `web_search` impide la repetición automática aunque no se haya observado ningún evento de herramienta.
+
+**TokenLab** ([patrocinador](https://github.com/lidge-jun/opencodex/blob/dev/SPONSORS.md)) es una puerta de enlace de API compatible con OpenAI en [tokenlab.sh](https://tokenlab.sh/r/OPENCODEX), operado por TOKENLAB AI INC. Cree una [clave API](https://tokenlab.sh/dashboard/api?tab=keys) de espacio de trabajo, luego ejecute `ocx provider add tokenlab` o seleccione **TokenLab** en el selector **Añadir proveedor** del panel de control. TokenLab mantiene un paso a paso [Guía de integración OpenCodex](https://tokenlab.sh/docs/en/integrations/opencodex) ([한국어](https://tokenlab.sh/docs/ko/integrations/opencodex)) que cubre la configuración y el enrutamiento por modelo. El preajuste utiliza [Chat Completions](https://tokenlab.sh/docs/en/quickstart) y descubre modelos en `GET /v1/models?category=chat`, manteniendo solo las entradas que declaran la capacidad de `tool-use`. Los modelos de imagen, video, audio, incrustación y decisión están excluidos de este preajuste de chat.
+
+Cada modelo utiliza el formato de solicitud TokenLab declara para ello ( `tokenlab.accepted_request_formats` en `GET /v1/models/{model}` ):
+
+| Modelos | Codex (Responses clientes) | Clientes de chat | Claude Code (Anthropic clientes) |
+| --- | --- | --- | --- |
+| `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6.1-terra`, `gpt-6-sol`, `gpt-6-luna`, `grok-4.7`, `deepseek-v4.1-flash`, `deepseek-v4-pro`, `kimi-k3`, `glm-5.3` | [Responses](https://tokenlab.sh/docs/en/api-reference/responses/create-response) | Chat Completions | Chat Completions |
+| `claude-*` | [Messages](https://tokenlab.sh/docs/en/api-reference/messages/create-message) | Messages | Messages |
+| Cualquier otro modelo, incluyendo `gemini-3.8-flash` | Chat Completions | Chat Completions | Chat Completions |
+
+Para mantener un modelo en Chat Completions, añádalo al `modelAdapters` del proveedor, por ejemplo `"modelAdapters": { "gpt-6.1-sol": "openai-chat" }`. El enrutamiento Claude se aplica solo mientras el proveedor apunta a `https://api.tokenlab.sh/v1`. OpenCodex no envía ningún encabezado de política de entrega, por lo que la política de entrega de su clave API decide cómo TokenLab sirve cada solicitud.
+
+El [catálogo de modelos](https://tokenlab.sh/docs/en/api-reference/models/list-models) es público sin una clave, pero se valida una clave suministrada y los resultados de alcances a sus permisos de modelo y política de entrega. Utilice una clave válida con un espacio de trabajo financiado para la inferencia. `gpt-5.6-terra` es el valor predeterminado; elija otro modelo descubierto si su clave no lo permite. Los prefijos de proveedor y modelo permanecen separados: `tokenlab/gpt-5.6-terra` envía `gpt-5.6-terra` aguas arriba. Las referencias [términos](https://tokenlab.sh/tos) y [Política de privacidad](https://tokenlab.sh/privacy-policy) de TokenLab se aplican a las solicitudes enviadas a este servicio. El preset fija la fila cerca de la parte superior del selector Añadir proveedor y la marca como patrocinador, y nada más sobre el enrutamiento o los cambios predeterminados.
+
+**Modelflare** es un relé compatible con OpenAI en `https://modelflare.dev/v1`. Selecciónalo en `ocx init` o **Añadir proveedor**, o ejecuta `ocx provider add modelflare`. Puedes usar la referencia `${MODELFLARE_API_KEY}` para mantener la clave en el entorno. El preajuste usa Chat Completions. Estos modelos existentes se verificaron con chat, streaming y llamadas a herramientas: `glm-5.3-flash` (predeterminado), `claude-sonnet-5-5`, `gpt-6.1-sol` y `deepseek-v4-flash`. `gpt-6.1-terra` es una entrada anticipada basada en Sol; aquí no se ha verificado su inferencia. Puedes añadir otros modelos compatibles con Chat como modelos personalizados. Los modelos de imagen y video usan endpoints distintos y no funcionan con este preajuste. Una clave ordinaria está vinculada a un grupo de enrutamiento y solo puede usar sus modelos: usa una clave inteligente para todo el conjunto inicial o indica con `--default-model` uno que tu grupo ofrezca. `deepseek-v4.1-flash` aparece en el catálogo del proveedor, pero actualmente responde 503 y se excluye del preajuste. La latencia varía desde unos segundos hasta unos 30 segundos, con 503 transitorios ocasionales.
+
+**AI Stupid Level** es un Smart Router en `https://aistupidlevel.info/v1`, operado por S.C. Studio Platforms S.R.L. Crea una clave de router en [aistupidlevel.info/router/keys](https://aistupidlevel.info/router/keys) y añade tus propias claves de OpenAI, Anthropic, Google, DeepSeek, Kimi o GLM a la misma cuenta. Selecciona **AI Stupid Level** en `ocx init` o **Añadir proveedor**, o ejecuta `ocx provider add aistupidlevel`. Entrega la clave del router directamente o como referencia `${AISTUPIDLEVEL_API_KEY}`. El router usa tus claves para llamar a cada proveedor, que te factura directamente; según sus [condiciones](https://aistupidlevel.info/terms#router), AI Stupid Level no añade margen. El preajuste usa Chat Completions para todos los clientes, incluido Claude Code, y descubre modelos mediante `GET /v1/models` autenticado.
+
+Las entradas iniciales son sus [modos de enrutamiento](https://aistupidlevel.info/router/docs#strategies): `auto-coding` (predeterminado) elige el modelo con mejor puntuación medida en su benchmark de programación; `auto-tooling` y `auto-reasoning` hacen lo mismo para herramientas y razonamiento. `auto-value-coding` y `auto-fastest-quality` eligen la mejor relación de costo o la mayor velocidad entre modelos a un máximo de cinco puntos del mejor. Un identificador real del catálogo, como `aistupidlevel/claude-opus-5-5`, fija un modelo; la cabecera `X-AISM-Model` identifica el que respondió. Los modos publican 262.144 tokens de contexto y 64.000 de salida, aplicables a cualquier modelo que el router elija. El router solo acepta texto: para sus modos o modelos fijados en el destino del preajuste, el proxy pasa las imágenes al sidecar de visión. Su endpoint Anthropic Messages reenvía a Anthropic sin enrutamiento; el preajuste no lo utiliza.
+
+El editor admite también `inputModalities` como valor alternativo: un arreglo no vacío con `text`, `image`, `audio` o `video`. Las declaraciones exactas por modelo tienen prioridad. Los valores inválidos se rechazan al guardar; un valor mal formado en una configuración editada a mano se carga como `["text"]` con una advertencia. El valor de solo texto del preajuste se aplica en ejecución incluso si se guarda con otro nombre, siempre que conserve la misma URL y el adaptador Chat. No se traslada a una URL personalizada ni a otro adaptador.
+
+Las tarjetas de proveedor MiniMax y MiniMax (CN) también pueden mostrar la cuota del Plan de codificación cuando la clave configurada tiene un plan activo. El panel de control lee la ventana de 5 horas del plan y, cuando está presente, la ventana semanal; estas son observaciones de visualización y no cambian el enrutamiento del modelo.
+
+Ollama Las tarjetas de proveedores de la nube leen la cuota de `/api/balance` primero, con `/api/usage` como alternativa para implementaciones anteriores. Un informe de reserva analizado reemplaza a un fallo anterior; de lo contrario, las respuestas 4xx duras (excepto 404/408/429) borran la última cuota válida incluso si falla otro intento, mientras que los fallos transitorios la mantienen. Un cuerpo ilegible o sobredimensionado detiene los intentos adicionales. Los créditos en dólares muestran solo la asignación incluida, excluyendo los créditos comprados, por lo que una asignación agotada deja de enviarse a Ollama Cloud solo cuando no queda ningún crédito comprado.
+
+`MiniMax-M3.1-Flash`, con contexto de 1M y hasta 524.288 tokens de salida, es el modelo predeterminado de ambos presets MiniMax. Se publicó el 2026-10-19 y reemplazó el identificador retirado `MiniMax-M3.1-Flash-Preview`: las configuraciones guardadas que aún lo usan se renombran a `MiniMax-M3.1-Flash` en el siguiente inicio. El razonamiento siempre está activo; el selector ofrece de `low` a `max`, con `max` por defecto, y no permite desactivarlo. El endpoint `/models` de MiniMax no enumera Flash, por lo que OpenCodex lo mantiene desde el preset. Una lista guardada que coincida con la anterior lista predeterminada recibe el modelo al iniciar; una lista modificada se conserva. Puedes registrarlo manualmente con `ocx models add minimax MiniMax-M3.1-Flash --context-window 1000000`. La actualización de las entradas iniciales solo se aplica a los endpoints oficiales de MiniMax; una URL personalizada conserva su lista de modelos.
+
+**OpenCode Go** enruta `gemini-4-argon-contributor` a través de su Gemini API, incluidos el streaming y las continuaciones de resultados de herramientas. El preajuste `opencode-go` existente mantiene su URL histórica fija: las URL personalizadas guardadas, incluida `https://opencode.ai/inference/go/v1`, se enrutan a través del endpoint canónico `https://opencode.ai/zen/go/v1` y heredan los valores predeterminados de Go. Gemini usa entonces el endpoint de modelo nativo de Go con autenticación por clave. Un proveedor personalizado con otro nombre conserva su URL configurada y no recibe este anclaje de Gemini. Go selecciona protocolos por ID de modelo exacto: GPT 6 Luna, GPT 5.6 Luna, Grok 4.6/4.7 y Muse Spark Contributor usan Responses; Claude Haiku 5.5, MiniMax M2.7/M3 y Qwen3.7 Plus/3.8 Max/3.8 Flash usan Anthropic Messages. Los heredados MiniMax M2.5 y Union Alpha también conservan Messages. Los modelos sin un protocolo listado conservan Chat. Los nuevos anclajes nativos se aplican al destino Go anclado con autenticación por clave. Los modelos Responses siguen aceptando una anulación explícita de `modelAdapters`. Al leer una configuración guardada anterior, OpenCodex ignora las anulaciones obsoletas de Chat/Responses para los modelos Gemini y Qwen recién anclados, junto con sus preferencias de herramientas alojadas exclusivas de Responses que antes eran válidas. Los demás proveedores, cuentas y el enrutamiento siguen disponibles. Las lecturas dejan el archivo sin cambios; una edición explícita posterior de la configuración guarda los valores actualizados. Las nuevas anulaciones para estos modelos nativos se siguen rechazando. Gemini usa niveles de pensamiento `low`, `medium` y `high`; los esfuerzos más altos se limitan a `high`.
+
+OpenCode Go requiere un identificador de sesión estable para el enrutamiento. OpenCodex envía `claude-haiku-5-5`, al igual que los modelos MiniMax, mediante el protocolo Anthropic Messages, que coincide con [Tabla de puntos finales de OpenCode Go](https://opencode.ai/docs/go/#endpoints). OpenCodex deriva su encabezado de sesión Go de encabezados de hilo/sesión Codex, o de un encabezado `x-opencode-session` de un cliente cuando los encabezados Codex están ausentes. Esto se aplica a las solicitudes Chat Completions directas y las solicitudes puenteadas a Responses. Incluso un valor entrante con prefijo `ocx_` se trata como entrada del cliente y se procesa con hash en la afinidad de Go; el puente interno lleva el valor original, por lo que Chat nativo, Chat puenteado y Responses obtienen el mismo resultado. Los encabezados de sesión configurados explícitamente en la configuración del proveedor son anulaciones del operador y se envían sin cambios. Los clientes deben mantener el identificador estable dentro de una conversación y distinto en todas las conversaciones. Una solicitud sin ningún identificador de sesión no recibe una identidad de solicitud cruzada inferida; en cambio, se envía bajo una sesión asignada solo para esa solicitud, aislada de cualquier otra solicitud (consulte la referencia del proveedor sobre cómo se transmite ese valor). Para Claude Messages, los encabezados de sesión configurados de OpenCode Go siguen prevaleciendo. De lo contrario, los encabezados de sesión o hilo explícitos válidos tienen prioridad, y la identidad de conversación válida en `metadata.user_id` proporciona la reserva. Esta reserva se aplica al destino final de Go, incluidas las selecciones aleatorias combinadas y los intentos de reserva, en lugar de la ruta preliminar. Las claves compartidas de la caché del prompt del sistema no identifican las conversaciones y la identidad específica de Go no se envía a los objetivos que no son Go. Las configuraciones del proveedor Pi generado habilitan `compat.sendSessionAffinityHeaders` para que Pi envíe su identidad por sesión al proxy. Las configuraciones de Pi administradas manualmente existentes también pueden establecer esta opción en su proveedor `opencodex`. Pi puede omitir la afinidad de sesión cuando `cacheRetention` es `none`; habilitar la retención de caché cuando se requiere una sesión ascendente estable.
+
+**Ecos de llamadas a herramientas de MiMo.** En OpenCode Go y otras rutas de Chat Completions, se oculta un bloque `<tool_call>` cuando duplica una llamada estructurada a la misma herramienta con la misma entrada efectiva. Esto incluye envoltorios de MiMo como `<tool_call_deadbeef>` con identificadores de cierre coincidentes, incluso cuando el eco sigue a un texto normal. Los ejemplos de código siguen visibles. Si la entrada es distinta o varias llamadas pueden explicar el bloque, el marcado se conserva. Para `mimo-v2` y los identificadores MiMo V2 con puntos, como `mimo-v2.6-pro`, si la pasarela envía exactamente una llamada vacía `{}` a una herramienta freeform declarada y coloca su entrada en un bloque independiente, sin identificador o con él, opencodex recupera la entrada en la llamada y oculta el bloque. Los identificadores con guiones, como `mimo-v2-pro` y `mimo-v2-omni`, no participan en esta recuperación. El texto normal, los ejemplos entre comillas, las funciones ordinarias y las respuestas ambiguas no cambian. También se admite el inicio incorrecto `<parameter=` de MiMo al principio de ese bloque independiente.
+
+**OpenCode Zen** (`opencode-zen`) utiliza `https://opencode.ai/zen/v1` con una clave API de [opencode.ai/auth](https://opencode.ai/auth). El tráfico de modelo libre puede alcanzar límites de velocidad de ventana corta alrededor de 15-20 solicitudes / minuto (medido por la comunidad; OpenCode no publica RPM). Cuando un límite de velocidad 429 omite `Retry-After`, opencodex agrega guía y un sintético `Retry-After`; las cabeceras válidas ascendentes tienen prioridad. Los reintentos de la misma clave siguen siendo opt-in a través de [`retryOn429`](/es/reference/configuration/).
+
+Los modelos Gemini en `opencode-zen` usan automáticamente la API nativa de Google cuando el proveedor usa una clave API, el `googleMode` predeterminado (`ai-studio`) y `https://opencode.ai/zen/v1` o `https://opencode.ai/inference/v1`. Use los ID de modelo que enumera Zen; OpenCodex los conserva, incluidos los ID de Flash sin el sufijo `-tiered`. Los modelos Claude en estas rutas con clave API usan Anthropic Messages automáticamente, independientemente de `googleMode`. Al cargar configuraciones guardadas, OpenCodex ignora las anulaciones anteriores elegibles de Chat/Responses de Gemini y Claude solo para los modelos nativos del `opencode-zen` canónico con clave en estas rutas oficiales de Zen. También ignora las preferencias de herramientas alojadas `image_generation` elegibles de solo Responses; los proveedores personalizados, las rutas sin clave y las demás preferencias permanecen sin cambios.
+
+**`opencode-free` se ha eliminado** porque todos sus modelos devuelven ahora `403 permission_denied` debido a la restricción del nivel gratuito de OpenCode ([#7255](https://github.com/lidge-jun/opencodex/issues/7255)). Cargar una configuración existente desactiva sus entradas y las referencias de modelo dependientes en memoria, avisa una vez por proceso y deja el archivo sin cambios durante la carga. El siguiente guardado de la configuración las elimina de config.json. Antes de ese guardado, el archivo original se conserva automáticamente como `config.json.pre-opencode-free-removal.bak` junto a config.json, o con otro nombre único en el mismo directorio si ese nombre ya está ocupado. Solo se reutiliza una copia independiente con bytes idénticos si se puede verificar que sus permisos permiten el acceso únicamente al propietario; de lo contrario se escribe otra copia protegida a su lado. Nunca se sobrescriben archivos existentes. Las primeras cargas simultáneas pueden dejar varias copias protegidas idénticas. El aviso indica la copia de recuperación. Para restaurarla, cópiala sobre config.json, por ejemplo después de volver a una versión anterior. Si falla la copia, el aviso pide copiar config.json inmediatamente. Si era el proveedor predeterminado, la ruta estándar de OpenAI OAuth pasa a ser la predeterminada. Usa `opencode-go`, `opencode-zen` con clave u otro proveedor. [Términos de OpenCode Zen](https://opencode.ai/docs/zen/). Las lecturas pasivas conservan la proyección en memoria sin crear una copia ni emitir el aviso.
+
+Se conservan las asignaciones y los valores predeterminados saludables de Claude Desktop. Las reglas cuya lista de permisos de modelo de origen se vacía están deshabilitadas, junto con la sincronización de subagentes nativa cuando se elimina su modelo de inyección. La configuración posterior guarda las referencias eliminadas fuera del archivo mientras conserva las ediciones concurrentes saludables.
+
+La mayoría usa el adaptador `openai-chat` con una clave bearer; los preajustes compatibles con Anthropic, como Xiaomi, usan el adaptador `anthropic` (`x-api-key`).
+
+**Xiaomi MiMo** (`xiaomi`) usa el adaptador `anthropic` (`x-api-key`). Xiaomi también tiene un preajuste OpenAI Chat, `xiaomi-mimo`, y un preajuste de plan de tokens, `mimo`. Los tres usan MiMo V2.6 de forma predeterminada (`mimo-v2.6-pro`, o `mimo-v2.6-flash` en `xiaomi-mimo`). Xiaomi retira `mimo-v2.5` y `mimo-v2.5-pro` el 2026-10-21 sin redirección, así que cambie un valor predeterminado V2.5 guardado antes de esa fecha; opencodex no lo reescribe por usted.
+
+El Plan de codificación y el Plan de agente de Volcengine usan sus endpoints nativos de Responses mediante `openai-responses`. Durante las continuaciones de herramientas validadas del Plan de codificación de Ark, reproducir el elemento `reasoning` que devuelve Responses respondía `400 InvalidParameter`, por lo que el preajuste del Plan de codificación descarta los elementos de razonamiento reproducidos antes de reenviar la entrada de continuación; eso pierde información, y `dropResponsesReasoningItems: false` lo desactiva. Una instalación que ya guardó el proveedor del Plan de codificación en `openai-chat` conserva ese protocolo —nada reescribe una fila almacenada—, así que el cambio es una edición deliberada: establezca `adapter` en `openai-responses` y `responsesPath` en `/responses`, o elimine y vuelva a agregar el preajuste. Las anulaciones explícitas por modelo de `openai-chat` siguen disponibles en cualquier caso.
+
+El preajuste integrado de DeepSeek también enruta `deepseek-v4-flash` por su endpoint nativo de Responses y mantiene habilitado el streaming SSE ascendente. Si ese modelo termina todos los elementos de salida pero omite el evento Responses final, opencodex aplica una reparación de gracia de cinco segundos limitada a ese modelo; los flujos mal formados o parciales se cierran como incompletos en lugar de informarse como exitosos. El modelo propio `deepseek-flash` anuncia entrada nativa `text` e `image`, por lo que las solicitudes de imagen se envían directamente a DeepSeek de forma predeterminada en lugar de pasar por el sidecar de visión. Las declaraciones explícitas de `noVisionModels` o de solo texto siguen siendo autoritativas. Los modelos propios `deepseek-chat`, `deepseek-reasoner` y `deepseek-v4-flash` siguen respaldados por el sidecar de forma predeterminada. Las rutas de Zen no cambian y no se sondearon en esta actualización.
+
+**Capacidades de razonamiento.** Los metadatos distinguen `supportsReasoning`, `supportsThinkingToggle` y `supportsReasoningEffort`. Un valor omitido es desconocido; `false` es una declaración explícita. `defaultThinkingEnabled` registra el estado predeterminado del interruptor y `reasoningEfforts` enumera los niveles de intensidad reales. Las declaraciones por modelo se guardan en `modelCapabilities`; los ejes se combinan con el registro sin distinguir mayúsculas en el identificador, y prevalece lo configurado por el operador. `/v1/models` publica `supports_reasoning`, `supports_thinking_toggle`, `supports_reasoning_effort` y `default_thinking_enabled` dentro de `capabilities`, sin inventar niveles para modelos de intensidad fija.
+
+Las configuraciones antiguas con una lista de esfuerzos explícitamente vacía y sin declaraciones de capacidades siguen publicando `capabilities.supports_reasoning: false` en `/v1/models`. Un `supportsReasoning: true` o `supportsThinkingToggle: true` explícito todavía anuncia pensamiento aunque la lista esté vacía.
+
+Los tres modelos públicos MiMo V2.6 admiten razonamiento y un interruptor para activarlo o desactivarlo, pero no una intensidad ajustable; el pensamiento está activado por defecto. El adaptador envía `thinking.type: enabled/disabled`. La entrada Responses de OCX acepta `reasoning.enabled` independientemente de `reasoning.effort`. Para clientes que solo ofrecen niveles, los catálogos Codex y las exportaciones OpenCode/Kilo representan el interruptor como `none/high`: son alias de compatibilidad, no intensidades de MiMo. El cliente puede seguir mostrando “High”. No se inventa un control para modelos de razonamiento fijo sin interruptor. La [guía de pensamiento profundo de Xiaomi](https://mimo.mi.com/docs/en-US/quick-start/usage-guide/other/deep-thinking) describe el interruptor público; las rutas gratuitas, de plan de tokens, de terceros y los modelos MiMo anteriores conservan sus declaraciones.
+
+> **Tres rutas de facturación Volcengine:** `volcengine` es el pago por uso de Ark API, `volcengine-coding-plan` consume la cuota del Plan de codificación, y `volcengine-agent-plan` consume la cuota del Plan de agente. Utilice la clave y el punto final emitidos para el mismo producto; el punto final ordinario `/api/v3` puede incurrir en cargos de pago por uso incluso cuando existe una suscripción a Plan. Los preajustes usan catálogos de modelos estáticos seleccionados porque la respuesta `/models` de Ark también incluye recursos de incrustación, imagen, video y 3D, la puerta de enlace de codificación devuelve el mismo catálogo amplio y la puerta de enlace de plan de agente no tiene ningún recurso `/models`. Pay-as-you-go predeterminado a `doubao-seed-2-1-pro-260628`; su catálogo curado también incluye modelos de texto DeepSeek y GLM actuales. El plan de codificación se establece por defecto en `ark-code-latest`, mientras que el plan de agente se establece por defecto en `deepseek-v4-flash`.
+
+En la ruta Ark de pago por uso, Kimi K3.1 Pro (`kimi-k3-1-pro`, incluidas las versiones con fecha) reproduce los turnos del asistente que solo contienen herramientas con una cadena vacía. Su endpoint rechaza el antiguo array de texto vacío con HTTP 400; los demás modelos de Ark conservan su formato de continuación.
+
+> **Restricción de uso del plan Volcengine:** Volcengine documenta la cuota de Plan de codificación y Plan de agente como válida solo dentro de las herramientas de codificación de IA compatibles, y advierte que el uso de una clave de plan para las llamadas generales API puede suspender la suscripción o prohibir la cuenta. La ruta Codex o Claude Code a opencodex es el uso documentado; señalar otra automatización en una clave de plan no lo es. La ruta `volcengine` de pago por uso no conlleva tal restricción.
+
+**Detección de Chutes.** El preajuste `chutes` usa la pasarela LLM compartida fija de Chutes, compatible con OpenAI. Lee el catálogo público `/v1/models`, conserva solo las filas cuyos `supported_features` anuncian
+`tools`, mantiene los identificadores de modelo con barras y los metadatos en vivo seguros, y limita el descubrimiento a 256 KiB y 128 filas sin procesar. Como ese catálogo es público, no puede demostrar que una clave dada sea válida; las solicitudes de chat siguen usando la clave Bearer configurada. Los hosts Chute personalizados desplegados por el usuario y las API de Chutes que no son LLM siguen siendo territorio de proveedor personalizado. Cree una clave en el [panel de Chutes](https://chutes.ai/auth/start).
+
+**Detección de DeepInfra.** El proveedor `deepinfra` de OpenAI Chat Completions basado en claves usa el adaptador `openai-chat` con una clave Bearer. Su URL de lista de modelos propiedad del registro conserva solo las filas etiquetadas con `chat`, mantiene los identificadores de modelo nativos con barras y limita el descubrimiento en vivo a 512 KiB y 512 filas sin procesar. Cree claves en el [panel de DeepInfra](https://deepinfra.com/dash/api_keys).
+
+**Detección de Hyperbolic.** El preajuste lee `/v1/models` con la clave bearer configurada, mantiene los identificadores de modelo nativos con barras y limita el descubrimiento en vivo a 256 KiB y 256 filas sin procesar. Solo cubre chat de texto y de visión-lenguaje sin servidor; los endpoints separados de imagen, audio y GPU de Hyperbolic quedan fuera de alcance. Cree claves en [Hyperbolic](https://app.hyperbolic.ai).
+
+**Detección de Nscale y Vultr.** Ambos preajustes leen el catálogo autenticado `/v1/models` del proveedor, mantienen los identificadores nativos y limitan el descubrimiento a 256 KiB y 256 filas sin procesar. El catálogo de Nscale mezcla modelos de chat, imagen e incrustación sin un campo de modalidad, por lo que el preajuste solo admite `meta-llama/Llama-3.1-8B-Instruct`, el modelo que usa el ejemplo oficial de llamada a herramientas de la API de Nscale. Vultr documenta actualmente llamadas a herramientas solo para `kimi-k2-instruct`, así que su preajuste expone únicamente ese modelo. Las demás filas permanecen ocultas hasta que el proveedor publique evidencia equivalente de herramientas de agente. Cree un token de servicio de Nscale en la [consola de Nscale](https://console.nscale.com); copie la clave de inferencia de Vultr desde el resumen de la suscripción en la [consola de Vultr](https://my.vultr.com).
+
+**Detección de Command Code.** El preajuste lee la lista `/provider/v1/models` de Command Code desde el host fijo de la Provider API, conserva los identificadores nativos del proveedor y limita el descubrimiento a 256 KiB y 256 filas sin procesar. `ocx login command-code` admite OAuth mediante el inicio de sesión en el navegador (con importación opcional de la credencial local del CLI desde `~/.commandcode/auth.json` para los usuarios existentes del CLI de Command Code); el catálogo de modelos está acotado a la cuenta y procede del endpoint de descubrimiento autenticado tras iniciar sesión. El preajuste de clave de Provider API (`commandcode`) envía la clave configurada activa: la mayoría de los identificadores de modelo usan Chat Completions con un encabezado Bearer, mientras que los identificadores `claude-*` usan Anthropic Messages con `x-api-key`, porque Command Code solo los sirve en `/provider/v1/messages`. Un proveedor que reutiliza el nombre `commandcode` para un endpoint distinto conserva su propio protocolo. El preajuste OAuth (`command-code`) usa el bearer de la cuenta almacenada para el descubrimiento autenticado y transmite la generación desde `/alpha/generate` como NDJSON. El marcado de llamadas a herramientas de MiMo que la pasarela devuelve como texto se elimina cuando duplica una llamada real. En los modelos MiMo, una llamada a herramienta declarada completa sin contraparte nativa se restaura solo tras un final limpio; los turnos interrumpidos o filtrados dejan el marcado como texto. Cree claves de Provider API en
+[Command Code Studio](https://commandcode.ai/studio/).
+
+Para un proveedor que utiliza el adaptador nativo `command-code`, `projectContext: "on"` opta por enviar archivos de proyecto locales en los campos `/alpha/generate`, `memory`, `taste` y `skills`. Con `projectContext` sin configurar o `"off"`, no se leen ni envían archivos de proyecto (`AGENTS.md`, gusto o habilidades); la carga útil de metadatos `config` existente no cambia. Las raíces se resuelven desde el **Directorio de trabajo del proceso proxy opencodex**, no desde el espacio de trabajo remoto de una persona que llama. El cargador lee `AGENTS.md`, `.commandcode/taste/taste.md` y `SKILL.md` archivos en directorios secundarios inmediatos de `.commandcode/skills`, `.agents/skills` y `.pi/skills` bajo ese directorio de trabajo. Al habilitar la opción, se envía el contenido recopilado aguas arriba al punto final Command Code configurado. Se rechaza para otros adaptadores. Las comprobaciones de ruta asíncrona mantienen las lecturas dentro del directorio de trabajo resuelto, incluso cuando ese directorio es una raíz del sistema de archivos; solo se lee el contenido del archivo regular. Los enlaces simbólicos de directorio de habilidad que se resuelven dentro de ese directorio están permitidos; aquellos que se resuelven fuera son rechazados. Cada entrada visitada cuenta para el presupuesto de escaneo; como máximo se seleccionan 16 habilidades. Los bytes de archivo, los bytes de habilidad total y el tiempo de carga están limitados; los archivos ilegibles o faltantes producen campos vacíos. Los resultados estables se almacenan en caché durante 30 segundos; los tiempos de espera y los rechazos de admisión al sistema de archivos no se almacenan en caché, por lo que una solicitud posterior puede volver a intentarlo.
+
+**Autenticación y descubrimiento de OrcaRouter.** Elija `ocx login orcarouter-oauth` para la autorización del navegador con un clic o `ocx login orcarouter` para pegar una clave API existente. El flujo PKCE abre primero un oyente de bucle de retorno, envía un desafío S256 nuevo y un `state` a `https://www.orcarouter.ai/auth`, canjea el código de un solo uso en `https://www.orcarouter.ai/api/v1/auth/keys` y guarda la clave devuelta, propiedad del usuario, en `~/.opencodex/auth.json`. El preajuste de clave manual sigue usando el almacén de claves de proveedor habitual. Ambos modos se enrutan a `https://api.orcarouter.ai/v1` y descubren el catálogo público en vivo con `capability=chat`; las filas de medios o de reordenamiento que no son de chat quedan excluidas, y las modalidades de entrada declaradas determinan si Codex ofrece adjuntos de imagen. Como el catálogo es público, el inicio de sesión con clave manual informa que la validación es desconocida en lugar de aceptar esa respuesta como prueba de que la clave funciona.
+
+Durante el inicio de sesión del navegador OrcaRouter (`ocx login orcarouter-oauth`), un cuerpo de respuesta de intercambio de claves exitoso debe ser válido UTF-8 JSON no más grande de 64 KiB. El presupuesto de 30 segundos de la solicitud cubre tanto los encabezados de respuesta como el cuerpo completo; los cuerpos sobredimensionados o malformados son rechazados antes de guardar la clave. Estos límites se aplican solo al intercambio de claves de inicio de sesión, no a las cargas útiles de solicitud de inferencia. La validación del alcance no cambia: se permite un `scope` omitido, mientras que se rechaza un `scope` explícitamente inválido.
+
+Para una implementación autoalojada de un origen, establezca el origen compartido antes del primer inicio de sesión de PKCE; la URL de inferencia guardada se deriva del mismo origen:
+
+```bash
+ORCAROUTER_BASE_URL=https://router.example ocx login orcarouter-oauth
+```
+
+Para una implementación auto-alojada dividida, establezca `ORCAROUTER_API_BASE_URL` y `ORCAROUTER_AUTH_BASE_URL` por separado.
+
+El valor debe ser un origen HTTPS (o loopback HTTP para el desarrollo local) sin credenciales, consulta o fragmento. Antes del primer inicio de sesión en un punto final autoalojado privado/loopback, permita explícitamente ese destino en la fila de proveedores `~/.opencodex/config.json`. Por ejemplo, fusione esta entrada en el objeto `providers` existente para un servidor de desarrollo local:
+
+```json
+{
+  "orcarouter-oauth": {
+    "adapter": "openai-chat",
+    "baseUrl": "http://127.0.0.1:9999/v1",
+    "authMode": "oauth",
+    "allowPrivateNetwork": true
+  }
+}
+```
+
+Luego ejecute `ORCAROUTER_BASE_URL=http://127.0.0.1:9999 ocx login orcarouter-oauth`. El inicio de sesión guarda la aceptación de ese consentimiento; fijar la URL por sí solo nunca concede acceso a la red privada. Sin esa aceptación, la validación de destino rechaza la inferencia y el descubrimiento de modelos para ese punto final. El requisito se aplica al punto final del proveedor; el oyente de devolución de llamada del navegador no lo necesita. Vuelva a ejecutar el inicio de sesión tras recibir un `401` de la retransmisión; las claves de OrcaRouter son duraderas y no tienen concesión de token de actualización.
+
+**Meta Model API (`meta-model`).** Ofrece Muse Spark mediante el endpoint compatible con OpenAI de Meta, en `/v1/responses`. Crea una clave en [la consola de desarrolladores de Meta](https://dev.meta.ai/docs/authentication). Meta llama `MODEL_API_KEY` a su variable, pero OpenCodex deriva el nombre del identificador del proveedor: usa **`META_MODEL_API_KEY`** o pega la clave durante `ocx init`. La cuenta requiere un método de pago y cada llamada se mide por token. Se incluyen tres modelos con contexto de 1M: `meta-model/muse-spark-1.3` y `meta-model/muse-spark-1.3-contributor`, con esfuerzos `minimal`/`low`/`medium`/`high`/`xhigh`, y `meta-model/muse-wonder-1.0` —Muse Wonder, preview—, con `minimal` a `max`. Muse Wonder solo ofrece modo Standard en Model API, sin nivel Contributor, a 4 USD por millón de tokens de entrada y 20 USD por millón de salida. Muse Wonder Full solo está disponible en las suscripciones Muse Code y no se incluye.
+
+Al iniciar, una lista guardada de los dos modelos Spark que siga sin modificaciones incorpora Muse Wonder si `meta-model` usa `https://api.meta.ai/v1` o no tiene un endpoint personalizado. Las pasarelas personalizadas y las listas editadas se conservan. También se mantienen los límites de salida y las ventanas de contexto existentes; la ventana de Wonder solo se añade si ya existe un mapa de ventanas. La detección sigue deshabilitada hasta verificar un catálogo autenticado, porque el mismo host también sirve modelos de imagen y voz.
+
+Dos cosas que vale la pena saber antes de elegirlo. **Una suscripción Muse Code no se aplica aquí:** Meta limita esa credencial al CLI de Muse Code y factura cualquier otra clave como pago por uso. Y el nivel Contributor es barato porque Meta entrena con sus prompts: aproximadamente 92% de descuento en la entrada, 96% en la salida y 99% en la entrada en caché, así que mantenga el material confidencial fuera de él. Muse Spark también está disponible a través de revendedores, con una lista más estrecha: `command-code` ofrece ambos niveles, mientras que `opencode-go` sirve solo `muse-spark-1.3-contributor`.
+
+**Meta Muse Code (`meta-muse`).** Un inicio de sesión normal en macOS primero intenta usar la clave API que `muse login` ya tiene almacenada. Sin credencial local, o en otra plataforma, se inicia el flujo de aprobación de dispositivo en el navegador. Agregar cuenta y la reautenticación omiten la importación local para no reutilizar la cuenta que se está reemplazando. OpenCodex nunca lanza el CLI de Muse. Si el inicio de sesión de dispositivo falla sin cancelación, una superficie de entrada manual disponible puede aceptar una clave pegada; esa clave pasa por el mismo formato y la misma validación de la Model API que una clave importada. En macOS, apruebe el aviso de Llavero en el host del proxy dentro de 120 segundos. Los rechazos de importación muestran el motivo del fallo y ofrecen un campo para pegar una clave existente sin iniciar otro inicio de sesión. Agregar cuenta en un proveedor ya configurado omite la importación local. Consulte
+[Soporte de plataforma](/es/reference/platform-support/) para ver el panorama completo por plataforma.
+
+Iniciar cualquier inicio de sesión de Meta Muse a través de la API de administración requiere una sesión del panel, incluidos agregar cuenta y la reautenticación. Un encabezado con un token de administración en bruto o encabezados de GUI falsificados reciben
+`403 oauth_consent_required` antes de que se lea una credencial o comience una concesión. Esta puerta usa el principal de sesión resuelto por el servidor, no un recibo de casilla de advertencia registrado por separado. `ocx login meta-muse` directo y los demás proveedores OAuth conservan sus políticas de inicio de sesión existentes. Por eso la lista de proveedores OAuth de la administración omite Meta Muse en los paneles con token de administración en bruto; abra un panel autenticado por sesión para usar ese flujo de inicio de sesión. Esto solo cambia el descubrimiento, no las comprobaciones de admisión al iniciar el inicio de sesión ni en la continuación manual.
+
+Los tres modelos `meta-muse` sembrados (Muse Spark 1.3, su nivel Contributor y Muse Wonder) exponen `minimal`/`low`/`medium`/`high`/`xhigh`/`max` a los clientes enrutados, incluido el selector de esfuerzo de Grok. Las solicitudes usan
+`User-Agent: muse-build/1.3.0 (opencodex compatibility)` para que Meta acepte el contrato de esfuerzo de Muse Code. Un User-Agent de proveedor explícito anula este valor predeterminado y puede hacer que se rechace
+`max`. En `meta-model`, solo Muse Wonder acepta `max`; sus filas Spark y OpenCode Go mantienen el techo `xhigh`. Anunciar `max` es el contrato del modelo y no demuestra que su plan de Muse Code cubra Muse Wonder.
+
+**Lea esto antes de habilitarlo.** Meta limita esa credencial al CLI de Muse Code, por lo que usarla aquí es una ruta *sin soporte*. Meta no autoriza la cobertura de suscripción fuera de su propio cliente, cómo se liquidan estas llamadas no es observable desde la API, y debe tratar cada llamada como facturable en su cuenta. Meta también puede rechazar la solicitud directamente con HTTP 403 y *"This API key is billed to a Muse Code subscription. Muse Code subscriptions cover requests from the Muse Code client only. Use it in Muse Code, or use a pay-as-you-go API key for other clients."* OpenCodex lo informa como una restricción de plan sobre una credencial válida, no como una credencial rechazada o caducada, porque ningún nuevo inicio de sesión puede levantarla: una clave de suscripción de Muse Code no puede servir ninguna solicitud fuera del cliente de Muse Code, y una clave de la API de Meta de pago por uso con el proveedor `meta-model` es la ruta admitida. La clave, importada o pegada, se copia en el almacén de autenticación de OpenCodex (`~/.opencodex/auth.json`, modo 0600) como cualquier otra credencial OAuth. El panel muestra una advertencia de Términos de servicio antes del primer inicio de sesión y antes de cualquier reautenticación: el mismo tratamiento que reciben Anthropic y Google Antigravity.
+
+Meta informa el uso de la ventana de suscripción dentro de las respuestas en streaming, y OpenCodex lo lee desde allí. La fila de la cuenta muestra las últimas ventanas de 5 horas y semanales observadas junto con la antigüedad de esa lectura: Meta no publica ningún endpoint para consultarlas bajo demanda, así que un valor solo se actualiza con otro turno en streaming a través de este proveedor, y un turno que pasa por la traducción de solicitudes en lugar de por passthrough no informa ninguno. Una cuenta que todavía no ha servido un turno en streaming simplemente no muestra cuota, lo cual no es un error. Los límites de solicitudes se aplican por equipo, no por clave.
+
+Si la solicitud conservada que empezó más recientemente para la cuenta actual de Muse informa explícitamente de una suscripción agotada y una hora futura de restablecimiento, la barra de cuotas del dashboard puede mostrar ese límite observado aunque Meta omita el mensaje habitual de uso. La etiqueta de Muse incluye una cuenta regresiva. Solo lee evidencias locales del registro de solicitudes y no envía ninguna solicitud a un modelo. No interpreta una ventana sin nombre como de cinco horas o semanal. Un éxito más reciente o el vencimiento de la hora de restablecimiento elimina este dato alternativo. La elección usa la hora de inicio de la solicitud en el historial coincidente acotado por el servidor, para que una solicitud anterior que termine tarde no oculte un éxito más reciente.
+
+Para una configuración admitida, use `meta-model` de arriba con su propia clave.
+
+**Cuota de Command Code.** El panel y `ocx account refresh` sondean las ventanas de Command Code `/alpha/billing/credits` (de 5 horas y semanales) en el host canónico `https://api.commandcode.ai`. El preajuste OAuth (`command-code`) usa el bearer de la cuenta almacenada; el preajuste de clave de Provider API (`commandcode`) usa la clave configurada activa. Nunca se sondea una URL base parecida editada por el usuario. Los créditos mensuales restantes, comprados y gratuitos se muestran como una ventana en USD cuando Command Code también informa del gasto del período.
+
+**SambaNova Cloud descubrimiento.** El preajuste lee la lista pública `/v1/models` de SambaNova Cloud desdel host API fijo, conserva los identificadores nativos del proveedor y limita el descubrimiento a 128 KiB y 128 filas sin procesar. Debido a que el catálogo no está autenticado, el flujo de inicio de sesión CLI informa que la clave no es verificable en lugar de tratar la respuesta pública como prueba. Las solicitudes de chat siguen utilizando la clave Bearer configurada y desactivan las llamadas a funciones paralelas, que SambaNova aún no admite. Los puntos finales de implementación privados de SambaStudio están fuera del alcance. Crear claves en [Nube SambaNova](https://cloud.sambanova.ai/apis).
+
+**Descubrimiento de la fábrica de tokens Nebius.** El preajuste solicita el catálogo de modelos detallado autenticado y mantiene solo filas cuya arquitectura produce texto, excluyendo modelos de incrustación y generación de imágenes. Conserva los identificadores nativos que contienen barras, además de los metadatos de contexto y de modalidad de entrada informados, y limita el descubrimiento a 512 KiB y 512 filas sin procesar. Los hosts de implementación dedicados están fuera del alcance. Crear claves en [Fábrica de tokens Nebius](https://tokenfactory.nebius.com).
+
+**Crusoe descubrimiento.** El preajuste basado en claves utiliza el adaptador `openai-chat` y envía su clave de portador solo al host de inferencia sin servidor fijo de Crusoe. `/v1/models` rechaza solicitudes no autenticadas con 401, por lo que una respuesta de lista exitosa cuenta como validación de clave. Discovery conserva los identificadores nativos delimitados por barras, como `zai-org/GLM-5.3` y `moonshotai/Kimi-K2.6`, exactamente como Crusoe los devuelve y tiene un límite de 256 KiB y 256 filas sin procesar. Las filas se mantienen solo cuando informan `is_public: true` y un texto o un multimodal `architecture.modality`, que excluye las implementaciones privadas de cuenta y cualquier incorporación o filas de medios. Los modelos de razonamiento devuelven su pensamiento en el campo Chat Completions `reasoning`, que lee el adaptador. Solo `openai/gpt-oss-120b` acepta una escalera `reasoning_effort` (`low`, `medium`, `high`); los otros modelos de razonamiento tratan el campo como un control de activación/desactivación, por lo que el preajuste declara que no hay escalera de esfuerzo en todo el proveedor y no hay llamadas de herramienta paralelas en todo el proveedor. Se aplican límites de solicitudes por proyecto y por modelo (429 cuando se excede, 503 cuando se escala una implementación compartida), y las nuevas cuentas comienzan con $ 5 de créditos gratuitos. Crea una clave en el [Consola de Crusoe Cloud](https://console.crusoecloud.com) bajo Fundición de Inteligencia, Inferencia.
+
+**Detección de DigitalOcean.** El preajuste usa una clave de acceso de modelo contra el host fijo compartido de Serverless Inference e interseca la respuesta autenticada de `/v1/models` con la lista de permitidos de Chat Completions respaldada por la documentación de DigitalOcean. Los identificadores desconocidos, exclusivos de Responses, de incrustación y de generación de medios se rechazan de forma segura. El descubrimiento se limita a 256 KiB y 256 filas sin procesar; los hosts dedicados y específicos de agentes quedan fuera de alcance. Cree una clave en el [panel de control de DigitalOcean](https://cloud.digitalocean.com/model-studio/manage-keys).
+
+**Scaleway descubrimiento.** El ajuste preestablecido cruza la lista de modelos autenticados con la lista de permisos de Scaleway Chat Completions sin servidor documentada. Desconocido, solo Responses, la incrustación, la transcripción y otros identificadores de modelos de medios fallan; el descubrimiento está limitado a 128 KiB y 128 filas en bruto. Utiliza el punto final compartido del proyecto predeterminado; las URL calificadas para el proyecto y las implementaciones dedicadas requieren un proveedor personalizado. Cree una clave API en el [Consola Scaleway](https://console.scaleway.com/generative-api).
+
+**Descubrimiento de Featherless.** El preajuste consulta el host fijo compatible con OpenAI y pide solo los primeros 100 modelos populares filtrados por el servicio para chat y el plan actual. Las reglas del registro rechazan cada fila salvo que declare disponibilidad en el plan, ausencia de restricciones de acceso de Hugging Face y `features.tool_use: true`. El descubrimiento se limita a 128 KiB y 100 filas originales; nunca se descarga ni almacena completo el catálogo de decenas de miles de modelos. Como `/v1/models` admite consultas con o sin autenticación, esa respuesta no demuestra que la clave proporcionada sea válida; las solicitudes de chat sí usan la clave Bearer configurada. Featherless reserva sus planes individuales para uso interactivo y prototipos; las aplicaciones generales necesitan un plan Scale. Crea una clave en el [panel de Featherless](https://featherless.ai/account/api-keys).
+
+**Detección de Novita.** El preajuste basado en claves usa el adaptador `openai-chat` y envía su clave Bearer solo al host fijo compatible con OpenAI de Novita. Su lista pública de modelos se filtra a las filas que informan tanto `model_type: chat` como el endpoint `chat/completions`, con el descubrimiento limitado a 512 KiB y 256 filas sin procesar. Los identificadores de modelo deben conservarse exactamente como los devuelve Novita, incluidos los delimitados por barras, y no deben normalizarse ni reescribirse antes del enrutamiento. Como el catálogo es público, el inicio de sesión informa la clave como no verificable en lugar de tratar una respuesta de lista exitosa como prueba. Las capacidades de los modelos varían, así que el preajuste no anuncia llamadas a herramientas paralelas para todo el proveedor ni `reasoning_effort` de OpenAI. Cree una clave en el [gestor de claves de Novita](https://novita.ai/settings/key-management).
+
+> **Alcance de Baseten:** El preajuste cubre solo las [API de modelos](https://docs.baseten.co/inference/model-apis/overview) compartidas de Baseten. Use una [clave API](https://docs.baseten.co/organization/api-keys) personal para uso local o una clave de equipo con acceso **API de modelo de llamada** para uso compartido/de producción. Los endpoints dedicados de Truss `predict` usan diferentes hosts y esquemas y no son enrutados por este preajuste. El descubrimiento en vivo para este preajuste se limita a una respuesta de 1 MiB y 256 filas de modelos sin procesar.
+
+<a id="official-codebuddy-code-cli-global--cn"></a>
+
+<a id="workbuddy-ai-subscription"></a>
+
+### Suscripción WorkBuddy AI
+
+`workbuddy-ai` conecta tu suscripción internacional de WorkBuddy AI como proveedor de modelos. Elige **WorkBuddy AI** en Proveedores e inicia sesión, o ejecuta:
+
+```bash
+ocx login workbuddy-ai
+```
+
+Completa el inicio de sesión en el navegador. OpenCodex consulta la autorización durante un máximo de cinco minutos, guarda los tokens y los renueva cuando hace falta. Puedes añadir cuentas mediante la lista OAuth existente; la identidad del equipo permanece asociada a su propio token. No necesitas instalar WorkBuddy Desktop ni importar archivos de credenciales.
+
+Los modelos y capacidades proceden del catálogo de productos de tu cuenta. Después de iniciar sesión, elige un modelo `workbuddy-ai/<model-id>`; si el descubrimiento no está disponible, se ofrece `workbuddy-ai/default-model` como selector de respaldo. El streaming, las herramientas y las respuestas almacenadas usan el endpoint Chat de WorkBuddy. Las pestañas Resumen y Cuentas muestran créditos restantes, usados y totales, saldos base y de regalo y los próximos créditos no diarios que caducan, cuando esa información está disponible. Actualizar consulta el resumen de facturación de la cuenta; una lectura fallida no significa saldo cero. Los créditos son informativos: agotarlos no desactiva los modelos gratuitos.
+
+Se utiliza un protocolo de suscripción no oficial basado en el [plugin WorkBuddy de Magpie](https://github.com/magpie-community/plugins/tree/e7f65641df820dfd715c0d2241f99f2092e4efb1/packages/workbuddy). Las restricciones del canal del cliente o de la cuenta se devuelven al solicitante. OpenCodex no reescribe instrucciones de identidad del agente para evitarlas. La disponibilidad depende de tu cuenta, región, permisos de modelo y la API vigente de WorkBuddy. Es independiente de los proveedores CodeBuddy CLI con clave API y no conecta el cliente WorkBuddy Desktop a OpenCodex.
+
+### CodeBuddy Code CLI oficial (Global y CN)
+
+OpenCodex proporciona soporte oficial para adaptadores para el código CodeBuddy Code CLI de Tencent Cloud a través de los presets `codebuddy` (Global) y `codebuddy-cn` (China).
+
+```json
+{
+  "providers": {
+    "codebuddy": {
+      "adapter": "codebuddy",
+      "baseUrl": "https://www.codebuddy.ai",
+      "apiKey": "${CODEBUDDY_API_KEY}"
+    },
+    "codebuddy-cn": {
+      "adapter": "codebuddy",
+      "baseUrl": "https://www.codebuddy.cn",
+      "apiKey": "${CODEBUDDY_CN_API_KEY}"
+    }
+  }
+}
+```
+
+- **Prerrequisitos:** Instale el CodeBuddy CLI oficial a nivel mundial:
+  ```bash
+  npm install -g @tencent-ai/codebuddy-code
+  ```
+- **Autenticación:** Obtenga su clave oficial API desde la consola del proveedor:
+  - Global: [Llaves CodeBuddy Global API](https://www.codebuddy.ai/profile/keys)
+  - CN: [Llaves CodeBuddy CN API](https://copilot.tencent.com/profile/keys)
+- **Aislamiento de la región:** `codebuddy` y `codebuddy-cn` utilizan puntos finales canónicos separados (`https://www.codebuddy.ai` y `https://www.codebuddy.cn`) y entornos infantiles aislados (`CODEBUDDY_INTERNET_ENVIRONMENT=public` vs `internal`). Las credenciales son estrictamente regionales y nunca se intercambian entre entornos. La anulación de la URL base canónica falla cerrada.
+- **Modelo Discovery:** el proxy solicita la configuración del producto CodeBuddy (`GET {baseUrl}/v3/config`) con la clave configurada como el encabezado `X-API-Key`, y la lista en esa respuesta es la lista autorizada de modelos descubiertos: es la configuración de la cuenta propia de la clave, por lo que se demuestra que pertenece a la clave: una clave diferente o incorrecta responde al sobre anónimo sin lista en lugar de los modelos de otra cuenta. La lista autenticada es la misma lista de las impresiones CLI para `--model` (la línea "Actualmente compatible" de un inicio de sesión CLI), puede diferir del manifiesto estático incluido con el CLI, y los selectores predeterminados del proveedor (`default` para CN, `default-model` para Global) nunca aparecen en él, pero permanecen llamables: el catálogo los retiene durante el descubrimiento en vivo y en cada ruta alternativa. Al iniciar/sincronizar, el proxy vincula la lista almacenada en caché a una huella digital irreversible de la clave configurada, por lo que un conmutador de clave nunca observa una lista almacenada en caché para la clave anterior, y se degrada a la caché obsoleta de proveedor/huella digital, luego a la semilla estática en `src/providers/codebuddy-models.ts`, cuando la clave no se autentica o la solicitud falla. Los registros de fallos de detección contienen solo una categoría y un estado HTTP, sin el mensaje de la puerta de enlace o una excepción de transporte sin procesar. La solicitud de descubrimiento con credenciales no sigue a las redirecciones; una respuesta 3xx degrada la lista sin reenviar la clave a otro origen.
+- **Propiedad de la herramienta y el puente de herramientas:** El CLI siempre se genera con `--tools ""` y `--strict-mcp-config`, por lo que no tiene herramientas incorporadas o configuradas por el usuario. Cuando una solicitud lleva un catálogo de herramientas Codex, el proveedor arma un puente MCP de captura solamente: el catálogo validado y la configuración MCP se escriben en un dir temp privado, el CLI se lanza con `--mcp-config` y una lista `--allowedTools` exacta, y el marco `system/init` debe informar exactamente ese servidor de puente como conectado o el giro falla cerrado. El puente anuncia las herramientas Codex y captura las llamadas propuestas, pero nunca ejecuta nada: un lote de llamadas a herramientas completado se devuelve como `function_call` elementos (nombres asignados a los nombres de cable de la solicitud, como máximo 16 llamadas por mensaje de asistente), el árbol de procesos se termina en `message_stop`, y el cliente externo Codex solo realiza aprobación, sandboxing y ejecución. Los bloques de uso de herramientas paralelos se almacenan en memoria intermedia y se devuelven como llamadas completas incluso cuando sus fragmentos se entrelazan o CodeBuddy reutiliza un índice de bloque de contenido. Un bloque que se deja abierto en el extremo de giro, un reemplazo del mismo índice antes de completar JSON argumentos, o un fragmento de argumento que no se puede atribuir a un bloque abierto falla el giro en lugar de reenviar una llamada parcial o vacía. Los resultados de la herramienta vuelven como entrada de la siguiente solicitud, y la conversación continúa. Las solicitudes sin herramientas mantienen la forma de texto y razonamiento sin formato. Si el CLI escribe una línea de control DSML `calls` no citada seguida de una línea de control `functions.*` invocada en texto o razonamiento, el OpenCodex rechaza el turno en lugar de reenviar el andamio o interpretarlo como una llamada ejecutable. DSML discutido o citado en prosa, código en línea, código cercado o ejemplos de fuente sigue siendo texto de respuesta ordinario.
+- **Aplicación de elección de herramienta:** Cuando una solicitud especifica `tool_choice: "required"` o selecciona una herramienta con nombre específico, el puente espera una llamada de herramienta del modelo. Si el CLI completa el turno con texto sin formato en lugar de capturar una llamada de herramienta, el OpenCodex falla al cerrarse con un error 502 `tool_call_required` en lugar de devolver una finalización de texto no válida.
+- **Estado de gobierno:** Si el enrutamiento de esta superficie de automatización del proveedor detrás de un proxy para un agente de terceros satisface los términos de uso aceptable de CodeBuddy es una pregunta abierta marcada para la revisión de seguridad del mantenedor (consulte la nota de gobierno en la entrada del registro del proveedor). Trate a este proveedor como pendiente de esa revisión, y tenga en cuenta el límite de propiedad del puente de herramientas: el CLI anidado anuncia herramientas pero nunca las ejecuta, y la aprobación, el sandboxing y la ejecución permanecen con el cliente externo Codex.
+- **Derechos y facturación:** El proveedor utiliza la misma cuenta CodeBuddy/superficie de autenticación CLI documentada por el proveedor. La disponibilidad y la facturación de los créditos gratuitos, promocionales, de prueba o de suscripción siguen estando determinadas por el derecho de cuenta de CodeBuddy del usuario.
+
+<a id="official-qoder-cli-global--cn"></a>
+
+### Oficial Qoder CLI (Global y CN)
+
+OpenCodex proporciona soporte de adaptador oficial para Qoder a través de los preajustes `qoder` (Global) y `qoder-cn` (China). Ambos usan un Token de Acceso Personal suministrado por el usuario y el CLI sin cabeza del proveedor; OpenCodex nunca lee sesiones de escritorio de Qoder, cookies de navegador, tokens de actualización o API de consolas privadas.
+
+```json
+{
+  "providers": {
+    "qoder": {
+      "adapter": "qoder",
+      "baseUrl": "https://qoder.com",
+      "apiKey": "${QODER_PERSONAL_ACCESS_TOKEN}"
+    },
+    "qoder-cn": {
+      "adapter": "qoder",
+      "baseUrl": "https://qoder.cn",
+      "apiKey": "${QODERCN_PERSONAL_ACCESS_TOKEN}"
+    }
+  }
+}
+```
+
+- **Prerrequisitos:** Instale el CLI oficial para la región que utiliza:
+  ```bash
+  npm install -g @qoder-ai/qodercli        # Global: qoder / qodercli
+  npm install -g @qodercn-ai/qoderclicn    # CN: qodercn / qoderclicn
+  ```
+- **Autenticación:** Cree una PAT en la página de integraciones de cuenta ([Mundial](https://qoder.com/account/integrations), [NC](https://qoder.cn/account/integrations)) y péguela como clave API del proveedor. La clave almacenada alcanza el CLI solo como `QODER_PERSONAL_ACCESS_TOKEN` (Global) o `QODERCN_PERSONAL_ACCESS_TOKEN` (CN) en un entorno secundario con alcance.
+- **Aislamiento de la región:** Cada preajuste acepta solo su destino canónico (`https://qoder.com` o `https://qoder.cn`) y resuelve su propio ejecutable. Las credenciales, el caché del modelo, el uso y la salud son independientes; ninguna región vuelve a la otra. Un proveedor personalizado más antiguo llamado `qoder` con un destino diferente mantiene su adaptador y URL existentes.
+- **Ejecutables de Windows:** Cada preset usa el ejecutable nativo de su CLI cuando está en PATH: `qoder.exe` o `qodercli.exe` para Global; `qodercn.exe` o `qoderclicn.exe` para CN. Dentro de una misma carpeta, `.exe` tiene prioridad sobre `.cmd` con el mismo nombre. Un nombre alternativo posterior, como `qoderclicn.exe`, encontrado en cualquier carpeta de PATH tiene prioridad sobre `qodercn.cmd`; sin embargo, una carpeta anterior que solo contenga `qodercn.cmd` oculta `qodercn.exe` del mismo nombre base en una carpeta posterior. Qoder recibe valores vacíos para `--tools` y `--setting-sources`, para excluir sus herramientas y ajustes locales. Un lanzador que pasa por PowerShell descarta esos argumentos vacíos. Si es el único disponible, se rechaza el turno antes de iniciar la CLI con `cli_dispatcher_drops_empty_args`. Añade a PATH la carpeta del ejecutable nativo —el instalador CN oficial usa `%USERPROFILE%\.qoder-cn\bin\qoderclicn`— y reintenta. Un lanzador que pasa los argumentos directamente, como una shim de npm, sigue funcionando.
+- **Modelo Discovery:** `qoder --list-models` es la lista autorizada de derechos para el PAT actual. La caché está vinculada a una huella digital irreversible del token, por lo que cambiar de cuenta nunca reutiliza la lista de otra cuenta. Si el descubrimiento falla, el proveedor se degrada a una caché obsoleta y luego a la semilla estática documentada.
+
+El CLI inicia primero un entorno de agente completo, por lo que el descubrimiento de catálogo en segundo plano permite hasta 30 segundos por ejecución, y las llamadas simultáneas al mismo proveedor comparten una ejecución por token. La prueba de conexión del panel espera como máximo 8 segundos; pasado ese tiempo informa que el proveedor sigue descubriendo en lugar de marcarlo como fallido, y cuando la ejecución tiene éxito el catálogo se vuelve a sincronizar sin reiniciar el proxy. Las sesiones de Codex que ya están en marcha conservan su lista de modelos anterior hasta reiniciarse: reinicie Codex o ejecute `ocx system codex-restart --yes`, que reinicia los app-servers de Codex (la referencia de la CLI describe qué conserva y qué vuelve a lanzar).
+- **Uso del token:** Qoder CLI reporta cero recuentos de tokens a menos que su interruptor de uso esté activado, por lo que cada preajuste lo enciende en su entorno hijo de alcance CLI: `QODER_EXPOSE_TOKEN_USAGE=true` para Global y `QODERCN_EXPOSE_TOKEN_USAGE=true` para CN, que lee solo su propio prefijo.
+- **Protección de la salida:** si la CLI repite envoltorios internos de llamadas o resultados de herramientas de OpenCodex dentro del texto del asistente, el turno falla con `vendor_scaffold_detected` (502), en lugar de devolver el envoltorio como una respuesta correcta. Tampoco se reenvían el razonamiento ni las llamadas a herramientas posteriores al envoltorio. El razonamiento inicia un bloque nuevo de texto, por lo que el texto o los bloques de código anteriores no pueden ocultarlo. Si el turno de la CLI ya terminó con un error propio, se informa ese error, sin exponer el envoltorio. El proxy no reintenta automáticamente ese fallo. El texto normal y los ejemplos de código con cierre siguen el reconocedor compartido; un ejemplo desbordado cuyo cierre no se puede verificar se rechaza. El texto conserva los caracteres Unicode divididos entre mensajes de la CLI; los sustitutos UTF-16 sin pareja se reemplazan por U+FFFD.
+- **Propiedad de la herramienta:** El CLI ejecuta un solo giro `stream-json` con `--tools ""`, `--strict-mcp-config`, deshabilitando las fuentes y la persistencia de la sesión, por lo que Codex mantiene la propiedad exclusiva de la herramienta. Las herramientas declaradas por el cliente se exponen a través de un servidor MCP aislado.
+- **Entrada de imagen:** Global sigue reenviando las imágenes compatibles mediante la proyección compartida, sin una lista de visión por modelo. CN conserva los valores predeterminados de su sidecar de visión. Su ruta de imágenes directas solo admite un PNG base64 canónico de hasta 1 MiB decodificado, 8192 píxeles por lado y 16 millones de píxeles en total, en un único turno de usuario, con `DeepSeek-Flash` o `Qwen3.8-Flash`. Usa `qoderclicn 1.1.70`: la [issue #7516](https://github.com/lidge-jun/opencodex/issues/7516) registra éxito real en Windows 11 x64 para ambos modelos con `--attachment` y con stdin en formato `--input-format stream-json --output-format stream-json`; OpenCodex solo usa stdin. Antes de descubrir la CLI, valida la longitud y el relleno base64, la firma PNG decodificada y los campos IHDR básicos. No descomprime píxeles ni valida todos los bloques o CRC. Estos límites son una política de recursos de OpenCodex, no máximos verificados del proveedor: la evidencia real corresponde a un PNG de 96×96 cuyo ráster RGBA ocupa 36 KiB. Los tamaños mayores necesitan verificación independiente. No se han verificado otras versiones de la CLI y el adaptador no comprueba la instalada. CN rechaza imágenes por URL, otros formatos o modelos, varias imágenes, imágenes de resultados de herramientas e historial con imágenes o repetición entre turnos antes de iniciar la CLI, con `unsupported_input_modality`; usa el sidecar de visión para esos casos. Las pruebas con una CLI inyectada verifican serialización y cancelación, sin demostrar soporte real del proveedor. La proyección compatible de Qoder conserva el orden de las imágenes y marca referencias no admitidas como `[image omitted: unsupported reference]`. La repetición sin estado de Global todavía puede asociar incorrectamente imágenes históricas con su texto original; CN no habilita esa repetición sin verificar.
+- **Recuperación de PAT:** en ambos preajustes de Qoder, un grupo de claves API con varias claves puede cambiar a otra PAT ante un rechazo de autenticación admitido o un agotamiento de cuota a nivel de cuenta, pero solo antes de que haya contenido de respuesta o un evento que haga insegura la repetición. La recuperación exige una clasificación específica de Qoder y respeta los presupuestos de credenciales y de envío; un mensaje de cuota o un HTTP 401/429 por sí solo no autoriza a repetir. Las configuraciones de una sola clave no rotan. Compartir el corredor del CLI no habilita esta recuperación de clave API para CodeBuddy ni para el CLI de Claude autenticado por sí mismo.
+- **Contingente:** No se utiliza la cuota pública API, por lo que los totales y los tiempos de reinicio no están disponibles. Los códigos 110 (límite diario de cuenta) y 118 (agotamiento de créditos personales) informan `insufficient_quota` y permiten la consideración de la recuperación de PAT. Otros códigos de cuota soportados también reportan `insufficient_quota` pero no lo autorizan. Los códigos de error numéricos tienen prioridad: un código numérico no reconocido no vuelve a la cuota o al texto de autenticación. Sin un código numérico, solo el mensaje diario de la cuenta compatible que comienza con "Ha alcanzado su límite de uso diario para Chat", sin equipo/modelo/calificador compartido, otorga recuperación de cuota; el texto genérico de límite de crédito no lo hace. Solo los fallos de cuota elegibles para la recuperación de PAT ingresan al manejo de enfriamiento de claves. Cuando un fallo de este tipo no tiene tiempo de reinicio, la clave fallida utiliza el tiempo de reutilización predeterminado existente; las clasificaciones de cuotas no recuperables no crean un tiempo de reutilización a través de esta ruta, y no se infiere ningún reinicio del día siguiente.
+- **Operadores:** Qoder Global es operado por BRIGHT ZENITH PRIVATE LIMITED bajo el [términos de servicio del producto](https://qoder.com/product-service); Qoder CN by?(?)? con Alibaba Cloud. Verifique `ocx provider test qoder` (o `qoder-cn` ) después de configurar.
+
+<a id="claude-code-cli-subscription"></a>
+
+### Claude Code CLI (suscripción)
+
+OpenCodex puede gastar una suscripción de Claude a través del propio arnés de Anthropic en lugar de reproducir una identidad de Claude Code contra el Messages API. El preajuste `claude-cli` ejecuta el oficial Claude Code CLI sin cabeza (`claude -p`, `stream-json`) una vez por turno:
+
+```json
+{
+  "providers": {
+    "claude-cli": {
+      "adapter": "claude-cli",
+      "baseUrl": "https://api.anthropic.com"
+    }
+  }
+}
+```
+
+- **Prerrequisitos:** `npm install -g @anthropic-ai/claude-code`, luego inicie sesión una vez con `claude` (o `claude setup-token` ). El CLI usa el propio inicio de sesión Claude Code de la máquina (la entrada macOS Keychain, o `~/.claude/.credentials.json` en otros lugares).
+- **Ninguna credencial almacenada:** esta fila no guarda ninguna clave API. La comprobación previa de cuota lee en memoria el token de inicio de sesión del CLI y lo envía solo al punto final de uso de Anthropic. OpenCodex no almacena ese token ni lo inyecta en las solicitudes de inferencia del CLI. El CLI posee el inicio de sesión y factura la cuenta por sí mismo. Un CLI sin iniciar sesión falla el turno con un error de inicio de sesión que nombra el comando, en lugar de un `401` genérico. La clasificación responde al mismo hecho: el preajuste es una fila de clave sin clave (`keyOptional`), por lo que no necesita ninguna clave API y no se ofrece ningún campo de clave. Una clave API guardada en esta fila por otros medios nunca llega al arnés: la facturación de la clave corresponde al preajuste `anthropic-apikey`.
+- **En el panel:** el selector de **Añadir proveedor** lista este preajuste bajo **Pagado**, junto con las filas de API, y lo marca con la insignia **Suscripción CLI** en lugar de **Libre**; que aquí no haya clave significa que el CLI posee la cuenta, no que el tráfico sea gratuito. Al seleccionarlo aparece una advertencia en lugar del campo de clave: esta no es una ruta de clave API, sino que impulsa el CLI con sesión iniciada (`claude -p`) y factura esa suscripción, y una clave introducida aquí nunca se usa. El espacio de trabajo de Proveedores lo cuenta y filtra como de pago y muestra **Suscripción CLI** como su modo de autenticación. Cualquier proveedor con `"adapter": "claude-cli"` se trata igual, incluidas las filas renombradas o escritas a mano: el panel lo lista como listo sin clave y nunca pide una.
+- **Un inicio de sesión sirve a todo el proxy:** el arnés lee el inicio de sesión Claude Code del usuario OpenCodex se ejecuta como, por lo que cada solicitud enrutada a través de esta fila, desde cualquier cliente del proxy, gasta esa cuenta Claude. No hay una cuenta por cliente, ni agrupación ni multiplexación; dar a varias personas su propio uso Claude necesita un usuario proxy por inicio de sesión.
+- **Medios de entrada:** la fila publica sus modelos como texto-sólo para v1. El CLI acepta un marco de imagen en su entrada de flujo json, pero no se ha mostrado ningún giro sin cabeza para entregar esos bytes al modelo, por lo que se rechaza una imagen enviada directamente a este proveedor (`unsupported_input_modality`) en lugar de caerse silenciosamente y responder ciegamente. Con el sidecar de visión en la ruta de la solicitud, las imágenes se subtitulan en texto antes de llegar a la fila.
+- **Aislamiento:** cada turno se ejecuta en un entorno hijo con alcance sin variable heredada `ANTHROPIC_*` (un `claude` ya apuntado a este proxy por lo tanto no puede volver a él), telemetría, retroalimentación y el auto-actualizador desactivado, y `--tools ""`, `--strict-mcp-config` más `--setting-sources ""`. El arnés no carga ningún servidor CLAUDE.md, skill, hook, plugin o MCP desde la máquina y no puede leer, escribir, ejecutar ni navegar. No se mantiene ninguna sesión entre turnos. El oficial CLI se encuentra en `PATH`, o en la ubicación de instalación nativa (`~/.local/bin/claude`) cuando un servicio inicia OpenCodex con un `PATH` más antiguo.
+- **Indicación del sistema:** el sistema de la persona que llama y las indicaciones del desarrollador reemplazan el preajuste Claude Code (`--system-prompt-file`), por lo que el turno responde al contrato del cliente en lugar del personaje del arnés. El indicador plegado se organiza en un archivo privado por turno (modo `0600`) y se pasa por ruta, porque los argumentos de proceso son legibles en todo el mundo a través de la lista de procesos; una solicitud que no lleva ni un sistema ni un indicador de desarrollador obtiene solo las instrucciones de repetición de conversación fijas.
+- **Almacenamiento en caché de conversación:** cada mensaje se reproduce como un bloque de texto estable separado, con el mensaje actual formateado de manera idéntica a su representación histórica posterior. La larga historia se corta solo en los puntos de control de mensajes completos. Los catálogos de herramientas se serializan de manera determinista. Claude Code controla los puntos de interrupción de caché, por lo que esto hace posible la reutilización de caché rápida sin garantizarlo.
+- **Propiedad de la herramienta:** cuando la solicitud lleva herramientas, un catálogo aislado de solo captura MCP expone solo las herramientas seleccionadas del cliente (el mismo puente que CodeBuddy usa). El CLI captura la llamada y el turn termina allí; aprobación, sandboxing, ejecución y el resultado devuelto se queda con Codex, Pi, u otro cliente. Las herramientas integradas y todos los demás servidores MCP permanecen desactivados.
+- **Límites de suscripción:** antes de cada lanzamiento OpenCodex pide el punto final de uso de Anthropic, con el propio inicio de sesión del CLI leído en la memoria, si la ventana de 5 horas, semanal o específica del modelo del plan está llena. Un plan agotado es rechazado localmente con HTTP 429 `claude_subscription_cooldown` y un `Retry-After` para el reinicio, en lugar de comenzar un CLI que fallaría. La respuesta se almacena en caché durante un minuto en `claude-usage-admission.json` bajo el OpenCodex home (solo porcentajes, tiempos de reinicio y una clave de cuenta hash). Si el cheque no puede ejecutarse, el turno continúa.
+- **Destino:** la fila canónica nombra `https://api.anthropic.com` porque ahí es donde aterriza el tráfico de la suscripción. OpenCodex nunca envía esa solicitud en sí, y anular la URL base falla en cerrarse en lugar de entregar el turno a otro entorno.
+
+> **Términos:** este preajuste gasta su suscripción Claude a través del propio CLI de Anthropic. Si conducir ese arnés sin cabeza desde un proxy se ajusta a los términos de su plan es una pregunta entre usted y Anthropic. OpenCodex no convierte el inicio de sesión en una clave API y no reproduce la identidad CLI de HTTP.
+
+<a id="a6api-credit-quota"></a>
+
+### Cuota de crédito A6API
+
+Un proveedor `openai-chat` personalizado que usa `authMode: "key"` y la URL base canónica `https://api.a6api.com` o `https://api.a6api.com/v1` recibe un medidor de crédito A6API en el panel de control y desde `ocx account refresh <provider>`. El nombre del proveedor es arbitrario; la detección utiliza el extremo canónico HTTPS. El medidor convierte las unidades de token A6API en USD utilizando el límite de crédito duro de la cuenta y muestra el porcentaje consumido más el crédito restante. El vencimiento del token no se muestra como un restablecimiento de la cuota porque el vencimiento no implica que el crédito se reponga.
+
+```json
+{
+  "providers": {
+    "my-a6": {
+      "adapter": "openai-chat",
+      "authMode": "key",
+      "baseUrl": "https://api.a6api.com/v1",
+      "apiKey": "${A6API_API_KEY}"
+    }
+  }
+}
+```
+
+Las sondas de cuota envían solo la clave activa al host canónico A6API y rechazan las redirecciones. Los totales de facturación mal formados, negativos o internamente inconsistentes no producen ningún informe en lugar de una barra engañosa.
+
+> **Restricción de uso de Tencent Cloud Coding Plan:** Tencent documenta esta suscripción solo para herramientas de codificación interactivas. La automatización general API, los backends de aplicaciones personalizados y el uso por lotes no interactivo están prohibidos y pueden hacer que se suspenda la clave del plan.
+
+> **Rutas de facturación GLM:** `zai` es la suscripción internacional de planes de codificación de Z.AI; `zhipu-bigmodel` es el punto final nacional de pago por uso de Zhipu. Diferentes hosts, diferentes claves, diferente facturación: una clave emitida para uno no se autenticará contra el otro.
+
+<a id="bigmodel-coding-plan-over-responses"></a>
+
+### Plan de codificación BigModel sobre Responses
+
+Seleccione **Zhipu AI - Plan de codificación BigModel ( Responses)** (`zhipu-bigmodel-responses`) para el punto final `openai-responses` `https://open.bigmodel.cn/api/v1`. Esto está separado de `zhipu-bigmodel-coding`, que usa Chat Completions en `/api/coding/paas/v4`.
+
+El preajuste utiliza un **Lista estática** (`liveModels: false`) tomado del [Documentación del plan de codificación GLM](https://docs.bigmodel.cn/cn/coding-plan/tool/codex.md) publicado:
+
+| Modelo | Tokens de contexto | Esfuerzo seleccionable ascendente | Esfuerzo predeterminado | Resúmenes de razonamiento |
+| --- | ---: | --- | --- | --- |
+| `glm-5.3` | 1,048,576 | `low`, `high`, `max` | `max` | Apoyado |
+| `glm-5.3-flash` | 1,048,576 | `low`, `high`, `max` | `max` | Apoyado |
+| `glm-5-turbo` | 204,800 | Ninguno (lista vacía) | `max` | Apoyado |
+
+`glm-5.3` y `glm-5-turbo` declaran entrada de solo texto aguas arriba. El catálogo Codex anuncia texto e imagen para ellos porque el sidecar de visión existente opencodex puede describir imágenes para modelos solo de texto; esa ruta requiere un sidecar de visión disponible y habilitado y no reclama soporte de imagen BigModel nativo.
+
+`glm-5.3-flash` es la excepción: declara la entrada nativa `text` y `image`, porque upstream lo documenta como un modelo multimodal nativo. Por lo tanto, lee imágenes directamente en lugar de ser enrutado a través del desvío del primer sidecar descrito.
+
+El modelo predeterminado es `glm-5.3`; Responses El contenido de razonamiento se conserva en la repetición. La exportación Codex existente agrega su nivel de compatibilidad `ultra` a GLM-5.3 y omite el campo de esfuerzo predeterminado de Turbo porque Turbo no tiene una escalera seleccionable; los metadatos del proveedor aún registran `max` para ambos modelos. Para Turbo, las solicitudes salientes Responses omiten `reasoning.effort`, incluyendo `max` o `ultra` de la persona que llama, mientras se conservan los resúmenes de razonamiento solicitados. Esto deja la selección de esfuerzo en el valor por defecto ascendente; opencodex no inyecta un protocolo seleccionable o `max`.
+
+El `models.json` del ejemplo es un archivo de catálogo local, no una respuesta documentada de la lista de modelos HTTP, y no el conjunto de modelos que sirve el punto final: las páginas del Plan de codificación indican que cada nivel del plan alcanza GLM-5.3 y GLM-5.3-Flash, y que las llamadas GLM-5-Turbo se cambian automáticamente a Flash, por lo que este punto final ya estaba sirviendo Flash bajo el Turbo id. Este preajuste aún no realiza el descubrimiento de modelos en vivo. Un proveedor personalizado existente con el mismo nombre mantiene su destino y metadatos configurados. El inicio de sesión de clave CLI también omite la sonda indocumentada `/models` e informa la validación como desconocida; la autenticación de clave exitosa se establece mediante una solicitud de inferencia posterior.
+
+<a id="multiple-api-keys"></a>
+
+### Múltiples claves API
+
+Los proveedores basados en claves también pueden mantener varias claves. Al añadir una clave desde la página Proveedores se guarda en `provider.apiKeyPool`, se activa y se refleja en `provider.apiKey`, de modo que el enrutamiento y los adaptadores siguen leyendo el mismo campo que antes. El mismo menú desplegable permite cambiar o eliminar claves; la API de gestión es `/api/providers/keys` y solo devuelve claves enmascaradas.
+
+<a id="switching-accounts-from-the-terminal"></a>
+
+### Cambio de cuentas desde la terminal
+
+Utilice `ocx account list`, `ocx account current` y `ocx account use` para inspeccionar o cambiar los mismos grupos de Codex, OAuth y claves API sin abrir el panel. Consulte la [referencia de la CLI](/es/reference/cli/providers-accounts/#ocx-account-subcommand) para ver los comandos, la salida JSON y el comportamiento de la sesión nueva.
+
+<a id="subscription-tier-in-account-listings"></a>
+
+#### Nivel de suscripción en los listados de cuentas
+
+`ocx account list <provider> --json` y `GET /api/oauth/accounts` reportan un campo `plan` en cada cuenta OAuth, usando el mismo nombre y ubicación que el proveedor OpenAI / Codex para que un consumidor pueda leer una forma en todos los proveedores.
+
+El campo siempre está presente. Es `null` cuando se desconoce el nivel, lo cual es deliberado: una clave **ausente** significa que el proxy es anterior a este campo, mientras que `null` significa que esta versión se veía y el proveedor no informó un nivel. Colapsar los dos permitiría a un consumidor asumir silenciosamente un nivel.
+
+Para Anthropic cuentas (ambos grupos) el valor proviene del perfil de cuenta autenticado que OpenCodex ya lee: el nivel de límite de solicitudes de la organización, informado como etiquetas como `max_20x`, `max_5x` o `pro`. Se registra en el inicio de sesión, importación local Claude Code y actualización de token. Para Google Antigravity el valor es el nivel pagado de `loadCodeAssist` (por ejemplo `g1-pro-tier`), volviendo al nivel actual. Una lectura fallida mantiene la última etiqueta grabada; una lectura que responde sin un nivel de informes `null`. El nivel nunca se deriva de los porcentajes de cuota, ya que estos se normalizan por cuenta: un asiento máximo × 5 al 50% es indistinguible de un asiento máximo × 20 al 50%.
+
+<a id="gpt-56-preview-paths"></a>
+
+### GPT-5.6 rutas de vista previa
+
+GPT-5.6 Sol / Terra / Luna se siembran en las listas de reserva del proveedor para que `ocx sync` pueda mantener los modelos visibles incluso cuando los catálogos en vivo se retrasan:
+
+| Ruta Codex | IDs de modelos de semillas | Codex - contexto visible |
+| --- | --- | --- |
+| Codex inicio de sesión ( Pool o Direct) | `gpt-5.6-*` | 922,000 |
+| OpenAI (clave API) | `openai-apikey/gpt-5.6-*` más `*-pro` | 922.000 (922.000 entradas máximas) |
+| OpenRouter | `openrouter/openai/gpt-5.6-sol`, `openrouter/openai/gpt-5.6-terra`, `openrouter/openai/gpt-5.6-luna` | 922,000 |
+| Codex | `gpt-6.1-terra` | 500,000 / 872,000 |
+| OpenAI API | `openai-apikey/gpt-6.1-terra` | 1,050,000 (128,000 de salida máxima) |
+| OpenRouter | `openrouter/openai/gpt-6.1-terra` | 1,050,000 |
+| Cursor | `cursor/gpt-5.6-sol`, `cursor/gpt-5.6-terra`, `cursor/gpt-5.6-luna` | 1,000,000 |
+
+Las entradas nativas de GPT-5.6 preservan las escalas de razonamiento aguas arriba ancladas (por ejemplo, Luna tiene `max` pero no `ultra`). Las entradas enrutadas usan sus metadatos de proveedor y mapeos de razonamiento. Las cuatro rutas siguen sujetas al filtrado aguas arriba; el descubrimiento en vivo de Cursor además filtra su semilla estática a los modelos que puede usar la cuenta con sesión iniciada.
+
+:::note[Pasarelas y proxies de suscripciones]
+Se incluye un proveedor cuando opencodex tiene un adaptador de cable correspondiente, **no** basado en si es un producto "agente". Los identificadores de adaptador actuales son `openai-chat`, `openai-responses`, `anthropic`, `google`
+(modos AI Studio, Vertex y Antigravity / Cloud Code Assist), `azure` / `azure-openai`, `kiro`, y
+`cursor`. Una API propietaria sin una de estas implementaciones, como Amazon Bedrock nativo, no se admite directamente.
+
+La configuración del proveedor selecciona el adaptador; la selección de transporte aguas arriba es independiente. El tráfico Responses elegible puede usar WSS con [Enrutamiento proxy explícito](/es/reference/proxy-formats/#json-and-sse-output). Los ajustes de proxy WebSocket no válidos o no compatibles vuelven a HTTP/SSE, que usa el [fetch saliente configurado del servidor](/es/reference/configuration/server/). Un proxy SOCKS5 de servidor definido en `config.proxy`, o un `ALL_PROXY` SOCKS5 heredado, usa el túnel incorporado cuando `NO_PROXY` no exime al objetivo. Las variables de proxy HTTP(S) específicas de esquema conservan su manejo nativo independiente; un `ALL_PROXY` que no sea SOCKS no es una ruta nativa de fetch HTTP.
+
+**GitHub Copilot** es un proveedor de OAuth (`ocx login github-copilot`) que canjea un inicio de sesión de GitHub mediante flujo de dispositivo por un token de API de Copilot de corta duración, no por una clave de API pegada. **GitLab Duo** sigue siendo una puerta de enlace de clave/token de suscripción en su punto final compatible con OpenAI. **Cloudflare AI Gateway** necesita que su cuenta y los identificadores de la puerta de enlace se rellenen en la URL.
+
+Copilot usa Auto automáticamente cuando cada fila válida de un catálogo de cuenta no vacío informa explícitamente que la selección manual no está disponible. Los permisos ausentes o mal formados conservan las rutas con nombre; el selector solo elimina las filas denegadas explícitamente. El descubrimiento de solo Auto suministra `github-copilot/auto`, y GitHub selecciona el modelo real en cada solicitud. Esto no cambia los permisos de suscripción. Las listas de permisos de modelos ordinarios, el estado pendiente/deshabilitado y la política de nuevo modelo también se aplican a la visibilidad automática. Si las selecciones guardadas o la directiva ocultan Auto, seleccione o habilite la fila Auto antes de usarla. Las preferencias manuales existentes permanecen guardadas. Un modelo llamado `auto` solo no anula la evidencia de la cuenta.
+
+Auto sigue el protocolo de sesión e intención de la [implementación pública de VS Code Copilot Chat](https://github.com/microsoft/vscode-copilot-chat/blob/7b70532a4cbdfa61c2b30fe4ccffda3d89336a4d/src/platform/endpoint/node/automodeService.ts). Se trata de una integración experimental de cliente, no de un contrato de API de terceros documentado; GitHub puede cambiar el protocolo o los permisos de la cuenta. Auto usa el punto final anunciado del modelo seleccionado en cada solicitud. El enrutamiento por intención envía solo el último texto del usuario, limitado localmente a 32.768 unidades de código UTF-16; la inferencia real conserva la entrada completa. La negociación tiene presupuestos defensivos locales de 512 entradas de catálogo/grupo/candidato, 1 MiB por respuesta correcta y ocho segundos por llamada, incluidos el ritmo y las lecturas del cuerpo. Son salvaguardas de OpenCodex, no límites documentados de GitHub; catálogos de gran tamaño, una negociación lenta o un extracto de intención truncado pueden afectar la compatibilidad.
+
+Para las selecciones con nombre, Copilot ofrece un catálogo de cables mixtos: los siguientes modelos (`gpt-5.3-codex`, `gpt-5.4`,
+`gpt-5.4-mini`, `gpt-5.5`, `gpt-5.6-luna`, `gpt-5.6-sol`, `gpt-5.6-terra`, `gpt-6.1-sol`, `gpt-6.1-terra`, `gpt-6-astra`, `grok-4.5`, `grok-4.6`, `mai-code-1.1-flash`, `mai-code-1-flash-picker`) rechazan
+`/chat/completions` para el tráfico de agentes, por lo que opencodex enruta esos modelos por la API Responses de forma predeterminada e incorporada, mientras que cualquier otro modelo de Copilot permanece en finalizaciones de chat. La precedencia es: fijación de cable obligatoria → su entrada explícita en
+[`modelAdapters`](/es/reference/configuration/providers/) → valor predeterminado del registro → adaptador de todo el proveedor. Para incluir en Responses un modelo sin valor predeterminado incorporado (por ejemplo
+`gpt-5.4-nano`), establezca `"modelAdapters": { "gpt-5.4-nano": "openai-responses" }`.
+
+Cursor se rastrea por separado como un adaptador experimental. `adapter: "cursor"` aparece en `ocx init`
+y el selector Add Provider del panel como una entrada de configuración local experimental con los metadatos estáticos del catálogo de modelos de reserva de Cursor. Cuando hay configurado un token de acceso de Cursor, opencodex usa el transporte HTTP/2 en vivo de Cursor. Establezca `upstreamHttpVersion: "http1.1"` cuando un proxy requiera la ruta de compatibilidad HTTP/1.1 de Cursor; el ajuste cubre tanto la inferencia como el descubrimiento de modelos en vivo y se expone en
+**Proveedores → Cursor → Configuración → Transporte de Cursor**. Su semilla de reserva incluye `gpt-5.6-sol` / `terra` / `luna` (contexto de 1M), filas regulares/Fast para Grok 4.5, 4.6 y 4.7 (500K), y `kimi-k3` (262K); el descubrimiento en vivo decide cuáles siguen visibles para la cuenta. Grok 4.6 y 4.7 exponen `low` / `medium` / `high` / `xhigh` en ambas formas, mientras que 4.5 se detiene en `high`. Las solicitudes Fast de Grok 4.5 y 4.6 envían el modelo base correspondiente con los parámetros separados
+`effort` y `fast=true` de `requested_model`; sus ids aplanados
+`cursor-grok-{version}-{effort}-fast` son solo identidades de descubrimiento y de selector. Grok 4.7 aparece sin el prefijo `cursor-` y envía `grok-4.7-{effort}-fast` directamente. Cursor sirve Kimi K3 solo como ids de protocolo con sufijo de esfuerzo, así que
+`cursor/kimi-k3` expone una escalera `low` / `high` / `max` y usa `max` de forma predeterminada, igualando el valor predeterminado documentado de la API del modelo. La ejecución nativa de lectura/escritura/eliminación/ls/grep/shell/fetch dirigida por el servidor de Cursor está deshabilitada de forma predeterminada porque omite la aprobación de Codex y la ruta del sandbox; establezca
+`unsafeAllowNativeLocalExec: true` en el objeto `providers.cursor` de `~/.opencodex/config.json`
+solo para experimentos locales de confianza (o mediante **Proveedores → Cursor → Editar JSON** en el panel). Las solicitudes de shell nativo en primer plano (`shellArgs` y `shellStreamArgs`) siguen sin estar disponibles en Windows, macOS y Linux incluso con esta opción: opencodex las rechaza antes de iniciar un proceso hasta que tenga un propietario descendiente respaldado por el kernel. Use la herramienta de shell del cliente en su lugar. No se recopila ninguna salida de comandos; los shells en segundo plano y los ejecutores MCP/desktop configurados por separado no cambian. Consulte la [Referencia de configuración](/es/reference/configuration/providers/#cursor-provider-adapter-cursor)
+para ver un ejemplo completo. MCP, la grabación de pantalla y el uso del ordenador están disponibles como ganchos de ejecutor; sin un ejecutor local configurado, opencodex devuelve resultados tipados de "sin ejecutor" en lugar de bloquear la solicitud por una directiva. Cursor OAuth y el descubrimiento de modelos en vivo están habilitados para este adaptador experimental; Cursor todavía no aparece en las listas de inicio de sesión con clave.
+:::
+
+<a id="ollama-cloud"></a>
+
+### Ollama Cloud
+
+Ollama Cloud es un servidor (no local) Ollama. Configure en `https://ollama.com/v1` con una clave de [ollama.com/settings/keys](https://ollama.com/settings/keys). opencodex lo alcanza sobre el propio Ollama REST API ( `POST /api/chat` ) en lugar de la superficie compatible con OpenAI, y descubre la lista de modelos en vivo del proveedor, por lo que los nuevos modelos Ollama Cloud aparecen sin un cambio de configuración. opencodex clasifica su línea de nubes por capacidad de visión, por lo que el [visión sidecar](/es/guides/sidecars/) solo se activa para modelos de solo texto. Los modelos solo de texto (p. `glm-5.2`, `deepseek-v4-flash`, `gpt-oss`, `qwen3-coder`, `minimax-m2.x`, `nemotron-3-*` ) se enumeran en `noVisionModels`; modelos nativos de la visión (por ejemplo. `kimi-k2.6`, `minimax-m3`, `gemma4`, `qwen3.5`, `gemini-3-flash-preview`). El emparejamiento es tolerante a las etiquetas `:size` de Ollama, por lo que `gpt-oss` cubre `gpt-oss:120b` y `gpt-oss:20b`.
+
+Ollama actualmente documenta salidas estructuradas como no compatibles en Ollama Cloud. Para canónica `ollama-cloud`, opencodex por lo tanto rechaza las solicitudes de salida estructuradas (`text.format`) con un error claro en lugar de devolver silenciosamente prosa sin restricciones; los endpoints locales y personalizados `ollama-native` conservan el comportamiento nativo de `format` de Ollama.
+
+<a id="4-local-providers"></a>
+
+## 4. Proveedores locales
+
+Apunte opencodex a un servidor local compatible con OpenAI, normalmente con una clave en blanco:
+
+| Proveedor | URL base |
+| --- | --- |
+| Ollama (local) | `http://localhost:11434/v1` |
+| vLLM | `http://localhost:8000/v1` |
+| LM Studio | `http://localhost:1234/v1` |
+
+<a id="any-openai-compatible-endpoint"></a>
+
+## Cualquier punto final compatible con OpenAI
+
+Si un proveedor habla Chat Completions, el adaptador `openai-chat` lo maneja: elija **Personalizado** en el tablero de instrumentos o `custom` en `ocx init` e ingrese la URL base. Ver el [Referencia de configuración](/es/reference/configuration/) para cada campo de proveedor (`headers`, `noReasoningModels`, `noVisionModels`, `models`,...).
+
+<a id="approval-reviewer-per-provider"></a>
+
+## Revisor de aprobación por proveedor
+
+Codex pide a un segundo modelo que revise las solicitudes de aprobación, y toma ese revisor de `auto_review_model_override` en la fila de catálogo del modelo del turno actual. La raíz `auto_review_model` en `$CODEX_HOME/config.toml` es el respaldo de Codex. La opción global **Anulación de revisión automática** del panel, en la configuración de modelos, aplica un revisor a todas las filas de catálogo que no tengan un revisor con alcance de proveedor. Guarda `autoReviewOverride` en `~/.opencodex/config.json`; el ajuste debe estar habilitado y nombrar un modelo. Un ajuste habilitado sin modelo no se aplica y deja en vigor el respaldo de Codex. La actualización del catálogo es un estado aparte: tras guardar puede quedar pendiente, y la página Modelos lo informa para que pueda reintentarla con `ocx sync`. Desde la CLI, lea el ajuste con `ocx models auto-review status` o cámbielo con `ocx models auto-review set <model|-> [--enabled <on|off>]`; use `-` para borrar el modelo. La salida de la CLI recomienda `ocx sync` cuando se puede reintentar una actualización. Si una actualización falla, el ajuste sigue guardado y el comando sale con 1. Resuelva el fallo antes de sincronizar. Para dar a un proveedor enrutado su propio revisor, normalmente más barato, configure el selector en esa fila de proveedor en `~/.opencodex/config.json`:
+
+```json
+{
+  "providers": {
+    "blsc": {
+      "autoReviewModel": "opencode-go/deepseek-v4-flash",
+      "autoReviewModelOverrides": { "kimi-k3": "gpt-5.6-terra" }
+    }
+  }
+}
+```
+
+`autoReviewModel` cubre todas las filas enrutadas del proveedor. `autoReviewModelOverrides` apunta a un único id de modelo ascendente y gana sobre él. Un valor es un id de modelo desnudo de ese mismo proveedor o un slug de catálogo público como `opencode-go/deepseek-v4-flash`, y un sello de proveedor gana sobre el selector de raíz en sus propias filas mientras que el selector de raíz mantiene la reserva en otro lugar.
+
+Un valor desnudo se resuelve contra las propias filas del proveedor primero y luego contra una fila de catálogo desnuda, que es cómo se nombra un modelo nativo como `gpt-5.6-terra`; un valor que no coincide con ninguno se deja sin resolver, y un valor desnudo que aterriza fuera del proveedor imprime una nota que nombra la fila que suministra el revisor. Dar la identificador completa evita la pregunta por completo cuando el revisor es el modelo enrutado de otro proveedor.
+
+Los selectores se resuelven contra el catálogo final en la siguiente sincronización, cada uno por su cuenta, y cada uno falla cerrado por sí mismo: un `autoReviewModel` no resuelto imprime un diagnóstico y no estampa filas de todo el proveedor, una entrada `autoReviewModelOverrides` no resuelta imprime un diagnóstico y no estampa una anulación por modelo, dejando un objetivo válido de todo el proveedor como reserva. Lo que sea que resuelva se sigue aplicando. Las filas sin un sello de proveedor mantienen el selector raíz o el comportamiento ascendente cuando no se establece. La eliminación del selector raíz deja solos los sellos del proveedor y la eliminación de un selector de proveedor solo borra los sellos de ese proveedor.
+
+Los campos de proveedor están disponibles a través de la configuración, `PATCH /api/providers?name=<provider>`, y el editor de proveedor raw JSON del panel de control; los controles de formulario de proveedor dedicado no están presentes. La anulación global está disponible en la configuración del modelo. El proveedor canónico `openai` rechaza los campos de revisor del proveedor. Las reglas de campo por campo viven en el [referencia de configuración del proveedor](/es/reference/configuration/providers/#auto-review-approval-model-selection).
+
+<a id="rate-limits-in-the-providers-overview"></a>
+
+## Límites de solicitudes en la descripción general de los proveedores
+
+La sección **Límites de solicitudes** de la descripción general de proveedores muestra las barras de utilización en vivo actualizadas desde el punto final de uso/facturación de cada proveedor cuando existe uno. Las barras muestran la cantidad de una ventana (5 horas, semanal, mensual o específica del proveedor) que ya se consume.
+
+Proveedores con una consulta activa: OpenAI/Codex, Anthropic, xAI, Cursor, Kimi, Google Antigravity, OpenCode Go, OpenRouter, DeepSeek, ClinePass, Z.AI, MiniMax, Moonshot, Venice, Synthetic, DeepInfra, Neuralwatt, Command Code y proveedores personalizados basados en a6api o Abliteration.
+
+**Cuota de Kimi Coding Plan.** Los proveedores con inicio de sesión de cuenta o clave API que usan el endpoint canónico `https://api.kimi.com/coding/v1` consultan `/usages`. Los planes que informan `usages.limit_month_total` (o `monthTotal`) muestran una barra de uso mensual; si el total no está disponible, se utiliza `limit_month_code` (o `monthCode`). La fracción `used_ratio` / `usedRatio` debe estar en `[0, 1]` antes de convertirse en porcentaje consumido; los valores inválidos se ignoran. Un contenedor `usages` vacío o inutilizable no oculta datos mensuales válidos de otro sobre compatible. Se conserva cualquier hora de restablecimiento informada. Las ventanas existentes de cinco horas, semanales y de créditos totales de suscripción siguen siendo independientes; una ventana mensual ausente no se muestra como 0%.
+
+**Créditos de Abliteration.** Un proveedor de cualquier nombre cuyo `baseUrl` sea `https://api.abliteration.ai` o `https://api.abliteration.ai/v1` consulta `GET https://api.abliteration.ai/v1/credits` con la clave activa como token bearer, sin seguir redirecciones. El saldo restante en USD es `total_credits` menos `total_usage`; la barra muestra el gasto consumido. Una cuenta sin créditos no muestra barra. Una clave rechazada elimina la fila; `503 credit_balance_unavailable`, 408 y 429 conservan la última lectura.
+
+**Cuota de OpenCode Go.** El preajuste canónico `opencode-go` lee `GET https://opencode.ai/zen/go/v1/usage` con la clave configurada como token de portador y no sigue redirecciones. Los valores `percent` móvil, semanal y mensual de la respuesta ya representan utilización consumida: el móvil se asigna a la barra de 5 horas, mientras que el semanal y el mensual conservan sus barras correspondientes. OpenCodex no reconstruye los límites de dólares de los registros de uso local, y a un proveedor que usa un `baseUrl` no canónico nunca se le envía la clave para esta sonda.
+
+**Cuota del plan de codificación Z.AI GLM.** Los preajustes `zai`, `glm`, `glm-cn` y `zhipu-bigmodel-coding` leen `GET /api/monitor/usage/quota/limit` y no siguen redireccionamientos. La sonda corre contra la región que el proveedor señala en: `api.z.ai` (desnudo o `/api/coding/paas/v4`) o `open.bigmodel.cn` (desnudo, `/api/coding/paas/v4` o el punto final OpenAI Responses `/api/v1`).
+
+La autenticación difiere según la región: `api.z.ai` toma la clave como token Bearer, mientras
+`open.bigmodel.cn` espera la clave directamente en `Authorization`, sin prefijo de esquema, y rechaza un encabezado Bearer. Las filas `limits` de la respuesta rellenan las barras de utilización:
+las filas `TOKENS_LIMIT` / `CREDIT_LIMIT` con `unit` 3 / `number` 5 rellenan la barra de 5 horas y
+las de `unit` 6 / `number` 1 la barra semanal.
+
+Las filas `TIME_LIMIT` **no** son cuota de modelo y se ignoran. Son la asignación mensual compartida de llamadas MCP para Web Search, Web Reader y Zread, así que tratarlas como una ventana de modelo haría que un presupuesto de búsqueda web ya gastado se leyera como capacidad de modelo agotada en la clasificación de cuentas consciente de cuotas. Por eso, un plan que solo informa filas `TIME_LIMIT` no muestra barras de cuota en lugar de una inventada, y las ventanas que el plan no informa permanecen ausentes en vez de mostrarse como 0%.
+
+Nunca se envía la clave para esta sonda a un proveedor que utilice un `baseUrl` no canónico.
+
+<a id="diagnosing-an-antigravity-quota-refresh"></a>
+
+### Diagnosticar una actualización de cuota Antigravity
+
+La vista de cuota de cuenta y `ocx account list google-antigravity --quota --refresh` distinguen entre denegación de acceso, limitación de velocidad, destinos bloqueados o redirecciones, DNS/conexión/tiempos de espera y datos de cuota inutilizables. Las últimas barras conocidas permanecen visibles con su tiempo de observación cuando falla una actualización. La reautenticación retira los diagnósticos de la credencial anterior; una actualización exitosa borra el fallo.
+
+Un resultado denegado por acceso no prueba por sí mismo un inicio de sesión vencido o un plan no elegible. Un destino bloqueado es una decisión de política de red, no una prueba de un defecto de IP falsa. Los destinos de la cuota Canonical Google retienen las restricciones de verificación y redirección/dirección privada de TLS. El comportamiento de TUN autenticado debe comprobarse en el entorno afectado; los accesorios de transporte inyectados solos no establecen ese resultado de campo.
+
+<a id="large-inline-images-on-chat-providers"></a>
+
+## Grandes imágenes en línea en proveedores de chat
+
+Las solicitudes de chat compatibles con la traducción OpenAI reducen las imágenes en línea cuando sus datos base64 combinados superan los 3,5 MiB. Las imágenes más antiguas pierden detalle primero. Este es un presupuesto de imagen de mejor esfuerzo, por lo que el texto grande, los esquemas o las imágenes que no se pueden procesar aún pueden exceder un límite de solicitud ascendente. Las URL de imágenes remotas no se descargan y las imágenes que no se pueden reducir permanecen adjuntas. El passthrough de Native Chat mantiene sus bytes de imagen originales.
+
+
+### Cambios del catálogo y cuotas
+
+Mientras un inicio de sesión esté en curso, **Cuentas** ofrece **Cancelar** al aparecer instrucciones. Las plazas Business Premium `self_serve_business_prolite` pesan cinco unidades Standard en la estimación, según los límites Business oficiales citados en la sección de capacidad, verificados el 20 de octubre de 2026. No cambia selección de cuentas ni crea ventanas que no informe el proveedor. Un grupo OAuth Anthropic activado con dos o más cuentas ofrece estimación equivalente, con igual peso por cuenta; usa últimas lecturas sin consultas extra y señala cobertura incompleta por pausa, reautenticación o datos obsoletos. Con el grupo desactivado o una sola cuenta muestra su lectura individual.
+
+Las configuraciones v1 migran al marcador 2 y una fila compatible con opciones. Se guarda una sola copia `~/.opencodex/config.json.pre-openai-tiers-v2.bak`; `cp ~/.opencodex/config.json.pre-openai-tiers-v2.bak ~/.opencodex/config.json` la restaura.
+
+Ante errores de versión OAuth, consulta [Claude OAuth](/es/guides/claude-code/#claude-oauth-client-version-errors).
+
+Mistral en `https://api.mistral.ai/v1` consulta `/v1/billing/budget` y `/v1/billing/subscription` con la credencial y salida de inferencia para mostrar presupuestos API/Vibe y plan reconocido. Es solo visual: no ordena, enruta ni pausa claves ni entra en Pool. Presupuestos ausentes, mal formados o no positivos, monedas inválidas o porcentajes fuera de rango son desconocidos; no se inventa nivel a partir de una clave ni se muestran planes desconocidos. Conserva lecturas válidas recientes ante 402, 408, 429, 5xx o error de transporte, pero no tras 401, 403 u otros rechazos no reintentables.
+
+
+
+**cheapaimodel** es una pasarela de pago por token para modelos abiertos DeepSeek, GLM y Kimi, y Grok, operada por LINKOVA PTE. LTD. Crea una [clave API](https://console.cheapaimodel.ai/keys) con saldo prepago USD y elige el preajuste en init/dashboard u `ocx provider add cheapaimodel`, con clave o `${CHEAPAIMODEL_API_KEY}`. Usa `https://api.cheapaimodel.ai/v1` y [Chat Completions](https://cheapaimodel.ai/docs/api/create-chat-completion) para todos los clientes, no sus rutas Responses/Messages. Descubre por [`GET /v1/models`](https://cheapaimodel.ai/docs/api/list-models), que devuelve 401 sin clave válida. Incluye `deepseek-v4-1-flash`, predeterminado, `glm-5.3`, `glm-5.3-flash`, `kimi-k3` y `grok-4.7`. GLM 5.3 es solo texto; sus imágenes van al sidecar. Kimi K3 usa muestreo propio y no recibe `temperature` ni `top_p`. Se aplican sus [términos](https://cheapaimodel.ai/terms) y [privacidad](https://cheapaimodel.ai/privacy).
+
+El rechazo HTTP 403 de Meta a una clave Muse Code fuera de su cliente es una restricción del plan sobre una credencial válida, no caducidad ni rechazo de clave. Volver a iniciar sesión no lo soluciona; usa `meta-model` con clave de pago por uso. La protección frente a una respuesta vacía de otros gateways conserva un snapshot con `output_text` agregado; ausente, null o vacío aún permite el reintento acotado. No cambia los demás proveedores ni sus políticas.
+
+Cuando se conoce un total positivo, el resumen de créditos muestra el porcentaje no disponible, incluidos créditos congelados, redondeado a entero, sin avisar agotamiento porque aún pueden funcionar modelos gratuitos. La caducidad de un crédito no se presenta como restablecimiento de todo el saldo.
+
+- Qoder acepta el nombre exacto de cliente o MCP de cada herramienta seleccionada; mismo ID y argumentos bajo cualquiera se entrega una vez. Un nombre desconocido se rechaza. Si el nombre de cliente de una herramienta coincide con el MCP de otra, falla `tool_catalog_invalid` antes de iniciar la CLI: selecciona una o renombra. El cliente ejecuta herramientas.
+- `claude-cli` no guarda una clave: lee el token de inicio local en memoria solo para el endpoint de uso Anthropic, sin persistirlo ni inyectarlo a inferencia. Muestra la última lectura previa a un turno de la cuenta actual, sin lanzar/probar al abrir la página. Actualizar cuotas relee la sesión y observación locales; una cuenta anterior desaparece al actualizar o en un minuto. Una cuenta nueva espera su primer turno.
+- `claude-cli` anuncia texto e imagen; conserva el orden y las imágenes de historial y herramientas a través de la CLI oficial. Rechaza referencias no admitidas, incluido `file_id`, y medios en instrucciones system/developer antes de sidecars. Si se omite historial, también sus imágenes. No necesita sidecar de visión. Migra solo el listado texto intacto de 2.94.0, respetando ajustes. Se verificó con Claude Code 2.1.312 y Fable 5.1; otras combinaciones dependen del proveedor.
+- Las claves configuradas tienen Pausar/Reanudar, también `ocx account pause` y `ocx account resume`. Una pausa excluye del enrutamiento, failover y recuperación; un envío multimedia xAI ya planificado conserva su clave. Otra fila activa de la misma referencia sigue siendo usable. Al pausar la última fila activa de la referencia actual, se elige la siguiente apta en orden circular; todas pausadas devuelve HTTP 403 `permission_error`.
+
+Para modelos Claude alcanzados por el adaptador Chat traducido, OpenCodex aplana `oneOf`, `anyOf` y `allOf` de la raíz del esquema a un objeto. Se determina por el ID real enviado al proveedor cuyo último segmento empieza por `claude-`, sin distinguir mayúsculas, no por todos los modelos de una pasarela. Conserva los required de raíz, combina los de ramas allOf y no promueve los de ramas oneOf/anyOf. Sigue hasta 64 referencias locales de ramas por esquema; si son externas, cíclicas, no resolubles, exceden el límite o apuntan a composiciones, conserva la composición y el proveedor puede rechazarla. Las composiciones anidadas en línea también se conservan si contienen propiedades o referencias sin leer, o exceden 256 entradas inspeccionadas; las que solo anidan restricciones siguen aplanándose. El guard no recorre esquemas de propiedades ni valores literales y preserva referencias anidadas. La conversión pierde restricciones de ramas y las propiedades posteriores prevalecen: las herramientas deben validar argumentos. Se mantienen las reglas de compatibilidad Zen y Azure.
+
+En Kimi con claves API, `https://api.kimi.ai/coding/v1` consulta /usages en ese mismo origen regional; el endpoint canónico `https://api.kimi.com/coding/v1` conserva su consulta /usages. El inicio de sesión de cuenta sigue en `api.kimi.com`.
+
+En cheapaimodel, `glm-5.3` mantiene la declaración de entrada solo texto y `kimi-k3` usa su muestreo propio. Estos contratos se aplican al destino oficial, no automáticamente a una pasarela personalizada.
diff --git a/docs-site/src/content/docs/es/guides/remote-hub.md b/docs-site/src/content/docs/es/guides/remote-hub.md
new file mode 100644
index 00000000000..a728574a4ac
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/remote-hub.md
@@ -0,0 +1,589 @@
+---
+title: "Despliegue de Remote Hub"
+description: "Despliega un Hub opencodex de un puerto en Linux, macOS o Docker, con listener local auxiliar, token de datos, ocx hub invite, administración por loopback, Tailscale Serve y OAuth remoto."
+---
+
+Para enlaces de máquinas SSH, véase [Enlace remoto](/es/guides/remote-link/).
+
+Un Hub de opencodex conserva las credenciales de proveedores y los datos de uso en un equipo, mientras los clientes autenticados acceden a su plano de datos de forma remota. La administración del navegador es independiente: un listener opcional escucha solo en `127.0.0.1`, sirve el dashboard y `/api/*`, y debe situarse detrás de Tailscale Serve u otro frontend HTTPS del operador.
+
+El plano de datos utiliza **un solo puerto**. Los equipos remotos se conectan a `hostname:port` con una clave propia para cada cliente; los procesos del propio Hub usan `127.0.0.1:<the same port>` sin credenciales mediante el listener auxiliar de loopback. Sigue [la receta de configuración](#linux-systemd-or-macos-launchd) y después entrega al otro equipo el comando generado por [`ocx hub invite`](#inviting-another-machine).
+
+La entrada de gestión nunca sirve `/v1/*`, `/healthz` o `/readyz`. Cuando se habilita explícitamente, el espacio de trabajo remoto admite solo su agente WebSocket autenticado por portador emparejado y su intercambio de emparejamiento único; véase [Espacio de trabajo remoto](/es/guides/remote-workspace/). No publique su puerto directamente, no agregue una regla de firewall en la nube para él y no use Tailscale Funnel. Funnel es una superficie de Internet pública y está fuera de este modelo de despliegue.
+
+Con la entrada de administración habilitada, el comando del panel local abre `http://127.0.0.1:<management port>` para que la dirección coincida con el oyente solo IPv4 sin resolver `localhost`.
+
+Las configuraciones del cliente exportadas o aplicadas a través de ese panel de control siguen apuntando al oyente de inferencia, no al puerto de administración. Los clientes locales usan el puerto complementario de bucle de retorno configurado (o el puerto del oyente público real cuando el compañero no tiene un puerto explícito).
+
+<a id="trust-and-consent-boundaries"></a>
+
+## Límites de confianza y consentimiento
+
+- El proveedor y las credenciales OAuth permanecen en el concentrador. Nunca los copie en un cliente, capa de imagen, definición de servicio, paquete de soporte, captura de pantalla o línea de comandos.
+- El token de admisión de datos se entrega a través del archivo `service-api-token` o `OCX_API_TOKEN_FILE`. No es una credencial de gestión.
+- El `allowedModels` de un cliente configurado debe incluir tanto el ejecutor como cualquier modelo de Asesor facturado por separado utilizado por el Anthropic Messages nativo administrado. Se aceptan los ID de modelo desnudo y los `provider/model` nombres configurados del concentrador. Un destino de Asesor no permitido o sin nombre devuelve HTTP 403 antes del envío del proveedor; las claves solo de proveedor y sin restricciones conservan su alcance existente.
+- GitHub Copilot Auto vuelve a comprobar el modelo concreto seleccionado durante la negociación y la renovación. Un modelo fuera del alcance permitido del cliente finaliza la solicitud con `model_not_allowed_for_key` (HTTP 403 antes de la transmisión, o un error de terminal en un flujo ya iniciado). La rotación de credenciales o un objetivo alternativo no pueden anular ese rechazo.
+- Un token de administración sin sesión permite las tareas administrativas ordinarias, pero no crear una sesión de navegador ni autorizar acciones que requieren consentimiento, como dar una estrella al repositorio. Esas acciones exigen una `gui-session` emitida por el servidor, un origen de navegador coincidente y un token CSRF.
+- `Tailscale-User-Login` se confía solo en la entrada de administración por separado. Se ignora el mismo encabezado en el oyente público. `remoteGui.allowedTailscaleUsers` controla la emisión de la sesión; no crea un nuevo principal de propósito general.
+
+<a id="roles-and-direct-data-flow"></a>
+
+## Roles y flujo directo de datos
+
+`standalone` mantiene los datos y la administración en un equipo. Un `hub` conserva las credenciales de proveedores, el catálogo y los registros de uso. Un `client` solo almacena metadatos de conexión y una clave de datos propia. El tráfico Codex y Claude va directamente del cliente al listener de datos del Hub; no pasa por un túnel del dashboard ni por el relé local de administración.
+
+Conecta usando exactamente una fuente de autorización temporal. Se lee desde stdin y no se escribe en la configuración ni en el archivo de token. En el ejemplo, el origen de datos usa HTTPS en 8443 y el de administración usa HTTPS en 443:
+
+```bash
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the one-time code without echoing it or putting it in shell history.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+  --management-url https://hub-name.tailnet-name.ts.net \
+  --pairing-code-stdin
+unset pairing_code
+ocx connect status
+ocx sync
+```
+
+Los diagnósticos de preparación legibles por humanos muestran caracteres de control en valores de catálogo como escapes hexadecimales visibles, tanto cuando se conecta por primera vez como cuando `ocx sync` rechaza un catálogo de concentrador actualizado. El estado estructurado JSON conserva el valor de diagnóstico original.
+
+No tienes que armar esa línea a mano. `ocx hub invite`, se ejecuta en el concentrador, acuña el código e imprime el comando exacto, incluidos ambos orígenes, para la máquina que se está uniendo. Véase [Invitar a otra máquina](#inviting-another-machine).
+
+El Hub emite una clave propia para cada cliente. Este la escribe en el archivo existente `service-api-token`, accesible solo por su propietario, nunca en `config.json`. Mientras está conectado, el uso se consulta en el Hub y se filtra por el identificador estable `apiKeyId` del cliente. Al desconectarse se consulta el almacén local; no se replica el uso entre ambos almacenes.
+
+`ocx service uninstall` elimina el servicio local, pero conserva una clave existente si el cliente está conectado, si sus metadatos son inválidos o no coinciden, o si un marcador de conexión pendiente corresponde a la clave actual. Un marcador válido de una clave anterior no conserva otra clave de servicio ajena a esa conexión. Si el marcador es inseguro, está mal formado o no puede leerse, no se puede verificar la limpieza del token: el comando advierte en lugar de afirmar que conservó la clave. Usa `ocx disconnect` para eliminar la clave y el estado locales de un cliente conectado.
+
+Si un cliente guardó una URL de concentrador remota `http://` antes de la regla de transporte seguro, sus operaciones de concentrador ahora devuelven `insecure_http_refused`. Ejecute el `ocx disconnect` localmente, luego vuelva a conectar al Hub con el `https://` (o use el bucle de retroceso HTTP cuando ambos lados estén en la misma máquina).
+
+Rotar un cliente conectado con una nueva autoridad transitoria:
+
+```bash
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: choose one authority source.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect rotate --pairing-code-stdin
+unset pairing_code
+
+# Alternatively, only over HTTPS, use the management admin token:
+read -r -s -p 'Admin token: ' admin_token; printf '\n'
+printf '%s\n' "$admin_token" | ocx connect rotate --admin-token-stdin
+unset admin_token
+```
+
+La rotación mantiene las claves de datos antiguas y nuevas válidas durante un máximo de diez minutos bajo el mismo `apiKeyId`. El cliente realiza una copia de seguridad del token antiguo como `service-api-token.prev`, instala atómicamente y sondea la nueva clave, luego confirma. Si una respuesta de confirmación es incierta, vuelva a ejecutar el comando rotar con autoridad transitoria; la recuperación prueba ambos archivos antes de confirmar o restaurar. Nunca elimine ninguno de los archivos cuando se informe de recuperación de que ambos candidatos fueron rechazados.
+
+`ocx disconnect` es una operación local y funciona aunque el Hub no esté disponible. Restaura el estado local, pero no revoca la clave en el Hub. Después de desconectar, revócala desde **Conectar → Claves API** en el Hub. `ocx connect revoke --admin-token-stdin` solo está disponible mientras sigas conectado y usa el `apiKeyId` guardado; no admite sustituir ese identificador. Cerrar o caducar la sesión del navegador es independiente de rotar, revocar o desconectar la clave de datos.
+
+<a id="what-a-connected-client-shows"></a>
+
+### Lo que muestra un cliente conectado
+
+`ocx connect` y `ocx connect status` comprueban la disponibilidad del catálogo contra el primer entorno de ejecución local válido de Codex en orden de selección. Los candidatos preferidos fallidos pueden retroceder, pero las alternativas de menor prioridad no se prueban después de que se selecciona un entorno de ejecución válido. Esta comprobación deja la selección de entorno de ejecución guardada sin cambios. General `ocx status` todavía descubre alternativas para el diagnóstico en entorno de ejecución.
+
+Un cliente no almacena credenciales de proveedor y ningún catálogo propio, por lo que su tienda de configuración y credenciales locales están vacías por diseño, y leerlas como la verdad produce una respuesta segura y errónea sobre lo que el concentrador puede servir. En un cliente conectado `ocx status` por lo tanto conduce con `State from hub <origin>` y fuentes las líneas de OAuth - inicios de sesión, proveedores y modelos delegables desde el concentrador sobre el plano de datos, etiquetando las líneas que realmente describen esta máquina `(local)`: el proxy, el servicio, el binario Codex y la shim, y los puertos locales. `ocx status --json` lleva la misma respuesta que `runtimeRole` más un bloque `remoteHub` cuyo `stateSource` es `hub`, `cache` o `unavailable`, nunca el propio estado del cliente. Un concentrador más antiguo que no sirve `/v1/hub-state` informa `unavailable` con una instrucción para actualizar el concentrador en lugar de volver silenciosamente al estado de inicio de sesión local, y `ocx config show` en un cliente imprime una nota `_remoteHub` que indica las credenciales y la disponibilidad del modelo en vivo en el concentrador. La lectura de concentrador utiliza solo la clave de datos por cliente; ningún token de administrador y ningún secreto de proveedor llegan a un cliente.
+
+`ocx status` realiza una solicitud de estado de concentrador en vivo solo cuando la conexión guardada aún coincide con la instantánea de estado y el archivo de token de datos coincide con esa conexión. Si falla la comprobación, se salta la solicitud y muestra el estado del concentrador en caché coincidente, o `unavailable` si no existe caché coincidente.
+
+<a id="linux-systemd-or-macos-launchd"></a>
+
+## Linux con systemd o macOS con launchd
+
+Vincule el oyente de datos a la dirección de Tailscale del concentrador, habilite el compañero de bucle de retorno para que los propios procesos del concentrador lleguen a ese mismo puerto sin una credencial y publique la administración por separado. Los valores siguientes son ejemplos:
+
+:::danger[Usa un servidor dedicado para un solo usuario]
+El listener auxiliar de loopback no exige autenticación. Cualquier proceso o usuario del sistema en ese equipo puede usar las credenciales y cuotas del Hub, y agotar la capacidad compartida de turnos de los clientes remotos autenticados. No lo habilites en un servidor compartido o con varios tenants. En ese caso, conserva `unauthenticatedLoopbackListener` desactivado y no ejecutes las integraciones locales del Hub.
+
+Escuchar en `127.0.0.1` hace que el kernel rechace conexiones remotas, pero no impide que una página visitada provoque conexiones desde tu navegador a `127.0.0.1`. Por eso el listener aplica las mismas comprobaciones de `Host` y `Origin` que un listener ordinario de loopback.
+:::
+
+:::caution[Crea los objetos `hub` y `remoteGui` solo cuando no existan]
+`ocx config set hub '{…}'` y `ocx config set remoteGui '{…}'` sustituyen el objeto completo, así que en
+una instalación existente descartan en silencio los ajustes que ya estaban allí. Compruébalo antes:
+`ocx config get hub` y `ocx config get remoteGui` responden `config path not found` cuando el objeto no
+existe y lo muestran cuando existe. Solo entonces es seguro ejecutar la línea de siembra `'{}'` de abajo;
+si el objeto existe, omítela y usa la forma anidada `hub.<field>`, que a su vez falla con
+`config parent path not found: hub` cuando falta de verdad un padre. Establecer un campo anidado de tipo
+matriz u objeto, como `hub.managementIngress` o `remoteGui.allowedTailscaleUsers`, también sustituye ese
+campo en lugar de fusionarse con él, así que lee el valor actual antes de sobrescribirlo.
+:::
+
+```bash
+ocx config set runtimeRole hub
+ocx config set hostname 100.64.0.10
+ocx config set corsAllowOrigins '["http://localhost:10100"]'
+
+# A fresh standalone config has no `hub` or `remoteGui` object, and `ocx config set` does not
+# create a missing parent: a nested set fails with `config parent path not found: hub`. Setting
+# `runtimeRole` does not create it either. Create each object first, then set its fields.
+ocx config set hub '{}'
+ocx config set remoteGui '{}'
+ocx config set hub.managementPublicOrigin '"https://hub-name.tailnet-name.ts.net"'
+ocx config set hub.dataPublicOrigin '"https://hub-name.tailnet-name.ts.net:8443"'
+ocx config set hub.managementIngress '{"enabled":true,"port":10101}'
+ocx config set remoteGui.allowedTailscaleUsers '["operator@example.com"]'
+
+# One port. Remote machines dial 100.64.0.10:10100 with their own key; the hub's own local
+# processes dial 127.0.0.1:10100 with no credential, on that same port.
+ocx config set unauthenticatedLoopbackListener '{"enabled":true}'
+
+# No token to export: install provisions the hub's own data-plane token. See below.
+ocx service install
+ocx service status
+ocx status                # the "Hub:" block summarizes every line above
+```
+
+En una configuración genuinamente vacía, puede establecer cada objeto en una llamada en su lugar:
+
+```bash
+ocx config set hub '{"managementPublicOrigin":"https://hub-name.tailnet-name.ts.net","dataPublicOrigin":"https://hub-name.tailnet-name.ts.net:8443","managementIngress":{"enabled":true,"port":10101}}'
+ocx config set remoteGui '{"allowedTailscaleUsers":["operator@example.com"]}'
+```
+
+Utiliza esa forma solo cuando el objeto no exista todavía, según decida la comprobación `ocx config get` de arriba. Establecer el objeto entero **sustituye** el objeto en lugar de fusionarse con él, así que ejecutarlo contra una configuración que ya tenía `hub.managementIngress` descarta la entrada en silencio. Cuando estés adaptando una configuración existente, establece un campo a la vez: el padre ya está allí, por lo que la forma anidada funciona y no toca nada más. Establecer un campo anidado de tipo matriz u objeto también sustituye ese campo.
+
+Dos detalles que deciden si se acepta una línea. El valor se analiza primero como JSON y vuelve a la cadena sin procesar, por lo que una URL se escribe como `'"https://…"'`: objetos, matrices, booleanos y números deben ser válidos JSON. Y `hub` y `remoteGui` son estrictos, por lo que una clave mal escrita se rechaza en el momento de la escritura como `schema_invalid: hub.<field>` en lugar de convertirse en una configuración que nunca tiene efecto. `managementPublicOrigin` y `dataPublicOrigin` deben ser cada uno un origen desnudo sin ruta, consulta o fragmento.
+
+<a id="the-data-plane-token-provisions-itself"></a>
+
+### Aprovisionamiento automático del token de datos
+
+No hace falta ejecutar `export OPENCODEX_API_AUTH_TOKEN=…` antes de `ocx service install`. Cuando el servicio escucha fuera de loopback, el instalador resuelve el token de admisión de datos con esta precedencia y lo guarda en `service-api-token`, accesible solo por su propietario y con modo `0600`:
+
+1. **`OPENCODEX_API_AUTH_TOKEN`**, si está exportado en la terminal que ejecuta la instalación. Así se conserva el valor elegido por el operador.
+2. **El archivo existente `service-api-token`.** Reutilizarlo hace que `ocx service install`, `ocx service repair` y los reinicios sean idempotentes: generar otro valor invalidaría las claves por cliente ya intercambiadas con el anterior. El archivo se vuelve a comprobar antes de reutilizarlo; no se confía en él sin validarlo. Véase la comprobación de colisiones con el token de administración más abajo.
+3. **Un token nuevo de 32 bytes aleatorios codificados en hexadecimal.** Esta opción elimina la necesidad de crear el token manualmente.
+
+El comando imprime la **ruta**, nunca el valor. Tanto el plist de launchd como la unidad de usuario de systemd leen ese archivo protegido al iniciar el proceso; ninguno contiene el token literal. No pegues su valor en `ocx config show`, en la salida de la unidad o del plist, en capturas ni en paquetes de soporte. `ocx start` en primer plano también lee ese archivo: puede escuchar fuera de loopback sin que exportes el token.
+
+Se rechaza cualquier token de datos que **coincida con el de administración**, tanto en la variable como en el archivo. El mensaje indica cómo corregir cada origen. Si la colisión está en `OPENCODEX_API_AUTH_TOKEN`, ejecuta `unset OPENCODEX_API_AUTH_TOKEN` y vuelve a iniciar. Si está en el archivo reutilizado `service-api-token`, elimina ese archivo y después ejecuta `ocx service repair`; quitar una variable no corrige el archivo. Ambas comprobaciones se ejecutan antes de omitir los requisitos de admisión por tratarse de loopback, de modo que también protegen una instalación local. El wrapper de arranque exporta el archivo como `OPENCODEX_API_AUTH_TOKEN` independientemente del hostname; una colisión impediría iniciar la API de administración.
+
+Los dos planos usan credenciales diferentes. El token de datos admite llamadas a `/v1/*` y no permite administrar el proxy. Como el servicio aprovisiona su propio token, no hace falta exportar ninguno de los dos. Una vez que existe el archivo, `ocx service repair` no vuelve a exigir la variable de entorno.
+
+`ocx status` muestra el estado del token sin revelar su valor: `present (file)`, `unsafe (file)` si los permisos no son exclusivos del propietario, `admin-collision (file)` si coincide con el token de administración, o `missing`. En caso de colisión también explica la consecuencia y la corrección. Este estado describe siempre el **archivo**, porque el wrapper sobrescribe el entorno antes de ejecutar el proceso. Una línea aparte indica si la terminal tiene `OPENCODEX_API_AUTH_TOKEN` establecido, que es el valor que usaría un `ocx start` en primer plano desde esa terminal.
+
+<a id="one-port-and-the-ported-alternative"></a>
+
+### Un puerto y la alternativa con puerto separado
+
+`unauthenticatedLoopbackListener: {"enabled": true}` con **no** `port` es la forma *compañero*: un segundo zócalo en `127.0.0.1:<proxy port>` - el mismo número de puerto que el oyente público utiliza en la dirección tailnet. Esa es la dirección que ya escribe cada integración local, por lo que no se debe enseñar nada en el concentrador a un nuevo puerto, y un puerto mantiene toda la superficie de datos remota.
+
+El formulario complementario se acepta solo cuando `hostname` es una dirección específica no loopback, no comodín. En `127.0.0.1`, `localhost`, `0.0.0.0` o `::` el oyente público ya tiene esa dirección de bucle, por lo que opencodex rechaza el par en el momento de la escritura y nuevamente en el inicio, nombrando la colisión, en lugar de dejar que el segundo enlace falle. En esos enlaces no necesitas al oyente en absoluto: un enlace de bucle de retorno ya admite llamadas locales.
+
+La forma más antigua *ported* todavía funciona y es la alternativa cuando desea que las dos superficies en puertos separados:
+
+```bash
+ocx config set unauthenticatedLoopbackListener '{"enabled":true,"port":10104}'
+```
+
+La forma portada es la misma superficie no autenticada: la advertencia de host dedicado anterior también se aplica a este comando.
+
+Con un `port` definido, las integraciones locales siguen al oyente y escriben `http://127.0.0.1:10104` en su lugar. El puerto debe ser distinto del puerto del proxy y nunca lo asigna el sistema operativo: un puerto efímero cambiaría entre reinicios mientras los servidores de aplicaciones ya en marcha conservarían el `base_url` anterior.
+
+**Reinicie el proxy tras cambiar este campo.** Los sockets se enlazan una sola vez al arrancar y los archivos de cliente local se escriben con el valor resuelto, así que un hub en ejecución conserva su respuesta antigua. En un hub con puerto, esa es la diferencia entre que `ocx claude` llegue al oyente o reciba un `404` de él. En un servicio en segundo plano el verbo es `ocx service restart`, que siempre reinicia; consulte [operaciones del servicio en macOS](#macos-service-operations). `ocx restart` es otro verbo: reinicia el proceso del proxy que usted mismo inició, no el servicio que supervisa el gestor.
+
+<a id="the-hubs-own-local-clients"></a>
+
+### Los propios clientes locales del hub
+
+Un concentrador solía ser la única máquina que no podía usarse a sí misma: `ocx claude`, Claude Desktop, Cursor, la inyección `system-env` y el asistente de visión enrutado, todos marcan `http://127.0.0.1:<port>`, que no existe cuando el oyente está vinculado a una dirección de red Tailscale. Con el oyente de loopback habilitado, trabajan en el concentrador:
+
+```bash
+ocx sync          # the hub now writes its own Codex/Grok blocks
+ocx claude        # Claude Code wired to the hub's own loopback address
+```
+
+El oyente solo lleva cables de inferencia: `POST /v1/responses` y su actualización WebSocket, `POST /v1/responses/compact`, `POST /v1/messages`, `POST /v1/chat/completions`, `POST /v1/alpha/search`, `GET /v1/models` y la superficie de voz en tiempo real. `POST /v1/messages/count_tokens` se admite deliberadamente **no**, por lo que Claude Code vuelve a la estimación de token local: una pérdida cosmética, no un lanzamiento roto. `/api/*`, `/healthz`, `/readyz` y el tablero de instrumentos todos devuelven `404` allí: lecturas de administración local como la llamada de descubrimiento de `ocx claude` van a la superficie de administración autenticada con una credencial de administración, nunca a un socket no autenticado. Es por eso que la entrada de la gerencia y este oyente siguen siendo dos cosas diferentes.
+
+Con el oyente **desactivado**, un concentrador deliberadamente no reescribe sus propias configuraciones de cliente, y cada salto nombra la puerta que lo detuvo:
+
+```text
+This machine is a hub; it does not rewrite its own Codex/Grok/Claude configs unless
+unauthenticatedLoopbackListener is enabled.
+```
+
+Esa frase significa la puerta del concentrador, no su conmutador `clientIntegrations`. `ocx ensure` deja un bloque gestionado existente Grok en su lugar cuando está cerrado en lugar de despojarlo, y `ocx restore back` informa de la puerta en lugar de culpar a un escritor competidor.
+
+<a id="acceptance-on-the-data-plane"></a>
+
+### Aceptación en el plano de datos
+
+Demostrar vivacidad y disposición en el oyente de datos públicos:
+
+```bash
+curl --fail --silent http://100.64.0.10:10100/healthz
+curl --fail --silent http://100.64.0.10:10100/readyz
+```
+
+Un `200` de `/healthz` solo demuestra que el proceso está vivo. La aceptación de implementación también requiere `/readyz`, una autenticación `GET /v1/catalog` y una respuesta real enrutada.
+
+<a id="tailscale-serve"></a>
+
+## Tailscale Serve
+
+Primero prueba que el socket de administración es solo loopback, luego publícalo a través de Serve:
+
+```bash
+ss -ltnp | grep 10101        # Linux: expected 127.0.0.1:10101 only
+lsof -nP -iTCP:10101 -sTCP:LISTEN  # macOS: expected 127.0.0.1 only
+
+tailscale serve --bg --https=443 http://127.0.0.1:10101
+tailscale serve status
+```
+
+Establecer `hub.managementPublicOrigin` al origen exacto HTTPS mostrado por Serve. Agregue el inicio de sesión de Tailscale exacto del operador a `remoteGui.allowedTailscaleUsers`; una lista vacía significa que ninguna identidad remota puede acuñar una sesión. Verifique ambas direcciones:
+
+```bash
+# Negative: the loopback-only port must not be reachable through the node's tailnet address.
+curl --fail --connect-timeout 3 http://100.64.0.10:10101/ && echo "unexpected exposure"
+
+# Transport only: an identity-required dashboard may reject curl; verify it in an allowed user's browser.
+curl --fail --silent --show-error https://hub-name.tailnet-name.ts.net/ >/dev/null
+```
+
+La prueba de navegador positiva debe usar una sesión Tailscale con inicio de sesión real; un `curl` desnudo puede no llevar los encabezados de identidad necesarios para la emisión automática de la sesión. El emparejamiento sigue siendo la alternativa cuando el frontend HTTPS no puede proporcionar una identidad de Tailscale confiable.
+
+<a id="giving-the-data-listener-tls"></a>
+
+### Proteger con TLS el listener de datos
+
+El mapa Serve de arriba publica solo la entrada **gestión**. Ese ingreso nunca sirve `/v1/*`, `/healthz` o `/readyz`, por lo que por sí solo no le da a un cliente remoto un plano de datos utilizable. opencodex también termina no TLS de su propio: el oyente es llano HTTP y HTTPS es siempre un frontend poseído por el operador.
+
+Servir puede ser ese frontend para el plano de datos también, en un segundo puerto HTTPS. En macOS necesita un salto extra, porque Tailscale Serve proxies solo a `127.0.0.1` - no puede apuntar al oyente que enlaza a la propia dirección tailnet del nodo, y la compilación de App Store del cliente macOS rechaza un destino remoto por completo. Ejecutar un reenviador de bucle en el concentrador y apuntar Servir en eso:
+
+```bash
+# Any loopback TCP forwarder works; socat is one. Pick a port the hub is not already using:
+# with the loopback companion enabled, 127.0.0.1:10100 belongs to opencodex itself.
+socat TCP-LISTEN:10110,bind=127.0.0.1,fork,reuseaddr TCP:100.64.0.10:10100 &
+
+tailscale serve --bg --https=8443 http://127.0.0.1:10110
+tailscale serve status   # expect both mappings: 443 -> 10101, 8443 -> 10110
+```
+
+**No apuntes Serve al listener auxiliar de loopback.** Existe un socket real en `127.0.0.1:10100`, pero el mapeo fallaría después de crearse: el auxiliar aplica la admisión de loopback y exige un `Host` local, mientras Serve reenvía `Host: hub-name.tailnet-name.ts.net`. El auxiliar sirve a los procesos del propio Hub, que sí envían un `Host` local. El reenviador debe llegar al listener vinculado a la dirección de Tailscale, cuya autenticación y manejo de `Host` son los adecuados para el frontend TLS.
+
+Servir acepta un conjunto limitado de puertos HTTPS; confirmar que el mapeo fue creado con `tailscale serve status` en lugar de asumir que el puerto estaba permitido.
+
+Dar al promotor la misma vida útil que el hub. Un trabajo de shell en segundo plano muere en el reinicio mientras que el El servicio vuelve a aparecer, lo que deja un concentrador que se ejecuta e inalcanzable sobre TLS; ejecútelo desde `launchd` o `systemd` junto `ocx service install`.
+
+Luego conéctese con los dos orígenes establecidos por separado. El URL posicional es el origen **datos** - es donde `/readyz` y `/v1/catalog` son buscados - y `--management-url` es el origen del tablero de instrumentos utilizado para el emparejamiento y la emisión de claves. No tienen que compartir un puerto:
+
+```bash
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the one-time code without echoing it or putting it in shell history.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+  --management-url https://hub-name.tailnet-name.ts.net \
+  --pairing-code-stdin
+unset pairing_code
+```
+
+Registre esos dos orígenes en el centro como `hub.dataPublicOrigin` y `hub.managementPublicOrigin`, y `ocx hub invite` los imprimirá para usted en lugar de pedirle que los recuerde.
+
+Cuando se omite `--management-url`, se toma de la respuesta `/readyz`, que informa `hub.managementPublicOrigin`. Establecerlo explícitamente es más claro cuando los dos orígenes difieren.
+
+**No evites el reenviador vinculando el listener de datos a `127.0.0.1`.** OpenCodex interpreta ese enlace como una instalación puramente local: deja de exigir la credencial de datos y exige que el `Host` también sea local. El frontend TLS reenvía `Host: hub-name.tailnet-name.ts.net`; por eso `/v1/catalog` responde `403 origin_rejected`, aunque `/readyz`, que no aplica esa comprobación, devuelva `200`. Puede parecer que el despliegue está sano sin poder servir un modelo. La ruta de solicitudes no lee `X-Forwarded-Host`, así que el frontend no puede corregirlo con esa cabecera. Mantén el listener en la dirección de Tailscale, donde se exige la credencial de datos y no se aplica esa comprobación de `Host`.
+
+Esa trampa es sobre el **enlace**, y sigue siendo cierto. Obtener un conector `127.0.0.1` en un concentrador para los propios procesos del concentrador es un problema diferente, y [`unauthenticatedLoopbackListener`](#one-port-and-the-ported-alternative) es la respuesta sancionada: el enlace público permanece en la dirección de la red Tailscale con la admisión activada, y un segundo conector sirve a las personas que llaman locales. No es un objetivo TLS, por la razón dada anteriormente.
+
+La vinculación `0.0.0.0` también funciona y elimina la necesidad de un promotor, ya que el oyente es entonces accesible en loopback también. Publica el puerto de datos en cada interfaz, por lo que lo prefiere solo dondel host no tiene otra red que le importe, y tenga en cuenta que la forma complementaria de `unauthenticatedLoopbackListener` se rechaza en un enlace comodín, porque el oyente público ya tiene `127.0.0.1:<port>` allí.
+
+Vuelva a ejecutar las comprobaciones de aceptación contra el origen de datos HTTPS una vez que Serve esté activo: `/readyz`, un `GET /v1/catalog` autenticado y una respuesta enrutada real.
+
+<a id="operator-owned-tsnet-certificate-proxy"></a>
+
+### Proxy de certificado ts.net propiedad del operador
+
+Si opera su propio proxy TLS, obtenga un certificado solo para el FQDN completo de ts.net:
+
+```bash
+tailscale cert hub-name.tailnet-name.ts.net
+```
+
+Protege la clave privada, renueva el certificado mediante el mecanismo admitido por Tailscale y reenvía únicamente a `127.0.0.1:10101`. Un proxy TLS genérico no aporta una identidad Tailscale confiable. No inventes cabeceras `Tailscale-User-*`; utiliza el emparejamiento de un solo uso vinculado al origen.
+
+<a id="inviting-another-machine"></a>
+
+## Invitar a otra máquina
+
+Ejecute esto en el concentrador en lugar de escribir una línea `ocx connect` a mano:
+
+```bash
+ocx hub invite
+```
+
+Crea un código de emparejamiento de un solo uso y de corta duración e imprime el comando para ejecutarlo en la otra máquina. Para mantener el código fuera del historial del shell, léelo sin mostrarlo y pásalo por stdin:
+
+```bash
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash, on the other machine:
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect https://hub-name.tailnet-name.ts.net:8443 --management-url https://hub-name.tailnet-name.ts.net --pairing-code-stdin
+unset pairing_code
+```
+
+El origen de los datos proviene de `--data-url`, luego `hub.dataPublicOrigin`, luego la dirección de enlace. Ese último recurso solo funciona cuando el enlace **es** una dirección que otra máquina puede marcar: en un enlace de loopback o comodín se resolvería con `http://localhost:<port>`, que le dice a la otra máquina que se marque a sí misma y gasta el código de un solo uso por nada, por lo que `invite` se niega e imprime la línea `ocx config set hub.dataPublicOrigin` (más el formulario `--data-url` por invitación). Un `--data-url` o `hub.dataPublicOrigin` explícito nunca se cuestiona en segundo lugar: un origen de datos de bucle de retorno es legítimo sobre un túnel SSH.
+
+El origen de gestión es `hub.managementPublicOrigin`, y en `invite` el indicador `--management-url` es un **confirmación, no una anulación**: la concesión está vinculada al origen configurado y el intercambio se compara con él, por lo que se rechaza un valor que difiere con ambos orígenes nombrados en lugar de imprimir un código que el concentrador rechazaría.
+
+Cada invitación exitosa también imprime el **origen del navegador vinculado** en stderr. Una concesión está vinculada a un origen, y un remoto `ocx connect` presenta `Origin: http://localhost:<its own configured port>`, por lo que si el origen vinculado no es el predeterminado `http://localhost:10100`, la otra máquina ya tiene que estar funcionando en ese puerto antes de que ejecute la línea, de lo contrario el concentrador rechaza el intercambio y el código se gasta. La nota dice qué puerto, y ofrece admitir el origen predeterminado en su lugar.
+
+`invite` rechaza *antes* acuñando cualquier cosa cuando la configuración no puede funcionar: un `runtimeRole` que no es `hub`, un `hub.managementPublicOrigin` faltante, un origen de gestión sin bucle de retorno de texto plano, un `--data-url` mal formado, un origen de datos que sería el propio bucle de retorno de esta máquina, o ningún proxy certificado en ejecución. Una condición previa merece su propio párrafo.
+
+**`corsAllowOrigins` tiene que nombrar el origen del navegador local de la máquina de unión.** `ocx connect` envía `Origin: http://localhost:<its own proxy port>` cuando intercambia la concesión, y las concesiones están vinculadas al origen, por lo que solo el propio `hub.managementPublicOrigin` o una entrada de bucle de `corsAllowOrigins` pueden coincidir. Sin ninguno presente, `invite` sale con un código distinto de cero, no acuña nada y nombra el comando exacto:
+
+```bash
+ocx config set corsAllowOrigins '["http://localhost:10100"]'
+```
+
+Usa el puerto en el que escucha el proxy de la máquina que **se conecta**; `10100` es el predeterminado. El bloque anterior ya lo establece. Asignar `corsAllowOrigins` reemplaza toda la lista. Si el Hub ya tiene entradas, ejecuta el comando completo que imprime `ocx hub invite`: conserva las existentes y añade el nuevo origen. `ocx config get corsAllowOrigins` muestra el valor actual.
+
+`ocx hub invite --json` emite `{ code, expiresAt, dataUrl, managementUrl, command }` con `expiresAt` como ISO 8601. El código es un secreto: de un solo uso, cinco minutos de vida útil, tasa limitada en el concentrador, y no debe ser persistente, registrado o pegado en un problema. `--clients codex,claude` elige qué cliente configura el comando impreso apuntará al concentrador.
+
+`invite` es una conveniencia sobre el flujo de emparejamiento existente, no un segundo mecanismo. Conduce la misma ruta local certificada que usa `ocx gui pair`, por lo que no necesita un token de administración y no tiene que exportarse a su shell. Todo en [Roles y flujo directo de datos](#roles-and-direct-data-flow) sobre rotación, revocación y desconexión se aplica sin cambios a una máquina que se unió de esta manera.
+
+<a id="macos-service-operations"></a>
+
+## Operaciones de servicio macOS
+
+`ocx service install` y `ocx service repair` se pueden volver a ejecutar en un hub activo. La reparación genera primero el plist y lo compara con el guardado. Si ambos son idénticos, el archivo de token no ha cambiado y `launchctl print` confirma que el job está cargado desde ese plist, se restablecen los permisos `0600`, se actualiza el estado de instalación y se muestra `service is already loaded from the current plist; nothing to do.`. En ese caso no se modifica launchd. Las versiones anteriores descargaban incondicionalmente un job sano, convirtiendo un comando de diagnóstico en una interrupción del servicio.
+
+**`ocx service restart` siempre solicita un reinicio.** Ya no es un alias de `repair`. Ejecuta la misma actualización y, si no hubo que recargar nada porque el job está sano y sin cambios, lo reinicia con `launchctl kickstart -k`. Después vuelve a consultar `launchctl print` para confirmar que el job sigue cargado y muestra:
+
+```bash
+ocx service restart
+# ℹ️  service restarted (launchctl kickstart -k gui/501/com.opencodex.proxy).
+```
+
+Usa ese comando después de cambiar `unauthenticatedLoopbackListener`, `hostname` o `port`. El reinicio con kickstart no descarga previamente el job, por lo que evita la ventana sin registro que provocaba la reparación incondicional antigua.
+
+`ocx service`, sin subcomando, sigue eligiendo `repair`, no `restart`: actualiza la instalación de forma idempotente y no solicita reiniciar un hub sano. Usa `ocx service repair` para corregir un job cargado desde un plist anterior o que ya no está cargado. Si está sano, no lo reiniciará.
+
+También siguen funcionando `launchctl kickstart -k gui/$(id -u)/com.opencodex.proxy` y la secuencia `ocx service stop` seguida de `ocx service start`. El mensaje de error ofrece el primero como alternativa, pero la vía recomendada es `ocx service restart`.
+
+En Linux y Windows no existía esta diferencia: `ocx service restart` usa respectivamente `systemctl --user restart` y la detención seguida del inicio de la tarea programada, según lo solicitado.
+
+`ocx service status` distingue cuatro launchd estados, y el último es el que la gente malinterpretó:
+
+| Resumen | Descripción |
+| --- | --- |
+| `installed and loaded` | Un dominio responde y ejecuta el comando definido en el plist actual. Estado normal. |
+| `installed and loaded from an OLDER plist` | El job se ejecuta con una definición anterior. `ocx service repair` la actualiza. |
+| `installed, not loaded` | Todos los dominios respondieron que el job está ausente. La reparación vuelve a registrarlo. |
+| `installed; launchd state could not be verified` | No se pudo consultar `launchctl`, por ejemplo por falta de acceso al dominio `gui/<uid>`. Esto **no demuestra** que el hub esté caído: no se recomienda reparar por ese motivo ni se marca como muerto un proxy que sigue activo. |
+
+Antes, una consulta que no se podía ejecutar se presentaba como «no cargado». Eso podía llevar a reparar un servicio sano y hacer que el actualizador iniciara otro proxy en el puerto que ya utilizaba el servicio.
+
+<a id="headless-oauth"></a>
+
+## OAuth sin navegador
+
+Deshabilitar el inicio del navegador en el concentrador:
+
+```bash
+ocx config set oauthOpenBrowser false
+```
+
+1. Desde el panel de control remoto autenticado o el cliente de administración, inicie `POST /api/oauth/login` para el proveedor. El concentrador devuelve la URL de autorización y las instrucciones sin abrir un navegador.
+2. Abra la URL en la máquina del operador y autorice allí.
+3. Si la devolución de llamada no puede llegar al concentrador, pegue la URL o el código de redirección final en el panel de control/ CLI. Envía `POST /api/oauth/login/code` con `{provider,input}`.
+4. Sondear el punto final de estado existente hasta que se complete y, a continuación, realizar una solicitud de modelo enrutado.
+
+Nunca ponga el código OAuth en argv de shell, registros, texto de emisión, capturas de pantalla o evidencia de implementación. La ruta de código manual mantiene sus comprobaciones de entrada existentes de proveedor desconocido, flujo no activo, código no válido y 4096 bytes.
+
+## Docker Compose
+
+opencodex no publica una imagen de contenedor oficial. El repositorio mantiene un código fuente-construido [`Dockerfile`](https://github.com/lidge-jun/opencodex/blob/dev/Dockerfile), [`compose.yaml`](https://github.com/lidge-jun/opencodex/blob/dev/compose.yaml), y un estrecho `.dockerignore`. La compilación fija el índice de imagen multiplataforma Bun 1.4.4 por compendio, ejecuta el proxy como el usuario no raíz `bun`, mantiene el sistema de archivos raíz de solo lectura, elimina las capacidades Linux y publica solo el oyente de datos en el `127.0.0.1:10100` del host de forma predeterminada. El proceso en primer plano utiliza `OCX_SERVICE=1`, por lo que detener o recrear el contenedor conserva el estado Codex enrutado en lugar de restaurar una configuración de escritorio nativa. Docker proporciona supervisión; no hay ningún administrador de servicios del sistema operativo instalado en la imagen. Use Compose para reiniciar/recrear el contenedor; esto no extiende el soporte a todas las rutas de reinicio del panel.
+
+La imagen siembra una configuración `hub` de primera ejecución que une el oyente de contenedor a `0.0.0.0`. Antes del primer inicio normal, transmita un token de plano de datos recién generado al ayudante de arranque. El ayudante acepta como máximo una línea de 4096 bytes, nunca imprime el token, se niega a reemplazar un token existente y lo persiste como el propietario canónico `service-api-token` en el volumen `ocx-state`.
+
+El despliegue persiste dos hogares separados: `ocx-state` en `/home/bun/.opencodex` para la configuración OpenCodex, las credenciales del proveedor y el uso, y `codex-state` en `/home/bun/.codex` para el estado Codex y `opencodex-catalog.json`. La imagen y Compose establecen explícitamente `CODEX_HOME=/home/bun/.codex`, por lo que esta ruta del catálogo sigue siendo escribible con `read_only: true` y sobrevive a la recreación de contenedores. La imagen crea ambos directorios para el usuario no raíz `bun` con el modo `0700`; la propiedad del volumen existente y los permisos no se migran automáticamente.
+
+No combine `CODEX_HOME` y `OPENCODEX_HOME`: ambos productos utilizan un nombre de archivo `auth.json` con diferentes formatos. Este cambio de empaque agrega persistencia, no un generador de catálogo. Materialice o importe un catálogo válido en `/home/bun/.codex/opencodex-catalog.json` antes de la verificación de aceptación del catálogo a continuación; sin uno, `catalog_not_found` sigue siendo la respuesta esperada.
+
+La actualización conserva el volumen `ocx-state` existente y agrega `codex-state`; no se migran archivos automáticamente. Si una solución anterior colocó un catálogo directamente debajo de `/home/bun/.opencodex`, respalde y copie deliberadamente solo el catálogo a la nueva casa Codex, preservando el acceso solo para el propietario. No copie el `auth.json` de ninguno de los productos sobre el otro. Las implementaciones con un `CODEX_HOME` personalizado deben conservar su entorno explícito y la asignación de volumen grabable hasta que se complete la migración. Al anular `CODEX_HOME`, monte ese directorio exacto y persista el catálogo predeterminado en `${CODEX_HOME}/opencodex-catalog.json`. Si `model_catalog_json` selecciona explícitamente otro archivo, esa ruta de acceso resuelta también debe persistir.
+
+Los volúmenes con nombre anteriores conservan los directorios predeterminados de configuración de opencodex y de estado de Codex. Si eliges otras rutas para el catálogo o para SQLite, debes darles persistencia por separado; esos volúmenes no conservan automáticamente las rutas no predeterminadas.
+
+Cuando se ejecute sin Compose, proporcione explícitamente ambos montajes con nombre. Solo las declaraciones Dockerfile `VOLUME` crean volúmenes anónimos que un `docker run` posterior no reutiliza automáticamente. Estas opciones de montaje utilizan nombres de ejemplo independientes; para reutilizar los datos de Compose, sustituya los nombres de volumen predefinidos para el proyecto:
+
+```sh
+--mount type=volume,src=ocx-state,dst=/home/bun/.opencodex \
+--mount type=volume,src=codex-state,dst=/home/bun/.codex
+```
+
+El host necesita Git y Docker Compose para un clon local, o solo Docker Compose para un contexto Git remoto. No se necesita Bun en el host ni una etapa de preparación manual. La etapa de manifiesto de solo compilación deriva el inventario canónico de la instantánea Git seleccionada, escribe el `src/generated/compatibility-version.json` sin seguimiento y verifica cada SHA-256 registrado contra el contexto de compilación de solo lectura antes de que las instrucciones de origen `COPY` puedan desreferenciar un enlace simbólico. Los archivos de entorno de ejecución copiados se verifican nuevamente dentro de la imagen. Los metadatos de Git se admiten solo para ese montaje de enlace; no `COPY` coloca `.git` en una capa de imagen, y el ejecutable de Git permanece confinado a la etapa de manifiesto.
+
+"Git metadata" aquí significa dos archivos. El inventario canónico proviene de `git ls-files`, que lee el índice y nunca abre un objeto o una referencia, por lo que el contexto de compilación admite solo `.git/index` y `.git/HEAD`, aproximadamente 1 MB, en lugar del almacén de objetos completo del repositorio. La etapa de manifiesto los copia en un directorio Git de cero que posee y suministra los directorios vacíos `objects/` y `refs/` que requiere la verificación del repositorio de Git. Un contexto sin un manifiesto ni un índice Git falla la compilación con un mensaje que nombra ambas entradas compatibles; nunca vuelve a un marcador de posición.
+
+Un manifiesto generado por el host existente sigue siendo compatible: la compilación lo verifica y lo usa en lugar de reemplazarlo silenciosamente. Los archivos que faltan o no coinciden, los archivos de origen adicionales ausentes del manifiesto y los enlaces simbólicos (incluidos los directorios principales) fallan la compilación. El inventario requiere `package.json`, `bun.lock` y `scripts/model-metadata.source.json`; el propio manifiesto generado es el único archivo fuente exento del inventario. No lo cometas ni lo edites a mano.
+
+```bash
+git clone https://github.com/lidge-jun/opencodex.git
+cd opencodex
+docker compose build
+openssl rand -hex 32 | docker compose run --rm -T hub bun run docker/bootstrap-token.ts
+docker compose up -d
+```
+
+Para un contexto Git remoto, establezca el argumento integrado BuildKit que conserva los metadatos de Git. Por ejemplo, reemplace el bloque de compilación del servicio con:
+
+```yaml
+services:
+  hub:
+    pull_policy: build
+    build:
+      context: https://github.com/lidge-jun/opencodex.git#dev
+      dockerfile: Dockerfile
+      target: runtime
+      args:
+        BUILDKIT_CONTEXT_KEEP_GIT_DIR: "1"
+```
+
+Establezca un puerto host alternativo sin cambiar el oyente `10100` fijo del contenedor:
+
+```bash
+OPENCODEX_PORT=10190 docker compose up -d
+```
+
+El acceso remoto es una opción explícita. Configure `OPENCODEX_BIND_ADDRESS` en la LAN o la IP de Tailscale del host, o use `0.0.0.0` para publicar en las interfaces de host **todos**:
+
+```bash
+OPENCODEX_PORT=10190 OPENCODEX_BIND_ADDRESS=0.0.0.0 docker compose up -d
+```
+
+Utiliza un firewall y un frontend TLS /tailnet autenticado antes de exponer el puerto. La anulación de enlace cambia solo la publicación del host; el oyente del contenedor sigue siendo `0.0.0.0:10100`. Cada una de estas variables se aplica solo al comando que la lleva, así que mantén ambas anulaciones en cada invocación posterior de Compose que recree el concentrador —o persístelas en el entorno de Compose— para que el servicio recreado no vuelva al puerto predeterminado. Para actualizar una implementación existente, ejecute `docker compose build` y vuelva a crear el concentrador con `docker compose up -d`; no repita la inicialización de token de una sola vez.
+
+Configure los proveedores con el panel de control a través de un frontend de administración propiedad del operador o con comandos CLI de un solo disparo que comparten el volumen de estado. Los siguientes comandos distinguen la inicialización de una instalación nueva de las actualizaciones posteriores de campos. Sustituye los orígenes y la identidad del ejemplo antes de habilitarlos:
+
+**Solo para un volumen nuevo:** la configuración inicial declara runtimeRole=hub, pero no contiene los objetos `hub` ni `remoteGui`. El bootstrap del token tampoco los crea. Las escrituras completas siguientes **reemplazan** esos objetos: no las ejecutes en un volumen configurado, porque podrían borrar `hub.managementIngress` u otros ajustes guardados. Sustituye los dos orígenes y la identidad del ejemplo; el origen CORS usa el puerto del proxy local del equipo que se conectará.
+
+```bash
+docker compose run --rm hub bun run src/cli/index.ts config set hub '{"managementPublicOrigin":"https://hub-name.tailnet-name.ts.net","dataPublicOrigin":"https://hub-name.tailnet-name.ts.net:8443","managementIngress":{"enabled":true,"port":10101}}'
+docker compose run --rm hub bun run src/cli/index.ts config set remoteGui '{"allowedTailscaleUsers":["operator@example.com"]}'
+docker compose run --rm hub bun run src/cli/index.ts config set corsAllowOrigins '["http://localhost:10100"]'
+docker compose restart hub
+```
+
+En un volumen ya configurado, inspecciona primero los objetos guardados y actualiza únicamente los campos que quieras cambiar. Las escrituras anidadas conservan los campos hermanos; la lista de usuarios permitidos reemplaza esa lista, así que incluye todas las identidades que deban conservarse. Si falta un objeto, usa el inicializador solo para ese objeto ausente. Si ya existe una lista CORS, conserva sus entradas y añade el origen del equipo que se conectará como explica [Invitar a otra máquina](#inviting-another-machine).
+
+```bash
+docker compose run --rm hub bun run src/cli/index.ts config set hub.managementPublicOrigin '"https://hub-name.tailnet-name.ts.net"'
+docker compose run --rm hub bun run src/cli/index.ts config set hub.managementIngress '{"enabled":true,"port":10101}'
+docker compose run --rm hub bun run src/cli/index.ts config set remoteGui.allowedTailscaleUsers '["operator@example.com"]'
+docker compose restart hub
+```
+
+El oyente del contenedor se une a `0.0.0.0`, por lo que ya es accesible en la propia dirección de bucle del contenedor y la forma complementaria de `unauthenticatedLoopbackListener` no se aplica allí, se rechaza en un enlace comodín. El bootstrap del token descrito antes es el contenedor equivalente al propio paso de aprovisionamiento del servicio, y también se ejecuta una vez.
+
+No incluyas tokens en `ARG`, `ENV`, `COPY`, el YAML de Compose, el historial de imágenes ni los argumentos de comandos. No montes el socket de Docker, los directorios personales del host o de Codex, el agente SSH ni los archivos de claves de proveedores. La entrada de administración vinculada a `127.0.0.1:10101` dentro del contenedor solo es accesible mediante un frontend TLS o de tailnet situado en el mismo espacio de nombres de red; nunca publiques `10101` como atajo de acceso.
+
+Cuando el contenedor esté sano, comprueba por separado si está listo para atender solicitudes:
+
+```bash
+docker compose exec hub bun -e \
+  "const r=await fetch('http://127.0.0.1:10100/readyz');console.log(r.status,await r.text());if(!r.ok)process.exit(1)"
+
+docker compose exec hub bun -e \
+  "const t=(await Bun.file('/home/bun/.opencodex/service-api-token').text()).trim();const r=await fetch('http://127.0.0.1:10100/v1/catalog',{headers:{'x-opencodex-api-key':t}});console.log(r.status);if(!r.ok)process.exit(1)"
+```
+
+A continuación, realiza una solicitud enrutada autenticada real con un modelo configurado. Si falta el secreto o no puede leerse, un Hub que escucha fuera de loopback no debe considerarse listo. Que el proceso esté activo no basta para demostrar que puede atender solicitudes.
+
+`docker compose down --volumes` elimina los volúmenes, incluida la configuración, las credenciales OAuth, el historial de uso, el token del plano de datos y el estado persistente de Codex. Usa `docker compose down` sin `--volumes` para conservar esos datos.
+
+CI multiplataforma construye la imagen de origen y comprueba el inicio, la admisión de tokens de plano de datos y la recreación de contenedores utilizando un proyecto de Compose aislado con credenciales desechables. Verifica que tanto los volúmenes con nombre como un catálogo sintético sobrevivan al reemplazo. Esta comprobación no valida una cuenta de proveedor real, devolución de llamada OAuth, migración de montaje personalizada o cada arquitectura de CPU; realice la comprobación de respuesta enrutada autenticada anterior para su implementación.
+
+<a id="rollback"></a>
+
+## Reversión
+
+Inspeccione las asignaciones de servicio existentes antes de cambiarlas. `tailscale serve reset` elimina todas las asignaciones en el nodo; use un comando de eliminación compatible más estrecho cuando existan asignaciones no relacionadas.
+
+```bash
+tailscale serve status
+tailscale serve reset
+ocx config set hub.managementIngress '{"enabled":false}'
+ocx service restart
+```
+
+Para una reversión de contenedor, conserve tanto los volúmenes de estado con nombre como sus asignaciones. Una imagen anterior todavía puede usar `CODEX_HOME=/home/bun/.codex` cuando ese directorio permanece montado; no vuelva a un archivo de composición anterior que elimine el montaje Codex. No fusione las casas ni vuelva a ejecutar el token bootstrap. Para una reversión del servicio, detenga el servicio de la sucursal y repare la versión anterior contra el mismo `OPENCODEX_HOME`. Deshabilitar la entrada de administración o Servir no requiere cambiar el oyente de datos.
+
+<a id="troubleshooting"></a>
+
+## Solución de problemas
+
+- **Hub abajo:** `ocx connect status` todavía muestra la conexión guardada. `ocx disconnect` puede restaurar el estado local sin conexión; no puede revocar la clave remota.
+- **Catálogo Stale:** `ocx sync` mantiene un último catálogo válido solo para fallos transitorios del concentrador. Las fallas de autenticación, esquema, tamaño y protocolo son errores difíciles y nunca vuelven a los proveedores locales.
+- **Token giratorio o recuperación `.prev`:** vuelve a ejecutar `ocx connect rotate` con un código de emparejamiento o token de administración. No edite ni elimine ninguno de los candidatos de token antes de que finalice la sonda de recuperación.
+- **Desajuste de protocolo:** actualizar el lado más antiguo nombrado por el mensaje `hub-too-new` o `hub-too-old`. La negociación falla antes de que el token, el catálogo, el diario o el estado del cliente escriban.
+- **Código de emparejamiento perdido o quemado:** ejecutar `ocx hub invite` de nuevo. Las concesiones son de un solo uso y los fallos repetidos son de velocidad limitada sin revelar si existe un código.
+- **`ocx hub invite` dice `No loopback browser origin is admitted for pairing`:** el concentrador no admite el origen del navegador de bucle de retroceso, por lo que una concesión vinculada al origen nunca podría igualar. Nada fue acuñado. Ejecuta el comando completo `ocx config set corsAllowOrigins` que imprime el error: conserva los orígenes existentes y añade el del puerto del proxy de la máquina que se conecta. Véase [Invitar a otra máquina](#inviting-another-machine).
+- **`ocx hub invite` dice que el origen de los datos anunciados sería el propio bucle de retorno de esta máquina:** el bind es solo loopback o un comodín y `hub.dataPublicOrigin` no está definido, por lo que no hay dirección para anunciar y nada adivina una red Tailscale o LAN. Nada fue acuñado. Establecer `hub.dataPublicOrigin`, o pase `--data-url` para esta invitación solamente.
+- **El intercambio del equipo que se conecta se rechaza y consume el código:** la autorización estaba vinculada a otro origen. Revisa la línea `Bound browser origin:` de la invitación: indica el puerto que debe usar el otro equipo o propone admitir `http://localhost:10100` en el Hub.
+- **`ocx hub invite` rechaza un `--management-url`:** en un concentrador ese indicador confirma `hub.managementPublicOrigin` en lugar de anularlo, porque la concesión está vinculada al valor configurado. Cambie la configuración o suelte la bandera.
+- **`ocx claude` en el concentrador se inicia de forma nativa Codex / Claude, o el concentrador se niega a escribir sus propias configuraciones de cliente:** `unauthenticatedLoopbackListener` está desactivado. El mensaje de omisión nombra la puerta. Habilite el oyente y reinicie el proxy (`ocx service restart` en una instalación de servicio).
+- **`ocx claude` en el concentrador obtiene `404` del oyente:** el proxy sigue siendo el proceso que comenzó antes de que existieran los cables del oyente, o antes de que el puerto cambiara. Reinicie con `ocx service restart` - ver [macOS operaciones de servicio](#macos-service-operations).
+- **`ocx service repair` muestra `nothing to do` sin reiniciar el proceso (macOS):** es lo esperado. Reparar un job sano no cambia nada deliberadamente. Para reiniciarlo, usa `ocx service restart`: reinicia el job cargado y muestra `service restarted (launchctl kickstart -k …)`. Solo si falla, usa como alternativa manual `launchctl kickstart -k gui/$(id -u)/com.opencodex.proxy`, tal como indica el error.
+- **`ocx service install` rechaza `OPENCODEX_API_AUTH_TOKEN`:** ese valor es un token de administrador de administración. `unset OPENCODEX_API_AUTH_TOKEN` y reejecutar; el servicio proporciona su propio token de plano de datos. Véase [El propio token del plano de datos](#the-data-plane-token-provisions-itself).
+- **El Hub rechaza el arranque y `ocx status` muestra `admin-collision (file)`:** `service-api-token` contiene el token de administración, por lo que OpenCodex mantiene cerrada su API de administración. Elimina ese archivo y ejecuta `ocx service repair` para aprovisionar un token de datos. Eliminar la variable de entorno no corrige una colisión cuyo origen es el archivo.
+- El emparejamiento de **Plain HTTP se negó:** sobre HTTP no loopback se rechaza completamente, y no hay ninguna bandera que opte por salirse de él. Ponga el origen de la administración detrás de HTTPS o pare sobre loopback. Los tokens de administrador nunca se envían por encima de HTTP.
+- **`403 origin_rejected` de `/v1/catalog` mientras que `/readyz` devuelve `200`:** el listener de datos está vinculado a loopback detrás de un frontend TLS. Véase [Dar al oyente de datos TLS](#giving-the-data-listener-tls).
+- **Finalizó la sesión remota:** Iniciar sesión o emparejar de nuevo. El cierre de sesión y la expiración invalidan solo la sesión del navegador, no una clave de datos del cliente.
+- **Revocación excepcional después de la desconexión:** usa la página **Conectar → Claves API** del panel de control central. Es el único camino de revocación posterior a la desconexión.
+
+<a id="usage-from-a-connected-client"></a>
+
+### Uso desde un cliente conectado
+
+`ocx usage` lee el concentrador conectado con la clave de datos registrada de este cliente. La salida humana identifica la fuente del concentrador y el alcance de la clave del cliente; `--json` devuelve los mismos datos de alcance. Los filtros de rango, superficie, proveedor / modelo y los límites personalizados `--since` / `--until` permanecen disponibles. Los desgloses de cuentas y los registros de otros clientes no se comparten. Un concentrador antiguo o no disponible produce un error explícito en lugar de sustituir el uso local; actualice el concentrador si no admite esta lectura.
+
+El endpoint de datos de solo lectura es `GET /v1/usage`. Usa `x-opencodex-api-key` con una clave de cliente configurada; se rechazan las claves globales del entorno y las de administración. Acepta `range`, `surface`, `provider`, `model`, `since` y `until`. Rechaza opciones desconocidas o repetidas e identificadores de clave elegidos por quien hace la solicitud. Las filas demasiado grandes que se omiten conservan el aviso explícito de historial incompleto.
+
+Las credenciales de uso del cliente se envían solo por HTTPS o loopback HTTP. Tanto la solicitud como la respuesta deshabilitan el almacenamiento en caché.
+
+<a id="pairing-this-browser-with-a-hub"></a>
+
+### Emparejar este navegador con un hub
+
+La inscripción de la máquina y la autenticación del navegador son independientes. El panel de emparejamiento nombra el concentrador y muestra un comando `ocx gui pair --origin` para el origen exacto abierto actualmente en su navegador. Ejecute ese comando en el concentrador o envíelo al operador del concentrador y solicite un código de emparejamiento único. Pegue ese código en el panel; una clave de datos API o un token de administración no es un código de emparejamiento.
+
+Mientras la autenticación del navegador está pendiente, el panel de control no recomienda reiniciar un cliente conectado saludable. Completar el emparejamiento actualiza los datos del panel de control de inmediato, incluido un error de autenticación previamente almacenado en caché. La expiración de la sesión vuelve al emparejamiento; la denegación de permiso mantiene su propia guía de configuración de acceso. Otras actualizaciones fallidas pueden mostrar los últimos datos recibidos con un aviso de datos obsoletos y una acción de reintento.
+
+Si se ha intercambiado el código pero la validación de Remote Link no está disponible temporalmente, mantenga la página abierta y use **Reintentar validación**. Esto comprueba la sesión pendiente del navegador sin gastar otro código de emparejamiento. Las respuestas a los desafíos de Cloudflare también mantienen la sesión pendiente para reintentar. Emparejar solicitudes de intercambio y validación cada vez después de 10 segundos, incluida la lectura del cuerpo de la respuesta, para que el formulario vuelva a ser utilizable. Un tiempo de espera de validación mantiene la sesión instalada pendiente para **Reintentar validación**; una respuesta de intercambio que llega después de su tiempo de espera no puede instalar credenciales. Si el concentrador rechaza definitivamente la sesión con HTTP 401 o 403, el panel de control restaura la sesión del navegador anterior solo mientras el traspaso aún posee el estado de sesión actual y no se ha reemplazado por un inicio de sesión, cierre de sesión o cambio de destino más reciente; solicite al operador del concentrador un código nuevo para este origen del navegador. Un intercambio de emparejamiento captura la revisión actual de la sesión y el objetivo antes de enviar el código; las respuestas retrasadas no pueden reemplazar una sesión después de que cambie la revisión. El arranque automático de descubrimiento y la recuperación de fondo siguen la misma regla, incluyendo cambiar los objetivos de ida y vuelta; ninguno anula el cierre de sesión. El cierre de sesión pendiente y completado suprime la recuperación automática hasta que cambie un nuevo inicio de sesión explícito o un nuevo objetivo. Un tiempo de espera de recuperación informa de una sesión no disponible solo si su solicitud sigue siendo actual, no cancelada y sin credenciales; los resultados de arranque tardío se descartan.
+
+Si un oyente auxiliar no puede enlazar, los nombres de inicio `unauthenticatedLoopbackListener` o `hub.managementIngress` y la dirección real. Corregir ese oyente o liberar su dirección; cambiar solo el puerto proxy público no repara un puerto auxiliar fijo. Los bloques de escucha mal formados editados a mano advierten y permanecen desactivados mientras se conservan las configuraciones no relacionadas.
+
+<a id="return-a-hub-to-standalone"></a>
+
+## Devolver un Hub al modo independiente
+
+Ejecuta `ocx hub disable [--json]` en el concentrador para eliminar `hub`, `unauthenticatedLoopbackListener`, `runtimeRole` y `hostname` juntos en una escritura validada. La configuración del proveedor, el puerto y las claves API guardadas se conservan. Se rechaza una configuración de cliente o independiente sin cambios.
+
+Las claves no llevan un origen de inscripción verificado y los nombres son editables. Para revocar las claves de cliente, primero inspeccione los ID con `ocx access key list --json` y, a continuación, seleccione explícitamente cada ID:
+
+```sh
+ocx hub disable --revoke-clients --client-key <client-key-id> --json
+```
+
+Repita `--client-key` para varios clientes. Con las claves guardadas presentes, `--revoke-clients` sin ID seleccionados se niega antes de cambiar la configuración. Las identificaciones desconocidas también se niegan. Solo se eliminan las teclas seleccionadas y sus rotaciones pendientes; la salida contiene metadatos seguros en lugar de secretos. El comando imprime el paso de reinicio para el supervisor detectado; no reinicia el proxy. Revisión `tailscale serve status` y otros frontends externos para asignaciones a puertos hub antiguos. La configuración y revocación persistentes se aplican al proxy en ejecución después del reinicio; Los registros de enlace remoto y los túneles permanecen sin cambios.
+
+<a id="remember-and-service-recovery"></a>
+
+### Recordar el dispositivo y recuperar el servicio
+
+**Recordar este dispositivo** funciona en `hub.managementPublicOrigin` porque el listener de administración es la entrada de confianza del Hub. Una instancia independiente detrás de un proxy que termina TLS necesita `dashboardTrustedProxy`; un Hub ignora ese ajuste. Consulta [Recordar detrás de un proxy inverso](/es/guides/web-dashboard/#remember-behind-a-reverse-proxy).
+
+`invite` lee el origen del archivo, pero el Hub en ejecución valida contra su configuración de inicio. Después de cambiar `hub.managementPublicOrigin` o `corsAllowOrigins`, reinicia antes de invitar. `ocx config set` recuerda el reinicio para esas claves y `hub.managementIngress`.
+
+En macOS, `launchctl bootout` regresa antes de terminar el proceso y `launchctl print` puede indicar que el trabajo ya no existe mientras aquel drena. Un reinicio inmediato podría producir `Bootstrap failed: 5`. La recuperación espera entre un número acotado de intentos: tras `launchctl bootout gui/$(id -u)/com.opencodex.proxy`, una llamada a `ocx service restart` o `ocx service repair` recupera el trabajo. Si el cierre nunca termina, devuelve el diagnóstico en lugar de esperar indefinidamente.
+
+<a id="restarts-after-an-unclean-exit"></a>
+
+### Reinicios después de un cierre inesperado
+
+El contenedor ejecuta el proxy como PID 1. Una caída, OOM o fallo del nodo puede dejar `ocx.pid` y `runtime-port.json` con ese PID. El siguiente inicio solo recupera automáticamente un registro de una ejecución anterior del mismo contenedor cuando la versión registró su entorno: un reinicio dentro del mismo pod sin reiniciar el nodo, o el mismo contenedor Docker/Podman reiniciado —incluido `docker restart`, una política de reinicio o un reinicio del host— con un identificador aleatorio de capa escribible, como Docker `overlay2` y Podman. El almacén de imágenes containerd de Docker numera las capas, por lo que ese caso se rechaza.
+
+Los demás casos fallan con `Proxy ownership is unverified; startup refused`: un pod de reemplazo, un contenedor Compose recreado, el regreso de un pod tras reiniciar el nodo, otro nodo o un registro de una versión anterior. Confirma primero que ningún proceso siga sirviendo ese directorio y después aparta una sola vez los dos archivos de propiedad para reiniciar. Mantén un único escritor por volumen: un `Deployment` compartido debe usar `strategy: Recreate` o `maxSurge: 0`. No compartas estado entre procesos en un mismo espacio de red, sidecars, distribuciones WSL, clones de una instantánea de VM ni equipos con el mismo nombre. En Compose, `volume-nocopy` evita que Docker rellene un volumen vacío con el estado incluido en la imagen.
+
+- Si `ocx hub invite` informa `Minting a pairing code failed (origin-refused)`, reinicia con el comando que imprime el error y vuelve a invitar: el origen permitido en memoria puede preceder a un cambio reciente. `(rate-limited)` indica el límite de ocho códigos por minuto o de códigos sin usar; espera a que se usen o caduquen a los cinco minutos. `(rejected)` es otro rechazo.
diff --git a/docs-site/src/content/docs/es/guides/remote-link.md b/docs-site/src/content/docs/es/guides/remote-link.md
new file mode 100644
index 00000000000..8d9feb9ec35
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/remote-link.md
@@ -0,0 +1,420 @@
+---
+title: "Enlace remoto"
+description: "Conecte una computadora OpenCodex Home a una computadora Child a través de SSH."
+---
+
+Un enlace de máquina conecta un ordenador **Home** OpenCodex a un ordenador **Child** a través de SSH. El Home sirve al Child a través del túnel SSH, mientras que ambos ordenadores mantienen su servicio local OpenCodex en el puerto `10100`. El panel de control transfiere la clave de enlace por hijo a través de SSH, por lo que no escribe un token.
+
+<a id="requirements"></a>
+
+## Necesidades
+
+- El ordenador Home puede iniciar sesión en el Child con una clave OpenSSH.
+- Para un enlace iniciado en Child, el Child puede iniciar sesión en Home con una clave OpenSSH (no se admite el inicio de sesión con contraseña).
+- OpenCodex 2.66.0 o posterior está instalado en el ordenador Child, y en Home para un enlace iniciado Child.
+- Ambos equipos ejecutan macOS, Linux o Windows x64. Windows requiere OpenSSH Server y Windows PowerShell; no necesita Git Bash ni curl.
+- El panel de control que agrega un Child de Home se abre en el propio Home o a través de una sesión Hub emparejada. Convertir el equipo actual en un Child requiere una sesión de panel de control emparejada con el operador; una sesión de panel de control local sin credenciales no puede confirmar ese cambio de enrutamiento.
+
+No se admite SSH con contraseña. Los enlaces pueden iniciarse desde Home o Child. En Windows, la ejecución usa PowerShell sobre la misma conexión OpenSSH con identidad fijada.
+
+<a id="add-a-child-from-remote"></a>
+
+## Añadir un Child de `#remote`
+
+1. Abra el panel de control en `#remote` y activar el enlace remoto.
+2. Elija **Home**, luego **Continuar**. Se abre la lista de hosts SSH.
+3. Elija un host de los candidatos SSH o introduzca un alias de configuración SSH.
+4. Ejecute la prueba de conexión y compare la huella dactilar del host ofrecida con la huella dactilar de la máquina que desea utilizar. Compararlo ayuda a detectar un host incorrecto o una clave de host cambiada antes de que SSH confíe en el host.
+5. Confirme la huella digital y luego conecte el Child.
+
+El panel de control no te pide que ingreses un token. Primero sondea el host y no puede aplicar el enlace hasta que confirme explícitamente la huella digital.
+
+La hoja Add Child explica que el Child utiliza los proveedores de este Home sobre SSH y enumera los requisitos previos anteriores. Los alias de host provienen de `~/.ssh/config` en el Home que ejecuta OpenCodex, no necesariamente el ordenador que muestra el navegador. Si el descubrimiento tiene éxito sin hosts, agregue una entrada `Host` como esta, luego elija **Rescan hosts**. También puede introducir un alias existente manualmente; seleccionar o introducir un alias habilita **Conexión de prueba**. La hoja enlaza con esta guía.
+
+El descubrimiento también sigue las directivas `Include` de nivel superior. Los paréntesis y las llaves
+de los nombres incluidos siguen siendo literales al combinarse con comodines. Por ejemplo,
+`Include conf.d/*(1).conf` encuentra `backup(1).conf`, y `Include conf.d/shard-{1..3}-*.conf` busca
+nombres que contengan `{1..3}`. Un `Include` dentro de `Host` o `Match` es condicional y no se usa
+para descubrir hosts.
+
+```sshconfig
+Host devbox
+  HostName devbox.example.com
+  User you
+  IdentityFile ~/.ssh/id_ed25519
+```
+
+Si falla el descubrimiento, la hoja muestra **No se pudo cargar los hosts SSH**, la razón de la solicitud disponible y **Reintentar**, en lugar de reclamar que la lista de host está vacía. Un fallo en la prueba de conexión mantiene su razón específica y la pista SSH desinfectada en la hoja activa, no duplicada detrás de ella. Compruebe la razón, utilice el diagnóstico SSH en Solución de problemas a continuación cuando sea relevante, y vuelva a intentarlo. El rescanning mantiene el alias ingresado pero requiere una nueva revisión de huellas dactilares antes de conectarse.
+
+<a id="connect-this-computer-as-a-child"></a>
+
+## Conecte este equipo como un Child
+
+En el equipo que debe utilizar los proveedores de Home:
+
+1. Abra el panel de control en `#remote` y activar el enlace remoto.
+2. Elija **Child**. Se abre la lista de hosts SSH.
+3. Elija el host SSH del Home, ejecute la prueba de conexión, luego compare y confirme su huella digital del host.
+4. Lea el aviso y elija **Conectar como Child**.
+
+La conexión se reinicia OpenCodex en este equipo. Codex turnos que ya se están ejecutando terminan primero, y las nuevas solicitudes pueden fallar hasta por un minuto mientras se reinicia. El tablero de instrumentos se recarga por sí mismo y muestra el enlace Child. Codex sigue usando `http://127.0.0.1:<port>/v1` en este equipo, sin token y sin variable de entorno para establecer: el local OpenCodex retransmite cada solicitud al Home, que le sirve con sus propios proveedores y cuentas.
+
+El Child espera su puerto configurado mientras el proceso anterior lo libera. Si aún falla un reinicio administrado CLI, ejecute `ocx start` en el Child y verifique `~/.opencodex/restart-handoff.log`. En la aplicación de escritorio, la aplicación inicia y supervisa el reemplazo automáticamente.
+
+Un `ocx stop` explícito en un Child de Remote Link detiene su proxy y, si se completa la restauración compartida, restaura el enrutamiento nativo de Codex, su catálogo y los metadatos respaldados del historial de reanudación, y elimina la configuración administrada de Grok. La conexión guardada con Home se conserva; usa `ocx disconnect` para eliminarla.
+
+Si una conexión al hub toma el control durante la parada, se conservan su enrutamiento y su configuración. Una conexión que aún se esté creando o desconectando puede impedir la restauración; deja que termine esa operación y reintenta `ocx stop`. La API de parada del dashboard devuelve HTTP 409 con `sharedTeardown: "refused"` cuando no puede confirmar quién tiene el control y mantiene el listener en ejecución. La limpieza por señal también conserva la configuración cuando no se puede confirmar ese control.
+
+Para volver a usar Home desde Codex después de la restauración, inicia el Child con `ocx start` (o `ocx service start` si hay un servicio instalado) y ejecuta después `ocx sync --restart-codex`. Iniciar el entorno de ejecución no vuelve a aplicar el enrutamiento de Codex del Child. Sync reaplica los ajustes de Codex cuando Codex está habilitado para la conexión guardada, y la opción reinicia Codex para cargarlos; no recrea el bloque de Grok. Este es el flujo explícito de parada e inicio de un Link Child; no cambian el control del cliente de hub ni las reglas independientes de reinicio, reciclado, salida del servicio e instancias hermanas.
+
+Si el **Child** dice emparejar esta máquina primero, abra el panel de control HTTP de loopback literal configurado de este equipo, por ejemplo, `http://127.0.0.1:<configured-port>`. El formulario de emparejamiento local aparece solo cuando falta el emparejamiento y el panel de control y el API usan el mismo origen de bucle invertido. Copie el comando `ocx gui pair --origin "http://127.0.0.1:<configured-port>"` del formulario, ejecútelo en un terminal en este equipo y pegue el código de un solo uso en el formulario. Use el origen exacto que se muestra en el formulario; una clave o token de administrador API del proveedor no es un código de emparejamiento. El emparejamiento faltante es independiente de un desajuste de puerto configurado.
+
+En un panel de Hub abierto a través de una dirección que no sea de loopback, es posible que el navegador no tenga sesión de loopback o que tenga una sesión compartida que no pueda administrar los enlaces de la máquina. Cuando Remote Link informe de ese problema de sesión o permiso, seleccione **Conecte este panel al concentrador** en la página Enlace remoto para abrir el formulario de emparejamiento único. Ejecute el comando mostrado en el Hub e introduzca su código. La página valida el acceso de enlace remoto de la nueva sesión antes de que cierre el formulario.
+
+El rol **Child** también requiere un entorno de ejecución independiente OpenCodex que se ejecuta en su puerto configurado, porque el Child se reinicia exactamente en ese puerto. Si el panel de control dice que OpenCodex no se está ejecutando en su puerto configurado, reinicie allí primero.
+
+<a id="link-status"></a>
+
+## Estado del enlace
+
+- **Conectado** significa que el túnel SSH está listo y el Child puede usar el enlace Home.
+- **Reconexión** significa que el túnel está siendo reintentado. Las solicitudes pueden devolver temporalmente `503` con `Retry-After` mientras el reintento está en curso. En un Child que se conectó desde su propio tablero de instrumentos, una solicitud primero espera hasta 15 segundos para que regrese el túnel.
+- **Fallido** significa que el enlace necesita atención. Revisa la autenticación SSH, la clave de host confirmada, el reenvío y el motivo que muestra el dashboard. Quien ejecuta el túnel sigue reintentando tras una suspensión, interrupción o reinicio: Home para un Child que añadió y Child para un enlace iniciado desde su propio dashboard. Tras un timeout o error de reenvío, el Home reintenta cada minuto un Child que añadió, de modo que un portátil que estuvo suspendido se reconecta aproximadamente un minuto después de despertar; un Child que se unió desde su propio dashboard reintenta tras un minuto y duplica la espera después de cada reintento que vuelve a fallar, hasta cinco minutos. Los errores de autenticación se reintentan cada cinco minutos en ambos lados; una clave de host cambiada nunca se reintenta. Para forzar otro intento, elige **Reintentar** en el dashboard del Home o ejecuta allí `ocx link reconnect --link-id <id>`. Esto reinicia el túnel del enlace, sin reiniciar OpenCodex.
+
+Un enlace fallido no cambia silenciosamente a un proveedor local. Si el túnel ya falló, está detenido o no está supervisado antes de iniciar el reenvío, el Child devuelve un `503` reintentable sin enviar la clave de enlace ni la solicitud. Un fallo posterior al inicio del reenvío es distinto: el Home puede haber recibido o procesado la solicitud; comprueba ese resultado incierto antes de reintentar. También mantiene la clave local cuando otro proceso posee el puerto del túnel; libre ese puerto para que el túnel SSH del Child pueda enlazarlo.
+
+En un Child, `GET /healthz` solo indica que OpenCodex se está ejecutando. `GET /readyz` y `ocx ready` también comprueban si el enlace puede transportar una solicitud. Si no puede, la respuesta es `503` con `Retry-After: 1`, `"status": "pending"` y un objeto `link`, por ejemplo `{ "state": "unavailable", "reason": "home_unreachable" }`. Si puede, responde `200`, `"status": "ready"` y `{ "state": "available" }`. Los motivos posibles son `tunnel_connecting`, `tunnel_failed`, `tunnel_idle`, `tunnel_unavailable`, `sidecar_invalid`, `home_unreachable`, `home_unauthorized`, `link_auth_failed`, `link_credential_unavailable` y `link_unverified`. Un Child enlazado desde su propio dashboard consulta su túnel. Si el Home añadió el Child, este no tiene un túnel propio que inspeccionar: consulta al Home por el túnel con la misma comprobación sin credenciales que precede a cada solicitud reenviada, como máximo una vez cada cinco segundos. Si el Home no responde en medio segundo, informa `link_unverified`.
+
+Para confirmar qué Home atiende a un Child, compara el encabezado `x-opencodex-served-by` de `GET /v1/models` del Child con `instanceId` de `GET /healthz` del Home. El Child retransmite el encabezado sin cambios, por lo que los valores coinciden mientras el enlace funciona. Es un identificador opaco, nunca un nombre de equipo; consulta [Identidad del Home y encabezado served-by](/es/reference/management-api/#home-identity-and-the-served-by-header).
+
+<a id="several-routes-to-one-child"></a>
+
+## Varias rutas a un Child
+
+Un Child añadido desde Home puede alcanzarse por varias rutas SSH, por ejemplo un alias directo en la misma LAN o tailnet y un alias de relay accesible desde cualquier lugar. Home mantiene una lista ordenada y se conecta por la primera ruta que funciona: el tráfico usa la ruta directa si está disponible al conectar y, en caso contrario, el relay.
+
+```text
+ocx link routes --link-id <id>
+ocx link routes add --link-id <id> --route <alias> [--position <n>]
+ocx link routes remove --link-id <id> --route <alias>
+ocx link routes order --link-id <id> --routes <alias,alias,...>
+```
+
+- **Todas las rutas llegan al mismo equipo.** El alias del enlace fija la clave: su clave de host confirmada es la única que puede presentar cualquier ruta y permanece en la lista. Antes de guardar una ruta con `ocx link routes add`, Home conecta con comprobación estricta de esa clave. Si presenta otra clave, rechaza el inicio de sesión o no responde, no se guarda (`route_unproven` con causa `hostkey`, `auth`, `forward` o `transient`). También se rechaza si el archivo privado `known_hosts` del enlace confía en otra clave para el alias (`pin_mismatch`, `trust_file_unexpected`). Al añadir un Child se comprueba el mismo archivo: una línea con comodín, lista de hosts o marcador, que OpenCodex nunca escribe, provoca `trust_file_unexpected`; elimina esa línea y vuelve a probar y confirmar el host. Las líneas hash son válidas: versiones anteriores a 2.89 las registraban cuando SSH las configuraba, y cada una cuenta para el alias correspondiente. Puede haber varias si todas tienen la clave del enlace. Confirmar otra clave para un alias ya usado por un enlace iniciado en Home se rechaza con `link_pin_conflict`; para confiar en un equipo sustituido, elimina y vuelve a añadir el enlace. Si el cambio se guarda pero los túneles activos no lo recargan, el comando devuelve `routes_stored_reload_failed`; el cambio se conserva y reiniciar OpenCodex en Home lo aplica.
+- **Orden.** Una ruta nueva va antes del alias salvo que se indique `--position`, para que las rutas directas precedan al alias de relay.
+- **Elección.** En cada conexión Home sondea las rutas en orden y concede 10 segundos a cada sondeo inicial. Si el sondeo tiene éxito, Home inicia un túnel candidato con hasta 30 segundos para que sshd del Child conceda el listener remoto y otros 30 segundos para comprobar que está listo. Una ruta solo funciona cuando el Child obtiene el catálogo de Home a través de ese túnel con su clave de enlace; hasta entonces aparece **Connecting**. Una ruta fallida espera unos segundos tras un error de red, un minuto tras un rechazo de reenvío, cinco tras un fallo de autenticación o diez tras una clave incorrecta; Home pasa a la siguiente. El enlace falla por clave de host solo si todas presentan una clave incorrecta.
+- **Túnel obsoleto.** Si Home se detuvo sin detener el ssh del enlace, este muestra **failed** y «stale tunnel may hold the port» hasta que termine ese ssh; detenlo (su pid está en `<config dir>/link/<link id>.pid`). Si ese pid pertenece ahora a otro programa, comprueba primero que ningún ssh del enlace siga activo, elimina el archivo `.pid` y reinicia OpenCodex en Home. Si OpenCodex no puede leer el archivo `.pid`, el enlace permanece bloqueado de la misma manera, incluso tras reiniciar. Haz que el archivo vuelva a ser legible y el enlace esperará a que termine el ssh indicado; o, cuando ya no haya ningún ssh del enlace activo, elimina el archivo y el enlace arrancará en un segundo o cuando corresponda su siguiente reintento.
+- **Volver a una ruta mejor.** Añadir o reordenar rutas no mueve un túnel activo; una ruta posterior se conserva mientras funcione. Home vuelve a probar desde el principio al caer el túnel o al ejecutar `ocx link reconnect --link-id <id>`, que interrumpe las solicitudes activas de ese enlace.
+- **Estado.** Para un enlace con varias rutas, `ocx link status --json` muestra `route` (ruta en uso y desde cuándo), `routes` (cada ruta, cuándo puede reintentarse y último resultado) y `routeBlocked`.
+- **Requisitos.** El `ssh` de Home debe ser OpenSSH o el enlace falla con `ssh_client_unsupported`. El Child necesita lo habitual para añadirlo: `curl` en macOS y Linux o Windows PowerShell en Windows. Los comandos usan la API de gestión de Home con token administrativo en loopback, como `ocx link reconnect`; no están disponibles por el socket privado de control que abre un Hub con bind no loopback para `ocx link status`.
+- **Relay y privacidad.** Si la ruta directa está bloqueada, se usa el relay, que solo transporta bytes cifrados por SSH. Los nombres son alias SSH: aparecen en `ocx link status` de Home y en los comandos de rutas, nunca en diagnósticos ni registros.
+- **Volver a una versión anterior.** Un Home antiguo rechaza un almacén de enlaces con rutas. Elimina las rutas adicionales con `ocx link routes remove` antes de usarlo.
+
+<a id="what-a-child-shows-and-manages"></a>
+
+## Lo que un Child muestra y administra
+
+Un Child se ejecuta en los proveedores, cuentas y configuraciones del Home, por lo que el Home es donde los cambia.
+
+- **Tablero.** El tablero de mandos del Child muestra el estado de solo lectura del Home y dice "Administrado por Home <name> a través de enlace remoto". El panel de control y los proveedores leen el Home a través del enlace, y la franja de uso en el encabezado muestra la cuota del Home. La lista de modelos no se muestra en un Child, porque al construirlo se ejecuta el descubrimiento de proveedores en el Home; Codex en el Child ya ofrece los modelos Home. Por la misma razón, los selectores de modelos de delegación y sidecar en un Child enumeran los modelos nativos y las opciones actuales del Home, no la lista completa de rutas del Home. Guardar un cambio allí se rechaza con un mensaje que nombra el Home; hacer el cambio en el tablero de Home. El navegador del Child nunca recibe una credencial Home.
+- **Codex ajustes.** `ocx sync` en el Child (y conectándolo) se aplica la configuración Codex OpenCodex se gestiona en el Home: Modo rápido, el modo multiagente, el conmutador de sidecar de búsqueda web y el subagente nativo por defecto cuando el Home los sincroniza. `ocx sync` y `ocx status` listan los valores que vinieron del Home. El esfuerzo de razonamiento predeterminado y los niveles de esfuerzo que se muestran en el selector de modelos de la aplicación Codex son la configuración de la aplicación Codex en cada computadora; OpenCodex no los administra en ningún ordenador.
+- **CLI.** Las órdenes que solo leen, como `ocx account list`, `ocx provider quota` y `ocx usage`, leen el Home. Muestran lo que el Home ya ha observado: una lectura de un Child nunca hace que el Home sondee a un proveedor, actualice un token o inicie un proceso, por lo que los detalles de la cuota y la cuenta son tan frescos como la propia actividad del Home los mantiene. Las lecturas que solo existen para ejecutar el descubrimiento del proveedor o una actualización forzada, como `ocx models live`, `ocx models preset show` y `ocx account list --quota`, se rechazan como cambios. Los comandos que cambian la configuración son rechazados con un mensaje que nombra el Home y el enlace y dice que no se envió ninguna solicitud. `ocx status` describe el Home y el enlace. `ocx provider list` y `ocx config get` todavía muestran la propia configuración de este ordenador, etiquetada como local e inactiva mientras el ordenador está enlazado. `ocx config set`, `ocx config unset` y `ocx config import` todavía escriben localmente, cada uno con la misma nota, y `ocx provider add`, `remove` y `set-default` son rechazados porque esos proveedores no se utilizan mientras están vinculados.
+
+Estas lecturas necesitan una versión OpenCodex con el relé de gestión de enlace remoto tanto en el Home como en el Child. Un antiguo Home responde con un mensaje pidiéndote que lo actualices.
+
+<a id="remove-a-child"></a>
+
+## Eliminar un archivo Child
+
+Seleccione **Desconectar** para el Child y confirme el alias. El Home detiene el túnel, revoca la clave de enlace de ese Child y elimina el registro de enlace guardado.
+
+Si el Home no puede alcanzar el Child para ejecutar su comando de desconexión, elija **Eliminar aquí solamente**. Esto elimina el túnel local, la clave y el registro. A continuación, inicie sesión en el Child y ejecute:
+
+```bash
+ocx disconnect   # or ~/.cache/opencodex/bin/ocx-child detach on a lightweight Child
+```
+
+Para desconectar un enlace iniciado por Child, ejecute `ocx disconnect` en el Child. Desconecta el túnel del cliente y revoca el enlace en Home sobre SSH. Si la revocación Home falla, se imprime: `Home revoke failed; run ocx link revoke --link-id <linkId> on the home.`
+
+Para medir el tráfico, ejecuta `ocx link status --json`. Cada enlace incluye `traffic`: bytes de cuerpos de solicitud hacia Home (`toHomeBytes`), bytes de cuerpos de respuesta (`fromHomeBytes`), número de solicitudes y solicitudes terminadas antes de tiempo (`incomplete`), desde el inicio del conteo (`since`, con `epoch` y `generation`). Compara lecturas solo si coinciden `epoch` y `generation`; si cambia cualquiera, el conteo comenzó de nuevo, y un reinicio siempre cambia `epoch`. En Child se cuentan los bytes transportados por el enlace, incluidas sus propias lecturas de Home. Una carga de cuerpo incompleta también cuenta en `incomplete`; si este es mayor que cero, `toHomeBytes` puede omitir parte de un cuerpo interrumpido y es un mínimo. Una carga en curso solo se cuenta al terminar su escritura, por lo que la lectura puede ir detrás de lo ya recibido por Home; la diferencia entre lecturas cuenta escrituras completas. Child muestra estas cifras en el estado del dashboard, pues `ocx link status` allí solo lee archivos locales. En Home, las respuestas se cuentan al enviarse y las solicitudes por su longitud declarada (`toHomeSource: "content-length"`); las que no la declaran se cuentan en `toHomeUncounted`. Hay contadores para hasta 256 enlaces; las solicitudes sin espacio para medir se cuentan en `untrackedRequests`. No se incluyen encabezados, sobrecarga SSH ni lo añadido por un relay, y el reinicio reinicia el conteo. OpenCodex no infiere si una ruta es directa o de relay. Un enlace de una ruta usa su alias; con varias, el estado muestra la ruta en uso y desde cuándo (`route.name`, `route.since`), y su nombre indica el tipo. Cada fila de `ocx logs --json` incluye `requestBody`: tamaño recibido (`wireBytes`), `encoding` y tamaño decodificado (`decodedBytes`).
+
+Cuando Child y Home ejecutan esta versión, Child comprime individualmente con zstd las solicitudes de modelo mayores de 1 KiB y de hasta 16 MiB que no tengan codificación propia antes de enviarlas por el enlace. Solo lo hace cuando Home anuncia por el enlace que las acepta; con un Home antiguo las envía como antes. Home rechaza solicitudes comprimidas que se expandirían más de 200 veces por encima de 8 MiB para protegerse de bombas de compresión. La conexión SSH no se comprime.
+
+Para desactivarlo, configura `"linkRequestCompression": false` en el `config.json` de Home y reinicia Home. Deja de ofrecer compresión y sus Children envían las solicitudes sin comprimir. La compresión implica una decisión de privacidad: quien pueda insertar texto elegido junto a un secreto en una solicitud y observar el tamaño de muchas solicitudes puede adivinar el secreto según cuánto se compriman. En un enlace esto incluye al operador del relay o a cualquiera en la ruta de red: el túnel oculta el contenido, pero no el tamaño. Está activada por defecto porque el ataque requiere controlar texto de la conversación y observar el tamaño de cada solicitud, mientras que reduce en más de la mitad los bytes enviados hacia Home.
+
+<a id="troubleshooting"></a>
+
+## Solución de problemas
+
+Cuando un paso falla, el panel de control muestra la razón y, cuando SSH informó de uno, una breve pista desinfectada de su última línea de error no vacía debajo del mensaje. Los errores de shell remoto pueden aparecer allí incluso cuando el shell remoto emite texto que no es UTF-8; OpenCodex elimina los controles de terminal, las claves de enlace y las consultas de URL y limita la longitud de la pista.
+
+- **No se pudo conectar al host SSH**: el host debe aceptar su clave SSH sin una solicitud de contraseña; `ssh -o BatchMode=yes <alias> true` debe tener éxito desde una terminal. Un ayudante `ProxyCommand` como `cloudflared` debe instalarse en `/opt/homebrew/bin`, `/usr/local/bin`, `~/.bun/bin`, `~/.local/bin` u otro directorio en el PATH OpenCodex se ejecuta con.
+- **ocx no se encontró en el equipo remoto**: OpenCodex busca `ocx` en el CAMINO de una sesión SSH no interactiva primero, luego en `~/.bun/bin`, `~/.local/bin`, `/opt/homebrew/bin` y `/usr/local/bin`. Si está instalado en otro lugar, agregue ese directorio a PATH en un archivo que el shell remoto lee para sesiones no interactivas, como `~/.zshenv` para zsh.
+- **OpenCodex en el equipo remoto es demasiado viejo**: ejecute `ocx update` en ese equipo. El enlace remoto necesita 2.66.0 o posterior.
+- **La computadora remota no reportó una versión OpenCodex**: `ocx --version` en ese equipo imprimió otra cosa, por ejemplo, el texto de uso de una instalación Windows no compatible.
+
+- **Las solicitudes fallan con `home_unreachable` cuando el Home no está disponible**: un Child nunca atiende solicitudes con sus proveedores locales. Si el túnel ya estaba caído antes del reenvío, devuelve un 503 reintentable y no envía nada al Home. Si el túnel se corta después de iniciar el reenvío, también devuelve `home_unreachable`, pero el Home puede haber recibido la solicitud. Un fallo de autenticación del relé devuelve `link_relay_auth_failed`: actualiza el Home y el Child o vuelve a enlazarlos. El permiso por dispositivo en la página **Remote Link** del Home, o `ocx fallback local on --device <alias>`, determina si GOAT puede usar las sesiones locales de ese dispositivo; consulta [Desactivar el fallback](/es/guides/fallback-off/).
+
+- **Un enlace iniciado por Home sigue Fallido por un error de reenvío después de una suspensión o un cambio de red:** ejecuta `ocx link status --json` en el Home. El campo `tunnel` muestra los intentos desde la última conexión, `nextRetryAt` y el fallo más reciente. Si `lastFailure.cause` es `remote_forward_conflict`, el servidor SSH del Child aún reserva el puerto de la sesión que perdió la conexión anterior del Home. Los nuevos túneles se rechazan hasta que libere ese puerto. OpenCodex sigue reintentando y se conecta cuando queda libre; nunca detiene procesos del Child. El servidor SSH detecta la sesión muerta al comprobarla. Sin `ClientAliveInterval` en `sshd_config` del Child, puede tardar lo que el keepalive TCP del sistema: dos horas por defecto en macOS. Configurar allí `ClientAliveInterval 15` y `ClientAliveCountMax 3` permite descartarla en aproximadamente un minuto.
+
+<a id="retryable-503-diagnostics"></a>
+
+### Diagnósticos de respuestas 503 reintentables
+
+Un `503` generado por el relay incluye `x-opencodex-link-request-id`, creado por el servidor. Permite correlacionar el fallo con la evidencia local del Child en `link/diagnostics.jsonl` y su copia rotada `link/diagnostics.jsonl.1`, bajo el directorio de configuración de OpenCodex. Cada archivo tiene un límite de 256 KiB y permisos privados: directorio 0700 y archivos 0600 en POSIX, ACL privadas en Windows. Los registros solo contienen categorías fijas de evento, resultado y estado, identificadores de correlación generados, tiempos, generaciones, intentos numéricos y marcas de tiempo. No incluyen secretos, cuerpos de solicitud, encabezados, URL, identificadores de cuenta ni errores sin filtrar. Cada par evento/resultado se limita a un registro por segundo y el siguiente incluye cuántos se suprimieron: la ausencia de un registro no prueba que no hubiera un fallo. Si el reloj retrocede, se inicia otra ventana de limitación conservando ese recuento, incluso con la cola llena. El escritor asíncrono admite hasta 56 registros pendientes, cuenta el exceso como suprimido y cede la ejecución durante el trabajo de ACL en Windows. Registrar es una operación de mejor esfuerzo y no cambia la admisión de solicitudes. El apagado por señal y el reciclado independiente esperan hasta un segundo para vaciar la cola; el almacenamiento bloqueado, el cierre forzado o la pérdida de energía pueden hacer que se pierdan registros.
+
+`owner_lookup` registra comprobaciones de propiedad rechazadas; las correctas ordinarias no se registran. `owner_lookup.elapsedMs` mide solo la consulta de propietario. En `auth_timeout`, los eventos `relay_retry` y `relay_failure` informan la duración real del intento de transporte en `elapsedMs`, normalmente unos cinco segundos. `relay_recovered` con resultado `recovered` solo se emite cuando un reintento recibe una respuesta del proveedor con `upstream.ok`, HTTP 2xx; no demuestra que el cuerpo transmitido haya terminado. Por la limitación de frecuencia, la correlación por identificador es evidencia muestreada y no un seguimiento garantizado de todos los fallos.
+
+El Home escribe el mismo tipo de archivo para los túneles que ejecuta. Cada transición de un túnel iniciado por Home genera `tunnel_transition`, con `previousState`, `state`, causa en `outcome` (`auth`, `hostkey`, `forward`, `remote_forward_conflict`, `timeout`, `network`, `unknown`, `spawn_failed` o `listener_unavailable`; `connected`, `spawned` o `stopped` si no hubo fallo), el número de `attempt` desde la última conexión, `tunnelPort` y `retryAfterMs` si se programa otro intento. También se registra cada reintento fallido de un enlace ya fallido. La misma limitación de frecuencia se comparte entre todos los enlaces.
+
+Antes de enviar datos, OpenCodex permite un único reintento previo compartido entre el timeout de consulta de propietario y un timeout de autenticación de cinco segundos identificado expresamente. Obtiene una prueba nueva de propietario cuando corresponde y un socket físico nuevo, que autentica antes de enviar la credencial del enlace o el cuerpo. No reutiliza una aprobación anterior de propietario, ni omite controles, ni reinicia SSH u OpenCodex, ni vuelve a enviar un cuerpo ya despachado. Los límites de dos segundos para propietario y cinco para autenticación siguen aplicándose a cada intento. Otros fallos no admiten este reintento previo.
+
+Esto puede recuperar esos timeouts transitorios y aportar diagnósticos para fallos posteriores. No demuestra la causa histórica de [#7297](https://github.com/lidge-jun/opencodex/issues/7297).
+
+<a id="security"></a>
+
+## Seguridad
+
+El Child utiliza los proveedores de la computadora Home y las credenciales del proveedor a través del enlace. El Home crea una clave de enlace separada para cada Child; la eliminación del enlace revoca esa clave. En el Child, la clave permanece dentro de OpenCodex: las credenciales que Codex o Claude Code envían allí no se reenvían al Home, incluidas las formas Bearer, `api-key` de Azure, `x-api-key` compatible con Anthropic y `x-goog-api-key` de Google. Cualquier programa en el Child que alcanza `127.0.0.1:<port>` utiliza el Home sin una llave, la misma confianza local que da una instalación independiente. Las páginas web de otros sitios son rechazadas. Compare la huella digital del host antes de la confirmación para que no se acepte por error una máquina incorrecta o una clave de host modificada. Las sesiones del panel de control emitidas desde una identidad de Tailscale no pueden administrar enlaces de máquina.
+
+<a id="capture-ssh-diagnostics"></a>
+
+### Capturar diagnósticos SSH
+
+La captura está desactivada por defecto y solo puede activarse localmente en el equipo cuyo túnel se inspecciona:
+
+```bash
+ocx link capture start            # 15 minutes; --minutes accepts 1 to 60
+ocx link capture status
+ocx link capture stop
+```
+
+En Home captura los túneles que ejecuta a sus Children; en Child, el suyo a Home. No requiere proxy activo ni token, y ningún sync, dashboard o petición remota puede activarla. `start` dentro de una ventana extiende el final y usa el mismo archivo. El siguiente intento SSH usa `LogLevel=DEBUG1` en lugar de `LogLevel=ERROR`; un túnel conectado conserva su nivel hasta reconectar. `stop` o caducar detiene la escritura y el siguiente intento vuelve a ERROR. No cambia la admisión; líneas reconocidas no alteran la causa de error, pero un banner no reconocido con Permission denied puede cambiarla y afectar la espera.
+
+Cada registro de `link/ssh-capture/ssh-<start time>.jsonl` indica hora, túnel `home` o Child, ID aleatorio del enlace, nivel y evento fijo saneado. Hosts, direcciones, usuarios, puertos, rutas, claves, huellas, comandos proxy, entorno y mensajes remotos se sustituyen por `<host>`, `<port>` u otros marcadores. Solo se conservan nombres estándar de algoritmo y autenticación; una línea no reconocida guarda `unrecognized` y recuento, nunca el texto. Cada ventana ocupa hasta 1 MiB, terminando en `capture_truncated`. Se conservan cuatro archivos y cada uno caduca a las 72 horas de su última escritura; se depuran al arrancar, iniciar túnel, ejecutar `ocx link capture` o vencer en un proxy activo. Sin proxy, se eliminan al siguiente arranque/comando. `stop` los conserva para compartir: bórralos al terminar. Directorio 0700 y archivos 0600 en POSIX, ACL privada en Windows y sin seguir enlaces simbólicos.
+
+<a id="cli-reference"></a>
+
+## Referencia CLI
+
+```text
+ocx link probe <alias> [--proxy-command <cmd> --ssh-user <user> --ssh-port <port>] [--exclusive] [--json]
+ocx link add <alias> [--plant] [--expect-fingerprint SHA256:…] [--proxy-command <cmd> --ssh-user <user> --ssh-port <port>] [--exclusive] [--json]
+ocx link port [--json]
+ocx link issue --alias <alias> --tunnel-port <port> [--json]
+ocx link status [--json]
+ocx link diagnostics [--limit <n>] [--since <iso-time|epoch-ms>] [--json]
+ocx link revoke --link-id <id> [--json]
+ocx link reconnect --link-id <id> [--json]
+ocx link routes --link-id <id> [--json]
+ocx link routes add --link-id <id> --route <alias> [--position <n>] [--json]
+ocx link routes remove --link-id <id> --route <alias> [--json]
+ocx link routes order --link-id <id> --routes <alias,alias,...> [--json]
+ocx link check (--link-id <id> | --all) [--no-wait] [--json]
+ocx link update (--link-id <id> | --all) --yes [--no-wait] [--json]
+ocx link sync (--link-id <id> | --all) [--no-wait] [--json]
+ocx link sync --link-id <id> (--restart-app-server-only | --restart-codex --yes) [--no-wait] [--json]
+ocx link restart-codex --link-id <id> [--scope app-server|codex] --yes [--no-wait] [--json]
+ocx link capture start [--minutes <1-60>] [--json]
+ocx link capture stop [--json]
+ocx link capture status [--json]
+ocx link policy [--updates off|notify|auto-when-idle] [--catalog-fanout auto|manual] [--child-codex-restart never|app-server-when-idle] [--idle-after-minutes <1-60>] [--json]
+```
+
+Una ruta explícita y exclusiva está destinada a quienes configuran por sí mismos la ruta SSH, por ejemplo un hub que aprovisiona un equipo desechable. `ocx link add <alias> --proxy-command <command> --ssh-user <user> --ssh-port <port> --exclusive` pasa ese ProxyCommand, usuario y puerto a ssh en la línea de comandos para cada comando y túnel del enlace, de modo que una edición posterior de `~/.ssh/config` no puede cambiar la ruta del enlace; el enlace también rechaza las modificaciones de `ocx link routes`. El comando debe comenzar con una ruta absoluta y usar solo letras, dígitos y `. _ / : @ + , = -` en palabras separadas por espacios individuales; se rechazan tokens `%`, comillas y caracteres de shell. `--exclusive` por sí solo limita el enlace a su único alias sin cambiar cómo ssh llega a él.
+
+<a id="related-guides"></a>
+
+## Guías relacionadas
+
+- [Implementación remota de Hub](/es/guides/remote-hub/)
+- [Espacio de trabajo remoto](/es/guides/remote-workspace/)
+
+<a id="relay-authentication-compatibility"></a>
+
+### Compatibilidad con autenticación de relés
+
+Actualice tanto el Home como el Child cuando actualice a la autenticación de retransmisión vinculada a la conexión. Antes de enviar una credencial o cuerpo de enlace de una solicitud retransmitida, el Child verifica el Home en la misma conexión que utilizará para esa solicitud. Una conexión cerrada no se reemplaza silenciosamente. Un Home sin este protocolo causa un error de autenticación reintentable; actualizar el Home y Child, y volver a vincular cuando el enlace almacenado ya no se reconoce. No hay un interruptor de reserva inseguro. Una rotación de clave API pendiente y no expirada sigue siendo válida hasta que expire o la rotación se confirme o se aborte.
+
+Eliminar los drenajes finales de enlace Home pendientes de solicitudes de retransmisión autenticadas antes de liberar su oyente. Detener el proceso aún cancela las conexiones activas. Esto no cambia qué credenciales de llamada se eliminan o qué rutas se pueden retransmitir, y no reemplaza la verificación de clave de host de SSH.
+
+
+<a id="home-and-child-versions"></a>
+
+### Versiones del Home y del Child
+
+En el Home, `ocx link status --json` informa la versión `local` del Home, la versión de autenticación del relé y sus capacidades, y añade un bloque `peer` a cada enlace. No consulta nada por SSH: el Home aprende esos datos mediante la comprobación de autenticación que el Child envía antes de cada solicitud retransmitida. Desde 2.91.0, esa comprobación también contiene la versión y las capacidades del Child. El Home guarda lo aprendido en memoria; tras reiniciarlo, un enlace muestra `unknown` hasta que su Child retransmita otra solicitud.
+
+| Parte del enlace | Primera versión |
+|---|---|
+| `relay-auth/2`, autenticación del relé vinculada a la conexión | 2.69.0 |
+| `link-management-relay`, administración de solo lectura del Home desde el Child | 2.84.0 |
+| `link-peer-report/1`, el Child informa su versión y sus capacidades | 2.91.0 |
+
+`peer.compatibility` puede ser:
+
+- `compatible`: las versiones de autenticación del relé coinciden y el Home ofrece todas las capacidades declaradas por el Child. Un Child anterior a 2.91.0 no informa su versión: `peer.version` es `null` y `peer.versionRange` indica el intervalo deducido de la autenticación del relé, por ejemplo `{ "min": "2.69.0", "below": "2.91.0" }`.
+- `degraded`: el Child declara una capacidad que el Home no ofrece. Actualiza el Home.
+- `incompatible`: el Child solicita una versión de autenticación que el Home no admite, por lo que sus solicitudes se rechazan. `peer.reasons` indica qué lado actualizar.
+- `unknown`: el Child no ha retransmitido solicitudes desde que arrancó el Home, o declaró una versión o lista de capacidades ilegible, por lo que no se puede comprobar su compatibilidad.
+
+La versión que declara el Child es una afirmación propia vinculada a su clave de enlace. OpenCodex solo la usa para mostrar información, nunca para autorizar solicitudes. Las instalaciones antiguas de `ocx` siguen recibiendo el documento de estado anterior: solo la CLI 2.91.0 o posterior solicita estos campos.
+
+<a id="standalone-pairing-authorization"></a>
+
+### Autorización de emparejamiento independiente
+
+El comando `ocx gui pair --origin <local-origin>` existente funciona mientras OpenCodex se ejecuta como un servicio en segundo plano. Ejecútelo con la cuenta propietaria del directorio privado de OpenCodex del servicio y, a continuación, introduzca el código de un solo uso devuelto en el panel de control local. No se requiere ningún terminal de servidor, contraseña adicional, Windows Hello ni clave de hardware. El CLI y el servidor deben usar la misma versión actual y el mismo directorio de configuración; reinicie un servidor anterior después de actualizar. Las invitaciones a Hub de versión mixta también requieren actualizar el CLI y el servidor juntos. El emparejamiento rechaza un directorio de configuración o de intención que sea un enlace simbólico; use el directorio protegido real como `OPENCODEX_HOME`.
+
+Internamente, la CLI crea un compromiso de autorización de corta duración e intenta eliminarlo tras su uso o un fallo. Leer información del entorno de ejecución por sí solo no autoriza el emparejamiento, y el verificador no se guarda en disco. Es un límite basado en el acceso de escritura al directorio privado, no una autenticación biométrica ni una prueba de presencia humana: se sigue confiando en un programa con acceso completo a los archivos de ese usuario. La autorización de invitaciones de Hub existente no cambia. Si falla una solicitud de emparejamiento, ejecuta un comando nuevo después de resolver el problema indicado. SSH Remote Link en Windows usa la vía de ejecución independiente mediante PowerShell descrita arriba.
+
+Si un proceso se interrumpe durante el emparejamiento, vuelva a ejecutar el comando para obtener una nueva autorización. No elimine manualmente el estado de emparejamiento mientras se ejecuta el servicio o un comando de emparejamiento.
+
+En Windows, el emparejamiento se rechaza si la carpeta de intención o el registro no es privado de la cuenta de servicio, o si su propietario y los permisos no se pueden verificar. Ambas entradas deben ser propiedad de esa cuenta; La propiedad de los administradores solo se acepta cuando los administradores son el propietario predeterminado del token de servicio y su función de administrador está habilitada. La lista de permisos debe estar protegida de la herencia y contener una entrada de permiso de control total ordinaria para la cuenta servidora. Además de eso, solo se aceptan entradas de permiso simple para SYSTEM y el grupo Administradores, porque SYSTEM y un administrador elevado ya pueden tomar posesión de cualquier archivo; un administrador no elevado no gana nada de esa entrada. Solo en la carpeta se permite la herencia hacia los elementos descendientes. Esta es la lista como Windows lo informa: las entradas duplicadas compatibles para el mismo recuento de cuentas que uno, y las entradas que no conceden nada se ignoran. El cheque deja registros rechazados en su lugar y no repara sus permisos ni cambia la propiedad. Restaurar una casa de configuración privada y, a continuación, ejecutar un nuevo comando de emparejamiento.
+
+La comprobación cubre la carpeta de intención y el registro. No protege contra el reemplazo de carpetas anteriores, derechos de eliminación en una carpeta principal, operaciones de restauración con privilegios o acceso a través de identificadores abiertos antes de que los permisos se vuelvan privados. Una solicitud con un compromiso coincidente puede bloquear el servidor durante un subproceso de verificación limitado a cinco segundos, incluso si su carpeta falla más tarde en la verificación de permiso. La configuración de inicio de proceso y búsqueda ejecutable precede a ese tiempo de espera. CLI limpieza puede realizar una verificación más. El presupuesto de subproceso de cinco segundos deja espacio dentro del tiempo de espera de solicitud de diez segundos del comando, pero la verificación lenta aún puede rechazar el emparejamiento.
+
+<a id="add-a-child-from-the-terminal"></a>
+
+## Agregar un Child desde el terminal
+
+En el Home, ejecute `ocx link probe child-a --json` para inspeccionar la huella digital SSH ofrecida, el tipo de clave y la versión OpenCodex. Verifique la huella digital a través de una fuente confiable. A continuación, ejecute `ocx link add child-a --expect-fingerprint SHA256:… --json`. El comando sondea de nuevo y rechaza un desajuste antes de almacenar la confianza o emitir una clave. Sin el indicador de huella dactilar, requiere un terminal interactivo y un `yes` explícito después de mostrar la huella dactilar. Nunca imprime la clave de enlace.
+
+Para una instalación completa de OpenCodex, las conexiones iniciadas desde Home reinician el Child después de guardar su conexión, incluidas las instalaciones antiguas que tengan la capacidad necesaria. Ese Child debe estar sirviendo OpenCodex independiente en su puerto configurado y ofrecer soporte de reinicio vinculado; actualízalo o desconéctalo si no supera esta comprobación previa. Un Child ligero limpio y desconectado no necesita un daemon en ejecución; consulta [Children efímeros](#ephemeral-child-machines-ocx-child). Los Children POSIX necesitan curl; Windows usa una solicitud HTTP de loopback con tiempo limitado mediante .NET. En Children macOS y Linux, Home usa primero la instalación de OpenCodex que sirvió el Child más recientemente, incluida una instalación npm bajo un prefijo personalizado, aunque haya otra copia instalada más reciente. Una aplicación de escritorio o copia de PATH anterior ya no responde en su lugar. Si esa instalación falta o no puede informar su versión, las instalaciones Desktop y de sistema tienen prioridad sobre los shims genéricos de PATH; los candidatos que no funcionan se omiten. Los Children Windows x64 usan comandos PowerShell codificados sin consumir la entrada estándar que transporta la clave. La comprobación previa lee `ocx config show --json` con el límite de captura de 4 MiB del ejecutor, por lo que un Child con una configuración guardada grande todavía acepta un enlace; si la salida supera ese límite, devuelve `child_preflight_output_limit` e indica el comando cuya salida hay que reducir. Cuando falla una fase, `ocx link add` muestra la fase junto con el motivo del Child, por ejemplo una configuración guardada no válida o la última línea de error del comando fallido. El motivo se acorta y se eliminan las claves de OpenCodex y las cadenas de consulta de las URL.
+
+<a id="windows-computers"></a>
+
+### Equipos Windows
+
+Un Child Windows x64 necesita OpenSSH Server, Windows PowerShell y el binario independiente `ocx.exe` o el ligero `ocx-child.exe`. Home reconoce Windows durante el sondeo, lo registra con el enlace y ejecuta todos los comandos del Child mediante PowerShell sobre la misma conexión SSH con identidad fijada, tanto si el shell predeterminado de SSH es cmd como si es PowerShell. La clave del enlace sigue viajando solo por la entrada estándar. Cerrar la conexión SSH termina el comando remoto del Child seleccionado. Si Windows PowerShell en el Child no puede cargar el asistente que contiene el ejecutable seleccionado en un Job que termina al cerrarse, por ejemplo bajo Constrained Language Mode, el comando se rechaza y no se ejecuta nada. Si Home no puede determinar la plataforma del Child, se detiene antes de emitir una clave de enlace.
+
+Ejecuta `ocx link cleanup` en Home para inspeccionar las plataformas registradas de los Children sin modificarlas. Las versiones actuales de Home desconectan los Children Windows mediante PowerShell. Si falla una desconexión remota, resuelve el error de shell o instalación indicado y reintenta; **Eliminar aquí solamente** sigue siendo una acción explícita de recuperación que puede dejar al Child pendiente de una desconexión local.
+
+Reiniciar espera los giros y puede tardar varios minutos. El éxito requiere que el Child reiniciado cumpla con el rol de cliente y transmita un nuevo catálogo completo a este Home. La configuración de SSH tiene una asignación limitada derivada de la latencia medida; la verificación del relé comienza después del reinicio con su propia ventana de 15 segundos. Los errores indican la fase fallida y terminan con el código de error. Si un error informa la configuración residual Child, ejecute `ocx disconnect` y `ocx restart` en ese Child antes de volver a intentarlo. Home limpieza por sí sola no restaura Child configuración. Un tiempo de espera CLI reporta un resultado incierto; inspeccione Home `ocx link status` y Child `ocx connect status` primero.
+
+En un Child cuyo enlace inició Home, `ocx link status` informa el rol `child`, la identidad del enlace y el puerto del túnel de su conexión guardada, aunque su almacén de enlaces Home está vacío. El estado del túnel no observado localmente es `idle`. `ocx status` llama al par un enlace remoto Home. Cuando Home se ejecuta en el modo Hub, el estado lee su proyección soportada a través del relé local Child. Un Home independiente informa que no publica el estado de Hub. La identidad del túnel iniciada por un Child proviene de su sidecar válido; la evidencia ilegible no declara una dirección.
+
+
+<a id="child-install-catalog-and-activity"></a>
+
+### Instalación, catálogo y actividad del Child
+
+El Home requiere OpenCodex 2.66.0 o posterior; el Child también si inicia el enlace o usa una instalación completa. Un host SSH vacío puede recibir `ocx-child` verificado sin Node, Bun ni OpenCodex previo. npm y Desktop no incluyen ese binario: consulta [Children efímeros](#ephemeral-child-machines-ocx-child). Confirma la huella antes de **Conectar Child** o **Instalar agente ligero y conectar**.
+
+Home reintenta cada minuto los túneles que inició tras un timeout o error de reenvío. Un Child que inició su enlace duplica la espera de uno hasta cinco minutos. Ambos esperan cinco minutos ante errores de autenticación; nunca reintentan una huella cambiada. `client_state_changed` significa que la conexión guardada falta o identifica otro propietario o enlace; los endpoints de estado también devuelven `503`. Detén o reinicia el Child y comprueba su conexión antes de enlazarlo otra vez; este resultado no desconecta el relay.
+
+`ocx connect status` muestra `Link tunnel:` con `up`, `down (<reason>)` o `unknown`. Las causas de este último son `runtime_not_running`, `runtime_unreadable` y `link_unverified`. `--json` lo incluye en `linkTunnel`. `Connection: connected` solo confirma el vínculo: puede coexistir con `Link tunnel: down (home_unreachable)` hasta reconectar.
+
+Si `ocx connect status --json` informa `disconnected` pero un token sobrante impide enlazar, inspecciona el Child. Tras confirmar que debes conservar los archivos, usa `ocx disconnect --orphaned-token --yes`. Rechaza clientes conectados o pendientes, runtimes clientes activos o no verificables, Hub, bind fuera de loopback, secretos de admisión configurados o coincidentes y servicios instalados o no verificables. Revisa `ocx service status`, bind, claves y entorno; migra o quita un servicio solo si es lo deseado. Mueve token y respaldo de rotación a un directorio privado e imprime su ubicación, sin presumir que eran del enlace. Windows exige enlaces duros para conservar identidad; inspecciona un respaldo incompleto antes de reintentar. Ante `unsafe token file`, revisa `orphaned-token-*` por `.service-api-token.identity` o `.service-api-token.prev.identity`: quita un pin solo si es un enlace duro al token actual, no solo porque coincida el nombre; puede ser la única copia de un token anterior. Inspecciona los demás enlaces. Para restaurar, detén OpenCodex y devuelve los archivos solo si sus nombres originales no existen. No revoca una clave Home ni reconstruye la configuración cliente.
+
+Con Desktop o un servicio supervisando el Child, sync puede aplicar ajustes y aplazar el reinicio. Cierra y abre Desktop o usa `ocx service restart` para hacerlos efectivos. Importar una configuración que reemplaza o elimina una conexión activa se rechaza: desconecta primero o conserva exactamente el registro.
+
+`ocx link status --json` incorpora un bloque `child` por enlace:
+
+- `runningVersion` es la versión declarada por el Child. `installedVersion`, `installKind` y `update` con `route`, `reason`, `observedAt` proceden de `ocx link check` y son null antes. `versionSkew` es `same`, `behind`, `ahead` o `unknown`; en `ocx-child`, siempre unknown.
+- `catalog.state` es `current`, `behind` o unknown según el contenido, no las fechas. Descargar, incluido durante `ocx link add`, no demuestra aplicar.
+- `activity.idle` es `true` tras diez minutos sin solicitudes retransmitidas, ajustable con `ocx link policy --idle-after-minutes`; `inFlight` cuenta las actuales. Tokens, catálogo y readiness no cuentan. Un Child antiguo sin autenticación por conexión cuenta contra todos los enlaces.
+- `activeJob` identifica la operación activa, `lastOperation` la última acabada; `codex` es null por ahora.
+
+`ocx link check --link-id <id>` o `ocx link check --all` consultan `ocx update --plan` por SSH, sin actualizar: 60 segundos por Child y tres a la vez. Antes de 2.97.0 devuelve `owner-action`, `legacy-ocx`; POSIX hace otra lectura de versión y Windows usa la declarada. npm/pnpm sin instalación servidora registrada pasan por el launcher habitual y sus registros de arranque. Los enlaces iniciados por Child y los ligeros no usan SSH en esta comprobación. `--no-wait` imprime el trabajo aceptado; en otro caso espera. Salidas: 0 todos responden, 6 no comprobable, ocupado, antiguo o desconectado, 1 fallo, 4 desconocido o Home antiguo, 5 operación ocupada o sin enlaces.
+
+<a id="operating-children-from-the-home"></a>
+
+### Operar Children desde Home
+
+- `ocx link sync` usa `ocx sync --expect-link`, con Child 2.93.0 o posterior.
+- `ocx link restart-codex --link-id <id> --yes` sincroniza y reinicia app-servers. `--scope codex` también cierra y abre Desktop y exige sesión gráfica. Equivale a `ocx link sync --link-id <id>` con `--restart-app-server-only` o `--restart-codex --yes`. Termina turnos y nombra un solo enlace.
+- `ocx link update (--link-id <id> | --all) --yes` lleva al Child exactamente a la versión del Home mediante su propio instalador. Comprueba pertenencia y plan, aplica con plazo del reloj del Child y sincroniza después de un éxito, fallo o reversión verificados. Un resultado desconocido no se reintenta ni sincroniza: usa `ocx link check`. npm/pnpm usan Node, con lectura previa `node --version`; Bun usa Bun. Requiere 2.97.0; procesa uno a la vez y termina las solicitudes del Child al reiniciarlo.
+
+Home no reinicia Codex mientras retransmite una solicitud del Child. `ocx sync --restart-children` o `--restart-children=codex --yes`, con `--child <linkId>` opcional, sincroniza y omite solo el reinicio ante actividad, `restart-skipped:link-active`. Si ya estaba activa al iniciar `ocx link restart-codex`, no envía nada y marca `busy`; si aparece durante sync, solo omite reinicio. Es de mejor esfuerzo: una petición que llegue entre la comprobación y el reinicio aún puede terminar. Home tampoco puede saber si Codex está en mitad de un turno que ejecuta una herramienta en lugar de una solicitud de modelo, así que deja que terminen los turnos activos de Codex en ese Child antes de reiniciar Codex o actualizar OpenCodex allí. Una actualización manual reinicia el OpenCodex de ese Child y termina cualquier turno que aún se retransmita para él; las actualizaciones automáticas esperan a que el Child esté inactivo. Antes de 2.69 la actividad sin streaming solo se ve al empezar la respuesta. Windows admite `sync`, pero rechaza `windows-restart` y `windows-apply`; `ocx-child` no admite esas operaciones. Solo una operación por enlace: borrarlo mientras trabaja devuelve `409 link_operation_in_progress`; un trabajo múltiple marca `link-operation-in-progress` en el ocupado y continúa con los demás.
+
+Salidas: 0 todos correctos o actualizados; con `--no-wait` solo confirma aceptación. Lee el `jobId` en `GET /api/link/children/jobs/<jobId>` con token administrativo loopback; los últimos 32 duran una hora y se pierden al reiniciar Home. 6 requiere atención, incluido reinicio omitido o actualización sin sync posterior; 1 es fallo o incertidumbre; 4 enlace desconocido o Home sin comandos; 5 operación activa, único enlace iniciado desde Child, sin enlaces o ejecución en Child. Requieren Home loopback; en otro bind fallan con 1, y la página **Remote Link** del panel de control ofrece las mismas acciones para un Child iniciado por Home. No enlaces equipos ajenos: Home ejecuta comandos con tu clave SSH.
+
+<a id="child-versions-and-actions"></a>
+
+### Versiones y acciones del Child
+
+En un Home, cada fila de Remote Link lleva lo último que el Home aprendió sobre ese Child, y una fila iniciada por Home también lleva sus controles. Las insignias dicen:
+
+- la versión del Child, con `Behind Home (<home version>)`, `Same version as Home` o `Newer than Home` al lado, más `Update available: <home version>` cuando se puede aplicar una actualización. Un Child iniciado desde su propio panel de control muestra su versión sin insignia de desfase, y un Child `ocx-child` siempre dice `unknown`.
+- el tipo de instalación (`Desktop app`, `GOAT`, `Source checkout`), o el token sin formato en monoespaciada cuando esta versión no lo nombra.
+- `Catalog current` o `Catalog out of date`. `Codex restart needed (<n>)` y `Codex not running` solo aparecen cuando el Child informa de su estado de Codex, que añade una versión posterior; todavía ningún Child publicado lo envía, así que hoy esas dos insignias no aparecen.
+- la última operación, como `Last <operation>: <state>` con su razón en monoespaciada, y la que se está ejecutando mientras un trabajo ocupa el enlace.
+
+Cuando el Home no puede actualizar ese Child por sí mismo, la fila dice qué hacer en su lugar: use Check for Updates en OpenCodex Desktop allí, actualice a mano, mediante `mise`, o deje que GOAT lo haga. Una razón desconocida se imprime como un token en lugar de una frase supuesta.
+
+Las cuatro acciones inician el mismo trabajo que la CLI, así que necesitan las mismas versiones en el Child:
+
+- **Check** lee los datos de instalación del Child, como `ocx link check`.
+- **Sync now** ejecuta allí el comando fijado `ocx sync --expect-link`, como `ocx link sync`.
+- **Restart Codex** abre una elección de alcance. `Codex app-servers` reinicia los app-servers en segundo plano del Child para que carguen el catálogo actual; no actualiza el app-server propio de la aplicación de escritorio de Codex, así que reinicie la aplicación de escritorio para eso. `Codex desktop app` además la cierra y la vuelve a abrir, lo que termina las conversaciones abiertas allí.
+- **Update** lleva el OpenCodex del Child a la versión de este Home mediante el propio actualizador del Child, como `ocx link update`. La confirmación dice que el OpenCodex del Child se reinicia y que cualquier turno que aún se retransmita para él termina, y que las actualizaciones automáticas esperan a que un Child esté inactivo.
+
+**Check all** y **Update all** actúan sobre cada enlace elegible iniciado por Home; Update all sigue ejecutando un Child a la vez y nunca apunta a otra versión. Un trabajo en ejecución muestra una línea por Child con su estado, la versión de la que salió y a la que llegó, el resultado de su sincronización de catálogo y el de su reinicio. El panel desaparece cuando el trabajo termina y las filas se actualizan; un trabajo que el Home ya no conoce, porque se reinició, lo dice y deja el estado propio de cada fila como respuesta. Mientras un trabajo ocupa un enlace, sus acciones y Desconectar están deshabilitadas; el servidor rechaza la solicitud de todos modos.
+
+Debajo de la lista, el panel **Child automation** muestra y edita el mismo archivo de política que `ocx link policy`: distribución del catálogo (automática por defecto), reinicio de Codex (nunca por defecto), actualizaciones (automáticas cuando está inactivo por defecto, aún no activas en esta versión) y el periodo de inactividad. Guardar escribe solo lo que cambió. Si el archivo de política está dañado, el panel dice que la distribución automática del catálogo y las actualizaciones automáticas están desactivadas, y guardar entonces escribe cada ajuste para que los modos que eligió sean los que persisten. Estos controles nunca eluden al servidor: vuelve a comprobar la política, el estado del enlace y la actividad del Child en cada trabajo.
+
+No enlace un equipo que no posee: el Home ejecuta estos comandos allí con su clave SSH.
+
+<a id="automatic-catalog-fan-out-and-the-child-policy"></a>
+
+### Catálogo automático y política de Children
+
+El envío de catálogo está activo por defecto. Auto-refresh o una comprobación cada cinco minutos detectan cambios y esperan 60 segundos para agruparlos, hasta cinco minutos desde el primero, antes de sincronizar por SSH sin reiniciar Codex salvo `childCodexRestart`. Exige enlace iniciado en Home, túnel conectado, ninguna operación y sync anterior al cambio. Descargar no basta. Con solicitudes activas solo sincroniza si los ajustes ya coinciden y el runtime reinició desde aplicarlos; si no, espera inactividad. Tras fallo espera cinco minutos y duplica hasta seis horas; un Child anterior a 2.93.0 espera otra versión. El trabajo usa `trigger: "auto"`; sin enlaces no se activa.
+
+Un app-server conserva el catálogo hasta reiniciar. Usa `ocx link restart-codex --link-id <id> --yes`, `ocx sync --restart-children` o `ocx link policy --child-codex-restart app-server-when-idle`. Esta última opción actúa en el siguiente sync automático con el Child aún inactivo: un catálogo ya actual no provoca otro sync/reinicio.
+
+La política está en `<configDir>/link/child-policy.json`, nunca en `config.json`:
+
+| Ajuste | Predeterminado | Valores |
+|---|---|---|
+| `catalogFanout` | `auto` | `auto`, `manual` |
+| `childCodexRestart` | `never` | `never`, `app-server-when-idle` |
+| `updates` | `auto-when-idle` | `off`, `notify`, `auto-when-idle` |
+| `idleAfterMs` | `600000` (10 minutos) | 1 a 60 minutos |
+
+Las actualizaciones automáticas aún no están activas: `updates` se guarda ahora y `notify` o `auto-when-idle` se aplicarán cuando se publiquen. Puedes anticipar tu elección con `ocx link policy --updates notify` o `--updates off`. Este periodo también define `activity.idle`.
+
+```text
+ocx link policy                                    # read the policy
+ocx link policy --catalog-fanout manual            # turn automatic catalog fan-out off
+ocx link policy --child-codex-restart app-server-when-idle
+ocx link policy --updates off --idle-after-minutes 20 --json
+```
+
+`GET` y `PUT /api/link/children/policy` consultan y cambian ajustes con token administrativo loopback o sesión dashboard; PUT solo envía cambios. Un archivo dañado o valor desconocido desactiva automatismos y muestra aviso. Guardar lo limpia pero deja desactivado lo no nombrado: actívalo explícitamente con `ocx link policy --catalog-fanout auto --updates auto-when-idle`. Home no lo reescribe solo.
+
+El preflight usa primero la instalación que sirvió el Child, incluso un prefijo npm personalizado. Si falta o no da versión, prioriza Desktop y sistema sobre PATH y omite candidatos rotos. Windows usa PowerShell codificado sin consumir stdin de la clave. `ocx config show --json` admite 4 MiB; superarlos informa `child_preflight_output_limit` y qué comando reducir. Los errores indican fase y último motivo acotado, sin claves ni consultas URL.
+
+<a id="ephemeral-child-machines-ocx-child"></a>
+
+### Children efímeros (`ocx-child`)
+
+Home envía por SSH `stdin` un binario SHA-256 verificado a `~/.cache/opencodex/bin/ocx-child`, o `%LOCALAPPDATA%\opencodex\bin\ocx-child.exe`. El Child no necesita Node, Bun ni red saliente. Elige **Instalar agente ligero y conectar** o `ocx link add <alias> --plant --expect-fingerprint SHA256:…`; `ocx link add <alias>` interactivo pregunta antes. POSIX exige `sha256sum`, `shasum` u `openssl`; sin ellos rechaza `hash_tool_unavailable` antes de ejecutar. Puede estar preinstalado en `~/.local/bin/ocx-child`, la caché o `PATH`. Se buscan primero todos los candidatos completos; con `$OPENCODEX_HOME/child/state.json`, se mantiene el ligero hasta separarlo.
+
+Home nunca construye ni descarga el binario. npm/Desktop no lo traen: `plantable: false`, `plantUnavailableReason: "artifact_not_found"` hasta aportarlo. Busca targets `darwin-arm64`, `darwin-x64`, `linux-x64`, `linux-arm64`, `windows-x64`, en orden:
+
+1. `OPENCODEX_CHILD_BIN_DIR`: `ocx-child-<target>`, `ocx-child-windows-x64.exe`, `<target>/ocx-child` o `ocx-child` si coincide con Home, listado en `SHA256SUMS` del mismo directorio.
+2. `native-bin/` junto al código o ejecutable, con la misma regla; ningún paquete lo aporta hoy.
+3. Solo en checkout, `native/ocx-child/target/release/ocx-child` para el mismo target.
+4. `$OPENCODEX_HOME/cache/ocx-child/<Home version>/ocx-child-<target>` con `SHA256SUMS`; debes copiarlo, no se rellena solo.
+
+Compila con `cargo build --release --locked --manifest-path native/ocx-child/Cargo.toml`, con compilación cruzada si procede; copia con el nombre adecuado y añade `sha256sum ocx-child-<target> >> SHA256SUMS` o `shasum -a 256`. No se aceptan enlaces ni archivos escribibles por grupo u otros.
+
+Un Child ligero separado no necesita daemon previo. Se comprueban el puerto `10100` y `~/.codex/config.toml`: `409 child_port_busy` o `409 child_external_provider_conflict` conserva la configuración y revierte el binario recién instalado. Home envía la clave por stdin, inicia `ocx-child serve` y verifica `/v1/catalog` autenticado. El dashboard indica **Ligero**. Desconectar restaura `~/.codex` y detiene el relay sin procesos, conservando el binario para reconectar. `--purge` de `ocx link revoke` también lo elimina, mediante su ruta verificada, nunca otro de PATH. Si falta o no confirma borrado, conserva el enlace y falla; permite reintentar, desconectar sin purga o limpiar manualmente. No admite purge para una instalación completa.
+
+En un Child completo, `ocx disconnect` reinicia el runtime cliente activo para servir independiente. Si falla distingue `ocx restart`, `ocx service restart` o inspección con `ocx status` y `ocx connect status` según propietario y conexión. Desktop o un servicio habilitado y activo pueden relanzarlo por SSH. Un servicio que no pueda verificarse relanzable conserva el proceso. Un simple `OCX_SERVICE=1`, incluidos `ocx claude`, `ocx codex` y `ocx opencode`, conserva el comportamiento anterior. Versiones antiguas deben reiniciar una vez con la nueva versión.
+
+`ocx link diagnostics` consulta solo archivos locales, sin proxy ni modificaciones: `--limit <n>` admite 1–1000, por defecto 200; `--since <iso-time|epoch-ms>` y `--json` usan `ocx.link.diagnostics/1`. Informa `skipped` para líneas no reconocidas y `files` con `refused` si hay enlaces o archivos no regulares. El dashboard usa la autoridad de estado de enlaces y muestra registros propios del Child.
+
+En un Home con bind `0.0.0.0`, el token administrativo no autoriza el listener público ni el de gestión vía Tailscale para leer enlaces. macOS/Linux ofrecen `<OPENCODEX_HOME>/run/control-<port>.sock`, socket privado que solo sirve `GET /api/link/status` con token; la CLI lo elige automáticamente. Windows y versiones anteriores conservan TCP, que devuelve `403` en este caso.
+
+<a id="lightweight-child-cleanup"></a>
+
+### Desconexión y recuperación del Child
+
+En el Home, `ocx link revoke --link-id <id>` desconecta sin borrar el binario ligero. `ocx link revoke --link-id <id> --purge` solicita además su eliminación, o usa `ocx-child detach --purge` desde el propio Child. Home ejecuta la copia plantada y verificada —`ocx-child.exe` en Windows—, no otra encontrada en PATH. Si falta o no confirma el borrado, informa error y conserva el enlace para reintentar o desconectar sin purga. Se rechaza la purga de una instalación completa; los enlaces antiguos primero verifican el tipo de Child. El agente ligero usa el `CODEX_HOME` elegido para restaurar el enrutamiento y cerrar el relay.
+
+Las operaciones que reinician Codex completo o actualizan un Child requieren `--yes`; una lectura no concede ese permiso. `ocx link policy` es local al Home: se persiste bajo la configuración de OpenCodex y no modifica el `config.toml` de Codex por sí solo. La API de políticas usa `PUT` con la autorización de administración habitual; una política de Home no puede activar la captura SSH local de otro equipo.
+
+Un error `Child restart preflight` con `child_restart_unsupported` describe la condición y el comando que la resuelve: un Child aún vinculado requiere desconectar y reiniciar; un runtime de cliente requiere `ocx restart`; un Hub, `ocx hub disable`; un runtime antiguo requiere actualizar; un puerto distinto del configurado requiere reiniciar. Inspecciona el estado antes de repetir una operación de resultado incierto.
diff --git a/docs-site/src/content/docs/es/guides/remote-workspace.md b/docs-site/src/content/docs/es/guides/remote-workspace.md
new file mode 100644
index 00000000000..16d42c085d9
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/remote-workspace.md
@@ -0,0 +1,224 @@
+---
+title: "Espacio de trabajo remoto"
+description: "Mantén Codex, Claude Code, Pi y sus sesiones de acceso en un Hub OCX, mientras otros equipos con solo OCX aportan el espacio de trabajo y el entorno de compilación."
+---
+
+Para conectar equipos mediante SSH, consulta [Enlace remoto](/es/guides/remote-link/).
+
+Remote Workspace permite ejecutar los agentes de programación en un Hub de OpenCodex, mientras otro equipo aporta los archivos del proyecto y los recursos para ejecutar comandos, pruebas y compilaciones. Puedes controlar la sesión desde un teléfono o un tercer equipo mediante el dashboard del Hub.
+
+```text
+Phone browser -> Computer 1 OCX Hub -> encrypted channel -> Computer 2 OCX Executor
+                 Codex / Claude / Pi                       project and commands
+                 logins and sessions                      no coding CLI login
+```
+
+El Ejecutor solo necesita OpenCodex. No necesita Codex, Claude Code, Pi, una sesión de ChatGPT ni una clave API de un proveedor. Abre una conexión WebSocket saliente hacia el Hub, por lo que no necesita un puerto público ni una redirección de puertos en el router.
+
+:::caution[Base experimental]
+Remote Workspace requiere activación explícita y todavía no está listo para producción. Linux ofrece herramientas de archivos y permite ejecutar comandos mediante bubblewrap cuando se cumplen las condiciones de aislamiento. Windows y macOS solo ofrecen herramientas de archivos: sus auxiliares nativos oficiales rechazan tanto las comprobaciones de aislamiento como las solicitudes de comandos. La ejecución de comandos en Windows seguirá sin admitirse hasta verificar que el componente responsable de su ciclo de vida conserva el control de la limpieza durante una cancelación. Si el Ejecutor no admite comandos, estos nunca se ejecutan en el Hub como alternativa.
+:::
+
+<a id="rpc-compatibility-and-timeouts"></a>
+
+## Compatibilidad con RPC y tiempos de espera
+
+Remote Workspace utiliza RPC v2 cifrado. Tanto el Hub como cada Ejecutor deben admitir v2. Las conexiones con componentes RPC v1 se rechazan de forma segura, sin recurrir a la ejecución inmediata; actualiza el Hub y los Ejecutores juntos.
+
+Al agotarse el tiempo de espera, se solicita la cancelación al Ejecutor, pero eso no confirma que se haya cancelado. Una autorización puede estar ya en tránsito o la operación autorizada puede estar ejecutándose. El tiempo de espera predeterminado de RPC es de 65 segundos; `timeoutMs` acepta valores de 1 a 120.000 milisegundos, ambos incluidos.
+
+<a id="set-up-the-hub"></a>
+
+## Configurar el Hub
+
+El equipo 1 conserva las sesiones de acceso de los agentes de programación y las sesiones de los modelos. Instala allí los agentes que quieras usar, inicia sesión en ellos y ejecuta OpenCodex como Hub:
+
+Mantén el Hub en ejecución en primer plano en esta terminal:
+
+```bash
+ocx config set runtimeRole hub
+OCX_REMOTE_WORKSPACE_ENABLED=1 ocx start
+```
+
+Mientras el Hub sigue en ejecución, abre otra terminal e inicia el dashboard:
+
+```bash
+ocx gui
+```
+
+Establece `OCX_REMOTE_WORKSPACE_ENABLED=1` en el propio proceso del Hub. Configurarlo solo al ejecutar un comando del dashboard no habilita un servicio que ya está en ejecución. Sin activación explícita, el Hub devuelve el estado deshabilitado sin crear claves del espacio de trabajo ni comprobar los entornos de ejecución de los agentes.
+
+Usa un despliegue HTTPS con autenticación para abrir el dashboard desde un teléfono u otro equipo. Consulta [Despliegue de Remote Hub](/es/guides/remote-hub/) para conocer el patrón admitido de acceso a la interfaz de administración mediante Tailscale. No expongas un puerto local del dashboard sin autenticación.
+
+Codex Remote Workspace utiliza los perfiles de permisos actuales de App Server. Si la configuración de Codex seleccionada en el Hub todavía establece las claves heredadas `sandbox_mode` o `sandbox_workspace_write`, el dashboard muestra Codex como no disponible en lugar de iniciarlo con un aislamiento más débil. Migra ese perfil de Codex antes de usar la función; no configures a la vez el sandbox heredado y un perfil de permisos.
+
+<a id="inspect-the-hub-without-starting-a-session"></a>
+
+## Inspeccionar el Hub sin iniciar una sesión
+
+```bash
+ocx remote-workspace hub --help
+ocx remote-workspace hub status --json
+ocx remote-workspace hub runtimes --json
+ocx remote-workspace hub sessions --json
+```
+
+Estos comandos consultan la interfaz de administración del Hub seleccionado que está en ejecución. El comando existente `remote-workspace status` sigue leyendo el estado local del Ejecutor. La consulta de estado devuelve `{available:true,devices,runtimes,sessions}`; la de entornos de ejecución devuelve `{runtimes:{codex:{available,...},claude:{available,...},pi:{available,...}}}`; y la de sesiones devuelve `{sessions:[...]}`. La disponibilidad de los entornos de ejecución se representa como un objeto, no como un arreglo; consultarla puede comprobar si sus ejecutables están disponibles. Las raíces del dispositivo muestran identificadores y etiquetas, no las rutas del sistema de archivos del Ejecutor. Las sesiones incluyen eventos públicos recientes; la salida de terminal destinada a personas escapa los caracteres de control.
+
+Un Hub disponible, aunque tenga listas vacías de dispositivos y sesiones, produce el código de salida 0. Si la función está desactivada en el Hub, el despachador externo puede devolver HTTP 200 con `available:false`, listas vacías de dispositivos y sesiones y `runtimes:{}`. En ese caso concreto, la CLI informa de que no está disponible, muestra una instrucción fija sobre el Hub y su activación, y termina con el código 1. No presenta la indisponibilidad como una consulta exitosa sin resultados. Una respuesta HTTP 409 interna que indica que el proceso no es un Hub produce el código de salida 5 y una indicación en stderr. El rol de cliente, los errores de transporte y las respuestas mal formadas también se consideran fallos.
+
+Si no está disponible, comprueba que consultas el Hub previsto y que tiene activada la opción `OCX_REMOTE_WORKSPACE_ENABLED=1`; no cambies la configuración de forma automática para recuperarlo. Estas consultas no autorizan ni realizan emparejamientos, creación de sesiones, envío de mensajes, revocaciones ni cambios de confianza. Esas acciones pertenecen a los flujos del dashboard y de las sesiones que se describen a continuación.
+
+<a id="pair-an-executor"></a>
+
+## Emparejar un Ejecutor
+
+1. Empareja el navegador con el Hub mediante el panel de emparejamiento del dashboard. Ejecuta en el Hub el comando `ocx gui pair --origin` que se muestra e introduce el código de un solo uso. Una sesión local o de Tailscale iniciada automáticamente puede consultar el estado, pero no controlar Remote Workspace.
+2. Abre **Espacio de trabajo remoto** en el dashboard del Hub ya emparejado.
+3. Selecciona **Crear código de emparejamiento**.
+4. En el equipo 2, entra en el directorio del proyecto que quieras compartir.
+5. Copia el comando generado para **Terminal Linux / macOS** o **Windows PowerShell**, según el equipo. Empareja el directorio actual y mantiene conectado `ocx remote-workspace agent` en esa terminal.
+
+El flujo manual equivalente es:
+
+```bash
+# Bash only: if using zsh, run bash first in this terminal.
+cd /path/to/project
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" || pairing_status=$?
+  unset pairing_code
+  if [ "$pairing_status" -eq 0 ]; then ocx remote-workspace agent; fi
+  unset pairing_status
+else
+  unset pairing_code
+fi
+```
+
+En Windows PowerShell, usa el comando que muestra el dashboard. Su equivalente manual es:
+
+```powershell
+$pairingSecret = Read-Host 'Pairing code' -AsSecureString
+$pairingBuffer = [IntPtr]::Zero
+$pairingExitCode = 1
+try {
+  $pairingBuffer = [Runtime.InteropServices.Marshal]::SecureStringToBSTR($pairingSecret)
+  $pairingCode = [Runtime.InteropServices.Marshal]::PtrToStringBSTR($pairingBuffer)
+  $pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
+    --pairing-code-stdin --root (Get-Location).Path
+  $pairingExitCode = $LASTEXITCODE
+} finally {
+  if ($pairingBuffer -ne [IntPtr]::Zero) {
+    [Runtime.InteropServices.Marshal]::ZeroFreeBSTR($pairingBuffer)
+  }
+  $pairingSecret.Dispose()
+  Remove-Variable pairingCode, pairingSecret, pairingBuffer -ErrorAction SilentlyContinue
+}
+if ($pairingExitCode -eq 0) { ocx remote-workspace agent }
+Remove-Variable pairingExitCode
+```
+
+El ejecutable actual de Bun que usa OCX se añade automáticamente al sandbox de Linux como un único archivo de solo lectura. Si el proyecto necesita herramientas instaladas por el usuario fuera de las rutas del sistema, incluye explícitamente esa cadena de herramientas en el emparejamiento, sin exponer el resto del directorio personal:
+
+```bash
+# Bash only: if using zsh, run bash first in this terminal.
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" \
+    --toolchain-root "$HOME/.nvm/versions/node/v24/bin" || pairing_status=$?
+  unset pairing_code pairing_status
+else
+  unset pairing_code
+fi
+```
+
+El código fuente del auxiliar nativo se incluye en el paquete para su revisión. Compilarlo no habilita la ejecución de comandos en Windows ni macOS en esta implementación. `--executor-helper` sigue siendo un selector de auxiliares revisados; que exista un binario o una ruta configurada no demuestra que se admita ejecutar comandos.
+
+El código de un solo uso se lee de la entrada estándar, no de los argumentos de la línea de comandos. El emparejamiento crea una clave de firma local y un token de portador limitado a ese dispositivo. El Hub solo almacena el hash del token y nunca recibe la ruta real del Ejecutor. Detén el agente en primer plano con Ctrl+C; al ejecutarlo de nuevo se reconecta el mismo dispositivo.
+
+Comprueba el registro local sin mostrar secretos:
+
+```bash
+ocx remote-workspace status
+```
+
+<a id="start-a-remote-coding-session"></a>
+
+## Iniciar una sesión de codificación remota
+
+En el dashboard, elige:
+
+1. el equipo conectado;
+2. una carpeta de espacio de trabajo aprobada localmente;
+3. Codex, Claude Code o Pi en el Hub; y
+4. un modo de acceso.
+
+**Solo lectura** es el modo predeterminado y permite listar directorios y leer archivos. La opción de escritura aparece como **Editar archivos y ejecutar comandos** solo si el Ejecutor ha superado una comprobación del sandbox de comandos; en caso contrario, aparece como **Editar solo archivos**. El dashboard muestra dos ubicaciones distintas: el modelo y la sesión de acceso permanecen en el Hub, mientras las operaciones sobre el espacio de trabajo se ejecutan en el equipo seleccionado.
+
+Envía mensajes desde el dashboard del Hub en el equipo 1, el equipo 3 o un teléfono. La sesión no puede cambiar de equipo o carpeta sin avisar. Si el Ejecutor se desconecta, la sesión pasa al estado **Ejecutor sin conexión** y nunca recurre al sistema de archivos del Hub como alternativa.
+
+Al enviar un mensaje, se confirma de inmediato que ha sido aceptado; el dashboard consulta periódicamente la sesión para conocer el progreso y la finalización. Si se pierde esa confirmación, el borrador permanece visible con un aviso de estado de envío desconocido. Comprueba el progreso de la sesión antes de volver a enviarlo; el dashboard nunca reenvía un mensaje automáticamente.
+
+Si el proceso Pi termina o falla su extensión mientras empieza un turno, la sesión informa del fallo aunque Pi todavía no haya confirmado ese turno.
+
+**Detener** sigue disponible mientras se procesa un mensaje. Interrumpe el turno del agente de programación del Hub, cancela el comando activo del Ejecutor y evita que una respuesta tardía vuelva a abrir la sesión detenida.
+
+<a id="work-with-sessions-side-by-side"></a>
+
+## Trabajar con sesiones lado a lado
+
+La lista de sesiones de la izquierda abre la sesión seleccionada en el panel activo. Arrastra una sesión al borde izquierdo, derecho, superior o inferior de otro panel para dividir el área de conversación. Puedes mostrar hasta cuatro sesiones diferentes a la vez. Si una sesión ya está visible, se mueve entre paneles en lugar de abrir otro editor de mensajes para la misma sesión.
+
+Como alternativa accesible por teclado, usa **Dividir a la derecha** o **Dividir debajo**, junto a la sesión. Arrastra un separador para cambiar el tamaño de los paneles, o dale el foco y usa las teclas de flecha. **Inicio (Home)** y **Fin (End)** lo llevan al tamaño mínimo y máximo, respectivamente. Cada sesión conserva su propio borrador, estado de envío y acción Detener; un turno pendiente en un panel no bloquea otra sesión. **Cerrar panel** solo cambia la distribución; no detiene la sesión.
+
+La distribución se restaura para este Hub en el mismo navegador. Solo se guardan los identificadores de sesión, las posiciones de los paneles y los tamaños de los separadores; los borradores y las respuestas del modelo no se escriben en el almacenamiento del navegador. Recargar la página borra los borradores sin enviar. En pantallas de hasta 760px de ancho, los paneles se apilan verticalmente y no muestran separadores para ajustar su tamaño; las posiciones y los tamaños guardados vuelven a aplicarse en pantallas más anchas.
+
+Esta vista se comparte entre el dashboard del navegador y el de OpenCodex Desktop. Si usas la CLI, puedes abrirla con `ocx gui` y seleccionar **Espacio de trabajo remoto** después de configurar el Hub de la forma habitual. No modifica la interfaz de terminal de `codex` ni la distribución de las conversaciones en la aplicación oficial de escritorio ChatGPT/Codex, que es independiente.
+
+<a id="restart-and-reconnect-behavior"></a>
+
+## Comportamiento al reiniciar y reconectar
+
+El Hub conserva metadatos de sesión de tamaño limitado y una pequeña instantánea de los eventos recientes. Tras reiniciar el Hub, una sesión sin terminar espera a su Ejecutor original. Cuando el dispositivo se reconecta, el siguiente mensaje reanuda el hilo original de Codex, la sesión de Claude Code o el identificador de sesión de Pi.
+
+Claude Code crea su historial persistente al completar el primer mensaje. Si el Hub se detiene antes de que una nueva sesión de Claude complete algún mensaje, no habrá una conversación que reanudar; inicia una sesión nueva.
+
+Un cambio en el manifiesto de capacidades no debilita una sesión existente sin avisar. Inicia una sesión nueva si el Ejecutor pierde el aislamiento de comandos o cambian sus herramientas disponibles. Revocar un equipo cierra su socket y detiene las sesiones vinculadas a él.
+
+<a id="security-boundaries"></a>
+
+## Límites de seguridad
+
+- Las credenciales de los proveedores y el historial de los agentes de programación permanecen en el Hub.
+- Las claves privadas, el token de portador del dispositivo y las rutas raíz reales del Ejecutor permanecen en su estado local de OCX, accesible solo por su propietario.
+- Cada listener limita los intentos fallidos de emparejamiento por la identidad del extremo remoto que observa el kernel. Diez códigos fallidos en diez minutos producen un `429` genérico con `Retry-After`; el Hub conserva una cantidad limitada de hashes de esas identidades, con caducidad. Los usuarios de Tailscale Serve comparten el contador de loopback del listener de administración porque una solicitud local directa podría falsificar su encabezado de identidad.
+- Cada sesión de trabajo utiliza una negociación efímera P-256 ECDH firmada con Ed25519 y mensajes AES-256-GCM ordenados.
+- Un socket no se muestra como conectado hasta que ambos extremos coinciden en el manifiesto de capacidades actual.
+- La reconexión puede retirar una capacidad si su sandbox local deja de estar disponible, pero nunca añade una capacidad fuera de la autorización registrada durante el emparejamiento.
+- Cada solicitud queda vinculada a un único hilo del modelo, dispositivo, raíz, modo de acceso y conjunto de capacidades.
+- Las rutas son relativas, se normalizan a su forma canónica y se mantienen dentro de los límites permitidos. Se rechazan los intentos de salir de la raíz mediante enlaces simbólicos, uniones de directorio o referencias al directorio padre. También se rechazan los nombres de dispositivo de Windows, los flujos de datos alternativos y los alias con puntos o espacios finales.
+- Las operaciones del Ejecutor se procesan en serie. Se vuelve a comprobar la identidad de los archivos abiertos y se verifican otra vez los hashes de escritura justo antes del reemplazo atómico. Sustituir una raíz aprobada exige emparejarla de nuevo; las raíces de las herramientas se revalidan antes de cada comando.
+- La lectura y escritura rechazan archivos con enlaces duros. Antes de ejecutar comandos, OCX examina como máximo 250.000 entradas del espacio de trabajo y deshabilita la ejecución si alguna entrada que no sea un directorio tiene varios enlaces. Un sandbox basado en rutas no puede demostrar si otro nombre de ese inodo está fuera de la raíz aprobada.
+- Los comandos de Linux se ejecutan mediante bubblewrap con un espacio de trabajo escribible, un entorno sin las variables heredadas, espacios de nombres de procesos privados, el ejecutable actual de Bun de OCX como un único archivo de solo lectura, límites de salida y tiempo de espera, y la red desactivada de forma predeterminada. Las pruebas específicas de confinamiento requieren un entorno alojado configurado expresamente; que la suite general pase no demuestra que se hayan ejecutado.
+- macOS solo anuncia herramientas de archivos. Un grupo de procesos no puede contener a un descendiente después de que este llame a `setsid()`. Además, importar un perfil amplio del sistema Apple Seatbelt solo para iniciar un comando expondría permisos sobre servicios del sistema ajenos a esa tarea. Por eso, el auxiliar nativo rechaza tanto las comprobaciones de aislamiento como las solicitudes directas de comandos hasta que OCX disponga de un componente con autoridad limitada y revocable para confinar los procesos descendientes.
+- Las solicitudes nativas de comandos en Windows y macOS se rechazan. Las pruebas de rechazo del auxiliar directo deben distinguirse de la evidencia de confinamiento funcional de comandos; la aceptación de comandos en Windows sigue pendiente.
+- El auxiliar nativo fijado debe estar fuera de todos los espacios de trabajo aprobados que permitan escritura. OCX lo comprueba antes de anunciar que admite comandos y justo antes de cada ejecución, para impedir que el código del espacio de trabajo sustituya el binario que aplica el siguiente sandbox.
+- Detener una sesión cancela el comando activo del Ejecutor y limpia el proceso del modelo en el Hub y el puente local de herramientas de loopback. En Windows se detiene todo el árbol de procesos del contenedor de npm bajo su control, sin dejar activo el proceso hijo de Node; Linux y macOS solo fuerzan la terminación de una CLI si esta ignora el plazo de cierre ordenado.
+
+El Hub ve deliberadamente los mensajes y las respuestas del modelo porque ejecuta el agente de programación. El cifrado de extremo a extremo protege los datos de RPC del Ejecutor. El Hub emparejado es un componente de confianza que selecciona raíces aprobadas mediante WSS autenticado; puede ver su propia conversación con el modelo.
+
+<a id="current-scope"></a>
+
+## Alcance actual
+
+Remote Workspace no copia ni sincroniza credenciales con otros equipos. Es independiente del enrutamiento de proveedores de Remote Hub y de cualquier futuro producto de cómputo alojado o Super Sync. Para una versión de producción todavía hacen falta un paquete firmado del auxiliar de Windows, pruebas de CI nativas sobre los binarios exactos, una revisión independiente del mantenedor y una prueba real de aceptación con tres equipos.
+
+<a id="prompt-acceptance-api"></a>
+
+## API de aceptación de mensajes
+
+`POST /api/remote-workspace/sessions/:id/prompt` devuelve HTTP 202 con la instantánea de la sesión que aceptó el mensaje. Su identificador de sesión y la secuencia monotónica de eventos identifican esa instantánea; 202 no significa que el turno del modelo haya terminado. Consulta periódicamente `GET /api/remote-workspace/sessions` para obtener los eventos posteriores y saber si la sesión llegó a un estado final. La reconexión y la reanudación del entorno de ejecución siguen ocupadas mientras ese turno está activo. Si se pierde la confirmación, no se sabe si el mensaje fue aceptado; los clientes deben consultar el estado antes de decidir si lo reenvían.
diff --git a/docs-site/src/content/docs/es/guides/response-inspection.md b/docs-site/src/content/docs/es/guides/response-inspection.md
new file mode 100644
index 00000000000..0f09f0882e3
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/response-inspection.md
@@ -0,0 +1,22 @@
+---
+title: "Inspección de respuestas y respuestas grandes"
+description: "Cómo se relacionan la retención limitada de diagnósticos, la inspección en streaming y la entrega de respuestas."
+---
+
+OpenCodex mantiene los diagnósticos de respuesta limitados sin hacer que el límite de registro sea un límite en los bytes entregados a su cliente. Otros límites de proveedor, solicitud y transporte siguen aplicándose de forma independiente.
+
+<a id="json-and-ordinary-error-responses"></a>
+
+## JSON y respuestas de error ordinarias
+
+La inspección JSON retiene como máximo 32 MiB de bytes fuente. Si el cuerpo excede esa asignación, el registro deja caer su copia retenida y continúa reenviando la respuesta original. No analiza un prefijo truncado como uso autorizado o metadatos del modelo. El uso ya suministrado por otra ruta de confianza se conserva; el uso faltante no se reemplaza con un cero inventado. Los diagnósticos de error ordinarios no JSON retienen solo los primeros 8 KiB y pasan a través de la lógica de redacción existente.
+
+El cliente recibe trozos a medida que los lee en lugar de esperar una inspección de diagnóstico de todo el cuerpo. Un fallo de lectura se registra como 502 y la cancelación como 499 en el historial de solicitudes; estos resultados de diagnóstico no reescriben las cabeceras HTTP que ya se han enviado. El registro se finaliza una vez.
+
+<a id="streaming-responses"></a>
+
+## Respuestas de streaming
+
+La inspección nativa SSE se detiene cuando se adelanta demasiado al consumo del cliente. La asignación es de 32 MiB más la sobrecarga de código fuente / nativo-prefetch, no un límite total de tamaño de respuesta o un límite en toda la memoria del proceso. Aún se inspecciona una respuesta más larga a través de su evento de finalización real, incluido el uso del terminal y el estado de continuación.
+
+Después de que el cliente se desconecta, el drenaje limitado existente aún puede observar una finalización tardía de hasta 15 segundos o 32 MiB de inspección adicional. Un cierre forzado es diferente: descarta candidatos no completados en lugar de registrarlos como una respuesta completa. La selección de transporte existente y los límites de memoria WebSocket no cambian. No se requiere ninguna configuración nueva.
diff --git a/docs-site/src/content/docs/es/guides/routing-profile-editor.md b/docs-site/src/content/docs/es/guides/routing-profile-editor.md
new file mode 100644
index 00000000000..898cead409a
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/routing-profile-editor.md
@@ -0,0 +1,81 @@
+---
+title: "Editor de perfiles de enrutamiento"
+description: "Crea, edita, valida, simula y elimina perfiles de políticas de enrutamiento desde el dashboard de OpenCodex."
+---
+
+La pestaña **Modelos → Routing** en el panel de control OpenCodex puede administrar `config.routingProfiles` sin editar `config.json` a mano.
+
+<a id="create-a-profile"></a>
+
+## Crear un perfil
+
+1. Abra **Enrutamiento** en el panel de control.
+2. Seleccione **Crear perfil**.
+3. Introduzca un `id`. El modelo canónico id es `policy/<id>`.
+4. Agregue uno o más candidatos explícitos de proveedor/modelo.
+5. Configure los requisitos opcionales, las ponderaciones de puntuación, los límites de costo (`onUnknownCost`, `maxEstimatedCostUsd`) y el comportamiento de evidencia desconocida.
+6. Guardar el perfil.
+
+Los ID de perfil son inmutables después de la creación. Para usar un id diferente, cree un nuevo perfil y elimine el antiguo después de actualizar las llamadas.
+
+<a id="validation-and-persistence"></a>
+
+## Validación y persistencia
+
+El panel de control envía el mismo objeto de perfil utilizado por `config.routingProfiles` a la administración API. El servidor valida el candidato completo antes de escribirlo:
+
+- ids y alias deben seguir las reglas de nombres y colisiones de perfiles de enrutamiento;
+- todos los proveedores candidatos deben existir y estar habilitados;
+- Los candidatos duplicados son rechazados.
+- Los límites y requisitos numéricos deben permanecer dentro de sus rangos admitidos; y
+- al menos un peso de optimización debe ser positivo.
+
+Un guardado exitoso mantiene el perfil a través del escritor de configuración normal, reconcilia el estado en vivo y actualiza el catálogo de modelos. Los errores de validación dejan la configuración anterior sin cambios y se muestran en el editor.
+
+Si configuras `limits.maxEstimatedCostUsd`, `limits.onUnknownCost` vale `"allow"` por defecto: una estimación desconocida no excluye al candidato por ese límite, y las trazas de simulación y ejecución muestran `cost.capOutcome: "unknown-allowed"` para indicar que no se pudo comprobar el costo. Usa `"exclude"` si el límite debe rechazar candidatos cuyo costo se desconoce: `cost-limit-unknown` y `cost.capOutcome: "unknown-excluded"`. Configurar solo `onUnknownCost`, sin un límite, no tiene efecto ni genera un resultado de límite. Por separado, `unknownEvidence.cost` aún puede excluir o penalizar precios desconocidos.
+
+<a id="dry-run-a-saved-profile"></a>
+
+## Ejecutar en seco un perfil guardado
+
+Las capacidades candidatas usan la configuración efectiva del proveedor después de que se aplican las anulaciones del registro. Por lo tanto, los requisitos locales (`localOnly` y `remoteAllowed`) utilizan la dirección de flujo ascendente efectiva. Si esa dirección no se puede clasificar, la configuración `unknownEvidence.capability` del perfil decide la elegibilidad. Una configuración de proveedor no válida que no se puede resolver siempre se excluye con `route-unavailable`, incluso cuando se permiten capacidades desconocidas. Los proveedores desaparecidos o desactivados también se excluyen con `route-unavailable` antes de anotar.
+
+Seleccione un perfil guardado y use **Evaluación en seco** para agregar evidencia de solicitud, como el tamaño de la ventana de contexto, el uso de herramientas, la entrada de imágenes o la salida estructurada. Dry-run evalúa la elegibilidad y la puntuación, pero nunca envía una solicitud de modelo ascendente.
+
+Las ediciones no guardadas no son usadas por dry-run. Guarde primero el perfil para que la revisión y la evaluación mostradas se refieran a la misma configuración.
+
+<a id="management-api"></a>
+
+## API de administración
+
+El editor utiliza estos puntos finales:
+
+- `GET /api/routing-profiles` lista perfiles normalizados y revisiones.
+- `PUT /api/routing-profiles` crea o actualiza un perfil. Envíe `mode: "create"` o `mode: "update"`; el modo create se niega a sobrescribir un id existente.
+- `DELETE /api/routing-profiles?id=<id>` elimina un perfil.
+- `POST /api/routing-profiles/dry-run` evalúa un perfil guardado sin enviar aguas arriba.
+
+Ejemplo de guardar carga útil:
+
+```json
+{
+  "id": "fast",
+  "mode": "create",
+  "profile": {
+    "alias": "ocx/fast",
+    "candidates": [
+      { "provider": "anthropic", "model": "claude-sonnet-5" },
+      { "provider": "openai", "model": "gpt-5.6" }
+    ],
+    "require": { "tools": true, "minContextWindow": 128000 },
+    "optimize": { "latency": 0.55, "health": 0.25, "cost": 0.1, "quota": 0.1 },
+    "limits": { "maxEstimatedCostUsd": 0.5, "onUnknownCost": "allow" },
+    "unknownEvidence": {
+      "capability": "exclude",
+      "health": "penalize",
+      "quota": "penalize",
+      "cost": "penalize"
+    }
+  }
+}
+```
diff --git a/docs-site/src/content/docs/es/guides/sidecars.md b/docs-site/src/content/docs/es/guides/sidecars.md
new file mode 100644
index 00000000000..1b23002039c
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/sidecars.md
@@ -0,0 +1,169 @@
+---
+title: "Sidecars: búsqueda web y visión"
+description: "Añade búsqueda web y comprensión de imágenes a los modelos enrutados mediante sidecars de ChatGPT, Anthropic y otros backends explícitos."
+---
+
+No todos los modelos enrutados ofrecen **búsqueda web alojada** o **entrada de imágenes** de forma nativa. opencodex cubre esas capacidades con dos sidecars. Ambos admiten una sesión de ChatGPT mediante un proveedor `forward` o credenciales Anthropic OAuth guardadas. La búsqueda también admite Grok OAuth con el backend `xai` seleccionado explícitamente. Los errores del sidecar se devuelven como resultados de herramienta o marcadores de imagen, sin hacer fallar todo el turno.
+
+:::note[Selección automática del backend]
+La configuración explícita de `backend` tiene prioridad. Cuando no se configura, cada sidecar usa su propio valor predeterminado:
+**Búsqueda web** usa `openai` por defecto; `anthropic` y `xai` solo se usan cuando se configuran explícitamente. El backend de búsqueda web `xai` requiere una cuenta Grok OAuth almacenada y utilizable, y no cambia a otro backend si esa cuenta no está disponible.
+**Visión** usa `anthropic` cuando un proveedor Anthropic OAuth habilitado tiene una cuenta activa que no está marcada como `needsReauth`; de lo contrario, usa `openai`. Seleccionar `anthropic` explícitamente sin esa credencial rechaza la operación. Visión solo admite `openai`, `anthropic` y `routed`; los modelos de visión xAI elegibles usan `routed`. Para ambos sidecars, `openai` requiere autenticación de inicio de sesión ChatGPT y un proveedor `forward` habilitado.
+:::
+
+Al cargar el archivo, se retiran los destinos de modelos retirados de OpenCode Free de las
+configuraciones globales o de `claudeCode` de `visionSidecar` y `webSearchSidecar`. El sidecar afectado
+queda deshabilitado explícitamente y conserva sus demás ajustes. Elige un destino compatible antes
+de volver a habilitarlo. Los destinos válidos y los valores predeterminados de las secciones ausentes
+no cambian.
+
+<a id="additional-web-search-backends-explicit-only"></a>
+
+## Backends de búsqueda web adicionales (solo explícitos)
+
+Además de ChatGPT y Claude, hay tres backends de búsqueda adicionales. Todos requieren **selección explícita**: encontrar una credencial no los activa. Si falta la credencial necesaria, no se crea un plan de sidecar ni se sustituye por otro backend; la solicitud sigue la ruta normal.
+
+| Backend | Ejecución | Credenciales | Notas |
+| --- | --- | --- | --- |
+| `xai` | Grok alojado `web_search` (+ opt-in `x_search` ) en `api.x.ai` Responses | Almacenado Grok OAuth (`ocx login xai`) | `webSearchSidecar.xSearch` permite la búsqueda X con `allowedXHandles` / `excludedXHandles` (máximo 20, mutuamente excluyentes) e ISO `fromDate` / `toDate`. Modelo predeterminado `grok-4.6`. |
+| `gemini` | Fundamentación mediante `google_search` en el transporte Antigravity | Almacenado Antigravity OAuth con un proyecto descubierto (`ocx login google-antigravity`) | Modelo predeterminado `gemini-3.8-flash`; el razonamiento selecciona el nivel coincidente. |
+| `exa` | Exa Search API (resumen de resultados no LLM) | `webSearchSidecar.exaApiKey` | La clave es solo escritura a través de la administración API (nunca se hizo eco, se redactó desde los registros). No se aplica ningún modelo de sidecar. |
+
+<a id="web-search-sidecar"></a>
+
+## Sidecar de búsqueda web
+
+Cuando Codex solicita `web_search` para un modelo enrutado sin paso, opencodex:
+
+1. **Sustituye** la herramienta alojada `web_search` por una función sintética `web_search(query)` que el modelo enrutado puede invocar. Conserva las opciones originales para la llamada al sidecar.
+2. Ejecuta el modelo en un pequeño **bucle de agente**. Cuando llama a `web_search`, el sidecar OpenAI usa `web_search` con `gpt-5.6-luna` por defecto; el de Anthropic usa `web_search_20250305` con `claude-sonnet-5`. La respuesta y sus citas se convierten en un resultado de herramienta. El backend xAI usa la búsqueda alojada `web_search` con `grok-4.6` por defecto y añade `x_search` a la misma solicitud si está habilitado.
+3. **Repite** hasta que el modelo responda o el total de consultas reales alcance `maxSearchesPerTurn` (3 por defecto). Al alcanzar el límite, retira la herramienta de búsqueda y solicita una respuesta final. Las llamadas a herramientas reales del cliente, como `apply_patch` o shell, terminan el turno para que Codex las reciba.
+
+Cuando el modelo agrupa varias consultas en una llamada `web_search`, sus resultados comparten un resultado de herramienta de 8.000 caracteres. El presupuesto se divide entre las consultas antes de que se corte nada, por lo que ninguna consulta desaparece del resultado. Las respuestas acortadas y las fuentes no listadas están marcadas con sus tamaños originales, lo que permite que el modelo indique los resultados recortados de las búsquedas que no encontraron nada. Los giros de salida estructurada reciben la misma información que un documento válido JSON. Si una llamada solicita más consultas de las que un resultado puede describir, opencodex enumera el estado de cada consulta sin su contenido y cuenta las consultas que no pudo enumerar.
+
+Cada iteración del modelo enrutado solicita `stream: true` al proveedor. Sin embargo, opencodex almacena por defecto todos los eventos semánticos antes de decidir si buscar o devolver la respuesta final. Solo obtiene de inmediato el estado y los encabezados finales de la primera iteración, junto con sus rotaciones de claves por 429. Las llamadas sintéticas de búsqueda y las salidas preliminares no se muestran al cliente como salida del modelo.
+
+La opción `webSearchSidecar.streamRoutedModelOutput`, desactivada por defecto (`false`), transmite en vivo los deltas iniciales de texto y razonamiento de cada iteración, igual que la ruta sin sidecar. Esa ventana de transmisión se cierra definitivamente al comenzar la primera llamada a herramienta; la decisión de interceptar `web_search` sigue siendo atómica y la reproducción final omite lo ya transmitido. Esto hace visible el texto emitido antes de decidir buscar, que el modo almacenado descartaría, y parte de ese texto puede repetirse en la respuesta posterior. La vista general ofrece **Transmitir respuestas en vivo** en la tarjeta de búsqueda web (`PUT /api/sidecar-settings`, campo `webSearch.streamRoutedModelOutput`).
+
+Esta opción también se aplica a los adaptadores que gestionan sus propios turnos, incluidos Devin y Cursor. Cuando los sidecars de búsqueda y de imagen/vídeo son elegibles, la búsqueda tiene prioridad. Un primer evento OAuth 429 gira la cuenta en la solicitud inicial y en cada solicitud de respuesta posterior a la búsqueda, reproduciendo la solicitud con la herramienta de búsqueda y los resultados recopilados. La cancelación de una solicitud detiene las búsquedas posteriores, y la salida del bucle de búsqueda retenido comparte el límite de la memoria intermedia de traducción de la solicitud; exceder ese límite falla la respuesta en lugar de iniciar otra iteración del modelo.
+
+El texto de la fase de comentario de Kiro es independiente de esta opción: ya se transmite antes del evento terminal en el modo almacenado. Con o sin `streamRoutedModelOutput`, solo se retienen los eventos necesarios para decidir si buscar —las llamadas a herramientas y todo lo posterior al inicio de la primera llamada— hasta resolver la interceptación atómica de `web_search`.
+
+El resultado inyectado se envuelve en un límite de datos no confiables, con límite de longitud y desduplicado por URL de origen. En los giros de salida estructurada (`json_schema` / `json_object`) se entrega como compacto JSON en lugar de prosa. Para los modelos con ruta de solo texto, también se le dice al modelo de búsqueda que describa imágenes relevantes en palabras e incluya sus URL de origen.
+
+```json
+{
+  "webSearchSidecar": {
+    "enabled": true,
+    "backend": "anthropic",
+    "model": "claude-sonnet-5",
+    "reasoning": "low",
+    "maxSearchesPerTurn": 3,
+    "routedModelStallTimeoutMs": 200000,
+    "timeoutMs": 200000,
+    "streamRoutedModelOutput": false
+  }
+}
+```
+
+El backend explícito xAI usa la credencial almacenada creada por `ocx login xai`. Su bloque opcional `xSearch` permite la búsqueda X y puede restringirlo a una lista de identificadores y un rango de fechas ISO:
+
+```json
+{
+  "webSearchSidecar": {
+    "backend": "xai",
+    "model": "grok-4.6",
+    "xSearch": {
+      "enabled": true,
+      "allowedXHandles": ["xai"],
+      "fromDate": "2026-08-01",
+      "toDate": "2026-08-21"
+    }
+  }
+}
+```
+
+`allowedXHandles` y `excludedXHandles` son mutuamente excluyentes y admiten como máximo 20 cadenas cada uno. Las fechas usan `YYYY-MM-DD`. Una escritura mal formada en la API de administración devuelve `400`. Si el bloque persistido es inválido, se rechaza el plan en lugar de ampliar la búsqueda silenciosamente.
+
+El razonamiento `minimal` no se utiliza porque el backend alojado rechaza las herramientas en ese esfuerzo. Una búsqueda fallida se devuelve al modelo enrutado como un resultado de error limitado, lo que le permite responder desde el contexto que ya tiene.
+
+Hay cuatro tiempos de espera independientes. `stallTimeoutSec` es el límite base de inactividad de eventos del puente. `connectTimeoutMs` (`200000` por defecto) cubre únicamente DNS, TCP, TLS y los encabezados finales. `webSearchSidecar.routedModelStallTimeoutMs`, disponible solo en el archivo de configuración (`200000` por defecto, entero `1..2147483647`), limita la inactividad de bytes de respuesta de cada iteración del modelo y se reinicia con cada byte no vacío. `webSearchSidecar.timeoutMs` limita por separado cada solicitud de búsqueda alojada. El watchdog efectivo del puente usa `max(base stall, connect timeout, routed-model stall, sidecar timeout) + 30 seconds`. El límite de inactividad del modelo no es un límite de duración total de generación. Si el error ocurre antes de iniciar SSE, se devuelve JSON con un estado no 2xx; si ocurre después de enviar los encabezados, se comunica mediante SSE `response.failed`.
+
+<a id="vision-sidecar"></a>
+
+## Sidecar de visión
+
+El preajuste del proveedor registra `zai-glm-5-3` de Mistral como modelo de solo texto. Si el sidecar de visión está habilitado y disponible, OpenCodex describe las imágenes adjuntas y envía sus descripciones a GLM. El catálogo de Codex anuncia adjuntos de imagen para esta ruta. Después de actualizar, ejecuta `ocx sync` y cierra por completo y vuelve a abrir Codex Desktop, o recarga la ventana de VS Code. Sin una opción de reinicio, la sincronización no reinicia un app-server existente de Codex, que puede conservar el catálogo anterior. También puedes usar `ocx sync --restart-codex` para sincronizar y reiniciar los procesos de Codex coincidentes y Desktop. Termina antes el trabajo activo: ese reinicio finaliza las conversaciones en curso. Consulta la [referencia de sincronización y reinicio](/es/reference/cli/lifecycle/#ocx-sync---restart-codex---restart-app-server-only). Después de abrirlo de nuevo, elige `mistral/zai-glm-5-3` y comprueba que puedas adjuntar imágenes. No necesitas modificar la modalidad del modelo. Mistral documenta la entrada nativa en su [referencia de GLM 5.3](https://docs.mistral.ai/models/zai-glm-5-3).
+
+El enrutamiento de imágenes tiene en cuenta las capacidades del modelo. Antes del envío, opencodex resuelve sus modalidades de entrada a partir de evidencia del proveedor en ejecución, declaraciones explícitas del operador, metadatos del backend y del registro, y metadatos generados. Si el destino es de solo texto, el sidecar describe la imagen **antes** de la llamada principal y la reemplaza por texto en su posición original. Si se confirma que admite imágenes, las recibe directamente. Para los modelos personalizados desconocidos se conserva el comportamiento de compatibilidad, sin suponer que son de solo texto.
+
+Para la ruta canónica ChatGPT Codex, opencodex utiliza el paquete de metadatos `openai-codex` en lugar de los metadatos públicos OpenAI API, por lo que se respetan las diferencias de modalidad específicas del backend. La ruta rápida nativa de Chat utiliza la misma puerta y no puede omitir un veredicto conocido de solo texto. Sin un plan de sidecar disponible, las imágenes en bruto se eliminan antes de un backend probado solo de texto. Con `visionSidecar.enabled: false`, el catálogo de modelos no agrega entrada de imagen respaldada por sidecar a los modelos de solo texto, incluidas las filas personalizadas y los miembros combinados. Se conservan el soporte de imagen nativa y las modalidades de imagen configuradas explícitamente. Omitir `enabled` mantiene activado el anuncio de sidecar; la visibilidad del catálogo no establece que las credenciales o la capacidad de sidecar estén disponibles. Los combos anuncian la entrada de imágenes solo cuando cada miembro acepta imágenes, ya sea de forma nativa o a través de un sidecar habilitado, y la configuración `imageInput` del combo no está deshabilitada, por lo que los clientes como la aplicación Codex permiten archivos adjuntos en lugar de bloquearlos antes de que se ejecute el sidecar. Cuando `visionSidecar.model` está ausente o en blanco, la ruta de ejecución OpenAI, el tablero de instrumentos y la administración API usan el retroceso `gpt-5.6-luna`. El inicio sigue migrando un valor `gpt-5.4-mini` heredado explícitamente persistente a `gpt-5.6-luna`; esa migración se aplica a un valor almacenado, no a un campo de modelo ausente. Guardar un combo multimodal desde el panel inscribe automáticamente a sus miembros que no son imagen: la página Combos los envía como `visionSidecarTargets` en `PUT /api/combos`, que escribe la declaración exacta de solo texto en el proveedor del miembro, por lo que no se necesita editar y recargar la configuración manual. La inscripción nunca sobrescribe una declaración con capacidad de imagen existente, y los miembros cuyas modalidades son desconocidas o no tienen entrada de texto no están inscritos: el panel los nombra y mantiene el interruptor de imagen del combo no disponible. El modelo DeepSeek `deepseek-flash` de origen es multimodal nativo (`text` y `image`) y no usa este sidecar por defecto. `noVisionModels` explícitas o declaraciones de solo texto siguen siendo autoritativas. El primer partido `deepseek-chat`, `deepseek-reasoner` y `deepseek-v4-flash` permanece respaldado por sidecar por defecto; Las rutas Zen no han cambiado y no se probaron en esta actualización.
+
+- Las imágenes pueden provenir de mensajes de usuario, desarrollador y resultado de herramientas, incluidos los `view_image` de Codex.
+- En la ruta OpenAI (paso de inicio de sesión ChatGPT), cada imagen se envía al modelo de visión configurado sobre el punto final Responses con el `reasoning.effort` seleccionado (`low` por defecto), y su descripción reemplaza la parte de imagen en línea. La ruta Anthropic utiliza el punto final Messages con su propia asignación de pensamiento-presupuesto e ignora esta configuración específica OpenAI.
+- Para los modelos nativos con metadatos de capacidad conocidos, el razonamiento no compatible se normaliza al peldaño más alto soportado en o por debajo del nivel solicitado; si no existe ninguno, se usa el peldaño más bajo soportado. Los modelos desconocidos o personalizados siguen siendo permisivos cuando no hay metadatos de capacidad confiables.
+- Las descripciones se ejecutan con concurrencia limitada (3 a la vez, orden de entrada preservado). El contexto del usuario enviado al descritor tiene un límite de 800 caracteres, y cada descripción inyectada tiene un límite de 2.000 caracteres. La solicitud no envía `max_output_tokens`, que el backend ChatGPT rechaza.
+- Las URL de las imágenes se validan antes del reenvío: las URL de datos deben usar `png` / `jpeg` / `jpg` / `webp` / `gif`, y los datos de base64 están limitados a aproximadamente 20 MB. Solo se aceptan los esquemas `data:` y `https:`; las imágenes `https` remotas son buscadas por el backend OpenAI, no por el proxy.
+- La coincidencia de `noVisionModels` ignora un sufijo Ollama-style `:size`, por lo que una entrada `gpt-oss` también cubre `gpt-oss:120b`.
+- Si falla la descripción, el modelo recibe un marcador de error de procesamiento corto. (Sin un plan de sidecar disponible, no se intenta ninguna descripción - la imagen sin procesar se elimina, como se describió anteriormente).
+- `maxDescriptionsPerTurn` (por defecto 8) limita las nuevas descripciones por turno de modelo principal. Los golpes de caché y los duplicados del mismo turno no lo consumen. Las descripciones de imágenes exitosas de `data:` se almacenan en caché por backend, modelo, detalle, bytes de imagen y contexto de mensaje, más el esfuerzo de razonamiento en las claves de caché de OpenAI (las de Anthropic lo omiten, ya que ese campo se ignora allí); las imágenes mutables de `https:` no se almacenan en caché.
+
+La API de administración y el selector del dashboard muestran modelos capaces de aceptar imágenes. Si está disponible el backend correspondiente, siempre se ofrecen `gpt-5.6-luna` (OpenAI) y `claude-haiku-4-5` (Anthropic) como opciones de referencia. `PUT /api/sidecar-settings` puede conservar un identificador personalizado o aún desconocido por el catálogo. Un sidecar de visión enrutado configurado explícitamente sigue siendo utilizable salvo que la evidencia demuestre que no acepta imágenes. Así se conserva la elección del operador sin enviar bytes de imagen a un modelo confirmado como de solo texto.
+
+```json
+{
+  "visionSidecar": {
+    "enabled": true,
+    "backend": "openai",
+    "model": "gpt-5.6-luna",
+    "reasoning": "medium",
+    "maxDescriptionsPerTurn": 8,
+    "timeoutMs": 45000
+  }
+}
+```
+
+Un modelo está marcado solo con texto por proveedor:
+
+```json
+{
+  "providers": {
+    "ollama-cloud": {
+      "baseUrl": "https://ollama.com/v1",
+      "noVisionModels": ["glm-5.2", "gpt-oss", "qwen3-coder", "deepseek-v4-flash"]
+    }
+  }
+}
+```
+
+<a id="dashboard-controls-and-disabling"></a>
+
+## Controles del panel de control y desactivación
+
+La tarjeta del sidecar de visión en el dashboard permite activarlo o desactivarlo y configurar `maxDescriptionsPerTurn` y `timeoutMs`, además del modelo, el backend y el razonamiento. Desactivarlo conserva todos esos ajustes para la próxima activación.
+
+`PUT /api/sidecar-settings` acepta los mismos campos. Las actualizaciones parciales no modifican las claves omitidas. `timeoutMs` admite enteros entre 1 y 2147483647 ms, los mismos límites del entorno de ejecución.
+
+Si cambia el estado efectivo del sidecar de visión, al guardar también se actualizan el catálogo administrado de Codex y la caché de modelos. Si la actualización no termina, la respuesta incluye `catalogRefreshPending: true`. El ajuste guardado se conserva. Publicar el catálogo no demuestra que un cliente en ejecución lo haya recargado.
+
+La tarjeta del sidecar de búsqueda web tiene un control equivalente: la primera opción del selector es **Desactivado**. Elegirla tiene dos efectos: OpenCodex deja de interceptar `web_search` y la integración de Codex escribe `web_search = "disabled"` en `~/.codex/config.toml`. Codex sigue anunciando su herramienta alojada `web_search` hasta que su propia configuración la desactiva; el modelo puede llamar a cualquier herramienta anunciada. Para que un servidor MCP sea la única vía de búsqueda, se necesitan ambos cambios.
+
+`web_search` es una clave de Codex con los valores `disabled`, `cached`, `indexed` y `live`. OpenCodex solo escribe `disabled` mientras el sidecar está desactivado y retira la línea de su propiedad al volver a activarlo: si la herramienta nativa siguiera desactivada, no habría llamadas que interceptar. Esta escritura requiere que `~/.codex/config.toml` esté administrado mediante `ocx sync`. La respuesta de administración la informa como `codexWebSearch`; la tarjeta de búsqueda advierte si no se pudo escribir y `ocx agent sidecar web --enabled off` indica si se escribió. Solo se intenta cuando al guardar cambia el estado efectivo. Si no cambió, se devuelve `not_requested` y no se imprime información adicional. Si el operador había configurado manualmente una línea raíz `web_search`, se reemplaza mientras el sidecar está desactivado para evitar claves TOML duplicadas. Su texto exacto se guarda en el diario de Codex y se restaura en su ubicación al reactivar el sidecar, incluso si la línea se añadió después de la instantánea del diario, algo que `ocx restore` por sí solo no puede cubrir. Ese registro también permite reconocer la línea `disabled` de OpenCodex si Codex reescribe `config.toml` y elimina el comentario de propiedad.
+
+También puedes establecer `enabled: false` directamente en `config.json`. La búsqueda y la descripción de imágenes mediante Anthropic OAuth reutilizan la identificación existente de Claude Code OAuth, pero requieren pruebas prolongadas con la cuenta y la carga de trabajo previstas.
+
+Vea el [Referencia de configuración](/es/reference/configuration/server/#sidecars) para cada campo.
+
+Las respuestas de búsqueda con campos opcionales mal formados conservan el texto válido de la respuesta y las citas. Los valores no válidos de un mensaje de error se sustituyen por un mensaje de fallo genérico.
+
+Los sidecars de búsqueda y visión de OpenAI aceptan finales de línea CR, LF y CRLF, incluso mezclados o con CRLF dividido entre fragmentos de red. Leen el evento final de finalización o fallo aunque el servidor cierre el cuerpo sin un salto de línea final. Una respuesta sin terminar o detenida por un límite de tamaño sigue notificando un error.
+
+Cuando una respuesta de búsqueda termina con una lista de fuentes, un elemento que no se reconoce como cita permanece en la respuesta en lugar de eliminarse. Un título seguido de su URL sigue tratándose como una sola cita. El texto con aspecto de URI que no sea HTTP dentro de código en línea, como `mode:fast`, permanece en la respuesta; las URL HTTP(S) con formato de código siguen siendo citas.
+
+Las consultas y respuestas de búsqueda largas se acortan sin dividir pares de sustitutos UTF-16, de modo que los límites del resultado nunca cortan por la mitad un carácter como 😀. Una secuencia de varios caracteres, como los emoji unidos mediante un carácter de unión de ancho cero, todavía puede cortarse entre sus componentes.
+
+Las llamadas al modelo de búsqueda Anthropic y sus reintentos por reset consumen los límites compartidos de envíos y tokens de la solicitud lógica en Responses enrutado, incluidos RunTurn y el puente passthrough. `maxSearchesPerTurn` no concede envíos adicionales. Si no queda admisión, devuelve un resultado de error sin contactar Anthropic y sin gastar la reserva de recuperación final del modelo principal. El endpoint independiente `/v1/alpha/search` conserva su comportamiento.
+
+Una respuesta de búsqueda con campos opcionales mal formados conserva el texto y las citas válidas; un mensaje de error inválido se sustituye por uno genérico. Una instantánea completa repetida reemplaza la previa de la misma parte, sin duplicarla. Las partes con índices conocidos distintos no se fusionan por una finalización sin índice. Un ID final único puede conservar el orden al recuperar texto; posiciones contradictorias o IDs finales duplicados no lo prueban.
+
+Los sidecars OpenAI de búsqueda y visión admiten finales de línea CR, LF y CRLF, mezclados o partidos entre chunks, y leen un terminal sin salto final. El primer terminal o `[DONE]` termina la lectura y descarta lo posterior incluso en el mismo chunk. Una respuesta incompleta o detenida por tamaño sigue siendo error. Para una URL ya vista, la primera cita final con título válido prevalece; si no hay título final válido conserva el de streaming. Las fuentes que solo llegaron en streaming respetan los límites existentes de número, URL, título y bytes.
diff --git a/docs-site/src/content/docs/es/guides/sub-agent-surface.md b/docs-site/src/content/docs/es/guides/sub-agent-surface.md
new file mode 100644
index 00000000000..aadfb96a6fa
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/sub-agent-surface.md
@@ -0,0 +1,308 @@
+---
+title: "Interfaz de subagentes (v1 / base / v2)"
+description: "Controle cómo Codex genera y gestiona subagentes en todos los modelos."
+---
+
+<a id="what-sub-agents-are"></a>
+
+## Qué son los subagentes
+
+Un subagente es un trabajador separado Codex que el agente principal puede crear para una tarea enfocada. Tiene su propio contexto y herramientas, por lo que varias tareas independientes pueden ejecutarse en paralelo. opencodex controla qué superficie de colaboración Codex expone a esos trabajadores, qué modelos Codex ofrece para ellos y cómo un modelo fallido puede retroceder. No decide cuándo su agente principal debe delegar.
+
+<a id="modes"></a>
+
+## Modos
+
+Elija el modo para **Nuevas sesiones**. Las sesiones existentes mantienen la superficie con la que comenzaron.
+
+| Modo | Herramientas de Codex | Para quién se recomienda |
+| --- | --- | --- |
+| **v1** (predeterminado) | Herramientas clásicas en un espacio de nombres: `spawn_agent`, `send_input`, `resume_agent` y `close_agent`. Al crear un subagente se puede elegir otro modelo directamente. | Para quienes delegan entre proveedores, especialmente desde un agente nativo hacia subagentes enrutados. Es el modo que incluye una instalación nueva. |
+| **base** | Asignaciones originales por modelo: GPT-5.6 Sol/Terra usan v2; Luna, v1. Los demás siguen la opción `multi_agent_v2` de Codex. | Para quienes quieren conservar esas asignaciones y usan modelos principales y subagentes del mismo lado del límite de proveedores. Sol y Terra quedan en v2. |
+| **v2** | Herramientas planas `spawn_agent`, `send_message`, `followup_task`, `interrupt_agent` y listado de agentes, con sesiones concurrentes. | Para quienes necesitan el flujo concurrente y comprenden la herencia de modelos y la limitación de tareas cifradas descrita abajo. |
+
+En **v2**, la opción **Mantener ChatGPT en v1** (`keepNativeChatGptOnV1`) conserva Sol/Terra en v1 para que puedan crear subagentes Grok o Claude. Los agentes principales nativos de ChatGPT cifran el cuerpo de las tareas `NEW_TASK` en v2 y los modelos enrutados no pueden leerlo. Los agentes principales enrutados permanecen en v2, donde las tareas de sus subagentes son texto plano. Para este modo híbrido, OpenCodex desactiva la anulación global `multi_agent_v2`, porque Codex la aplica antes que los ajustes por modelo del catálogo. Es una opción de v2, no un cuarto modo de catálogo.
+
+:::tip[¿Tienes dudas?]
+Usa **v1**, el modo predeterminado. Elige **base** o **v2** solo si el modelo principal y el subagente están del mismo lado del límite de proveedores: en ambos modos, una tarea enviada desde un modelo nativo de ChatGPT a uno enrutado llega cifrada y falla. La opción híbrida de v2 descrita arriba evita ese cruce conservando los modelos nativos en v1. El dashboard pide confirmación antes de elegir base o v2 y enlaza a [Por qué v1 es el valor predeterminado](/es/guides/subagent-v1-default/).
+:::
+
+<a id="model-switches-and-side-chat-compaction"></a>
+
+## Interruptores de modelo y compactación de chat lateral
+
+Codex puede compactar la historia heredada antes del primer turno de un chat lateral o después de un cambio de modelo. Un disparador compara los marcadores de compatibilidad `comp_hash` de los modelos anteriores y de destino: cuando ambos están presentes y difieren, Codex se compacta incluso si el historial se ajusta al contexto del destino.
+
+OpenCodex representa compatibilidad desconocida para modelos enrutados como `comp_hash: null`, en lugar de inventar un marcador `"opencodex"` o copiar uno de una plantilla nativa. Las reconstrucciones de catálogo también borran esos marcadores antiguos en OpenCodex filas retenidas durante una interrupción de descubrimiento del proveedor. Los modelos nativos y los alias explícitos Codex-forward mantienen sus marcadores ascendentes, por lo que aún se aplican verificaciones de incompatibilidad nativa genuinas. Este comportamiento es independiente de la superficie del subagente v1/v2 y del modelo configurado para realizar la compactación.
+
+El contexto normal y la compactación de límite de token todavía se aplican. Este cambio elimina el desajuste de hash sintético; no selecciona qué mensajes visibles hereda un chat lateral ni restaura los mensajes originales de un contexto ya compactado. El soporte de contenido del proveedor sigue siendo una restricción separada.
+
+<a id="external-task-input"></a>
+
+## Entrada de tarea externa
+
+Codex puede entregar la entrada inicial o seguimiento de una tarea en una envolvente en forma de resultado sin un `call_id`. En las rutas traducidas, OpenCodex reconoce solo la forma completa de `function_call_output` con `id`, `name` y `namespace` sin espacios en blanco y salida de texto/imagen compatible, luego la trata como un turno de usuario. Esto también inicia el nuevo límite de conversación durante la continuación y borra el razonamiento pendiente del turno anterior. La guía para desarrolladores generada se coloca antes de la tarea actual tanto en los mensajes analizados como en el historial sin procesar guardado, preservando el mismo orden cuando se reproduce ese historial.
+
+Los sobres mal formados, vacíos, opacos o incompletos aún fallan en la validación. Los resultados reales de la herramienta mantienen su `call_id` requerido; el paso nativo y la compactación enrutada (portátil) aplican el mismo mapeo de giro de usuario a sus cuerpos sin procesar; el `/responses/compact` directo mantiene su manejo de entrada sin procesar existente. Véase [el contrato del adaptador](/es/reference/adapters/#external-task-input-on-translated-responses-routes).
+
+<a id="how-it-works"></a>
+
+## Cómo funciona
+
+El modo seleccionado controla el campo `multi_agent_version` en cada entrada del catálogo que lee Codex:
+
+- **v1** marca `multi_agent_version = "v1"` en todos los modelos.
+- **base** restaura los pines de aguas arriba. Las entradas sin pines siguen la bandera de la característica nativa `multi_agent_v2`.
+- **v2** marca `multi_agent_version = "v2"` en todos los modelos, excepto cuando **Mantener ChatGPT en v1** está habilitado: las filas nativas de ChatGPT permanecen en `"v1"` y las filas enrutadas o de combo permanecen en `"v2"`.
+
+opencodex aplica esto como el pase final tanto al catálogo en vivo `/v1/models` como al catálogo sincronizado al disco. Es por eso que un cambio de modo afecta a las nuevas sesiones de App, CLI y TUI creadas de manera consistente.
+
+Para una lista v2, la elegibilidad tiene tres estados: es elegible una entrada marcada como `"v2"`, establecida explícitamente en `null` o sin campo `multi_agent_version`. Se excluye un pin genuino `"v1"` porque establece que el modelo pertenece a la otra superficie de colaboración.
+
+<a id="which-models-spawn_agent-advertises"></a>
+
+## Qué modelos anuncia `spawn_agent`
+
+Codex muestra como máximo cinco modelos en la descripción de `spawn_agent`. Los elige ordenando las filas visibles del catálogo por `priority`, de menor a mayor, y tomando las cinco primeras. La lista de la página **Subagentes** (`subagentModels`) influye en esa selección al asignar a sus modelos las prioridades más bajas, en el orden configurado (`0` a `4` si no hay selectores de cuenta). No limita la selección exclusivamente a esos modelos.
+
+Si destacas entre uno y cuatro modelos, Codex completa los espacios restantes con las siguientes filas por prioridad. Esas filas no las elegiste tú y el dashboard no muestra cuáles son. Dependen del catálogo:
+
+| Catálogo | Filas que completan los espacios restantes |
+| --- | --- |
+| Sin selectores de cuenta de Codex | Las demás filas enrutadas `provider/model`. Todas tienen prioridad `5`, por lo que se ordenan alfabéticamente por proveedor y después por identificador de modelo. Las filas GPT nativas no destacadas usan `featured.length + 100 + sourcePriority`, conservando su orden de origen detrás de esas filas enrutadas. |
+| Con selectores de cuenta de Codex | Las filas nativas calificadas por cuenta (`<selector>/<native-model>`), inmediatamente después de las destacadas. Las filas enrutadas no destacadas pasan a la prioridad `1005` y quedan detrás. |
+
+Por ejemplo, sin selectores de cuenta y con esta lista:
+
+```json
+{ "subagentModels": ["xai/grok-4.5", "anthropic/claude-sonnet-5"] }
+```
+
+| Posición | Modelo | Prioridad | Motivo |
+| ---: | --- | ---: | --- |
+| 1 | `xai/grok-4.5` | `0` | Primera entrada de la lista |
+| 2 | `anthropic/claude-sonnet-5` | `1` | Segunda entrada de la lista |
+| 3 | `deepseek/deepseek-v4-flash` | `5` | Primera fila enrutada restante en orden alfabético |
+| 4 | `google/gemini-3-pro` | `5` | Siguiente fila enrutada |
+| 5 | `moonshot/kimi-k3` | `5` | Siguiente fila enrutada |
+| 6+ | `zai/glm-5.2`, y después las filas GPT nativas | `5`, y después `102 + sourcePriority` | Fuera de las cinco primeras |
+
+La prioridad nativa de origen usa primero el descubrimiento actual, después la copia de seguridad intacta, la prioridad de origen conservada para el mismo modelo y la instantánea del proveedor, con `9` como valor de respaldo. Las sincronizaciones repetidas y los cambios entre destacar y dejar de destacar conservan esa prioridad sin el desplazamiento de banda. La lista en vivo, el catálogo publicado y la caché coinciden para las mismas entradas. Consulta [Orden de modelos](/es/guides/model-ordering/) para conocer la validación y las anulaciones del orden del selector.
+
+Con la lista vacía, opencodex no fija ninguna prioridad y se eligen las cinco filas según las prioridades habituales del catálogo.
+
+Los modelos que completan la lista se anuncian normalmente, así que el agente principal puede elegirlos. La lista tampoco es una lista de permisos: Codex acepta un modelo del catálogo que esté fuera de las cinco primeras filas si el agente principal lo nombra exactamente. Para controlar lo que anuncia Codex:
+
+- Destaca cinco modelos. Una lista completa no deja espacios por rellenar.
+- Desactiva un modelo que no quieras que se ofrezca, o exclúyelo de `selectedModels` de su proveedor. Sale del selector y no puede completar un espacio.
+- `modelPickerOrder` cambia las prioridades usadas para ordenar. Una lista formada solo por modelos enrutados mueve sus filas no destacadas a `1000` o más, de modo que las filas enrutadas que no figuren en ella completan primero los espacios. Si contiene un identificador nativo sin calificar, ordena todo el selector, incluidas las filas destacadas: las filas de la lista ocupan los espacios antes que cualquier fila que no figure en ella. Véase [Orden de modelos](/es/guides/model-ordering/).
+
+En v2, Codex excluye las filas con valor fijo `"disabled"` antes de elegir las cinco; el resto funciona igual. La guía v2 de opencodex (`{{roster}}`) solo nombra los modelos configurados que estén entre esas cinco filas. Por eso los modelos de relleno aparecen en la descripción de la herramienta de Codex, pero no en la guía de opencodex. Codex lee el catálogo al iniciar una sesión, así que los cambios de la lista se aplican a sesiones nuevas.
+
+<a id="delegation-model-and-effort"></a>
+
+## Modelo de delegación y esfuerzo
+
+El **Delegación de subagentes** del panel de control controla tres configuraciones relacionadas:
+
+- `injectionModel` es el modelo de trabajador preferido nombrado en la guía opencodex.
+- `injectionEffort` es el `reasoning_effort` opcional para solicitar ese modelo.
+- `injectionPrompt` reemplaza el texto de guía v2 incorporado.
+
+La opción **Sugerir**, junto al modelo de delegación, pide una breve descripción del trabajo que Codex suele delegar. Realiza una llamada a tu modelo predeterminado de Codex para evaluar la tarea y propone el modelo más económico que resulte suficiente, con un nivel de esfuerzo de los disponibles en el selector. También explica los motivos y qué señales justificarían subir o bajar de nivel. La sugerencia no se aplica hasta pulsar **Usar este**: ese botón guarda el modelo y el esfuerzo igual que una selección manual. Los niveles se obtienen de `codexRoleTiers` o del precio, como en la [asignación automática de roles](/es/guides/integrations/#auto-assign), pero sin las puntuaciones medidas que esta última puede leer de fuentes configuradas.
+
+`multiAgentGuidanceEnabled` por defecto está encendido y es el switch maestro para opencodex, guía de autoría en ambas superficies. Apagarlo suprime tanto el bloque de designación v2 como el texto proactivo v1.
+
+Para las solicitudes Responses sin estado en forma de matriz, opencodex coloca la guía generada después de los metadatos líderes del sistema y del desarrollador, incluido el desarrollador `additional_tools`, y antes de la entrada conversacional. `previous_response_id` continuaciones reutilizan la guía etiquetada solo cuando coincide con el último elemento etiquetado en su prefijo de reproducción de confianza. Otra guía generada se reutiliza cuando existe un elemento de desarrollador generado exacto en ese prefijo. Cuando la guía cambia, el protocolo de la herramienta líder permanece primero y el reemplazo se inserta antes de la entrada conversacional actual.
+
+Estas son instrucciones para el agente principal, no un router de generación del lado del proxy. En v2, una bifurcación de historia completa hereda el modelo padre y rechaza anulaciones de modelo o esfuerzo. La guía generada nombra el modelo preferido y la lista, pero no impone `fork_turns`; si quieres esa combinación, el spawn debe establecer `fork_turns: "none"` (o un recuento de turnos parcial positivo como `"3"`) junto con `model` o `reasoning_effort`, con un mensaje de tarea autónomo.
+
+El texto personalizado `injectionPrompt` puede usar los cuatro marcadores de posición:
+
+| Marcador de posición | Reemplazado por |
+| --- | --- |
+| `{{model}}` | El modelo preferido efectivo para esta solicitud. Un `injectionModel` nativo desnudo solo está calificado para la cuenta cuando la solicitud se dirige a un selector de cuenta explícito. Un valor desnudo no resuelto o ambiguo se convierte en una cadena vacía; un id explícito no resuelto calificado o encaminado permanece sin cambios. |
+| `{{effort}}` | El `injectionEffort` configurado, o una cadena vacía |
+| `{{roster}}` | La lista resuelta de selector visible y superficie compatible |
+| `{{fallback}}` | La guía de respaldo global configurada |
+
+La guía v2 incorporada tiene un presupuesto de 700 caracteres. Si superara el presupuesto, opencodex eliminaría la lista primero en lugar de truncar las instrucciones básicas de generación. La guía integrada se activa solo cuando se resuelve un modelo preferido, una lista elegible o una cadena de reserva. Un `injectionModel` configurado es suficiente para representar un mensaje personalizado; si un valor desnudo no puede resolverse de manera única, `{{model}}` se expande a una cadena vacía.
+
+En la v1, opencodex inyecta la misma orientación de delegación proactiva que el preajuste recomendado de v2 solo a `max` o `ultra` esfuerzo. Solo cambia el desencadenador de delegación: no se necesita ninguna solicitud de delegación por separado; todavía se aplican las instrucciones de usuario, la autoridad, el alcance de la tarea y las reglas de la herramienta de colaboración. No agrega un modelo preferido, una lista, una lista de reserva o un mensaje personalizado en la v1. En el modo de código Codex, opencodex ve las herramientas v1 cuando la descripción de la herramienta `exec` las enumera. Cuando Codex los aplaza para la búsqueda de herramientas, lo que hace para cada modelo de catálogo opencodex, opencodex se basa en la lista de herramientas diferidas que Codex Desktop envía con la conversación; si esa lista nombra `multi_agent_v1`, se agrega la guía proactiva. Un cliente Codex que no envía la lista no da opencodex ninguna señal de que v1 está disponible, por lo que la guía no se agrega allí.
+
+La opción `syncCodexSubagentDefaults` está **desactivada por defecto** y es independiente de la guía para el agente. Si opencodex administra el enrutamiento activo de Codex, al sincronizar o reiniciar puede escribir los valores elegidos en `[agents] default_subagent_model` y `default_subagent_reasoning_effort`, con sus marcadores de propiedad, dentro del TOML de Codex. Solo actualiza o elimina campos que conservan esos marcadores. Si editas un valor administrado, la siguiente sincronización conserva tu valor, retira el marcador y trata el campo como tuyo desde entonces. La restauración también conserva esas ediciones aunque reproduzcan contenidos inyectados anteriormente. Si cualquiera de los dos campos pertenece al usuario, deja ambos intactos; un TOML ambiguo impide escribir. También respeta los gestores externos y el enrutamiento raíz definido por el usuario.
+
+<a id="fallback-chains"></a>
+
+## Cadenas de fallback
+
+Para un trabajador generado, opencodex crea este orden de prioridad:
+
+1. El modelo primario solicitado.
+2. Una cadena por modelo de `subagentModelFallbackByModel` en opencodex config, tecleada por el modelo primario solicitado.
+3. La lista global `subagentModelFallback` en opencodex config.
+
+Las cadenas de reserva per-rol pertenecen a la configuración opencodex, no a la `$CODEX_HOME/agents/*.toml`. Codex 0.146+ estrictamente deserializa los archivos de rol de agente y rechaza `model_fallback` como un campo desconocido, lo que omite toda la definición de rol (#1190). opencodex todavía puede leer una línea `model_fallback` heredada del TOML para la compatibilidad con versiones anteriores, pero `ocx doctor` advierte al respecto y Codex en sí ignorará el rol afectado.
+
+Los identificadores de modelos duplicados se eliminan mientras se conserva la primera aparición. Durante la selección, opencodex omite candidatos que están deshabilitados, no enrutables, respaldados por un proveedor deshabilitado, marcados como no saludables, dentro de un tiempo de reutilización, falta una cuenta Codex agrupada utilizable o más allá del umbral de cuota configurado. Las sondas de disponibilidad se almacenan en caché durante `subagentModelFallbackPollMs` (60 segundos por defecto).
+
+Fallback no hace legibles las tareas cifradas incompatibles. Cuando la tarea hija se cifra para ChatGPT, la selección se restringe a ChatGPT objetivos nativos canónicos y rutas de autenticación de clave directa Responses explícitamente confiables con `allowEncryptedV2AgentTasks: true`, incluso si otro modelo externo aparece antes en la cadena. Los combos siguen siendo canónicos.
+
+<a id="encrypted-v2-task-delivery"></a>
+
+## Entrega de tareas cifradas v2
+
+Codex puede enviar una tarea hijo v2 nativa a enrutada solo como `encrypted_content` encriptado en el backend. Esa carga útil puede ser leída por el backend nativo ChatGPT, pero no por un proveedor externo. Este es el conocido [limitación #92](https://github.com/lidge-jun/opencodex/issues/92).
+
+opencodex falla de manera segura en lugar de reenviar una tarea vacía o ilegible:
+
+- Una ruta no nativa directa inelegible devuelve HTTP 400 con `error.code = "unreadable_encrypted_agent_task"` y no hace eco del texto cifrado. Un proveedor elegible de clave directa Responses que opte explícitamente por `allowEncryptedV2AgentTasks: true` recibe el texto cifrado opaco y evita este error.
+- Un combo primero considera objetivos canónicos nativos ChatGPT. Si no hay ninguno disponible o se agotan sus intentos, la recuperación habilitada puede hacer que la tarea sea legible para un destino enrutado disponible. Sin una recuperación exitosa y un objetivo elegible, el texto cifrado ilegible nunca se reenvía.
+- Una tarea de texto plano legible mantiene la ruta normal y el comportamiento de reserva.
+
+Las opciones de recuperación son seleccionar un hijo nativo ChatGPT, confiar explícitamente en un relé de clave-auth directa Responses que puede consumir la carga útil opaca, agregar un destino nativo ChatGPT al combo, usar v1 para la delegación de proveedor heterogéneo o reenviar la tarea como contenido de texto plano v2 `agent_message` cuando se controla la persona que llama.
+
+Una opción experimental, desactivada por defecto `agentTaskRecovery` puede recuperar esta forma específica nativa a la ruta a través de un paso de Responses sin procesar al punto final fijo ChatGPT `/responses` utilizando la forma de credencial entrante utilizada por el proveedor canónico `openai` con `authMode: "forward"`. La recuperación solo está disponible mientras el proxy está vinculado a loopback. Nunca sustituye la autenticación de clave API, otra credencial de proveedor u otra cuenta Codex. Solo `authorization`, que coincide con `chatgpt-account-id`, `originator` y metadatos opcionales `openai-beta` / `user-agent` se reenvían; `content-type` y `accept` se generan localmente, y ninguna otra cabecera de llamada cruza el límite. Consume cuota, agrega latencia, retiene brevemente el texto plano recuperado en una caché en memoria limitada y depende del comportamiento del backend indocumentado ChatGPT. Debido a que un modelo devuelve el texto recuperado, la fidelidad byte por byte no está garantizada. Rechaza a los llamantes genéricos/proxy API. Recuperación fallida antes de que cualquier intento nativo devuelva `unreadable_encrypted_agent_task`; después de que los intentos nativos hayan fallado, se retiene su último error. Consulte [Configuración del agente: recuperación de tareas cifradas v2](/es/reference/configuration/agents/#encrypted-v2-task-recovery) para conocer los límites y la configuración de confianza completos.
+
+La misma recuperación también cubre un hilo en vivo cambiado de un modelo nativo ChatGPT a uno enrutado. Tal hilo reproduce un mensaje de agente cifrado acuñado en cada turno posterior, por lo que antes de [#4089](https://github.com/lidge-jun/opencodex/issues/4089) falló en cada turno y la única solución fue comenzar un nuevo hilo. Ese turno de interruptor no es un turno de aparición, por lo que la ruta directa ya no restringe la recuperación a turnos de subagentes creados; la recuperación combinada aún lo hace.
+
+El enrutamiento combinado prefiere un objetivo canónico nativo seleccionable ChatGPT para tareas cifradas. Si ninguno es utilizable, o los intentos de autorización nativa se agotan, una recuperación habilitada explícitamente puede hacer que la tarea sea legible para un destino enrutado disponible. Toda la confianza de recuperación y los protectores de no persistencia anteriores siguen siendo aplicables; un objetivo nativo configurado pero deshabilitado o que se enfría no bloquea esta reserva, y la cancelación nunca se convierte en un error de tarea ilegible.
+
+<a id="rejected-encrypted-history"></a>
+
+## Rechazado el historial cifrado
+
+Un servidor upstream Responses puede rechazar partes cifradas en la salida anterior de la función/herramienta personalizada o el contenido `agent_message` con `Encrypted function output content could not be decrypted or decoded.`. Antes de que se confirme cualquier salida, opencodex reemplaza esas partes con `[encrypted content omitted]` y reconstruye la solicitud una vez. El contenido legible circundante permanece intacto; el contenido omitido no es descifrado o recuperado por este reintento.
+
+Si la solicitud reconstruida recibe otro SSE `error` desnudo seguido por EOF, ambos modos de retransmisión conservan el mensaje de error en un terminal `response.failed` en lugar de informar `adapter_eof`. Otros `response.failed` eventos aguas arriba siguen SSE fallas. Esta recuperación de historial no cambia las restricciones de entrega de tareas v2 cifradas descritas anteriormente.
+
+<a id="changing-the-mode"></a>
+
+## Cambiar el modo
+
+### GUI
+
+- **Tablero** → primera celda de estadística: elija **v1**, **base** o **v2**.
+- **Modelos** → control segmentado de la fila superior: elija el mismo modo global.
+- **Tablero** → **Delegación de subagentes**: establece el modelo/esfuerzo de guía y la opción de opt-in por defecto nativa.
+- **Subagentes**: elija y ordene la lista y configure la cadena de reserva global.
+
+### CLI
+
+Utilice `ocx v2` para la configuración de la superficie de colaboración y las funciones nativas:
+
+```bash
+ocx v2 status
+ocx v2 mode v1
+ocx v2 mode default
+ocx v2 mode v2
+ocx v2 threads 8
+```
+
+Utilice `ocx agent` para la configuración de delegación, lista, límite de esfuerzo y reserva:
+
+```bash
+ocx agent status
+ocx agent injection set --model anthropic/claude-sonnet-5 --effort xhigh
+ocx agent injection suggest "read-only searches across the repo" --apply
+ocx agent subagents set gpt-5.6-sol,anthropic/claude-sonnet-5
+ocx agent fallback set gpt-5.6-luna,xai/grok-4.5 --poll-ms 60000
+ocx effort set --subagent max
+```
+
+El comando de nivel superior `ocx effort` es el punto de entrada canónico para la inspección de esfuerzo y sus límites (p. ej. `ocx effort high`, `ocx effort status`, `ocx effort clear`), con `ocx agent effort` preservado como una ruta compatible con versiones anteriores. Obsérvese que `ocx effort clear` elimina los límites del agente principal y del subagente activo mientras deja intacta la delegación `injectionEffort` (use `ocx effort set --injection -` o `ocx agent injection set --effort -` para borrar el esfuerzo de inyección).
+
+Pase `-` para borrar un valor nullable de `ocx agent injection`, o use la acción relevante de `clear` para una lista o lista de reserva. Vea el [CLI referencia](/es/reference/cli/) para todas las familias de comando.
+
+### API
+
+La gestión API expone los puntos finales coincidentes `GET` y `PUT`:
+
+| Punto final | Administra |
+| --- | --- |
+| `/api/v2` | Modo de superficie, bandera de función nativa y configuración de subprocesos |
+| `/api/injection-model` | Modelo preferido, esfuerzo, prompt personalizado, orientación y sincronización predeterminada nativa |
+| `/api/effort-caps` | Límites máximos de esfuerzo del agente principal y del subagente |
+| `/api/subagent-models` | Lista de pedidos de hasta cinco modelos |
+| `/api/subagent-model-fallback` | Orden de reserva global e intervalo de encuesta |
+
+Por ejemplo:
+
+```bash
+curl -X PUT http://localhost:10100/api/v2 \
+  -H 'Content-Type: application/json' \
+  -d '{"multiAgentMode":"v2"}'
+
+curl -X PUT http://localhost:10100/api/injection-model \
+  -H 'Content-Type: application/json' \
+  -d '{"model":"anthropic/claude-sonnet-5","effort":"xhigh"}'
+```
+
+## FAQ
+
+<a id="does-choosing-a-delegation-model-force-codex-to-spawn-it"></a>
+
+### ¿La elección de un modelo de delegación obliga a Codex a generarlo?
+
+No. La guía puede recomendar un modelo, y la sincronización nativa predeterminada puede proporcionar un valor predeterminado de Codex, pero el agente principal aún decide si delegar.
+
+<a id="why-did-my-v2-child-use-the-parent-model"></a>
+
+### ¿Por qué mi subagente v2 usó el modelo principal?
+
+Una bifurcación v2 con el historial completo hereda el modelo del agente principal. Para indicar otro modelo o esfuerzo de razonamiento al crear el subagente, establezca `fork_turns` en `"none"` o en un recuento parcial positivo.
+
+<a id="why-is-a-configured-model-missing-from-the-v2-roster"></a>
+
+### ¿Por qué falta un modelo configurado en la lista de v2?
+
+Puede estar oculto por el selector, fuera del límite de visualización de cinco modelos, falta en el catálogo o anclado a v1. Un `"v2"`, `null`, o el valor de superficie ausente es elegible; un verdadero `"v1"` pin no lo es.
+
+<a id="why-does-spawn_agent-list-models-i-did-not-feature"></a>
+
+### ¿Por qué `spawn_agent` muestra modelos que no destaqué?
+
+Codex completa hasta cinco posiciones según la prioridad de las filas del catálogo. Si destacas menos de cinco modelos, las filas siguientes ocupan los espacios restantes. Véase [Qué modelos anuncia `spawn_agent`](#which-models-spawn_agent-advertises).
+
+<a id="do-mode-changes-affect-running-sessions"></a>
+
+### ¿Los cambios de modo afectan a las sesiones en ejecución?
+
+No. Inicie una nueva sesión Codex después de cambiar el modo. Si un host de aplicaciones de larga duración aún muestra un estado de catálogo obsoleto, ejecute `ocx sync` y reinicie esa superficie Codex.
+
+<a id="what-happens-when-opencodex-cannot-trust-the-catalog"></a>
+
+### ¿Qué sucede cuando opencodex no puede confiar en el catálogo?
+
+opencodex compara el catálogo del modelo en el disco con la hora de inicio de cada Codex app-server propiedad del usuario actual, produciendo uno de los cuatro estados:
+
+| Estado | Descripción | v2 Orientación |
+|---|---|---|
+| `fresh` | Todos los servidores de aplicaciones comenzaron después de que se escribió el catálogo | Orientación completa: modelo preferido, plantel, fallbacks |
+| `not_running` | No se detectó ningún servidor de aplicaciones | Orientación completa |
+| `stale` | Al menos un servidor de aplicaciones precede al catálogo | **No opencodex - Guía del modelo** |
+| `unknown` | La comparación no se pudo hacer | **No opencodex - Guía del modelo** |
+
+Para `stale` y `unknown`, opencodex retiene sus propias reclamaciones derivadas del disco - modelo preferido, lista, reserva y orientación personalizada - porque el Codex en ejecución puede no ser capaz de generar lo que anuncia el catálogo de discos.
+
+Esto **no** indica al modelo que deje de configurar `model` o `reasoning_effort`. La observación abarca todos los app-servers del usuario, mientras que la solicitud entrante no identifica al proceso que la envió. Por tanto, no se puede atribuir un proceso obsoleto a esa solicitud. Prohibir las anulaciones basándose en esa observación bloquearía opciones que la herramienta activa `spawn_agent` puede anunciar legítimamente en una sesión nueva. El esquema de la herramienta activa sigue siendo la autoridad.
+
+`unknown` no es sinónimo de `stale`. Significa que la comparación en sí falló - una marca de tiempo de catálogo ilegible, un tiempo de inicio de proceso ilegible o una enumeración de proceso fallido - y se informa por separado por `ocx doctor`. `stale` se borra solo después de que cada Codex app-server detectado se inicia después de la escritura final del catálogo; no necesariamente se borra `unknown`.
+
+En Windows, esta comprobación de aviso utiliza el descubrimiento asíncrono de PowerShell/CIM en la ruta de solicitud v2. Las comprobaciones en frío simultáneas comparten un descubrimiento en vuelo. Los estados observados se almacenan en caché durante cinco segundos; un error `unknown` se almacena en caché durante solo 250 milisegundos, por lo que un error CIM transitorio se reintenta rápidamente. Una consulta de CIM lenta o defectuosa puede retrasar o suprimir solo la guía del modelo OpenCodex; no bloquea el bucle de eventos Bun, `/healthz` o el tráfico proxy no relacionado. Las operaciones explícitas del ciclo de vida CLI /service conservan el recopilador de procesos síncrono y cerrado por error, ya que pueden señalar procesos.
+
+Solo un cambio real cuenta. Una sincronización cuyo resultado es idéntico en bytes al catálogo ya en disco deja el archivo intacto, por lo que reiniciar el proxy o volver a sincronizar un conjunto de modelos sin cambios no hace que un Codex en ejecución parezca obsoleto.
+
+<a id="reasoning-effort"></a>
+
+### Esfuerzo de razonamiento
+
+`injectionEffort` afecta solo a la orientación del trabajador delegado y, cuando está explícitamente habilitada, a los valores predeterminados del subagente nativo de Codex. No cambia el esfuerzo de la sesión principal. `ultra` es un nivel superior orientado al cliente que Codex convierte a `max`; opencodex luego asigna o limita el valor para el proveedor seleccionado.
+
+<a id="context-cap"></a>
+
+### Límite de contexto
+
+El límite de contexto del modelo es independiente del modo de subagente. Configure en la página Modelos; los modelos nativos OpenAI conservan sus ventanas de contexto real.
+
+El campo experimental `plaintextV2AgentMessages` no se establece en una nueva configuración y se ejecuta solo cuando se establece en `true`. La persona que llama debe usar el cable Responses y el destino final debe usar `adapter: "openai-responses"`, `authMode: "forward"` y la URL base exacta `https://chatgpt.com/backend-api/codex`. Quedan excluidos los proveedores de clave API de OpenAI, las pasarelas compatibles personalizadas, las rutas a otros proveedores y los llamantes que no usan Responses. Para una nueva llamada a la herramienta ChatGPT v2 nativa elegible, la opción asigna alias con alcance de solicitud al espacio de nombres y tres nombres reservados de la herramienta de mensajes, elimina el marcador de mensajes y restaura las identidades originales en la respuesta. Maneja `spawn_agent`, `send_message` y `followup_task` y no agrega ninguna petición de recuperación. HTTPS permanece cifrado, pero el texto de la tarea se puede conservar en el historial de Codex, las solicitudes del proveedor enrutado y el estado de respuesta/depuración local. El texto cifrado existente no cambia, y la opción depende del comportamiento no documentado de ChatGPT y Codex. Véase [Configuración del agente: Mensajes de agente de texto sin formato v2](/es/reference/configuration/agents/#plaintext-v2-agent-messages). Si una respuesta de flujo continuo ChatGPT no lleva ningún tipo de contenido, o una que no es ni `application/json` ni un flujo de eventos reconocible, opencodex comprueba un prefijo de evento Responses limitado antes de restaurar los nombres de herramienta de mensaje. Una respuesta `application/json` toma el camino JSON limitado en su lugar. La sonda espera como máximo `stallTimeoutSec` por su prefijo, y un cuerpo que permanece silencioso, no reconocido o ilegible se rechaza y nunca llega a Codex como una respuesta exitosa.
diff --git a/docs-site/src/content/docs/es/guides/subagent-v1-default.md b/docs-site/src/content/docs/es/guides/subagent-v1-default.md
new file mode 100644
index 00000000000..477d355c6e6
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/subagent-v1-default.md
@@ -0,0 +1,122 @@
+---
+title: "Por qué v1 es la interfaz de subagentes predeterminada"
+description: "Qué impide la limitación de tareas cifradas de v2, por qué OpenCodex utiliza v1 y qué opciones existen si prefiere v2."
+---
+
+OpenCodex se instala con la interfaz de subagentes en **v1**. Las páginas Panel, Modelos y Subagentes solicitan confirmación antes de cambiar a **base** o **v2** y enlazan esta explicación. La CLI no solicita esa confirmación.
+
+El motivo es concreto: de forma predeterminada, en v2 un modelo enrutado no puede leer la tarea cifrada que recibe de un modelo nativo de ChatGPT. Esto afecta al caso habitual de un agente GPT que crea un subagente Grok, Claude o GLM. Las excepciones explícitas son `keepNativeChatGptOnV1`, que conserva los modelos nativos de ChatGPT en v1 mientras los enrutados usan v2; un destino autorizado que pueda procesar la tarea cifrada mediante `allowEncryptedV2AgentTasks: true`; o la recuperación experimental `agentTaskRecovery`, descritas más abajo.
+
+<a id="what-you-see-when-it-happens"></a>
+
+## Qué ocurre cuando falla
+
+La creación del subagente se rechaza para evitar que reciba una tarea vacía sin advertencia:
+
+```json
+{
+  "error": {
+    "code": "unreadable_encrypted_agent_task",
+    "message": "Routed V2 worker task is encrypted for the native ChatGPT backend and cannot be read by the selected provider. Use plaintext V2 agent-message delivery or select a native ChatGPT model."
+  }
+}
+```
+
+La respuesta es HTTP 400 y nunca devuelve el texto cifrado. El rechazo es deliberado: reenviar una carga ilegible entregaría al subagente instrucciones vacías y podría producir una respuesta incorrecta presentada con seguridad.
+
+<a id="why-it-happens"></a>
+
+## Por qué ocurre
+
+![Comparación de la delegación: en v1, ChatGPT envía una tarea sin cifrar mediante OpenCodex y el subagente enrutado puede leerla. En v2 envía encrypted_content del backend de ChatGPT; OpenCodex no puede descifrarlo y la solicitud falla con unreadable_encrypted_agent_task al cruzar el límite entre proveedores.](../../../../assets/subagent-v2-encrypted-task.svg)
+
+En v1, el agente principal emite la tarea del subagente como texto sin cifrar. OpenCodex la lee y la enruta; el subagente recibe instrucciones que puede ejecutar.
+
+En v2, el agente principal emite la tarea como `encrypted_content`, generado por el backend de ChatGPT. La clave permanece en ese backend; OpenCodex nunca la tuvo. El proxy no puede descifrar ni reescribir el contenido: es texto cifrado real. Es una limitación estructural: ningún ajuste del proxy permite descifrar el contenido localmente.
+
+Ningún ajuste del proxy permite descifrar localmente. La opción experimental `agentTaskRecovery` puede pedir al backend de ChatGPT que recupere tareas elegibles; no descifra su contenido en el equipo. Se mantienen la autorización, la elegibilidad y los límites de fallo descritos arriba.
+
+La comparación de estas tres combinaciones muestra dónde aparece el límite:
+
+| Combinación | v1 | v2 |
+| --- | --- | --- |
+| Agente ChatGPT a subagente enrutado | funciona | **falla de forma predeterminada**; excepciones: `keepNativeChatGptOnV1` conserva el agente nativo en v1, un destino autorizado usa `allowEncryptedV2AgentTasks: true` o la recuperación experimental `agentTaskRecovery` recupera la tarea |
+| Agente enrutado a subagente enrutado | funciona | funciona |
+| Agente ChatGPT a subagente ChatGPT | funciona | funciona: el backend puede descifrar lo que generó |
+
+El backend puede leer su propio texto cifrado. El problema aparece al cruzar hacia otro proveedor.
+
+<a id="is-it-fixed-upstream"></a>
+
+## ¿Está resuelto en Codex?
+
+Todavía falta la parte necesaria para este caso. Codex integró [openai/codex#35845](https://github.com/openai/codex/pull/35845), que permite recibir mensajes de colaboración sin cifrar. Ese cambio afecta al receptor: procesa texto que ya fue generado sin cifrar, pero no hace que un agente de OpenAI lo emita de esa forma.
+
+La parte de envío sigue descrita en [#36376](https://github.com/openai/codex/issues/36376), reproducida con las versiones CLI 0.146 a 0.151 en Windows, macOS y Linux, y en [#37197](https://github.com/openai/codex/issues/37197), que solicita una política de entrega para el emisor. No hay un compromiso de implementación ni una fecha estimada del mantenedor.
+
+OpenCodex registró esta consecuencia en [#92](https://github.com/lidge-jun/opencodex/issues/92), cerrada como no planificada: este repositorio no puede resolver el cifrado del emisor. La issue remite al trabajo en Codex.
+
+<a id="what-the-three-modes-do-now"></a>
+
+## Qué hace cada modo
+
+| Modo | Interfaz | Cuándo elegirlo |
+| --- | --- | --- |
+| **v1** (predeterminado) | Todos los modelos anuncian las herramientas clásicas de creación con espacio de nombres. Cada creación puede indicar otro modelo directamente. | Si delega entre proveedores. Es el valor incluido en la instalación. |
+| **base** | Respeta la asignación de Codex por modelo: Sol y Terra usan v2, Luna usa v1 y los modelos sin asignación siguen la opción de Codex. | Si desea la interfaz prevista por Codex y delega dentro de un mismo proveedor. |
+| **v2** | Todos los modelos anuncian las herramientas concurrentes sin espacio de nombres. | Si desea las sesiones concurrentes nuevas y ambos agentes están del mismo lado del límite entre proveedores. |
+
+base aparece en segundo lugar porque asigna v2 a Sol y Terra, modelos utilizados habitualmente como agentes principales. Para delegar de ChatGPT a un modelo enrutado, base tiene la misma limitación que v2.
+
+<a id="if-you-already-chose-base-or-v2"></a>
+
+## Si ya eligió base o v2
+
+La actualización no sobrescribe una elección existente. El panel muestra el aviso una vez y espera una respuesta.
+
+- **Continuar** conserva el modo actual y deja de preguntar.
+- **Cambiar a v1** aplica v1 y deja de preguntar.
+
+Ambas respuestas quedan registradas. Cerrar el aviso sin responder lo deja pendiente para la siguiente apertura del panel.
+
+El modo se aplica a las sesiones **nuevas** de Codex. Inicie otra sesión después del cambio. Si un proceso de la aplicación que lleva tiempo abierto todavía muestra la interfaz anterior, ejecute `ocx sync` y reinicie esa aplicación.
+
+<a id="if-you-want-v2-anyway"></a>
+
+## Si prefiere utilizar v2
+
+Hay cuatro opciones, en el orden recomendado:
+
+1. **Mantener ChatGPT en v1.** Dentro de v2, `keepNativeChatGptOnV1` conserva Sol y Terra en v1 para que puedan crear subagentes Grok o Claude; los agentes principales enrutados utilizan v2.
+2. **Delegar dentro del mismo proveedor.** Un agente enrutado que crea otro subagente enrutado utiliza texto sin cifrar en v2 y funciona normalmente.
+3. **Confiar en un relay directo de Responses con clave API.** Un proveedor marcado explícitamente con `allowEncryptedV2AgentTasks: true` recibe la carga opaca en lugar de HTTP 400. Utilícelo únicamente con un destino que sepa que puede procesarla.
+4. **Activar `agentTaskRecovery`.** Es experimental y está desactivado de forma predeterminada. Recupera los elementos cifrados ilegibles `NEW_TASK`, `MESSAGE`, `FOLLOWUP_TASK` y `FINAL_ANSWER` mediante el backend de ChatGPT, con consumo de cuota, latencia y dependencia de un comportamiento no documentado. La recuperación de Combo sigue limitada a los turnos de subagentes creados; los fragmentos de tokens divididos no son compatibles.
+
+Consulte [Interfaz de subagentes](/es/guides/sub-agent-surface/) para conocer su funcionamiento y [Configuración de agentes](/es/reference/configuration/agents/) para los ajustes.
+
+<a id="when-this-page-goes-away"></a>
+
+## Cuándo dejará de ser necesaria esta página
+
+Cuando Codex permita que un agente nativo de ChatGPT emita sin cifrar la tarea de un subagente enrutado, desaparecerá el motivo de este valor predeterminado. Entonces podrá volver a base, dejar de mostrar la confirmación y conservar esta página como registro histórico.
+
+<a id="changing-the-mode"></a>
+
+## Cambiar el modo
+
+Panel, Modelos y Subagentes comparten el selector v1/base/v2 y solicitan confirmación antes de pasar a base o v2. Desde la CLI:
+
+```bash
+ocx v2 status
+ocx v2 mode v1
+```
+
+La CLI no solicita confirmación. Modifica la misma configuración; elija el modo teniendo en cuenta estas limitaciones.
+
+<a id="concurrent-child-limit"></a>
+
+## Límite de subagentes simultáneos
+
+En **Modelos → Ajustes del modelo**, el control de subagentes establece el máximo de agentes secundarios simultáneos, sin contar al principal. Está disponible en v1, base y v2, incluido el modo híbrido con la opción global de v2 desactivada. El modo de interfaz y este límite se eligen por separado.
+
+Aumentar el límite permite más subagentes; no los crea automáticamente ni garantiza mayor velocidad. Inicie una sesión nueva de Codex después de cambiarlo. Si un proceso de la aplicación que lleva tiempo abierto sigue usando el límite anterior, reinícielo.
diff --git a/docs-site/src/content/docs/es/guides/telemetry.md b/docs-site/src/content/docs/es/guides/telemetry.md
new file mode 100644
index 00000000000..febdf868a88
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/telemetry.md
@@ -0,0 +1,213 @@
+---
+title: Telemetría y privacidad
+description: Estadísticas diarias anónimas de uso, consentimiento y límites para agentes, desactivación, vista previa de datos y conservación del recolector.
+---
+
+opencodex incluye telemetría diaria anónima para conocer las versiones, plataformas, canales de instalación, tipos de proveedor y familias generales de modelos utilizados, así como las causas de fallo de las solicitudes. El endpoint público de solo lectura `GET /v1/stats` ofrece estadísticas del proyecto para el [panel público](/es/dashboard/): instalaciones activas y nuevas, actividad de 365 días, minutos activos, resultados, cinco categorías de tokens, distribución diaria y por periodo de proveedores y modelos, las 50 versiones principales, sistemas y arquitecturas, canales y causas de error. `/v1/stats` nunca devuelve los hashes diarios de instalación (`installDayHash`) ni los de límite de tasa (`ip_hash`).
+
+La telemetría está **activada de forma predeterminada**, pero **no se envía nada hasta que una persona vea el aviso**.
+
+<a id="how-consent-and-the-default-on-rule-work"></a>
+
+## Consentimiento y activación predeterminada
+
+Una instalación nueva, o una que actualice a una versión con telemetría sin una decisión guardada, empieza en `awaiting-notice`. En ese estado no envía datos.
+
+El envío solo se activa después de que una persona vea la información o registre su decisión:
+
+1. **Aviso del dashboard (`TelemetryConsentCard`)**: aparece en un proxy independiente o Home al iniciar o actualizar sin decisión guardada ni desactivación por entorno. Los Child de Remote Link delegan la gestión al Home. La casilla **Compartir estadísticas diarias anónimas de uso** está marcada. **Continuar** guarda `decision: "accepted"`, o `"declined"` si se desmarca, además de `decidedAt` y `noticeShownAt`, mediante `PUT /api/telemetry`. Escape, el fondo, cerrar o cargar la página sin continuar no registra **nada**. No hay endpoint de solo aviso; sin decisión vuelve a aparecer en la siguiente apertura hasta elegir en el aviso, **Detalles del proxy** o la CLI.
+2. **Pregunta de terminal interactiva**: `ocx start`, `ocx init` y `ocx service install` muestran qué se envía, qué se excluye, que los agregados son públicos en `opencodex.me/dashboard`, cómo verlos con `ocx telemetry status --json` y cómo desactivar con `ocx telemetry disable`, `OCX_TELEMETRY=0`, `DO_NOT_TRACK=1` o **Detalles del proxy**. Después preguntan una vez `Share anonymous usage statistics? [Y/n]` si stdin y stdout son TTY (`isatty`), `OCX_SERVICE` no está definida e `isAgentDriven()` es false. Intro o `y` guarda `decision: "accepted"`, `decidedAt` y `noticeShownAt`; `n` guarda `decision: "declined"`.
+3. **Activación explícita**: el interruptor **Compartir estadísticas anónimas de uso** de **Detalles del proxy**, que ya muestra los datos, guarda `decision: "accepted"`. `ocx telemetry enable [--json]` exige una terminal humana interactiva, ambos flujos TTY, sin `OCX_SERVICE` ni `isAgentDriven()`, muestra la misma información y pide confirmación `[Y/n]`, Sí predeterminado.
+
+`resolveTelemetryStatus` (`src/telemetry/consent.ts`) aplica esta precedencia:
+
+| Condición, primera coincidencia | Estado efectivo | `reason` |
+| --- | --- | --- |
+| `OCX_TELEMETRY` es `0`, `false`, `off` o `no` | Desactivada | `env-ocx-telemetry` |
+| `DO_NOT_TRACK` es `1`, `true` o `yes` | Desactivada | `env-do-not-track` |
+| `telemetry.decision === "declined"` | Desactivada | `declined` |
+| `telemetry.decision === "accepted"` | Activada | `accepted` |
+| `telemetry.decision` no está definida y `telemetry.noticeShownAt` sí | Activada | `default-on` |
+| Ambas no están definidas | Desactivada | `awaiting-notice` |
+
+<a id="agent-driven-starts-never-enable-telemetry"></a>
+
+## Los arranques de agentes nunca activan la telemetría
+
+Un agente de IA o sistema de automatización nunca debe responder ni reconocer el aviso en tu nombre:
+
+- En agentes o CI, detectados mediante `CLAUDECODE`, `CODEX_THREAD_ID`, `CURSOR_TRACE_ID`, `CI` y otros indicadores de `isAgentDriven()`, terminales sin TTY o servicios (`OCX_SERVICE=1`), esos comandos omiten la pregunta. Imprimen como máximo un aviso por versión, registrado en `<OPENCODEX_HOME>/.telemetry-deferred`, sin escribir `noticeShownAt` ni `decision`. Se mantiene `awaiting-notice` hasta que uses personalmente el dashboard o una terminal fuera del agente.
+- `PUT /api/telemetry` exige una sesión humana vigente del dashboard (`hasHumanDashboardSession`). El token administrativo o una sesión de dispositivo recordado no bastan: HTTP `403`, `code: "agent_consent_required"`.
+- `ocx telemetry enable` exige stdin y stdout TTY, ausencia de `OCX_SERVICE` y no ser `isAgentDriven()`. De lo contrario termina con `1`, `agent_consent_required` o `tty_required`, y dirige al dashboard.
+- `ocx config set telemetry` y `ocx config unset telemetry` se rechazan para todos. `ocx config import` ignora cualquier bloque importado `telemetry` y conserva intacto el estado persistente.
+- Desactivar con `ocx telemetry disable`, `OCX_TELEMETRY=0` o `DO_NOT_TRACK=1` siempre está permitido, también en scripts y agentes.
+
+Como al dar una estrella en GitHub, estas comprobaciones cubren las rutas habituales de CLI y API frente a agentes (`AGENT_ENV_VARS`) y tokens administrativos. La política también prohíbe que un agente local edite `config.json` o cree una sesión loopback para registrar tu consentimiento.
+
+<a id="how-to-turn-telemetry-off"></a>
+
+## Desactivar la telemetría
+
+Puedes desactivarla en cualquier momento:
+
+1. **Instalador de Windows**: la página de MSI resume los datos, enlaza la [declaración de privacidad](/es/reference/code-signing/#privacy) y muestra marcada **Enviar estadísticas anónimas de uso**. Desmárcala, o pasa `OCX_TELEMETRY_CHOICE=optout` a `msiexec /qn`. La aplicación guarda `"decision": "declined"` al primer arranque de cada cuenta, antes de resolver o iniciar un proxy. En una instalación nueva guarda primero la decisión en `telemetry-state.json` hasta que exista `config.json`, para que siga funcionando `ocx init`. La elección es de todo el equipo, también en despliegues silenciosos de administrador, y se conserva al actualizar desde la aplicación. Solo `send` mantiene la opción; `optout` sin distinción de mayúsculas, o cualquier otro valor, la desactiva. Cada decisión se aplica una vez por cuenta; continuar en un instalador posterior sin cambiar la casilla conserva la decisión anterior y no sobreescribe una elección posterior del dashboard. Si guardar falla, el proxy que inicia la aplicación recibe `OCX_TELEMETRY=0` y se reintenta en segundo plano y al abrir de nuevo. Dejar la casilla marcada no inicia el envío ni reactiva una cuenta que lo desactivó: aún se muestra el aviso. Un servicio de `ocx service install` puede arrancar sin Desktop; la decisión de un instalador posterior lo alcanza al abrir la aplicación. Usa `ocx telemetry disable` para detener el envío de inmediato.
+2. **Aviso del dashboard**: desmarca **Compartir estadísticas diarias anónimas de uso** y pulsa **Continuar**.
+3. **Detalles del proxy**: abre Inicio en el [dashboard](/es/guides/web-dashboard/), sección **Telemetría**, `#proxy-telemetry`, y desactiva **Compartir estadísticas anónimas de uso**.
+4. **CLI**:
+
+   ```bash
+   ocx telemetry disable
+   ```
+
+   Guarda `"decision": "declined"` en `config.json` y, solo después de persistirla, elimina `<OPENCODEX_HOME>/telemetry-id.json`. Si `mutatePersistedConfig` devuelve `unavailable` o lanza un error al activar o desactivar, la CLI termina con error y sin mensaje de éxito; no elimina el archivo si no se guardó el rechazo.
+5. **`OCX_TELEMETRY=0`**: defínela en el entorno del proxy; acepta `false`, `off` o `no`, sin distinguir mayúsculas.
+6. **`DO_NOT_TRACK=1`**: acepta también `true` o `yes`, sin distinguir mayúsculas.
+
+Las variables solo llegan a procesos que las heredan. Un servicio systemd, launchd o del Programador de tareas no ve las exportaciones de tu terminal interactiva: configúralas en el entorno del servicio o usa un control persistente. `ocx telemetry status` consulta al proxy activo y muestra su estado efectivo.
+
+Ambas variables prevalecen sin editar `config.json`. Al observarlas al arrancar en `src/server/background-lifecycle.ts`, aunque no se active el temporizador, o en cada ciclo del planificador, se guardan mediante escritura atómica sin seguir enlaces `ineligibleThroughDay` con el día UTC actual (`YYYY-MM-DD`) y `envOptOutActiveSince` en `<OPENCODEX_HOME>/telemetry-state.json`, y se elimina `<OPENCODEX_HOME>/telemetry-id.json`. El marcador cubre todos los días que siga ejecutándose el proxy iniciado con la variable. Al detenerse ordenadamente, o en el primer ciclo sin ella tras un fallo, se extiende `ineligibleThroughDay` hasta ese día. Ningún día cubierto, incluido el final, se envía después; el siguiente envío apto crea otro ID. Con la variable activa, el dashboard deshabilita el interruptor e identifica cuál prevalece.
+
+<a id="how-to-see-the-exact-payload"></a>
+
+## Ver los datos exactos
+
+`GET /api/telemetry` y `ocx telemetry status [--json]` generan `preview` para el **mismo día UTC completo que enviaría el planificador**: el apto pendiente más antiguo dentro de siete días, con `previewEligible: true`. Si no hay ninguno, por falta de consentimiento, por ser el día de la decisión, por desactivación o porque ya se enviaron, muestran el último día completo para inspección con `previewEligible: false`, sin prometer su envío.
+
+- **CLI, lectura humana y vista previa JSON**:
+
+  ```bash
+  ocx telemetry status
+  ```
+
+- **CLI, instantánea estructurada**:
+
+  ```bash
+  ocx telemetry status --json
+  ```
+
+  Consulta `GET /api/telemetry` si hay proxy activo; si está detenido, genera la misma instantánea con `config.json` y `usage.jsonl` locales.
+- **Dashboard**: pulsa **Vista previa del JSON** en el aviso o junto al interruptor de **Detalles del proxy** para ver **Qué se envía**, **Nunca se envía** y el JSON exacto.
+
+Antes del primer informe, o después de eliminar `telemetry-id.json` al desactivar, no hay ID en disco y `installDayHash` aparece como 64 ceros: `0000000000000000000000000000000000000000000000000000000000000000`.
+
+<a id="what-is-collected"></a>
+
+## Qué se recoge
+
+Cada informe corresponde a un día UTC completo (`YYYY-MM-DD`). `validateTelemetryPayloadV1` de `src/telemetry/contract.ts` lo valida antes de salir del proxy y al llegar al recolector. Se rechazan claves desconocidas y valores ajenos a las listas predefinidas.
+
+Ejemplo real producido por `buildTelemetryPayloadV1` (`src/telemetry/payload.ts`):
+
+```json
+{
+  "schemaVersion": 1,
+  "batchId": "c2bf1164-d009-4111-a8a6-902d55f727c7",
+  "day": "2026-11-06",
+  "installDayHash": "456b15e3a95d8665bbd9a40ac2cae49986aec3f03b78b6dd601df49abfc406d4",
+  "newInstall": false,
+  "env": {
+    "version": "2.99.0",
+    "releaseChannel": "latest",
+    "os": "darwin",
+    "arch": "arm64",
+    "installChannel": "npm-global"
+  },
+  "activeMinutes": 312,
+  "requests": {
+    "completed": 840,
+    "failed": 12,
+    "incomplete": 3,
+    "aborted": 5
+  },
+  "models": [
+    {
+      "providerKind": "anthropic",
+      "modelFamily": "claude-opus",
+      "requests": 400,
+      "inputTokens": 184200,
+      "cacheReadTokens": 6410000,
+      "cacheWriteTokens": 512000,
+      "outputTokens": 96400,
+      "reasoningTokens": 28100
+    },
+    {
+      "providerKind": "chatgpt",
+      "modelFamily": "gpt-6",
+      "requests": 460,
+      "inputTokens": 210500,
+      "cacheReadTokens": 5890000,
+      "cacheWriteTokens": 0,
+      "outputTokens": 112300,
+      "reasoningTokens": 44800
+    }
+  ],
+  "errors": {
+    "rate-limit": 7,
+    "upstream-fault": 5
+  }
+}
+```
+
+| Campo | Contenido |
+| --- | --- |
+| `schemaVersion` | Entero fijo `1`. |
+| `batchId` | UUID v4 aleatorio generado al construir el informe. |
+| `day` | Día UTC completo (`YYYY-MM-DD`) entre los últimos siete días UTC completos. |
+| `installDayHash` | `sha256(installId + ":" + day)`, 64 caracteres hexadecimales minúsculos; cambia cada día UTC. |
+| `newInstall` | `true` solo en el primer informe del `telemetry-id.json` local actual; después `false`. |
+| `env.version` | Versión que cumple `^\d+\.\d+\.\d+(-preview\.\d{8}(\.\d+)?)?$`, como `2.40.1`, `2.6.15-preview.20260701`, `2.6.15-preview.20260701.1` o `2.7.9-preview.20260712.2`; el cliente elimina metadatos `+build` y `validateTelemetryPayloadV1` los rechaza. |
+| `env.releaseChannel` | `"latest"` o `"preview"`. |
+| `env.os` | `"darwin"`, `"linux"`, `"win32"` u `"other"`. |
+| `env.arch` | `"x64"`, `"arm64"` u `"other"`. |
+| `env.installChannel` | `"npm-global"`, `"pnpm-global"`, `"bun-global"`, `"mise"`, `"standalone"`, `"desktop"`, `"docker"`, `"source"` o `"unknown"`. |
+| `activeMinutes` | Minutos UTC distintos (`0`–`1440`) de `day` con alguna solicitud registrada en `usage.jsonl`. |
+| `requests` | Recuentos por resultado predefinido: `completed`, `failed`, `incomplete` y `aborted`. |
+| `models` | Hasta 64 pares únicos `(providerKind, modelFamily)` por día. Si hay más, se conservan las 63 filas principales por solicitudes y tokens y el resto se suma en `"other"` / `"other"`. Cada intento de `combo` se atribuye a su proveedor y modelo; `models[].requests` puede superar `requests`. Cada fila incluye `requests` y cinco contadores sin solapamiento: `inputTokens`, entrada sin caché; `cacheReadTokens`; `cacheWriteTokens`; `outputTokens`, salida sin razonamiento; y `reasoningTokens`. Su suma es `usageDisplayTotalTokens`. |
+| `errors` | Solicitudes no completadas por causa predefinida: `transport-unsent`, `transport-ambiguous`, `upstream-declined`, `rate-limit`, `quota-exhausted`, `credential-rejected`, `policy-refusal`, `parameter-rejected`, `ciphertext-refusal`, `payload-too-large`, `payload-rejected`, `upstream-fault`, `empty-output`, `client-cancelled`, `local-refusal`. |
+
+Valores predefinidos de `providerKind` (26): `openai`, `chatgpt`, `anthropic`, `claude-subscription`, `google`, `vertex`, `xai`, `deepseek`, `moonshot`, `qwen`, `zai`, `minimax`, `mistral`, `openrouter`, `groq`, `cerebras`, `together`, `fireworks`, `cursor`, `kiro`, `copilot`, `devin`, `ollama`, `lmstudio`, `local-other`, `other`.
+
+Valores predefinidos de `modelFamily` (19): `gpt-6`, `gpt-5`, `gpt-4`, `o-series`, `codex`, `claude-opus`, `claude-sonnet`, `claude-haiku`, `gemini-3`, `gemini-2`, `grok`, `deepseek`, `qwen`, `kimi`, `glm`, `minimax`, `mistral`, `llama`, `other`.
+
+<a id="what-is-never-collected"></a>
+
+## Qué nunca se recoge
+
+Los datos de telemetría nunca incluyen:
+
+- Prompts, respuestas, trazas de razonamiento, argumentos de herramientas o cuerpos de solicitudes y respuestas.
+- Claves API, tokens OAuth de acceso o renovación, cookies ni tokens administrativos o del plano de datos.
+- ID de cuenta, correos, identificadores de organización, facturación o planes.
+- Nombres o claves de proveedores elegidos por el usuario, IDs personalizados ajenos a `modelFamily`, que pasan a `"other"`, ni `baseUrl` o URLs de proxy personalizados.
+- Nombres de host, IP local o del proveedor, MAC, números de serie, directorios de trabajo o rutas.
+- Errores libres del proveedor o trazas de pila.
+- Uso del día de consentimiento o aviso (`formatUtcDay(decidedAt ?? noticeShownAt)`) ni anterior: solo días completos posteriores, `day > formatUtcDay(decidedAt ?? noticeShownAt)`.
+- Uso de un día cubierto por `OCX_TELEMETRY=0` o `DO_NOT_TRACK=1`, incluido el último día del proceso con esa variable y el del fin de la desactivación: `day <= ineligibleThroughDay`; tampoco se envía nada mientras exista `envOptOutActiveSince`.
+
+<a id="public-profile-and-rank-opt-in"></a>
+
+## Perfil y posición públicos, con activación explícita
+
+Por separado, puedes conectar un **perfil público** para aparecer en la [clasificación](/es/dashboard/#leaderboard) y ver tu posición del último día, semana y mes. Está desactivado hasta que lo conectes personalmente y no cambia tu elección de telemetría anónima. Requiere que esté activa porque usa los mismos agregados diarios locales.
+
+- **Conectar**: desde *Perfil público y clasificación* en Inicio, o `ocx telemetry profile connect --handle <handle> [--name <display name>] [--avatar <colour>]` en terminal interactiva, con No predeterminado. Elige nombre público de 3–24 letras minúsculas, dígitos o guiones, nombre visible y color de una paleta. No pide correo ni cuenta. Guarda el secreto del recolector en `<OPENCODEX_HOME>/telemetry-profile.json`, modo `0600`; nunca se muestra, imprime ni devuelve por la API del dashboard. El recolector solo guarda su SHA-256. Se rechaza a agentes con `agent_consent_required`, terminales no interactivas con `tty_required` y sesiones recordadas.
+- **Información pública**: nombre público, nombre visible, color, posición y, por día, solicitudes, cinco categorías de tokens y totales por `modelFamily`. Las respuestas de perfiles y clasificación llevan `x-robots-tag: noindex`; la [página del dashboard](/es/dashboard/#leaderboard) es pública y las representa en el navegador.
+- **Envío**: desde el día completo posterior al de conexión, como máximo uno por ciclo y siete días atrás, `POST /v1/profiles/me/days` envía esos totales. No incluye ID de instalación, hash diario, ID de lote, versión, plataforma, canal, tipo o nombre de proveedor, error, prompt, respuesta, clave, cuenta ni ruta. Usa su propio temporizador. Se suspende si la telemetría está desactivada por entorno, rechazada o pendiente del aviso; el perfil permanece conectado y se reanuda al activarla.
+- **Consultar**: `ocx telemetry profile status` muestra perfil, siguiente día apto y posiciones; `ocx telemetry profile status --json` incluye el JSON exacto como `preview`. La tarjeta muestra el perfil y posiciones.
+- **Desconectar**: desde la tarjeta o `ocx telemetry profile disconnect`, siempre permitido, también a agentes, sin proxy o con telemetría desactivada. Elimina perfil y todos sus días del recolector. Sin conexión, la eliminación queda pendiente, cesa el envío y se reintenta en cada ciclo y arranque. Desconectar y conectar reemplaza el secreto.
+- **Clasificación**: se clasifican los totales positivos por periodo con ranking de competición; los empates comparten posición. Los datos son autodeclarados y se comprueban coherencia y límites diarios. Cada día se acepta una sola vez; gana el primer envío.
+- **Control de abuso**: nombres reservados; nombres visibles de 1–32 letras, dígitos, espacios y `. _ ' -` que no parezcan direcciones web; cinco creaciones por red y hora, límites de envíos por perfil, eliminación a los 14 días de perfiles que nunca envían y posibilidad de ocultarlos por los mantenedores.
+- **Inicio de sesión con GitHub**: aún no está disponible; requiere una aplicación OAuth que los mantenedores no han creado.
+
+<a id="storage-retention-and-collector-source"></a>
+
+## Almacenamiento, conservación y código del recolector
+
+- **ID local de instalación y rotación diaria del hash**: cuando la telemetría envía su primer informe, el proxy crea `<OPENCODEX_HOME>/telemetry-id.json` (modo `0600`) con un UUID v4 aleatorio. El UUID sin procesar nunca sale de su máquina; cada informe envía solo `sha256(installId + ":" + day)`. Como la fecha UTC se aplica al hash junto con el UUID, el hash de una instalación cambia cada día y no puede vincularse entre días en el servidor. Rechazar la telemetría o ejecutarla con `OCX_TELEMETRY=0` o `DO_NOT_TRACK=1` elimina `telemetry-id.json` de inmediato, y volver a habilitarla más adelante genera un UUID nuevo.
+- **Agregación de un día en streaming**: `src/telemetry/aggregate.ts` recorre `usage.jsonl` con `scanUsageLedgerCooperatively`; acumula solo el día UTC en `onEntry`, sin guardar filas en memoria.
+- **Planificación y exclusión de días anteriores**: `src/telemetry/scheduler.ts` usa un temporizador sin retener el proceso, fuera de la ruta de solicitudes, a los 30–60 segundos y cada seis horas con variación aleatoria. Cada ciclo tiene `AbortSignal`, cancelado por `stopProcessLoops` o `nudgeTelemetryScheduler`, relee `config.json` y envía como máximo **un** día completo, el pendiente más antiguo de los últimos siete, a `https://telemetry.opencodex.me/v1/events`, con diez segundos de timeout. Exige `day > formatUtcDay(decidedAt ?? noticeShownAt)` y `day > ineligibleThroughDay`. Justo antes de enviar vuelve a comprobar consentimiento y entorno. HTTP `429` o `503` guarda `retryAfterUntil` en `<OPENCODEX_HOME>/telemetry-state.json`; respeta `Retry-After` o espera unos 15–20 minutos. Los marcadores de días enviados se depuran a los 30 días. Un recolector no disponible falla silenciosamente sin afectar al proxy ni marcar el día como enviado.
+- **Un informe por instalación y día**: el recolector evita duplicados por `(day, install_day_hash)` en un lote condicional atómico D1 de `daily_installs`, `daily_totals`, `daily_models` y `daily_errors`. Reenviar el mismo `installDayHash` y día no suma de nuevo.
+- **Hash por hora para límites de tasa, sin IP en bruto**: se admiten **120 informes por hora** y clave, considerando NAT/CGNAT, con HTTP `429` y `Retry-After`. La clave usa únicamente `cf-connecting-ip` de Cloudflare: IPv4 tal cual o prefijo IPv6 /64; ignora `x-forwarded-for`. Aplica sal secreta y hora UTC: `sha256(RATE_LIMIT_SALT + "\0" + bucketHour + "\0" + key)` en `rate_limits`. La tarea horaria `15 * * * *` elimina cada bloque dentro de unas dos horas y 15 minutos.
+- **Instalaciones-día, grupos pequeños y datos no autenticados**: `totals.activeInstalls` e `installs` de `GET /v1/stats` suman instalaciones diarias, no usuarios únicos del periodo. `totals.avgDailyActiveInstalls` calcula `install-days / days in range`, redondeado a un decimal. La protección de grupos pequeños se aplica por día y clave antes de sumar: `providers`, `models`, `versions`, `platforms`, `channels`, `errors` y `dailyByProvider` solo incluyen valores comunicados por **10 instalaciones distintas** ese día. `daily_models`, `daily_errors`, `daily_provider_installs` y `daily_family_installs` cuentan cada informe una vez por clave. Las versiones, plataformas y canales pequeños se agrupan en `"other"`, publicado si llega a diez; proveedores, modelos y errores pequeños se omiten. `totals`, `daily` y `heatmap` no se filtran, por lo que pueden aproximarse valores por resta. `POST /v1/events` **no está autenticado** y permite informes falsificados dentro de sus límites. Nueve informes falsos y uno real sobre una clave rara alcanzan diez y permiten restar la parte falsa. La instalación sigue anónima; el límite de tasa encarece el abuso, sin impedirlo. Por ello el dashboard indica **datos comunicados por instalaciones de opencodex**.
+- **Conservación**: `daily_installs`, con hash diario, versión, canal de versión, sistema, arquitectura, canal de instalación, `new_install` y `active_minutes`, se elimina a los 400 días. Los contadores diarios del proyecto `daily_totals`, `daily_models` y `daily_errors`, sin filas individuales por instalación, se conservan indefinidamente.
+- **Despliegue primero en el recolector y código auditable**: cliente en [`src/telemetry/`](https://github.com/lidge-jun/opencodex/tree/main/src/telemetry) y Worker de Cloudflare con D1 en [`services/telemetry-collector/`](https://github.com/lidge-jun/opencodex/tree/main/services/telemetry-collector). Ambos usan `src/telemetry/contract.ts`; las nuevas categorías o contratos se despliegan primero en el recolector, antes de una versión del cliente que los envíe. Consulta [Servidor y entorno de ejecución](/es/reference/configuration/server/#telemetry-telemetry) para el esquema y las variables.
diff --git a/docs-site/src/content/docs/es/guides/video-bridge.md b/docs-site/src/content/docs/es/guides/video-bridge.md
new file mode 100644
index 00000000000..ffb17761e1a
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/video-bridge.md
@@ -0,0 +1,91 @@
+---
+title: "Puente de video"
+description: "Genera videos con Grok Imagine Video desde un modelo distinto de OpenAI."
+---
+
+<a id="overview"></a>
+
+## Descripción general
+
+El puente de video permite generar videos con Grok Imagine Video de xAI desde cualquier modelo ajeno a OpenAI enrutado mediante opencodex. Al activarlo, se añade la herramienta sintética `video_gen` a la conversación. El modelo la llama como una función; opencodex intercepta la llamada, envía el trabajo a xAI, consulta su estado hasta que termina y descarga el resultado.
+
+<a id="prerequisites"></a>
+
+## Requisitos previos
+
+- Un proveedor `xai` con una **clave API**: `ocx login xai` por sí solo no basta; el puente requiere autenticación con clave.
+- Un modelo de otro proveedor, como Anthropic Claude o Google Gemini.
+- opencodex configurado para enrutar mediante ese proveedor.
+
+> **⚠ Se requiere una clave del proveedor:** El puente solo se activa cuando `xai` utiliza autenticación con clave API. Añada esta referencia a su configuración:
+>
+> ```json
+> {
+>   "providers": {
+>     "xai": { "adapter": "openai-chat", "apiKey": "${XAI_API_KEY}", "authMode": "key" }
+>   }
+> }
+> ```
+>
+> Define `XAI_API_KEY` en el entorno de inicio del proxy, conserva la referencia `${XAI_API_KEY}` y selecciona explícitamente `authMode: "key"`. Exportarla en otra terminal no modifica un proxy activo: reinícialo mediante Desktop, su servicio o la terminal propietaria para que herede el valor. No pongas claves literales en commits, registros o informes compartidos.
+
+<a id="configuration"></a>
+
+## Configuración
+
+Agregue `videoBridgeEnabled: true` a su configuración `images`:
+
+```json
+{
+  "images": {
+    "bridgeEnabled": true,
+    "videoBridgeEnabled": true,
+    "videoBridgeModel": "grok-imagine-video",
+    "videoMaxRounds": 2,
+    "videoTimeoutMs": 300000
+  }
+}
+```
+
+| Opción | Predeterminado | Descripción |
+|--------|---------|-------------|
+| `videoBridgeEnabled` | `false` | Interruptor maestro. Debe estar explícitamente habilitado. |
+| `videoBridgeModel` | `"grok-imagine-video"` | Id. de modelo de vídeo xAI. |
+| `videoMaxRounds` | `2` | Número máximo de rondas de generación de video antes de forzar la respuesta final. |
+| `videoTimeoutMs` | `300000` (5 min) | Plazo máximo por video, incluidas las consultas de estado. |
+
+<a id="how-it-works"></a>
+
+## Cómo funciona
+
+1. opencodex detecta un modelo enrutado no OpenAI con `videoBridgeEnabled: true`
+2. Una herramienta de función sintética `video_gen` se inyecta en la conversación
+3. Cuando el modelo llama al `video_gen`, opencodex envía un trabajo al endpoint `/videos/generations` de xAI
+4. El puente sondea el estado del trabajo cada 5-15 segundos, enviando mensajes de latido para mantener viva la transmisión
+5. Cuando el video está listo, se descarga en el directorio de artefactos
+6. La ruta local del archivo se devuelve al modelo como resultado de la herramienta
+
+<a id="supported-parameters"></a>
+
+## Parámetros soportados
+
+La herramienta `video_gen` acepta:
+
+| Parámetro | Tipo | Alcance | Descripción |
+|-----------|------|-------|-------------|
+| `prompt` | cadena | requerido | Indicación detallada de generación de vídeo |
+| `duration` | entero | 1-15 | Duración del vídeo en segundos |
+| `resolution` | cadena | `"480p"`, `"720p"` | Resolución de vídeo |
+| `aspect_ratio` | cadena | 7 relaciones | `16:9`, `9:16`, `1:1`, `4:3`, `3:4`, `3:2`, `2:3` |
+
+<a id="limitations"></a>
+
+## Limitaciones
+
+- **xAI solamente**: La generación de video solo está disponible mediante la API Grok Imagine Video de xAI
+- **Asíncrono**: La generación de video toma 30-120 segundos
+- **Coste**: la generación de video es una función de pago de xAI. Consulta las [tarifas oficiales](https://docs.x.ai/developers/pricing) antes de usarla.
+- **Un video por llamada**: Cada llamada `video_gen` produce un vídeo
+- **Coexiste con Image Bridge**: Ambos puentes se pueden habilitar simultáneamente
+- **Prioridad de búsqueda web**: Cuando un sidecar de búsqueda web está activo durante un giro (no adaptador `runTurn`), el puente de vídeo se salta - los dos no pueden funcionar simultáneamente. Se emite un `console.warn` para que pueda detectarlo en registros.
+- **Plazo compartido entre el envío y las consultas**: `videoTimeoutMs` empieza antes de enviar el trabajo. La solicitud de envío (60 s) y las consultas posteriores comparten el mismo plazo máximo.
diff --git a/docs-site/src/content/docs/es/guides/web-dashboard.md b/docs-site/src/content/docs/es/guides/web-dashboard.md
new file mode 100644
index 00000000000..6111cac87c4
--- /dev/null
+++ b/docs-site/src/content/docs/es/guides/web-dashboard.md
@@ -0,0 +1,407 @@
+---
+title: "Dashboard web"
+description: "Dashboard de opencodex para gestionar el proxy, proveedores, modelos, delegación, cuentas, uso y registros."
+---
+
+opencodex incluye un dashboard web local, una aplicación Vite/React en `gui/` servida por el proxy. Permite gestionar proveedores, cuentas de Codex/ChatGPT, el catálogo de modelos, sidecars, subagentes y tráfico de solicitudes.
+
+<a id="opening-it"></a>
+
+## Abrirlo
+
+```bash
+ocx gui
+```
+
+El comando abre en el navegador la dirección del proxy en ejecución: `http://127.0.0.1:<port>` por defecto o `http://[::1]:<port>` si escucha en una dirección literal de loopback IPv6. Estas direcciones literales conservan el origen configurado que exige el emparejamiento local del navegador. Si está habilitado el acceso de administración del hub, abre `http://127.0.0.1:<management port>`. Si hace falta, inicia primero el proxy. Para desarrollar, puedes ejecutar el servidor de la GUI por separado contra un proxy activo; inicia cada comando en su propia terminal:
+
+```bash
+ocx start
+```
+
+Mantén el proxy en ejecución en esa terminal. En una segunda terminal, inicia el servidor de desarrollo del dashboard:
+
+```bash
+bun run dev:gui
+```
+
+<a id="sign-in"></a>
+
+## Iniciar sesión
+
+Cuando el proxy escucha en la dirección local predeterminada de loopback (`localhost` / `127.0.0.1`), el dashboard no pide un token. El proxy incorpora sesiones de GUI de corta duración en la página servida y las renueva automáticamente cuando caducan o se reinicia. Solo un dashboard que escucha en un hostname fuera de loopback requiere el token de administración: `OPENCODEX_ADMIN_AUTH_TOKEN` o el archivo generado automáticamente `~/.opencodex/admin-api-token`.
+
+Si el dashboard remoto necesita esa credencial, muestra un formulario de contraseña estándar para que el gestor de contraseñas del navegador pueda ofrecer guardarla y completarla. El dashboard conserva el token únicamente en memoria y nunca lo escribe en `localStorage` ni en `sessionStorage`. Guardarlo depende exclusivamente del navegador o del gestor de contraseñas.
+
+**Recordar este dispositivo** está desactivado por defecto. En un dashboard HTTPS directo (o en loopback local), intercambia el token de administración por una cookie de dispositivo emitida por el servidor, HttpOnly y SameSite=Strict, y una prueba independiente del dispositivo guardada en el localStorage de este sitio. Las cookies HTTPS son Secure y están restringidas al host. Ni la cookie ni la prueba son el token de administración, y ninguna funciona por sí sola. Las cookies se comparten entre los puertos de un mismo hostname; la prueba, limitada al origen, vincula el dispositivo recordado al origen de este dashboard. Aun así, conviene usar un hostname exclusivo. El token de administración nunca se escribe en localStorage ni sessionStorage. Si el almacenamiento del navegador no está disponible o no puede guardar la prueba, Recordar indica que no está disponible.
+
+El archivo privado dashboard-sessions.json almacena hashes de la cookie, la prueba, la credencial de administración y la identidad del navegador, el origen del servidor y una caducidad fija de 30 días. Volver a abrir la aplicación de Safari añadida a la pantalla de inicio reanuda una sesión breve de GUI mientras ese registro sea válido. Las sesiones recordadas no pueden aprobar acciones que requieren consentimiento: estrellas de GitHub, consumo de créditos de restablecimiento, cambios en la capa de prompts, inicio de sesión de Meta Muse, cambios de compatibilidad de escritorio o validación de cuotas. Para esas acciones, usa una sesión local o emparejada nueva. Los dashboards de otro origen o retransmitidos y el HTTP remoto sin cifrar no admiten Recordar. La caducidad, un cambio de identidad del navegador o la rotación del token de administración seguida de un reinicio del servidor obligan a iniciar sesión de nuevo.
+
+Cuando **Olvidar este dispositivo** en la barra lateral o en la barra de acciones móvil tiene éxito (al igual que cerrar la sesión), revoca de inmediato el registro y todas las sesiones reanudadas desde él, y elimina la prueba del navegador. Si falla el cierre de sesión, conserva la prueba para que puedas reintentarlo. El servidor sincroniza el contenido del registro antes de publicar el cambio; la persistencia de la entrada del directorio tras un cierre inesperado se garantiza solo en la medida de lo posible. Las claves antiguas de tokens bearer recordados se eliminan sin leerlas ni migrarlas. Úsalo únicamente en un dispositivo de confianza. Esto no hace que Safari ofrezca autocompletar contraseñas.
+
+Una sesión ya emitida que siga siendo válida en los demás aspectos puede usar **Olvidar este dispositivo** incluso después de un cambio del User-Agent del navegador; el acceso ordinario y la reanudación siguen exigiendo la identidad original del navegador.
+
+<a id="remember-behind-a-reverse-proxy"></a>
+
+### Recordar tras un proxy inverso
+
+La opción `dashboardTrustedProxy`, solo en una instancia independiente y con activación explícita, indica el origen exacto del navegador y las IP desde las que conecta el proxy:
+
+```json
+"dashboardTrustedProxy": {
+  "origin": "https://ocx.example.com",
+  "proxyAddresses": ["192.168.1.20"],
+  "trustHeaders": ["x-forwarded-proto"]
+}
+```
+
+- `origin` debe ser un origen `https://` exacto, sin ruta, comodines o credenciales; se rechaza `http://`.
+- `proxyAddresses` contiene las IP del proxy vistas desde este equipo, `127.0.0.1` si es local, sin rangos, comodines ni hostnames. Una IP distinta no se trata como proxy aunque envíe esos encabezados.
+- Por defecto se lee `Host`; conserva el original. `x-forwarded-host` en `trustHeaders` selecciona `X-Forwarded-Host`; `x-forwarded-proto` exige además `X-Forwarded-Proto: https`.
+- Un encabezado `X-Forwarded-Host` o `X-Forwarded-Proto` contradictorio o con varios saltos rechaza la solicitud aunque no sea de confianza.
+- Para un puerto no predeterminado con `x-forwarded-host`, reenvía también el puerto; en nginx usa `$http_host` en vez de `$host`.
+- Si el proxy sirve HTTP sin cifrar para ese host, exige `x-forwarded-proto` para rechazarlo.
+- Solo se respeta en bind fuera de loopback, con token de administración. Hub lo ignora y usa su listener de gestión.
+
+Recordar sigue exigiendo el token; un certificado de cliente en el proxy no otorga acceso por sí solo. Se mantienen Origin, caducidad de 30 días, Olvidar y restricciones de consentimiento. `ocx config set` rechaza valores inválidos; una edición manual inválida desactiva la opción. Reinicia OpenCodex tras cambiarla.
+
+<a id="finding-the-admin-token"></a>
+
+### Encontrar el token de administración
+
+Solo necesitas este token cuando el proxy escucha fuera de loopback. Un dashboard local no lo pide. Si uno local solicita autenticación, consulta [Cuando un panel local no puede iniciar una sesión](#when-a-local-dashboard-cannot-start-a-session).
+
+El proxy genera el token la primera vez que se inicia. Por diseño, no lo imprime. Puedes leerlo desde su archivo:
+
+```bash
+cat ~/.opencodex/admin-api-token
+```
+
+Si `OPENCODEX_HOME` está establecido, la ruta es `$OPENCODEX_HOME/admin-api-token`. En Windows, la ubicación predeterminada es `%USERPROFILE%\.opencodex\admin-api-token`. Un token generado consta de `ocx_admin_` seguido de 43 caracteres. Si un archivo no tiene ese formato, el proxy lo rechaza en lugar de regenerarlo silenciosamente.
+
+Para elegir el valor, establece `OPENCODEX_ADMIN_AUTH_TOKEN` antes de iniciar el proxy. La variable tiene prioridad: en ese caso no se lee ni se crea el archivo. Usa un valor diferente de la credencial de datos (`OPENCODEX_API_AUTH_TOKEN` o una clave API configurada); se rechaza la reutilización de una misma credencial en ambos planos.
+
+Ningún comando de la CLI imprime el token. `ocx doctor` solo informa si hay una credencial, sin revelar su valor.
+
+<a id="when-a-local-dashboard-cannot-start-a-session"></a>
+
+### Cuando un panel local no puede iniciar una sesión
+
+El dashboard en `localhost` obtiene su propia sesión y no debería pedir un token. Si no puede iniciar una sesión, la causa es la dirección utilizada: el proxy no reconoció la solicitud como loopback. Abre la dirección exacta que muestra el proxy al iniciar, normalmente `http://127.0.0.1:<port>`, y usa ese host y puerto en lugar de una IP de la red local o un alias.
+
+<a id="classic-dashboard"></a>
+
+## Dashboard clásico
+
+El diseño nuevo abre Inicio y agrupa páginas en **Uso diario**, **Configuración** y **Ajustes avanzados**. El anterior sigue en `/classic/`, por ejemplo `http://127.0.0.1:10100/classic/`.
+
+- Cambia mediante el reloj **Dashboard clásico** al pie de la barra lateral; allí **Nuevo dashboard** permite volver.
+- El navegador recuerda la elección; abrir `/` y Desktop la respetan. El desplegable de bandeja siempre usa el nuevo.
+- El clásico modifica las mismas opciones del proxy, pero las páginas y opciones posteriores al rediseño solo existen en el nuevo.
+
+Las filas descritas en [Distribución del dashboard](#dashboard-layout) corresponden al clásico.
+
+<a id="dashboard-layout"></a>
+
+## Diseño de panel
+
+La barra lateral tiene ocho entradas: **Dashboard**, **Conectar**, **Codex**, **Proveedores**, **Modelos**, **Subagentes**, **Uso y registros** y **Enlace remoto**. **Conectar** muestra las pestañas **Codex**, **Claude**, **Claude Desktop**, **Grok Build** y las demás integraciones. Claude muestra directamente los ajustes de Claude Code, sin subpestañas; Claude Desktop tiene una pestaña independiente en `#claude/desktop`. Conectar no usa un selector de secciones. **Subagentes** agrupa Subagentes y Asesor (`#advisor`); **Uso y registros** agrupa Uso, Registros y depuración, y Almacenamiento; **Enlace remoto** agrupa Enlace remoto (`#remote`) y Espacio de trabajo remoto (`#remote-workspace`, si está disponible). Estos grupos usan un selector de secciones. **Codex** sustituye el nombre anterior **Codex Set**. Se conservan `#codex-set`, `#claude`, `#claude/code` y `#claude/desktop`; el marcador antiguo `#claude/settings` abre Code y `#claude/account` redirige a `#providers?provider=anthropic&tab=accounts`. Inicio (`#startup`) no aparece en la barra lateral.
+
+La medición del tiempo hasta la primera salida de Responses incluye texto, razonamiento, argumentos de funciones transmitidos y entradas de herramientas personalizadas. Por tanto, un turno que solo llama a herramientas puede tener esa medición aunque no genere prosa. Los deltas vacíos y los avisos de inicio de herramienta no activan el temporizador. Se mide la primera salida observada por el proxy, no el comienzo del razonamiento oculto ni la velocidad exacta de generación del modelo.
+
+La vista general usa tarjetas de estado y filas de ajustes de ancho completo. En pantallas amplias, las etiquetas comparten una columna y los controles de modelo y esfuerzo otra. En pantallas estrechas, los controles pasan debajo de sus etiquetas y conservan el orden de lectura. Las versiones largas se acortan visualmente; pasa el puntero por la etiqueta o el valor para leerlos completos.
+
+<a id="quota-summary-bar"></a>
+
+### Barra de resumen de cuotas
+
+La parte superior de cada página, salvo Inicio, muestra en una línea el uso de cuota de los proveedores, por ejemplo `OpenAI 31% | Claude 54% | xAI 12% | Google 8%`. Lee los mismos informes de `GET /api/provider-quotas` que la página Proveedores, cada 60 segundos mientras la pestaña está visible, y nunca fuerza una actualización al proveedor.
+
+- Cada indicador muestra una ventana preferida entre las informadas: primero la semanal, luego la mensual, la de cinco horas y, por último, una ventana con nombre propio del proveedor o sus créditos prepagados.
+- El indicador se vuelve ámbar al 70 % de uso y rojo al 90 %.
+- Pasa el puntero o enfoca el indicador con el teclado para ver todas las ventanas informadas, sus reinicios y la hora de lectura. El detalle sigue abierto al mover el puntero hacia él, incluso al cruzar la separación visual. En una pantalla táctil, el primer toque abre el detalle.
+- Haz clic, o toca por segunda vez, para abrir la pestaña Cuentas de ese proveedor. El enlace **Abrir gestión de cuentas** del detalle abre la misma pestaña; se puede alcanzar con Tab y activar con Enter. Escape cierra el detalle y devuelve el foco al indicador si estaba dentro.
+- La barra permanece en una línea. Si no caben los indicadores, desplázala horizontalmente o usa los botones « y » de los extremos.
+- Tras una respuesta apta de API con clave enviada por el proxy a OpenAI, xAI, Groq, Anthropic o Mistral, fichas separadas por clave y modelo muestran las dimensiones esperadas de solicitudes y tokens. Los campos de encabezado ausentes aparecen como **Unknown**, incluso si la respuesta no contiene encabezados de límite de tasa. Los valores medidos previamente conservan su hora original de observación y quedan obsoletos al restablecerse; el servidor conserva cada observación durante un máximo de 24 horas. Si falla una consulta del panel, puede seguir mostrándose la instantánea anterior. Estas lecturas solo se muestran: no activan consultas ni afectan al enrutamiento. Para una clave del llavero, la lectura se vincula a la credencial ya almacenada en la caché de enrutamiento y se oculta cuando no se puede verificar esa identidad. Un reemplazo externo en el llavero no es visible hasta invalidar dicha caché; mientras tanto, tanto el enrutamiento como la lectura usan la credencial almacenada. Al vaciar la caché, las lecturas se ocultan hasta que el enrutamiento vuelva a leer cada clave. Una nueva lectura coincidente puede restaurar las observaciones conservadas; se descartan las respuestas recibidas mientras la clave no está verificada.
+- Se omiten los proveedores sin informe de cuota ni observación pasiva de clave conservada. La barra se oculta cuando no hay ninguno de los dos.
+- El extremo derecho muestra la hora de la última lectura del dashboard. Se vuelve ámbar si falló la lectura más reciente y se siguen mostrando los datos anteriores.
+
+<a id="what-you-can-do"></a>
+
+## Lo que puedes hacer
+
+| Zona | Lo que hace |
+| --- | --- |
+| **Resumen del panel** | Modo multiagente, estado en línea, versión, tiempo de actividad, recuento de proveedores, total de 30 días de token, proveedores activos y modelos nativos/enrutados disponibles. |
+| **Retención del razonamiento nativo** | Activa por separado el reenvío de razonamiento cifrado al cambiar de modelo nativo o de cuenta. Ambas opciones están desactivadas por defecto; la retención entre cuentas es experimental. Véase [el ámbito de configuración](/es/reference/configuration/server/#native-reasoning-retention). |
+| **Delegación de subagentes** | Elija un modelo nativo o enrutado y un esfuerzo de razonamiento opcional compartido por la guía de delegación OpenCodex y el opt-in nativo predeterminado separado. Este no es un router proxy por spawn; ver más abajo. |
+| **Sidecares** | Elija el modelo de búsqueda web y el esfuerzo más el modelo de descripción de la visión. Los cambios se aplican en la siguiente solicitud. |
+| **Mantenimiento** | Resincroniza el catálogo de Codex, revisa advertencias de configuraciones locales del proyecto, consulta versiones latest o preview y actualiza con reinicio opcional. Con el reinicio habilitado, se conservan el enrutamiento de Codex y su catálogo durante el reemplazo del paquete, para que Codex siga viendo los modelos enrutados. El proxy reiniciado asume esa configuración; si no vuelve a iniciarse, `ocx stop` restaura Codex nativo. En Desktop, la entrada de actualización abre la página de actualización de la aplicación nativa. |
+| **Seguridad de inicio** | Mostrar si el enrutamiento Codex inyectado sobrevive a un reinicio, con servicio separado y estado del lanzador más comandos de reparación exactos. |
+| **Bandeja Windows** | Instale una bandeja de inicio de sesión por usuario para iniciar, detener, reiniciar, acceder al panel y el estado del proxy con un solo clic. La bandeja es un controlador, no un servicio de reinicio proxy. |
+| **Codex autostart** | Permitir que se ejecute una shim de lanzador Codex ya instalada `ocx ensure`. Este conmutador no instala un servicio de shim o de fondo. |
+| **Telemetría** | En **Detalles del proxy** (`#proxy-telemetry`), activa o desactiva compartir estadísticas anónimas y consulta la vista previa JSON. El aviso inicial solo guarda al pulsar **Continuar** (`PUT /api/telemetry`); cerrarlo no registra nada. Consulta [Telemetría y privacidad](/es/guides/telemetry/). |
+| **Proveedores** | Añade, edita, habilita, deshabilita y elimina proveedores; solo los habilitados pueden ser predeterminados. Gestiona grupos de cuentas OAuth y de claves API cuando se admiten. Si eliminas el proveedor predeterminado, se selecciona el primer proveedor habilitado restante; si no hay ninguno, se rechaza la eliminación y se conserva el actual. Los ajustes del proveedor permiten desactivar el descubrimiento en vivo cuando su catálogo `/models` no existe, tarda demasiado o es demasiado grande. En Claude (Anthropic) OAuth, cada cuenta conectada muestra sus propias barras de cuota de cinco horas y semanal: el uso corresponde a cada credencial. Si falla una consulta, se conservan las últimas barras válidas y se marcan como no disponibles hasta que una actualización tenga éxito. La actualización de cuotas omite las cuentas OAuth en pausa y las claves API deshabilitadas; las filas omitidas sin una lectura en caché siguen sin estar disponibles, pero no afectan al resultado de la actualización. La actualización informa de un fallo si una cuenta OAuth sin pausar o una clave API habilitada que admita consultas de cuota tiene una lectura no disponible. Cuando no hay un proveedor seleccionado, la vista general ofrece **Actualizar todas las cuotas**, que fuerza una nueva consulta del servidor para cada proveedor configurado. Si falla la consulta a un proveedor, se conserva su última fila válida. El estado informa de que la comprobación terminó, sin afirmar que todos los valores sean nuevos; la antigüedad de cada fila indica la vigencia de sus datos. |
+| **Añadir proveedor** | Una búsqueda por encima de las pestañas llega a los cuatro a la vez — Cuentas, Gratis, Local, Pagado. Mientras una consulta está en vivo, los resultados se agrupan por pestaña con un recuento de cada uno, y la pestaña seleccionada se mantiene en lugar de saltar. Presione ArrowDown en el cuadro de búsqueda para enfocar la primera acción de resultado disponible, omitiendo los botones desactivados; si no hay ninguna acción disponible, el enfoque permanece en el cuadro de búsqueda. Los tiempos de ejecución locales (Ollama, vLLM, LM Studio, LitelLM) tienen su propia pestaña, y una larga nota del proveedor se fija a dos líneas con el texto completo a un clic de distancia. Claude Code CLI (suscripción) se encuentra bajo Pagado con una suscripción CLI insignia, y al seleccionarlo advierte que se factura la suscripción iniciada a través de Claude `claude -p` y nunca usa una clave API (usar `anthropic-apikey` ej., para facturación de claves). |
+| **Codex Autonomía** | Agregue cuentas de grupo ChatGPT/Codex, seleccione la cuenta de la siguiente sesión, actualice las cuotas de 5h / semanal / 30d, habilite o deshabilite el cambio automático de cuota, establezca su umbral 1–100% y configure la conmutación por error de transitorios. |
+| **Subagentes** | Define las primeras cinco prioridades de `spawn_agent` mediante `subagentModels`, con modelos nativos sin prefijo o modelos enrutados con espacio de nombres. No es una lista de permitidos: las posiciones libres pueden completarse con filas visibles del catálogo. El panel **Límites del flujo de trabajo para subagentes** controla los turnos simultáneos, las solicitudes al modelo y los subagentes distintos permitidos por tarea en cada ventana de 10 minutos. Consulta [Límites del flujo de trabajo](/es/reference/configuration/server/#workflow-limits). |
+| **Modelos** | Alternar GPT nativo y modelos enrutados, establecer listas de proveedores y límites de contexto, elegir v1/base/v2 y configurar el límite de hilos v2. La página distingue un catálogo guardado en el concentrador, un catálogo obtenido por este cliente y la activación en un cliente en ejecución. Una marca de tiempo fetch no prueba que incluya la última función de guardado del concentrador, y la activación en entorno de ejecución se muestra como no verificada. Los proveedores configurados permanecen visibles como grupos de modelo cero cuando la detección está desactivada o no devuelve filas. |
+| **Registros** | Actualizar automáticamente las solicitudes recientes con tokens, el esfuerzo solicitado y (cuando esté disponible) el esfuerzo de salida efectivo, el modelo resuelto, el proveedor, el estado, la identificación de la solicitud, la duración y los detalles del error. La vista de detalle incluye el campo exacto del cable de razonamiento cuando el adaptador emite uno. Filtrar por ID de conversación/sesión opaca (cuando el cliente envía uno) a tokens total y costo de lista-precio estimado para el anillo de registros cargado actualmente. |
+| **Uso / Depuración** | Inspeccione la cobertura y las tendencias de uso de token. La tabla Modelos de la página de Uso también divide cada modelo en tokens de entrada, tokens de salida, aciertos de caché, escrituras de caché y tasa de aciertos de caché; un guion significa que la telemetría de caché para esa métrica no está disponible. O habilite el transporte de proveedores y los diagnósticos de extracción de uso. |
+| **Almacenamiento** | Desglose de solo lectura del espacio usado en CODEX_HOME: sesiones, archivos, bases de datos y adjuntos. La limpieza opcional de archivos permite previsualizar el N% más antiguo y enviarlo después a cuarentena en `CODEX_HOME/.trash` (opción predeterminada), o eliminarlo definitivamente mediante una casilla de confirmación explícita. La **política de autolimpieza** requiere activación y está **desactivada de forma predeterminada** (`storageCleanupPolicy.enabled`); configura el umbral, el objetivo, la programación y el modo en Almacenamiento, o selecciona **Ejecutar ahora**. Las entradas en cuarentena se pueden restaurar desde esa página (JSONL e hilos). Las sesiones activas son de solo lectura. La limpieza y la restauración se rechazan mientras Codex mantiene bloqueada la base de datos `state_*.sqlite` más reciente o activa. |
+| **Detener** | Detiene de forma ordenada el proxy y el servicio en segundo plano instalado, restaura Codex nativo y termina el proceso (`POST /api/stop`). En Windows con el backend del Programador de tareas, el dashboard rechaza la acción y pide ejecutar `ocx stop`: el contenedor puede volver a iniciar el proxy al terminar la tarea, y la parada debe ejecutarse fuera de ese proceso para comprobar que no reaparezca antes de restaurar la configuración del cliente. Si el proxy pertenece a OpenCodex Desktop, también se rechaza la acción porque la aplicación lo iniciaría de nuevo; usa **Detener proxy** o **Salir** en la bandeja de la aplicación. Ninguno de estos rechazos modifica la configuración. |
+
+Si no se pueden incluir algunos registros de uso, las vistas de Uso, Dashboard, espacio de trabajo del proveedor, catálogo de proveedores y claves API muestran una advertencia, incluso si no queda ningún registro legible. Los recuentos, las fechas y las clasificaciones de uso reflejan únicamente los registros legibles. **Modelos → Instantánea de los más usados → Aplicar orden** rechaza guardar una instantánea incompleta; elige otro orden o repara el historial antes de volver a intentarlo.
+
+<a id="account-selection"></a>
+
+### Selección de cuenta
+
+La selección de cuenta se comparte con el enrutamiento de solicitudes. Elegir manualmente una cuenta OAuth se aplica a la siguiente solicitud, incluso si hay un grupo habilitado. Una cuenta válida no se sustituye solo porque otra cuenta OAuth genérica tenga más cuota disponible. Si la cuenta devuelve 429, la conmutación automática todavía puede seleccionar otra cuenta utilizable aunque el grupo esté desactivado. Una selección automática confirmada se refleja de inmediato en el dashboard, sin esperar al temporizador de actualización de cuotas. Las solicitudes ya enviadas al proveedor conservan sus credenciales originales.
+
+<a id="filtering-request-logs"></a>
+
+### Filtrar registros de solicitudes
+
+Los detalles de una solicitud priorizan una causa reconocida de fallo del proveedor sobre un mensaje genérico de error del proxy. Siempre muestran los envíos físicos cuando su recuento es válido; si falta o no es válido, indican **No disponible**, no cero. **Reintentos** cuenta los envíos posteriores al primero solo cuando hay un único intento registrado de forma completa y coherente. Si hay varios intentos, resultados pendientes, inconsistencias o una normalización con pérdida de información, el recuento se omite. Una causa persistida desconocida utiliza el encabezado correspondiente al estado HTTP, sin mostrar atribuciones en bruto.
+
+**Motivo del proveedor** muestra una condición clasificada, como límite de tasa, cuota o créditos agotados, exceso de contexto, ubicación no admitida, verificación de cuenta requerida o modelo no disponible. **Detalle del fallo** muestra texto redactado por el proxy, como un timeout de inactividad o un límite de bytes; las filas nuevas no guardan el mensaje de error original del proveedor. Los archivos `usage.jsonl` antiguos aún pueden contenerlo, pero el dashboard lo descarta al leerlos.
+
+Cuando el proxy rechaza repetir una solicitud, conserva HTTP 429 y el código `upstream_reset_replay_refused`. Sin embargo, la causa del fallo de la solicitud y del intento es `transport-ambiguous`, con permiso de reenvío `refused-ambiguous`: el proveedor puede haber procesado ya el turno. Un 429 auténtico del proveedor sigue clasificado como `rate-limit`, con permiso de reenvío `permitted`.
+
+Si Codex cambia de cuenta después de un HTTP 402, los detalles de recuperación del intento muestran **Cuota de cuenta agotada (402)**. También se contabiliza como una recuperación de cuota en las métricas exportadas.
+
+Los filtros de registros combinan superficie, solicitudes interceptadas, proveedor, modelo exacto, estado, tiempo, velocidad e identificador de conversación sobre el búfer de solicitudes cargado. Las opciones de proveedor y modelo también incluyen los intentos de fallback. Los modelos se comparan sin distinguir mayúsculas ni espacios al principio o al final, pero no se aceptan coincidencias parciales. Las opciones que desaparecen del búfer se restablecen a Todos.
+
+El campo de conversación también acepta enlaces `codex://threads/<id>`, como los que genera la opción de Codex para copiar el enlace de sesión. Se ignoran el envoltorio del enlace y sus metadatos, como `?hostId=…`, y se compara únicamente el identificador del hilo. Es el mismo valor que extrae una búsqueda con `ocx logs filter --conversation`.
+
+Las ventanas temporales abarcan los últimos 15 minutos, una hora o un día. Se actualizan cada 30 segundos mientras la pestaña Registros está activa, incluso con la actualización automática desactivada. Usan la marca de tiempo del proxy incluida en la respuesta de registros y avanzan con el tiempo transcurrido en el navegador, para que una diferencia entre relojes no desplace el límite. Con un proxy antiguo que no envía esa marca, se usa el reloj del navegador hasta recibir una muestra válida. La velocidad corresponde a los tokens de salida por segundo durante toda la solicitud: menos de 15, de 15 a menos de 50, o al menos 50. Si hay un filtro de velocidad activo, se excluyen los valores no disponibles. Éxito significa 2xx; error significa 4xx o 5xx.
+
+La lista de registros y la tabla de intentos identifican cada estimación de decodificación como **Ventana de generación** o **Después de la salida visible**. Los detalles usan **Velocidad de salida durante la generación (est.)** o **Velocidad de salida después de la primera salida visible (est.)**. Las respuestas antiguas en caché sin método de medición muestran **Tiempo desconocido** y **Velocidad de salida (est.; método de medición desconocido)**. Una nota bajo la velocidad explica el método; no aparece si la velocidad no está disponible.
+
+Si el proxy observó ambos extremos, divide los tokens de salida entre la duración desde el primer elemento o bloque de salida, incluido el razonamiento, hasta el último delta. Las filas antiguas sin esa ventana usan el tiempo entre el primer token visible y el final de la solicitud. Son observaciones del proxy, no tiempos internos del proveedor: siempre son estimaciones y una ventana inferior a un segundo se muestra como no disponible. Ambos numeradores incluyen los tokens de razonamiento informados, por lo que los dos métodos no son directamente comparables. No se reescriben los registros históricos ni se inventan marcas de tiempo ausentes. La columna tok/s de extremo a extremo y el filtro de velocidad anteriores no cambian.
+
+Los filtros activos muestran el recuento correspondiente del total cargado. Restablecer filtros restaura todo filas y devuelve el foco del teclado al control de toda la superficie; “Sin solicitudes coincidentes” difiere de un anillo de registro vacío. Utilice las teclas de flecha o Home/End en el selector de superficie. Estos controles no consultan registros históricos más allá del anillo cargado.
+
+El selector de idioma incluye **Portugués** (Portugués brasileño, `pt-BR`) Los idiomas del navegador portugués lo seleccionan automáticamente a menos que ya se guarde una preferencia de idioma compatible.
+
+<a id="linking-to-a-section"></a>
+
+### Vincular a una sección
+
+Hay un solo diseño, por lo que no hay ningún interruptor de diseño para configurar. Las secciones del panel son direccionable en su lugar: `#dashboard` abre Vista general, y `#dashboard/providers` y
+`#dashboard/models` Abre los otros dos. Recargar, marcar y Atrás todos mantienen la sección que estabas encendido. **Registros** Funciona de la misma manera con `#logs` y `#logs/debug`. Un viejo `#providers/workspace`
+Marcador ahora aterriza en `#providers`.
+
+Valores de costos en **Registros** y **Uso** son equivalentes de lista-precio de API calculados a partir de tokens notificado. Para un intervalo de uso personalizado, el servidor debe confirmar las horas de inicio y fin solicitadas. Si un proxy de ejecución anterior no admite esos límites, el panel de control y CLI rechazan su informe; Actualizar y reiniciar ese proxy antes de volver a intentarlo. Restablecer un precio de modelo manual afecta solo a modelo, conservando otras tasas ahorradas independientemente. Los **Uso** Las tablas de resumen y Modelos/Proveedores muestran el rendimiento de salida de extremo a extremo del historial de uso para el rango y los filtros seleccionados: salida sumada tokens dividida por segundos de reloj de pared sumados, no un promedio de tasas individuales. El recuento de muestras se mide por intentos (o solicitudes de filas heredadas sin intentos); se excluyen las muestras que carecen de salida finita positiva tokens o duración. Un guión significa que no hay muestra calificada o el servidor devolvió una tasa inutilizable. Esto incluye la espera de predecodificación y no es una velocidad de decodificación estimada.
+
+Las tablas de modelos y proveedores de **Uso** muestran la parte del costo que se pudo estimar para cada fila. Si el proxy informa la cobertura de precios, junto al importe aparece el número de solicitudes excluidas por falta de una tarifa aplicable o de datos de consumo utilizables. El consumo medido solo parcialmente (`unreported` o `unsupported`) no se valora; una parte potencialmente facturable cuyo costo se desconoce excluye toda la solicitud del recuento con precio de esa fila.
+
+Un intento sin datos de consumo que nunca llegó al proveedor, o que recibió un error HTTP antes de generar salida y sin una interrupción del stream, tiene un costo conocido de cero. No añade costo ni excluye la parte medida de otro intento de la misma solicitud. En cambio, una cancelación del cliente (499), o un intento cuya respuesta empezó o terminó sin estado ni datos de consumo, pudo generar un cargo: ese costo desconocido sí excluye la solicitud del recuento con precio. Un rechazo seguido de un envío exitoso y medido aporta el costo de ese envío al resumen aunque el estado de consumo agregado sea `unreported`. En el resumen general, una solicitud formada solo por rechazos de costo conocido cero sigue sin medición; no se convierte en una estimación confirmada de cero dólares.
+
+Una fila con todas las solicitudes excluidas muestra un guion y su recuento, no una estimación de cero dólares. Un cero mostrado sí representa una estimación calculada. Un proxy antiguo que no informa la cobertura muestra solo un guion, sin recuento: así se distinguen la cobertura ausente, una fila completamente excluida y una estimación cero confirmada. Son estimaciones de tarifa pública, no recibos ni pruebas de un cargo real; pueden aplicarse cuotas de suscripción o créditos del proveedor.
+
+La atribución de uso conserva el modelo y proveedor resueltos por el servidor: los tokens pertenecen al proveedor que atendió la solicitud, no necesariamente al nombrado al entrar. El dashboard conserva el nombre y el uso originales sin adivinar qué modelo se ejecutó. Para un nombre no resuelto que contenga barras, el precio de un modelo de **otro proveedor** no basta para estimar el coste; sí puede aplicarse el precio del proveedor exacto o uno configurado. Las proporciones de modelos se calculan dentro del proveedor seleccionado. Una solicitud a un nombre reservado `policy/` desconocido falla antes de contactar al proveedor; se conserva el uso histórico.
+
+El proveedor seleccionado **Descripción general** y **Uso** tabuladores muestran **Uso de la cuenta corriente** debajo de la Estadísticas de uso. **Cuentas** y **Claves API** muestre la cuota propia de cada credencial soportada, incluyendo saldos de crédito. La visión general de todo el proveedor todavía muestra la capacidad combinada cuando está disponible; no se sustituye por una lectura de cuenta corriente faltante. Búsqueda sin soporte, sin pasivo observación, carga, búsqueda fallida con valores conocidos por última vez y cero medido están separados estados. **Control de cuotas completado** significa la lectura settled—not que una observación pasiva se convirtió en nuevo o que todas las mediciones anteriores se actualizaron.
+
+<a id="model-visibility"></a>
+
+## Visibilidad del modelo
+
+Los **Modelos** Los switches muestran la visibilidad final de Codex: un modelo enrutado solo está activado cuando su lista de proveedores lo incluye (o no está configurada) y no está desactivado. Activar un modelo reconcilia ambos filtros atómicamente; **Todos en** borra la lista de proveedores para que los modelos recién descubiertos también estén encendidos.
+
+Los interruptores responden de inmediato y puedes seguir cambiando modelos mientras los cambios se guardan en segundo plano, en el orden en que haces clic. La confirmación aparece cuando la cola termina y la lista se actualiza con el estado del servidor. Si un guardado falla, se muestra un error y se restaura el estado del servidor cuando puede leerse. Espera esa confirmación antes de salir de **Modelos** o cambiar de servidor: los cambios que sigan en cola y aún no se hayan enviado se descartan al salir.
+
+<a id="managing-models-in-a-provider-workspace"></a>
+
+### Administrar modelos en un espacio de trabajo de proveedor
+
+En un proveedor **Modelos** token: **Eliminar** elimina la definición personalizada almacenada. Un subyacente El modelo nativo o el modelo descubierto en vivo pueden volver a aparecer, por lo que el recuento de modelos puede permanecer igual.
+**Ocultar** solo cambia la visibilidad del catálogo: no elimina la definición ni cambia directamente política de enrutamiento. Uso **Gestionar la visibilidad en modelos** para abrir el **Modelos** página y restaurar visibilidad, incluso cuando la pestaña del proveedor no tiene filas.
+
+**Añadir** guarda una definición personalizada; no borra una regla de selección de proveedores o ocultación existente. Por lo tanto, un modelo guardado puede permanecer oculto. Si el modelo ya se conoce, gestionar su visibilidad en **Modelos**. Todavía se guarda un guardado confirmado con una actualización de catálogo fallida: siga la actualización mensaje en lugar de añadirlo de nuevo. Si el cambio no se puede confirmar, actualice el estado del modelo antes de volver a intentarlo.
+
+El recuento de modelos del proveedor es el número de entradas únicas no desactivadas en el modelo actual. inventario devuelto por el servidor, antes de buscar o mostrar truncamiento. No es el proveedor tamaño de lista de permisos, un recuento de descubrimiento en vivo o prueba de que se descubrió una entrada de origen. Selección Las insignias y la información de descubrimiento permanecen separadas de esa cuenta.
+
+<a id="delegation-picker-vs-spawn-routing"></a>
+
+## Selector de delegación vs enrutamiento de generación
+
+El selector **Delegación de subagentes** guarda las preferencias orientativas `injectionModel` e `injectionEffort`, este último opcional. **Guía multiagente de OpenCodex** controla por separado si aparecen en la guía de los turnos v2 aptos. El texto incorporado nombra preferencias sin ordenar cambios de modelo; no garantiza qué argumentos enviará Codex a `spawn_agent`. Borrar el modelo también borra el esfuerzo.
+
+La opción **Usar como valores predeterminados de subagentes nativos de Codex** está desactivada de forma predeterminada. Si OpenCodex administra el enrutamiento activo, aplica la misma selección a los valores nativos de `[agents]` en la siguiente sincronización o reinicio. Respeta la configuración de proveedores externos del usuario. Solo afecta a tareas de Codex creadas después y no provoca delegación por sí misma. Los valores de `[agents]` definidos por el usuario se conservan, por lo que pueden seguir teniendo prioridad sobre los solicitados.
+
+:::caution
+Ninguno de los controles es un router de generación de modelos cruzados del lado proxy. La guía OpenCodex le pide a Codex que pase Anulaciones para `spawn_agent`; nativo `[agents]` los valores predeterminados se aplican solo cuando Codex crea una nueva tarea después de han sido sincronizados. Véase
+[Interfaz de subagentes](/es/guides/sub-agent-surface/) para el comportamiento canónico v1/base/v2.
+:::
+
+<a id="remote-hub-sessions-keys-and-usage"></a>
+
+## Sesiones, claves y uso de Remote Hub
+
+En **Conectar → Claves API**, cada fila tiene un botón para eliminar su clave tras pedir confirmación. Al pulsar una clave, una sesión autorizada de forma independiente puede mostrar su valor completo y un botón **Copiar**.
+
+<a id="applying-a-codex-cli-update-over-http"></a>
+<a id="applying-a-codex-cli-update-from-the-dashboard"></a>
+
+### Actualizar Codex CLI desde el dashboard
+
+**Codex → Codex CLI** comprueba y actualiza la CLI usada por OpenCodex, por separado de OpenCodex; nunca modifica Codex Desktop. **Buscar actualización** es de solo lectura: muestra instalador, propiedad, versión instalada y disponible, sesiones activas y causa de rechazo. Solo permite un plan aplicable y exige confirmar que cambia únicamente esa instalación. Aplica exactamente el plan mostrado y sigue su trabajo hasta actualizado, sin cambios, rechazado o incierto. Un resultado incierto nunca se reintenta ni revierte: inspecciona la instalación. Consultar de nuevo descarta plan y confirmación anteriores. Un dashboard conectado a Remote Hub informa que debe ejecutarse en el equipo propietario.
+
+Aplicar exige una sesión vigente emparejada explícitamente en una entrada loopback de confianza, Origin y CSRF coincidentes y `confirmed: true`. Inicio local automático, sesión recordada, token de administración o Tailscale solos no autorizan. Si falta esa autoridad, muestra el formulario local de emparejamiento y el comando `ocx system codex-cli-update apply`. Usa el origen literal `http://127.0.0.1:<port>` o `http://[::1]:<port>` configurado y `ocx gui pair --origin "<browser-origin>"`; `localhost`, un bind comodín o un rol de cliente no emiten esa autoridad. Emparejar no actualiza nada por sí solo.
+
+La alternativa local sigue siendo `ocx system codex-cli-update plan` y `ocx system codex-cli-update apply --plan-id <32-hex> --yes`, con el mismo propietario persistente del trabajo. La prueba es autoridad sobre el directorio protegido, no identidad humana ni defensa frente a procesos sin restricciones del mismo usuario.
+
+<a id="reading-an-existing-api-key"></a>
+
+### Lectura de una clave API existente
+
+Para mostrar el valor completo de una clave guardada, se necesita una sesión del dashboard autorizada mediante emparejamiento explícito o una identidad de Tailscale de confianza. Una sesión local automática puede mostrar la lista enmascarada, pero no revelar valores existentes; un token de administración sin esa sesión tampoco sirve. Usa el [flujo de emparejamiento](/es/guides/remote-hub/#pairing-this-browser-with-a-hub) antes de solicitar el valor. Si se rechaza, la página explica el requisito. El formulario local solo se ofrece en un dashboard independiente del mismo origen, abierto por HTTP en la dirección literal `127.0.0.1` o `[::1]`, y el origen debe coincidir con la dirección literal de loopback configurada en el servidor. Si abriste `http://localhost:<port>` u otro alias, comprueba esa configuración y abre `http://127.0.0.1:<port>` para un servidor enlazado a `127.0.0.1`, o `http://[::1]:<port>` para uno enlazado a `::1`. Un servidor configurado con hostname `localhost` no tiene un origen local elegible para este formulario. El dashboard no puede deducir la dirección configurada a partir de un alias; por eso muestra una denegación genérica sin proponer otra URL. En ese caso usa el emparejamiento de Remote Hub o Tailscale de confianza, si está disponible. Vuelve a emparejar si la sesión caduca o se revoca. El inicio de sesión normal y la creación, rotación y eliminación de claves no cambian.
+
+Después del emparejamiento, vuelve a pulsar la clave para solicitar su valor; emparejar por sí solo no revela ninguna clave. Los valores visibles y los avisos de copia se borran al quitar o sustituir la sesión compartida, iniciar un emparejamiento, salir de esta página, ocultar la pestaña o ventana de Desktop, o cambiar de servidor. Esto también afecta a los valores recién creados o de reemplazo: copia el valor de una sola visualización antes de salir. Si una creación o rotación termina después de cambiar de sesión o vista, su valor permanece oculto. Al regresar al servidor original, se vuelve a validar la lista de claves. Las rotaciones pendientes siguen disponibles para confirmarlas o cancelarlas expresamente.
+
+La administración desde el dashboard está separada del tráfico de modelos directo entre cliente y hub. **Conectar → Claves API** muestra las rotaciones pendientes, revela el secreto de reemplazo una sola vez y requiere confirmación o cancelación explícita. Cerrar sesión en el navegador invalida únicamente la sesión remota actual. Con conexión se consulta el uso guardado en el hub filtrado por el `apiKeyId` del cliente; sin conexión se muestra el uso local, sin duplicarlo.
+
+La guía v2 **incorporada** presenta preferencias orientativas, sin garantizar cambios de modelo al crear subagentes. Un `injectionPrompt` personalizado la sustituye por completo y debe incluir `{{model}}` y `{{effort}}`, y opcionalmente `{{roster}}`, para mostrar esos valores.
+
+El selector ofrece modelos nativos y enrutados habilitados, además de la escalera de esfuerzo global Codex. El API valida el esfuerzo seleccionado globalmente; Codex todavía valida un esfuerzo de generación contra el objetivo Entrada de catálogo.
+
+<a id="codex-auth-and-account-pools"></a>
+
+## Autenticación de Codex y grupos de cuentas
+
+La página **Codex Auth** administra la ruta nativa de ChatGPT/Codex:
+
+El modo Pool selecciona en las cuentas Codex principales y agregadas; Direct utiliza solo el inicio de sesión de la persona que llama/principal. Las solicitudes en vuelo mantienen sus credenciales capturadas y una reautenticación 401/403 o un tiempo de reutilización 429 puede borrar la afinidad y rotar a otra cuenta Pool elegible. Esto es separado de `openai-apikey`
+y otros proveedores.
+
+:::caution[Responsabilidad sobre las políticas del proveedor]
+El grupo de cuentas es una función técnica de administración de cuentas, enrutamiento y resiliencia. Esto no afirma que tener varias cuentas esté prohibido: el cumplimiento depende de la configuración de cada cuenta y del patrón de uso. OpenCodex no respalda el uso de cuentas adicionales para eludir límites de solicitudes, cuotas, límites del plan u otras restricciones del proveedor, ni compartir credenciales entre personas. Usted es responsable de cumplir los términos vigentes del proveedor para cada cuenta y forma de uso. Las restricciones, suspensiones o cancelaciones de cuentas quedan fuera del control de OpenCodex. Los mantenedores no ofrecen asesoramiento sobre políticas ni pueden resolver las medidas que aplique el proveedor. Consulte los
+[Términos de uso de OpenAI](https://openai.com/policies/terms-of-use/).
+:::
+
+- La elección manual se aplica en la siguiente solicitud, incluso de un hilo ya vinculado; las solicitudes en curso conservan las credenciales que capturaron. Además, la cuenta queda fijada con una insignia **FIJADA**: ninguna prioridad superior la sustituye hasta que se agote, elijas otra o cambies el orden de selección de alguna cuenta. Pulsar de nuevo la insignia pide confirmar que se libere esa fijación. Al confirmar, los hilos vinculados conservan su cuenta y las solicitudes nuevas o no vinculadas vuelven al orden y los umbrales. Una confirmación antigua no puede liberar una fijación más reciente. Si la operación se rechaza o su resultado es incierto, revisa la vista actualizada antes de volver a confirmar.
+- Cada cuenta tiene un control **Orden de selección**: primero, antes, normal, después y último. Solo se recurre a un orden inferior cuando todas las cuentas superiores están agotadas o no disponibles. El cambio afecta a la siguiente solicitud no vinculada, sin mover hilos que ya tengan cuenta. La cuenta principal de Codex participa en el mismo orden y puede reservarse como **Última**. Una prioridad personalizada de `ocx account priority` sigue siendo visible y seleccionable aunque no coincida con esos cinco valores.
+- La afinidad evita cambiar de cuenta en cada solicitud. Con `pool.cacheAffinity` activado por defecto, un hilo mantiene su cuenta aunque cruce el umbral de uso, hasta que se agote o no pueda atenderlo. Solo se mueve a otra con margen de cuota real y uso estrictamente menor. `false` permite volver a evaluar el cambio al cruzar el umbral, pero mantiene esos requisitos del destino.
+- Las sesiones nuevas pueden elegir la cuenta elegible de menor uso. Los planes pagados puntúan las 5h más calientes conocidas, semanal, o 30d ventana; Los planes Go/Free solo usan la ventana 30d.
+- Si WHAM proporciona `limit_window_seconds`, Codex Auth clasifica como 30d una ventana principal de al menos 28 días, en lugar de suponer que es semanal. Si la respuesta no indica la duración, conserva la interpretación semanal anterior.
+- **Actualizar las cuotas** vuelve a leer el uso de la cuenta inmediatamente, por lo que el enrutamiento y las tarjetas de cuenta usan lo mismo valores.
+- Los registros de solicitudes Pool usan etiquetas opacas, como `p3fa91c`, nunca correos electrónicos de cuenta.
+- Cada cuenta también muestra su etiqueta de registro estable, el total de tokens observado en 30 días, una estimación de coste equivalente de API y la proporción de intentos con uso medido. Los precios personalizados de `modelCosts` tienen prioridad sobre el catálogo verificado y los precios de respaldo; el uso histórico se vuelve a valorar con los precios activos al consultarlo. Es una estimación para conciliación, no una factura de ChatGPT Plus o Pro. Los registros históricos de `openai` anteriores a la atribución explícita siguen siendo ambiguos y no se asignan a la cuenta principal actual.
+- **Apuntar a una cuenta específica de Codex desde el selector de modelos** Es una opción explícita. Cuando está habilitado, Las filas del selector GPT ordinarias se reemplazan por una entrada por selector de cuenta pública. La elección de uno bloquea esa conversación a la cuenta asignada: no rota, retrocede o cambiar la cuenta Pool activa. El inicio de sesión de la aplicación Codex incorporado tiene su propio selector; mapas generados normalmente utilizan `main`con un sufijo de colisión segura como `main-2` cuando sea necesario. Cuentas añadidas reciba etiquetas estables y seguras para la privacidad, y se conservan las etiquetas selectoras personalizadas existentes. Las conversaciones existentes y las selecciones de modelo guardadas continúan el enrutamiento. Desactivar la configuración Oculta las entradas generadas del selector sin eliminar cuentas, selectores ni rutas exactas. Llanura GPT Los ID de modelo continúan usando el comportamiento configurado Pool o Direct.
+- Los cambios de agregar, quitar y seleccionar cuentas se guardan antes de actualizar el catálogo de modelos. Si esa actualización limitada no puede terminar, el panel de control muestra un aviso ámbar de éxito con recuperación; ejecutar `ocx sync` para reintentar. El cambio de cuenta o configuración en sí permanece guardado.
+
+La descripción general de los proveedores resume por separado el uso del modo Pool como una capacidad ponderada solo para pantalla estimación, junto con la cuota bruta de la cuenta efectiva y la próxima recuperación de capacidad. Véase
+[Capacidad del grupo](/es/guides/providers/#providers-overview-pool-capacity) por el campos visibles, significado de cobertura incompleta y límite de enrutamiento.
+
+<a id="starring-is-yours-to-decide-not-an-agents"></a>
+
+## Tú decides si dar una estrella
+
+El botón de la barra lateral y la pregunta que `ocx start` muestra en una terminal interactiva usan **tu propia sesión de `gh`**. opencodex no guarda un token de GitHub para esta acción; solo registra tu respuesta.
+
+Como esta acción modifica tu cuenta de GitHub, se rechazan las llamadas dirigidas por agentes en lugar de permitir que respondan por ti:
+
+- `ocx start` y `ocx service install` omiten la pregunta interactiva cuando detectan un agente o entorno automático (`CLAUDECODE`, `CODEX_THREAD_ID`, `CURSOR_TRACE_ID`, `CI`, entre otros). El agente debe trasladar la pregunta una sola vez con una opción clara Sí/No. El silencio queda pendiente: no se registra como Sí ni como No y el agente no debe repetirla en respuestas o sesiones posteriores. Una versión posterior puede volver a activar el aviso de la CLI según los plazos de `AGENTS_INSTALL.md`.
+- `POST /api/github/star` devuelve `403` con `code: "agent_consent_required"` cuando el proxy detecta una sesión de agente y la solicitud no acredita una sesión del navegador del panel. Tener el token de administración no constituye consentimiento: un agente local puede leer ese archivo.
+- El botón del panel sigue disponible. Un clic real aporta la evidencia de sesión del mismo origen, incluso si el agente inició el proxy.
+- Una respuesta negativa termina el asunto; no se insiste ni se añaden indicaciones a los mensajes del modelo para retomarlo después.
+
+<a id="how-the-dashboard-talks-to-the-proxy"></a>
+
+## Cómo el panel de control habla con el proxy
+
+La GUI es un cliente ligero de la API JSON de administración del proxy. Algunos endpoints útiles son:
+
+| Punto de conexión | Finalidad |
+| --- | --- |
+| `GET` / `PUT /api/settings` | Lee los ajustes o actualiza el inicio automático Codex, los ajustes de flujo/memoria y la visibilidad del selector de segmentación de cuentas. |
+| `GET` / `POST /api/github/star` | Lea el `gh`-derivada del estado de estrella, o la estrella del repositorio. El POST es rechazado con `403` `agent_consent_required` para llamadas dirigidas por agentes sin una sesión de panel. |
+| `GET /api/startup-health` | Lea los diagnósticos de enrutamiento, servicio, shim y seguridad de reinicio sin secretos. |
+| `POST /api/startup-action` | Instale el servicio en segundo plano o la shim de lanzador Codex a través de acciones fijas y permitidas. |
+| `GET` / `POST /api/windows-tray` | Lea o cambie la instalación de la bandeja Windows y el estado del proceso visible. POST acepta `install`, `start`, `stop`, o `uninstall`. |
+| `POST /api/sync` | Reconstruye el catálogo compartido y marca la caché de modelos de Codex como obsoleta. |
+| `GET /api/update/check` · `POST /api/update/run` · `GET /api/update/status` | Revisar, ejecutar y supervisar los trabajos de autoactualización. Los PID de los trabajadores persisten para que un trabajo bloqueado se recupere automáticamente; los trabajos heredados sin PID se recuperan después de diez minutos. |
+| `GET` / `PUT /api/sidecar-settings` | Leer o establecer la configuración del modelo de búsqueda/visión sidecar. |
+| `GET` / `PUT /api/injection-model` | Leer o establecer la selección compartida de modelo/esfuerzo de subagente y los conmutadores de orientación/nativo-predeterminado independientes. |
+| `GET` / `PUT /api/v2` | Lea o establezca el modo de superficie, el indicador de características Codex y el límite de hilos v2. |
+| `GET /api/providers` · `POST /api/providers` · `PATCH /api/providers?name=...` · `DELETE /api/providers?name=...` | Listar, agregar/reemplazar, habilitar/deshabilitar, establecer el valor predeterminado o eliminar proveedores. `PATCH` utiliza independiente `{ "setDefault": true }` en un proveedor habilitado; `POST` puede incluir `setDefault` al crear/reemplazar (también solo habilitado). Eliminación de la actual por defecto reasigna al primer proveedor habilitado restante cuando existe uno; de lo contrario, el API devuelve `409` con `code: "last_provider"` y mantiene el valor predeterminado actual. |
+| `GET /api/models` · `PUT /api/disabled-models` | Enumera filas de modelos nativos/enrutados y actualiza el conjunto de modelos deshabilitados compartidos. |
+| `GET /api/selected-models` · `PUT /api/model-visibility` | Lea las listas de proveedores y cambie atómicamente la visibilidad final de un modelo o grupo de proveedores. |
+| `GET /api/key-providers` · `GET /api/oauth/providers` | Lea los catálogos de proveedores API y OAuth. |
+| `GET /api/oauth/accounts?provider=...&quota=1` · `GET /api/providers/keys?name=...&quota=1` | Lea cada cuenta o cuota de clave donde sea compatible, sin cambiar la credencial activa. Añadir `refresh=1` para omitir la caché de cuota establecida; se puede compartir una lectura de la misma credencial en vuelo. Omita `quota=1` para una lista local barata con cada fila de `quotaMode`: `probe`, `passive`, o `unsupported`. Las lecturas pasivas devuelven las observaciones existentes sin una sonda de red. Ninguna lectura es lo mismo que el 0% utilizado, y las cuotas para múltiples claves no se suman. |
+| `POST /api/oauth/login` · `GET /api/oauth/status` | Inicie un flujo de proveedores OAuth y realice una encuesta para su finalización. |
+| `GET /api/codex-auth/accounts?refresh=1` | Listar cuentas principales y de grupo, forzar la actualización de cuotas e informar la cuenta principal `hasCredential` / terminal `needsReauth` Estado. |
+| `PUT /api/codex-auth/active` · `PUT /api/codex-auth/auto-switch` · `PUT /api/codex-auth/failover` | Seleccione la cuenta para la siguiente solicitud y configure el enrutamiento del grupo. |
+| `GET /api/codex-auth/active` · `PUT /api/codex-auth/accounts/priority` | Lea la cuenta efectiva (incluyendo `pinned` ¿Cuál es la cuenta `pinnedAccountId`y establecer el orden de selección de una cuenta. |
+| `POST /api/codex-auth/login` · `GET /api/codex-auth/login-status` | Agregar una cuenta de grupo a través del inicio de sesión del navegador. |
+| `GET /api/logs?tail=50&limit=20&offset=0&provider=...&status=5xx` | Lea los metadatos de las solicitudes recientes con filtros opcionales de cola, proveedor y estado exacto/clase. Con `limit`/`offset`, paging camina hacia atrás desde la fila más reciente (`offset=0` devuelve la última página). Forma de respuesta: `{ timeZone, generatedAt, total, logs }` donde `total` es el recuento de filas filtradas antes de la paginación. |
+| `GET` / `PUT /api/subagent-models` | Leer o establecer los cinco destacados `spawn_agent` Anule los modelos. |
+| `POST /api/stop` | Detenga el proxy/servicio, restaure el Codex nativo y salga. Rechazado con `respawnable_service` en el Backend del Programador de Tareas Windows, con `self_unload_service` cuando este proxy es en sí mismo el trabajo instalado de lanzamiento / sistema, y con `service_state_unknown` cuando no se puede leer el estado del Programador de tareas; nada cambia en ninguno de esos casos. Una sesión de dashboard también es rechazada, con `desktop_supervised`Mientras que la aplicación de escritorio OpenCodex ejecuta el proxy. |
+
+La parada vuelve a comprobar quién controla la conexión antes de restaurar la configuración. Una conexión nueva al hub conserva su enrutamiento, catálogo y configuración de Grok. Si el control aún está cambiando o no se puede confirmar, la API devuelve HTTP 409 con `sharedTeardown: "refused"` y sigue atendiendo solicitudes; deja que termine la operación de conexión y reintenta. Consulta el [flujo de parada de Remote Link](/es/guides/remote-link/).
+
+:::tip
+Adición **Ollama Nube** u otro proveedor de catálogo desde el panel copia su texto contra visión En el caso de que la configuración del proveedor sea guardada, [visión sidecar](/es/guides/sidecars/)
+se cierra correctamente sin clasificación manual.
+:::
+
+<a id="pairing-this-browser-with-a-hub"></a>
+
+### Emparejar este navegador con un hub
+
+La inscripción de la máquina y la autenticación del navegador son independientes. El panel de emparejamiento nombra el concentrador y muestra un `ocx gui pair --origin` comando para el origen exacto actualmente abierto en su navegador. Ejecute ese comando en el concentrador o envíelo al operador del concentrador y solicite un código de emparejamiento único. Pegue ese código en el panel; una clave API de datos o admin token no es un código de emparejamiento.
+
+Mientras la autenticación del navegador está pendiente, el panel de control no recomienda reiniciar un cliente conectado saludable. Completar el emparejamiento actualiza los datos del panel de control inmediatamente, incluido un error de autenticación previamente almacenado en caché. La expiración de la sesión vuelve al emparejamiento; la denegación de permiso mantiene su propia guía de configuración de acceso. Otras actualizaciones fallidas pueden mostrar los últimos datos recibidos con un aviso de datos obsoletos y una acción de reintento.
+
+<a id="usage-chart-keyboard-and-touch-controls"></a>
+
+### Teclado de la tabla de uso y controles táctiles
+
+Los días del mapa de calor de uso tienen un punto de entrada de pestaña. Usa Arriba/Abajo para días adyacentes e Izquierda/Derecha para semanas adyacentes. Las barras semanales exponen los detalles del mismo día en el enfoque del teclado, el puntero o el tacto. Las etiquetas de día incluyen la fecha, el recuento de solicitudes y el recuento de token; las superposiciones de información sobre herramientas permanecen dentro de la ventana.
+
+### Claude
+
+**Claude** es una pestaña dentro **Conectar**, cuya tira de pestañas coloca Codex, Claude, Claude Desktop y Grok Build en ese orden. Claude no tiene subpestañas: muestra la configuración de Claude Code directamente. La página comienza con **Claude Code CLI de primera mano**, seguido de **Empezar**, **General**
+(compatibilidad, instrucciones del agente y controles de contexto), **Modelo de ayudante de fondo**,
+**Interceptación modelo**, **Modelos disponibles**, y finalmente **Conexión Claude**. Una pegajosa barra de Guardar muestra **Sin cambios** o **Cambios no guardados**, con **Reversión** para descartar ediciones y **Guardar** Comprometer A ellos. Ambos interruptores se aplican inmediatamente; **Guardar** Nunca los cambia. Cuando se detiene la interceptación, la página muestra por qué y ofrece **Iniciar interceptación**, que lo inicia en su lugar sin reiniciar OpenCodex. Las subpestañas de Código, Configuración y Cuenta anteriores han desaparecido; todo lo que mostraba la vista Configuración de solo lectura, excepto el número de puerto de intercepción, está en esta página.
+
+**Claude Desktop** tiene su propia pestaña en Conectar, `#claude/desktop`. Incluye el selector de modo, una lista por modelo que determina qué muestra Claude Desktop (consulta [Elegir los modelos que muestra Claude Desktop](/es/guides/claude-code/#choose-which-models-claude-desktop-lists)) y las familias de modelos en **Avanzado**. Una fila indica si Desktop ejecuta el perfil; una insignia aparte muestra si los cambios del dashboard están guardados, junto a **Guardar** y **Guardar y aplicar**.
+
+Las cuentas Claude/Anthropic se administran solo en **Proveedores > Anthropic > Cuentas**: inicio de sesión y la opción del navegador, la lista de cuentas con interruptor, pausa, eliminar y volver a autenticar, el campo de código de pegado, la configuración del grupo de cuentas y la cuota. Claude ya no tiene una subpestaña Cuenta. Controles a nivel de proveedor, como el proveedor predeterminado, la eliminación y la opción habilitada permanecer en proveedores.
+
+Los marcadores `#claude` y `#claude/code` abrir esta página, y la anterior `#claude/settings` redirecciona a `#claude/code`; `#claude/desktop` selecciona la token Escritorio Claude separada. El viejo `#claude/account` Marcador redirige a `#providers?provider=anthropic&tab=accounts`. Legado `#integrations/claude` y `#integrations/claude/desktop` Los marcadores todavía redirigen a `#claude/code` y `#claude/desktop`, respectivamente. Las teclas de flecha se mueven entre pestañas; Home y End seleccione la primera y última pestaña.
+
+
+<a id="test-one-provider-model"></a>
+
+## Probar un modelo de proveedor
+
+En **Proveedores**, **Probar conexión** comprueba la conectividad para descubrir modelos. El control independiente **Probar generación** comprueba si el modelo seleccionado responde. Elige un modelo y confirma que aceptas que la solicitud pueda generar cargos del proveedor. Cancelar la confirmación no envía nada. Cambiar de proveedor o modelo, o salir de la página, cancela la prueba y descarta cualquier resultado que ya no corresponda a la selección actual.
+
+La prueba envía `Reply exactly OK.` una sola vez, con un máximo de 32 tokens de salida, un plazo de 20 segundos y un límite de 64 KiB para el flujo. Informa del tiempo hasta el primer delta de texto no vacío (TTFT), la latencia total y el modelo declarado por el proveedor. Lo compara con el identificador del modelo enviado y muestra coincidencia, diferencia o resultado desconocido. Si faltan metadatos o se contradicen, el resultado es desconocido; los metadatos del proveedor no verifican la identidad del modelo. El panel explica por qué una combinación de autenticación, adaptador o transporte no admite la prueba. No muestra el texto generado ni modifica el estado de enrutamiento, el historial de solicitudes o el catálogo del proveedor.
+
+El endpoint de administración autenticado es `POST /api/providers/test-completion?name=<provider>`, con exactamente `{"model":"<model>","confirm":true}`. Las sesiones del dashboard necesitan su token CSRF habitual. Una entrada inválida devuelve 400; un proveedor desconocido, 404; y otra prueba en curso para el mismo proveedor, 409. Los diagnósticos completados y los resultados de aplicabilidad devuelven 200, incluido un error estructurado si falla la inferencia. Se aplican la política de destinos y la configuración de salida del proveedor. Las redirecciones, los reintentos y el fallback están desactivados. Para usar la CLI, consulta [Proveedores y cuentas](/es/reference/cli/providers-accounts/).
+
+**Probar todos los modelos** ejecuta la misma prueba de generación para cada modelo configurado, listado y predeterminado del proveedor, una solicitud a la vez. Primero pide una confirmación que indica el máximo de solicitudes; algunos modelos pueden omitirse antes del envío. Este control y **Probar modelo** comparten un único bloqueo por proveedor: ambos permanecen deshabilitados mientras el otro confirma o ejecuta la prueba. **Detener** cancela la solicitud en curso y no envía más.
+
+Cada modelo figura como correcto, fallido o no probado. Fallido significa que el proveedor respondió con un error o agotó el tiempo de espera. No probado incluye rechazos de la API de administración, como otra prueba simultánea; rechazos de admisión anteriores al envío, como credenciales ausentes o cambiadas o un destino rechazado; y rechazos HTTP 401/403/429 del proveedor por autenticación, acceso o cuota, devueltos en un resultado estructurado con HTTP 200. Estos casos no se convierten en candidatos para deshabilitar. Un adaptador efectivo no compatible marca solo ese modelo como no probado y continúa, porque un proveedor puede usar protocolos distintos para modelos distintos. Un rechazo que afecte al proveedor completo, como autenticación OAuth o ajustes de transporte no admitidos, detiene el lote.
+
+Si algún modelo falla, **Deshabilitar modelos fallidos** pide una segunda confirmación. Solo entonces oculta esos modelos del catálogo y del selector mediante el mismo ajuste de visibilidad de **Modelos**, desde donde pueden volver a habilitarse. Como los demás modelos ocultos, siguen aceptando llamadas por identificador exacto. Nunca se deshabilitan sin esa confirmación. Salir de la página o cambiar la conexión del proveedor retira el consentimiento pendiente y cancela su solicitud. Un lote nuevo espera a que se resuelva ese consentimiento o la escritura de visibilidad, para que una respuesta antigua no oculte la acción del lote más reciente.
+
+
+<a id="usage-by-app"></a>
+
+### Uso por aplicación
+
+Uso abre con **Todas las aplicaciones**, **Todos los dispositivos** y **30d**, dentro del ámbito de acceso. Los cambios duran mientras se mantiene abierta la página; al reabrir vuelve a esos valores. Con todas las aplicaciones, **Aplicaciones**, después de Modelos y Proveedores, muestra porcentaje y total de tokens, coste estimado a precio de lista, solicitudes y solicitudes medidas. CLI, Desktop e IDE de Codex se agrupan en Codex. El histórico sin atribución es **Sin clasificar**, distinto de **Desconocido** y **Otro**. Elegir una aplicación oculta el desglose; no disponible no equivale a lista vacía.
+
+Los registros reúnen todas las aplicaciones con un icono accesible por solicitud, no pestañas ni filtro de aplicación. No tener atribución no implica Codex ni fallo. Los filtros combinan intercepción, proveedor, modelo exacto, estado, tiempo e identidad; un `metadata.user_id` de Claude remoto omite `tk` para encontrar toda la sesión. Si el proveedor declara `INVALID_ARGUMENT` o `MALFORMED_FUNCTION_CALL`, el detalle muestra ese identificador sin guardar su mensaje original.
+
+Termina un inicio de sesión o borrado OAuth antes de empezar el otro. Si no puede actualizarse su estado queda sin verificar y **Cerrar sesión** permite reintentar explícitamente. Tras borrar, se comprueba el login; si no se verifica, actualiza la lista antes de repetir. Las cuotas omiten OAuth pausado y claves desactivadas sin convertir sus filas no observadas en fallos. Un proveedor sin seleccionar ofrece **Actualizar todas las cuotas**; las filas fallidas conservan su última lectura y antigüedad, sin prometer frescura global.
+
+Los borradores de Ajustes y JSON se conservan en memoria por servidor: cambiarlo aparca el borrador; guardar escribe donde comenzó. Si cambió la configuración guardada, elige conservar tu borrador o cargarla. JSON combina solo tus cambios y señala conflictos; Ajustes solo escribe campos modificados. Un relay antiguo comprueba destino antes de enviar sin garantía atómica y avisa; actualiza el proxy. Cerrar o recargar pierde los borradores.
+
+- Créditos prepagados con 90% usado prevalecen en el titular si la ventana habitual no es crítica; si también lo es, se conserva esa ventana.
diff --git a/docs-site/src/content/docs/es/index.mdx b/docs-site/src/content/docs/es/index.mdx
new file mode 100644
index 00000000000..c041b6fcd55
--- /dev/null
+++ b/docs-site/src/content/docs/es/index.mdx
@@ -0,0 +1,19 @@
+---
+title: "opencodex — Una pasarela local para Codex, Claude Code y más"
+description: "Una única pasarela local para tus herramientas de programación con IA y tus modelos: usa los proveedores que elijas con Codex, Claude Code, Claude Desktop y Grok Build, y conecta más herramientas mediante configuraciones administradas."
+template: splash
+head:
+  # Brand-first, no " | opencodex" suffix: Google matches the site name against
+  # the home page title, so the wordmark leads and is not duplicated.
+  - tag: title
+    content: "opencodex — Una pasarela local para Codex, Claude Code y más"
+  - tag: meta
+    attrs:
+      property: og:locale
+      content: es_ES
+tableOfContents: false
+---
+
+import Landing from '../../../components/Landing.astro';
+
+<Landing locale="es" />
diff --git a/docs-site/src/content/docs/es/reference/adapters.md b/docs-site/src/content/docs/es/reference/adapters.md
new file mode 100644
index 00000000000..60868fad9a3
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/adapters.md
@@ -0,0 +1,363 @@
+---
+title: "Adaptadores"
+description: "Adaptadores de proveedores: destinos, construcción de solicitudes y particularidades de cada uno."
+---
+
+Un **adaptador** traduce entre el modelo interno de solicitudes y respuestas de opencodex y el formato de comunicación de un proveedor. Todos implementan `ProviderAdapter`. El siguiente extracto está abreviado; la interfaz completa y vigente está en `src/adapters/base.ts`:
+
+```ts
+interface ProviderAdapter {
+  name: string;
+  buildRequest(parsed: OcxParsedRequest, incoming: IncomingMeta): AdapterRequest | Promise<AdapterRequest>;
+  fetchResponse?(request: AdapterRequest, ctx?: AdapterFetchContext): Promise<Response>;
+  parseStream(response: Response, budget: TranslatorBudget): AsyncGenerator<AdapterEvent>;
+  parseResponse?(response: Response, budget: TranslatorBudget): Promise<AdapterEvent[]>;
+  runTurn?(parsed: OcxParsedRequest, incoming: IncomingMeta, emit: (event: AdapterEvent) => void): Promise<void>;
+}
+```
+
+`buildRequest` transforma un `OcxParsedRequest` en una solicitud HTTP al proveedor; `parseStream` y `parseResponse` convierten su respuesta en eventos internos `AdapterEvent`. `fetchResponse` permite que el adaptador gestione sus propios reintentos y tiempos de espera. `runTurn` admite transportes que no se pueden representar mediante una sola solicitud HTTP seguida de un flujo de respuesta. Después, [`bridge.ts`](/es/reference/architecture/#the-bridge) convierte esos eventos al formato SSE de Responses.
+
+<a id="shared-tool-argument-repair"></a>
+
+## Reparación compartida de argumentos de herramientas
+
+El puente repara números de coma flotante integrales en campos enteros y enteros seguros en campos que solo admiten cadenas, según el esquema de la herramienta. Los enteros no seguros, los números desbordados y los decimales no integrales sin reparar conservan sus tokens exactos mientras se reparan los valores vecinos seguros. Los arrays anidados y las claves duplicadas conservan cada token no seguro, de modo que reparar un plazo no cambia silenciosamente un identificador ajeno.
+
+<a id="external-task-input-on-translated-responses-routes"></a>
+
+## Entrada de tarea externa en rutas Responses traducidas
+
+La coordinación de tareas de Codex puede proporcionar la entrada como un `function_call_output` con campos `id`, `name` y `namespace` no vacíos y sin la propiedad `call_id`. OpenCodex convierte ese sobre completo en un mensaje de usuario antes de traducirlo para el adaptador. La salida debe ser texto que no esté en blanco, o un array formado exclusivamente por partes compatibles de texto y de URL `input_image`. Se conservan el texto y el orden de las imágenes; el nivel de detalle `original` de las imágenes se convierte en `high`.
+
+El contenido vacío, las partes mal formadas u opacas, las imágenes identificadas únicamente por un archivo y los sobres parciales siguen siendo inválidos. Los resultados ordinarios de herramientas de función o personalizadas siguen requiriendo un `call_id` no vacío. Los metadatos del sobre identifican un formato de compatibilidad y no conceden permisos adicionales. El passthrough nativo y la compactación enrutada portátil aplican la misma conversión a turnos de usuario en sus cuerpos sin procesar; el reenvío nativo directo a `/responses/compact` conserva sus reglas actuales para esos cuerpos.
+
+<a id="checkpoint-continuation-after-routed-compaction"></a>
+
+## Continuación del punto de control después de la compactación enrutada
+
+Un modelo enrutado reproduce un punto de control OpenCodex `ocx1:` como texto de usuario junto con las solicitudes anteriores conservadas. Cuando una solicitud contiene uno de esos puntos de control decodificados, OpenCodex añade una nota breve a las instrucciones del sistema en las rutas traducidas, o a `instructions` en el passthrough de Responses. La nota presenta las solicitudes completadas como historial y solo permite continuar el trabajo pendiente ya autorizado que siga dentro de ese alcance, sin volver a pedir la misma autorización mientras sea válida. Los permisos y las confirmaciones existentes siguen vigentes: las decisiones o autorizaciones pendientes deben resolverse antes de realizar acciones que dependan de ellas. Los puntos de control y las delegaciones, incluidos los de otro hilo, no amplían la autoridad ni el alcance. Los mensajes posteriores del usuario tienen prioridad, incluso si pausan, cancelan, sustituyen o cambian el alcance del trabajo. Las solicitudes de compactación, los blobs nativos opacos y las solicitudes sin punto de control no reciben esa nota.
+
+## `openai-chat`
+
+**Objetivos:** OpenAI **Chat Completions** (`POST {baseUrl}/chat/completions`; un `/chat/completions` o `/` en `baseUrl` se elimina primero) y todos los proveedores compatibles - xAI, Kimi, DeepSeek, GLM, Groq, OpenRouter, Ollama (local), y más. **Auth:** `key` (Portador).
+
+Para xAI, el adaptador de flujo ascendente resuelto puede ser `openai-chat` o `openai-responses`, dependiendo de los valores predeterminados del modelo y las anulaciones explícitas de `modelAdapters`. Ambos soportan autenticación de clave pública xAI API y Grok CLI OAuth. El registro de uso [`attempts[].credentialSource`](/es/reference/management-api/) sigue ese transporte resuelto; no infiere atribución de suscripción del protocolo entrante.
+
+- Convierte los mensajes internos a los roles de OpenAI y las herramientas a `{type:"function", function:{…}}`, junto con `tool_choice` (`auto` / `none` / `required` o una función con nombre).
+- Las **imágenes de los resultados de herramientas** se envían en partes `image_url` de un mensaje de usuario con visión, después de cerrar la ronda de herramientas, porque el contenido de `role:"tool"` solo admite texto. El marcador `[image]` permanece como referencia en el mensaje de la herramienta.
+- **Reescribe el mensaje de identidad GPT-5 de Codex** con una introducción independiente del modelo para que los modelos enrutados no afirmen ser de OpenAI.
+- Para las solicitudes `Qwen3.8-27B` traducidas (incluyendo identificadores separados por nombres de pasarela como `openai/Qwen3.8-27B`), las solicitudes Flash-Next (`flash-next` o `Qwen3.8-Flash-Next`, también con espacios de nombres de pasarela) y las solicitudes `OrcaSAQ-2-Cyber-27B` GGUF, un recordatorio de desarrollador de solo texto después del mensaje de sistema principal permanece en su ranura de conversación, pero se envía como `user`. La excepción Orca requiere `GGUF` en el segmento de modelo final antes de cualquier etiqueta de cuantificación de colon opcional; las variantes de Orca que no son GGUF mantienen su comportamiento de rol de desarrollador configurado. Estas plantillas de chat ancladas, por ejemplo [Qwen3.8-27B](https://huggingface.co/Qwen/Qwen3.8-27B/blob/1d4bf0f2ff6012fd82039f2fa52739d0dd7c60c0/chat_template.jinja), rechazan mensajes posteriores de `system` y no aceptan `developer`, mientras que los mensajes posteriores de `user` son válidos. Esto preserva el orden pero no puede preservar la precedencia del rol de desarrollador. Otros modelos mantienen su comportamiento configurado de rol de desarrollador; el passthrough de Chat nativo no cambia.
+- **Limita `reasoning_effort`** al subconjunto anunciado del modelo cuando un nivel exacto no está disponible; `xhigh` y `max` siguen siendo etiquetas distintas a menos que un proveedor configure explícitamente un alias. El adaptador **lo omite por completo** para ids en `provider.noReasoningModels`.
+- Transmite `delta.content` (texto), `delta.reasoning_content` (pensamiento) y `delta.tool_calls[]`, y recopila `usage`. Los proveedores de `reasoningDetailsModels` (serie M de MiniMax) leen en cambio segmentos estructurados de `delta.reasoning_details`: su `text` llega como instantáneas acumulativas, de las que se extrae la diferencia respecto al prefijo anterior. El razonamiento conservado se reproduce como un array `reasoning_details`.
+- Para `api.mistral.ai`, ambas rutas de respuesta aceptan también arrays de bloques tipados `text` y `thinking`. Los bloques de texto conservan sus bytes y su orden; el pensamiento se mantiene separado de la respuesta. Los bloques de texto adyacentes comparten el analizador de etiquetas en línea, que se reinicia al recibir un bloque tipado de pensamiento. Un bloque no admitido o mal formado produce un error del proveedor. Los demás hosts conservan su comportamiento. Esto no añade reproducción de firmas de Mistral.
+- Suprime texto desnudo `<tool_call>` cuando duplica una llamada estructurada, y colapsa dos bloques idénticos inmediatamente adyacentes cuando exactamente una llamada estructurada está de acuerdo con su función y entrada. Un doble `input` se reduce a una copia, unida directamente o por una nueva línea, y sólo cuando el objeto argumentos no tiene ninguna clave aparte de `input`. El espacio en blanco posterior después de que se suprime el par; el marcado no coincidente o de ejemplo permanece visible.
+- ClinePass utiliza el formato de puerta de enlace verificado en vivo `reasoning: { enabled: true, effort }` (o `{ enabled: false }` cuando el razonamiento está deshabilitado); sus API documentos públicos no especifican actualmente esta forma de solicitud. El adaptador conserva los niveles solicitados `low`, `medium`, `high`, `xhigh` y `max`, acepta deltas de razonamiento de `delta.reasoning_content` o `delta.reasoning`, solicita el uso de flujo con `stream_options.include_usage` y lee el uso de envolventes de respuesta no de flujo.
+
+Las llamadas a herramientas de streaming conservan su identidad cuando un proveedor envía por primera vez un ID, luego asocia ese ID con un índice y luego envía fragmentos de argumentos de solo índice. Esos fragmentos se reúnen en una llamada con el nombre original y argumentos completos; las llamadas paralelas retienen identidades separadas. Cuando está presente, los índices de llamada a herramientas transmitidos deben ser enteros seguros no negativos. Los valores no numéricos y los números negativos, fraccionarios o inseguros terminan el flujo con un error ascendente antes de la coincidencia de identidad. Los índices ausentes y nulos permanecen como marcadores de posición del índice ausente; las cadenas numéricas no son forzadas.
+
+## `ollama-native`
+
+**Objetivos:** la propia **Chat API** de Ollama ( `POST /api/chat` ) en lugar de su superficie compatible con OpenAI. El proveedor incorporado `ollama-cloud` se selecciona en este adaptador; también se puede configurar en un proveedor Ollama personalizado o autoalojado por separado con `adapter: "ollama-native"`. **Auth:** `key` (Bearer) para endpoints personalizados/en la nube; no se envía ninguna credencial a loopback o `authMode: "local"` objetivos.
+
+- **La selección definida en el registro determina el adaptador.** La fila incorporada `ollama-cloud` mantiene la URL base `https://ollama.com/v1` para el descubrimiento en vivo `/v1/models`, mientras que la inferencia se normaliza en `POST https://ollama.com/api/chat`. Un nivel de configuración `adapter` se descarta para esa fila de proveedor. El Ollama local incorporado ordinario permanece en `openai-chat`; elegir `ollama-native` para un punto final local o autoalojado es una decisión explícita de configuración del proveedor, detectada por el host para que un destino que no sea Ollama nunca se reescriba en silencio.
+- **Metadatos del modelo:** `/v1/models` no lleva metadatos por modelo, por lo que para el canónico Ollama Cloud el proveedor del adaptador enriquece cada id descubierto a través de un *delimitado* `POST /api/show` (256 KiB por respuesta, 8 s por solicitud, concurrencia 4, 48 solicitudes, un plazo de 12 s para toda la fase) para llenar la ventana de contexto real y la capacidad de visión. La solicitud de demostración es del mismo origen y nunca sigue una redirección; los fallos degradan ese modelo y nunca fallan el descubrimiento.
+- **Transmisión:** el NDJSON nativo de Ollama. El texto y los deltas `message.thinking` se reenvían a medida que llegan; un giro se completa solo en un registro de terminal `done: true`, y el `done: false` almacenado en memoria intermedia o un terminal faltante suprime completamente las llamadas parciales de texto y herramientas.
+- **Razonamiento:** se asigna al campo nativo `think` de Ollama (`low` / `medium` / `high` / `max`, más booleanos), sujetado a la escala anunciada del modelo, y honra la semántica centinela `__omit__` configura aguas arriba.
+- **Imágenes:** se envía de forma nativa en la matriz de mensajes `images` donde el modelo tiene capacidad de visión; se rechaza el video en lugar de enviarlo incorrectamente, y no se obtienen URL de imágenes remotas.
+- **Herramientas:** se declaran con el formato nativo de Ollama. Las llamadas recibidas en streaming son registros completos, con un objeto `arguments`. Los resultados se asocian estrictamente por identificador de llamada y nombre de herramienta. Los identificadores nativos válidos distinguen llamadas aunque el proveedor repita un índice de función; un identificador repetido actualiza los argumentos de esa misma llamada. Si falta el identificador, se usa el índice y, en su defecto, la posición. Se conserva el orden de la primera aparición. Con `parallel_tool_calls: false`, una segunda llamada distinta del proveedor rechaza el turno antes de emitir cualquier llamada a herramienta.
+  Codex puede registrar comentarios del asistente antes de los resultados de una llamada pendiente. El texto o razonamiento sin llamadas nuevas se aplaza hasta completar el lote, para mantener cada resultado junto a su llamada original. Un lote nuevo cierra el anterior; los resultados que falten conservan un marcador explícito de estado desconocido. Las salidas adicionales de una llamada abierta se añaden en orden de llegada. Si llegan después de cerrar su lote, se conservan como texto de conversación con atribución explícita, después de cualquier par pendiente de llamada y resultado. Los identificadores desconocidos y las identidades de herramienta que no coincidan siguen siendo inválidos: este mecanismo no crea ni ejecuta otra llamada.
+  La atribución generada para salidas tardías comparte un máximo de 256 KiB de bytes JSON por solicitud. Superarlo produce HTTP 413 `request_too_large`, sin truncar identificadores ni resultados. El error indica la causa y el límite. Para continuar, inicia un hilo nuevo: compactar mediante la misma ruta de Ollama reenvía el mismo historial y vuelve a rechazarse, salvo que la compactación se enrute a otro proveedor. `tool_choice: "none"` y `auto` funcionan normalmente. **`required` o una selección por nombre exacto se rechazan de forma segura**, porque `/api/chat` no tiene un campo `tool_choice` que permita hacerlas cumplir.
+- **La salida estructurada se rechaza en Ollama Cloud canónico.** Ollama documenta que su nube no admite esa función y no aplica las restricciones del campo `format`. OpenCodex rechaza la solicitud en lugar de devolver texto sin restricciones cuando se pide un esquema. Los destinos locales y personalizados `ollama-native` conservan la conversión nativa de `format`: `json_object` → `"json"` y `json_schema` → el objeto del esquema.
+
+## `openai-responses`
+
+**Objetivos:** el OpenAI **Responses API**. **`passthrough: true`** - normalmente reenvía el cuerpo de la solicitud sin procesar y la respuesta, con estrechas reescrituras de compatibilidad para puertas de enlace enrutadas. **Auth:** canónica OpenAI `forward` retransmite solo la lista de permisos de llamada segura; no canónico `forward` utiliza cabeceras estáticas configuradas sin retransmitir la autorización de llamada; `key` utiliza la clave de proveedor configurada.
+
+Cuando el historial de Google se reproduce al canónico ChatGPT Codex o al oficial OpenAI Responses API, el adaptador elimina el nivel de elemento `extra_content` de la solicitud HTTP saliente o WebSocket crea. Native `/responses/compact` aplica la misma proyección. La historia original mantiene la firma de pensamiento Google para Google giros posteriores. Otras Responses pasarelas conservan sus extensiones.
+
+Los destinos operados por OpenAI reciben las anotaciones `url_citation` del historial con los títulos
+e índices ausentes o inválidos corregidos. Esto se aplica a las solicitudes HTTP/WebSocket ordinarias
+y a `/responses/compact` nativo. Las pasarelas personalizadas conservan las anotaciones originales,
+incluso cuando `supportsNativeCompactEndpoint: true` habilita la compactación nativa. La corrección
+de citas no modifica el historial guardado por el cliente.
+
+El adaptador conserva el `User-Agent` del cliente entrante como un respaldo en ambos modos de autenticación porque algunos proveedores compatibles con Responses usan la huella digital del cliente Codex para el comportamiento de compatibilidad. Un proveedor configurado explícitamente `User-Agent` sigue siendo autorizado independientemente de la carcasa de la cabecera; si el llamante no envía ninguno, OpenCodex no inventa uno. Se pueden seleccionar metadatos adicionales del llamante con `forwardClientHeaders`; el proveedor `headers` gana para esta opción, y se rechazan los nombres de credenciales o de transporte. Canonical ChatGPT adelante auth conserva su lista de permisos de cabecera fija separada. Solo `originator`, `x-client-request-id`, `x-codex-app-version` y `user-agent` son compatibles con `forwardClientHeaders`; los nombres arbitrarios son rechazados en carga/escritura e ignorados en entorno de ejecución.
+
+`forwardClientHeaders` solo admite `originator`, `x-client-request-id`, `x-codex-app-version`, `user-agent`, `x-codex-window-id`, `x-codex-installation-id`. Nombres arbitrarios y comodines se rechazan al cargar/guardar y se ignoran en ejecución. Para un gateway de confianza que exija metadatos de Codex, como `codex_cli_only`, selecciona únicamente los necesarios:
+
+```json
+{
+  "forwardClientHeaders": [
+    "originator", "user-agent", "x-codex-app-version", "x-client-request-id",
+    "x-codex-window-id"
+  ]
+}
+```
+
+Solo conserva valores enviados por el cliente, también en compactación nativa y WebSocket, con la política de transporte final. Ambos IDs están desactivados por defecto y requieren selección independiente. `x-codex-installation-id` permite correlación entre sesiones; habilitar el de ventana no lo habilita. Quitar la opción evita copias futuras, sin borrar lo ya recibido. `headers` prevalece y no filtra IDs del cuerpo. No genera IDs ni les da identidad Codex a pruebas de conexión o descubrimiento; no demuestra cliente oficial ni permisos de acceso.
+
+<a id="native-compaction-on-custom-gateways"></a>
+
+### Compactación nativa en puertas de enlace personalizadas
+
+La compatibilidad con Responses por sí sola no es evidencia de soporte de compactación nativo. Las pasarelas personalizadas continúan usando resúmenes de texto portátiles a menos que el operador declare la capacidad relevante:
+
+- `supportsNativeCompactionTrigger: true` conserva las solicitudes de v2 `compaction_trigger` y la salida nativa.
+- `supportsNativeCompactEndpoint: true` opta por rutas clave/local/directa en el punto final v1 separado. OAuth conserva la compactación enrutada y su ciclo de vida de credenciales existente. El soporte V2 no implica soporte v1.
+- `decodesNativeCompactionBlobs: true` conserva los blobs nativos en turnos posteriores cuando no hay desajuste de proveedor de servicio conocido. Ninguna bandera de generación implica esta capacidad de reproducción.
+
+El v1 nativo personalizado también respeta `preserveResponsesReasoningContent: true` para la entrada de razonamiento de texto plano, igual que las solicitudes Responses personalizadas ordinarias. Si falta o es `false`, el contenido permanece en blanco; los destinos compactos operados por OpenAI siguen dejándolo en blanco incluso si la bandera está establecida. Los sobres internos `ocxr1:` siempre se eliminan. La preservación del texto sin formato es independiente de las banderas de generación, la capacidad de reproducción nativa de blob y las verificaciones de identidad de servicio.
+
+Si el proveedor personalizado también requiere resultados de herramientas adyacentes (`requiresAdjacentResponsesToolResults: true`), tanto el Responses ordinario como el v1 nativo eliminan el texto cifrado de razonamiento opaco y requieren una reproducción de texto sin formato. La falta de `reasoning_text` se rellena desde el `summary_text` del elemento, o con un marcador de posición mínimo si no existe un resumen utilizable. El texto plano existente se conserva. El modo compacto operado por OpenAI mantiene su propia política.
+
+Para una puerta de enlace cuyos **Generación v2 y reproducción** han sido verificados, combine estos campos en su configuración de proveedor existente, conservando su URL real y la autenticación configurada:
+
+```json
+{
+  "adapter": "openai-responses",
+  "supportsNativeCompactionTrigger": true,
+  "decodesNativeCompactionBlobs": true
+}
+```
+
+Estas opciones no convierten la pasarela en un destino oficial de OpenAI, no reenvían las credenciales de quien realiza la solicitud, no cambian la selección de cuenta ni omiten la normalización habitual de compatibilidad. Valida una respuesta de compactación real y la continuación de la conversación, además del estado HTTP 200. Mantén los blobs en el backend que los generó; la compactación enrutada entre proveedores sigue usando resúmenes portátiles. Los resúmenes de respaldo v1 siguen siendo portátiles aunque el destino admita por separado los disparadores v2. Las rutas con capacidad nativa quedan excluidas de la recuperación de emergencia mediante compactación portátil para su protocolo correspondiente.
+
+La selección del adaptador no determina el transporte hacia el proveedor. Las solicitudes elegibles pueden usar la [ruta proxy WebSocket](/es/reference/proxy-formats/#json-and-sse-output); una configuración de proxy WebSocket inválida o no admitida hace que se use HTTP/SSE. Las solicitudes Responses mediante HTTP fetch usan el [transporte de salida configurado](/es/reference/configuration/server/#server-fields). Un proxy SOCKS5 de `config.proxy` o de `ALL_PROXY` utiliza el túnel integrado, salvo que `NO_PROXY` excluya el destino. Las variables HTTP(S) específicas de cada esquema conservan su tratamiento nativo independiente. Un `ALL_PROXY` que no sea SOCKS no proporciona una ruta nativa para HTTP fetch.
+
+Las decisiones internas de modelo, las respuestas de compactación, el fallback de combos y la entrega nativa Responses aceptan tipos de medios event-stream válidos sin distinguir mayúsculas ni parámetros, incluido `Text/Event-Stream; charset=UTF-8`. Otros tipos explícitos conservan su formato aunque un parámetro mencione `text/event-stream`. La entrega nativa también identifica JSON por su tipo de medios exacto; mencionar JSON en un parámetro no selecciona ese decodificador. Se mantienen el fallback SSE sin encabezado y la validación de eventos V2 en texto plano.
+
+Las pasarelas Responses no canónicas reciben la declaración `tool_search` que ejecuta el cliente Codex como una herramienta de función pública con un nombre que evita colisiones. El historial de solicitudes correspondiente y las llamadas de función recibidas por JSON o SSE se convierten de nuevo al ciclo de vida privado `tool_search` que espera el cliente. El reenvío canónico a OpenAI conserva el tipo privado nativo sin cambios.
+
+Las solicitudes con `authMode` distinto de `"forward"` convierten los elementos `agent_message` de Codex en mensajes públicos de usuario cuando contienen una matriz no vacía de partes de texto plano compatibles. Conservan esas partes y los metadatos legibles de autor y destinatario. `agent_message` es un tipo privado del backend de Codex de ChatGPT; los destinos enrutados observados rechazan el cuerpo completo con `422 unknown item type "agent_message"`. Como Codex reproduce el historial de subagentes en cada turno, el error se repite durante el resto del hilo. El contenido cifrado o desconocido queda sin modificar, al igual que todos estos elementos en proveedores con `authMode: "forward"`. Para xAI Responses en HTTPS, en `api.x.ai` o `cli-chat-proxy.grok.com` y con el puerto estándar, un resultado de subagente de tipo cadena que contenga al menos un carácter que no sea un espacio en blanco también se convierte en una parte `input_text`, conservando exactamente sus espacios y saltos de línea. Los demás destinos conservan los elementos cuyo valor es una cadena. Las cadenas vacías o compuestas únicamente por espacios en blanco y las partes que mezclan contenido cifrado o desconocido no se convierten parcialmente. Véase [Mensajes de agentes](/es/reference/configuration/providers/#routed-agent-messages) para la recuperación opcional de tareas cifradas.
+
+Meta Responses también recibe las declaraciones actuales `additional_tools` de Codex en el array público `tools`. El catálogo se captura antes de normalizar el historial: las declaraciones reproducidas y los descubrimientos históricos de herramientas no pueden activar herramientas para el nuevo turno. Los alias actuales de namespaces, herramientas personalizadas y nombres largos conservan la normalización y restauración de respuestas existentes. Si un resultado de búsqueda repite una herramienta, se conserva el esquema de parámetros de su declaración actual. Las llamadas personalizadas históricas mantienen su representación como llamadas de función sin conceder autoridad actual a esas herramientas antiguas. Las definiciones de función anidadas se convierten en declaraciones públicas. Los catálogos de namespaces mal formados o que no se puedan representar devuelven HTTP 400 antes de la inferencia, también si la entrada es una cadena o se omite; no se promueven parcialmente.
+
+Para Meta Responses en el host exacto `api.meta.ai`, OpenCodex omite la entrada include no admitida `output.encrypted_content` que solicita Codex Desktop; de lo contrario, Meta rechaza la solicitud antes de la inferencia. Conserva `reasoning.encrypted_content` y las demás entradas para mantener la reproducción de razonamiento sin estado. La misma normalización de esa entrada exacta se aplica a xAI y a Kimi Code en su endpoint HTTPS Responses exacto (`https://api.kimi.com/coding/v1/responses`); los demás destinos Responses conservan su lista include original.
+
+Estas correcciones del formato no cambian los permisos de la cuenta. Meta limita las credenciales de suscripción Muse Code al cliente Muse Code; otros clientes requieren una clave API de Meta con facturación separada. Una clave de suscripción puede devolver HTTP 403 a través de OpenCodex aunque el formato sea válido. Consulta las [reglas de suscripción de Meta](https://dev.meta.ai/docs/muse-code/subscriptions).
+
+Para xAI Responses `auto` o `none` La selección de herramientas se omite cuando la normalización no deja herramientas en la solicitud, incluso cuando se elimina la búsqueda solo en caché. Selección de funciones forzadas válidas permanecen intactos. Las llamadas a herramientas personalizadas repetidas con ID de artículo no válido o que faltan reciben ID estables cuando su identificador de llamada, nombre y entrada son cadenas; su emparejamiento de llamada/resultado se conserva.
+
+El destino canónico ChatGPT Codex también normaliza dos formas públicas Responses que su extremo posterior más estricto rechaza: los mensajes `system` totalmente textuales dentro de `input` se agregan a la cadena `instructions` de nivel superior en orden de solicitud, y se elimina el campo `truncation` de nivel superior. Esta reescritura está limitada al destino. Los proveedores Responses de Key-Auth public/custom y las pasarelas de avance no canónicas mantienen ambos campos sin cambios; un mensaje de sistema multimodal nunca se pliega parcialmente o se deja caer silenciosamente.
+
+Para las continuaciones directas canónicas, las propiedades `prompt_cache_breakpoint` solo de cliente se eliminan recursivamente dentro de los límites transversales limitados. Cuando `store: false`, `item_reference` filas también se omiten porque el destino no puede resolver un elemento que no persistía. Función/herramienta `call_id` pares y `reasoning.effort` se conservan.
+
+[Compatibilidad con Luna Reserve](/es/reference/cli/providers-accounts/#luna-reserve-alongside-routed-models) utiliza esta ruta canónica de reenvío de ChatGPT, no la autenticación por clave ni las puertas de enlace Responses arbitrarias. Conserva la lista permitida de cabeceras seguras del llamante y la normalización de solicitudes de destino que se describen aquí. OpenCodex envía su cabecera de capacidad de Reserva en la búsqueda de uso de cuenta principal propia; esa cabecera no es en sí misma permiso. Las solicitudes de compatibilidad elegibles vuelven a verificar la autorización vinculada a credenciales en el envío. Conversación y compactación son compatibles; ayudantes de visión, ayudantes de búsqueda web, y relé de búsqueda independiente no lo son.
+
+En autenticación `key`, [`retryOn429`](/es/reference/configuration/) también se aplica aquí: un 429 anterior al inicio del flujo espera y reenvía la misma solicitud con la misma clave antes de cualquier otro tratamiento, igual que en la ruta traducida `openai-chat` / Anthropic. Los transportes personalizados `runTurn` quedan fuera del bucle de reintento HTTP.
+
+- El analizador sin estado Responses de DeepSeek recibe normalización del historial de alcance del proveedor: el contexto inyectado por gancho se mueve después de un lote de llamada de herramienta / resultado inequívoco. Las llamadas paralelas permanecen agrupadas antes de sus salidas coincidentes para que cada llamada permanezca en el turno del asistente de razonamiento. Los proveedores tolerantes y los identificadores ambiguos duplicados, faltantes o fuera de orden mantienen su orden de entrada original.
+
+- `forward` URL → `{baseUrl}/responses`. Un proveedor `key` se ajusta por defecto a la construcción heredada `{baseUrl}/v1/responses`.
+- Un proveedor `key` puede establecer un relativo validado `responsesPath`; el adaptador elimina una barra posterior de `baseUrl` y envía `{trimmedBaseUrl}{responsesPath}`. Para Ark Agent Plan, use `baseUrl: "https://ark.cn-beijing.volces.com/api/plan/v3"` con `responsesPath: "/responses"`.
+- En el modo `forward` solo se retransmite una lista de permisos de encabezado seguro (`FORWARD_HEADERS`): autorización, ID de cuenta ChatGPT y los encabezados beta/originador/sesión OpenAI. Esta es la ruta de inicio de sesión ChatGPT que también alimenta el [sidecares](/es/guides/sidecars/).
+
+<a id="command-code-session-affinity"></a>
+
+## Afinidad de sesión de Command Code
+
+El adaptador OAuth `command-code` deriva un `x-session-id` opaco de la identidad del hilo de cliente, luego la identidad de conversación de repetición de razonamiento. Cuando ninguno de los dos está disponible, utiliza una clave de caché rápida solo si la integración ha clasificado explícitamente esa clave como perteneciente a una conversación. Las claves de caché compartidas o no clasificadas no establecen afinidad de sesión; las solicitudes sin una identidad utilizable reciben un ID de sesión nuevo. La recuperación y la reproducción de la historia guardada en caché preservan esta clasificación.
+
+El proveedor con clave API `commandcode` usa Chat Completions para la mayoría de los modelos y el adaptador Anthropic Messages (`x-api-key`) para los identificadores `claude-*`, que Command Code solo sirve en `/provider/v1/messages`. La selección fija del adaptador solo se aplica mientras el proveedor apunte a ese endpoint. `tokenlab` aplica la misma regla a `claude-*` en `https://api.tokenlab.sh/v1/messages`, el endpoint que TokenLab anuncia para Chat y Messages. Command Code permite reenviar `prompt_cache_key`; esto es independiente del encabezado de sesión del adaptador OAuth y no garantiza un acierto de caché. El preset OAuth `command-code` recibe `/alpha/generate` como NDJSON. Si la pasarela repite como texto el marcado de una llamada MiMo real, se elimina ese duplicado. El marcado que aparece después de prosa normal, incluso si su marcador llega dividido entre deltas posteriores del mismo bloque, se retiene y solo se elimina si una llamada nativa contiene el mismo contenido. Si no coincide, se emite como texto y nunca se convierte en una llamada. La espera solo dura mientras siga abierta una llamada nativa que pudiera ser su duplicado, incluida la primera llamada a esa misma herramienta que empiece después del marcado. Si esas llamadas terminan sin coincidencia, el texto se libera de inmediato; la llegada intermedia de razonamiento u otros eventos no lo libera. Tras una finalización correcta o el cierre de una llamada a herramienta, un bloque completo que contenga únicamente una llamada a una herramienta declarada y no tenga contraparte nativa se restaura como llamada real. Si el turno se interrumpe o falla, queda como texto. Si el analizador no puede interpretar una llamada aislada, pero esta abre, cierra y nombra una herramienta declarada, se descarta en lugar de imprimirse cuando llega la llamada real a esa herramienta o el turno termina correctamente. Una llamada de formato libre repetida sin el cierre `</function>` se considera completa al llegar `</tool_call>`. Esto se aplica a todos los modelos MiMo servidos por Command Code.
+
+## `anthropic`
+
+**Objetivos:** Anthropic **Messages** ( `/v1/messages` ). **Auth:** `key` (`x-api-key` por defecto, o `Authorization: Bearer` con `apiKeyTransport: "bearer"`) o `oauth` (Portador + `anthropic-beta`, para Claude Pro/Max).
+
+- Convierte mensajes a bloques de contenido Anthropic (texto, imagen base64, `tool_use`, `thinking`).
+- La compactación enrutada de Codex conserva el catálogo de herramientas, el prompt de sistema y las opciones de selección para mantener el prefijo de caché. Las solicitudes de resumen deshabilitan los sidecars de búsqueda y medios. Las herramientas alojadas por el proveedor conservan sus declaraciones con `tool_choice: none`, igual que una elección de herramienta obligatoria, sin cambiar el catálogo anunciado. Si la solicitud anuncia una herramienta de búsqueda sidecar, como Exa, la compactación sí cambia ese prefijo de herramientas. Un resumen que intenta llamar a una herramienta falla sin publicar la llamada ni reemplazar el historial. Un resumen correcto devuelve exactamente un elemento de compactación. No cambian la normalización de imágenes ni el único reintento con reducción adicional de imágenes después de HTTP 413.
+- El razonamiento de la repetición Anthropic Messages comparte el presupuesto de traducción de la solicitud, incluida la sobrecarga de codificación/decodificación de copias. Las peticiones que la superan devuelven HTTP 413 con `translation_buffer_limit`; las firmas y los datos de razonamiento opacos nunca se truncan para encajar. Native Anthropic passthrough utiliza su contrato de tamaño de cuerpo separado.
+- **Matemáticas de pensamiento extendido:** Anthropic requiere `max_tokens > thinking.budget_tokens`. El adaptador asigna el esfuerzo de razonamiento a un presupuesto (mínimo 1024... max 32000), luego calcula un seguro `max_tokens` con espacio libre de salida, y **omite `temperature` / `top_p`** cuando el pensamiento está habilitado (Anthropic los prohíbe allí).
+- **Visualización del pensamiento adaptativo:** los modelos compatibles (Opus 4.7+, Sonnet 5 y Fable) reciben `thinking.display: "summarized"` para que Chat y Responses reciban deltas de razonamiento durante una reflexión larga. Ocultar el resumen (`reasoning.summary: "none"`) conserva el valor predeterminado del proveedor. Opus 5.5 nativo en `api.anthropic.com` usa `display: "updates"` de forma predeterminada; `reasoning.summary: "concise"` o `"detailed"` explícitos seleccionan `"summarized"` sin la beta de actualizaciones. Consulta [Actualizaciones de progreso de Opus 5.5](/es/guides/providers/#claude-opus-55-progress-updates).
+- **Salida estructurada:** Responses `text.format` y Chat Completions `response_format` las solicitudes con `type: "json_schema"` se convierten en Anthropic `output_config.format`. El formato se fusiona en una configuración de salida de pensamiento adaptativo existente, conservando un `output_config.effort` compatible. Las solicitudes Anthropic Messages enrutadas conservan el mismo formato a través de la traducción OAuth almacenada. El adaptador refleja el subconjunto de esquemas JSON soportado por Anthropic TypeScript SDK: las restricciones no soportadas se mueven a `description` como guía de modelo, `oneOf` se convierte en `anyOf` y los esquemas de objetos reciben `additionalProperties: false`. Una raíz `$ref` retiene su `$defs` adyacente de modo que la referencia local permanece resoluble. OpenAI campos envolventes tales como esquema `name`, envolvente `description` y `strict` no son parte del formato de cable Anthropic. El modo objeto JSON sin esquema no tiene equivalente Anthropic y no se traduce. En la dirección inversa, los esquemas de salida traducidos Anthropic conservan el esquema original del llamante. `strict: true` requiere una raíz de objeto sin una unión de raíz y objetos cerrados completos en todas las propiedades anidadas, elementos de matriz, uniones y definiciones: `properties` debe ser un objeto, `additionalProperties` debe ser `false` y `required` debe contener exactamente sus nombres de propiedad. Los objetos incompletos, palabras clave de esquema desconocidas y valores fuera del subconjunto estricto documentado de OpenAI usan `strict: false` explícito; el clasificador usa una lista de permisos en lugar de perseguir cada restricción no soportada por separado. El proxy no inventa campos requeridos, cierra un objeto abierto o descarta el esquema del llamante simplemente para obtener el modo estricto.
+- Siempre envía `anthropic-version: 2023-06-01`. Corrientes `content_block_delta` (`text_delta`, `thinking_delta`, compatibles `reasoning_delta`, `input_json_delta`). El decodificador SSE conserva el estado del evento a través de fragmentos de extracción y acepta un terminal `message_stop` sin una nueva línea posterior. En `message_stop`, el flujo traducido emite su resultado terminal y termina sin esperar a EOF aguas arriba. Los pings o comentarios posteriores no convierten ese mensaje completado en un error de flujo de búsqueda web. Los pings y los comentarios anteriores a `message_stop` siguen manteniendo viva la larga reflexión; los rechazos siguen siendo resultados incompletos no recuperables y las razones de detención de errores ascendentes siguen siendo fallas.
+- Para los giros Anthropic Responses encaminados con herramientas de cliente, un protector de terminal limitado detecta el caso de alta confianza en el que el usuario solicitó una acción pero Claude termina con una reclamación de ejecución y sin llamada de herramienta. Realiza como máximo una continuación interna; las respuestas normales, las preguntas de aclaración, los giros que usan herramientas y las respuestas incompletas de transporte no se reintentan automáticamente.
+
+## `google`
+
+**Objetivos:** Google **Gemini**, **Vertex AI**, y la Antigravity **Asistencia de código en la nube**. AI Studio utiliza
+`/v1beta/models/{model}:streamGenerateContent`; los otros modos usan sus puntos finales nativos Google.
+**Auth:** clave API, Vertex ADC o Google Antigravity OAuth, seleccionado por `googleMode`.
+
+- **Las denegaciones de ubicación son errores de permiso, no solicitudes inválidas.** Google rechaza ubicaciones geográficas o de centros de datos no compatibles con HTTP 400 `FAILED_PRECONDITION: User location is not
+  supported for the API use.` El proxy informa de esto como `… location not supported: …` y lo clasifica como `permission_error` con el código `location_not_supported`, por lo que un cliente no lee mal un rechazo de ubicación de red como un mensaje mal formado. La respuesta HTTP directa conserva el 400 del proveedor; las rutas que solo reciben un mensaje final infieren un 403, correspondiente a un error de permisos. La restricción procede de Google y el proxy no la elude.
+- Prompt de sistema → `systemInstruction`; mensajes → `contents[]` (asistente → `model`); herramientas → `functionDeclarations`. Imágenes con URL de datos → `inline_data`.
+- Los identificadores de llamada a herramientas se sintetizan cuando Gemini los omite. Vertex y Antigravity preservan y reproducen valores opacos de `thoughtSignature` para que las continuaciones de resultados de herramientas conserven la continuidad del razonamiento de Gemini. La caché de firma se captura en el directorio config, por lo que las continuaciones también sobreviven a los reinicios de proxy.
+- **Las formas de respuesta mal formadas fallan al cerrarse.** Un candidato reclamado, su `content`, o su `content.parts` que no es el contenedor documentado termina el turno con un error `google response contained invalid …` nombrando la razón estructural y el tipo del valor ofensivo - nunca su contenido. La ausencia se maneja por separado de la corrupción: una ausencia, `null` o `content` vacío o `parts` todavía completa el turno normalmente, un fragmento de flujo continuo cuyo `candidates` está ausente, `null` o vacío se omite para que el turno se complete en una trama terminal posterior, y una respuesta almacenada en memoria intermedia que no lleva ningún candidato en todos los retornos `google response contained no candidates`. Una raíz `data: null` keepalive marco todavía se omite como relleno.
+- Los lotes de llamada de herramienta se cierran en un turno de usuario inmediatamente adyacente que contiene un pedido de `functionResponse` por llamada representable. Las historias interrumpidas reciben un marcador explícito de resultados perdidos; los resultados duplicados o independientes se conservan como texto marcado (y hermanos de imagen) en lugar de emitirse como partes no emparejadas inválidas de `functionResponse`.
+- **Entrada de video y procesamiento agéntico.** La parte de contenido compatible con OpenAI `{"type": "video_url", "video_url": {"url": "…", "processing": "agentic"}}` se acepta en las rutas de ingreso de Chat y Responses. `url` es necesario; `processing` es opcional y se convierte a mayúsculas en la parte de Gemini como `media_processing` (`STATIC` es el valor predeterminado de Gemini, `AGENTIC` solicita comprensión agéntica del video). El campo se encuentra en la **parte**, junto a `inline_data` o `file_data`, por lo que se aplica a los bytes en línea y URIs buscados por igual: no es el `processing` de Interacciones API. Una solicitud que omite `processing` no gana campo, por lo que las llamadas existentes no cambian.
+
+  Se manejan tres formularios de URL, y solo tres:
+
+  | `url` | enviado como |
+  | --- | --- |
+  | `data:` URL | `inline_data` con el tipo de medio propio de la URL de datos |
+  | YouTube ver URL (`youtube.com`, `youtu.be`, `m.`/`music.`/`-nocookie` variantes) | `file_data.file_uri` |
+  | `https://generativelanguage.googleapis.com/<version>/files/<id>` - el formulario de recursos de Archivos API, donde `<version>` es `v1`, `v1beta` o `v1alpha` | `file_data.file_uri` |
+
+  Cualquier otra URL remota se mantiene como el marcador de texto `[video: <url>]`, porque el adaptador no tiene ningún tipo de medio para él y no hay evidencia de que Gemini lo buscará. La lista de permisos se hace coincidir en el host de la URL analizada y la ruta sobre HTTPS, no en una subcadena, para que un host similar no se convierta en una referencia `file_data` que el proxy pida a Gemini que busque. La ruta está anclada en el inicio, por lo que el punto final de carga reanudable (`/upload/<version>/files/<id>`) es *no* aceptado: no es un recurso legible, y `file_data.file_uri` pide a Gemini que acceda al recurso indicado a lo que se da. `file_data` lleva `file_uri` solamente; no se adjunta `mime_type` adivinado.
+
+- **Salida de imagen en línea:** cuando el modelo es uno de los ID de chat explícitos con capacidad de imagen (`gemini-3.1-flash-image`, `gemini-2.0-flash-preview-image-generation` o `gemini-3-pro-image-preview`), el adaptador envía `responseModalities: ["TEXT", "IMAGE"]`. No se incluyen los ID de generación de medios independientes, como `gemini-3-pro-image`. Las partes `inlineData` devueltas se materializan bajo el directorio OpenCodex `artifacts/` configurado y aparecen como enlaces de imagen de marcado descendente a la ruta opaca autenticada `/v1/opencodex/artifacts/<id>` (no `file:` URI o rutas del sistema de archivos host). Cada imagen se limita a 50 MB y cada respuesta a 100 MB de datos decodificados; se rechazan las cargas útiles base64 mal formadas. Los artefactos se podan automáticamente cuando el recuento supera los 200 archivos.
+
+## `kiro`
+
+**Objetivos:** el servicio Amazon CodeWhisperer Streaming `GenerateAssistantResponse` utilizado por Kiro (`https://runtime.{region}.kiro.dev/` ). **Auth:** Kiro OAuth token de acceso como portador, con metadatos de región/perfil de la credencial Kiro.
+
+- Construye Kiro `conversationState`, mapea las herramientas Codex y los resultados de la herramienta, y envía bloques de imágenes compatibles por el cable Kiro.
+- Conserva como máximo 20 imágenes en línea por mensaje y 100 por solicitud. Las imágenes antiguas del historial se omiten primero cuando la solicitud excede el límite, con un marcador de texto en los mensajes afectados; las imágenes recientes en el turno actual permanecen disponibles.
+- Cuando una URL de datos de imagen en línea carece de bytes de imagen o una coma, omite esa imagen con un marcador de texto en su turno de usuario o resultado de la herramienta. Las referencias a imágenes remotas usan un marcador separado; ninguno de los marcadores repite la URL.
+- Coalesce las salidas adyacentes de la misma herramienta original en un resultado Kiro. El texto permanece ordenado, las imágenes conservan los límites por mensaje existentes y cualquier indicador de error permanece establecido. Usuario, desarrollador, asistente u otra herramienta de salida termina el grupo. Se rechazan ID originales distintos que se asignan al mismo ID normalizado de Kiro.
+- Las salidas combinadas mantienen texto real e información de fallos sin insertar una pista de salida vacía para un fragmento en blanco posterior. Un solo resultado mantiene su normalización existente; un grupo completamente vacío de texto recibe un recurso alternativo, con una redacción neutral cuando hay imágenes o una bandera de error.
+- Trata un valor de cliente `parallel_tool_calls: true` como permiso en lugar de un requisito de cable. Kiro permanece serializado: el catálogo enrutado no anuncia ninguna capacidad de herramienta paralela y el adaptador no envía ningún campo de control paralelo aguas arriba, pero las vueltas de herramienta ordinarias Codex no se rechazan únicamente porque el cliente permite llamadas paralelas.
+- Acepta los controles de Responses `text` que no son salida estructurada, como `text.verbosity` y `text.format: {"type":"text"}`, sin reenviarlos. Kiro no dispone de campos para ellos, por lo que los ignora en vez de rechazarlos.
+- Envía como máximo 48 herramientas del cliente y 96 KB de JSON de herramientas convertido por solicitud, y recorta la descripción de cada herramienta a 1.024 caracteres (9.216 para `gpt-5.6-sol`). Primero admite las herramientas cargadas mediante búsqueda de herramientas y la herramienta de ejecución de modo código de Codex; informa al modelo de las herramientas omitidas. Configura `OCX_KIRO_TOOL_BUDGET=off` en el entorno del proxy para enviar todo el catálogo del cliente y `OCX_KIRO_TOOL_DESCRIPTION_LIMIT=off` para enviar las descripciones completas. Ambos se leen al convertir cada solicitud, se aplican a todos los modelos Kiro y no cambian otros límites. Desactivar el presupuesto elimina el límite, por lo que no hay nada que priorizar ni omitir: todas las herramientas declaradas se envían en orden de declaración, desaparece el aviso de omisión y un cliente que declare más de lo que Kiro acepta recibe la `ValidationException` ascendente en vez de un catálogo recortado. El tamaño de las solicitudes crece entonces con el catálogo del cliente. Estas opciones sirven para una cuenta en la que se haya medido la aceptación de solicitudes mayores; no hacen seguro un catálogo demasiado grande.
+- Elimina de los esquemas de herramientas y salida estructurada las palabras clave JSON Schema que rechaza el validador de Kiro (`pattern`, `minLength`, `maximum`, `additionalProperties` y otras 25), salvo las que una prueba haya medido como aceptadas por un modelo. `claude-opus-4.5` conserva todas. `claude-opus-5.5` y `claude-sonnet-5.5` conservan `pattern` y `maximum`; las demás se eliminan porque ninguna prueba las envió a esos modelos. Todos los demás modelos Kiro, incluidos los otros identificadores Claude, mantienen la eliminación completa. La excepción depende del modelo y de la palabra clave: este protocolo ya distingue los modelos Claude por esfuerzo de razonamiento y una palabra rechazada por Kiro hace fallar toda la solicitud, no solo priva al modelo de una indicación.
+
+- Emula la salida estructurada: `text.format` de Responses con tipo `json_schema` o `json_object`, y `output_config.format` de Messages. Como el protocolo Kiro no restringe la forma de la respuesta, el adaptador anuncia una herramienta privada de salida cuyo esquema de entrada es el solicitado y devuelve la entrada de esa herramienta como texto de respuesta. También acepta una respuesta de texto que ya sea el JSON solicitado. Si otra respuesta, incluso vacía, termina normalmente, realiza un solo reintento acotado. Un corte por límite de tokens de salida, filtro de contenido o ventana de contexto llena termina con el error de ese motivo. Si el reintento también falla, la solicitud termina con `invalid_kiro_structured_output`. La prosa no se devuelve como respuesta estructurada; los comentarios que preceden a una llamada real a una herramienta del cliente sí pueden transmitirse con ella.
+  Sin `strict: true`, se comprueban la sintaxis JSON, el tipo raíz y sus propiedades obligatorias. Con `strict: true`, el valor completo se valida exactamente contra el esquema. Un esquema estricto fuera de este subconjunto se rechaza antes del envío:
+  - `type`, `properties`, `required`, `additionalProperties`, un único esquema en `items`, `enum`, `const` y `anyOf`. Se rechaza un valor `const` o `enum` que contenga un número: la solicitud ya llega analizada y un número como `1.0000000000000001` llega como `1`, lo que podría aceptar un valor excluido por el cliente.
+  - `$ref` solo hacia `#/$defs/<name>` o `#/definitions/<name>` de la raíz del esquema, usando únicamente los escapes JSON Pointer `~0` y `~1`. Se rechazan referencias como `#`, `#/properties/...` o `#/default`, los `$defs` anidados y los ciclos de referencia que nunca alcanzan una propiedad o elemento. También se rechazan un `$ref` junto a una palabra clave de validación, porque los borradores difieren en su tratamiento, un `$id` bajo la raíz y `$anchor`.
+  - `minLength`, `maxLength`, `minItems` y `maxItems` como enteros no negativos.
+  - `minimum`, `maximum`, `exclusiveMinimum` y `exclusiveMaximum` como enteros seguros o decimales de hasta 15 cifras significativas. Los números de la respuesta se comparan tal como están escritos. El límite en sí usa una heurística: si fue escrito con más cifras de las que admite un double, puede llegar redondeado; un valor a aproximadamente una unidad en la última posición del límite puede juzgarse del lado equivocado.
+  - `multipleOf`, `pattern` y `patternProperties` se rechazan en modo estricto. Sin `strict: true`, se aceptan y solo se aplican las comprobaciones ligeras anteriores.
+
+  La validación está acotada por respuesta: 10.000 comprobaciones de esquema más 16 por valor JSON y 128 niveles de profundidad. El presupuesto incluye comparaciones `const`/`enum` y cada recorrido de listas `required`, entradas de objetos, cadenas largas y números largos. Se rechaza un formato estricto sin un objeto de esquema JSON, o una lista `type` que repita un tipo. Una respuesta que requiere más trabajo se considera incompatible con el formato. También se rechaza un esquema estricto con más de 10.000 nodos o más de 10.000 valores en sus literales `const`/`enum`. Los errores identifican únicamente la comprobación fallida, sin nombres de propiedades ni rutas de la respuesta o del esquema.
+  Un esquema Messages `output_config.format` siempre recibe las comprobaciones `strict: true`, incluso si tiene propiedades opcionales y se reenvía a destinos compatibles con OpenAI sin `strict`: Anthropic promete una respuesta que cumpla el esquema. Si queda fuera de este subconjunto, se rechaza antes del envío.
+- Decodifica `application/vnd.amazon.eventstream`, reconstruye eventos de texto / pensamiento / herramienta, detecta la herramienta truncada JSON y estima el uso porque el flujo ascendente no devuelve recuentos de tokens.
+  El cierre del decodificador inicia la cancelación sin esperar a que termine la limpieza del transporte; una promesa de limpieza bloqueada no mantiene abierto el decodificador después de que el consumidor deje de leer.
+- Utiliza el `baseUrl` configurado literalmente cuando es personalizado. Una URL canónica `runtime.{region}.kiro.dev` sigue la región API de la credencial importada; solo esa forma canónica es elegible para un retroceso presupuestado a `q.{region}.amazonaws.com` después de un fallo de punto final, firma, DNS o conexión, o HTTP 502/503/504 recibido antes de la salida.
+- Posee recuperación de conexión-reseteo segura para reproducción, esa única reserva de punto final elegible, una actualización/reproducción OAuth después de HTTP 401 y recuperación limitada para transitorios Kiro 429. Una revisión compartida y una única prueba posterior al enfriamiento evitan que las solicitudes simultáneas agoten los presupuestos de reintento independientes; los fallos de cuota difícil no se vuelven a intentar en esa misma cuenta y no se vuelven a reproducir otros errores de servicio. Cada envío físico Kiro utiliza la salida del proveedor configurada. Una fecha límite de encabezado devuelve 504; la cancelación de la persona que llama detiene el turno. Los cuerpos finales HTTP 5xx usan texto público fijo sin detalles previos.
+- Su analizador sin flujo drena el mismo flujo de eventos para el bucle de búsqueda web.
+- Informes de uso por cuenta. `AmazonCodeWhispererService.GetUsageLimits` en `https://management.{region}.kiro.dev/` devuelve la asignación del plan, que se convierte en la ventana de cuota mensual para esa cuenta; un saldo de prueba gratuita se informa como su propia ventana. La región proviene del perfil de la cuenta ARN, luego su región API /SSO almacenada. Una cuenta de AWS Builder ID no tiene un ARN de perfil propio, por lo que la sonda envía el mismo perfil de servicio Builder ID que utilizan las solicitudes de generación; ese ARN fijo nunca selecciona la región. Una respuesta ilegible o no reconocida se informa como desconocida en lugar de como uso cero, y una cuenta cuyo exceso está habilitado no se trata como agotada simplemente por pasar su límite. La operación no está documentada por AWS, así que trate los números como el mejor esfuerzo. Una cuenta sin ID de constructor sin un perfil utilizable ARN no hace ninguna solicitud de uso; el uso no está disponible mientras que una barra de cuota de mismo inicio de sesión anterior permanece visible. Las pruebas de cuota y agotamiento conocidas sobreviven al reinicio solo por el mismo inicio de sesión, cada uno hasta su propio reinicio o vida útil de diez minutos. La evidencia faltante, vieja o malformada se vuelve desconocida. El saldo crediticio preciso del plan se mantiene con la lectura de la cuota de identidad. Por separado, los valores de crédito Kiro `meteringEvent` son gastos de solicitud medidos: se usa el último valor dentro de una respuesta física y se agregan créditos de envíos facturados por separado. El uso de tokens sigue siendo estimado; los créditos nunca se infieren de los tokens. Las solicitudes con herramientas alojadas de búsqueda o imagen conservan la estimación completa del prompt del adaptador en Uso y en la actividad diaria, incluido el historial reproducido, aunque el modelo no invoque esas herramientas.
+- Después de una solicitud admitida, lee los modelos disponibles de esa cuenta desde el servicio de gestión regional sin retrasar la solicitud. Los resultados almacenados en caché agregan ID de modelo al catálogo enviado. Las respuestas vacías o no reconocidas retienen la lista enviada y cualquier lista de la última buena cuenta. La membresía modelo guía la preferencia de cuentas elegibles; las identificaciones desconocidas aún van hacia arriba. Los límites de entrada informados informan las ventanas de contexto, combinadas de manera conservadora con los límites enviados cuando la evidencia es parcial. Las cuentas que no han servido aún no tienen evidencia de lista.
+- Participa en la rotación de cuentas múltiples. Con dos cuentas almacenadas, un rechazo de tasa de solicitud enfría brevemente la cuenta rechazada; un rechazo con el motivo exacto `MONTHLY_REQUEST_COUNT` o `OVERAGE_REQUEST_LIMIT_EXCEEDED` en HTTP 400 o 429 excluye esa cuenta hasta el reinicio observado o la expiración de la evidencia. Una suspensión confirmada de HTTP 403 pone en cuarentena esa cuenta en proceso, mientras que una 403 ordinaria no rota. La rotación reactiva permanece disponible cuando `oauthAccountFailover.enabled` es falsa. La selección consciente de rechazo antes del primer envío requiere preferencia proactiva, con la configuración del proveedor teniendo prioridad sobre la configuración global. Un giro completo del mismo inicio de sesión borra un veredicto de agotamiento más antiguo. Cada portador rotado lleva su propio perfil ARN y región.
+
+<a id="completion-semantics"></a>
+
+### Semántica de finalización
+
+El texto del asistente Kiro no tiene una fase de giro final propia confiable. Su terminal `metadataEvent` puede llevar un nativo `stopReason`, pero Kiro puede etiquetar la prosa de progreso como `END_TURN`. Por lo tanto, en los giros habilitados para herramientas, `END_TURN` y `STOP_SEQUENCE` solo prueban que la inferencia se detuvo; el texto ordinario permanece como comentario e ingresa la validación de finalización limitada.
+
+`END_TURN`, `STOP_SEQUENCE`, o una razón de parada faltante puede usar la ruta de compatibilidad. Otras razones explícitas ya han terminado la inferencia en sentido ascendente, por lo que el adaptador las informa en lugar de gastar otra solicitud de modelo: una superficie de límite de token de salida como salida incompleta que un cliente puede continuar, mientras que las superficies de agotamiento de ventana de contexto como un error de longitud de contexto no reintentable en lugar de como salida truncada. El filtrado y la barrera de protección se detienen en la superficie como salida incompleta filtrada, y una parada `TOOL_USE` que llega sin una llamada de herramienta real se informa como una contradicción en lugar de tratarse como progreso.
+
+Cuando existe una herramienta cliente normal, opencodex agrega una herramienta privada `codex_kiro_final_answer` a la solicitud ascendente; progrese flujos de texto como comentario y no puede terminar el turno. El adaptador consume la llamada privada, emite su respuesta como texto final, y nunca expone la herramienta privada a Codex o Claude Code. Debido a que la razón de parada solo llega al final de la secuencia, el texto del asistente en un turno habilitado para herramientas se mantiene hasta que se inicia una llamada de herramienta real o la secuencia termina, luego lo libera como comentario a menos que la herramienta privada proporcione la respuesta final. Cuando el sidecar de búsqueda web está activo, los comentarios publicados aún se transmiten antes del evento terminal; solo los eventos necesarios para decidir si el modelo solicitó una búsqueda sintética permanecen almacenados en el búfer.
+
+Una pregunta sin la que el modelo no puede proceder es también una respuesta final. El contrato inyectado le dice a un modelo enrutado que cuando necesita una decisión, una información o una aclaración que solo el usuario puede dar, debe entregar esa pregunta a través de `codex_kiro_final_answer` y detenerse, en lugar de escribir la pregunta como texto ordinario y continuar. Tal turno llega como cualquier otra respuesta completada: texto final con el turno terminado, no comentario y no una llamada de herramienta de cliente. Sin esto, el contrato sólo describe "todavía funciona" y "completamente", y un modelo de celebración de una pregunta de bloqueo no tenía manera de decirlo - el resultado observado fue una pregunta y una auto-invalidación emitida como un mensaje, seguido de otra llamada herramienta de la misma inferencia.
+
+Si Kiro se detiene sin llamar a la herramienta de finalización, el adaptador hace una continuación. Razonamiento: solo los reintentos conservan el turno original válido de usuario/resultado de la herramienta en lugar de fabricar un mensaje de asistente vacío; el progreso visible se reproduce con una instrucción propiedad del adaptador no vacía. Antes del transporte, la conversación generada se comprueba en busca de roles alternativos, giros estructurales no vacíos e identificadores de uso de herramientas/resultado coincidentes. La salida de la herramienta vacía recibe un marcador de posición neutral no vacío. El reintento no se puede repetir: un reintento vacío o solo razonado se devuelve como incompleto reintentable, mientras que una llamada de herramienta de cliente real mantiene el turno abierto. Una respuesta de la herramienta de finalización siempre se emite como `final_answer`, incluso cuando se repite exactamente el comentario anterior, porque la corrección de fase es más importante que la deduplicación cosmética. Las solicitudes libres de herramientas conservan el comportamiento normal de finalización del texto.
+
+La instrucción de continuación informa al modelo de que su texto ordinario aún no llegó al usuario y le pide llamar a `codex_kiro_final_answer` con la respuesta final completa si la tarea terminó, enviando la respuesta anterior sin cambios cuando ya era la respuesta correcta. Así, un modelo que respondió a una petición trivial en texto conserva su respuesta en vez de recibir una orden de continuar un trabajo ya completado.
+
+<a id="reasoning-effort"></a>
+
+### Esfuerzo de razonamiento
+
+La familia GPT-5.6 y los modelos GPT-6 (`gpt-6-sol`, `gpt-6-luna`, `gpt-6.1-sol`, `gpt-6.1-terra`) usan `additionalModelRequestFields.reasoning.effort`; los identificadores Claude indicados abajo usan `additionalModelRequestFields.output_config.effort`. Para `gpt-5.6-luna` y `gpt-5.6-terra`, solo `low`, `medium`, `high` y `max` usan la ruta nativa verificada. Su selección `xhigh` conserva las instrucciones anteriores de pensamiento limitado en el contenido del usuario porque ese nivel nativo no se ha verificado. `gpt-5.6-sol` y los modelos GPT-6 mantienen su comportamiento nativo `low`, `medium`, `high`, `xhigh` y `max` mediante el mismo campo `reasoning.effort`.
+
+Kiro acepta `output_config.effort` para `claude-opus-5`, `claude-opus-5.5`, `claude-opus-4.8`, `claude-opus-4.7`, `claude-opus-4.6`, `claude-sonnet-5.5`, `claude-sonnet-5`, `claude-sonnet-4.6` y `claude-haiku-5.5` con `low`, `medium`, `high`, `xhigh` y `max`, con una excepción: `claude-opus-4.6` y `claude-sonnet-4.6` rechazan el `xhigh` nativo, por lo que ese nivel conserva el bloque de pensamiento emulado.
+
+Kiro no tiene nivel `minimal`. En los nueve modelos salvo `claude-opus-5` y `claude-opus-5.5`, `minimal` conserva el bloque emulado en vez de fallar una solicitud que funcionaba antes de habilitar el esfuerzo nativo. Esos dos modelos Opus 5 y los modelos GPT con esfuerzo nativo rechazan `minimal` con un 400 `invalid_request_error` antes de enviar nada.
+
+Las interfaces informan el rechazo de manera distinta. Una solicitud Responses incluye en `error.message` una frase con el modelo y el esfuerzo rechazado. Las rutas Messages y Chat Completions incluyen allí su texto fijo — `The provider rejected the request.` — porque sustituyen el detalle del adaptador por su propia frase. Solo Responses indica el modelo y el esfuerzo. Las solicitudes con y sin streaming se comportan igual en cada interfaz: el rechazo ocurre al construir la carga, antes de abrir un stream o enviar una solicitud al proveedor.
+
+El `ultra` del cliente se reduce a `max` durante el análisis. Los valores fijados `pinnedReasoningEffort`, `modelPinnedReasoningEfforts` y `modelPinnedEfforts` se aplican después; para modelos con esfuerzo nativo Kiro, el adaptador también convierte un `ultra` fijado en `max` nativo. Para modelos con razonamiento emulado, se descarta un `ultra` fijado y la solicitud se envía sin señal de razonamiento.
+
+`claude-haiku-4.5`, `claude-opus-4.5` y `claude-sonnet-4.5`, así como cualquier modelo Kiro no enumerado arriba, usan razonamiento emulado en todos los niveles; un control de esfuerzo anunciado no demuestra compatibilidad nativa.
+
+## `cursor`
+
+**Objetivos:** `agent.v1.AgentService/Run` de Cursor sobre HTTP/2 Connect streaming en `api2.cursor.sh` por defecto. Con `upstreamHttpVersion: "http1.1"` (o `"h1"`), utiliza el par de compatibilidad HTTP/1.1 de Cursor: `agent.v1.AgentService/RunSSE` para la salida del servidor y `aiserver.v1.BidiService/BidiAppend` para mensajes de cliente. **Auth:** Cursor OAuth /token de acceso desde `provider.apiKey` o la cabecera de autorización reenviada.
+
+- Utiliza `runTurn` en lugar de la ruta ordinaria de extracción / análisis. Las solicitudes, los eventos del servidor, los argumentos de la herramienta, los puntos de control de uso y las respuestas del cliente se codifican con `@bufbuild/protobuf` esquemas en `cursor/gen/agent_pb.ts` y se enmarcan como mensajes de conexión.
+- Reproduce el estado de la conversación a través de blobs dirigidos al contenido, mapea las llamadas de la herramienta del servidor al Codex, descubre los modelos en vivo del Cursor a través del protobuf `GetUsableModels` RPC y vuelve a intentarlo solo antes de que se envíe una solicitud de ejecución al cable.
+- Después de un giro sin herramientas exitoso, el adaptador mantiene Cursor ConversationStateStructure devuelto en un almacén de proceso local y reutiliza ese punto de control en la siguiente continuación lineal validada en lugar de reconstruir toda la historia raíz. Los turnos de resultados de herramientas reutilizan el último turno completado punto de control más solo el sufijo descubierto cuando se conoce el límite del mensaje cubierto. La búsqueda de prefijos sin refrescar requiere una conversación Cursor recordada o un hilo de cliente estable (incluyendo la sesión de escritorio limitada / retroceso del hilo) y un punto de control propiedad de ese mismo conversación con el proveedor; de lo contrario, se reproduce completamente. Compactación, aislamiento helper/shadow, desajuste cuenta/modelo, falta de refs, fallos de decodificación, recuperación forzada-fresca, y invalid_argument reintentos caen de nuevo a la repetición completa existente. A El reinicio del proceso elimina el almacén en memoria y las repeticiones completas. Cursor Conectar todavía no expone cache_read_tokens autorizada, por lo que el uso de OpenCodex no es un contador de aciertos en caché. El respaldo de escritorio limitado almacena solo un propietario derivado de HMAC de proceso; sesión/hilo en bruto cabeceras y OAuth/material de autorización nunca se escriben en el estado del punto de control. Cursor El transporte en vivo respaldado por OAuth y el descubrimiento de modelos filtrados por cuenta siguen siendo experimentales; vea el
+  [guía del proveedor](/es/guides/providers/) y [Configuración del proveedor Cursor](/es/reference/configuration/providers/#cursor-provider-adapter-cursor)
+  para los ajustes de inicio de sesión y transporte. La reutilización del punto de control es automática y no tiene ninguna configuración de usuario.
+- Las continuaciones de herramientas de modelo externo mantienen la última solicitud de usuario real en la acción activa; los resúmenes automáticos y el contexto de entorno-navegador independiente siguen siendo contexto histórico. La entrada de usuario en blanco o solo imagen no revive una solicitud anterior. Grok 4.6 guía de modo de código requiere la emisión de resultados explícitos y nunca supone una celda vacía completa emitida salida. La salida faltante requiere una comprobación de estado de solo lectura, no una repetición de un efecto secundario completado. El aviso de repetición se restablece en un nuevo turno de usuario / desarrollador y permite las encuestas solicitadas. Si las raíces de los puntos de control superan el presupuesto de reproducción, el historial disponible se reconstruye bajo los mismos límites. Estas reparaciones no garantizan una redacción ni un comportamiento de razonamiento idénticos entre las rutas Cursor y xAI.
+- Honores `upstreamHttpVersion` para el descubrimiento y la inferencia del modelo en vivo. `auto`, `http2` y `h2` conservan el transporte HTTP/2 existente; solo `http1.1` y `h1` seleccionan el modo de compatibilidad.
+- Expone Cursor Router como `cursor/auto` más entradas explícitas `cursor/auto-cost`, `cursor/auto-balance` y `cursor/auto-intelligence`. Los niveles explícitos se codifican en `requested_model.parameters` mientras que la entrada `cursor/auto` heredada retiene el valor predeterminado de la cuenta/equipo.
+- Envía niveles regulares `cursor/grok-4.5` con los identificadores de cable de descubrimiento en vivo exactos de Cursor (`cursor-grok-4.5-low`, `-medium` o `-high`). Mantiene el `cursor/grok-4.5-fast` seleccionable mientras envía el modelo canónico `grok-4.5` con parámetros separados `effort` y `fast=true`.
+- La ejecución nativa local de Cursor (filesystem/shell/network) se deniega de forma predeterminada. Las integraciones explícitas `mcpServers` y `desktopExecutor` tienen opt-ins separados; `nativeLocalExec: "on"` habilita el ejecutor incorporado más amplio y evita la aprobación/semántica de sandbox Codex, y el legado `unsafeAllowNativeLocalExec: true` permanece equivalente solo cuando `nativeLocalExec` no está definido. Las solicitudes en primer plano `shellArgs` y `shellStreamArgs` son una excepción: ambas se rechazan antes de crear el proceso en todas las plataformas hasta que esté disponible el control de pertenencia de los procesos descendientes mediante el kernel. Utilice herramientas de shell de cliente; la ejecución de shell de fondo y otras operaciones nativas conservan su política existente.
+- La respuesta de denegación se adapta al catálogo de herramientas de la solicitud. Para modelos Cursor de la familia Claude seleccionados explícitamente, enumera las herramientas disponibles sin pedir que se oculte la redirección. El modelo puede explicar el enrutamiento antes de llamar a una herramienta, sin terminar el turno. Si no hay herramientas del cliente ni herramientas MCP configuradas, se le pide que responda sin herramientas o explique la limitación. Otros modelos, incluidos Auto y el predeterminado, conservan la redirección silenciosa y la protección de comentarios existentes. La disponibilidad de herramientas, la política de ejecución y las reglas de aprobación y sandbox no cambian. En modo de código, cuando el catálogo expone un `exec` unificado de forma libre y ningún puente de shell independiente, se redirige al interior de `exec`: las operaciones de shell, archivos, búsqueda y consulta se invocan como ayudantes `tools.<name>(...)` dentro de la celda JavaScript. No se recomienda un puente de shell de nivel superior que ese catálogo no expone. Los catálogos planos con `shell_command` / `exec_command`, o con un `exec` unificado que no sea de forma libre, conservan la indicación del puente. Si no se ofrece ninguna de esas variantes, como en un cliente orquestador con sus propias herramientas Responses, se usan los nombres reales de herramientas de la solicitud, sin inventar alias.
+- Una puerta de política de datos Cursor reconocida se informa con su título, la acción que requiere y la URL de revisión del panel de control Cursor en lugar de una `failed_precondition: Error` desnuda. El reconocimiento se limita a los detalles estructurados conocidos: los detalles desconocidos o mal formados mantienen el error genérico de Connect, no se reenvía ni se ejecuta ninguna acción de texto, botón, URL o consentimiento ascendente, y el fallo no se puede volver a intentar. La revisión y aceptación de una política de datos sigue siendo una acción del usuario en el propio Cursor.
+
+Los esquemas de shell compatibles con Codex conservan los permisos de sandbox, la justificación, las reglas de prefijo reutilizables y el modo de inicio de sesión. Las herramientas de forma libre exponen una cadena obligatoria `input` y mantienen sus instrucciones específicas, como el envoltorio exigido para un parche. Los nombres sin prefijo `exec_command` y `shell_command` están reservados para puentes de shell que no sean de forma libre; una herramienta personalizada de forma libre que use esos nombres debe llevar un espacio de nombres. Declarar estos esquemas no concede aprobación ni modifica la política de ejecución.
+
+## `devin`
+
+**Objetivos:** `exa.api_server_pb.ApiServerService/GetChatMessage` de Cognition sobre streaming Connect por HTTPS en `server.codeium.com`. **Auth:** clave API de Devin/Cognition de `provider.apiKey` o la cabecera de autorización reenviada. Login primero intenta importar la credencial que Devin CLI ya tiene instalada: `devin auth
+login` completa el propio inicio de sesión PKCE del CLI y escribe un `devin-session-token` en su `credentials.toml`, que es la misma credencial que `SeatManagementService.RegisterUser` emite para un inicio de sesión en el navegador. Cuando no existe una credencial CLI utilizable, el inicio de sesión vuelve al inicio de sesión del navegador Auth0 e intercambia el token pegado a través de `RegisterUser` por una clave API de larga duración. `devin-cli` sobrevive solo como un alias obsoleto: `ocx login devin-cli` aún se encamina a `devin`, y una configuración guardada que nombra el antiguo id se reescribe al inicio.
+
+- Utiliza `runTurn` en lugar de la ruta ordinaria de extracción / análisis. Las solicitudes y los eventos del servidor se codifican con el encuadre manual de protobuf en `devin/cloud-direct/wire.ts`; la ruta ordinaria `buildRequest` / `parseStream` está deshabilitada.
+- Las conversaciones con nombre reutilizan una trayectoria en turnos secuenciales, con alcance a la credencial resuelta y al host inquilino. La identidad de hilo propio tiene prioridad sobre los marcadores de sesión (`session_id`, `session-id` o `x-session-affinity`). Cuando se suministran una identidad de hilo propio y un `x-codex-parent-thread-id` no vacío, su par identifica la conversación, por lo que las ID propias iguales bajo diferentes padres permanecen separadas. Las identidades independientes propias y de solo sesión conservan su precedencia existente; un padre compartido solo no es una identidad de conversación. Los turnos superpuestos reciben distintas ID. El proxy retiene como máximo 256 entradas en la memoria, desaloja solo entradas inactivas y libera reclamaciones después de la finalización, el fallo o la cancelación. Reiniciar el proxy borra la retención. Las llamadas sin nombre continúan asignando un ID por solicitud. Esto admite continuidad pero no garantiza un éxito de caché ascendente o un ahorro particular.
+- La continuidad del razonamiento lleva firmas de proveedores a través de turnos. Si Cognition rechaza una repetición firmada de Anthropic antes de la salida visible, Devin vuelve a intentarlo una vez con la firma retenida y el texto pensante conservado.
+- Descubrimiento de modelos en vivo a través de `GetCascadeModelConfigs`; la lista estática visible se filtra con la lista en vivo de la cuenta: se eliminan los modelos que no están incluidos en su plan, en lugar de dejarlos fallar al enviar una solicitud.
+- Las definiciones de herramienta se codifican en la solicitud y los eventos de llamada de herramienta se decodifican a partir del flujo de respuesta. Cognition impone un límite de longitud por herramienta-descripción (6998 caracteres) y una lista de bloques de frases exactas; el adaptador desinfecta los disparadores conocidos y trunca las descripciones demasiado largas antes de codificar.
+- Las claves API de Devin/Cognition no tienen punto final de actualización. Si Cognition rechaza una clave almacenada con 401, OpenCodex marca esa cuenta para la reautenticación y puede usar otra cuenta de inicio de sesión para El turno. Correr `ocx login devin` de nuevo para una clave de inicio de sesión del navegador revocada. Una cuenta importada por CLI Puede seguir un `devin auth login` rotación de teclas solo cuando su ID de cuenta o correo electrónico almacenados coincide con la identidad CLI acuñada. Importaciones sin una identidad almacenada requieren un
+  `ocx login devin` Después de la rotación. Un legado `devin-cli` slot para esa misma cuenta ya puede Mantenga la nueva clave; una cuenta diferente que la mantenga bloquea la adopción. Si el archivo CLI es temporalmente ilegible o la verificación de identidad no está disponible, reintente después de que se recupere. Una cuenta en pausa permanece en pausa durante esta recuperación y devuelve 403.
+- Solo la credencial es local cuando se usa la ruta de importación CLI. El turno en sí mismo va a Cognition de cualquier manera, por lo que las rutas de inicio de sesión de importación y navegador no difieren en nada más que de dónde vino la credencial. Instale el CLI con `curl -fsSL https://cli.devin.ai/install.sh | bash` o `brew install --cask devin-cli`, ejecute `devin auth login` una vez y luego agregue el proveedor.
+- Una compilación anterior envió un segundo adaptador bajo el id `devin-cli` que ejecutó el turno como una sesión de Protocolo de cliente de agente contra un proceso secundario local `devin acp`. Se ha ido. Una configuración guardada que todavía nombra ese adaptador se reescribe a `devin` al iniciarse, incluida una fila con nombre personalizado como `"devin-acp"`.
+- La solicitud de chat está calibrada, no adivinada. Tres cosas lo unen: la credencial es el token de sesión duplicado y unido en un encabezado `Authorization: Basic`, mientras que el cuerpo del protobuf mantiene una copia, la envolvente de la solicitud sube sin comprimir y `Metadata` #31 lleva una huella digital del dispositivo de 732 caracteres cuya longitud, no valor, el servicio verifica. En el interior `CompletionConfiguration`, el campo #2 es el límite de salida y el campo #3 es `max_newlines`, enviado a un valor fijo grande; intercambiar esos dos hace que cada turno falle con un `invalid_argument` opaco. Sin límite de llamadas o configurado, el límite de salida es el propio techo del modelo seleccionado del catálogo, y 8192 solo cuando el catálogo no está disponible. Se rechaza una temperatura de exactamente 0, por lo que se fija al valor aceptado más pequeño.
+- Una pre-salida 429 con un retardo de recuperación indicado aparece inmediatamente por defecto, liberando la capacidad compartida del giro admitido. Establezca `OPENCODEX_DEVIN_STATED_RESET_WAIT_MS` en una asignación acumulativa positiva en milisegundos para esperar el retraso completo indicado y reproduzca la misma solicitud hasta dos veces. La asignación tiene un límite máximo de una hora; un valor ausente, vacío, inválido o negativo desactiva la espera. Una espera independiente optada mantiene el giro HTTP y su ranura de giro activo compartida abierta durante todo el retraso. Los giros de transmisión comienzan SSE en un latido del corazón de enfriamiento seguro, luego programa los latidos del corazón cada 500 ms o menos durante la espera para que el supervisor se mantenga alimentado. Una salida previa posterior 429 puede rotar aún a otra cuenta elegible OAuth; sin una se informa dentro del flujo ya abierto. Grok giros amortiguados retienen un HTTP 429 y `Retry-After` en un rechazo final. Los niños combinados muestran la presalida 429 inmediatamente, incluso cuando la espera está habilitada, de modo que el combo puede probar su siguiente objetivo sin mantener una respuesta no comprometida. Los retrasos que exceden la asignación restante en giros independientes aparecen en el 429 original sin un reintento temprano. El 429 final conserva el retraso declarado como una pista de enfriamiento. Un `~` en su mensaje marca un retraso recuperado de una oración de remolque de segunda mano en lugar de un valor de encabezado exacto.
+- Para los flujos de Responses Codex, los fallos de límite de velocidad tipificados conocidos con un retardo válido se normalizan a `rate_limit_exceeded` con `Please try again in Ns.` antes del detalle redactado original. Esto permite que Codex honre el retraso indicado y use su notificación de reconexión nativa sin agregar un elemento de razonamiento al historial de conversaciones. Los reintentos del cliente son finitos y están controlados por el `stream_max_retries` del cliente; esto no promete recuperación después del apagado o reinicio de la aplicación. Deja `OPENCODEX_DEVIN_STATED_RESET_WAIT_MS` sin definir o en `0` para que el cliente sea el propietario de la espera. Una asignación de proxy positivo mantiene la espera existente propiedad de proxy; el cliente sólo se entera de un rechazo final después, y los reintentos de cliente pueden multiplicar los intentos por solicitud del proxy. La conmutación por error de destino/cuenta combinada y el manejo Grok HTTP 429 conservan su orden existente. La ubicación exacta de la interfaz de usuario y el texto dependen de la versión Codex; esto no es una cuenta atrás personalizada. Los errores de límite de velocidad de solo mensaje usan el mismo formato de retardo más largo. Los errores tipificados sin un retraso útil retienen su código original. Los reintentos de cliente crean nuevas solicitudes HTTP; no comparten el contador de envío o la asignación de espera acumulativa de una solicitud proxy. Esta asignación de compatibilidad no reemplaza los controles de una espera proxy habilitada explícitamente.
+- Puente no oficial experimental; no se muestra en el panel de control preestablecido de forma predeterminada. Vea el [guía del proveedor](/es/guides/providers/) para instrucciones de inicio de sesión.
+
+El identificador de modelo que elige es una familia de modelos, y el esfuerzo de razonamiento elige la variante. Sin esfuerzo, se utiliza la variante por defecto de la familia: `swe-1-7` selecciona `swe-1-7-medium` y `swe-2` selecciona `swe-2-high`. Un esfuerzo cambia solo el esfuerzo y aterriza en la variante más baja en o por encima de él, o la más alta por debajo cuando no hay nada por encima, por lo que un peldaño faltante nunca baja el razonamiento: `swe-1-7` en `high` selecciona la fila máxima `swe-1-7`, `swe-2` en `low` selecciona `swe-2-medium` y `kimi-k3` en `medium` selecciona `kimi-k3-high`. `fast` selecciona la variante Fast y `1m`, `max-1m` o `none-1m` la variante de contexto 1M donde la familia tiene uno; de lo contrario no cambian nada. Un id con sufijo como `claude-opus-5-high-fast` mantiene su variante sin esfuerzo, y con uno mantiene su configuración rápida y contextual a menos que eso disminuya el esfuerzo: sin fila rápida en o por encima del esfuerzo, se usa la fila regular. Un id que nombra una variante que tu cuenta ha deshabilitado se envía con el nombre cuando el esfuerzo aún aterriza en ella, por lo que la solicitud falla con el propio error de esa variante en lugar de cambiar de nivel silenciosamente. La resolución nunca se traslada a otra familia. Cuando el catálogo de la cuenta no está disponible, el esfuerzo se agrega al id.
+
+## `zed`
+
+**Destino:** el endpoint `POST /completions` de Zed Hosted AI en `cloud.zed.dev`.
+**Autenticación:** identidad de la cuenta de la aplicación nativa de Zed y token de acceso, que se intercambian por un token LLM de corta duración.
+
+- Utiliza el inicio de sesión de devolución de llamada RSA nativo (`ocx login zed`) y empareja el `user_id` devuelto con el token de acceso para búsquedas de usuarios y organizaciones con alcance de cuenta.
+- Envuelve los constructores de chat existentes Anthropic Messages, Google Gemini, OpenAI Responses y xAI dentro del sobre del proveedor de Zed, luego desenvuelve los eventos NDJSON/SSE de Zed en `AdapterEvent`.
+- Obtiene una lista de modelos en vivo acotada y limitada a la cuenta para la visualización y la inferencia de familia de proveedor; la lista no es una lista de modelos permitidos, por lo que un id de modelo proporcionado por quien llama se sigue reenviando.
+- Experimental, no oficial y no respaldado por Zed. Usarlo puede romper los términos de servicio de Zed y puede limitar o suspender la cuenta de Zed; ese riesgo es el del usuario.
+
+## `azure-openai` (alias: `azure`)
+
+**Objetivos:** **Azure OpenAI**. Envuelve `openai-responses` (así también `passthrough: true`). **Auth:** `key` a través del encabezado `api-key` (no portador).
+
+Las solicitudes Azure omiten la entrada no admitida output.encrypted_content de include y conservan reasoning.encrypted_content y las demás entradas. Esto también se aplica a configuraciones openai-responses dirigidas a un recurso bajo .openai.azure.com. Si no queda ninguna entrada, se omite include.
+
+- Delega la construcción de la solicitud al adaptador de passthrough de Responses, valida que `baseUrl` no contenga marcadores de plantilla sin resolver y sustituye `Authorization` por `api-key`. La URL configurada apunta directamente a la API Responses v1 de Azure, por lo que el adaptador no añade `api-version`.
+- Comparte la recuperación de Responses para el estado de razonamiento generado por otro proveedor: después de un `400 invalid_encrypted_content`, reenvía una sola vez sin ese estado. Consulta «Cambiar de proveedores en una conversación existente» en [Formatos del proxy](/es/reference/proxy-formats/).
+
+<a id="image-utilities-imagets"></a>
+
+## Utilidades de imagen (`image.ts`)
+
+Funciones auxiliares compartidas por los adaptadores con capacidad de visión:
+
+- `parseDataUrl(url)` - dividir una URL `data:<type>;base64,<data>` en `{ mediaType, base64 }` para bloques de imagen Anthropic / Google.
+- `contentPartsToText(content)` - Aplanar las partes de contenido al texto para mensajes de herramienta de solo texto (una imagen no descrita se convierte en un marcador corto de `[image]`, nunca en un bloque base64 de explosión de token).
+
+<a id="grok-build-terminal-snapshots"></a>
+
+## Instantáneas de terminal Grok Build
+
+Las solicitudes marcadas con `x-opencodex-grok: 1` optan por una reparación de terminal estrecha Responses. Si `response.completed.response.output` falta o está vacío, opencodex puede reconstruirlo a partir de elementos reales, indexados de forma única, contiguos `output_item.done` cuyos campos sin procesar satisfacen las formas soportadas. Los deltas por sí solos no crean resultados. La evidencia malformada, contradictoria, duplicada, abierta o de gran tamaño mantiene el terminal vacío sin cambios; las respuestas fallidas e incompletas nunca se convierten en éxito.
+
+El marcador es una opción de compatibilidad seleccionada por el cliente, no una identidad autenticada o una concesión de permiso. Los clientes no identificados conservan su comportamiento existente. Esta reparación se ejecuta antes de la opción de proveedor separado `responsesSnapshotRepair` y no permite esa reparación de ciclo de vida más amplio. La búsqueda de herramientas, la herramienta personalizada, la función de finalización y el manejo de herramientas no declaradas mantienen su orden establecido.
+
+<a id="deepseek-and-claude-code-artifact"></a>
+
+### DeepSeek y la herramienta Artifact de Claude Code
+
+Para el endpoint oficial de Chat Completions de DeepSeek, OpenCodex flexibiliza las restricciones `anyOf` del esquema de la herramienta integrada `Artifact` de Claude Code para evitar errores HTTP 400 de validación de esquema. El modo estricto se omite para esa herramienta. Los campos definidos únicamente dentro de un `anyOf` dejan de estar limitados por esa unión; la herramienta debe validar sus entradas. Las demás herramientas y proveedores conservan su comportamiento.
+
+
+- **Mistral canónico.** Chat con clave en `https://api.mistral.ai/v1` mueve `max_completion_tokens` a `max_tokens` salvo valor no null explícito y omite `user`, `store`, `thinking`, `include_reasoning`, `reasoning`, `top_k` y el `reasoning_content` del historial que Mistral rechaza con 422. No vuelve a añadirlo. El preajuste une developer en system salvo `foldDeveloperRoleToSystem: false`. Aplica las escalas: medium no admitido pasa a low en DeepSeek/GLM; Large 4 conserva medium.
+- En SSE/JSON convierte arrays tipados de texto en `content` string y pensamiento en `reasoning_content`, sin mostrar `[object Object]`.
+- Los 4xx de esquema conservan solo nombres de campo y tipos de error reconocidos y acotados en registros, sin valores, mensajes libres ni ubicaciones desconocidas.
+
+Una clave Muse Code rechazada fuera de su cliente exige `meta-model` con pago por uso, no otro login; consulta [las reglas Meta](/es/guides/providers/). `thinkingDisplay` o su mapa por modelo pueden seleccionar `summarized` (`display: "summarized"`), `updates` u `omitted`; un resumen explícito sigue prevaleciendo, como explica [la configuración](/es/reference/configuration/providers/).
+
+En Vertex AI, Project ID y Location son opcionales. Sin clave se usa ADC del host del proxy, salvo `GOOGLE_CLOUD_API_KEY`, que prevalece. ADC también necesita proyecto y ubicación del formulario o `GOOGLE_CLOUD_PROJECT` / `GCLOUD_PROJECT` y `GOOGLE_CLOUD_LOCATION`. Añadir el proveedor o probar su catálogo estático no verifica credenciales ni permisos. Una clave sin proyecto usa express. Filas existentes sin `liveModels` mantienen descubrimiento genérico; `liveModels: false` usa catálogo estático.
+
+En Vertex y Antigravity, HTTP 400 o `INVALID_ARGUMENT`/firma dentro de 200 limpia el replay de firmas de esa conversación en memoria. Solo un error que nombra firma también expulsa las rechazadas del almacén persistente; no reintenta esa solicitud.
+
+- Gemini 4 Argon conserva el nivel de pensamiento al pedir resúmenes.
+
+Cursor puede diferir herramientas, incluida `exec`, mediante `GetDynamicTools`/`CallDynamicTool`; la guía de code mode usa `opencodex-responses` y el nombre listado sin recomendar un shell no expuesto. Una firma tardía recibe índice propio tras cerrar su elemento, sin duplicar texto o dejar herramientas abiertas; el replay solo la asocia a salida asistente adyacente y comprueba IDs si existen.
diff --git a/docs-site/src/content/docs/es/reference/architecture.md b/docs-site/src/content/docs/es/reference/architecture.md
new file mode 100644
index 00000000000..024bbcd71dc
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/architecture.md
@@ -0,0 +1,177 @@
+---
+title: "Arquitectura"
+description: "Mapa de módulos de opencodex, puente AdapterEvent, analizador de solicitudes y caché."
+---
+
+opencodex se ejecuta en un único proceso Bun. Una solicitud llega como OpenAI Responses, se normaliza al modelo interno, se enruta y se envía al proveedor mediante un adaptador. La respuesta vuelve a convertirse en Responses SSE. Consulta [Cómo funciona](/es/getting-started/how-it-works/) para conocer el flujo completo.
+
+<a id="module-map"></a>
+
+## Mapa de módulos
+
+```
+src/
+├── cli/                # ocx command dispatch, init, status, provider commands
+├── server/             # Bun.serve, /v1/* proxy, /api/* management API, WS bridge
+├── codex/              # Codex config injection, catalog sync, auth/account integration
+├── providers/          # provider metadata, API-key pool, quota and labels
+├── adapters/           # wire adapters, shared guards/utilities, Cursor protobuf transport
+├── oauth/              # OAuth providers, API-key catalog, token store/refresh
+├── usage/              # request usage extraction, JSONL logs, summaries, totals
+├── lib/                # runtime, process, retry, privacy, token estimate helpers
+├── web-search/         # web-search sidecar (synthetic tool, loop, executor, parser)
+├── vision/             # vision sidecar (describe + plan)
+├── config.ts           # ~/.opencodex/config.json, defaults, PID, env resolution
+├── router.ts           # model id → provider + adapter
+├── bridge.ts           # facade over bridge/
+├── bridge/             # AdapterEvent stream → Responses SSE (sse.ts) / JSON (response-json.ts)
+├── reasoning-effort.ts # reasoning-effort translation, clamping, and catalog levels
+├── responses/
+│   ├── parser.ts       # Responses request → OcxParsedRequest
+│   ├── schema.ts       # Zod validation
+│   └── compaction.ts   # remote compaction prompts, envelopes, compact history
+├── service.ts          # launchd / systemd / Task Scheduler background service
+├── types.ts            # core interfaces + helpers (modelInList, namespacedToolName)
+└── index.ts            # public entry
+```
+
+Varios archivos de entrada que antes eran grandes conservan ahora la compatibilidad como fachadas: `codex/catalog.ts` exporta sus módulos especializados `codex/catalog/*.ts`; `server/management-api.ts` delega en `server/management/*.ts`; `server/responses.ts` exporta `server/responses/*.ts`; y `bridge.ts` reexporta `bridge/*.ts`. La fachada mantiene estable la ruta de importación, mientras la implementación reside en esos módulos. Los pasos siguientes indican el módulo responsable; `structure/transports/responses.md` contiene el inventario completo de responsables de la interfaz Responses.
+
+<a id="request-flow"></a>
+
+## Flujo de solicitudes
+
+`server/index/serve-options.ts` posee el límite HTTP y delega el plano de datos Responses a la fachada `server/responses.ts` y sus módulos `server/responses/*.ts`:
+
+1. `server/index/serve-options.ts` aplica CORS y la autenticación de API, registra los metadatos del ciclo de vida y rechaza trabajo nuevo durante el drenaje con HTTP 503, JSON `error.code: "server_restarting"` y `Retry-After: 5`. La respuesta usa la política CORS del servidor receptor. Atiende `GET /v1/models`, `POST /v1/responses`, `POST /v1/responses/compact` y `POST /v1/images/generations` / `POST /v1/images/edits` (reenviados por `server/images.ts` a un proveedor de la familia OpenAI para la herramienta integrada `image_gen` de Codex). `POST /v1/live` y `POST /v1/realtime/calls` (voz de ChatGPT / Codex App y creación de llamadas de OpenAI Realtime, retransmitidas por `server/live.ts`), las conexiones WebSocket de banda lateral en `/v1/live/{callId}` (y `/v1/realtime?call_id=`), y la actualización opcional a WebSocket en `/v1/responses`.
+2. `server/responses/request-prepare.ts` descomprime y analiza JSON, expande la entrada de `previous_response_id` recordada localmente, si existe, y llama a `responses/parser.ts`.
+3. `router.ts` resuelve un identificador sin prefijo o `provider/model`. El servidor resuelve la afinidad de cuenta de Codex, actualiza OAuth cuando es necesario y aplica la credencial elegida.
+4. Antes de la llamada principal, `vision/` describe las imágenes de los modelos incluidos en `noVisionModels`. Si no existe una ruta sidecar segura, se eliminan las imágenes en lugar de enviarlas a un proveedor de texto.
+5. `server/adapter-resolve.ts` aplica las opciones de protocolo por modelo y construye el adaptador. Responses reenvía el cuerpo nativo; Cursor usa su transporte bidireccional `runTurn`; los adaptadores traducidos construyen, envían y analizan la solicitud.
+6. En modelos enrutados que solicitan la herramienta alojada `web_search`, `web-search/` expone una función sintética, ejecuta la búsqueda real mediante el backend configurado (el sidecar de OpenAI/ChatGPT o Anthropic), devuelve los resultados al modelo y repite hasta el límite configurado. Los adaptadores HTTP ordinarios usan el bucle basado en fetch. Los que implementan `runTurn`, incluido Cursor, usan el bucle independiente `runTurnWebSearchLoop` de `server/responses/run-turn-execution.ts` cuando el plan de búsqueda cumple los requisitos.
+7. `bridge/sse.ts` / `bridge/response-json.ts` generan Responses SSE o JSON. `server/request-log.ts` y `usage/` recogen estado terminal, latencia, etiquetas de proveedor y modelo y el uso de tokens disponible sin modificar la respuesta.
+
+La estimación de entrada previa al envío sigue lo que realmente envía el adaptador enrutado. Para los modelos `openai-chat` excluidos por la política efectiva de repetición de pensamiento de chat (una lista explícita `preserveReasoningContentModels`, o detección DeepSeek Flash/Pro cuando no está configurado), el adaptador elimina el pensamiento de asistente repetido, por lo que la estimación también lo excluye; el historial que nunca llega al proveedor, por lo tanto, no puede causar un rechazo de límite de contexto local. Los modelos que preservan el razonamiento, y otros adaptadores, envían ese pensamiento y aún lo cuentan.
+
+<a id="the-parser"></a>
+
+## El analizador
+
+`responses/parser.ts` valida la solicitud entrante con `responses/schema.ts` (Zod), luego construye un `OcxParsedRequest`:
+
+- **Mensajes**: los elementos de `input` se normalizan como `OcxMessage[]`, con mensajes de usuario, desarrollador, asistente o resultados de herramientas (toolResult). Los elementos `reasoning` se convierten en bloques de pensamiento; `function_call`, `custom_tool_call` y `tool_search_call`, en llamadas a herramientas; y sus correspondientes elementos `*_output`, en resultados de herramientas.
+- **Herramientas**: las herramientas de función se conservan. Las herramientas con espacio de nombres (MCP) se aplanan como `namespace__name` y recuperan su espacio de nombres al devolver la respuesta. Se marcan las herramientas de formato libre (como `apply_patch`) y las de descubrimiento **tool_search**. Las herramientas alojadas (`web_search`, generación de imágenes, etc.) se eliminan del conjunto enviado al adaptador y un sidecar solo las vuelve a incorporar si va a ejecutarlas.
+- **Imágenes**: se conservan como partes de contenido reales (URL de datos o URL HTTPS remota), sin convertirlas en texto.
+- **Indicadores de funciones**: `_webSearch` indica una búsqueda web alojada solicitada; `_structuredOutput`, que `text.format` es json_schema o json_object; y `_compactionRequest`, una compactación remota v2.
+
+<a id="the-bridge"></a>
+
+## El puente
+
+`bridge/sse.ts` convierte el flujo interno `AdapterEvent` del adaptador en Responses SSE que Codex entiende:
+
+| AdapterEvent | Responses SSE emitido |
+| --- | --- |
+| `text_delta` | `response.output_text.delta` → `…done`, `response.content_part.done`, `response.output_item.done` |
+| `thinking_delta` | `response.reasoning_summary_text.delta` → `…done`, cierre del elemento |
+| `reasoning_raw_delta` | Un elemento `reasoning_text` sin procesar, o una envolvente oculta para conservarlo al reenviarlo |
+| `thinking_signature` / `redacted_thinking` | Conservado en un sobre de razonamiento `encrypted_content` |
+| `tool_call_start` | `response.output_item.added` (tipo: `function_call` / `custom_tool_call` / `tool_search_call` ) |
+| `tool_call_delta` | `response.function_call_arguments.delta` (omitido para forma libre / tool_search) |
+| `tool_call_end` | `response.function_call_arguments.done` → `response.output_item.done` |
+| `web_search_call_begin` / `web_search_call_end` | Un elemento activo `web_search_call` y citas de URL |
+| `heartbeat` | Señala actividad del proveedor, sin generar un elemento visible para el usuario |
+| `done` | `response.completed` (con uso) |
+| `error` | `response.failed` (con `last_error`) |
+
+El puente también envía un **latido para mantener la conexión activa** (RC3). Durante el silencio del proveedor, emite el comentario SSE `: opencodex heartbeat` cada 2 segundos para reiniciar el temporizador de inactividad de Codex. Los analizadores de eventos descartan estos comentarios sin generar eventos, por lo que los decodificadores estrictos de Responses no reciben variantes desconocidas. El **tiempo de espera por inactividad** predeterminado es de 300 segundos para un proveedor público y está desactivado para uno local (`stallTimeoutSec`; `0` lo desactiva en todos los casos). Al agotarse, se cancela el flujo del proveedor y se emite `response.incomplete` con la razón `upstream_stall_timeout`, para que una conexión bloqueada no detenga Codex indefinidamente.
+
+El mapa de espacios de nombres y los conjuntos de herramientas de formato libre y de búsqueda que registra el analizador permiten distinguir tres tipos de elementos Responses. Así se conservan al enviar y recibir los espacios de nombres MCP, las herramientas de formato libre como `apply_patch` y las llamadas `tool_search` ejecutadas por el cliente. `buildResponseJSON()` genera una única respuesta sin streaming a partir de los mismos eventos.
+
+<a id="management-api-oauth-and-usage"></a>
+
+## API de administración, OAuth y uso
+
+`server/management-api.ts` sirve al panel y delega los grupos de rutas en
+`server/management/*.ts`. Sus rutas `/api/*` cubren la configuración y los ajustes
+filtrados, la gestión de proveedores y grupos de claves, la selección de modelos,
+los límites de contexto y los controles v2, la sincronización del catálogo, los
+diagnósticos y registros de depuración, el uso y las cuotas, los sidecars, las
+actualizaciones, las claves API de cliente generadas, OAuth, la selección y gestión
+de cuentas Codex y la parada ordenada.
+
+El acceso de administración a `/api/*` utiliza la credencial independiente
+`OPENCODEX_ADMIN_AUTH_TOKEN` o el token administrativo generado; el panel utiliza
+sesiones de administración. La admisión de modelos en `/v1/*` usa credenciales del
+plano de datos, como `OPENCODEX_API_AUTH_TOKEN` o las claves API de cliente
+configuradas. `server/auth-cors.ts` exige una credencial de datos al escuchar fuera
+de loopback. Un token de modelos no concede acceso administrativo.
+Las entradas de `corsAllowOrigins` amplían la lista de orígenes locales permitidos.
+
+Las implementaciones OAuth están en `oauth/`. Los tokens de acceso se cargan o renuevan inmediatamente antes de una llamada enrutada. `oauth/token-guardian.ts` puede renovarlos de forma anticipada únicamente en los proveedores cuya política lo permita. La renovación coordina una sola operación en curso por proceso, un bloqueo de archivo por cuenta y una comparación e intercambio (CAS) de generación, para impedir que escrituras simultáneas sobrescriban una credencial más reciente.
+
+La proyección compartida de estado (`oauth/health.ts`) alimenta `ocx status`, `ocx doctor`, la API de administración y el dashboard. Las credenciales del grupo Codex/ChatGPT y la afinidad de los hilos con las cuentas se gestionan en `codex/` y no se incluyen en las respuestas administrativas. La afinidad es local al proceso: se elimina ante `401`, `403` o `429`, sin mantener una cuenta fijada tras un límite de solicitudes, y no se conserva al reiniciar.
+
+El uso de cada solicitud se normaliza como `OcxUsage`, se incluye en los eventos finales de Responses y se agrega mediante `usage/` para el dashboard y los diagnósticos JSONL opcionales.
+
+<a id="transport-and-compaction"></a>
+
+## Transporte y compactación
+
+`server/index/serve-options.ts` sirve HTTP / SSE en `/v1/responses` por defecto. Si Codex intenta una actualización Responses WebSocket mientras que `websockets` es `false`, opencodex devuelve `426 upgrade_required`; Codex luego vuelve a HTTP para esa sesión. Cuando se establece `"websockets": true`, el mismo punto final acepta la actualización y utiliza el puente WebSocket.
+
+Independientemente de esa opción del cliente, las solicitudes canónicas de reenvío a ChatGPT con `stream: true` en la raíz pueden usar el transporte WebSocket de Codex hacia el proveedor en Bun estable 1.4.0 o posterior. Esa ruta conserva la intención de HTTP Responses Lite en los metadatos de la trama WS y calcula la indicación de enrutamiento a partir del modelo y el nivel de servicio que realmente envía. Los metadatos iniciales de cuota y modelo se convierten en encabezados HTTP de respuesta acotados. Las actualizaciones posteriores de cuota se atribuyen a la cuenta que atendió la solicitud, sin añadirlas a encabezados ya enviados. Un fallo posterior al envío WS no provoca un reenvío automático por HTTP. Estas reglas no habilitan la opción WebSocket del cliente ni cambian el transporte de otros proveedores.
+
+El paquete actual incluye Bun **1.4.4**. Los paquetes anteriores, como Bun 1.3.14, las versiones preliminares y los entornos cuya identidad no se puede verificar usan HTTP/SSE en lugar de esa optimización WS hacia el proveedor. Las respuestas WS correctas conservan el contrato SSE hacia el cliente y evitan `tee()` mediante un relé acotado que lee anticipadamente con un solo lector: 4 MiB por trama, sin procesar o encapsulada, y una cola de producción de 8 MiB. Si la cola se desborda, se cierra la conexión con el proveedor y se envían al cliente un evento final `response.failed` y `[DONE]`.
+
+Para el modelo saliente final `gpt-5.3-codex-spark`, el reenvío canónico ChatGPT desactiva explícitamente Responses Lite tanto en la cabecera HTTP como en los metadatos de trama WS nativos, incluso cuando un alias selecciona Spark, pero solo cuando el cuerpo saliente no lleva ningún elemento `additional_tools` con una matriz `tools` no vacía. Ese grupo ES la forma de entrega de herramientas Lite, por lo que un cuerpo de Spark que todavía lo usa mantiene Lite ON incluso si un llamante o un encabezado configurado dijeron lo contrario; de lo contrario, el marco anunciaría que no es Lite mientras que las herramientas existen solo en la forma Lite. Una identidad Lite cambiada retira el socket anterior; las solicitudes elegibles posteriores con la misma identidad pueden reutilizar el socket nuevo. Otros modelos y puertas de enlace mantienen su política Lite existente. Los metadatos nativos mal formados todavía caen de nuevo a HTTP con su cuerpo sin cambios.
+
+Cuando un proveedor rechaza una solicitud de flujo continuo con HTTP 413 antes de que comience SSE, OpenCodex emite un evento de terminal `response.failed` con `context_length_exceeded` en lugar de retransmitir el estado desconocido reintentable. Esto permite que Codex detenga su bucle de reconexión y aplique su propia política de compresión de contexto en el siguiente turno. OpenCodex no elimina silenciosamente mensajes o imágenes; reduzca la entrada actual o reintente después de la compactación. Las llamadas a la API sin streaming siguen recibiendo el HTTP 413 del proveedor.
+
+La compactación de contexto de Codex funciona con modelos enrutados. `server/responses/compact.ts` atiende `POST /v1/responses/compact` mediante un turno interno de resumen enrutado y devuelve el historial compactado. Por su parte, `responses/parser.ts` y `bridge/sse.ts` atienden los turnos `compaction_trigger` de compactación remota v2 y emiten exactamente un elemento sintético de salida `compaction`.
+
+<a id="caching--the-catalog"></a>
+
+## El almacenamiento en caché y el catálogo
+
+- `codex/model-cache.ts` mantiene en memoria una caché por proveedor con TTL de los resultados de `/models`: 5 minutos de forma predeterminada, como la de Codex. Si la consulta falla, puede usar los resultados anteriores aunque hayan caducado.
+- `codex/catalog/sync.ts`, exportado mediante la fachada `codex/catalog.ts`, incorpora los modelos enrutados al catálogo de Codex con sus espacios de nombres. Ordena primero los [modelos de subagentes](/es/guides/codex-integration/#the-subagent-picker) destacados, filtra `disabledModels` y permite restaurar el catálogo original desde una copia de seguridad creada una sola vez.
+
+<a id="reasoning-effort"></a>
+
+## Esfuerzo de razonamiento
+
+`reasoning-effort.ts` traduce las etiquetas de esfuerzo de razonamiento de Codex a los valores enviados a cada proveedor. El catálogo anuncia etiquetas admitidas por Codex (`low` / `medium` / `high` / `xhigh` / `max`), pero el proveedor puede admitir solo algunas o necesitar un alias específico. El módulo:
+
+- Define los niveles canónicos `CODEX_REASONING_LEVELS` y su orden.
+- Ajusta el esfuerzo solicitado al nivel compatible más cercano si el nivel exacto no está disponible.
+- Resuelve las opciones `reasoningEffortMap` por modelo y proveedor para personalizar los valores del protocolo.
+- Omite por completo el esfuerzo en los modelos incluidos en `noReasoningModels`.
+
+Qwen3.8-Max constituye una excepción de esfuerzo directo frente al contrato anterior de presupuesto de Qwen3.x. Alibaba Token Plan declara los niveles `low`, `medium` y `xhigh` (predeterminado), y envía el valor efectivo como `reasoning_effort`. Solo los niveles superiores añadidos por compatibilidad con Codex se limitan a `xhigh` al enviarlos al proveedor. El enriquecimiento del registro durante la ejecución corrige los metadatos guardados de versiones anteriores que aún clasifican el modelo como `thinking_budget`.
+
+<a id="core-types"></a>
+
+## Tipos principales
+
+El modelo interno se define en `types.ts`: `OcxParsedRequest`, `OcxContext`, la unión `OcxMessage`, `OcxContentPart` (texto o imagen), `OcxToolCall`, `OcxTool`, `AdapterEvent` y los tipos de configuración `OcxConfig` y `OcxProviderConfig`. Se usan ampliamente las funciones auxiliares `namespacedToolName()` y `modelInList()`; esta última compara modelos en `noVisionModels` y `noReasoningModels` tolerando las etiquetas `:size`.
+
+
+<a id="incomplete-quota-terminals"></a>
+
+### Terminales de cuota incompletos
+
+Una respuesta nativa reenviada que termina en `incomplete` con evidencia de cuota o límite de solicitudes registra el fallo de cuota de la cuenta y actualiza el estado usado por el fallback de subagentes. Se aceptan `incomplete_details.reason` y códigos de error estructurados aunque no haya un mensaje. Las respuestas incompletas por límite de salida, filtrado, control del turno o falta de progreso no ponen la cuenta en enfriamiento. La clasificación de políticas de ciberseguridad conserva su precedencia. Después de emitir salida no se repite el turno; las solicitudes fijadas a una cuenta conservan esa selección.
+
+Las solicitudes compactas remotas pueden almacenar su respuesta en búfer durante más tiempo que el tiempo de espera inactivo de la solicitud del servidor. Ese tiempo de espera del oyente se deshabilita después de que se acepte el cuerpo de la solicitud; aún se aplican los plazos de cancelación del cliente y de operación ascendente.
+
+La compactación enrutada con respuesta en búfer considera progreso los deltas no vacíos de texto y razonamiento, sin exponer un resumen parcial. Los comentarios, deltas vacíos y keepalives de la pasarela no reinician el detector de falta de progreso del adaptador. El plazo predeterminado sigue siendo de 300 segundos y el contenido cifrado de compactación se conserva intacto.
+
+El almacenamiento en búfer de una respuesta de compactación nativa también limita el tiempo sin recibir bytes del cuerpo mediante `stallTimeoutSec`. A diferencia del streaming, esta ruta conserva su valor predeterminado de 300 segundos incluso con un proveedor local, porque almacena el cuerpo completo mientras mantiene una reserva de turno activo; un valor explícito, incluido `0`, sigue teniendo prioridad. Los fragmentos no vacíos reinician el plazo. Un cuerpo detenido produce HTTP 504; la cancelación del cliente conserva HTTP 499. La limpieza no espera indefinidamente una promesa de cancelación del proveedor. Se mantienen el máximo de respuesta de 32 MiB y los bytes originales del cuerpo.
+
+Un error canónico de creación rechazada WebSocket aguas arriba puede convertirse en un HTTP 4xx solo antes de que se confirme la respuesta y después de las comprobaciones de correlación de flujo. Las cabeceras de cuota permitidas se acotan y reconstruyen sin cabeceras de entramado ascendentes; la respuesta JSON no se puede almacenar en caché. Los errores posteriores al compromiso y 5xx mantienen la ruta sin reenvío.
+
+Si la recuperación de una tarea de agente cifrada rechaza una tarea enrutada, el error 400 existente puede incluir un `recovery_reason` de este conjunto: `unsupported_envelope`, `admission_denied`, `recovery_unavailable`, `caller_cancelled`, `input_changed`, `recovery_http_rejected`, `recovery_timeout`, `recovery_aborted`, `recovery_transport_error` o `recovery_invalid_output`. El rechazo HTTP requiere haber observado una respuesta sin éxito. Una salida inválida incluye UTF-8 incorrecto, cuerpos demasiado grandes, streams mal formados o incompletos y asignaciones inválidas o contradictorias. La cancelación del cliente tiene prioridad sobre el plazo propio de la operación; este tiene prioridad sobre los fallos de decodificación o transporte. `recovery_aborted` indica que se canceló una recuperación compartida por una causa independiente de ese cliente. Los clientes que esperan la misma operación reciben el mismo fallo, salvo que se cancelen individualmente. Solo se guarda en caché el texto plano recuperado correctamente. Los diagnósticos no contienen errores originales del proveedor ni texto de la carga útil. Si no hay un resultado clasificado, se omite el campo. Las ramas de combo que devuelven el error original del destino conservan esa respuesta. `recovery_unavailable` también incluye la falta de capacidad de caché o de operaciones compartidas; no demuestra que se haya intentado consultar al proveedor. Esto no habilita reintentos ni admite nuevos formatos de envoltorio.
+
+
+El guard de inactividad del cuerpo del adaptador es distinto del timeout general: si se detiene un cuerpo inicial, de recuperación, continuación terminal o reintento vacío en streaming Responses traducido, termina con response.failed, upstream_stall_timeout y duración acotada; el registro lo clasifica 504 y puede incluir `body_stall`, sin cambiar los encabezados HTTP ya enviados. Sin streaming devuelve HTTP 504 con el mismo mensaje. La clasificación no modifica los envíos físicos ni el uso medido.
diff --git a/docs-site/src/content/docs/es/reference/cli.md b/docs-site/src/content/docs/es/reference/cli.md
new file mode 100644
index 00000000000..47473349363
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/cli.md
@@ -0,0 +1,237 @@
+---
+title: "Referencia de CLI"
+description: "Despacho de comandos, códigos de salida y enlaces a cada familia de comandos ocx."
+---
+
+La CLI de opencodex es `ocx`. El primer nombre determina qué comando se ejecuta. Los alias documentados `setup`/`init`, `restore`/`eject` y `models`/`model` realizan la misma operación. Los comandos desconocidos y las sintaxis no válidas producen errores.
+
+Ejecuta `ocx`, `ocx help`, `ocx --help` o `ocx -h` para ver el mismo índice compacto, agrupado en primeros pasos, tareas comunes, exploración y ayuda adicional. Usa `ocx help --all` o `ocx --help --all` para la referencia completa, incluidas las variantes omitidas del índice. Para un comando registrado en la tabla de ayuda, usa `ocx help <command>`, `ocx <command> --help` o `ocx <command> -h`; también se admite `ocx <command> help`. La ayuda y la versión son de solo lectura: no inician, detienen, instalan, desinstalan ni reescriben el estado de Codex u opencodex.
+
+<a id="nested-help"></a>
+
+## Ayuda anidada
+
+La ayuda de una familia, como `ocx help models`, conserva su sintaxis y sus detalles y enumera los subcomandos declarados con sus resúmenes. La lista describe los subcomandos registrados y no garantiza una cobertura exhaustiva de los disponibles durante la ejecución. La ayuda de un alias conserva su sintaxis y sus detalles y enlaza con la familia canónica: `ocx help model` conduce a `ocx help models`. La ayuda de modelos también enlaza el tema específico `models context`, aparte de las capacidades declaradas.
+
+La ayuda acepta rutas con varios nombres de comando:
+
+```bash
+ocx help models context
+ocx models context --help
+ocx model context --help
+ocx help account list
+ocx help account main
+```
+
+Las tres primeras formas muestran el mismo tema de límites de contexto, incluido el alias `model`:
+
+```text
+ocx models context <status|value <tokens> [--set-all]|provider <name> on [--value <tokens>]|provider <name> off|all <on|off>> [--json]
+```
+
+`ocx models context status --json` lee los ajustes actuales. `value <tokens>` fija el valor predeterminado para las futuras activaciones; `--set-all` también lo aplica a todos los proveedores enrutados. `provider <name> on` habilita el límite de un proveedor y permite indicar `--value <tokens>`; `off` lo desactiva. `all on|off` cambia todos los proveedores enrutados a la vez.
+
+Los temas de capacidades declaradas, como `account list`, muestran su resumen, opciones conocidas y detalles, con un enlace a la ayuda superior. Esos metadatos no cubren todos los argumentos ni subcomandos disponibles, por lo que un tema puede mostrar `Command: ocx ...` sin prometer una gramática `Usage:` completa. Un prefijo como `account main` enumera sus subcomandos declarados e indica que la cobertura es incompleta. Un tema explícito no declarado (`ocx help <path>`) termina con código 1 y escribe en stderr un mensaje breve de ayuda no disponible junto con una referencia a la familia conocida o a la ayuda completa. stdout queda vacío y no se imprime toda la ayuda. La falta de detalles no determina si el comando existe. Añadir `--help` o `-h` conserva el comportamiento anterior: si faltan metadatos detallados, se muestra correctamente la ayuda superior conocida sin ejecutar el comando.
+
+El despachador inicial de la CLI Bun reconoce `help` sin opciones solo en la raíz o inmediatamente después del comando raíz. Usa `--help` o `-h` en rutas anidadas. Los valores posteriores, como `help` en `ocx alias set demo help`, siguen siendo argumentos del comando. Un `--` exacto termina la búsqueda inicial de opciones de ayuda; por eso `ocx claude -- --help` conserva los argumentos para enviarlos al comando.
+`ocx alias set demo help` Siguen siendo argumentos de comando. Un exacto `--` termina la ayuda de la cabeza que explora, así que `ocx claude -- --help` conserva los argumentos para el despacho de comandos.
+
+<a id="recovering-from-command-typos"></a>
+
+## Recuperación de errores tipográficos de comando
+
+Los comandos raíz desconocidos y las rutas explícitas de ayuda no resueltas terminan con código 1, muestran un diagnóstico breve y orientación en stderr y dejan stdout vacío. Para errores tipográficos cercanos pueden sugerir nombres de comandos visibles o subcomandos documentados de la familia actual. Son sugerencias informativas: la CLI nunca las ejecuta ni reintenta el comando.
+
+| Entrada | Orientación |
+| --- | --- |
+| `ocx modles` o `ocx help modles` | Sugiere `ocx help models`. |
+| `ocx help account lisst` | Sugiere `ocx help account list` dentro de la familia de cuentas. |
+| `ocx help qzxv` | Ofrece `ocx help --all` sin adivinar un comando. |
+| `ocx help models qzxv` | Indica que la ayuda detallada no está disponible y remite a la familia de comandos de modelos conocida. |
+
+La CLI Bun rechaza una raíz desconocida antes de restaurar automáticamente el shim o ejecutar otras comprobaciones previas. Los comandos reconocidos conservan sus comprobaciones. Los comandos ocultos y el ejecutor interno siguen siendo destinos válidos, pero no aparecen en el descubrimiento ni en las sugerencias. Se conservan la ayuda alternativa al añadir una opción, las capacidades JSON y los errores específicos de proveedor.
+
+<a id="command-families"></a>
+
+## Familias de comandos
+
+### `ocx message`
+
+`ocx message sessions [--json]` descubre las sesiones locales de Codex cargadas y devuelve sus identificadores, nombres y estados de ejecución. `--thread` exige un UUID exacto; `--name`, un único nombre exacto. Los destinos inexistentes, duplicados, incompletos o no cargados producen un error. `ocx message send (--thread <uuid> | --name <exact-name>) --stdin [--json]` envía un mensaje de par correlacionado sin iniciar un daemon ni reanudar un hilo. Sin `--host`, estas operaciones son locales. Consulta [Mensajería de Codex](/es/reference/cli/messaging/) para conocer el contexto del remitente, los tipos, el entorno probado y los recibos `not_sent` / `queued` / `unknown`. El [transporte remoto mediante SSH](/es/reference/cli/messaging/#explicit-remote-peers) requiere un host registrado y `--host`; no inicia automáticamente el receptor ni reenvía mensajes de forma automática.
+
+### `ocx provider`
+
+`ocx provider`, `ocx help provider`, `ocx provider help`, `ocx provider --help` y `ocx provider -h` muestran la misma ayuda: sintaxis, ejemplos, orientación sobre proveedores predefinidos o personalizados y enlaces a los temas declarados. La ayuda correcta se imprime en stdout y termina con código 0. Ejecutar solo `ocx provider` conserva las comprobaciones previas normales; las formas explícitas de ayuda inicial terminan antes de ellas. Una acción desconocida escribe el diagnóstico y la ayuda en stderr, deja stdout vacío y termina con código 1.
+
+### `ocx alias`
+
+`ocx alias list [--json]` muestra alias de usuario efectivos e integrados. Utilice `ocx alias set <provider>[/<native-model-id>] <alias>` y `ocx alias rm <provider>[/<native-model-id>]` para editarlos. Los identificadores de modelo nativos pueden contener barras adicionales porque el selector se divide solo en la primera barra. Habilite los valores predeterminados enviados con `ocx alias defaults on|off [--provider <name>]`.
+
+### `ocx remote-workspace`
+
+`ocx remote-workspace pair <hub-url> --pairing-code-stdin --root <absolute-path>` inscribe el equipo local como un Ejecutor solo OCX. Repita `--root` para aprobar más carpetas y utilizar `--name` para anular el nombre de host. Repita `--toolchain-root <absolute-directory>` para exponer un directorio de Node, Rust, Go u otra cadena de herramientas instalado por el usuario de solo lectura dentro del entorno de pruebas del comando. En las compilaciones internas de prueba para macOS y Windows, `bun run build:remote-workspace-helper` compila el helper de Rust que el comando de emparejamiento descubre automáticamente; `--executor-helper <absolute-file>` selecciona otra compilación revisada explícitamente y fija su resumen en el estado de Ejecutor local. `ocx remote-workspace agent` mantiene la conexión cifrada saliente; `ocx remote-workspace status [--json]` informa sobre el Hub, el dispositivo, las raíces y las capacidades anunciadas sin imprimir su portador o clave privada. Véase [Espacio de trabajo remoto](/es/guides/remote-workspace/).
+
+Familias de comandos adicionales:
+
+| Familia | Sintaxis y referencia |
+| --- | --- |
+| `ocx chatgpt` | `ocx chatgpt <launch\|restore\|status>`: shim experimental del app-server de macOS, desactivado de forma predeterminada. Consulta [ChatGPT Desktop](/es/guides/chatgpt-desktop/). |
+| `ocx hub` | `ocx hub invite [--json] [--data-url <origin>] [--management-url <origin>] [--clients codex,claude]`: crea un código secreto de emparejamiento de un solo uso en un Hub activo. Consulta [Remote Hub](/es/guides/remote-hub/). La invitación exige autorización explícita y su código no debe aparecer en la transcripción de un agente. |
+| `ocx inspect` | `ocx inspect <subcommand>`: lee la configuración efectiva, el catálogo, las trazas de enrutamiento, la cadencia, el inventario de claves, el prompt de Codex, la configuración de clientes, el estado de estrella o la bandeja de Windows. Ejecuta `ocx help inspect` para acceder a los temas. |
+| `ocx mcode` | `ocx mcode [mcode args...]`: inicia MiniMax Code después de habilitar su integración mediante archivos administrados. Consulta [Clientes MiniMax](/es/guides/minimax/). |
+| `ocx mmx` | `ocx mmx text <chat\|repl> [mmx args...]`: inicia los comandos de texto de MiniMax CLI mediante el proxy. Para las demás funciones, usa `mmx` directamente. Consulta [Clientes MiniMax](/es/guides/minimax/). |
+| `ocx zcode` | `ocx zcode [status\|enable\|disable\|history\|restore] [--json]`: administra la integración de ZCode. Consulta [Almacenes de ZCode](/es/guides/integrations/#zcode-314-and-later). |
+
+- [Ciclo de vida](/es/reference/cli/lifecycle/) - Configuración, proxy y ciclo de vida del servicio, estado, diagnóstico, sincronización del catálogo, el panel de control y actualizaciones.
+- [Proveedores, cuentas y modelos](/es/reference/cli/providers-accounts/) - configuración de proveedores, autenticación, grupos de credenciales, cuota, modelos personalizados, visibilidad, modelos seleccionados y límites de contexto.
+- [Agentes, enrutamiento e integraciones](/es/reference/cli/agents/) - controles multiagente, combos, observabilidad, claves de admisión, rutas de protocolo, integraciones de clientes, configuración en entorno de ejecución, configuración validada e inspección de actualización de solo lectura Codex CLI.
+
+<a id="headless-behavior"></a>
+
+## Uso sin interfaz gráfica
+
+Los comandos de administración se comunican con la API del proxy activo mediante el puerto registrado y las comprobaciones de identidad, sin mantener una segunda ruta de configuración. Si el proxy está detenido o no es accesible, devuelven HTTP 503 y la CLI termina con un código distinto de cero. Los comandos documentados expresamente como operaciones sin conexión pueden validar y editar el archivo de configuración sin un proxy activo.
+
+`ocx system codex-cli-update check` no necesita proxy en vivo y no hace ninguna solicitud de registro de paquetes. Inspecciona los metadatos de procedencia limitada para el candidato de instalación configurado, incluida su ubicación ejecutable redactada y la evidencia de propiedad. El contexto del lanzador publicado de confianza autentica esa instantánea candidata, no una ejecución exitosa de Codex. En POSIX, `selectionAttested` puede ser `true` cuando el solucionador en entorno de ejecución selecciona el mismo candidato de entorno canónico sin ejecutarlo. Un manifiesto de paquete global vinculado npm puede establecer `managed: true` cuando prueba la propiedad y, si se informa de una versión candidata, esa versión coincide con el manifiesto; los candidatos persistentes permanecen sin certificar. El informe JSON expone `candidateAvailable`, `candidateVersion`, `candidateSource` y `selectionAttested`. Inspeccionar el candidato configurado requiere un contexto confiable del lanzador publicado; un arranque directo desde Bun o el código fuente carece de esa prueba, ignora el estado ambiental y persistido y puede informar `candidate_unavailable` en POSIX o `windows_inspection_deferred` en Windows. Windows x64 también admite un `codex.cmd` npm estándar con ruta absoluta capturada por la prueba, una pareja Node/npm vinculada a identificadores abiertos —local al prefijo si existe, o la pareja capturada en PATH anclada a la arquitectura del lanzador— y un binario de plataforma verificado dentro del prefijo. Usa identificadores abiertos que rechazan puntos de reanálisis; otras estructuras Windows siguen aplazadas o no administradas. Un resultado Windows `managed` solo clasifica la instalación observada: Node/npm sirve para leer metadatos del actualizador, sin afirmar qué intérprete resolverá una ejecución posterior de `codex.cmd`. La inspección y la planificación siguen siendo de solo lectura; la aplicabilidad y la aplicación confirmada se deciden por separado. El comando no instala ni repara software, ejecuta Codex o npm, controla procesos ni escribe configuración o caché.
+
+`ocx system codex-cli-update plan --json` agrega una decisión de actualización de solo lectura para una instalación POSIX npm-global atestada. Resuelve `latest` mediante el registro oficial npm, valida la versión exacta y la integridad SHA-512 y rechaza sesiones activas u observación incompleta de procesos. Las consultas usan configuración, caché y registros npm temporales aislados con limpieza de mejor esfuerzo. No instala software ni envía señales. La aplicación Windows x64 exige un prefijo npm acotado con autoridad privada de escritura verificada y conserva paquetes y shims ajenos; las estructuras no admitidas devuelven `applicable: false` y `refusal: windows_apply_disabled`. La selección solo por PATH y los wrappers de inicio automático de OpenCodex siguen aplazados. La planificación Windows también exige autoridad de escritura confiable sobre todo el árbol npm y los directorios de búsqueda de módulos. La aplicación bloquea cambios de selección e inicios de sesiones propias hasta que el instalador termine y se verifique el resultado; una vida de proceso desconocida mantiene el bloqueo. El Node seleccionado debe admitir hooks de módulos síncronos; npm no puede cargar dependencias fuera de su árbol verificado. Consulta los [detalles de planificación](/es/reference/cli/agents/#read-only-codex-cli-update-plan).
+
+Para un plan npm-global revisado y aplicable, `ocx system codex-cli-update apply --plan-id <id> --yes` realiza la actualización exacta y devuelve un trabajo persistente. `ocx system codex-cli-update status <job-id> --json` consulta su resultado. Usa un `--request-id` estable si se pierde una respuesta. Consulta [la confirmación y los estados del trabajo](/es/reference/cli/agents/#confirmed-codex-cli-apply-and-job-status).
+
+Para la observación de la instalación de Windows x64, véase [El comando `attest`](/es/reference/cli/agents/#explicit-installation-observation-on-windows-x64). Sin rutas explícitas, observa el candidato seleccionado identificado a partir de la instantánea del lanzador de prueba; no otorga autoridad de actualización ni certifica la selección en entorno de ejecución.
+
+Cuando no hay ambigüedad, se muestra la lista o el estado de forma predeterminada. Usa `--json` solo en los subcomandos que lo admiten. `ocx observe logs --follow --jsonl` muestra filas actualizadas; `ocx logs --follow --events`, instantáneas e incorporaciones versionadas de la ventana observada. Ninguna modalidad garantiza un historial sin pérdidas: consulta los [límites de cursores, reinicios y datos incompletos](/es/reference/cli/agents/#follow-request-windows-or-injection-sequences). Las [comprobaciones de modelos y audio con una clave seleccionada](/es/reference/cli/agents/#explicit-key-model-and-audio-checks) requieren operaciones con el proveedor autorizadas por el operador y la entrega privada de datos por stdin. Sus informes son observaciones, no certificados del alcance de la clave. El tema, el idioma, la navegación y otros estados puramente visuales del navegador no tienen equivalente CLI; configurar Cloudflare Tunnel queda fuera de estos comandos.
+
+Para consultar información como en el dashboard, usa [la selección acotada de registros, la búsqueda de modelos en uso y los totales guardados de companion](/es/reference/cli/agents/#filter-a-bounded-log-snapshot). `logs filter` distingue la ventana examinada de las coincidencias devueltas; `usage --search` cambia las filas de modelos sin recalcular los totales del informe; `companion usage` conserva la disponibilidad de cada rango y los ajustes alternativos. La [consulta de cuota del grupo de claves API](/es/reference/cli/providers-accounts/#accounts-and-key-pools) con `account list --quota` es explícita y puede contactar a los proveedores.
+
+<a id="liveness-probe-ceiling-override"></a>
+
+## Ajustar el tiempo máximo de la sonda de actividad
+
+`ocx health`, `ocx status`, `ocx account *`, `ocx login codex` y `ocx ready` localizan el proxy activo mediante una sonda breve: 750 ms por intento de forma predeterminada y 1500 ms con reintentos para decidir la parada o el inicio. Si una capa de seguridad, como un filtro de contenido o una extensión de red de tipo EDR, añade un coste fijo a cada conexión de loopback, esos plazos pueden vencer antes de que responda un proxy saludable. Los comandos lo muestran entonces como detenido aunque `curl http://127.0.0.1:10100/healthz` funcione.
+
+Establece `OCX_PROBE_TIMEOUT_MS` para ampliar esos plazos, por ejemplo `OCX_PROBE_TIMEOUT_MS=5000 ocx status`. Se admiten milisegundos enteros de 1 a 30000. La opción solo aumenta los límites: conserva los mínimos de 750 ms y 1500 ms, de modo que `1000` amplía únicamente la sonda predeterminada. Los valores ausentes, vacíos, fraccionarios, negativos, cero o superiores al máximo se ignoran y se usan los plazos originales.
+
+En Windows, el proxy también eleva su propio proceso a la prioridad ABOVE_NORMAL cuando se inicia, lo que reduce los retrasos de programación en un host saturado por otro trabajo de prioridad NORMAL (exploraciones de antivirus, codificadores, emuladores) sin garantizar que la sonda permanezca bajo estos techos a carga extrema. El impulso se aplica solo al proceso proxy (el trabajo que genera aún se ejecuta en NORMAL) y un proxy con CPU pesada puede retrasar las aplicaciones con prioridad NORMAL. El cambio es de mejor esfuerzo; establece `OCX_DISABLE_PRIORITY_BOOST=1` en el entorno del proxy para dejar la prioridad sin cambios.
+
+<a id="exit-codes-and-confirmation"></a>
+
+## Códigos de salida y confirmación
+
+Los comandos exitosos terminan con código 0. Los argumentos no válidos, los comandos o recursos desconocidos, las operaciones de API fallidas y la falta de servicios necesarios producen un código distinto de cero. `ocx health` sale específicamente con 0 solo cuando el proxy está sano y con 1 cuando no se encuentra ningún proxy sano; los argumentos no válidos salen con 2, por lo que se puede usar como una sonda de servicio. Los scripts deben probar el código de salida en lugar de raspar la salida legible por humanos.
+
+Muchos comandos de administración comparten estas correspondencias; otras familias de la CLI conservan sus propios códigos:
+
+| Código | Causa |
+|---|---|
+| 0 | éxito |
+| 2 | rechazo de uso local en los controladores de gestión; también no compatible con `doctor --json` |
+| 64 | argumentos inválidos a `capabilities`, `ready` o `resolve`, antes de su descubrimiento / solicitud de trabajo |
+| 4 | HTTP 404 - la cuenta, el proveedor, la clave o la ruta con nombre no existe |
+| 5 | HTTP 409: conflicto, por un bloqueo ocupado o porque cambió el estado durante la operación |
+| 1 | todo lo demás, incluyendo fallos de transporte y otros errores HTTP |
+
+El código 0 significa que no se informó de ningún error. Las operaciones de vista previa, como `ocx storage cleanup` sin `--yes`, también terminan con 0 sin modificar nada. Un ajuste guardado puede incluir un resultado de aplicación omitido o incompleto: lee el recibo y las advertencias de stderr.
+
+Las operaciones de eliminación destructiva, importación, consumo de crédito y actualización que anuncian la confirmación requieren `--yes` en uso no interactivo. La bandera es un opt-in explícito; omitirla no debe confirmar silenciosamente la acción.
+
+`ocx storage cleanup` sin `--yes` solo muestra una vista previa: imprime lo que liberaría, no cambia nada y termina con código 0. Estas operaciones no ofrecen confirmación interactiva. Una pregunta que un agente puede responder automáticamente no establece un límite de consentimiento; la opción explícita es el requisito para aplicar la operación.
+
+<a id="driving-the-cli-from-an-agent"></a>
+
+## Usar la CLI desde un agente
+
+Descubra progresivamente, sin iniciar un proxy:
+
+```bash
+ocx help
+ocx help models
+ocx help models preset show
+```
+
+Lee el capítulo correspondiente en `skills/ocx/references/01_management_surface.md` o en las páginas públicas de familias de comandos anteriores. `ocx help --all` permite acceder a la referencia completa. El inventario amplio para lectura por máquinas es opcional:
+
+```bash
+ocx capabilities --json
+ocx capabilities --mutating-only --json
+ocx capabilities --route '/api/providers/{provider}/model-costs' --json
+```
+
+La búsqueda de ruta coincide con la plantilla declarada literal, no con los ID de proveedor concretos ni con un método HTTP. Un error sale con 4 y no prueba que un comando runtime esté ausente. Las declaraciones incluyen comandos locales, así como comandos de gestión; solo estos últimos necesitan un objetivo en vivo. Antes de las operaciones en vivo, ejecute `ocx ready --json` y `ocx status --json`, inspeccione el objetivo y `versionSkew.relation`, y resuelva el desajuste de versión. `unknown` no confirma las compilaciones coincidentes. La ayuda sin conexión, la configuración local y la inspección local del laboratorio no requieren el inicio.
+
+`ocx status --json` incluye `cliCommand`: la intención de escritorio configurada, el ejecutable esperado, candidatos de PATH observados, `pathFirst`, `desktopFirstOnPath`, códigos de problema y `shellResolution: "unobserved"`. El informe de estado humano imprime una línea de selección de comandos. `ocx doctor` añade una sección de "selección de comandos ocx": los registros no válidos, inseguros (`record-unsafe`) o habilitados pendientes y los objetivos de escritorio faltantes/inutilizables fallan la comprobación, mientras que los registros deshabilitados pendientes de limpieza, los conflictos de orden de PATH y los escaneos incompletos advierten. `OCX_NO_DESKTOP_HANDOFF=1` suprime el traspaso de paquete-lanzador para una invocación; deja la configuración de la shim de escritorio y de PATH en su lugar. Estas observaciones de solo lectura no ejecutan candidatos, resuelven alias/funciones de parent-shell ni identifican al propietario del entorno de ejecución del proxy. En Windows, el traspaso de paquete-lanzador está desactivado; el orden de `Path` del usuario selecciona `ocx.exe` de escritorio. `status` y `doctor` siguen leyendo el registro e informan del primer candidato de PATH. Se informa de un posible candidato de directorio actual cmd por separado del orden PATH.
+
+`ocx status --json` también incluye `install`: cómo se instaló este `ocx`, según el mismo detector que usa `ocx update`. `install.method` es `bun`, `npm`, `pnpm`, `mise`, `source`, `standalone` (el binario compilado de escritorio) o `unknown` si la detección falló. `install.evidence.basis` indica qué evidencia decidió el resultado (`package-layout`, `mise-backend-record`, `standalone-binary` o `unavailable`); una instalación mise añade el alias de la herramienta y el backend de mise, y un fallo añade un código `error`. No se añade ninguna ruta.
+
+Los indicadores de salida son por comando. `doctor` rechaza `--json` con el código de salida 2; [`v2` (referencia de la familia)](/es/reference/cli/agents/) soporta `--json` para objetivos locales y `--live`. Incluso para los comandos de gestión con capacidad JSON, los fallos API normalmente usan prosa stderr con líneas opcionales `reason:` y `hint:`, no una envolvente de error JSON. Mantenga separados stdout, stderr y el código de salida.
+
+La cobertura se determina por flujos de trabajo concretos, no por prefijos compartidos de rutas. Los ajustes de modelos, la visibilidad, los controles de cuentas y la lectura de perfiles de enrutamiento no implican que se puedan editar los nombres visibles de modelos descubiertos o escribir perfiles de enrutamiento. El consentimiento que exige una sesión y la presentación del navegador tienen límites independientes. Crear una clave de acceso o iniciar su rotación devuelve credenciales en texto plano: los agentes deben dejar esos pasos a una persona en una terminal fuera de la sesión y recibir solo identificadores no secretos y confirmaciones. Nunca pidas credenciales en el chat ni eludas una acción limitada a la sesión mediante otro cliente API.
+
+<a id="recent-behavior-changes"></a>
+
+## Cambios de comportamiento recientes
+
+Estas son correcciones a comandos que previamente informaron mal sus propios resultados:
+
+- `doctor` y `sync-cache` ahora terminan con un código distinto de cero si fallan. Antes imprimían el fallo y terminaban con 0, por lo que los scripts no podían distinguirlo de un éxito.
+- Los errores de `account` convierten HTTP 404 en el código de salida 4 y HTTP 409 en el código 5. Los demás fallos siguen usando el código 1.
+- `ocx restore back --json` ahora respeta su opción de salida, que antes aceptaba pero ignoraba. Esto no convierte `--json` en una opción global.
+- `ocx logs --model` ahora filtra los resultados. Antes aceptaba la opción pero la ignoraba y mostraba todas las filas.
+- `ocx storage` incorpora los subcomandos `cleanup`, `trash` y `policy`. Ejecutar solo `ocx storage` sigue mostrando el informe de almacenamiento, como cuando era un alias de `ocx observe storage`.
+
+<a id="version-and-internal-dispatch-targets"></a>
+
+## Objetivos de versión y despacho interno
+
+`ocx --version`, `ocx -v`, y `ocx version` imprimen una línea de versión amigable para el script y salen.
+
+Dos destinos de envío se omiten intencionalmente de la ayuda normal: `__refresh-version [preview]` actualiza la caché de actualización-notificación en un proceso separado, y `__gui-update-worker <job-id> [latest|preview] [restart]` ejecuta un trabajo de actualización del panel de control. Son detalles de implementación, no comandos estables orientados al usuario. El panel registra el PID del trabajador, recupera un trabajo activo cuyo trabajador murió, trata los registros activos sin PID más antiguos como obsoletos después de diez minutos y protege a un trabajador vivo de actualizaciones simultáneas.
+
+<a id="capability-argument-validation"></a>
+
+## Validación del argumento de capacidad
+
+`ocx capabilities` rechaza argumentos desconocidos, banderas repetidas y valores en blanco de `--route` con código de salida 64. Una ruta válida sin capacidad declarada sale con 4.
+
+<a id="integer-option-values"></a>
+
+## Valores de opción enteros
+
+Las opciones enteras como `--limit` requieren números enteros decimales dentro de los límites de seguridad de JavaScript. Se aceptan separadores de dígitos tales como `1_000` y `1,000`. Los valores vacíos, hexadecimales, notación de exponente y fracciones son rechazados antes de que se envíe una solicitud.
+
+<a id="windows-json-configuration-files"></a>
+
+## Archivos JSON de configuración en Windows
+
+`ocx config validate <file>` y `ocx config import <file> --yes` aceptan JSON UTF-8 con o sin marca de orden de bytes (BOM) inicial, también desde stdin (`-`). Esto permite usar las exportaciones UTF-8 de Windows PowerShell y otros editores. La entrada UTF-16 se rechaza.
+
+<a id="default-alias-listing"></a>
+
+## Listado de alias predeterminado
+
+`ocx alias --json` es equivalente a `ocx alias list --json`. La bandera de salida puede preceder o seguir una acción de alias explícita.
+
+<a id="local-config-output-and-validation"></a>
+
+## Salida y validación de configuración local
+
+`ocx config validate [path|-] [--json]` sale con 1 cuando falla la validación. El modo JSON emite una carga útil `{ok:false,error}`; el modo humano nombra el fallo de validación.
+
+Cuando la configuración guardada no es válida o ilegible, `ocx config`, `ocx config show` y `ocx config get` advierten en stderr que los valores predeterminados se muestran para configuraciones inválidas y salen con un código distinto de cero. Stdout conserva su formato existente. Ejecute `ocx config validate` para inspeccionar el error, o `ocx config show --source` para los diagnósticos de configuración y fuente. La inspección explícita `--source` sale con 0 cuando informa con éxito una reserva y aún emite la advertencia.
+
+`ocx config export <file> --json` escribe la configuración raw en el archivo y emite solo `{ok:true,path}` en stdout. Exportar a `-` siempre emite el documento de configuración en bruto, incluidas las credenciales; manténgalo fuera de las transcripciones del agente.
+
+`ocx provider add` valida toda la configuración candidata antes de guardarla localmente. Un fallo de validación deja intacto el archivo guardado. Los proveedores deliberadamente locales requieren `--allow-private-network`, salvo que su entrada del registro ya permita destinos privados. Esa opción no permite acceder a los endpoints de metadatos bloqueados.
+
+`ocx health` solo acepta una bandera opcional `--json`. Los argumentos desconocidos o los indicadores repetidos devuelven el código de salida 2 antes de sondear. Los errores de uso de Alias también devuelven el código de salida 2 con un error legible; las acciones desconocidas nombran `ocx help alias`.
+
+<a id="log-model-selectors"></a>
+
+### Selectores de modelo de registro
+
+`ocx logs --model` admite un ID de modelo sin prefijo o la etiqueta completa `provider/model` que muestran las filas legibles por humanos, incluso si el ID contiene barras. Los intentos de failover se comparan como destinos completos. El filtro se aplica antes de `--limit`, y `--follow` usa el mismo filtro del servidor. Si no hay coincidencias, la salida humana lo indica; `--json` y `--jsonl` conservan sus formatos para máquinas.
+
+`ocx hub disable [--revoke-clients --client-key <id> ...] [--json]` devuelve un concentrador a autónomo en una escritura de configuración validada. La revocación de la clave del cliente requiere identificadores explícitos porque los nombres de clave no prueban el origen. Véase [Devolver un concentrador a autónomo](/es/guides/remote-hub/#return-a-hub-to-standalone).
+
+
+`ocx alias template set <provider> <template>`, `ocx alias template rm <provider>` y `ocx alias template show [<provider>]` administran plantillas opcionales por proveedor; consulta [plantillas de alias](/es/guides/model-routing/#model-alias-templates). La pestaña **Codex → Codex CLI** usa el mismo plan y trabajo de actualización: [guía del dashboard](/es/guides/web-dashboard/#applying-a-codex-cli-update-from-the-dashboard).
diff --git a/docs-site/src/content/docs/es/reference/cli/agents.md b/docs-site/src/content/docs/es/reference/cli/agents.md
new file mode 100644
index 00000000000..028395a849c
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/cli/agents.md
@@ -0,0 +1,1031 @@
+---
+title: "Agentes, enrutamiento e integraciones de CLI"
+description: "Comandos multiagente, combo, observabilidad, acceso, ruta de protocolo, integración, sistema y configuración."
+---
+
+Estos comandos controlan la política del agente y el enrutamiento, inspeccionan el proxy en vivo y conectan los clientes compatibles con opencodex.
+
+<a id="agent-policy"></a>
+
+## Política del agente
+
+### `ocx agent <status|injection|effort|subagents|fallback|roles|sidecar|memory-models|compaction-routing> ...`
+
+Administre la lista de agentes múltiples sin cabeza, los límites de esfuerzo, la inyección rápida, la reserva y la configuración del sidecar. Utilice `status` para la política actual. Vea [Superficies de los subagentes](/es/guides/sub-agent-surface/) para ver cómo encajan entre sí los modos de superficie, la delegación, el esfuerzo y el comportamiento alternativo.
+
+```bash
+ocx agent subagents set ark/model-a,openai/gpt-5.5
+```
+
+`ocx agent roles` es para omo (Codex / LazyCodex). Enumera cada rol de agente Codex en `$CODEX_HOME/agents` con su pin de modelo y si `~/.omo/omo.jsonc` se puede actualizar, o dice que LazyCodex no está instalado, en cuyo caso `set` es rechazado. `ocx agent roles set <role> <model> [--effort <level>]` reescribe solo la línea de la raíz `model` de ese rol, y su línea `model_reasoning_effort` con `--effort`, y refleja tanto en omo.jsonc como `[codex].agents.<role>` como `model` y `reasoning`. Un esfuerzo para el que LazyCodex no tiene nivel, como `ultra`, se escribe solo en el archivo de rol. Una falta omo.jsonc, o uno que contiene comentarios, se deja sin cambios y el comando lo dice. Véase [omo ( Codex / LazyCodex) modelos de rol](/es/guides/integrations/#omo-codex--lazycodex-role-models).
+
+```bash
+ocx agent roles set explorer xai/grok-4.5 --effort medium
+```
+
+`ocx agent roles suggest` es omo (Codex / LazyCodex) solamente, rechazado como `set` cuando LazyCodex no está instalado. Dimensiona cada rol con una llamada al modelo predeterminado Codex (o `--model`) e imprime un modelo propuesto y un esfuerzo por rol sin escribir nada. `--apply` escribe cada propuesta a través de la misma escritura que `set`, saltándose y nombrando los roles cuyo modelo y esfuerzo ya coinciden. Véase [Asignación automática](/es/guides/integrations/#auto-assign).
+
+Una operación `--apply` admite como máximo **50 roles que necesiten cambios**, para registrar sus modificaciones en un lote de historial completo y poder restaurarlas juntas desde **Historial de cambios**. Los roles que ya coinciden, no pudieron dimensionarse o no tienen asignación no cuentan para el límite. Si cambiarían más de 50, el comando termina con código 5 antes de enviar ninguna actualización. Revisa la propuesta sin `--apply` y usa `ocx agent roles set <role> <model> [--effort <level>]` para los cambios individuales.
+
+Las actualizaciones se envían secuencialmente. Si una solicitud falla, se mantienen las escrituras anteriores confirmadas, no se intentan los roles posteriores y el comando conserva el código de error original, distinto de cero. El recibo identifica las escrituras confirmadas, el rol cuya escritura no pudo confirmarse, los roles no intentados y el lote de historial emitido por el servidor, si se conoce. Una respuesta perdida puede ocurrir después de guardar, incluso en la primera escritura antes de recibir el identificador del lote. Inspecciona `ocx agent roles --json` y el historial del dashboard antes de reintentar. No hay reintento ni reversión automáticos. El historial mantiene sus límites de disponibilidad y retención: un identificador de lote no garantiza que se registraran todas las escrituras ni que aún puedan restaurarse.
+
+Con `--json`, una aplicación interrumpida añade `complete: false`, `unconfirmedRole` y `unattemptedRoles` a los arrays existentes `applied`, `skipped` y `omoJsoncNotWritten`. Un rechazo previo añade `refusal` con el código `too_many_role_changes`, el límite y el número de cambios propuestos.
+
+La salida de sugerencias legible por humanos muestra caracteres de control de terminal como escapes visibles. Utilice `--json` cuando necesite los valores de sugerencia originales sin que se escape la presentación.
+
+`ocx agent injection suggest <work>` hace lo mismo para el modelo de delegación: mide el trabajo descrito, propone el modelo suficiente más barato y un esfuerzo de la lista del seleccionador de delegación, y no escribe nada a menos que se dé `--apply`, lo que ahorra a través de la misma escritura que `injection set`. Véase [Modelo de delegación y esfuerzo](/es/guides/sub-agent-surface/#delegation-model-and-effort).
+
+`ocx agent sidecar web --list` y `ocx agent sidecar vision --list` imprimen los modelos que el servidor ofrece actualmente para cada sidecar: el conjunto filtrado exacto que muestra el selector de tablero (filas visibles para el selector más las ranuras de autenticación Luna/Haiku con nombre de inicio de sesión, intersectadas con la disponibilidad del ejecutor para la búsqueda web, menos los modelos de solo texto para la visión). Las listas legibles por humanos muestran el backend de cada modelo entre paréntesis. Una escritura de búsqueda web `--model` resuelve esa fila ofrecida por el servidor y persiste su backend y modelo juntos, por lo que cambiar a una opción Anthropic no puede mantener un backend OpenAI (o viceversa). Las escrituras van a la misma ruta de administración que la GUI y están sujetas a la misma puerta por sidecar: la búsqueda web rechaza un par backend / modelo fuera del conjunto de la lista (miembro cerrado), mientras que la visión rechaza solo un modelo que probablemente no pueda ver (ids desconocidos permanecen escribibles).
+
+```bash
+ocx agent sidecar web --list
+ocx agent sidecar web --model gpt-5.6-luna
+ocx agent sidecar web --enabled off
+```
+
+Para el sidecar de búsqueda web, `--enabled off` equivale a la fila Off del dashboard: OpenCodex deja de ejecutar el sidecar y la integración con Codex escribe `web_search = "disabled"` en `~/.codex/config.toml`, permitiendo que un servidor MCP sea la única ruta de búsqueda. `--enabled on` elimina esa línea administrada.
+
+Cuando el guardado cambia realmente el interruptor, el comando informa del intento de aplicar el cambio a Codex nativo: mediante `codexWebSearch` con `--json`, o una línea final `Codex config:` en la salida legible. Un resultado satisfactorio confirma la reescritura. Si el ajuste se guardó, pero su aplicación nativa se aplazó o rechazó, el recibo indica el motivo y el siguiente paso que corresponde, como `ocx sync`; revisa ese motivo antes de reintentar. Si el interruptor no cambió, no hay escritura nativa que informar y no se muestra ninguna línea `Codex config:`. La opción de habilitación también funciona para `vision`.
+
+<a id="injection-defaults-and-sidecar-runtime-settings"></a>
+
+### Configuración predeterminados de inyección y entorno de ejecución del sidecar
+
+```bash
+ocx agent injection status --json
+ocx agent injection set --sync-codex-defaults off --json
+ocx agent injection status --json
+ocx agent sidecar web --stream-routed-output on --json
+ocx agent sidecar vision --timeout-ms 30000 --json
+ocx agent sidecar status --json
+```
+
+Ejecutar escribe solo para el cambio solicitado. La inyección `--sync-codex-defaults on|off` actualiza `syncCodexSubagentDefaults`; modelo/esfuerzo/pronta/orientación omitido permanece intacto, y `-` borra modelo/esfuerzo/pronta. El recibo ha normalizado realmente `model`, `effort`, `prompt`, `multiAgentGuidanceEnabled` y `syncCodexSubagentDefaults`, no un resultado de catálogo fabricado.
+
+Web `--reasoning` sigue siendo compatible. `--max-descriptions` y `--timeout-ms` son solo de visión; el tiempo de espera acepta enteros de 1 a 2147483647 milisegundos. `--stream-routed-output` es solo web. Las escrituras parciales conservan la configuración de hermanos. El recibo de la nueva opción expone únicamente el estado público seleccionado, `webSearch` o `vision`, y el informe de aplicación de `codexWebSearch`. `{applied:false, reason, retryable}` distingue el aplazamiento/rechazo de aplicación nativa de una configuración guardada; una nueva configuración faltante o no coincidente queda sin verificar y devuelve un código distinto de cero. Lee el estado para ver los ajustes completos observados, incluido el razonamiento web. No vuelvas a intentar ciegamente el rechazo de la propiedad.
+
+<a id="memory-and-compaction-routing-overrides"></a>
+
+### Anulaciones de enrutamiento de memoria y compactación
+
+```bash
+ocx agent memory-models show --json
+ocx agent memory-models set --extract-model <route> --extract-effort high --consolidation-model <route> --json
+ocx agent memory-models show --json
+ocx agent compaction-routing show --json
+ocx agent compaction-routing set --model <route> --effort high --triggers manual,auto --sources '<exact-source>,<provider>/*' --json
+ocx agent compaction-routing show --json
+```
+
+Cada conjunto reemplaza el bloque entero. La memoria acepta el modelo de extracción/consolidación y los pares de esfuerzo opcionales; se rechaza un esfuerzo sin el modelo de esa fase. Las fases omitidas usan su ruta existente/predeterminada, no una canalización detenida. `--file memory.json` en cambio lee el bloque en sí:
+
+```json
+{"extract":{"model":"example/model","reasoningEffort":"high"}}
+```
+
+Un archivo de memoria explícito `{}` es válido y sigue siendo un bloque de anulación vacío; `ocx agent memory-models clear --json` escribe null. Ambos significan que no hay una anulación personalizada, no un procesamiento de memoria deshabilitado. El modo de archivo es exclusivo con opciones escalares. Los archivos UTF-8 regulares o `--file -` canalizados utilizan el contrato de entrada limitada de 4 MiB/30 segundos, incluido un límite de solicitud seriado de 4 MiB.
+
+Los archivos de compactación contienen `model`, `reasoningEffort` opcional, `triggers` y `sourceModels`. Los disparadores son únicos `manual` / `auto`; los selectores de fuente deben ser exactos y únicos, o patrones de proveedor /. Los disparadores omitidos usan los valores predeterminados del servidor; las fuentes omitidas seleccionan todas las fuentes, no el alcance personalizado anterior. `ocx agent compaction-routing clear --json` escribe null y restaura el enrutamiento de compactación ordinario sin deshabilitar la compactación. Ninguna llamada de modelo sintético verifica estos ahorros.
+
+Las lecturas devuelven únicamente `{memoryModels: blockOrNull}` o `{compactionRouting: blockOrNull}`. Las escrituras añaden `catalogRefreshPending`: si es `false`, el comando termina con código 0, sin garantizar que todos los clientes hayan aplicado el cambio; si es `true`, guarda el cambio y termina con código 1. Si falta la evidencia de ese estado o está mal formada, devuelve null, `verification:"unverified"` y código 1. Vuelve a leer el estado antes de intentar recuperarlo.
+
+### `ocx effort [status|set|clear]`
+
+Inspeccione o cambie los límites del esfuerzo de razonamiento del agente principal y del subagente a través del proxy en vivo o la configuración local cuando no haya proxy disponible. Los valores máximos son `low`, `medium`, `high`, `xhigh`, `max` y `ultra`; `-` borra la tapa seleccionada. `none` y `minimal` no son niveles de límite y se rechazan antes de probar el proxy o enviar una actualización, incluso cuando otra opción en el mismo comando es válida. Siguen siendo válidos para `--injection`, que establece el esfuerzo de inyección por separado en lugar de una tapa.
+
+```bash
+ocx effort status --json
+ocx effort set --main high --subagent low
+ocx effort set --subagent -
+```
+
+Status conserva los valores de límite de entorno de ejecución/almacenados existentes e informa de los valores no admitidos en `warnings` (una matriz vacía cuando no se admite ninguna). Las mismas advertencias aparecen en la salida humana y nombran el campo que se ignora con un comando de corrección. El estado nunca repara o reescribe esos valores. Un campo de subagente ignorado no elimina un límite principal válido. `ocx effort clear` limpia ambos límites mientras retiene la configuración de esfuerzo de inyección separada. Véase [Superficies de los subagentes](/es/guides/sub-agent-surface/) para las superficies de solicitud donde se aplican los límites.
+
+### `ocx v2 <status|on|off|mode <v1|default|v2>|keep-native-v1 <on|off>|threads <n>|mode-hint <text|--clear>>`
+
+Administre el indicador de características Codex `multi_agent_v2` y el modo de superficie multiagente de tres estados. Estos funcionan localmente por defecto. `--live` utiliza el proxy de ejecución seleccionado sin respaldo local; ambos objetivos admiten `--json`. Vuelva a leer el estado en el mismo objetivo después de un cambio y distinga la configuración almacenada del comportamiento de la nueva sesión.
+
+| Subcomando | Medidas adoptadas |
+| --- | --- |
+| `status` (por defecto) | Reportar el indicador v2 actual, el modo multiagente y la concurrencia de subprocesos. |
+| `on` | Habilite la función global `multi_agent_v2`; los cambios locales vuelven a sincronizar el catálogo. Rechazado mientras el pin híbrido v2 está activo porque la anulación global lo derrotaría. |
+| `off` | Desactive la función `multi_agent_v2` y vuelva a sincronizar el catálogo. |
+| `mode v1` | Forzar a todos los modelos a v1, deshabilitar v2 nativo y preservar el límite de subproceso activo. |
+| `mode default` | Respete los pines de superficie del modelo aguas arriba. |
+| `mode v2` | Forzar los modelos a v2 y preservar el límite de rosca activa. Con `keep-native-v1` desactivado, habilite la v2 nativa global; con ella, deshabilite la anulación global y use pines de catálogo. |
+| `keep-native-v1 on\|off` | Bajo `mode v2`, mantenga los modelos nativos ChatGPT en v1 y los modelos enrutados en v2. Habilitarlo desactiva la anulación global de V2 antes de la sincronización del catálogo. |
+| `threads <n>` | Establezca el límite de hilo v1/v2 activo en un número entero de al menos 1. |
+| `mode-hint <text>` | Establezca la sugerencia de delegación proactiva (modo Ultra) para cada modelo y esfuerzo. |
+| `mode-hint --clear` | Elimine la sugerencia para que se reanude la política derivada del esfuerzo (ultra + proactiva). |
+
+```bash
+ocx v2 status
+ocx v2 mode v1
+ocx v2 mode default
+ocx v2 on
+ocx v2 threads 16
+ocx v2 mode-hint "Proactive multi-agent delegation is active."
+ocx v2 mode-hint --clear
+```
+
+El subcomando `mode` escribe `multiAgentMode` a la configuración opencodex y vuelve a sincronizar el catálogo Codex. Las transiciones de modo y bandera mueven el límite de subproceso numérico actual entre las teclas v1/v2 Codex válidas; una transición fallida restaura el `config.toml` original. Los cambios se aplican a las nuevas Codex sesiones, mientras que las sesiones en ejecución mantienen su superficie fija.
+
+Codex resuelve una anulación global habilitada de `multi_agent_v2` antes del pin de catálogo del modelo seleccionado. Por lo tanto, el contrato híbrido `keep-native-v1` mantiene esa anulación global apagada; de lo contrario, una fila nativa estampada `v1` aún comenzaría en V2 y produciría tareas secundarias cifradas en el backend.
+
+`mode-hint` escribe `features.multi_agent_v2.multi_agent_mode_hint_text` en el `$CODEX_HOME/config.toml` de Codex incluso cuando `multi_agent_v2` está actualmente deshabilitado. El comando solo persiste la anulación; no habilita ni deshabilita la función, por lo que la sugerencia tiene efecto cuando una superficie coincidente Codex está activa. La sugerencia anula la política multiagente derivada de esfuerzo de codex-rs, por lo que cualquier modelo y cualquier esfuerzo de razonamiento recibe el mensaje de delegación proactiva. **no** cambia el esfuerzo de razonamiento en sí. Se rechaza un argumento faltante o un valor de solo espacio en blanco; solo `--clear` elimina la sugerencia. El modo Ultra **on** del panel de Subagents tiene una puerta más estricta: requiere que la función nativa esté habilitada con una superficie v2 explícita ( `ocx v2 mode v2` ); `ocx v2 on` por sí solo no satisface esa puerta del tablero.
+
+<a id="explicit-v2-target-and-outcome"></a>
+
+#### Objetivo y resultado explícitos de la versión 2
+
+```bash
+ocx v2 status --json
+ocx v2 status --live --json
+ocx v2 mode v1 --live --json
+ocx v2 status --live --json
+```
+
+La escritura en vivo utiliza la ruta de gestión existente. Sólo explícito en vivo `mode` acepta `--acknowledge-surface-advisory`; añadirlo sólo cuando se reconoce que se solicita asesoramiento. El modo local y `status`/`on`/`off`/`keep-native`/`threads`/`hint` lo rechazan. No hay reconocimiento automático.
+
+Para el texto literal reservado, pase un operando citado después de `--`:
+
+```bash
+ocx v2 mode-hint --live --json -- '--clear'
+```
+
+Esto almacena el literal `--clear`; sin `--`, `mode-hint --clear` elimina la pista. El sufijo no se analiza en busca de los controles de ayuda, en vivo, JSON o borrado; los controles van antes de `--`. Los operandos adicionales y los indicadores duplicados se rechazan antes de la mutación.
+
+El JSON local es `{ok, target:"local", action, changed, state, sync}` y usa el estado real posterior a la escritura. Modo/mantener-nativo y on/off con cambio conservan su intento de sincronización real incluso sin un puerto descubierto; hilos/sugerencias y on/off sin cambios no añaden sincronización. Un resultado de sincronización ausente o mal formado queda sin verificar, con código de salida 1, no como éxito. `changed` o el estado pueden ser desconocidos después de un fallo; no afirme que hubo reversión. Los informes de estado en vivo validan estado/asesoramiento/recomendación con `target:"live"`; las escrituras añaden `ok:true` y `catalogRefresh`. Solo una actualización confirmada y no degradada sale con 0. Un HTTP 502 puede significar un estado nativo aplicado en parte: inspeccione antes de reintentar. Los errores de uso local conservan el código de salida 1; los nuevos errores de uso en vivo usan el código de salida 2.
+
+<a id="combo-routing"></a>
+
+## Ruteo combinado
+
+### `ocx combo <list|show|set|remove|stats> ...` · `ocx route combo ...`
+
+Gestione la conmutación por error combinada y los modelos virtuales round-robin. `ocx route combo` es el alias jerárquico; combos y perfiles de enrutamiento son recursos distintos. Los objetivos combinados usan `provider/model[:weight],provider/model[:weight]`.
+
+```bash
+ocx combo list
+ocx route combo set reliable --targets ark/model-a:2,openai/gpt-5.5
+```
+
+`set` acepta `--strategy`, `--sticky`, `--effort`, `--alias`, `--rename-from`, `--native-alias` y `--display-name <label|->` (`-` borra la etiqueta). Un alias nativo captura solo un identificador de modelo OpenAI no calificado actualmente soportado. Bare `gpt-5.6-*` alias nativos utilizan Codex Pool / Direct credenciales. Las rutas con calificación de cuenta OpenAI siguen siendo distintas, mientras que las rutas con calificación de proveedor como `openai-apikey/gpt-5.6-*` usan su clave configurada API y nunca caen a través del alias nativo. Lea el contrato de seguridad y visibilidad en la guía antes de habilitar el par de compatibilidad. El método de decisión se elige mediante dos opciones mutuamente excluyentes únicamente cuando la estrategia efectiva es JEV: al indicar `--strategy jev` o al omitir `--strategy` en un combo JEV existente. `--decision-provider <provider|->` nombra una fila `jev-decision` configurada (por ejemplo, una Ollama `tev1` autoalojada) como un servidor compatible con System One. `--decision-model <route|->` nombra una ruta opencodex ordinaria (por ejemplo `ollama/qwen3:4b`) que responde a la misma opción que JSON; no puede ser este combo o cualquier combo JEV. Un combo JEV nuevo usa TypeSafe si se omiten ambas opciones; uno existente conserva su método de decisión hasta cambiarlo mediante una de ellas. `--decision-timeout <ms|->` establece el plazo de decisión (1000-120000, por defecto 4000); `-` elimina cualquiera de los tres.
+
+`ocx combo set <id> --decision-quota-signals on|off|-` controla la evidencia consultiva por combo. `--decision-quota-tiers '{"limited":80}'` configura umbrales parciales; `-` los borra. Ambas opciones son exclusivas de JEV. Si se omiten, se conservan al sustituir destinos con `--targets-file` o `--targets` y al renombrar. Si no se indica `--strategy`, un combo existente conserva su estrategia: JEV mantiene su método, cuotas y fijación de sesión; un combo nuevo usa failover por defecto. Si una política JEV conservada rechaza los destinos nuevos, el comando identifica esa política y no guarda nada. Desactivar las señales conserva los umbrales; salir de JEV elimina ambos ajustes. Esto aporta datos de cuota al backend elegido, sin añadir consultas a proveedores, selección de cuentas ni exclusiones obligatorias. Véase [valores predeterminados, vigencia y privacidad](/es/guides/combos/#advisory-quota-signals-for-jev).
+
+`ocx combo set <id> --session-pin <duration|->`, exclusivo de JEV, mantiene la sesión en el destino que JEV eligió mientras siga activa, permitiendo reutilizar la caché del proveedor. La duración es un plazo de inactividad: `90s`, `20m`, `1h` o milisegundos, entre un minuto y 24 horas. `-` lo desactiva. Véase [Fijación de sesión para JEV](/es/guides/combos/#session-pin-for-jev).
+
+`ocx combo test [--combo <id>] [--decision-provider <provider|jev> | --decision-model <route>]
+[--decision-timeout <ms>]` envía una sonda de decisión sintética a través de un método combinado guardado o una selección no guardada e informa de la puerta, el backend y la latencia; puede pasar una llamada de decisión. `ocx combo discover [--query <text>]` enumera las filas configuradas de System One y los modelos de catálogo que parecen modelos de decisión, con el punto final derivado.
+
+Para metadatos de destino estructurados, inspeccione la ayuda sin conexión y el combo actual:
+
+```bash
+ocx combo set --help
+ocx combo list --json
+ocx combo show reliable --json
+```
+
+Un documento `--targets-file` es una matriz ordenada no vacía, por ejemplo, esta forma con valores de proveedor/modelo reemplazados por candidatos configurados reales:
+
+```json
+[{"provider":"example","model":"raw/model","weight":1,"reasoningEfforts":["high"],"modelProfile":"Reasoning tasks","lastResort":false}]
+```
+
+Los campos opcionales son `weight`, `reasoningEfforts`, `modelProfile` y `lastResort`. `reasoningEfforts` acepta una lista no vacía, sin duplicados, de `low`, `medium`, `high`, `xhigh`, `max` o `ultra`. Omitir el campo lo deja sin configurar; una lista vacía se rechaza. Los valores especiales de modelos personalizados, como `none` y `minimal`, no se admiten aquí. Los archivos y la entrada canalizada mediante `-` tienen un límite de 4 MiB y un plazo de lectura de 30 segundos; el cuerpo serializado de administración también debe caber en 4 MiB. Los campos desconocidos se rechazan antes de guardar.
+
+```bash
+ocx combo set reliable --targets-file targets.json --image-input auto --reasoning-effort-mode strict --json
+ocx combo show reliable --json
+```
+
+`--targets-file` y `--targets` son mutuamente excluyentes. Omitir ambos preserva metadatos de destino completos para ediciones parciales; los archivos de reemplazo preservan el orden y el `lastResort: false` explícito. `--image-input auto|disabled` y `--reasoning-effort-mode strict|adaptive` preservan la omisión, mientras que `auto` y `strict` explícitos anulan los valores deshabilitados/adaptativos guardados. El modo Razonamiento-esfuerzo está separado del `--effort-mode fallback|force`, que gobierna el esfuerzo predeterminado. `--allow-metered-targets on|off` otorga o borra el consentimiento del operador para los objetivos combinados marcados en un proxy de solo loopback; las personas que llaman públicas y vinculadas aún necesitan el consentimiento de clave configurada. `--native-alias on|off` conserva explícito falso; la bandera desnuda legado significa verdadero. Desactivarlo puede requerir el alias claro previsto, `--native-alias off --alias -`, para evitar retener un alias nativo incompatible. Establecer/renombrar es un upsert sin CAS, así que vuelve a leerlo después de los cambios. El recibo es `{success, id, model, combo, catalogRefresh}`; la actualización del catálogo omitida, fallida o degradada devuelve un valor distinto de cero después de guardar.
+
+<a id="observe-combo-decision-statistics"></a>
+
+### Observar las estadísticas de decisiones combinadas
+
+```bash
+ocx combo stats reliable --range 30d --json
+```
+
+Utilice el ID combinado almacenado exacto de list/show, no su modelo público o alias. Los rangos son `7d`, `30d` (predeterminado) y `all`. Esto lee observaciones JEV registradas sin ejecutar una sonda de decisión pagada. Inspeccione las decisiones, los intentos de modelo, los intentos medidos, los tokens de modelo y los tokens de decisión por separado. Mantenga las proporciones de cobertura `measuredModelAttempts/modelAttempts` y `decisionUsageReported/decisions` con los totales. Los promedios nulos no están disponibles, no son cero. Conservar `usageIncomplete`, `historyTruncated`, `entriesTruncated`, recuentos de entrada caída y límites de ventana instantánea. Cero observaciones no prueban el éxito. No hay costos monetarios ni ahorros comparativos en este informe.
+
+Consulte [Combos](/es/guides/combos/) para obtener orientación sobre el comportamiento de enrutamiento y la configuración.
+
+<a id="fallback-off"></a>
+
+## Desactivar el fallback
+
+### `ocx fallback <status|off|on|clear|local> ...`
+
+```bash
+ocx fallback status --json
+ocx fallback off --kind provider
+ocx fallback on --route combo/coding
+ocx fallback clear --provider anthropic --kind model
+ocx fallback local on --device mac-studio
+```
+
+`off`, `on` y `clear` aceptan `--kind model|provider|all` (por defecto, `all`) y como máximo un alcance: `--provider <name>`, `--route <selector>` o `--device <id|alias>`. Sin alcance explícito, modifican el ajuste global. Un dispositivo configurado en off siempre rechaza el fallback; en los demás casos, la ruta tiene prioridad sobre el proveedor y este sobre el ajuste global. `local` guarda si un dispositivo puede usar sus propios proveedores mientras el Home no esté disponible, un permiso que consulta GOAT; OpenCodex sigue devolviendo `home_unreachable` en ese caso. Los comandos se comunican con el proxy en ejecución; en un Remote Link Child, `status` consulta el Home y las escrituras se rechazan. Consulta [Desactivar el fallback](/es/guides/fallback-off/).
+
+<a id="routing-profiles"></a>
+
+## Perfiles de enrutamiento
+
+Los perfiles existentes apoyan la inspección y evaluación a través del API en vivo:
+
+```bash
+ocx route policy list --json
+ocx route policy show reliable --json
+ocx route policy dry-run reliable --model-context 128000 --tools --image --structured-output --json
+```
+
+Solo ejecute esta evaluación con autoridad para activar Lab en el destino. La administración POST puede activar Lab e iniciar la automatización que ya está habilitada allí, incluidas las sondas ascendentes. Use list/show para la observación sin ese efecto de activación.
+
+Reemplazar `reliable` con un ID listado. `evaluate` es un alias para `dry-run`; ambos envían requisitos al evaluador del perfil guardado sin una solicitud de inferencia. La creación, actualización y eliminación utilizan el flujo de trabajo explícito de archivo/revisión a continuación. Combo escribe editar un recurso separado. Los perfiles faltantes devuelven 4 y los operandos faltantes, 2.
+
+<a id="edit-a-routing-profile-with-its-observed-revision"></a>
+
+### Editar un perfil de enrutamiento con su revisión observada
+
+Crear/actualizar puede activar la automatización de Lab y ya habilitada, incluidas las sondas ascendentes. Sólo guárdalos con esa autoridad. La lista/presentación son observacionales; primero lea la ayuda fuera de línea y guarde el perfil previsto:
+
+```bash
+ocx route policy update --help
+ocx route policy show reliable --json > profile.observed.json
+jq 'del(.id, .model, .revision) | if .alias == null then del(.alias) else . end' profile.observed.json > profile.next.json
+```
+
+Editar y revisar el siguiente archivo; mantener el archivo observado sin cambios. La entrada contiene solo `alias`, `candidates`, `require`, `optimize`, `limits`, `unknownEvidence` y `compatibility` editables con campos anidados admitidos. `id`, `model`, `revision`, las claves desconocidas y el alias nulo no son entradas editables. El servidor sigue validando la semántica de proveedor, alias y políticas. `--file -` acepta stdin canalizado; los archivos/stdin UTF-8 regulares tienen el contrato de lectura de 4 MiB y de 30 segundos acotado.
+
+```bash
+ocx route policy update reliable --file profile.next.json --expected-revision '<exact-revision-from-observed-show>' --json
+ocx route policy show reliable --json
+```
+
+Utilice la revisión opaca original explícitamente. HTTP 409 / exit 5 significa volver a leer show, revisar los cambios concurrentes y reconstruir la edición. Nunca busque silenciosamente una revisión de reemplazo, vuelva a intentar o convierta la actualización en crear. Para un nuevo ID autorizado, utilice `ocx route policy create <new-id> --file profile.next.json --json` sin revisión. La eliminación autorizada es `ocx route policy remove <id> --yes --json` y no tiene guardia de revisión.
+
+Crear/actualizar devuelve `{success, id, model, profile, catalogRefresh}` con el nuevo `profile.revision`; eliminar devuelve `{success, id, catalogRefresh}`. Solo una actualización confirmada y no degradada sale con 0. Un recibo guardado con una actualización omitida, fallida o degradada sale con 1: inspeccione antes de recuperarse en lugar de repetir la escritura de configuración.
+
+<a id="compatibility-lab"></a>
+
+## Laboratorio de compatibilidad
+
+Lab es la inspección local **y** explícita de pruebas / automatización de gestión. Las lecturas usan la proyección local y no requieren una administración en ejecución API:
+
+```bash
+ocx lab status --json
+ocx lab catalog --json
+ocx lab subjects --limit 10 --json
+ocx lab automation status --json
+ocx lab automation runs --limit 10 --json
+ocx lab public community --json
+```
+
+`subject`, `observations`, `event`, `artifact` y `production-signals` siguen el linaje de evidencia local. La familia pública ofrece vista previa/exportación por `--event <id>` repetido, verificación/importación a través de `--file <bundle.json>`, y contexto comunitario. Exportar e importar escribe evidencia local. La verificación puede imprimir su resultado y aún salir con un código distinto de cero cuando el paquete no es criptográficamente válido.
+
+El manual `lab run` selecciona una capa y un escenario y puede gastar la cuota ascendente. Lea `ocx help lab` y la hoja correspondiente antes de estas operaciones autorizadas. Una política local guardada no prueba que un programador de proxy que ejecuta por separado la haya adoptado. Estos controles CLI no exponen la edición de políticas de automatización completa ni la cancelación de ejecución.
+
+<a id="observability-and-debug"></a>
+
+## Observabilidad y depuración
+
+### `ocx observe <logs|usage|storage|memory|debug|claude-inbound|injection> ...`
+
+Inspeccione las solicitudes de proxy, el uso, el almacenamiento, la memoria y los datos de depuración. Los alias directos son:
+
+| Alias | Recursos equivalentes |
+| --- | --- |
+| `ocx logs [filters] [--follow] [--json\|--jsonl\|--events]` | `ocx observe logs` |
+| `ocx usage [--range <today\|1d\|7d\|30d\|all>] [--since <timestamp> --until <timestamp>] [--surface <all\|codex\|claude\|grok>] [--provider <name>] [--model <id>] [--api-key-id <id>] [--search <text>] [--top <1-1000>] [--json]` | `ocx observe usage` |
+| `ocx usage compare [--range <today\|1d\|7d\|30d>] [--json]` | `ocx observe usage compare` |
+| `ocx storage [--json]` | `ocx observe storage` |
+| `ocx memory [--json]` | `ocx observe memory` |
+
+```bash
+ocx observe usage --range 30d --json
+ocx usage --since 2026-09-01T09:00:00Z --until 2026-09-01T10:59:59.999Z --json
+```
+
+`--since` y `--until` deben suministrarse juntos. Aceptan milisegundos de época enteros o fechas ISO completas con una zona horaria explícita, incluyen ambos puntos finales y anulan `--range`. Los límites no válidos o invertidos fallan antes de la solicitud. La salida humana imprime el intervalo solicitado; `--json` incluye `customWindow`, `since` y `until`. Todavía se aplican los filtros de superficie/proveedor/modelo existentes. Estos comandos consultan el proxy en ejecución; no proporcionan informes sin conexión.
+
+`--range today` (alias `1d` ) informa el día local actual. `--provider` y `--model` reducen el informe a un objetivo ascendente, distinto del `--surface`, que selecciona el cliente llamante (Codex, Claude Code, Grok) en lugar del proveedor que atiende la solicitud.
+
+La vista predeterminada imprime la solicitud, el token y los totales de costos estimados, además de los desgloses por proveedor y por modelo. Los costos son equivalentes al precio de lista de API, no un recibo de facturación: los planes de suscripción y los créditos del proveedor se facturan por separado, y las solicitudes sin fila de precios coincidentes se cuentan como `unpriced` / `unmetered` en lugar de doblar como cero.
+
+```bash
+ocx usage --range today --provider xai
+```
+
+Cuando no se pueden incluir algunos registros de uso, la salida humana advierte, incluso cuando hay cero filas legibles. Los totales mostrados reflejan solamente registros legibles. Si un filtro no tiene coincidencias legibles, la salida muestra la advertencia y la guía en lugar de las líneas totales; los registros omitidos pueden contener coincidencias. `--json` preserva el diagnóstico y la razón del nivel de respuesta `usageIncomplete`.
+
+<a id="compare-a-range-with-the-previous-equal-window"></a>
+
+### Comparar un rango con la ventana igual anterior
+
+```bash
+ocx usage compare --range today --json
+ocx usage compare --range 7d --provider xai
+```
+
+`ocx observe usage compare` es la forma familiar equivalente. El comando lee `GET /api/usage` dos veces: el rango nombrado termina ahora, luego el mismo rango evaluó una ventana igual antes (un día local para `today` / `1d`, siete para `7d`, treinta para `30d`). El rango predeterminado es `30d`. `--range all` se rechaza porque el historial abierto no tiene una ventana igual anterior. `--since` y `--until` no son aceptados; las ventanas se derivan. Los filtros de superficie, proveedor, modelo y API teclas se aplican a ambas lecturas. La salida humana imprime el cambio actual, anterior, firmado delta y porcentual. `--json` es `{schemaVersion,range,current,previous,delta,change,incomplete}`. Las dos lecturas son secuenciales, no una instantánea atómica. La opción personalizada `since` / `until` en cada respuesta debe coincidir con la ventana solicitada. Ambas lecturas usan la misma conexión y credencial. Si la conexión, la cuenta o la credencial cambian durante el comando, se informa de un desajuste del propietario y se le pide que vuelva a intentar en lugar de imprimir una comparación.
+
+<a id="page-indexed-request-history"></a>
+
+### Historial de solicitudes indexadas de página
+
+```bash
+ocx logs history --provider xai --status 200 --limit 50 --json
+ocx logs history --cursor '<nextCursor>' --json
+ocx logs get <request-id> --json
+```
+
+`ocx observe logs history` y `ocx observe logs get` son las formas familiares equivalentes. Estos leen el índice de historial de solicitudes derivado, no el reciente anillo `ocx logs`. `--limit` es 1-100 (por defecto 50). `--from` y `--to` aceptan milisegundos de época o fechas ISO completas con una zona horaria y son inclusivos. `--json` devuelve `{entries,hasMore,nextCursor,index}`. `--jsonl` emite filas solamente; cuando existen más páginas, `nextCursor=…` se imprime en stderr para que un llamante pueda reanudar sin mezclar el token en el flujo de filas. Los partidos vacíos tienen éxito. `get` devuelve una fila canónica por ID de solicitud; `ocx logs explain` sigue siendo la vista de decisión de ruta para ese mismo ID.
+
+<a id="filter-a-bounded-log-snapshot"></a>
+
+### Filtrar una instantánea de registro limitado
+
+```bash
+ocx logs filter --surface claude --status errors --time-window 1h --scan-limit 2000 --limit 50 --json
+```
+
+`ocx observe logs filter` es el alias equivalente. Lee una ventana reciente, filtra localmente y conserva las coincidencias más recientes en su orden original. `--scan-limit` limita las filas leídas (1-2000, por defecto 2000); `--limit` limita las filas devueltas (1-2000, por defecto 200). JSON informa `{schemaVersion:1,logs,cursor,filters,window:{scanLimit,loaded,matched,returned,limit}}`. Los recuentos describen únicamente la ventana examinada, no todo el historial. JSONL solo emite filas; una búsqueda sin coincidencias también termina correctamente. Los metadatos del cursor no son un token para reanudar la búsqueda.
+
+Los selectores incluyen `--surface all|codex|claude|grok`, `--status all|success|errors`, `--time-window all|15m|1h|24h`, `--model`, `--provider`, `--conversation` (alias `--conversationId`), `--intercepted-only`, `--min-tok-per-sec`, `--max-tok-per-sec` y `--protocol-mode all|native|translated|legacy-bridge|blocked|none`. La igualdad de modelo/proveedor se recorta y no distingue entre mayúsculas y minúsculas, incluidos los modelos resueltos/servidos y los intentos. Claude incluye Desktop; Codex significa superficie ausente. El éxito es HTTP 200-299, errores 400-599. Los límites inferiores de tiempo son inclusivos. La velocidad utiliza tok/s de valor-bueno observado, con valores mínimos y máximos inclusivos; los valores no disponibles fallan los filtros de velocidad activos. El protocolo ninguno incluye trazas ausentes o no válidas. La coincidencia de conversaciones utiliza los mismos ID de hash que los registros ordinarios. La interceptación selecciona marcadores de reescritura con valor de cadena.
+
+Las banderas desconocidas, repetidas o conflictivas, los límites inválidos y las opciones follow/events no admitidas en estos filtros se rechazan antes del descubrimiento: se escribe un error en stderr y se termina con código 2. Los fallos operativos, incluidos los del descubrimiento y las lecturas malformadas, demasiado grandes, rechazadas o fallidas por transporte, escriben un error en stderr y terminan con código 1. No se interpretan como un valor cero ni como resultados vacíos. Para reducir el tamaño de la respuesta, reduce el límite de exploración; reducir el límite de salida no cambia la consulta. Para streaming, usa los comandos de seguimiento independientes que se describen a continuación.
+
+<a id="search-usage-model-rows"></a>
+
+### Buscar filas de modelo de uso
+
+```bash
+ocx usage --range 7d --search 'model-a' --json
+```
+
+`--search` coincide con una subcadena recortada que no distingue entre mayúsculas y minúsculas en el modelo, proveedor o modelo resuelto después de leer el informe. Ordena las filas del modelo descendiendo tokens totales con empates estables y mantiene hasta 100 por defecto. JSON agrega `modelView:{query,matchedModelCount,returnedModelCount,limit:100,truncated}`; la salida humana etiqueta la vista y muestra las filas de modelos seleccionadas. Los totales de los informes, las filas proveedor/día/cuenta, los filtros exactos y los metadatos incompletos/ventana permanecen sin cambios. Ninguna coincidencia de modelo no significa que no se utilice el informe.
+
+Una consulta en blanco explícita (`--search=`) selecciona la vista top-100; la omisión de la búsqueda conserva el resultado existente. Exacto `--provider` / `--model` todavía alcance el informe subyacente. La búsqueda no amplía el auto alcance de la clave seleccionada o del cliente conectado y nunca se envía como un nuevo parámetro de consulta de Hub API.
+
+`ocx usage --top 25` (también `ocx observe usage --top 25`) establece el límite de la tabla del modelo humano a un número entero de 1 a 1000. El valor predeterminado es 10, o 100 con `--search`; el límite se aplica después del filtrado de búsqueda. Solo cambia la visualización local: los totales de los informes, las filas de proveedores/cuentas y los parámetros API permanecen sin cambios. Con `--json`, se ignora un `--top` válido; JSON conserva su informe completo existente o vista de búsqueda de 100 filas. Límites no válidos devuelven el código de salida 2 antes de buscar.
+
+<a id="saved-companion-usage-totals"></a>
+
+### Totales de uso de compañeros guardados
+
+```bash
+ocx companion show --json
+ocx companion usage --json
+```
+
+El segundo comando lee los ajustes complementarios guardados, luego hoy y el uso de 30d secuencialmente en el mismo entorno de ejecución de administración. Aplica las preferencias guardadas `models` y `hiddenProviders` y conserva los costos y tokens desconocidos / no medidos. La selección de modelo nulo significa todo; una selección vacía significa nada. No cambia la configuración, opera ventanas nativas o retransmite a través de un cliente conectado.
+
+El JSON devuelve `schemaVersion:1`, `filters`, `settingsUpdatedAt`, `settingsCorrupt`, `settingsFallback`, `ranges` y `partial`. Cada rango tiene `status:"available"` con `data` filtrado, o `status:"unavailable"`. Un rango no disponible establece `partial` y el código de salida 1 mientras conserva el otro rango. Los datos disponibles pero incompletos conservan sus propios metadatos; no se miden como cero. Los valores predeterminados válidos del servidor conservan una marca de tiempo de configuración nula y activan el respaldo; los valores predeterminados de un archivo corrupto además marcan la configuración como corrupta y advierten en la salida humana. Una configuración mal formada detiene el proceso antes de leer el uso. Estas lecturas no son una instantánea atómica. Cada GET tiene un plazo de 10 segundos para la búsqueda y el cuerpo tras el descubrimiento y un límite de respuesta de 32 MiB; no es un plazo para todo el comando. Las señales salen con 130/143 sin resultados tardíos.
+
+<a id="follow-request-windows-or-injection-sequences"></a>
+
+### Siga las ventanas de solicitud o secuencias de inyección
+
+```bash
+ocx logs --help
+ocx logs --limit 200 --json
+ocx logs --follow --events --limit 200
+```
+
+`--events` requiere seguir e implica JSONL; se acepta la redundancia `--jsonl`. `--json` sigue siendo de un solo disparo y entra en conflicto con los siguientes / eventos. Cada línea events-v1 es `{schemaVersion:1,type:"snapshot"|"append",rows,cursor,limit}`. Reemplace la ventana del consumidor en la instantánea, agregue/recortar en el agregado, preservando el orden y los ID repetidos. Se emiten instantáneas iniciales vacías y de reinicio/eliminación; las encuestas vacías estables permanecen en silencio. Las matrices heredadas son instantáneas con cursor nulo, no con cursores inventados. Estas son ventanas observadas, no una repetición sin pérdidas del tráfico que se pierde entre las urnas o después del desalojo del anillo.
+
+`ocx logs --follow --jsonl --limit 200` conserva la salida en forma de fila. Vuelve a emitir eventos modificados, incluyendo el mismo estado de ID / enmiendas de token y ID repetidos. No colapse todo por ID de solicitud. Esta salida heredada no puede codificar eliminaciones, reinicios u orden de ventana exacto; elija eventos cuando esas distinciones importan. El límite de seguimiento de registro es 1-2000, por defecto 200.
+
+```bash
+ocx observe injection --limit 500 --json
+ocx observe injection --follow --jsonl --limit 500
+```
+
+La inyección emite `{seq,at,line}` filas ordenadas, donde `at` es milisegundos de época; el `after` interno avanza con seq. El límite de seguimiento es 1-2000, por defecto 500. JSON es one-shot y JSONL requiere seguir. La observación no permite la captura. Las encuestas vacías no identifican la captura de desactivados ni prueban la ausencia de brechas. La deriva en entorno de ejecución detectable se detiene; no se pueden excluir intervalos de reinicio/última N indetectables sin un marcador de época/intervalo API.
+
+Ambos bucles de seguimiento usan esperas en serie de un segundo, plazos de 10 segundos para la búsqueda y el cuerpo, y límites de respuesta de 32 MiB. Los errores de formato, tamaño o transporte se detienen con stderr y código de salida 1, sin reintento ni reconexión automáticos. Reduzca el límite para ventanas demasiado grandes. SIGINT/Ctrl-C sale con 130 y SIGTERM con 143, sin sondeos ni salida posteriores. Inspeccione el estado de salida y las filas retenidas en lugar de tratar la cancelación como un historial completo.
+
+<a id="companion-timeline-and-key-scoped-usage"></a>
+
+### Línea de tiempo complementaria y uso de key-scoped
+
+```bash
+ocx companion timeline --help
+ocx companion timeline --hours 24 --bucket-minutes 60 --metric total --aggregation sum --grouping model --model example/model-a --hide-provider excluded-provider --json
+```
+
+Reemplace los ID ficticios con los filtros seleccionados. Repita `--model` para los ID de proveedor/modelo individuales (se permiten las barras anidadas; no CSV); repita `--hide-provider` para excluir a los proveedores. Positivo `--provider` no está soportado. Las horas son 6/24/72/168, los minutos del cubo 1-1440 con un máximo de 2000 cubos, métrico total/entrada/salida/caché, suma de agregación/promedio/máx, modelo de agrupación/modelAccount. El API limita las entradas de filtro a 100 elementos. Esto lee el uso sin cambiar la configuración del compañero.
+
+Compruebe `appliedFilters.models/hiddenProviders`. Los límites de la línea de tiempo son segundos de época, con final exclusivo, a diferencia de la ventana personalizada de milisegundos del uso ordinario. El final debe coincidir con el depósito de tiempo de solicitud, o su sucesor inmediato si la solicitud cruza un límite de depósito; se rechaza una ventana alineada más antigua. Las series vacías retienen los metadatos del bucket/filtro. `missingMeasurements` y `truncated` deben permanecer visibles: los puntos sin relleno no demuestran un uso cero completo.
+
+En un host de gestión no cliente:
+
+```bash
+ocx access key list --json
+ocx usage --api-key-id key-example --range 7d --json
+```
+
+Utilice un identificador de clave real no secreto. El CLI requiere un acuse de recibo de respuesta exacto en `filter.apiKeyId`; los filtros ignorados fallan en lugar de mostrar totales no explorados. Un ID desconocido reconocido puede devolver `matched:false` y vaciar el tráfico, no 404. Mantenga los datos incompletos/de ventana personalizada. Los clientes conectados rechazan `--api-key-id` antes del acceso o transporte de clave inscrita; lo omiten para el uso de Hub auto-solamente existente o realizan la vista de clave seleccionada en el Hub. Ninguna autoridad de gestión de concesiones de claves de datos.
+
+### `ocx debug <provider|usage|injection|claude> <on|off|status|reset|logs [-f]>`
+
+Lea o cambie las anulaciones de depuración en entorno de ejecución a través de la administración del proxy en ejecución API.
+
+```bash
+ocx debug provider on|off|status|reset
+ocx debug provider logs [-f|--follow]
+ocx debug usage on|off|status|reset
+ocx debug usage logs [-f|--follow]
+```
+
+Sin alcance, `ocx debug` imprime el uso y, cuando se detiene el proxy, el entorno de siguiente inicio predeterminado. Depuración de proveedores por defecto desde `OCX_DEBUG=1` (también funciona el legado `OCX_DEBUG_FRAMES=1`); depuración de uso por defecto desde `OPENCODEX_USAGE_DEBUG=1`.
+
+<a id="api-access"></a>
+
+## Acceso API
+
+### `ocx access <key|endpoints|models|test|audio> ...`
+
+Inspeccione las claves de admisión, los puntos finales externos y los modelos con la familia de acceso. `ocx api-key` alias la familia de claves de acceso. La creación y el inicio de rotación devuelven una credencial de texto sin formato de una sola vez en el texto y la salida JSON. Los agentes deben dejar esos pasos a un terminal operado por humanos fuera de la sesión de agente; solicite solo confirmación y claves no secretas / ID de rotación, nunca la credencial.
+
+```bash
+ocx access key list --json
+```
+
+Después de que el humano configure y verifique el reemplazo, realizar su rotación o eliminar la clave antigua requiere una autoridad de revocación explícita separada. Los seguimientos no secretos seguros son `ocx access key rotate commit <id> <rotation-id> --json` y `ocx access key rotate abort <id> <rotation-id> --json`, con autoridad para la acción elegida. Volver a la lista después. El estado pendiente ausente por sí solo no prueba la confirmación: la expiración o el aborto también pueden borrarlo. No envíe el consentimiento emitiendo directamente la solicitud de gestión de devolución secreta.
+
+<a id="rename-one-key-without-changing-its-access-policy"></a>
+
+### Cambiar el nombre de una clave sin cambiar su política de acceso
+
+```bash
+ocx access key rename key-example 'Research client' --json
+ocx access key list --json
+```
+
+Use un ID único real o un nombre inequívoco. Renombrar solo envía `{id,name}` y conserva los ámbitos de proveedor/modelo; no rota ni elimina una clave. La respuesta contiene id/name/createdAt y, opcionalmente, allowedProviders/allowedModels, nunca texto sin formato ni un prefijo. La lista sigue enmascarada. Los nombres no contienen caracteres de control, se recortan, no están vacíos y ocupan como máximo 64 unidades de cadena de JavaScript. La secuencia de lectura y renombrado no es CAS; inspeccione la lista enmascarada tras un resultado desconocido antes de reintentar. El alias raíz `api-key rename` usa el mismo comando.
+
+<a id="explicit-key-model-and-audio-checks"></a>
+
+### Modelo de clave explícita y comprobaciones de audio
+
+Descubre la sintaxis instalada sin contactar con upstream:
+
+```bash
+ocx access test --help
+ocx access audio transcribe --help
+ocx access audio live-check --help
+```
+
+Las solicitudes de modelos, las cargas de audio y las verificaciones de sesiones en vivo requieren una autorización explícita del operador para esa operación ascendente en particular y una posible cuota/costo. El operador suministra la clave seleccionada desde una fuente privada aprobada en un terminal operado por humanos fuera de la sesión de agente. Los agentes no deben capturarlo o pedirlo en el chat. Nunca lo ponga en argv / medio ambiente. Estos son el lado ocx de esa tubería privada, no las indicaciones de teclas interactivas directas o un lote de agente:
+
+```bash
+ocx access test example/model --protocol responses --api-key-stdin --json
+ocx access audio transcribe sample.wav --model gpt-4o-mini-transcribe --api-key-stdin --json
+ocx access audio live-check --model gpt-live-1-codex --api-key-stdin --json
+```
+
+Elija solo la tarea autorizada y el modelo/archivo real. Se rechaza la entrada TTY. La entrada está limitada a 4096 bytes/30 segundos, ASCII imprimible UTF-8 válido, sin espacios en blanco externos, controles o líneas adicionales; se permite un LF/CRLF final. Esto cubre deliberadamente las claves emitidas actualmente, no todos los valores Unicode que la configuración del servidor podría aceptar. Las ocurrencias exactas de la clave suministrada en el texto permitido se convierten en `[redacted]`; las codificaciones arbitrarias no se garantizan detectadas. No se imprime ningún portador de claves codificado.
+
+Los objetivos son el origen de servicio local comprobado o el origen de concentrador inscrito normalizado existente, con la identidad comprobada alrededor del trabajo asíncrono. No hay un origen personalizado, administración o reserva de clave inscrita, seguimiento de redireccionamiento, caché de credenciales o reintento automático. El operador solo informa al agente sobre el resultado no secreto.
+
+<a id="model-control-and-response-limits"></a>
+
+#### Control del modelo y límites de respuesta
+
+Los protocolos son chat (predeterminado), respuestas o mensajes. El modo de clave seleccionada primero envía un control mal formado sin credenciales: JSON a ese punto final. Solo la clave nativa requerida 401 avanza a una solicitud de modelo de 16 tokens fija usando la clave suministrada. El control tiene un presupuesto de respuesta de 5 segundos/4096 bytes; la solicitud tiene un presupuesto de respuesta de 60 segundos/2 MiB que incluye lecturas del cuerpo. Los controles sin autorización/no reconocidos se detienen antes de la inferencia. La contabilidad de registro/admisión local puede seguir ocurriendo.
+
+JSON es `{schemaVersion:1,control:{outcome,status?},request:{outcome,status?},response?}`. La respuesta segura contiene el protocolo, el texto ordenado, la finalización completa/limitada y los recuentos de tokens medidos opcionales. Una respuesta de longitud limitada utilizable es `limited`; las respuestas de rechazo, filtradas por contenido, que contienen solo llamadas a herramientas o que están mal formadas no son compatibles, incluso con HTTP 2xx. Los metadatos de error, ID, herramientas y razonamiento no se imprimen. El fallo operativo retiene un informe versionado más stderr/código de salida 1 fijo; la entrada de gramática o clave no válida sale con 2 sin un informe fabricado.
+
+El éxito solo dice: "La solicitud sin credenciales fue rechazada; la solicitud del modelo que usa la clave suministrada tuvo éxito". Los cambios de política del oyente entre las llamadas siguen siendo posibles; esto no certifica el alcance de la clave, la admisión atómica o la identidad de facturación. Sin `--api-key-stdin`, la prueba heredada JSON sigue siendo su carga útil original y no dice nada sobre una clave recién seleccionada.
+
+<a id="transcription-and-live-readiness"></a>
+
+#### Transcripción y preparación en vivo
+
+La transcripción requiere un archivo regular no vacío de hasta 25.000.000 bytes, con un límite de lectura local de 30 segundos y un cuerpo multipart de hasta 32 MiB. Admite `gpt-4o-transcribe`, `gpt-4o-mini-transcribe` o `whisper-1`, según el destino. La carga y la respuesta comparten un único límite de 130 segundos; la respuesta no puede superar 2 MiB. Si tiene éxito, devuelve solo `{text}`, incluso si está vacío, y oculta la clave exacta. Si falla, deja stdout vacío, escribe un diagnóstico fijo en stderr y termina con un código distinto de cero; no devuelve un objeto JSON de error ni el cuerpo sin procesar.
+
+El audio utiliza la admisión de clave explícita sin el control del modelo. La verificación en vivo envía solo session.update y session.close fijas. La preparación requiere session.started o session.updated con ID de sesión nativa no en blanco en 15 segundos; el socket abierto o session.created solo es insuficiente. Después de la preparación, espera como máximo 2 segundos para el cierre normal del código-1000. Cada cuadro UTF-8 tiene un límite de 64 KiB, suma 2 MiB; no hay un historial de cuadros retenidos.
+
+En vivo JSON es `{schemaVersion:1,ready,close:"confirmed"|"unverified",check:"session-readiness",event?}`. El fallo operacional preserva esa observación sin marcos en bruto. Disposición parcial con salidas cerradas no verificadas 1; un cierre normal posterior no puede borrar un error anterior. Salida de señales 130/143. Esto comprueba la disponibilidad/cierre solamente, no el micrófono, la carga, la ejecución de la herramienta, la liberación de ida y vuelta de voz completa o el arrendamiento del servidor. La apertura de la sesión previa no está garantizada gratis. Ninguna reconexión o reintento es automático.
+
+### `ocx api <protocols|explain|policy> ...`
+
+Inspeccione y establezca cómo viajan las solicitudes entre las API del cliente y los cables del proveedor. Vea [Rutas de protocolo](/es/guides/protocol-paths/) para el vocabulario.
+
+| Comando | Ruta | Cambia el estado |
+| --- | --- | --- |
+| `ocx api protocols [--provider <name>] [--json]` | `GET /api/protocols` | No |
+| `ocx api explain --model <id> --inbound <responses\|chat\|messages> [--feature <key>]... [--json]` | `POST /api/protocols/plan` | No |
+| `ocx api policy [--json]` | `GET /api/protocols` | No |
+| `ocx api policy [--messages <on\|off>] [--unrepresentable <legacy\|reject>] [--rollout <switch>=<on\|off>]... [--json]` | `PATCH /api/protocols/settings` | Sí |
+
+- `protocols` imprime la versión del contrato, si cada cliente API está atendido y por qué, la política no representable, cada interruptor de implementación y la revisión de la política. `--provider` agrega el cable ascendente que recibe el proveedor, quién lo decidió y los modelos en otro cable.
+- `explain` previsualiza la ruta que tomaría un modelo de un cliente API. `--feature` es repetible y acepta una lista separada por comas; `ocx api protocols --json` enumera las claves de características conocidas. La vista previa se calcula a partir de la configuración: no se envía nada aguas arriba, no se avanza en la rotación combinada y la entrada no se registra.
+- `policy` sin una bandera de configuración solo se lee. Con uno, envía un solo cambio al proxy en ejecución, que lo valida, guarda la configuración y responde con la nueva política. `--messages off` también desactiva la integración Claude, como lo hace el conmutador del tablero de instrumentos. Los nombres y las combinaciones de conmutación son validados por el proxy; por ejemplo, se rechaza `--rollout managedMessagesNativeOAuth=on` a menos que `managedMessagesNative` ya esté activado o activado en el mismo commando.
+
+```bash
+ocx api explain --model combo/main --inbound chat --feature request.seed,request.tools
+ocx api policy --rollout shadowPlan=on
+```
+
+Los errores de uso salen con 2 antes de que se envíe cualquier solicitud. `--json` imprime el cuerpo de gestión API tal cual.
+
+<a id="client-integrations"></a>
+
+## Integraciones de clientes
+
+<a id="basic-integration-commands"></a>
+
+### Comandos básicos de integración
+
+| Comando | Medidas adoptadas |
+| --- | --- |
+| `ocx integration client status [--client <id>] [--profile <id>] [--json]` | Lea todas las integraciones de archivos administrados, un cliente o perfiles de Aside. `show` y `list` alias `status`. |
+| `ocx integration client history [--client <id>] [--profile <id>] [--json]` | Lea las operaciones de reversión y la disponibilidad de instantáneas. `journal` alias `history`. |
+| `ocx integration client enable --client <id> [--profile <id>] [--overwrite-conflict] [--json]` | Aplicar la integración de archivos administrados. Sobrescribir un bloque en conflicto requiere la bandera explícita. |
+| `ocx integration client disable --client <id> [--profile <id>] [--json]` | Elimine la integración administrada seleccionada a través de su propietario de tiempo de ejecución. |
+| `ocx integration client restore --op <opId> [--client aside --profile <id>] [--confirm-drift] [--json]` | Restaurar una operación registrada; reemplazar ediciones posteriores requiere confirmación explícita de deriva. |
+| `ocx integration native [list] [--json]` | Leer estado de integración nativa. |
+| `ocx integration native <claude\|claude-desktop\|codex\|grok> <on\|off> [--json]` | Escriba la configuración del cliente nativo seleccionado a través de su propietario en tiempo de ejecución. |
+
+Estos comandos requieren un proxy en ejecución. `--profile` selecciona un ID de cuenta de Aside no negativo y requiere `--client aside`; perfiles omitidos seleccionan el agregado para lecturas y todos los perfiles para habilitación/desactivación sin atar. Conmutaciones nativas cambian la configuración del cliente; Cursor tiene comandos de inspección de solo lectura separados a continuación. Para obtener una vista previa y opciones de escritura limitada, continúe con las recetas a continuación.
+
+<a id="preview-and-recover-managed-file-integrations"></a>
+
+### Vista previa y recuperación de integraciones de archivos administrados
+
+```bash
+ocx integration client preview --client hermes --operation apply --json
+ocx integration client restore --op op-example --preview --json
+```
+
+`op-example` es ficticio; use una identificación de la historia. Las operaciones de vista previa se aplican, sobrescriben y desactivan; la restauración utiliza `--preview` en su comando existente. Revise los cambios estructurales y `canApply` / `willChange`; rechazo válido / salidas no opcionales 0 sin aplicar. Habilitar/deshabilitar/restaurar acepta la opción `--plan-fingerprint` para un compromiso vinculado explícito. Direct escrituras de legado permanecen disponibles. Para previsualizar o escribir vinculado se requiere `--client aside --profile N`. La confirmación de deriva y la sobreescritura nunca son automáticas; las salidas de enlace obsoletas 5 con stdout vacío y una instrucción de revisualización en stderr. Siga el [recetas completas de vista previa/compromiso y deriva](/es/guides/integrations/#preview-and-bind-a-terminal-write).
+
+Droid aplica/sobrescribe los soportes repetidos `--reasoning-default MODEL=EFFORT` para el reemplazo completo del mapa, o el exclusivo `--clear-reasoning-defaults` para `{}`. La omisión preserva el mapa. Repita el mapa exacto en vista previa y confirmación; ver [Droid valores predeterminados](/es/guides/integrations/#factory-droid).
+
+La eliminación del historial es irreversible y requiere un opId exacto más `--yes`: `ocx integration client history remove --op op-example --yes --json` apunta al diario global. Solo `--client aside` y el opcional `--profile N` ofrecen ámbitos de eliminación más estrechos. La fila más reciente está protegida. `snapshotRemoved:false` sale con 1 tras la retirada con la limpieza incompleta; no reintente la eliminación ni afirme una reversión.
+
+`ocx integration client sync --client aside --json` actualiza los perfiles elegibles a través del propietario certificado, sin selector de perfil o reserva local. El vacío `results` es una observación exitosa de perfiles no elegibles; una fila fallida hace que el agregado sea distinto de cero mientras conserva otros éxitos. Lea los hechos de estado y recuperación antes de volver a intentarlo; [Los controles de Aside](/es/guides/integrations/#aside-profile-controls) explican la intención del perfil versus el estado del archivo.
+
+<a id="inspect-cursor-without-installing-it"></a>
+
+### Inspeccione Cursor sin instalarlo
+
+```bash
+ocx integration native cursor status --json
+ocx integration native cursor local-installer --json
+```
+
+El estado puede recopilar el inventario del modelo; la búsqueda del instalador puede obtener un manifiesto público. No descargan ni instalan nada ni modifican Cursor. El estado distingue la credencial del modo de puerta de enlace de marcador de posición; el marcador de posición no es una credencial de acceso. El instalador `{available:false,url:null,version:null,reason:null}` es válido, incluso cuando Private Inference ya está instalado. Una lectura no disponible válida sale con 0.
+
+### `ocx integration <claude|grok> ...`
+
+Administre las integraciones Claude y Grok compatibles. Las familias de comandos directos a continuación exponen sus controles específicos del cliente.
+
+### `ocx claude [claude args...]`
+
+Asegúrese de que el proxy se está ejecutando, luego inicie Claude Code con `ANTHROPIC_BASE_URL`, `ANTHROPIC_AUTH_TOKEN`, `CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1` y las ranuras del modelo de `config.claudeCode`. Los modelos encaminados aparecen en el selector nativo `/model` a través de alias de ranura estables con Claude Code 2.1.129 o más reciente. En versiones anteriores, seleccione con `ANTHROPIC_MODEL` o `/model <id>`. Las variables `ANTHROPIC_*` exportadas por el usuario siempre tienen prioridad.
+
+Los comandos de perfil Claude Desktop son:
+
+```text
+ocx claude desktop [apply]                         Save and apply the four-family profile
+ocx claude desktop show [--json]                   Show routes, families, and defaults
+ocx claude desktop status [--json]                 Show applied state, drift, and health
+ocx claude desktop move <route> <family> [--default]
+ocx claude desktop default <family> <route|none>
+ocx claude desktop export <path|->                 Export versioned JSON (`-` = stdout)
+ocx claude desktop import <path> [--apply]         Validate and import JSON
+```
+
+Las familias son `opus`, `fable`, `sonnet`, y `haiku`; nuevas rutas comienzan en `opus`. `none` es válido Sólo cuando la familia está vacía. Legado aplicar banderas `--static`, `--hybrid`, y `--discovery-only`
+seguir siendo apoyados. Uso `ocx claude config <status|set> ...` para la configuración de Claude Code.
+
+<a id="read-or-save-the-selected-runtimes-desktop-profile"></a>
+
+#### Leer o guardar el perfil de escritorio del entorno de ejecución seleccionado
+
+Los comandos show/import existentes son locales. La familia `profile` se dirige al entorno de ejecución de la administración en ejecución y puede recopilar el inventario del modelo:
+
+```bash
+ocx claude desktop profile show --json > desktop-observed.json
+jq '.profile' desktop-observed.json > desktop-profile.json
+```
+
+Editar/revisar el perfil versionado, preservando los marcadores aplicados propiedad del servidor. Para un guardado autorizado, lea de nuevo:
+
+```bash
+ocx claude desktop profile import desktop-profile.json --json
+ocx claude desktop profile show --json
+```
+
+Import acepta el perfil en sí, no la respuesta externa `{profile,models,rendered,port}`, utilizando archivos JSON regulares limitados o stdin explícito `-` (4 MiB / 30 segundos). Devuelve esos campos observados más `ok:true`, es decir, guardados solo. `--apply` y se rechazan las banderas en modo nativo; la función de guardado en entorno de ejecución no tiene respaldo local. Apply es una acción de escritorio existente separada en su máquina, así que verifique el host/contexto antes de elegirlo. Los modelos renderizados no son prueba de aplicación nativa.
+
+### `ocx codex [codex args...]`
+
+La clave solo se suministra cuando la configuración y sus espacios de nombres están protegidos
+frente a otros usuarios; se confía en el usuario actual y en las autoridades privilegiadas del sistema
+operativo. También se confía en los procesos del mismo usuario: quien tenga tus permisos de escritura
+ya puede leer el archivo de clave de OpenCodex. La sustitución de la configuración por ese mismo
+usuario entre la verificación y el arranque nativo queda fuera de este modelo de amenazas;
+el lanzador no inmoviliza la configuración al ceder el control.
+
+En una instalación normal de Windows, los permisos predeterminados de ProgramData permiten que
+otros usuarios creen directorios. Por eso se retienen las credenciales automáticas incluso si no
+existe `ProgramData\OpenAI\Codex`. La carpeta de configuración de sistema de Codex bajo ProgramData
+debe existir y solo Administrators/SYSTEM deben poder escribir en ella; sus directorios superiores
+deben impedir que otros usuarios la sustituyan. Pide a un administrador que revise la política del
+directorio. opencodex nunca cambia las ACL por sí mismo ni ofrece un comando de aprovisionamiento.
+
+Como alternativa, suministra la clave tú mismo, por ejemplo exportando `OPENCODEX_API_AUTH_TOKEN`;
+`ocx codex` la conserva intacta. Los archivos de configuración de sistema existentes siguen impidiendo
+la entrega automática de credenciales y requieren una revisión aparte. Cada motivo de retención
+produce un diagnóstico breve y específico en stderr, sin valores de claves, contenido ni rutas de sus archivos.
+
+Usa `--` antes de un mensaje de una sola palabra para que no pueda seleccionar un subcomando desconocido de Codex.
+
+Las credenciales automáticas también requieren una prueba reciente de propiedad del listener activo de esta instalación. En un proxy independiente, debe proceder del origen HTTP exacto de la configuración administrada del proveedor Codex; un proxy activo en otro puerto o dirección loopback no autoriza ese destino. Un cliente directo prueba su propio listener local y conserva las comprobaciones de su URL de servidor guardada, porque el servidor al que se conecta pertenece a otra instalación. Esa prueba demuestra que el listener que responde pertenece a la instalación local, no qué tipo de listener es. Si no hay una prueba coincidente, el lanzador retiene el token automático y deja el enrutamiento sin cambios.
+
+El espacio de nombres de configuración del equipo también debe impedir que otros usuarios creen
+archivos de sistema ausentes. Un espacio ProgramData/OpenAI/Codex sin protección en Windows
+impide la entrega automática de credenciales; el lanzador no lo crea. macOS acepta ACL que solo
+deniegan permisos y entradas de permiso de solo lectura, pero rechaza cualquier entrada que conceda
+escritura, anexado, eliminación, cambios de atributos o seguridad, o cambios de propietario, incluso
+después de una entrada de denegación. Las etiquetas desconocidas y los errores de inspección causan rechazo.
+
+Solo se carga un token de servicio nuevo si los argumentos están en la lista permitida de abajo,
+el entorno no contiene opciones no vacías de proxy HTTP(S)/ALL ni variables `CODEX_*`/`OPENAI_*`/
+`AZURE_OPENAI_*` que alteren el comportamiento (se permite `CODEX_HOME` canónico), y los espacios
+de nombres del directorio personal, la configuración y el sistema superan las comprobaciones de
+propiedad. La configuración solo debe contener claves auditadas y el proveedor loopback administrado
+exacto, sin otros consumidores de credenciales ni capas de configuración. Cualquier argumento no
+admitido, incluidos `-c`/`--config`, `-p`/`--profile`, opciones desconocidas y `resume`/`fork`, impide
+cargar el token y genera un diagnóstico sin valores; se conservan las credenciales explícitas y los argumentos originales.
+
+El directorio personal canónico y `config.toml` deben pertenecer al usuario actual. POSIX rechaza
+la escritura de grupo u otros; Windows comprueba el SID del propietario y rechaza permisos DACL
+de escritura para identidades ajenas al usuario actual, SYSTEM y Administrators. También se
+comprueba si los directorios superiores permiten sustituciones. macOS exige además que no haya
+preferencias de configuración forzadas de Codex. Estas comprobaciones excluyen escritores de otros
+usuarios; no aíslan un proceso malicioso del mismo usuario ni a un administrador.
+
+| Lista permitida | Opciones |
+| --- | --- |
+| Interruptores | `--no-daemon`, `--json`, `--ephemeral`, `--skip-git-repo-check`, `--no-alt-screen`, `--full-auto`, `--dangerously-bypass-approvals-and-sandbox`, `--search` |
+| Un valor | `--model`/`-m`, `--sandbox`/`-s`, `--ask-for-approval`/`-a`, `--image`/`-i` |
+
+La entrega automática de credenciales interpreta `CODEX_HOME` como una ruta literal, incluidos
+`~` y los espacios, verifica ese directorio y pasa su ruta absoluta canónica al proceso hijo.
+Si no puede leerse, omite la carga. Cualquier variable `HTTP_PROXY`, `HTTPS_PROXY` o `ALL_PROXY`
+no vacía, con cualquier combinación de mayúsculas y minúsculas, también la impide, independientemente
+de `NO_PROXY`; no cambia los lanzamientos rechazados ni las credenciales exportadas por el usuario.
+Con un token recién cargado, `NO_PROXY` y `no_proxy` del hijo incluyen `127.0.0.1` y `::1`, conservando
+las excepciones existentes. Habilitar `features.respect_system_proxy` o reenviar `--enable`/`--disable`
+impide la carga automática.
+
+Se asegura de que el proxy esté en ejecución y después inicia Codex con los argumentos originales.
+El enrutamiento permanece en la configuración de Codex; el lanzador nunca lo reescribe. Las rutas
+nativas y ajenas omiten el arranque del proxy. Si el enrutamiento es desconocido, avisa e intenta
+iniciarlo; si falla, avisa y continúa. La ayuda, la versión y los comandos internos como `login`,
+`doctor` y `help` omiten tanto el arranque como la carga automática del token.
+
+Si falta `OPENCODEX_API_AUTH_TOKEN`, se lee del `service-api-token` de esta instalación solo cuando
+la configuración de transporte completa del proveedor seleccionado coincide con el bloque administrado
+del listener loopback configurado o de la conexión de cliente local persistente. Los nombres y los
+comentarios de inyección por sí solos no conceden acceso a credenciales. Los destinos desconocidos
+o remotos, los perfiles predeterminados, la configuración del proyecto, `OPENAI_BASE_URL` y las opciones
+reenviadas `-c`/`--config`, `-p`/`--profile`, `-C`/`--cd` o `--remote` impiden la carga automática.
+Se conservan las credenciales exportadas por el usuario y los argumentos; las opciones que cambian
+el archivo de token no permiten seleccionar otra credencial y se rechazan las colisiones con tokens de administración.
+
+Solo un envoltorio de arranque automático que coincida con el esperado ejecuta directamente el Codex
+que respalda. Un estado desconocido, incluida una excepción de inspección, requiere una vía de omisión
+verificada; los envoltorios CMD administrados de Windows deben coincidir con la plantilla generada
+actual completa antes de ejecutar el comando absoluto seleccionado con `OCX_SHIM_BYPASS=1`.
+Los lanzadores npm ordinarios siguen admitidos. Los envoltorios obsoletos o no verificables terminan
+con código 1 sin iniciar Codex; ejecuta `ocx codex-shim install` para actualizarlos. Este lanzamiento
+no repara shims. La comprobación del contenido no demuestra la procedencia del archivo de respaldo
+en Windows ni impide la sustitución concurrente de su ruta.
+
+En macOS, cada inicio, incluidos los de ayuda o versión, verifica el ejecutable seleccionado si su ruta seleccionada o su ubicación canónica está dentro de cualquier paquete `.app`. Los paquetes renombrados y los enlaces simbólicos hacia paquetes requieren las mismas comprobaciones de propiedad, permisos y firmas de OpenAI para el paquete y el ejecutable. Un miembro seleccionado debe permanecer dentro del `Contents/` canónico de ese paquete, también al resolver enlaces simbólicos de ejecutables, directorios o del paquete completo. Si falla la verificación, termina con código 1 sin iniciar Codex. Los ejecutables ordinarios fuera de paquetes, incluidas las instalaciones npm, conservan su comportamiento.
+
+Usa `ocx help codex` para la ayuda del lanzador y `ocx codex --help` para la de Codex.
+Ejecutar después `codex` directamente conserva su comportamiento habitual.
+
+### `ocx opencode [opencode args...]`
+
+Asegúrese de que el proxy se está ejecutando, después inicia OpenCode con los bloques `provider.opencodex` y `providers.opencodex` generados en la capa de entorno de ejecución en línea de OpenCode (`OPENCODE_CONFIG_CONTENT`). El bloque heredado mantiene a los clientes V1 trabajando con mapas variantes; el bloque V2 lleva matrices nativas para las mismas opciones de esfuerzo de razonamiento y valores predeterminados. La configuración en línea existente se conserva y solo se reemplazan esas dos claves para este lanzamiento. Los archivos globales o de proyecto `opencode.json` se pueden leer para advertir sobre una anulación existente, pero los archivos en el disco nunca se modifican. Los modelos enrutados aparecen como `opencodex/<provider>/<model>`. El lanzamiento del plain `opencode` más tarde se comporta exactamente como antes.
+
+### `ocx grok <status|exclude|include|set|clear|apply> ...`
+
+Administre y aplique la valla modelo Grok Build.
+
+<a id="client-config-export"></a>
+
+## Exportación de configuración de cliente
+
+La exportación de Hermes y Command Code y las operaciones de integración apply/overwrite aceptan
+`--model-names alias|routed` (campo JSON de la API: `modelNames`). Omitirlo al exportar significa
+`routed`; omitirlo al aplicar después conserva el modo guardado. Es independiente de
+`preferModelAliasIds`. Solo se emite un alias cualificado por proveedor que llegue al mismo proveedor
+y modelo; si falta, es inseguro o hay colisiones, se usa el nombre enrutado. Los combos conservan sus claves.
+
+`ocx export --client hermes --model-names alias --json` previsualiza un catálogo actual ya existente
+sin escribir archivos del cliente ni estado administrado. Un catálogo sin cargar o desactualizado
+devuelve que no está disponible; cárgalo por separado y reintenta. `--out` solo escribe el archivo
+de exportación solicitado y conserva su comportamiento de creación exclusiva/`--force`.
+Para escrituras administradas, pasa el mismo modo a `integration client preview --operation apply|overwrite`
+y a `enable` al confirmar un plan. El campo no se admite en disable/restore ni para otros clientes.
+Cambiar un alias durante Aplicar o una actualización puede causar un conflicto antes de escribir;
+reintenta con el catálogo actual. Los alias eliminados o renombrados migran en la siguiente actualización
+correcta, que sigue rechazando ediciones ajenas. Consulta [la guía de integraciones](/es/guides/integrations/#opt-in-alias-model-names).
+
+### `ocx export --client <opencode|pi|omp|hermes|openclaw|kimi|gajae|dsh|mcode|zcode|prime|aside|raycast|omo|cline|kilo|commandcode|droid>`
+
+Imprima una configuración de cliente conectada al proxy en ejecución. El comando serializa el bloque del proveedor `opencodex` (URL base, lista de modelos y el marcador de posición de referencia de credenciales o loopback del cliente) en el formato nativo del cliente seleccionado.
+
+El proxy debe estar ejecutándose; el comando resuelve su puerto activo, usa el catálogo actual
+(`/api/models` o la exportación del cliente en el servidor) y emite solo los modelos que Codex puede ver actualmente.
+
+Las exportaciones de OpenCode y Kilo preservan los límites efectivos del modelo, las capacidades conocidas, las opciones de razonamiento declaradas y los valores predeterminados, incluidos los metadatos heredados por las filas personalizadas. Las anulaciones explícitas aún ganan; no se inventan capacidades desconocidas y valores predeterminados. El lanzador de OpenCode utiliza los mismos metadatos. Consulte [Integraciones de clientes](/es/guides/integrations/) para conocer el comportamiento de actualización y actualización administrados.
+
+| Bandera | Medidas adoptadas |
+| --- | --- |
+| `--client <opencode\|pi\|omp\|hermes\|openclaw\|kimi\|gajae\|dsh\|mcode\|zcode\|prime\|aside\|raycast\|omo\|cline\|kilo\|commandcode\|droid>` | Requerido. Selecciona el dialecto de configuración del cliente. |
+| `--json` | Imprima el documento generado como JSON en stdout para scripts. Esto es JSON incluso cuando el formato nativo del cliente seleccionado es YAML, TOML o JSON5. |
+| `--out <path>` | Escriba el formato de configuración nativo del cliente en `<path>`. Se niega a reemplazar un archivo existente. |
+| `--force` | Permite que `--out` reemplace un archivo existente. |
+
+```bash
+ocx export --client opencode                     # config plus destination, merge warning, and counts
+ocx export --client pi --json > pi-models.json   # JSON document for a pipe or a diff
+ocx export --client omp --out ./omp-models.yml    # native OMP YAML
+ocx export --client opencode --out ~/opencodex-opencode.json
+```
+
+Sin `--json`, la configuración generada conduce, luego la ruta de destino canónica, la advertencia de fusión, la línea de exportación env donde el cliente tiene uno y un recuento de modelos con cuántas filas omite los límites de contexto (el cliente aplica sus propios valores predeterminados para esos).
+
+| Cliente | Destino canónico | Descargar nombre de archivo | Env var |
+| --- | --- | --- | --- |
+| `opencode` | `~/.config/opencode/opencode.json` (`XDG_CONFIG_HOME` gana cuando se establece) | `opencode.json` | `OPENCODEX_OPENCODE_API_KEY` |
+| `pi` | `~/.pi/agent/models.json` (`PI_CODING_AGENT_DIR` gana cuando se establece; se rechaza un valor relativo) | `pi-models.json` | ninguno - el bloque lleva el literal `opencodex-loopback` |
+| `omp` | `~/.omp/agent/models.yml` (`OMP_PROFILE` gana sobre `PI_PROFILE`, incluso cuando está vacío; los perfiles con nombre usan el nombre de directorio `PI_CONFIG_DIR` relativo a la casa e ignoran `PI_CODING_AGENT_DIR`, mientras que el perfil predeterminado permite que `PI_CODING_AGENT_DIR` gane) | `omp-models.yaml` | Ninguno - Loopback placeholder |
+| `hermes` | `~/.hermes/config.yaml` | `hermes-config.yaml` | `OPENCODEX_HERMES_API_KEY` |
+| `openclaw` | `~/.openclaw/openclaw.json` | `openclaw.json5` | `OPENCODEX_OPENCLAW_API_KEY` |
+| `kimi` | `~/.kimi-code/config.toml` | `kimi-config.toml` | Ninguno - Loopback placeholder |
+| `gajae` | `~/.gjc/agent/models.yml` | `gajae-models.yaml` | marcador de posición de bucle de retroceso no secreto |
+| `dsh` | `$DSH_HOME/settings.yaml` (por defecto `~/.dsh/settings.yaml` ) | `settings.yaml` | ninguno - marcador de posición de portador de bucle de retorno no secreto |
+| `mcode` | `~/.minimax/config.yaml` (`MINIMAX_DATA_DIR`, luego el legado `MAVIS_DATA_DIR`, gana cuando se establece; se rechaza un valor relativo) | `mcode-config.yaml` | Ninguno - Loopback placeholder |
+| `zcode` | `~/.zcode/v2/config.json` (`dataBaseDir` en la página de inicio predeterminada `setting.json` reubica la raíz; `ZCODE_DATA_DIR` gana cuando se establece; se rechazan los valores relativos) | `config.json` | Ninguno - Loopback placeholder |
+| `prime` | `~/.prime/agent/models.json` (`PRIME_AGENT_CODING_AGENT_DIR` gana cuando se establece; se rechaza un valor relativo) | `prime-models.json` | Ninguno - Loopback placeholder |
+| `aside` | `~/.aside/u/<account>/models.json` para la cuenta de Aside `accounts.json` nombres como actual; un manifiesto ilegible se rechaza en lugar de por defecto a una cuenta | `aside-models.json` | Ninguno - Loopback placeholder |
+| `raycast` | `~/.config/raycast/ai/providers.yaml` en macOS y Windows por igual (Raycast no honra `XDG_CONFIG_HOME`) | `raycast-providers.yaml` | ninguno - solo loopback, no se escribe ninguna entrada `api_keys` |
+| `omo` | `~/.omo/agent/models.json` (`OMO_CODING_AGENT_DIR`, luego `SENPI_CODING_AGENT_DIR`, luego `PI_CODING_AGENT_DIR` gana en ese orden cuando se establece; se rechaza un valor relativo) | `omo-models.json` | Ninguno - Loopback placeholder |
+| `kilo` | primero existente `kilo.jsonc`, `kilo.json`, `opencode.jsonc`, `opencode.json`, o `config.json` bajo `~/.config/kilo` (`XDG_CONFIG_HOME` reubica ese directorio); utiliza `kilo.jsonc` cuando no existe ninguno | `kilo.jsonc` | `OPENCODEX_KILO_API_KEY` |
+| `commandcode` | `~/.commandcode/providers.json` (en Windows con el inicio predeterminado: usar `HOME ?? USERPROFILE` solo si no está en blanco y Windows-absoluto, de lo contrario `homedir()`; se conserva una vivienda suministrada por separado; adjuntar `.commandcode\providers.json`) | `providers.json` | solo loopback; `apiKey: false`; no hay variable de entorno |
+| `droid` | `~/.factory/settings.json` ( `%USERPROFILE%\.factory\settings.json` en Windows) | `factory-settings.json` | loopback solamente; no hay variable de entorno |
+
+La exportación DSH administrada requiere DSH 0.1.0-rc.6 o más reciente y solo posee `llm-pi-ai.providers.opencodex`. DSH recarga ese proveedor; el modelo predeterminado del usuario y `deepseek-official` permanecen intactos. Esta exportación es solo loopback y no tiene credenciales reales. La importación de DSH 0.1.7 y más reciente `settings.yaml` una vez en el primer perfil que arranca y luego lo cambia el nombre, por lo que la integración del panel escribe el mismo proveedor en la fila `llm-pi-ai` del perfil de escritorio `$DSH_HOME/profiles/desktop/cordis.patch.yml` una vez que existe ese perfil.
+
+OpenCode interpola `{env:OPENCODEX_OPENCODE_API_KEY}`. Las exportaciones de Pi y OMP generadas no requieren una variable de entorno: cada una lleva el marcador de posición literal `opencodex-loopback`. Esto es soportante porque ambos clientes resuelven `apiKey` mientras construyen sus listas de modelos y ocultan a todo el proveedor cuando una configuración existente contiene una referencia env no establecida. El proxy nunca comprueba el marcador de posición generado en loopback. OMP admite encabezados a nivel de proveedor, pero esta integración inicial permanece deliberadamente solo en bucle; se aplaza el cableado remoto `x-opencodex-api-key`.
+
+La exportación de Raycast es un documento independiente `providers.yaml` con un elemento `id: opencodex` en la secuencia `providers`: `name: OpenCodex`, el proxy `/v1` URL base, y cada modelo encaminado con su `abilities` (`tools` y `system_message` siempre soportado, `vision` de las modalidades de entrada del catálogo, `reasoning_effort` cuando el modelo tiene una escalera de esfuerzo, `temperature` para los modelos de razonamiento). Custom Providers es una función de Raycast Pro, y Raycast observa el archivo, por lo que un cambio guardado entra en vigencia sin reiniciarlo. El formato está documentado en [manual.raycast.com/ai/proveedores personalizados](https://manual.raycast.com/ai/custom-providers). No se escribe la entrada `api_keys`, por lo que esta exportación es solo loopback y se rechaza un enlace que no sea loopback.
+
+Las exportaciones de MCode, ZCode y Prime son solo loop-back por la misma razón y también llevan el marcador de posición `opencodex-loopback` en lugar de una credencial real. El agente principal lee el mismo contrato de `models.json` que Pi, por lo que las dos exportaciones producen el mismo documento; solo el destino difiere. Se rechaza una ruta relativa en cualquiera de esas tres anulaciones de entorno, porque el proxy y el cliente pueden tener directorios de trabajo diferentes y de lo contrario no estarían de acuerdo sobre qué archivo se quiere decir.
+
+ZCode 3.8.1 puede guardar los metadatos de contexto por defecto y derivados del entorno de ejecución `reasoning`, `limit.output` en las entradas generadas `provider.opencodex.models`. El estado de integración administrado trata solo aquellas adiciones documentadas como deriva actualizable. La identidad del proveedor y la configuración de conexión, incluyendo `options.baseURL`, la membresía del modelo, los nombres, las modalidades y cualquier límite de contexto OpenCodex emitido con autoridad permanecen protegidos; editándolos informa `conflict / foreign-edit` en lugar de sobrescribir el archivo. Un registro de propiedad creado por una versión anterior de OpenCodex puede recuperarse automáticamente cuando el catálogo generado no cambia. Si tanto el catálogo como el bloque cambiaron, vuelva a aplicar solo después de revisar el archivo porque el registro anterior no puede probar qué cambio fue derivado de ZCode.
+
+:::caution[Combina la configuración; no la reemplaces]
+`ocx export` nunca escribe su configuración de cliente real. El destino está impreso para que usted se fusione con mano, y `--out` se niega a sobrescribir un archivo existente sin `--force`, porque reemplazando a config destruye los otros proveedores, agentes y entradas MCP que ya están en él.
+:::
+
+Ninguna llave se serializa nunca. Los Configs llevan una referencia de entorno documentada o un marcador de posición de bucle de retroceso no secreto. Una dirección de loopback (`127.0.0.1`) sola no establece la admisión sin llave: compruebe la política de destino y el punto final. Los comandos de modelo/audio de clave seleccionada aún requieren una entrada de clave explícita en loopback. Establezca una variable referenciada solo cuando el esquema del cliente la admita y el proxy se vincule más allá del bucle de retorno; consulte [Acceso remoto](/es/reference/configuration/server/#remote-access) para conocer cómo se emiten las claves de admisión. Las claves para los propios proveedores ascendentes son una cosa completamente separada, configuradas por [Proveedores](/es/guides/providers/). La integración gjc generada utiliza un marcador de posición de bucle de retroceso no secreto y no necesita ninguna variable de entorno. Sigue siendo solo loopback; no configura las credenciales de admisión remotas.
+
+La misma carga útil es servida por `GET /api/client-config` y renderizada en la pestaña API del tablero de instrumentos, por lo que el CLI, el API y la GUI usan los mismos bytes.
+
+<a id="runtime-and-configuration"></a>
+
+## Tiempo de ejecución y configuración
+
+### `ocx system <status|settings|startup|diagnostics|sync|codex-app-server|codex-restart|update|codex-cli-update> ...`
+
+Gestione la configuración, el inicio, la sincronización, los diagnósticos y las actualizaciones en entorno de ejecución sin cabeza.
+
+`ocx system codex-restart --yes` reinicia Codex servidores de aplicaciones a través del mismo módulo que `ocx sync --restart-codex`. Se cierra y vuelve a lanzar la aplicación de escritorio Codex cuando la aplicación se lanzó antes de que se escribiera el catálogo de modelos actual o esta solicitud cambió su vinculación `model_catalog_json`, porque el selector de modelos se creó en el lanzamiento. De lo contrario, la aplicación permanece abierta, reaparece su propio servidor de aplicaciones y mantiene los borradores no guardados y las aprobaciones pendientes. Si no se puede leer el estado de la aplicación o del catálogo, se reinicia por completo. Cuando el proxy se está ejecutando dentro de la aplicación Codex, el reinicio del escritorio se niega con un mensaje procesable en lugar de prometer un traspaso que no puede completar.
+
+Un enlace `model_catalog_json` modificado por esta solicitud también fuerza el reinicio del escritorio, incluso cuando el shell se inició después de que se escribió el archivo de catálogo.
+
+```bash
+ocx system settings --stream-mode eager-relay
+```
+
+Otros booleanos del sistema aceptan `on`/`off`: `--show-codex-credits`, `--account-picker`, `--main-account-hard-lock`, `--ultra-fast-tier` y `--fast-rows`. Escriben solo campos explícitos y pueden combinarse con las opciones del sistema existentes. Mostrar créditos es una preferencia de visualización, no una opción de crédito pagado; el sistema Ultra Fast está separado del proveedor Fast.
+
+Ultra Fast es una configuración opt-in, por defecto desactivado. Con `--ultra-fast-tier on`, el catálogo generado agrega la opción de velocidad ultrarrápida a `gpt-6-astra` y `gpt-6.1-sol` nativos (incluidas las filas vinculadas a la cuenta), por lo que el selector Codex lo ofrece junto a Fast. Ultrafast requiere un plan ChatGPT elegible; el catálogo no puede verificar eso, así que active la configuración solo si su plan lo incluye. Otros modelos y la velocidad predeterminada no se modifican.
+
+Para los modelos enrutados, la convergencia de sincronización y catálogo retiene las entradas `ultrafast` suministradas por el operador de una fila enrutada existente en `service_tiers` y `additional_speed_tiers` junto con su capacidad Fast actual. Las declaraciones pertenecen a la pieza exacta del proveedor/modelo; no se copian a otros modelos. La configuración no crea declaraciones faltantes ni restaura modelos eliminados. Apagarlo elimina Ultra Fast de las filas enrutadas ordinarias y la opción nativa generada en la siguiente regeneración del catálogo.
+
+El modo Fast del proxy decide lo que llega al backend: cuando no está configurado, una solicitud Ultrafast seleccionada se reenvía como `service_tier: "ultrafast"`; `fastMode: true` reemplaza cualquier nivel con Fast (`priority`), y `fastMode: false` elimina el nivel. Deje el modo Rápido sin configurar para usar Ultrarápido.
+
+```bash
+ocx system settings --json
+ocx system settings --show-codex-credits on --json
+ocx system settings --json
+```
+
+Al escribir las nuevas opciones se devuelve `{ok:true, settings: observedFields, catalogRefreshPending}`. Ultra Fast consulta el mismo destino mediante GET porque PUT omite ese valor. Si la observación falta, no coincide o la lectura falla, el resultado conserva `verification:"unverified"`, incluye `unverifiedFields` y termina con un código distinto de cero tras aceptar el cambio; los valores solicitados nunca sustituyen a las observaciones. Los controles de escritorio combinados conservan los valores guardados, los efectivos y el resultado de aplicación. Que el catálogo esté pendiente o la aplicación nativa se difiera o rechace es distinto de que una opción se haya guardado. Un estado pendiente falso no demuestra que todos los clientes hayan recargado.
+
+`ocx system update` actualiza el propio OpenCodex. La superficie de inspección separada Codex CLI es:
+
+```bash
+ocx system codex-cli-update check --json
+```
+
+`check` no consulta ningún registro de paquetes e inspecciona evidencia acotada de la procedencia
+del candidato configurado, incluidos su ubicación y propiedad con datos sensibles ocultos.
+El contexto confiable del lanzador publicado autentica la instantánea del candidato, no una ejecución
+correcta de Codex. En POSIX, la selección solo se certifica cuando el resolvedor del entorno de ejecución
+selecciona el mismo candidato canónico del entorno sin ejecutarlo. Un manifiesto npm-global vinculado
+puede establecer `managed: true` si demuestra la propiedad y, cuando se informa una versión del
+candidato, coincide con la del manifiesto; los candidatos persistentes siguen sin certificar.
+El informe JSON expone `candidateAvailable`, `candidateVersion`, `candidateSource` y `selectionAttested`.
+Inspeccionar el candidato requiere un contexto confiable del lanzador publicado; arrancar directamente
+con Bun o desde el código fuente no aporta esa prueba, ignora los candidatos del entorno y persistentes
+y puede informar `candidate_unavailable` en POSIX.
+
+En Windows x64, un `codex.cmd` npm estándar con ruta absoluta capturada por ese contexto puede
+considerarse administrado cuando los handles locales mantenidos abiertos vinculan su paquete,
+un par Node/npm del prefijo o el par de metadatos del PATH capturado ligado a la arquitectura del
+lanzador, y el primer ejecutable de plataforma de respaldo dentro del prefijo. Ese par de metadatos
+no certifica qué intérprete seleccionaría una invocación CMD posterior. Las rutas del plan y las raíces
+configuradas de gestores de versiones deben usar sus nombres DOS largos canónicos; los alias,
+las raíces inaccesibles y los puntos de reanálisis dejan la instalación sin administrar. Los demás
+diseños de Windows siguen aplazados o sin administrar. Windows nunca consulta el estado persistente:
+sin un candidato capturado del entorno informa `windows_inspection_deferred`, en lugar de
+`candidate_unavailable`, porque no puede observar si Codex CLI está instalado. El comando no ejecuta
+Codex ni un gestor de paquetes, no repara shims, no escribe configuración ni caché, no detiene procesos
+ni instala nada. Las instalaciones independientes, los paquetes de aplicación, los gestores de versiones
+reconocidos y los shims ambiguos o no verificados se informan como no administrados o desconocidos;
+nunca se clasifican como administrados.
+
+En Windows, un comando desnudo capturado como `CODEX_CLI_PATH=codex`, una ruta remota o una ruta de dispositivo informa `candidate_path_unavailable` en su lugar. Esos casos tienen un candidato capturado; su trayectoria no es elegible para esta inspección.
+
+<a id="read-only-codex-cli-update-plan"></a>
+
+#### Plan de actualización de solo lectura Codex CLI
+
+```bash
+ocx system codex-cli-update plan --channel latest --json
+```
+
+Ejecuta el comando mediante el lanzador Node publicado con el `CODEX_CLI_PATH` deseado en el entorno
+del shell. El plan requiere una instalación npm-global certificada y una versión vinculada del
+manifiesto del paquete. Windows solo admite un `codex.cmd` npm estándar indicado mediante una ruta
+absoluta explícita, con las herramientas Node/npm vinculadas mediante handles mantenidos abiertos:
+se usa el par del prefijo cuando existe y, en caso contrario, el par del PATH capturado ligado a la
+arquitectura del lanzador. La selección solo por PATH, los envoltorios de arranque automático de
+OpenCodex y las alternativas globales o del proveedor siguen aplazados. El comando consulta el
+registro oficial npm para obtener una versión exacta, integridad SHA-512 y un tarball del mismo origen,
+usando el PATH capturado del lanzador y configuración, caché y registros npm temporales aislados.
+Se siguen admitiendo los ajustes de proxy y `NODE_EXTRA_CA_CERTS`; la limpieza se intenta sin garantía.
+No se ejecuta ningún comando Codex.
+
+Un plan aplicable devuelve `applicable: true` y un `planId` determinista que vincula la plataforma,
+los hashes de la raíz y del contenido instalado, la versión instalada, el canal y los archivos exactos
+de los paquetes principal y de plataforma. El plan no se guarda. Rechaza versiones anteriores o ya
+instaladas, sesiones Codex activas y observaciones incompletas de procesos. Las consultas de metadatos
+admitidas en Windows usan el Node/npm observado con handles coincidentes mantenidos abiertos.
+Windows x64 solo puede producir un plan aplicable para un prefijo npm acotado con permisos de
+escritura verificados; otros prefijos observados conservan `windows_apply_disabled`. Las sesiones
+activas o desconocidas siguen causando rechazo antes. Los diseños de Windows no admitidos devuelven
+`windows_inspection_deferred` antes de consultar el registro o los procesos. Un rechazo termina con 0:
+inspecciona `applicable` y `refusal`. Los argumentos de instalación mostrados son orientativos.
+Este comando no instala nada, no cambia el estado de la aplicación ni envía señales a las sesiones.
+Un identificador de plan por sí solo no autoriza instalar: aplicar exige una confirmación explícita adicional.
+
+<a id="confirmed-codex-cli-apply-and-job-status"></a>
+
+#### Aplicar una actualización confirmada de Codex CLI y consultar el trabajo
+
+```bash
+ocx system codex-cli-update apply --plan-id <32-hex> --yes --request-id <stable-key> --json
+ocx system codex-cli-update status <job-id> --json
+```
+
+La aplicación admite la CLI npm-global administrada y seleccionada en Linux/macOS, sin shim,
+y el diseño npm restringido de Windows x64. Revalida el plan aprobado bajo un bloqueo exclusivo
+de instalación, verifica los archivos exactos de los paquetes principal y de plataforma, los instala
+sin red y con los scripts de ciclo de vida desactivados, y comprueba los archivos instalados y la versión
+de la CLI seleccionada. Nunca detiene sesiones de Codex existentes: si hay procesos activos o no se
+conoce su estado, rechaza la actualización.
+
+Windows admite prefijos compartidos con ACL verificadas y sin rutas con puntos de reanálisis.
+La observación incluye paquetes y shims ajenos, con límites de 4,096 entradas, 512 MiB en total
+y 384 MiB por archivo. Deben conservarse sus bytes e identidades. Los prefijos mayores o inseguros,
+ARM64, la reparación de shims, las aplicaciones nativas y otros gestores de instalación siguen sin
+admitirse. Si no se conoce la duración de los hijos o la limpieza de handles queda incompleta,
+se conservan la preparación y el bloqueo de instalación; no borres el bloqueo para reintentar.
+La lectura posterior incluye archivos auxiliares, raíces de respaldo nuevas o ausentes y el archivo
+de bloqueo oculto de npm. `not_applied` significa que se observó sin cambios el estado de instalación
+dentro del ámbito inspeccionado, no que npm no haya hecho E/S en ningún lugar.
+
+Los directorios de instalación y preparación deben tener propietarios y permisos POSIX confiables en toda su cadena de directorios. Las rutas de instalación inseguras producen `installation_prefix_unsupported` o `installation_paths_untrusted`; las raíces temporales inseguras producen `staging_path_untrusted`. Usa un directorio temporal privado bajo directorios confiables; se admiten raíces temporales de root con el bit sticky.
+
+Durante la instalación y verificación, el inicio de sesiones de Codex bajo control de OCX, los
+reinicios de Desktop y los cambios de selección del entorno de ejecución o shim informan de que están
+ocupados. Mientras no se confirme la terminación del instalador o del proceso hijo de verificación,
+la admisión sigue cerrada. Se recupera cuando se demuestra que el grupo de procesos bajo control de
+OCX ya no existe, incluso si el hijo de verificación terminó después del plazo para recogerlo.
+Perder el worker antes de confirmar también restaura la admisión; su cierre por sí solo después
+de confirmar no basta. Los registros de recuperación persistentes conservan esta exclusión tras
+reiniciar el proxy. En Windows, la recuperación comprueba el Job exacto del instalador o verificador
+y la identidad original de creación del proceso; todos los miembros del Job deben haber terminado.
+Los fallos de acceso mantienen cerrada la admisión y nunca detienen un instalador. Una identidad de
+proceso hijo ausente, registros parciales o evidencia de actividad inaccesible requieren inspección.
+Un registro completo de estado final que quedó pendiente del renombrado que lo publica puede
+restaurar la admisión tras un reinicio si se verifica su propietario exacto y que ya no existen el padre
+ni el grupo. En Windows, una identidad completa de un hijo pendiente también puede restaurar la
+admisión si coincide con el propietario activado y el Job, la prueba final del guardián es válida y
+se demuestra que ya no existen el padre, la instancia exacta del proceso hijo ni ningún miembro del
+Job. Si falta la prueba, las escrituras pendientes incompletas o activadas todavía requieren
+inspección; la muerte del guardián por sí sola no permite reabrir la admisión.
+
+La recuperación no modifica un resultado ambiguo, no reintenta la instalación ni recupera un bloqueo de instalación abandonado. Sin historial de recuperación, un `OPENCODEX_HOME` alcanzado mediante un enlace simbólico, o con un enlace en un directorio superior, permite estas operaciones ordinarias. Con historial, la admisión lee el destino canónico protegido del directorio de estado; las rutas de recuperación inseguras siguen informando de que están ocupadas. Esto no relaja los requisitos del actualizador para las rutas de instalación o configuración. Reparar shims, actualizar aplicaciones nativas o usar otros gestores de instalación sigue sin admitirse.
+
+La aplicación termina con código 0 solo si el trabajo queda `applied`. Los estados `not_applied`, `refused`, `ambiguous` y los trabajos duplicados aún pendientes terminan con 1, también con `--json`. La consulta de estado lee el mismo registro privado sin necesitar un proxy en ejecución ni un token del dashboard. Si se pierde una respuesta, repite el mismo identificador opcional de solicitud: la misma clave y el mismo plan devuelven el trabajo original; reutilizar la clave con otro plan se rechaza.
+
+El registro privado conserva hasta 64 trabajos, incluidos los terminados, sin purga automática. Al llegar al límite, rechaza identificadores nuevos con `store_full`; los reintentos coincidentes siguen devolviendo su trabajo original. La gestión de capacidad y la recuperación del operador quedan para un aporte separado que debe conservar esta deduplicación. Un registro de admisión ocupado produce `job_store_busy` (HTTP 503 con `Retry-After: 1`); los fallos permanentes no incluyen una cabecera de demora de reintento. Si el estado CLI no existe o no puede leerse, devuelve `job_unavailable` y un código distinto de cero. Un fallo al guardar la finalización no vuelve a ejecutar el instalador ni convierte un resultado incierto en un éxito confirmado.
+
+Un resultado ambiguo nunca se reintenta ni se revierte automáticamente. Tras reiniciar el proceso propietario, un trabajo sin terminar informa de propiedad desconocida en lugar de afirmar que el proceso anterior terminó. Inspecciona el resultado del trabajo, los procesos hijos, el bloqueo y los errores de limpieza; el código de salida del comando por sí solo no demuestra qué se instaló.
+
+La API de administración ofrece lecturas autenticadas del plan y del estado, y admite la aplicación confirmada desde una sesión GUI confiable de loopback. `ocx start` mediante el lanzador Node publicado aporta la instantánea de inspección necesaria; el inicio directo con Bun o con el sidecar compilado no aporta esa prueba. El panel de actualización del dashboard queda para otro aporte.
+
+<a id="explicit-installation-observation-on-windows-x64"></a>
+
+#### Observación explícita de la instalación en Windows x64
+
+```text
+ocx system codex-cli-update attest [--json]
+ocx system codex-cli-update attest --candidate <absolute-path> --npm-prefix <absolute-path> --npm-cli <absolute-path> --node <absolute-path> [--json]
+```
+
+`attest` es un opt-in, observación de solo lectura de una instalación Windows x64 npm. Sin opciones, identifica el candidato seleccionado a partir de la instantánea del lanzador de prueba: el `CODEX_CLI_PATH` configurado o el primer `codex` en el PATH capturado, con un envoltorio OpenCodex que resuelve su respaldo `codex.opencodex-real.cmd` npm renombrado. Suministrar los cuatro caminos absolutos anula el descubrimiento; el descubrimiento solo propone caminos y la observación manual sigue siendo la autoridad. `--candidate` debe nombrar el estándar npm `<prefix>/codex.cmd` o `<prefix>/node_modules/@openai/codex/bin/codex.js`. `--npm-cli` debe terminar en `node_modules/npm/bin/npm-cli.js`; `--node` nombra un `node.exe` explícito. Los paquetes de aplicaciones, los diseños de administradores de versiones reconocidos, las shims opencodex sin su respaldo npm y los envoltorios personalizados son rechazados.
+
+Los controladores nativos mantienen los directorios y archivos antecesores durante las lecturas limitadas. Se rechazan las plataformas no compatibles, los puntos de reanálisis y las uniones de directorio, los procesos de escritura en conflicto, las rutas inseguras y los archivos demasiado grandes. El informe fijo no contiene rutas: `status` es `observed` o `refused`, con `installationIdentityObserved`; `selectionAttested`, `managed` y `applyAllowed` permanecen `false`. Compruebe `status`, no solo el código de salida del proceso: un rechazo informado puede salir con 0.
+
+Una identidad o resumen observado describe esos archivos durante esta observación. No es un permiso de actualización duradero y no prueba el entorno de ejecución seleccionado, el instalador anterior, la configuración efectiva del npm o la autenticidad de la herramienta. El ejecutable Node suministrado solo se observa; no se ha demostrado que sea el que seleccionaría un lanzador. No se ejecuta ningún destino; no se produce ninguna solicitud de registro, instalación, escritura de configuración o control de procesos. Los criterios independientes de `check`/`plan` para Windows descritos antes pueden establecer evidencia de planificación de solo lectura; `attest` sigue limitado a la observación.
+
+### `ocx config [show|get|set|unset|validate|export|import] ...`
+
+`ocx config [show] [--json] [--source]` muestra la configuración local sin un proxy en ejecución. Omitir `show` también funciona con cualquiera de las banderas o ambas, en cualquier orden. `--source` incluye campos de fuente de diagnóstico, error y advertencia y solo se acepta para su visualización. `--json` puede preceder a una acción explícita; no cambia qué acción se ejecuta. Se rechazan las banderas `--json` o `--source` repetidas y los argumentos desconocidos.
+
+Inspeccione y modifique de forma segura la configuración validada del OpenCodex. `show` y `get` secretos de máscaras. Importar valida antes de escribir y requiere `--yes`.
+
+La visualización y la mutación eliminan las credenciales de las URL proxy al tiempo que retienen el host y el puerto. `direct` y los valores de proxy sin credenciales se mantienen legibles. `export` conserva las credenciales para que la copia de seguridad pueda restaurar la configuración; almacenar los archivos exportados como secretos.
+
+<a id="usage-from-a-connected-client"></a>
+
+### Uso desde un cliente conectado
+
+`ocx usage` lee el concentrador conectado con la clave de datos registrada de este cliente. La salida humana identifica la fuente del concentrador y el alcance de la clave del cliente; `--json` devuelve los mismos datos de alcance. Los filtros de rango, superficie, proveedor / modelo y los límites personalizados `--since` / `--until` permanecen disponibles. Los desgloses de cuentas y los registros de otros clientes no se comparten. Un concentrador antiguo o no disponible produce un error explícito en lugar de sustituir el uso local; actualice el concentrador si no admite esta lectura.
+
+El punto final del plano de datos de solo lectura es `GET /v1/usage`, usando `x-opencodex-api-key` con una clave de cliente configurada. En todo el entorno y las claves de administración son rechazadas. Acepta `range`, `surface`, `provider`, `model`, `since` y `until`; se rechazan las opciones desconocidas / repetidas y los identificadores de clave seleccionados por el llamante. Las filas sobredimensionadas omitidas retienen la advertencia explícita de historial incompleto.
+
+<a id="explain-a-listed-request"></a>
+
+## Explicar una solicitud listada
+
+La salida `ocx logs` humana incluye `id=<request-id>`. Pase ese valor a `ocx logs explain <request-id>` para inspeccionar las decisiones de enrutamiento. Las filas sin ID o con caracteres de control en su ID omiten el campo en lugar de mostrar una clave de búsqueda diferente. JSON y la salida JSONL conservan su esquema existente.
+
+<a id="routing-profile-lookup-status"></a>
+
+## Estado de búsqueda del perfil de enrutamiento
+
+`ocx route policy show <id>` sale con 4 cuando el perfil no existe. Los argumentos de comando ausentes o no válidos producen el código de salida 2. Los scripts pueden distinguir un perfil que falta del uso incorrecto.
+
+<a id="upstream-error-details"></a>
+
+## Detalles de error ascendentes
+
+Cuando una envolvente de error ascendente contiene varios campos de mensaje, OpenCodex usa la primera cadena no en blanco en su orden de prioridad establecido. Los campos vacíos o mal formados ya no ocultan un diagnóstico alternativo válido.
+
+<a id="forced-claude-code-subagent-model"></a>
+
+### Modelo de subagente forzado Claude Code
+
+La página Subagentes ofrece **Forzar un modelo para todos los subagentes**, una opción **desactivada de forma predeterminada**. Selecciona un identificador disponible en la lista, como `combo/tev-auto`, y después activa la opción. Primero se ofrece la lista de modelos; las entradas guardadas que ya no estén disponibles no se pueden usar como destino forzado.
+
+`ocx agent subagents force combo/tev-auto` conjuntos `claudeCode.subagentModelForce`; `ocx agent subagents force -` lo aclara. `ocx agent status` informa de la configuración. `GET /api/subagent-models` devuelve `force`, `forceAvailable` y `forceStatus`; `PUT` acepta `{ "force": "combo/tev-auto" }` o `{ "force": null }` sin cambiar la lista. Omitir `force` lo deja sin cambios. Los objetivos inválidos o no expuestos son rechazados en la escritura; los objetivos obsoletos son reportados y omitidos en el lanzamiento.
+
+Esto tiene efecto en el **siguiente inicio enrutado de `ocx claude`**, inyectando `CLAUDE_CODE_SUBAGENT_MODEL` como un alias proxy explícito (con `[1m]` solo para una ventana autorizada de un millón de tokens; los objetivos nativos Claude usan un alias nativo reversible) y `CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1`. Cada variable no vacía exportada por el shell gana independientemente. Los lanzamientos nativos no inyectan ninguna variable; el plano `claude` no se ve afectado. No hay archivos de plugin o `settings.json` se modifican por esta configuración.
+
+Claude Code **2.1.257 o más reciente** es necesario para la fuerza. Los argumentos de modelo de complemento y agentes incorporados (incluyendo Explorar/Planear) y por llamada se anulan. Las bifurcaciones y las habilidades de subagente con `model: inherit` mantienen el modelo de conversación principal. El bucle principal y los sidecars de pequeño-rápido no se ven afectados. Los archivos de la lista existentes permanecen disponibles.
+
+El panel de control advierte sobre versiones antiguas o desconocidas de CLI, objetivos no disponibles y cualquiera de las variables ya presentes en `settings.json` → `env` (que anula env de lanzamiento). La detección es de solo lectura y local en el servidor: no puede inspeccionar otro shell de lanzamiento, otra máquina o la configuración local del proyecto. Un resultado desconocido no es prueba de apoyo a la fuerza.
+
+
+`--jev-effort-mode decide|client` conserva el ajuste si se omite. `client` mantiene el destino de JEV y delega el esfuerzo a la política Combo ordinaria; un `decide` explícito borra `client`. La integración Command Code solo escribe `providers.json`: nunca escribe `~/.commandcode/auth.json`, porque Desktop necesita su propio inicio de sesión.
diff --git a/docs-site/src/content/docs/es/reference/cli/lifecycle.md b/docs-site/src/content/docs/es/reference/cli/lifecycle.md
new file mode 100644
index 00000000000..73ce95bee07
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/cli/lifecycle.md
@@ -0,0 +1,871 @@
+---
+title: "Ciclo de vida de la CLI"
+description: "Comandos de instalación, inicio, parada, servicio, diagnóstico, sincronización y actualización."
+---
+
+Estos comandos instalan, ejecutan, inspeccionan, reparan y actualizan el proxy local opencodex y su integración Codex.
+
+<a id="discover-before-starting-services"></a>
+
+## Descubre antes de comenzar los servicios
+
+`ocx help`, `ocx help <family>` y `ocx help <family> <leaf>` están fuera de línea. Utilice `ocx help --all` cuando la raíz compacta es insuficiente. La ayuda, la validación de configuración local y la inspección local de laboratorio no requieren iniciar un proxy.
+
+Antes de un flujo de trabajo de administración en vivo, ejecute `ocx ready --json` y `ocx status --json`. La preparación distingue `pending`, `failed` y `unreachable`; solo `ready: true` confirma la preparación. Compruebe el objetivo y `versionSkew.relation`: `unknown` no es prueba de versiones coincidentes. Un desajuste de versión requiere resolver la instalación prevista, no intentar repetidamente una bandera más nueva contra un servidor más antiguo.
+
+Las convenciones de salida y de código de salida son específicas de cada comando. `ready` y `resolve` rechazan argumentos inválidos con 64, mientras que `doctor --json` no está soportado y sale con 2. Una solicitud de guardado local o de reinicio aceptado satisfactoriamente no prueba convergencia; lea el recibo del comando y vuelva a verificar el estado después de la operación solicitada.
+
+Cuando el descubrimiento de destino en vivo no encuentra proxy, comandos de directiva/catálogo, uso de alcance de clave e informe de sincronización de perfil de Aside: "Proxy no se está ejecutando. Inicie el proxy deseado con: ocx start. No se envió ninguna solicitud." Una solicitud de administración que se envió puede tener un resultado de escritura incierto; leer de nuevo desde el objetivo previsto antes de volver a intentar. Los rechazos de integración de cliente heredados agregan una guía de recuperación fija basada en la razón del rechazo (nunca el propio texto del escritor); los avisos de respaldo y recuperación residual permanecen disponibles.
+
+`ocx system update run --yes` imprime el ID de trabajo aceptado y el estado del trabajo observado. Síguelo con `ocx system update status <job-id>`; la aceptación no establece una instalación o reinicio exitosos. `--json` conserva la respuesta completa del servidor.
+
+<a id="setup"></a>
+
+## Configuración
+
+### `ocx init` · `ocx setup`
+
+Asistente de configuración interactiva (`setup` es un alias de `init`). Indica un proveedor (preestablecido o personalizado), una clave API (literal o `${ENV}`), un modelo predeterminado y un puerto proxy; guarda `~/.opencodex/config.json`; opcionalmente inyecta el proxy en `$CODEX_HOME/config.toml` (predeterminado `~/.codex/config.toml`); y opcionalmente instala la shim de inicio automático Codex.
+
+<a id="proxy-lifecycle"></a>
+
+## Ciclo de vida del proxy
+
+### `ocx start [--port <port>] [--socks5 [host:port] | --socks5-off]`
+
+Inicie el servidor proxy (puerto preferido `10100`). Escribe el estado PID / runtime-port y se niega a iniciar una segunda instancia en vivo. Cuando el puerto preferido está ocupado, `start` pregunta al titular quién es y se detiene en cualquier sentido: se niega rotundamente cuando un opencodex responde allí, e informa a un titular no identificado de lo contrario. Nunca mueve al oyente a otro puerto por sí mismo, porque eso dejaría el primer proxy en funcionamiento y volvería a apuntar al Codex en el segundo. Todavía se rechaza un `--port` explícito diferente cuando el proxy en vivo comparte este `OPENCODEX_HOME`, porque tanto la contabilidad de gastos solo observada como forzada escriben el mismo diario. Use un `OPENCODEX_HOME` separado para un hermano independiente; `port: 0` solo pide al sistema operativo el puerto de esa instancia y no separa su estado. Al inicio, sincroniza los modelos de cada proveedor en el catálogo de Codex. Al apagarlo, restaura el Codex nativo, a menos que se haya lanzado como un servicio administrado (`OCX_SERVICE=1`). Un hermano iniciado junto a un proxy en ejecución no hace ninguna de las dos cosas: sirve solicitudes directas solo en su propio puerto, y Codex, Grok y Claude permanecen apuntando al proxy que ya se estaba ejecutando. Con un `OPENCODEX_HOME` separado, el inicio comprueba el registro de entorno de ejecución del hogar predeterminado y administra Grok y Codex destinos de bucle de retorno para un propietario de opencodex en vivo antes de la sincronización. Una casa personalizada sin propietario en vivo todavía se sincroniza normalmente; `ocx sync` y `ocx grok apply` explícitos permanecen disponibles. Detener a ese hermano con `ocx stop` o una señal también deja su configuración sola. Mientras se ejecuta, el proxy también mantiene Codex apuntado a sí mismo: cuando el enrutamiento opencodex en `~/.codex/config.toml` nombra otro puerto local donde no opencodex ha respondido durante aproximadamente 20 segundos (una instancia que lo volvió a apuntar y luego murió, por ejemplo), el proxy vuelve a apuntar Codex en su propio puerto e imprime una advertencia. Codex hilos abiertos mientras tanto, mantenga la dirección muerta hasta que los vuelva a abrir.
+
+`--socks5` (por defecto `127.0.0.1:10808`) guarda `config.proxy` como una URL de SOCKS5 y las rutas de salida HTTP (S) a través de un túnel real SOCKS5. `--socks5-off` borra solo ese proxy SOCKS5 guardado; no elimina un proxy HTTP. El valor sobrevive `ocx update` porque vive en config, no en el paquete instalado. Se puede incluir un nombre de usuario y una contraseña proxy en la URL, pero los registros de inicio los redactan.
+
+```bash
+ocx start
+ocx start --port 8080
+ocx start --port 10100 --socks5
+ocx start --socks5-off
+```
+
+### `ocx stop [--json]`
+
+Un Child de Remote Link sin supervisor que recibe una señal de apagado restaura Codex nativo y Grok administrado antes de liberar su listener, comprobando de nuevo la conexión atendida antes de cada escritura. La supervisión de servicio o Desktop, la propiedad de otra instancia, los traspasos de reinicio o reciclaje y los recibos pendientes de parada del padre conservan las integraciones. Durante el apagado se rechaza un reinicio vinculado con `409 runtime_stopping`. Una terminación forzada puede omitir los manejadores de señales; sigue siendo necesaria la restauración del `ocx stop` del padre. Para volver a enrutar Codex por el Home, inicia primero el Child con `ocx start`, o `ocx service start` si está instalado como servicio, y después ejecuta `ocx sync --restart-codex`. Iniciar por sí solo no restablece el enrutamiento. Sincronizar con el Child detenido también lo restablece, pero apuntaría a un listener que no está ejecutándose: inicia primero el Child.
+
+Detiene el proxy en ejecución por su PID, elimina el archivo PID y restaura Codex nativo cuando el entorno es independiente. Si hay un servicio administrado, `ocx stop` lo detiene primero para impedir que vuelva a iniciar el proxy.
+
+En un cliente conectado a un Hub, la parada conserva el enrutamiento de Codex, su catálogo y la
+configuración de Grok, incluso si se detiene correctamente mediante la API. Esos ajustes pertenecen
+a la conexión; `ocx start` vuelve a servirlos sin reinyección. Usa `ocx disconnect` para devolver Codex
+a su propia cuenta. Si un cliente conectado ya muestra enrutamiento nativo, `ocx status` indica
+`ocx sync --restart-codex` para recuperarlo.
+
+Una parada explícita en un Child de Remote Link restaura el enrutamiento y el catálogo nativos de
+Codex y los metadatos respaldados del historial de reanudación, y elimina la configuración administrada
+de Grok cuando la restauración compartida termina correctamente. La conexión guardada con Home
+se conserva; `ocx disconnect` la elimina. Para volver a usar Home desde Codex, inicia el Child con
+`ocx start` (o `ocx service start` si hay un servicio instalado) y después ejecuta
+`ocx sync --restart-codex`. Iniciar por sí solo no vuelve a aplicar el enrutamiento;
+sync no recrea el bloque de Grok. Si no se puede confirmar la titularidad de la conexión antes de
+detener el servicio, la API de parada devuelve HTTP 409 con `sharedTeardown: "refused"` y mantiene
+en ejecución el proxy y el gestor del servicio. Deja que termine cualquier conexión o desconexión
+pendiente y vuelve a intentarlo.
+
+Antes de modificar el servicio, la parada de un cliente conectado verifica el listener frente al
+registro local protegido del entorno de ejecución. Tanto los listeners de rol cliente como los proxies
+ordinarios deben demostrar esa identidad; un proxy ordinario debe además declarar, mediante una
+lectura autenticada, que conserva los ajustes al detenerse mediante API, señal y servicio.
+Los entornos antiguos o no verificados se rechazan antes de actuar. Actualiza o reinicia ese entorno
+mediante su supervisor y reinténtalo. Usa `ocx disconnect` solo si quieres liberar las integraciones
+de la conexión. Si el cliente ya está detenido, otra parada verifica que el gestor del servicio esté
+inactivo y que no haya listeners en los endpoints locales conocidos antes de devolver el resultado
+habitual de proceso ausente.
+
+Mientras OpenCodex Desktop esté abierto, `ocx stop` no mantiene detenido el proxy: la aplicación lo trata como una salida inesperada y lo inicia de nuevo, en segundos si lo había iniciado ella o en aproximadamente un minuto si solo se había conectado a él. Usa **Stop proxy** en su bandeja, para un proxy iniciado por la aplicación, o **Quit** para mantenerlo detenido. Por esa misma razón, el botón **Stop** del dashboard rechaza la acción con `desktop_supervised` sin cambios cuando el proxy pertenece a la aplicación. En otros entornos, ejecuta `POST /api/stop`, salvo con el Programador de tareas de Windows: allí un contenedor puede reiniciar el proxy después de terminar la tarea. El dashboard responde `respawnable_service`, no cambia nada y pide ejecutar `ocx stop` desde fuera del proxy para verificar que no reaparezca antes de restaurar los ajustes del cliente.
+
+El panel de control también se niega cuando el proxy está ejecutando *como* el servicio launchd o systemd instalado. Detener ese administrador desde el interior del proxy terminaría el proceso antes de que se restaure el Codex nativo, dejando la configuración del cliente apuntando a un proxy que se ha ido, por lo que el panel de control devuelve `self_unload_service`, no cambia nada y le pide que ejecute `ocx stop`, lo que detiene el servicio desde el exterior y completa la restauración.
+
+Una salida proxy sola no confirma que la restauración compartida Codex / Grok tuvo éxito. Si la respuesta de parada informa de un fallo, es ilegible o no confirma el modo de desmontaje asignado, el CLI mantiene la restauración con el padre de parada después de las comprobaciones de propiedad y reaparición existentes. No entra en el repliegue forzado para un proceso que ya se ha observado que ha salido. Un aplazamiento respaldado por recibos aún deja la restauración final y la limpieza de recibos con el padre; el fracaso en restaurar la configuración del cliente compartido mantiene la parada fallida y su recibo pendiente.
+
+`ocx stop --json` ejecuta la misma parada y escribe un resumen versionado (`schema: "ocx-stop/1"`) en stdout; los mensajes de progreso van a stderr. El resumen indica el resultado (`stopped`, `not-running`, `history-incomplete`, `history-deferred` o `failed`), la clasificación del servicio y del proxy, si el entorno de ejecución está detenido y un mensaje estable de una línea. Los códigos son iguales con y sin `--json`: 0 si termina correctamente, 1 si falla, 79 si solo quedó incompleta la limpieza del historial de Codex y 80 si el desmontaje compartido se aplazó y sigue pendiente. El código 81 indica que una actualización del dashboard con reinicio transfirió el enrutamiento y catálogo de Codex al futuro proxy en vez de restaurar Codex nativo. Con 81 el proxy está detenido; el reiniciado libera el desmontaje conservado después de su primera sincronización. Si no llega a iniciarse, el siguiente `ocx stop` restaura Codex nativo.
+
+Para una adquisición aprobada por el escritorio, `ocx stop --json` también acepta el conjunto completo de `--expect-*` valores suministrados por `ocx resolve --json`. En Windows, esta parada vigilada puede detener una tarea del Programador de tareas solo cuando su definición registrada, el estado de ejecución y el antepasado de la envoltura demuestren que posee el proxy aprobado. Un servicio WinSW debe probar su ruta binaria instalada y la ascendencia PID del servicio. Después de detener cualquiera de los administradores, el CLI señala el proxy aprobado por separado y verifica que la tarea ya no se esté ejecutando, que no sobreviva ningún envoltorio y que se detenga WinSW. Un proceso `wscript.exe`, `cscript.exe` o `cmd.exe` con una línea de comandos ilegible en la cadena de supervisión del proxy aprobado (o sobrevivir bajo el administrador detenido) deja desconocida la propiedad del envoltorio, por lo que el stop vigilado no puede informar el éxito. La evidencia faltante o ilegible bloquea la parada vigilada.
+
+### `ocx restart`
+
+Cuando este CLI es más nuevo que un proxy POSIX independiente certificado, el reinicio puede detener la instalación anterior y ejecutar esta. Esta actualización vigilada requiere un hogar físico no reclamado, un proxy separado cuyo padre es PID 1, supervisión de servicio positivamente inactiva y una versión conocida CLI. Un registro de servicio launchd instalado pero descargado o systemd inactivo solo es elegible cuando no conlleva ningún reclamo de propiedad. Ambos dominios launchd deben estar ausentes; systemd debe informar inactivo con MainPID cero. La evidencia de un gerente ilegible o incierto se niega. El comando congela todos los registros de servicio y la definición de la plataforma y los verifica a través de stop, lanzamiento y publicación secundaria. Cualquier reescritura, reemplazo, cambio de permiso o creación / eliminación de registros se niega; reintente después de inspeccionar `ocx status`. El stop usa la misma conexión que probó la identidad del viejo proxy. El comando se inicia una sola vez después del apagado confirmado, luego requiere el PID hijo exacto, el punto final, la prueba de identidad nueva y la versión coincidente. La versión que falta, la parada incierta, el tiempo de espera o un reemplazo inesperado informa de un fallo sin otra parada o inicio. Si el entorno de ejecución este CLI se lanzaría sigue siendo el pequeño marcador de posición, una instalación npm en el lugar deja antes de su postinstalación, el reinicio se niega antes de detener cualquier cosa; después de una parada confirmada, espera el entorno de ejecución dentro de la misma fecha límite y no lanza nada si no llega. Windows, en primer plano, supervisado por el escritorio, servicio activo, cliente conectado y tiempos de ejecución hermanos no utilizan esta ruta de actualización; utilizar sus controles de ciclo de vida de posesión. Un proxy más nuevo o una versión incomparable aún rechaza una degradación in situ. Utilice el `ocx` de la instalación más reciente para reiniciar; inspeccione `which -a ocx` y `ocx status` para identificarlo. Los rechazos de elegibilidad nombran la razón y la siguiente acción: use el `ocx service restart` de la instalación propietaria para un servicio, el terminal propietario para un proxy en primer plano o la aplicación de servicio / escritorio propietario en Windows. La ascendencia desconocida o un objetivo cambiado requiere `ocx status` antes de cualquier reinicio.
+
+En un entorno cliente conectado (Remote Link Child o cliente Hub), `ocx restart` pide al propio entorno iniciar su reemplazo en el mismo puerto. Si el reemplazo no responde dentro del plazo, se detiene y el entorno anterior vuelve a ocupar el puerto y sigue atendiendo; el comando informa que el reinicio no se completó. Un entorno cliente administrado por un servicio o la aplicación Desktop rechaza la solicitud y sigue funcionando ("Restart not performed; the running client runtime was kept"); reinícialo con `ocx service restart` o desde la aplicación. Consulta [Paridad de aplicación de Remote Link](#remote-link-apply-parity).
+
+Si los archivos de paquete o el entorno de ejecución del Bun permanecen incompletos después de que el instalador haya salido o haya fallado, ejecute `ocx status`, detenga cualquier proxy que se ejecute a través de su propietario (`ocx stop`, o su servicio o aplicación de escritorio), luego vuelva a instalar con el mismo administrador de paquetes y vuelva a iniciarlo. Véase [Fallo de actualización](/es/troubleshooting/update-failed).
+
+Cuando un proxy se está ejecutando, pida que PID y puerto certificados exactos se reinicien en su lugar, espere a que su normal, y verificar un entorno de ejecución diferente PID en el mismo puerto. Enrutamiento y servicio gestionados La supervisión permanece instalada en todas partes; una petición incierta se observa más bien que se repite como un problema. Parada/Inicio por separado. Si no se está ejecutando ningún proxy, el comando vuelve a la posición normal. `ensure` Inicio. Si un reinicio aceptado pierde su reemplazo, el comando intenta un inicio de recuperación limitado incluso cuando el inicio automático Codex está deshabilitado, e informa de un error si no se inicia ningún proxy. Cuando el proxy inicia su propio reemplazo (ningún servicio en segundo plano lo supervisa) después del drenaje terminado normalmente, un reemplazo que sale antes de que responda se inicia de nuevo hasta dos veces. ¿Qué Las impresiones de reemplazo van a `~/.opencodex/restart-handoff.log`, que se mantiene cerca de 256 KiB: a El reinicio lo vacía una vez que alcanza ese tamaño, y el reemplazo en ejecución lo verifica una vez por minuto. Un proxy que la aplicación de escritorio OpenCodex inició no inicia su propio reemplazo: sale y la aplicación inicia el nuevo proxy en el mismo puerto. Si no se puede certificar un oyente en vivo a un PID en entorno de ejecución (incluido un proxy de actualización previa), se produce un error de reinicio Cerrado sin un `ensure` o detener/iniciar el retroceso. Después de confirmar la propiedad, el uso `ocx stop` entonces
+`ocx start` para un proxy independiente. Para un proxy administrado por servicio, use `ocx stop` seguido por
+`ocx service start` Se restablece la supervisión. Una invocación vuelve a observar las razas de descubrimiento transitorias. Un inicio fallido se vuelve a intentar solo cuando el intento anterior nunca lanzó un niño o se sabe que el niño lanzado ha salido. Si un inicio aún puede estar en ejecución, reinicie los informes del error original sin iniciar un segundo proxy, incluso cuando una investigación de salud no encuentra nada. Cuando un reinicio aceptado nunca publica un reemplazo, el comando vuelve a observar una vez antes de renunciar a — un proxy que se estrelló a mitad de reinicio lee ausente y se inicia fresco, mientras que un reemplazo que aterrizó justo después de la espera de reemplazo acortada todavía demuestra el éxito dentro del plazo general de observación. Fuera de la ruta de actualización CLI más reciente, un destino en vivo es nunca se detuvo para hacer espacio, por lo que un proceso de escucha rancio no puede ser reemplazado por un segundo Para el puerto. Cada intento fallido de inicio es seguido por un ritmo y una fuerte re-observación antes de la siguiente intento: un niño que acaba de ser lanzado puede seguir siendo vinculante, y los pasos posteriores a la salud puede haber lanzado en un proxy que ya sirve. Una lectura en vivo significa no se genera un segundo comienzo: un rechazo limpio luego da fe del éxito, mientras que un tiro se propaga como un fallo de inicio porque el trabajo posterior a la salud falló en un proceso de servicio. Durante la recuperación de un accidente después de un reinicio en vivo aceptado, el éxito requiere una entorno de ejecución PID en el puerto original: si el PID original se vuelve a leer en vivo, el reinicio falla como un reemplazo perdido en lugar de informar el éxito. Pruebas de ausencia y lanzamiento-salida confirmadas juntas permiten otro intento de inicio. Mientras que el PID anterior todavía está activo, o una sonda es incierta, la La ventana de confirmación mantiene la votación para un reemplazo dentro de la reserva en lugar de Fracasó de inmediato. Un segundo proxy nunca se genera junto a uno vivo. La espera de reemplazo termina lo suficientemente temprano como para que la ventana de confirmación aún se ajuste dentro del plazo de observación general.
+
+La recuperación del puerto después de la parada o actualización respeta una comprobación de proceso OCX fallido incluso cuando el PID se registró antes del apagado. Un soporte en vivo rechazado se deja en funcionamiento y evita la limpieza de la fila TCP. Si no se verifica, la espera de recuperación limitada puede caducar con el puerto todavía ocupado. Compruebe el titular del puerto actual y vuelva a intentar el reinicio después de que se resuelva el conflicto.
+
+### `ocx ensure`
+
+Asegúrese de que se está ejecutando un proxy en segundo plano y, a continuación, sincronice su catálogo de modelos en vivo. Si `codexAutoStart` es `false`, se imprime que el inicio automático está deshabilitado y no hace nada.
+
+Con una configuración de cliente conectado validada, `ensure` tiene éxito sin iniciar un proxy de proveedor local después de conciliar el diario del cliente. Esto no prueba ni certifica la disponibilidad del concentrador remoto. El estado del cliente no válido o no coincidente sigue fallando.
+
+### `ocx restore [back]` · `ocx eject [back]`
+
+Restaurar nativo Codex **sin** detener el proxy - tiras de las líneas de configuración inyectadas y entradas de catálogo enrutado para llanura `codex` funciona de forma nativa de nuevo. `eject` es un alias de `restore`.
+
+La salida del catálogo restaurado excluye los modelos nativos retirados, incluidos los `gpt-5.3-codex-spark`, ya sean almacenados como ID desnudos o filas calificadas para cuentas de confianza. Esto se aplica con o sin una copia de seguridad del catálogo; se conservan la copia de seguridad original y la configuración histórica seleccionada por el usuario.
+
+La restauración informa de un fallo en lugar de reemplazar los archivos de configuración modificados cuando un diario guardado carece de los hashes de inyección correspondientes. Los archivos actuales y el diario permanecen disponibles para su revisión; ver [recuperación sin hashes de inyección](/es/guides/codex-integration/#recovery-without-injection-hashes).
+
+Pase `back` para volver a señalar el plano `codex` en un proxy que ya se esté ejecutando sin cambiar el ciclo de vida del proxy:
+
+```bash
+ocx restore back
+ocx eject back
+```
+
+### `ocx recover-history --legacy-openai --yes`
+
+Recuperación explícita para versiones de desarrollo anteriores que volvieron a mapear el historial de la aplicación Codex antes de que existiera el soporte de copia de seguridad reversible. Cierre primero Codex si su base de datos de historial está bloqueada.
+
+Este es un reetiquetado amplio y destructivo: cada hilo de mensaje de usuario etiquetado actualmente `opencodex` se cambia a `openai`, `exec` se normaliza a `cli` y se establece el marcador de evento. Eso incluye la historia legítima de proveedores dedicados. Realice una copia de seguridad del estado y ejecútelo solo cuando se pretenda ese alcance completo.
+
+### `ocx recover-history --ocx-compaction <thread-id> --yes`
+
+Repare un hilo que se compactó a través de un proveedor enrutado antes de reanudarlo a través del Codex nativo. El comando lee el subproceso exacto seleccionado por UUID, guarda una copia de seguridad privada de byte por byte y, a continuación, convierte solo el estado de compactación `ocx1:` / `ocx2:` propiedad de OpenCodeX en un resumen sencillo que el Codex nativo puede reproducir. El contenido cifrado nativo y otros hilos se dejan sin cambios. Cierre el subproceso seleccionado antes de ejecutar el comando; un cambio de implementación concurrente hace que la recuperación se detenga sin reemplazar el archivo.
+
+### `ocx uninstall` · `ocx remove`
+
+Detenga el servicio y el proxy, elimine el servicio y la compensación Codex, restaure el Codex nativo y, a continuación, elimine la configuración local opencodex solo si todos los pasos de restauración tuvieron éxito. `remove` es un alias de `uninstall`. La limpieza de configuración requiere metadatos de propiedad creados por una instalación nueva; los directorios heredados o compartidos se dejan en su lugar.
+
+Cuando `ocx uninstall` se ejecuta como root o desde una terminal Windows elevada, comprueba primero que ninguna otra cuenta pueda modificar el directorio de configuración, sus antecesores ni los directorios que contiene. También comprueba que ningún enlace interno salga de ese directorio; en Windows exige que no haya enlaces. Si una comprobación falla, se detiene antes de modificar nada e indica el motivo. Ejecuta `ocx uninstall` con la cuenta propietaria, sin `sudo` ni privilegios de administrador, o restringe los directorios a esa cuenta y elimina esos enlaces antes de reintentarlo. En Windows ARM64, donde no puede determinarse la elevación, se aplica la misma comprobación; si no puede completarse, detén opencodex y elimina tú mismo el directorio de configuración.
+
+Una entrada registrada cuyo directorio padre dentro de la configuración sea un enlace simbólico o junction se conserva y se informa como ruta pendiente; el resultado es una desinstalación parcial. Sustituye ese enlace por el directorio real o elimínalo, y vuelve a ejecutar `ocx uninstall` para terminar.
+
+Ambos comandos no aceptan argumentos. Las banderas no soportadas (incluyendo `--dry-run` y `--yes`) salen con el estado de uso 2 antes del prevuelo o desmontaje; no se realizan cambios. Para obtener ayuda, ejecute `ocx help uninstall` o `ocx help remove`.
+
+<a id="status-and-health"></a>
+
+## Situación y salud
+
+### `ocx status [--json]`
+
+Estado y `ocx doctor` comparan la versión de este CLI con la del proxy en ejecución. Si el CLI es más nuevo, reinicie el proxy utilizando la instalación actual prevista; para un servicio en segundo plano, ejecute `ocx service restart`. En macOS, un sesgo de versión deja la definición de servicio byte-idéntica, por lo que `ocx service repair` no recargaría nada y mantendría el antiguo proceso en servicio. Si el proxy es más nuevo, actualice el CLI o resuelva `PATH` a la instalación prevista. Estos diagnósticos no reparan el servicio ni cambian si se permiten solicitudes.
+
+Las cadenas de versión idénticas y los marcadores de posición `unknown` / `0.0.0` suprimen la advertencia, al igual que una versión proxy ausente. El doctor no reporta marcadores de posición como un partido confirmado. Las diferentes cadenas aún producen una advertencia neutral cuando no pueden analizarse estrictamente como SemVer o difieren solo en los metadatos de compilación; ninguno de los lados se llama más antiguo. Las versiones no se recortan y no se normaliza un `v` principal. JSON expone el mismo consejo en `versionSkew`, cuyos campos permanecen `cliVersion`, `proxyVersion`, `skewed` y `warning`.
+
+En un Remote Link Child y su Home, `--json` también informa `appliedCodexSettingsDigest`, `lastApplyAt` y `runtimeStartedAt`; consulta [Paridad de aplicación de Remote Link](#remote-link-apply-parity).
+
+Imprima un resumen de diagnóstico de solo lectura: PID proxy, accesibilidad `/healthz`, URL del panel de control, ruta de configuración, proveedor predeterminado, configuración de inicio automático Codex, estado del servicio, estado de compensación y la casa Codex efectiva redactada. Solo la firma de inicio de ejecución Windows explícita y de alta confianza de Orca agrega una advertencia procesable de desajuste de App-home; nunca cambia `CODEX_HOME` automáticamente. También advierte cuando el Codex enrutamiento opencodex escribió nombres de un puerto local que el proxy en ejecución no sirve. `ocx sync` lo repara inmediatamente, y un proxy de propietario en ejecución también puede volver a apuntarlo por su cuenta una vez que nada responde en ese puerto. El estado de un hermano no lo informa, porque su enrutamiento nombra el proxy al lado del cual se ejecuta.
+
+Cuando un proxy en vivo ya ha pasado la verificación de identidad / vitalidad, `ocx status` prefiere el informe de salud de inicio certificado de ese proceso para reiniciar la seguridad y la viabilidad del servicio. Esto evita falsos negativos de una prueba de administrador de servicio local de shell que carece del entorno de administrador del servicio en ejecución. El informe en vivo se valida por esquema; si no está disponible o está mal formado, el estado vuelve al servicio local y a los diagnósticos de shim. `ocx doctor` utiliza la misma regla de live-first para su sección **Seguridad de reinicio Codex**, por lo que los dos comandos deben acordar la protección de reinicio. Si está diagnosticando una discrepancia, compare el veredicto de inicio en vivo reportado con los detalles del servicio local en lugar de tratar la sonda de shell como más autorizada.
+
+La lectura en vivo permite que la sonda de servicio limitada termine: hasta 6,5 segundos en macOS / Linux y 16,5 segundos en Windows cuando la caché de diagnóstico está fría o caducada. Cached lee el regreso rápidamente. Un tiempo de espera todavía vuelve a los diagnósticos locales; un `/healthz` saludable solo no establece protección de reinicio.
+
+El diagnóstico `clients=pending-restart(...)` enumera Codex CLI clientes que son anteriores a la inyección de enrutamiento. En macOS, los renderizadores de electrones, la utilidad y los ayudantes de crashpad bajo el marco Codex.app están excluidos de esa lista de clientes, incluidos los ayudantes cuyas rutas ejecutables contienen espacios.
+
+La salida humana también incluye un bloque **OAuth salud** después del resumen de inicios de sesión OAuth: `OAuth health:
+ok` cuando cada cuenta conocida está sana, o `OAuth health: warning` con una línea redactada por cuenta no saludable (proveedor, ID de cuenta enmascarada, estado tal como reautenticación requerida, tasa o cuota limitada o conflicto de actualización) más una sugerencia opcional `Action:`. Los identificadores de la cuenta se redactan; los tokens y los correos electrónicos nunca se imprimen. El contrato `--json` no incluye actualmente este bloque de salud.
+
+```bash
+ocx status
+ocx status --json
+```
+
+Forma de ejemplo abreviada:
+
+```json
+{
+  "schemaVersion": 1,
+  "proxy": {
+    "running": false,
+    "pid": null,
+    "health": {
+      "ok": false,
+      "url": "http://127.0.0.1:10100/healthz",
+      "message": "unreachable"
+    }
+  },
+  "dashboard": {
+    "url": "http://localhost:10100/"
+  },
+  "paths": {
+    "config": "/Users/example/.opencodex/config.json",
+    "pid": "/Users/example/.opencodex/ocx.pid",
+    "runtime": "/path/to/bun"
+  },
+  "runtime": {
+    "source": "bundled"
+  },
+  "codexHome": {
+    "effectiveCodexHome": "C:\\Users\\[USER]\\.codex",
+    "appCodexHome": "C:\\Users\\[USER]\\.codex",
+    "mismatch": false,
+    "warning": null,
+    "action": null
+  },
+  "codexAutostart": true,
+  "defaultProvider": "openai",
+  "service": {
+    "summary": "not installed (logs: /Users/example/.opencodex/service.log)"
+  },
+  "codexShim": {
+    "summary": "Codex autostart shim: not installed"
+  }
+}
+```
+
+El objeto real también incluye `listen` (puerto, nombre de host, entorno de ejecución/fuente de configuración), carga de configuración diagnósticos y diagnósticos de complementos Codex incluidos. El esquema JSON es solo aditivo: versiones futuras puede agregar campos, pero los campos existentes deben permanecer estables. Excluye intencionadamente las claves API, OAuth tokens, encabezados de autorización, contenido de solicitud, correos electrónicos e identidades de cuenta.
+
+### `ocx health [--json]`
+
+Verifique la identidad del proxy en vivo. La salida humana informa del PID y el puerto; `--json` emite `{ok, pid, port}`. El comando sale con 0 solo cuando está sano y con 1 en caso contrario, lo que lo hace adecuado para sondas de servicio.
+
+### `ocx system health [--json]`
+
+```bash
+ocx health --json
+ocx system health --json
+```
+
+La salud de la raíz es la sonda de vitalidad. La salud del sistema es una observación de gestión separada: `{status:"ok",service:"opencodex",version,uptime,pid,spendLedger}`, con tiempo de actividad en segundos. `system status` sigue siendo su configuración / inicio / memoria agregada. Una observación válida de la salud del sistema sale con 0 incluso si el libro mayor de gastos está degradado. Lea la propiedad retenida o no retenida, inicializada, configurada, degradada, `persistFailures` y `corruptRecords`; un estado ok no certifica que todos los subsistemas estén sanos. Las lecturas fallidas o malformadas siguen devolviendo un código distinto de cero con un stderr seguro, no con datos inventados.
+
+Para diagnósticos limitados, [solicitud/inyección seguir](/es/reference/cli/agents/#follow-request-windows-or-injection-sequences) se detiene en caso de error o cambio de objetivo detectado en lugar de volver a conectarse automáticamente. SIGINT sale con 130 y SIGTERM con 143. Los eventos de registro con versiones reconstruyen las ventanas observadas, no el tráfico perdido entre sondeos; la secuencia de inyección no puede excluir las brechas de reinicio / desalojo.
+
+### `ocx ready [--json] [--wait [--timeout <seconds>]]`
+
+Comprueba si el proxy está listo después de la sincronización mediante el endpoint no autenticado `GET /readyz`. Devuelve `200` cuando está listo, o `503` con `Retry-After: 1` para `pending` y el estado terminal `failed`. Su identidad HTTP depurada es `{service, version, uptime, pid, port, status}`, junto con los campos del protocolo del hub remoto `{protocol, minimumClientProtocol, managementUrl, features}`. `protocol` identifica el protocolo del hub y `minimumClientProtocol` el cliente más antiguo aceptado, para rechazar un emparejamiento incompatible antes de enviar otros datos. `managementUrl` indica el origen del plano de administración: `hub.managementPublicOrigin` cuando `runtimeRole` es `hub`; en los demás casos, el origen por el que llegó la solicitud. Se rechazan las solicitudes sin un origen HTTP(S) en lugar de adivinar uno.
+
+`features` enumera las capacidades que ofrece esta compilación para que otro nodo pueda comprobarlas sin comparar versiones: `relay-auth/<n>` identifica la versión de autenticación del relé Remote Link; `link-management-relay`, su relé de administración de solo lectura; `link-peer-report/<n>`, el informe de versión y compatibilidad de cada Child que el Home muestra en `ocx link status`; `quota-pool/1`, la consulta de administración `GET /api/quota-pool`; y `served-by-header`, el encabezado de respuesta `x-opencodex-served-by`. Las capacidades no disponibles se omiten. La lista contiene únicamente nombres fijos, nunca datos de cuentas o configuración.
+
+Los proxies antiguos sin `/readyz` se consideran `unreachable` y no se aceptan como listos; `/healthz` comprueba por separado si el proceso responde. El comando realiza una comprobación por defecto. `--wait` repite la consulta hasta que el proxy esté listo o se agote el plazo, pero termina inmediatamente al observar `failed`. El plazo predeterminado es de 45 segundos; `--timeout <seconds>` requiere `--wait` y acepta enteros de 1–300. La salida `--json` de la CLI contiene menos campos que la respuesta HTTP: `{ready, status, pid, port}`, donde `status` es `ready`, `pending`, `failed` o `unreachable`. Los códigos de salida son 0 si está listo; 1 si no está listo, sigue pendiente, falla, se agota el plazo o no es accesible; y 64 si los argumentos no son válidos.
+
+En un Child de Remote Link, la disponibilidad también incluye el enlace. Si no puede transportar solicitudes, `/readyz` devuelve `503` con `status: "pending"` y `link: {state: "unavailable", reason}`; `ocx ready --wait` sigue esperando a que se recupere. Un enlace operativo añade `link: {state: "available"}` a la respuesta `200`. En un Child, `/healthz` sigue indicando únicamente que el proceso responde. Los motivos se enumeran en [Remote Link](/es/guides/remote-link/#link-status).
+
+### `ocx resolve [--json]`
+
+Resolver los hechos de entorno de ejecución que un shell necesita sin volver a implementarlos: la configuración de inicio, el puerto efectivo y el veredicto de vivacidad verificado de identidad. `--json` emite un documento versionado (`schema: "ocx-resolve/1"`) con `cliVersion`, `configHome`, `port` (`effective`, `configured` y `source`), y `liveness` (`status`, `pid`, `port`, `source`, más `version`, `role` y `hostname` cuando el proxy en vivo los informa). Cuando un proxy está activo, el documento también lleva `versionSkew` - la misma superficie de comparación `ocx status` y `ocx doctor` - con `cliVersion`, `proxyVersion`, `skewed`, `relation` de `match`, `cli-newer`, `proxy-newer`, `incomparable` o `unknown`, y el `warning` orientado al operador. Los shells leen `relation` en lugar de reformular la advertencia; el escritorio usa `proxy-newer` para evitar que una toma de control disminuya el oyente. Liveness tiene tres respuestas: `live`, `absent-proven` (cada punto final registrado y configurado rechazó o respondió definitivamente no opencodex), y desconocido: una sonda agotada o un oyente que no responde a `/healthz` sale con 1 en lugar de leerse como ausente, por lo que solo `absent-proven` puede autorizar el inicio de un nuevo entorno de ejecución. El puerto es el puerto del oyente en vivo cuando un proxy responde, de lo contrario, el puerto configurado (por defecto 10100). El código de salida 0 lleva un veredicto digno de confianza; el código de salida 1 significa que el CLI no se pudo resolver, incluido un `config.json` inválido, que nunca se repara aquí, y la persona que llama debe negarse a adivinar; cualquier argumento desconocido sale con 64. Discovery utiliza el mismo presupuesto de sondeo seguro para la propiedad que `ocx start`, porque una respuesta falsa de "no escuchar nada" es cómo suceden los proxies duplicados. El verbo es de solo lectura y omite la función de restauración automática previa.
+
+### `ocx doctor`
+
+El informe predeterminado incluye el estado del coordinador de escritura nativa y la ruta exacta utilizando la inspección de solo lectura inmutable SQLite. Los estados de cero bytes, vacío-sin versionar y sin filas se muestran por separado del estado del catálogo/servidor de aplicaciones, por lo que una actualización de catálogo exitosa no se confunde con una inyección de configuración Codex exitosa.
+
+La comprobación de historial pendiente lee un WAL-mode `state_5.sqlite` con puntos de control incluso cuando Codex está cerrado y sus archivos `-wal` / `-shm` están ausentes. Los sidecares que faltan por sí solos no indican un fallo de integridad de la historia. Los manifiestos de copia de seguridad y los objetivos de restauración aún se someten a validación de integridad.
+
+Después de detener el servicio/proxy OpenCodex, conserve y mueva explícitamente un coordinador no autorizado probado, luego vuelva a intentar la sincronización:
+
+```bash
+ocx doctor --recover-zero-byte-coordinator --yes
+ocx sync
+```
+
+La recuperación solo acepta un remanente probado de cero bytes. Rechaza todas las bases de datos no vacías, válidas, desconocidas, cambiadas, inseguras u ocupadas y crea un archivo del mismo directorio `.zero-byte-backup-*` en lugar de eliminar nada.
+
+Ejecuta diagnósticos de solo lectura sobre rutas de estado, sistema de archivos, instalaciones WSL duplicadas, configuración y entorno de proxy, conectividad con ChatGPT, avisos de plugins y configuración de proyectos Codex, y migración pendiente del historial. La sección **Native main refresh** consulta el endpoint autenticado de solo lectura de admisión de la cuenta principal del proxy activo. Así, un `ocx doctor` iniciado por separado informa `foreign-ownership` u otro motivo de bloqueo del servicio; si no puede consultar el proxy, indica que la admisión no está disponible. El diagnóstico del directorio de Codex App también detecta el caso limitado de desajuste de directorio de ejecución de Orca en Windows y explica la migración del servicio cuando corresponde. Las rutas ocultan el nombre de usuario del sistema operativo. Doctor propone reparaciones, pero no las aplica.
+
+Los diagnósticos de Project-config ignoran los ejemplos de proveedores dentro de cadenas multilínea TOML, incluyendo `developer_instructions`. La configuración real del proveedor y del perfil después del delimitador de cierre sigue estando marcada, incluso cuando una cita escapada precede inmediatamente a ese delimitador.
+
+La sección **OAuth fiabilidad** informa si el almacenamiento de credenciales es escribible, si se pueden crear archivos de actualización de un solo vuelo/bloqueo bajo `OPENCODEX_HOME`, OAuth o Codex cuentas de grupo no saludables (ids redactados) con una recuperación `Action:`, y un OK estático de que la ruta de reenvío Codex no fabrica metadatos de cliente oficial. El médico nunca muta las credenciales ni aplica reparaciones.
+
+<a id="catalog-sync"></a>
+
+## Sincronización de catálogo
+
+<a id="read-saved-state-separately-from-synchronization"></a>
+
+### Leer el estado guardado por separado de la sincronización
+
+El modelo, el proveedor, la configuración y los recibos v2 tienen contratos de finalización distintos. Los cambios locales de modelos personalizados se sincronizan de forma oportunista: si no hay proxy, el guardado se considera exitoso, con `needsSync:true`, `sync.status:"not-attempted"` y código de salida 0. En cambio, un `--sync` explícito de un proveedor local sin proxy devuelve un valor distinto de cero después de guardar.
+
+Las escrituras de configuración usan `catalogRefreshPending`, mientras que las escrituras en vivo de v2/catálogo usan un resultado completo de `catalogRefresh`. El modo local de v2/keep-native y un on/off modificado siguen intentando su sincronización habitual incluso cuando no se descubrió ningún puerto. JSON informa del estado realmente modificado y de la evidencia de sincronización; una sincronización sin verificar o fallida devuelve un código distinto de cero. Los hilos, las sugerencias y un on/off sin cambios no introducen un nuevo intento de sincronización.
+
+Inspeccione el mismo objetivo con `ocx v2 status --json` o `ocx v2 status --live --json` y utilice `ocx system settings --json` para la lectura de la configuración. Un resultado guardado pero pendiente o desconocido no demuestra una reversión y no autoriza a repetir una escritura. Consulte los [resultados de v2](/es/reference/cli/agents/#explicit-v2-target-and-outcome) y la [política de cuentas](/es/reference/cli/providers-accounts/#pool-policy-account-thresholds-and-paid-credit-intent) para conocer los límites de destino, alcance y gasto. Una lectura de estado de una concesión de reinicio puede contactar con el estado ascendente, pero nunca consume ni reanuda una concesión.
+
+### `ocx sync [--expect-link <linkId> | --expect-hub-key <apiKeyId>] [--local-only] [--json] [--restart-codex] [--restart-app-server-only] [--child <linkId>]... [--restart-children[=app-server] | --restart-children=codex --yes]` <span id="ocx-sync---restart-codex---restart-app-server-only"></span>
+
+En Home, un catálogo confirmado se distribuye a Children aptos salvo `--local-only`. `--json` devuelve `ocx.sync.fanout/1` con Home y cada Child, incluidos motivo e `hint` de omisiones. Actualiza un Child antiguo a 2.93.0 o posterior mediante el instalador que administra el `ocx` seleccionado; para Desktop Windows sin sesión gráfica, usa el actualizador de la bandeja con sesión iniciada. Un vínculo cambiado puede requerir volver a enlazar; si el Child se está actualizando, vuelve a intentarlo después de la actualización. Se conserva el código de salida distinto de cero de Home; si Home termina con 0, un Child conectado omitido, fallido, con timeout, reinicio incierto o almacén ilegible produce 6. Omisiones intencionales por enlace iniciado en Child, selección `not-selected`, `--local-only` o `child-busy` mantienen su comportamiento. El error de almacén no expone rutas; 7 se reserva a una actualización activa. Si Home lanza error en JSON, stdout conserva un único resultado y stderr un mensaje saneado.
+
+El fan-out no reinicia Codex salvo `--restart-children`, para app-servers, o `--restart-children=codex --yes`, para Desktop con sesión gráfica. Sync se realiza primero, luego se comprueba actividad otra vez y se envía otro sync fijado con reinicio. Se omite solo el reinicio ante `restart-skipped:link-active`, `restart-skipped:activity-unknown`, `restart-skipped:windows` o `restart-unsupported:ocx-child`, terminando con 6. Un tipo de Child desconocido recibe la opción para identificarlo; el ligero la ignora. Envío no realizado o resultado incierto indica `restart-not-run` o `restart-result-unknown`, también 6. Es protección de mejor esfuerzo: una petición nueva aún puede interrumpirse. `--child <linkId>` selecciona enlaces; el resto es `not-selected`, y una operación ocupada, `child-busy`. El sync puede reiniciar el runtime OpenCodex del Child tras cambiar ajustes. Un timeout del SSH local no garantiza que el sync remoto se detuviera.
+
+Si hay una actualización activa o no se puede determinar el estado del mutex compartido entre actualización y sincronización, sync no cambia nada, informa `update-in-flight` y termina con código de salida 7. Cuando el rechazo se debe a un marcador dejado por una actualización interrumpida en OpenCodex 2.100.x o anterior, stderr también identifica el marcador y su recuperación; consulta [Actualización fallida](/es/troubleshooting/update-failed/#if-every-update-and-sync-says-update-in-flight). Si otra sincronización posee el mutex, informa `sync-in-progress` y termina con 1; el Home cuenta ese Child como fallido y devuelve 6 si su propia sincronización tuvo éxito. Con `--json`, ambos rechazos imprimen un único resultado con el Home omitido y el motivo en `fanout.reason`.
+
+Un reinicio solicitado explícitamente también se ejecuta después de un cambio realizado con éxito de `config.toml`, incluso si los bytes de catálogo y caché no cambian. Una escritura de solo configuración sin opción, de rechazo, previa o de retroceso no la activa. Sin un indicador de reinicio, la sincronización nunca se reinicia automáticamente Codex.
+
+En un Remote Link Child, `ocx sync` también aplica la configuración de Codex del Home y reinicia el entorno cliente si este arrancó antes de esa aplicación; consulta [Paridad de aplicación de Remote Link](#remote-link-apply-parity).
+
+Obtenga la lista de modelos en vivo de cada proveedor configurado y vuelva a inyectar el catálogo combinado en Codex. Ejecutarlo después de agregar un proveedor o para actualizar los modelos disponibles.
+
+Antes de la detección de proveedores o el reemplazo de catálogo/caché, `ocx sync` valida que se puede inyectar la configuración administrada Codex. Si esa validación rechaza la configuración, el comando sale con un código distinto de cero, imprime la razón concreta en stderr y deja el catálogo y la caché existentes sin cambios. `ocx restore back` usa el mismo prevuelo sin escritura antes de volver a habilitar el enrutamiento.
+
+Si los procesos de larga vida Codex `app-server` todavía se están ejecutando, `ocx sync` advierte que pueden seguir sirviendo la lista de modelos en memoria anterior a pesar de que `opencodex-catalog.json` / `models_cache.json` se actualizaron. Pase `--restart-codex` para reiniciar los procesos `codex … app-server` y `codex-code-mode-host` que coinciden con **y** y reinicie completamente la aplicación de escritorio Codex, en macOS, Linux y Windows, por lo que el selector de modelos vuelve a leer el catálogo. Las conversaciones en vivo terminan. La coincidencia amplia `pkill -f codex` se evita intencionadamente.
+
+`--restart-desktop-app` es un alias obsoleto de `--restart-codex`. Todavía funciona, imprime un aviso de obsolescencia y no está limitado a Windows.
+
+`--restart-app-server-only` restaura el comportamiento más antiguo y más estrecho: `SIGTERM` solo a los procesos de host de modo de código y de servidor de aplicaciones correspondientes propiedad del usuario actual, con la aplicación de escritorio en ejecución. Los giros activos aún pueden interrumpirse. Si se combina con `--restart-codex` o `--restart-desktop-app`, el alcance estrecho gana, porque perder conversaciones en vivo es irrecuperable y un selector obsoleto no lo es.
+
+Cuando el comando se ejecuta desde dentro de la aplicación Codex, el reinicio se transfiere a un ayudante separado y esta sesión finaliza con la aplicación.
+
+<a id="sync-only-from-the-expected-home-expect-link-and-expect-hub-key"></a>
+
+#### Sincronizar solo desde el Home esperado: `--expect-link` y `--expect-hub-key`
+
+```bash
+ocx sync --expect-link <linkId> [--restart-codex]
+ocx sync --expect-hub-key <apiKeyId> [--restart-codex]
+```
+
+Un script que lee `ocx connect status --json` y luego ejecuta `ocx sync` no puede saber si, entre
+ambos comandos, el equipo se desconectó o se vinculó a otro Home. Un `ocx sync` sin más opciones
+sincronizaría entonces los proveedores locales o el catálogo del otro Home. Pasar la identidad leída
+evita esa situación. `--expect-link` recibe el `link.linkId` de un Remote Link Child, y
+`--expect-hub-key` recibe el `apiKeyId` de un cliente de Hub. La comprobación se ejecuta bajo el mismo
+bloqueo que elige la ruta de sincronización, y todas las escrituras posteriores quedan vinculadas
+a la conexión que la superó.
+
+Si la identidad coincide, el comando realiza exactamente la sincronización conectada descrita arriba.
+En otro caso no cambia nada —ni siquiera la reparación automática de la shim de Codex que otros
+comandos ejecutan primero—, nunca sincroniza los proveedores locales, termina con código **5** y
+escribe en stderr una línea legible seguida de una línea JSON, que es la última:
+
+```json
+{"phase":"child_link_mismatch","reason":"other_link"}
+```
+
+`phase` es `child_link_mismatch` para `--expect-link` y `hub_client_mismatch` para `--expect-hub-key`.
+
+| `reason` | Estado del equipo |
+| --- | --- |
+| `disconnected` | No está conectado a ningún Home ni Hub |
+| `invalid_state` | No se puede leer la configuración del cliente o un marcador de conexión |
+| `disconnect_pending` | Se inició una desconexión que aún no termina |
+| `pending_operation` | Hay una rotación de clave, conexión u otra sincronización en curso, incluida una operación que mantiene los bloqueos que esta comprobación necesita |
+| `hub_client` | Se usó `--expect-link` en un cliente de Hub |
+| `link_client` | Se usó `--expect-hub-key` en un Remote Link Child |
+| `other_link` / `other_key` | Está conectado, pero mediante otro enlace o con otra clave |
+
+Un valor ausente o mal formado, una opción repetida o las dos opciones juntas terminan con código 2
+antes de leer ningún estado. Si la conexión cambia después de la comprobación, mientras se obtiene
+el catálogo, la operación falla como una sincronización conectada normal: código 1 y ninguna escritura.
+Las versiones que no admiten estas opciones las ignoran; comprueba antes `ocx --version`.
+
+### `ocx sync-cache [--restart-codex] [--restart-app-server-only]`
+
+Invalide la caché local del selector de modelos de Codex para que se reconstruya a partir del catálogo activo de opencodex. Se aplican las mismas advertencias obsoletas `app-server` y los indicadores de reinicio opcionales que `ocx sync`.
+
+Si la caché derivada ya tiene bytes idénticos, el comando se ejecuta correctamente sin reescribirlo ni reiniciar Codex. Con `--json`, esto se informa como `ok: true`, `wrote: false`, `skipped: true` y `skippedReason: "unchanged"`; un catálogo no válido o una escritura en caché fallida sigue saliendo con un código distinto de cero.
+
+<a id="catalog-write-diagnostics"></a>
+
+### Diagnósticos de escritura de catálogo
+
+Catalog write auditing records diagnostics en `opencodex-catalog-audit.jsonl` bajo `CODEX_HOME`. Un catálogo o caché sin cambios no produce ningún evento; un error de auditoría no falla la publicación del catálogo.
+
+En Windows, **como máximo se registra el evento de creación de nuevo archivo exitoso**. El archivo se crea vacío y endurecido antes de que se escriban los datos de diagnóstico. Todos los eventos posteriores omiten el archivo existente, tanto en el mismo proceso como después de reiniciar. Un fallo de endurecimiento puede dejar un archivo vacío, que eventos posteriores también omiten. Los archivos existentes y sus ACL no se cambian para la auditoría, incluso cuando otra casa OpenCodex posee el catálogo. Este es un retroceso de la privacidad, no un flujo de auditoría Windows completo; el comportamiento NTFS nativo para esta ruta de auditoría aún no se ha validado.
+
+La auditoría POSIX continúa agregando y conservando registros limitados. La limitación Windows no deshabilita la protección del catálogo o la curación del propietario. Los archivos de auditoría en un `CODEX_HOME` separado permanecen como residuos de limpieza porque el manifiesto de desinstalación de configuración no puede reclamar rutas fuera de su propia raíz.
+
+### `ocx catalog pull <https-url> [--auth-env <NAME>] [--json] [--restart-codex] [--restart-app-server-only]`
+
+Instale un catálogo completo servido por el punto final `/v1/catalog` de otra instancia OpenCodex y, a continuación, sincronice `models_cache.json`. A diferencia de `ocx sync`, este comando no descubre proveedores configurados ni inyecta la configuración Codex. A diferencia de `ocx sync-cache`, reemplaza el catálogo activo antes de reconstruir la caché. Funciona incluso cuando el estado deseado de la integración local Codex está desactivado.
+
+La URL debe ser HTTPS; se acepta loopback HTTP para pruebas locales. Las credenciales de URL incrustadas, consultas, fragmentos, redirecciones, respuestas de gran tamaño, JSON malformadas, identificadores duplicadas o inseguras y desconocidas `input_modalities` se rechazan antes de cualquier escritura local.
+
+Las solicitudes de Loopback HTTP son rechazadas antes de que se adjunten las cabeceras de autenticación o se envíe cualquier solicitud cuando se aplica `HTTP_PROXY` o `http_proxy` sin una derivación `NO_PROXY` o `no_proxy` coincidente. `ALL_PROXY` / `all_proxy` y la configuración limitada a `HTTPS_PROXY` / `https_proxy` no activan esta restricción HTTP; La adquisición del catálogo HTTPS permanece permitida. El mensaje de denegación no incluye ni la dirección proxy ni el testigo de autenticación. `http_proxy` y `no_proxy` tienen prioridad sobre `HTTP_PROXY` y `NO_PROXY`, respectivamente. Para reglas de omisión compatibles con Bun, use nombres de host, entradas coincidentes `host:port`, direcciones IPv6 entre corchetes como `[::1]` o `*`; no use URL, rutas o prefijos `*.`.
+
+La autenticación es opcional y solo se lee mediante referencia de entorno variable:
+
+```bash
+export OPENCODEX_CATALOG_AUTH_TOKEN='...'
+ocx catalog pull https://proxy.example.com/v1/catalog \
+  --auth-env OPENCODEX_CATALOG_AUTH_TOKEN
+```
+
+El valor se envía como un token de portador, pero nunca se acepta como un valor de argv. Las redirecciones son rechazadas, por lo que la autorización no puede cruzar orígenes. Las escrituras de catálogo y caché utilizan el bloqueo de catálogo Codex compartido y el escritor atómico. Una recuperación, validación, adquisición de bloqueos, escritura de catálogo o reconstrucción de caché fallida conserva los últimos archivos buenos conocidos. Si los bytes del catálogo son idénticos, la operación no cambia nada: conserva los mtimes y no modifica los procesos. `--restart-codex`, `--restart-app-server-only` y el alias `--restart-desktop-app` en desuso significan lo mismo aquí que en `ocx sync` y `ocx sync-cache`, y se aplican solo después de una escritura real.
+
+La URL debe nombrar `/v1/catalog` en la raíz del host. Este comando no admite un proxy inverso que sirva el punto final bajo un prefijo de ruta.
+
+El comando descarga el catálogo completo y compara bytes localmente en lugar de emitir un `ETag` /
+`If-None-Match` Solicitud condicional. Los bytes idénticos se tratan como un no-op completo, por lo que Codex casa cuyo catálogo es correcto, pero cuya `models_cache.json` falta o es rancio no reparado por este comando; usar `ocx sync-cache` Por eso.
+
+`--json` emite un sobre estable en stdout. `schemaVersion`, `ok`, `status`, `catalogWritten`, `cacheSynced` y `codexRestarted` están siempre presentes. `codexRestarted` todavía significa solo servidores de aplicaciones. `desktopAppRestarted` está presente solo cuando se solicitó un reinicio del escritorio, y es `true` solo cuando se inició el relanzamiento; un traspaso no es un éxito. `status` es `updated`, `unchanged`, o `failed`. Un tirón exitoso agrega `modelCount`; un fallo agrega `code`, que es el campo en el que se ramifica un script:
+
+| `code` | Descripción | Salir |
+| --- | --- | --- |
+| `usage` | Los argumentos no eran una invocación `catalog pull` válida. | 2 |
+| `auth_env_missing` | `--auth-env` nombró una variable que no está establecida | 1 |
+| `url_invalid`, `insecure_http_refused` | La URL fue rechazada antes de cualquier solicitud | 1 |
+| `request_failed`, `redirect_refused`, `http_error` | La solicitud no produjo una respuesta utilizable | 1 |
+| `body_too_large`, `body_invalid`, `catalog_invalid` | La respuesta fue rechazada antes de cualquier escritura local. | 1 |
+| `write_failed`, `lock_database`, `unsafe_path` | La escritura coordinada no se completó; los archivos no han cambiado | 1 |
+| `lock_busy` | Otro escritor tiene el bloqueo de catálogo Codex | 3 |
+| `restart_incomplete` | El catálogo y la caché aterrizaron, pero un Codex app-server sobrevivió `--restart-codex` o `--restart-app-server-only` | 1 |
+
+`restart_incomplete` es el único fallo que reporta escrituras reales: `catalogWritten` y `cacheSynced` permanecen verdaderas y `ok` es falsa, porque un servidor de aplicaciones sobreviviente todavía sirve el catálogo anterior de memoria.
+
+<a id="background-service"></a>
+
+## Servicio en segundo plano
+
+Un servicio administrado puede iniciar una instalación más nueva que anteriormente servía a la misma casa OpenCodex, incluso cuando su definición de servicio aún apunta a una instalación más antigua. Si ese hijo más nuevo sale antes de vincularse, con cualquier código de salida, el servicio original se inicia en su lugar y aplica sus propias comprobaciones antes de servir. Los inicios de primer plano y los proxies lanzados por el cliente mantienen su ejecutable seleccionado. En Windows, esto se aplica al Programador de tareas y a los servicios nativos WinSW recién instalados o reparados. Una definición nativa de WinSW creada antes de este comportamiento necesita `ocx service repair` para actualizar su XML antes de que pueda pasar a una instalación más reciente.
+
+### `ocx service [install|repair|restart|start|stop|status|uninstall|remove]`
+
+En Windows Task Scheduler, el envoltorio de servicio reinicia el proxy después de cinco segundos, incluso cuando una herramienta externa lo termina con el código de salida 0. Si otro proxy opencodex ya posee el puerto, el contenedor sale deliberadamente. Utilice `ocx stop` o `ocx service stop` para detener el servicio y su bucle de reinicio. Después de actualizar una instalación existente, ejecute `ocx service repair` para actualizar el envoltorio generado.
+
+Ejecute opencodex como un servicio en segundo plano gestionado por el inicio de sesión (macOS **launchd**, Linux **unidad de usuario de systemd**, Windows **Programador de tareas**) que se inicia solo al iniciar sesión y se reinicia solo tras un fallo. El servicio establece `OCX_SERVICE=1` para que un reinicio no altere la configuración de Codex.
+
+Windows Las instalaciones del Programador de tareas usan la prioridad de proceso normal (`Priority=4`). La prioridad de fondo más antigua (`7`, también el planificador predeterminado cuando se omite) puede retrasar las respuestas de estado del proxy en la contención de la CPU, haciendo que la bandeja informe Desconectado incluso mientras el proceso está activo. Después de actualizar, ejecute `ocx service repair` para migrar esa prioridad registrada y reinicie el servicio. Esta migración puede solicitar la aprobación de UAC; una prioridad ya establecida a normal o alta no desencadena la sustitución.
+
+El envoltorio Windows admite fechas de configuración regional que contienen paréntesis, incluidos los formatos de fecha coreano y japonés. Después de actualizar, ejecute `ocx service repair` para reemplazar un envoltorio generado más antiguo que sale antes de lanzar Bun en esas configuraciones regionales.
+
+El envoltorio Windows verifica su entorno de ejecución Bun horneado y su entrada CLI antes de cada intento de inicio. Si una actualización de paquete interrumpida elimina cualquiera de los archivos, registra un mensaje `installation is incomplete` y se detiene en lugar de volver a intentar el mismo ejecutable que falta cada cinco segundos. Vuelva a instalar opencodex y, a continuación, ejecute `ocx service repair` para actualizar la tarea con las rutas de paquetes restauradas.
+
+Las definiciones de servicio omiten los directorios multishell version-manager locales de sus `PATH` guardados. Esto incluye el servicio nativo Windows instalado con `ocx service install --native`; ejecute `ocx service repair` para regenerar una definición de WinSW anterior con un `PATH` duradero.
+
+En Linux, la unidad systemd invoca el primer ejecutable normal `ocx` archivo encontrado en `PATH` en tiempo de instalación en lugar de las rutas Bun y CLI dentro del árbol de paquetes instalado. Administradores de versiones como el **mise** y **asdf** instalar en un directorio versionado y eliminar el antiguo en la actualización; su shim estable mantiene la unidad resolviendo. Fuente checkouts sin un `ocx` lanzador mantener el forma directa Bun + CLI. Un confiable `OPENCODEX_BUN_PATH` seleccionado antes de Bun se inicia se conserva a través de la shim; las rutas de paquetes locales Bun se redescubren después de las actualizaciones.
+
+En macOS, launchd en su lugar utiliza el paquete local Bun y CLI rutas seleccionadas durante la instalación o reparación. Esto evita que una shim PATH mutable reciba el token de servicio API y el entorno proxy configurado en un reinicio posterior. Después de actualizar una instalación del administrador de versiones, ejecute `ocx service repair` para actualizar esas rutas antes de reiniciar el servicio. Lanzado reinicia el proxy después de un fallo o un traspaso de reinicio fallido, pero lo deja detenido cuando el servicio sale deliberadamente de forma limpia porque la aplicación de escritorio es propietaria del entorno de ejecución. Ejecute `ocx service repair` una vez para aplicar este comportamiento a un servicio instalado por una versión anterior.
+
+Las definiciones anteriores no fijan los valores resueltos de `CODEX_HOME` y `OPENCODEX_HOME` para los reinicios del servicio. Después de actualizar, ejecuta `ocx service repair` una vez para que el shell generado restablezca ambos directorios después de inicializar el perfil de inicio, y el Programador de tareas conserve rutas absolutas en vez de expandir variables del perfil de ejecución. La reparación también actualiza rutas antiguas versionadas; si ya se eliminó el ejecutable antiguo, reinstala opencodex antes de reparar. En Linux, el servicio sigue el lanzador; en macOS, la reparación escribe las nuevas rutas del paquete y los directorios en la definición de launchd. En macOS, instalar o reparar rechaza valores de directorio o entorno proxy con caracteres de control que un plist XML no puede contener, como U+0001, e identifica la variable que debes corregir. Una actualización externa no sustituye un proxy activo: si la CLI instalada es más reciente, ejecuta `ocx service restart` para servir la nueva versión. En macOS no basta con `repair` si la definición no cambia, porque una reparación sin cambios no recarga nada. Si el proxy es más reciente que la CLI, comprueba la instalación y `PATH` como explica [`ocx status`](#ocx-status---json).
+
+| Subcomando | Medidas adoptadas |
+| --- | --- |
+| Ninguno | Instale e inicie cuando esté ausente; de lo contrario, `repair` el servicio existente. Se reutiliza una definición saludable del planificador Windows; una definición obsoleta puede volver a registrarse y requerir elevación. |
+| `install` | Crear e iniciar el servicio. Lo registra, que en Windows necesita elevación. |
+| `repair` | Actualizar un servicio instalado en su lugar. En macOS, el administrador se recarga solo cuando algo cambia, por lo que un trabajo saludable y sin cambios sigue funcionando y la reparación no es una interrupción. En Linux y Windows, el servicio se reinicia; se reutiliza una definición de planificador de Windows saludable, mientras que una definición obsoleta puede volver a registrarse y requerir elevación. |
+| `restart` | La misma actualización y un reinicio garantizado en todas las plataformas. En el macOS se inicia un trabajo sin cambios y ya cargado. No es un alias de `repair`. |
+| `start` | Iniciar un servicio instalado. |
+| `stop` | Detener el servicio y restaurar nativo Codex. |
+| `status` | Informar los diagnósticos del servicio y del proxy, y las rutas de registros. `--json` muestra el documento pasivo descrito a continuación. |
+| `uninstall` | Retire el servicio y restaurar nativo Codex. |
+| `remove` | Alias de `uninstall`. |
+
+En `ocx service`, un Windows ejecuta la ruta de instalación solo después de que se demuestre que está ausente el Programador de tareas y WinSW. Si cualquiera de las consultas de estado no es concluyente, se niega a registrar nada y le pide que ejecute `ocx service status`; use `ocx service install` explícito solo después de confirmar la ausencia.
+
+`ocx service status --json` muestra un documento pasivo para scripts y otros clientes, como el inventario de dispositivos de GOAT. Realiza las mismas lecturas que el informe de texto y nunca instala, inicia, detiene ni repara nada; cualquier otro verbo `service` rechaza `--json`. Campos: `schemaVersion` (1), `platform`, `supported`, `backend` (`launchd`, `systemd`, `schtasks`, `winsw` o `none` si no hay ningún registro), `label` (nombre del trabajo, unidad, tarea o servicio WinSW), `installed`, `enabled`, `running` (veredicto del administrador de servicios), `viable`, `stale`, `conflict`, `serving` (`probed`, `ok`, `port`; solo se sondea cuando hay un registro), `summary`, `logPath`, `ownershipLease` y `desktopLogin`. Una plataforma no admitida o un contenedor Docker también recibe el documento, con `supported: false`.
+
+<a id="runtime-ownership"></a>
+
+### Propiedad en entorno de ejecución
+
+La aplicación de escritorio OpenCodex puede tomar el proxy de fondo de una instalación CLI. Cuando lo hace, registra el traspaso en el estado de instalación del servicio compartido, y ese registro es lo que hace que la adquisición sobreviva a un reinicio. Su registro de servicio es **mantenido, nunca eliminado** - el registro lo reemplaza en lugar de reemplazarlo.
+
+Un archivo de estado sin registro de propiedad significa que la instalación CLI es propietaria del entorno de ejecución, que es en lo que se realiza cada instalación antes de que se encuentre esta función. Nada cambia para ti hasta que una aplicación se hace cargo.
+
+Los hijos de servicio supervisados también verifican al propietario registrado antes del inicio y una vez más mientras mantienen el contrato de arrendamiento de propiedad de inicio, antes de elegir un puerto o publicar un PID. Si la aplicación de escritorio reclama el entorno de ejecución durante el inicio, el hijo de servicio se desactiva incluso si el proxy de escritorio aún no ha comenzado a escuchar. Un registro de propiedad ilegible tiene el mismo comportamiento de stand-down.
+
+Home rutas dentro de un registro de estado se comparan con la casa actual por el directorio físico que resuelven, no solo su ortografía. Un cruce o enlace simbólico registrado bajo una instalación anterior todavía nombra la misma casa y sigue funcionando después de la mudanza; un alias que ya no se resuelve solo se trata como una casa diferente cuando su ortografía registrada también difiere de la actual, por lo que un montaje obsoleto aún produce la negativa del propietario extranjero en lugar de reclamar silenciosamente el entorno de ejecución.
+
+Mientras que algo más que este CLI posee el entorno de ejecución, los subcomandos que **activar** su registro se niegan en su lugar:
+
+| Subcomando | Comportamiento bajo un propietario extranjero |
+| --- | --- |
+| `repair`, `restart` | Se rechazan antes de cambiar nada. El registro no se vuelve a habilitar, reescribir ni reiniciar. |
+| `start` | Se niega por la misma razón, por lo que un inicio automático de bandeja no puede poner un segundo proxy al lado de la aplicación. |
+| `stop`, `uninstall` | Sin cambios. Se desactivan, por lo que nunca están cerradas. |
+| `install` | Devuelve el tiempo de ejecución. Limpia el registro de propiedad después de que el registro tenga éxito, e informa de quién fue. |
+
+`ocx update` se comporta de la misma manera: ni detiene el proxy en ejecución ni actualiza el servicio mientras la aplicación posee el entorno de ejecución, porque el servidor en ejecución es el propio binario incluido de la aplicación y la actualización volvería a habilitar el lanzador que reemplazó la adquisición. La aplicación actualiza su propio entorno de ejecución.
+
+La denegación nombra la instalación propietaria y la generación de consentimiento, por ejemplo:
+
+```text
+Background service repair stopped: the desktop app owns the runtime (install <id>, consent generation 2).
+The service registration was left exactly as it is — not re-enabled, not rewritten and not restarted.
+Quit the desktop app and run 'ocx service install' to hand the runtime back to this CLI.
+```
+
+Un registro que no se puede leer o no analiza produce el mismo rechazo con una primera línea diferente, porque una reclamación ilegible no es lo mismo que ninguna reclamación - tratándolo como "nadie es dueño de esto" es como un error de permisos reactivaría silenciosamente su servicio.
+
+**La recuperación en todos los casos es `ocx service install`.** Es deliberadamente el único verbo que nunca está cerrado, por lo que eliminar la aplicación sin devolver el entorno de ejecución, o un archivo de estado dañado, aún le deja una forma de recuperar el servicio:
+
+```bash
+ocx service install
+```
+
+```bash
+ocx service
+ocx service install
+ocx service repair
+ocx service restart
+ocx service status
+ocx service uninstall
+```
+
+`install`, `start` y `repair` confirman que un proxy realmente responde en el puerto instalado antes de informar el éxito en las tres plataformas. Esperan hasta 20 segundos y luego imprimen el puerto de servicio:
+
+```
+✅ opencodex service installed and serving on port 10100.
+```
+
+Si nada responde, advierten y **salen con un código distinto de cero**:
+
+```
+⚠️  Service installed, but no proxy answered on port 10100 within 20s.
+   The manager registered the job; that is not the same as serving.
+   Log:       ~/.opencodex/service.log
+   Meanwhile: ocx start   (serves in the foreground)
+```
+
+Una salida distinta de cero significa aquí *Registrados pero sin servicio*, no *no instalado*. El gerente de servicio aceptó el trabajo; el proxy detrás de él nunca conectó el puerto. Lea el registro nombrado en el mensaje y use `ocx start` para servir en primer plano.
+
+`ocx service status` informa los mismos tres estados en lugar de la salida del administrador en bruto:
+
+```
+✅ installed and loaded (launchd; logs: …)
+   Serving on port 10100.
+```
+
+```
+⚠️  installed and loaded (launchd; logs: …)
+   Registered, but no proxy is answering on port 10100.
+   launchd is running an OLDER plist than the one on disk.
+   Fix:    launchctl bootout gui/$(id -u)/com.opencodex.proxy && ocx service repair
+   Log:    ~/.opencodex/service.log
+   Repair: ocx service repair
+   Meanwhile: ocx start           (serves in the foreground)
+```
+
+Ya no imprime la línea sin procesar `launchctl list` / `systemctl status`, que informaba de un trabajo registrado de manera idéntica si estaba sirviendo, vinculado a nada o ejecutando una definición anterior. La línea `Diagnostics:` todavía lleva la trayectoria logarítmica y cualquier hallazgo de trayectoria anticuada.
+
+En Windows, el backend del programador mantiene su propia salida de estado más rica, que ya informó el registro del Programador de tareas por separado de la accesibilidad del proxy.
+
+<a id="service-logs"></a>
+
+### Registros de servicio
+
+El proxy administrado escribe stdout y stderr a `~/.opencodex/service.log` (o `$OPENCODEX_HOME/service.log` con un hogar personalizado). Cuando se establece `OCX_SERVICE`, `ocx start` prefija cada línea de registro de consola, incluidos los diagnósticos multilínea, con una marca de tiempo UTC ISO-8601 como `2026-10-14T03:04:05.678Z`. La salida en primer plano y otros comandos CLI mantienen su formato existente.
+
+El servicio comprueba el tamaño del registro en el inicio y una vez por minuto. Por encima de 20 MiB copia los 20 MiB más nuevos en `service.log.1`, mueve el archivo anterior a `service.log.2` y trunca el archivo activo en su lugar para que los identificadores de apéndice abierto del administrador de servicios sigan siendo utilizables. El archivo activo puede superar el umbral entre comprobaciones; cada archivo está limitado a 20 MiB. Las fallas de rotación no detienen el servicio. Copy-truncate puede perder líneas escritas durante la copia, y un archivo puede comenzar a mitad de camino a través de una línea. Los mensajes de envoltura Windows existentes mantienen su formato de envoltura.
+
+En macOS esto también cubre un fallo más sutil: `launchctl load` informa de un fallo en stderr mientras sale con 0, por lo que una carga que no surtió efecto dejaba a launchd ejecutando una versión **anterior** de la definición de servicio mientras el comando imprimía una marca de verificación. `install` ahora falla ruidosamente en ese caso y nombra el comando `launchctl bootout` que limpia el trabajo obsoleto.
+
+En Windows, `ocx service status` informa el registro del Programador de tareas por separado de la accesibilidad del proxy OpenCodex verificado por identidad. No imprime la tabla localizada `schtasks`, por lo que el resumen sigue siendo legible en Windows páginas de código. La recuperación de copia de seguridad transaccional registra un mensaje de éxito fijo en lugar del nombre del directorio de copia de seguridad; los nombres de copia de seguridad que contienen metacaracteres de shell no se convierten en comandos en ese mensaje de registro.
+
+En Windows, desinstalar una tarea `opencodex-proxy` registrada con elevación puede requerir un
+terminal elevado. Si se deniega su eliminación, o termina con código 1 y la tarea sigue presente,
+OpenCodex informa de que se requiere elevación y conserva los archivos del servicio.
+Abre PowerShell o Terminal con **Ejecutar como administrador** y ejecuta:
+
+```powershell
+schtasks /delete /tn opencodex-proxy /f
+```
+
+Después, vuelve a ejecutar `ocx service uninstall` desde la cuenta original para terminar la limpieza
+y comprueba `ocx service status`. Los comandos de inicio o parada con acceso denegado indican el
+comando `schtasks` elevado correspondiente. Los fallos del Programador usan diagnósticos y códigos
+de salida estables en lugar de reproducir el stderr localizado del hijo, que puede usar otra página
+de códigos de Windows. Si la tarea está ausente o no puede leerse después de una eliminación fallida,
+el código 1 por sí solo no confirma una denegación de acceso; el texto de acceso denegado reconocido
+en la eliminación sigue clasificándose como tal.
+
+En Windows, la creación de la entrada del Programador de tareas requiere elevación. El texto denegado de acceso localizado reconocido mantiene la ruta de guía existente. Si ese texto es ilegible, el recurso alternativo requiere la forma de comando propia `/create /tn opencodex-proxy /xml <non-empty-path> /f`, estado 1, y un token no elevado confirmado; la acción de seguridad de inicio del panel de control puede solicitar UAC automáticamente. Si esa reserva no puede determinar el estado del token, retiene el error del programador original. Las tareas y operaciones en el extranjero nunca pueden emitir el marcador de elevación automática. Aprobar el indicador UAC del panel de control o volver a ejecutar `ocx service install` en una ventana de PowerShell elevada.
+
+Para una instalación nueva en la que la tarea del planificador OpenCodex se confirma ausente, la aprobación de UAC ahora ocurre antes de que el instalador detenga cualquier proxy existente. Su XML de registro único se organiza en un directorio privado endurecido por ACL fuera de la raíz de configuración OpenCodex, y la tarea se registra sin ejecutarse. Solo después de que el registro tenga éxito, OpenCodex elimina ese XML, requiere metadatos de propiedad para una raíz de configuración genuinamente nueva, detiene el antiguo oyente, elimina y vuelve a verificar de manera limitada cualquier registro nativo de WinSW, publica los activos de servicio e inicia la tarea programada. La cancelación o denegación de UAC, o no reclamar una nueva raíz de forma segura, por lo tanto, deja el proxy de trabajo y su enrutamiento Codex en su lugar. Los registros de planificador existentes o conflictivos continúan fallando en lugar de ser eliminados como un retroceso inseguro del mejor esfuerzo.
+
+Si los informes de inicio `another process owns the runtime mutation lease` o `ocx service status` muestran `Runtime mutation lease busy`, el contrato de arrendamiento bloquea el inicio o los cambios de servicio incluso si el proxy no se está ejecutando. El mensaje incluye la ruta de bloqueo, el PID registrado, la vida actual, el nombre ejecutable cuando esté disponible y la edad de arrendamiento. La identidad del proceso no está verificada: el PID puede haber sido reutilizado, por lo que la vitalidad y el nombre ejecutable describen el proceso que ocupa ese PID ahora. Espere a que la operación termine y vuelva a intentarlo; no elimine el bloqueo ni detenga un proceso basado solo en este PID. Un intento de mutación posterior puede reclamar un arrendamiento obsoleto una vez que su edad supera los 30 segundos y el PID registrado ya no está vivo; el estado solo lo inspecciona.
+
+En Windows, este diagnóstico compartido del Nodo/Bun no lanza un ejecutable para buscar el nombre de la imagen; el PID, la vivacidad, la edad de arrendamiento y la guía de recuperación registrados permanecen disponibles.
+
+### `ocx codex-shim <install|status|uninstall|remove>`
+
+En macOS y Linux, instale un envoltorio de inicio automático privado en `<OPENCODEX_HOME>/bin/codex` y un `<OPENCODEX_HOME>/codex-shell-env.sh` fuente, utilizando el home de OpenCodex resuelto. El lanzador nativo se queda donde brew, npm o fnm lo instaló; las actualizaciones del administrador de paquetes y las reversiones de versiones continúan funcionando sin volver a envolver ese lanzador. En Windows, los lanzadores basados en scripts todavía están envueltos en su lugar. Los objetivos reales `codex.exe` se dejan intactos. Si se rechaza la instalación o el contenedor no se puede ejecutar, el comando sale con un código distinto de cero y el panel de control informa de la razón del fallo. Un envoltorio Unix ejecutable cuenta como una instalación exitosa incluso antes de la activación en el shell actual; una shim saludable ya instalada también cuenta como éxito. Para las instalaciones de Windows que exponen solo `codex.exe`, use `ocx service install` para autoarranque.
+
+En macOS /APFS, un reinicio puede cambiar los números de dispositivo del sistema de archivos. Después de ese cambio, un entorno de envoltura y shell privado permanece intacto, por lo que el estado, la reparación y la desinstalación continúan funcionando. OpenCodex todavía comprueba sus inodos registrados, rutas, propietario, permisos y enlace de contenido/lanzador; se conservan los archivos reemplazados o no validados.
+
+Después de brew/fnm y otra configuración PATH, ejecute el comando de activación impreso por install. Con la casa por defecto, es:
+
+```sh
+. "$HOME/.opencodex/codex-shell-env.sh"
+```
+
+Para un hogar personalizado, use la ruta impresa y cotizada. El abastecimiento es idempotente: elimina entradas duplicadas de contenedores privados y pone ese directorio primero en PATH. Para activar futuros proyectiles, agregue esa línea de origen después de configurar su PATH de administrador de paquetes usted mismo; OpenCodex nunca edita archivos de inicio de shell. La instalación no puede cambiar su shell padre. `ocx status`, `ocx codex-shim status`, `ocx doctor` y `ocx connect` informan de una envoltura ejecutable pero no seleccionada como **No activo**, con el commando de activación. Los alias/funciones de Shell y los lanzadores de escritorio o servicios configurados por separado aún necesitan su propia configuración.
+
+Para fnm-managed Codex, la instalación resuelve el directorio multishell temporal a la instalación duradera del Nodo mientras se conserva el nombre de archivo del lanzador. Si ese directorio no se puede resolver, la instalación se niega en lugar de envolver una ruta temporal. Cuando se selecciona Codex, `ocx connect` también informa de la preparación de la shim. Esta comprobación de preparación omite entradas PATH de archivo especial y, en macOS y Linux, archivos sin permiso de ejecución, incluidos los objetivos de enlace simbólico. Preserva el orden de los lanzadores ejecutables regulares, incluidos los enlaces simbólicos npm y fnm. Windows mantiene su búsqueda PATHEXT. Si un envoltorio PATH diferente oculta una shim ejecutable, corrige el orden PATH; reinstalar la misma shim no cambia qué comando encuentra primero tu shell. Si la shim rastreada se puede ejecutar pero no se encuentra ningún comando `codex`, connect lo informa como inactivo e imprime el comando de activación. Una inspección PATH fallida informa la activación como no verificada en lugar de afirmar que no existe ningún comando. Estas advertencias no cambian el estado de salida del comando connect.
+
+Antes de que se realice una instalación o reparación, OpenCodex ejecuta el lanzador guardado con `--version` mientras se omite el inicio del servicio. Rechaza el cambio y retrocede cuando el lanzador resuelve `codex` de nuevo a la shim, sale distinto de cero, excede los cinco segundos, deja a los descendientes corriendo o no puede validarse y limpiarse de forma segura. Por lo tanto, `codex-shim install` no es incondicional. Si se rechaza, reinstale Codex para que la entrada PATH sea un ejecutable concreto o un lanzador y reintente; use `ocx service install` en su lugar cuando un lanzador de administrador de comandos dinámico no pueda cumplir con estas comprobaciones. Los rechazos de limpieza incluyen un sufijo de diagnóstico limitado que identifica la fase de sonda, un código o señal de error nativo reconocido, y el estado de salida cuando se conoce. No incluye rutas de lanzamiento ni salida de raw child, y no relaja las comprobaciones de validación o reversión. Una shim Unix más antigua instalada en su lugar es migrada solo por una `ocx codex-shim install` explícita. La migración restaura el lanzador nativo registrado sin reemplazar un lanzador más nuevo ya presente, luego instala el envoltorio privado. Si la instalación privada falla después de la restauración nativa, el lanzador nativo permanece restaurado y la operación se puede volver a intentar. Lanzadores nativos faltantes o inutilizables requieren reparación del gestor de paquetes; OpenCodex no adivina otra instalación ni vuelve a envolver la ruta del administrador. La migración también se niega cuando el `codex-shim.json` registrado no es un archivo regular de su propiedad o es grabable en grupo o en todo el mundo. Las versiones anteriores escribieron ese archivo con el proceso umask, por lo que un umask de `002` lo dejó en el modo `0664`. El rechazo nombra el archivo y el `chmod 600` que aclara solo el rechazo escrito en grupo o en todo el mundo. Se mantienen Symlink y las denegaciones de propietarios extranjeros; OpenCodex no cambia los permisos en sí.
+
+La instalación del lanzador por sí sola no prueba que las solicitudes Codex usarán OpenCodex. Después de una instalación ejecutable, el comando comprueba el enrutamiento Codex actual e informa una advertencia en lugar de un resultado verde cuando el enrutamiento es externo, de propiedad del usuario o no verificable. También advierte cuando existen variables proxy salientes solo en el proceso actual, mientras que `config.proxy` no está configurado o no se ha resuelto, porque los lanzadores Codex y los servicios en segundo plano pueden no heredar ese entorno. Estas comprobaciones son de solo lectura y nunca imprimen valores de proxy; resuelva el traspaso informado y ejecute `ocx doctor` antes de confiar en el inicio automático.
+
+En Unix, la reparación automática actualiza solo el envoltorio privado y nunca reescribe el gestor de paquetes Lanzadores o migra una shim más antigua en el lugar. En Windows, si se ha completado una actualización externa de Codex sobrescribe una shim instalada, el siguiente ordinario `ocx` El comando respalda el nuevo lanzador estable y restablece la shim antes del envío. El efecto cero
+`ocx system codex-cli-update check` de inspección e invocaciones malformadas en su reserva
+`ocx system codex-cli-update` El espacio de nombres nunca realiza esa reparación. `ocx status`, `ocx doctor`, y
+`ocx codex-shim status` también omita la reparación automática de la shim e informe el estado observado. Un lanzador que todavía está cambiando se deja intacto y se vuelve a intentar más tarde. Fallas de reparación advierten sin fallar el pedido comando; fallback manual: `ocx codex-shim install`. Establecer `codexShimAutoRestore` a `false`, o establecer
+`OPENCODEX_CODEX_SHIM_AUTO_RESTORE=0` para una opción de exclusión a nivel de proceso.
+
+El contenedor Unix conserva su ruta nativa de lanzador registrada. Los cambios del gestor de paquetes detrás de esa entrada duradera se siguen automáticamente; eliminar esa entrada requiere reparación del gestor de paquetes. Los lanzadores de administradores de comandos dinámicos todavía tienen que pasar la validación anterior. Windows reparación en el lugar necesita el original guardado al lado de la shim; si un gestor de versiones destruye todo el árbol y copia de seguridad, OpenCodex informa de la condición y se detiene en lugar de inventar un original de reemplazo.
+
+Si el lanzador del gestor de versiones no puede pasar la validación, rutee la configuración Codex en lugar del lanzador: `ocx start` escribe `openai_base_url` y `ocx service install` proporciona autoarranque. Ejecute `ocx status` para confirmar - informa el enrutamiento activo, y advierte cuando un proxy en ejecución no es el Codex se apunta.
+
+| Subcomando | Medidas adoptadas |
+| --- | --- |
+| `install` | Instalar la cuña (o reparar si es rancio). |
+| `uninstall` | Retire los artefactos privados de Unix, dejando intacto el nativo Codex; el Windows, restaure el lanzador original. |
+| `remove` | Alias de `uninstall`. |
+| `status` | Informe el estado de la cuña y si el envoltorio privado está activo en PATH. |
+
+```bash
+ocx codex-shim install
+ocx codex-shim status
+ocx codex-shim uninstall
+```
+
+Después de desinstalar Unix, elimine la línea de origen del archivo de inicio de shell y reinicie el shell o elimine la entrada de bin privado de su PATH. La desinstalación elimina el envoltorio, el archivo de entorno de shell y el estado propios; deja intacto el lanzador del administrador de paquetes. Se libera una shim Unix más antigua en el lugar utilizando sus datos de restauración registrados.
+
+:::note[Entorno del token en Windows]
+Windows CMD y las shims PowerShell recientemente generadas restauran el número de la persona que llama `OPENCODEX_API_AUTH_TOKEN` Después de la ejecución. Codex y sus procesos secundarios aún pueden heredar el token.
+
+Después de actualizar OpenCodex, vuelva a crear una shim Windows existente con `ocx codex-shim uninstall` seguido por `ocx codex-shim install` para obtener este comportamiento. Una actualización ordinaria no reescribe una shim Windows saludable.
+:::
+
+:::tip[Servicio y shim]
+Uso `ocx service` para un proxy de fondo siempre activo (recomendado). Uso `ocx codex-shim` por arranque ligero bajo demanda sin un demonio — el proxy se inicia solo cuando `codex` es lanzado.
+:::
+
+<a id="token-injection-into-codex"></a>
+
+#### Inyección de token en Codex
+
+En un enlace que no es de loopback, el proveedor inyectado lleva `env_key = "OPENCODEX_API_AUTH_TOKEN"`. Esa línea indica a Codex qué variable leer; no la crea. Codex se niega a iniciar una solicitud cuando falta la variable (`Missing environment variable: OPENCODEX_API_AUTH_TOKEN`), y el proxy nunca se alcanza. El valor vive en `$OPENCODEX_HOME/service-api-token`; el proceso de lanzamiento debe suministrarlo en el entorno de Codex.
+
+Utilice la shim mantenida instalada por `ocx codex-shim install`. Cuando el contexto de lanzamiento resuelve esta shim, lee el archivo de token creado por OpenCodex y suministra la variable a Codex. Los lanzamientos de escritorio, cron y servicio deben usar una ruta PATH o un trazado de lanzamiento que seleccione la shim; la instalación no configura esos entornos automáticamente. Los propios procesos hijo de Codex aún pueden heredar el token.
+
+No exporte este token portador desde un archivo de inicio de shell ni lo copie en `config.toml`. El archivo `service-api-token` contiene el token sin procesar, no las asignaciones `NAME=value`, por lo que no se puede usar directamente como un systemd `EnvironmentFile=`.
+
+Un `EnvironmentFile=` o `OCX_API_TOKEN_FILE` en `opencodex-proxy.service` configura el proceso proxy solamente y nunca fluye a un `codex exec` lanzado independientemente.
+
+Las actualizaciones de Unix package-manager dejan el envoltorio privado intacto. Un envoltorio ejecutable que es **No activo** no inyecta el token: fuente del archivo de activación impreso en el shell de inicio. En Windows o con una shim en el lugar más antigua, una actualización Codex que reemplaza el lanzador elimina la shim; en Windows el siguiente comando ordinario `ocx` lo restaura (ver arriba), pero un `codex exec` que corre antes falla. `ocx doctor` informa de este estado exacto bajo "Codex env_key listo para el lanzamiento" (env_key configurado, variable unset, calza faltante o insalubre, archivo de token presente) con reparación o guía de activación, y nunca imprime el token. La lectura del archivo token no forma parte del contrato `env_key` inyectado; el proceso de lanzamiento debe suministrar esa variable.
+
+### `ocx tray <install|start|stop|status|uninstall|remove> [--json] [--no-start]`
+
+Instale y controle el icono de la bandeja de estado Windows. Se inicia en el inicio de sesión Windows y proporciona controles proxy con un solo clic. `start` y `stop` controlan el icono solamente; use su menú para controlar el proxy. `--no-start` se aplica a `install` e instala la bandeja sin lanzarla inmediatamente. En desuso: la aplicación de escritorio OpenCodex proporciona la bandeja en Windows, macOS y Linux; `ocx tray` permanece para las instalaciones sin la aplicación de escritorio. Cuando se conoce una versión de paquete más reciente, la bandeja agrega un punto azul a su icono en línea, advertencia o sin conexión y muestra **Actualización disponible**. La bandeja comprueba su insignia local almacenada en caché aproximadamente una vez por minuto; los resultados obsoletos o no disponibles eliminan el punto. El elemento de menú abre el panel de control, donde puede iniciar la actualización del paquete. No se instala automáticamente.
+
+<a id="dashboard"></a>
+
+## Panel
+
+### `ocx gui`
+
+Abra el [panel web](/es/guides/web-dashboard/) en `http://127.0.0.1:<port>` - o en `http://127.0.0.1:<management port>` cuando la entrada de administración de concentradores esté habilitada - inicie automáticamente el proxy si no se está ejecutando.
+
+<a id="updating"></a>
+
+## Actualización
+
+`ocx update` actualiza OpenCodex en sí; no actualiza el Codex CLI. Utilice el [comandos de inspección del sistema](/es/reference/cli/agents/) para inspeccionar el candidato Codex CLI configurado con inspección de procedencia limitada de solo lectura. `ocx system codex-cli-update check` no consulta un registro de paquetes ni instala una actualización.
+
+### `ocx update [--tag latest|preview]`
+
+<a id="orchestrated-update"></a>
+
+#### Actualización orquestada
+
+La automatización puede comprobar la compatibilidad mediante `ocx capabilities --contracts --json`: el array `contracts` incluye `update.orchestrated/1`. La opción de solo contratos no puede combinarse con `--route` ni `--mutating-only`.
+
+```bash
+ocx update --plan --json [--tag latest|preview | --version <version>]
+ocx update --yes --json [--version <version>] [--expect-plan <token>] [--not-after <unix-ms>]
+```
+
+Plan emite un único objeto JSON `ocx.update.plan/1`: `currentVersion`, `targetVersion`, `installer`, `runtimeOwner`, `servingPath`, `cliPath`, `canApply`, el `reason` opcional, `restartRequired`, `planToken`, `updateInFlight` y `mutationBoundMs`. El plan es de solo lectura. Los motivos son `desktop-app-owned`, `source-checkout`, `mise-managed`, `installer-unknown`, `plan-unavailable`, `serving-install-unknown`, `cli-not-serving-install`, `runtime-ownership-refused`, `target-unresolved`, `downgrade-refused` y `up-to-date`. `desktop-app-owned` dirige la actualización a Desktop; una identidad de ejecución incierta provoca rechazo en vez de adivinar. Ejecuta `ocx start` u `ocx stop` para resolver un registro de ejecución obsoleto antes de volver a planificar.
+
+Apply emite un objeto `ocx.update.result/1` con `applied`, `fromVersion`, `toVersion`, `installer`, `restarted`, `healthy`, `rolledBack` y un `error` opcional. Pasa el `planToken` del plan como `--expect-plan` para rechazar con `plan-changed` si cambia la instalación seleccionada o la identidad de ejecución. `--not-after` es un entero positivo y seguro con la hora Unix en milisegundos; después de ese momento se rechaza la modificación con `deadline-passed`. `mutationBoundMs` es 900000 (15 minutos): excederlo informa de un resultado incierto sin terminar una transacción activa. `updateInFlight` sigue siendo true mientras una actualización pueda modificar archivos, incluso si su estado es indeterminado; una sincronización por sí sola no lo activa. Una sincronización simultánea puede rechazar apply con `sync-in-progress`, y otra actualización, con `update-in-flight`.
+
+La aplicación orquestada sale con 0 cuando el resultado está verificado o ya estaba actualizado; con 10 ante un rechazo; con 11 cuando la actualización falló pero se verificó que la versión anterior sigue activa (incluido el runtime cuando corresponde); con 12 cuando el resultado no está verificado o sigue en curso; y con 64 por uso no válido. `rolledBack` solo es verdadero si una reversión real del instalador se realizó y se verificó. Un comando de plan emite su plan con código de salida 0; los campos `canApply` y `reason` describen la elegibilidad.
+
+Las instalaciones independientes compiladas, incluido el paquete de escritorio MSI Windows, se actualizan a través de **Buscar actualizaciones...** en OpenCodex Desktop, o reinstalando el binario independiente desde [GitHub Lanzamientos](https://github.com/lidge-jun/opencodex/releases). `ocx system update check` reporta `installer: "standalone"`, `canUpdate: false` y `reason: "standalone_install"` con esa guía. `ocx update` sale sin éxito con la misma pista; no ejecuta una actualización de gestor de paquetes para el ejecutable compilado. Una comprobación de fuente genuina todavía reporta `installer: "source"` y `reason: "source_checkout"`.
+
+Cuando OpenCodex se instala a través de mise, este comando sale sin éxito antes de detener el proxy o cambiar los archivos del paquete y muestra `mise upgrade <tool>`, utilizando el alias local mise verificado. Las comprobaciones de actualización permanecen disponibles e informan la instalación como administrada externamente. Un registro de propiedad de mise ilegible o inconsistente provoca el rechazo de la operación sin intentar adivinar el nombre de la herramienta, y `--tag preview` nunca cambia la selección configurada de mise.
+
+En Linux, un servicio en segundo plano cuyo lanzador registrado es el lanzador de paquetes de mise (`<tool>/latest/node_modules/.bin/ocx`, no es una mise shim) sigue `mise upgrade` por sí mismo: dentro de unos diez segundos de la nueva versión se establece, drena las solicitudes activas y se reinicia en ella, y se recupera de la misma manera si mise poda más tarde la versión que estaba ejecutando. En macOS, para un servicio instalado a través de una shim de mise, y para un proxy en primer plano, reinicie el servidor después de actualizar (en macOS, `ocx service repair` primero).
+
+Auto-actualización opencodex de npm. Las instalaciones estables usan `@latest`; las instalaciones de vista previa permanecen en `@preview` a menos que pase `--tag latest|preview`. Detecta una comprobación de origen y le dice que `git pull && bun install` en su lugar, y es una opción prohibida si ya está en la versión más reciente para esa etiqueta. Antes de detener cualquier cosa, las instalaciones npm ejecutan una propiedad de caché Unix limitada y una verificación de acceso. Los enlaces simbólicos anidados se verifican con `lstat` pero no se siguen; Windows omite explícitamente esta comprobación de solo Unix. Un error se aborta mientras la bandeja y el proxy siguen ejecutándose. Un proxy en ejecución se detiene antes de reemplazar los archivos; un servicio instalado se reconstruye y se inicia automáticamente, mientras que una instalación en primer plano imprime `ocx start` como el siguiente paso. Los registros de actualización del panel de control redactan las rutas de perfil/caché y los valores UID/GID antes de que persistan. Cuando la dirección IP literal de un oyente detenido deja caer el dial de vitalidad en lugar de rechazarlo (por ejemplo, en una red Tailscale), el actualizador intenta brevemente vincular esa misma dirección y puerto. Un enlace exitoso confirma la ausencia en ese instante; un enlace fallido o una sonda de nombre de host no concluyente aún impide la actualización.
+
+En Windows, las instalaciones predeterminadas de Scoop `nodejs` y `nodejs-lts` `npm` se pueden usar desde el directorio de inicio del usuario cuando su unión `current` permanece dentro del directorio de la aplicación Node; también se admite el directorio `bin` persistente predeterminado. Ejecutando dentro de esa instalación (incluyendo su directorio de versiones resueltas o persistentes `bin`), las entradas de directorio de versiones `npm`, `NO_JUNCTION` de project-local y las raíces Scoop personalizadas debajo de la casa permanecen excluidas.
+
+Si el paso de instalación falla, la versión anterior permanece instalada y su servicio se reinicia; la salida del terminal nombra el siguiente paso, y [Fallo de actualización en Windows](/es/troubleshooting/update-failed/) cubre terminar la actualización y las carpetas que un intento fallido puede dejar atrás.
+
+```bash
+ocx update
+ocx update --tag preview
+```
+
+Las nuevas versiones estarán disponibles cuando el [Liberar el flujo de trabajo](https://github.com/lidge-jun/opencodex/actions/workflows/release.yml) las publique en npm.
+
+<a id="save-cleanup-thresholds-without-starting-a-cleanup"></a>
+
+## Ahorre umbrales de limpieza sin iniciar una limpieza
+
+```bash
+ocx storage policy show --json
+ocx storage policy set --archived-bytes-over 1073741824 --reduce-to-bytes 536870912 --json
+ocx storage policy show --json
+```
+
+El setter escribe anidado `trigger.archivedBytesOver` y un objetivo. Los valores de bytes son enteros no negativos seguros. Alternativamente, elija `--remove-oldest-percent 10` o `--percent 10` heredado; los dos indicadores de porcentaje y reducir a son mutuamente excluyentes. CLI porcentajes son enteros con el servidor-compatible con el rango 1-100. Omitido `--enabled` deja el valor almacenado sin cambios; los valores explícitos son `true` y `false`. El conjunto no se ejecuta en la limpieza, pero un programa ya habilitado permanece vigente. No agregue habilitar o ejecutar una política inmediata a menos que esté previsto.
+
+El recibo de nuevo campo es `{ok:true,policy,job:{status}}`, con el disparador observado, el objetivo, el modo, la programación y los hechos opcionales de última/siguiente ejecución. `job.status` describe un estado inactivo/de funcionamiento existente, no una limpieza iniciada por este commando. Lee de nuevo sobre un resultado desconocido en lugar de reproducir la escritura.
+
+<a id="remote-link-apply-parity"></a>
+
+## Paridad de aplicación de Remote Link
+
+Un Remote Link Child aplica la configuración de Codex administrada por su Home al enlazarse (`ocx link add` en el Home) y en cada `ocx sync`. Tres datos permiten comprobar que el Child realmente usa la configuración aplicada sin leer los archivos de configuración de ninguno de los equipos.
+
+`ocx status --json`, en cualquier dispositivo, incluye:
+
+| Campo | Significado |
+| --- | --- |
+| `appliedCodexSettingsDigest` | SHA-256 hexadecimal en minúsculas de la configuración aplicada (descrita abajo). En un Child, los valores de la última aplicación registrada. En un Home o una instalación independiente, el documento que sirve actualmente a sus Children, calculado con su configuración actual. Es `null` en un cliente Hub, un Child sin aplicación registrada, o uno cuya aplicación de cambios está en curso o falló (primero se retira el resumen anterior para no informar valores que Codex ya no tiene). |
+| `lastApplyAt` | Solo en un Child: milisegundos desde epoch de la última aplicación correcta que cambió los ajustes. Reaplicar los mismos valores conserva la fecha; un `ocx sync` sin cambios nunca fuerza un reinicio. Es `null` en los demás casos. |
+| `runtimeStartedAt` | Solo en un Child: milisegundos desde epoch en que arrancó el entorno cliente en ejecución. Es `null` cuando no responde ningún entorno cliente. |
+
+El resumen se calcula sobre este JSON compacto en UTF-8, con las claves exactamente en este orden, sin espacios y con los valores realmente aplicados:
+
+```json
+{"version":1,"settings":{"fastMode":true,"multiAgentMode":"v1","webSearchSidecarEnabled":false,"subagentDefaults":null}}
+```
+
+`subagentDefaults` es `null` si no se configura; en caso contrario, es `{"model":…,"reasoningEffort":…}` en ese orden. El ejemplo anterior produce `57c751eff89844f93db71a6ee4acdac03afbc29fec52734ade80a40193e826cd`. El resumen no contiene los valores de los ajustes, y el nombre y la versión del Home no forman parte de él: un Home y un Child que aplicaron los mismos valores informan el mismo resumen.
+
+En el Home, cada fila de `ocx link status --json` incluye lo último que declaró el Child: `lastApplyAt`, `runtimeStartedAt`, `appliedCodexSettingsDigest` (con los significados anteriores) y `reportedAt` (milisegundos desde epoch según el reloj del Home). El Child informa poco después del arranque y luego una vez por minuto. El Home solo conserva los informes en memoria: tras reiniciarse, los campos son `null` hasta el siguiente informe. Un Child cuyo entorno arrancó antes de `lastApplyAt` ejecuta un entorno anterior a su última aplicación de ajustes.
+
+<a id="child-operations-from-the-home"></a>
+
+## Operaciones sobre Children desde Home
+
+```text
+ocx link update (--link-id <id> | --all) --yes [--no-wait] [--json]
+ocx link sync (--link-id <id> | --all) [--no-wait] [--json]
+ocx link sync --link-id <id> (--restart-app-server-only | --restart-codex --yes) [--no-wait] [--json]
+ocx link restart-codex --link-id <id> [--scope app-server|codex] --yes [--no-wait] [--json]
+```
+
+Estos comandos crean un trabajo para enlaces iniciados en Home y devuelven `ocx.link.child-job/1`: `{schema, jobId, op, trigger, restart, state, createdAt, finishedAt, items}`. Cada elemento incluye `linkId`, `alias`, `state`, `reason`, `startedAt`, `finishedAt` y, cuando procede, `hint`, `fromVersion`, `toVersion`, `sync` con `{state, reason}` y `restart` con `{requested, outcome}`. `outcome` es `requested`, `unsupported`, `not-run` o `skipped`. Consulta [Operar Children desde Home](/es/guides/remote-link/#operating-children-from-the-home) para acciones, versiones y restricciones Windows/ligeras. Reiniciar nombra un solo enlace; `update`, `restart-codex` y `--restart-codex` requieren `--yes`.
+
+| Salida | Significado |
+|---|---|
+| 0 | Todos `succeeded` o `up-to-date` y cada reinicio solicitado se envió; con `--no-wait`, solo confirma aceptación, no finalización. |
+| 6 | Alguno `busy`, `offline`, `refused`, `owner-action`, `unsupported`, o con `restart-skipped:link-active` o `post-update-sync-failed`. |
+| 1 | `failed`, `uncertain`, estado desconocido, plazo de espera agotado o Home fuera de loopback. |
+| 2 | Argumentos inválidos, por ejemplo reinicio con `--all` o update sin `--yes`. |
+| 4 | Enlace desconocido o Home sin esas operaciones. |
+| 5 | Enlace ocupado, único enlace iniciado desde Child, Home sin enlaces o comando ejecutado en Child; el mensaje distingue la causa. |
+
+La espera excluye el tiempo de un elemento en cola detrás de otro trabajo. Quitar un enlace ocupado devuelve `409 link_operation_in_progress`.
+
+<a id="child-policy-from-the-home"></a>
+
+## Política de Children desde Home
+
+```text
+ocx link policy [--updates off|notify|auto-when-idle] [--catalog-fanout auto|manual] [--child-codex-restart never|app-server-when-idle] [--idle-after-minutes <1-60>] [--json]
+```
+
+`ocx link policy` no crea un trabajo ni devuelve `ocx.link.child-job/1`. Lee la política y solo modifica los ajustes nombrados: `--catalog-fanout auto|manual`, `--child-codex-restart never|app-server-when-idle`, `--updates off|notify|auto-when-idle`, `--idle-after-minutes <1-60>`. Imprime una línea por ajuste o `{policy, warning}` con `--json`. Un archivo dañado informa `policy-file-invalid` y desactiva automatismos; guardar conserva apagado lo no nombrado, por lo que debes indicar `--catalog-fanout auto` y un modo `--updates` para activarlos otra vez. El catálogo se distribuye automáticamente por defecto; consulta [la política](/es/guides/remote-link/#automatic-catalog-fan-out-and-the-child-policy). Salidas: 0 éxito, 2 argumentos, 4 Home antiguo, 5 conflicto `runtime_role_client`, 1 Home no loopback, respuesta inválida o rechazo local por ejecutar en Child.
+
+<a id="remote-link-ssh-capture"></a>
+
+## Captura SSH de Remote Link
+
+```text
+ocx link capture start [--minutes <1-60>] [--json]
+ocx link capture stop [--json]
+ocx link capture status [--json]
+```
+
+Ventana local de 15 minutos por defecto, hasta 60, con `LogLevel=DEBUG1` y copia saneada bajo `<OPENCODEX_HOME>/link/ssh-capture/`. No requiere proxy ni token y sirve en Home o Child. Devuelve `{enabled, logLevel, startedAt, expiresAt, directory, retentionHours, maxMinutes, maxFileBytes, files, removed}`. `stop` conserva archivos; `status` y `start` depuran los que llevan 72 horas sin escribir e informan cuántos quitaron. Consulta [los datos y su saneamiento](/es/guides/remote-link/#capture-ssh-diagnostics). Argumentos inválidos terminan con 2.
+
+`ocx link diagnostics [--limit <n>] [--since <iso-time|epoch-ms>] [--json]` solo lee el historial acotado en el equipo que lo creó, sin proxy activo ni escrituras. Consulta [diagnósticos 503](/es/guides/remote-link/#retryable-503-diagnostics).
+
+**Children ligeros.** `ocx-child sync [--expect-link <id>] [--json]`, `ocx-child status [--json]`, `ocx-child disconnect` y `ocx-child detach` se ejecutan allí; `ocx link status --json` sigue siendo del Home. Un sync correcto inicia `ocx-child serve` si falta, aun sin cambios, lo reemplaza si `runtimeStartedAt < lastApplyAt` y envía un informe de paridad de mejor esfuerzo en sync no obsoleto. Acepta `--restart-codex` y `--restart-app-server-only` sin reiniciar Codex; reinicia Desktop y app-servers por separado. Detach restaura `~/.codex` sin conexión y termina el relay sin dejar daemon.
+
+Solo una instalación ligera administra cada `CODEX_HOME`: usa `CODEX_HOME/.ocx-child.lock`, conservado permanentemente, y `CODEX_HOME/.ocx-child-owner.json` hasta completar detach. `ocx-child attach` o `sync` desde otro `OPENCODEX_HOME` no escribe y exige separar primero el propietario. En un Child completo, sync sin runtime cliente activo no inicia nada; un reinicio fallido deja al anterior sirviendo. El ligero detiene el anterior antes de reemplazar: si falla, no queda relay hasta `ocx-child sync` u `ocx-child restart`. No se intercalan applies. Un segundo `ocx-child sync --expect-link <id>` termina con `5`, `pending_operation`, sin cambios; sin expect-link espera al primero.
+
+**Actualización de servicios.** macOS usa la política launchd `Interactive` para evitar limitación de CPU/E/S de daemon; `ocx service repair` la aplica. Si la definición cambia y launchd rechaza, intenta restaurar la anterior cuando su estado puede comprobarse. Sin comprobación inicial no escribe plist ni respaldo. Si el estado se vuelve incierto después de bootstrap, conserva nueva definición y respaldo sin otra expulsión, distinguiendo rechazo de recarga no verificada. Inspecciona `launchctl print gui/$(id -u)/com.opencodex.proxy` antes de reintentar; puede requerir sesión gráfica. Un estado pendiente no se confirma solo por bytes o comando iguales. Conserva el respaldo original hasta verificar registro; quitar `.prev` después del éxito es de mejor esfuerzo. Los demás errores de limpieza, salvo archivo ya ausente, se notifican sin borrar el estado instalado.
+
+En una instalación Bun, `ocx update` comprueba antes de parar que `config.json` sea legible y no necesite fallback o rescate; si no, termina con 1 manteniendo servicio y bandeja. `ocx config validate` diagnostica sin modificar. Inspecciona permisos, enlaces y destino: validar valores predeterminados ante un enlace roto no demuestra que el archivo sea correcto. Corrige o restaura desde un respaldo confiable antes de reintentar.
+
+En un Child, `ocx connect status` añade `Link tunnel:` con `up`, `down (<reason>)` o `unknown (<reason>)` según `/readyz`; `--json` usa `linkTunnel`. `Connection: connected` solo indica vínculo, no disponibilidad del túnel.
+
+
+
+
+<a id="remote-link-child-attestations"></a>
+
+## Atestaciones del Child de Remote Link
+
+Un equipo que envía trabajo a través de un Child de Remote Link puede comprobar dos datos más en
+`ocx status --json` del Child. Ambos campos se omiten, nunca son `null`, si no pueden demostrarse.
+
+| Campo | Significado |
+| --- | --- |
+| `localCredentials` | `{count, generation}`. `count` es el número de credenciales de proveedor que esta instalación guarda en este equipo: cuentas OAuth, entradas de claves API de proveedor (incluidas las deshabilitadas y las referencias al llavero o al entorno), registros del pool de cuentas de Codex, el `auth.json` nativo de Codex y los perfiles nativos inactivos de Codex. No cuentan las claves de enlace, los tokens de administración ni las claves API entrantes, ni tampoco las cuentas que sirve un Home. `generation` es opaco y cambia cada vez que se añade, sustituye o elimina una credencial guardada, aunque el recuento final sea el mismo. Solo se informa mientras haya un entorno de ejecución de OpenCodex activo en este equipo y todos los almacenes puedan leerse por completo. Si la configuración nativa de Codex tiene `cli_auth_credentials_store` con un valor distinto de `file`, se omite. |
+| `link.connectionGeneration` | En un Child: es opaco y cambia cada vez que el túnel a su Home se conecta (incluida una reconexión que conserva el mismo enlace) y cada vez que se reinicia cualquiera de los dos entornos de ejecución. Solo se informa cuando el entorno del Child está listo. Para un enlace iniciado desde Home, el Child lo obtiene de la respuesta firmada del Home, por lo que un Home con una versión anterior lo omite. |
+
+Un Child que informa `localCredentials.count` 0, con `localCredentials.generation` y
+`link.connectionGeneration` sin cambios durante una solicitud, no tuvo credenciales locales de
+proveedor durante ella ni observó ninguna reconexión del túnel.
+
+Para los enlaces añadidos por Home, cada fila incluye además `tunnel`: `attempt`, cantidad de intentos SSH desde la última conexión; `nextRetryAt`, hora ISO del próximo intento o `null` si hay uno activo o no hay ninguno programado; `lastTransition` (`{from, to, at, cause}`) y `lastFailure` (`{cause, at}`). Las causas posibles son `auth`, `hostkey`, `forward`, `remote_forward_conflict`, `timeout`, `network`, `unknown`, `spawn_failed` y `listener_unavailable`. Home guarda estos datos en memoria, por lo que empiezan vacíos tras reiniciarse. `GET /api/link/status` solo incluye el campo con `?diagnostics=1`, porque las versiones antiguas de `ocx link status` rechazan campos desconocidos.
+
+Después de aplicar los ajustes del Home en el Child, `ocx sync` reinicia el entorno cliente si arrancó antes de `lastApplyAt`, mediante el mismo mecanismo de `ocx restart`. No modifica un entorno que ya arrancó después de la aplicación ni inicia uno si no hay ninguno en ejecución. Un reinicio fallido termina con código distinto de cero y deja funcionando el entorno anterior; vuelve a ejecutar `ocx sync` o `ocx restart` para reintentarlo. Dos aplicaciones en un Child nunca se intercalan: un segundo `ocx sync` mientras se aplica otro falla de inmediato y no cambia nada.
+
+<a id="forced-link-revoke-and-remote-recovery"></a>
+
+## Revocación de enlace forzado y recuperación remota
+
+Solo cuando se pretenda explícitamente omitir la limpieza remota, use el ID de enlace seleccionado real (el `lnk_0123456789abcdef` a continuación es ficticio):
+
+```bash
+ocx link revoke --link-id lnk_0123456789abcdef --force --yes --json
+```
+
+`--force` requiere `--yes`; `--yes` solo no es válido. La revocación ordinaria no cambia. Un éxito forzado devuelve `{linkId,remoteCleanup:"skipped",recovery}`. En su lugar, un link-not-found idempotente informa de `remoteCleanup:"unverified"`. Ambos pueden salir con 0; estos hechos derivan de la intención de la CLI, no de un informe de limpieza del servidor. Ninguno de los dos significa que se intentara o confirmara una desconexión remota. Siga la instrucción de recuperación, `ocx disconnect` en el cliente remoto, cuando esa acción esté autorizada.
+
+<a id="observe-remote-workspace-from-the-hub"></a>
+
+## Observar el espacio de trabajo remoto desde el Hub
+
+```bash
+ocx remote-workspace hub status --json
+ocx remote-workspace hub runtimes --json
+ocx remote-workspace hub sessions --json
+```
+
+Estas lecturas de gestión fija están separadas del ejecutor-local `ocx remote-workspace status`. La disponibilidad en entorno de ejecución es un objeto clave; un concentrador disponible sin dispositivos/sesiones es un éxito vacío. La observación del Hub desactivado puede llegar como HTTP 200 con `available:false` pero sale con 1; no es un éxito vacío. Una respuesta HTTP 409 interna sale con 5. Nunca registra dispositivos, crea sesiones ni envía mensajes. Véase [Observación y recuperación del Hub](/es/guides/remote-workspace/#inspect-the-hub-without-starting-a-session).
+
+<a id="remote-hub-client-lifecycle"></a>
+
+## Ciclo de vida del cliente de Remote Hub
+
+Use `ocx connect <url> --pairing-code-stdin`, `ocx connect status`, `ocx sync` y `ocx connect rotate --pairing-code-stdin`. La descarga inicial del catálogo falla después de cinco segundos sin bytes entrantes, pero las transferencias activas pueden durar más; use `--catalog-timeout <seconds>` (1-120) para anular esa ventana de inactividad. `ocx disconnect` restaura el estado local sin conexión y no revoca la clave de concentrador. Mientras está conectado solamente, `ocx connect revoke --admin-token-stdin` revoca el `apiKeyId` persistente; después de desconectar, use la página **Conecte las llaves → API** del concentrador. Los secretos son solo Stdin y nunca pertenecen a Argv.
+
+<a id="setup-port-validation"></a>
+
+## Validación del puerto de configuración
+
+`ocx init` acepta TCP puertos 1-65535 como números enteros decimales. Presione Enter para usar 10100. La entrada no válida como `0`, `10100oops` o `1.5` nunca se reemplaza o trunca silenciosamente; la configuración la informa y vuelve a solicitar el puerto.
+
+<a id="login-registration-diagnostics"></a>
+
+## Iniciar sesión registro diagnósticos
+
+En Linux, `ocx service install` controles `loginctl show-user <current-user> -p Linger` antes de imprimir el consejo de arranque. La demora habilitada se informa como ya habilitada. La persona desactivada se queda con el `loginctl enable-linger $USER` hint; los diagnósticos faltantes o ilegibles indican la incertidumbre y no fallan la instalación.
+
+En macOS, `ocx service status` distingue un elemento de inicio de sesión de escritorio cargado de un registro válido habilitado en espera del siguiente inicio de sesión. `ocx status` acredita a este último en seguridad de reinicio cuando la misma aplicación de escritorio supervisa actualmente el proxy. Una etiqueta o comando de lista incorrecto, una entrada deshabilitada, una sonda de carga no verificada o una identidad de proceso cambiada aún no pueden obtener protección.
+
+<a id="custom-codex-provider-consent"></a>
+
+## Consentimiento personalizado del proveedor Codex
+
+`ocx codex-provider status` enumera los ID de proveedor aprobados para el hogar seleccionado Codex. `ocx codex-provider allow <id>` pregunta antes de permitir la administración de solo URL en inicio/sincronización; `--yes` es el consentimiento explícito no interactivo para ese proveedor nombrado. `ocx codex-provider revoke <id>` restaura una URL administrada sin cambios y revoca el permiso. Estos comandos son locales y no requieren un proxy en ejecución. Ver [enrutamiento de proveedor personalizado](/es/guides/codex-integration/#opt-in-a-custom-provider-to-managed-local-routing) para elegibilidad, comportamiento de restauración y preservación del transporte.
+
+### Diagnóstico de propiedad y comandos del Child
+
+1. Verifica de manera independiente identidad del proceso, instalación, directorio, supervisor y dirección/puerto real de escucha, con permisos suficientes para IPv4, IPv6 y comodines. Un PID reutilizable o una inspección incompleta no prueba propiedad ni ausencia; las herramientas citadas abajo solo aportan indicios.
+2. Solo si todos esos hechos se confirman y se acepta terminación forzada, el dueño puede ejecutar `ocx stop` desde la instalación y el directorio propietarios. Primero intenta parar con normalidad, pero puede forzar la terminación o rechazarla. No eludas un rechazo.
+3. Confirma independientemente que el proceso terminó, que ningún supervisor lo reiniciará y que dirección y puerto están libres. Una parada correcta o un resultado de estado no prueba las tres cosas. Solo entonces usa `ocx start` desde la instalación, directorio, bind y puerto previstos. Si una comprobación queda incompleta o forzar el cierre no es aceptable, detente y pide al propietario o administrador que investigue; no edites el registro ni mates procesos ajenos.
+
+
+Antes de detener un PID desconocido, inspecciona su proceso con `ps -p <pid> -o pid=,ppid=,args=` y el listener con `lsof -nP -iTCP:<port> -sTCP:LISTEN`. Que `lsof` encuentre un puerto no demuestra que ese proceso pertenezca al registro de OpenCodex. No elimines registros de propiedad ni detengas procesos cuando no se puede confirmar el dueño.
+
+En el Home, `--child` selecciona el agente ligero `ocx-child`; el estado `child` distingue instalación, catálogo y actividad observados. `ocx link check (--link-id <id> | --all) [--no-wait] [--json]` comprueba sin actualizar. `ocx link update` actualiza con confirmación y `ocx link restart-codex` reinicia según el alcance elegido; no equivalen a sincronizar un catálogo. En una actualización local, `ocx update --plan` permite inspeccionar el plan antes de ejecutarlo. Consulta [operaciones de Remote Link](/es/guides/remote-link/#child-install-catalog-and-activity).
diff --git a/docs-site/src/content/docs/es/reference/cli/messaging.md b/docs-site/src/content/docs/es/reference/cli/messaging.md
new file mode 100644
index 00000000000..bcfd7bed71b
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/cli/messaging.md
@@ -0,0 +1,211 @@
+---
+title: "Mensajería de Codex"
+description: "Envía mensajes correlacionados a sesiones de Codex cargadas localmente o mediante pares SSH registrados expresamente."
+---
+
+`ocx message sessions` y `ocx message send` son funciones opcionales para sesiones existentes de Codex. No inician un proxy ni un app-server, no reanudan hilos ni instalan skills. Admiten sockets Unix en Linux y macOS; la mensajería local en Windows falla explícitamente. El daemon de Codex existente debe admitir el método experimental `thread/queue/add`. No requieren fijar una versión de la CLI ni seleccionar `CODEX_CLI_PATH`.
+
+El [servidor MCP de colas](#mcp-queue-host) descrito a continuación es independiente: puede dirigirse a UUID de hilos almacenados sin un socket de control. No cambia la restricción de sesiones cargadas de los comandos anteriores.
+
+<a id="mcp-queue-host"></a>
+
+## Servidor MCP de colas
+
+Ejecuta `ocx message mcp` solo cuando quieras que un cliente MCP, como Claude Code o Claude Desktop, descubra hilos almacenados de Codex y les envíe texto a la cola. Este servidor se comunica mediante stdio, no abre ningún listener de red ni se registra automáticamente en clientes. Configura el cliente MCP con una CLI de Codex explícita y un directorio personal existente:
+
+```json
+{
+  "mcpServers": {
+    "opencodex-queue": {
+      "command": "ocx",
+      "args": [
+        "message", "mcp",
+        "--codex", "/absolute/path/to/codex",
+        "--codex-home", "/absolute/path/to/.codex"
+      ]
+    }
+  }
+}
+```
+
+Sustituye ambas rutas por las rutas locales reales y usa una ruta absoluta para `ocx` si el cliente no hereda PATH. Esta primera versión admite macOS y Linux; Windows se rechaza explícitamente.
+
+- `codex_threads` enumera como máximo 50 hilos almacenados y no archivados. Para obtener otra página, pasa `nextCursor` como `cursor`. Devuelve identificadores y nombres, sin historial, vista previa ni directorios de trabajo. `liveStateVerified: false` significa que no demuestra que el hilo esté abierto en la aplicación ni listo para procesar un mensaje.
+- `codex_queue_message` acepta un UUID exacto `threadId` y un `message`. Envía solo mensajes autorizados por el usuario. El texto junto con la etiqueta fija de par tiene un límite de 16 KiB; se rechazan el texto vacío y NUL. No se adivinan nombres ni se cambia el modelo. Tampoco se conceden permisos ni se generan respuestas automáticas.
+
+Cada llamada a una herramienta de cola/metadatos o de lectura de respuestas guardadas inicia por stdio un app-server de corta duración de la CLI de Codex seleccionada explícitamente. Usa `thread/list` o el mismo método experimental `thread/queue/add` que `codex queue`, sin incluir el texto en los argumentos del proceso. No solicita iniciar un daemon, iniciar sesión, reanudar un hilo, empezar un turno ni redirigir un turno activo. El inicio normal de OpenCodex no ejecuta estos auxiliares. La CLI nativa puede mantener su propio estado en el directorio elegido; esta función no crea un almacén de OpenCodex.
+
+`queued` significa que una respuesta de cola correlacionada confirmó el almacenamiento, **no el procesamiento**. Un rechazo explícito produce `not_sent`; una desconexión, un tiempo de espera agotado o un recibo inválido después de escribir en la cola produce `unknown`. Nunca repitas un envío incierto. Un hilo no cargado puede seguir esperando, y un objetivo o turno activo puede retrasar el consumo. El servidor no activa un hilo no cargado. Las herramientas de cola predeterminadas no leen la respuesta; la lectura explícita se describe abajo. Verifica esos comportamientos con la combinación instalada de aplicación y CLI antes de depender de la entrega.
+
+Cada servidor permite como máximo cuatro llamadas simultáneas a auxiliares. Cada operación dispone de 20 segundos, incluida la validación del ejecutable, con un plazo RPC de 12 segundos y un límite de salida de 1 MiB. La limpieza pasa a SIGKILL después de 600 ms. La desconexión o cancelación detiene los auxiliares de esa invocación y espera su terminación; nunca detiene al destinatario. El ejecutable seleccionado en macOS pasa por la comprobación existente de confianza de ejecución del paquete. El acceso MCP y el directorio elegido establecen un límite de confianza del usuario local, no una autorización por proyecto o hilo. El texto entrante de un par es contexto, nunca prueba de aprobación del usuario ni de autoridad delegada.
+
+Esta ruta de colas almacenadas es distinta de `sessions` y `send`: estos siguen exigiendo un descubrimiento completo de sesiones cargadas mediante el socket de control existente y nunca inician un auxiliar de la CLI nativa. Los pares remotos, el transporte de bandejas de Claude, los traspasos persistentes, la entrega automática de respuestas, la redirección de turnos y la configuración automática de clientes quedan fuera de este servidor.
+
+
+<a id="opt-in-stored-turn-replies"></a>
+
+## Lectura explícita de respuestas guardadas
+
+Añade `--allow-reply-read` a los argumentos del host MCP para exponer `codex_read_reply` y `codex_wait_reply`. Sin la opción conserva las dos herramientas previas y el descubrimiento de solo metadatos. Permite expresamente que el texto de la conversación llegue al cliente MCP: el acceso de usuario local al directorio no es autorización por proyecto o hilo. Un `clientMessageId` es correlación, no credencial ni consentimiento.
+
+```sh
+ocx message mcp --codex /absolute/path/to/codex --codex-home /absolute/path/to/.codex --allow-reply-read
+```
+
+Usa `codex_read_reply` con `threadId` exacto y `clientMessageId` del recibo de cola. Busca como máximo una página de 50 elementos por llamada; si encuentra la entrada, identifica el turno y devuelve una página de textos de agente `final_answer`. Omite cuerpos del usuario, razonamiento, comandos, citas y resultados de herramientas. Presupuesto total de 20 segundos para hasta tres helpers secuenciales más limpieza propia; cada helper conserva 12 segundos RPC y 1 MiB de salida. Hasta 16 KiB de texto por página, UTF-8 válido y `truncated` por elemento. `nextCursor` continúa elementos, no bytes omitidos.
+
+- `observed`: entrada encontrada; `replies` puede estar vacío. Siempre `same_turn_not_exclusive`: son textos del mismo turno, no una respuesta certificada exclusiva a esa entrada. Puede haber texto anterior a otra entrada del turno compartido. `turnStatus` procede de los últimos 50 resúmenes o es `unverified`; completar un turno no completa un objetivo.
+- `not_observed`: no aparece en esta página; no demuestra falta de entrega, borrado ni ausencia de respuesta. `reachedHistoryEnd` describe posición, no entrega/procesamiento. Continúa `nextCursor` no nulo para buscar antes.
+- `ambiguous`: varias entradas coincidentes; no devuelve texto.
+- `available: false`: acceso desactivado, entrada/cursor inválido, historial mal formado, método nativo ausente, cancelación o fallo de lectura. No expone diagnóstico nativo ni representa fallo como éxito vacío.
+
+Pasa `nextCursor` como `cursor` para continuar. Tras coincidir, `refreshCursor` vuelve al inicio del turno para recoger elementos finalizados después; revisita todas las páginas y actualiza por ID para evitar duplicados. No hay bandeja persistente ni sondeo en segundo plano. Un cursor nulo solo termina esa instantánea, no la salida futura. Los cursores son posiciones acotadas del cliente, asociadas a ambos IDs, no permisos firmados. La continuación vuelve a verificar entrada, turno y correlación; posiciones obsoletas o fuera de ámbito fallan sin reiniciar todo el historial. Solo usa `thread/items/list`, `thread/items/read`, `thread/turns/list`: no reanuda, dirige, inicia turnos ni modifica colas. Se observó con Codex CLI 0.166.0; versiones antiguas pueden no admitirlo, sin fallback ilimitado. No demuestra receptor activo, objetivo completo ni registro en Claude Desktop, y no añade entrega automática o transporte inverso de Claude.
+
+<a id="bounded-reply-waiting"></a>
+
+### Espera acotada de respuestas
+
+`codex_wait_reply` acepta los mismos IDs/cursor y `waitMs`, entero de 1 a 20.000, por defecto 20.000. Realiza hasta tres instantáneas separadas por dos segundos, incluyendo helpers y pausas en el plazo y reutilizando validación y límites. Hasta nueve helpers secuenciales; la antigüedad se mide desde el inicio de la última instantánea correcta, incluidos metadatos y limpieza. Comparte las cuatro plazas del host y ocupa una hasta terminar, más la limpieza. Cuatro esperas pueden dejar envíos y consultas ocupados; las adicionales se rechazan sin cola. Usa menos si necesitas capacidad de envío.
+
+Solo lee datos guardados; no despierta un hilo descargado. Para continuar trabajo, el usuario abre o reanuda la conversación en Codex nativo. Enviar y esperar son llamadas distintas. Un texto apto devuelve `waitOutcome: reply_observed` inmediatamente aunque ya existiera; no es suscripción ni propiedad exclusiva. Una coincidencia ambigua devuelve `ambiguous`; una siguiente página sin texto apto devuelve `needs_pagination`, sin recorrer todo el historial.
+
+En otro caso actualiza turno o repite posición hasta el límite, devolviendo `wait_exhausted` con la última observación válida. `attempts` cuenta intentos y `lastObservationAgeMs` su antigüedad. Solo cuenta una instantánea cuyas lecturas terminaron antes del plazo; la limpieza posterior no la invalida, pero datos leídos tarde caducan. Sin observación válida, ante error o cancelación, el resultado no está disponible; nunca es espera correcta vacía. Un `turnStatus` guardado puede diferir del servidor activo y no termina la espera. El cliente administra paginación e IDs; cancelar limpia pausas y helpers. No hay vigilancia en segundo plano, entrega automática ni creación o reanudación de sesiones.
+
+
+<a id="discover-and-send"></a>
+
+## Descubrir y enviar
+
+```bash
+ocx message sessions --json
+printf '%s\n' 'Please review the current change and send your findings back.' |
+  ocx message send --name 'reviewer' --stdin --json
+```
+
+El descubrimiento devuelve únicamente los identificadores de los hilos cargados, sus nombres y sus estados de ejecución, sin historial, vistas previas ni directorios de trabajo. `--thread` exige un UUID exacto y `--name`, un único nombre exacto de sesión cargada. Los destinos inexistentes, duplicados, incompletos o no cargados producen un error. No se usan coincidencias aproximadas ni se recurre a sesiones almacenadas.
+
+El socket de control existente se localiza dentro del `CODEX_HOME` efectivo, con la misma política de selección del directorio que los demás comandos de integración de Codex. Antes de conectar, se comprueba que la ruta resuelta sea un socket y pertenezca a tu uid. Cada directorio padre hasta la raíz debe pertenecer a tu uid o a root y no permitir escritura al grupo ni a otros usuarios, salvo directorios con sticky bit propiedad de root, como `/tmp`. Se admiten directorios personales enlazados si sus rutas resueltas superan las comprobaciones. Una ruta no confiable produce `untrusted_socket` sin revelar la ruta resuelta.
+
+El descubrimiento, la comprobación final de que el destino sigue cargado y el envío a la cola usan una misma conexión a ese socket. No se ejecuta un auxiliar de la CLI nativa ni se instala, repara o reconecta nada. Un daemon sin soporte de cola local devuelve `unsupported_queue`.
+
+Solo se acepta texto UTF-8 por stdin: como máximo 16 KiB, no vacío y sin NUL. Un único plazo de 30 segundos cubre la lectura, el descubrimiento, la revalidación y el envío. Cada RPC tiene un máximo de 10 segundos y la envolvente completa, de 32 KiB. El texto viaja por la conexión RPC Unix y nunca se incluye en los argumentos de procesos auxiliares.
+
+<a id="sender-and-replies"></a>
+
+## Remitente y respuestas
+
+El wrapper genera un UUID para el mensaje y adjunta el identificador y el nombre del remitente a partir de un `CODEX_THREAD_ID` cargado y los metadatos del daemon. Este contexto **no autentica la autoridad del par** y nunca constituye aprobación del usuario ni permite elevar privilegios. Si el remitente declarado es inválido o no está cargado, la operación falla. Si falta el contexto, queda como desconocido y no se inventa una ruta de respuesta. Los mensajes de pares se encolan como texto, no como aprobaciones de permisos ni cambios de configuración. El entorno del agente receptor aplica sus permisos; las instrucciones de la envolvente no establecen una barrera técnica de autorización ni garantizan el comportamiento del modelo.
+
+El tipo predeterminado es `request`. Contesta usando el `replyCommand` generado en el sobre, o correlaciona explícitamente una respuesta:
+
+```bash
+printf '%s\n' 'Review findings: ...' |
+  ocx message send --thread <sender-thread-uuid> --kind response \
+    --in-reply-to <request-message-uuid> --stdin --json
+```
+
+`response` requiere `--in-reply-to`; los demás tipos lo rechazan. Usa `--kind notification` para informar sin pedir respuesta. Las respuestas y notificaciones no solicitan acuses de recibo. La respuesta final normal de un agente no se envía a su par; nunca deben inventarse rutas que falten. No se modifican los prompts globales ni se crean bucles de confirmación.
+
+<a id="receipts-and-exit-codes"></a>
+
+## Recibos y códigos de salida
+
+`--json` emite un recibo versionado (`ocx-message/1`) que contiene el mensaje UUID, tipo, correlación de respuesta, metadatos de remitente/objetivo y estado de envío. Nunca incluye el texto del cuerpo o la salida del demonio en bruto. Fallos de entrada/configuración antes de que exista un recibo, use `ocx-message-error/1` con `not_sent`; los fallos de detección usan el mismo esquema de error sin un estado de envío. El uso no válido sale con 64 en stderr antes de E/S.
+
+| Situación | Salir | Descripción |
+| --- | --- | --- |
+| `not_sent` | 1 | Validación/descubrimiento/revalidación falló, no se escribió ningún marco de cola o el demonio lo rechazó explícitamente. |
+| `queued` | 0 | Una respuesta de demonio correlacionada reconoció la presentación, **no procesamiento** por el destinatario. |
+| `unknown` | 3 | El mensaje puede haberse enviado a la cola, pero se perdió el acuse de recibo, estaba malformado, no correspondía a la solicitud o se canceló la operación. **No vuelvas a enviar el mensaje.** |
+
+El UUID de mensaje de aplicación es también el `clientUserMessageId` de la petición de cola. El ID de envío del daemon está separado; ninguno de los dos demuestra el procesamiento del destinatario. La cola no es la dirección y puede esperar a que un giro ocupado para terminar. OpenCodex no realiza ninguna repetición automática, sondeo de seguimiento, persistencia o monitoreo de entrega. La comprobación final del objetivo cargado y la presentación de la cola no son atómicas: si el objetivo se descarga después, un rechazo explícito es `not_sent` con `queue_rejected`; una respuesta perdida o inválida es `unknown`. OpenCodex no lo reanuda ni vuelve a intentarlo.
+
+<a id="explicit-remote-peers"></a>
+
+## Pares remotos explícitos
+
+La mensajería remota es independiente de Remote Link y del inicio normal del proxy. No redirige proveedores, no comparte sus credenciales ni inicia un daemon nativo. Ambos nodos necesitan una CLI OpenCodex compatible y un daemon existente que admita colas. Linux cuenta con pruebas aisladas de interoperabilidad. macOS requiere una validación propia. El transporte remoto en Windows no está soportado.
+
+En cada nodo, habilite explícitamente la mensajería. En el nodo receptor, mantenga el propietario en primer plano en ejecución:
+
+```bash
+ocx message enable --port 39176 --json
+ocx message serve --json
+```
+
+En el nodo de inicio, use su destino/alias OpenSSH existente. Verifique la huella digital ofrecida contra una fuente confiable antes de confirmarla:
+
+```bash
+ocx message hosts probe --ssh worker --json
+ocx message hosts add worker --ssh worker --fingerprint 'SHA256:<confirmed-key>' --json
+ocx message hosts list --json
+ocx message serve --host worker --json
+```
+
+Los registros de sondeo privados mantienen su formato prefijado por alias incluso cuando su configuración SSH normal habilita `HashKnownHosts`; su archivo known_hosts normal no cambia. Cada intento de inscripción utiliza su propio archivo de rascado de clave fija calificado para la transacción, eliminado después de que su ayudante SSH se resuelva, incluidos los fallos, sin depender del bloqueo del propietario de otra mutación. Si la limpieza no se puede confirmar, el comando informa de un resultado de almacenamiento desconocido, no de éxito. El diario de recuperación está separado.
+
+`hosts add worker` autoriza mensajes salientes desde este nodo iniciador hacia el `worker` registrado; **no concede acceso entrante arbitrario a las sesiones locales del iniciador**. El intercambio de control SSH autoriza esa dirección de salida en el receptor mediante tu sesión SSH existente. El recibo de inscripción y `hosts list` muestran la política de entrada local de cada nodo. En el iniciador, la política predeterminada es `responses-only`: el par solo puede ver y responder a las sesiones locales originales que esperan una respuesta correlacionada a una solicitud enviada por este nodo. La respuesta debe coincidir con el UUID de solicitud, la inscripción y el destino local original; no puede dirigirse a otra sesión ni convertirse en una solicitud o notificación no solicitada.
+
+Para conceder un acceso más amplio en cualquiera de los nodos, ejecute explícitamente en ese nodo:
+
+```bash
+ocx message hosts allow-inbound <peer-alias-or-machine-uuid> --json
+# Withdraw the broad grant without removing enrollment:
+ocx message hosts deny-inbound <peer-alias-or-machine-uuid> --json
+```
+
+`allow-inbound` concede expresamente el acceso más amplio: permite los tres tipos de mensaje en **cualquier sesión local cargada de Codex** y expone a ese par los metadatos de su directorio. No es un permiso limitado a respuestas. Los cambios de consentimiento se aplican a las conexiones existentes antes de posteriores lecturas o envíos. Los registros antiguos sin una política local de entrada usan `responses-only` de forma predeterminada. Cada proceso propietario en primer plano admite como máximo 256 solicitudes de respuesta pendientes; las rutas caducan a las 24 horas o al retirar o reiniciar el proceso propietario. Si no hay contexto del remitente, no hay ruta de respuesta. Una respuesta encolada o incierta consume su ruta; un rechazo nativo confirmado no. Si la ruta se pierde o caduca, el operador y el remitente deben reconciliar el estado de forma explícita, sin repetición automática.
+
+Cada `serve` es propiedad de primer plano: manténgalo en funcionamiento y use un terminal separado para la mensajería. A lo sumo se pueden suministrar cuatro selecciones de `--host` distintas. Nada instala un servicio o inicia un propietario automáticamente. SSH utiliza claves de host ancladas confirmadas y sus claves/agente configurados; las solicitudes de contraseña están deshabilitadas. La envoltura posee rutas de retorno y de avance solo de bucle, por lo que el nodo receptor puede enviar respuestas correlacionadas sin un inicio de sesión SSH al iniciador, sujeto a la política anterior.
+
+```bash
+ocx message status --json
+ocx message sessions --host worker --json
+printf '%s\n' 'Please review and reply using the supplied route.' |
+  ocx message send --host worker --name reviewer --stdin --json
+```
+
+`--host` selecciona un alias inscrito exacto o UUID de máquina. Los comandos de respuesta incluyen el UUID de máquina de origen validado y el UUID de subproceso; la identidad de origen se resuelve en el demonio de origen, no se adivina desde un directorio remoto. Sin el contexto del remitente, no hay un comando de respuesta inventado. Los comandos locales sin `--host` conservan su ruta sin estado/sin SSH/sin oyente. El receptor valida la envolvente canónica completa contra el UUID de máquina y mensaje nativo autenticado, incluyendo el host/comando de respuesta y la guía de pares estándar. Un par no puede etiquetar el envoltorio como otro equipo u omitir su advertencia de no mensaje de usuario. Los nombres de sesión y los identificadores de subproceso siguen siendo reclamos descriptivos de esa máquina, no autenticación por sesión.
+
+Las capacidades direccionales emitidas por el receptor se guardan en el estado privado de mensajería bajo `OPENCODEX_HOME` o el directorio de configuración predeterminado de OpenCodex. Nunca aparecen en la salida habitual de comandos, argumentos auxiliares, URL ni sobres de mensajes. Las pruebas mutuas autentican la conexión WebSocket real antes de aceptar tramas nativas o el cuerpo del mensaje. Una comprobación de salud por separado no demuestra la identidad del par. Este es un protocolo de pasarela de OpenCodex: `codex queue --remote` por sí solo no implementa su autenticación. La pasarela usa el mismo contrato nativo experimental `thread/queue/add` y no modifica `--ws-auth` de Codex, su configuración ni sus listeners nativos con token bearer. Solo expone metadatos de hilos cargados y colas de texto, no el control general del app-server.
+
+El estado distingue la configuración habilitada, un propietario en ejecución y rutas iniciadas/alquiladas. Los arrendamientos de devolución caducan después de 25 segundos sin actualizar; no son recibos de entrega o procesamiento. La pérdida de una ruta o el cambio de configuración del propietario requiere un reinicio explícito del propietario. La recuperación del transporte nunca reenvía un mensaje incierto.
+
+```bash
+ocx message hosts remove worker --json
+ocx message disable --json
+```
+
+La eliminación revoca la admisión local primero; una limpieza remota no confirmada termina con código de salida 3 y también requiere la eliminación de ese par. Cada eliminación saliente utiliza un archivo temporal independiente para la clave fijada; un fallo en la preparación de ese archivo aún informa la eliminación local y la limpieza remota no confirmada. La limpieza de ese archivo temporal se intenta tanto si la operación tiene éxito como si falla. La guía de limpieza generada utiliza `hosts remove <machine-uuid> --transaction <enrollment-uuid> --json`; el guardia de transacciones rechaza un recibo antiguo en lugar de eliminar una inscripción más reciente. La eliminación ordinaria sin este protector opcional sigue eliminando el par seleccionado actualmente. Deshabilitar retira la generación actual del propietario; el despacho rechaza el nuevo trabajo inmediatamente, y el propietario en primer plano nota una configuración cambiada dentro de su intervalo de mantenimiento de diez segundos. El remitente vuelve a verificar la autoridad local inmediatamente antes del envío; la revocación tras el envío no puede retirar un mensaje en tránsito o un trabajo nativo ya aceptado. Una respuesta de inscripción perdida retiene una transacción privada: repita exactamente el mismo comando add para reconciliar, en lugar de inscribirse con otro nombre dentro de la misma generación habilitada. Deshabilitar/rehabilitar o cambios de puerto invalidan esa generación de recuperación. Las transacciones completadas o revocadas no pueden restaurar un par eliminado ni borrar el registro de recuperación de otra inscripción. Si el diario local guardado contiene JSON mal formado, registros con una estructura inválida o valores de campo inválidos, `hosts add`, `hosts list`, `status` y `hosts abandon` se rechazan con `invalid_enrollment_journal`. Sus bytes se conservan para la recuperación explícita del operador; OpenCodex no lo repara, reemplaza o elimina automáticamente. `hosts add` no envía ninguna solicitud de control de inscripción en este caso, aunque puede ejecutarse su sonda de clave de anfitrión preliminar. El almacenamiento inseguro o un bloqueo de mutación ocupado conserva su clasificación de error separada. Si un diario válido ya no se puede conciliar, inspeccione `ocx message hosts list --json` o `ocx message status --json` para `pendingEnrollment` (alias, UUID de transacción y si su generación es obsoleta), luego abandone explícitamente ese diario local exacto:
+
+```bash
+ocx message hosts abandon --transaction <pending-transaction-uuid> --json
+```
+
+Abandonar la transacción también funciona cuando la función está desactivada. Conserva los pares existentes, no reintenta la inscripción y termina con código de salida 3 porque la limpieza remota no está confirmada. Si queda una inscripción huérfana, sigue las instrucciones de limpieza en el nodo remoto. Los diarios obsoletos no se borran silenciosamente. Un receptor lleno devuelve `peer_capacity` sin inscribir al par: libera un espacio y repite la misma transacción o abandónala explícitamente. Las respuestas de control perdidas o mal formadas mantienen el resultado incierto. Se aceptan directorios de configuración existentes, confiables y con permisos 0755 sin ejecutar chmod; el subdirectorio de mensajería sigue siendo privado. Un reinicio inmediato del proceso propietario puede reemplazar una concesión de retorno obsoleta cuando el nuevo endpoint se autentica y el anterior deja de hacerlo dentro de una comprobación de un segundo. Un endpoint anterior que todavía se autentica conserva su concesión hasta que venza; una falta temporal de acceso puede permitir el relevo, pero no la repetición. La pérdida inesperada del túnel retira visiblemente al propietario en primer plano; eliminar un par de forma deliberada deja funcionando las rutas no relacionadas. Los bloqueos de modificación que quedan tras un fallo impiden continuar y requieren recuperación del operador; el envoltorio nunca supone que un bloqueo antiguo fue abandonado. La publicación del estado y del diario de recuperación sincroniza el archivo y su directorio antes del trabajo remoto dependiente; eliminar el diario también sincroniza el directorio. `remote_storage_unknown` (código de salida 3) significa que no se pudo confirmar la persistencia del cambio de almacenamiento ante un fallo. En macOS, un rechazo de ACL o un fallo del sondeo después de reemplazar el archivo también produce este código: el estado nuevo ya es visible, pero su privacidad mediante ACL y su persistencia ante un fallo siguen sin confirmarse. Inspecciona el estado y los permisos antes de realizar una recuperación explícita; no reintentes ni reviertas automáticamente. Un diario que se puede leer de forma segura, pero contiene JSON o un esquema mal formado, no impide eliminar pares y se conserva para la recuperación del operador. El almacenamiento inseguro o la imposibilidad de invalidar un diario coincidente siguen impidiendo la eliminación.
+
+El propietario en primer plano comparte límites finitos de conexiones, solicitudes, procesos auxiliares y memoria entre todos los pares, y rechaza la sobrecarga sin una cola ilimitada. Los pares inscritos juntos pueden mantener doce conexiones autenticadas; otras cuatro quedan reservadas para el control, las comprobaciones salientes y la renovación del propietario. Se permiten como máximo ocho procesos de túnel y dos auxiliares transitorios de control o inspección: diez en total. La preparación de todo el lote de pares elegido tiene un límite de 30 segundos. Si SSH informa de que se perdió un puerto de reenvío seleccionado, se cierra el par administrado y se eligen puertos nuevos, con un máximo de tres intentos dentro del mismo plazo. Deben completarse la confirmación del reenvío SSH, las comprobaciones de loopback y la preparación autenticada del par. Otros fallos de preparación detienen el proceso de inmediato; las rutas publicadas no se reconectan automáticamente.
+
+Antes de confirmar el inicio se renueva por última vez la autorización temporal. Los lotes de renovación final y periódica tienen plazos de cinco segundos, incluidos en el plazo de preparación cuando corresponda; el mantenimiento periódico se ejecuta cada diez segundos. Cancelar detiene solo los procesos y listeners SSH administrados: conserva los daemons de Codex, los hilos y los proxies ajenos. La limpieza también espera las rutas de túnel retiradas. La terminación de los procesos hijos directos y el EOF natural de sus tuberías deben confirmarse dentro de tres segundos; si no, la limpieza sigue incompleta y se mantiene la reserva de recursos del auxiliar. Cancelar tuberías retenidas no demuestra que sus descendientes hayan terminado. No se rastrean descendientes separados o que cierren las tuberías heredadas.
+
+La captura de stdout del auxiliar se limita a 64 KiB; stderr se descarta sin mostrarlo ni guardarlo. Si se supera el límite, el auxiliar se detiene y se drena la salida descartada hasta su EOF natural. Una limpieza completa informa del error de salida original; una incompleta mantiene `cleanup_incomplete` y la reserva de recursos del auxiliar. Los procesos con el mismo uid pueden leer el estado privado de inscripción: la autenticación de la máquina no establece una identidad infalsificable para cada agente. El tráfico nativo que evite esta pasarela queda fuera de su control.
+
+Malla, controles de panel/caché, aislamiento, mensajería Claude, habilidades administradas y notificaciones inactivas permanecen fuera de esta contribución.
+
+
+## Reanudación explícita en un servidor existente
+
+**La ejecución está actualmente bloqueada a la espera de compatibilidad nativa con reanudación condicional atómica.**
+Esta herramienta pendiente no puede reanudar de forma segura una conversación no cargada con la API revisada de Codex 0.166.0. Realiza una comprobación preliminar acotada y devuelve un rechazo; no ejecuta trabajo en cola. Las herramientas existentes de cola y de lectura de respuestas guardadas siguen disponibles por separado.
+
+Para exponer la herramienta de comprobación preliminar, configura los tres argumentos:
+
+```sh
+ocx message mcp --codex /absolute/path/to/codex --codex-home /absolute/path/to/.codex --allow-reply-read --allow-resume --resume-socket /absolute/path/to/existing.sock --resume-permissions :read-only
+```
+
+El socket debe ser un App Server Unix local, existente y de confianza, que informe del mismo directorio canónico de Codex. No se instala ni se inicia ningún servidor. Un UUID de hilo exacto se normaliza antes de la búsqueda que solo usa metadatos. Los objetivos observados cargados e inactivos/activos devuelven `already_loaded`; los objetivos no saludables se rechazan. Para un objetivo no cargado, se rechazan la política administrada, las API no compatibles, los metadatos inválidos o un perfil ausente/no permitido/no observado. El perfil lo configura el host, nunca los argumentos de la herramienta ni los mensajes en cola. La comprobación lee una página acotada del catálogo, con un máximo de 50 perfiles, en el directorio de trabajo de destino.
+
+Incluso cuando estas comprobaciones pasan, el resultado es `not_resumed` con `resume_atomicity_unsupported`. No se envía `thread/resume`. Otro cliente podría cargar la conversación y desuscribirse entre la lectura de metadatos y la reanudación; el servidor nativo revisado puede reemplazar esa entrada inactiva de la caché usando los permisos suministrados. Un bloqueo del lado del cliente o una segunda lectura no eliminan esta ventana. La ejecución requiere una condición nativa de «solo no cargado» aplicada de forma atómica antes de cambiar un hilo activo; no existe una API de reanudación condicional compatible en la versión revisada. No eludas este rechazo, no deduzcas seguridad de una cadena de versión ni trates un acuse de recibo como una forma de deshacer trabajo ya iniciado.
+
+`executionVerified` siempre es false. La herramienta no inicia ninguna conversación ni turno, no cambia ningún permiso y no responde a ninguna solicitud de aprobación. Cada llamada comparte un presupuesto de 20 segundos y el límite de cuatro operaciones del host; las llamadas superpuestas para un mismo UUID se rechazan. La desconexión cierra solo la conexión del puente. Los endpoints de red/SSH y Windows quedan fuera del alcance de esta herramienta.
diff --git a/docs-site/src/content/docs/es/reference/cli/providers-accounts.md b/docs-site/src/content/docs/es/reference/cli/providers-accounts.md
new file mode 100644
index 00000000000..647a09f7832
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/cli/providers-accounts.md
@@ -0,0 +1,816 @@
+---
+title: "Proveedores, cuentas y modelos de CLI"
+description: "Comandos de configuración, credenciales, cuota y catálogo de proveedores."
+---
+
+Estos comandos configuran proveedores ascendentes, autentican cuentas, administran grupos de credenciales y controlan el catálogo de modelos expuesto a Codex.
+
+Los errores de argumento sobrante de `account list`, `account current`, perfiles principales nativos y comandos de proveedor redactan valores de opciones de credenciales, incluidos `--code`, `--token`, `--api-key`, `--key`, `--secret`, `--password` y `--admin-token`, en ambos formularios `--option value` y `--option=value`. El registro de proveedores locales utiliza `ocx provider add <name> --api-key <key>`; se rechaza un `--api-key=<key>` en línea con su valor editado. `ocx provider edit` no acepta `--api-key`.
+
+<a id="providers"></a>
+
+## Proveedores
+
+### `ocx provider <subcommand>`
+
+Gestión de proveedores no interactivos. Las entradas del registro se siembran por nombre; un nombre personalizado requiere tanto `--adapter` como `--base-url`.
+
+| Subcomando | Banderas soportadas | Medidas adoptadas |
+| --- | --- | --- |
+| `list` | `--json`, `--jsonl` | Listar los proveedores configurados y las entradas de registro restantes; `--jsonl` emite un objeto de proveedor configurado por línea. |
+| `add <name>` | `--adapter <adapter>`, `--base-url <url>`, `--api-key <key>`, `--responses-path <path>`, `--auth-mode <key\|forward\|oauth\|local>`, `--default-model <model>`, `--set-default`, `--force`, `--json`, `--sync`, `--live` | Guardar localmente de forma predeterminada; `--sync` intenta la sincronización del cliente en cualquier modo de salida. `--live` escribe a través del proxy en ejecución y no puede combinar con `--sync`. `--force` permite la sobreescritura. |
+| `edit <name>` | banderas de campo de proveedor, `--headers <json>`, `--model-context-tier <model=default\|long_context>`, `--upstream-http-version <http1.1\|->`, `--fast <on\|off>`, `--context-window <N\|->`, `--json` | Edite los campos de proveedores activos validados sin reemplazar los grupos de claves. Repita `--model-context-tier` para varios modelos de Copiloto. `--headers` fusiona encabezados de solicitud personalizados; pase `{}` o `-` para borrarlos. |
+| `test <name>` | `--model <id>`, `--yes`, `--json` | Verifique el descubrimiento; con `--model`, solicite una prueba de finalización confirmada. |
+| `show <name>` | `--json` | Mostrar la configuración con las claves API enmascaradas. |
+| `remove <name>` | `--json`, `--live`, `--yes` | La eliminación local rechaza el proveedor predeterminado y el último. La eliminación en vivo requiere `--yes` y utiliza comprobaciones de dependencia del servidor, reasignación predeterminada y limpieza de cuenta / modelo personalizado. |
+| `set-default <name>` | `--json`, `--live` | Seleccione un valor predeterminado local o actualice el proxy en ejecución con `--live`. |
+| `pacing <name>` | `--json`, `--enabled <on\|off>`, `--rpm <number>`, `--min-interval-ms <integer>`, `--max-concurrent <integer>`, `--file <FILE\|->` | Lea las reglas configuradas y el estado en tiempo de ejecución; actualice escalares o reemplace las reglas de un archivo. Las banderas de archivo y escalar son exclusivas. |
+| `snapshot` | `--json` | Lee del proxy en ejecución un documento público del editor de proveedores, con los datos sensibles ocultos y validado. |
+| `apply` | `--baseline <FILE\|->`, `--file <FILE\|->`, `--yes`, `--json` | Aplique un documento editor revisado con una comparación de línea de base; las eliminaciones / cambios de nombre requieren `--yes`. |
+| `selected <name>` | `--set <ids>`, `--clear`, `--json` | Lea o actualice la lista de permisos del modelo de proveedor. |
+| `quota` | `--refresh`, `--json` | Lea los informes de cuotas de proveedores. |
+| `resets` | `--limit <n>`, `--json` | Listar los restablecimientos de ventana de cuota detectados recientemente. |
+| `presets` | `--json` | Listar los ajustes preestablecidos del proveedor del panel de control. |
+| `account-mode` | `pool`, `direct`, `--json` | Seleccione el enrutamiento de cuenta agrupado o directo Codex. |
+| `import-cc-switch` | `--source <FILE>`, `--provider <id>`, `--apply`, `--restore`, `--allow-private-network`, `--json` | Previsualiza, aplica de forma selectiva o revierte entradas de proveedor sin claves desde una base de datos SQLite de CC-Switch (`cc-switch.db`) o un archivo JSON antiguo. |
+
+```bash
+ocx provider list --json
+ocx provider list --jsonl        # one configured provider object per line
+ocx provider test ark
+ocx provider add anthropic --set-default --sync
+ocx provider add local-dev --adapter openai-chat --base-url http://localhost:11434/v1
+ocx provider show anthropic --json
+ocx provider edit github-copilot --model-context-tier gpt-5.6-luna=long_context
+ocx models --provider anthropic --json
+ocx models live --provider ark --json
+```
+
+`--jsonl` escribe solo proveedores configurados, un objeto JSON por línea, y omite el resumen `registryCount` de `--json`. Cada objeto tiene los mismos campos que un elemento en la matriz `configured`. Utilícelo para scripts que procesan un objeto de proveedor configurado por línea. `--json` y `--jsonl` no se pueden combinar.
+
+Cada fila configurada también incluye `active`. Es `false` cuando este dispositivo está enlazado con un Home (como Remote Link Child o cliente en modo Hub): la fila describe configuración local que queda sustituida por los proveedores del Home y no atiende solicitudes mientras el enlace esté conectado. Es `true` cuando la fila sí atiende solicitudes, incluso si no se puede leer el estado del enlace. Las filas nunca contienen credenciales: `baseUrl` elimina las credenciales incluidas en la autoridad de la URL y oculta valores de consulta con nombres de credenciales, como `key` o `token`, conservando parámetros normales como `api-version`.
+
+:::caution[Los encabezados personalizados no son un canal para credenciales]
+`--headers` es para los metadatos de solicitud no secreta — sugerencias de enrutamiento, inquilino o selectores de proyectos, identificaciones de rastreo. Es **no** un lugar para poner autenticación material, y el validador rechaza los nombres de encabezado de credenciales estándar (`Authorization`, `X-Api-Key`, `Cookie`, y el resto) con un puntero a
+`apiKey` / `authMode`.
+
+El validador no puede reconocer un nombre arbitrario como `X-My-Token`, por lo que el límite es suyo para respetar. Dos razones por las que importa:
+
+- El JSON es un argumento de línea de comandos, por lo que un secreto en él aterriza en la historia de la shell y en la lista de procesos, donde cualquier otro proceso en la máquina puede leerlo antes de que el CLI redacte algo.
+- Los valores de encabezado se mantienen en `config.json` en texto claro, a diferencia de las claves API, que tienen su propio camino de almacenamiento y enmascaramiento.
+
+Utilice el inicio de sesión de credenciales compatible o el flujo stdin para la entrada secreta. No coloque claves en una transcripción de agente o copiarlas en ejemplos de comandos.
+:::
+
+<a id="local-saves-and-live-provider-state"></a>
+
+### Estado de los locales guardados y del proveedor en vivo
+
+Comience con el descubrimiento fuera de línea: `ocx provider --help`, luego `--help` de la hoja. `list` y `show` leen la configuración local; `add`, `remove` y `set-default` también usan configuración local a menos que se indique `--live`. Otras operaciones de administración de proveedores a continuación requieren un proxy en ejecución. Compruebe `ocx ready --json` y `ocx status --json` antes del trabajo en vivo para confirmar el objetivo y la versión previstos. Una lista local no establece que el proxy adoptó un cambio guardado.
+
+Local `provider add <name> --json` informa `needsSync: true`. Añadir `--sync` realmente intenta la sincronización tanto en JSON como en los modos de salida humanos. Su recibo añade `sync: {status, ok}`; solo `status: "applied"` con `ok: true` despeja `needsSync`. Sin proxy (`not-running`), una sincronización rechazada o fallida devuelve un valor distinto de cero al tiempo que conserva el guardado local. Los resultados omitidos por políticas o solo por catálogo pueden salir con 0 con `needsSync: true`; no son una sincronización de cliente aplicada. La propiedad del catálogo o los rechazos de seguridad de la configuración guardada dejan el catálogo sin cambios, hacen que el comando salga con 1 y muestran la guía de recuperación en la salida humana o `sync.warning` en JSON, incluso si la inyección de configuración tuvo éxito.
+
+Para cambios en vivo autorizados:
+
+```bash
+ocx provider snapshot --json
+ocx provider add anthropic --live --json
+ocx provider set-default anthropic --live --json
+ocx provider snapshot --json
+```
+
+Live add utiliza los ajustes preestablecidos del objetivo y rechaza un proveedor existente observado sin `--force`. El upsert de comprobación y servidor no son atómicos: los cambios simultáneos pueden acelerarse. Los proveedores personalizados todavía necesitan `--adapter` y `--base-url`. `--live` nunca vuelve a caer en un salvamento local; combinarlo con `--sync` no es válido. Las credenciales pertenecen al login humano soportado o al flujo stdin, no a CLI ejemplos.
+
+Para eliminar un proveedor autorizado, utilice `ocx provider remove <name> --live --yes --json`. El servidor comprueba las dependencias y aplica la reasignación predeterminada y la limpieza de la cuenta/modelo personalizado. Inspeccione el recibo y lea de nuevo el destino después de escribir.
+
+Un recibo en vivo puede ser `{"success":true,"name":"example","catalogRefresh":{"status":"committed","changed":true,"degraded":false,"notices":[]}}`. `success` significa que la configuración persistió; no prueba por sí misma la convergencia del catálogo. Por ejemplo, `{"success":true,"name":"example","catalogRefresh":{"status":"skipped","reason":"busy","retryable":true}}` sale con 1 aunque el guardado haya tenido éxito. Una actualización fallida o los saltos por `stale`, `refused` y `catalog-unavailable` también devuelven un valor distinto de cero. Conserve los avisos degradados. Una actualización nula, ausente o `not-requested` puede salir con 0 sin una sincronización de cliente. Lea el estado antes de recuperarse; no repita una escritura persistida para reparar la convergencia. Los errores usan prosa segura en stderr, incluso en el modo JSON, en lugar de un sobre de error JSON.
+
+`provider test <name>` sin `--model` comprueba la conectividad del descubrimiento de modelos aguas arriba. Una conexión fallida sale con 1; el éxito y un catálogo estático sin un punto final de descubrimiento aplicable salen con 0. `applicable: false` es un resultado esperado de catálogo estático, no una inferencia exitosa ni una conexión fallida.
+
+Para enviar una solicitud de finalización para un modelo elegido, utilice:
+
+```bash
+ocx provider test my-relay --model my-model
+ocx provider test my-relay --model my-model --yes --json
+```
+
+Esta prueba puede incurrir en cargos del proveedor. Un terminal interactivo pide confirmación; `--yes` acepta la advertencia de cargo. El uso no interactivo y `--json` requieren `--yes`. Usar `--yes` sin `--model` es un error de uso. Rechazar la confirmación no envía ninguna solicitud y sale con 1. El comando usa la API de gestión del proxy en ejecución.
+
+La prueba de finalización envía el mensaje fijo `Reply exactly OK.`, solicita un límite de salida de 32 tokens, se detiene después de 20 segundos o 64 KiB y nunca reintenta ni hace conmutación por error. Es compatible con proveedores de OpenAI Chat y Responses con autenticación por clave o locales, incluidas las anulaciones de cable por modelo. Las configuraciones deshabilitadas, de OAuth, de autenticación reenviada y de adaptador o transporte no soportados devuelven una razón de aplicabilidad sin enviar una finalización. Los perfiles TLS, las fijaciones de versión HTTP, la limitación de ritmo de solicitudes habilitada y los ejecutores personalizados con una anulación de proxy de proveedor no son compatibles actualmente.
+
+Los resultados incluyen el tiempo hasta el primer delta de texto (TTFT), la latencia total, los identificadores de modelo solicitados y de cable, los metadatos saneados del modelo ascendente y una comparación distinta de coincidencia, discrepancia o desconocido. Los metadatos ausentes o conflictivos son desconocidos. La comparación usa el id ascendente antes del enmascaramiento, frente al id realmente enviado tras el manejo de alias y sufijos. Los metadatos informados por el proveedor no pueden verificar la identidad del modelo: `identityVerified` es siempre `false`. No se devuelve el texto generado. Una finalización fallida sale con 1; el éxito y un resultado no aplicable salen con 0.
+
+<a id="transport-settings-and-request-pacing"></a>
+
+### Configuración de transporte y ritmo de solicitud
+
+`provider edit` ya está en vivo. Utilice `--upstream-http-version http1.1` para fijar ese protocolo, o `--upstream-http-version -` para borrarlo. `--fast on|off` alterna rápidamente; `--context-window N` establece una anulación de proveedor positiva y `--context-window -` la borra. Los ajustes omitidos permanecen sin cambios; cero no es una operación clara.
+
+```bash
+ocx provider pacing anthropic --json
+ocx provider pacing anthropic --enabled on --rpm 30 --min-interval-ms 1000 --max-concurrent 2 --json
+ocx provider pacing anthropic --json
+```
+
+La lectura devuelve `{provider, rules, status}`. `rules: null` significa no configurado; `status` contiene observaciones separadas de cola/temporización en entorno de ejecución. Los indicadores numéricos solos no habilitan un bloque no configurado; `--enabled off` desactiva el ritmo. RPM acepta valores fraccionarios positivos validados. Intervalo/concurrencia requieren enteros positivos.
+
+Las ediciones escalares preservan las reglas del modelo observadas, pero PATCH reemplaza todo el bloque sin CAS, por lo que se puede sobrescribir una edición concurrente. Utilice la instantánea/aplicar debajo cuando se requiera una comparación de línea base. Para un objeto de reglas completas, incluyendo reglas específicas del modelo, use `ocx provider pacing anthropic --file pacing.json --json`. Un archivo de reglas mínimas es `{"enabled":true,"requestsPerMinute":30}`. El modo archivo reemplaza todo el bloque y no se puede combinar con banderas escalares. `--file -` lee stdin canalizado; se aplican los límites de entrada a continuación.
+
+<a id="snapshot-edit-and-apply-with-a-baseline"></a>
+
+### Instantánea, editar y aplicar con una línea de base
+
+Mantenga el mismo host previsto y el contexto CLI en estos pasos. La fijación de objetivos dura dentro de una invocación; las instantáneas no contienen ningún token de identidad de destino.
+
+```bash
+ocx provider snapshot --json > providers.baseline.json
+cp providers.baseline.json providers.next.json
+```
+
+Edite el siguiente archivo y revise la diferencia mientras conserva la línea base original. Cada documento contiene exactamente `{defaultProvider, providers}`. Snapshot es una proyección de editor de solo lectura, no una exportación de configuración sin procesar. No agregue campos secretos, derivados o desconocidos: las credenciales, cualquier campo `headers` y los marcadores de visualización (`hasApiKey`, `hasHeaders`, `xaiResponsesOptInState`, `initialModelSelection`) no son editables por lotes. La exportación de configuración sin procesar puede exponer credenciales y pertenece a un terminal operado por humanos fuera de una sesión de agente.
+
+```bash
+ocx provider apply --baseline providers.baseline.json --file providers.next.json --json
+ocx provider snapshot --json
+```
+
+Agregue `--yes` solo para eliminaciones o cambios de nombre revisados y autorizados. Batch PUT conserva los valores privados intactos y utiliza la línea de base pública para detectar conflictos. No realiza la limpieza de cuentas OAuth que ejecuta DELETE al eliminar un proveedor individual. HTTP 409 devuelve el código de salida 5: tome una nueva instantánea, revise los cambios simultáneos y reconstruya la edición propuesta. No reemplace la línea base ni vuelva a intentarlo automáticamente. Los resultados de escritura desconocidos requieren inspección, no una suposición de retroceso.
+
+Use archivos UTF-8 JSON regulares o explícitos canalizados `-`; como máximo una entrada por lotes puede ser stdin. Cada entrada tiene un límite de 4 MiB y una fecha límite de lectura de 30 segundos. La solicitud serializada combinada `{baseline,next}` también debe ajustarse a 4 MiB. Interactivo stdin, archivos especiales, banderas conflictivas, campos no válidos y eliminaciones no confirmadas son rechazadas antes de la mutación con código de salida 2. Los errores de entrada nunca se hacen eco de los valores enviados.
+
+<a id="keyless-cc-switch-provider-import"></a>
+
+### Importar proveedores de CC-Switch sin claves
+
+```bash
+ocx provider import-cc-switch --source ~/.cc-switch/cc-switch.db
+ocx stop
+ocx provider import-cc-switch --source ~/.cc-switch/cc-switch.db --provider my-provider --apply
+# Start the proxy in another terminal (or run ocx ensure), then add credentials:
+ocx start
+printf '%s\n' "$API_KEY" | ocx account add-key my-provider
+
+# Separate rollback path (stop the proxy first; removes unedited keyless entries only):
+ocx stop
+ocx provider import-cc-switch --restore
+```
+
+`ocx provider import-cc-switch` solo extrae una lista explícita de metadatos no secretos: identificadores de proveedor, tipos de aplicación, URL base, protocolos y modelos predeterminados. La fuente debe ser una base SQLite regular de CC-Switch o un archivo JSON antiguo. Los bytes de la fuente y de las configuraciones incluidas se leen temporalmente para inspeccionarlos; los campos secretos, nombres libres y comentarios TOML se omiten a nivel de bytes, sin convertirlos en cadenas, escribirlos ni registrarlos. Los búferes temporales se ponen a cero en `finally`.
+
+Como protección adicional, la URL base debe tener la forma `http(s)://host[:port]` con una ruta vacía o de 1 a 4 segmentos de API en minúsculas `[a-z0-9._-]`, como `/v1`, `/api/v1` o `/compatible-mode/v1`. También se valida la sintaxis de los identificadores y modelos; los valores no conformes se rechazan sin mostrarlos. La fuente se abre una vez y se verifica mediante el descriptor con `O_NOFOLLOW | O_NONBLOCK`. SQLite se deserializa solo para lectura en memoria, sin archivos temporales. Se rechazan bases con varios enlaces duros (`nlink > 1`), para que una ruta alternativa no evite las comprobaciones de archivos auxiliares. Si un archivo hermano `-wal` o `-journal` contiene datos, se pide cerrar CC-Switch o consolidar la base y volver a intentarlo. Usa solo una fuente local de confianza y verifica cada identificador, modelo y `baseUrl` mostrado antes de añadir credenciales.
+
+- **Previsualizar (predeterminado):** requiere `--source <FILE>`, no escribe nada e informa de las entradas descubiertas, elegibles, conflictivas y no válidas.
+- **Aplicar (`--apply`):** requiere `--source <FILE>` y el proxy detenido (`ocx stop`); se rechaza en un Child de Remote Link. Repite `--provider <id>` para elegir entradas concretas o añade `--allow-private-network` para permitir destinos de loopback o red privada. Aunque no hayas previsualizado, muestra cada identificador, modelo predeterminado y destino antes de guardar entradas sin claves y registrar `$OPENCODEX_HOME/cc-switch-provider-import-journal.json`. Los muestra por `stdout` en modo texto y por `stderr` con `--json`. Se rechaza otra aplicación mientras exista un diario activo. Verifica los destinos, inicia el proxy (`ocx start` en otra terminal u `ocx ensure`) y añade las credenciales con `printf '%s\n' "$API_KEY" | ocx account add-key <provider>` por stdin canalizado o con `ocx login <provider>`.
+- **Restaurar (`--restore`):** es una ruta de reversión separada. Requiere el proxy detenido (`ocx stop`), se rechaza en un Child de Remote Link y no admite `--source`, `--provider` ni `--allow-private-network`. Inspecciona `auth.json` solo para lectura a nivel de bytes y rechaza la operación si es ilegible o no válido. Solo elimina proveedores del diario activo que aún coincidan con el estado importado sin claves y que no sean `defaultProvider` ni estén referenciados por enrutamiento, combos, fallback, cuentas OAuth o claves API.
+
+<a id="authentication"></a>
+
+## Autenticación
+
+<a id="diagnosing-missing-main-account-quota"></a>
+
+### Diagnosticar la cuota de cuenta principal faltante
+
+`ocx account list openai --quota --refresh --json` incluye un objeto `quotaRefresh` en la fila de la cuenta principal cuando esa operación intenta una lectura de uso WHAM. La respuesta existente `GET /api/codex-auth/accounts?refresh=1` expone el mismo diagnóstico.
+
+Su `status` es `ok`, `not_reported` (no hay cuota parseable en una respuesta exitosa), `http_error`, `timeout`, `network_error`, `invalid_response`, o `internal_error`. Solo `http_error` incluye un `httpStatus` numérico. Este objeto no incluye ninguna respuesta sin procesar, mensaje de error, credencial o identificador de cuenta. Las lecturas de solo caché, los aplazamientos de credenciales y las instantáneas de cuenta invalidadas lo omiten; los servidores más antiguos también lo omiten. La ausencia no es prueba de éxito. Un estado de no éxito HTTP permanece `http_error` incluso si su cuerpo de error no se puede leer; `timeout` y `network_error` describen fallos antes de cabeceras o mientras se lee una respuesta exitosa.
+
+Un inicio de sesión válido no garantiza que esta solicitud de uso por separado tenga éxito. Estas categorías no cambian las reglas de autenticación, selección de cuenta o actualización de cuota, y no convierten cuota desconocida en uso cero. Este diagnóstico actualmente cubre la cuenta principal nativa, no las actualizaciones de la cuenta de grupo. Al informar sobre la cuota faltante, comparta la categoría y el estado HTTP en lugar de archivos de credenciales o una captura de red en bruto.
+
+### `ocx login <provider>`
+
+Inicie el flujo de acceso registrado del proveedor. Los proveedores de cuentas estilo OAuth abren un navegador y almacenan las credenciales bajo `~/.opencodex/` (los tokens renovables rotan automáticamente; las concesiones de claves duraderas como OrcaRouter se reutilizan hasta que el proveedor las revoca); los proveedores de inicio de sesión con clave API abren su panel de control de claves, solicitan la clave, la validan cuando es posible y guardan la configuración del proveedor resultante. El comando imprime los identificadores de proveedor OAuth y de clave API actualmente aceptados cuando el nombre falta o es desconocido.
+
+Los inicios de sesión fallidos OAuth salen con el estado 1 e imprimen un diagnóstico fijo: el estado HTTP y el código de error estándar OAuth (como `invalid_grant` ) cuando el proveedor devuelve uno, `network_error` o `timeout` cuando no se pudo llegar al proveedor, `configuration_error` con el motivo de que una configuración local como un espacio de nombres de cuenta Codex bloquea el inicio de sesión y `oauth_authentication_failed` de lo contrario. Pool 2 ( `anthropic2`) también informa `configuration_error` antes de solicitar cuando un proveedor personalizado posee ese nombre o su archivo de configuración no se puede leer o analizar.
+
+Utilice el mismo comando para **reautenticar** después de que `ocx status` / `ocx doctor` informe de que se requiere reautenticación o de un fallo definitivo de renovación (o utilice Reauthenticate en el panel de control). Las cuentas del grupo Codex no son uno de esos proveedores OAuth o de clave API, pero `ocx login codex` llega a ellas de todos modos: se dirige al inicio de sesión del grupo de cuentas, por lo que `ocx login codex --reauth` es lo mismo que `ocx account reauth codex`. El grupo de cuentas Codex del panel (Reauthenticate) también lo hace. Esa ruta se ejecuta dentro del proxy, por lo que necesita uno en ejecución.
+
+Para el proveedor OAuth de ChatGPT, un código OAuth terminal explícito que confirma una concesión de actualización caducada o revocada exige iniciar sesión de nuevo. Las descripciones de texto libre por sí solas nunca requieren una nueva autenticación. Los fallos temporales del servicio de tokens, los tiempos de espera y la cancelación dejan la cuenta elegible para una actualización posterior. El intercambio de tokens del navegador y la actualización tienen cada uno un plazo de 30 segundos por búsqueda que cubre los encabezados y el cuerpo. Los errores derivados de HTTP muestran solo el estado y un código OAuth permitido. La cancelación, el tiempo de espera y los fallos de transporte utilizan mensajes fijos sin el motivo o la causa originales.
+
+```bash
+ocx login xai
+ocx login anthropic
+ocx login orcarouter-oauth # browser consent + S256 PKCE
+ocx login orcarouter       # paste an existing API key
+ocx login anthropic --headless # no browser, no local port
+```
+
+`--headless` ejecuta el inicio de sesión **code-display** para los hosts cuyo navegador no puede llegar a la devolución de llamada del proxy (contenedores, servidores remotos). El comando imprime una URL de autorización; apruébela en cualquier navegador y el proveedor muestra una cadena `code#state` para volver a pegar en el símbolo. No hay ningún puerto de devolución de llamada y no se inicia ningún navegador. Solo `anthropic` y `anthropic2` lo admiten hoy en día; cualquier otro proveedor sale con la lista de proveedores que lo hacen. Para Codex cuentas utilizan el inicio de sesión de código de dispositivo en su lugar, `ocx account login codex --device` - `ocx login codex --headless` se rechaza en lugar de pasar. La ventana de pegado es de 10 minutos, y cada inicio de sesión acepta un código: si el intercambio falla, inicie un nuevo inicio de sesión. Un inicio de sesión exitoso se convierte en la cuenta activa del proveedor, exactamente como un inicio de sesión del navegador.
+
+La reautenticación OAuth conserva la configuración del operador, como selecciones de modelo, anulaciones de precios, y preferencias de conmutación por error de cuenta. Campos de transporte/autenticación de inicio de sesión y de registro Se actualizan los metadatos del catálogo. Un proveedor de live-discovery mantiene su modelo predeterminado seleccionado; un El proveedor estático puede reemplazar un valor predeterminado que ya no existe en su catálogo actualizado.
+
+Para Antigravity, un `401` ascendente puede actualizar la credencial OAuth de la cuenta rechazada y volver a intentar la solicitud una vez. El reintento utiliza el proyecto Cloud Code Assist de esa credencial. Si la actualización falla o no hay ningún proyecto utilizable disponible, la solicitud devuelve un error de autenticación; use el flujo de reautenticación anterior. Un segundo `401` no inicia otro ciclo de refresco/reintentar. Un `403` que solicita verificar la cuenta pone en cuarentena esa credencial como `needs-reauth(verify)`; cuando la conmutación por error de la cuenta está habilitada, la solicitud puede volver a intentar en otra cuenta elegible. Complete la verificación de la cuenta de Google, luego ejecute `ocx login google-antigravity`. La actualización silenciosa del token no borra este requisito de verificación. Si OpenCodex no puede guardar la cuarentena, este intercambio de adaptador conserva el `403` original sin otro envío de recuperación; la cuenta no se ha puesto en cuarentena de forma duradera. Si no se puede construir o admitir una solicitud de hermano para el envío, el intercambio entrega el `403` original a través del formato de error normal. Un combo adjunto o una ruta de directiva aún pueden aplicar sus reglas de reserva existentes.
+
+Para las solicitudes de búsqueda web basadas en la búsqueda, la rotación automática de hermanos solo acepta un sobre de error Google completo y limitado que contiene `error.details[].reason === "VALIDATION_REQUIRED"`. La redacción de verificación por sí sola no rota. Esta recuperación con alcance de solicitud utiliza el token y el proyecto del hermano sin que persista una marca de `needs-reauth`; la cancelación, la salida comprometida, el agotamiento del presupuesto o un hermano no disponible conserva el error.
+
+Un proxy que ya se está ejecutando recoge la nueva credencial sin un reinicio: el CLI le pide que vuelva a cargar ese proveedor desde el disco, y la solicitud no tiene credenciales propias. Si el proxy en ejecución no puede aceptar esa solicitud, la mayoría de las veces porque comenzó a partir de una compilación anterior a la recarga certificada, el inicio de sesión aún tiene éxito y la credencial todavía se escribe en el disco, pero el proceso en vivo sigue sirviendo al anterior. El CLI lo dice y te pide que reinicies:
+
+```
+⚠️  A proxy is running but could not reload this provider (unattested-target).
+   The credential is saved to disk; the running proxy keeps using the previous one.
+   Restart it to pick this up: ocx restart
+```
+
+### `ocx logout <provider>`
+
+Quite la credencial OAuth almacenada localmente de forma predeterminada. `--json` informa de `{schemaVersion:1, ok, provider, removed}`; las credenciales ausentes devuelven `reason: "not_found"` y salen con 4, mientras que una eliminación sale con 0.
+
+Para un cierre de sesión solicitado en el proxy en ejecución, `ocx logout <provider> --live --json` acepta proveedores OAuth públicos y devuelve `{schemaVersion:1, success:true, provider, live:true}`. No cierra la sesión de Codex/native-main ni elimina una cuenta seleccionada. Nunca elimina las credenciales locales antes de la solicitud en vivo ni recurre a la eliminación local tras un fallo.
+
+<a id="accounts-and-key-pools"></a>
+
+## Cuentas y grupos de claves
+
+<a id="pool-policy-account-thresholds-and-paid-credit-intent"></a>
+
+### Política Pool, umbrales de cuenta e intención de crédito pagado
+
+Lee la ayuda sin conexión y, a continuación, la política del objetivo seleccionado antes de cambiarla:
+
+```bash
+ocx account pool --help
+ocx account pool openai --json
+ocx account pool anthropic --json
+```
+
+Estas son las lecturas de gestión en vivo. La respuesta incluye `provider`, `kind`, `supported`, la política almacenada nullable, `enabledEffective` y opcional `inert`. Sólo los campos nombrados por `supported` se pueden escribir; nulo no es falso, y una política inerte no es agrupación activa. Los umbrales cero y `enabled:false` son independientes. Utilice `--enabled on|off`, `--threshold 0..100`, `--strategy`, `--sticky 1..100` y `--quota-window` solo donde sea compatible. OpenAI no admite escrituras de agrupación/ventana habilitadas; `reset-first` es para OpenAI y grupos OAuth genéricos (nunca Anthropic), `least-loaded` solo para Kiro, y las ventanas de Anthropic son `five-hour`, `weekly`, `max-utilization`. Los campos omitidos permanecen sin cambios. Los campos de lectura DTO como rutas, concurrencia por cuenta o Anthropic `nativeMessages` no implican un setter en este comando; use solo las opciones CLI enumeradas. Un guardado que devuelve `warning: "config_bookkeeping_failed"` se persistió, pero necesita una lectura nueva para confirmar el estado en vivo.
+
+```bash
+ocx account pool anthropic --threshold 80 --quota-window five-hour --json
+ocx account pool anthropic --json
+ocx account auto-switch openai status --account <id-or-alias-or-main> --json
+```
+
+Un `--account` explícito selecciona el umbral OpenAI por cuenta. Las acciones son `status`, `on` (80), `off` (0), `inherit` (nulo), o `threshold N` (0-100). Sin `--account`, el comando de conmutación automática existente permanece en el grupo. El resultado es `{ok, id, autoSwitchThresholdOverride, autoSwitchThreshold}`; lea la anulación anulable y el valor efectivo observado por separado.
+
+El uso de crédito pagado después de la cuota incluida es una política distinta que requiere una intención de gasto explícita. `ocx account credits openai <id-or-alias-or-main> on|off --json` apunta a una cuenta. `ocx account credits openai --all on|off --json` es exclusivo con ese selector: en los registros de ID seleccionables actuales más principal, se borra la lista. Los recibos son `{ok, id, creditsAfterLimit}` o `{ok, all, ids}`; conservar los ID devueltos reales y leer de nuevo `ocx account list openai --json`. Mostrar saldos de crédito con `--show-codex-credits` no habilita esta póliza. No permita que los créditos se recuperen de una lectura de inicio de sesión o de cuota fallida.
+
+<a id="quota-activation-and-reset-grant-observations"></a>
+
+### Observaciones de activación y reset-grant de cuotas
+
+```bash
+ocx account quota-activation openai <id-or-alias-or-main> --window fiveHour off --json
+ocx account list openai --json
+ocx account anthropic-reset-grants --json
+```
+
+La activación de cuotas acepta `fiveHour` o `weekly`, deliberadamente diferente de Anthropic pool `five-hour`. Escribe un toggle de cuenta/ventana; habilitar puede programar la actualización de cuota. `{ok, id, window, enabled, available}` reporta la política y la disponibilidad observada, no la actualización completada. La habilitación no disponible puede devolver 409; la desactivación todavía está permitida. Nunca consume una concesión de reinicio.
+
+Anthropic reset-grants acepta un ID de cuenta Anthropic exacto opcional, no un selector alias/principal Codex; la omisión utiliza la opción activa/retroactiva existente. El GET puede contactar con el servicio de estado ascendente. Reporta elegibilidad/razón, recuento de subvenciones, fechas anulables, tiempo de reutilización, operación pendiente y disponibilidad de revistas. Las subvenciones vacías no son lo mismo que el estado no disponible. Nunca consume una subvención o reanuda un gasto pendiente. El consumo sigue siendo una operación GUI humana.
+
+<a id="use-remaining-included-quota"></a>
+
+### Utilizar la cuota incluida restante
+
+Para seguir utilizando una cuenta seleccionada más allá de un umbral de conmutación proactiva o el umbral de protección de cuenta principal, habilite explícitamente su preferencia de cuota restante:
+
+```bash
+ocx account use-remaining openai main on
+ocx account use openai main
+ocx account use-remaining openai main status --json
+ocx account use-remaining openai main off
+```
+
+Reemplace `main` con un ID o alias de cuenta de grupo único para orientar una cuenta agregada. Al habilitar esto, se desactiva el cambio de uso proactivo para esa cuenta. Para el inicio de sesión principal, también mueve ambos umbrales efectivos de bloqueo duro al 100%, por lo que una lectura del 95% aún puede admitir una solicitud. La preferencia persiste en los reinicios hasta que se desactiva; la configuración del umbral original permanece almacenada y se reanuda la aplicación cuando está desactivada. No selecciona una cuenta en sí ni anula la programación de round-robin, la pausa manual / automática, las verificaciones de derechos, la reautenticación o los tiempos de reutilización ascendentes. El permiso de crédito pagado sigue siendo una configuración separada; habilitar esto nunca opta por una cuenta en créditos o canjea una subvención de restablecimiento. La cerradura rígida principal por defecto todavía se niega al 100%.
+
+`GET /api/codex-auth/accounts/use-remaining?id=<account-id>` lee la política en vivo. `PUT /api/codex-auth/accounts/use-remaining` acepta `{ id, useRemainingQuota: boolean }`. Ambos requieren la autenticación de gestión existente. Este control está expuesto actualmente a través de los CLI y API.
+
+<a id="main-account-quota-protection"></a>
+
+### Protección de la cuota de cuenta principal
+
+En **Codex ajustes → Multi-auth → Ajustes avanzados**, **Bloquear cuenta principal** está activado por defecto junto a Ultra Fast. Apagarlo se aplica inmediatamente; volver a encenderlo primero muestra las consecuencias, y la cancelación no cambia la configuración. La tarjeta de la cuenta principal muestra la supervisión, el uso desconocido o un bloque de directiva actual incluso cuando se cierra la configuración avanzada.
+
+El valor predeterminado sigue a lo que hace una cuenta principal drenada en Codex Desktop: una vez que la ventana de la cuenta ChatGPT informa **0%** restante, Desktop deshabilita su botón de envío y la cuenta deja de aceptar turnos hasta que la ventana se restablece. Mantener el tráfico propio de ocx por debajo de ese punto mantiene la cuenta utilizable ([#5694](https://github.com/lidge-jun/opencodex/issues/5694)). El coste es Luna Reserve: mientras el bloque esté vigente, Reserve en esa cuenta principal no podrá activarse. Para que la cuenta principal se agote y se entregue a Reserve, apague el interruptor.
+
+El **Ventana de 5h y la ventana semanal cada bloque por su cuenta**: la ventana de 5h alcanza el 90% o la ventana semanal alcanza el 98% de bloques de inmediato, incluso cuando el otro todavía tiene espacio para la cabeza. Las cuentas solo mensuales usan su ventana mensual. El bloque se libera automáticamente, con el interruptor todavía encendido, una vez que cada ventana de bloqueo informa una nueva lectura por debajo de su umbral (un 0% de recuentos de reinicio); la siguiente observación en el umbral bloquea nuevamente. Configure `codexMainAccountHardLockThresholds` en `config.json` con los porcentajes opcionales `short` y `long`, por ejemplo `{ "short": 90, "long": 98 }`. Ambos deben ser números enteros de 80 a 100, y `short` no debe exceder `long`; campos omitidos utilizan los valores predeterminados. La configuración API acepta el mismo objeto y devuelve los valores efectivos en `mainAccountHardLock.thresholds`.
+
+**Mientras que el bloqueo bloquea, las solicitudes pueden recaer en otro modelo en lugar de fallar.** La fila **Retroceso mientras está bloqueado** se encuentra al lado del interruptor de protección y funciona como la fila de llamada a la sombra: elegir un modelo, por ejemplo `deepseek/deepseek-chat`, enciende la redirección inmediatamente, se le aplica el esfuerzo de pensamiento opcional y el interruptor pausa la redirección sin olvidar el modelo. Mientras que el bloque está en vigor y no Codex cuenta puede servir a una solicitud de un modelo nativo Codex, esa solicitud se encamina al modelo de reserva (con el esfuerzo configurado) en lugar de ser rechazada. Una cuenta Pool utilizable todavía sirve la solicitud primero; selectores calificados por el proveedor, combos, filas calificadas por la cuenta y Luna Reserve mantienen sus propios destinos; y se ignora una reserva que nombra un modelo Codex nativo, porque el reencaminamiento gpt-? solo volvería a ingresar el mismo rechazo. La cerradura en sí no cambia: se suelta por sí misma como antes, y el desvío termina con ella. Configurar `codexMainAccountHardLockFallback` en `config.json` como `{ "model": "deepseek/deepseek-chat", "reasoningEffort": "low" }`; `enabled: false` pausa el desvío mientras mantiene el modelo. Una sección ausente, un modelo omitido o una sección mal formada significa que las solicitudes son rechazadas como de costumbre; `reasoningEffort` debe ser un esfuerzo declarado. La configuración API acepta el mismo objeto, rechaza escrituras inválidas antes de la mutación y `null` borra la sección.
+
+El panel de control y el `ocx status` muestran **posible uso fuera del opencodex** cuando las lecturas nuevas aumentan en al menos un punto en el mismo episodio de reinicio sin actividad reciente de la cuenta principal a través de este proxy. Esta es una observación de asesoramiento, no una prueba: un giro de larga duración también puede causarlo. La cerradura no puede evitar el agotamiento del tráfico exterior. El aviso de proceso local borra los cambios de identidad o de restablecimiento y caduca después de seis horas o en el restablecimiento observado, lo que ocurra primero. `ocx status --json` expone el estado, los umbrales efectivos, el tipo de ventana de bloqueo y la advertencia opcional `externalUsage` bajo `mainAccountHardLock` cuando hay evidencia de gestión en vivo disponible.
+
+Una lectura ilegible de 5h no puede ocultar un bloque semanal. El uso desconocido no fabrica un cero, y una lectura faltante no borra una tupla de bloqueo ya medida. Un tiempo de reinicio predicho solo no lo desbloquea. Mientras está bloqueado, la recuperación comprueba los metadatos de uso propio en un horario limitado de 5/10/20/40/60 minutos, por lo que se observa un restablecimiento canjeado fuera de opencodex antes del restablecimiento previsto; el primer cheque espera cinco minutos, los cheques permanecen al menos cinco minutos de diferencia y el siguiente cheque se introduce al último restablecimiento de bloqueo conocido. Un principal en pausa o requerido para la re-autenticación no recibe ninguna comprobación antes de su reset predicho. Un `Retry-After` más largo también retrasa la preparación de perfiles y tokens. Solo el uso nuevo y válido o la evidencia autorizada de ausencia de ventana pueden levantar el bloqueo. En el modo Pool, una cuota `--refresh` evita la frescura de la memoria caché, pero aún honra el ritmo de lectura fallida; una lectura diferida no hace ningún nuevo intento de diagnóstico. Otros límites de pausa, reautenticación y aguas arriba permanecen independientes.
+
+La protección trata una nueva respuesta de uso WHAM válida como un reemplazo para la lectura de 5 horas anterior cuando su ventana principal dura explícitamente **al menos 24 horas** e informa sobre el uso válido, o su ventana principal es explícitamente `null` y un secundario medido proporciona el uso semanal. En cualquier caso, las ventanas secundarias / terciarias deben ser explícitamente `null` o explícitamente durar al menos 24 horas e informar el uso válido. Esto sigue el límite corto / largo del analizador, por lo que una ventana de un día califica, así como ventanas semanales / mensuales. La ventana actual sigue utilizando el mismo umbral de ventana larga configurado (98% por defecto). Esto se basa en la única instantánea reportada; no se requieren observaciones repetidas. Cualquier campo de ventana omitido, una duración desconocida o encabezados de respuesta parcial no pueden borrar un bloque anterior. Las respuestas totalmente nulas con solo créditos y lecturas complementarias mensuales tampoco pueden establecer la recuperación. El proxy comprueba la credencial almacenada de nuevo antes de aplicar una respuesta retardada. Un archivo ilegible o portador reemplazado no puede actualizar la memoria caché de uso, liberar el bloqueo o poner en cuarentena la nueva credencial, incluso para la misma cuenta sin leer la segunda cuota. Su uso ordinario analizado aún se puede devolver al llamante solicitante, sin actualizaciones de estado compartido o evidencia de recuperación. La tarjeta de cuenta muestra el uso publicado en caché, manteniendo su cuota alineada con el estado de bloqueo; Direct cuota de proveedor omite una respuesta no publicada y su informe en caché anterior. Las identidades de cuentas en conflicto y las respuestas obsoletas 401/403 retienen la información almacenada en caché actual y no pueden borrar o establecer el estado de reautenticación de la cuenta actual.
+
+Responses a las solicitudes enviadas con la credencial principal identificada actualizan su uso en caché desde sus cabeceras de cuota, ya sea que el proxy sustituya la credencial almacenada o el llamante envíe la misma credencial. Una respuesta se aplica solo si esa credencial sigue siendo la credencial principal observada cuando llega; una credencial propiedad del llamante para otra cuenta o espacio de trabajo nunca actualiza el uso de la cuenta principal.
+
+La opción persistente es `"codexMainAccountHardLock"` en OpenCodex `config.json`. Una tecla ausente o `true` significa encendido; solo un `false` explícito lo apaga, y eso es lo que se almacena al desactivar la opción. El valor predeterminado cambió aquí: la política solía ser opt-in y el interruptor antiguo eliminó la clave cuando estaba apagada, por lo que una instalación que la había desactivado ahora se lee como activada. Si desea el comportamiento anterior, apáguelo una vez para registrar la opción de exclusión. La protección cubre nuevas solicitudes utilizando la cuenta principal identificada, no el último 2% en sí: las solicitudes que ya se están ejecutando, las credenciales de llavero propiedad del llamante sin igual y el tráfico fuera del proxy aún pueden gastar cuota. Las cuentas agregadas y otros proveedores permanecen disponibles.
+
+Con la protección activada, una startup propia restaura la vinculación de identidad en memoria de la credencial principal después de la recuperación y limpieza del perfil nativo, por lo que un bloque de políticas persistente sobrevive a un reinicio. Las solicitudes Direct, exact-main, main-fallback y main-pin pueden recibir brevemente 503 mientras está pendiente esa vinculación; las cuentas Pool almacenadas saludables siguen siendo elegibles durante todo el proceso. No se lee ninguna credencial de un hogar de servicio extranjero o no confirmado para esta inicialización.
+
+Mientras que esta política bloquea la principal, la Reserva Luna en esa cuenta también está bloqueada. Mantenerse por debajo del agotamiento de la cuota ordinaria puede evitar la activación de la reserva. Deshabilitar el switch restaura el manejo local normal, no el derecho ascendente adicional. Utilice la acción de actualización de cuota de cuenta para obtener una nueva observación; no se consume automáticamente ningún crédito de reinicio.
+
+<a id="luna-reserve-alongside-routed-models"></a>
+
+### Luna Reserve junto a modelos enrutados
+
+El [Modo de escritorio](/es/guides/codex-integration/#authless-codex-desktop-opt-in) opcional mantiene inactiva la puerta del selector de solo reserva de Desktop. También deshabilita el manejo automático de reservas de Desktop: Reserve es una opción de modelo explícita, no una alternativa automática.
+
+Mantenga habilitado el proveedor OpenAI integrado en modo de reenvío ChatGPT, habilite el selector de modelo de cuenta y configure un selector público para la cuenta principal almacenada. Con el modo sin autenticación de loopback efectivo habilitado, `ocx sync` incluye `<main-selector>/gpt-reserve` junto con los modelos de proveedores enrutados. Un `gpt-reserve` sin calificar, un selector de cuenta añadida y el descubrimiento de modelos con clave API no se añaden al catálogo. La configuración sin autenticación se ignora para el enrutamiento de clientes remotos o para un oyente que necesita un encabezado de admisión. Cuando los oyentes públicos y locales se ejecutan juntos, la reserva de compatibilidad solo se aplica a las solicitudes admitidas por el oyente local. Una solicitud pública autenticada permanece en la ruta normal aunque se origine en la misma máquina; los encabezados de la solicitud no pueden seleccionar la directiva local.
+
+Habilite el modo de escritorio sin autorización con `ocx system settings --desktop-authless on`, ejecute `ocx sync`, luego salga completamente y vuelva a abrir Codex Desktop para que vuelva a cargar la configuración y el catálogo reescritos. Siga el [canónica flujo de trabajo de escritorio authless](/es/guides/codex-integration/#authless-codex-desktop-opt-in).
+
+Cada solicitud de compatibilidad comprueba una autorización de servidor vinculada a credenciales, almacenada en caché durante un máximo de 60 segundos. OpenCodex envía el encabezado de capacidad de reserva en una lectura de uso de cuenta principal propia y requiere que el uso ordinario no esté permitido, la bandera de Reserva Luna y exactamente un cubo de reserva permitido. La evidencia faltante, denegada, rancia o no coincidente rechaza la solicitud; no cambia de cuentas ni usa silenciosamente la Luna ordinaria. El uso pasivo puede revocar la autorización, pero no puede crearla. El tiempo de reutilización global, la pausa, la reautenticación y el bloqueo de la cuenta principal aún se aplican. Apague el bloqueo duro si desea usar Reserve en una cuenta principal agotada; al hacerlo, no otorga derecho al servidor. Esta ruta de compatibilidad admite solicitudes de conversación y compactación, no se reserva como un ayudante de visión o búsqueda web o un modelo de relé de búsqueda independiente. Elija otro modelo para esos ayudantes.
+
+El selector prefiere los metadatos de reserva reales. Cuando no se ha observado ninguno, utiliza una adaptación de metadatos de Luna explícitamente marcada, siguiendo el mapeo preestablecido de Reserva o Luna de Desktop. Una entrada visible no es prueba de disponibilidad. Se verificaron las rutas de origen del escritorio y las rutas respaldadas por accesorios; no se usó una cuenta activa de reserva en vivo para validar esta ruta de compatibilidad.
+
+### `ocx account <subcommand>`
+
+Haga una lista y cambie de cuentas de proveedores y grupos de claves API a través del proxy en ejecución. La superficie de ayuda enviada es:
+
+```text
+Usage: ocx account <list|history|current|use|clear|refresh|auto-switch|alias|priority|pause|resume|reset-affinity|pause-exhausted|strategy|sticky|remove|clear-cooldown|add-key|import|import-orca|login|reauth|code|cancel|reset-credits|grok-reset-coupons|main> ...
+
+list [provider]     Codex account pool, OAuth accounts and API keys (identifiers shown masked as the API returns them).
+history openai <pool-account-id> [--limit <1-200>]  Recent routing decisions for one Codex pool account.
+current <provider>  Show the active account or key.
+use <provider> <id|alias|main|auto> Switch the active credential; 'main' selects the Codex App login, 'auto' clears the selection unless an account carries that id.
+clear <provider>  Clear the manual Codex account selection unconditionally.
+refresh <provider>  Force-refresh Codex or provider quota reports.
+auto-switch <provider> <on|off|status|threshold N>  Control the Codex pool threshold.
+alias <provider> <id|alias> <display-name|->  Set or clear an account's display name; '-' clears it.
+pause <provider> <id|alias|main>  Hold an account out of automatic selection.
+resume <provider> <id|alias|main>  Return a paused account to automatic selection.
+pause-exhausted <provider>  Pause every account whose quota is spent.
+clear-cooldown <openai|anthropic> <id|alias|main>  Drop a cooldown the proxy set after an upstream failure.
+reset-affinity <anthropic|anthropic2> [--json]  Confirm all session bindings are cleared, even with no accounts; selection and pause state stay unchanged. Run on the Home; a Remote Link Child names the Home and sends no request.
+strategy <provider> [<quota|round-robin|fill-first|least-loaded|reset-first>]  Pool placement strategy; least-loaded is Kiro-only.
+sticky <provider> [<1-100>]  Requests a bound thread keeps on one account; omit the value to read it.
+priority <provider> <id|alias|main> [first|earlier|normal|later|last|-100..100|reset]  Selection order; omit the value to read it.
+remove <provider> <id|alias|main> --yes  Remove a stored account or key after an existence check.
+add-key <provider> [--label <label>]  Add a key read only from piped stdin.
+login/reauth/code/cancel  Run browser or manual-code auth from a headless shell.
+reset-credits <id|main> [--consume --yes]  Inspect or consume Codex reset credits.
+grok-reset-coupons [<id>] [--consume --yes] [--token-id <token-id>] [--operation-id <uuid>]  Inspect or redeem Grok reset coupons.
+import <provider> --format <format> (--file <path>|--stdin)  Import credentials from a named external format.
+import-orca --source <dir> --registry <file> [--apply]  Preview or apply imports from Orca-managed Codex homes.
+main <doctor|list|register|add|reauth|switch|recover>  Manage the Codex App login the pool calls 'main'.
+Switching the active account takes effect immediately; running threads move on their next request, and in-flight requests keep the account they captured.
+A selection-order change applies from the next unbound request and never moves a bound thread.
+```
+
+Los subcomandos de cuenta requieren que el proxy se ejecute y resuelvan automáticamente su puerto de entorno de ejecución registrado, excepto `import-orca`: la vista previa es solo local, y `import-orca --apply` requiere que el proxy esté detenido. Las operaciones exitosas salen con 0. El uso no válido, un proveedor o id de cuenta/clave desconocido, un proxy inalcanzable o un fallo de la API salen normalmente con 1. Para `reset-affinity`, HTTP 404 sale con 4 y HTTP 409 sale con 5; los demás fallos de la API y los resultados no confirmados salen con 1. Los campos de credenciales se muestran exactamente como los devuelve la API de gestión (incluido su enmascaramiento); las claves API sin procesar y los tokens OAuth nunca se devuelven. Las comodidades de visualización se sintetizan en el cliente, igual que en el panel: `main` es el alias de la CLI para el inicio de sesión de Codex App en el grupo de cuentas `openai`, las cuentas OAuth sin correo electrónico aparecen como `Account N`, y la columna de plan/etiqueta recurre al plan, al correo electrónico enmascarado, a la etiqueta y a la clave enmascarada.
+
+Las filas de la cuenta `--json` usan esta forma común (los campos opcionales se omiten cuando no están disponibles):
+
+```json
+{
+  "provider": "openai",
+  "type": "codex | oauth | api-key",
+  "id": "__main__",
+  "label": "plus",
+  "email": "m***@example.com",
+  "plan": "plus",
+  "masked": "sk-ab****wxyz",
+  "priority": 0,
+  "active": true,
+  "needsReauth": false,
+  "quota": null
+}
+```
+
+### `ocx account import-orca --source <orca-data-directory> --registry <orca-data.json> [--apply] [--json]`
+
+Reutilice los inicios de sesión locales administrados por Orca Codex sin otro inicio de sesión del navegador. El directorio fuente debe contener `codex-accounts/<account>/home/auth.json`. Proporcione el directorio de datos de Orca y el perfil elegido `orca-data.json` explícitamente. Solo se consideran las cuentas registradas en ese perfil; las casas de cuentas sobrantes o eliminadas no se importan. Cada hogar debe llevar el marcador de Orca correspondiente `.orca-managed-home`. El comando no escanea hogares no relacionados ni hosts remotos.
+
+```powershell
+# Windows: preview only; no account is registered.
+ocx account import-orca --source "$env:APPDATA\orca" --registry "$env:APPDATA\orca\profiles\local-default\orca-data.json" --json
+
+# Finish active proxy requests and stop the proxy before applying.
+ocx stop
+ocx account import-orca --source "$env:APPDATA\orca" --registry "$env:APPDATA\orca\profiles\local-default\orca-data.json" --apply
+ocx start
+```
+
+Los perfiles más antiguos de Orca pueden usar `orca-data.json` directamente debajo del directorio de datos. En otras plataformas, pase el directorio de datos local de Orca y el registro de perfil con el mismo diseño. El importador omite identidades ya presentes en el inicio de sesión principal nativo, el grupo de cuentas o el almacén de credenciales, incluidos los duplicados dentro de la fuente. Esto utiliza deliberadamente el ID de cuenta ChatGPT como un depósito conservador: los miembros separados que comparten un ID de cuenta del espacio de trabajo también se omiten, no se fusionan ni se importan individualmente. La repetición de una importación conserva las cuentas existentes. Si una importación anterior se detuvo entre guardar credenciales y registrar la fila de grupo, reintentar puede finalizar ese registro con el mismo ID solo cuando su registro pendiente intacto aún coincida con el origen. Las entradas no válidas se cuentan por código de razón fijo. Un resultado mixto con al menos una cuenta elegible sale con éxito; un resultado en el que cada entrada descubierta no es válida sale con un código distinto de cero. La salida contiene códigos de cuenta y razón, no correos electrónicos, identificadores de cuenta, rutas o tokens.
+
+**Orca conserva la propiedad de actualización.** OpenCodex almacena un enlace fuente de solo lectura y una instantánea de token de acceso, nunca el token de actualización de Orca. Al resolver las credenciales, vuelve a leer la fuente y verifica que todavía pertenece a la identidad importada. Orca debe mantener ese inicio de sesión disponible y actualizado. Las credenciales de origen ausentes, malformadas, caducadas o cuya identidad no coincide se rechazan; OpenCodex no vuelve a la instantánea anterior ni actualiza el inicio de sesión de origen. Este es un enlace local, no una exportación portátil o una transferencia de propiedad de actualización. Las solicitudes que ya se envían aguas arriba mantienen las credenciales que capturaron.
+
+Las cuentas nuevas se registran como **validación pendiente**. Después de iniciar el proxy, abra **Codex Auth** y haga clic en **Actualizar las cuotas** para autorizar el paso de validación del modelo existente, que puede consumir una pequeña cantidad de cuota. La importación sin conexión y el análisis JWT no establecen la autenticación ascendente. La actualización de la cuota CLI por sí sola no realiza esa validación. El importador nunca inicia ni detiene la aplicación, cambia los archivos de Orca o cambia la cuenta del grupo activo.
+
+Las cuentas guardadas del grupo ChatGPT se pueden listar, mostrar en el dashboard y actualizar aunque no exista un directorio nativo de Codex. Listarlas no crea ese directorio ni cierra la sesión nativa de la cuenta principal. Desactivar la integración de Codex no desactiva la consulta de cuota de una sesión nativa existente. Una ruta explícita inválida en `CODEX_HOME` sigue siendo un error de configuración. El almacenamiento inseguro de `OPENCODEX_HOME` también produce un error aunque falte el directorio de Codex. La resolución del directorio predeterminado rechaza archivos, enlaces rotos y directorios padre que no puedan recorrerse.
+
+### `ocx account list [provider] [--json] [--all] [--quota [--refresh]]`
+
+Sin un proveedor, enumera el grupo Codex, las cuentas OAuth y los grupos de claves API configurados. Los proveedores vacíos se omiten a menos que esté presente `--all`. Con un proveedor, enumera solo esa familia de credenciales. La salida legible usa `PROVIDER TYPE ID PLAN/LABEL PRIORITY STATUS`; una fila Codex elegida manualmente está marcada con `selected`. `PRIORITY` es el orden de selección Codex con signo (`0` cuando no está establecido) y muestra `-` en las filas donde el orden no se aplica, como las cuentas OAuth y las claves API. Con dos cuentas Kiro almacenadas, el límite de tasa, la cuota mensual confirmada y las denegaciones de suspensión pueden rotar a una cuenta elegible antes de la salida; la evidencia positiva de la lista de modelos en caché se prefiere entre las cuentas elegibles antes que la estrategia de grupo ordinaria. La rotación reactiva se activa por presencia y no se puede desactivar: `oauthAccountFailover.enabled: false` rechaza la preferencia de la cuenta previa al envío, no la recuperación ante rechazos, y una anulación del proveedor tiene prioridad; `ocx account login kiro` añade cuentas al grupo de una en una. Un resultado vacío sigue siendo un éxito. `--json` devuelve:
+
+Las filas JSON de Codex incluyen `slotId`, igual al `id` registrado, y `slotKind`, con valor `native-main` o `pool`. Si el proxy puede verificar la identidad del usuario y de la cuenta del proveedor, también incluye `upstreamAccountKey`: `uai1_` seguido de 64 caracteres hexadecimales en minúscula. Dentro de `openai`, claves iguales identifican posiciones del mismo usuario; conserva cada posición y su estado de cuota por separado. La clave solo vale para esta instalación y puede cambiar al rotar el token de administración. Si falta, no deduzcas coincidencias por correos enmascarados ni valores de cuota. No se muestran identificadores originales del proveedor, declaraciones de identidad ni credenciales.
+
+```text
+{ accounts: AccountRow[], notes: string[] }
+```
+
+Un listado de proveedores vacío nombra el siguiente comando en la salida humana y JSON `notes`:
+`ocx account login <provider>` para OAuth/Codex, o `ocx account add-key <provider>`
+con una fuente de canalización controlada por humanos para las claves API. Un listado global vacío puntos a `ocx account login <provider>` y `ocx help account login`.
+
+Las filas de la cuenta incluyen una etiqueta `health` validada y, cuando la recuperación está disponible, `healthAction`. La salida humana imprime la recuperación debajo de la tabla. La reautenticación apunta a la cuenta almacenada con `ocx account reauth <provider> --id <id>`; la principal nativa usa `ocx account main reauth --device`. La verificación del proveedor, los conflictos de credenciales y la validación pendiente conservan una orientación distinta. Codex filas preservan el `creditsAfterLimit` booleano del servidor en list/current JSON; las filas humanas muestran `paid-credits: on` solo cuando el permiso está habilitado. Estas lecturas no cambian el permiso de crédito pagado.
+
+`--quota` agrega una columna `QUOTA` con el uso propio de cada cuenta, para los proveedores que admiten una sonda por cuenta (Anthropic, Kiro, Google Antigravity y Devin hoy). Es opt-in porque el proxy sondea el flujo ascendente una vez por credencial almacenada; el listado predeterminado permanece como una lectura local. `--refresh` omite el resultado almacenado en caché. Una cuenta sin cuota por cuenta muestra `-`, y una cuya sonda falló muestra `unavailable` - en blanco se leería como "no uso" en lugar de "no medido". `--json` lleva el desglose completo por cuenta, no solo las ventanas resumidas.
+
+Los grupos de claves API también admiten `ocx account list <provider> --quota [--refresh]`. Sin `--quota`, su listado no solicita una investigación de cuotas. La lectura opt-in utiliza el propietario de la cuota de cada clave almacenada; `--refresh` solicita nuevas pruebas de que propietario y puede ponerse en contacto con el proveedor de upstream. No reemplaza las claves almacenadas o leer el agregado de todo el proveedor devuelto por `account refresh`.
+
+Las filas JSON de claves API conservan `quotaMode` (`probe`, `passive`, `unsupported`), `quota` opcional o nulo, y `quotaUnavailable` cuando se devuelve. La cuota pública puede incluir ventanas personalizadas, saldos de crédito en USD, créditos de Kiro y horarios de actualización, no solo los porcentajes al estilo Codex. La salida legible distingue entre no admitido, no medido, no disponible y mediciones reales. Desconocido no es cero; el cero observado se conserva. Los campos consumidos mal formados, o una fila de clave devuelta sin evidencia de modo de cuota, fallan en lugar de fabricar soporte. Un grupo vacío sigue siendo válido. Las claves permanecen enmascaradas.
+
+Google Antigravity filas llevan las mismas ventanas `Gem` / `Cla` que la cuota a nivel de proveedor, calculada a partir de la credencial propia de esa cuenta y el id del proyecto Cloud Code Assist. La sonda por cuenta siempre habla con el host Cloud Code Assist de Google a través del transporte saliente anclado, independientemente de un `baseUrl` configurado: una URL base personalizada es una opción de enrutamiento para solicitudes, no una segunda fuente de Google que representa una credencial almacenada. Una cuenta sin un ID de proyecto, o una cuya sonda se redirige o falla, muestra `unavailable`. Cuando el descubrimiento de modelos de reserva proporciona lecturas de cuotas, las pantallas detalladas retienen hasta 256 diagnósticos de modelos con distintas etiquetas limitadas. Estas filas no afectan los titulares de resumen del proveedor, la gravedad, la clasificación de la cuenta, el enrutamiento o las notificaciones de reinicio.
+
+Las filas de Devin provienen de la `GetUserStatus` de Cognition para la propia clave de esa cuenta, enviada a su host api-server permitido. Si una credencial anterior no tiene host, la sonda utiliza la URL base del proveedor configurada cuando se incluye en la lista de permisos o el valor predeterminado de EE. Muestran las ventanas de fecha diaria y semanal que expone el plan, y una ventana de crédito mensual solo en un plan de crédito facturado que informa un saldo de crédito; una estrategia de facturación desconocida usa esa reserva de crédito solo si ambas fechas de reinicio están ausentes. Las ventanas vencidas diarias y semanales permanecen ocultas sin convertirse en una cuota de crédito mensual. Un saldo ilimitado, o un estado sin saldo en absoluto, no muestra ninguna ventana de crédito. Solo una tecla rechazada (401) borra una lectura almacenada en memoria caché; otros fallos de sondeo retienen la última lectura.
+
+```text
+$ ocx account list anthropic --quota
+PROVIDER   TYPE   ID        PLAN/LABEL         PRIORITY  STATUS  QUOTA
+anthropic  oauth  1278f8da  a***r@examp***.com  -                5h 7% wk 62%
+anthropic  oauth  e112f28b  k***1@examp***.net  -        active  5h 9% wk 45%
+```
+
+Kiro factura una asignación mensual y no reporta una ventana más corta, por lo que sus cuentas rinden una cifra de `mo`:
+
+```text
+$ ocx account list kiro --quota
+PROVIDER  TYPE   ID        PLAN/LABEL         PRIORITY  STATUS  QUOTA
+kiro      oauth  3f0a91c2  a***r@examp***.com  -        active  mo 15%
+kiro      oauth  8b24de70  k***1@examp***.net  -                mo 88%
+```
+
+`ocx account list kiro` marca una cuenta excluida de la selección automática como `not-auto-selected(<reason>)`. JSON lleva `autoSelectable` y, cuando es falso, un `skipReason` cerrado (`paused`, `needs_reauth`, `suspended`, `cooldown` o `quota_exhausted`). Todavía se puede enviar un singleton activo o un pool totalmente excluido. Kiro `providerCredits` proviene de los valores medidos `meteringEvent`: la última lectura dentro de una respuesta física se conserva, y los envíos facturados por separado se agregan al gasto de la solicitud. Los créditos nunca se estiman a partir de tokens.
+
+Con dos o más cuentas Kiro iniciadas, la tasa de solicitud, la cuota mensual confirmada y las negativas de suspensión confirmadas pueden rotar antes de la salida. El agotamiento mensual excluye solo ese inicio de sesión hasta que se restablezca o expire la evidencia; el servicio completado borra un veredicto anterior. Los rechazos de cuota incluyen los motivos exactos `MONTHLY_REQUEST_COUNT` y `OVERAGE_REQUEST_LIMIT_EXCEEDED` en HTTP 400 o 429. Los planes que permiten consumo adicional pueden seguir atendiendo solicitudes aunque el indicador mensual llegue al 100 %. La rotación reactiva permanece disponible cuando la preferencia proactiva de la cuenta está desactivada. Las cuentas se agregan una a la vez: `ocx account login kiro` delega en el Kiro CLI y añade la nueva cuenta al grupo. En el panel de control, las cuentas Login y Add también ofrecen inicio de sesión de dispositivos Builder ID, Google y GitHub junto con la opción Kiro CLI; el inicio de sesión de dispositivo nativo agrega una cuenta sin cerrar sesión en el CLI. Los usuarios de un perfil de organización (IAM Identity Center) comparten su perfil ARN, por lo que una cuenta Kiro CLI se identifica por ese perfil junto con los informes `kiro-cli whoami` de correo electrónico para la sesión. Por lo tanto, dos usuarios de la misma organización siguen siendo cuentas separadas, y al iniciar sesión el mismo usuario vuelve a actualizar la cuenta de ese usuario. Cuando `kiro-cli whoami` no reporta ningún usuario, el perfil solo identifica la cuenta como antes. Si ese perfil ya tiene una cuenta con un usuario conocido, tal inicio de sesión solo actualiza la cuenta cuya sesión Kiro CLI almacenada continúa; se rechaza cualquier otro inicio de sesión en lugar de reemplazar una cuenta, y un inicio de sesión de cuenta Agregar conmuta el Kiro CLI de nuevo a su sesión anterior. Ejecute `kiro-cli whoami` para confirmar el usuario que ha iniciado sesión y, a continuación, vuelva a intentarlo. Reautenticar una cuenta guardada antes de que se conozca a su usuario registra al usuario que inicia sesión, a menos que ese usuario ya tenga otra cuenta del mismo perfil. Para agregar una cuenta sin el Kiro CLI, use `ocx account login kiro --method builder-id`, `--method google` o `--method github`. Abra la URL de verificación impresa, ingrese el código de usuario y espere la aprobación. `--no-wait` imprime el ID de flujo; cancélalo con `ocx account cancel kiro --flow <flow-id>`. El inicio de sesión nativo solo agrega cuentas. Para volver a autenticar uno, retíralo y agrégalo de nuevo. Un ARN de perfil social repetido crea otra ranura e imprime `duplicate_profile_arn`; las ranuras llevan cada una su propio estado de cuota y carga. Kiro puede optar por la colocación proactiva de `least-loaded` con `pool.kernel` y la preferencia de cuenta habilitada. La preferencia de modelo proactiva también requiere que la preferencia de cuenta esté habilitada explícitamente a nivel mundial o para Kiro; una configuración no establecida o falsa deja una cuenta activa saludable en su lugar. Las listas de modelos se aprenden después de que una cuenta sirve, por lo que un hermano inactivo puede inicialmente no tener evidencia. Un ID de modelo ausente de cada lista almacenada en caché todavía se envía aguas arriba. Su límite opcional `maxConcurrentPerAccount` es una cola limitada por cuenta: una cuenta completa seleccionada espera hasta 250 ms, luego devuelve 503 `account_capacity` con `Retry-After: 1`. El límite es local para cada proceso proxy y no mueve una solicitud; la rotación reactiva permanece disponible después de un rechazo.
+
+### `ocx account current <provider> [--json]`
+
+Muestra la cuenta o clave activa. Un grupo Codex sin anclaje manual informa de la selección automática con prioridad: se elige el nivel elegible de mayor prioridad y, dentro de ese nivel, se selecciona la cuenta de menor uso con enrutamiento por cuota; otra familia sin credenciales activas informa de ese estado y aun así sale con 0. `--json` devuelve:
+
+```text
+{ provider, type, activeId: string | null, autoSwitchThreshold?: number, account: AccountRow | null }
+```
+
+### `ocx account use <provider> <account-or-key-id|alias|main|auto> [--json]`
+
+`auto` borra la selección manual para que el grupo vuelva a colocar el trabajo según su propia estrategia, a menos que una cuenta Codex lleve literalmente el id `auto`, que gana por precedencia de id exacto; `ocx account clear <provider>` siempre restaura la selección automática. Cualquier cuenta Codex puede nombrarse por el alias establecido con `ocx account alias` en lugar de por su id; eso también vale para `priority`, `pause`, `resume`, `clear-cooldown`, `remove` y `alias`. Para las cuentas Codex, `auto`, `main` y `__main__` están reservados sin distinguir mayúsculas y minúsculas y no se pueden asignar como alias. Los nombres de visualización de OAuth y de clave API mantienen sus reglas existentes.
+
+Selecciona una cuenta Codex, una cuenta OAuth o una clave API existente. Para `openai`, `main` selecciona el inicio de sesión de Codex App. Una selección de Pool Codex borra la afinidad y se aplica a la siguiente solicitud, incluida la de una tarea visible existente. Los vínculos de las solicitudes con un id de sesión (incluidos los turnos normales de Codex CLI y App y de los subagentes), o de las solicitudes sin sesión ancladas a su padre inmediato, pueden sobrevivir a un reinicio ordenado del proxy, durante hasta 24 horas de inactividad, cuando el guardado final de afinidad al apagar tiene éxito. Las cadenas sin sesión más profundas y los vínculos con el inicio de sesión principal de Codex App solo viven en memoria y se reasignan tras el reinicio; la expulsión, la eliminación de la cuenta, un nuevo inicio de sesión, un cierre inesperado o un restablecimiento de afinidad pueden dejar una tarea sin vínculo, mientras que las solicitudes en curso conservan la cuenta que capturaron. Esto controla solo el enrutamiento de Pool; el modo Direct sigue usando la credencial principal nativa o propiedad del llamante. La conmutación proactiva basada en el uso, la reautenticación 401/403, los enfriamientos 429/retry-after, la exclusión y la recuperación de fallos 429/402 previos a la salida pueden seleccionar más tarde otra cuenta Pool elegible. Esas rutas de recuperación siguen activas cuando la conmutación basada en el uso está desactivada. OpenCodex reproduce la conversación tras un cambio de cuenta, pero la caché de prompts del lado del proveedor puede estar fría. Los proveedores o ids desconocidos salen con 1. En un **401/403**, el inicio de sesión de App borra la afinidad local al proceso de esa cuenta y exige reautenticación. En un **429**, opencodex respeta `Retry-After`, inicia el enfriamiento de la cuenta, borra la afinidad y puede rotar la solicitud a otra cuenta Pool elegible. Estas transiciones de fallo siguen activas con `autoSwitchThreshold: 0`; esa configuración desactiva solo la conmutación proactiva basada en el uso. `--json` devuelve:
+
+```text
+{ ok: true, provider, type, activeId }
+```
+
+### `ocx account clear <provider> [--json]`
+
+Borre la selección manual de la cuenta Codex sin resolver un identificador de cuenta, por lo que funciona incluso cuando una cuenta se llama literalmente `auto`. Solo para grupos Codex; otros tipos de proveedor no tienen selección automática que restaurar.
+
+### `ocx account pause|resume <provider> <id|alias|main> [--json]`
+
+Las cuentas pausadas por el opt-in [Política de pausa automática por proveedor](/es/reference/configuration/providers/#auto-pause-permanently-refused-accounts) usan los mismos comandos. El listado muestra la razón de pausa fija; la reanudación lo borra.
+
+Pausa o reanuda una cuenta en el grupo Codex, Anthropic, OAuth genérico o de claves API, incluido `google-antigravity`. Para el grupo Codex, `main` identifica solo la cuenta Codex incorporada; las cuentas OAuth deben identificarse por id o por un alias único. Una cuenta OAuth pausada queda excluida de la selección de solicitudes, de la conmutación por error 429 y de la renovación proactiva de tokens, y no se puede seleccionar manualmente. Pausar la cuenta activa cambia a la siguiente cuenta utilizable cuando existe una. Si todas las cuentas están en pausa, las solicitudes de ese grupo devuelven 403 hasta que se reanude una cuenta.
+
+Para proveedores Anthropic y genéricos OAuth, identifique la cuenta por id o por un alias único exacto o insensible a mayúsculas y minúsculas. La respuesta JSON informa el id de la cuenta, el estado de pausa y el id de la cuenta activa.
+
+La pausa Anthropic se aplica incluso cuando la agrupación proactiva está deshabilitada, incluida la afinidad de sesión y 429 sucesores. Sobrevive al reinicio y la reautenticación, conserva las credenciales y la salud, y no interrumpe un turno ya enviado. Eliminar la cuenta elimina su estado de pausa. Los umbrales de conmutación automática Anthropic por cuenta no forman parte de este control.
+
+La reserva de pausa automática de Anthropic mantiene el orden de las cuentas, omite las cuentas pausadas y las cuentas que requieren reautenticación, y excluye las importaciones de Claude Code que expiran en 60 segundos. Las cuentas heredadas sin un origen registrado siguen siendo elegibles utilizando solo sus propias credenciales almacenadas y la actualización normal del token almacenado; nunca adoptan las credenciales de disco CLI. Se puede seleccionar una importación Claude Code aún válida con más tiempo restante. Más tarde, la readopción automática acepta un token compartido, de acceso no vacío o de actualización. Si ambos tokens rotan, OpenCodex requiere una prueba UUID de cuenta autenticada tanto para el portador almacenado como para el importado. Guarda esa prueba en privado cuando está disponible desde el inicio de sesión, la actualización o la búsqueda de perfil; las etiquetas de cuenta, el correo electrónico, la organización y la ubicación del archivo de credenciales no pueden sustituirla.
+
+Cuando el portador antiguo ha expirado y no se ha guardado ninguna prueba de cuenta vinculada, la recuperación automática puede ser imposible. Un perfil no disponible o un par girado no verificado deja la cuenta almacenada sin cambios y no reproduce un token de actualización potencialmente consumido. Use el inicio de sesión explícito para importar la credencial actual Claude Code. Importar conserva ranuras sin identidad no relacionadas y puede crear una cuenta separada; seleccione la cuenta deseada y elimine ranuras obsoletas solo después de verificarlas. Un error de búsqueda de perfil puede dejar una nueva importación sin identidad, con la misma limitación de recuperación automática.
+
+Si no se permite ninguna reserva, la detección de cuotas y modelos en vivo espera una cuenta activa utilizable. Puede seleccionar explícitamente una cuenta heredada sin pausa existente con `ocx account use anthropic <account-id-or-alias>`; su propia credencial válida y la actualización normal de token almacenado permanecen disponibles incluso cuando no se registró su fuente de credenciales original.
+
+```bash
+ocx account pause google-antigravity <account-id-or-alias>
+ocx account resume google-antigravity <account-id-or-alias>
+ocx account resume anthropic <account-id-or-alias> --if-healthy
+```
+
+### `ocx account clear-cooldown <openai|anthropic> <id|alias|main> [--json]`
+
+Elimina un tiempo de reutilización de fallos de proceso local sin cambiar las credenciales almacenadas. Utilice `openai` para una cuenta de grupo Codex o `anthropic` para una cuenta Anthropic OAuth; otros proveedores son rechazados. Ambos formularios aceptan un identificador de cuenta o alias único, mientras que `main` es específico del grupo Codex.
+
+```bash
+ocx account clear-cooldown anthropic <id-or-alias>
+```
+
+El comando reporta el éxito incluso cuando no hay tiempo de reutilización activo, con `cleared: false` en JSON. El borrado de un tiempo de reutilización de Anthropic también avanza la generación de cuentas para que una investigación de cuotas en vuelo más antigua no pueda restaurar el estado borrado o publicar la elegibilidad obsoleta derivada de la cuota después.
+
+### `ocx account refresh <provider> [--json]`
+
+Para el grupo Codex, use `ocx account refresh openai [--json]`. Se actualiza a la fuerza las cuotas de cuenta e imprime los porcentajes semanales / mensuales disponibles y los tiempos de reinicio; los datos de cuotas faltantes se informan como desconocidos, no como 0%. Su envolvente JSON es `{ accounts: AccountRow[] }`, con `quota` en cada fila Codex.
+
+Para proveedores OAuth y de clave API, esto fuerza la actualización del punto final de informes de cuota del proveedor; no es un nuevo inicio de sesión de token ni una simple relectura de la lista de cuentas. `--json` devuelve `{ provider, report: ProviderQuotaReport | null }`. Un proveedor sin un informe de cuota compatible imprime `no quota report available for <provider>` y sale con 0. Los proveedores desconocidos y los fallos de la API de gestión salen con 1; una sonda de cuota ascendente que falla o expira se degrada a un informe nulo o desactualizado (código de salida 0), lo que coincide con las barras de cuota del panel.
+
+### `ocx account auto-switch <provider> <on|off|status|threshold <0-100>> [--json]`
+
+Controla el umbral del grupo Codex `openai`, o almacena un umbral para un grupo OAuth genérico. `on` almacena el 80%, `off` almacena el 0% y `threshold <n>` acepta 0–100. Un umbral de grupo genérico dirige la selección solo mientras `pool.kernel` está activado con `strategy: "fill-first"`; con el indicador desactivado, guardar uno no habilita la conmutación basada en umbral. Nunca cambia la anulación de habilitación del proveedor ni desactiva la rotación reactiva 429. `status` y la salida de las mutaciones de grupos genéricos usan la respuesta confirmada del servidor. Para grupos genéricos, `poolEnabled` es la anulación almacenada del proveedor (`null` significa no especificado), no el estado efectivo heredado; `inert: true` significa que el umbral se almacena pero no se aplica, `inert: false` significa que el grupo lo está aplicando, y un `inert` ausente es una capacidad desconocida, que nunca informa `enabled: true`. Se rechazan los proveedores de clave API y los valores no válidos.
+
+### `ocx account auto-switch anthropic … --account <id>`
+
+Para Anthropic OAuth, use `ocx account auto-switch anthropic threshold 90 --account <id>` (entero 0-100), `off --account <id>` (0), `on --account <id>` (80), `inherit --account <id>` (reseteo) o `status --account <id>` (solo lectura); agregue `--json` para la salida estructurada. La tarjeta de cuenta ofrece la misma palanca de umbral personalizado. Faltante / nulo hereda `anthropicAccountPool.autoSwitchThreshold` (predeterminado 80); 0 deshabilita la conmutación basada en el uso para esa cuenta, no la pausa o la recuperación reactiva 429. Las anulaciones sobreviven al reinicio y al reinicio y se eliminan con la cuenta. Con la agrupación habilitada, la cuota y el relleno primero comparan cada fuente/candidato con su propio umbral en la ventana de cuota seleccionada. La precedencia manual/afinidad, el comportamiento sin identidad de round-robin/fill-first, el retroceso de cuota desconocida y el retroceso totalmente drenado permanecen sin cambios. Round-robin no está controlado por el uso; los grupos deshabilitados ignoran estos umbrales. Las listas de permisos de ruta de modelo aún restringen a todos los candidatos.
+
+```text
+openai: { provider, autoSwitchThreshold: number, enabled: boolean }
+generic OAuth: { provider, autoSwitchThreshold: number | null, enabled: boolean, poolEnabled: boolean | null, inert: boolean | null }
+```
+
+### `ocx account preserve-signed-in openai [on|off|status] [--apply-to-bound] [--json]`
+
+Optar por **use primero otras cuentas elegibles y mantenga la identidad de escritorio iniciada como reserva ChatGPT / Codex**. Una invocación desnuda o `status` lee la política del proxy en ejecución, los ID de entrada afectados, el pin manual y la siguiente opción no vinculada. `on` persiste `codexPreserveSignedInAccount: true`; `off` restaura su pedido de cuenta personalizada existente sin volver a escribir ninguna prioridad.
+
+El grupo reservado incluye entradas nativas de `__main__` y de grupos ordinarios con el mismo correo electrónico de miembro normalizado de ChatGPT cuenta/espacio de trabajo seleccionado de **y**. Compartir un espacio de trabajo solo es insuficiente. El grupo sigue el inicio de sesión físico más reciente observado por el ciclo de vida de inicio de sesión nativo del proxy; ninguna credencial de solicitud entrante puede definirlo. Si la evidencia del miembro/espacio de trabajo no está disponible, `identityKnown: false` informa que solo se puede identificar la principal. El estado obtiene una nueva observación propia; un perfil nativo ocupado o ilegible devuelve 503 sin aplicar el cambio.
+
+Las cuatro estrategias Codex prefieren otras identidades con margen de cuotas, preservando el orden personalizado dentro de cada grupo. Las entradas reservadas permanecen como reserva cuando los niveles preferidos se agotan. **Fallback puede consumir la cuota de inicio de sesión**, sujeto al modelo de acceso existente, pausa, tiempo de reutilización, reautenticación, bloqueo estricto y cheques de consentimiento de crédito pagado. Esta política no otorga el consentimiento de crédito pagado.
+
+Las fijaciones existentes saludables permanecen en su lugar, y los pines manuales y las rutas de modelo exactas calificadas para la cuenta anulan la preferencia. Para aplicarlo al trabajo en curso, ejecute:
+
+```bash
+ocx account preserve-signed-in openai on --apply-to-bound
+```
+
+Esto libera explícitamente solo los enlaces afectados y cualquier pin manual afectado para el **siguiente solicitud**; Las solicitudes en vuelo mantienen su cuenta capturada. Permanecen fijaciones y pasadores no relacionados. El trabajo en movimiento puede perder su caché de solicitud de calor, y las cargas o el estado de continuación de la cuenta pueden evitar un movimiento. `codexAccountPriorityFailback` sigue siendo un opt-in separado, con su actual cuota-estrategia, umbral positivo y nuevas condiciones de observación, sino que también puede mover el trabajo hacia un grupo preferido.
+
+Para **Nunca use esta identidad a través del grupo.**, use `ocx account pause openai main` en su lugar: la pausa vinculada excluye las entradas del grupo principal y coincidente sin cambiar el archivo de inicio de sesión del escritorio. Solo se controlan las solicitudes que alcanzan OpenCodex. Esto no desbloquea un compositor de escritorio ya desactivado ni promete arreglar la conmutación de cuotas del lado del cliente.
+
+### `ocx account priority <provider> <account-id|alias|main> [<-100..100|first|earlier|normal|later|last|reset>] [--json]`
+
+Lee o establece el orden de selección de una cuenta del grupo Codex: **un valor más alto se usa antes**, el predeterminado es `0` y el rango va de `-100` a `100`. Solo se ordena el grupo Codex `openai`, por lo que otros proveedores salen con 1. `main` apunta al inicio de sesión de Codex Desktop, que se ordena como cualquier otra cuenta del grupo. `ocx account priority openai main last` solo baja esa entrada; use `preserve-signed-in` (arriba) para reservar también sus entradas ordinarias correspondientes del grupo.
+
+Las palabras preestablecidas representan números enteros pequeños: `first` es `+2`, `earlier` es `+1`, `normal` es `0`, `later` es `-1` y `last` es `-2`. `reset` devuelve la cuenta al valor predeterminado y elimina su entrada almacenada. **Omitir el valor leído** el orden actual en lugar de escribir uno.
+
+Ordenar selecciones qué cuentas se consideran primero, no cuáles son utilizables: la selección aún se ejecuta entre las cuentas elegibles, tomando el nivel de orden más alto que aún tiene margen de cuota y dejando `accountPoolStrategy` para elegir dentro de él. La pausa, el tiempo de reutilización y la reautenticación no se ven afectados. Los cambios se aplican desde el **siguiente solicitud no vinculada**, no solo desde las sesiones recién iniciadas: la preferencia mueve una solicitud no vinculada tan pronto como un orden superior recupera espacio libre. Los hilos ya vinculados a una cuenta normalmente la mantienen hasta que se agota esa cuenta; un fallo de reautenticación o un tiempo de reutilización de la cuota aún liberan el enlace inmediatamente. Una racha de fallos transitorios (5xx y otros fallos no contingentes que alcanzan `upstreamFailoverThreshold`, por defecto 3) ya no elimina un enlace en vivo: la solicitud es servida por otra cuenta mientras se mantiene el enlace, y la tarea vuelve a su propia cuenta tan pronto como esa cuenta vuelve a servir. Si la cuenta sigue fallando después de 10 minutos, la vinculación se libera normalmente. Esta retención es independiente de `pool.cacheAffinity`. Cualquier escritura aceptada también libera un pin manual "usar esta cuenta ahora", en cualquier cuenta que la tenga, incluyendo una escritura que almacena el pedido que una cuenta ya tenía - esta es la única manera de borrar un pin mientras se mantiene la cuenta que está seleccionada actualmente. (Borrar la cuenta activa a través de la administración API libera un pin también, pero deja caer esa selección junto con él.) `--json` devuelve:
+
+```text
+{ ok: true, provider, id, priority: number, preset: string | null }
+```
+
+### `ocx account login|reauth|code|cancel ...`
+
+Ejecute la autenticación de cuenta basada en navegador o por código manual desde un shell sin interfaz. Utilice `ocx account --help` para la forma de comando específica del proveedor. Si se guarda un inicio de sesión de cuenta Codex pero su validación o la actualización del catálogo de modelos sigue pendiente, tanto el modo humano como el JSON salen con 1. El inicio de sesión guardado sigue visible; no reinicie la autenticación solo porque el trabajo de seguimiento esté pendiente. La salida humana imprime en stderr la guía de recuperación fija de `ocx sync` para un catálogo pendiente. `--json` mantiene stdout analizable y conserva las marcas de pendiente sin la advertencia humana.
+
+Las nuevas opciones de inicio de sesión son específicas de flujo:
+
+| Flujo | `--open-browser on\|off` | `--add-account on\|off` |
+| --- | --- | --- |
+| Proveedor ordinario fresco OAuth | Compatible con proveedores con capacidad de navegador | Se admite; se omiten los valores predeterminados para agregar una cuenta |
+| Reauth proveedor ordinario | Flujos compatibles con el navegador solamente | Rechazado; la omisión retiene el comportamiento reauth |
+| Inicio de sesión del navegador Codex | Apoyado | Rechazado |
+| Dispositivo Codex, o kimi/nous/github-copilot nativo | Rechazado | Rechazado para Codex; reglas ordinarias OAuth para otros proveedores |
+| Nativo Kiro `--method` | Rechazado | Rechazado; este flujo es solo para agregar |
+
+Explícita add-off cuenta permite la preferencia de importación existente; no elimina una cuenta. Omission conserva los valores predeterminados anteriores de CLI. El operador debe completar la verificación del navegador/dispositivo. Mantenga `flowId`, ID de cuenta y código de verificación separados; una concesión de dispositivo devuelta no es un lanzamiento exitoso del navegador. `--no-wait --json` informa el traspaso, no el inicio de sesión completo. Conservar el estado pendiente, caducado, cancelado, pendiente de validación y pendiente de catálogo; nunca reinicie silenciosamente un flujo, credenciales de captura o verificación completa para el operador.
+
+`ocx account login openai --device` ejecuta el inicio de sesión de código de dispositivo de OpenAI en lugar de la devolución de llamada del navegador. Utilícelo cuando el host proxy no tiene navegador, o cuando nada puede alcanzar su `localhost:1455`: un contenedor, un VPS o cualquier concentrador alcanzado a través de SSH:
+
+```bash
+ocx account login openai --device --no-wait --json
+# Read the returned flowId, URL and deviceCode; the operator completes verification.
+```
+
+Abra esa URL en cualquier otra máquina, ingrese el código corto y se completa el inicio de sesión. Sin `--no-wait`, el comando sondea hasta que termina; la concesión del dispositivo vive 15 minutos, y el comando espera ese tiempo en lugar de los 5 minutos que permite un inicio de sesión del navegador, porque el punto es que se aleja a otro dispositivo. `kimi`, `nous` y `github-copilot` aceptan el indicador como una opción prohibida porque su único inicio de sesión ya es un flujo de dispositivos; un proveedor sin concesión de dispositivo lo rechaza.
+
+En el panel de control, la casilla de verificación **"No abra un navegador en la máquina proxy"** selecciona el mismo inicio de sesión en el modal de cuenta agregada. Ese ajuste ya significa que el operador no está sentado en el host proxy, que es exactamente cuando una URL de devolución de llamada es inútil, por lo que al marcarlo cambia el inicio de sesión Codex al flujo del dispositivo y muestra un código copiable.
+
+### `ocx account remove <provider> <id|alias|main> --yes [--json]`
+
+Esta eliminación protegida y no interactiva requiere `--yes`. Antes de eliminar, verifica que el id exista; un id ausente sale con 1 sin enviar DELETE. El inicio de sesión principal de Codex App no se puede eliminar, por lo que
+`remove openai main --yes` se rechaza. Tras la eliminación, la familia se vuelve a leer: eliminar la cuenta Codex anclada borra el anclaje y vuelve a la selección automática; OAuth promueve la primera cuenta restante o informa de que no queda ninguna; los grupos de claves API promueven la primera clave restante o informan de que no queda ninguna. Las formas de éxito y fallo de `--json` son:
+
+```text
+{ ok: true, provider, id, removedActive: boolean, promotedActiveId: string | null, catalogRefreshPending?: boolean }
+{ error: string } // stderr, exit 1
+```
+
+`catalogRefreshPending` solo está presente en eliminaciones de Codex. Cuando es `true`, la eliminación de la cuenta ya está guardada; la salida humana imprime la guía de recuperación genérica de `ocx sync` en stderr y aun así sale con 0. Los sobres de eliminación de cuentas OAuth y de claves API no incluyen este campo.
+
+### `ocx account add-key <provider> [--label <label>] [--json]`
+
+Añade y activa una clave para un proveedor de clave API. La clave se lee solo desde stdin canalizado/redirigido que no sea TTY; la entrada TTY interactiva, la entrada vacía, los proveedores OAuth/Codex y los fallos de la API salen con 1. La clave nunca se repite, incluso cuando aparece dentro de una etiqueta. Prefiera un gestor de secretos o un here-string:
+
+```bash
+ocx account add-key openrouter --label personal <<< "$OPENROUTER_API_KEY"
+security find-generic-password -w openrouter | ocx account add-key openrouter --json
+```
+
+`--json` devuelve `{ ok: true, id: string | null, label?: string }` y nunca incluye la clave.
+
+### `ocx account reset-credits <id|main> [--consume --yes]`
+
+Inspeccione los créditos de reinicio Codex para una cuenta. Consumir un crédito es destructivo y requiere `--consume` y `--yes`.
+
+Después de un `reset` confirmado, el nuevo uso puede recuperar el tiempo de reutilización derivado del restablecimiento compartido elegible existente de la misma cuenta. Las cuentas en pausa, las cuentas que necesitan reautenticación y los tiempos de reutilización propiedad de una sonda en curso quedan excluidos de esta recuperación. Una actualización de uso fallida u ocupada tras el consumo confirmado no requiere otro crédito: vuelva a comprobar el uso en lugar de repetir `--consume`. El éxito del consumo no garantiza la capacidad de rotación; consulte el [contrato de recuperación de la API de gestión](/es/reference/management-api/#codex-authentication-delegation) para restablecer/reproducir, frescura y límites de alcance.
+
+### `ocx account grok-reset-coupons [<account-id>] [--consume --yes [--token-id <id>] [--operation-id <uuid>]] [--json]`
+
+Inspecciona los cupones restantes o canjea uno por una cuenta xAI / Grok.
+
+Cuando se invoca sin `--consume`, devuelve los tokens de cupón disponibles y las ventanas de validez:
+
+```bash
+ocx account grok-reset-coupons
+ocx account grok-reset-coupons acc_xai_01 --json
+```
+
+Canjear un cupón de reinicio muta el estado de facturación y agota permanentemente un token de cupón. `--consume` requiere estrictamente `--yes`:
+
+```bash
+ocx account grok-reset-coupons --consume --yes
+ocx account grok-reset-coupons --consume --yes --token-id <token-id>
+```
+
+Pase `--operation-id <uuid>` (debe ser un UUIDv4 válido) para garantizar la liquidación idempotente. Si la red cae o se vuelve a intentar la orden, IDs de operación idénticas reproducen el resultado grabado de forma duradera en lugar de consumir un segundo cupón.
+
+El comando sale con un valor distinto de cero a menos que el código establecido sea `redeemed` (incluido un `redeemed` reproducido). Cuando el resultado no está confirmado (un código establecido ausente o no reconocido, `attempt_unresolved`, `attempt_in_progress`, `attempt_reconcile_failed`, `operation_state_changed`, `operation_token_mismatch`, `attempt_mark_failed` o `ledger_unavailable`/`capacity` con un id de operación), imprime el `--operation-id` que debe conservar; vuelva a ejecutar con ese mismo id en lugar de iniciar una nueva operación. Un rechazo registrado (`auth_failed`, `fetch_resets_failed`, `no_coupons_available`, `coupon_unavailable` o `token_unresolved`), como un fallo repetido, imprime `Coupon was not redeemed (<code>)`; cualquier otro código establecido cuenta como no confirmado.
+
+### `ocx account main <subcommand>`
+
+Gestione los perfiles de inicio de sesión principal nativos con nombre Codex sin cambiar el enrutamiento del grupo de cuentas OpenCodex:
+
+```text
+ocx account main doctor [--json]
+ocx account main list [--json]
+ocx account main register <label> [--json]
+ocx account main add <label>
+ocx account main reauth --device [--no-wait] [--json]
+ocx account main reauth status --flow <id> [--json]
+ocx account main reauth cancel --flow <id> [--json]
+ocx account main switch <profile-id-or-label> --yes [--json]
+ocx account main recover [--rollback --yes] [--json]
+```
+
+Una lista de perfil nativo vacía sugiere `ocx account main add <label>` en salida humana y JSON `notes`; no asume que esté disponible un inicio de sesión nativo existente.
+
+`ocx account main reauth --device --no-wait --json` escribe un objeto JSON a stdout en caso de éxito, sin la línea `follow up:` legible por humanos. Utilice su `flowId` con `ocx account main reauth status --flow <id> --json` para comprobar el progreso.
+
+Cada comando de mutación reporta el `CODEX_HOME` efectivo canónico devuelto por el proxy en ejecución. Esta ruta puede diferir de la `CODEX_HOME` de la persona que llama; las órdenes que soportan JSON exponen el mismo valor que `effectiveCodexHome`.
+
+La versión 1 admite la autenticación Codex basada en archivos, cifra los perfiles almacenados con AES-256-GCM y mantiene la clave de cifrado en el almacén de credenciales del sistema operativo. `add` etapas de la oficial Codex flujo de inicio de sesión antes de importar la credencial resultante. Cierre Codex antes de cambiar de perfil; un switch exitoso conserva las tareas locales y el historial, luego requiere que se reinicie Codex. Utilice `doctor` para inspeccionar el estado del perfil y `recover` para terminar o revertir una transición interrumpida. `switch` acepta el ID de perfil o su etiqueta.
+
+`reauth` vuelve a autenticar la identidad principal nativa *existentes* con un código de dispositivo OpenAI (#3898) en lugar de inscribir un nuevo perfil. Es la ruta de recuperación del concentrador sin cabeza: no se requiere ninguna aplicación local Codex, ningún binario `codex` y ningún llavero del sistema operativo. El inicio de sesión del dispositivo debe completarse para la misma cuenta ChatGPT que ya tiene la ranura principal nativa; la escritura de credenciales está cercada por la reivindicación exclusiva y una instantánea de ruta/hash/inodo, y la salida del comando lleva solo el ID de flujo, el URL de verificación, el código del dispositivo y el estado. La ruta de inicio de sesión del grupo permanece solo en el grupo y sigue rechazando `__main__`; la superficie equivalente del tablero de instrumentos es el Re-login de la tarjeta principal Codex Auth con control de código del dispositivo.
+
+La matriz de recuperación v1 cubre un proceso OpenCodex que sale después de que un archivo de transacción ha sido publicado por cambio de nombre. No reclama durabilidad en un fallo del sistema operativo o kernel o pérdida de energía repentina: `atomicWriteFileAsync()` no `fsync` ni el archivo ni su directorio padre.
+
+La bóveda cifrada, el diario de conmutación, el marcador de recuperación y la cuarentena del diario viven en el directorio canónico `<real CODEX_HOME>/.opencodex-native-main-profiles`, por lo que cada OpenCodex instancia compartida en Codex casa observa un propietario y un estado de recuperación. La puesta en escena de inicio de sesión de texto sin formato permanece aislada bajo cada directorio `<OPENCODEX_HOME>/native-main-profile-staging`.
+
+Antes de que se admita el tráfico principal nativo o la recuperación del diario, el propietario de por vida acepta el reclamo de credencial exclusivo y elimina solo los residuos de accidentes exactos de `auth.json.ocx.<pid>.<sequence>.tmp`. Cada candidato debe seguir siendo un archivo regular vinculado bajo el canónico inalterado `CODEX_HOME`; está truncado, ruborizado y luego no vinculado. Las sustituciones de enlaces/reparaciones, los cambios de identidad y otras ambiguedades mantienen cerrado el tráfico principal nativo, mientras que los nombres casi perdidos nunca se eliminan automáticamente. Esto protege contra las fallas cooperativas OpenCodex, no un proceso malicioso que ya se está ejecutando como el mismo usuario del sistema operativo. Ese usuario y el sistema de archivos que contiene `CODEX_HOME` siguen siendo de confianza, y el truncamiento no promete el borrado físico del almacenamiento de copia en escritura, instantáneas o remanencia SSD.
+
+Previsualizar las compilaciones utilizadas `<OPENCODEX_HOME>/native-main-profiles`. Ese diseño nunca se importa en silencio. Si `doctor` informa el estado del perfil heredado, detenga cada proxy OpenCodex que comparta el mismo `CODEX_HOME`. Luego, haga una copia de seguridad y mueva el marcador de recuperación coincidente `*.vault.json`, `*.journal.json` y cualquier archivo de cuarentena de diario referenciado juntos al directorio canónico mientras conserva los permisos de solo propietario, o elimine el conjunto de vista previa antiguo y ejecute `ocx account main register` nuevamente. No elija entre varias raíces antiguas ni ejecute ambos diseños mientras cualquier proxy de uso compartido esté activo. En Windows, el estado de vista previa en clave de la identidad inicial plegada por mayúsculas y minúsculas anterior debe restablecerse en lugar de moverse porque su AAD encriptado y la identidad del anillo de claves del sistema operativo no se reutilizan intencionalmente.
+
+<a id="models"></a>
+
+## Modelos
+
+### `ocx models [subcommand]` · `ocx model <subcommand>`
+
+`ocx model` es un alias de `ocx models`. Sin subcomando, lista los modelos sembradas estáticamente en proveedores configurados. `--provider` filtra un proveedor configurado y `--json` devuelve metadatos del modelo. `live` lee el catálogo en ejecución; `add`, `edit`, `remove` y `list-custom` gestionan las entradas de catálogo manuales; `enable`, `disable` y `provider` controlan la visibilidad; `selected` controla una lista de proveedores; `context` controla los límites de contexto del proveedor; y `shadow` gestiona la interceptación de llamadas de sombra de fondo.
+
+Los precios modelo son estimaciones en USD por millón de tokens. `ocx models --json` incluye un objeto `price` con tasas `cost4` y su fuente; `ocx models price --json` guarda `cost` para la anulación guardada e informa las tasas resueltas en `effectiveCost`. Los precios manuales (incluido el cero) tienen prioridad, seguidos del catálogo compartido y las devoluciones de precios oficiales verificadas. Los modelos desconocidos devuelven `null`; no se inventa ningún precio. Los valores predeterminados automáticos se derivan de la lectura y no pueblan `modelCosts` en su configuración, por lo que las actualizaciones del catálogo siguen siendo efectivas. Use `set-price` para ahorrar tarifas específicas del proveedor.
+
+`price --json` también conserva una política de `promptLengthPricing` guardada en `cost`; las cuatro tasas de `effectiveCost` son las tasas base, antes de evaluar la longitud rápida o el nivel de una solicitud. Utilice **Modelos → Precio** o la administración API para editar una directiva de longitud de prompt. Los comandos `set-price` existentes reemplazan las cuatro tarifas base y mantienen la política de umbral plana o personalizada guardada del modelo; `--auto` elimina tanto las tarifas como cualquier política.
+
+Descubra la sintaxis de comandos con `ocx models --help` antes del trabajo en vivo. `list-custom` lee la configuración local; `add` y `remove` salvan localmente a menos que se les dé `--live`. La costumbre local escribe de forma oportunista cuando existe un proxy. El resto de las operaciones de gestión de modelos utilizan el proxy en ejecución. Compruebe la preparación y la versión antes de las llamadas en vivo; la inspección sin conexión no requiere iniciar un proxy. Las anulaciones de nombre de pantalla para modelos descubiertos tienen su propio comando, separado del modelo personalizado `edit`.
+
+| Subcomando | Banderas soportadas | Medidas adoptadas |
+| --- | --- | --- |
+| `list` (por defecto) | `--provider <name>`, `--json` | Lista de modelos sembrados en proveedores configurados, con precios estimados de entrada/salida. |
+| `live` | `--provider <name>`, `--json` | Lea el catálogo en ejecución, incluidos los modelos descubiertos en tiempo de ejecución. Las filas están marcadas `native` / `routed`, `custom`, y `enabled` / `disabled`. |
+| `price <provider/model>` | `--json` | Lea la anulación manual guardada y el precio efectivo, incluidos los valores predeterminados automáticos del catálogo. |
+| `set-price <provider/model>` | `--input <rate>`, `--output <rate>`, `--cache-read <rate>`, `--cache-write <rate>`, `--auto`, `--json` | Establezca los precios de visualización en USD por 1 millón de tokens. Se requieren entradas/salidas cuando se establece; las tasas de caché omitidas se vuelven cero. `--auto` elimina solo la anulación de este modelo. |
+| `add <provider> <modelId>` | `--display-name <name>`, `--context-window <tokens>`, `--modalities <text,image,audio>`, `--reasoning-efforts <levels>`, `--default-reasoning-effort <level>`, `--live`, `--json` | Registre un modelo personalizado localmente o, con `--live`, en el proxy en ejecución. |
+| `edit <custom-id>` | `--model-id <id>`, `--display-name <name\|->`, `--context-window <tokens\|0>`, `--modalities <text,image,audio\|->`, `--json` | Edite un modelo personalizado. `-` despeja un campo; `0` borra la ventana de contexto. |
+| `remove <custom-id\|provider/modelId>` | `--yes`, `--live`, `--json` | Elimine un modelo personalizado localmente o en el destino en vivo. La eliminación en vivo y la eliminación local de JSON requieren `--yes`; el modo de texto local retiene la confirmación interactiva. |
+| `display-name <provider/raw-model-id>` | `--set <text>` o `--clear`, `--json` | Establezca o borre la anulación de visualización del modelo descubierto; conserve el ID de flujo ascendente sin procesar. |
+| `order status` | `--json` | Lea el orden/modo guardado, los candidatos enrutados y el estado destacado conocido. |
+| `order set` | `--models <CSV>` o `--mode <default\|alphabetical\|provider\|most-used>`, `--json` | Establezca una permutación enrutada completa u obtenga un orden preestablecido. |
+| `order reset` | `--json` | Borrar el orden y el modo guardados, conservando la selección destacada. |
+| `list-custom` | `--json` | Mostrar todos los modelos personalizados con el `custom-id` los otros subcomandos toman. |
+| `enable <provider/model\|native-model>` | `--native`, `--json` | Haga que un modelo sea visible hasta Codex. |
+| `disable <provider/model\|native-model>` | `--native`, `--json` | Ocultar un modelo de Codex. |
+| `provider <name> <on\|off>` | `--json` | Habilitar o deshabilitar cada modelo de un proveedor en una sola escritura. |
+| `selected <provider>` | `--set <id,id...>`, `--clear`, `--json` | Lea o sustituya la lista de permisos del modelo de proveedor. `--clear` elimina la lista de permisos para que se ofrezca cada modelo. |
+| `preset show` | `--provider <name>`, `--json` | Lea las versiones preestablecidas enviadas y el modo aplicado, opcionalmente para un proveedor. |
+| `preset apply <provider>` | `--all`, `--json` | Aplicar el preajuste seleccionado; `--all` borra la lista de permisos. Un ajuste preestablecido de coincidencia cero deja la selección sin cambios e informa `fallback: "preset-empty"`. |
+| `new-policy [on\|off]` | `--provider <name>`, `--json` | Lea o cambie la política de exposición para los modelos recién descubiertos; la omisión del proveedor selecciona la política global. Un proveedor de lectura puede reportar `inherit`. |
+| `new-arrivals` | `--json` | Lea los descubrimientos recientes registrados por el proveedor; no fuerza un nuevo descubrimiento aguas arriba. |
+| `context <status\|value <tokens> [--set-all]\|provider <name> on [--value <tokens>]\|provider <name> off\|all <on\|off>>` | `--json` | Lea o establezca el límite de la ventana de contexto, globalmente o por proveedor. `value <tokens> --set-all` también vuelve a apuntar a cada proveedor enrutado (como el conmutador del panel de control); sin él, el valor solo se convierte en el predeterminado. `provider ... on --value <tokens>` establece un límite explícito solo para ese proveedor (`--value` Es válido con `on` solamente). |
+| `shadow <status\|set> [model\|-]` | `--enabled <on\|off>`, `--json` | Lee o configura el modelo de reemplazo para las llamadas de ayudante de fondo del Codex. `-` borra el modelo. `status` también reporta `sourceModels`, el ayudante lanza las intercepciones proxy (por defecto: `gpt-6-luna`, `gpt-5.6-luna`; clientes a través de 0.144.x usaron `gpt-5.4-mini`, que una anulación explícita `sourceModels` puede restaurar). |
+
+```bash
+ocx models live --json                                  # what Codex can actually see right now
+ocx models disable anthropic/claude-haiku-4             # hide one routed model
+ocx models enable gpt-5.6-sol                           # no slash, so it is treated as native
+ocx models provider zenmux off                          # hide a noisy provider wholesale
+ocx models selected anthropic --set claude-opus-5,claude-fable-5
+ocx models selected anthropic --clear                   # drop the allowlist again
+ocx models add deepseek deepseek-v4 --display-name 'DeepSeek V4' --context-window 128000 --modalities text,image
+ocx models list-custom --json                           # read the custom-id for edit/remove
+ocx models remove deepseek/deepseek-v4 --yes
+```
+
+Se enruta un selector de modelo con una barra (`anthropic/claude-opus-5`); un id desnudo se trata como un modelo nativo OpenAI, por lo que `--native` solo se necesita para forzar esa lectura para un id que de otro modo parecería enrutado.
+
+`--modalities` solo acepta `text`, `image`, y `audio`. Codex analiza ese campo como un enum cerrado y rechaza un catálogo completo que contiene cualquier otro valor, por lo que `add`, `edit` y la administración API rechazan el valor malo en lugar de almacenar algo que el escritor del catálogo tendría que eliminar más tarde (#759).
+
+<a id="live-custom-models-and-local-save-outcomes"></a>
+
+### Modelos personalizados en vivo y resultados de guardado locales
+
+Utilice nombres de proveedores configurados e ID de modelo ascendente sin procesar. Para una adición o eliminación en vivo autorizada, inspeccione el objetivo previsto y vuelva a leer después:
+
+```bash
+ocx ready --json
+ocx status --json
+ocx models add <provider> <raw-model-id> --live --display-name 'Research model' --context-window 128000 --modalities text --json
+ocx models live --json
+```
+
+Guarde el `id` devuelto almacenado. La eliminación usa `ocx models remove <complete-stored-id> --live --yes --json` o un selector de proveedor/modelo inequívoco de ese objetivo. Las etiquetas de visualización y los prefijos de ID no son selectores. No hay reserva local, eliminación protegida por revisión o reintento de ID alternativo. `models list-custom --json` es una lista local, no un registro en vivo leído para otro objetivo.
+
+Sin `--live`, el JSON de añadir/eliminar devuelve `{action, model, needsSync, sync}`. Si no hay proxy, `sync: {"status":"not-attempted","ok":false}`, `needsSync: true` y la salida es 0: el guardado local tuvo éxito y la sincronización oportunista no se intentó. Los fallos o rechazos de una sincronización intentada devuelven un código distinto de cero mientras conservan el guardado. Solo una sincronización aplicada por completo borra `needsSync`; un éxito omitido por la política puede salir con 0 con `needsSync` aún verdadero. La eliminación con JSON requiere `--yes` incluso en un terminal interactivo.
+
+<a id="display-names-and-picker-identities"></a>
+
+### Mostrar nombres e identidades de selector
+
+```bash
+ocx models display-name <provider>/<raw-model-id> --set 'Research model' --json
+ocx models live --json
+```
+
+Este comando divide por la primera barra y conserva cada barra restante en el id de modelo ascendente sin procesar. No sustituya un id de selector público codificado o un alias. `--clear` es la alternativa a `--set` y envía null. Las anulaciones de etiqueta no cambian los precios ni la identidad pública. Un resultado reconocido como guardado pero con actualización fallida tiene `saved: true` y código de salida 1; inspeccione el estado antes de otra escritura.
+
+```bash
+ocx models order status --json
+ocx models live --json
+ocx models order set --models '<complete-public-id-permutation>' --json
+ocx models order status --json
+```
+
+El pedido manual utiliza los identificadores públicos en `pickerAvailable`, cada candidato enrutado exactamente una vez, con los modelos destacados actuales en su orden inicial requerida exacta. Las entradas en blanco, duplicadas, faltantes, desconocidas y ambiguas se niegan. El CLI vuelve a leer los ajustes y las identidades del modelo inmediatamente antes del PUT manual; el estado modificado devuelve el conflicto. Este es un chequeo observacional, no CAS, así que léalo después. Nunca silenciosamente deja caer identidades natales o modifica la selección ofrecida.
+
+Alternativamente, seleccione `--mode alphabetical`, `--mode provider` o `--mode most-used`. Estos ajustes preestablecidos no preceden al prefijo de la función manual. La mayoría de las lecturas utilizadas son de todos los tiempos, el uso de toda la superficie, retiene a los candidatos no clasificados y rechaza la historia incompleta. Tanto los modos manuales como los modos no predeterminados rechazan los pedidos guardados que contienen ID nativas desnudas. Si se pretende borrar esa orden guardada, use primero `ocx models order reset --json` o `ocx models order set --mode default --json`. No reajuste automáticamente el rechazo.
+
+Las escrituras personalizadas y de orden en vivo incluyen `catalogRefresh`. Solo una actualización confirmada y no degradada sale con 0; una actualización omitida, fallida o degradada devuelve el recibo guardado con código de salida 1. El recibo de un pedido `applied` es la lista destacada, no la convergencia del cliente. Los resultados desconocidos requieren inspección, no una suposición de reversión.
+
+<a id="apply-a-preset-and-verify-selection"></a>
+
+### Aplicar un preajuste y verificar la selección
+
+```bash
+ocx models preset show --provider anthropic --json
+ocx models preset apply anthropic --json
+ocx models selected anthropic --json
+ocx models new-policy --provider anthropic --json
+ocx models new-policy off --provider anthropic --json
+ocx models new-policy --provider anthropic --json
+ocx models new-arrivals --json
+```
+
+Las escrituras requieren la intención de cambiar la política de selección o descubrimiento. Lee la selección y la política; un ajuste preestablecido guardado puede dejar intacta la selección anterior. `preset apply <provider> --all` es el modo compatible con todos los modelos; el preajuste personalizado del panel de control deshabilitado no agrega otro modo seleccionable.
+
+<a id="mark-one-model-text-only"></a>
+
+### Marcar un solo texto de modelo
+
+Use `ocx provider add mine --adapter openai-chat --base-url https://example.com/v1 --default-model model-a --text-only` al registrar un proveedor, o `ocx provider edit mine --model model-a --text-only` para un proveedor existente. Add puede usar `--model` o su modelo predeterminado; editar requiere `--model`. La bandera actualiza solo los modelos exactos `modelCapabilities.inputModalities` a `["text"]`, preservando otros modelos y ejes.
+
+<a id="cached-quota-history"></a>
+
+### Historial de cuotas en caché
+
+Los cheques automáticos de agotamiento de la cuenta OpenAI distinguen los créditos de uso comprados de los tickets de restablecimiento. El gasto permanece desactivado de forma predeterminada: habilite **Usar créditos** para esa cuenta (almacenada en `creditCodexAccountIds`). Solo que la aceptación junto con un saldo gastable positivo fresco o créditos ilimitados puede mantener una cuenta elegible después de que el uso incluido alcance el 100%; un límite de rechazo o exceso de edad aún bloquea esa evidencia. La evidencia de crédito expira después de cinco minutos, y los encabezados de uso no renuevan su reloj. `pause-exhausted` utiliza esta regla. Restablecer tickets por sí solo nunca otorga espacio libre automático, y una respuesta de solo créditos no puede borrar un tiempo de reutilización de la solicitud. El bloqueo de la cuenta principal por defecto sigue siendo una política local separada y no se levanta por el interruptor de créditos.
+
+`ocx account history openai <pool-account-id> [--limit 1-200] [--json]` lee las observaciones almacenadas sin ponerse en contacto con el proveedor. La salida separa el tiempo de observación real, WHAM o fuente de encabezado de respuesta, familia de ventanas y porcentaje de uso. Como máximo 200 observaciones por cuenta se conservan durante 30 días, con límites de almacenamiento global.
+
+Cuando una misma cuenta de grupo sigue informando dos ventanas de siete días distintas (por ejemplo, 100% usado con un restablecimiento en unas horas y después 24% usado con un restablecimiento la semana siguiente), la fila de la cuenta incluye `weeklyQuotaConflicts` con el uso, el restablecimiento, la fuente y la hora de la última observación de cada ventana. La columna QUOTA de `ocx account list openai --quota` añade `(weekly windows conflict)`, y la tarjeta del panel de control explica que el restablecimiento que muestra puede no devolver la asignación completa. OpenCodex no elige ninguna de las dos ventanas y no cambia por ello la selección de cuenta, los bloqueos estrictos ni el uso de créditos. La advertencia desaparece cuando ha pasado la hora de restablecimiento más temprana.
+
+La actualización ordinaria de tokens conserva la historia. La reautenticación, eliminación o reemplazo de cuenta retira la publicación anterior. No se incluyen las sondas principales nativas realizadas antes de publicar un inicio de sesión. La historia que falta significa observaciones insuficientes, no uso cero. Este comando no gasta cuota. Las estimaciones efectivas, cuando se apoyan en observaciones, llevan las limitaciones a continuación.
+
+La producción histórica también incluye estimaciones efectivas de tokens informados cuando las observaciones de la misma ventana y el uso atribuible los respaldan. Cada estimación incluye un recuento de muestras y baja confianza. El redondeo de las cuotas, el uso externo y la continuidad supuesta de la etiqueta de registro limitan la inferencia; no es la asignación de token de su proveedor. La evidencia del libro mayor faltante o truncado devuelve evidencia insuficiente. `--limit` controles muestran el historial, no la entrada de estimación limitada.
+
+### `ocx account routes anthropic`
+
+Lea las rutas guardadas del modelo Anthropic OAuth, reemplácelas de una matriz local JSON o deslícelas:
+
+```sh
+ocx account routes anthropic --json
+ocx account routes anthropic --file routes.json
+ocx account routes anthropic --clear
+```
+
+El archivo está limitado a 64 KiB. El servidor valida cada ruta y la almacena bajo `anthropicAccountPool.routes`; las escrituras requieren el proxy en ejecución. Use los ID de cuenta almacenados de `ocx account list anthropic --json`. Las reglas solo afectan al grupo habilitado y nunca afirman que una cuenta tiene derecho a un modelo. Los registros de solicitudes identifican una regla coincidente como `route:#<n>` (posición de lista basada en 1), sin su nombre de operador.
+
+Los ayudantes de visión y búsqueda web coinciden con su propio modelo de forma independiente y pueden fallar localmente cuando su ruta estricta no tiene una cuenta elegible. Véase [Anthropic enrutamiento de cuenta de ayudante](/es/reference/configuration/providers/#anthropicaccountpool-experimental).
+
+
+`reset-affinity` confirma que se borraron todos los vínculos de sesión de Anthropic sin exigir cuentas, cambiar selección o pausas. Se ejecuta en Home; un Child informa del Home sin enviar. HTTP 404 termina con 4, 409 con 5 y otros errores o resultado no confirmado con 1.
+
+Cuando el saldo es desconocido, `quotaUnknownReason` explica `no_balance_source`, sin lector; `passive_not_observed`, sin observación pasiva; `read_failed`, lectura fallida; `not_read`, lector aún no usado, por ejemplo clave pausada; o `not_reported`, lectura correcta sin saldo. Filas de sondeo incluyen `quotaReadAt`, milisegundos epoch del último intento, incluso fallido. Solo `quotaMode: "probe"`, como OpenRouter, DeepSeek, Ollama Cloud, Moonshot, Venice o Abliteration, informa un saldo medido. La salida humana usa `unsupported: balance UNKNOWN (no balance source)` o `probe: mo 12%; read 3 min ago`, nunca cero por desconocido. OAuth sin observación muestra `UNKNOWN (not observed yet)`. CLIs antiguas ignoran los nuevos campos; motivos desconocidos se omiten.
+
+<a id="resume-if-healthy"></a>
+
+#### Reanudar solo si está sana
+
+`ocx account resume <provider> <account-id-or-alias> --if-healthy` permite un supervisor sin atención, pero solo reanuda después de leer con éxito el uso de esa cuenta: WHAM para Pool Codex o el token almacenado para Anthropic. Pausas automáticas `oauth_organization_disabled` y `account_permission_denied` nunca se levantan así. Un token Anthropic caducado no se renueva en esta prueba: `credential_expired` exige login nuevo. Otros OAuth y la principal Codex devuelven `health_check_unsupported`; pools de claves rechazan la opción. Un rechazo termina con 3 y motivo, o `{ "ok": false, "resumed": false, "reason": ... }` con JSON. Un login o reautenticación explícitos limpian pausas automáticas de la credencial anterior; una manual espera `ocx account resume`.
+
+Un enfriamiento Anthropic 429 con ventanas de cuota identificadas se puede levantar al observar margen en todas: el barrido de instancias OAuth activas consulta aproximadamente cada minuto, o diez mientras sigan agotadas. Un 429 solo con Retry-After conserva su plazo. Clear-cooldown sigue siendo el override manual.
+
+`ocx models` sin subcomando lista modelos locales guardados, semillas y caché de descubrimiento de ese proceso, no el catálogo del proxy. `reasoningEfforts` solo aparece con JSON: null es escala desconocida o no consultada, también si exigiría abrir el llavero; `[]` es escala explícitamente vacía o razonamiento desactivado, como `noReasoningModels`. Usa `ocx models live` para el catálogo activo. `new-policy [on\|off\|admit]` permite `admit`, que añade llegadas a `selectedModels` personalizado; sin proveedor selecciona política global y una lectura de proveedor puede decir inherit.
diff --git a/docs-site/src/content/docs/es/reference/client-support.md b/docs-site/src/content/docs/es/reference/client-support.md
new file mode 100644
index 00000000000..8b3c32a1c3b
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/client-support.md
@@ -0,0 +1,60 @@
+---
+title: "Compatibilidad con clientes"
+description: "Qué herramientas de programación conecta opencodex, cómo se conecta cada una y qué protocolo utiliza."
+---
+
+<!-- GENERATED by scripts/generate-client-support-matrix.ts. Do not edit by hand. -->
+<!-- Regenerate: bun run docs:clients -->
+
+opencodex es una única pasarela local para tus herramientas de programación con IA y tus modelos. Configura algunas herramientas de forma nativa; para las demás, exporta o administra un archivo de configuración que las dirige al proxy local. Esta página se genera a partir de los registros del código, por lo que enumera exactamente lo que ofrece la versión actual.
+
+## Niveles de compatibilidad
+
+- **implemented**: el cliente figura en el registro. Para las configuraciones exportadas, el protocolo mostrado se lee de la configuración que genera opencodex, y la generación falla si cambia. Un protocolo marcado como *revisado* indica un endpoint determinado mediante una revisión, en lugar de obtenerse de la propia configuración (clientes nativos y clientes que convierten un ajuste en un endpoint concreto); el generador comprueba que el código revisado siga presente. Las filas «Compatible con OpenAI» no afirman que se use un endpoint concreto.
+- **test-covered**: cumple implemented y enlaza un caso de prueba elegido durante la revisión que ejercita este cliente. El generador solo comprueba que la prueba siga existiendo y esté habilitada; léela para saber qué verifica.
+- **Verificado en ejecución**: una observación histórica: una persona ejecutó el producto cliente y la versión exactos que se indican con la versión de opencodex mostrada, en el escenario y la fecha señalados, y enlazó la evidencia. No demuestra nada sobre otras versiones o productos. La evidencia se revisa al añadir el resultado; el generador no vuelve a ejecutar la prueba. Un guion significa que no hay ningún resultado registrado.
+
+## Clientes
+
+| Cliente | Nativo | Exportación de configuración | Integración mediante archivo administrado | Protocolo de entrada | Nivel de compatibilidad | Verificado en ejecución | Notas |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| Codex (CLI, app, SDK) | Sí | — | — | Responses (revisado) | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/codex-integration/codex-inject-missing-config.test.ts)) | — | Configurado por el propio opencodex, sin archivo de configuración exportado. [guía](/es/guides/codex-integration/) |
+| Claude Code | Sí | — | — | Anthropic Messages (revisado) | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/claude-integration/claude-cli.test.ts)) | — | Configurado por el propio opencodex, sin archivo de configuración exportado. [guía](/es/guides/claude-code/) |
+| Claude Desktop | Sí | — | — | Anthropic Messages (revisado) | implemented | — | Configurado por el propio opencodex, sin archivo de configuración exportado. |
+| Grok Build | Sí | — | — | Responses (revisado) | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/providers/xai/grok-config-inject.test.ts)) | — | Configurado por el propio opencodex, sin archivo de configuración exportado. [guía](/es/guides/grok-build/) |
+| Qoder | — | JSON | Sí | Compatible con OpenAI (endpoint elegido por el cliente) | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/clients/qoder-client.test.ts)) | — | Solo escucha local. |
+| Qoder CN | — | JSON | Sí | Compatible con OpenAI (endpoint elegido por el cliente) | implemented | — | Solo escucha local. |
+| WorkBuddy | — | JSON | Sí | Chat Completions | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/clients/agent-clients.test.ts)) | — | Solo escucha local. Antes de aplicar los cambios, se ejecuta una comprobación específica del cliente que puede rechazarlos. |
+| WorkBuddy AI | — | JSON | Sí | Chat Completions | implemented | — | Solo escucha local. Antes de aplicar los cambios, se ejecuta una comprobación específica del cliente que puede rechazarlos. |
+| OpenCode | — | JSON | Sí | Chat Completions | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/config/client-config-export.test.ts)) | — | El exportador también admite la escucha remota (añade la cabecera de clave API). [guía](/es/guides/opencode/) |
+| Pi | — | JSON | Sí | Chat Completions | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/config/client-config-export.test.ts)) | — | Solo escucha local. [guía](/es/guides/pi/) |
+| Oh My Pi (omp) | — | YAML | Sí | Chat Completions; Responses (solo modelos nativos de OpenAI) | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/config/client-config-export.test.ts)) | — | Solo escucha local. Solo edita su propio bloque YAML. |
+| Hermes | — | YAML | Sí | Chat Completions | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/clients/hermes-catalog-refresh.test.ts)) | — | El exportador también admite la escucha remota (añade la cabecera de clave API). Solo edita su propio bloque YAML. |
+| OpenClaw | — | JSON5 | Sí | Chat Completions | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/gui/integrations-invariants.test.ts)) | — | El exportador también admite la escucha remota (añade la cabecera de clave API). |
+| Kimi CLI | — | TOML | Sí | Compatible con OpenAI (endpoint elegido por el cliente) | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/config/client-config-export-new-clients.test.ts)) | — | Solo escucha local. |
+| Gajae | — | YAML | Sí | Chat Completions | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/clients/client-export-modality-enum.test.ts)) | — | Solo escucha local. |
+| DSH | — | YAML | Sí | Responses | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/config/client-config-export.test.ts)) | — | Solo escucha local. Escribe en el almacén actual de proveedores del cliente. Solo edita su propio bloque YAML. Las escrituras se coordinan mediante un archivo de bloqueo junto a la configuración. |
+| MCode | — | YAML | Sí | Anthropic Messages | implemented | — | Solo escucha local. Las escrituras se coordinan mediante un archivo de bloqueo junto a la configuración. |
+| ZCode | — | JSON | Sí | Responses (revisado) | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/clients/integrations-current-store.test.ts)) | — | Solo escucha local. Escribe en el almacén actual de proveedores del cliente. El cliente elige el endpoint a partir de este ajuste (revisado según el comportamiento documentado del cliente). |
+| Command Code | — | JSON | Sí | Chat Completions | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/clients/command-code-client.test.ts)) | — | Solo escucha local. Las escrituras se coordinan mediante un archivo de bloqueo junto a la configuración. |
+| Prime | — | JSON | Sí | Chat Completions | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/clients/prime-client.test.ts)) | — | Solo escucha local. |
+| Aside | — | JSON | Sí | Chat Completions | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/clients/aside-profiles-catalog-refresh.test.ts)) | — | Solo escucha local. |
+| Raycast | — | YAML | Sí | Chat Completions (revisado) | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/clients/raycast-client.test.ts)) | — | Solo escucha local. El cliente elige el endpoint a partir de este ajuste (revisado según el comportamiento documentado del cliente). |
+| omo | — | JSON | Sí | Chat Completions | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/clients/omo-client.test.ts)) | — | Solo escucha local. |
+| Cline | — | JSON | Sí | Responses | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/clients/cline-client.test.ts)) | — | Solo escucha local. Las escrituras se coordinan mediante un archivo de bloqueo junto a la configuración. |
+| Kilo Code | — | JSON | Sí | Chat Completions | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/clients/client-export-reasoning-controls.test.ts)) | — | El exportador también admite la escucha remota (añade la cabecera de clave API). |
+| Factory Droid | — | JSON | Sí | Chat Completions | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/clients/droid-client.test.ts)) | — | Solo escucha local. [guía](/es/guides/factory-droid/) |
+| Gentle Shell | — | JSON | Sí | Chat Completions | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/clients/gentle-shell-client.test.ts)) | — | Solo escucha local. |
+| T3 Code | — | JSON | Sí | Anthropic Messages | test-covered ([prueba](https://github.com/lidge-jun/opencodex/blob/dev/tests/clients/t3code-client.test.ts)) | — | Solo escucha local. Antes de aplicar los cambios, se ejecuta una comprobación específica del cliente que puede rechazarlos. |
+
+## Endpoints de entrada
+
+El proxy acepta estos protocolos. Una herramienta que no figure arriba puede conectarse si permite configurar un endpoint personalizado para alguno de ellos.
+
+- `POST /v1/responses`: Responses
+- `POST /v1/chat/completions`: Chat Completions
+- `POST /v1/messages`: Anthropic Messages
+
+## Mantener esta página actualizada
+
+Esta página se genera mediante `scripts/generate-client-support-matrix.ts` a partir de los registros de exportación, integración administrada e integración nativa. Para añadir un cliente, añade su entrada en `scripts/client-support-matrix/metadata.ts` y ejecuta `bun run docs:clients`; `bun run docs:clients:check` falla mientras la página guardada en el repositorio esté desactualizada.
diff --git a/docs-site/src/content/docs/es/reference/code-signing.md b/docs-site/src/content/docs/es/reference/code-signing.md
new file mode 100644
index 00000000000..1eb2190e3e9
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/code-signing.md
@@ -0,0 +1,78 @@
+---
+title: "Firma de código en Windows"
+description: "Cómo OpenCodex firma sus binarios de Windows mediante SignPath Foundation, cómo verificar las firmas y qué política aplica."
+---
+
+OpenCodex está incorporando firmas Authenticode de [SignPath Foundation](https://signpath.org) en sus descargas de Windows: el ejecutable independiente `ocx.exe` y el instalador de escritorio `OpenCodex-<version>-windows-x64.msi`. Una firma identifica al editor ante Windows, SmartScreen y los antivirus y permite comprobar que el archivo no cambió después de compilarlo. Puede reducir los avisos y falsos positivos por binarios sin firma como el de [#7207](https://github.com/lidge-jun/opencodex/issues/7207). No garantiza que SmartScreen lo acepte ni demuestra que el archivo sea seguro: [Microsoft explica](https://learn.microsoft.com/windows/apps/package-and-deploy/smartscreen-reputation) que un binario recién firmado todavía puede mostrar avisos de reputación.
+
+La incorporación está en curso. El flujo de publicación ya está preparado y SignPath lo valida con un certificado de prueba. Hasta que se emita el certificado de producción, los archivos de Windows se publican sin firma y SmartScreen puede pedir confirmación (**Más información → Ejecutar de todas formas**). Después de ese cambio, el flujo intentará firmarlos en producción mediante **SignPath Foundation**. Si la firma o su verificación falla, la versión puede incluir el archivo original sin firmar, como se explica más abajo.
+
+<a id="code-signing-policy"></a>
+
+## Política de firma de código
+
+Firma gratuita proporcionada por [SignPath.io](https://about.signpath.io/), con certificado de [SignPath Foundation](https://signpath.org/).
+
+- Personas que realizan commits y revisiones: [lidge-jun](https://github.com/lidge-jun).
+- Aprobador: [lidge-jun](https://github.com/lidge-jun).
+
+Cada solicitud de firma de una versión se aprueba manualmente en SignPath antes de usar el certificado. Solo se firman los binarios compilados desde el código de este repositorio mediante GitHub Actions. Los archivos de terceros incluidos, como los módulos de llavero precompilados, conservan su forma original: la política de SignPath Foundation prohíbe firmarlos con el certificado del proyecto.
+
+<a id="privacy"></a>
+
+### Privacidad
+
+OpenCodex envía un resumen de uso anónimo diario (un hash de instalación por día que cambia a diario, la versión, el canal de publicación, la plataforma, el canal de instalación, el tipo de proveedor, la familia de modelo aproximada, los minutos activos y los recuentos de solicitudes, tokens y errores; nunca prompts, salidas de modelo, claves, cuentas, nombres de host ni rutas) a telemetry.opencodex.me, y solo después de que la persona que lo instala u opera haya visto el aviso en el dashboard o en un prompt interactivo de la CLI y no lo haya rechazado. Se puede desactivar en ese aviso, en el instalador de Windows («Send anonymous usage statistics», marcado por defecto), en **Detalles del proxy**, o con `ocx telemetry disable`, `OCX_TELEMETRY=0` o `DO_NOT_TRACK=1`. Solo son públicos los agregados de proyecto de estos datos anónimos. Un **perfil público** independiente para la clasificación está desactivado salvo que lo conectes personalmente (*Perfil público y clasificación* en Inicio, u `ocx telemetry profile connect`); comparte únicamente un identificador, un nombre visible y un color elegidos, y tus totales diarios de solicitudes, tokens y familias de modelo, nunca tu ID de telemetría anónimo, y desconectarlo lo elimina. Todo lo demás va solo a los proveedores y servicios que configures. Para buscar versiones nuevas, OpenCodex también lee metadatos de publicaciones de GitHub y del registro npm, y esas comprobaciones de versión no llevan ninguno de tus prompts ni credenciales. Consulta [Telemetría y privacidad](/es/guides/telemetry/).
+
+<a id="verifying-a-download"></a>
+
+## Verificar una descarga
+
+En PowerShell, comprueba el archivo descargado:
+
+```powershell
+Get-AuthenticodeSignature .\OpenCodex-<version>-windows-x64.msi | Format-List Status, SignerCertificate
+Get-AuthenticodeSignature .\ocx.exe | Format-List Status, SignerCertificate
+```
+
+Una versión firmada muestra `Status : Valid` y un certificado cuyo sujeto identifica a `SignPath Foundation`. En el Explorador puedes ver la misma información en **Propiedades → Firmas digitales**. Cada archivo publicado tiene un `.sha256` junto a él en la página de versiones; puedes compararlo con `Get-FileHash <file> -Algorithm SHA256`.
+
+<a id="what-gets-signed"></a>
+
+## Qué archivos se firman
+
+| Archivo | Contenido firmado |
+|---|---|
+| `ocx-<version>-bun-windows-x64.zip` | El `ocx.exe` del archivo. El ZIP y su `.sha256` se generan a partir del binario firmado. |
+| `OpenCodex-<version>-windows-x64.msi` | El instalador y todos los `.exe` que instala, incluida la aplicación de escritorio y su `ocx.exe`. |
+
+La firma del actualizador de escritorio (`.msi.sig`) y `latest.json` se generan a partir del instalador firmado. Así, las actualizaciones dentro de la aplicación instalan los mismos bytes que ofrece la página de versiones.
+
+<a id="for-maintainers"></a>
+
+## Para mantenedores
+
+El flujo de publicación (`.github/workflows/release.yml`) firma mediante la acción oficial `signpath/github-action-submit-signing-request`. Lee un secreto y tres variables del repositorio:
+
+| Nombre | Tipo | Valor |
+|---|---|---|
+| `SIGNPATH_API_TOKEN` | Secreto | Token API del usuario de CI de SignPath |
+| `SIGNPATH_ORGANIZATION_ID` | Variable | Identificador de la organización de SignPath |
+| `SIGNPATH_PROJECT_SLUG` | Variable | `opencodex` |
+| `SIGNPATH_SIGNING_POLICY_SLUG` | Variable | `test-signing` actualmente; `release-signing` cuando se emita el certificado |
+
+Las configuraciones de artefactos de SignPath son `windows-standalone-zip` (un `ocx.exe` en la raíz del ZIP) y `windows-msi-zip` (un `.msi` en la raíz del ZIP, con firma profunda).
+
+La firma nunca bloquea una publicación. El resultado depende de la política:
+
+| Política | Simulación | Publicación real |
+|---|---|---|
+| Sin token o con configuración incompleta | Sin firma | Sin firma, con un aviso o advertencia |
+| `test-signing` | Firmado con el certificado de prueba y conservado solo como artefacto del workflow | Sin firma, con un aviso; nunca se distribuye un certificado de prueba |
+| `release-signing` | Firmado y verificado como confiable | Firmado y verificado como confiable |
+
+Si la solicitud de firma falla, agota el tiempo o se rechaza, o si falla la verificación, el trabajo registra una advertencia y publica el archivo original sin firmar. El MSI conserva su firma original del actualizador cuando existe; el ejecutable independiente `ocx.exe` no tiene firma del actualizador.
+
+**Cambiar al certificado de producción.** Cuando SignPath lo emita, establece `SIGNPATH_SIGNING_POLICY_SLUG` en `release-signing` desde la configuración del repositorio (Settings → Secrets and variables → Actions → Variables). No hace falta modificar el workflow. Desde entonces, cada publicación, incluidas las simulaciones, abre dos solicitudes: una para el binario independiente y otra para el instalador. Un aprobador debe aceptar ambas en [app.signpath.io](https://app.signpath.io) mientras la ejecución espera. El flujo espera hasta una hora por solicitud antes de continuar con archivos sin firmar.
+
+**Probar sin publicar.** El workflow **Windows signing test** (`.github/workflows/windows-signing-test.yml`, solo ejecución manual y sin parámetros) compila `ocx.exe` y el MSI en servidores Windows de GitHub, firma ambos con `test-signing`, verifica las firmas y los conserva como artefactos de corta duración. No publica nada ni usa la política de publicación.
diff --git a/docs-site/src/content/docs/es/reference/codex-retry-diagnostics.md b/docs-site/src/content/docs/es/reference/codex-retry-diagnostics.md
new file mode 100644
index 00000000000..6e97d2067be
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/codex-retry-diagnostics.md
@@ -0,0 +1,112 @@
+---
+title: "Diagnósticos de reintentos de Codex"
+description: "Distingue los avisos de límites de solicitudes, la repetición automática, la recuperación del proveedor y las notificaciones de escritorio."
+---
+
+OpenCodex [Adaptador Devin](/es/reference/adapters/#devin) conserva una pista de reintento utilizable en el contrato de error Codex entiende. Esto no garantiza que Desktop muestre una fila de reconexión o que el proveedor acepte la siguiente solicitud.
+
+<a id="who-waits"></a>
+
+## Quien espera
+
+Con `OPENCODEX_DEVIN_STATED_RESET_WAIT_MS` sin configurar o `0`, el adaptador Devin no mantiene una solicitud rechazada para el enfriamiento indicado. Codex recibe el fallo final y posee su política de reintentos limitada. Un valor positivo opta por la espera existente de propiedad de proxy; retrasa la entrega del fallo final y puede combinarse con reintentos de clientes. Esta asignación de compatibilidad no cambia ese ajuste ni el recuento de reintentos de Codex. Una anulación de solo proceso no necesita sobrevivir al reinicio.
+
+`rate_limit_exceeded` junto con `Please try again in Ns.` es un consejo de reintento, no un evento de cuenta atrás. La propia política de reintento, cancelación y ciclo de vida de Codex todavía se aplican. No agregues elementos sintéticos de razonamiento, herramienta, asistente o éxito para hacer visible la espera: esos elementos pueden contaminar el historial o implicar que el trabajo sucedió. No acorte el retraso del proveedor ni provoque una solicitud adicional para avanzar en el contador de reintentos del cliente.
+
+## Triage: `exceeded retry limit, last status: 429 Too Many Requests`
+
+El mensaje es el resumen del presupuesto de reintento del cliente, no un diagnóstico. Una negativa que el cliente no retransmita puede terminar un turno en las mismas palabras que un presupuesto totalmente agotado, así que trate el texto como una pregunta. Tres casos se ven idénticos en esta capa y se comprueban de manera diferente.
+
+| Comprobar | Evidencias distintivas | Si el cheque es positivo |
+| --- | --- | --- |
+| Cerradura de la cuenta principal (política de admisión local) | La configuración del panel de control o `GET /api/settings` informa el estado de la política, como `mainAccountHardLock.state` que es `blocked`, `ready` o `off`, con `thresholds` y un `resetAt` opcional. Una solicitud de no transmisión también puede llevar un cuerpo de política principal explícito en lugar de un desnudo aguas arriba 429. | Actualizar el uso con `ocx account refresh openai`; el nuevo uso por debajo de cada umbral de bloqueo o ausencia de ventana validada libera el bloqueo. Si permanece bloqueado, espere a que se reduzca el uso o apague explícitamente `codexMainAccountHardLock` en Configuración. Builds before [#6287](https://github.com/lidge-jun/opencodex/pull/6287) podría mantener un bloque obsoleto de ventana corta a través de reinicios cuando ninguna observación nueva lo reemplazó; la semántica de liberación se describe en el [nota de cierre de #6244](https://github.com/lidge-jun/opencodex/issues/6244). |
+| Ventana del plan ChatGPT | La sección de cuotas de cuenta muestra una ventana de 5 horas o semanal en o cerca de su límite, mientras que la cerradura informa `ready` o `off`. | Espere a que la ventana se restablezca, inspeccione cualquier opción de reinicio que ofrezca ChatGPT ([Reglas de restablecimiento bancario](https://help.openai.com/en/articles/20001498-how-banked-codex-resets-work), [Plan de Ventanas](https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan) ) o atienda la solicitud en otra cuenta con `ocx account use openai <id>`. Para el uso de crédito pagado explícitamente autorizado después del límite, vea [política de crédito de cuenta](/es/reference/cli/providers-accounts/#pool-policy-account-thresholds-and-paid-credit-intent). El defecto de redescubrimiento de la balanza crediticia en [#6845](https://github.com/lidge-jun/opencodex/issues/6845) fue arreglado por [#6886](https://github.com/lidge-jun/opencodex/pull/6886). |
+| Incidente del proveedor o falla de transporte | La cuota se mantiene baja, la cerradura se mantiene liberada y `ocx doctor` informa problemas de transporte o ChatGPT de accesibilidad. | Vuelva a intentar después de que el incidente se despeja o redirija a través de un combo existente. Cambiar la política de bloqueo o umbral no es una cura para un fallo de transporte. |
+
+Una respuesta `upstream_reset_replay_refused` generada por el proxy también usa el estado 429: se desconoce si el proveedor ejecutó la solicitud, por lo que OCX rechaza reenviarla automáticamente. Su causa en el registro es `transport-ambiguous`, no un límite de cuota del proveedor. Se aplica a rutas directas y fallos de destinos de combo en entradas HTTP y WebSocket, con independencia de `upstreamWebsocket`. Estos rechazos sintéticos no enfrían destinos ni cuentan como límites de cuentas; los 429 reales mantienen su tratamiento. Las versiones antiguas pueden registrar un rechazo WebSocket o de combo como `rate-limit` / `rate_limit_exceeded`; esa combinación no demuestra que se haya agotado la cuota. `headers-only` es una etapa de progreso, no prueba de haber recibido encabezados del proveedor. Atribuir correctamente el rechazo no diagnostica ni repara el reinicio de conexión original.
+
+Una credencial principal bloqueada cierra la solicitud de admisión; no reserva la cuota restante de la cuenta, y un restablecimiento predicho nunca libera el bloque por sí solo. Los umbrales (por defecto `short` 90, `long` 98) son visibles en la carga útil de estado y configurables a través de `codexMainAccountHardLockThresholds`.
+
+Un rechazo de bloqueo duro se informa como `usage_limit_reached`, por lo que Codex termina el turno y marca un objetivo activo como limitado al uso en lugar de esperar días en un reintento. El tiempo de reintento sugerido es el restablecimiento de la cuenta principal o, para una solicitud de que el grupo de cuentas enrutado a la cuenta principal, el primer momento conocido en que se recupera otra cuenta del grupo, lo que ocurra primero (nunca antes de un minuto). Reanudar el objetivo después de ese tiempo; enrutamiento a continuación, recoge una cuenta de estado fresco.
+
+<a id="stored-account-credit-metadata-retries"></a>
+
+## Reintentos de metadatos de crédito de cuentas guardadas
+
+Una cuenta guardada seleccionada explícitamente puede agotar su uso incluido cuando la última observación del saldo de créditos tiene más de cinco minutos. Si tiene activado el uso de créditos y la evidencia está desactualizada, ausente o incompleta, su rechazo local 429 recomienda reintentar tras el intervalo base de metadatos de 300 segundos, o al restablecerse la cuota incluida si ocurre antes. Un enfriamiento conocido del proveedor más tardío para el ámbito de cuota seleccionado, incluidas las retenciones de toda la cuenta, conserva la prioridad: si ambos se aplican, gana el plazo posterior. No se incorporan retenciones de otros grupos de modelos. El restablecimiento original de la ventana incluida sigue asociado al rechazo interno como `resetAt`; el aviso más corto ofrece volver a consultar metadatos, no un nuevo restablecimiento de cuota.
+
+La solicitud sigue rechazada hasta disponer de evidencia reciente de créditos utilizables. El aviso no actualiza datos, no evita el ritmo de consultas, no garantiza la recuperación, no cambia la cuenta ni activa el uso de créditos. Los vínculos Direct conservan su identidad. La desactivación explícita de créditos, un valor null antiguo en caché sin procedencia, un veto de gasto conocido o un saldo finito vacío sin derecho a créditos ilimitados conservan el aviso de restablecimiento incluido. Un resumen de créditos recién observado ausente o mal formado retira la autorización de gasto, pero permite el reintento corto de metadatos; un veto explícito sigue prevaleciendo. Los créditos ilimitados con saldo cero también necesitan evidencia reciente. Los retrasos 429 ordinarios del proveedor mantienen el máximo de 24 horas del analizador para valores Retry-After numéricos y en formato de fecha HTTP.
+
+<a id="triage-idle-timeout-waiting-for-sse"></a>
+
+## Diagnóstico: `idle timeout waiting for SSE`
+
+Codex termina un stream que no ha enviado eventos durante `stream_idle_timeout_ms` —300 segundos
+por defecto— y reintenta el turno. El mensaje por sí solo no explica el silencio. En el WebSocket
+nativo de ChatGPT, una posible causa es una ruta que falló silenciosamente después de empezar
+la respuesta: reiniciar una VPN o túnel, reconectar Wi-Fi o caducar una asignación NAT puede
+interrumpirla sin que el proxy reciba FIN o RST.
+
+En el endpoint canónico de ChatGPT Codex (`https://chatgpt.com/backend-api/codex/responses`, con
+canal de metadatos), el proxy envía pings durante todo el intercambio. Después de empezar la
+respuesta, si el otro extremo respondió al menos a un ping y luego no entrega ningún frame ni
+pong durante dos intervalos de ping, el stream termina con un fallo reintentable. Codex se
+reconecta entre 30 y 45 segundos después del último frame o pong, en vez de esperar 300 segundos.
+La fila de reconexión identifica la causa:
+
+```text
+Reconnecting... 1/5 (stream disconnected before completion: Upstream stream terminated unexpectedly: codex websocket stopped answering after the response started [cause=after-response-started ...])
+```
+
+Si un ping alcanza una ruta que un túnel reiniciado restablece, la fila informa
+`codex websocket closed before a Responses terminal event (close 1006)` en aproximadamente
+un intervalo de ping. Un `idle timeout waiting for SSE` que sigue llegando después del plazo
+completo corresponde a un extremo que respondió a los pings sin enviar eventos, uno que nunca
+respondió a un ping o un intercambio sin canal de metadatos, como el WebSocket Responses de OpenAI
+API, que no envía pings. En esos tres casos se conserva deliberadamente el plazo del cliente.
+`ocx logs get <request-id> --json` muestra `codexWsStage` y los recuentos `pings` y `pongs` del
+intento para distinguirlos. Aumentar `stream_idle_timeout_ms` solo prolonga la espera.
+
+<a id="why-the-first-reconnect-row-can-be-absent"></a>
+
+## Por qué la primera fila de reconexión puede estar ausente
+
+La fuente pública Codex `rust-v0.158.0-alpha.2.1` guarda la notificación de reintento de transmisión ordinaria en [`handle_response_stream_error`](https://github.com/openai/codex/blob/rust-v0.158.0-alpha.2.1/codex-rs/core/src/responses_retry.rs):
+
+```rust
+let report_error = retry_count > 1
+    || cfg!(debug_assertions)
+    || !sess.services.model_client.responses_websocket_enabled();
+```
+
+En una construcción de liberación, el primer reintento en este bucle puede por lo tanto esperar sin emitir `Reconnecting...` cuando el predicado interno habilitado para WebSocket es verdadero. El retardo seleccionado no es parte de ese predicado de notificación, y el reposo está fuera del bloque `if report_error`. Una larga espera aconsejada por el servidor también puede ser silenciosa. Esta es una observación de origen específica de la versión, no prueba de que cualquier solicitud de escritorio en particular tomó esa rama. No inferir el predicado interno de un nombre de modelo, un estado HTTP o el transporte visto en un salto proxy.
+
+Una suscripción de notificación habilitada y un renderizador capaz de dibujar la fila solo establecen que existe la ruta de recepción. No prueban que el motor emitió un evento para el giro afectado. Del mismo modo, los detalles del proveedor colapsados pueden explicar el texto de detalle faltante, pero no una fila de reconexión faltante por sí mismos.
+
+El correspondiente app-server [`ErrorNotification`](https://github.com/openai/codex/blob/rust-v0.158.0-alpha.2.1/codex-rs/app-server-protocol/schema/typescript/v2/ErrorNotification.ts) contiene `willRetry`, `threadId` y `turnId`. Observe la emisión, la entrega al giro correspondiente y la representación por separado. Un marco proxy `response.failed` no es en sí mismo esa notificación de servidor de aplicaciones. El cambio de esta política de notificación por primera vez en el lado del motor requiere un cambio Codex; una reescritura de mensaje de error OpenCodex no puede forzar un evento a través de una rama que no lo emite.
+
+<a id="read-only-verification"></a>
+
+## Verificación de solo lectura
+
+Mantenga la aplicación existente, el proxy, la configuración y la prueba sin cambios mientras recopila evidencia. Reiniciar, enviar un nuevo turno o cambiar de transporte cambia el experimento. En un seguimiento aislado, compare el mismo fallo controlado en ambos estados internos WebSocket e inspeccione los reintentos primero y posteriores; no llame a eso una prueba de renderización de escritorio real a menos que se observe la interfaz de usuario.
+
+Para la conversación afectada y el turno activo, distinga estos resultados:
+
+| Pregunta | Evidencia requerida |
+| --- | --- |
+| ¿Se ha proporcionado asesoramiento útil? | El código del fallo final, el retardo normalizado y el tiempo de finalización de la respuesta. |
+| ¿Ocurrió la retransmisión automática? | Una siguiente solicitud correlacionada después de ese fallo, sin un envío manual. Mida desde el final de la respuesta de fallo hasta el siguiente inicio de la solicitud, no desde el primer inicio de la solicitud. |
+| ¿Se recuperó el proveedor? | Una respuesta exitosa y continuación del trabajo afectado, no simplemente otra solicitud o un giro exitoso no relacionado. |
+| ¿Se emitió y entregó una notificación de reintento? | El evento de error app-server coincidente y su indicador de reintento, no solo la configuración de suscripción. |
+| ¿Era visible el aviso? | Observación del turno de escritorio afectado; las comprobaciones de protocolo o código fuente por sí solas son insuficientes. |
+
+El asesoramiento aproximado del proveedor y la sobrecarga de programación pueden producir una pequeña diferencia de tiempo. Si la retransmisión llega a un error de cierre del socket y un intento posterior recibe un nuevo límite de velocidad, registre la retransmisión como operativa pero la recuperación del proveedor como incompleta. El nuevo retraso del rechazo es una nueva observación, no un temporizador heredado del rechazo anterior. Un giro `inProgress` por sí mismo no prueba ni la recuperación ni la representación correcta. El agotamiento, la cancelación y la recuperación de reinicio de la aplicación deben evaluarse por separado.
+
+Publica solo el alcance de validación y las duraciones y resultados agregados. Mantén los registros sin procesar, los cuerpos de las solicitudes, las credenciales, los datos de cuentas, las rutas privadas y los identificadores de hilo, conversación, solicitud o traza fuera de las solicitudes de extracción (PR) y los informes de diagnóstico.
+
+<a id="regression-test-scope"></a>
+
+## Alcance de la prueba de regresión
+
+`tests/server/retry-delay-hardening.test.ts` comprueba que las indicaciones de espera de 120, 900, 1800, 2460 y 3600 segundos conserven sus valores al formatearse; que la indicación más larga aparezca primero si también hay una más corta; y que una desconexión intermedia sin tiempo de espera no haga que un rechazo posterior herede un retraso antiguo. Son pruebas aisladas del analizador y el formateador. No esperan una hora ni ejercitan la condición interna con la que Codex decide emitir una notificación. Tampoco verifican un reinicio de la aplicación ni demuestran la recuperación frente a un fallo real del proveedor.
diff --git a/docs-site/src/content/docs/es/reference/configuration.md b/docs-site/src/content/docs/es/reference/configuration.md
new file mode 100644
index 00000000000..5dee9f5a555
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/configuration.md
@@ -0,0 +1,101 @@
+---
+title: "Referencia de configuración"
+description: "Dónde guarda opencodex la configuración, cómo aplica las ediciones y dónde consultar cada área."
+---
+
+opencodex almacena su configuración persistente en `$OPENCODEX_HOME/config.json`, normalmente `~/.opencodex/config.json`. En Windows, el valor predeterminado es `%USERPROFILE%\.opencodex\config.json`.
+
+<a id="ways-to-edit-configuration"></a>
+
+## Formas de editar la configuración
+
+Elija el canal de edición que se ajuste a la tarea:
+
+- **Panel de control:** utiliza la interfaz de usuario web para la configuración guiada de proveedor, modelo, agente, acceso y almacenamiento.
+- **CLI:** `ocx init` crea el archivo inicial, mientras que los comandos como `ocx provider`, `ocx models`, `ocx combo`, `ocx agent` y `ocx config` actualizan o inspeccionan sus configuraciones propias.
+- **Archivo:** editar `config.json` directamente para campos sin una interfaz de usuario dedicada o comando CLI. El archivo debe seguir siendo válido JSON.
+
+El panel de control, la administración API y la mutación CLI persisten en el mismo archivo. Prefiera esos canales, o detenga el proxy antes de editar a mano. Un proceso en ejecución mantiene la configuración en la memoria, por lo que un live save posterior puede reescribir ediciones de mano no relacionadas desde su instantánea. Live save combina los campos `claudeCode` editados externamente y los campos vinculantes para el oyente donde esas rutas tienen protección explícita contra conflictos, pero esa protección no cubre todos los subárboles.
+
+Si el archivo no se puede analizar, opencodex lo respalda como `config.json.invalid-<timestamp>`, advierte en la consola y comienza con valores predeterminados. Un archivo que falta también utiliza el valor predeterminado de instalación reciente: un proveedor de reenvío `openai`.
+
+Los comandos locales `ocx config set`, `unset`, `import`, `ocx effort` sin conexión, las altas y bajas de modelos personalizados y las altas, bajas y cambios de proveedor predeterminado rechazan un `config.json` existente inválido o ilegible sin cambiar sus bytes. Ejecuta `ocx config validate` y repara el archivo antes de reintentar. La importación también exige un destino válido y legible si ya existe configuración.
+
+<a id="precedence-and-defaults"></a>
+
+## Precedencia y valores por defecto
+
+<a id="provider-and-model-aliases"></a>
+
+### Proveedor y modelo de alias
+
+Los alias son nombres de solicitud cortos opcionales. Nunca cambian el identificador de modelo nativo enviado aguas arriba, y omitir cada campo de alias conserva el enrutamiento existente exactamente.
+
+```jsonc
+{
+  "providers": {
+    "openrouter": {
+      "alias": "or",
+      "modelAliases": { "anthropic/claude-opus-5": "opus" },
+      "defaultAliases": true
+    }
+  },
+  "defaultModelAliases": false
+}
+```
+
+Los alias coinciden insensiblemente con el caso. Un alias modelo funciona como `or/opus` o, cuando es globalmente único, bare `opus`; un alias ambiguo bare informa a sus candidatos calificados. Los selectores de modelos Codex muestran el alias calificado mientras preservan el identificador de enrutamiento canónico `provider/model`. El valor `defaultAliases` de un proveedor anula `defaultModelAliases`. Los built-ins se omiten cuando varios modelos en un proveedor coinciden con el mismo patrón.
+
+<a id="native-reasoning-retention"></a>
+
+### Retención del razonamiento nativo
+
+La retención de texto cifrado de razonamiento nativo en los cambios de modelo y cuenta tiene dos configuraciones de aceptación, ambas desactivadas de forma predeterminada. Configurelos en la vista general del panel o consulte [Retención del razonamiento nativo](/es/reference/configuration/server/#native-reasoning-retention) para conocer el alcance exacto y el comportamiento experimental de la cuenta.
+
+<a id="cursor-effort-rows"></a>
+
+### filas de esfuerzo Cursor
+
+`cursorEffortRows` es un booleano opcional y por defecto a `false`. Cuando está habilitada, la lista OpenAI -style `/v1/models` sin procesar agrega `<base-id>--<effort>` selectores para modelos con capacidad de razonamiento que Cursor Private Inference no coincide en su tabla de esfuerzo instalada. La selección de una fila generada enruta el modelo base y aplica el esfuerzo de esa fila; los modelos Cursor ya reconocen que no reciben variantes. El indicador reserva un sufijo `--<declared-effort>` de terminal para selectores generados, excepto cuando el valor completo ya es un identificador de modelo configurado conocido. Cursor puede requerir una actualización o reinicio de la lista de modelos después de que esta configuración cambie.
+
+<a id="fast-rows"></a>
+
+### Filas rápidas
+
+`fastRows` es un booleano opcional cuyo valor predeterminado es `true`. La lista `/v1/models` con formato OpenAI, el descubrimiento de Claude Code y las exportaciones de configuración de clientes —pi, OpenCode, OMP, Hermes, OpenClaw, Kimi, gjc, DSH, MCode, ZCode, Prime, Aside, Raycast, omo, Cline, Kilo y Command Code— añaden un selector `<base-id>--fast` por cada modelo cuya política Fast resuelta sea elegible. Elegir esa fila enruta al modelo base y solicita el nivel de servicio `priority`, el mismo modo Fast que ofrece el selector de Codex App. La fila base sigue disponible: la fila Fast se añade, no la reemplaza.
+
+Establece `"fastRows": false` para ocultar los selectores Fast generados. Un valor mal formado también los desactiva. La página Modelos del dashboard ofrece el mismo ajuste y actualiza las integraciones conectadas cuando es posible. Si un selector externo no cambia después de guardar, actualiza su integración o catálogo. Los clientes usan los metadatos de disponibilidad del proxy al que se conectan; si un proxy antiguo no los proporciona, no se inventan entradas Fast. Codex conserva su control Fast nativo.
+
+El sufijo es `--fast`, con dos guiones, porque un terminal `-fast` ya es un identificador de modelo real para varios proveedores (`grok-4-fast`, `glm-5.3-fast` y las propias variantes rápidas de Cursor), y un solo guion no podría distinguir un producto aparte de un nivel. Un id de modelo configurado exacto siempre gana sobre el sufijo generado, y un id que lleva tanto este marcador como un marcador de esfuerzo no resuelve ninguno.
+
+Una fila aparece solo donde el nivel realmente puede ser honrado: un modelo cuyo proveedor no lo soporta, o lo soporta en un cable que la ruta no puede usar, no obtiene ninguna fila. `fastMode: false` todavía suprime Fast globalmente y tiene prioridad sobre una fila seleccionada, y un selector cuyo modelo más tarde pierde elegibilidad se degrada a una solicitud ordinaria en lugar de fallar.
+
+Los modelos nativos tienen una condición adicional: así como una política elegible, el nivel de upstream debe anunciar el nivel rápido para ese modelo. Esta es la misma evidencia de la palanca del propio selector Codex se construye a partir de, por lo que las dos superficies no pueden estar en desacuerdo sobre qué nativos tienen rápido.
+
+Alcance: esto cubre las superficies de servicio de solicitudes: `/v1/models`, Claude Code descubrimiento y los puntos finales `/v1/responses`, `/v1/chat/completions`, `/v1/messages`, `/v1/messages/count_tokens` y `/v1/responses/compact`, más `ocx export`, integraciones de clientes administrados y el lanzador OpenCode. Después de deshabilitar las filas rápidas, actualice las configuraciones de cliente guardadas y seleccione un modelo base en lugar de un selector rápido guardado anteriormente.
+
+Los valores válidos en `config.json` anulan los valores predeterminados incorporados. Los campos opcionales que faltan utilizan los valores predeterminados documentados en las páginas de dominio. `OPENCODEX_HOME` tiene prioridad sobre el directorio de configuración predeterminado. Los campos que aceptan una referencia de entorno, como `apiKey: "${PROVIDER_API_KEY}"`, resuelven esa variable en el momento de la solicitud. Para el proxy saliente, un `HTTP_PROXY` o `HTTPS_PROXY` ya establecido tiene prioridad sobre el campo `proxy` de nivel superior.
+
+El enrutamiento tiene sus propias reglas de resolución ordenadas; ver [Enrutamiento](/es/reference/configuration/routing/).
+
+<a id="configuration-domains"></a>
+
+## Dominios de configuración
+
+- [Proveedores](/es/reference/configuration/providers/) - entradas de proveedores, autenticación, endpoints, catálogos, listas de permisos, límites de contexto, cuotas y opciones específicas de proveedores.
+- [Enrutamiento](/es/reference/configuration/routing/) - `defaultProvider`, orden de resolución del modelo, combos, alias y valores predeterminados de esfuerzo combinado.
+- [Agentes](/es/reference/configuration/agents/) - modo multiagente, guía de delegación, modelos de reserva, sincronización por defecto nativo y límites de esfuerzo.
+- [Servidor y entorno de ejecución](/es/reference/configuration/server/) - oyente y acceso remoto, claves de admisión, tiempos de espera, almacenamiento, sidecars, comportamiento de inicio y llamadas de sombra.
+
+<a id="keep-secrets-out-of-the-file"></a>
+
+## Mantener los secretos fuera del archivo
+
+Prefiere referencias `${ENV_VAR}` para las claves API. Los valores literales de `apiKey`, `apiKeyPool[].key` y `apiKeys[].key` son secretos: no los incluyas en commits, registros ni informes compartidos. Los tokens OAuth y los de autenticación por reenvío se guardan en almacenes de credenciales separados de `config.json`. Los identificadores de cuenta y correos también deben mantenerse privados; usa alias públicos de selector cuando estén admitidos.
+
+:::note[Escrituras atómicas]
+opencodex escribe los archivos administrados `config.toml` y `opencodex-catalog.json` en un archivo temporal y después lo renombra de forma atómica mediante `atomicWriteFile`. Esto evita archivos parciales cuando varios procesos, como `ocx stop` y el controlador de apagado del proxy, restauran Codex a la vez. Si un TOML administrado contiene un entero fuera del rango seguro de JavaScript, se rechaza la reescritura y se conserva el archivo original sin redondear su valor.
+:::
+
+
+En Windows, si el atributo de solo lectura de `opencodex-catalog.json` impide renombrarlo, opencodex elimina ese atributo y reintenta una vez. Si aún falla, informa `Codex catalog is read-only: <path>` en vez de un `EPERM` genérico.
diff --git a/docs-site/src/content/docs/es/reference/configuration/advisor.md b/docs-site/src/content/docs/es/reference/configuration/advisor.md
new file mode 100644
index 00000000000..e472013848b
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/configuration/advisor.md
@@ -0,0 +1,139 @@
+---
+title: "Advisor"
+description: "Consulta independiente a un modelo experto, con políticas manuales, previas a la tarea o adaptativas basadas en evidencia."
+---
+
+El asesor es un modelo experto independiente que revisa la tarea del modelo principal y devuelve recomendaciones. OpenCodex controla toda la consulta: el proxy incorpora una herramienta sintética `advisor` al turno, la ejecuta mediante el enrutamiento habitual y entrega las recomendaciones al modelo principal para que continúe. Este no delega, no crea subagentes ni maneja credenciales del proveedor para consultar al asesor.
+
+Es distinto de los [subagentes](/es/reference/configuration/agents/), que el modelo principal inicia mediante las herramientas de colaboración de Codex. El asesor es un sidecar del proxy que el cliente no ve como herramienta; también puede asesorar a un modelo que nunca cree subagentes.
+
+<a id="question-only-mode"></a>
+
+## Modo de solo pregunta
+
+Para reducir entradas repetidas, selecciona **Enviar solo la pregunta del agente** en Advisor o ejecuta:
+
+```sh
+ocx advisor set --context-mode question-only
+```
+
+Esta opción envía únicamente una instrucción fija y la pregunta, hasta 2.000 caracteres conservados más el aviso de truncamiento. No adjunta tarea, historial, resultados o catálogo de herramientas, identidad del agente ni evidencias de reparación. La pregunta debe contener el contexto esencial. Una pregunta vacía se rechaza sin consultar al proveedor. Suspende consultas automáticas preventivas y de reparación adaptativa; conserva llamadas manuales, consentimiento y límites. El modo predeterminado `context` mantiene el contexto descrito más abajo; vuelve con `--context-mode context`.
+
+<a id="configuration"></a>
+
+## Configuración
+
+En **Advisor**, bajo **Subagentes** en la barra lateral del dashboard, elige el modelo experto desde el catálogo. Se guarda el identificador exacto: nativo, de proveedor, de cuenta concreta, personalizado o de combo. Los modelos deshabilitados o pendientes de su selección inicial no se ofrecen como nuevas opciones. Si una selección guardada desaparece del catálogo, permanece visible con una advertencia hasta que la cambies o la borres. Un error al cargar el catálogo conserva la selección y permite reintentar. Elige un modelo que pueda devolver recomendaciones de texto: aparecer en el catálogo no garantiza compatibilidad con esta consulta. La CLI y la API siguen aceptando las cadenas de modelo admitidas por el router.
+
+```json
+{
+  "advisor": {
+    "enabled": true,
+    "model": "gpt-6-astra",
+    "effort": "max",
+    "policy": "preflight",
+    "contextSharingConsent": "v1"
+  }
+}
+```
+
+| Campo | Tipo | Predeterminado | Significado |
+| --- | --- | --- | --- |
+| `enabled?` | `boolean` | `false` | Interruptor principal. Deshabilitado no añade comportamiento del asesor a las solicitudes. Habilitarlo no registra consentimiento. |
+| `model?` | `string` | — | Modelo experto. Admite un modelo nativo sin prefijo (`gpt-6-astra`), un `provider/model` explícito (`anthropic/claude-sonnet-4-6`, `xai/grok-...`) o un modelo nativo de una cuenta concreta. El asesor y el modelo principal pueden usar proveedores distintos. |
+| `effort?` | `string` | `"max"` | Esfuerzo de razonamiento de la consulta (`low` a `ultra`). |
+| `policy?` | `"manual" \| "preflight" \| "adaptive"` | `"manual"` | Cuándo se consulta al asesor. |
+| `contextMode?` | `"context" \| "question-only"` | `"context"` | Intercambio de contexto. `question-only` exige una pregunta explícita del agente y suspende consultas automáticas. |
+| `maxConsultationsPerTask?` | `integer` | `3` | Límite de intentos por tarea adaptativa, de 1 a 3, incluidas las consultas manuales. |
+| `timeoutMs?` | `number` | `120000` | Plazo de la consulta mediante loopback. |
+| `contextSharingConsent?` | `"v1"` | Ausente | Consentimiento del operador para enviar el contexto al proveedor del asesor. Solo `"v1"` es vigente. Un valor ausente, obsoleto o diferente impide enviar el contexto. |
+
+Puedes administrarlo en **Advisor** —la casilla para compartir contexto empieza desmarcada— o con `ocx advisor status`, `ocx advisor on --ack-context-sharing`, `ocx advisor consent`, `ocx advisor consent --revoke`, `ocx advisor off` y `ocx advisor set --model <model> --effort <effort> --policy <manual|preflight|adaptive>`. Si falta consentimiento, `ocx advisor on` sin `--ack-context-sharing` muestra la explicación y se detiene sin habilitar el intercambio entre proveedores. `ocx advisor set` no concede consentimiento.
+
+<a id="policies"></a>
+
+## Políticas
+
+- **`manual`**: solo se consulta cuando el modelo principal llama explícitamente a la herramienta sintética `advisor`. El proxy intercepta la llamada; el cliente no la ve y no se ejecuta como herramienta local.
+- **`preflight`**: OpenCodex intenta además una consulta automática por tarea. Después de la primera señal de orientación —una llamada a herramienta del asistente o un resultado de herramienta posterior al último mensaje del usuario—, consulta al asesor antes del siguiente turno del modelo principal. No requiere que este llame a la herramienta. El disparador es una aproximación determinista, no una detección semántica de que el modelo esté atascado. Si la consulta falla, la tarea continúa y el fallo no se trata como una recomendación válida. Se puede volver a consultar cuando caduque la entrada de fallo en el registro de deduplicación; así, una interrupción temporal no desactiva permanentemente la política.
+- **`adaptive`**: añade consultas tras una reparación fallida al intento inicial de `preflight`. Debe observar una validación que termine con error, una edición de archivo posterior que tenga éxito y una nueva ejecución del **mismo comando en el mismo directorio de trabajo** que vuelva a fallar. Una validación exitosa borra el estado de fallo. Una comprobación iniciada antes de la edición no cuenta como reintento posterior. Los intentos iniciales y los de reparación tienen registros de deduplicación separados. Solo los clientes con identidad de conversación estable reciben consultas adaptativas automáticas.
+
+<a id="adaptive-budget-and-evidence"></a>
+
+### Presupuesto y evidencia adaptativa
+
+```sh
+ocx advisor set --policy adaptive --max-consultations 2
+ocx advisor activity --json
+```
+
+El presupuesto cuenta **intentos** manuales y automáticos a través de distintas solicitudes y cambios del modelo principal. El servidor reserva cada intento antes de enviarlo, en el archivo privado `advisor-budget.sqlite` de `OPENCODEX_HOME`; reiniciar el proxy no restablece ese presupuesto. Un resumen criptográfico de la identidad de conversación y del último límite de tarea del usuario identifica la tarea. Las reservas caducan 24 horas después del primer intento: es una aproximación acotada de la duración de una tarea, no un presupuesto monetario diario ni una sesión permanente. Solo se guardan resúmenes, recuentos y vencimientos. Hay capacidad para 512 tareas activas; si el presupuesto está lleno, bloqueado o no disponible, se omite la consulta y el modelo principal continúa. Una consulta enviada que falla o pierde la conexión conserva su reserva porque pudo generar consumo. Revocar el consentimiento antes del envío no consume el presupuesto. Sin una identidad estable se conserva el acceso manual limitado a cada solicitud, pero no se realizan consultas adaptativas automáticas. Las políticas `manual` y `preflight` conservan su deduplicación anterior por tarea.
+
+El recolector reconoce llamadas de shell emparejadas con un código de salida numérico explícito: `exec_command`, `shell_command`, `shell`, `Bash` y sondeos finales de `write_stdin`. Admite comandos habituales de Bun/npm/pnpm/yarn para test, typecheck, lint, check y build, además de `pytest`, `python -m pytest`, `tsc`, `eslint`, `cargo test/check/clippy/build` y `go test/vet`. Reconoce ediciones exitosas mediante `apply_patch`, `Write`, `Edit`, `write_file` o `edit_file`. También reconoce llamadas individuales a helpers de Code Mode con argumentos JSON literales; las claves pueden ir sin comillas. No usa como disparadores JavaScript arbitrario, lotes, tuberías o sustituciones de shell, ediciones mediante shell, salidas ambiguas ni texto de error sin evidencia estructurada. Examina como máximo los últimos 512 mensajes desde la última tarea del usuario. Antes de la transcripción general, el contexto de reparación incluye la validación, extractos limitados del primer fallo y de su repetición, y referencias a los mensajes originales.
+
+<a id="consent"></a>
+
+## Consentimiento
+
+No se envía el contexto hasta que el operador registra el consentimiento `v1` para compartirlo. Una divulgación futura de mayor alcance podría exigir `v2` en vez de reutilizar el consentimiento anterior. El entorno de ejecución comprueba esta condición: un valor ausente u obsoleto impide ejecutar el asesor (`advisor_context_sharing_consent_required`) sin hacer fallar la solicitud de programación. Ningún modelo ni texto de la tarea puede otorgar ese consentimiento.
+
+<a id="what-the-advisor-sees"></a>
+
+## Qué ve el asesor
+
+Una consulta puede enviar:
+
+- La última tarea del usuario.
+- Texto del usuario, del asistente y del desarrollador visible en la conversación analizada.
+- Llamadas a herramientas y sus argumentos.
+- Resultados de herramientas.
+- El catálogo de herramientas del modelo principal y sus descripciones.
+- La identidad del modelo principal y el modelo del asesor configurado.
+- Una pregunta específica opcional cuando el modelo principal llama a `advisor()`.
+
+El proveedor del asesor puede ser distinto del proveedor del modelo principal.
+
+Las consultas respetan el ámbito de modelos capturado para la clave API del solicitante, su consentimiento para combos de pago y los límites de fallback del dispositivo. También respetan los límites del host definidos por la clave de admisión del propio Advisor: `OPENCODEX_API_AUTH_TOKEN` o el archivo de token del servicio, cuando estén configurados y este proxy los acepte; en caso contrario, la primera clave API configurada. Solo en ese último caso importa el orden: la primera clave debe poder acceder al modelo del asesor, o todas las consultas quedarán no disponibles. Si se configura un token de entorno o de servicio, ese token controla la consulta. Las mismas reglas se aplican a los combos, los modelos de decisión anidados y los reintentos. Si no se pueden cumplir, el modelo principal recibe un aviso de que la consulta no está disponible.
+
+Por ejemplo, una clave `laptop` con `allowMeteredComboTargets: false` no puede generar gasto en objetivos medidos de combos mediante Advisor; `fallback.devices.laptop.provider: false` también impide sus saltos de fallback entre proveedores. Un solicitante de loopback sin clave sigue necesitando `allowMeteredTargets: true` en el combo. Si ambas claves tienen `allowMeteredComboTargets: true` y el combo tiene `allowMeteredTargets: true`, Advisor puede usar sus objetivos medidos, incluso desde el listener de loopback de un enlace público. El servidor captura la política del solicitante al autenticar la solicitud, antes de esperar capacidad o leer el cuerpo; las ediciones posteriores de claves o fallback no pueden ampliar los permisos de esa consulta. Esto también abarca los auxiliares de visión enrutada, las solicitudes de compactación y sus modelos de decisión, y cada reintento candidato dentro de un turno WebSocket. Cada turno WebSocket nuevo captura su propia política.
+
+OpenCodex no añade a ese prompt claves API de proveedores, encabezados de autorización, tokens OAuth, secretos internos de configuración, variables del entorno del proceso ni razonamiento interno oculto. Tampoco descifra ni reenvía razonamiento cifrado privado del proveedor. **No se eliminan secretos del contenido de la tarea.** Una clave pegada en ella, un secreto en un archivo leído por una herramienta o un token impreso en su salida puede enviarse. OpenCodex no realiza prevención general de fuga de datos (DLP).
+
+<a id="authority"></a>
+
+## Autoridad
+
+Una consulta manual devuelve un resultado para la llamada `advisor` realizada por el modelo principal. Es un objeto JSON: `advice` contiene el texto del asesor y `status` lo establece el entorno de ejecución.
+
+La consulta automática mantiene la instrucción fija de transporte en un mensaje de desarrollador y coloca el consejo JSON citado en un **mensaje consultivo de rol usuario** separado. El texto generado por el asesor nunca entra en mensajes de desarrollador o sistema, incluso cuando OpenAI Chat traduce las instrucciones de desarrollador al rol sistema. Anthropic puede transportar ese mensaje consultivo sin inventar una llamada a herramienta. El escape JSON impide alterar la estructura o falsificar campos; no garantiza aislamiento frente a inyección de instrucciones. Un protocolo dedicado a resultados de consulta podría distinguir mejor las recomendaciones del texto normal del usuario.
+
+Cada solicitud admite como máximo tres consultas, incluidos los intentos automáticos, y cuatro continuaciones del modelo principal controladas por el asesor. Al agotar las consultas se retira la herramienta `advisor`. Una llamada repetida recibe un último resultado de límite emparejado; si se vuelve a llamar, un error 502 `advisor_continuation_limit` termina la solicitud sin otra llamada oculta al modelo principal. Este límite se comparte con los reintentos por finalización vacía.
+
+Los turnos de búsqueda web basados en `fetch` admiten la misma consulta manual cuando el `tool_choice` efectivo permite la herramienta sintética `advisor`. El bucle solo expone e intercepta `advisor` dentro de ese alcance; una selección `allowed_tools` limitada a `web_search` excluye las consultas manuales al Asesor. Las llamadas permitidas a `web_search` y `advisor` se procesan en el orden del modelo. Sus iteraciones tienen presupuestos independientes y una llamada real a una herramienta del cliente devuelve el control al cliente. Los turnos run-turn y los sidecars de imagen o video conservan sus limitaciones. Si el modelo emite una llamada `advisor` excluida, el turno falla con `undeclared_tool_call` antes de que llegue al cliente. Una herramienta normal del cliente llamada `advisor` solo está disponible mientras la iteración actual la declare y permita; una recuperación con herramientas desactivadas no puede reutilizar una declaración anterior.
+
+La supresión de consultas no depende de textos del asesor: la deduplicación automática usa el registro del servidor. Un mensaje de desarrollador, aunque copie el texto de transporte, no suprime la consulta `preflight`.
+
+<a id="cost-and-accounting"></a>
+
+## Costos y registro de actividad
+
+Cada consulta es una llamada real adicional al modelo. Se registra bajo el **modelo asesor**, separada de los tokens del modelo principal. Cada una genera una línea `[advisor]` con disparador, duración, estado y consumo, de modo que puede comprobarse en los registros.
+
+**Actividad reciente del asesor** y `GET /api/advisor/activity` muestran los últimos 100 registros de metadatos de este proceso, conservados hasta 24 horas. El dashboard los actualiza cada cinco segundos mientras están visibles. Incluyen disparador, estado, modelos principal y experto, duración, tokens de entrada y salida informados, esfuerzo solicitado y esfuerzo convertido por el adaptador. Un rechazo por presupuesto aparece como bloqueado. No contienen texto de tareas, comandos, recomendaciones, identificadores de hilos ni cuerpos de error del proveedor. Se borran al reiniciar el proxy.
+
+El esfuerzo convertido describe lo que serializó el adaptador; no garantiza el razonamiento interno del proveedor. Un esfuerzo o consumo no informado queda como desconocido, no como consumo cero ni compatibilidad confirmada. No se infiere una puntuación de adopción de recomendaciones ni un costo monetario exacto.
+
+<a id="failure-behavior"></a>
+
+## Comportamiento ante fallos
+
+Un fallo del asesor permite que la tarea continúe. Si una consulta ya enviada falla por modelo no disponible, proveedor mal configurado o plazo agotado, el modelo principal recibe un aviso breve de indisponibilidad: `<opencodex_advisor_unavailable>` para `preflight` o un resultado de herramienta con error para una consulta manual. Solo una consulta cancelada no añade ningún mensaje, porque quien la solicitó ya se desconectó. Si nunca se envió una consulta —asesor deshabilitado, sin modelo o sin consentimiento vigente—, no se añade un aviso `preflight`. Una llamada manual a `advisor()` sin consentimiento devuelve un resultado que lo solicita y no envía contexto. Estos fallos no hacen fallar la solicitud de programación ni cambian el modelo principal de la sesión.
+
+<a id="limitations"></a>
+
+## Limitaciones
+
+- Los turnos nativos OpenAI passthrough —modelos del pool ChatGPT— no reciben la herramienta sintética. El asesor cubre proveedores enrutados mediante traducción. La consulta `preflight` se aplica a los adaptadores de ejecución de turnos; la herramienta no.
+- Las solicitudes traducidas de `/v1/messages` (por ejemplo, Claude Code enrutado a un proveedor traducido) reciben la herramienta sintética y la consulta preflight igual que `/v1/responses` y `/v1/chat/completions`. Se aplican las mismas reglas de `policy` y consentimiento para compartir contexto, y los ajustes se leen de la configuración vigente. Por ello, revocar el consentimiento bloquea las consultas de solicitudes ya en curso que aún no se hayan enviado. No cancela una consulta ya enviada ni retira el contexto que ya salió del proxy.
+- No hay detección semántica de bloqueo, revisión de finalización, escalada de niveles, varios asesores ni votación. La consulta adaptativa exige la evidencia estructurada de validación, edición y reintento descrita arriba.
+- El registro de deduplicación `preflight` pertenece al proceso. Tras reiniciar el proxy, una tarea en curso puede recibir un intento adicional.
diff --git a/docs-site/src/content/docs/es/reference/configuration/agents.md b/docs-site/src/content/docs/es/reference/configuration/agents.md
new file mode 100644
index 00000000000..197256c61ed
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/configuration/agents.md
@@ -0,0 +1,218 @@
+---
+title: "Configuración de agentes"
+description: "Modos multiagente, guía de delegación, modelos preferidos, cadenas de respaldo, sincronización de valores nativos y límites de esfuerzo."
+---
+
+La configuración de agentes determina qué interfaz de colaboración de Codex se anuncia y cómo opencodex orienta, enruta y limita el trabajo delegado.
+
+<a id="agent-fields"></a>
+
+## Campos de agentes
+
+<a id="skills-catalog-refresh"></a>
+
+### Actualización del catálogo de habilidades
+
+`skills.catalog_refresh` acepta `"per_session"` (predeterminado) o `"per_turn"` en el archivo `config.json` de opencodex. El modo por sesión reutiliza las primeras instrucciones de habilidades recibidas para la conversación, de modo que los cambios del catálogo entre turnos no alteren el prefijo de la caché del prompt. El modo por turno reenvía el catálogo actual del cliente. Consulta [Mantener estable el catálogo de habilidades](/es/guides/codex-prompt/#keeping-the-skills-catalog-stable) para conocer la configuración y la duración de las instantáneas.
+
+<a id="astra-roster-upgrade"></a>
+
+### Actualización de la lista de Astra
+
+En el primer inicio después de actualizar, las listas existentes de `subagentModels` reciben `gpt-6-astra` en primer lugar. Se conservan las primeras cuatro opciones únicas distintas de Astra y se descarta la quinta opción anterior. Si se conserva `gpt-5.5`, pasa al final. Por tanto, la antigua lista predeterminada queda como Astra, Sol, Terra, Luna y 5.5. Una lista antigua sin configurar recibe los valores predeterminados actuales; una lista antigua explícitamente vacía pasa a ser `["gpt-6-astra"]`. Las entradas de Astra existentes no se duplican.
+
+La lista predeterminada actual es `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6-luna`. En el primer inicio después de actualizar se eliminan las entradas retiradas de las listas guardadas: `gpt-5.6-sol` y `gpt-5.6-luna` pasan a ser `gpt-6-sol` y `gpt-6-luna` en su misma posición, y se elimina cualquier otro modelo `gpt-5.5` o `gpt-5.6`. Los identificadores con `/` (rutas `provider/model` u opciones que especifican una cuenta) se conservan tal como están escritos. Una lista que solo contenía modelos retirados recibe la lista predeterminada actual; una lista vacía permanece vacía.
+
+GPT-6.1 Sol sustituyó a GPT-6 Sol como modelo predeterminado el 30 de septiembre de 2026. En el primer inicio tras esa actualización, un `gpt-6-sol` sin prefijo en una lista guardada pasa a ser `gpt-6.1-sol` en la misma posición, sin duplicarlo si 6.1 Sol ya figura en ella. GPT-6 Sol sigue disponible: puedes volver a añadirlo después y se conservará.
+
+El marcador interno `subagentModelsVersion` (actualmente `3`) hace que cada migración se ejecute una sola vez. Después puedes reordenar la lista, quitar Astra o guardar una lista vacía sin que el inicio vuelva a cambiar tus opciones. Los modelos desactivados permanecen desactivados. La disponibilidad de Astra sigue dependiendo de la compatibilidad del proveedor con tu cuenta.
+
+| Campo | Tipo | Predeterminado | Significado |
+| --- | --- | --- | --- |
+| `multiAgentMode?` | `"v1" \| "default" \| "v2"` | `"default"` | `v1` marca todos los modelos del catálogo como v1; `v2` los marca como v2. `default` restaura las asignaciones del proveedor (Sol/Terra v2, Luna v1) y, en los demás casos, sigue la opción nativa `multi_agent_v2`. Se aplica a las sesiones nuevas. |
+| `keepNativeChatGptOnV1?` | `boolean` | `false` | Cuando `multiAgentMode` es `"v2"`, desactiva la anulación global de V2, marca las entradas nativas de ChatGPT como v1 y conserva las enrutadas en v2. Codex resuelve la anulación global antes que las asignaciones del catálogo: ambas partes son necesarias para que un agente principal de ChatGPT cree subagentes enrutados sin tareas cifradas por el backend ([#92](https://github.com/lidge-jun/opencodex/issues/92)). Se ignora en `v1` y `default`. |
+| `subagentModels?` | `string[]` | `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6-luna` | Hasta cinco identificadores nativos sin prefijo, con cuenta `<selector>/<native-openai-model>` o enrutados `provider/model` que aparecen primero en el selector de subagentes. El panel ofrece identificadores nativos sin prefijo y enrutados para nuevas selecciones; al guardar conserva los identificadores exactos de cuenta ya configurados, aunque no estén disponibles en el catálogo actual. Para añadir un identificador exacto de cuenta nuevo, usa `ocx agent subagents set` o edita la configuración. Tras la [migración única de Astra](#astra-roster-upgrade), se conserva una lista explícitamente vacía. |
+| `injectionModel?` | `string` | — | Modelo de subagente nativo o enrutado preferido que se menciona en la guía de delegación v2 redactada por el proxy. |
+| `injectionEffort?` | `string` | — | Esfuerzo preferido (de `low` a `ultra`); solo tiene efecto junto con `injectionModel`. |
+| `injectionPrompt?` | `string` | — | Sustituye el cuerpo de la guía v2 integrada. Admite `{{model}}`, `{{effort}}`, `{{roster}}` y `{{fallback}}`. Basta con configurar `injectionModel` para generar el prompt personalizado. |
+| `multiAgentGuidanceEnabled?` | `boolean` | `true` | Solo controla la guía de desarrollador v1/v2 redactada por opencodex; no cambia los valores nativos de agentes, las herramientas, el enrutamiento, las listas ni los límites de esfuerzo. |
+| `syncCodexSubagentDefaults?` | `boolean` | `false` | Permite escribir `injectionModel` y el `injectionEffort` opcional como valores nativos de Codex al sincronizar o reiniciar. Requiere `injectionModel`. |
+| `subagentModelFallback?` | `string[]` | `[]` | Modelos globales de respaldo, en orden de prioridad, para los turnos de subagentes creados. |
+| `subagentModelFallbackByModel?` | `Record<string, string[]>` | `{}` | Cadenas de respaldo por modelo principal, indexadas por su identificador solicitado. Esta es la ubicación admitida para los metadatos de respaldo por rol; incluir `model_fallback` en el TOML de un agente hace que Codex 0.146+ omita ese rol (#1190). |
+| `subagentModelFallbackPollMs?` | `number` | `60000` | Duración de la caché de comprobaciones de disponibilidad. Los valores inferiores a 1000 ms usan el predeterminado. |
+| `codexRoleTiers?` | `{ fast?, standard?, frontier?: string[] }` | — | Nivel de capacidad de los modelos indicados para la [asignación automática de roles](/es/guides/integrations/#auto-assign). Esos modelos reciben el nivel indicado. Los demás se clasifican por la puntuación medida en el dominio del rol cuando al menos dos tienen una, sin exigir precio; puntuaciones iguales comparten nivel. Si se recurre al precio, se excluyen los modelos sin precio ni nivel configurado. |
+| `codexRoleCapability?` | `{ artificialAnalysis?: { apiKey?: string } }` | Sin fuente medida | Fuente de puntuaciones para la [asignación automática de roles](/es/guides/integrations/#auto-assign). Artificial Analysis usa tu clave API (literal, `${ENV}` o referencia del llavero) una vez al día para leer su lista gratuita de modelos; todos los dominios usan su Intelligence Index. Las puntuaciones no se incluyen en la respuesta. Si faltan datos o no están disponibles, se usan los niveles y precios configurados. La clave retirada `huggingFace` se ignora. |
+| `effortCap?` | `string` | — | Límite máximo para los turnos principales v2 que cumplan los requisitos y para los turnos de subagentes que lleven los marcadores correspondientes. Admite de `low` a `ultra`. |
+| `subagentEffortCap?` | `string` | — | Límite adicional solo para turnos de subagentes creados. Cuando se aplican ambos límites, prevalece el menor. |
+| `plaintextV2AgentMessages?` | `boolean` | — (sin configurar) | Opción experimental que solo se ejecuta al establecerla explícitamente en `true`. Pide a los agentes principales v2 nativos de ChatGPT que cumplan los requisitos emitir en texto sin cifrar los argumentos de mensaje de `spawn_agent`, `send_message` y `followup_task`. Consulta [Mensajes de agentes v2 en texto sin cifrar](#plaintext-v2-agent-messages). |
+| `agentTaskRecovery?` | `object` | — | Recuperación experimental de tareas v2 cifradas por el backend que se envían a proveedores enrutados. Está desactivada salvo que se indique `enabled: true`; consulta [Recuperación de tareas v2 cifradas](#encrypted-v2-task-recovery). |
+
+Configura el modo desde el panel o con `ocx v2 status|on|off|mode <v1|default|v2>|keep-native-v1 <on|off>|threads <n>|mode-hint <text|--clear>`. Los cambios de modo se aplican a sesiones nuevas. `maxConcurrentThreadsPerSession` es un campo de `PUT /api/v2`, no una clave de `config.json`; después de activar v2, `ocx v2 threads <n>` escribe `max_concurrent_threads_per_session` dentro de `[features.multi_agent_v2]` en el archivo `$CODEX_HOME/config.toml` de Codex.
+
+El límite de subagentes de la página Modelos cuenta agentes secundarios. Un total V2 guardado de 1 solo permite el agente raíz y muestra 0 secundarios; configurar un secundario guarda un total V2 de 2. Los límites nuevos deben permitir al menos un secundario. Tanto esa cantidad como su conversión para la API deben ser enteros seguros, como máximo 9.007.199.254.740.991. Si V2 global está desactivado, incluido el modo híbrido, no se añade una posición para el agente raíz. La API rechaza límites inseguros con HTTP 400 antes de cambiar la función o la configuración.
+
+**Delegación siempre proactiva**, en Subagentes → Avanzado (antes **Modo Ultra**), cambia el criterio para delegar sin cambiar el esfuerzo de razonamiento. Su configuración predefinida conserva las instrucciones del usuario, los límites de autoridad, el alcance de la tarea y las reglas de las herramientas. El interruptor del panel, el campo `multiAgentModeHintText` de `PUT /api/v2` y `ocx v2 mode-hint` escriben `features.multi_agent_v2.multi_agent_mode_hint_text` en el archivo `$CODEX_HOME/config.toml` de Codex. El comando `ocx v2 mode-hint` guarda esta clave incluso cuando `multi_agent_v2` está desactivado; no activa la función. Cuando la interfaz nativa está activa, esta indicación sustituye la política multiagente que codex-rs deriva del esfuerzo. Un valor `null` elimina la clave y restaura la política derivada del esfuerzo (ultra = proactiva; los demás niveles = explícita). Se rechazan los valores vacíos o compuestos solo por espacios, porque una anulación vacía suprimiría incluso el mensaje proactivo derivado de ultra. El interruptor **Delegación siempre proactiva** del panel de Subagentes requiere tanto la función nativa como un modo v2 explícito (`multiAgentMode: "v2"`, equivalente a `ocx v2 mode v2`); `ocx v2 on` por sí solo no cumple ese requisito.
+
+`GET` y `PUT /api/v2` también devuelven `multiAgentModeHintRecommendation: { text, revision }`. El panel usa ese texto del servidor al activar o restaurar la configuración predefinida, sin un texto alternativo fijo. Si un servidor anterior omite la recomendación o devuelve un valor mal formado, no se puede instalar ni restaurar la configuración predefinida; sigue siendo posible editar o borrar una indicación personalizada existente. **Restaurar configuración predefinida** solo cambia el borrador local; **Guardar** lo conserva.
+
+Leer la configuración, actualizar campos ajenos o cambiar de versión no migra una indicación guardada. Solo una actualización explícita cuyo texto coincida byte por byte con uno de los dos preajustes antiguos reconocidos de OpenCodex se sustituye por la recomendación actual. Los demás textos personalizados válidos, incluidas las variantes de espacios, se conservan byte por byte. Antes de escribir se sigue comprobando la compatibilidad con esta función, y los cambios se aplican a sesiones nuevas de Codex.
+
+La API de administración expone `GET`/`PUT /api/v2`, `/api/injection-model`, `/api/effort-caps`, `/api/subagent-models` y `/api/subagent-model-fallback`. Las actualizaciones del modelo de inyección son parciales; en esa API el prompt personalizado corresponde al campo `prompt`.
+
+La página de autenticación de Codex también permite cambiar la opción nativa `default_mode_request_user_input` (`GET`/`PUT /api/codex-auth/features/default-mode-request-user-input`). Al activarla se añade `[features] default_mode_request_user_input = true` al archivo `$CODEX_HOME/config.toml` de Codex mediante el comando oficial `codex features enable|disable`, con una edición que conserva el formato y se elimina al desactivar la opción. Esto permite que Codex pause una sesión en modo Default para preguntar con `request_user_input`. La función está en desarrollo en el proyecto original y solo afecta a sesiones nuevas; si la compilación instalada todavía no la reconoce, el interruptor muestra un error explícito.
+
+Mientras una actualización de Codex CLI controle la instalación, este interruptor devuelve HTTP 503 reintentable (`codex_cli_selection_busy`) antes de ejecutar el comando de funciones. Reintenta cuando termine la actualización; los fallos al escribir la configuración siguen devolviendo 502.
+
+<a id="roster-and-guidance"></a>
+
+## Lista de modelos y guía
+
+La lista v2 efectiva comprende los primeros cinco modelos configurados, visibles en el selector y ordenados por prioridad que estén presentes en el catálogo inyectado y no estén marcados explícitamente como `"disabled"`. Una asignación `"v2"` explícita permite subagentes recursivos; `"v1"`, `null` o la ausencia de asignación siguen permitiendo subagentes sin delegación adicional. Las entradas excluidas permanecen en la configuración para poder cumplir los requisitos más adelante.
+
+El modo se detecta por la estructura de las herramientas. Un `spawn_agent` dentro de un espacio de nombres, junto con `send_input`, `resume_agent` o `close_agent`, indica v1. Un `spawn_agent` plano, junto con `send_message`, `followup_task`, `interrupt_agent` o `list_agents`, indica v2.
+
+La guía v1 solo usa texto proactivo en `max` o `ultra`. V2 recibe un mensaje de desarrollador del proxy únicamente cuando existe un modelo preferido, una lista de modelos aptos o una cadena de respaldo. La guía v2 integrada tiene un presupuesto de 700 caracteres y, si hace falta, omite primero la lista. Se eliminan duplicados entre los prefijos del historial reproducido y la guía se inserta antes de un `compaction_trigger` final.
+
+Tanto la guía v2 integrada como el cuerpo de `injectionPrompt` usan `<opencodex_subagent_guidance>`, separado de los mensajes nativos `<multi_agent_mode>` de Codex. El texto integrado informa el modelo preferido resuelto, la lista y la cadena de respaldo sin ordenar la delegación ni imponer cambios de modelo o de `fork_turns`. Los cuerpos personalizados conservan su contenido y la sustitución de marcadores. `injectionModel` e `injectionEffort` siguen siendo recomendaciones salvo que se active la sincronización de valores nativos; los marcadores personalizados sin valor se sustituyen por una cadena vacía.
+
+La eliminación de duplicados compara el texto exacto más reciente de cada familia de etiquetas. Cuando ambos valores usan la nueva familia del proxy, volver de una guía personalizada a la integrada añade el valor actual; los cambios intermedios del modo nativo no duplican una guía del proxy que no haya cambiado. Se conserva el historial nativo y el que lleva etiquetas antiguas. Cambiar esta envoltura no identifica al autor de mensajes anteriores ni revoca instrucciones previas. La etiqueta antigua por sí sola no permite clasificar historiales de versiones mixtas y no se garantiza la detección de transiciones en ellos.
+
+<a id="native-codex-default-sync"></a>
+
+## Sincronización de valores nativos de Codex
+
+Al activarse, `syncCodexSubagentDefaults` escribe los campos `[agents] default_subagent_model` y `default_subagent_reasoning_effort` que pertenecen al marcador de opencodex. Los campos de destino sin marcador que pertenecen al usuario se consideran conflictos y siguen teniendo prioridad; las escrituras TOML parciales o ambiguas se rechazan. Borrar `injectionModel` también desactiva esta opción. Estos valores afectan a las tareas nuevas de Codex y no provocan delegación por sí mismos.
+
+<a id="fallback-chain"></a>
+
+## Cadena de respaldo
+
+El orden de respaldo para los turnos de subagentes creados es:
+
+1. El modelo principal solicitado.
+2. Las cadenas por modelo de `subagentModelFallbackByModel`, indexadas por el modelo principal.
+3. Las entradas globales de `subagentModelFallback`.
+
+Las cadenas por rol deben estar en la configuración de opencodex. Escribir `model_fallback` en `$CODEX_HOME/agents/*.toml` hace que Codex 0.146+ rechace todo el archivo por un campo desconocido y omita el rol (#1190). Una línea antigua `model_fallback` todavía se lee por compatibilidad, pero `ocx doctor` la señala.
+
+opencodex omite candidatos desactivados, sin ruta, con problemas de funcionamiento, en espera de recuperación o que hayan alcanzado el umbral de cuota. La instantánea de disponibilidad se conserva durante `subagentModelFallbackPollMs`. Las tareas cifradas limitan la cadena a destinos nativos canónicos de ChatGPT y a rutas directas de Responses con clave que se hayan declarado de confianza mediante `allowEncryptedV2AgentTasks: true`. Si ninguno puede consumir la carga cifrada, la solicitud falla sin enviarla a otro destino que no pueda leerla. El enrutamiento de Combos prueba primero un destino nativo canónico disponible; cuando ninguno es seleccionable o se agotan sus intentos y `agentTaskRecovery` está activado, recupera una vez el `NEW_TASK` cifrado antes de enviarlo al destino enrutado. La recuperación de Combos solo se ejecuta en turnos de subagentes creados; la ruta enrutada directa también recupera tareas al cambiar de modelo en medio de un hilo.
+
+```json
+{
+  "multiAgentMode": "v2",
+  "subagentModels": ["gpt-6.1-sol", "anthropic/claude-sonnet-5"],
+  "injectionModel": "gpt-6.1-sol",
+  "injectionEffort": "high",
+  "syncCodexSubagentDefaults": true,
+  "subagentModelFallback": ["gpt-6-luna"],
+  "subagentModelFallbackByModel": {
+    "gpt-6.1-sol": ["gpt-6-luna"]
+  },
+  "subagentModelFallbackPollMs": 60000,
+  "subagentEffortCap": "high"
+}
+```
+
+<a id="plaintext-v2-agent-messages"></a>
+
+## Mensajes de agentes v2 en texto sin cifrar
+
+`plaintextV2AgentMessages` no está configurado en una instalación nueva y solo se ejecuta al establecerlo explícitamente en `true`. El cliente debe usar el protocolo Responses y el destino final debe usar el transporte canónico de reenvío de ChatGPT Codex: `adapter: "openai-responses"`, `authMode: "forward"` y la URL base exacta `https://chatgpt.com/backend-api/codex`. Nunca se reescriben los proveedores de OpenAI con clave API, las pasarelas personalizadas compatibles con OpenAI, las rutas cuyo destino final sea otro proveedor ni las solicitudes que no usen Responses.
+
+Para una solicitud v2 apta, opencodex reconoce el catálogo por un espacio de nombres `collaboration` de nivel superior con un hijo directo `spawn_agent`. El catálogo puede estar en `tools` de nivel superior o, cuando no existe `tools`, en `additional_tools` del primer elemento de entrada de desarrollador (Responses Lite). El catálogo explícito de nivel superior tiene prioridad; los catálogos de rol de usuario y los posteriores del historial no activan la opción. Se elimina `parameters.properties.message.encrypted: true`, si existe, únicamente de `spawn_agent`, `send_message` y `followup_task`. ChatGPT reserva tanto `collaboration` como esos tres nombres de herramientas, por lo que la solicitud usa alias privados fijos para las cuatro identidades. Antes del cambio, opencodex comprueba los catálogos de nivel superior y de `additional_tools`, los espacios de nombres anidados, las declaraciones `tool_search_output`, `tool_choice` y las llamadas anteriores para detectar conflictos con los alias o el espacio de nombres privado. Ante cualquier conflicto, toda la solicitud se conserva sin cambios. OpenCodex restaura solo los alias correspondientes a esa solicitud en las respuestas JSON, SSE y WebSocket antes de que Codex reciba la llamada. Se conserva `encrypted_function_args: []` para que los clientes compatibles reconozcan el mensaje como texto sin cifrar.
+
+Esta ruta no añade solicitudes de recuperación y, por tanto, no consume la cuota adicional de ChatGPT asociada a una entrada ausente de la caché de `agentTaskRecovery`. No puede cambiar tareas que ya estén cifradas. Si la solicitud ya declara el alias privado o una referencia conflictiva, opencodex la conserva sin cambios; la recuperación activada por separado aún puede atender una tarea enrutada que se cifre después. Si ChatGPT rechaza o ignora el esquema modificado, o si el cliente no reconoce los campos de respuesta de texto sin cifrar, la llamada puede fallar. OpenCodex no reintenta la solicitud principal con el esquema original, porque podría duplicar el consumo de cuota o las llamadas a herramientas.
+
+La restauración recorre un máximo de 10.000 identidades por respuesta. Si se agota ese presupuesto, la respuesta JSON acotada devuelve HTTP 502 y una transmisión devuelve `response.failed`; ninguna ruta envía los alias privados a Codex ni guarda la respuesta rechazada para continuar mediante `previous_response_id`.
+
+En las llamadas reescritas correctamente, la opción elimina el cifrado de aplicación de los argumentos de mensaje de agentes. HTTPS sigue cifrando el transporte de red, pero el texto puede aparecer en el historial de tareas de Codex, las solicitudes al proveedor enrutado, `responses-state.json` o sus archivos auxiliares y, si está activada la captura de depuración, `usage-debug.jsonl`. El comportamiento depende de campos no documentados del esquema y de la respuesta de ChatGPT y puede dejar de funcionar tras actualizar el cliente o el backend. Al iniciar se muestra una advertencia mientras la opción esté activada.
+
+```json
+{
+  "plaintextV2AgentMessages": true
+}
+```
+
+El comando equivalente es `ocx config set plaintextV2AgentMessages true`. Reinicia el proxy después de cambiar la configuración.
+
+<a id="encrypted-v2-task-recovery"></a>
+
+## Recuperación de tareas v2 cifradas
+
+`agentTaskRecovery` es una ruta experimental de compatibilidad para tareas v2 cifradas por el backend que llegan a un proveedor enrutado. Admite dos casos: un agente principal nativo de ChatGPT que crea un subagente v2 enrutado, y un hilo activo que cambia de un modelo nativo de ChatGPT a uno enrutado y reproduce en cada turno posterior un mensaje de agente cifrado por el backend ([#4089](https://github.com/lidge-jun/opencodex/issues/4089)). Está desactivada de forma predeterminada. Al activarla explícitamente, si la tarea final enrutada contiene una carga Fernet ilegible, opencodex hace una solicitud de paso directo de Responses al destino fijo `https://chatgpt.com/backend-api/codex/responses`, con autenticación de reenvío. ChatGPT devuelve la tarea en texto sin cifrar mediante una llamada a función forzada; opencodex convierte únicamente ese elemento en un mensaje de usuario estándar antes de enviarlo al proveedor enrutado. La recuperación directa, la reproducción del historial en caché y el detector de tareas ilegibles reconocen los cuatro tipos de mensajes de agentes de codex-rs: `NEW_TASK`, `MESSAGE`, `FOLLOWUP_TASK` y `FINAL_ANSWER`. La recuperación de Combos sigue limitada a turnos de subagentes creados. La envoltura de `FINAL_ANSWER` puede omitir la línea `Task name`; en ese caso no existe una dirección de cabecera que comparar con el destinatario del elemento y se omite solo esa comprobación. Se mantienen la comparación del remitente y el ámbito de la caché, que sigue incluyendo al destinatario estructurado.
+
+Esto no descifra localmente ni corrige el protocolo de Codex. Depende de comportamiento no documentado del backend de ChatGPT y puede dejar de funcionar si cambia. La tarea recuperada es salida de un modelo, no texto sin cifrar verificado criptográficamente: no se garantiza fidelidad byte por byte. Una entrada ausente de la caché puede añadir una solicitud autenticada a ChatGPT, consumir cuota de la cuenta y aumentar la latencia antes de la solicitud enrutada. Las solicitudes concurrentes para la misma tarea y el mismo ámbito comparten una sola recuperación. Al iniciar se muestra una advertencia mientras la función esté activada.
+
+La admisión y la conservación están limitadas deliberadamente:
+
+- La recuperación solo está disponible mientras el proxy esté vinculado a loopback.
+- Solo se admite un cliente nativo de Codex con un par de token bearer y cuenta de ChatGPT coincidente. Es el tipo de credencial del proveedor canónico `openai` con `authMode: "forward"`. La recuperación usa únicamente el par recibido y nunca lo sustituye por autenticación con clave API, credenciales de otro proveedor ni otra cuenta de Codex.
+- Los clientes que usen `x-opencodex-api-key`, `x-api-key`, credenciales API genéricas o un secreto de acceso al proxy siguen recibiendo `unreadable_encrypted_agent_task`.
+- Las credenciales originales de ChatGPT solo se envían al destino fijo de ChatGPT; nunca se incluyen en el cuerpo, los registros, las claves de caché ni la solicitud al proveedor. El ámbito de la caché en memoria usa un resumen de la credencial y la cuenta del cliente, calculado con una clave aleatoria por proceso.
+- La recuperación solo reenvía `authorization`, el `chatgpt-account-id` coincidente, `originator` y, opcionalmente, `openai-beta` y `user-agent`. opencodex establece `content-type` y `accept`; ningún otro encabezado del cliente cruza ese límite.
+- El texto recuperado nunca se registra ni persiste. La caché del proceso está delimitada por credencial, hilo principal y texto cifrado, caduca a los 15 minutos y tiene dos límites: la cantidad configurada de entradas (200 de forma predeterminada, 512 como máximo) y 8 MiB en total.
+- Una envoltura mal formada, una recuperación fallida, un tiempo de espera agotado o un error de validación conservan el rechazo seguro existente; la cancelación del cliente devuelve 499. Ninguna de esas rutas reenvía el texto cifrado al proveedor enrutado.
+
+La recuperación acepta una secuencia consecutiva de hasta 32 partes cifradas completas con estructura Fernet, con un máximo de 2 MiB de texto cifrado combinado. Las partes conservan su orden y sus límites en una sola solicitud autenticada. La identidad de caché incluye la secuencia; la entrada original vuelve a validarse antes de sustituir la tarea. Los fallos HTTP conservan la razón de diagnóstico acotada existente. No generan reintentos internos salvo que se configure `retries`: con un valor de 1 a 2, opencodex repite la misma solicitud admitida solo ante un estado transitorio del proveedor (500/502/503/504/52x) o un fallo de transporte, tras una espera breve con variación aleatoria y dentro de la misma credencial, plazo y operación compartida. Los estados terminales y las salidas de recuperación inválidas nunca se reintentan.
+
+Los tokens divididos no se reconstruyen para recuperarlos. Una secuencia acotada cuya concatenación exacta tenga estructura Fernet sigue clasificada como texto cifrado al normalizar los campos de texto sin cifrar. Si la tarea no contiene texto legible independiente, se rechaza sin hacer una recuperación ni una solicitud al proveedor enrutado. El texto legible independiente conserva la política existente de contenido mixto. Otras representaciones fragmentadas no están admitidas; esto no ofrece recuperación general de tokens divididos ni garantiza fidelidad multipart del proveedor.
+
+<a id="threat-model"></a>
+
+### Modelo de amenazas
+
+Esta ruta presupone que el cliente nativo local de Codex ya tiene una credencial válida de ChatGPT y que se confía en el destino fijo de ChatGPT para autenticarla. Protege frente a clientes genéricos del proxy o con clave API que intenten usar la función como un oráculo de texto sin cifrar, el envío de credenciales a otro destino, la reutilización de caché entre cuentas o hilos y el registro o la persistencia de datos sensibles. Antes de cada consulta a la caché, la admisión comprueba emisor, audiencia, cliente Codex, fechas de validez y coincidencia exacta de cuenta; el destino sigue siendo la autoridad que valida la firma.
+
+No protege frente a otro proceso del mismo usuario del sistema operativo, un backend de ChatGPT o un modelo de recuperación comprometido, la inyección de instrucciones dentro de la tarea cifrada, errores de transcripción del modelo ni la inspección de memoria del proxy. Por ello, la salida recuperada debe tratarse como salida de modelo no confiable y no como texto autenticado.
+
+```json
+{
+  "agentTaskRecovery": {
+    "enabled": true,
+    "model": "gpt-5.6-sol",
+    "timeoutMs": 45000,
+    "cacheEntries": 200,
+    "retries": 0
+  }
+}
+```
+
+Activa esta opción solo si aceptas la solicitud autenticada adicional, el consumo de cuota, la presencia de texto sin cifrar en el proceso y la dependencia del backend privado. En caso contrario, prefiere un subagente nativo de ChatGPT o la delegación heterogénea v1.
+
+Esta recuperación se aplica a subagentes enrutados directamente y a la creación de `NEW_TASK` cifrados en Combos. Puede haber **como máximo 32 solicitudes de recuperación activas a la vez**; las solicitudes adicionales sin entrada de caché se rechazan. Un Combo con un destino nativo canónico disponible sigue enviándole el texto cifrado directamente: la recuperación solo se ejecuta cuando no se puede seleccionar ningún destino nativo. Después de agotar la actualización de la cuenta guardada de Pool y la repetición con esa misma cuenta, la recuperación puede usar la credencial del cliente entrante para un destino enrutado disponible sin probar otra cuenta nativa. Los rechazos por política siguen siendo terminales. Una recuperación fallida o la falta o el agotamiento de destinos provocan el rechazo sin reenviar texto cifrado a un proveedor enrutado.
+
+<a id="effort-caps"></a>
+
+## Límites de esfuerzo
+
+Los límites solo se aplican a la colaboración v2: un turno principal cumple los requisitos cuando sus herramientas exponen v2; un subagente los cumple si lleva los marcadores exactos de codex-rs `x-openai-subagent: collab_spawn` o `"subagent_kind": "thread_spawn"` en `x-codex-turn-metadata`, aunque sus herramientas ya no expongan colaboración. Los turnos principales v1, `multiAgentMode: "v1"`, la compactación, la revisión y la consolidación de memoria quedan exentos.
+
+Los límites solo reducen el esfuerzo. Se elige el nivel anunciado más alto que no supere el límite. Si el modelo no tiene control de esfuerzo o no admite ningún nivel que cumpla el límite, opencodex omite el esfuerzo y deja que se aplique el valor predeterminado del proveedor. Se aceptan `max` y `ultra`, aunque el panel ofrece de `low` a `xhigh`.
+
+Los límites configurados también se aplican a turnos nativos aptos de Chat Completions que no lleven una asignación de esfuerzo por modelo. La conversión al formato del proveedor se ejecuta al aplicar una asignación o al cambiar el valor por un límite; si no ocurre ninguna de esas cosas, se conserva la representación original enviada por el cliente nativo.
+
+Consulta [Modos de subagentes](/es/guides/sub-agent-surface/) para una explicación inicial de v1, default y v2.
+
+<a id="global-model-effort-pins"></a>
+
+## Asignaciones globales de esfuerzo por modelo
+
+El mapa opcional de nivel raíz `modelPinnedEfforts` completa o sustituye el esfuerzo recibido cuando no existe una asignación por modelo del proveedor ni una asignación para todo el proveedor. Por ejemplo:
+
+```json
+{
+  "modelPinnedEfforts": {
+    "example-provider/example-model": "high"
+  }
+}
+```
+
+La búsqueda consulta primero el selector final antes de normalizar el prefijo del proveedor; después, el destino completo `provider/model`; y, por último, el identificador del modelo de origen sin prefijo. Los alias originales de Combos y los identificadores sintéticos de filas de esfuerzo no son claves de asignaciones globales: configura el destino concreto. Los valores predeterminados de esfuerzo de filas sintéticas y de Combos se conservan como entrada efectiva antes de aplicar la asignación. Cada destino elegido resuelve su propia asignación, luego los límites aplicables y la normalización del protocolo. Las solicitudes de compactación quedan exentas. `none` omite el esfuerzo y usa el comportamiento predeterminado del proveedor; no garantiza que se desactive el razonamiento.
+
+Para el reenvío canónico de OpenAI prevalece la lista de esfuerzos del modelo final: `gpt-6.1-sol` y `gpt-6.1-terra` empiezan en `low`, por lo que `none` o `minimal` entrantes se envían como `low`, también tras cambiar de modelo de compactación o durante un fallback de combo.
+
+`GET /api/effort-caps` incluye el mapa. `PUT /api/effort-caps` acepta `modelPinnedEfforts` junto con los límites existentes: los campos omitidos no cambian, `null` borra el mapa y una entrada con `null` o `""` elimina solo esa clave. Una actualización combinada inválida no modifica los límites ni las asignaciones. Guardar una asignación no cambia la lista de subagentes destacados.
+
+## Actualizaciones de la CLI durante la sincronización v1
+
+Si una sincronización explícita con `multiAgentMode: "v1"` necesita desactivar la opción global v2 de Codex, una actualización activa de Codex CLI puede rechazarla temporalmente. Reintenta cuando termine la actualización. Un directorio que ya usa v1 puede sincronizarse durante la actualización porque no necesita ejecutar un comando nativo de funciones.
diff --git a/docs-site/src/content/docs/es/reference/configuration/catalog.md b/docs-site/src/content/docs/es/reference/configuration/catalog.md
new file mode 100644
index 00000000000..23dbcbf4dc6
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/configuration/catalog.md
@@ -0,0 +1,80 @@
+---
+title: Opciones del catálogo
+description: Omisión opcional de modelos nativos en el catálogo generado de Codex.
+---
+
+<a id="reloading-model-metadata"></a>
+
+## Recargar los metadatos de los modelos
+
+Codex carga un catálogo local de modelos al iniciar. Después de que OpenCodex cambie ese
+catálogo, ejecuta `ocx sync --restart-codex` para actualizar los clientes existentes.
+Publicar un archivo de catálogo nuevo no actualiza un cliente que ya está en ejecución.
+
+Un cliente Codex con metadatos de modelo ausentes o desactualizados puede enviar por
+anticipado todas las definiciones de herramientas MCP en lugar de usar el descubrimiento
+diferido de herramientas, lo que hace mucho más grande cada prompt. Cuando una solicitud de
+Codex declara 64 o más definiciones de herramientas MCP anticipadas, OpenCodex registra una
+advertencia con el recuento y el umbral, y después reenvía la solicitud sin cambios. La
+advertencia no contiene nombres de herramientas ni contenido de la solicitud. Reinicia Codex
+para recargar el catálogo: `ocx system codex-restart --yes` lo reinicia a petición (interrumpe
+los turnos en ejecución), mientras que `ocx sync --restart-codex` reinicia solo después de
+escribir un catálogo o una configuración modificados.
+
+La advertencia se muestra una vez por sesión. Una solicitud sin identidad de sesión no tiene
+sesión por la que advertir una sola vez, así que se advierte una vez por solicitud: un
+reintento o un traspaso por compactación de la misma solicitud permanece silencioso, y la
+siguiente solicitud anónima vuelve a advertir. La lista de sesiones es acotada, por lo que
+una instalación con más de 1024 sesiones concurrentes puede ver una advertencia repetida de
+la sesión desalojada tras el mayor tiempo de inactividad.
+
+El recuento abarca las herramientas de nivel superior, las declaraciones `additional_tools`
+de Responses Lite que el cliente envió con esta solicitud, y las herramientas MCP
+representadas en la descripción `exec` de Code Mode. Codex reenvía el catálogo de la ventana
+al inicio de cada solicitud, así que las declaraciones enviadas por el cliente en un turno
+reanudado también cuentan, incluido un turno que reenvía toda su ventana almacenada bajo
+`previous_response_id`; solo se excluye el historial que el propio proxy restauró desde el
+estado de `previous_response_id`. La compactación, incluidos los desencadenantes de
+compactación de la API Responses, cuenta solo el catálogo de herramientas de nivel superior.
+La comprobación reconoce las identidades canónicas de cliente Codex o los metadatos de turno
+de Codex; una subcadena `codex` incidental en el nombre de otro cliente no la activa. Las
+herramientas diferidas explícitamente, el texto de la conversación y otros clientes de API no
+se cuentan.
+
+Los modelos enrutados anuncian el descubrimiento diferido. En Code Mode, descubre las
+herramientas disponibles mediante `ALL_TOOLS` y llámalas mediante `tools`; no se requiere una
+función `tool_search` separada. Los modelos que usan la interfaz de herramientas directa
+pueden exponer `tool_search`.
+
+<a id="omit-disabled-native-models"></a>
+
+## Omitir modelos nativos deshabilitados
+
+`omitDisabledNativeModels` es un booleano opcional de `config.json`, desactivado
+de forma predeterminada (`false`). Actívalo y ejecuta `ocx sync` para omitir las filas
+nativas deshabilitadas explícitamente sin necesitar un combo con alias nativo:
+
+```json
+{
+  "omitDisabledNativeModels": true,
+  "disabledModels": ["gpt-5.5"]
+}
+```
+
+El ajuste se aplica a la sincronización, la convergencia, la caché de modelos generada y
+el descubrimiento con formato de Codex mediante `/v1/models?client_version=…`. Deshabilitar
+un identificador nativo sin calificar omite ese modelo y todas sus filas de selección de
+cuenta; deshabilitar uno calificado por cuenta omite solo esa fila de selección.
+La plantilla nativa de herencia se valida y se captura antes de la omisión, por lo que las
+filas enrutadas conservan los mismos metadatos de entrada y herramientas, incluso si la
+única fila que servía de plantilla está deshabilitada.
+
+Un valor ausente, falso o no válido conserva el comportamiento predeterminado, sin esta
+omisión adicional. La omisión existente mediante alias nativo es independiente de este ajuste.
+El ajuste solo controla el descubrimiento: las solicitudes directas a identificadores nativos
+deshabilitados siguen enrutándose con normalidad. Si la sincronización no cambia la salida,
+conserva su comportamiento de no escribir y de mantener la fecha de modificación.
+
+Consulta [Modelos de Codex App](/es/guides/codex-app-models/#what-this-means-for-a-disabled-native-model)
+para la visibilidad en Desktop y [Configuración del proveedor](/es/reference/configuration/providers/)
+para `disabledModels`.
diff --git a/docs-site/src/content/docs/es/reference/configuration/keychain.md b/docs-site/src/content/docs/es/reference/configuration/keychain.md
new file mode 100644
index 00000000000..83a6d4ffaf1
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/configuration/keychain.md
@@ -0,0 +1,30 @@
+---
+title: Almacenar claves en el llavero del sistema operativo
+description: Guarda claves API de proveedores y credenciales de Vertex en el Llavero de macOS, el Administrador de credenciales de Windows o Secret Service de Linux.
+---
+
+Para Vertex, la entrada específica del grupo de claves API (`POST /api/providers/keys`) acepta credenciales GCP completas en formato JSON de tipo `service_account` o `authorized_user` después de crear el proveedor. El formulario de creación o edición y `ocx provider add --api-key` rechazan ese JSON antes de guardar: crea el proveedor sin clave y añade después el JSON mediante su grupo de claves. Pega el contenido JSON, no una ruta de archivo de Windows, Unix o relativa.
+
+Puedes pegar varios objetos JSON separados por comas o espacios: se guardan como entradas independientes del grupo y la primera queda activa. La configuración contiene únicamente referencias `gcp-sa:<account>`, nunca el JSON de las credenciales. Si mezclas JSON y claves literales, se rechaza toda la entrada; añade las claves literales por separado. Los fallos de almacenamiento conservan la configuración y devuelven un error fijo sin mostrar las credenciales. Un marcador con cuenta vacía es inválido y no recurre a las credenciales del equipo.
+
+Pega un objeto de credenciales o una secuencia de objetos, sin una matriz exterior ni una cadena entre comillas. Se rechaza el texto mal formado. Si una credencial seleccionada se elimina o deja de poder leerse, Vertex rechaza la solicitud aunque tenga en caché un token de acceso obtenido con ella.
+
+Al eliminar una clave o un proveedor, o sustituirlo con `ocx provider add --force`, sus credenciales GCP sin referencias se eliminan después de guardar la configuración. Las que otro proveedor todavía utilice se conservan. Si falla la limpieza del almacén del sistema operativo, se solicita una inspección manual mediante una advertencia; no se revierte la eliminación ya guardada en la configuración.
+
+Las operaciones habituales de almacenamiento y restauración en el llavero conservan los marcadores GCP y su JSON en el almacén del sistema operativo. No se permite restaurar ese JSON mediante un alias `keychain:`. La limpieza conserva las cuentas que sigan referenciadas por cualquiera de los dos formatos de marcador. Tampoco se permite usar como clave API un alias `keychain:` que contenga JSON de GCP: para autenticar Vertex, selecciona su referencia `gcp-sa:`.
+
+Las claves API literales deben ser texto simple del token. La resolución y restauración de claves literales rechazan objetos, matrices y cadenas JSON entre comillas, incluidos los envoltorios con texto de credenciales escapado. La escritura de credenciales y la persistencia de sus marcadores comparten el bloqueo de la transacción de limpieza: una eliminación simultánea no puede borrar el JSON entre la lectura de comprobación y la confirmación del marcador.
+
+De forma predeterminada, `apiKey` y `apiKeyPool` se guardan en `config.json` con modo 0600 y escrituras atómicas. Para mantener las claves fuera de ese archivo, pásalas al almacén de credenciales del sistema operativo:
+
+```bash
+ocx provider keychain deepseek status    # store: file | env | keychain, and whether the keychain answers
+ocx provider keychain deepseek store     # move active key + pool into the OS keychain
+ocx provider keychain deepseek restore   # bring the plaintext back and delete the keychain items
+```
+
+Estas operaciones también están disponibles mediante `GET`/`POST /api/providers/keychain`. Después de `store`, `config.json` contiene `"apiKey": "keychain:deepseek"` y las entradas del grupo usan `keychain:deepseek/<id>`. El secreto se guarda bajo el servicio `opencodex.provider-api-key.v1` en el Llavero de macOS, el Administrador de credenciales de Windows o Secret Service de Linux. Las copias de seguridad de `config.json` contienen solo referencias. La rotación y la conmutación por error siguen funcionando: las entradas se comparan por referencia y una rotación nunca vuelve a escribir la clave en texto sin cifrar.
+
+Antes de modificar la configuración, `store` escribe y vuelve a leer cada entrada. Si el llavero no está disponible o la lectura no coincide, devuelve 503 y conserva el archivo. Durante una solicitud, una referencia que no se puede leer no aporta ninguna credencial y produce una advertencia por clave; no se recurre a una copia en texto sin cifrar.
+
+No actives esta opción si el proxy se ejecuta como servicio sin sesión interactiva (systemd, launchd o Task Scheduler) o en un contenedor sin un llavero desbloqueado: las solicitudes se rechazarían al no poder leer las claves. En ese caso, usa una referencia `${ENV_VAR}` y proporciona la variable en el entorno del servicio. `store` deja intactas las referencias a variables de entorno.
diff --git a/docs-site/src/content/docs/es/reference/configuration/providers.md b/docs-site/src/content/docs/es/reference/configuration/providers.md
new file mode 100644
index 00000000000..d86de0a8285
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/configuration/providers.md
@@ -0,0 +1,1332 @@
+---
+title: "Configuración del proveedor"
+description: "Entradas de proveedores, autenticación, puntos finales, catálogos de modelos, cuotas, límites de contexto y opciones específicas del proveedor."
+---
+
+<!-- Created: 2026-10-16; Updated: 2026-10-18; Version: 1.1 (Vertex endpoint note) -->
+
+Un proveedor le dice a opencodex dónde vive un modelo, qué adaptador de cable habla y cómo se autentican las solicitudes.
+
+<a id="deepseek-tokens-versus-image-bytes"></a>
+
+## DeepSeek: tokens y bytes de imágenes
+
+DeepSeek documenta un [Límite de solicitud de cuerpo de 48 MiB](https://api-docs.deepseek.com/guides/files_api/) separado. Una sesión de captura de pantalla puede alcanzar ese límite antes de que se llene su contexto de token; aumentar `model_auto_compact_token_limit` no puede evitarlo.
+
+Las subidas están **desactivadas de forma predeterminada**. Configure `modelCapabilities: { "deepseek-flash": { deepseekImageFiles: true } }` en su proveedor si acepta imágenes persistentes por separado en los servidores de DeepSeek durante una hora. PATCH `null` en la entrada del eje o modelo borra la opción de inclusión.
+
+Para los modelos opcionales en las URL Responses de origen, los cuerpos de más de 40 MiB reemplazan las imágenes en línea más antiguas con [Archivos API referencias](https://api-docs.deepseek.com/guides/files_api/), con el objetivo de 32 MiB. Los bytes de imagen, el historial y el uso de tokens permanecen sin cambios. Los archivos solicitan una hora de vencimiento; las cargas parciales exitosas permanecen hasta el vencimiento incluso si la generación falla. La caché de referencia limitada está aislada de credenciales y dura un máximo de 50 minutos (menos si el proveedor informa una expiración anterior). Un reintento puede reutilizar cargas exitosas; otra credencial carga su propia copia.
+
+Las pasarelas de terceros y Chat Completions conservan su comportamiento. Un `detail: low` explícito mantiene la imagen en línea, porque las referencias de archivo lo ignoran. Si falla, la operación se detiene sin descartar imágenes ni reintentar la generación. La reparación tiene un plazo de subida de 60 segundos, un límite de entrada de 128 MiB y un máximo de dos preparaciones simultáneas; siguen aplicándose el ritmo y la concurrencia del proveedor. El texto demasiado grande y las imágenes que no puedan convertirse aún necesitan compactación. Esta reparación del transporte no amplía la ventana de contexto del modelo.
+
+Solo se suben imágenes de mensajes `user` y `developer`, y las imágenes de resultados de herramientas. DeepSeek rechaza las imágenes en otros roles, por lo que nunca se almacenan.
+
+## GPT-6.1 Terra
+
+[GPT-6.1 Terra](https://openai.com/index/introducing-gpt-6-1-terra/) se publicó el 26 de octubre de 2026 como sucesor de GPT-5.6 Terra. `gpt-6.1-terra` está disponible junto a `gpt-5.6-terra`; no cambian el modelo predeterminado ni la lista de subagentes. GitHub Copilot usa Responses; OpenRouter enumera `openai/gpt-6.1-terra` con 1,050,000 de contexto y $1.00 de entrada / $5.00 de salida por millón de tokens.
+
+En Codex nativo: contexto predeterminado de 500,000 y máximo de contexto largo de 872,000; esfuerzo predeterminado `low` y niveles `low`, `medium`, `high`, `xhigh`, `max`, `ultra`. El `ultra` nativo se envía como `max`. La fila nativa solo ofrece Fast.
+
+En la [API de OpenAI](https://developers.openai.com/api/docs/models/gpt-6.1-terra): contexto de 1,050,000 y salida máxima de 128,000; entrada de texto e imágenes y salida de texto; conocimiento hasta 2026-06-01. Los esfuerzos son `none`, `low`, `medium` (predeterminado), `high`, `xhigh` y `max`. Los endpoints son `v1/responses` y `v1/chat/completions`; las llamadas a herramientas requieren Responses.
+
+Por millón de tokens: $1.00 de entrada, $0.05 de entrada en caché, $1.25 de escritura de caché durante 30 minutos y $5.00 de salida. Con más de 272,000 tokens de entrada, toda la solicitud usa el doble para entrada y caché y 1,5 veces para salida: $2.00 / $0.10 / $2.50 / $7.50, respectivamente. El modo Fast cuesta el doble.
+
+<a id="context-windows-on-custom-providers"></a>
+
+## Ventanas de contexto en proveedores personalizados
+
+Cuando un proveedor personalizado omite la ventana de contexto de un modelo, OpenCodex puede inferirla a partir de los metadatos del modelo agrupados. Esto está desactivado de forma predeterminada: establezca `inferContextWindow: true` en el proveedor para activarlo. Sin ella, un modelo sin ventana utiliza el límite de Contexto habilitado como su ventana, luego la reserva de compatibilidad de 128k. Con él, el orden es: límites descubiertos / configurados (las ganancias más pequeñas), metadatos de Azure, metadatos de ID de modelo, límite de contexto habilitado como la ventana, luego 128k. Un límite de contexto activado sigue limitando el resultado. Los proveedores incorporados mantienen su comportamiento existente e ignoran la bandera.
+
+`GET /api/providers` incluye `inferContextWindow` solo cuando está configurado, conservando tanto `true` como `false`. Para cambiarlo, `PATCH /api/providers?name=<provider>` acepta `true`, `false` o `null` para borrar la configuración y restaurar el comportamiento desactivado de forma predeterminada; otros tipos devuelven `400`. Omitirlo mantiene la configuración actual. Un `POST /api/providers` del mismo nombre también mantiene una configuración omitida, incluyendo `false` y cualquier cambio realizado mientras se validaba el guardado. Un booleano enviado gana, incluyendo `false`, incluso si el valor almacenado es `true`.
+
+```json
+{ "providers": { "my-relay": { "adapter": "anthropic", "baseUrl": "https://relay.example/v1", "inferContextWindow": true } } }
+```
+
+Las tablas API de proveedor original tienen prioridad sobre las tablas de agregador. Se prefieren los IDs exactos; las variantes de caso y punto/hipno se aceptan solo cuando no son ambiguas. IDs desconocidos, `~` alias flotantes y coincidencias conflictivas no se adivinan. OpenAI API ventanas no describen Codex límites de suscripción. Una ventana inferida afecta el presupuesto de compactación de Codex y otros catálogos de clientes conectados, incluida la selección de contexto largo de Claude, pero se registra por separado de la capacidad de enrutamiento afirmada.
+
+Un ID de modelo coincidente hace que **no** verifique la capacidad real de su relé. Si sirve menos que la ventana del proveedor, configure `modelContextWindows` o **Cap. de contexto** del proveedor antes de usar sesiones largas. OpenCodex no habilita una tapa automáticamente ni prueba el modelo. Las solicitudes más pequeñas exitosas no prueban que la ventana inferida completa funcione. Las ventanas configuradas existentes permanecen bajo control.
+
+<a id="initial-model-selection"></a>
+
+## Selección inicial del modelo
+
+Nuevas conexiones no OAuth esperan una lista de modelos confiable antes de exponer los modelos. Si esa lista contiene al menos 20 filas distintas de la pestaña Modelos, todos los modificadores de modelo se inician en OFF; el proveedor en sí permanece activo. Las conexiones OAuth y de inicio de sesión de ChatGPT mantienen sus valores predeterminados, según el modo de autenticación efectivo.
+
+Esto se ejecuta solo para un nuevo registro de proveedor. Las selecciones existentes sobreviven a las actualizaciones, el re-login y el reemplazo de claves. Después de la inicialización, habilite los modelos que necesita en Modelos o con el CLI a continuación; la política de llegada de modelos nuevos por separado no cambia. Reemplace `<model-id>` con un ID de la lista.
+
+```sh
+ocx models live --provider openrouter
+ocx models enable '<model-id>'
+ocx models disable '<model-id>'
+ocx models provider openrouter on
+```
+
+Después del registro de la GUI o del inicio de sesión del OAuth, el cuadro de diálogo de confirmación le permite abrir la página Modelos. CLI registro y acceso imprimir comandos de gestión de modelos; JSON incluye los siguientes pasos estructurados. `--no-wait` informes pendientes de inicio de sesión, no de finalización. Inicie el proxy con `ocx start` antes de usar comandos de modelo en vivo.
+
+<a id="zai-coding-plan-quota-endpoints"></a>
+
+## Z.ai Coding Plan puntos finales de cuota
+
+La sonda de cuota Z.ai reconoce la base de codificación internacional Chat `https://api.z.ai/api/coding/paas/v4`, la documentada [Claude Code Anthropic base](https://docs.z.ai/devpack/tool/claude) `https://api.z.ai/api/anthropic` y la documentada [Codex Responses base](https://docs.z.ai/devpack/tool/codex) `https://api.z.ai/api/v1`. Los tres leen la cuota del monitor internacional con autenticación de portador; esto no cambia la URL de inferencia ni implica un consumo de cuota diferente entre adaptadores. La selección del monitor BigModel CN existente permanece separada. Las URL de solicitud completas como `/api/v1/responses` no son URL de base del proveedor.
+
+<a id="provider-related-top-level-fields"></a>
+
+## Campos de nivel superior relacionados con el proveedor
+
+| Campo | Tipo | Predeterminado | Descripción |
+| --- | --- | --- | --- |
+| `providers` | `Record<string, OcxProviderConfig>` | — | Mapa del nombre del proveedor a la configuración del proveedor. |
+| `openaiProviderTierVersion?` | `2` | establecido por la migración | Marca la proyección OpenAI con una sola opción como completa. |
+| `disabledModels?` | `string[]` | — | Modelos ocultos del catálogo de Codex y `/v1/models`, pero no bloqueados de llamadas proxy directas. Un identificador encaminado se elimina de los listados. Un identificador nativo calificado para la cuenta oculta solo esa fila selectora; un identificador GPT nativo desnudo oculta la fila desnuda y cada fila de selector de cuenta para ese modelo. La página Modelos del panel de control expone solo filas nativas enrutadas y desnudas; use este campo de configuración directamente para ocultar una fila calificada por el selector. Configura [`omitDisabledNativeModels`](/es/reference/configuration/catalog/) como `true` para omitir las filas nativas deshabilitadas; está desactivado de forma predeterminada. |
+| `providerContextCaps?` | `Record<string, number>` | `{}` | Límites de contexto de proveedor activo. Las ventanas ordinarias se bajan; los modelos nativos con una ventana larga compatible pueden expandirse solo hasta su propio techo compatible. |
+| `providerContextCapValues?` | `Record<string, number>` | `{}` | Límites del último proveedor seleccionado, retenidos mientras están desactivados. Estos valores no activan un límite. Un valor habilitado tiene prioridad sobre un valor recordado. |
+| `contextCapValue?` | `number` | `350000` | Por defecto se utiliza en la primera habilitación. Una habilitación posterior restaura el valor del proveedor seleccionado. Actualizar el valor global solo con los límites de cambios habilitados para `setAll: true`; `setAll: true` sin un valor habilita a todos los proveedores configurados al valor global actual. |
+| `codexAccounts?` | `CodexAccount[]` | `[]` | ChatGPT / Codex metadatos de cuenta de grupo administrados por Codex Auth. Los secretos viven por separado en `codex-accounts.json`. |
+| `pausedCodexAccountIds?` | `string[]` | `[]` | Cuentas excluidas de la selección Pool hasta que se reanude, incluida la cuenta principal `__main__` cuando se detiene. La pausa manual y el reinicio también actualizan las entradas principales y de grupo existentes para la misma cuenta y espacio de trabajo. |
+| `codexUseRemainingQuotaAccountIds?` | `string[]` | `[]` | Las cuentas optaron por usar su cuota incluida restante. Desactiva el cambio de uso proactivo para las cuentas enumeradas; para `__main__`, los umbrales efectivos de bloqueo duro corto / largo se convierten en 100%. Los umbrales originales permanecen almacenados y se aplican de nuevo después de deshabilitarlos. Todavía se aplican la pausa, la autenticación, la elegibilidad, el tiempo de reutilización y el permiso de crédito pagado. Gestionado por `ocx account use-remaining openai <id-or-main> on`; esta preferencia persistente no selecciona la cuenta. |
+| `creditCodexAccountIds?` | `string[]` | `[]` | Cuentas permitidas para seguir sirviendo desde ChatGPT créditos después de un límite de uso, incluida la cuenta principal `__main__`. Upstream no rechaza una cuenta que tiene créditos al 100%; sirve a la solicitud y extrae el saldo. El gasto es opt-in: una cuenta que no aparece aquí se salta por selección, mientras que una de sus ventanas de uso (semanal o mensual, solo mensualmente en planes de 30 días o la ventana de 5 horas) lee el 100% con su restablecimiento aún por delante, y regresa una vez que ese restablecimiento pasa. Una lectura semanal o mensual sin un tiempo de reinicio no mantiene la cuenta; una lectura de 5 horas al 100% sin un reinicio lo mantiene solo mientras esa lectura aún está fresca. Cuando no hay otra cuenta disponible, la selección automática no encuentra ninguna en lugar de gastar créditos. Un `__main__` no listado también es rechazado, como un rechazo de bloqueo, cuando una solicitud lo nombra o lleva su credencial. El listado `__main__` no levanta el bloqueo de la cuenta principal (por defecto al 98%), lo que aún detiene el inicio de sesión principal primero; apague el bloqueo para dejar que la cuenta principal gaste créditos (un bloqueo al 100% aún lo detiene al 100%). Las cuentas nuevas comienzan a no estar listadas. Gestionado por el interruptor **Usar créditos** en el encabezado Codex Auth y el interruptor **Usar créditos después del límite** en el menú **⋯** de cada tarjeta de cuenta. |
+| `codexQuotaAutoRefresh?` | `Record<string, object>` | `{}` | Opt-in por cuenta de inicio de sesión de Codex para la activación automática de las ventanas `fiveHour` y `weekly` en el modo Pool; el modo Direct no ejecuta este trabajador. En **Configuración avanzada** de Providers/Codex Auth, un solo control habilita o desactiva ambas ventanas compatibles en todas las cuentas principales y añadidas actuales. Las cuentas nuevas no se incluyen automáticamente. Habilitar omite las ventanas ausentes de los datos WHAM en vivo; deshabilitar también borra las ventanas habilitadas obsoletas. La interfaz reutiliza las escrituras granulares de `/api/settings`, reconcilia los fallos parciales y reintenta la intención original de activación/desactivación sin reemplazar configuraciones no relacionadas o marcadores de reinicio completados. La API sigue rechazando habilitar una ventana no disponible con HTTP 409. En un tiempo de reinicio informado, opencodex envía un mensaje Codex mínimo no almacenado usando la cuota de esa cuenta y persiste la marca de tiempo activada. Esto no se aplica a los proveedores de claves API. |
+| `codexAccountNamespaces?` | `Record<string, string>` | — | Mapa opcional de un selector de modelo público arbitrario a un destino de cuenta Codex almacenado. Cuando se habilitan las filas de selector calificadas para la cuenta, cada selector cuyo objetivo está presente agrega `<selector>/<native-openai-model>` filas separadas al selector Codex; cada fila usa solo esa cuenta. Con cualquier selector activo, las filas nativas desnudas están ocultas en el selector, pero sus ids permanecen enrutables y listados por `/v1/models` sin procesar a menos que estén explícitamente deshabilitados. |
+| `codexAccountPickerEnabled?` | `boolean` | cuando el mapa está vacío | Controla si las asignaciones `codexAccountNamespaces` elegibles generan filas de selector Codex calificadas para la cuenta. `true` permite que aparezcan las filas asignadas. Si se omite con un mapa no vacío, se trata como habilitado para la compatibilidad con versiones anteriores; si el mapa está vacío, está desactivado. `false` oculta las filas generadas y restaura las filas del selector nativo desnudo sin eliminar asignaciones ni deshabilitar el enrutamiento exacto `<selector>/<native-openai-model>`. |
+| `activeCodexAccountId?` | `string` | — | La cuenta Pool seleccionada manualmente para la siguiente solicitud. La selección borra la afinidad del hilo; las solicitudes en vuelo mantienen las credenciales capturadas. |
+| `codexAccountPriorities?` | `Record<string, number>` | — | Orden de selección por cuenta para el grupo Codex: número de identificación de cuenta → de `-100` a `100`, **más alto se utiliza antes**, medios ausentes `0`. Este es un límite de pedido, no uno de elegibilidad: la selección reduce las cuentas ya elegibles al nivel más alto que aún tiene margen de cuota, y `accountPoolStrategy` luego elige dentro de ese nivel. Un nivel se salta solo cuando cada miembro está en o por encima de su propio umbral de uso efectivo distinto de cero (anulación de cuenta o valor predeterminado global), enfriamiento, evitación suave, pausa o necesita reautenticación: la cuota desconocida nunca agota un nivel. Ordenar nunca hace que una cuenta no elegible sea seleccionable y, por defecto, nunca vuelve a unir un hilo que ya tiene una cuenta. La cuenta principal `__main__` participa en igualdad de condiciones, que es la forma en que el inicio de sesión del escritorio Codex se puede configurar para agotar en último lugar. Sin entradas, el grupo se comporta exactamente como antes. Un mapa mal formado se ignora con una advertencia de consola (ordenación desactivada, sin reparación de configuración). Administrado por `ocx account priority` y la página Codex Auth. |
+| `activeCodexAccountPinned?` | `string` | — | ID de cuenta que el operador seleccionó por última vez a mano. Mientras está establecido, un nivel `codexAccountPriorities` más alto no puede evitarlo hasta que el pin se libere por drenaje, exclusión, eliminación o una conmutación por error / promoción explícita. El movimiento ordinario de round-robin dentro del nivel con tapa no lo libera. Escribir cualquier entrada `codexAccountPriorities` también libera el pin, por lo que un pin hecho antes de que existiera una orden no puede superar a un conjunto después. `GET /api/codex-auth/active` informa tanto si la cuenta efectiva está anclada ( `pinned` ) como si la cuenta que lleva el techo ( `pinnedAccountId` ). |
+| `codexPreserveSignedInAccount?` | `boolean` | `false` | Prefiera otras identidades elegibles Codex Pool antes de las entradas nativas principales y ordinarias que coincidan con su espacio de trabajo seleccionado y el correo electrónico del miembro. Las prioridades personalizadas existentes se conservan dentro de cada grupo. Permanecen fijaciones y pines manuales saludables; las rutas exactas de la cuenta y el modo Direct no cambian. El retroceso puede consumir la cuota de inicio de sesión bajo todos los guardias existentes. Use [cuenta preserve-signed-in](/es/reference/cli/providers-accounts/#ocx-account-preserve-signed-in-openai-onoffstatus---apply-to-bound---json) para el estado o una transición explícita de enlace de siguiente solicitud. |
+| `codexAccountPriorityFailback?` | `boolean` | `false` | Opt-in retorno de Codex Pool tareas en curso a una cuenta de mayor prioridad utilizable bajo la estrategia `quota`. Las solicitudes activan una actualización de cuota de fondo como máximo una vez cada cinco minutos, incluidos los intentos de actualización fallidos. Cuando las observaciones recientes de la cuota muestran margen, la siguiente solicitud puede volver a vincularse incluso si su cuenta corriente está por debajo del umbral. Esta preferencia explícita puede descartar una caché de solicitud caliente; no cambia la afinidad de caché predeterminada. Ninguna solicitud significa que no hay votación. Los pines manuales, el acceso al modelo, los tiempos de reutilización, las pausas y las exclusiones de reautenticación aún se aplican; las solicitudes en vuelo mantienen su cuenta capturada. Requiere que el umbral efectivo de la cuenta de origen actual sea positivo (una anulación de 0 lo deshabilita; una anulación positiva funciona con 0 global); las rutas exactas de la cuenta y el modo Direct no cambian. |
+| `autoSwitchThreshold?` | `number` | `80` | Umbral de uso para asignar trabajo nuevo o sin vínculo. `quota` puede reevaluar tareas sin vínculo en su próxima solicitud cuando se cruza este umbral. Las tareas vinculadas conservan su cuenta más allá del umbral de forma predeterminada (`pool.cacheAffinity`); solo la abandonan si se agota o no puede atenderlas, y solo cambian a una cuenta con margen real de cuota y uso estrictamente menor. Usa `pool.cacheAffinity: false` para reevaluar las tareas vinculadas en el umbral, con el mismo requisito para el destino. `fill-first` lo usa como punto de agotamiento de la asignación sin vínculo. `round-robin` lo aplica únicamente al trabajo nuevo o sin vínculo: omite cuentas que alcanzan o superan su umbral efectivo mientras haya alguna apta por debajo, sin mover por ello una tarea vinculada. Se evalúa la ventana conocida con mayor uso de cinco horas, semanal o de 30 días. `0` desactiva solo el cambio proactivo basado en uso, sin desactivar la asignación sin vínculo ni la recuperación de fallos. |
+| `codexAccountAutoSwitchThresholds?` | `Record<string, number>` | — | Anulaciones por cuenta para `autoSwitchThreshold`: id de cuenta → entero de `0` a `100`. Una entrada ausente hereda el valor global; `0` desactiva la conmutación basada en el uso solo cuando esa cuenta es la fuente. `quota` utiliza el umbral efectivo de la cuenta de origen actual para la reevaluación de tareas limitadas y la conmutación sin límites. El margen de nivel de primer drenaje y de orden de selección se evalúa contra el propio umbral efectivo de cada cuenta; los pines de la cuenta principal y el retroceso del subagente también usan el umbral efectivo de la cuenta relevante. Soporta la cuenta principal `__main__`. Un mapa mal formado se ignora con una advertencia. Administrado por cada tarjeta de cuenta en la página Codex Auth; deshabilitar una anulación elimina su entrada. Al habilitar la anulación, se copia el umbral global actual en un valor de cuenta fijo. La anulación, incluyendo `0`, tiene prioridad sobre los cambios globales posteriores. Deshabilitar envía `threshold: null`, elimina la entrada y restaura la herencia del umbral global actual y los cambios globales futuros. |
+| `accountPoolStrategy?` | `"quota" \| "round-robin" \| "fill-first" \| "reset-first"` | `"quota"` | Estrategia de asignación para solicitudes Codex nuevas o sin vínculo. Una solicitud no está vinculada si no tiene afinidad activa para su ID de hilo padre y ámbito de cuota. Los vínculos de solicitudes con un ID de sesión, incluidos los turnos habituales de Codex CLI, App y subagentes, o de solicitudes sin sesión ancladas a su padre inmediato, pueden sobrevivir a un reinicio ordenado del proxy hasta 24 horas de inactividad si el guardado final de afinidad al apagar termina correctamente. Las cadenas más profundas sin sesión y los vínculos al inicio de sesión principal de Codex App solo existen en memoria y se asignan otra vez tras el reinicio. La expulsión de caché, la eliminación de la cuenta, otro inicio de sesión, un cierre inesperado o un restablecimiento de afinidad pueden dejar una tarea sin vínculo. `quota` elige la cuenta apta de menor uso si no existe una activa, conserva una activa apta por debajo de `autoSwitchThreshold` y puede mover una solicitud sin vínculo tras cruzarlo. Las tareas vinculadas siguen `pool.cacheAffinity`, activado de forma predeterminada: permanecen hasta agotarse la cuenta, con uso conocido del 100%, o hasta que no pueda atenderlas; el nuevo destino debe tener margen real y uso estrictamente menor. Usa `false` para permitir la reasignación proactiva al alcanzar el umbral, con ese mismo requisito. `round-robin` distribuye las solicitudes sin vínculo entre cuentas aptas por debajo de su `autoSwitchThreshold` efectivo, o entre todas si ninguna queda por debajo. `fill-first` sigue asignando trabajo sin vínculo a la cuenta activa hasta el enfriamiento, la falta de disponibilidad o el umbral configurado. `reset-first` prefiere el restablecimiento futuro de cinco horas o semanal más cercano entre cuentas por debajo del umbral; las tareas vinculadas siguen la política de afinidad. Las cuotas independientes de modelo usan orden por cuota y los restablecimientos mensuales no determinan el orden. En todas las estrategias, un turno de Claude Code que llega a una cuenta Codex mediante `/v1/messages` se vincula por su sesión Claude: primero `session_id`/`session-id`, después la sesión de metadatos y, por último, `x-claude-code-session-id`. Una clave secreta del servidor limita el vínculo a la credencial admitida o al uso local de loopback, impidiendo compartir, adivinar o reutilizar el de otra credencial. El vínculo solo elige cuenta; no cambia los encabezados enviados al proveedor. Los turnos spawn y los que ya incluyen `x-codex-parent-thread-id`, `thread-id` o un par completo de sesión e hilo conservan su identidad. La sesión vinculada suele permanecer en una cuenta, aunque las reglas de afinidad y recuperación aún pueden moverla. |
+| `pool.cacheAffinity?` | `boolean` | `true` | Ordenación de afinidad de caché para hilos vinculados Codex, independientemente de `pool.kernel`. Omitir la clave o la configuración `true` mantiene una tarea vinculada en su cuenta hasta que esa cuenta realmente no pueda servir. Solo un `false` explícito restaura la reasignación basada en umbral de tareas vinculadas. Un enlace en vivo supera el margen de la cuota: `quota` no mueve el hilo simplemente porque el uso cruzó `autoSwitchThreshold`. El hilo todavía se va si esa cuenta no puede servir - pausado, inutilizable o genuinamente agotado (uso conocido al 100%) - y luego solo a una cuenta con margen de cuota genuino y uso estrictamente más bajo. En cualquier configuración, una cuenta con uso desconocido nunca se elige como destino para una tarea vinculada, por lo que cuando cada cuenta se encuentra por encima del umbral, la tarea se mantiene. La afinidad es un reordenamiento, no un pin. |
+| `pool.credentialGroups?` | `Array<{ id: string; credentials: string[]; note?: string }>` | `[]` | Aceptado y validado, pero aún no consumido por el enrutamiento: declarar que un grupo no cambia ninguna decisión de enrutamiento hasta que una capa consumidora aterriza. Dominios de cuota declarados por el operador: grupos de credenciales que comparten demostrablemente un límite de uso ascendente. Los miembros de un grupo cuentan una vez para la capacidad disponible, y un rechazo de cuota dentro de un grupo no se responde rotando a otro miembro: el límite es el mismo, por lo que el movimiento pagaría un prefijo frío por cero nueva capacidad. Los grupos declarados solo hablan de cuota; compartir un límite no dice nada sobre la compatibilidad de la caché de solicitud, que se clasifica por separado. Cada miembro está calificado por el proveedor como `"<provider>:<credential-id>"`, porque una identificación de credencial significa algo solo dentro de su proveedor; el segmento de proveedor acepta los alias habituales (`chatgpt:` y `codex:` significan ambos OpenAI). Los identificadores de grupo deben ser únicos, `credentials` no debe estar vacío, y una credencial puede aparecer en un máximo de un grupo: una declaración ambigua se rechaza al escribir y se elimina con una advertencia sobre la carga en lugar de resolverla el grupo que aparece primero, ya que eso combinaría dos dominios de cuota no relacionados. Una lista mal formada cuesta solo la agrupación: `pool.kernel` y `pool.cacheAffinity` se conservan. Ausente o vacío significa que no se declara agrupación, por lo que una instalación no configurada se comporta exactamente como antes. |
+| `accountPoolStickyLimit?` | `number` | `1` | Las asignaciones de tareas nuevas/no vinculadas se conservan en una selección de round-robin antes de avanzar; el contador avanza cuando una tarea está vinculada, no después de un éxito ascendente. Alcance 1-100. |
+| `upstreamFailoverThreshold?` | `number` | `3` | Fallos transitorios consecutivos tras los cuales las sesiones nuevas cambian a otra cuenta. Configura `0` para desactivarlo. En las solicitudes Responses normales y las de compactación nativa, los fallos de conectividad DNS/TCP confirmados antes de establecer la conexión se registran por host del proveedor. No afectan al estado ni a la espera de las cuentas, la afinidad de hilo o sesión, la cuenta activa ni el enrutamiento del Pool, y no cuentan para este umbral. |
+| `codexFailureWindow?` | `boolean` | `true` | Proporción de fallos transitorios en una ventana móvil de 60 segundos para hilos nuevos de Codex, junto con el contador de fallos consecutivos. Con al menos 20 muestras, una proporción del 25% o más marca la cuenta como degradada; esa marca se borra cuando la proporción permanece en el 10% o menos durante 30 segundos. Las cuentas degradadas solo se omiten para hilos nuevos: los que ya tienen una cuenta asignada la conservan. Configura `false` para decidir únicamente mediante el contador de fallos consecutivos. |
+| `codexPinnedTransientPolicy?` | `"hold" \| "detour-new-threads"` | `"hold"` | Mientras una cuenta anclada manualmente está en la ventana de falla, `hold` sigue enviándole nuevos hilos y registra una advertencia degradada. `detour-new-threads` coloca solo nuevos hilos en otra cuenta. Un giro en vuelo nunca se mueve, y un giro que ya se ha enviado nunca se resiente. |
+| `codexWsReuseAcrossTurns?` | `boolean` | `false` | Opt-in Codex WebSocket reutilización a través de turnos de una cuenta y el hilo. Cuando está activado, se espera un socket ocupado como máximo 750 ms antes de otro dial, se mantienen hasta dos sockets cuando cambia el modelo o el nivel de servicio, y las cabeceras de estado de giro permanecen en cada mensaje en lugar del apretón de manos. Los cambios de autorización, cuenta, proxy o dial-URL aún retiran el socket anterior. |
+| `upstreamHostCircuitThreshold?` | `number` | `0` | Umbral de entrada para fallos probados de DNS/ TCP previos a la conexión en envíos Responses directos nativos OpenAI y compactos. `0` lo deshabilita; `1` - `20` abre un tiempo de reutilización de origen del proveedor de 30 segundos después de muchas solicitudes lógicas de terminal. Mientras están abiertas, las solicitudes reciben `503` con `Retry-After` antes de la selección de la cuenta o el envío ascendente; después del tiempo de reutilización, se admite una solicitud a medio abrir. Los tiempos de espera y las respuestas HTTP nunca cuentan, y cualquier respuesta HTTP cierra el circuito. Se aplica solo al enrutamiento Codex Pool sin cuenta fija; es inerte para `codexAccountMode: "direct"` y selectores calificados para cuentas. |
+| `maxUpstreamBodyBytes?` | `number` | `0` | Techo opt-in, en bytes, en un cuerpo serializado nativo Responses **passthrough**. `0` u omitido lo desactiva: no se infiere ningún límite para ningún destino. Cuando se establece, un cuerpo construido que supera el techo se rechaza localmente antes del envío: los turnos en streaming reciben un `response.failed` / `context_length_exceeded` terminal para que el cliente compacte en lugar de reenviar, y los turnos que no son de streaming reciben un `413` que nombra el tamaño, el número de elementos `input_image` incrustados y aproximadamente cuántos megabytes de datos de imagen representan. Se comprueba en cada punto de construcción y reconstrucción, incluida la repetición tras una actualización de OAuth y el reintento con otra cuenta. Las rutas de adaptador traducidas no están cubiertas. Deliberadamente no hay valor predeterminado: el único techo medido aquí pertenece al transporte WebSocket, que ya recurre a HTTP para los turnos de gran tamaño, así que un valor predeterminado rechazaría solicitudes que hoy tienen éxito. Establézcalo cuando su puerta de enlace tenga un límite de tamaño de solicitud conocido y prefiera un error local accionable a un fallo ascendente opaco. |
+| `maxInboundBodyBytes?` | `number` | `0` | Techo opt-in, en bytes, en un cuerpo de solicitud de plano de datos **entrantes** descomprimido - el espejo de `maxUpstreamBodyBytes` arriba. `0` u omitido mantiene el valor predeterminado de 256 MiB incorporado. Levántelo cuando una sesión de contexto grande ya no pueda compactar: Codex reproduce todo el historial en el modelo de compactación, por lo que en la ventana opt-in del token 922k, la solicitud de compactación es la que cruza el límite, y la sesión está atascada en la única operación que la habría reducido. Sujeto a 1 MiB-512 MiB. El techo no es negociable: el lector materializa el cuerpo varias veces (bytes de cable, bytes decodificados, la cadena decodificada y el gráfico de objeto analizado), por lo que la memoria máxima es un múltiplo de lo que se admite, y un valor ilimitado sería una palanca de agotamiento de memoria. Se aplica a `/v1/responses`, `/v1/responses/compact`, `/v1/chat/completions`, y `/v1/messages`. También cubre las rutas de imágenes, búsqueda y recuento de tokens indicadas en [admisión de cuerpos entrantes](/es/reference/inbound-body-admission/). El tamaño de aceptación del oyente se fija cuando el proxy se une, por lo que un cambio tiene efecto al reiniciar. Se rechaza localmente un cuerpo por encima del límite con HTTP 413 y `code: "inbound_body_too_large"`, que es deliberadamente distinto del `context_length_exceeded` 413 que produce una denegación de tamaño del proveedor. Un límite efectivo superior a 256 MiB activa además el control compartido `maxConcurrentInboundBodyBytes`; aumentar solo el límite por solicitud no aumenta ese presupuesto. |
+| `maxConcurrentInboundBodyBytes?` | `number` | `536870912` (512 MiB) | Presupuesto compartido opcional de nivel superior en bytes, activo solo si `maxInboundBodyBytes` efectivo supera 256 MiB. Omitirlo, usar `0` o un valor inválido conserva los 512 MiB predeterminados. Los enteros positivos válidos se limitan a 512 MiB–2 GiB (`536870912`–`2147483648`) al consumirse. Requiere reinicio; todos los listeners del proceso comparten el presupuesto. Contabiliza admisión: no preasigna memoria, limita RSS ni dimensiona automáticamente la RAM. Los 2 GiB requieren una decisión explícita. Consulta [admisión de cuerpos entrantes](/es/reference/inbound-body-admission/) para el ejemplo, la cola, la duración de las respuestas y por qué el valor predeterminado solo admite una carga completa de 512 MiB antes del análisis. |
+| `upstreamRequestCompression?` | `"off" \| "gzip" \| "zstd"` | `"off"` | Compresión opt-in de cuerpos de solicitud nativos ChatGPT Responses HTTP. Codex vuelve a enviar toda la conversación en cada turno, y cuando ese turno supera HTTP OpenCodex, de lo contrario la envía a `chatgpt.com` sin comprimir; en una salida medida o de larga distancia, ese es el costo dominante. Cuando se fijan, los cuerpos de cuerda de 1 KiB a 16 MiB enviados a `https://chatgpt.com/backend-api/codex/responses` y `/compact` se comprimen en el envío final y se etiquetan con `Content-Encoding`. WebSocket gira, cada otro destino, los cuerpos que ya declaran un `Content-Encoding`, y los cuerpos fuera de esa ventana de tamaño se envían sin cambios, y un fallo de códec cae de nuevo al envío sin comprimir. `zstd` es la codificación Codex CLI que se utiliza con este backend y es la opción más rápida para giros pesados de imagen; `gzip` (nivel 1) también está disponible. En una medición local, la historia de código pesado se redujo alrededor de 2-4 ×, mientras que las imágenes incrustadas apenas se reducen. La compresión se ejecuta de forma sincronizada en el bucle de eventos del proxy, por lo que cada envío elegible retrasa brevemente otras solicitudes en vuelo, del orden de 2-3 ms por MiB para texto en una CPU portátil reciente, más para datos incompresibles con `gzip`. Los límites de bytes tales como `maxUpstreamBodyBytes` todavía miden el cuerpo no comprimido. Configúrelo con `ocx config set upstreamRequestCompression zstd` (se rechaza un valor desconocido) o editando `config.json`, donde se ignora un valor desconocido, y luego reinicie el proxy para aplicar. |
+| `modelCacheTtlMs?` | `number` | `300000` | Ventana de frescura para la caché por proveedor `/models`. |
+| `cacheRetention?` | `"none" \| "short" \| "long"` | Anthropic de primera parte: `"long"`; otros puntos finales compatibles con Anthropic: `"short"` | Política de caché de prompts de Anthropic: deshabilitada, efímera de 5 minutos o extendida de 1 hora. Cuando no se establece, las solicitudes a `api.anthropic.com` (clave API o los grupos de cuentas OAuth) usan el TTL de 1 hora, porque los turnos de agente a menudo se pausan más de cinco minutos y una escritura de 1 hora (2× la entrada base en lugar de 1.25×) se amortiza en la primera reutilización; las puertas de enlace compatibles con Anthropic y los puntos finales de proveedores mantienen el TTL de 5 minutos porque su soporte de 1 hora no está documentado. En el paso nativo `/v1/messages`, los puntos de interrupción del llamante sin un `ttl` obtienen `"1h"` a menos que la solicitud fije algún punto de interrupción a `"5m"`, en cuyo caso se reenvía sin cambios. En una ruta traducida `/v1/messages`, los puntos de interrupción del llamante que piden todos `ttl: "1h"` significan `"long"` y cualquier `"5m"` explícito significa `"short"`. Un valor explícito siempre gana. Cambiar el TTL hace que cada conversación abierta escriba su caché una vez más, ya que las entradas de 5 minutos y 1 hora son independientes. Las estimaciones de costo valoran las escrituras informadas como de 1 hora a la tarifa de 1 hora. |
+| `tokenGuardian?` | `OcxTokenGuardianConfig` | Desactivado | Política opcional de actualización proactiva de OAuth y de calentamiento de cuentas de Codex. |
+
+Las cuentas de grupo con una ventana de uso incluida completa refrescan su evidencia de crédito a través del barrido de antecedentes existente a partir de los tres minutos de edad. Los encabezados de respuesta ordinarios no actualizan los saldos de crédito. Una lectura de metadatos fallida nunca extiende la vida útil de la evidencia de gasto de cinco minutos.
+
+
+A través de estas estrategias, el umbral efectivo de cada cuenta es su entrada `codexAccountAutoSwitchThresholds` cuando está presente, de lo contrario global `autoSwitchThreshold`. Una anulación cero desactiva solo el cambio de uso proactivo; la vinculación de inicio, el bloqueo duro, el tiempo de reutilización, las comprobaciones de derechos y la recuperación de fallas siguen vigentes.
+
+Establecer el umbral de conmutación de una cuenta en `0` no desactiva el bloqueo de la cuenta principal, la protección de inicio, los tiempos de reutilización o las verificaciones de elegibilidad del modelo. En el modo Pool, una credencial de llamada anclada que coincide con la cuenta principal observada no puede omitir el tiempo de reutilización aplicable de esa cuenta: se usa una alternativa elegible de Pool o se rechaza la solicitud. Las credenciales de llamadas no relacionadas no heredan el tiempo de reutilización de la cuenta principal; el comportamiento explícito de Direct no cambia.
+
+Los nombres de selector son etiquetas públicas elegidas por el usuario; opencodex no les asigna semántica de rol de cuenta. `codexAccountNamespaces` teclas son 1-64 caracteres, comenzando y terminando con una letra o número ASCII, con letras, números, `.`, `_` o `-` en el interior. Se rechazan los nombres de objetos JavaScript reservados. Cada valor es un identificador válido de cuenta de grupo (nunca interno `__main__`) o `"@main"` para la cuenta de escritorio Codex. Las colisiones de proveedor y reservadas `openai` / `combo` / `policy` se comprueban de forma insensible a mayúsculas; un alias combinado o de perfil de enrutamiento espaciado por nombres no puede reutilizar un selector como su prefijo de espacio de nombres, y los identificadores de grupo configurados o los objetivos del selector tampoco pueden reutilizar un selector. Mantenga los ID de cuenta y los correos electrónicos en privado; el selector es el nombre público. Véase [Configuración de enrutamiento](/es/reference/configuration/routing/) para el comportamiento de selección exacta y la precedencia.
+
+El control del panel de control Codex Auth posee mapas que tienen un campo explícito `codexAccountPickerEnabled`. Habilitar un mapa administrado vacío crea selectores seguros para la privacidad; las adiciones posteriores de la cuenta extienden ese mapa incluso mientras las filas del selector están ocultas, sin cambiar el nombre de los selectores existentes. Un mapa escrito a mano que omite la bandera permanece manual y nunca se expande automáticamente. Eliminar una cuenta mantiene su asignación para que las rutas exactas fallen mientras falta; agregar la misma identificación de cuenta restaura nuevamente el selector público existente en lugar de asignar uno nuevo.
+
+<a id="reserved-openai-providers"></a>
+
+## Proveedores reservados de OpenAI
+
+`openai` y `openai-apikey` son identificadores reservados fijos. `openai.codexAccountMode` es `"pool"` por defecto y selecciona entre las cuentas principales más añadidas; `"direct"` utiliza solo el inicio de sesión actual de la persona que llama/principal. API utiliza solo su llave o grupo de llaves API configurado. Utilice un modelo desnudo o `openai-apikey/<model>`; no hay respaldo de credenciales de ruta cruzada. API GPT-5.6 filas llevan 1,050,000 metadatos de entrada de contexto / 922,000 máximos, y las id virtuales Pro reescriben al modelo de cable base con `reasoning.mode: "pro"`.
+
+`openaiProviderTierVersion: 2` marca la proyección actual de un solo proveedor. Antes de migrar una configuración v1 enviada, opencodex crea `config.json.pre-openai-tiers-v2.bak` sin reemplazar una copia de seguridad diferente y reescribe los identificadores seleccionados conocidos de namespace a identificadores desnudos.
+
+<a id="gpt-6-astra-sol-luna-and-astra-minor"></a>
+
+### GPT-6 Astra, Sol y Luna
+
+`gpt-6-astra` usa la ruta de inicio de sesión de Codex; `openai-apikey/gpt-6-astra` usa su clave API. La disponibilidad sigue dependiendo de la cuenta aguas arriba. Astra nativo conserva los valores predeterminados que envía Codex: 272.000 de contexto, razonamiento `low` y la escalera `low` / `medium` / `high` / `xhigh` / `max` / `ultra`. Su descripción de Fast en el catálogo es **2x velocidad**; no es el multiplicador de facturación.
+
+Establecer `providerContextCaps.openai` a `922000` para optar por el grupo nativo en contexto largo; Astra se detiene en su propio techo **872,000**. Los modelos `providers.openai.modelContextWindows` y `modelAutoCompactTokenLimits` pueden reducir su ventana y su presupuesto de compactación suave. Por ejemplo, `modelAutoCompactTokenLimits: { "gpt-6-astra": 700000 }` reduce el valor predeterminado de la ventana larga de 784.800. Un límite de proveedor explícito más pequeño o límite de destino aún gana, incluidos los combos de alias nativos.
+
+Sin un límite rígido configurado, el catálogo nativo mantiene el `max_context_window` anunciado separado del `context_window` predeterminado (para Astra, 872,000 frente a 272,000). La compactación sigue utilizando la ventana por defecto efectiva. Para dar un modelo 500.000 tokens y los otros 300.000, establece `providers.openai.contextWindow` a `300000` y `providers.openai.modelContextWindows` a `{ "gpt-6.1-sol": 500000 }`. El valor por modelo anula la ventana del proveedor; `providerContextCaps.openai`, cuando está habilitado, sigue siendo un techo para cada modelo nativo y debe ser al menos `500000` para este ejemplo. La capacidad de cada modelo limita el resultado.
+
+La fila API tiene 1.050.000 contextos, 922.000 entradas máximas, 128.000 salidas máximas, entradas de texto/imagen y API esfuerzos de razonamiento a través de `max`. El control Ultra sintético enrutado de OpenCodex conserva su mapeo de esfuerzo de cable existente; no es un esfuerzo adicional de API. No hay alias Astra `-pro`. Utilice la configuración `fastMode` existente, o Codex `service_tier = "fast"` con `[features].fast_mode = true`; API `fast` y `priority` se aceptan ortografía rápida.
+
+[GPT-6 Sol y Luna](https://openai.com/index/introducing-gpt-6-sol-and-luna/) (anunciado el 22 de septiembre de 2026) son Codex nativos de inicio de sesión: `gpt-6-sol` y `gpt-6-luna`, mostrados como **GPT-6-Sol** y **GPT-6-Luna**. Al igual que Astra, se enumeran en cada instalación y no están cerradas en una lista de cuentas; si su cuenta no puede usarlas todavía, la solicitud aún se apaga y ve el error ascendente. Sus metadatos provienen de la lista Codex `/models`, que sirve a estas dos filas solo a `client_version` **0.155.0 o más tarde**; opencodex envía una copia de esas filas, por lo que aparecen incluso cuando su catálogo Codex instalado es anterior a ellas.
+
+| Modelo | Contexto predeterminado | Techo opt-in | Esfuerzo predeterminado | Razonamiento escalera |
+| --- | ---: | ---: | --- | --- |
+| `gpt-6-sol` | 272,000 | 872,000 | `medium` | `low` hasta `ultra` |
+| `gpt-6-luna` | 272,000 | 872,000 | `medium` | `low` a `max` (n.o `ultra`) |
+
+[GPT-6.1 Sol](https://openai.com/index/introducing-gpt-6-1-sol/) (anunciado el 29 de septiembre de 2026) es la actualización a GPT-6 Sol; Astra y Luna no obtuvieron un lanzamiento de 6.1. Está catalogado como `gpt-6.1-sol` (**GPT-6.1-Sol**), sin conexión como Sol, y su fila proviene del catálogo Codex, donde necesita `client_version` **0.153.0 o más tarde** y es el Codex predeterminado. GPT-6 Sol se queda en la lista.
+
+| Modelo | Contexto predeterminado | Techo opt-in | Esfuerzo predeterminado | Razonamiento escalera |
+| --- | ---: | ---: | --- | --- |
+| `gpt-6.1-sol` | 500,000 | 872,000 | `low` | `low` hasta `ultra` |
+
+OpenAI elevó el contexto predeterminado de GPT-6.1 Sol en Codex y Work de 272,000 a 500,000 tokens el 11 de octubre de 2026, por lo que la fila nativa ahora se establece en 500,000 y se compacta en 450,000. El catálogo Codex incluido todavía lee 272,000, por lo que opencodex establece el nuevo valor predeterminado. Una ventana configurada o tapa del proveedor todavía lo baja, y el opt-in de ventana larga todavía se detiene en 872,000: OpenAI describe el máximo del modelo como 1M sin decir cómo se mapea en los límites de ventana y entrada de Codex, por lo que opencodex no anuncia más que el techo que puede verificar.
+
+Las mismas palancas `providerContextCaps.openai`, `modelContextWindows` y `modelAutoCompactTokenLimits` se aplican como para Astra. En el OpenAI API (`openai-apikey`), `gpt-6.1-sol` tiene 1.050.000 contextos, 922.000 entradas máximas, 128.000 salidas máximas y esfuerzos `low` a `max`, con un precio de $2 entradas, $0.10 entradas en caché y $10 salidas por 1 millón de tokens (provoca más de 272K billetes a la tasa de contexto largo). GitHub Copilot, OpenRouter, Vercel AI Gateway, Kilo y OpenCode Zen también lo enumeran.
+
+Cuando OpenAI envía un modelo GPT que esta versión aún no conoce, agréguelo a través de config en lugar de esperar una actualización, de la misma manera que un nuevo id Claude pasa a `providers.anthropic.models`:
+
+```json
+{
+  "providers": {
+    "openai": {
+      "adapter": "openai-responses",
+      "authMode": "forward",
+      "baseUrl": "https://chatgpt.com/backend-api/codex",
+      "models": ["gpt-6-nova"]
+    }
+  }
+}
+```
+
+Cada una de las `gpt-*` id listadas allí en el proveedor de inicio de sesión Codex aparece como un modelo nativo (aquí **GPT-6-Nova**) con la escalera de razonamiento, el esfuerzo predeterminado y las modalidades de Sol GPT-6.1, un contexto predeterminado de 272,000 tokens y un techo de aceptación de 872,000 tokens. Elevar o estrechar con `modelContextWindows`, por ejemplo `"modelContextWindows": { "gpt-6-nova": 872000 }`. Nunca está cerrado por cuenta: si su cuenta no puede usar el modelo, la solicitud aún se apaga y verá el error de subida. Los identificadores que ya están incorporados se ignoran, y al eliminar un id de la lista se elimina el modelo. Un combo `nativeAlias` no puede apuntar a un identificador configurado.
+
+`gpt-6-astra-minor` (**GPT-6-Astra-Minor**) es una variante inédita de Astra. Está cerrado por cuenta: permanece oculto y las solicitudes se rechazan localmente, hasta que una lista autenticada de Codex para su cuenta lo enumera. Cuando aparece utiliza el contexto, la escalera y las modalidades de Astra.
+
+Consultado el 5 de septiembre de 2026:
+
+| Astra API (USD por millón de tokens) | Entrada | Entrada en caché | Escribir caché | Productos |
+| --- | ---: | ---: | ---: | ---: |
+| Estándar, hasta 272k de entrada | 10 | 1 | 12.5 | 50 |
+| Estándar, por encima de la entrada 272k | 20 | 2 | 25 | 75 |
+| Rápido, hasta 272k de entrada | 20 | 2 | 25 | 100 |
+| Rápido, por encima de la entrada 272k | 40 | 4 | 50 | 150 |
+
+El [Tabla de precios API](https://developers.openai.com/api/docs/pricing) revaloriza el **Toda la solicitud** por encima de 272k, contando los tokens en caché hacia el umbral. Las tasas de contexto rápido y largo se combinan; esto también se aplica a las filas GPT-5.6 API publicadas y sus selecciones virtuales Pro.
+
+Todas las estimaciones en dólares integradas usan los **precios de referencia de la API**, incluidas las rutas de inicio de sesión de Codex. Por lo tanto, Astra y GPT-5.6 usan las mismas tarifas base/caché de la API, el multiplicador **2x Fast** y las bandas publicadas de contexto largo en `openai` y `openai-apikey`. Los dos selectores Daybreak Blue siguen la referencia de la API de Sol. Estas son estimaciones comparativas, no facturas ni predicciones de saldo de crédito. Las anulaciones explícitas de precios de proveedor/modelo siguen teniendo prioridad.
+
+<a id="provider-namespace-aliases"></a>
+
+## Alias de espacio de nombres de proveedor
+
+Los proveedores pueden exponer una abreviatura incorporada, como `agy` para `google-antigravity`. Un nombre de proveedor configurado o alias explícito afirma que taquigrafía case-insensible; la taquigrafía incorporada de un proveedor diferente se suprime entonces en ambos nombres de catálogo y enrutamiento de alias. Por ejemplo, la configuración de un proveedor llamado `agy` mantiene los modelos de Google bajo `google-antigravity/<model>`, mientras que `agy/<model>` selecciona el proveedor configurado. Los nombres de proveedores canónicos todavía requieren una coincidencia de casos exacta, y los prefijos no reconocidos conservan el respaldo de enrutamiento de modelo existente.
+
+<a id="provider-entries-ocxproviderconfig"></a>
+
+## Entradas de proveedores (`OcxProviderConfig`)
+
+| Campo | Tipo | Descripción |
+| --- | --- | --- |
+| `adapter` | `string` | Uno de `openai-chat`, `openai-responses`, `anthropic`, `claude-cli`, `google`, `kiro`, `cursor`, `ollama-native`, `azure-openai` (o alias `azure`), `codebuddy`, `qoder`. |
+| `baseUrl` | `string` | URL de base ascendente API. La mayoría de los puntos finales fijos incorporados ignoran una falta de coincidencia; los ajustes preestablecidos de clave seguros contra colisiones conservan un destino personalizado con el mismo nombre más antiguo. |
+| `proxy?` | `string \| null` | Ruta de salida por proveedor. Omita que herede la decisión de proxy global; use `"direct"` o `null` para forzar la salida directa; o proporcione una URL proxy absoluta `http://`, `https://`, `socks5://` o `socks5h://`. Se rechaza una cadena vacía. |
+| `noProxy?` | `string \| string[]` | Destinos a los que este proveedor llega directamente, utilizando la sintaxis de patrón de host `NO_PROXY`. Una coincidencia pasa por alto tanto el propio proxy de este proveedor como un proxy global heredado. |
+| `requestPacing?` | `{ enabled, requestsPerMinute?, minIntervalMs?, maxConcurrentRequests?, models?, keySelection?, keys? }` | Indicadores opcionales de inicio de solicitud de salida del lado del cliente, separados del uso ascendente, la facturación y los indicadores de límite de solicitudes. RPM se convierte en un intervalo uniforme; `minIntervalMs` puede imponer un intervalo más largo. `maxConcurrentRequests` es un límite de enteros positivo en las solicitudes en vuelo. Una regla de proveedor o modelo puede usar el límite de concurrencia solo; los límites de proveedor se aplican a todos los modelos, mientras que las entradas `models` usan ID de modelo ascendente exactos (por ejemplo, `nvidia/llama-3.1-nemotron-ultra-253b-v1`) y solo pueden agregar retardo o concurrencia estrecha. Los esperas de cola no consumen el tiempo de espera del encabezado de respuesta ascendente. HTTP y el adaptador explícito `fetchResponse` / `runTurn` despachos están cubiertos. Un giro canónico Responses WebSocket con límite de concurrencia usa HTTP / SSE para que su arrendamiento pueda liberarse cuando el cuerpo de respuesta se complete, se equivoque o se cancele. Para los adaptadores `runTurn`, incluyendo Cursor, el cap cuenta los giros activos en lugar de los envíos físicos: RunSSE y BidiAppend pueden superponerse en un giro, mientras que otro turno espera. Seguimiento envía todavía obedecer intervalos de inicio. |
+| `requestPacing.keySelection?` | `"active"`, `"round-robin"` | Selección normal de la tecla de petición. El valor predeterminado `active` conserva la clave guardada y la rotación de fallas existente; `round-robin` distribuye las selecciones locales de solicitud a través de referencias de grupo de claves API elegibles sin cambiar la clave activa guardada. Equilibra las asignaciones, no los tokens o el costo. |
+| `requestPacing.keys?` | `{ requestsPerMinute?, minIntervalMs?, maxConcurrentRequests? }` | RPM uniformes por referencia clave, intervalo de inicio mínimo y límites de concurrencia, compartidos entre modelos. Estos componen con el proveedor y el modelo exacto de los límites superiores. Las referencias duplicadas comparten un cubo; las referencias separadas en un proyecto ascendente no implican una cuota independiente. El TPM y las cuotas diarias no se aplican. |
+| `upstreamHttpVersion?` | `"auto" \| "http1.1" \| "h1" \| "http2" \| "h2"` | Fije la versión HTTP utilizada para las solicitudes ascendentes a este proveedor. El valor predeterminado es `auto`, lo que permite que Bun negocie. Un pin explícito requiere un objetivo HTTPS y falla localmente cuando no puede ser honrado. Establecer `http1.1` cuando la transmisión HTTP/2 SSE de un proveedor se detiene en lugar de entregar eventos: el síntoma es una solicitud de transmisión de larga duración que no produce nada y, finalmente, expira. Para Cursor, `http1.1` / `h1` selecciona su transporte de compatibilidad `RunSSE` + `BidiAppend` para inferencia y también descubrimiento de modelos en vivo de pines. La gerencia `POST` / `PATCH` acepta `null` para volver a `auto`. |
+| `tlsProfile?` | `"antigravity-browser"` | **Usar bajo su propio riesgo.** Opt-in navegador-como TLS apretón de manos (a través de la dependencia opcional `wreq-js`) para el canónico `google-antigravity` OAuth proveedor. Cambia solo cómo se ve la conexión en el cable; no es un cliente oficial Google, y no cambia lo que permiten los términos de Google. Google aún puede detectar, limitar la tarifa, suspender o prohibir la cuenta con la que inició sesión, y solo usted conlleva ese riesgo. Está desactivado por defecto y solo se acepta con el adaptador Google, el modo Cloud Code Assist y los hosts canónicos HTTPS Antigravity de Google. Redirigir manual de estancia. La propia ruta `proxy` / `noProxy` del proveedor es transportada por el transporte TLS; una ruta que no puede mantener falla la solicitud en lugar de salir por otra ruta, que incluye cualquier ruta directa mientras se establece `HTTP_PROXY`, `HTTPS_PROXY` o `ALL_PROXY`. `GET /api/providers` reporta el estado del perfil como `pending`, `active` o `failed`. Omitir el campo mantiene el transporte normal Bun y nunca carga la dependencia. |
+| `responsesPath?` | `string` | Ruta de recurso relativa para solicitudes de clave-auth `openai-responses`. Debe comenzar con `/` y no contener esquema, consulta o fragmento. |
+| `chatCompletionsPath?` | `string` | Ruta de recurso relativa para `openai-chat` solicitudes, el espejo de `responsesPath` y sujeto a las mismas reglas de forma. Se necesita cuando uno de aguas arriba sirve Chat Completions y Responses bajo diferentes prefijos: una anulación de cable por modelo cambia el adaptador y deja solo `baseUrl`, por lo que sin esto, se enviaría una solicitud de chat opcional a la base Responses. Z.AI es el ejemplo enviado. |
+| `allowEncryptedV2AgentTasks?` | `boolean` | Deshabilitado por defecto. Confíe en un proveedor de claves directas `openai-responses` para consumir o retransmitir tareas subagente cifradas opacas V2 sin cambios. Las rutas elegibles omiten `agentTaskRecovery`; todas las demás rutas mantienen la recuperación existente o el comportamiento cerrado por error. OpenCodex no descifra, traduce ni recupera las tareas enviadas a través de esta opción. |
+| `projectResponsesLiteHostedSearchHistory?` | `boolean` | Por defecto. Configure el `true` booleano real para optar por este proveedor en la proyección con pérdida del historial de búsquedas alojadas no referenciadas para turnos ordinarios y solicitudes nativas de v2 `compaction_trigger` para que sea exacto canónico ChatGPT Codex `/responses` con intención explícita Responses Lite. Omission o `false` retiene la historia estructural; las cadenas y los números no son válidos. No permite Lite, cambiar el transporte, o afectar v1 `/responses/compact` nativo, público OpenAI API / otros destinos, o la proyección de compactación portátil / enrutado existente. Véase [Historial de búsquedas alojadas Lite](/es/reference/proxy-formats/#codex-native-ordinary-lite-hosted-search-history). |
+| `upstreamWebsocket?` | `boolean` | Transporte Responses WebSocket para `openai-responses` solicitudes (falso por defecto). Se honra solo para el flujo ascendente de origen `https://api.openai.com/v1`; los puntos finales de proveedor personalizado siempre usan un límite HTTP / SSE porque Bun no puede imponer un límite de mensaje de entrada WebSocket antes de asignar el mensaje completo. Para el proveedor canónico ChatGPT `openai`, omitiendo que mantiene el WebSocket ascendente en giros elegibles, un `false` explícito envía giros de transmisión sobre HTTP / SSE, y la administración del proveedor rechaza `true`; con `false`, la dirección e inyección nativas a mitad de giro no están disponibles. El campo es independiente de la configuración `websockets` orientada al cliente y no cambia ni el punto final ni la credencial. La llanura HTTP permanece en SSE; las rutas no Responses y las solicitudes `openai-chat` permanecen en HTTP. |
+| `supportsServiceTier?` | `boolean` | Repliegue de capacidad rápida canónica tri-estatal. `true` publica Fast en el catálogo, satisface los requisitos de enrutamiento de nivel de servicio, contribuye con una huella dactilar compatible y permite el modo rápido inyectar el valor de cable canónico del proveedor en un adaptador final compatible. `false` arranca el campo y nunca se inyecta, y las declaraciones exactas del modelo no pueden volver a abrirlo. Ausente deja al proveedor sin clasificar: el modo rápido no inyecta ni normaliza un valor canónico de la persona que llama, y los valores de la persona que llama obedecen el permiso de reenvío del cable final (`chatServiceTier` en Chat; passthrough en Responses). El registro clasifica canónico OpenAI (`true`), DeepSeek y Arca Volcengine (`false`); lo puso explícitamente sólo para puertas de enlace personalizadas que realmente soporten niveles. |
+| `responseTierAuthoritative?` | `boolean` | Si el nivel de respuesta puede confirmar o denegar Fast. Establezca explícitamente `false` para rutas con metadatos de respuesta no autoritativa; la omisión conserva el comportamiento existente. Esto no habilita Fast o cambia los parámetros de salida. Véase [Autoridad de nivel de servicio de respuesta](#response-service-tier-authority). |
+| `fastEnabled?` | `boolean` | Cambio de operador para el carril rápido del proveedor. `false` se apaga rápidamente (sin conmutación rápida, sin fila `--fast`, sin campo de cable rápido) y anula `supportsServiceTier`. `true` habilita un carril de las marcas de registro opt-in. Ausente mantiene el valor predeterminado del registro: desactivado para `anthropic` y `anthropic-apikey`, cuyo modo rápido gasta créditos de uso a un precio 2x, y sin cambios para todos los demás proveedores. La página Modelos del panel de control muestra una fila de Off/On para proveedores de suscripción voluntaria. |
+| `modelSupportsServiceTier?` | `Record<string, boolean>` | Capacidad exacta del modelo ascendente anula. El Exact `true` habilita el canonical Fast para ese modelo; el Exact `false` reduce los valores predeterminados del proveedor. Un nivel de proveedor explícito `supportsServiceTier: false` permanece cerrado por error y no se puede reabrir. Exact `true` no autoriza el reenvío de llamadas extranjeras en Chat. Los modelos no declarados vuelven a caer en el comportamiento de todo el proveedor. Administración `PATCH /api/providers` fusiona entradas y acepta `null` para borrar una. |
+| `chatServiceTier?` | `boolean` | Chat-wire en todo el proveedor opt-in para el reenvío de llamadas `service_tier` valores. En una ruta clasificada gobierna valores extranjeros como `flex`, no canónica propiedad de proxy Fast después de la validación de la capacidad; en una ruta no clasificada gobierna cada valor de llamada porque no se ha validado ninguna capacidad Fast. La capacidad del modelo exacto no autoriza el reenvío extranjero. Responses rutas conservan su comportamiento de reenvío de llamadas basado en la capacidad. |
+| `promptCacheKey?` | `boolean` | Opción de todo el proveedor `openai-chat` para reenviar `prompt_cache_key`. El adaptador reenvía la clave recibida sin inventarla, aunque no siempre procede del cliente: la conversión de Claude Messages obtiene una a partir de `metadata.user_id` o de un grupo de modelo, sistema y herramientas cuando no hay metadatos. Está desactivada por defecto salvo que lo indique el preajuste. Mistral la habilita según su [contrato de caché de instrucciones](https://docs.mistral.ai/studio/conversations/advanced/prompt-caching); un `false` explícito la desactiva. Habilítala solo si el proveedor documenta compatibilidad, porque una pasarela estricta puede rechazar ese campo con HTTP 400. |
+| `preserveResponsesReasoningContent?` | `boolean` | Por defecto para los proveedores personalizados. En **Proveedores → Configuración**, habilite **Replay razonamiento de texto plano** para un punto final personalizado Responses solo si acepta este historial. Esto envía un razonamiento previo de texto sin formato a ese punto final y puede aumentar el uso de tokens. Mantenga el contenido de razonamiento de texto plano en los elementos de razonamiento Responses reproducidos en lugar de borrarlo, incluida la entrada compacta nativa personalizada v1 (blanking es la regla del backend ChatGPT). Habilitar para aguas arriba cuyo contrato acepta la repetición de razonamiento, como DeepSeek o un Kimi autoalojado en vLLM. Los sobres `ocxr1` con proxy siempre se eliminan. Un proveedor `openai-responses` configurado manualmente sin él registra una advertencia por host la primera vez que se elimina el razonamiento de texto sin formato. `preserveReasoningContentModels` no afecta a este cable. |
+| `preserveResponsesInputItemIds?` | `boolean` | Por defecto. Preservar `input[].id` válido cuando `store: false` para relés de lanzador de confianza explícita que requieren identidad de turno. Responses proveedores ordinarios siguen eliminando las identificaciones; xAI La reparación del ID de llamada personalizada permanece activa. |
+| `preserveResponsesMessageMetadata?` | `boolean` | Por defecto. Preservar `internal_chat_message_metadata_passthrough` privado en elementos de entrada para relés de lanzador de confianza explícita, incluidas las solicitudes compactas nativas personalizadas v1. Esto reenvía metadatos privados de turno/sesión a ese destino; no habilite las puertas de enlace ordinarias. |
+| `dropResponsesReasoningItems?` | `boolean` | Elimine por completo los elementos Responses `reasoning` reproducidos de la entrada de continuación, incluidas las solicitudes compactas nativas v1 personalizadas, en lugar de reenviarlos con contenido en blanco. Esto es con pérdida: resúmenes, identificadores de ítems y `encrypted_content` van con ellos, por lo que no queda ningún ítem de razonamiento del turno anterior en la entrada reenviada. No elimina `previous_response_id`, por lo que un curso arriba que mantiene su propio estado de giro aún puede alcanzarlo. Habilitar solo para un upstream que rechaza la repetición de razonamiento directamente: el preajuste integrado Volcengine Ark Coding Plan lo establece porque las continuaciones de la herramienta validadas respondieron `400 InvalidParameter` de lo contrario. Establezca a `false` en ese proveedor para reenviar los elementos de razonamiento nuevamente. |
+| `disabled?` | `boolean` | Mantenga el proveedor en el disco, pero excluya el enrutamiento y los listados de modelos/catálogos. |
+| `apiKey?` | `string` | Clave API, una referencia `${ENV_VAR}` / `$ENV_VAR` o una referencia `keychain:<provider>` escrita por `ocx provider keychain <name> store`. Las referencias se resuelven en el momento de la solicitud. Véase [Almacenar claves en el llavero del sistema operativo](/es/reference/configuration/keychain/). |
+| `apiKeyTransport?` | `"x-api-key" \| "bearer"` | Anthropic estilo de encabezado de clave. Predeterminados a `x-api-key` nativos; válido solo para proveedores de llave-auth `anthropic`. |
+| `apiKeyPool?` | `ApiKeyPoolEntry[]` | Grupo de varias claves. `apiKey` refleja la entrada activa; cada elemento tiene `id`, `key`, `label` opcional y `addedAt` numérico opcional. |
+| `apiKeyPoolStrategy?` | `"round-robin" \| "fill-first" \| "quota"` | Cómo se elige una llave caliente **antes** el primer intento cuando la llave comprometida ya se está enfriando. Omitido mantiene la rotación reactiva solamente: el grupo se mueve después de un 429 o 401 y no antes. `round-robin` toma la siguiente clave en el grupo, `fill-first` mantiene la primera elegible, y `quota` prefiere la clave con el mayor margen restante, cayendo a `fill-first` para un proveedor cuya cuota por clave es desconocida. El orden por cuota usa evidencia de inferencia reciente, vinculada a la credencial y ya presente en la caché local; las ventanas solo informativas, como la búsqueda de Synthetic y los presupuestos de Mistral, no ordenan claves. La evidencia de inferencia ausente o no disponible es desconocida y la selección no realiza consultas. Una clave comprometida saludable nunca se anula, por lo que se mantiene una selección manual de la clave. |
+| `defaultModel?` | `string` | Modelo utilizado cuando se selecciona este proveedor sin un modelo explícito. |
+| `models?` | `string[]` | Lista de modelos de semillas/retroceso. Con `liveModels: false`, una lista `models` no vacía es seguida por `retainModels`; una lista `models` vacía u omitida en su lugar siembra `defaultModel` (si está configurada), luego `retainModels`, eliminando los ID duplicados en el orden primero visto. |
+| `liveModels?` | `boolean` | Busca el catálogo en vivo en start/sync (por defecto `true` ). Los proveedores personalizados usan `${baseUrl}/models`; los complementos pueden usar una URL y un filtro de registro. |
+| `modelDiscovery?` | `{ skipInvalidRows?: boolean }` | Compatibilidad de descubrimiento para gateways con filas inválidas en `/models`. Por defecto una fila inválida rechaza la lista completa y se indica su posición y el total de errores. `skipInvalidRows: true` omite filas que no sean objetos o tengan un id ausente, no textual, vacío o inválido; un aviso único cuenta las omitidas sin mostrar su contenido. Todas cuentan para límites de bytes y filas. Deduplicación, filtros y eliminación del prefijo se aplican a las restantes; si no queda ninguna tras omitir filas, se rechaza la lista. Solo listas de estilo OpenAI; los analizadores específicos conservan sus reglas. Es distinto de `modelDiscovery` en la raíz, que guarda la política de modelos nuevos. |
+| `selectedModels?` | `string[]` | Catálogo allowlist después del descubrimiento. No vacía expone solo esos ids; vacía u omitida expone todos los modelos descubiertos. |
+| `retainModels?` | `string[]` | Los identificadores se mantienen en el catálogo incluso cuando el descubrimiento en vivo los omite. No necesitan repetirse en `models`. Vacío u omitido mantiene el comportamiento de hoy. |
+| `modelDisplayNames?` | `Record<string, string>` | Etiquetas persistentes de presentación, indexadas por el ID exacto que usa el proveedor. Tienen prioridad sobre los metadatos del catálogo y sobreviven a las actualizaciones de descubrimiento y edición. No cambian la autenticación, el adaptador, la facturación, la construcción de solicitudes, el selector enrutado `provider/model` ni el ID enviado de un modelo ya conocido. Hay una excepción de enrutamiento: si un selector directo `provider/model` no coincide con ningún ID, alias o ID de `retainModels` conocido (por ejemplo, mientras el catálogo en vivo aún no se ha cargado), una clave cuyo formato codificado coincida se envía como ID nativo. Las claves distinguen mayúsculas y minúsculas; los ID desconocidos se conservan para aplicarles su etiqueta si vuelven a aparecer. Se admiten como máximo 2.000 entradas, igual que el límite de descubrimiento. |
+| `contextWindow?` | `number` | Valor de contexto alternativo para todo el proveedor si faltan metadatos; si existen, actúa como un tope que conserva los valores menores del proveedor. Los valores del registro no pueden superar un límite configurado inferior; las entradas explícitas de `modelContextWindows` tienen prioridad. La página Modelos lo muestra separado de `providerContextCaps`. |
+| `modelContextWindows?` | `Record<string, number>` | Por-modelo contexto fallbacks/caps. Estos anulan `contextWindow`: una ventana desconocida utiliza el valor configurado, mientras que los metadatos en vivo más pequeños siguen siendo autorizados. |
+| `inferContextWindow?` | `boolean` | Solo proveedores personalizados, por defecto desactivado. `true` llena una ventana faltante de metadatos de ID de modelo agrupados ([detalles](#context-windows-on-custom-providers)); el valor es una estimación, no una capacidad de retransmisión verificada. |
+| `modelContextTiers?` | `Record<string, "default" \| "long_context">` | Por modelo de nivel ascendente para `github-copilot`. `long_context` envía `contextTier: "long_context"`. Los metadatos del catálogo crecen solo con un valor exacto por modelo `modelContextWindows` que documenta la ventana compatible; ese valor gana antes de la limitación del proveedor. Un modelo desconocido mantiene su ventana observada. Las solicitudes passthrough no configuradas retienen un campo `contextTier` suministrado por el llamante en cualquier proveedor. |
+| `modelInputModalities?` | `Record<string, string[]>` | Sugerencias de entrada por modelo, como `["text"]` o `["text", "image"]`. |
+| `modelMaxInputTokens?` | `Record<string, number>` | Límites de entrada máximos positivos por modelo utilizados para las sugerencias de autocompactación del catálogo. |
+| `modelAutoCompactTokenLimits?` | `Record<string, number>` | Presupuestos de autocompactación suaves positivos por modelo. Los valores solo pueden reducir la envolvente efectiva del 90% de contexto/entrada máxima y se omiten cuando no se resuelve ninguna ventana de contexto. Para el canónico `openai`, las claves deben ser IDs de modelo nativos compatibles exactos sin prefijos de proveedor o selector de cuenta. El proveedor PATCH combina entradas; establece una clave en `null` para eliminarlo o todo el campo en `null` para borrar el mapa. Estas `null` lápidas son sólo de pátch. |
+| `minMaxOutputTokens?` | `number` | Piso entero positivo opcional para presupuestos `max_output_tokens` positivos explícitos en rutas `azure-openai` / `azure` Responses. Desactivar conserva la tapa de la persona que llama. Configurarlo autoriza el aumento de un límite más pequeño, lo que puede aumentar el uso de salida. Los presupuestos de solicitudes omitidas o no válidas no se modifican. |
+| `defaultMaxOutputTokens?` | `number` | Límite alternativo de `openai-chat` para solicitudes sin `max_output_tokens`. Un proveedor `anthropic` sin este valor usa el límite del registro para el modelo Claude servido, 64000 en `api.anthropic.com`, u 8192 para un modelo no registrado. Un valor explícito aquí o en `modelMaxOutputTokens` prevalece. |
+| `modelMaxOutputTokens?` | `Record<string, number>` | Presupuestos de respaldo positivos por modelo `openai-chat`; las coincidencias exactas / patrón superan al predeterminado del proveedor. |
+| `modelCosts?` | `Record<string, ProviderCostOverlay>` | Precios de visualización por modelo (USD por tokens de 1 millón), tecleados por el ID de modelo ascendente exacto de ese proveedor, no un identificador de proveedor o una etiqueta `provider/model` enrutada, p. `{ "deepseek-v4-flash": { "input": 0.14, "output": 0.28, "cacheRead": 0.0028, "cacheWrite": 0 } }`. Cualquier ID de modelo es una clave válida: los proveedores personalizados pueden apuntar a cualquier punto final compatible con OpenAI a través del adaptador `openai-chat`, y los ID de proveedores locales o internos funcionan incluso cuando están ausentes de los catálogos incorporados. Los precios configurados por el usuario ganan sobre los catálogos incorporados en los registros `~$` y las estimaciones de uso; las entradas históricas se revaloran desde la superposición actual, por lo que editar un precio puede pasar de los totales. La orden de reserva es el usuario `modelCosts` → corrección oficial exacta → catálogo → precio esperado superposición → vendedor nivel de modelo de reserva, y una entrada de usuario explícita de todo cero significa una estimación de cero conocido; borrar esa entrada de modelo para restaurar la fijación automática de precios. Los metadatos de catálogo de todo cero todavía fallan. Cada tasa debe ser un número finito no negativo como máximo 1.000.000 (USD por 1M tokens); las filas fuera de rango son rechazadas por el límite de administración y se eliminan en la carga. Estimación del tiempo de visualización solamente: las superposiciones nunca afectan el enrutamiento, la selección de cuentas, las cuotas o la facturación. |
+| `headers?` | `Record<string, string>` | Encabezados adicionales. El sidecar clásico de búsqueda OpenAI elimina `x-openai-internal-codex-responses-lite` sin distinguir mayúsculas después de combinar encabezados configurados y seleccionados; conserva los demás admitidos. Se rechazan autorización, cookies, claves API, saltos de línea y nombres inválidos. Descubrimiento, pruebas y diagnósticos mediante el wrapper de salida, incluida la consulta show de Ollama, usan `User-Agent: opencodex` salvo User-Agent configurado o del preajuste. Un relay experimental puede negociar entrega anticipada con `x-opencodex-tool-completion: block-stop-v1`: exige membresía de turno autenticada y persistente del shell, reconocimiento del mismo encabezado por el relay y marcadores de finalización asociados a la llamada exacta. No lo configures en otros proveedores. Solo afecta a llamadas estructuradas aptas; un error o cancelación posterior no puede retirar una llamada ya entregada. |
+| `forwardClientHeaders?` | `string[]` | Solo `openai-responses`: copia metadatos entrantes indicados cuando el proveedor no haya fijado el encabezado. Rechaza y filtra credenciales y transporte: `Authorization`, cookies, claves API, `Content-Type`, `Content-Length`, `Host`, `x-oai-attestation`. Los nombres no distinguen mayúsculas ni pueden repetirse. `headers` prevalece; sigue usándose el `User-Agent` del cliente si no hay otro. Solo admite `originator`, `x-client-request-id`, `x-codex-app-version`, `user-agent`, `x-codex-window-id`, `x-codex-installation-id`. |
+| `supportsNativeCompactionTrigger?` | `boolean` | Solo `openai-responses`: declara soporte para elementos de entrada nativos v2 `compaction_trigger`. Predeterminados para puertas de enlace no canónicas; preserva la compactación nativa en lugar de solicitar un resumen de texto portátil. Independiente de las capacidades de reproducción de v1 y blob. |
+| `supportsNativeCompactEndpoint?` | `boolean` | `openai-responses` solamente: declara soporte para v1 nativo `POST /responses/compact`. Predeterminados desactivados para puertas de enlace personalizadas. Las rutas clave/local/directas usan el URL Responses del proveedor más `/compact` y su autenticación de transporte normal; OAuth mantiene la compactación enrutada y su ciclo de vida de credenciales existente. No habilita los disparadores v2 ni otorga la identidad oficial OpenAI. |
+| `decodesNativeCompactionBlobs?` | `boolean` | Declare que este destino puede reproducir blobs de compactación nativos, no `ocx1:`. Independientemente de cualquier capacidad de generación; un desajuste de proveedor de servicio conocido todavía degrada el texto cifrado extraño. Habilite solo después de probar el compacto y una vuelta posterior en el mismo backend. |
+| `openRouterRouting?` | `OpenRouterProviderRouting` | Predeterminado OpenRouter `order`, `only` y `allowFallbacks` preferencias; válido sólo para canónica OpenRouter con `openai-chat`. |
+| `modelOpenRouterRouting?` | `Record<string, OpenRouterProviderRouting>` | El identificador de modelo exacto reemplaza la preferencia OpenRouter de todo el proveedor. |
+| `vercelGatewayRouting?` | `VercelGatewayRouting` | Preferencias predeterminadas de Vercel AI Gateway `order`, `only` y `sort` (`"cost"` + `"ttft"` + `"tps"`); válidas solo para la puerta de enlace canónica de Vercel AI con `openai-chat`. |
+| `modelVercelGatewayRouting?` | `Record<string, VercelGatewayRouting>` | El ID de modelo exacto reemplaza la preferencia de Vercel AI Gateway para todo el proveedor. |
+| `authMode?` | `"key" \| "forward" \| "oauth" \| "local"` | Modo de autenticación (por defecto `key` ). OAuth /las credenciales de suscripción se almacenan fuera de `config.json`; `local` se limita a los proveedores cuya entrada en el registro lo permita. |
+| `codexAccountMode?` | `"pool" \| "direct"` | Canonical `openai` solamente; valores predeterminados a Pool. Direct evita el estado del grupo. |
+| `refreshPolicy?` | `"proactive" \| "lazy-only" \| "disabled"` | Anule la política de Token Guardian de este proveedor OAuth. |
+| `reasoningEfforts?` | `string[]` | Etiquetas de razonamiento Codex para todo el proveedor para anunciar y enviar. Para los proveedores de adaptadores `google`, una escalera configurada también afirma la capacidad `thinkingLevel`: las solicitudes directas y de no imagen de Vertex envían el esfuerzo seleccionado como `generationConfig.thinkingConfig.thinkingLevel`, mientras que Cloud Code Assist utiliza su ruta específica de envolvente. |
+| `modelReasoningEfforts?` | `Record<string, string[]>` | Etiquetas por modelo. Una lista vacía oculta el control del esfuerzo. Al igual que con `reasoningEfforts`, cada escalera configurada para el adaptador `google` declara la capacidad `thinkingLevel`; las solicitudes directas y de Vertex que no son de imagen usan la ruta plana de Gemini, mientras que Cloud Code Assist la envía dentro del sobre de su solicitud. Un adaptador que envía su propia tabla por modelo (actualmente `command-code`) permite que esa tabla gane en el cable para los modelos que conoce, así que ajuste `modelReasoningEffortsAuthoritative` también para ampliar dicha fila. |
+| `modelReasoningEffortsAuthoritative?` | `boolean` | Trate el `modelReasoningEfforts` de este proveedor como autorizado en el cable, no solo en el catálogo. Sin él, un adaptador que envía su propia tabla de esfuerzo por modelo (actualmente `command-code`) anuncia su escalera ensanchada en el selector y luego quita el peldaño adicional al salir. Es opt-in porque los ajustes preestablecidos se siembran con la tabla enviada, por lo que una fila almacenada por sí sola no puede probar que la escribió en lugar de una versión anterior. Con él establecido, un peldaño que el flujo ascendente rechaza se devuelve como ese error en lugar de volver a intentarlo en silencio sin el esfuerzo, lo pediste, por lo que ves la respuesta. |
+| `modelSuppressSyntheticMax?` | `Record<string, boolean>` | Interruptor por modelo solo para catálogo. `true` evita que OpenCodex agregue un peldaño `max` sintético faltante mientras retiene un `max` declarado por el proveedor y continúa agregando `ultra` a las escaleras con capacidad de razonamiento. Una fila conservada que ya contiene `max` lo mantiene hasta que el descubrimiento saludable reconstruye esa fila, porque el catálogo no persiste si un `max` más antiguo era sintético. Si un valor predeterminado configurado nombra un `max` suprimido que falta, el catálogo vuelve al peldaño real más alto debajo de él. Codex utiliza la misma membresía de escalera para el selector y la validación explícita del esfuerzo `spawn_agent`, por lo que una creación explícita de subagente con `max` puede fallar en el lado del cliente antes de la sujeción proxy; `ultra` sigue siendo el camino de arnés soportado. |
+| `modelSupportsReasoningSummaries?` | `Record<string, boolean>` | Establezca un modelo en `false` para detener los resúmenes de publicidad y los campos de entrega de resumen de tira. |
+| `modelReasoningSummaryDelivery?` | `Record<string, "sequential" \| "sequential_cutoff" \| "concurrent" \| "concurrent_cutoff">` | Enum de entrega por modelo Responses; reescribe un campo de entrega existente. |
+| `thinkingDisplay?` | `"auto" \| "summarized" \| "updates" \| "omitted"` | Política de `thinking.display` adaptativo de Anthropic. Ausente o `auto` usa `updates` para Opus 5.5 nativo en `api.anthropic.com` y `summarized` para otros modelos adaptativos. `summarized` fuerza resúmenes; `updates` solo se respeta en Opus 5.5 nativo y equivale a `auto` en los demás. `omitted` omite display y produce pensamiento oculto con bloques de solo firma: un cliente Chat solo recibe latidos mientras piensa. `reasoning.summary` explícito `concise` o `detailed` fuerza `summarized`. Editor y `PATCH /api/providers` aceptan `null` para borrar. Escritura directa: `ocx config set providers.<name>.thinkingDisplay summarized`. |
+| `modelThinkingDisplay?` | `Record<string, "auto" \| "summarized" \| "updates" \| "omitted">` | Anula `thinkingDisplay` por ID original exacto, por ejemplo `claude-opus-5-5`. Cada entrada prevalece, incluso `auto` para restablecer la política integrada de ese modelo; sin entrada se usa el valor del proveedor. Se aplica la misma degradación de `updates` a `auto` en modelos no aptos. `PATCH /api/providers` combina entradas y acepta `null` para una o todo el mapa. |
+| `modelAdapters?` | `Record<string, string>` | Cambia por modelo entre `openai-chat` y `openai-responses` en pasarelas que admiten ambos protocolos. Las entradas explícitas prevalecen sobre el registro. OpenCode Go selecciona Responses para `gpt-5.6-luna` y mantiene el protocolo documentado de los demás modelos. DeepSeek puede usar Responses nativo para `deepseek-v4-flash`. Alibaba Token Plan (Pekín) fija `qwen3.8-flash`, `qwen3.7-plus` y `glm-5.3` a su API Responses nativa solo para solicitudes entrantes de Responses, verificada en esa pasarela incluida la reproducción de razonamiento en texto plano; Chat y Anthropic mantienen Chat, y el resto de la familia puede activarse aquí. GitHub Copilot usa exclusivamente Responses de forma predeterminada para `gpt-5.3-codex`, `gpt-5.4`, `gpt-5.4-mini`, `gpt-5.5`, `gpt-5.6-luna`, `gpt-5.6-sol`, `gpt-5.6-terra`, `gpt-6.1-sol`, `gpt-6.1-terra`, `gpt-6-astra`, `grok-4.5`, `grok-4.6`, `mai-code-1.1-flash` y `mai-code-1-flash-picker`, porque rechazan `/chat/completions` para tráfico de agentes. Los modelos sin predeterminado incorporado, como `gpt-5.4-nano`, pueden activarse aquí. Los proveedores fijados a un solo protocolo y el reenvío canónico a ChatGPT rechazan las anulaciones. |
+| xAI Chat Completions (panel / CLI) | interruptor | Las solicitudes Responses con OAuth de Grok 4.5/4.6 usan Responses de forma predeterminada. Las anulaciones de Chat existentes se migran una vez al actualizar; las elecciones posteriores de Chat se conservan. Actívelo para seleccionar Chat en ambos modelos y desactívelo para seleccionar Responses. CLI: `ocx provider edit xai --xai-chat on` o `--xai-chat off` (requiere un proxy en ejecución). «Mixto» significa que actualmente solo un modelo usa Chat. Las demás anulaciones y la política de niveles no cambian. Los valores predeterminados de clave API y de Chat/Anthropic traducido no cambian. Grok 4.7 usa Responses de forma predeterminada en OAuth a través del valor de cable predeterminado de su registro y puede usar Chat mediante una anulación explícita de `modelAdapters["grok-4.7"] = "openai-chat"`. |
+| `xaiResponsesXSearch?` | `boolean` | Deshabilitado por defecto. En un xAI Responses destino, añade el proveedor alojado `x_search` declaración solo cuando una vida `web_search` La herramienta sobrevive a la normalización de la solicitud final. Las declaraciones existentes no están duplicadas, llamante `tool_choice`/`allowed_tools` Los selectores nunca se amplían, y esto está separado del sidecar de la búsqueda web. `search.xSearch` opciones. |
+| `modelPreferHostedTools?` | `Record<string,string[]>` | Opción de modelo exacto para puertas de enlace Responses no directas que reservan un espacio de nombres de herramienta alojada. Actualmente solo acepta `["image_generation"]`; un modelo coincidente debe usar el `openai-responses` cable y soporte de esa herramienta alojada. Elimina el cliente en colisión `image_gen` declaraciones y reescribe sus selectores para preservar la elección de la herramienta de llamadas. Para OpenAI virtual API `-pro` modelos, el ID público seleccionado se empareja primero y el ID de modelo de cable base resuelto es un respaldo. `modelAdapters` primero resuelve el ID público, luego el ID base; la segunda resolución determina el cable final. Otros modelos conservan el comportamiento normal de alias. |
+| `annotateEmptyToolOutputs?` | `boolean` | Reemplace un resultado de herramienta presente pero vacío con un marcador corto antes de que llegue al modelo, de modo que un resultado en blanco no se lea como faltante. Se aplica a cadenas en blanco y matrices de partes de solo texto; nunca se tocan imágenes, archivos y partes cifradas. Predetermina a `true` para DeepSeek desde el registro integrado y no se establece de otro modo. Establecer `false` para excluir a un proveedor - un `false` explícito se conserva en ediciones posteriores que omiten el campo. `PATCH /api/providers?name=<provider>` acepta `true`, `false` o `null` para borrar la anulación y volver al comportamiento predeterminado del registro. |
+| `promoteAdditionalTools?` | `boolean` | Controla si los elementos `additional_tools` de Codex Desktop se convierten en declaraciones `tools` de nivel superior y se retira su envoltorio de `input`. Se activa automáticamente para OpenCode Go y xAI (`api.x.ai` y `cli-chat-proxy.grok.com`), salvo con `authMode: "forward"`, donde requiere `true` explícito. Otros gateways estrictos de terceros compatibles con OpenAI que devuelvan HTTP 422 por tipos de elemento desconocidos en `input` pueden activarlo aquí. `PATCH /api/providers?name=<provider>` acepta un booleano o `null` para borrar la opción. |
+| `unsupportedHostedTools?` | `string[]` | La herramienta alojada declara que este destino Responses rechaza, por lo que se eliminan de `tools`, desde el cliente-cargado `additional_tools`, y desde `tool_choice` En lugar de ser reenviado y rechazado de origen. Utilícelo para una puerta de enlace compatible con OpenAI con un conjunto de capacidades más estrecho — que acepte solicitudes simples Responses y `function` herramientas, pero devuelve HTTP 400 para alojado `web_search` — para que un mensaje de solo texto no falle por una capacidad que nunca necesitó. Acepta solo nombres de tipo de herramienta alojados (`web_search`, `web_search_preview`, `file_search`, `computer_use_preview`, `computer_use`, `code_interpreter`, `image_generation`, `image_gen`, `mcp`, `tool_search`, `local_shell`, `x_search`); un nombre no reconocido es rechazado en lugar de silenciosamente ignorado. Las variantes de ortografía de una capacidad se aliased, así que `["web_search"]` También niega `web_search_preview`. Un proveedor no puede negar una herramienta alojada aquí y preferirla en `modelPreferHostedTools`. Xiaomi MiMo Responses destinos (`xiaomimimo.com` y sus subdominios, incluyendo `api.xiaomimimo.com` y `token-plan-cn.xiaomimimo.com`) automáticamente tira `web_search` y `web_search_preview` conservando las herramientas de función; no se necesita ninguna declaración para estos hosts. Esto es independiente de `supportsResponsesCustomTools`; establece ambos para una puerta de enlace que también rechaza las herramientas personalizadas nativas. `PATCH /api/providers?name=<provider>` Acepta una matriz o `null` No lo puedo evitar. |
+| `unsupportedHostedToolsWithClientTools?` | `string[]` | Herramientas alojadas que se eliminan solo si hay herramientas del cliente en la misma solicitud: `function`, `custom` o `namespace` con miembros, en `tools`, `additional_tools` o un resultado `tool_search_output`. Se retiran de esos campos y de `tool_choice` como con `unsupportedHostedTools`; forzar una eliminada pasa a `"none"`. Las solicitudes con solo herramientas alojadas las conservan. Úsalo para gateways que rechazan HTTP 400 al combinar funciones y búsqueda alojada, por ejemplo `Please enable tool_config.include_server_side_tool_invocations to use Built-in tools with Function calling.`. Admite los mismos nombres y alias que `unsupportedHostedTools`; rechaza desconocidos. Esa lista siempre prevalece y tampoco puede preferirse aquí una herramienta mediante `modelPreferHostedTools`. Ausente o `[]` no cambia nada; `PATCH /api/providers?name=<provider>` acepta lista o `null`. |
+| `reasoningEffortMap?` | `Record<string, string>` | Alias de cable de todo el proveedor para etiquetas de razonamiento. Asignar una etiqueta a `"__omit__"` para eliminar el campo de razonamiento de la solicitud aguas arriba por completo: `reasoning_effort` en un cable compatible con OpenAI, y el campo nativo `think` de Ollama en el adaptador nativo Ollama (#2356). |
+| `modelReasoningEffortMap?` | `Record<string, Record<string, string>>` | Alias de cable por modelo para etiquetas de razonamiento. Asignar una etiqueta a `"__omit__"` para eliminar por completo el campo de razonamiento de la solicitud ascendente. |
+| `reasoningWireFormat?` | `"gateway-object"` | Para pasarelas compatibles con OpenAI que aceptan `reasoning: { enabled, effort }` en lugar de `reasoning_effort`. En destinos Responses personalizados también autoriza explícitamente la extensión OCX `reasoning.enabled`; los demás destinos Responses eliminan ese campo interno. Declarar que el modelo puede razonar no activa este formato. ClinePass lo configura automáticamente. Si se conserva el destino al guardar el proveedor, se conserva el ajuste; consulta [Qué conserva un guardado](#what-a-provider-save-keeps). `PATCH` acepta `"gateway-object"` o `null` para borrarlo. |
+| `noReasoningModels?` | `string[]` | Modelos que rechazan los parámetros de razonamiento/pensamiento. |
+| `noTemperatureModels?` | `string[]` | Modelos que rechazan el `temperature` especificado por la persona que llama. |
+| `noTopPModels?` | `string[]` | Modelos que rechazan el `top_p` especificado por la persona que llama. |
+| `noStopModels?` | `string[]` | Modelos que rechazan el `stop` especificado por la persona que llama. El adaptador `openai-chat`, el paso de Chat y el paso de Responses omiten el campo para esos identificadores. El preajuste incorporado `xai` enumera sus modelos de razonamiento (`grok-4.7`, `grok-4.6`, `grok-4.5`, `grok-4.3`, `grok-4.20-multi-agent-0309`, `grok-4.20-0309-reasoning`, `grok-build-0.1`), que xAI lo rechaza; `grok-4.20-0309-non-reasoning`, `grok-composer-2.5-fast` mantener llamante `stop`. |
+| `noPenaltyModels?` | `string[]` | Modelos que rechazan penalizaciones de presencia/frecuencia. El preajuste `xai` incorporado enumera sus modelos de razonamiento (`grok-4.7`, `grok-4.6`, `grok-4.5`, `grok-4.3`, `grok-4.20-multi-agent-0309`, `grok-4.20-0309-reasoning`, `grok-build-0.1`), que xAI documentos como rechazarlos; los identificadores no razonadores mantienen las sanciones de la persona que llama. |
+| `noStructuredOutputModels?` | `string[]` | ID de modelo exactos cuyo punto final `openai-chat` rechaza `response_format`. Solo una coincidencia exacta del modelo solicitado omite el campo; la traducción de salida estructurada permanece habilitada para cada otro modelo `openai-chat`. |
+| `noJsonSchemaModels?` | `string[]` | ID de modelo exactos cuyo punto final `openai-chat` rechaza un `json_schema` `response_format` pero aún acepta `json_object`. Tal solicitud se degrada a `json_object` en lugar de ser descartada, por lo que una persona que llama por JSON todavía obtiene JSON. `noStructuredOutputModels` gana cuando un modelo está en ambas listas. Los presets `opencode go` y `opencode zen` envían esto para sus rutas DeepSeek. |
+| `foldDeveloperRoleToSystem?` | `boolean` | Indica si un destino `openai-chat` admite el rol `developer`. Si se omite `foldDeveloperRoleToSystem`, se envía `system`; con `true`, se envía `system`; con `false`, se envía `developer`. Omitirlo significa que todavía no se ha registrado el comportamiento del destino; `true` indica que rechaza el rol y `false` que lo acepta. Salvo que se active la [compatibilidad con un único mensaje de sistema inicial](/es/guides/lm-studio/) mediante `singleLeadingSystemMessage`, el mensaje conserva su posición y solo cambia el rol. Un destino incompatible responde `400 role 'developer' is not allowed` antes de comenzar el turno, por lo que la opción no registrada usa el rol de sistema. Guardar en el mismo destino conserva el ajuste omitido; consulta [Lo que conserva un guardado de proveedor](#what-a-provider-save-keeps). `PATCH` acepta un booleano o `null` para borrarlo. |
+| `omitReasoningEffortWithToolsModels?` | `string[]` | ID de modelo exactos `openai-chat` que aceptan un campo de esfuerzo de razonamiento en un turno ordinario pero lo rechazan una vez que las herramientas de función están presentes. El modelo mantiene su escalera de esfuerzo anunciada; OpenCodex omite el campo de cable solo para solicitudes de soporte de herramientas y se aplica el valor predeterminado ascendente. Más estrecho que `noReasoningModels`, que quita el razonamiento de cada solicitud y le cuesta al modelo su selector por completo. Un proveedor de guardar que mantiene el destino lo mantiene; ver [Lo que un proveedor guarda](#what-a-provider-save-keeps). |
+| `parallelToolCalls?` | `boolean` | Alternar las llamadas de herramientas paralelas. OpenAI Chat está activado por defecto; los adaptadores que no son de chat solo se anuncian en `true` explícito. |
+| `terminalContinuationGuard?` | `boolean` | Opte por un proveedor `openai-chat` a una re-pregunta interna limitada cuando un giro accionable anuncia el trabajo, luego se detiene limpiamente sin una llamada de herramienta. Por defecto a `false`; explícito `false` se comporta como omisión. Se excluyen los intentos combinados y los giros de compactación enrutados, y los adaptadores que no son `openai-chat` ignoran esta opción. |
+| `responsesItemIdRepair?` | `{ message?: string[]; reasoning?: string[]; repairMissingTerminalIds?: boolean; repairInvalidIds?: boolean }` | Deshabilitado por defecto aguas abajo SSE reparación para ids de marcador de posición exacto, ids de terminal faltantes, y (con `repairInvalidIds` ) mensaje / ids de razonamiento faltantes el prefijo canónico `msg_` / `rs_`. Los identificadores de llamada de función nunca se reescriben. El DeepSeek incorporado habilita los dos últimos por defecto. |
+| `responsesSnapshotRepair?` | `boolean` | Deshabilitado por defecto de cara al cliente de reparación para escasa Responses instantáneas del ciclo de vida en SSE y JSON. Rellena el estado canónico faltante, la salida y los metadatos de la herramienta, mientras que la inspección en bruto y la persistencia permanecen sin cambios. |
+| `messagePhaseInference?` | `boolean` | Desactivado por defecto. En streams Responses de paso directo, infiere las fases de mensaje ausentes al completarlo: otro evento de protocolo posterior determina `commentary`; un evento terminal o `[DONE]`, `final_answer`. Conserva las fases explícitas commentary/final_answer; infiere valores nulos o desconocidos igual que los ausentes. Los keepalives no determinan la fase. Las instantáneas completed/incomplete reutilizan la decisión por elemento si no tienen fase. El texto se sigue transmitiendo mientras la finalización del mensaje espera su clasificación. El estado retenido usa el presupuesto de traducción de la solicitud. También se aplica al JSON reconstruido desde SSE del proveedor; el JSON ordinario del proveedor no cambia. |
+| `webSearchBridge?` | `{ enabled?: boolean; backend?: "ollama" \| "openai" \| "anthropic" \| "xai" \| "gemini" \| "exa"; maxSearches?: number; timeoutMs?: number; endpoint?: string }` | Key-auth `openai-responses` solo proveedores de pases. Desactivado por defecto. Codex siempre declara la herramienta `web_search` alojada, y el paso a través la retransmite en el supuesto de que el destino la ejecute. Una puerta de enlace que no ejecuta respuestas de búsqueda alojadas con un `function_call` llamado `web_search` que no se ejecuta, y el guardia de herramientas no declaradas termina el turno. Con `enabled: true` y un `backend` OpenCodex explícito intercepta esa llamada, ejecuta la búsqueda en sí misma, devuelve el resultado al mismo flujo ascendente y muestra Codex una celda `web_search_call` alojada. Nunca armado para `authMode: "forward"` (ChatGPT ya busca) o para un proveedor que ejecuta la búsqueda alojada aguas arriba. `backend` es necesario; no hay un valor predeterminado implícito y una credencial faltante para el backend nombrado deja el puente desarmado en lugar de caer a través de otra búsqueda pagada. `ollama` reutiliza la tecla API de este proveedor en `POST <origin>/api/web_search`, por lo que el origen debe ser `https://ollama.com` a menos que el operador nombre `endpoint` explícitamente. `openai` / `anthropic` / `xai` / `gemini` / `exa` reutilizar el ejecutor sidecar coincidente y que propia credencial del ejecutor (`webSearchSidecar.exaApiKey` para Exa). El modelo de búsqueda viene de `webSearchSidecar.model` solo cuando `webSearchSidecar.backend` resuelve el mismo nombre de este puente; de lo contrario, el puente ejecuta el propio valor predeterminado de ese backend, porque un modelo elegido para un proveedor es rechazado por otro. Un unset `webSearchSidecar.backend` resuelve a `openai`, así que un modelo unset-backend alcanza un puente `openai` y ningún otro. No hay anulación del modelo de puente por proveedor. Streaming de giros solamente. Un turno que mezcla `web_search` con otra llamada de herramienta de cliente aún falla en cerrar en lugar de dejar caer la llamada del cliente. No se ejecuta texto auxiliar como prosa XML-like `<web_search>`. Valores predeterminados: `maxSearches: 3` (1..10), `timeoutMs: 60000` (1000..600000). |
+| `retryOn429?` | `{ enabled?: boolean; attempts?: number; intervalMs?: number; maxIntervalMs?: number; respectRetryAfter?: boolean }` | Solo proveedores con clave API (`authMode: "key"`). Reintenta el mismo destino ante un 429. Ausente significa desactivado, salvo OpenCode Go y Command Code oficiales con clave, y Mistral `openai-chat` oficial: usan seis repeticiones, intervalo de diez segundos y límite de espera de 60 segundos. El objeto habilita la opción salvo `enabled: false`, que también desactiva esos valores especiales. Ante un 429, espera `Retry-After` o el intervalo fijo y repite la misma solicitud con la misma clave antes de cambiarla, en el bucle principal de texto, paso directo de Responses, puentes de imágenes y video, sidecar de búsqueda y continuaciones finales. Solo admite HTTP 429 antes del streaming; los transportes `runTurn` personalizados quedan fuera. `attempts` cuenta las repeticiones tras el primer 429: envíos totales = `attempts` + 1. Es un presupuesto compartido por toda la solicitud. Agotarlo detiene esas repeticiones; se aplica después el cambio de clave o el error final según los destinos disponibles. El paso directo autenticado con clave no cambia de destino y devuelve el 429. Para Mistral Chat oficial, un plazo explícito superior al permitido detiene la repetición con esa clave, aunque otra del grupo todavía puede servir, y devuelve el `Retry-After` original. Otros proveedores mantienen la espera acotada. Mistral comparte plazos por credencial y modelo salvo `requestPacing.enabled: false` o `retryOn429.respectRetryAfter: false`. Un 429 con presión válida sobre el presupuesto por minuto y sin plazo activa una espera conservadora de 60 segundos y después una sola consulta de prueba; si funciona, vuelve el tráfico normal. El tráfico correcto no predice el costo de la consulta siguiente. La política usa los límites anunciados, excluye cuotas mensuales conocidas como agotadas, no afirma una hora exacta de restablecimiento y nunca inicia compactación. Codex no reintenta por sí mismo los 429. Valores predeterminados: `enabled: true`, `attempts: 3`, `intervalMs: 5000`, `maxIntervalMs: 60000` (cada espera se limita a `maxIntervalMs`, acotado a 600000), `respectRetryAfter: true`. |
+| `transientRetryOn5xx?` | `{ enabled?: boolean; attempts?: number }` | Key-auth `openai-chat` y `openai-responses` proveedores solamente. `authMode: "forward"` proveedores (el grupo de cuentas ChatGPT) nunca leyó esta opción y mantiene la escalera predeterminada. Reintento de reintento para estados ascendentes transitorios previos a la corriente (500, 502, 503, 504, 520, 521, 522): medios ausentes desactivados, la presencia del objeto lo habilita a menos que `enabled: false`. Cubre la solicitud inicial Responses, el carril de paso Responses y cada una de sus patas de recuperación (reproducción OAuth-401, reproducción 429 del mismo objetivo, reconstrucción validada), la continuación de terminal-guardia y `/v1/chat/completions` nativo. `attempts` es el número TOTAL de envíos ascendentes permitidos para una solicitud, incluida la primera (1..10, por defecto 3): es un presupuesto compartido con la recuperación de reinicio de conexión, por lo que `3` significa que como máximo tres solicitudes reales llegan al proveedor. En el carril de paso Responses, el valor configurado se cruza adicionalmente con la asignación de envío de toda la solicitud, por lo que un valor por debajo de esa asignación estrecha la escalera exactamente mientras que un valor por encima de ella no eleva el límite. Cada objetivo Combo incluye su primer envío prepagado en el total configurado de ese objetivo; `attempts: 1` envía una vez, sin reembolsar la reserva o ampliar el límite combo compartido. Una negativa o cancelación local antes del envío libera una reserva no enviada. Las Esperas usan un retroceso exponencial fijo de 400 ms limitado a 5 s y honor `Retry-After`. Separado de `retryOn429`, que maneja la limitación de velocidad; los fallos de mid-stream nunca se reproducen. |
+| `retryOnReset?` | `{ enabled?: boolean; replacements?: number }` | Nativo `openai-responses` proveedores, incluyendo `authMode: "forward"`, además de genérico traducido Responses despacho antes de cabeceras ascendentes. Reemplazo opt-in de un envío que falló mientras la persona que llamó no había observado nada: ausencia de medios desactivados, presencia de objetos lo habilita a menos que `enabled: false`. Cubre ambas etapas ambiguas: una conexión que murió antes de cualquier encabezado de respuesta y un cuerpo SSE que murió después del encabezado mientras solo llevaba eventos de control. Un ChatGPT canónico corriente arriba WebSocket que se cerró o se equivocó después de su marco de creación a la izquierda, antes de cualquier evento Responses, se cubre de la misma manera, y su reemplazo se envía sobre HTTP. Solo se reemplaza una solicitud autónoma: `store: false`, `input`, `previous_response_id`, `conversation` o `stream_id`, y solo herramientas ejecutadas por el cliente. `replacements` es el número de envíos de reemplazo UNA solicitud lógica puede hacer a través de cada pierna y cada niño combinado (1...2, por defecto 1) - no un recuento de reintentos por pierna y no un presupuesto de envío, por lo que un reemplazo todavía tiene que caber dentro de la asignación de envío que la pierna ya tenía. Una solicitud que ya ha emitido una salida o una llamada a una herramienta nunca se reemplaza, cualquiera que sea el valor establecido. La inferencia de reemplazo aún puede facturarse si el origen ya había comenzado el primero, por lo que está desactivado por defecto. El despacho traducido genérico admite el reemplazo de reinicio previo a la cabecera para los envíos iniciales y reconstruidos bajo el mismo presupuesto de subvención y envío. Los transportes propiedad del adaptador y los fallos del flujo traducido después de excluir los encabezados ascendentes. |
+| `autoToolChoiceOnlyModels?` | `string[]` | Los modelos cuyo `tool_choice` acepta solo `auto` o `none`; las opciones forzadas se degradan. |
+| `preserveReasoningContentModels?` | `string[]` | Modelos que requieren `reasoning_content` previo del asistente. Chat traducido a `api.mistral.ai` reconstruye bloques nativos de pensamiento antes del texto; por defecto reproduce pensamiento aportado en todas las familias alojadas, salvo lista explícita, incluido `[]`. No inventa pensamiento ni firmas. Chat nativo a Mistral elimina ese campo de la historia porque lo rechaza. Guardar sin cambiar destino conserva la lista, incluido `[]`; consulta [qué conserva un guardado](#what-a-provider-save-keeps). `PATCH /api/providers?name=<provider>` acepta lista o `null`. |
+| `inlineThinkTagModels?` | `string[]` | Recuperación opt-in para `openai-chat` gateways sin un analizador de razonamiento del lado del servidor. Un bloque principal `<think>` / `<thinking>` / `<reasoning>` (opcionalmente después del espacio en blanco) activa la división en respuestas transmitidas y almacenadas en memoria intermedia. Toda la respuesta se conserva en blanco. Las etiquetas posteriores son delimitadoras en cualquier lugar, incluyendo el intercalado de la misma línea y las vallas de código; este modo no interpreta Markdown. El texto ordinario o una cerca de código antes de la primera etiqueta mantiene toda la respuesta intacta. Fuera de forma predeterminada; prefiere el razonamiento ascendente estructurado o `reasoningSplitModels` donde sea compatible. |
+| `reasoningDetailsModels?` | `string[]` | Los modelos cuyo punto final devuelve el pensamiento como una matriz `reasoning_details` estructurada (serie M MiniMax con `reasoning_split` ); los deltas de flujo son instantáneas acumulativas que se diffed por prefijo y se conservan las repeticiones de razonamiento como una matriz `reasoning_details` en lugar de una cadena `reasoning_content`. |
+| `requiresReasoningPlaceholderModels?` | `string[]` | Modelos cuyo flujo ascendente rechaza una continuación tool_call que falta `reasoning_content` (modo de pensamiento DeepSeek); se inyecta un marcador de posición mínimo cuando la caché de reproducción falla. Por defecto a `preserveReasoningContentModels`; ajuste `[]` para optar por no participar. Un proveedor de guardar que mantiene el destino mantiene la lista almacenada, incluyendo `[]`; ver [Lo que un proveedor guarda](#what-a-provider-save-keeps). `PATCH /api/providers?name=<provider>` acepta una matriz o `null` para borrarla. |
+| `showThinkingSummary?` | `boolean` | Mostrar resúmenes de autoría de proveedor cuando un cliente Responses omite `reasoning.summary`. El cable explícito `"none"` gana; un cliente que serializa su preferencia como omisión no puede distinguirse. Razonamiento crudo sigue siendo contenido y nunca es reetiquetado como un resumen. El valor predeterminado preestablecido de `google-antigravity` es `true`; el `false` explícito deshabilita ese valor predeterminado. Las solicitudes de CCA, Vertex y Gemini directas elegibles también optan por `generationConfig.thinkingConfig.includeThoughts` cuando la pantalla está habilitada; las solicitudes de imagen, Claude, gpt-oss y Vertex sin escaleras no lo hacen. Esto no cambia la configuración del cliente o los valores predeterminados de resumen del catálogo global. |
+| `hideRawReasoning?` | `boolean` | Mantenga la cadena de pensamiento sin procesar de un proveedor enrutado fuera del canal de contenido orientado al cliente (openai-chat `reasoning_content`, etiquetas kiro, `response.reasoning_text.*`) mientras los resúmenes de autor del proveedor aún se transmiten en el canal de resumen. El valor explícito del protocolo `reasoning.summary: "none"` sigue ocultando ambos. Esto controla lo que muestra un cliente; no guarda el texto del cliente. Una ruta de puente Responses todavía lo envía dentro del sobre de repetición `ocxr1` en el elemento de razonamiento `encrypted_content`, que es base64 JSON en lugar de cifrado, por lo que el cliente puede hacer eco de nuevo en el siguiente turno. Los codificadores directos de Chat y Messages no tienen envolvente en su cable, por lo que esos clientes no reciben copia y la reproducción proviene de la caché de reproducción de razonamiento del lado del servidor. `preserveReasoningContentModels` repetición y DeepSeek - estilo continuaciones no se ven afectados de ninguna manera. Desactivado de forma predeterminada; una ruta de paso nativa transmite los propios fotogramas del flujo ascendente e ignora esta opción. Guardar el mismo nombre de proveedor mantiene un valor omitido incluso después de un movimiento de destino; `PATCH` acepta un booleano o `null` para borrarlo. |
+| `thinkingToggleModels?` | `string[]` | Chatea modelos usando `thinking.enabled` en lugar de una escalera de esfuerzo. |
+| `thinkingBudgetModels?` | `string[]` | Modelos de chat usando el número entero `thinking_budget`; el esfuerzo mapea a una fracción de presupuesto. |
+| `noVisionModels?` | `string[]` | Los modelos solo de texto enviados a través del sidecar de visión toleran una etiqueta Ollama `:size`. |
+| `escapeBuiltinToolNames?` | `boolean` | Escápese de los nombres de herramientas incorporados para las puertas de enlace compatibles con Anthropic y restaure las llamadas devueltas. |
+| `anthropicEofTolerance?` | `boolean` | Deje que una puerta de enlace compatible con Anthropic complete un flujo que termina antes de `message_stop`, solo cuando se recibió texto visible o una entrada completa de la herramienta JSON-objeto. Desactivado por defecto. |
+| `forwardAdvisorTool?` | `boolean` | Herramienta Advisor tipada de Claude Code, `advisor_20260301`, en Messages traducido. Ausente: solo un adaptador `anthropic` con `https://api.anthropic.com` recibe declaración, intercambios completados y beta `advisor-tool-2026-03-01`. `true` los permite en un gateway Anthropic compatible que ejecute Advisor; `false` impide reenviarlos incluso al oficial. Otros destinos omiten la herramienta. Un Advisor de OpenCodex activo controla el nombre `advisor`. Consulta [Advisor de Anthropic](/es/guides/claude-code/#anthropics-advisor-tool-on-translated-routes). Guardar con el mismo destino conserva un valor omitido; moverlo lo elimina. `PATCH` acepta booleano o `null`. |
+| `googleMode?` | `"ai-studio" \| "vertex" \| "cloud-code-assist"` | Google transporte/modo auth. Por defecto `ai-studio`. |
+| `googleToolSchemaPolicy?` | `"compatible" \| "reject-lossy"` | Google solamente. Omitted/ `compatible` conserva el esquema de herramienta compatible y la reparación no directa existente de 400. `reject-lossy` rechaza la pérdida inicial del esquema o una comparación limitada indeterminada antes del envío y retiene una reparación de Vertex o Cloud Code Assist que abriría restricciones. Direct AI Studio nunca realiza esa reparación. |
+| `directGeminiWireRenames?` | `boolean` | Google solamente. Se aplica en el modo AI Studio, incluidas las URL personalizadas compatibles con Google. Omitida o `true` mantiene el nombre del cable `-tiered` para Gemini Flash ids ( `gemini-3.7-flash` -? `gemini-3.7-flash-tiered` ); `false` envía los identificadores desnudos solicitados al cable sin cambios. Las rutas Vertex y OpenCode Zen con clave canónica conservan el ID del modelo solicitado independientemente de esta configuración; El enrutamiento de Cloud Code Assist no cambia. Establecer `false` cuando el configurado aguas arriba todavía sirve a los ID desnudos. |
+| `project?` | `string` | Identificador de proyecto de Vertex o Antigravity Cloud Code Assist. Las claves API de Vertex usan ese proyecto cuando está configurado; si se omite, usan el modo express aunque exista `GOOGLE_CLOUD_PROJECT`. ADC recurre a `GOOGLE_CLOUD_PROJECT` / `GCLOUD_PROJECT`. Con `"auto"`, cada clave API de Vertex resuelve su propio proyecto: los resultados correctos se guardan en caché por clave y los fallidos se vuelven a consultar en otra solicitud. Así, un grupo de claves puede abarcar varios proyectos. ADC rechaza `"auto"`. |
+| — | — | Sondas de cuota de la cuenta Antigravity (`retrieveUserQuota` y `retrieveUserQuotaSummary`) siempre vaya al host de código en la nube de Google a través del transporte saliente anclado, independientemente de si está configurado `baseUrl`; el portador de la cuenta nunca se envía a un punto final configurado por el operador y una redirección aborta la sonda. Solo la lista de modelos sigue honrando `baseUrl`. |
+| — | — | El resumen de cuota Antigravity se solicita con el User-Agent de Antigravity CLI, la única familia para la que Google incluye el grupo de cuota Gemini 4 Argon. Si devuelve 403 para una cuenta OAuth válida, OpenCodex reintenta una vez con el User-Agent heredado `antigravity/1.0` y el mismo token y proyecto. No reintenta un 401. La inferencia no Argon y el fallback de cuota de la lista de modelos conservan el User-Agent IDE. |
+| — | — | Antigravity cuota muestra Gemini 4 Argón como ventanas separadas `Argon` / `Argon (Weekly)` junto a Gem y Cla. Solo se muestran: la clasificación de la cuenta, el agotamiento de la cuota, el restablecimiento de las notificaciones de pedido y restablecimiento siguen utilizando las ventanas Gemini y Claude, y las solicitudes de argón aún se evalúan según la ventana Gemini. |
+| — | — | Actualizar el descubrimiento Antigravity combina los modelos habilitados de las cuentas utilizables y conserva el inventario de cada cuenta seis horas. Con failover activo, un CCA 404 prueba otra cuenta solo si el error original completo ocupa como máximo 4 KiB y contiene un ResourceInfo de modelo cuyo resourceName coincide exactamente con `models/<sent-model>`. Los errores solo de mensaje, otros recursos y los cuerpos demasiado grandes, incompletos o fallidos conservan el estado HTTP original sin denegar modelos ni rotar cuentas. Una denegación confirmada dura hasta 24 horas, hasta un descubrimiento positivo iniciado después de la solicitud o hasta sustituir las credenciales; un descubrimiento anterior no puede borrarla ni reemplazar un inventario positivo más reciente. El agotamiento nombra el modelo y distingue cuentas no disponibles de fallos de credenciales, admisión o presupuesto de envíos. No se infiere ninguna categoría de pago o prueba. |
+| `location?` | `string` | Ubicación de Vertex. Los puntos finales de proyecto con clave API usan `global` de forma predeterminada e ignoran `GOOGLE_CLOUD_LOCATION`; ADC requiere este campo o el respaldo `GOOGLE_CLOUD_LOCATION`. Gemini 4 Argon admite `global`, `us` y `eu`. |
+| `mcpServers?` | `Record<string, CursorMcpServerConfig>` | Cursor solamente: servidores stdio o Streamable HTTP MCP. |
+| `desktopExecutor?` | `DesktopExecutorConfig` | Cursor solamente: comandos externos de uso del ordenador y de pantalla de registro. |
+| `unsafeAllowNativeLocalExec?` | `boolean` | Cursor legacy booleano, equivalente a `nativeLocalExec: "on"` solo cuando el campo más nuevo no está establecido. |
+| `nativeLocalExec?` | `"off" \| "codex-sandbox" \| "on"` | Cursor directiva de ejecución local. `off` es el valor predeterminado; `codex-sandbox` actualmente falla cerrado como `off`. |
+
+Para Responses nativo, la misma activación opcional cubre también un EOF limpio después de solo eventos de ciclo de vida. Los límites de solicitud autónoma y de reemplazo siguen aplicándose. Las solicitudes fuera de esos límites no se inspeccionan, así que sus flujos nunca se retienen. Un flujo directo recibe la cabecera de respuesta original en 200 milisegundos aunque el origen todavía esté en silencio. El reemplazo aporta su propio estado y sus propias cabeceras solo si se selecciona antes de que se devuelva esa cabecera: el reinicio o el EOF de un flujo directo debe ocurrir dentro de esos 200 milisegundos, y la cabecera del reemplazo debe llegar dentro de los 15 segundos posteriores a la respuesta original, o el tiempo de espera por bloqueo si es más corto. Las solicitudes no transmitidas que se recopilan en JSON y los destinos de combo no tienen una ventana de 200 milisegundos y pueden esperar ese tiempo antes de elegir una cabecera, porque su cliente no recibe ninguna cabecera hasta que la respuesta se recopila o se selecciona. Una vez devuelta la cabecera, lo que debe coincidir un reemplazo depende de cómo terminó el flujo. Un error de lectura conserva el comportamiento existente del carril de reinicio: el cuerpo del reemplazo se publica detrás de la cabecera original como siempre lo ha hecho. Un EOF limpio que ocurre solo tras el preludio es más estricto, porque es un intento distinto que responde al mismo turno: el reemplazo debe coincidir con la cabecera confirmada en el estado, el texto de estado, el tipo de medio de content-type, \`openai-model\` y \`x-codex-turn-state\`. Las cabeceras volátiles y de salto (\`date\`, los id de solicitud, \`cf-ray\`, \`server-timing\`, \`x-ratelimit-*\`, \`openai-processing-ms\`, \`content-length\`, \`transfer-encoding\`, \`connection\`, \`keep-alive\`) nunca tienen que coincidir, porque el cliente ya tiene los valores de la cabecera original y un origen real las varía en cada intento. Una discrepancia conserva el flujo original y su error. Los flujos directos que todavía se inspeccionan después de ese punto reciben un comentario keepalive SSE junto con la cabecera y después cada 15 segundos; la preverificación de combo retiene estos comentarios hasta que selecciona una respuesta.
+
+Los valores predeterminados de esfuerzo por modelo que incluye Command Code incorporan mediciones de la API en vivo. DeepSeek v4/v4.1 Flash (incluido v4 Flash Vision), GLM-5.3 y GLM-5.3-Flash, Qwen3.8-Flash y Gemini-3.7-Flash admiten `low`, `medium`, `high`, `xhigh` y `max`. Las escaleras siguen siendo específicas de cada modelo: `poolside/laguna-s-2.1-free` ofrece solo `medium`, mientras que Gemini-3.8-Flash y MiMo-v2.5-Pro ofrecen `low`, `medium` y `high`. Para anular una fila fijada de Command Code, establezca `modelReasoningEffortsAuthoritative: true` junto con la lista `modelReasoningEfforts` de ese modelo.
+
+El registro y el reemplazo del proveedor (`POST /api/providers`) validan `responsesPath` y `chatCompletionsPath` antes de cambiar la configuración activa o el estado del disco. `PATCH /api/providers?name=<provider>` fusiona el cuerpo de la solicitud con el proveedor almacenado; las actualizaciones que tocan campos más allá de `disabled` —excepto las actualizaciones de solo `requestPacing`— validan las rutas del proveedor fusionado de la misma manera antes de guardar, y una ruta retenida no válida devuelve `400` con la configuración sin cambios. Las mismas reglas de ruta se aplican cuando se carga un archivo de configuración.
+
+Por ejemplo, esto aplica un límite de concurrencia para todo el proveedor y un límite más estricto a un modelo exacto, sin configurar un intervalo:
+
+```json
+{
+  "requestPacing": {
+    "enabled": true,
+    "maxConcurrentRequests": 8,
+    "models": {
+      "nvidia/llama-3.1-nemotron-ultra-253b-v1": {
+        "maxConcurrentRequests": 2
+      }
+    }
+  }
+}
+```
+
+El intervalo de simultaneidad permanece ocupado hasta que finaliza la solicitud ascendente, incluyendo los bytes de respuesta transmitidos finales. Las solicitudes por encima de los límites aplicables del proveedor y del modelo esperan en la cola de estimulación; cuando se libera un intervalo, se admite la siguiente solicitud elegible. La espera de cola no consume el tiempo de espera del encabezado de respuesta ascendente.
+
+Para múltiples entradas de grupo de claves API, opte por la distribución de solicitudes normales por separado de la selección de fallos existente `apiKeyPoolStrategy`:
+
+```json
+{
+  "requestPacing": {
+    "enabled": true,
+    "keySelection": "round-robin",
+    "maxConcurrentRequests": 10,
+    "keys": { "requestsPerMinute": 15, "maxConcurrentRequests": 1 }
+  }
+}
+```
+
+Esto admite como máximo diez solicitudes activas en todo el proveedor y una por referencia de credencial, con inicios en cada referencia con al menos cuatro segundos de diferencia. Estos son límites superiores locales, no una promesa de capacidad ascendente. Una configuración de RPM para todo el proveedor, cuando está presente, sigue siendo un límite agregado y no se multiplica con el recuento de claves. Los límites clave abarcan modelos; las reglas del modelo siguen siendo restricciones adicionales. Los proyectos que comparten cuota necesitan un límite agregado apropiado. El TPM y las cuotas diarias no se rastrean aquí.
+
+Round-robin selecciona claves por solicitud sin guardar una nueva clave activa. Se omiten los tiempos de reutilización 401/429 conocidos; cuando ninguno sigue siendo elegible, las nuevas solicitudes reciben un 429 reintentable en lugar de enviarse repetidamente. El trabajo ya puesto en cola normalmente retiene su clave seleccionada y puede esperar detrás de esa clave incluso cuando otra está inactiva. Si esa selección se enfría o no es válida, la solicitud vuelve a seleccionar una clave elegible y vuelve a adquirir la admisión de estimulación; la cola limitada expira en lugar de esperar para siempre. La selección y el diagnóstico son locales de proceso, se restablecen al reiniciar y no igualan el uso o la facturación de tokens equilibrados. Comienza a contar las admisiones de ritmo, incluido el trabajo cancelado antes del envío. OAuth y las credenciales reenviadas mantienen su selección existente. El panel de control muestra los identificadores de teclas, los inicios, el trabajo en vuelo, el trabajo en cola y los tiempos de reutilización conocidos, nunca los valores de las claves secretas. Estos límites cubren el ejecutor de estimulación de inferencia, no la búsqueda directa del relé de imágenes independiente.
+
+<a id="azure-openai-model-metadata-discovery"></a>
+
+### Azure OpenAI descubrimiento de metadatos del modelo
+
+Para una URL base cuyo nombre de host termina en `.openai.azure.com`, el descubrimiento llena el soporte de entrada de imagen/texto faltante y los límites de contexto/salida incluso cuando el proveedor tiene un nombre personalizado. Los indicadores de inferencia y chat de Azure `/models` por sí solos no describen el soporte de imágenes o los límites de token. opencodex los complementa con el público [catálogo models.dev](https://models.dev), utilizando sus filas de Azure antes de los metadatos de Azure y otros paquetes de proveedores. La búsqueda de ID de modelo es exacta o insensible a mayúsculas y minúsculas; un modelo recién publicado no requiere una nueva versión opencodex.
+
+La instantánea de metadatos públicos se actualiza durante el descubrimiento como máximo una vez cada 24 horas, con un plazo de dos segundos y un límite de cuerpo de 16 MiB. Se almacena en `azure-model-metadata-cache.json` bajo el directorio de configuración opencodex. No se envían credenciales de Azure al catálogo público. El descubrimiento sin conexión mantiene los metadatos obsoletos en caché o vuelve a las sugerencias agrupadas; las solicitudes de generación no obtienen esta instantánea.
+
+Las declaraciones de insumos explícitos y las modalidades notificadas siguen teniendo prioridad, incluido el `vision: false` notificado. Todavía se aplica la cobertura de sidecar de visión existente. Los límites informados/configurados siguen siendo válidos y los límites del proveedor aún los restringen. Los metadatos describen el soporte del modelo, no una capacidad de implementación particular. Los alias de implementación arbitraria, como `my-production-model`, no se pueden asignar desde los indicadores de inferencia de Azure; configure `modelInputModalities` y `modelContextWindows` para esa identificación exacta cuando sea necesario. Los identificadores desconocidos no se adivinan.
+
+<a id="what-a-provider-save-keeps"></a>
+
+### Lo que un proveedor guarda
+
+`POST /api/providers` con el nombre de un proveedor existente sustituye la fila almacenada por la de la solicitud. Como el formulario no envía todos los campos, conserva los omitidos que describen el comportamiento del proveedor: `preserveReasoningContentModels`, `preserveResponsesReasoningContent`, `requiresReasoningPlaceholderModels`, `foldDeveloperRoleToSystem`, `singleLeadingSystemMessage`, `reasoningWireFormat`, `omitReasoningEffortWithToolsModels`, `promoteAdditionalTools`, `retryOn429`, `transientRetryOn5xx`, `retryOnReset`, `unsupportedHostedTools`, `unsupportedHostedToolsWithClientTools` y `forwardAdvisorTool`.
+
+| Guardado | Los once ajustes | `apiKeyPool` almacenado |
+| --- | --- | --- |
+| Mismo destino, campo omitido | Valor almacenado mantenido, incluyendo un `[]` o `false` explícito | Conservado |
+| Nuevo destino, campo omitido | No se mantiene; pueden aplicarse los valores predeterminados del registro para el nuevo destino | No se conserva |
+| Campo enviado en la solicitud | El valor de la solicitud | El valor de la solicitud |
+
+El destino se determina por el adaptador, la URL base (esquema y host sin distinguir mayúsculas ni barras finales) y el modo de autenticación, cuando la solicitud lo incluye. Cambiar de destino descarta esos ajustes porque describen el proveedor anterior, y también el grupo de claves porque se emitieron para él. El guardado no fusiona el resto de la fila antigua con la nueva.
+
+`hideRawReasoning` es una directiva de visualización del operador, por lo que guardar el mismo nombre de proveedor mantiene su valor almacenado cada vez que la solicitud lo omite, incluso después de un movimiento de destino. Gana un valor enviado en la solicitud, incluyendo `false`.
+
+La configuración opcional `inferContextWindow` también sobrevive a los guardados con el mismo nombre que lo omiten, incluidos los movimientos de destino. Su comportamiento de lectura, actualización y claridad se describe en [Ventanas de contexto en proveedores personalizados](#context-windows-on-custom-providers).
+
+`PATCH /api/providers?name=<provider>` cambia solo los campos que incluye y conserva los demás, aunque cambie el destino. Admite esos ajustes; `null` elimina uno. También admite un booleano `hideRawReasoning` o `null` para borrarlo. En las dos listas de razonamiento, un array vacío se guarda como una exclusión explícita.
+
+Con `webSearchBridge` habilitado, una continuación de búsqueda permanece vinculada a la selección de clave API que sirvió la primera solicitud. Cambiar la clave seleccionada, su valor de referencia o resuelto, modo de autenticación o URL base durante la búsqueda o el ritmo del proveedor finaliza el turno con un error de puente antes de enviar otra solicitud del proveedor. El cambio y la vuelta también terminan esa continuación. Inicie un nuevo turno para utilizar la nueva selección. La selección cambia antes de que el primer proveedor envíe la retención de reselección normal.
+
+Un resultado de búsqueda puenteado se muestra de nuevo al proveedor en el siguiente turno de la conversación solo para la misma persona que llama, conversación, proveedor, modelo y clave seleccionada. La persona que llama se identifica por la clave API opencodex que presenta, por lo que un cliente que no envía la clave opencodex API no obtiene dicha repetición: sus celdas de búsqueda anteriores llegan al proveedor sin cambios, como lo hacen para un proveedor sin el puente.
+
+Una lista explícita `inlineThinkTagModels` reemplaza los valores predeterminados del registro coincidentes; `[]` desactiva la recuperación.
+
+Las solicitudes Responses traducidas con un esfuerzo de razonamiento activo validado preservan el razonamiento en bruto cuando se omite `reasoning.summary`. `"none"` explícito lo mantiene oculto para su reproducción; la omisión sin un esfuerzo activo también permanece oculta. Un combo inyectado por defecto agrega `summary: "auto"` solo cuando el llamante no ha elegido un modo de resumen. Razonamiento en bruto nunca se vuelve a etiquetar como un resumen de autor proveedor, y Codex todavía controla su pantalla con `show_raw_agent_reasoning`.
+
+El modelo personalizado `reasoningEfforts` normalmente anula los metadatos del proveedor descubiertos. La excepción limitada es una fila personalizada explícita cuyo identificador de modelo ha fijado capacidades nativas Codex, incluyendo Astra o Daybreak en una puerta de enlace arbitraria: su lista anunciada se cruza con las capacidades nativas fijadas de ese modelo. La identidad nativa completa aún requiere el destino canónico `openai` Codex-forward. Una lista vacía explícita permanece vacía sin ningún valor predeterminado; una lista incompatible no vacía vuelve al valor predeterminado nativo como una sola opción. Los valores predeterminados deben pertenecer a la lista final. Esto cambia la proyección del catálogo, no la configuración almacenada. Véase [ejemplos de catálogo nativos personalizados](/es/guides/codex-app-models/).
+
+<a id="per-provider-egress"></a>
+
+### Salida por proveedor
+
+Establecer `proxy` en un proveedor cuando ese flujo ascendente necesita una salida diferente del proxy de todo el proceso:
+
+- Omita `proxy` para heredar el proxy global y la decisión `NO_PROXY`.
+- Configurar `proxy` a `"direct"` o `null` para forzar a este proveedor a conectarse directamente, incluso cuando se establece un proxy global.
+- Establezca `proxy` en una URL absoluta `http://` o `https://` para usar ese proxy HTTP para este proveedor.
+- Configure `proxy` a una URL absoluta `socks5://` o `socks5h://` para usar ese proxy SOCKS5 para este proveedor.
+
+Una cadena vacía o de solo espacio en blanco se rechaza a propósito. Un campo borrado no debe cambiar silenciosamente de "heredar el proxy global" a "forzar directo"; eliminar el campo para heredar, o escribir `"direct"` para elegir la salida directa explícitamente.
+
+`noProxy` acepta una cadena separada por comas o una matriz de cadenas en la sintaxis `NO_PROXY`. Se evalúa para cada solicitud. Un destino coincidente va directo si el proveedor usaría su propio `proxy` o heredaría un proxy global.
+
+<a id="what-the-route-covers"></a>
+
+#### Lo que cubre la ruta
+
+La ruta se aplica a inferencias enrutadas, pruebas de descubrimiento y conexión de proveedores y sondas de cuota de clave API. Algunos transportes no pueden llevarlo, y OpenCodex lo dice en lugar de pretender lo contrario:
+
+- **OAuth intercambio de tokens y actualización** seguir utilizando el proxy de todo el proceso. Estos alcanzan puntos finales de proveedores fijos desde código que no contiene configuración de proveedor, por lo que un proveedor anclado a su propio proxy o a `"direct"` aún actualiza sus credenciales por la ruta global. Las sondas de cuota respaldadas por OAuth y las sondas de validación de clave API se comportan de la misma manera.
+- **El Responses WebSocket carril rápido** selecciona su proxy cuando marca y no puede llevar una ruta por proveedor, por lo que un proveedor que declara que uno sirve esos convierte más de HTTP / SSE y registra un aviso único.
+- **el transporte HTTP/2 predeterminado de Cursor**, los **proveedores de subprocesos CodeBuddy y Qoder** (su entorno hijo omite las variables de proxy) y el remitente anclado **Compatibility Lab** no lo aplican.
+- Los endpoints que no enrutan un modelo (generación y edición de imágenes, transcripción de audio, llamadas en tiempo real y en vivo, y `/v1/alpha/search` no calificado) no tienen ruta de proveedor para aplicar.
+
+Un proveedor configurado con un ejecutor `fetch` personalizado es rechazado en lugar de ser enviado silenciosamente por la propia ruta del ejecutor.
+
+Este ejemplo mantiene un proxy global para el tráfico ordinario, envía un proveedor a través de un proxy regional HTTP, y fija otro proveedor a una conexión directa:
+
+```json
+{
+  "proxy": "http://global-proxy.example:8080",
+  "providers": {
+    "regional-gateway": {
+      "adapter": "openai-chat",
+      "baseUrl": "https://regional-api.example/v1",
+      "proxy": "http://regional-proxy.example:3128"
+    },
+    "direct-gateway": {
+      "adapter": "openai-chat",
+      "baseUrl": "https://direct-api.example/v1",
+      "proxy": "direct"
+    }
+  }
+}
+```
+
+<a id="operator-pinned-reasoning-effort"></a>
+
+### Esfuerzo de razonamiento fijado por el operador
+
+Configure `pinnedReasoningEffort` en un proveedor existente para anular las opciones de esfuerzo entrantes, o use `modelPinnedReasoningEfforts` para ID de modelo ascendente individuales. Los pines de proveedor por modelo ganan sobre el pin de todo el proveedor; el mapa de la raíz `modelPinnedEfforts` es el respaldo. Estos son ajustes del operador, no los valores predeterminados del registro del proveedor. No cambian el descubrimiento del modelo o la escala de esfuerzo anunciada.
+
+```json
+{
+  "pinnedReasoningEffort": "high",
+  "modelPinnedReasoningEfforts": {
+    "example-model": "max"
+  }
+}
+```
+
+Combina estos campos en la fila de proveedores existente. Los valores aceptados son `none`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max` y `ultra`. **`none` elimina el campo de esfuerzo explícito**; utiliza el comportamiento predeterminado del proveedor y no garantiza que el razonamiento esté deshabilitado. Los límites de esfuerzo aplicables aún se ejecutan después del pin, y la asignación/normalización de cables del proveedor puede reducir u omitir un valor no compatible. `ultra` se normaliza antes de que alcance un cable aguas arriba. Las solicitudes de mantenimiento de compactación están exentas de pines.
+
+`PATCH /api/providers?name=<provider>` acepta estos campos. Omita un campo para conservarlo; use `null` para borrar un escalar o todo el mapa. Una entrada de mapa establecida en `null` o `""` elimina esa entrada mientras conserva otras entradas. Las escrituras mal formadas son rechazadas antes de guardarlas. Un pin opcional mal formado en un archivo editado a mano se ignora bajo carga sin descartar el resto de la configuración.
+
+<a id="auto-review-approval-model-selection"></a>
+
+### Selección del modelo de revisión automática (aprobación)
+
+Codex lee `auto_review_model_override` de la fila del catálogo del modelo actual de turno para elegir el modelo que revisa las solicitudes de aprobación. La configuración de la raíz `auto_review_model` en `$CODEX_HOME/config.toml` suministra el respaldo de Codex. El panel de control global **Anulación de revisión automática** en Configuración de modelo almacena `autoReviewOverride` en `~/.opencodex/config.json` y tiene prioridad sobre ese recurso; los campos de alcance de proveedor a continuación aún ganan en sus propias filas. La configuración global debe estar habilitada y nombrar un modelo. Una configuración habilitada sin modelo permanece sin aplicar y deja en vigor el respaldo de Codex. Una actualización de catálogo es un estado aparte: tras guardarla puede quedar pendiente, y la página Modelos lo informa para que pueda reintentarla con `ocx sync`. Los usuarios de CLI pueden leer la configuración con `ocx models auto-review status` o cambiarla con `ocx models auto-review set <model|-> [--enabled <on|off>]`; use `-` para borrar el modelo. La salida del CLI recomienda `ocx sync` cuando se puede reintentar una actualización. Si una actualización falla, la configuración sigue guardada y el comando termina con código de salida 1. Resuelva el fallo antes de sincronizar. La [guía del proveedor](/es/guides/providers/#approval-reviewer-per-provider) tiene el flujo de trabajo del operador y un ejemplo trabajado.
+
+Cuando se incluyen OpenAI filas nativas y el catálogo final tiene una fila nativa desnuda ordinaria que no sea Reserve (recuento de filas ocultas), OpenCodex mantiene la fila oculta `codex-auto-review` para que Codex pueda seleccionar su revisor de aprobación preferido cuando no se configura la anulación. Queda fuera de los selectores de modelos, las opciones de subagentes, las listas de escritorio y las listas públicas `/v1/models`. El proveedor y el revisor raíz anulan su precedencia y no estampan esta fila interna. Los catálogos sin una fila nativa desnuda ordinaria, incluidos los catálogos solo de reserva, la omiten y conservan el respaldo de Codex al modelo de tarea. El revisor recibe la misma proyección de modo multiagente que las filas nativas ordinarias.
+
+`autoReviewModel` es el objetivo del revisor de todo el proveedor. Un valor puede ser un id de modelo desnudo de ese mismo proveedor (la fila de catálogo está normalizada a la identificador `provider/model`) o una identificador de catálogo pública completa como `opencode-go/deepseek-v4-flash`. Un valor desnudo se resuelve primero contra las filas de ese proveedor y luego contra una fila de catálogo desnuda, que es como se nombra un modelo nativo como `gpt-5.6-terra`, y un valor desnudo que aterriza fuera del proveedor imprime una nota que nombra la fila que realmente suministra al revisor; un valor que no coincide con ninguno no se resuelve. `autoReviewModelOverrides` claves son exactamente ids de modelo ascendente de ese proveedor, o el alias publicado del proveedor para uno ( `modelAliases` ); o bien nombres ortográficos de la misma fila enrutada, cuya slug lleva el id ascendente. Una entrada gana sobre el valor de todo el proveedor para su modelo. Un sello de proveedor gana sobre el selector de raíz en sus propias filas enrutadas, y el selector de raíz sigue siendo la reserva para las filas nativas y las filas enrutadas sin un sello de proveedor. La eliminación de un selector de proveedor solo borra los sellos de ese proveedor; la eliminación del selector raíz nunca borra los sellos de proveedor. Los ID de modelo que contienen una barra pueden escribirse sin procesar o en su forma de catálogo codificada; ambas ortografías se resuelven en la misma fila enrutada. Las llaves del modelo conservan el caso. Los selectores se resuelven contra el catálogo final en cada sincronización, independientemente uno del otro, y cada uno falla cerrado por sí solo: un `autoReviewModel` no resuelto emite un diagnóstico y no estampa filas de todo el proveedor, una entrada `autoReviewModelOverrides` no resuelta emite un diagnóstico y no estampa una anulación por modelo, por lo que un objetivo válido de todo el proveedor sigue siendo su reserva. Se sigue aplicando cualquier selector que se resuelva. Las filas sin sello de proveedor mantienen el selector raíz o el comportamiento normal de revisión automática ascendente cuando no está establecido. El proveedor canónico `openai` no acepta estos campos.
+
+La eliminación del selector de raíz borra los sellos de raíz de cada fila, incluidas las filas nativas estampadas por versiones anteriores al marcador de procedencia de OpenCodex. Esa limpieza reconoce un sello heredado por su forma, un valor en todo el catálogo que también lleva una fila enrutada, por lo que un valor genuino por fila que coincida con esa forma se borra con él, y un catálogo que desde entonces ha divergido de esa forma necesita una sincronización manual. Los sellos de proveedores nunca son tocados por la eliminación de raíces.
+
+`PATCH /api/providers?name=<provider>` acepta ambos campos. Use `null` para borrar el escalar o todo el mapa; use una entrada de mapa de `null` o `""` para eliminar ese modelo mientras conserva otras entradas. El proveedor no relacionado guarda los valores previamente configurados.
+
+Estos campos están disponibles en `config.json`, la administración de proveedores API y el editor de proveedores JSON sin procesar del panel de control. Los controles de formulario dedicados no están presentes. Los sellos raíz nativos registran el valor anterior y lo restauran al eliminarlo cuando el valor sellado no se ha cambiado externamente.
+
+<a id="discovered-model-display-names"></a>
+
+### Nombres de modelo descubiertos
+
+Utilice `modelDisplayNames` cuando un proveedor devuelve identificadores compatibles con la máquina, pero el selector de modelos Codex necesita etiquetas más cortas. El mapa pertenece a un proveedor, por lo que el mismo identificador de modelo puede tener una etiqueta diferente bajo otro proveedor. Agregue el campo a la fila de proveedores existente en `config.json` y mantenga todas las demás configuraciones de proveedores. El ejemplo incluye los campos requeridos para el contexto:
+
+```json
+{
+  "providers": {
+    "xai": {
+      "adapter": "openai-chat",
+      "baseUrl": "https://api.x.ai/v1",
+      "modelDisplayNames": {
+        "grok-4.6": "Grok 4.6"
+      }
+    }
+  }
+}
+```
+
+Las filas GPT nativas desnudas compatibles en el catálogo local Codex también aceptan etiquetas exactas en `providers.openai.modelDisplayNames`, por ejemplo `"gpt-6-astra": "GPT 6 Astra"`. Tanto la sincronización de inicio como la convergencia de catálogo local vuelven a aplicar estas etiquetas. La eliminación de una etiqueta restaura el nombre nativo original solo cuando el nombre de visualización de la fila aún coincide con la anulación aplicada. Se conserva un nombre de visualización externo más reciente sujeto a la normalización de metadatos nativos existentes; por ejemplo, Astra (`gpt-6-astra`) aún reemplaza un nombre no anclado con su nombre nativo anclado. La superposición de etiquetas deja sin cambios los ID de modelo, los metadatos (incluidas las capacidades), los alias combinados enrutados y las filas calificadas para la cuenta. Esta anulación del catálogo local no reetiqueta los listados de modelos HTTP ni las filas virtuales `*-pro`.
+
+El orden efectivo de la etiqueta es el operador `modelDisplayNames`, luego los metadatos del catálogo del proveedor, luego el retroceso normal `provider/model`. El selector encaminado permanece `xai/grok-4.6`, mientras que el modelo de cable aguas arriba permanece `grok-4.6`. Las etiquetas solo se muestran. No cambian la autenticación, el comportamiento del adaptador, el enrutamiento, la facturación o la construcción de solicitudes ascendentes. La eliminación de una entrada de mapa restablece solo su etiqueta. Para los modelos OpenAI API incorporados, use `providers.openai-apikey.modelDisplayNames`; la etiqueta sobrevive a las actualizaciones del catálogo. Un cliente de administración puede establecer o restablecer una etiqueta con `PUT /api/providers/:provider/model-display-names` y un cuerpo de `{ "modelId": "grok-4.6", "displayName": "Grok 4.6" }`; enviar `displayName: null` para restablecerla. El proveedor `PATCH` no edita este mapa. Utilice este punto final dedicado `PUT` para cambiar o eliminar etiquetas.
+
+El tablero de instrumentos expone la misma configuración duradera en **Modelos**. Expanda el proveedor, encuentre un modelo descubierto y elija **Nombre**. El cuadro de diálogo mantiene visible el selector exacto `provider/model` mientras guarda una etiqueta amigable. Elija **Restablecer nombre** para volver a los metadatos del proveedor o al menú desplegable del selector normal. **Nombre** cambia solo la presentación; el lápiz de alias separado cambia el alias de enrutamiento corto y no es un editor de nombres de visualización. Las filas nativas OpenAI y de modelo personalizado mantienen sus controles existentes.
+
+Si el cambio se guarda pero falla la actualización, el cuadro de diálogo refleja la anulación guardada y mantiene **Reintentar** disponible. Volver a intentar repite la convergencia de catálogo cuando el servidor informó de que falló, o recarga la lista cuando solo falló la solicitud de lista. La recuperación de restablecimiento mantiene la operación de restablecimiento; no restaura el nombre antiguo. Las solicitudes tienen una fecha límite de 60 segundos que cubre la redacción y la actualización de su lista de seguimiento. Un tiempo de espera no deshace una escritura: use **Reintentar** para verificar el nombre actual antes de realizar otro cambio.
+
+El selector `/model` de Claude Code (`GET /v1/models` en formato Anthropic) muestra una fila enrutada con etiqueta exacta como `<label> (<provider>)`, por ejemplo `Sonnet 5.5 (anthropic2)` y `Sonnet 5.5 (anthropic2) · 1M`. Sin etiqueta conserva `<model id> (<provider>)`. Cuando `fastMode` global reescribe una fila Cursor a su id rápido con estilo legible, conserva el id listado en lugar de la etiqueta configurada. Los alias y metadatos del catálogo no cambian esa etiqueta; los ids y las filas nativas no cambian.
+
+<a id="codex-catalog-and-root-configtoml-settings"></a>
+
+## Codex catálogo y raíz `config.toml` configuración
+
+Estos ajustes pertenecen a la raíz de `$CODEX_HOME/config.toml`, junto con `approvals_reviewer`; no son campos de proveedor.
+
+| Campo | Tipo | Descripción |
+| --- | --- | --- |
+| `auto_review_model` | `string` | Selector de catálogo público en forma `provider/model`, por ejemplo `opencode-go/deepseek-v4-flash`. Después de cada fusión de catálogo, OpenCodex lo resuelve contra el catálogo final y marca el valor recortado como `auto_review_model_override` en las entradas de catálogo. Se elimina el espacio en blanco límite; los componentes delimitados por barras del selector no cambian de otro modo. Si el valor está ausente o en blanco, las anulaciones enrutadas existentes se borran y se conserva la selección normal de auto-revisión ascendente. Si es sintácticamente inválido o está ausente del catálogo final (incluso después de la eliminación del proveedor / modelo), OpenCodex falla cerrado solo para la anulación: borra la anulación muerta, conserva el comportamiento normal de flujo ascendente y emite un diagnóstico. Volver a agregar el proveedor/modelo en una sincronización posterior permite que el selector configurado se selle nuevamente. |
+
+La configuración se evalúa después del descubrimiento del proveedor, el filtrado del modelo, la proyección nativa/de la fila de cuentas y la prioridad de combinación, por lo que solo un selector presente en el catálogo producido por esa sincronización puede convertirse en una anulación. Los valores ascendentes nativos se conservan cuando la configuración se borra o no se resuelve. El campo de catálogo persistente es leído por Codex para el modelo del turno actual, por lo que se copia un selector configurado válido a cada entrada aplicable. Los selectores con alcance de proveedor (arriba) se aplican antes de esta reserva raíz y ganan en filas enrutadas.
+
+<a id="response-service-tier-authority"></a>
+
+### Autoridad de nivel de servicio de respuesta
+
+Establecer `providers.<name>.responseTierAuthoritative` a `false` en `config.json` cuando la respuesta de ese proveedor `service_tier` no puede establecer si se concedió Fast. Esta es una declaración del operador sobre toda la ruta del proveedor, independiente de `supportsServiceTier` y `fastWire`. No permite Fast ni cambia el `service_tier` saliente.
+
+Por ejemplo, agregue este campo a un proveedor de puerta de enlace existente cuyo backend Codex tiene metadatos de respuesta no autoritativa:
+
+```json
+{ "responseTierAuthoritative": false }
+```
+
+**El soporte de Gateway es opt-in.** La actualización de OpenCodex por sí sola no añade esta declaración a los proveedores existentes. Sin ella, una solicitud de prioridad elegible seguida de `service_tier: "default"` conserva la interpretación heredada de `response-declined`. Configure `false` solo cuando se sabe que los metadatos de respuesta de la ruta no son autorizados.
+
+Para una solicitud elegible serializada como `priority`, tanto un eco `default` como un eco `priority` permanecen como observaciones. Los troncos conservan `responseServiceTier` y registran `tierOutcome.responseTierAuthoritative: false`, `fastOutcome: "applied"` y `confirmation: "assumed"`, sin `response-declined`. Aquí **aplicado significa que el parámetro de solicitud fue enviado** y **supuesto significa que el efecto rápido real no está confirmado**. La descripción del modelo muestra la solicitud y la respuesta sin procesar por separado con esa confirmación. Ni esta configuración ni estos registros prueban una aceleración o un nivel facturado.
+
+Las estimaciones de costos usan el recurso existente solicitado en lugar de tratar el eco crudo como un nivel de precio confirmado; las reglas de precios que requieren confirmación de respuesta no pueden usar ese eco. Los registros históricos sin una bandera de autoridad conservan su interpretación anterior.
+
+El campo solo acepta booleanos. La Omisión y el `true` explícitos retienen la confirmación basada en la respuesta para otros destinos, incluso el API oficial y puertas de enlace no declaradas. Canonical `https://chatgpt.com/backend-api/codex` con `authMode: "forward"` permanece automáticamente no autorizado, incluso si `true` está configurado. Los nombres de puerta de enlace y las URL nunca se infieren. Si una puerta de enlace mezcla contratos de respuesta, utilice entradas de proveedor separadas para esas rutas y aplique la declaración solo a la entrada relevante.
+
+<a id="fastwire-b1-capability-migration"></a>
+
+### FastWire B1 migración de capacidad
+
+La capacidad rápida y el reenvío arbitrario del nivel de llamada de Chat son independientes después de FastWire B1. El [definiciones de campo proveedor](#provider-entries-ocxproviderconfig) anterior sigue siendo el contrato autorizado; las configuraciones existentes ven estos deltas de migración:
+
+1. Un proveedor/modelo de chat declarado compatible con Fast ya no necesita `chatServiceTier: true` para canónica Fast. La publicación, la elegibilidad de enrutamiento y la inyección aún requieren una política elegible y un mapeo FastWire compatible en el adaptador final. En las rutas clasificadas, `fastMode: false` todavía elimina el ayuno canónico. Establecer `supportsServiceTier: false` o un modelo exacto `false` cuando la ruta no es Fast-capable.
+2. En una ruta clasificada elegible, la ortografía de la persona que llama `fast` y `FAST` se normaliza a través de `fastWire.canonicalToWire.priority`; la persona que llama `priority` permanece canónica. Configure una asignación verificada a `fast` solo cuando ese es el valor canónico del flujo ascendente. Las rutas no clasificadas conservan su comportamiento de reenvío existente.
+3. El modelo exacto `true` ya no autoriza los niveles de Chat extranjeros, como `flex` o los valores específicos del proveedor. Aquellos que todavía requieren `chatServiceTier: true`; de lo contrario se eliminan y se registran como niveles de llamada caídos.
+
+La capacidad explícita `false` y Responses de reenvío de llamadas retienen sus contratos existentes.
+
+<a id="anthropic-fast-anthropic-speed"></a>
+
+### Anthropic rápido (`anthropic-speed`)
+
+Las entradas `anthropic` (almacenadas en Claude OAuth) y `anthropic-apikey` anuncian Fast solo para `claude-opus-5-5`, `claude-opus-5` y `claude-opus-4-8`. Otros modelos Claude no están clasificados; las entradas no tienen un valor predeterminado rápido para todo el proveedor.
+
+Anthropic Fast está **desactivado de forma predeterminada** porque gasta créditos de uso (suscripción) o acceso en modo rápido (API) a un precio 2x. Enciéndalo por proveedor con la fila Off/On en la página Modelos del panel de control, o configure `providers.anthropic.fastEnabled: true` (o el mismo campo en `anthropic-apikey`). Mientras está desactivado, esos modelos no publican ningún cambio rápido o fila `--fast` y el proxy nunca envía `speed`, incluso con un `fastMode: true` global. Claude Code passthrough nativo aún reenvía un campo `speed` que el llamante se envía a sí mismo (por ejemplo Claude Code `/fast`), porque esa solicitud nunca alcanza la política Fast del proxy. Cursor Fast y otros proveedores no se ven afectados.
+
+Cuando está habilitado, un `--fast` o un selector rápido elegible envía `speed: "fast"` y agrega `fast-mode-2026-02-01` al encabezado `anthropic-beta` existente. El proxy conserva OAuth valores beta y envía un encabezado deduplicado. `fastMode: false` desactiva esta inyección.
+
+El eco `usage.speed` de Anthropic determina el resultado: `fast` confirma Fast, `standard` registra una degradación y un eco faltante no está confirmado. Solo el uso rápido confirmado recibe la estimación de precio de lista 2x (Opus 5.5 $ 8 de entrada / $ 40 de salida; Opus 5 y 4.8 $ 10 de entrada / $ 50 de salida por millón de tokens). Si se rechaza el primer envío rápido porque se requieren créditos de uso, una organización desactiva Fast, el modelo rechaza `speed` o el grupo rápido está vacío, el envío del adaptador principal puede hacer un reenvío de velocidad estándar presupuestado. Los límites de velocidad genéricos y los errores de capacidad mantienen su manejo habitual. Las compilaciones posteriores de esa solicitud permanecen a la velocidad estándar; un nuevo giro puede encontrar el rechazo nuevamente.
+
+Suscripción Fast en Pro/Max necesita créditos de uso; Las organizaciones de equipos/empresas también necesitan habilitación de administrador. La primera parte API Fast es una vista previa de investigación que requiere acceso. Consulte [Anthropic Modo rápido](https://platform.claude.com/docs/en/build-with-claude/fast-mode) y [Claude Code Modo rápido](https://code.claude.com/docs/en/fast-mode) para conocer los términos de acceso y facturación.
+
+<a id="cursor-fast-cursor-variant"></a>
+
+### Cursor rápido (`cursor-variant`)
+
+Cursor no tiene campo `service_tier`. Su producto rápido es un diferente **variante modelo** - `claude-opus-5-thinking-high-fast`, un parámetro de solicitud `{id:"fast",value:"true"}` para Grok 4.5/4.6, o un identificador de cable `grok-4.7-{effort}-fast` aplanado para Grok 4.7, por lo que la entrada Cursor declara `fastWire.kind: "cursor-variant"` y el generador de solicitudes resuelve la variante en lugar de establecer un campo de solicitud.
+
+Solo las bases que realmente declaran una variante rápida anuncian Fast: `claude-opus-4-7`, `claude-opus-4-8`, `claude-opus-5`, `claude-opus-5-5`, `grok-4.5`, `grok-4.6`, `grok-4.7`. Cada otra fila Cursor publica `supportsServiceTier: false`, por lo que Codex no muestra ninguna palanca en lugar de una muerta.
+
+Una base cuya fila de paraguas dirige las actualizaciones de pensamiento a su variante **pensamiento-rápido**, no al hermano rápido simple: ese hermano es un producto diferente con una escalera de esfuerzo más corta, y para `claude-opus-5` su familia regular está en cuarentena aguas arriba.
+
+`fastMode` se comporta de manera diferente por superficie, ya que solo Codex tiene una palanca rápida propia:
+
+| Superficie | `fastMode: true` |
+|---|---|
+| Codex | filas permanecen filas de paraguas; la palanca Fast de la aplicación selecciona la variante |
+| Claude Code ( `?ids=cli` ) | enumera la identidad rápida, p. ej. `ocx-claude-cursor--claude-opus-5-thinking-fast` |
+| OpenAI `/v1/models` | listas `cursor/claude-opus-5-thinking-fast` |
+| Claude Desktop (3P) | inalterado - sus alias están hashizados desde el nombre del modelo |
+| Tablero `/api/models` | ID de fila sin cambios; son las teclas de activación/desactivación |
+
+Las solicitudes se promocionan de cualquier manera: con `fastMode: true`, elegir el ID de paraguas aún se resuelve en la variante rápida, por lo que un cliente cuya configuración guardada sea anterior al conmutador no necesita redescubrir. Cada ID de variante heredada mantiene el enrutamiento sin cambios.
+
+<a id="xai-priority-processing"></a>
+
+### Procesamiento prioritario de xAI
+
+El preajuste integrado `xai` admite Fast en sus dos transportes, con alcances distintos.
+El modo de clave API usa `https://api.x.ai/v1`. Las rutas resueltas como `openai-chat`
+envían `service_tier: "priority"` mediante Chat Completions; los valores predeterminados
+y las anulaciones de cada modelo pueden seleccionar `openai-responses` en su lugar.
+`ocx login xai` guarda credenciales OAuth para la pasarela de suscripción de Grok
+(`https://cli-chat-proxy.grok.com/v1`), que se actualizan automáticamente.
+
+En esa pasarela, Fast se clasifica por modelo según las comprobaciones del 2026-09-13
+y el 2026-09-23. grok-4.7, grok-4.6, grok-4.5, grok-4.3,
+grok-4.20-0309-reasoning, grok-4.20-0309-non-reasoning, grok-build-0.1 y
+grok-composer-2.5-fast aceptan `service_tier: "priority"` mediante Grok OAuth y lo
+devuelven en la respuesta. Por ello, sus filas anuncian Fast, aceptan selectores
+`--fast` y reenvían el nivel enviado por el cliente en cualquiera de los transportes.
+grok-4.20-multi-agent-0309 queda excluido: cuando recibe `priority`, la pasarela
+responde `service_tier: "default"`; el modelo permanece sin clasificar y no se reenvía
+el nivel solicitado por el cliente. Los modelos que no figuran en la lista permanecen
+sin clasificar en ambos transportes.
+
+En la pasarela OAuth, Fast funciona de otra manera para Grok 4.7. La pasarela también
+ofrece `grok-4.7-build-fast`, el mismo modelo sobre hardware de servicio más rápido:
+las mediciones indicaron aproximadamente 1.6 × la velocidad de `grok-4.7`.
+El procesamiento prioritario de `grok-4.7` no resultó más rápido y consumió
+aproximadamente 6 × el uso de suscripción por token de salida. La lista Modelos muestra
+por ello una única fila de Grok 4.7. Elegir su fila Fast (`xai/grok-4.7--fast`),
+enviar `service_tier: "priority"` o activar el modo Fast envía la solicitud como
+`grok-4.7-build-fast`, sin nivel de servicio. Los registros conservan `grok-4.7`
+como modelo y guardan `grok-4.7-build-fast` como modelo del protocolo. El modo de
+clave API sigue igual: build-fast no está en la API pública de xAI y Grok 4.7 Fast
+sigue significando procesamiento prioritario en esa ruta. Una selección explícita
+`xai/grok-4.7-build-fast` procedente de una configuración anterior sigue funcionando.
+
+Si el proveedor no tiene un `fastWire` explícito, una clave API de opencodex
+restringida por `allowedModels` debe permitir `xai/grok-4.7-build-fast` o su
+identificador sin prefijo para usar OAuth Fast. Permitir solo `xai/grok-4.7` no
+autoriza esta variante Fast. Una clave que permite únicamente el modelo del protocolo
+Fast puede usarlo; las solicitudes normales o con Fast desactivado siguen requiriendo
+`xai/grok-4.7`. Con un `fastWire` explícito, permita el modelo que realmente se
+envía. Por ejemplo, un transporte `service-tier` conserva `xai/grok-4.7` y requiere
+permiso para ese modelo. Las restricciones por proveedor siguen vigentes.
+Estas reglas se aplican a Responses, Chat Completions, Messages y las solicitudes de
+compactación enrutadas.
+
+xAI cobra Priority Processing a 2 × el precio estándar de los tokens de entrada,
+salida, caché y razonamiento; los descuentos de caché se aplican antes del
+multiplicador. Las estimaciones solo incluyen ese recargo cuando la respuesta de xAI
+confirma `service_tier: "priority"`. Si el nivel falta, no se puede interpretar o
+la respuesta devuelve `default`, se conserva el precio estándar.
+
+Para `grok-4.6` y `grok-4.7`, la tarifa estándar por 1M de tokens es $2.00 de
+entrada, $0.50 de entrada en caché y $6.00 de salida. Un prompt de al menos
+200.000 tokens cambia la tarifa de toda la solicitud a $4.00 / $1.00 / $12.00.
+xAI no ha publicado cómo se combina esa banda de contexto largo con Priority
+Processing. Cuando una respuesta de contexto largo confirma `priority`, el panel
+muestra el costo publicado de contexto largo con un marcador `≥` y una explicación
+de que se trata de un límite inferior; no inventa un multiplicador combinado.
+
+<a id="openrouter-fast"></a>
+
+### OpenRouter Rápido
+
+El preajuste canónico `https://openrouter.ai/api/v1` anuncia Fast solo para estos ids de modelo exactos respaldados por OpenAI:
+
+- `openai/gpt-5.6-sol`
+- `openai/gpt-5.6-terra`
+- `openai/gpt-6.1-terra`
+- `openai/gpt-5.6-luna`
+
+`anthropic/claude-sonnet-5` y OpenRouter modelos no declarados permanecen sin clasificar. Un valor predeterminado de nivel de proveedor `supportsServiceTier` está intencionalmente ausente, y un conjunto de usuarios `supportsServiceTier: false` aún desactiva las declaraciones de modelo exacto. Las declaraciones del registro se aplican solo mientras el proveedor aún se dirige a la URL base canónica OpenRouter; no se supone que un destino personalizado del mismo nombre comparta el contrato de OpenRouter.
+
+Envíos rápidos `service_tier: "priority"`. No añade ni reescribe `provider.only`, `provider.order` o `provider.allow_fallbacks`. OpenRouter documenta los puntos finales prioritarios como la primera opción de enrutamiento, seguido de un elegante retorno a otros puntos finales cuando la capacidad de prioridad no está disponible. La facturación sigue el punto final realmente utilizado, y la respuesta informa el nivel superior real `service_tier`. Por lo tanto, fijar los puntos finales de nivel y deshabilitar las opciones alternativas reduciría la disponibilidad sin mejorar la seguridad de la facturación.
+
+Los registros de solicitud usan ese eco de respuesta como autoridad. `priority` confirma Rápido según se aplica; `default` registra una degradación y utiliza la estimación del precio estándar; un campo faltante deja el intento asumido en lugar de adivinar una degradación. El multiplicador de prioridad de OpenRouter varía según el flujo ascendente y no se incluye aquí. Cuando se confirma la prioridad pero no se conoce un precio de prioridad exacto, el panel de control mantiene la estimación del precio estándar como un límite inferior documentado y la prefija con `≥`; los intentos degradados no tienen un marcador de límite inferior.
+
+Los proveedores de claves API pueden tener una clave literal o una referencia de entorno. OAuth proveedores utilizan el almacén de credenciales poblado por `ocx login`; el comportamiento de lanzamiento de Claude Code respaldado por suscripción se configura en [`claudeCode.authMode`](/es/reference/configuration/server/#claude-code-claudecode).
+
+OrcaRouter expone ambos formularios explícitamente: `orcarouter` es el proveedor de claves API manual y `orcarouter-oauth` ejecuta el consentimiento del navegador con S256 PKCE, luego almacena la clave API duradera devuelta como una credencial de cuenta. El público por defecto divide intencionalmente la autenticación (`https://www.orcarouter.ai`) de la inferencia (`https://api.orcarouter.ai/v1`). Establecer `ORCAROUTER_BASE_URL` antes del inicio de sesión de la primera cuenta para una implementación autohospedada de un origen, o usar `ORCAROUTER_AUTH_BASE_URL` y `ORCAROUTER_API_BASE_URL` para orígenes separados. Para un punto final autoalojado privado/loopback, **antes del primer inicio de sesión**, cree o actualice `providers["orcarouter-oauth"]` con `adapter: "openai-chat"`, el previsto `baseUrl`, `authMode: "oauth"` y un `allowPrivateNetwork: true` explícito. El inicio de sesión conserva esa configuración del operador y nunca la otorga una anulación de URL. Sin ella, la validación de destino rechaza el punto final local para la inferencia y el descubrimiento de modelos. El oyente de devolución de llamada del navegador OAuth en sí no requiere esta opción de proveedor. Ver el [Ejemplo de configuración de OrcaRouter](/es/guides/providers/).
+
+<a id="provider-diagnostic-outbound-safety"></a>
+
+## Seguridad de salida de diagnóstico del proveedor
+
+Las pruebas de conexión del panel de control y el descubrimiento de modelos en vivo utilizan un transporte limitado solo GET. Sin un proxy de salida, opencodex resuelve el nombre de host una vez y se conecta solo a esa dirección validada. HTTPS conserva la verificación original de host, SNI y certificado; la configuración del proveedor no puede deshabilitar las verificaciones de certificados.
+
+Las descargas de respuestas directas se pausan cuando el procesamiento local aún no está listo
+para recibir más datos, también en respuestas gzip y deflate. Esa pausa no cuenta como inactividad
+del proveedor; el plazo total de la solicitud y la cancelación siguen vigentes.
+
+Estas operaciones utilizan el [transporte de salida configurado en el servidor](/es/reference/configuration/server/). Un servidor proxy SOCKS5 — establecido con
+`config.proxy` o heredado de un SOCKS5 `ALL_PROXY` — utiliza el túnel incorporado de OpenCodex cuando
+`NO_PROXY` No exime al objetivo. Esquema específico `HTTP_PROXY` y
+`HTTPS_PROXY` conservar el manejo nativo de HTTP(S) de Bun, mientras que un manejo no SOCKS `ALL_PROXY` No es un nativo Ruta HTTP fetch. URL y las comprobaciones de direcciones literales aún se ejecutan, pero un proxy seleccionado elige el final ruta, respuesta DNS y par, por lo que opencodex no puede fijar o verificar ese par. Este es un explícito Limitación de seguridad.
+
+Los destinos privados/locales requieren `allowPrivateNetwork: true` y, cuando un proxy saliente está activo, una entrada `NO_PROXY` coincidente. Loopback se agrega automáticamente; lista cada host LAN explícitamente porque las entradas CIDR no se interpretan. El emparejador admite hosts exactos, sufijos de dominio, puertos opcionales, IPv6 entre corchetes y `*`; por ejemplo, enumere `192.168.1.50` explícitamente. Los metadatos y los destinos locales de enlace permanecen bloqueados. Las solicitudes de diagnóstico rechazan las redirecciones e informan sobre un destino con credenciales eliminadas. La revisión ordinaria de la redirección de solicitudes del proveedor permanece separada de esta guardia de diagnóstico.
+
+Dos falsos IP DNS existen adaptaciones para los usuarios de Clash / Surge / Mihomo, y ambos se aplican a DNS
+*respuestas* solo — una dirección literal en el URL sigue siendo rechazada. La gama de referencia IANA
+`198.18.0.0/15` (y su ortografía IPv4-mapped IPv6) se acepta siempre que un proxy saliente aplique al anfitrión. El rango de IPv6 fake-IP predeterminado de Mihomo `fdfe:dcba:9876::/48` es aceptado en un estricto puerta: la variable proxy que coincide con el esquema URL (`HTTPS_PROXY` por
+`https:`, `HTTP_PROXY` por `http:`o un SOCKS5 `ALL_PROXY` debe ser establecido (un non-SOCKS `ALL_PROXY` hace no contar), el anfitrión no debe coincidir `NO_PROXY`, y el La solicitud se vincula a ese proxy explícitamente. Cualquier otro ULA, un prefijo adyacente o una respuesta de IP falsa mezclada con una respuesta privada real todavía requiere `allowPrivateNetwork: true`. Tiempo de ahorro del proveedor La validación nunca aplica la acomodación IPv6.
+
+<a id="codex-account-pool"></a>
+
+## Grupo de cuentas Codex
+
+Utilice **Codex Auth** en el panel de control para agregar cuentas de grupo y actualizar cuotas. `config.json` almacena metadatos no secretos; los tokens de acceso y actualización usan el almacén de credenciales reforzado. El enrutamiento Pool separa la asignación nueva/no vinculada, la conmutación proactiva basada en el uso y la recuperación de fallas. Una tarea ligada normalmente mantiene la afinidad. Por defecto (`pool.cacheAffinity`) `quota` no lo vuelve a vincular simplemente porque se cruza el umbral de uso; ese rebind espera hasta que la cuenta vinculada se agote o no pueda servir, y luego solo en una cuenta con margen de cuota genuino y uso estrictamente más bajo. Establecer `pool.cacheAffinity: false` para restaurar la reasignación umbral de las tareas vinculadas, todavía sólo en tal destino. La pausa, el tiempo de reutilización, la reautenticación y los rechazos de cuotas aún liberan un enlace en vivo de inmediato. Una racha de fracaso transitorio sirve la solicitud de otra cuenta mientras se mantiene el enlace, y la tarea vuelve una vez que la cuenta sirve de nuevo; después de 10 minutos, el enlace se libera normalmente. Una solicitud sin vínculo no tiene una cuenta asociada activa. Los vínculos de solicitudes con un ID de sesión, incluidos los turnos habituales de Codex CLI, App y subagentes, o de solicitudes sin sesión ancladas a su padre inmediato, pueden sobrevivir a un reinicio ordenado del proxy hasta 24 horas de inactividad si el guardado final de afinidad al apagar termina correctamente. Las cadenas más profundas sin sesión y los vínculos al inicio de sesión principal de Codex App solo existen en memoria y se asignan otra vez tras el reinicio. La expulsión de caché, la eliminación de la cuenta, otro inicio de sesión, un cierre inesperado o un restablecimiento de afinidad pueden dejar una tarea sin vínculo. Una respuesta previa al flujo 429 o 402, o una respuesta 5xx cuyo cuerpo limitado informa explícitamente del agotamiento de la cuota, vuelve a intentar una vez en una cuenta alternativa elegible en la misma solicitud, incluso cuando la conmutación proactiva basada en el uso está desactivada. La política transitoria ordinaria 5xx se ejecuta en primer lugar, por lo que una respuesta de cuota incluida puede generar hasta tres envíos en la cuenta agotada antes de la rotación del grupo. Los cambios en la cuenta preservan y reproducen el contexto de la conversación, pero no se garantiza la reutilización del prompt-cache del lado del proveedor en todas las cuentas y es posible que la caché deba calentarse nuevamente.
+
+En un **401/403**, el inicio de sesión de la aplicación borra la afinidad de proceso local de esa cuenta y requiere una reautenticación. En un **429**, opencodex honra a `Retry-After`, inicia el enfriamiento de la cuenta, borra la afinidad y puede rotar la solicitud a otra cuenta elegible de Pool. Estas transiciones de falla permanecen activas con `autoSwitchThreshold: 0`; esa configuración deshabilita solo la conmutación proactiva basada en el uso.
+
+La pausa de una cuenta conserva sus metadatos de cuota, pero la excluye de la conmutación, conmutación por error, sondas de recuperación y activación manual. También aclara las afinidades de hilo de esa cuenta. Las solicitudes en vuelo mantienen las credenciales capturadas; los giros posteriores se redirigen. Si todas las cuentas están en pausa, el enrutamiento Pool falla en lugar de elegir una silenciosamente. **Pausa agotada** actualiza las cuentas elegibles con credenciales disponibles y pausa solo las cuentas recién confirmadas al 100%; las actualizaciones desconocidas o fallidas permanecen sin cambios.
+
+| Estrategia | Comportamiento |
+| --- | --- |
+| `quota` (por defecto) | Si no existe una cuenta activa, elija la cuenta elegible de menor uso en ventanas de 5 horas, semanales y de 30 días. De lo contrario, mantenga una cuenta activa elegible por debajo de `autoSwitchThreshold`; después de que cruce el umbral, una solicitud no vinculada puede pasar a una cuenta elegible de menor uso. Las tareas vinculadas mantienen la afinidad de caché de forma predeterminada y permanecen hasta que la cuenta se agote (uso conocido al 100%) o no pueda servir (pausa, inutilizable); un movimiento requiere espacio libre de cuota genuino y un uso estrictamente menor en el destino, por lo que la tarea se mantiene cuando cada cuenta supera el umbral o la única cuenta más fresca tiene un uso desconocido. Establecer `pool.cacheAffinity: false` para permitir que la siguiente solicitud de una tarea vinculada se mueva en el umbral, todavía solo a tal destino. `0` deshabilita esta reevaluación basada en el uso, no la recuperación de fallas. |
+| `round-robin` | Asigna uniformemente las solicitudes sin vínculo entre cuentas aptas mediante un contador. Una asignación nueva omite las cuentas que alcanzan o superan su `autoSwitchThreshold` efectivo, específico de cuenta o global y evaluado como en `quota`, mientras haya alguna apta por debajo. El uso desconocido y un umbral `0` cuentan como inferiores al umbral. Una selección manual del operador recibe la siguiente asignación en cada ámbito de cuota cualquiera que sea su uso; una solicitud correcta en ese ámbito consume la selección y las asignaciones posteriores vuelven a aplicar el umbral. Si todas las cuentas aptas alcanzan o superan su umbral, la rotación incluye a todas. Una tarea vinculada conserva su cuenta más allá del umbral y solo cambia si no puede atenderla: enfriamiento, rechazo por cuota, failover o pausa. Un hijo de una conversación activa comienza en la cuenta de su padre. El filtro compartido por nivel de prioridad evalúa el margen del mismo modo. `accountPoolStickyLimit` (1–100) cuenta asignaciones de una elección, no respuestas correctas del proveedor. |
+| `fill-first` | Asignar solicitudes no vinculadas a la cuenta activa hasta el tiempo de reutilización, la reautenticación o el umbral de drenaje efectivo de esa cuenta (anulación de cuenta o valor predeterminado global); el uso desconocido no obliga a cambiar. Las tareas atadas saludables mantienen la afinidad. |
+
+La rotación no protege contra la aplicación del proveedor; el uso de múltiples cuentas puede violar los términos del proveedor.
+
+### `anthropicAccountPool` (experimental)
+
+Esta opción agrupa varias cuentas OAuth Anthropic ya almacenadas en `auth.json`. Está desactivado por defecto y experimental, y Anthropic no ha respaldado la agrupación automatizada de cuentas. Las cuentas de la misma organización pueden compartir cuotas, y el cambio de cuentas no protege contra las restricciones del proveedor. Vea el [Claude Code guía](/es/guides/claude-code/#claude-oauth-account-pool-experimental) para las condiciones de suscripción y cliente para las que está destinado el grupo.
+
+| Clave | Tipo | Predeterminado | Descripción |
+| --- | --- | --- | --- |
+| `anthropicAccountPool.enabled?` | `boolean` | `false` | Habilitar la afinidad de sesión pegajosa y la selección de nueva sesión con clasificación de cuota. **429 failover no está cerrado aquí**: se activa cada vez que se almacenan dos o más cuentas utilizables, exactamente como cualquier otro proveedor multicredencial, y no se puede desactivar. |
+| `anthropicAccountPool.nativeMessages?` | `boolean` | `true` | Prefiera Claude Messages nativo para rutas directas elegibles Anthropic cuando la agrupación esté habilitada. Todavía se aplican las opciones de exclusión de implementación nativa explícita. `false` selecciona el puente heredado para las solicitudes agrupadas; pool-off conserva el comportamiento de despliegue explícito. |
+| `anthropicAccountPool.autoSwitchThreshold?` | `number` | `80` | Para sesiones nuevas, al alcanzar la cuenta activa este umbral, elige el menor uso conocido en caché de la ventana configurada, con preferencia por cuentas aún por debajo de su propio umbral; la cuenta elegida no tiene que haber alcanzado el umbral. `0` desactiva solo el cambio **proactivo** basado en uso: la selección de sesiones nuevas y la recuperación de un 429 apto siguen consultando `quotaWindow`. |
+| `anthropicAccountPool.strategy?` | `"quota" \| "round-robin" \| "fill-first"` | `"quota"` | Estrategia de sesiones nuevas. `quota` conserva la cuenta activa hasta que el uso de `quotaWindow` alcanza su `autoSwitchThreshold` efectivo, 80 por defecto, o no puede atender la solicitud. Después cambia a la cuenta de menor uso, prefiriendo las que aún estén por debajo de su propio umbral. Si el uso es desconocido, mantiene la cuenta activa. `round-robin` rota las sesiones nuevas sin consultar umbrales de uso. `fill-first` evalúa su umbral de agotamiento en `quotaWindow`. |
+| `anthropicAccountPool.quotaWindow?` | `"five-hour" \| "weekly" \| "max-utilization"` | `"five-hour"` | Indicador de utilización informado por el proveedor y almacenado en caché para seleccionar cuentas según el uso. `five-hour` conserva el comportamiento original. `weekly` evalúa el uso semanal y omite cuentas con la ventana de cinco horas agotada mientras haya otra apta; si no la hay, permite las agotadas. `max-utilization` evalúa la barra de mayor uso conocido, incluida la de cinco horas antes de conocerse la semanal. Si ninguna se conoce, se aplica el orden de uso desconocido. El uso conocido precede al desconocido solo en `weekly` y `max-utilization`; omitir la opción o usar `five-hour` conserva el orden heredado. Si todas las cuentas aptas tienen uso desconocido, se elige una en orden de elegibilidad. Tras el desempate documentado por menor uso de cinco horas, los empates exactos conservan ese orden. Una sesión sana vinculada por afinidad no se redistribuye proactivamente. Cuando `quota` busca reemplazo, para una sesión nueva cuya cuenta llegó al umbral o no puede atenderla, o tras un 429 apto, prefiere cuentas por debajo de su propio umbral y las ordena con esta ventana. `fill-first` avanza en orden estable con el umbral y las reglas de agotamiento de esta ventana; `round-robin` la ignora. El enfriamiento, los límites de failover y la necesidad de reautenticación siguen siendo estados locales independientes. Los indicadores semanales por cuenta proceden de consultas de uso o encabezados observados. |
+| `anthropicAccountPool.stickyLimit?` | `number` | `1` | Nueva sesión exitosa se une retenido en una selección round-robin. Alcance 1-100. |
+| `anthropicAccountPool.routes?` | `{name, match, accounts, fallback?}[]` | — | Rutas de modelos ordenadas para el grupo Anthropic OAuth habilitado. `match` es un glob de ID de modelo completo y sensible a las mayúsculas de los casos (`*` y `?`); gana el primer partido. `accounts` contiene ID de cuenta almacenados, no alias. Las cuentas elegibles están limitadas a la ruta para la selección inicial y 429 reintentos. Sin reserva, una ruta vacía devuelve un 401 o 429 local con `Retry-After` de alcance de ruta si todas sus cuentas declaradas se están enfriando. Con `fallback: true`, un grupo ordinario de enfriamiento completo devuelve 429 con su primer tiempo de reutilización utilizable, incluso si se eliminó una cuenta de ruta guardada; la respuesta del cliente nunca nombra la ruta; el registro proxy usa `route:#<n>` para la posición basada en la regla 1. `fallback: true` se amplía solo cuando ninguna cuenta enrutada es elegible; primero rellene y luego use el orden de grupo ordinario. Ninguna regla coincidente mantiene la selección normal; la desactivación del grupo hace que las rutas guardadas estén inactivas. Las reglas no válidas no validan las escrituras y evitan el envío encaminado hasta que se corrigen. `null` despeja las rutas a través de los ajustes API. |
+
+Anthropic OAuth ayudantes de visión y búsqueda web coinciden con estas rutas utilizando el modelo de cada ayudante, independientemente del modelo de solicitud principal. Cada ayudante se autentica con su cuenta enrutada, que puede diferir de la cuenta globalmente activa. Si una ruta helper estricta no tiene una cuenta elegible, el helper falla localmente antes de cualquier solicitud del proveedor; no usa silenciosamente una cuenta fuera de la ruta. Cuando la solicitud principal funciona pero falla la descripción de la imagen o la búsqueda web, compruebe el modelo configurado del ayudante y las cuentas elegibles para la ruta de ese modelo.
+
+Los 429 de cuota compartida (ventanas compartidas rechazadas de 5h/7d) enfrían la cuenta de servicio y pueden recuperarse en un hermano elegible. Retry-After gana, de lo contrario se usa el último reinicio válido rechazado, con un valor predeterminado de 60 segundos cuando no se puede usar una fecha límite. Un acelerador de velocidad transitoria pausa solo la admisión de esa cuenta, conserva la afinidad y permite un reintento corto de la misma cuenta más como máximo un desvío de hermanos por solicitud. Un 429 sin encabezado permite como máximo un breve reintento en la misma cuenta, deja la salud de la cuenta intacta y no agrega reintento sintético. Estos reintentos comparten el presupuesto de envío físico y se detienen en la cancelación o en la salida transmitida comprometida. El comportamiento predeterminado de una sola cuenta no cambia. La evidencia semanal y familiar compartida del modelo solicitado determina su admisión en el grupo. Un rechazo solo de Fable mantiene a Sonnet elegible en la misma cuenta. La evidencia pasiva de Fable envejece después de treinta minutos o su reinicio conocido y se revalida con una solicitud de entrega a la vez. Los umbrales de uso siguen siendo preferencias blandas con una alternativa totalmente drenada; estos controles no son límites de uso o facturación difíciles. Las sondas de uso activo preservan las ventanas de familia ausentes a menos que la respuesta enumere los límites de manera autorizada. La afinidad es proceso-local y tamaño-limitado. Los fallos de credenciales de actualización de token conservan la política de autenticación existente. 403s de pre-salida de autorización de cuenta clara afinidad y enfriar la cuenta para `Retry-After`, o diez minutos por defecto, antes de intentar un reemplazo elegible. Los 403 genéricos o de nivel de solicitud siguen siendo terminales; véase [Claude recuperación de la cuenta](/es/guides/claude-code/). Si todas las cuentas elegibles se están enfriando, los clientes reciben 429 con `Retry-After` cuando se conocen, no un error de autenticación.
+
+Cuando cada cuenta que la solicitud puede usar se mantiene en la cuota gastada (una ventana compartida de 5 horas o semanal, o la ventana semanal de la familia de modelos solicitada), ese 429 es un límite de uso en lugar de un límite de tasa: el cuerpo Responses lleva `error.type` y `error.code` `usage_limit_reached` y, cuando se conoce el reinicio aguas arriba de cada cuenta retenida, `resets_at` (segundos de época del primer reinicio). Codex se detiene en esta respuesta y muestra cuándo volver a intentarlo en lugar de reintentar hasta "exceeded retry limit". El rechazo de la última cuenta de la cuota gastada obtiene la misma respuesta una vez que no queda ningún reemplazo. Si alguna cuenta retenida solo está limitada temporalmente por tasa de solicitudes, requiere revalidar una familia de modelos o se rechaza por falta de permisos de uso, la respuesta permanece en el `rate_limit_exceeded` reintentable. Los objetivos de combo conservan la forma de límite de tasa para que el combo pueda pasar a su siguiente objetivo. La ruta nativa `/v1/messages` mantiene el tipo `rate_limit_error` de Anthropic; su mensaje nombra el límite de uso.
+
+Un tiempo de reutilización de cuota se levanta temprano una vez que una nueva lectura de uso (la página de proveedores del panel de control, o `ocx account list anthropic --quota --refresh`) muestra cada ventana que el rechazo rechazó por debajo del 100%, ya sea que el tiempo de reutilización provenga de `Retry-After` o de un reinicio de ventana. Esto cubre una actualización del plan o una ventana que se reabrió antes. Una lectura tomada antes del rechazo nunca lo levanta, y los tiempos de reutilización de los derechos 403 esperan su fecha límite.
+
+Las lecturas de uso priorizan las filas reconocidas de `limits` sobre los contadores heredados. Pro, Max 5x y Team conservan los indicadores medidos de cinco horas y semanales, cualquiera que limite el uso en ese momento. El uso compartido influye en la admisión y la recuperación del enfriamiento aunque el límite esté inactivo. Un contador de cinco horas explícitamente null solo genera un indicador si Anthropic marca como activo un límite finito de sesión. Un límite semanal de una familia solo restringe esa familia mientras esté activo; el semanal global se aplica a todos los modelos. Los contadores heredados Pro/Max siguen siendo compatibles.
+
+[Ultra sustituye a Max 20x](https://support.claude.com/en/articles/17728952-what-is-the-ultra-plan). El proveedor aún puede identificarlo como `claude_max_20x`, mostrado como `max_20x`. Las cuentas Ultra sin límite activo de cinco horas solo muestran el uso semanal. Los nombres de nivel, incluidos los futuros desconocidos, son metadatos de presentación: no implican cuota ni crédito API adicionales. Las autorizaciones de restablecimiento siguen siendo acciones opcionales y explícitas con sus propias condiciones y caducidad; consultar el uso nunca consume una. Un rechazo `access_denied` al consultar la cuota también puede indicar que caducó el token de acceso; cambiar el nombre de un plan no repara las credenciales.
+
+Anthropic respuestas también informan de la utilización de 5 horas y semanal de la cuenta de servicio, y cualquiera de las dos que lleva una respuesta dada se registra contra esa cuenta, cada ventana de forma independiente, tanto sobre los rechazos como sobre los éxitos. Por lo tanto, la selección consciente del uso funciona desde las cuentas que realmente usa, sin esperar a que la página de proveedores del panel de control las interrogue. Estas lecturas actualizan la fila existente en lugar de reemplazarla, por lo que las barras semanales con alcance de modelo solo se conservan los informes de punto final de uso hasta que pase su tiempo de reinicio conocido. Las mediciones caducadas se vuelven desconocidas, incluyendo las ventanas estándar retenidas omitidas por encabezados posteriores. Un encabezado de solo reinicio no puede extender una medición de utilización anterior. Los valores sin restablecimiento conocido conservan su comportamiento existente; las mediciones faltantes nunca se reemplazan con uso cero.
+
+Las observaciones de cabecera no posponen las sondas de uso ni borran el estado no disponible de una sonda fallida. Después del reinicio, las observaciones Anthropic en caché permanecen disponibles mientras la siguiente cuota lee las sondas nuevamente, porque las observaciones guardadas no incluyen el reloj de la sonda.
+
+:::caution[Experimental]
+Deje esto deshabilitado a menos que entienda el riesgo de la política de cuenta Anthropic. Prefiero manual
+`ocx account use anthropic <id>` Cambiar cuando no está seguro.
+:::
+
+<a id="anthropic--pool-2-anthropic2"></a>
+
+### Anthropic · Pool`anthropic2`)
+
+`anthropic2` (" Anthropic + Pool 2") es un segundo proveedor incorporado Anthropic OAuth con su propio fondo de cuentas. Ejecuta la misma implementación Anthropic que `anthropic`: el mismo flujo de inicio de sesión, formato de cable, puente nativo Messages y Responses y metadatos del modelo. Solo las cuentas y el grupo a su alrededor están separadas. Elija un grupo con el prefijo del modelo: `anthropic/claude-sonnet-5` usa el grupo principal y `anthropic2/claude-sonnet-5` usa Pool 2.
+
+Pool 2 permanece inactivo hasta que lo agregue. Inicie sesión con `ocx login anthropic2` o agregue **Anthropic · Pool 2** en la página de proveedores del panel de control. Un primer inicio de sesión exitoso crea `providers.anthropic2` con el marcador `"anthropicOAuthInstance": "anthropic2"`. Pool 2 nunca se convierte en el proveedor predeterminado: los nombres de modelo `claude-*`, el modelo predeterminado y el reenvío de llamadas Claude Code siguen resolviendo `anthropic`. Una entrada `anthropic2` sin marcar que creó anteriormente mantiene su significado personalizado; el inicio de sesión rechaza la colisión del nombre y no reescribe ni la entrada ni sus credenciales.
+
+Pool 2 lee la configuración de su grupo desde su propia entrada de proveedor. Las claves, los valores predeterminados y el comportamiento coinciden con el nivel superior [`anthropicAccountPool`](#anthropicaccountpool-experimental), y nada se hereda del grupo principal. `providers.anthropic.anthropicAccountPool`, o el campo en cualquier otro proveedor, es rechazado.
+
+```json
+{
+  "anthropicAccountPool": { "enabled": true, "strategy": "quota" },
+  "providers": {
+    "anthropic2": {
+      "adapter": "anthropic",
+      "authMode": "oauth",
+      "baseUrl": "https://api.anthropic.com",
+      "anthropicOAuthInstance": "anthropic2",
+      "anthropicAccountPool": { "enabled": true, "strategy": "round-robin" }
+    }
+  }
+}
+```
+
+Los dos grupos están aislados dentro de opencodex:
+
+- **Credenciales:** Pool 2 cuentas se almacenan bajo su propia clave `anthropic2` en el almacén de credenciales protegidas. Se rechaza un inicio de sesión cuyo token o cuenta verificada Anthropic ya está almacenada en el otro grupo.
+- **Pool configuración y estado de ejecución:** selección, afinidad de sesión, tiempos de reutilización, pausas, rutas de modelo y umbrales por cuenta pertenecen a un grupo. La ruta `fallback: true` se ensancha solo dentro de el mismo grupo.
+- **Cuota y uso:** sondas de uso, cachés de cuota y atribución de uso se registran por grupo, por lo que un ID de cuenta que existe en ambos grupos todavía tiene dos registros separados.
+- **Restablecer subvenciones:** Pool 2 mantiene su propio diario (`anthropic2-reset-grant-ledger.json`) junto al diario sin cambios del grupo primario.
+- **Recuperación:** a directo `anthropic2/<model>` La petición nunca vuelve al grupo principal, y un El límite de solicitudes o el rechazo de Pool 2 nunca enfría una cuenta de grupo principal. Un combo explícito que nombra a ambos pools mantiene los objetivos declarados.
+
+Esta separación es un límite de enrutamiento dentro de opencodex. No cambia la forma en que Anthropic trata sus cuentas o el [riesgo de política de cuenta](#anthropicaccountpool-experimental) descrito anteriormente.
+
+Pool 2 cuentas se agregan solo a través del navegador OAuth. A diferencia de `anthropic`, Pool 2 nunca importa, adopta o escribe un token Claude Code CLI; esta diferencia es intencional. Pool 2 comienza vacío, y una Pool 2 solicitud sin Pool 2 cuenta utilizable falla con un error de autenticación en lugar de tomar prestado un grupo primario o Claude Code credencial.
+
+Los comandos de cuenta y las API de administración toman el grupo por su nombre: `ocx account pool anthropic2 …`, `ocx account auto-switch anthropic2 …`, `ocx account routes anthropic2 …` y `ocx account anthropic-reset-grants --provider anthropic2`. La configuración del grupo y los puntos finales de concesión de reinicio aceptan `provider: "anthropic2"`; omitiéndolo mantiene el grupo principal.
+
+<a id="helper-pool-selection-anthropicinstance"></a>
+
+#### Selección de grupos de ayuda (`anthropicInstance`)
+
+Los ayudantes de búsqueda y visión web aceptan un `anthropicInstance` opcional, en la configuración global `webSearchSidecar` y `visionSidecar` y en el Claude Code anula `claudeCode.webSearchSidecar` y `claudeCode.visionSidecar`. El panel de control lo muestra como un **Pool** seleccionar cuando el helper backend es Anthropic.
+
+| Valor | Comportamiento |
+| --- | --- |
+| unset (por defecto) | Siga el grupo de la solicitud actual: una solicitud `anthropic2/<model>` utiliza Pool 2 y una solicitud `anthropic/<model>` utiliza el grupo principal. Una solicitud de otro proveedor mantiene el descubrimiento de ayudante existente, que nunca selecciona Pool 2. |
+| `"anthropic"` | Utilice siempre el grupo principal. |
+| `"anthropic2"` | Utilice siempre Pool 2. |
+
+El campo solo se aplica cuando el backend del ayudante se resuelve a Anthropic. Establecerlo con otro backend es un error de validación; porque la búsqueda web por defecto es OpenAI, también establece `"backend": "anthropic"`. También se rechaza un modelo de ayudante calificado con el otro grupo, como `anthropic/claude-sonnet-5` con `"anthropicInstance": "anthropic2"`. Si el grupo elegido no tiene una cuenta utilizable, el ayudante falla antes de enviar nada; no cambia al otro grupo. La solicitud principal continúa sin ese ayudante. Una elección no establecida se guarda como ausente, nunca como `"anthropic"`.
+
+```json
+{
+  "webSearchSidecar": { "backend": "anthropic", "anthropicInstance": "anthropic2" }
+}
+```
+
+:::caution[Volver a una versión anterior]
+Las versiones sin Pool 2 no entienden la `anthropic2` entrada. Antes de instalar un viejo versión, detener el proxy, copia de seguridad `config.json` y `auth.json`, y eliminar
+`providers.anthropic2` Desde `config.json`. Las credenciales de grupo primario nunca se mueven ni reescriben Pool 2. No se admite una degradación in situ con un Pool 2 activo.
+:::
+
+### `oauthAccountFailover`
+
+Rota a otra cuenta registrada del mismo proveedor cuando uno está limitado por tarifa, para OAuth proveedores que no tienen un grupo propio: xAI, Cursor, Kimi, GitHub Copilot, Google Antigravity y Nous.
+
+**Entrar en una segunda cuenta es lo que enciende esto, y nada lo apaga.** Rotación activa para cualquiera de esos proveedores que posean 2 o más cuentas que no estén marcadas para Reautenticación — la misma regla `apiKeyPool` ya se aplica a un grupo de claves 2+. Un proveedor con una cuenta almacenada se comporta exactamente como antes.
+
+La rotación aquí se ejecuta solo *después* aguas arriba ya ha rechazado la solicitud, por lo que la única opción que un interruptor de desactivación podría ofrecer es entre volver a intentar en una segunda cuenta que inició sesión deliberadamente y devolver un 429 mientras esa cuenta permanece inactiva. El rechazo de la rotación se expresa al no almacenar una segunda cuenta.
+
+| Clave | Tipo | Predeterminado | Descripción |
+| --- | --- | --- | --- |
+| `oauthAccountFailover.enabled?` | `boolean` | presencia-conducido | Anulación global solo para el **Preferencia de cuenta pre-envío**. `false` impide que una solicitud saludable se dirija hacia la cuenta con más espacio libre conocido. No desactiva la rotación ante errores 429. |
+| `providers.<name>.oauthAccountFailover.enabled?` | `boolean` | hereda | Anulación por proveedor para la misma preferencia; supera la configuración global en cualquier dirección. `false` declina la preferencia por este proveedor incluso cuando la configuración global es `true`, y `true` opta por este proveedor incluso cuando la configuración global es `false`. La rotación reactiva 429 no se ve afectada de ninguna manera. |
+| `providers.<name>.oauthAccountFailover.sessionAffinity?` | `"conversation" \| "none"` | `"none"` | Conversación opt-in para grupos genéricos OAuth. Requiere `enabled: true` proactivo (proveedor o valor global heredado). Las sesiones existentes mantienen su cuenta por delante de la estrategia de la nueva sesión hasta que no esté disponible. |
+| `providers.<name>.oauthAccountFailover.strategy?` | `"quota" \| "round-robin" \| "fill-first" \| "reset-first" \| "least-loaded"` (solo Kiro) | — | `least-loaded` de Kiro elige la cuenta elegible con la menor cantidad de solicitudes en vuelo, utilizando el orden de las cuentas para resolver los empates. Requiere `pool.kernel` y preferencia proactiva; otras estrategias conservan sus reglas existentes. `reset-first` también requiere `pool.kernel`: entre las cuentas elegibles que no se agotan, el primer intento (mientras que la preferencia proactiva está activada) y una rotación de 429 prefieren la cuenta cuya cuota se restablece más pronto (la ventana semanal cuando se informa, de lo contrario la ventana de 5 horas), con mayor margen disponible para resolver los empates. Las cuentas agotadas son las últimas. Sin evidencia de cuotas, o cuando un proveedor pasivo tiene evidencia solo para algunas cuentas, vuelve al orden de margen. El grupo Anthropic no lo acepta. |
+| `providers.kiro.oauthAccountFailover.maxConcurrentPerAccount?` | número entero 1-100 | ilimitado | Una cola por cuenta de proceso local mantiene una ranura hasta la finalización o cancelación de la respuesta. Una cuenta seleccionada completa espera como máximo 250 ms, luego devuelve 503 `account_capacity` con `Retry-After: 1`. El límite no mueve la solicitud a otra cuenta. |
+| `providers.<name>.oauthAccountFailover.autoSwitchThreshold?` | `number` | `80` | 0-100 por ciento de uso en el que `fill-first` avanza fuera de la cuenta activa (#695). Juego con `ocx account auto-switch <provider> threshold <n>`. Leer solo por debajo de `pool.kernel` con `strategy: "fill-first"`; una cuenta sin uso medido cuenta como debajo del umbral. |
+| `providers.<name>.oauthAccountFailover.stickyLimit?` | `number` | `1` | Los despachos exitosos se conservaron en una selección de `round-robin`, 1-100 (#695). Leer solo bajo `pool.kernel` con `strategy: "round-robin"`. |
+
+Para rechazar la dirección proactiva de la cuenta para un proveedor cuyos términos preferiría no probar, mientras se recupera de un límite de solicitudes:
+
+```json
+{
+  "providers": {
+    "cursor": {
+      "oauthAccountFailover": { "enabled": false }
+    }
+  }
+}
+```
+
+Esa configuración sobrevive al inicio de sesión, la adición de una cuenta y la reautenticación.
+
+Los proveedores genéricos OAuth (Google Antigravity, xAI, Cursor, Kimi, GitHub Copilot, Nous y cualquier otro proveedor OAuth fuera de los grupos Codex y Anthropic) también aceptan `strategy` y `autoSwitchThreshold` en la misma clave, a través de `GET` / `PUT /api/oauth/accounts/pool?provider=<name>` y los verbos `ocx account strategy` / `ocx account auto-switch` / `ocx account sticky`. La respuesta transporta `"inert"` para esos tres campos solamente - `true` mientras están almacenados pero no consumidos, `false` una vez que `pool.kernel` está encendido y realmente seleccionan una cuenta - `enabled` está activa y gobierna la preferencia de pre-despacho. `quotaWindow` no forma parte del contrato genérico. Codex ( `/api/codex-auth` ) y Anthropic ( `anthropicAccountPool` ) mantienen sus propios contratos sin cambios.
+
+Establecer `providers.<name>.oauthAccountFailover.sessionAffinity` a `"conversation"` junto con `enabled: true` para mantener una conversación en su cuenta admitida. La identidad de sesión usa el marcador de subproceso cliente, encabezados de sesión, encabezado de subproceso, luego `prompt_cache_key`; se excluye una cohorte de caché de escritorio compartida. Los enlaces son aislados por el proveedor, el hogar de configuración y el principal de llamada autenticado. Las llamadas locales no autenticadas comparten el alcance local. Sin marcador de sesión significa que no hay unión.
+
+Las nuevas sesiones utilizan la estrategia existente (`pool.kernel` todavía puertas round-robin/fill-first). Las sesiones existentes permanecen ancladas incluso cuando otra cuenta tiene más cuota. Una pausa, un requisito de reautenticación, un tiempo de reutilización familiar o una lista de modelos incompatibles liberan la vinculación; la recuperación de fallas limitada existente vincula el reemplazo admitido. El límite de concurrencia de Kiro aún espera o se niega en lugar de mover una conversación vinculada saludable simplemente para equilibrar la carga.
+
+En este modo, las opciones automáticas, incluidas las solicitudes sin claves y las conmutación por error, permanecen locales: la cuenta seleccionada del panel de control sigue siendo la selección del operador. El historial de solicitudes sigue atribuyendo la cuenta de servicio. La selección manual, la reselección de la misma cuenta y los cambios en la revisión de la lista/política invalidan los vínculos del proveedor, incluidas las escrituras de otro proceso. Una actualización ordinaria mantiene la misma cuenta. Fill-first conserva su cuenta actual en la memoria sin cambiar la selección guardada. Los enlaces expiran después de 24 horas sin admisión, están limitados a 2.000 entradas en todo el proceso (incluidos los cursores de relleno primero) y se pierden al reiniciar. Establezca `sessionAffinity: "none"` o deshabilite la preferencia proactiva para liberarlos. Codex y Anthropic mantienen sus propios contratos de afinidad.
+
+El grupo Codex y el grupo Anthropic están excluidas y mantienen su propia rotación; permitiendo que esto cambie tampoco. Un proveedor con una sola cuenta almacenada es un estricto no-op, y no se registra ningún tiempo de reutilización para ello.
+
+Antes del envío, genérico OAuth instantáneas de la lista elegible. En un 429 la cuenta fallida se enfría usando `Retry-After` cuando está presente (limitada a 15 minutos) o un retroceso predeterminado, y la solicitud se reproduce en la siguiente cuenta seleccionada de la lista en vivo. El techo de rotación estable es `max(3, min(eligibleCount, 6) - 1)` por solicitud; la selección en vivo aún filtra los tiempos de reutilización, y nunca se selecciona una cuenta marcada para la reautenticación. Los tiempos de reutilización son locales, por lo que un reinicio los olvida.
+
+Cuando al menos dos cuentas son elegibles, la asignación de envío por defecto de propiedad de ingreso cubre hasta tres envíos por cuenta elegible, contando como máximo seis cuentas, por lo que una solicitud no hace más de 18 envíos, sin embargo, muchas cuentas están inscritas. Una sola cuenta elegible mantiene la asignación básica existente de tres y la asignación total de cuatro. Los techos de llamadas explícitas y los ámbitos combinados mantienen sus límites existentes.
+
+Rotation lleva la instantánea de credenciales **lleno** de la cuenta alternativa, no solo su portador, por lo que un proveedor que empareja metadatos de enrutamiento con su identificador de proyecto Cloud Code Assist de Antigravity, por ejemplo, no puede terminar enviando el token de una cuenta con los metadatos de otra cuenta.
+
+Para la inferencia primaria Antigravity a través del despacho principal del adaptador Google, un 401 primero actualiza y reproduce la misma cuenta. Si esa repetición sigue siendo 401, o la actualización falla con un rechazo de credenciales de terminal que requiere una reautenticación, la solicitud puede cambiar una vez a un hermano en vivo elegible. Esa solicitud hermana mantiene los reintentos transitorios ordinarios del adaptador, y cada envío físico cuenta con el presupuesto de envío existente de la solicitud. Un fallo de actualización transitoria mantiene el error de autenticación desinfectado. Se omiten las cuentas de pausa, de reautenticación requerida y de enfriamiento; la credencial fallida obtiene un tiempo de reutilización en proceso de 60 segundos solo mientras su generación es actual. El mismo despacho principal también puede conmutar una vez en un 403 cuando la normalización de errores delimitados de Google encuentra una razón estructurada completa de `VALIDATION_REQUIRED`. Las rutas 401 y 403 comparten un intento hermano por solicitud; una ruta 403 no relacionada o incompleta mantiene su error original. Un hermano rechazado, la cancelación o el presupuesto de envío agotado no causan otro envío ascendente. El bucle de búsqueda web basado en fetch también gira una vez en esta razón estructurada 403, utilizando el token OAuth del hermano y el proyecto Cloud Code Assist. Solo acepta sobres de error Google completos y delimitados con `error.details[].reason === "VALIDATION_REQUIRED"`; la redacción de verificación por sí sola no autoriza la rotación, y esta ruta no persiste como una marca de reautenticación. Cada envío físico, incluyendo un reintento 429, consume el mismo presupuesto de solicitud exactamente una vez. Un grupo deshabilitado, cancelación, presupuesto agotado o hermano no disponible conserva el fallo. Si falla la construcción o el envío de la solicitud entre hermanos, el 403 con límite original sigue siendo el error; una repetición rechazada antes del envío físico devuelve su asignación de envío no utilizada. Las continuaciones, el paso a través de Responses nativo, los sidecars de imagen y la salida ya enviados al cliente no usan esta rotación.
+
+El alcance actual son las rutas de solicitud Responses ordinarias. Cursor informa de los límites de velocidad como eventos del adaptador en lugar de un estado HTTP, y el punto final de la imagen independiente Antigravity tiene su propia ruta de solicitud; ninguno de los dos gira todavía.
+
+:::caution[Experimental]
+Rotar entre cuentas de suscripción gasta la cuota de una segunda cuenta y puede violar algunas términos de los proveedores. Si eso no es una compensación que desea, establezca `enabled: false` globalmente o para el proveedor en cuestión.
+:::
+
+<a id="managed-record-shapes"></a>
+
+### Formas de registro administradas
+
+`apiKeys[]` entradas contienen `id`, `name`, generado `key`, y cadenas ISO `createdAt`. Opcional `allowMeteredComboTargets: true` permite explícitamente los objetivos marcados `metered: true`; el consentimiento omitido o falso los niega. El token de entorno nunca califica. Las personas que llaman solo en bucle local pueden usar per-combo `allowMeteredTargets: true`; las personas que llaman con clave configurada y vinculada aún necesitan consentimiento de clave. Véase [Consentimiento de fallback medido](/es/guides/combos/#metered-fallback-consent). `codexAccounts[]` entradas requieren `id`, `email`, y `isMain`, con opcional `plan`, `chatgptAccountId`, y la privacidad de seguridad `logLabel`. Estos registros normalmente se administran en el panel de control.
+
+### `tokenGuardian` (`OcxTokenGuardianConfig`)
+
+| Campo | Tipo | Predeterminado | Descripción |
+| --- | --- | --- | --- |
+| `enabled?` | `boolean` | `false` | Interruptor proactivo-actualizado global. |
+| `tickSeconds?` | `number` | `21600` | Intervalo de barrido (6 horas, mínimo 60 segundos). |
+| `jitterSeconds?` | `number` | `300` | Retraso aleatorio antes de un barrido. |
+| `concurrency?` | `number` | `3` | Máximas actualizaciones simultáneas. |
+| `leadSeconds?` | `number` | `900` | Tiempo de espera de actualización adicional más allá de una marca. |
+| `failureBackoffBaseSeconds?` | `number` | `300` | Retroceso transitorio inicial. |
+| `failureBackoffMaxSeconds?` | `number` | `3600` | Techo de retroceso y retraso de falla permanente. |
+| `codexWarmupEnabled?` | `boolean` | `false` | Opte por la validación sintética de la cuenta de grupo Codex. |
+| `codexWarmupMaxAgeSeconds?` | `number` | `691200` | Revalida una cuenta después de 8 días. |
+| `codexWarmupModel?` | `string` | `gpt-5.6-luna` | Modelo nativo utilizado para el calentamiento opcional. |
+
+<a id="fixed-provider-endpoints"></a>
+
+## Endpoints de proveedores fijos
+
+El enrutamiento resuelve un extremo del proveedor antes del adaptador. Para la mayoría de las funciones integradas, el punto final del registro gana sobre el `baseUrl` configurado. Cuatro tipos de entrada mantienen la URL configurada:
+
+- proveedores habilitados para anulación: `ollama`, `vllm`, `lm-studio`, `litellm`, `qwen-cloud` y `alibaba-token-plan-intl`;
+- plantillas de registro rellenadas por el usuario, tales como `azure-openai` y `cloudflare-ai-gateway`;
+- preajustes fijos de clave API promovidos que conservan un destino personalizado más antiguo con el mismo nombre; y
+- proveedores ausentes del registro.
+
+Los adaptadores pueden ajustar la URL resuelta después. Kiro, por ejemplo, sigue la región API de la credencial importada para el canónico `runtime.{region}.kiro.dev`. Véase [Adaptadores](/es/reference/adapters/).
+
+Cuando el encaminamiento descarta `baseUrl`, opencodex registra el punto final del registro y solo el origen configurado; una ruta configurada puede contener una credencial. Elimine la URL no utilizada o elija la entrada del proveedor que coincida con la región deseada. `alibaba-token-plan` está anclado a Beijing, mientras que `alibaba-token-plan-intl` cubre puntos finales internacionales.
+
+Para una puerta de enlace `openai-responses` rota, la reparación pertenece al objeto del proveedor:
+
+```json
+{
+  "providers": {
+    "custom-gateway": {
+      "adapter": "openai-responses",
+      "baseUrl": "https://gateway.example/v1",
+      "apiKey": "${GATEWAY_KEY}",
+      "responsesItemIdRepair": {
+        "reasoning": ["rs_0"],
+        "message": ["msg_0"],
+        "repairMissingTerminalIds": true
+      }
+    }
+  }
+}
+```
+
+Las listas de marcadores son coincidencias exactas. Deje el campo sin configurar para los proveedores Responses normales / estatales para que el paso permanezca idéntico byte por byte.
+
+<a id="cursor-provider-adapter-cursor"></a>
+
+## Proveedor de Cursor (`adapter: "cursor"`)
+
+El puente Cursor es experimental. Después de `ocx login cursor`, agregue o edite `providers.cursor`.
+
+Si un proxy no puede transportar el flujo HTTP/2 predeterminado de Cursor, establezca `upstreamHttpVersion` en `"http1.1"`
+o en su alias `"h1"`. Esto cambia la inferencia al transporte de compatibilidad `RunSSE` + `BidiAppend` de Cursor y también usa HTTP/1.1 para el descubrimiento con `GetUsableModels`. El valor requiere una `baseUrl` HTTPS. Déjelo sin definir o use `"auto"` para conservar el comportamiento HTTP/2 existente. En el panel elija
+**Proveedores → Cursor → Configuración → Transporte de Cursor**.
+
+La escalera de optimización del Cursor Router se expone como ids de Codex separados porque el selector no puede representar los parámetros de modelo específicos de Cursor:
+
+| Modelo Codex | Modo router Cursor |
+| --- | --- |
+| `cursor/auto` | Equipo/cuenta predeterminada |
+| `cursor/auto-cost` | Coste |
+| `cursor/auto-balance` | Saldo |
+| `cursor/auto-intelligence` | Inteligencia |
+
+Las variantes explícitas envían el modelo `default` de Cursor con su parámetro `optimization`, preservando la selección en cada solicitud. Permanecen disponibles cuando el descubrimiento en vivo omite `default`.
+
+<a id="vision"></a>
+
+### Visión
+
+La visión nativa de Cursor usa `SelectedImage` (tope flexible de JPEG + `blobIdWithData`) para los modelos que pueden ver imágenes de forma nativa —Claude, Gemini, GPT, Kimi y Grok entre ellos— usando solo imágenes `data:` del turno activo. Las imágenes de turnos anteriores se reproducen como marcadores de texto `[image attached]`; las imágenes remotas o no decodificables se convierten en marcadores de omisión. Auto, la familia Composer y GLM (`glm-5.2`, `glm-5.3`) permanecen en la lista curada `noVisionModels` y usan en su lugar el sidecar de descripción de visión.
+
+Las herramientas locales dirigidas por el servidor de Cursor están deshabilitadas de forma predeterminada. Codex sigue usando sus propias herramientas, como `apply_patch` y `exec_command`, con su propia política de aprobación y sandbox:
+
+- `"off"` (predeterminado) rechaza la ejecución nativa de Cursor de `read`, `write`, `delete`, `ls`, `grep`, `shell` y `fetch`.
+- `"on"` opta por la ejecución local de confianza y omite la semántica de aprobación/sandbox de Codex, excepto la ejecución de shell nativa en primer plano, que sigue sin estar disponible.
+- `"codex-sandbox"` se mantiene por compatibilidad, pero falla cerrado igual que `"off"`; la prosa de la solicitud no es una atestación de sandbox fiable.
+
+```json
+{
+  "providers": {
+    "cursor": {
+      "adapter": "cursor",
+      "baseUrl": "https://api2.cursor.sh",
+      "authMode": "oauth",
+      "defaultModel": "auto",
+      "nativeLocalExec": "off"
+    }
+  }
+}
+```
+
+Establezca `nativeLocalExec` en `providers.cursor`, no en el nivel superior. En el panel use **Proveedores → Cursor → Editar JSON**, guarde y luego reinicie. El antiguo `unsafeAllowNativeLocalExec: true` equivale a `nativeLocalExec: "on"` solo cuando `nativeLocalExec` no está definido. MCP, la grabación de pantalla y el control del equipo se configuran por separado mediante `mcpServers` y `desktopExecutor`.
+
+Para una búsqueda de directorio nativa de `grep` habilitada, `glob` filtra los nombres de archivo:
+`*.ts` coincide a cualquier profundidad y `src/**/*.ts` se interpreta respecto al directorio elegido;
+`./` es opcional. Usa `/` como separador en todas las plataformas. Se admiten clases de caracteres
+y alternativas entre llaves; Bun 1.4.4 también admite extglobs como `**/!(*.test).ts` y rangos como
+`part-{1..3}.ts`. Los filtros no cambian el directorio elegido ni habilitan la ejecución nativa.
+
+Las solicitudes en primer plano de `shellArgs` y `shellStreamArgs` se rechazan antes de crear el proceso en Windows, macOS y Linux, incluso con `nativeLocalExec: "on"`. Requieren un propietario descendiente respaldado por el kernel que esta implementación no proporciona; use en su lugar la herramienta de shell del cliente. La forma de streaming sigue devolviendo el inicio, una salida abortada, un fallo tipado y el cierre del flujo para que el turno de Cursor pueda terminar. No recopila stdout/stderr y no tiene ninguna asignación activa de bytes de salida. Esta restricción no cambia la ejecución de shell en segundo plano ni las demás opciones explícitas de ejecutor.
+
+Cada `mcpServers.<name>` acepta `command` (stdio) o `url` (Streamable HTTP). Stdio también acepta `args`, `env` y `cwd`. HTTP acepta `headers`. Ambos soportan `enabled` (valor predeterminado true) y `toolPrefix`. `desktopExecutor` acepta `computerUseCommand`, `recordScreenCommand`, `cwd`, `env` y `timeoutMs` (por defecto `30000`). Los comandos se ejecutan mediante `sh -c`, leen una solicitud JSON de stdin y deben escribir un resultado JSON en stdout.
+
+:::caution[Seguridad]
+El enlace de loopback predeterminado admite cualquier proceso local sin autenticación, incluidos otros usuarios de un host multiusuario. Deje la ejecución local desactivada a menos que confíe en todos los llamantes del plano de datos y acepte deliberadamente omitir la aprobación y la semántica de sandbox de Codex.
+:::
+
+<a id="zed-provider-adapter-zed"></a>
+
+## Proveedor Zed (`adapter: "zed"`)
+
+El puente Zed Hosted AI es experimental y solo para inicio de sesión. Ejecute `ocx login zed` antes de usarlo; el inicio de sesión almacena la identidad de la cuenta Zed con su token de acceso de aplicación nativa en la tienda normal OAuth.
+
+```json
+{
+  "providers": {
+    "zed": {
+      "adapter": "zed",
+      "baseUrl": "https://cloud.zed.dev",
+      "authMode": "oauth",
+      "defaultModel": "auto"
+    }
+  }
+}
+```
+
+El puente obtiene un token de inferencia alojada de corta duración y envía `POST /completions`. La lista `/models` en vivo se utiliza solo para metadatos de selector específicos de la cuenta: los identificadores de modelo arbitrarios permanecen reenviables, con la familia de backend inferida a partir del campo de proveedor en vivo o el nombre del modelo.
+
+:::caution[No oficial: úsalo bajo tu responsabilidad]
+Zed no proporciona ni respalda esta integración, y puede estar fuera de los términos de servicio de Zed. Zed puede limitar o suspender una cuenta que la utiliza. El proveedor nunca está habilitado de forma predeterminada.
+:::
+
+<a id="openrouter-provider-routing"></a>
+
+## Enrutamiento del proveedor OpenRouter
+
+OpenRouter puede servir a un modelo a través de varios proveedores de inferencias. `openRouterRouting` mantiene las solicitudes de los proveedores preferidos; `modelOpenRouterRouting` lo reemplaza por ID de modelo exacto. Esto es útil para la afinidad de caché rápida porque el soporte de caché, la retención, las tasas de éxito y los precios varían según el proveedor de inferencias.
+
+Los nombres de los proveedores son OpenRouter identificadores. `allowFallbacks: false` falla cerrado; `true` permite a otro proveedor elegible después de la lista ordenada. `only` es siempre una lista de permisos.
+
+```json
+{
+  "providers": {
+    "openrouter": {
+      "adapter": "openai-chat",
+      "baseUrl": "https://openrouter.ai/api/v1",
+      "apiKey": "${OPENROUTER_API_KEY}",
+      "openRouterRouting": {
+        "order": ["deepseek"],
+        "allowFallbacks": false
+      },
+      "modelOpenRouterRouting": {
+        "anthropic/claude-sonnet-5": {
+          "only": ["anthropic"],
+          "allowFallbacks": false
+        }
+      }
+    }
+  }
+}
+```
+
+<a id="vercel-ai-gateway-provider-routing"></a>
+
+## Enrutamiento del proveedor de Vercel AI Gateway
+
+Vercel AI Gateway puede enrutar un modelo a través de múltiples proveedores de inferencia subyacentes. `vercelGatewayRouting` configura las preferencias de todo el proveedor; `modelVercelGatewayRouting` lo reemplaza por ID de modelo exacto. Dejando ambos unset hace que `resolveVercelGatewayRouting()` devuelva `undefined`, por lo que los creadores de solicitudes de chat omiten el campo `provider` y Vercel AI Gateway conserva su comportamiento de enrutamiento dinámico predeterminado.
+
+- `order`: Vercel AI Gateway upstream proveedor identificadores en orden de prioridad.
+- `only`: lista de permisos explícita que restringe los proveedores de upstream de Vercel AI Gateway elegibles.
+- `sort`: clasifica automáticamente a los proveedores elegibles por `"cost"` (el costo más bajo), `"ttft"` (el tiempo hasta el primer token) o `"tps"` (tokens por segundo).
+
+```json
+{
+  "providers": {
+    "vercel-ai-gateway": {
+      "adapter": "openai-chat",
+      "baseUrl": "https://ai-gateway.vercel.sh/v1",
+      "apiKey": "${VERCEL_AI_GATEWAY_KEY}",
+      "vercelGatewayRouting": {
+        "sort": "ttft"
+      },
+      "modelVercelGatewayRouting": {
+        "zai/glm-5.2": {
+          "only": ["novita", "deepinfra"],
+          "order": ["novita", "deepinfra"]
+        }
+      }
+    }
+  }
+}
+```
+
+Las claves de modelo son selectores de modelo públicos Vercel sin el prefijo de proveedor externo OpenCodex. Al seleccionar `vercel-ai-gateway/zai-glm-5.2` se restaura el `zai/glm-5.2` nativo antes de aplicar la regla del modelo. La misma asignación se aplica a un selector nativo `vercel/<model-id>`: use el selector codificado `vercel-ai-gateway/vercel-<model-id>` en OpenCodex y mantenga `vercel/<model-id>` como la clave del modelo.
+
+<a id="storing-keys-in-the-os-keychain"></a>
+
+## Almacenar claves en el llavero del sistema operativo
+
+Las claves API y las referencias a credenciales se pueden guardar en el almacén del sistema operativo (Llavero de macOS, Administrador de credenciales de Windows o Secret Service de Linux) en lugar de `config.json`. Consulta [Almacenar claves en el llavero del sistema operativo](/es/reference/configuration/keychain/) para conocer los comandos de migración, las reglas de almacenamiento y las limitaciones de servicios sin sesión interactiva.
+
+<a id="static-model-allowlists"></a>
+
+## Listas de modelos estáticos
+
+El preajuste `zhipu-bigmodel-responses` incluye inicialmente `glm-5.3`, `glm-5.3-flash` y `glm-5-turbo` con `liveModels: false` para `https://open.bigmodel.cn/api/v1`. Su lista estática y el contexto por modelo, el esfuerzo y los metadatos de resumen provienen del [Guía BigModel Responses](/es/guides/providers/#bigmodel-coding-plan-over-responses). El ejemplo oficial local `models.json` no establece un vivo `/models` API.
+
+Con `liveModels: false`, un `models` vacío u omitido inicia primero el `defaultModel` configurado, seguido por `retainModels`; se eliminan los ID duplicados mientras se conserva la primera aparición. Una lista explícita no vacía de `models` en cambio siembra `models` seguido de `retainModels`, sin agregar implícitamente un `defaultModel` diferente. Ese valor predeterminado todavía se puede enumerar explícitamente en `models` o `retainModels`. Si ninguno de estos campos proporciona un id, la semilla estática está vacía. Este es el orden de la semilla, no una promesa del orden final del selector. `selectedModels`, `disabledModels` y la política de proveedores desactivados todavía se aplican. `authMode: "forward"` mantiene su rama separada y no usa esta semilla estática enrutada. Estas reglas no cambian el fracaso del descubrimiento en vivo.
+
+Live discovery rechaza más de 4 MiB o 2.000 filas de modelos sin procesar antes del almacenamiento en caché; los ajustes preestablecidos incorporados pueden usar límites inferiores y filtrar a filas elegibles para chat. Si el resultado es demasiado grande o está mal formado, se recurre al catálogo anterior o configurado. Un resultado válido sin modelos elegibles sigue siendo autoritativo: no se sustituye ni se trunca silenciosamente.
+
+Utilice `selectedModels` cuando el descubrimiento aún debería ejecutarse, pero solo los id seleccionados deberían aparecer en Codex y `/v1/models`. El panel de control conserva la lista completa descubierta para cambios posteriores en la lista de permisos.
+
+Use `retainModels` para el problema opuesto: un proveedor cuyo punto final `/models` omite un id que todavía es llamable (una implementación privada, un id de vista previa, una puerta de enlace compatible con OpenAI con un listado parcial). Los ids listados se mantienen en el catálogo enrutado con el mismo contexto y sugerencias de esfuerzo que `models`, y también sobreviven `liveModels: false`. `selectedModels` todavía reduce lo que es visible, por lo que un id debe estar en ambas listas cuando una lista de permisos está activa. Retener un id no hace que el upstream lo acepte; un id incorrecto falla en el momento de la solicitud con el error upstream. Desde el CLI: `ocx provider edit <name> --retain-models gemini-3.7-flash,other-id` (`-` borra).
+
+Las entradas de reserva de vista previa de GPT-5.6 usan el mismo mecanismo. El preajuste de clave API de OpenAI siembra los ids base y Pro con contexto `1050000` y entrada máxima `922000`; OpenRouter siembra `openai/gpt-5.6-sol`, `openai/gpt-5.6-terra` y `openai/gpt-5.6-luna` con contexto `1050000`. Las ventanas nativas de Pool/Direct siguen la [política de proveedores OpenAI reservados](#reserved-openai-providers). El catálogo sincronizado anuncia `max` a la vez que mantiene `xhigh` distinto.
+
+```json
+{
+  "providers": {
+    "openrouter": {
+      "adapter": "openai-chat",
+      "baseUrl": "https://openrouter.ai/api/v1",
+      "apiKey": "${OPENROUTER_API_KEY}",
+      "liveModels": false,
+      "models": ["deepseek/deepseek-v4-flash", "qwen/qwen3-coder-plus"]
+    }
+  }
+}
+```
+
+<a id="complete-example"></a>
+
+## Ejemplo completo
+
+```json
+{
+  "port": 10100,
+  "defaultProvider": "openai",
+  "providers": {
+    "openai": {
+      "adapter": "openai-responses",
+      "baseUrl": "https://chatgpt.com/backend-api/codex",
+      "authMode": "forward"
+    },
+    "anthropic": {
+      "adapter": "anthropic",
+      "baseUrl": "https://api.anthropic.com",
+      "authMode": "oauth",
+      "defaultModel": "claude-sonnet-4-6"
+    },
+    "ollama-cloud": {
+      "baseUrl": "https://ollama.com/v1",
+      "apiKey": "${OLLAMA_API_KEY}",
+      "defaultModel": "glm-5.2",
+      "noVisionModels": ["glm-5.2", "glm-5.3", "gpt-oss", "qwen3-coder", "deepseek-v4-flash"]
+    }
+  },
+  "subagentModels": ["anthropic/claude-opus-5", "ollama-cloud/glm-5.2"],
+  "disabledModels": [],
+  "websockets": false,
+  "webSearchSidecar": {
+    "maxSearchesPerTurn": 3,
+    "routedModelStallTimeoutMs": 200000,
+    "timeoutMs": 60000
+  },
+  "visionSidecar": { "enabled": true }
+}
+```
+
+<a id="opencode-go-responses-compatibility"></a>
+
+## Compatibilidad con OpenCode Go Responses
+
+En solicitudes no reenviadas cuyo punto final resuelto es `https://opencode.ai/zen/go/v1/responses`, OpenCodex se mueve Codex `additional_tools` Declaraciones de entrada al nivel superior `tools` herramienta y espacio de nombres normalización. Las herramientas alojadas compatibles se conservan hasta el filtrado específico del modelo; malformado envolturas permanecen sin cambios. Esto no descarta el texto cifrado o el contenido de agente-mensaje desconocido. La verificación utiliza el URL final, por lo que las URL base y la división incluyen puntos finales. `baseUrl`/`responsesPath`
+Las configuración reciben el mismo comportamiento. Un camino personalizado resolver en otro lugar no lo hace.
+
+El canónico `opencode-go` predeterminados preestablecidos a `statelessResponses: true`: las solicitudes utilizan el historial explícito con `store: false`, sin `previous_response_id`, `conversation`, `background`, `metadata`, o `prompt` referencias almacenadas. Esto evita el rechazo de Go del texto cifrado de razonamiento combinado con `previous_response_id`. El razonamiento de registros de caché de continuación en la misma representación devuelto al cliente, incluyendo la reescritura de contenido a resumen visible, por lo que hacer eco del historial completo con `previous_response_id` no duplica ese historial. Las solicitudes de resumen oculto y las manchas de razonamiento opacas conservan su representación existente. Los hits de caché también pueden proporcionar un historial anterior para las continuaciones delta; después de un error de caché, el proxy devuelve `previous_response_not_found` antes del envío ascendente para que el cliente pueda volver a enviar la conversación completa sin `previous_response_id`. Los resultados huérfanos y los resultados perdidos de la herramienta no pueden reconstruir el historial perdido o probar si la ejecución de una herramienta faltante tuvo éxito.
+
+Se conserva un `statelessResponses: false` explícito. Las configuraciones preestablecidas canónicas existentes reciben el valor predeterminado solo cuando el ajuste está ausente; las entradas renombradas personalizadas mantienen su valor configurado y no adquieren este valor predeterminado por coincidencia de destino. Las rutas del modelo de chat mantienen su protocolo existente. La bandera sin estado no fuerza la transmisión de Responses en JSON.
+
+<a id="opencode-go-session-affinity"></a>
+
+## Afinidad de sesión OpenCode Go
+
+Cada solicitud opencodex rutas a un destino OpenCode Go lleva un encabezado `x-opencode-session`. El flujo ascendente comenzó a rechazar solicitudes sin él en 2026-09-06, por lo que la cabecera no es una optimización.
+
+El valor depende de lo que la solicitud ya sabe sobre sí misma:
+
+- Un `x-opencode-session` configurado por el operador en el proveedor se conserva exactamente como está escrito.
+- Una solicitud que lleva la identidad de la conversación - cabeceras de hilo Codex, un Claude `metadata.user_id`, un `session_id`, o un `x-opencode-session` entrante - se hashed en un valor estable por conversación, por lo que cada turno de una conversación llega a ir bajo la misma sesión.
+- Una solicitud sin ninguna identidad, como una sonda de disponibilidad de modelo o una primera solicitud antes de que exista ningún metadato de conversación, recibe un valor asignado una vez para esa solicitud. Está aislado de otras solicitudes en lugar de compartido, y sobrevive a los lugares opencodex reconstruye la solicitud: la traducción a la forma interna Responses, compactación, niños combinados y el reintento de recuperación de políticas que entrega el turno al próximo candidato.
+
+Los destinos Non-Go no se ven afectados: opencodex nunca obtiene o agrega el encabezado de sesión para ellos. Todavía se envía un encabezado que un operador configuró en un proveedor de este tipo, porque opencodex deja esa configuración sola.
+
+<a id="opencode-go-reasoning-efforts"></a>
+
+## Esfuerzos de razonamiento OpenCode Go
+
+Las filas de catálogo Go conservan sus esfuerzos de razonamiento configurados exactamente, incluso durante la sincronización del catálogo. OpenCodex no anexa opciones sintéticas `max` o `ultra` a estas filas. Use `modelReasoningEfforts` y `modelDefaultReasoningEfforts` para los valores ascendentes aceptados de cada modelo. Teclee estos mapas por proveedor por ID de modelo ascendente, no por la identificador de catálogo `opencode-go/<model-id>` enrutada. Por ejemplo, una lista `["high", "max"]` configurada sigue siendo exactamente esas dos opciones; una lista `["high", "xhigh"]` configurada no gana `max`. Vea el [Lista de modelos de OpenCode](https://opencode.ai/docs/go/#models) para la lista actual. Un subconjunto configurado puede excluir los niveles inferiores. Otros proveedores mantienen su comportamiento existente.
+
+Para un selector nativo-primero, incluya los identificadores nativos en `modelPickerOrder` seguidos de los identificadores enrutados. Esto ordena el selector completo mientras se conserva el cálculo de orientación de prioridad natural separado de OpenCodex. Native Codex anuncia cinco prioridad de selector de seguimiento y puede cambiar; la elegibilidad de anulación de nombre exacto no se limita a ese anuncio. Las órdenes de solo ruta mantienen su comportamiento anterior. Ver el [Ordenar nota de migración](/es/guides/model-ordering/#migration-note-native-ids-in-existing-orders). `modelDisplayNames` en un proveedor controla las etiquetas legibles sin cambiar los identificadores de cable.
+
+<a id="routed-agent-messages"></a>
+
+## Mensajes de agentes enrutados
+
+Con el [`openai-responses` adaptador](/es/reference/adapters/#openai-responses), Codex
+`agent_message` Los elementos que contienen matrices no vacías de partes de texto plano admitidas se convierten en mensajes de usuario cuando `authMode` no es `"forward"`
+(Por ejemplo, `"key"`) Proveedores que utilizan `authMode: "forward"` mantener estos elementos sin cambios.
+`agent_message` es privado al backend ChatGPT Codex, y los destinos enrutados reportado hasta el momento responder a toda la solicitud con
+`422 unknown item type "agent_message"`; Codex reproduce el historial de subagentes en cada giro posterior, por lo que el hilo sigue fallando hasta que se convierte el elemento. El autor y el destinatario siguen siendo metadatos de texto explícito, y se conservan las partes del contenido. Para HTTPS `api.x.ai` y `cli-chat-proxy.grok.com` en el puerto estándar, no hacia adelante El despacho Responses también acepta un resultado hijo de cadena no en blanco y lo convierte en uno
+`input_text` parte. La cadena original, incluyendo el espacio en blanco y las líneas nuevas, se conserva. Otros destinos mantienen sin cambios los mensajes de agente con valor de cadena. Vacío o Las cadenas de solo espacio en blanco permanecen sin cambios, al igual que las formas incompletas y mezcladas cifradas/desconocidas. El contenido encriptado y desconocido no está normalizado; las tareas encriptadas nativas aún requieren el opt-in separado [recuperación de tareas](/es/reference/configuration/agents/#encrypted-v2-task-recovery).
+
+Con la recuperación de tareas habilitada, los elementos `NEW_TASK`, `MESSAGE`, `FOLLOWUP_TASK` y `FINAL_ANSWER` reutilizan una asignación en caché solo después de validar el llamador y coincidir con el alcance del subproceso principal. La restauración de reproducción no realiza una nueva solicitud de recuperación ni extiende la caducidad de la caché. El texto cifrado caducado o no visto no se reemplaza. Los nuevos elementos cifrados `NEW_TASK`, `MESSAGE`, `FOLLOWUP_TASK` y `FINAL_ANSWER` utilizan la misma ruta de recuperación opt-in, incluida la entrega `send_message` de padres nativos. El tipo de mensaje, el remitente, el destinatario, el alcance principal y las credenciales del llamante siguen siendo parte de la validación o la identidad de caché. Un `FINAL_ANSWER` sin una línea `Task name` no tiene ninguna dirección de cabecera para verificar, pero su destinatario todavía explora la caché.
+
+Cuando una solicitud contiene varios mensajes de agente, la restauración de reproducción en caché comprueba cada mensaje de forma independiente. La caché separa el tipo de mensaje, el remitente, el destinatario y el texto cifrado dentro del alcance admitido de la persona que llama/cuenta y del padre. La recuperación reciente solo maneja el mensaje de cola actual (ignorando los metadatos posteriores `compaction_trigger` o `additional_tools`). No recupera por lotes mensajes históricos no vistos; esos permanecen sin cambios. Un error de caché o vencimiento no extiende el contrato de recuperación del historial.
+
+El remitente y el destinatario en la ruta Responses son contexto para el modelo de recepción, no un nuevo protocolo de enrutamiento legible por máquina. El enrutamiento de herramientas continúa utilizando los contratos de colaboración existentes.
+
+<a id="per-model-capability-declarations"></a>
+
+### Declaraciones de capacidad por modelo
+
+`modelCapabilities` almacena declaraciones explícitas con la clave exacta del ID del modelo ascendente. Los ID preservan el caso y no deben contener espacios en blanco circundantes. Cada entrada puede contener `inputModalities` (`text`, `image`, `audio`, `video`), `contextTier` (`default`, `long_context`), `video.processing` (`static`, `agentic`) y `deepseekImageFiles` (`boolean`; véase [DeepSeek image bytes](#deepseek-tokens-versus-image-bytes)). Estas son declaraciones del operador, no prueba de apoyo del proveedor. Los campos de nivel de contexto y vídeo actualmente graban solo la intención y no activan el comportamiento ascendente ni aumentan las ventanas de catálogo.
+
+El editor y proveedor de proveedores en bruto API exponen este mapa. POST/PUT reemplaza un mapa suministrado explícitamente y rechaza entradas nulas. PATCH combina ejes individuales; null borra un valor de procesamiento de mapa, modelo, eje o vídeo, mientras que `{}` no cambia. El proveedor omitido sobrescribe el mapa existente. Los archivos mal formados editados a mano retienen ejes independientes válidos y tratan las modalidades de entrada explícitas mal formadas como solo texto, con un diagnóstico.
+
+Un `modelCapabilities.<id>.inputModalities` explícito ahora tiene prioridad sobre las sugerencias de modalidad heredadas para ese modelo enrutado exacto. Una declaración de solo texto utiliza el sidecar de visión existente para reemplazar las imágenes con descripciones; si no hay un sidecar disponible, la solicitud recibe un marcador de omisión explícito antes del envío. Las solicitudes de imagen de chat nativo se desvían a través de esta ruta. El catálogo aún puede anunciar el soporte de archivos adjuntos de imagen porque el proxy proporciona el paso de descripción. Las declaraciones de nivel contextual y de procesamiento de video permanecen inertes hasta que se soporte su transporte.
+
+Una declaración de modalidad de entrada en un **fila de modelo personalizado** - las casillas de verificación de modalidades de entrada en la pestaña Modelos, o `inputModalities` en `customModels[]` - también tiene prioridad sobre las sugerencias de visión heredadas del proveedor (`noVisionModels`, `modelInputModalities`) para ese proveedor exacto y la identificación del modelo. Declare `text, image` en una fila personalizada y las imágenes lleguen a ese modelo incluso cuando la fila del proveedor lo enumere como solo texto; declare solo `text` y se enruta a través del sidecar de visión. Esta es la misma prioridad que el catálogo ya aplicado, por lo que la fila anunciada y la solicitud ahora están de acuerdo. `modelCapabilities` se mantiene por encima de él, porque es el eje de capacidad dedicado por modelo, incluida la escritura realizada por `ocx provider edit <provider> --model <id> --text-only`. Una fila personalizada que deja las modalidades en blanco hereda la fila del proveedor en lugar de reclamar solo texto. Cada consumidor que responde "puede este modelo tomar una imagen" aplica una regla a la declaración: la imagen está ausente de la lista. Por lo tanto, una fila que declara solo `audio` o `video` cuenta como incapaz de imagen, en lugar de ser tratada como un modelo de texto por un predicado y un objetivo de imagen por el otro.
+
+<a id="prompt-length-pricing"></a>
+
+### Precios puntuales
+
+En **Modelos → Precio**, mantenga cuatro tarifas base y elija un modo de longitud rápida:
+
+- **Automático** mantiene las reglas de contexto de catálogo. También es el comportamiento de las anulaciones de cuatro tasas existentes sin una política.
+- **Tarifa fija** utiliza las tasas base en cada longitud de solicitud, deshabilitando los ajustes de contexto del catálogo.
+- **Umbral personalizado** selecciona cuatro velocidades alternativas absolutas usando `>` o `≥` y un umbral de testigo. La directiva personalizada reemplaza la regla de contexto de catálogo en ambos lados del umbral.
+
+Todos los tokens de solicitud cuentan, incluidas las lecturas y escrituras de caché, antes de la resta de entrada facturable. La salida no cuenta hacia el umbral. Una vez cruzadas, las tarifas alternativas se aplican a toda la solicitud, incluida la salida, no solo a los tokens en exceso. Las tarifas personalizadas son tarifas de velocidad estándar: se aplica una prima Fast / Priority aplicable una vez que se seleccionan las tarifas y sigue la relación del catálogo entre la prioridad y los precios de contexto largo para ese modelo. Una solicitud de prioridad confirmada muestra la estimación personalizada como un límite inferior solo cuando el catálogo declara que esa relación es `lower-bound`, al igual que para xAI Grok, que no publica ninguna tasa combinada. Un modelo sin regla de contexto de catálogo aplica cualquier multiplicador de prioridad una vez. Estos ajustes controlan las estimaciones; no cambian la facturación del proveedor. **Restablecer a automático** elimina la anulación completa y restaura los precios y las reglas del catálogo. Guardar o editar las actualizaciones de configuración en tiempo real estimaciones y totales históricos.
+
+Por ejemplo, una anulación de Haiku 5.5 con tasas alternativas estrictamente superiores a 100.000 tokens de solicitud:
+
+```json
+{
+  "modelCosts": {
+    "claude-haiku-5-5": {
+      "input": 0.10,
+      "output": 0.50,
+      "cacheRead": 0.01,
+      "cacheWrite": 0.125,
+      "promptLengthPricing": {
+        "mode": "custom",
+        "thresholdTokens": 100000,
+        "comparison": "gt",
+        "rates": { "input": 0.50, "output": 2.50, "cacheRead": 0.05, "cacheWrite": 0.625 }
+      }
+    }
+  }
+}
+```
+
+Este es un ejemplo de precios definidos por el usuario, no una lista oficial de precios de Haiku. Se admite cualquier umbral entero seguro positivo, incluido el `272000`; use el `"gte"` para una comparación inclusiva. Se requieren las cuatro tasas alternativas y siguen los límites de la tasa base, incluido cero. La otra política es `{ "mode": "flat" }`. Omitir `promptLengthPricing` para retener las reglas de contexto automáticas con sus precios base; se acepta un `{ "mode": "automatic" }` explícito y significa lo mismo, y se guarda desde el panel de control o API almacenarlo como un campo ausente.
+
+Las anulaciones de precio de modelo Legacy `openai-multi` retienen políticas de longitud de prompt válidas cuando el inicio las migra a `openai`, incluidas las anulaciones tecleadas en `openai-multi/<model>`.
+
+<a id="renamed-api-key-presets"></a>
+
+### Preajustes de clave API renombrados
+
+Un proveedor guardado bajo otro nombre, como `CommandCode`, hereda metadatos faltantes de esfuerzo de razonamiento cuando su adaptador y el punto final fijo API coinciden con un ajuste preestablecido del registro. Sus listas explícitas por modelo, incluyendo `[]`, siguen siendo autorizadas. Una lista omitida en todo el proveedor hereda el valor predeterminado preestablecido; una lista explícita permanece sin cambios. Esto no coincide con OAuth, los puntos finales no relacionados, o plantillas / preajustes de punto final personalizado.
+
+<a id="azure-model-validation-output-budgets"></a>
+
+### Azure presupuestos de salida de validación de modelos
+
+Algunas implementaciones de Azure Responses rechazan el pequeño presupuesto de validación de cambio de modelo de Claude Code. Si su implementación informa que `max_output_tokens` está por debajo de su mínimo, configure `minMaxOutputTokens` en ese proveedor de Azure al mínimo que requiera su punto final (por ejemplo, `16` para un punto final que informa de ese mínimo). Esto es opt-in: aumenta cada presupuesto entero positivo más pequeño en ese proveedor, no solo las solicitudes de validación. Se conservan presupuestos más grandes, y otros adaptadores no aplican esta configuración en este cambio. La admisión de gastos se reserva el presupuesto efectivo antes del envío, incluido el envío prepagado de cada objetivo Combo. Por lo tanto, un techo de gasto configurado puede rechazar una solicitud cuya asignación de producción elevada excedería ese techo.
+
+```json
+{
+  "providers": {
+    "azure": {
+      "adapter": "azure-openai",
+      "baseUrl": "https://YOUR_RESOURCE.openai.azure.com/openai/v1",
+      "apiKey": "${AZURE_OPENAI_API_KEY}",
+      "minMaxOutputTokens": 16
+    }
+  }
+}
+```
+
+<a id="native-chat-thinking-replay"></a>
+
+### Chat nativo pensando repetición
+
+Estas listas de razonamiento de chat también se aplican a la continuación de llamada de herramienta nativa `/v1/chat/completions`. El proxy conserva el `reasoning_content` suministrado y restaura el razonamiento omitido de las respuestas JSON o SSE aguas arriba usando identificadores de llamada de herramienta. La repetición de razonamiento original requiere un encabezado estable `thread-id`, `session_id` o `session-id` en cada solicitud y el mismo proveedor, punto final, modelo y credencial. La caché es local y limitada; un reinicio, caducidad, desalojo o falta de encabezado de conversación utiliza el marcador de posición mínimo configurado en su lugar. Un marcador de posición no puede reconstruir el razonamiento perdido. Los clientes deben conservar el `reasoning_content` ascendente en su historial de asistentes para reanudar las conversaciones de manera confiable.
+
+Cuando `preserveReasoningContentModels` no está configurado, DeepSeek Flash / Pro nombres de modelos se reconocen en todas las versiones, incluyendo `deepseek-v4.1-flash`, identificadores de namespaced y sufijos de puerta de enlace. Las listas explícitas siguen siendo autoritativas: `preserveReasoningContentModels: []` desactiva la reparación automática, mientras que `requiresReasoningPlaceholderModels: []` desactiva los marcadores de posición y aún permite el razonamiento original en caché. Otras familias modelo requieren la declaración de conservación. Las solicitudes DeepSeek habilitadas para herramientas también requieren razonar sobre respuestas de asistentes anteriores sin llamadas de herramientas. El marcador de posición configurado llena estas omisiones; no se puede recuperar ningún razonamiento original de la caché de llamadas a herramientas para esos giros. Preservar su razonamiento suministrado para la plena fidelidad.
+
+<a id="auto-pause-permanently-refused-accounts"></a>
+
+## Pausa automática de cuentas permanentemente rechazadas
+
+`providers.<provider>.accountAutoPause` es opcional y está desactivado de forma predeterminada. Se aplica a las cuentas OAuth de ese proveedor, a las cuentas de grupo de Codex (incluida la cuenta principal en modo de grupo) y a las entradas de grupo de claves API configuradas. Por ejemplo:
+
+```sh
+ocx config set providers.anthropic.accountAutoPause.enabled true
+ocx config set providers.anthropic.accountAutoPause.consecutiveFailures 2
+```
+
+`consecutiveFailures` es un entero de 1 a 100; omitirlo usa 2. Solo cuentan rechazos HTTP 401/403 exactos y propios de la cuenta: una organización que prohíbe OAuth, una suscripción inactiva o vencida, acceso denegado a API/Claude Code, una cuenta deshabilitada por Google por infringir sus condiciones de servicio, o el cambio a un plan gratuito sin créditos. Un error de permisos del modelo, un token de acceso vencido, una ventana de cuota, un 429, un 5xx, una respuesta mal formada o un fallo de red nunca pausan una cuenta.
+
+El contador es de proceso local, serializado por cuenta, y se restablece en una respuesta HTTP exitosa, reanudación explícita o un nuevo inicio de sesión. La actualización del token por sí sola no restablece la racha de una cuenta OAuth. Los errores transitorios dejan el contador sin cambios. Reiniciar el proxy borra los contadores; pausas completadas, sus códigos de razón fija y marcas de tiempo persisten. Los procesos proxy independientes mantienen contadores independientes. Cambiar, deshabilitar o volver a habilitar la política, deshabilitar el proveedor o cambiar su punto final descarta observaciones de rechazo en vuelo, por lo que un rechazo de una solicitud enviada bajo la política anterior nunca puede pausar una cuenta después. Un rechazo cuenta solo para la credencial que realmente llegó a la parte superior: cuando un plugin local reescribe la credencial o el destino de un envío, ese envío nunca cuenta para una pausa. Para Codex cuentas de pool esto incluye el espacio de trabajo (`chatgpt-account-id`) para el que se envió la solicitud.
+
+En el umbral, OpenCodex excluye la cuenta utilizando su mecanismo de pausa existente e intenta un hermano elegible para la solicitud actual dentro del presupuesto de reintento/envío existente. Corregidos los selectores de cuenta Codex y los archivos cargados vinculados a la cuenta conservan sus restricciones. Una pausa nunca cancela el trabajo ya enviado ni cambia las credenciales. Emite una línea de registro genérica sin identificadores de cuenta o texto de error ascendente.
+
+`ocx account list <provider>` muestra la razón de pausa. La insignia Paused del panel expone la razón y el tiempo. Utilice `ocx account resume <provider> <account-id-or-alias>` para aclarar la razón y permitir la selección de nuevo. En una fila de API teclas, al hacer clic en Reanudar también se activa la clave. Esta política nunca reanuda una cuenta automáticamente.
+
+
+<a id="mistral-images-per-request"></a>
+
+### Imágenes por solicitud Mistral
+
+El límite cuenta todos los turnos del historial. La [guía de visión](https://docs.mistral.ai/capabilities/vision/) documenta ocho; se midieron 20 para `deepseek-v4-1-flash-1017`, con HTTP 503 y código `3800` al superarlos, 100 para `mistral-large-4` y `mistral-large-4-0`, y ninguna negativa hasta 256 en `zai-glm-5-3-flash`. Para `https://api.mistral.ai/v1/chat/completions`, tanto Responses traducido como Chat nativo conservan las imágenes más recientes y reemplazan las anteriores por notas solo en la copia enviada, sin modificar historial ni compactación. El uso es el informado después del reemplazo. Las imágenes promovidas de herramientas también cuentan.
+
+Los límites medidos se incluyen en `modelCapabilities` del registro y se conservan al renombrar un proveedor que siga apuntando al destino Mistral; otros modelos usan ocho. Puedes declarar `modelCapabilities: { "mistral-small-2603": { mistralMaxImages: 8 } }`, entero de 1 a 1000, que prevalece; PATCH null lo borra. Solo cuentan partes `image_url` con cadena no vacía en `image_url` o `image_url.url`, sin comprobar sintaxis ni accesibilidad. Una referencia ausente o inválida se convierte en `[image omitted: missing or malformed image URL]`, sin consumir cupo. El parser Responses elimina input_image sin URL/ID usable antes de este límite. Un `file_id` sin URL no vacía en mensaje o herramienta se rechaza antes de enviar; dentro de `agent_message`, no inspeccionado por ese guard, pasa como texto `[image: <file id>]` y no consume cupo. No se sube ni persiste nada adicional; los otros destinos no cambian.
+
+`aliasTemplate` solo deriva alias sin alias manual o integrado; consulta [plantillas](/es/guides/model-routing/#model-alias-templates). En respuestas de reset sin reemplazo, el registro distingue `ambiguous-no-policy`, `ambiguous-request-not-replayable` y `ambiguous-allowance-spent`. La política de reemplazo sigue desactivada por defecto y puede generar cargos duplicados si el primer envío ya empezó en origen.
+
+Las etiquetas de modelos nativos configuradas también se ofrecen mediante `GET /api/models`, de modo que exportaciones y `ocx opencode` las usan. OpenCode conserva el sufijo, por ejemplo `sol (native)`. Reinícialo o actualiza la integración administrada para regenerarlas; no cambia IDs, capacidades, orden, `/v1/models` ni filas virtuales. `claude-fable-5-2` conserva su ID original al configurar su modelo.
+
+`modelCapabilities` admite `mistralMaxImages` y `responsesCustomTools` por modelo. Son declaraciones del operador, no prueba de soporte. `responsesCustomTools` prevalece sobre `supportsResponsesCustomTools` para el modelo final exacto; ausente hereda el proveedor, y si ambos faltan se conservan herramientas custom nativas. PATCH puede borrar cada eje con null.
+
+La pausa automática nunca reanuda por sí sola; un login explícito limpia la pausa que registró sobre la credencial sustituida. [`resume --if-healthy`](/es/reference/cli/providers-accounts/#resume-if-healthy) exige lectura nueva correcta. Una pausa manual permanece hasta reanudarla.
+
+Para un proveedor Ark Kimi Responses personalizado, `arkKimiResponsesModels` lista IDs exactos del modelo o endpoint que rechazan includes de salida cifrada y replay de razonamiento huérfano. Está sin definir por defecto; usa el ID de origen, no su alias visible.
diff --git a/docs-site/src/content/docs/es/reference/configuration/routing.md b/docs-site/src/content/docs/es/reference/configuration/routing.md
new file mode 100644
index 00000000000..c29ac3c15b4
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/configuration/routing.md
@@ -0,0 +1,302 @@
+---
+title: "Configuración de enrutamiento"
+description: "Selección de proveedor predeterminado, orden de resolución del modelo, alias combinados, ordenación de objetivos y valores predeterminados de esfuerzo."
+---
+
+El enrutamiento convierte el ID de modelo enviado por un cliente en un proveedor concreto y un modelo ascendente.
+
+<a id="top-level-routing-fields"></a>
+
+## Campos de enrutamiento de nivel superior
+
+| Campo | Tipo | Predeterminado | Descripción |
+| --- | --- | --- | --- |
+| `defaultProvider` | `string` | `"openai"` | El proveedor final se usa cuando no coincide ninguna regla de modelo anterior. Debe nombrar un proveedor configurado habilitado. |
+| `combos?` | `Record<string, OcxComboConfig>` | `{}` | Modelos virtuales `combo/<id>` construidos a partir de objetivos de proveedor/modelo ordenados. |
+| `routingProfiles?` | `Record<string, OcxRoutingProfileConfig>` | `{}` | Modelos virtuales `policy/<id>` que seleccionan entre una lista de permisos de candidatos explícitos utilizando requisitos de capacidad dura y puntuación determinista. |
+
+<a id="model-alias-discovery"></a>
+
+### Alias de modelo descubrimiento
+
+Establecer `preferModelAliasIds: true` para publicar alias de modelo incorporados configurados o habilitados como el `id` en `GET /v1/models`. El valor predeterminado es `false`. Las filas promocionadas conservan su ID calificado anterior en `native_id` y mantienen `alias_of`; ambos ID permanecen enrutables. Los modelos sin alias mantienen sus ID existentes. Si un alias corto es ambiguo a través de proveedores o es sombreado por otra ruta, la fila mantiene su ID calificado de modo que la selección todavía alcanza el modelo previsto. El ID calificado también se mantiene cuando un alias corto incorporado produciría un selector Fast sintético no analizable. El catálogo de modelos de Codex no ha cambiado.
+
+<a id="codex-pool-only-policy"></a>
+
+### Solo cuentas añadidas en Codex Pool
+
+`codexPool.poolOnly`, booleano `false` de forma predeterminada, limita la selección automática a cuentas añadidas registradas. Activado, nunca elige la sesión principal nativa por ordenación, no la conserva como cuenta activa ni la usa como fallback del cliente; ignora una fijación manual sobre ella. Sin cuenta permitida apta, rechaza la solicitud. Modelos con cuenta explícita, incluido `__main__`, Reserve y modo Direct son elecciones fuera de esta política. No cambia las comprobaciones de pausa, duplicados, acceso y enfriamiento. Los helpers de búsqueda y visión que toman una sesión Codex siguen la regla: con solo la principal iniciada, consideran Codex no disponible.
+
+```json
+{"codexPool":{"poolOnly":true}}
+```
+
+<a id="codex-pool-low-quota-protection"></a>
+
+### Codex Pool Protección de baja cuota
+
+`codexPool.lowQuotaProtection` se aplica solo a las cuentas Codex Pool almacenadas. La cuenta de escritorio/principal mantiene su bloqueo separado del 98%. La forma opcional es:
+
+```json
+{"codexPool":{"lowQuotaProtection":{"enabled":true,"threshold":80,"actions":{"pause":true,"notify":true,"desktop":true},"windows":{"short":true,"weekly":true}}}}
+```
+
+Ausencia o `enabled: false` lo deshabilita. `threshold` es un porcentaje inclusivo finito de 1 a 100. Una directiva habilitada necesita al menos una acción verdadera y una ventana verdadera. Una ventana seleccionada de 5 horas o semanal se activa en `usage >= threshold`; cualquier ventana seleccionada es suficiente. Solo las observaciones nuevas aceptadas califican: no hay sondeos adicionales, y las observaciones de uso fuera de rango de créditos, caché, caducadas, mensuales, solo de ventana personalizada y sin procesar se ignoran para esta política. Las barras de visualización todavía pueden sujetar porcentajes aguas arriba no válidos. La política es independiente del cambio proactivo de cuenta.
+
+Con `pause`, la cuenta se excluye en memoria de la selección Pool antes de la siguiente solicitud. El servidor agrupa el guardado de configuración tras observar el turno y reintenta los fallos de guardado durante un plazo limitado. El cierre normal espera brevemente a los guardados pendientes. Un guardado cuyo plazo venció pero ya estaba ejecutándose permanece `pending` hasta que termine; uno en cola se cancela. Los fallos son visibles en el historial de eventos. Si el proxy se reinicia antes de guardar correctamente, puede perderse la pausa. Las solicitudes en curso conservan la cuenta que ya capturaron. La reanudación manual evita volver a pausar la cuenta por todas sus ventanas actualmente altas hasta que una lectura por debajo del umbral o un nuevo restablecimiento rearme una ventana. Un restablecimiento nunca reanuda una cuenta automáticamente.
+
+Con `notify`, el servidor escribe una línea de registro local con ventana y porcentaje, pero sin id de cuenta y registra un evento limitado. Autenticado `GET /api/codex-auth/low-quota-events` expone sólo los eventos de ese servidor, incluyendo ID de cuenta, ventana, porcentaje de uso, tiempo de restablecimiento conocido, marca de tiempo y estado. El estado predeterminado es `logged`: la alerta solo alcanzó el historial de registros y eventos. Cada cuenta/ventana se registra una vez por episodio local del servidor.
+
+Opcional `actions.desktop: true` (requiere `notify: true`) también entrega cada aviso al notificador del sistema operativo de la máquina que ejecuta el proxy: `/usr/bin/osascript` en macOS, o `notify-send` de `/usr/bin`, `/usr/local/bin` o `/bin` en Linux. La notificación nombra la cuenta solo por su etiqueta de registro seudónimo (por ejemplo, `p1a2b3c`), nunca por su correo electrónico, alias o id, e incluye la ventana, el uso, el umbral y el tiempo de reinicio conocido. Windows y hosts sin un notificador compatible mantienen la alerta `logged`. `delivered` significa que el notificador del sistema operativo aceptó la notificación; no puede ver si la configuración de notificación del sistema la oculta. Un notificador de fallo o de tiempo de espera se registra como `failed`; una observación elegible al menos cinco minutos más tarde puede volver a intentarlo, sin repetir la línea de registro. La activación o desactivación de `desktop` se aplica a la siguiente observación sin reiniciar. Un aviso que aún está en vuelo se cancela al apagarse, y cuando la siguiente observación de la cuota detecta que su episodio terminó (restaurar límite, recuperación, eliminación de cuenta o cambio de política); hasta entonces, el notificador está limitado por un tiempo de espera de cinco segundos.
+
+<a id="model-resolution-order"></a>
+
+## Orden de resolución del modelo
+
+opencodex resuelve el modelo solicitado en este orden:
+
+1. Un `policy/<id>` o alias de perfil configurado ejecuta el evaluador de políticas y enruta al candidato elegido. Un selector reservado `policy/<id>` desconocido se rechaza antes de evaluar las reglas posteriores.
+2. Un espacio de nombres `<account-selector>/<native-openai-model>` configurado usa exactamente la cuenta de Codex asignada. Si el modelo nativo o el destino exacto no son válidos o no están disponibles, la solicitud se rechaza sin recurrir a Pool, Direct ni a otro proveedor.
+3. Un `combo/<id>` canónico o un alias de Combo configurado. Los identificadores canónicos tienen prioridad frente a los alias.
+4. Un espacio de nombres `<provider>/<model>` explícito cuyo prefijo sea un proveedor configurado.
+5. Un identificador nativo de OpenAI sin prefijo, como `gpt-*`, `o1-*`, `o3-*` u `o4-*`, mediante el proveedor canónico `openai` activado.
+6. Una coincidencia exacta con el `defaultModel` de un proveedor.
+7. Un prefijo conocido de familia de modelos.
+8. Un modelo exacto de la lista `models` de un proveedor.
+9. `defaultProvider`, conservando el identificador solicitado.
+
+Se excluyen los proveedores desactivados. Una solicitud con el espacio de nombres explícito de un proveedor deshabilitado se rechaza en lugar de continuar con las reglas siguientes. Las entradas de proveedor se comprueban en su orden de inserción JSON cuando una regla puede coincidir con varios proveedores; usa espacios de nombres explícitos si un modelo sin prefijo podría ser ambiguo.
+
+<a id="blocked-model-redirects"></a>
+
+### Redireccionamientos de modelo bloqueado
+
+`blockedModelRedirects` es un nivel superior opcional `Record<string, string>` de reemplazos de ID de modelo resueltos exactos, no configurado por defecto. Las claves desnudas aún coinciden con el proveedor, la cuenta y la resolución de alias del modelo nativo **después**. Un objetivo sin un proveedor configurado explícito y diferente mantiene ese proveedor y cuenta seleccionados y reemplaza solo el ID de modelo ascendente, una vez. Esto preserva las asignaciones existentes de valores desnudos y de barra diagonal, incluidas las asignaciones en las solicitudes calificadas por el proveedor.
+
+Un destino que nombra explícitamente un **proveedor configurado diferente** (por ejemplo, `google-antigravity/gemini-3.8-flash-high`) en su lugar se enruta a través de ese proveedor. Una clave exacta `<source-provider>/<resolved-model>` con tal objetivo tiene prioridad sobre una clave desnuda; otras claves calificadas no tienen ningún efecto. Las redirecciones entre proveedores pueden encadenarse a través de alias resueltos, con un límite de cinco bordes compartido y detección de ciclo. Un selector de cuenta anclado nunca sale de su cuenta: un destino que apunta a otro proveedor se rechaza, tanto si su clave no tiene prefijo como si está calificada para la cuenta. El destino utiliza sus propias credenciales y cuota, y nunca hereda campos de cuenta de origen; se elimina un encabezado `Authorization` del llamante dirigido a la ruta de origen, como para las rutas combinadas y de directiva. Un destino deshabilitado, un destino directo o un destino clave/OAuth sin credenciales almacenadas utilizables mantiene el comportamiento heredado de la ruta de origen. Bajo una política de enrutamiento, cada objetivo de redirección debe ser un candidato elegible declarado, incluso cuando mantiene el mismo proveedor. El conjunto de proveedores/modelos elegibles de la evaluación inicial permanece fijo a través de la recuperación de subagentes. Los reintentos usan candidatos concretos, por lo que un alias combinado no puede reemplazar el destino de un candidato. Diferentes candidatos que resuelven un destino ya intentado no vuelven a enviar el turno allí. Un modelo virtual elegible mantiene su mapeo normal de modelo de cable sin agregar esa identificación de cable a los candidatos permitidos del perfil. Si se salta un reemplazo local, la reserva retiene el último fallo aguas arriba. Los mapas de redirección mal formados se ignoran con una advertencia bajo carga y se rechazan en las escrituras de configuración. Las rutas redirigidas registran `blocked-model-redirect`; omitiendo la configuración deja el enrutamiento sin cambios.
+
+```json
+{
+  "blockedModelRedirects": { "gpt-5.6-terra": "gpt-5.6-luna" }
+}
+```
+
+<a id="exact-codex-account-selectors"></a>
+
+## Selectores de cuenta Codex exactos
+
+`codexAccountNamespaces` mapea un selector público tal como `side` a una cuenta Codex almacenada. Una solicitud para `side/gpt-5.6-sol` usa solo esa cuenta, incluso cuando el proveedor canónico `openai` está en modo Direct, y envía el identificador de modelo `gpt-5.6-sol` desnudo aguas arriba. Solo los identificadores familiares OpenAI nativos desnudos son válidos después del selector. Los identificadores de cuentas descubiertas observados en el catálogo de modelos actual de Codex también se pueden conservar exactamente cuando aún no forman parte del conjunto estático de opencodex; la observación debe llevar la forma de campo de una fila de catálogo real, permanece calificada para su selector de cuenta coincidente y nunca se promociona a la lista de modelos desnudos global. Esa comprobación de forma filtra filas mal formadas y mínimas: no es un control de confianza, porque la caché de modelos es un archivo propiedad del usuario y una fila completa escrita a mano es indistinguible de una observación ascendente. Nada nuevo se convierte en enrutable: un identificador `gpt-*` desnudo bajo un selector de cuenta es aceptado por el enrutador independientemente del catálogo.
+
+La selección exacta evita la estrategia de asignación Pool y la afinidad de hilo ordinaria. Si la cuenta asignada falta, está pausada, se está enfriando, no se puede usar o requiere una nueva autenticación, la solicitud se rechaza sin recurrir a otra cuenta y no cambia la cuenta activa de Pool. Cuando se configura al menos un selector elegible, Codex catálogos ocultan filas de selector nativo desnudas y listan una fila `<selector>/<native-openai-model>` separada para cada selector. Los identificadores nativos desnudos retienen el enrutamiento normal Pool / Direct y permanecen en el descubrimiento de `/v1/models` sin procesar a menos que se deshabiliten explícitamente. Los selectores cuya cuenta almacenada asignada no se muestra no se anuncian. La validación del selector, las reglas de colisión y la guía de privacidad están documentadas en [Configuración del proveedor](/es/reference/configuration/providers/).
+
+La página Codex Auth expone este comportamiento de selector como un opt-in. Deshabilitarlo oculta las filas del selector calificado generadas y restaura las filas ordinarias de GPT, pero no elimina las asignaciones ni cambia el enrutamiento exacto `<selector>/<model>`. Por lo tanto, volver a habilitar restaura las mismas etiquetas públicas. Las mutaciones de cuenta y configuración persisten antes de una actualización de catálogo limitada; una advertencia `ocx sync` solo significa que el catálogo de selector aún necesita convergencia, no que se haya perdido el cambio de enrutamiento.
+
+## Combos (`config.combos`)
+
+Cada tecla combinada es una identificación que coincide con `[A-Za-z0-9][A-Za-z0-9._-]{0,63}`. Siempre es direccionable directamente como `combo/<id>` y también puede exponer un `alias`. Los alias deben ser únicos, no pueden ocupar el espacio de nombres `combo/` y no pueden usar familias nativas desnudas reservadas como `gpt-*`, `o1-*`, `o3-*`, `o4-*` o `codex-*` a menos que `nativeAlias: true` permita explícitamente el contrato de compatibilidad con el escritorio.
+
+| Clave | Tipo | Predeterminado | Descripción |
+| --- | --- | --- | --- |
+| `targets` | `{ provider: string; model: string; weight?: number; lastResort?: boolean; metered?: boolean }[]` | requerido | Rutas concretas ordenadas. `weight` es 1-10000 y por defecto `1`. `lastResort` marca un objetivo de emergencia solamente; ver `cooldownWaitPolicy`. `metered: true` requiere el consentimiento de la clave o el consentimiento combinado de solo loopback; ver [consentimiento](/es/guides/combos/#metered-fallback-consent). |
+| `allowMeteredTargets?` | `boolean` | `false` | Consentimiento del operador para llamadas locales en un proxy de solo loopback. Un oyente que no es de bucle de retorno deshabilita esta bandera; las personas que llaman con clave configurada y vinculada todavía necesitan el consentimiento de clave. |
+| `strategy?` | `"failover" \| "round-robin" \| "random" \| "least-used" \| "reset-window" \| "jev"` | `"failover"` | Estrategia de selección. El orden objetivo es la prioridad de conmutación por error; los pesos forman sorteos redondos y aleatorios; el menos utilizado sigue los éxitos registrados; la ventana de reinicio sigue el reinicio de cuota más rápido; JEV toma una decisión limitada para el objetivo inicial elegible y el esfuerzo, luego usa la reserva ordenada ordinaria. |
+| `stickyLimit?` | `number` | `1` | Solicitudes exitosas retenidas en un lote round-robin. Alcance 1-100. Solo se aplica a round-robin. |
+| `cooldownMs?` | `number` | sin configurar → 5 s para límites de frecuencia 429 con códigos `1302`/`1305`; 10 min para una ventana de uso agotada o fallos de credenciales/facturación de todo el proveedor; 60 s en los demás casos | Rango 1-600000. Cuando se establece, se aplica siempre que no exista una señal de reinicio de flujo ascendente `Retry-After` o Codex utilizable, incluida la tasa de solicitud 429s; cuando no se establece, utiliza la reposición de flujo ascendente. Las señales ascendentes tienen prioridad. Un `Retry-After` aguas arriba explícito está limitado a las 24 horas; los tiempos de reutilización derivados, configurados y de reserva están limitados a los 10 minutos. |
+| `waitForCooldownMs?` | `number` | `0` | Esperar al máximo el objetivo de enfriamiento elegible más temprano en cada intento de selección. Rango 0-600000; un aborto cancela la espera. Un combo de un solo objetivo con una espera distinta de cero mantiene la solicitud hasta este techo y vuelve a intentar el mismo objetivo en lugar de fallar inmediatamente; si no se envió ningún objetivo, la espera termina en `combo_unavailable`, de lo contrario se devuelve el último fallo ascendente. |
+| `cooldownWaitPolicy?` | `"before-last-resort"` | Sin configurar | Aplaza los destinos marcados como `lastResort`: con cualquier estrategia, solo se usan si no hay un destino normal disponible. `waitForCooldownMs` permite esperar a que termine el enfriamiento de un destino normal. Con su valor predeterminado `0` no se espera y se usa el último recurso en cuanto no haya un destino normal disponible. Este aplazamiento y la espera ordinaria comparten un único presupuesto `waitForCooldownMs` por intento de selección. Solo la cadena indicada activa esta política; sin ella, `lastResort` no tiene efecto. |
+| `defaultEffort?` | `"low" \| "medium" \| "high" \| "xhigh" \| "max" \| "ultra" \| null` | Sin configurar | `defaultEffort` llena un `reasoning.effort` ausente en el modo de reserva, o anula el esfuerzo del llamante válido en el modo de fuerza explícita cuando el combo tiene un valor por defecto no nulo y el objetivo seleccionado tiene una escalera conocida, no vacía. Si el destino admite el valor configurado, se retiene; de lo contrario, se usa el peldaño soportado más alto en o por debajo de él, o el peldaño soportado más bajo cuando ninguno es más bajo. Las escaleras desconocidas o vacías omiten el valor predeterminado. |
+| `defaultEffortMode?` | `"fallback" \| "force"` | `"fallback"` | Preserva la precedencia del llamante por defecto. La fuerza explícita requiere un valor predeterminado válido, respeta la capacidad de destino y puede aumentar el costo y la latencia. `reasoningEffortMode` sigue siendo independiente. |
+| `reasoningEffortMode?` | `"strict" \| "adaptive"` | `"strict"` | `"strict"` calcula la intersección de todas las escalas de esfuerzo conocidas de los objetivos, incluidas las vacías; `"adaptive"` excluye las escalas vacías. Las escalas desconocidas actúan como comodines en el catálogo en ambos modos. Al enviar la solicitud, una escala explícitamente vacía elimina los controles de esfuerzo y pensamiento en ambos modos; una escala desconocida solo los elimina en modo adaptativo. Se conserva `reasoning.summary`. Los objetivos con escalas conocidas y no vacías mantienen su resolución de esfuerzo; la selección y el orden de los objetivos no cambian. |
+| `jevEffortMode?` | `"decide" \| "client"` | `"decide"` | Solo JEV. `"decide"` aplica al primer hijo el esfuerzo decidido, por encima del cliente. `"client"` conserva el destino decidido y usa la política Combo habitual: esfuerzo del cliente, escala del destino y `defaultEffort`/`defaultEffortMode`; `"force"` aún prevalece. Solo se guarda `"client"`. Consulta [límites y estado compartidos](/es/guides/combos/#shared-limits-state-and-statistics). |
+| `imageInput?` | `"auto" \| "disabled"` | `"auto"` | `"auto"` publica imágenes solo cuando cada objetivo admite imágenes; `"disabled"` fuerza el texto solo (cae la imagen de las modalidades publicadas y rechaza las solicitudes que llevan imágenes antes del envío). |
+| `alias?` | `string` | — | id modelo público opcional en lugar de la identificador selector canónica. |
+| `nativeAlias?` | `boolean` | `false` | Permite que un id nativo sin calificar actualmente soportado tenga prioridad solo para ese id. Los ids `gpt-5.6-*` sin calificar usan las credenciales de grupo/directas de Codex. Las rutas calificadas por cuenta siguen siendo distintas. Las rutas calificadas por proveedor como `openai-apikey/gpt-5.6-*` usan su ruta de clave API configurada y nunca pasan al alias nativo. |
+| `displayName?` | `string` | — | Etiqueta de catálogo solo para mostrar, requerida y no vacía para un alias nativo. |
+| `decisionProvider?` | `string` | `"jev"` | `strategy: "jev"` solamente. `"jev"` (lo mismo que omitirlo y almacenarlo como omisión) es el servicio de decisión TypeSafe, válido sin una fila de proveedor; cualquier otro valor debe nombrar un proveedor configurado con `adapter: "jev-decision"` y una decisión completa HTTPS `baseUrl` (cualquier ruta) o un punto final local HTTP `/systemone`. Userinfo, cadenas de consulta y fragmentos son rechazados. |
+| `decisionModel?` | `string` | Sin configurar | `strategy: "jev"` solamente, mutuamente excluyentes con `decisionProvider`. Una ruta ordinaria opencodex (por ejemplo `ollama/qwen3:4b`) pidió elegir una opción ofrecida como JSON. Se ejecuta con las credenciales almacenadas del proveedor seleccionado, nunca con las de la persona que llama, y no puede resolver este combo, ningún combo JEV o una fila `jev-decision`. |
+| `decisionTimeoutMs?` | `number` | `4000` | Solo `strategy: "jev"`. Plazo de la decisión antes de usar la alternativa fail-open al primer destino elegible, 1000-120000 ms. |
+| `decisionQuotaSignals?` | `boolean` | `false` | Sólo JEV. Explícito `true` envía evidencia de cuota de asesoramiento cargada al backend seleccionado; nunca cambia la elegibilidad dura o la selección de cuenta. |
+| `decisionQuotaTiers?` | `{ moderate?: number; limited?: number; nearlyExhausted?: number }` | `{ limited: 70, nearlyExhausted: 90 }` | Sólo JEV. Las anulaciones parciales se combinan con valores predeterminados; los valores finitos de 0-100 deben ser estrictamente ascendentes. `moderate` está ausente a menos que sea explícito. No permite señales por sí mismo. |
+| `sessionPin?` | `{ ttlMs: number }` | Desactivado | Solo JEV. Mantiene una sesión explícita del cliente en el destino elegido mientras siga activa; `ttlMs` es el plazo de inactividad, de 60000 a 86400000. `null` borra el ajuste. Véase [Fijación de sesión para JEV](/es/guides/combos/#session-pin-for-jev). |
+
+La configuración de cuotas, la privacidad y la semántica de grupos desconocidos se describen en [Señales de cupos de asesoramiento para JEV](/es/guides/combos/#advisory-quota-signals-for-jev). La configuración omitida sobrevive a las actualizaciones/cambio de nombre de JEV API; `null` borra, `false` desactiva las señales sin borrar niveles, y cambiar a otra estrategia elimina ambas configuraciones.
+
+```json
+{
+  "defaultProvider": "openai",
+  "combos": {
+    "coding": {
+      "targets": [
+        { "provider": "anthropic", "model": "claude-sonnet-5" },
+        { "provider": "openrouter", "model": "qwen/qwen3-coder-plus" }
+      ],
+      "strategy": "failover",
+      "defaultEffort": "high",
+      "alias": "coding-primary"
+    }
+  }
+}
+```
+
+Para ver el comportamiento de la estrategia, los fallos reintentables, los tiempos de reutilización, los límites de tareas cifrados v2 y los comandos de administración, consulte [Combos](/es/guides/combos/).
+
+La estrategia `jev` es opcional. Solo el método TypeSafe, utilizado cuando no se establece `decisionProvider` ni `decisionModel`, requiere la credencial del proveedor canónico `jev`. Este proveedor es un servicio de decisión: no publica modelos enrutables directamente y no puede ser un destino de un combo. JEV solo considera los miembros de `targets` que sean elegibles en ese momento. Si la decisión falta, falla o no es válida, utiliza el primer miembro elegible; la cancelación del llamante sigue siendo terminal. Añadir el proveedor o el combo no cambia `defaultProvider` ni oculta modelos directos. Consulta [Método de decisión](/es/guides/combos/#decision-method) para conocer los tres métodos, la configuración, los límites de privacidad y el contrato de una decisión por llamada. Los ámbitos de proveedor y modelo de las claves API también se aplican a los destinos de decisión TypeSafe y autoalojados, antes de leer sus credenciales o el estado de la solicitud. Si la clave no permite el destino de decisión opcional, no se envía ninguna solicitud de decisión. El fallback de inferencia también debe respetar los ámbitos de esa clave.
+
+<a id="self-hosted-decision-model-eg-ollama-tev1"></a>
+
+### Modelo de decisión autoalojado (e.g. Ollama tev1)
+
+`decisionProvider` puede apuntar un combo JEV a un modelo de decisión autoalojado compatible con Jev-API, como `tev1` de Ollama (Ollama 0.35 +, `POST /v1/systemone`, sin clave API):
+
+```json
+{
+  "providers": {
+    "ollama-tev1": {
+      "adapter": "jev-decision",
+      "baseUrl": "http://127.0.0.1:11434/v1/systemone",
+      "allowPrivateNetwork": true,
+      "defaultModel": "tev1:4b",
+      "liveModels": false
+    }
+  },
+  "combos": {
+    "jev-local": {
+      "strategy": "jev",
+      "decisionProvider": "ollama-tev1",
+      "decisionTimeoutMs": 60000,
+      "targets": [
+        { "provider": "openai", "model": "gpt-5.6-sol" },
+        { "provider": "openai", "model": "gpt-5.6-luna" }
+      ]
+    }
+  }
+}
+```
+
+El `baseUrl` de la fila es el endpoint de decisión completo. Los endpoints locales
+con HTTP sin cifrar deben terminar en `/systemone`; los endpoints HTTPS pueden usar
+su ruta configurada, por ejemplo `/v1/decisions`. El modelo procede de
+`defaultModel` o, en su defecto, de `models[0]`. Una fila sin ninguno de los dos
+aplica la alternativa fail-open sin enviar una solicitud de decisión.
+Loopback requiere un `allowPrivateNetwork: true` explícito en la propia fila.
+El protocolo `http:` sin cifrar solo se acepta para `localhost` o una dirección
+literal de loopback, RFC 1918 o ULA alcanzada sin proxy.
+
+Solo se envía el `apiKey` de esa fila, o ninguna clave si no está configurada.
+Se rechaza una clave que haga referencia a las variables de entorno de TypeSafe
+o a la entrada de llavero de otro proveedor; las credenciales de TypeSafe nunca
+se envían a este destino. Las opciones se transmiten como cadenas de descripción,
+como requiere Ollama. `tev1` se entrenó con 2–24 opciones: mantenga el producto
+de destinos por niveles de esfuerzo en 24 o menos. Si hay menos de 2 o más de
+26 opciones, se aplica la alternativa fail-open sin hacer la solicitud.
+Su contexto efectivo es de unos 2k tokens, y OpenCodex limita el texto de la tarea
+a 500 caracteres.
+
+Mantenga el modelo residente (`OLLAMA_KEEP_ALIVE=-1`) y aumente
+`decisionTimeoutMs` para servicios lentos; consulte
+[Servidor compatible con System One](/es/guides/combos/#system-one-compatible-server).
+En el panel, elija **Servidor compatible con System One** en **Método de decisión**
+del combo JEV, en **Modelos → Combos**. Seleccione la fila y configure
+**Tiempo de espera de decisión (ms)**.
+
+<a id="routing-policy-profiles-configroutingprofiles"></a>
+
+## Perfiles de las políticas de enrutamiento (`config.routingProfiles`)
+
+Los perfiles de política de enrutamiento son la capa de selección de Inteligencia de Enrutador: un `policy/<id>` solicitado explícitamente (o alias configurado) selecciona entre una lista de permisos candidata fija utilizando requisitos de capacidad dura y puntuación explicable y determinista. Una solicitud explícita `policy/<id>` (o un alias configurado) ejecuta el evaluador y encamina al candidato seleccionado. Los identificadores de modelo existentes son **nunca** enrutados a través de un perfil implícitamente: el espacio de nombres `policy/` y los alias de perfil son los únicos puntos de entrada, y ambos se validan contra el orden de resolución del modelo anterior.
+
+Cada clave es un id que coincide con `[A-Za-z0-9][A-Za-z0-9._-]{0,63}`, siempre direccionable como `policy/<id>`, con un `alias` opcional. Los alias deben ser únicos y no pueden colisionar con proveedores configurados, el espacio de nombres de enrutamiento `<provider>/<model>`, los combos, los espacios de nombres de cuentas de Codex, el espacio de nombres `policy/` ni las familias nativas sin calificar reservadas (`gpt-*`, `o1-*`, `o3-*`, `o4-*`, `codex-*`).
+
+| Clave | Tipo | Predeterminado | Descripción |
+| --- | --- | --- | --- |
+| `candidates` | `{ provider: string; model: string }[]` | requerido | Lista explícita de permisos de `provider/model` refs. No hay expansión implícita. |
+| `alias?` | `string` | — | ID modelo público opcional en lugar de `policy/<id>`. |
+| `require?` | objeto | `{}` | Requisitos de capacidad dura evaluados antes de la puntuación (ver más abajo). |
+| `optimize?` | objeto | latencia 0,55, salud 0,25, costo 0,10, cuota 0,10 | Pesos de puntuación, normalizados determinísticamente. `health`, `quota` y `cost` tienen dimensiones de puntuación; la cuota de prioridad configurada es `1 - health - quota - cost` (por defecto 0,55), y `latency` se pliega en esa cuota de prioridad en lugar de anotar independientemente. |
+| `limits?` | objeto | — | Límites difíciles. `maxEstimatedCostUsd` excluye a un candidato cuando se conoce su costo estimado y por encima del límite. Cuando se establece ese límite, `onUnknownCost` ( `"allow"` por defecto, o `"exclude"` ) controla estimaciones desconocidas: allow evita una exclusión específica del límite y registra `cost.capOutcome: "unknown-allowed"`; exclude emite `cost-limit-unknown` y `capOutcome: "unknown-excluded"`. `onUnknownCost` solo (sin tapa) es inerte. Separado de `unknownEvidence.cost`, que aún puede excluir o penalizar precios desconocidos a través de `unknown-price` / puntuación. |
+| `unknownEvidence?` | objeto | capacidad `exclude`, salud / cuota / costo `penalize` | Cómo se trata la evidencia desconocida por dimensión: `allow`, `penalize` o `exclude`. Desconocido nunca se convierte en cero. |
+
+`require` soporta: `minContextWindow` (entero positivo), `minQuotaHeadroom` (0...1 fracción), y los booleanos `tools`, `imageInput`, `structuredOutput`, `localOnly`, `remoteAllowed`,
+`encryptedCodexTasks`; más `reasoningEffort` y `serviceTier` cuerdas.
+
+Para `unknownEvidence.capability`, `penalize` se comporta actualmente como `allow`: la puntuación solo tiene un componente de prioridad configurada hasta que se envía una dimensión de puntuación de capacidad (planificada con RI-06 +), por lo que `penalize` aún no puede cambiar el candidato seleccionado.
+
+La evidencia de solicitud se evalúa contra las capacidades del candidato junto con el bloque `require` de perfil; un candidato debe satisfacer a ambos para ser elegible. En la ruta de solicitud en vivo, el proxy obtiene herramientas y evidencia de entrada de imagen del cuerpo de la solicitud; el tamaño de la ventana de contexto y las dimensiones de evidencia restantes permanecen desconocidas en el momento del enrutamiento. Utilice la prueba en seco API / CLI para inspeccionar toda la superficie de evidencia en busca de perfiles sensibles al contexto.
+
+El CLI en seco acepta banderas de solicitud de pruebas, pero aún no puede proporcionar evidencia de capacidad candidata; la evidencia candidata se proporciona a través del API (`POST /api/routing-profiles/dry-run`).
+
+```json
+{
+  "routingProfiles": {
+    "fast": {
+      "alias": "ocx/fast",
+      "candidates": [
+        { "provider": "anthropic", "model": "claude-sonnet-5" },
+        { "provider": "openai", "model": "gpt-5.6-sol" }
+      ],
+      "require": { "tools": true, "minContextWindow": 128000 },
+      "optimize": { "latency": 0.55, "health": 0.25, "cost": 0.10, "quota": 0.10 },
+      "limits": { "maxEstimatedCostUsd": 0.50, "onUnknownCost": "allow" },
+      "unknownEvidence": {
+        "capability": "exclude",
+        "health": "penalize",
+        "quota": "penalize",
+        "cost": "penalize"
+      }
+    }
+  }
+}
+```
+
+CLI: `ocx route policy list [--json]`, `ocx route policy show <id> [--json]`, y `ocx route policy dry-run <id> [--model-context <tokens>] [--tools] [--image] [--structured-output] [--json]`. Dry-run evalúa a los candidatos sin enviar ninguna solicitud previa.
+
+La evidencia de cuotas (`optimize.quota`, `require.minQuotaHeadroom`, `unknownEvidence.quota`) proviene de cachés de cuotas Codex y Anthropic con clave de cuenta. Un candidato en entorno de ejecución recibe la cuota en caché solo cuando la evidencia ya identifica la cuenta. Los candidatos canónicos no vinculados `openai` y Anthropic siguen siendo desconocidos durante la evaluación de la política porque la selección Pool, la identidad del llamante Direct, la rotación del proveedor y la afinidad del hilo se resuelven después de que la política elija un proveedor / modelo; una cuenta activa en el proceso no se usa como sustituto. La evidencia de cuotas nunca cambia la selección de cuentas, la afinidad de sesiones, los tiempos de reutilización o el comportamiento de cambio, solo alimenta la puntuación de las políticas. Para ver el comportamiento de acuerdo con la cuota en una ejecución en seco de API, las referencias de cuenta de suministro en la evidencia candidata enviadas a `POST /api/routing-profiles/dry-run`: `candidates[].codexAccountId` (grupo de Codex, proveedor `openai`) o `candidates[].accountRef` (Anthropic) obtienen la cuota de cuenta en caché coincidente; se repite un objeto `candidates[].quota` explícito como se indica. El CLI dry-run no puede suministrar estos campos de cuenta por candidato.
+
+<a id="combos-vs-policy-profiles"></a>
+
+### Combos vs perfiles de políticas
+
+- Un **combo** es un enrutamiento de destino explícito con una estrategia seleccionable (conmutación por error ordenada, equilibrio ponderado o aleatorio suave, menos utilizado, ventana de reinicio o una decisión de primera selección de JEV limitada): la estrategia configurada decide y los fallos reintentables avanzan a través de la lista.
+- Un **perfil político** es una selección basada en la evidencia entre los candidatos configurados: los requisitos de capacidad dura se filtran primero, luego la puntuación determinista clasifica a los sobrevivientes.
+
+Ambos son espacios de nombres virtuales con alias y validación de colisión; difieren en *cómo* se elige un candidato. La puntuación de perfil combina el componente de prioridad configurada con las dimensiones de puntuación de salud (RI-06), cuota (RI-07) y coste (RI-08) donde hay evidencia; el peso de `latency` se pliega en la cuota de prioridad en lugar de anotar independientemente. El costo también se aplica a través del límite de `limits.maxEstimatedCostUsd`: se excluye a un candidato cuyo costo estimado sea conocido y exceda el límite (`cost-limit`). Cuando se configura un límite y se desconoce la estimación, el valor predeterminado `limits.onUnknownCost: "allow"` registra `cost.capOutcome: "unknown-allowed"` en el trazado de decisión de ruta sin una exclusión de límite; se establece `onUnknownCost: "exclude"` para un techo cerrado por error (`cost-limit-unknown`). El resultado del límite no es la elegibilidad general: `unknownEvidence.cost: "exclude"` aún puede agregar `unknown-price` y marcar al candidato no elegible. Los rastros de decisión de ruta por solicitud se registran cuando se ejecuta un perfil de directiva.
+
+<a id="catalog-eligibility"></a>
+
+### Elegibilidad del catálogo
+
+Un combo permanece directamente enrutable incluso cuando no se puede enumerar. `ocx sync`, `/v1/models`, y el selector Codex lo lista solo cuando cada destino expone capacidades que pueden ser intersectadas:
+
+- un `contextWindow` positivo, a partir de metadatos activos, sugerencias de registro, proveedor `modelContextWindows` / `contextWindow`, un `maxInputTokens` positivo conocido en la fila de miembros, o - cuando el proveedor es conocido y habilitado pero cada fuente aún omite una ventana - una reserva conservadora de 128,000 tokens (fijada por `providerContextCaps` cuando se establece); y
+- una intersección `inputModalities` no vacía, tratando un valor de miembro omitido como `["text"]`.
+
+Un destino en un proveedor deshabilitado (incluso con una fila de descubrimiento completa), en un proveedor desconocido sin fila de descubrimiento, o en objetivos con modalidades disjuntas, elimina el combo del catálogo. La sincronización emite una advertencia de resumen y el tablero de instrumentos lo marca como **Necesita atención**. Agrega metadatos de contexto, alinea modalidades o modelos de destino con capacidades compatibles detectables.
+
+<a id="request-history-and-routing-analytics"></a>
+
+## Historial de solicitudes y análisis de enrutamiento
+
+- `GET /api/request-history` - historia completa paginada por cursor del índice derivado (`routing-history.sqlite`), con filtros (`provider`, `model`, `requestedModel`, `status`, `conversationId`, `surface`, `inboundProtocol`, `apiKeyId`, `profileId`, `fallback`, `from`, `to`) y paginación opaca `cursor`. `GET /api/request-history/:requestId` devuelve una fila canónica.
+- `GET /api/request-history/:requestId/route-decision` - la explicación de por qué esta ruta: traza (candidatos, exclusiones, componentes de puntuación, perfil + revisión), secuencia de intentos de ejecución y resultado final.
+- `GET /api/routing-analytics` - tasas de éxito/fracaso/cancelado/retroceso, duración p50/p95/p99 y TTFT, tasa de flujo incompleto, fallos de activación de tiempo de reutilización, costo por solicitud exitosa, cobertura, confianza y un indicador de truncamiento explícito.
+- `GET /api/routing-profiles`, `POST /api/routing-profiles/dry-run` - inspección de perfil y evaluación de funcionamiento en seco (sin despacho previo).
+
+El historial devuelto y las cargas útiles de decisión de ruta exponen solo metadatos de solicitud enmascarados (por ejemplo, etiquetas opacas `apiKeyId`). No incluyen credenciales, cuerpos rápidos en bruto o secretos de proveedores.
+
+CLI: `ocx logs history`, `ocx logs get <request-id>`, `ocx logs explain <request-id>`, `ocx logs rebuild-index`, `ocx logs index-status`, `ocx route policy list | show | dry-run | evaluate`.
+
+<a id="index-validation-and-recovery"></a>
+
+### Validación y recuperación del índice
+
+Un índice de historial existente se comprueba en un proceso de trabajo de solo lectura al abrirlo por primera vez. Las consultas de historial esperan esa comprobación inicial sin bloquear el hilo que atiende las solicitudes del proxy. Mientras tanto, las lecturas síncronas de enrutamiento indican que el índice está ocupado y los perfiles aplican su política `unknownEvidence.health`. Una reconstrucción pequeña realizada en línea queda disponible de inmediato; una reconstrucción en un proceso de trabajo se comprueba antes de publicarse.
+
+Tras una comprobación o reconstrucción correcta, la primera lectura realizada al menos cinco minutos después inicia una única comprobación de integridad en segundo plano. Las lecturas siguen usando el índice verificado mientras se ejecuta. Las actualizaciones normales conservan las comprobaciones de esquema, identidad de origen y desplazamiento, sin un recorrido síncrono completo; un índice inactivo no inicia ningún temporizador. Los fallos temporales, como una base de datos ocupada o un proceso de trabajo no disponible, conservan el índice y permiten reintentar en una lectura posterior tras una espera de 30 segundos. Un índice que aún no complete su validación inicial permanece inaccesible.
+
+La corrupción detectada provoca una reconstrucción automática a partir de `usage.jsonl`, con un reintento para la lectura asíncrona de historial o analítica afectada. Cerrar o reconstruir el índice descarta los resultados antiguos y espera a que el comprobador libere el archivo antes de sustituirlo. La validación y recuperación nunca reescriben el registro canónico. La comprobación inicial sigue tardando un tiempo proporcional al tamaño del índice; las posteriores solo se ejecutan cuando se utiliza.
+
+<a id="migration"></a>
+
+## Migración
+
+`routingProfiles` es opcional y aditivo: los archivos de configuración existentes se cargan sin cambios. Las filas antiguas de `usage.jsonl` que no incluyen `routeDecision` se siguen analizando sin cambios. El índice histórico se puede reconstruir: eliminar `routing-history.sqlite` provoca su reconstrucción automática desde `usage.jsonl` en la siguiente consulta; `ocx logs rebuild-index` permite forzarla. Cuando `usage.jsonl` alcanza 1 MiB, la reconstrucción se ejecuta en un hilo de trabajo para que el proxy siga atendiendo solicitudes. Las consultas del historial esperan a que termine y los perfiles de enrutamiento tratan mientras tanto el estado histórico como evidencia desconocida, según la política `unknownEvidence.health` del perfil. Este sistema no ajusta automáticamente los pesos, presupuestos ni conjuntos de candidatos.
diff --git a/docs-site/src/content/docs/es/reference/configuration/server.md b/docs-site/src/content/docs/es/reference/configuration/server.md
new file mode 100644
index 00000000000..c09477ef3f6
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/configuration/server.md
@@ -0,0 +1,837 @@
+---
+title: "Configuración de servidor y entorno de ejecución"
+description: "Listener, acceso remoto, claves de admisión, tiempos de espera, almacenamiento, sidecars, llamadas auxiliares e inicio del entorno."
+---
+
+La configuración del servidor controla la forma en que el proxy local escucha, protege el tráfico remoto, administra los recursos y ejecuta las funciones de ayuda en torno a las solicitudes del proveedor.
+
+<a id="server-fields"></a>
+
+## Campos del servidor
+
+`completeOnMaxOutputTokens` es un booleano opcional, `false` de forma predeterminada. Actívalo para que una respuesta de texto de Responses traducida y limitada por tokens se indique como `completed` en lugar de `incomplete`. El texto sigue truncado: OpenCodex lo conserva exactamente, incluido cualquier Markdown sin terminar. Solo admite salida de texto plano no vacía. Quedan excluidas las llamadas a herramientas y operaciones alojadas, aunque hayan terminado, el razonamiento, `text.format` con `json_schema` o `json_object`, la compactación, los turnos explícitamente sin terminar, los errores y la ausencia de eventos terminales. El agotamiento de la ventana de contexto y `pause_turn` siguen siendo incompletos. Chat Completions, Anthropic Messages y el paso directo nativo de Responses, incluida su salida WebSocket nativa, conservan su comportamiento de finalización.
+
+| Campo | Tipo | Predeterminado | Descripción |
+| --- | --- | --- | --- |
+| `completeOnMaxOutputTokens?` | `boolean` | `false` | Activa la finalización de las respuestas de texto de Responses traducidas que cumplan las condiciones y alcancen el límite de tokens. El texto sigue truncado; se aplican las exclusiones anteriores. |
+| `port` | `number` | `10100` | Puerto de escucha proxy. |
+| `hostname?` | `string` | `"127.0.0.1"` | Dirección de escucha. Fuera de loopback exige una clave de cliente configurada en `config.apiKeys` o un token compartido de datos, resuelto en este orden: `OPENCODEX_API_AUTH_TOKEN`, `OCX_API_TOKEN_FILE` y el archivo instalado `service-api-token`, accesible solo por su propietario. Consulta [Acceso remoto](#remote-access). |
+| `proxy?` | `string` | — | URL de proxy de salida HTTP(S) o SOCKS5 (`socks5://host:port`), `${ENV_VAR}` o `"auto"`. Las URL HTTP se aplican a `HTTP_PROXY` / `HTTPS_PROXY` si no están definidas. SOCKS5 utiliza el transporte de OpenCodex y también se expone mediante `ALL_PROXY` (`ocx start --socks5`); en este proceso se elimina el `HTTP(S)_PROXY` heredado. Loopback permanece en `NO_PROXY`. `"auto"` lee una vez al iniciar la configuración estática HTTP/HTTPS de WinINET en Windows o de macOS. Las variables HTTP(S) heredadas omiten esa detección; en macOS también lo hacen `ALL_PROXY`/`all_proxy`. Windows conserva por separado `http=` y `https=`; un `ProxyServer` sin prefijo se aplica a ambos. macOS convierte las IP literales, `*` y el patrón válido `*.<domain>` en la exclusión `.<domain>` de Bun. Este patrón también excluye el dominio raíz `<domain>`. Los rangos de enlace local exactos `169.254/16`, `169.254.0.0/16` y `fe80::/10` se omiten con un diagnóstico: sus IP literales usan el proxy. Otros CIDR, patrones y excepciones de host simple hacen que se rechace la detección sin alterar el entorno del proxy. No se siguen configuraciones desactivadas o mal formadas, PAC/WPAD, configuraciones que solo usan SOCKS ni cambios en vivo. Reinicie después de cambiar los ajustes del sistema. |
+| `noProxy?` | `string \| string[]` | — | Hosts que omiten `proxy`; se combinan con las entradas heredadas de `NO_PROXY` y las de loopback. La cadena admite la sintaxis de `NO_PROXY` separada por comas o `${ENV_VAR}`. |
+| `emptyCompletionRetry?` | `boolean` | `false` | Activa un único reintento idéntico de Responses cuando el turno no contiene texto ni llamadas a herramientas. Incluye flujos que terminan antes del evento final y fallos `MALFORMED_FUNCTION_CALL` de Vertex AI anteriores a cualquier salida. El reintento puede generar un cobro. `OCX_EMPTY_COMPLETION_RETRY=0` lo desactiva sin modificar la configuración. Los turnos Combo y de compactación enrutada quedan excluidos. |
+| `dropCodexSafetyBuffering?` | `boolean` | `false` | Elimine las sugerencias opcionales orientadas al cliente de los campos canónicos Codex Responses passthrough: los dos encabezados de respuesta `x-codex-safety-buffering-enabled` / `x-codex-safety-buffering-faster-model`, los eventos `response.metadata` cuyo tipo de metadatos es `safety_buffering` y los campos `safety_buffering` de nivel superior. Se conservan otros encabezados, datos de respuesta, rechazos de políticas y fallos. Esto no inhabilita la aplicación de la seguridad del proveedor o el almacenamiento en búfer aguas arriba. Los metadatos nativos `codex.response.metadata.headers` WebSocket y `/responses/compact` están fuera de este filtro. |
+| `stallTimeoutSec?` | `number` | `300` (público) / desactivado (local) | Segundos sin progreso significativo del proveedor (Responses y Chat nativo) antes de cortar el flujo. Si no se configura, un proveedor **local** (loopback, dirección privada o nombre `.local`/`.lan`) no tiene este límite; uno público tiene 300 s. Un valor positivo se aplica a ambos (mínimo 1 s); `0` desactiva el supervisor de inactividad en todos los casos. Así, un modelo local que sigue conectado puede permanecer en silencio mientras envía señales de mantenimiento. Las Responses canónicas de ChatGPT que se convierten de SSE a JSON sin streaming conservan un límite total independiente de 15 minutos. Las lecturas pendientes del cuerpo de `/v1/responses/compact` comparten este presupuesto, pero su valor predeterminado es 300 s incluso con un proveedor local, porque la ruta almacena el cuerpo completo mientras conserva una reserva de turno activo. Un valor explícito, incluido `0`, tiene prioridad. |
+| `oauthOpenBrowser?` | `boolean` | `true` | Permite abrir el navegador en la máquina que ejecuta el proxy al iniciar sesión. Omitir el campo o usar `true` conserva esa apertura; solo `false` la desactiva. Es útil si necesita otro perfil de navegador o si el panel está en otra máquina: el inicio de sesión comienza igualmente y se devuelve y muestra la URL. `POST /api/oauth/login` y `POST /api/codex-auth/login` admiten un booleano `openBrowser` por solicitud que tiene prioridad sobre este ajuste; el panel ofrece la misma opción junto al botón de inicio de sesión. Ambas rutas informan `browserLaunch`: `started`, `failed` (el panel indica que no se pudo abrir) o `skipped`. Los flujos con código de dispositivo nunca abren el navegador. |
+| `connectTimeoutMs?` | `number` | `200000` (público) / desactivado (local) | Plazo por intento desde el envío hasta el primer encabezado del proveedor, incluidos DNS, TCP, TLS y la espera de encabezados. Termina antes del cuerpo y es independiente de `stallTimeoutSec`. Sin configurar, un destino local (loopback, privado o nombre `.local`/`.lan`) no tiene plazo y uno público usa 200 s. Un valor positivo se aplica a ambos; `0` o un valor no positivo desactiva el plazo en todos. Así un modelo local puede dedicar minutos al prefill sin interrumpir un turno sano. |
+| `shutdownTimeoutMs?` | `number` | `5000` | Plazo para finalizar los turnos de forma ordenada antes de abortar los que sigan activos. |
+| `websockets?` | `boolean` | `false` | Anuncie y admita la ruta Responses WebSocket orientada al cliente. False mantiene a los clientes en HTTP / SSE; no desactiva una optimización WS canónica elegible de ChatGPT. Las solicitudes de entrada completa pueden reutilizar una conexión ascendente dentro de la misma credencial, cuenta, subproceso y turno seleccionados; la política de enlace cambiada o la identidad faltante mantienen las solicitudes en conexiones separadas. Esto no recorta la entrada HTTP ni crea ID de respuesta anterior. |
+| `codexNativeSteering?` | `boolean` | `false` | Control experimental durante un turno nativo en el endpoint Responses WebSocket. Requiere `websockets: true`, proveedor y cliente compatibles, y una cuenta, modelo y conjunto de herramientas fijos. Los parámetros de generación validados pueden cambiar en continuaciones explícitas de resultados guardados. No habilita modelos traducidos ni una alternativa por HTTP. Véase [Control nativo](/es/guides/codex-integration/#experimental-native-mid-turn-steering). |
+| `codexNativeInjection?` | `boolean` | `false` | Inyección experimental de resultados de funciones guardados en turnos multiagente WebSocket nativos compatibles. Requiere `websockets: true`, `multi_agent.enabled` explícito y un proveedor apto. Es independiente del control durante el turno; no vuelve a ejecutar herramientas ni crea una recuperación automática. Véase [Inyección nativa](/es/guides/codex-integration/#experimental-native-function-result-injection). |
+| `nativeReasoningRetention?` | `{ modelSwitch?: boolean; accountSwitch?: boolean }` | ambos `false` | Permite reenviar el razonamiento cifrado al cambiar de un modelo o una cuenta conocidos dentro del mismo backend canónico de ChatGPT. La retención entre cuentas es experimental. Consulta [Retención del razonamiento nativo](#native-reasoning-retention). |
+| `workflowBudget?` | `{ maxConcurrentChildren?: number; maxPhysicalSends?: number; maxDistinctChildren?: number }` | `8` / `256` / `64` | Límites por tarea: turnos simultáneos, envíos al proveedor por ventana de 10 minutos y subagentes distintos por ventana. Los campos omitidos conservan su valor integrado. Consulta [Límites del flujo de trabajo](#workflow-limits). |
+| `corsAllowOrigins?` | `string[]` | `[]` | Orígenes exactos adicionales permitidos por CORS. Los orígenes de Loopback siempre están permitidos. Se admiten orígenes de extensión de navegador basados en autoridad como `chrome-extension://<extension-id>`; `*` no es un comodín. Firefox y Safari regeneran la extensión UUID (por instalación / por lanzamiento del navegador), así que actualice la entrada cuando cambie el origen. |
+| `dashboardTrustedProxy?` | `{ origin: string; proxyAddresses: string[]; trustHeaders?: ("x-forwarded-host" \| "x-forwarded-proto")[] }` | sin definir | Solo instancia independiente, con activación explícita: permite **Recordar este dispositivo** tras un proxy inverso que termina TLS. `origin` debe ser un origen `https://` exacto y `proxyAddresses` sus IP exactas, sin rangos ni comodines. `trustHeaders` lee el host de `X-Forwarded-Host` o exige `X-Forwarded-Proto: https`; por defecto solo `Host`. Se ignora en loopback y Hub. Consulta [recordar tras un proxy inverso](/es/guides/web-dashboard/#remember-behind-a-reverse-proxy). |
+| `apiKeys?` | `OcxApiKey[]` | `[]` | Credenciales generadas `ocx_…` para admitir tráfico de datos fuera de loopback. Se administran desde el panel y no autorizan las API de administración; estas utilizan la credencial independiente indicada en la [referencia de administración](/es/reference/management-api/). |
+| `storageCleanupPolicy?` | `StorageCleanupPolicy` | desactivada | Política de limpieza de sesiones archivadas que requiere activación explícita. Nunca se habilita implícitamente. |
+| `usageLedgerMaxBytes?` | `number` | Sin configurar | Techo opt-in en bytes para `usage.jsonl`. Ausente significa que el historial de solicitudes crece sin límite, lo que se mantiene como predeterminado. Véase [tamaño del historial de uso](#usage-history-size). |
+| `appOwnedMemoryBudgetMb?` | `number` | `256` | Límite en MiB para registros, cachés, blobs y cargas de continuación propios de la aplicación que se pueden desalojar. Rango 64–4096; no limita el RSS del proceso. |
+| `metricsExport.enabled?` | `boolean` | `false` | Habilite las métricas de solicitud agregada local de proceso en `GET /api/metrics` autenticado. Se requiere reiniciar; el modo desactivado devuelve 404 y no inicia ninguna actividad de exportador. |
+| `serviceHealthRecovery.enabled?` | `boolean` | `false` | Recuperación opt-in para el servicio en segundo plano: un pequeño proceso centinela sondea `/healthz` y, cuando el proxy permanece vivo pero no responde nada durante aproximadamente un minuto de sondas consecutivas, lo termina para que el administrador del servicio (Task Scheduler, launchd, systemd, WinSW) lo reinicie. Solo el hijo de servicio administrado inicia uno; las solicitudes del proceso bloqueado no se reproducen. Como máximo tres recuperaciones por hora. Reiniciar requerido. La recuperación automática requiere una dirección de enlace numérica (o la asignación localhost/wildcard predeterminada); Los nombres de enlace DNS no se supervisan. Una dirección grabada o puerto modificados detiene la supervisión. |
+| `spend?` | `{ root?: { maxTokens?: number }; identity?: { maxTokens?: number }; pool?: { maxTokens?: number }; retentionDays?: number }` | Sin configurar | Límites persistentes de tokens, desactivados hasta que se configura uno. Cada ámbito incluye el gasto liquidado, las reservas en curso y el gasto pendiente de resolver: `root` abarca una tarea y todas sus subtareas, `identity` una cuenta en todas las tareas que atiende y `pool` un grupo de proveedores. La solicitud solo se admite si hay capacidad en los tres ámbitos; crear un ID de tarea nuevo por solicitud no evita estos límites. Cada reserva incluye toda la entrada y el límite de salida exigible, suponiendo que no se aprovecha ningún prefijo en caché. El modo de solo observación también escribe en el registro; por eso cada servidor conserva la reserva de escritor único del directorio de estado, y otra instancia explícita debe usar su propio `OPENCODEX_HOME`. El gasto se conserva tras un reinicio normal si las escrituras llegaron al sistema de archivos, pero no se garantiza que sobreviva a un corte eléctrico porque cada anexión no se sincroniza físicamente. Subir o eliminar un límite solo modifica la capacidad de las solicitudes iniciadas después; las que ya están en curso mantienen su política inicial. `maxTokens` debe ser un entero positivo (0 rechazaría todo); `retentionDays` admite 1–365 y usa 7 de forma predeterminada. Las claves desconocidas se rechazan. El rechazo local devuelve HTTP 429 con `x-opencodex-local-refusal: workflow_spend_exhausted` e identifica el ámbito y el límite; no se contacta al proveedor. Con un límite aplicable también se rechaza el envío si no puede registrarse su reserva, incluso cuando se agotó la capacidad de seguimiento. Sin un límite aplicable se mantiene el modo de solo observación. |
+| `codexAutoStart?` | `boolean` | `true` | Permite que el shim de Codex ejecute `ocx ensure` antes de iniciar Codex. Con `false`, ensure no realiza ninguna acción. |
+| `codexShimAutoRestore?` | `boolean` | `true` | Restaura el shim instalado cuando una actualización externa de Codex lo reemplaza al completarse. Se puede desactivar mediante `OPENCODEX_CODEX_SHIM_AUTO_RESTORE=0`. |
+| `codexDesktopAuthless?` | `boolean` | `false` | Enrutamiento de Codex Desktop sin inicio de sesión, con activación explícita y solo en loopback: inyecta el proveedor dedicado `opencodex` con `requires_openai_auth = false`. Se ignora fuera de loopback. `ocx system settings --desktop-authless on`. Véase [Integración con Codex](/es/guides/codex-integration/#authless-codex-desktop-opt-in). |
+| `codexAccountPickerEnabled?` | `boolean` | Sin configurar | Controla si se anuncian las filas generadas del catálogo con cuenta específica (`<selector>/<model>`). Al habilitarlo, completa un `codexAccountNamespaces` ausente o vacío con los selectores predeterminados; `false` oculta esas filas sin eliminar los enlaces exactos de enrutamiento. Si se omite, un mapa de selectores manual no vacío sigue activo. La fila Luna Reserve también requiere una cuenta específica: solo se escribe cuando un selector apunta a la cuenta principal de Codex. Si se omite, la sincronización registra el motivo y la acción necesaria para recuperarla. |
+| `codexAccountNamespaces?` | `Record<string, string>` | Sin configurar | Mapa de selectores públicos a cuentas de Codex. El inicio de sesión principal usa el marcador de configuración `@main`; las cuentas añadidas usan su ID. Normalmente se genera al habilitar `codexAccountPickerEnabled`. Un mapa vacío significa que no hay filas con cuenta específica, incluida Luna Reserve. |
+| `codexClientCompaction?` | `boolean` | `false` | Activa explícitamente la compactación del cliente Codex en loopback autenticado. Usa el proveedor dedicado `opencodex` con `requires_openai_auth = true`, evitando que las nuevas compactaciones enrutadas almacenen estado `ocx1:` de OpenCodeX. Si también está habilitado, `codexDesktopAuthless` tiene prioridad y conserva `requires_openai_auth = false`. El enrutamiento V2 de subagentes no cambia. `ocx system settings --client-compaction on`. Véase [Integración con Codex](/es/guides/codex-integration/#client-side-compaction-opt-in). |
+| `codexProviderDisplayName?` | `string` | `"OpenCodex Proxy"` | Nombre visible del proveedor `opencodex` inyectado en Codex, escrito en el campo `name` de `config.toml` y del perfil de referencia. Solo cambia la presentación: el enrutamiento utiliza el ID `opencodex`, por lo que renombrarlo no mueve `model_provider = "opencodex"` ni la cabecera `[model_providers.opencodex]`, y conserva los hilos asociados a ese ID. Codex exige un nombre; use una etiqueta neutra si lo prefiere. Un valor vacío, de más de 128 caracteres o con caracteres de control se ignora y se sustituye por el predeterminado. |
+| `codexMainAccountHardLock?` | `boolean` | `true` | Bloquea nuevas solicitudes que coincidan con la identidad de la cuenta principal cuando se alcance el umbral de su ventana. Solo `false` explícito lo desactiva. Véase [Protección de la cuenta principal](/es/reference/cli/providers-accounts/#main-account-quota-protection). |
+| `codexMainAccountHardLockThresholds?` | `{ short?: number; long?: number }` | `{ short: 90, long: 98 }` | Umbrales independientes para las ventanas de 5 h y semanal/mensual. Enteros entre 80 y 100, con `short <= long`. Los valores persistidos no válidos vuelven a los predeterminados; la API rechaza las escrituras inválidas antes de modificar la configuración. |
+| `codexMainAccountHardLockFallback?` | `{ enabled?: boolean; model?: string; reasoningEffort?: string }` | desactivado | Mientras el bloqueo esté activo y ninguna cuenta de Codex pueda atender la solicitud, redirige las solicitudes de modelos nativos de Codex a `model` con `reasoningEffort`. `enabled: false` pausa la alternativa y conserva el modelo. Sin la sección o el modelo se mantiene el rechazo; una cuenta Pool utilizable sigue teniendo prioridad. `reasoningEffort` debe ser un esfuerzo declarado. Una sección persistida no válida desactiva la alternativa y la API rechaza escrituras inválidas antes de modificar el estado. Véase [Protección de la cuenta principal](/es/reference/cli/providers-accounts/#main-account-quota-protection). |
+| `nativeMainRefresh?` | `"codex" \| "opencodex"` | automático | Determina quién renueva el inicio de sesión nativo principal de ChatGPT en `CODEX_HOME`. `"codex"` consulta el binario de Codex mediante app-server `getAuthStatus` (Codex 0.130.0 o posterior, localizado con la misma resolución que `ocx sync`, incluido el paquete de ChatGPT) y nunca escribe `auth.json`; también funciona con credenciales guardadas en el llavero del sistema. Si falta el archivo, las solicitudes nativas Pool y Direct guardadas consultan el inicio de sesión actual de Codex, también tras reiniciar; los cierres de sesión y cambios de cuenta se aplican en la siguiente consulta. Cada respuesta del llavero es autoritativa para esa consulta: un token ausente o retenido deja esa materialización no disponible y una respuesta posterior puede reutilizar incluso el mismo bearer. No se conserva un rechazo permanente; las solicitudes que ya tienen un token pueden terminar sin volver a comprobarlo al enviar. Las credenciales en archivo no cambian. Un cambio de cuenta verificado elimina las restricciones de cuota de la anterior antes de seleccionar; en la primera consulta tras reiniciar, un registro de cuota válido debe identificar otra cuenta para eliminarlas. La misma cuenta conserva sus restricciones y las pausas manuales no cambian. Las consultas de cuota de las tarjetas, la preparación inicial del Pool y la recuperación inactiva de cuota principal también usan ese inicio de sesión; la recuperación pasiva conserva la cuarentena de reautenticación por tráfico. `"opencodex"` conserva el escritor protegido de `auth.json` de OpenCodex. Si se omite y hay un binario compatible, elige `"codex"`; sin él, tanto la omisión como `"codex"` recurren al escritor protegido. `ocx doctor` muestra el modo activo. |
+| `resetCreditAutoRedeem?` | `{ enabled?: boolean; leadTimeMinutes?: number }` | desactivado | Activación explícita: canjear el crédito de restablecimiento más pronto de la cuenta principal Codex `leadTimeMinutes` (1–60, por defecto 10) antes de que expire. Cada intento vuelve a leer la lista de crédito ascendente primero y se salta cuando el crédito se ha ido (por ejemplo, canjeado a mano); `redeem_request_id` Es journalizado en `$OPENCODEX_HOME/reset-credit-auto-redeem.json` antes de la llamada, por lo que un bloqueo reproduce la misma solicitud idempotente en lugar de gastar un segundo crédito. Los servidores que comparten este directorio de configuración coordinan las reservas y liquidaciones para que un proceso no reemplace el registro de solicitud de otro. Los registros solo llevan una clave de cuenta hash. |
+| `syncResumeHistory?` | `boolean` | `true` | Compatibilidad reversible con el historial de Codex App. Los metadatos originales se respaldan y se restauran mediante `ocx stop` / `ocx restore`. |
+| `spendPoolAliases?` | `Record<string, string>` | Sin configurar | Mapa explícito de alias históricos de grupos, calculados con sal, a proveedores canónicos. Mantenga esta clave en el nivel superior, fuera de `spend`. Véase [Continuidad histórica de los grupos](#historical-pool-continuity). |
+| `shadowCallIntercept?` | `{ enabled?: boolean; model?: string; sourceModels?: string[] }` | desactivado | Redirige llamadas auxiliares reconocidas de Codex al modelo elegido, conservando su esfuerzo de razonamiento. Los prefijos predeterminados son `gpt-6-luna` y `gpt-5.6-luna`. El panel ofrece un interruptor por origen; las generaciones Terra (`gpt-6.1-terra` y `gpt-5.6-terra`) y el antiguo `gpt-5.4-mini` permanecen desactivados hasta seleccionarlos. Debe quedar al menos un origen activo; desactiva el interruptor principal para detener todas las llamadas de sombra. |
+| `memoryModels?` | `{ extract?: { model: string; reasoningEffort?: string }; consolidation?: { model: string; reasoningEffort?: string } }` | desactivado | Enruta las dos fases de memoria de Codex a un modelo elegido, con un esfuerzo de razonamiento opcional por fase. Véase [Enrutamiento de memoria](#memory-routing). |
+| `webSearchSidecar?` | `OcxWebSearchSidecarConfig` | activado si está disponible | Opciones del asistente de búsqueda web. |
+| `visionSidecar?` | `OcxVisionSidecarConfig` | activado si está disponible | Opciones del asistente de descripción de imágenes. |
+| `images?` | `OcxImagesConfig` | selección automática de OpenAI | Opciones del relay independiente de imágenes para `image_gen` de Codex. |
+| `telemetry?` | `OcxTelemetryConfig` | activa tras mostrar el aviso a una persona | Estado de consentimiento para estadísticas diarias anónimas: `decision`, `decidedAt`, `noticeShownAt`. No envía nada hasta que una persona vea el aviso o acepte. `OCX_TELEMETRY=0` y `DO_NOT_TRACK=1` prevalecen. Consulta [Telemetría](#telemetry-telemetry) y [privacidad](/es/guides/telemetry/). |
+
+En Linux x64/arm64 con soporte para pidfd, la recuperación del servicio vincula la terminación a la identidad del proceso del proxy en el kernel; la reutilización del PID no puede redirigirla. El mensaje de supervisión del centinela termina en `(pidfd)`. Los kernels o arquitecturas sin soporte conservan la comprobación existente del PID del proceso padre activo y registran esa alternativa. Otros fallos de vinculación desactivan la recuperación para ese proxy. macOS conserva la comprobación del proceso padre activo y Windows su vinculación al identificador de proceso.
+
+<a id="native-reasoning-retention"></a>
+
+## Retención del razonamiento nativo
+
+El resumen del panel ofrece dos opciones independientes: conservar el razonamiento al cambiar de modelo y conservarlo al cambiar de cuenta. Ambas están desactivadas de forma predeterminada. También puede guardar esta política en `config.json`:
+
+```jsonc
+{
+  "nativeReasoningRetention": {
+    "modelSwitch": true,
+    "accountSwitch": false
+  }
+}
+```
+
+Este ejemplo conserva el razonamiento `encrypted_content` al cambiar a un modelo conocido dentro del mismo destino nativo de ChatGPT y con la misma credencial. Establezca `accountSwitch` en `true` solo si desea el reenvío experimental entre cuentas. Si cambian tanto el modelo como la cuenta, deben estar activadas ambas opciones. La política se aplica a cada destino nativo real de un Combo y a los reintentos del grupo; no habilita la retención para destinos de terceros ni para los que usan claves API.
+
+La retención permite que OpenCodex reenvíe el texto cifrado recibido; no confirma que el proveedor acepte o reutilice ese razonamiento. Un rechazo de descifrado detectado activa la recuperación existente con limpieza limitada, y ese rechazo tiene prioridad sobre ambas opciones. Las referencias de respuestas y conversaciones, los ID de razonamiento ajeno, las restricciones de cuenta de los archivos subidos y el aislamiento de la caché mantienen sus propias reglas de propiedad. Los bloques de compactación nativa conservan su limpieza habitual; el saneamiento nativo directo de `/v1/responses/compact` no cambia.
+
+Utilice `GET /api/native-reasoning-retention` para leer los booleanos efectivos y `PUT` con un objeto booleano parcial para modificarlos. `PUT` con JSON `null` restaura ambos valores predeterminados. Los campos no válidos y las claves desconocidas se rechazan; un bloque mal formado en el archivo desactiva la retención y genera una advertencia. Los cambios desde el panel o la API se aplican a las solicitudes posteriores. Los cambios locales con `ocx config set/unset` requieren reiniciar el proxy.
+
+<a id="workflow-limits"></a>
+
+## Límites del flujo de trabajo
+
+OpenCodex limita cuánto puede expandirse una tarea. Cada tarea incluye la conversación raíz, identificada por el encabezado del cliente `x-codex-parent-thread-id`, y todos los subagentes que crea. Se aplican tres límites de cantidad. Las solicitudes que superan alguno se rechazan localmente con HTTP 429 y un encabezado `x-opencodex-local-refusal` que identifica el límite (`workflow_concurrency_exhausted`, `workflow_sends_exhausted` o `workflow_children_exhausted`); no se contacta con ningún proveedor.
+
+| Campo | Predeterminado | Permitido | Significado |
+| --- | --- | --- | --- |
+| `maxConcurrentChildren` | `8` | 2–64 | Turnos simultáneos de una tarea. Siempre se reserva un espacio para la conversación raíz, por lo que los subagentes disponen de uno menos. |
+| `maxPhysicalSends` | `256` | 1–10000 | Admisiones de envíos al proveedor, incluidos reintentos, por ventana de diez minutos. Cada admisión comprueba y reserva una plaza atómicamente; solicitudes y reintentos comparten techo. Un permiso no usado no gasta plaza; un inicio físico confirmado sigue contando aunque falle. |
+| `maxDistinctChildren` | `64` | 1–1024 | Hilos de subagentes distintos que una tarea puede iniciar durante esa misma ventana. |
+
+Los valores predeterminados sirven para la mayoría de las instalaciones. Súbelos si un flujo que necesita muchos subagentes alcanza los límites repetidamente; bájalos para frenar antes una expansión descontrolada:
+
+```jsonc
+{
+  "workflowBudget": {
+    "maxConcurrentChildren": 16,
+    "maxPhysicalSends": 1024
+  }
+}
+```
+
+La página **Subagentes** del dashboard muestra los límites efectivos y permite editarlos. `GET /api/workflow-budget/settings` devuelve sus valores efectivos, predeterminados y rangos permitidos. Un `PUT` parcial actualiza los campos indicados y JSON `null` restablece los predeterminados. Los cambios del dashboard o la API se aplican a la siguiente solicitud sin reiniciar y nunca restablecen el consumo acumulado de una tarea; para perdonar ese consumo se mantiene `POST /api/workflow-budget/clear`. Un bloque mal formado en el archivo se ignora con una advertencia y conserva los límites integrados. Los cambios locales mediante `ocx config set/unset` requieren reiniciar el proxy. La ventana de 10 minutos, el espacio reservado para la conversación interactiva y el máximo de 512 tareas registradas no son configurables.
+
+<a id="upstream-transport-recovery"></a>
+
+## Recuperación de transporte ascendente
+
+Mientras que el canónico ChatGPT upstream WebSocket espera el primer evento Responses después de enviar el marco de creación, observa la vitalidad en lugar de una fecha límite fija. Cuando el socket admite pings de protocolo, el proxy lo hace cada 15 segundos. Cualquier trama entrante (cuota, metadatos de respuesta o un pong) restablece un reloj de silencio de 90 segundos, por lo que un socket sin soporte de ping aún permanece activo en sus propias tramas, y solo 90 segundos sin nada en absoluto establece la solicitud como un HTTP 504 con un error `upstream_no_response`. Por lo tanto, un origen lento pero vivo espera la fecha límite del cliente o la `connectTimeoutMs` (200 s por defecto para destinos públicos, desactivado para locales salvo configuración explícita), lo que ocurra primero; un tiempo de espera de conexión que se dispara después de que se envió el marco de creación se establece como el mismo 504. Un zócalo que se cierra o comete errores antes del primer evento Responses se establece como un HTTP 502 con `upstream_closed_before_response`. El proxy no vuelve a intentar ninguno de los estados por sí mismo: la trama ya puede estar ejecutándose aguas arriba, por lo que el cliente aplica su propia política de reintento exactamente como lo haría cuando se conecta directamente al backend. La única excepción es que 502 en un proveedor que optó por `retryOnReset`, se describe a continuación. Una vez que la respuesta ha comenzado, una gota más tarde las superficies dentro de la corriente como antes. `stallTimeoutSec` no está relacionado con esta ventana.
+
+Un envío ordinario HTTP tiene un tercer caso. Cuando la conexión muere antes de que llegue cualquier cabecera de respuesta, el proxy no puede decir si el modelo ya procesó la solicitud, por lo que se niega a enviarla de nuevo y responde HTTP 429 con `upstream_reset_replay_refused`. El estado es deliberado: un 5xx aquí es una instrucción para la mayoría de los clientes, incluido el Codex, para enviar todo el turno de nuevo, que es el duplicado que existe la negativa a evitar. No `Retry-After` se adjunta, y la respuesta lleva `x-should-retry: false`, que los oficiales OpenAI y Anthropic SDK leen antes de sus propias reglas de estado - sin él, esos clientes vuelven a intentar un 429 en su propio horario y vuelven a enviar el turno de todos modos. El mismo comportamiento de rechazo de reproducción se aplica en `/v1/responses` y `/v1/chat/completions`, ya sea que la solicitud se reenvíe de forma nativa o se traduzca. Las solicitudes `/v1/messages` enrutadas se traducen a través de Responses y proyectan el mismo estado, código y encabezados de reintento en una envolvente de error en forma de Anthropic. El proxy no realiza rotación de claves, conmutación por error de cuenta o repetición del mismo objetivo en él, ni registra el rechazo como evidencia de límite de tasa o cuota contra la credencial que tenía. Las solicitudes del lado de la herramienta de llamada, como la visión y la búsqueda web, se reproducen normalmente, porque repetirlas no puede duplicar un turno.
+
+Las solicitudes nativas ChatGPT Responses y compactas HTTP cuyas cadenas serializadas JSON son de al menos 1 MiB en UTF-8 usan cargas de byte-búfer para evitar que Bun restablezca una carga de cadena grande antes de que lleguen los encabezados de respuesta. Esto conserva el contenido de la solicitud y no permite reintentos automáticos. Un restablecimiento de conexión genuino sigue la política de rechazo de reproducción anterior.
+
+Un proveedor nativo Responses puede optar por reemplazar ese envío con [`retryOnReset`](/es/reference/configuration/providers/#provider-entries-ocxproviderconfig). La misma concesión cubre el caso en el que la conexión sobrevive a la cabecera y el cuerpo SSE muere entonces llevando solo eventos de control, porque el llamante no ha observado nada en ninguno de los dos. También cubre el canónico ChatGPT WebSocket anterior: un socket que se cierra o errores antes del primer evento Responses se sustituye por un HTTP enviar, nunca por un segundo socket. Un enchufe silencioso mantiene su 504, y nunca se reemplaza un giro de dirección o inyección nativo. Un reemplazo ocurre solo cuando la solicitud es autónoma (`store: false`, entrada completa, herramientas ejecutadas por el cliente solamente, sin estado de continuación del lado del servidor), y una solicitud lógica obtiene el número configurado de reemplazos en total, en cada tramo de recuperación y cada hijo combinado, no uno cada uno. La denegación regresa tan pronto como se gaste esa subvención, la pierna no se envíe o un reemplazo falla por cualquier otra razón. Una solicitud que ya ha emitido una salida o una llamada de herramienta mantiene el rechazo independientemente. Una persona que llama y cancela a mitad del reemplazo obtiene la cancelación, no el rechazo.
+
+Para la recuperación de WebSocket, "antes del primer evento Responses" es más estricto que "antes del primer texto": incluso `response.created`, un evento de herramienta o una respuesta de soporte de uso cierra la ventana de reemplazo. Los metadatos de ping/pong y cuotas por sí solos no lo hacen. Un cierre posterior del zócalo no puede convertir una cancelación ya establecida o un tiempo de espera de conexión/silencio en un reintento de HTTP.
+
+`noProxy` acepta una cadena separada por comas o una matriz. Ambos formularios agregan entradas sin reemplazar un `NO_PROXY` heredado:
+
+```jsonc
+{ "proxy": "http://proxy.corp:8080", "noProxy": "internal.example,10.0.0.0/8" }
+```
+
+```jsonc
+{ "proxy": "http://proxy.corp:8080", "noProxy": ["internal.example", "10.0.0.0/8"] }
+```
+
+SOCKS5 (escuchadores de puertos mixtos incluidos) pertenece al `ALL_PROXY`, no al `HTTP_PROXY`:
+
+```jsonc
+{ "proxy": "socks5://127.0.0.1:10808" }
+```
+
+`ocx start --socks5` escribe ese valor; `ocx start --socks5-off` lo aclara.
+
+HTTPS solicitudes a través de SOCKS5 tienen una fecha límite separada de 30 segundos TLS apretón de manos. Un apretón de manos detenido falla sin deshabilitar la verificación del certificado; la cancelación de la llamada puede detenerlo antes.
+
+Si una compilación de desarrollo anterior cambió los metadatos del historial de reanudación antes de que existiera el soporte de copia de seguridad, ejecute `ocx recover-history --legacy-openai --yes` para forzar la recuperación del proveedor nativo. Forzar-reetiqueta cada fila de mensajes de usuario `opencodex`, incluido el historial legítimo de proveedores dedicados; revise la advertencia de alcance completo en la referencia del ciclo de vida antes de ejecutarla.
+
+<a id="native-chat-timeouts-and-completion"></a>
+
+### Tiempos de espera y finalización del chat nativo
+
+Native Chat también utiliza `stallTimeoutSec` mientras espera la salida de flujo ascendente, con el mismo valor predeterminado local vs público: un presupuesto no establecido está deshabilitado para un flujo ascendente local y 300 s para uno público, y `0` lo deshabilita en todas partes. El texto no vacío, el razonamiento, el rechazo, las actualizaciones de herramientas y los marcos de finalización renuevan la asignación; los comentarios de mantenimiento, los marcos de solo rol y el uso por sí solos no lo hacen. Esperar a que un cliente lento lea pausa la asignación. Una pérdida produce `upstream_stall_timeout`: una trama de error para clientes de transmisión en tiempo real, o HTTP 502 para clientes que no son de transmisión en tiempo real. La cancelación antes de un resultado de terminal devuelve un error de cancelación en lugar de una respuesta parcial exitosa. Los resultados de los búferes aceptan tanto el encuadre LF como CRLF SSE, incluidos los datos multilínea.
+
+<a id="codex-quota-network-diagnostics"></a>
+
+## Diagnósticos de red de cuota Codex
+
+La fila principal de la cuenta Codex puede incluir `quotaRefresh` cuando se intentó una búsqueda de cuota. Esto describe que fetch, no cuota restante, modelo de acceso o permiso para reintentar. Las lecturas en caché y las filas sin un fetch pueden omitirlo; la ausencia no significa éxito. Un valor de cuota de `null` significa no disponible, no cuota cero.
+
+Para solicitar datos nuevos y mostrar solo el diagnóstico en PowerShell:
+
+```powershell
+$quotaReport = ocx account list openai --quota --refresh --json | ConvertFrom-Json
+$quotaReport.accounts |
+    ForEach-Object { if ($_.quotaRefresh) { $_.quotaRefresh } } |
+    ConvertTo-Json -Depth 3
+```
+
+Si no hay diagnóstico presente, esta proyección no produce ningún objeto de diagnóstico. Comparta solo estos campos al comparar los modos de red, en lugar de la lista completa de cuentas.
+
+| `quotaRefresh.status` | Descripción |
+| --- | --- |
+| `ok` | Se completó la extracción y se analizó un objeto de cuota. |
+| `not_reported` | La respuesta no contenía ningún objeto de cuota utilizable. |
+| `http_error` | El flujo ascendente devolvió un fallo de HTTP; `httpStatus` contiene su código de estado. |
+| `timeout` | Se agotó el tiempo de espera de la cuota. |
+| `network_error` | La solicitud falló antes de una respuesta clasificada HTTP. |
+| `invalid_response` | La respuesta no fue un documento de cuota utilizable. |
+| `internal_error` | Un paso de actualización interno falló. |
+
+Sólo `http_error` incluye `httpStatus`. Otros estados no implican HTTP 0 o un problema de derecho de cuenta. Un `http_error` también puede incluir `code` cuando el proveedor nombra una razón por la que solo se corrige un nuevo inicio de sesión (`token_invalidated`, `invalid_refresh_token`, `invalid_workspace_selected`). Una respuesta `token_invalidated` indica una sesión revocada; la fila muestra `needsReauth: true` con el último plan conocido.
+
+Si el endpoint de tokens rechaza la autorización principal de renovación almacenada, las solicitudes automáticas dejan de reintentar esa misma autorización aunque una actualización de uso tenga éxito. Inicia sesión de nuevo con `codex login` para sustituir la credencial. El proceso conserva hasta 64 registros de rechazo asociados al perfil y a la autorización; reiniciar el proxy o expulsar un registro antiguo permite una comprobación nueva. Los límites de solicitudes y los fallos del servidor siguen siendo reintentables y no retiran esa autorización. Las credenciales proporcionadas por el cliente siguen siendo de su propiedad.
+
+
+<a id="which-proxy-path-is-used"></a>
+
+### ¿Qué ruta proxy se utiliza?
+
+El servicio proxy en ejecución obtiene la cuota. Utiliza su propio entorno, no el shell interactivo que más tarde se ejecuta `ocx account list`. Configure la configuración o el entorno proxy del servicio y, a continuación, reinicie el servicio; cambiar variables en otro terminal no actualiza un servicio que ya se esté ejecutando.
+
+Un `proxy` no establecido deja variables proxy heredadas sin cambios. Una URL proxy explícita HTTP (S) llena `HTTP_PROXY` y `HTTPS_PROXY` solo donde no están establecidos. `"proxy": "auto"` lee la configuración Windows estática de WinINET o macOS estática HTTP / HTTPS una vez en el inicio. Las variables de entorno proxy existentes tienen prioridad; macOS descubrimiento también se salta heredado `ALL_PROXY` / `all_proxy`. Una excepción macOS `*.<domain>` se convierte en `.<domain>`: `foo.local` deriva para `*.local`, `xlocal` no, y el ápice desnudo `local` también deriva. Los CIDR locales de enlace exacto se eliminan con una advertencia, por lo que los literales de IP locales de enlace usan el proxy. Otras excepciones no representables rechazan el descubrimiento sin cambiar las variables proxy. La detección automática no resuelve los ajustes de PAC/WPAD, SOCKS-only o los cambios de proxy en vivo. Utilice una configuración de proxy HTTP estática compatible o una URL de proxy HTTP (S) explícita cuando sea necesario.
+
+Compare el diagnóstico en la misma máquina y cuenta en los dos modos de red. Una prueba TUN exitosa por sí sola no identifica por qué falló la ruta proxy HTTP del servicio y no establece una corrección general.
+
+<a id="connection-reuse-for-specific-upstream-hosts"></a>
+
+## Reutilización de conexión para hosts de origen específicos
+
+Algunos upstreams mantienen una conexión abierta después de haber dejado de servirla. La siguiente solicitud reutiliza ese socket agrupado y falla sin llegar al proveedor. `OCX_FRESH_CONNECTION_HOSTS` nombra a los hosts que nunca deben reutilizar una conexión agrupada, como una variable de entorno en lugar de un campo de configuración, por lo que se puede aplicar a una máquina sin editar la configuración compartida:
+
+```bash
+OCX_FRESH_CONNECTION_HOSTS="api.example.com, relay.example.net" ocx start
+```
+
+El valor es una lista separada por comas de nombres de host. El emparejamiento es insensible a las mayúsculas, cubre cada host nombrado y sus subdominios, e ignora los puntos principales, por lo que `.example.com` y `example.com` coinciden ambos con `api.example.com`. No incluya un esquema, puerto o ruta. Una variable vacía o sin establecer deja el comportamiento de conexión predeterminado sin cambios.
+
+Un envío coincidente lleva `Connection: close` y se envía con keep-alive deshabilitado. La decisión se toma en contra de la dirección realmente utilizada en el cable, por lo que todavía se aplica cuando un proveedor de transporte reescribe el destino después de la selección de credenciales. La latencia por solicitud aumenta ligeramente para esos hosts, ya que cada solicitud paga un nuevo protocolo TCP y TLS; nombre solo los hosts que lo necesitan.
+
+<a id="remote-access"></a>
+
+## Acceso remoto
+
+La dirección predeterminada `127.0.0.1` solo escucha en loopback. Una dirección externa, como `0.0.0.0` o una IP de Tailscale, exige una credencial de datos para las solicitudes de modelos: una clave de cliente configurada en `config.apiKeys` o un token compartido de datos. Las rutas administrativas `/api/*` usan la credencial independiente `OPENCODEX_ADMIN_AUTH_TOKEN` o el token administrativo generado, también en loopback. Una credencial de datos no concede acceso administrativo; nunca entregues el token de administración a un cliente de modelos.
+
+Usted no tiene que producir ese token. `ocx service install` proporciona uno en un enlace no loopback, en este orden: `OPENCODEX_API_AUTH_TOKEN` desde el shell de instalación, luego un archivo existente de solo propietario `service-api-token`, luego 32 bytes aleatorios nuevos. El resultado se escribe `0600` y el envoltorio de lanzamiento (launchd plist, systemd unidad, Windows envoltorio) lee el archivo al inicio, por lo que el valor nunca entra en una definición de servicio o argv. Un primer plano `ocx start` aplica la misma precedencia - entorno, luego `OCX_API_TOKEN_FILE`, luego el `service-api-token` instalado - por lo que une un nombre de host non-loopback sin un token exportado también.
+
+Un **token de administración de administración** es rechazado en cualquier lugar que pueda aparecer - la variable de entorno o un archivo reutilizado `service-api-token` - y el mensaje nombra el remedio para ese lugar: desconfigurar la variable, o eliminar el archivo y ejecutar `ocx service repair`. Ambas comprobaciones se ejecutan antes del cortocircuito de bucle de retorno, porque el envoltorio de lanzamiento lee el archivo en `OPENCODEX_API_AUTH_TOKEN` sea cual sea el nombre de host, por lo que un archivo de token de administrador cerca la administración API cerrada incluso en un enlace de bucle de retorno. `ocx status` informa que el estado como `admin-collision (file)` en un concentrador.
+
+La configuración de la variable usted mismo todavía se admite para un operador que desee poseer el valor:
+
+```bash
+export OPENCODEX_API_AUTH_TOKEN="your-secret-token"
+ocx start
+```
+
+Los clientes deben enviar:
+
+```text
+x-opencodex-api-key: your-secret-token
+```
+
+| Punto final | `Authorization: Bearer` | `x-opencodex-api-key` | `x-api-key` |
+| --- | --- | --- | --- |
+| `/v1/responses` | aceptado | aceptado | no aceptado |
+| `/v1/chat/completions` | aceptado | aceptado | no aceptado |
+| `/v1/messages` | aceptado | aceptado | aceptado |
+| `/v1/messages/count_tokens` | aceptado | aceptado | aceptado |
+| `/v1/models` | aceptado | aceptado | aceptado |
+
+Responses y Chat Completions aceptan una credencial reconocida del plano de datos en `x-opencodex-api-key` o, si ese encabezado dedicado falta o queda vacío tras quitar los espacios, en `Authorization: Bearer`. Un encabezado dedicado no vacío tras quitar los espacios tiene prioridad aunque sea inválido: un bearer válido no corrige ese rechazo. Un bearer ajeno no concede admisión al proxy, y estas rutas no aceptan `x-api-key`. Las `apiKeys` generadas por el dashboard y el token compartido de datos se comparan en tiempo constante; las credenciales administrativas no conceden admisión a modelos.
+
+Messages y `count_tokens` siguen aceptando los tres formularios de admisión para la compatibilidad con el cliente encaminado. El passthrough nativo Anthropic es más estricto en un enlace no loopback: la admisión proxy debe usar `x-opencodex-api-key`, mientras que `Authorization` y `x-api-key` están reservados para las credenciales Anthropic. Cualquier secreto de admisión proxy colocado en esos encabezados de proveedor se elimina antes del reenvío.
+
+:::caution[Exposición a la LAN]
+A `0.0.0.0` bind expone el proxy y el acceso del proveedor configurado a la LAN. Utilícelo solo en el confiable redes con un fuerte token.
+:::
+
+<a id="local-clients-that-cannot-receive-the-token"></a>
+
+### Clientes locales que no pueden recibir el token
+
+Un enlace remoto requiere una credencial de cada persona que llama, incluidas las locales. Eso rompe un caso específico: un `codex app-server` lanzado por un proceso host que resuelve el punto de entrada Codex directamente (`require.resolve('@openai/codex/bin/codex.js')`) nunca pasa a través de la shim `codex` generada, por lo que nunca hereda `OPENCODEX_API_AUTH_TOKEN` y cada llamada de modelo falla con `401` antes de que se abra un flujo.
+
+`unauthenticatedLoopbackListener` abre un segundo oyente vinculado a `127.0.0.1` que admite sin una credencial. El oyente principal no ha sido tocado - las personas que llaman a distancia todavía necesitan el token.
+
+```json
+{
+  "hostname": "0.0.0.0",
+  "port": 10100,
+  "unauthenticatedLoopbackListener": { "enabled": true, "port": 10200 }
+}
+```
+
+`ocx sync` luego escribe `base_url = "http://127.0.0.1:10200/v1"` en el bloque de proveedor Codex administrado y omite el encabezado de autenticación, por lo que un servidor de aplicaciones generado directamente funciona sin ninguna fontanería de credenciales.
+
+Cuando establece `port`, debe diferir del puerto proxy. Nunca se asigna al sistema operativo: un puerto efímero cambiaría en los reinicios mientras que los servidores de aplicaciones que ya se ejecutan conservarían el anterior `base_url`.
+
+Omitir `port` selecciona la forma **compañero** - el oyente enlaza el puerto proxy en `127.0.0.1`:
+
+```json
+{
+  "hostname": "100.76.170.81",
+  "port": 10100,
+  "unauthenticatedLoopbackListener": { "enabled": true }
+}
+```
+
+Los clientes remotos marcan `100.76.170.81:10100` con una credencial; los procesos locales marcan `127.0.0.1:10100` sin una. Esa es la dirección que toda integración local ya escribe, por lo que `ocx claude`, Claude Desktop, Cursor y la inyección system-env siguen trabajando en un host cuyo enlace público no pueden alcanzar. El formulario complementario se acepta solo cuando `hostname` es una dirección específica no loopback, no comodín: en `127.0.0.1`, `localhost` o `0.0.0.0` el oyente público ya tiene esa dirección loopback, por lo que OpenCodex rechaza el par en el momento de la escritura y en el inicio en lugar de fallar el segundo enlace. En esos enlaces no necesita al oyente en absoluto: un enlace de bucle de retorno ya admite llamadas locales.
+
+Con un conjunto de `port`, las integraciones locales siguen al oyente: `ocx claude`, la inyección `system-env`, el perfil Claude Desktop, el valor de puerta de enlace Cursor y el asistente de visión enrutado todos escriben `http://127.0.0.1:<listener port>`, el mismo puerto `ocx sync` escribe en Codex. En la forma complementaria, esas mismas integraciones siguen escribiendo el puerto proxy, que es donde está el socket complementario.
+
+**Reinicie el proxy después de cambiar este campo, en cualquier forma.** Los sockets se unen una vez en el inicio y los valores de cliente exportados se escriben desde el puerto resuelto, por lo que un proxy en ejecución mantiene su respuesta anterior, en un oyente portado que es la diferencia entre una solicitud servida y un `404` del oyente.
+
+En un `runtimeRole: "hub"`, este campo también es la puerta de entrada para saber si el concentrador reescribe la configuración del cliente local **Su propio**. Con el oyente desactivado, `ocx sync`, `ocx ensure` y `ocx restore back` omiten las escrituras propias del concentrador Codex / Grok / Claude y lo dicen, nombrando `unauthenticatedLoopbackListener` en lugar del conmutador `clientIntegrations`.
+
+El oyente sólo sirve `POST /v1/responses`, su actualización WebSocket, `POST /v1/responses/compact`,
+`POST /v1/messages` (el cable Anthropic Claude Code y Claude Desktop hablar),
+`POST /v1/chat/completions` (el cable de chat OpenAI Cursor y el asistente de visión hablan),
+`POST /v1/alpha/search` (el relé de búsqueda web nativo Codex), `GET /v1/models`, y el tiempo real superficie de voz: las actualizaciones independientes WebSocket, creación de llamadas WebRTC (`POST /v1/live`,
+`POST /v1/realtime/calls`), y la banda lateral con teclas se unen a las actualizaciones (`/v1/live/{callId}`,
+`/v1/realtime/calls/{callId}`, `/v1/realtime?call_id=`) Todo lo demás, incluyendo `/api/*`,
+`/healthz`, `/readyz` y el dashboard, vuelve `404` — gestión local lee como
+`ocx claude`'s descubrimiento llamada ir a la superficie de gestión autenticada con una gestión Credencial, nunca aquí.
+
+:::danger[Esta interfaz no requiere autenticación]
+Cada proceso en la máquina puede usar este oyente. Gasta cuota de cuenta y proveedor pagado credenciales, y puede agotar la capacidad de giro compartida que dependen los clientes remotos autenticados encendido. No lo habilite en un host compartido o multi-tenant.
+
+Vinculación a `127.0.0.1` significa que el kernel rechaza conexiones remotas, pero no detiene un navegador: una página que visita puede hacer que su navegador se conecte a `127.0.0.1`. Por lo tanto, el oyente misma `Host` y `Origin` como un enlace de bucle de retorno ordinario. Desactivado por defecto.
+:::
+
+<a id="ssh-port-forwarding"></a>
+
+### Reenvío de puertos SSH
+
+El uso remoto no requiere un enlace remoto. Mantén el loopback y reenvíalo:
+
+```bash
+ssh -L 20100:localhost:10100 you@remote
+```
+
+Cualquier puerto local funciona. Las solicitudes cuyo host se resuelve en `localhost`, `127.0.0.1` o `::1` permanecen en bucle, independientemente del puerto, por lo que `http://localhost:20100/v1` funciona. Establecer la URL base en el cliente; `ocx` escribe solo la dirección local predeterminada `127.0.0.1` en la configuración del cliente administrado.
+
+Las devoluciones de llamada del proveedor OAuth escuchan en un puerto remoto fijo. Inicie sesión en la máquina remota o reenvíe ese puerto también:
+
+```bash
+ssh -L 20100:localhost:10100 -L 1455:localhost:1455 you@remote
+```
+
+Si un puerto de devolución de llamada registrado ya está en uso y la superficie de inicio de sesión ofrece entrada manual, OpenCodex mantiene el URI de redirección registrado y aún devuelve la URL de autorización del proveedor. Complete el inicio de sesión del proveedor, luego pegue la URL de redirección final desde la barra de direcciones del navegador o el código de autorización en OpenCodex. El flujo pendiente conserva el estado y la validación PKCE. Las llamadas sin entrada manual aún fallan.
+
+:::caution[El bucle local reenviado no requiere autenticación]
+Un `ssh -L` simple escucha en el bucle local y es seguro para el enlace no autenticado predeterminado. No use `ssh -g -L`, la publicación amplia de contenedores ni modos de reenvío que expongan el lado del cliente en
+`0.0.0.0`. En caso de duda, enlace explícitamente con `ssh -L 127.0.0.1:20100:localhost:10100`.
+:::
+
+<a id="account-email-masking-privacy"></a>
+
+## Enmascaramiento de correo electrónico de la cuenta (`privacy`)
+
+Los correos electrónicos de la cuenta almacenados están enmascarados en todas partes que dejan el proxy: las listas de cuentas del panel de control, `GET /api/codex-auth/accounts`, `GET /api/oauth/status` y la sección de inicios de sesión `ocx status` muestran `p***n@example.com` en lugar de la dirección registrada.
+
+| Campo | Tipo | Predeterminado | Descripción |
+| --- | --- | --- | --- |
+| `privacy.maskEmails?` | `boolean` | `true` | Solo `false` revela correos almacenados en los campos proyectados. Ausente, `true` o un valor inválido conserva la máscara. |
+
+Apáguelo cuando ejecute muchas cuentas en una máquina que controle y no pueda distinguirlas de los formularios enmascarados. Lea el indicador como una decisión de divulgación en lugar de una preferencia de visualización: la administración no siempre es loopback, por lo que en un concentrador configurado con `remoteGui`, una dirección desenmascarada llega a todos los principales de administración que pueden llegar al concentrador, no solo a alguien sentado en la máquina. La bandera mueve solo el campo de correo electrónico: los tokens, los tokens de actualización y los identificadores de cuenta permanecen redactados de cualquier manera.
+
+```json
+{ "privacy": { "maskEmails": false } }
+```
+
+`ocx config set privacy.maskEmails false` falla con `config parent path not found` hasta que el bloque existe, porque `config set` entra en los objetos existentes y nunca los crea. Escribe todo el objeto en su lugar - `ocx config set privacy '{"maskEmails":false}'` - o añadir el bloque a `config.json` a mano.
+
+<a id="telemetry-telemetry"></a>
+
+## Telemetría (`telemetry`)
+
+La telemetría diaria anónima solo se activa por defecto después de que una persona vea el aviso en el dashboard o la terminal. El bloque de `config.json` guarda el consentimiento:
+
+```json
+{
+  "telemetry": {
+    "decision": "accepted",
+    "decidedAt": "2026-11-07T09:00:00.000Z",
+    "noticeShownAt": "2026-11-07T09:00:00.000Z"
+  }
+}
+```
+
+| Campo | Tipo | Predeterminado | Significado |
+| --- | --- | --- | --- |
+| `telemetry.decision?` | `"accepted" \| "declined"` | sin definir | Elección explícita. `"declined"` desactiva y elimina `<OPENCODEX_HOME>/telemetry-id.json`; `"accepted"` permite informes diarios. |
+| `telemetry.decidedAt?` | `string` (ISO 8601) | sin definir | Momento UTC de la decisión. Solo se envían días completos posteriores al día de `decidedAt ?? noticeShownAt`: `day > formatUtcDay(decidedAt ?? noticeShownAt)`. No se recupera el día de consentimiento ni los anteriores. |
+| `telemetry.noticeShownAt?` | `string` (ISO 8601) | sin definir | Momento en que una persona vio el aviso. Sin `decision`, este campo permite `default-on`; sin él se mantiene `awaiting-notice`. |
+
+El endpoint `https://telemetry.opencodex.me/v1/events` es constante en el código y no configurable.
+
+Dos variables prevalecen sobre `config.json` sin modificarlo. Observar su desactivación al arrancar o en el planificador guarda `ineligibleThroughDay` con el día UTC en `<OPENCODEX_HOME>/telemetry-state.json` y elimina `<OPENCODEX_HOME>/telemetry-id.json`: esos días no se envían después, y una activación futura crea otro ID.
+
+- `OCX_TELEMETRY=0`, también `false`, `off` o `no`, sin distinguir mayúsculas.
+- `DO_NOT_TRACK=1`, también `true` o `yes`, sin distinguir mayúsculas.
+
+`ocx config set telemetry` y `ocx config unset telemetry` se rechazan para todos. `ocx config import` ignora ese bloque y conserva la decisión local. Usa `ocx telemetry enable`, con TTY humana interactiva, aviso y confirmación, o error `agent_consent_required` / `tty_required`; `ocx telemetry disable`; `ocx telemetry status [--json]`; o **Detalles del proxy**. Consulta el esquema y la conservación en [Telemetría y privacidad](/es/guides/telemetry/).
+
+<a id="storage-cleanup"></a>
+
+## Limpieza de almacenamiento
+
+`storageCleanupPolicy` está deshabilitado por defecto. Cuando está habilitado, se ejecuta en `startup`, `daily`, `weekly` o `manual` después de que los bytes archivados superan `trigger.archivedBytesOver`. Selecciona los archivos más antiguos hacia `target.reduceToBytes` o `target.removeOldestPercent`. `mode` por defecto es `quarantine`; use `permanent` solo como una opción destructiva explícita. La política persiste `lastRun` y `nextRun`. Configurelo en la página de almacenamiento o con `GET` / `PUT /api/storage/cleanup-policy`; inicie una ejecución manual con `POST /api/storage/cleanup-policy/run`.
+
+<a id="usage-history-size"></a>
+
+## Tamaño del historial de uso
+
+`usageLedgerMaxBytes` no se establece por defecto, y unset significa que el historial de solicitudes en `usage.jsonl` crece sin límite. Nada borra el historial que no pediste haber borrado.
+
+Configurar a un techo de bytes y el proxy recorta el archivo después de un apéndice cruza, manteniendo las filas enteras más nuevas y dejando caer la más antigua. Se recorta un poco por debajo del techo en lugar de exactamente a él, por lo que el siguiente apéndice no vuelve a cruzar inmediatamente la línea. El valor mínimo aceptado es 1 MiB; un número menor, o uno que no es un número entero seguro, deja el límite fuera en lugar de fallar la configuración.
+
+Las filas se copian byte por byte y nunca se reescriben, por lo que cada campo sobrevive a un ajuste, incluidos los campos de una compilación más reciente que escribió que uno más antiguo no entiende. El reemplazo se rechaza directamente si algo se agrega al libro mayor mientras se ejecuta, por lo que una solicitud registrada durante un ajuste nunca se pierde; el siguiente agregado se vuelve a intentar. Recortar también actualiza lo que muestra el panel de control, por lo que `/api/logs` deja de servir filas que el libro mayor ya no tiene.
+
+No hay control de tablero para esto todavía; configúrelo en `config.json` o con `ocx config set usageLedgerMaxBytes <bytes>`.
+
+<a id="catalog-auto-refresh-catalogautorefresh"></a>
+
+## Auto-actualización de catálogo (`catalogAutoRefresh`)
+
+Habilitado de forma predeterminada cuando OpenCodex administra su cliente local Codex: la sección o `enabled` pueden estar ausentes. El proxy actualiza su catálogo de modelos cada 60 minutos, con una actualización inicial unos tres minutos después del inicio. Cuando se desactiva la integración Codex, o la instancia se ejecuta como un concentrador o junto a otro proxy en vivo, la actualización de fondo se ejecuta solo con un `"enabled": true` explícito, y nunca lee Codex fuentes.
+
+```json
+{
+  "catalogAutoRefresh": { "enabled": true, "intervalMinutes": 60 }
+}
+```
+
+| Campo | Predeterminado | Descripción |
+| --- | --- | --- |
+| `enabled` | `true` | Ajuste a `false` para desactivar la actualización automática. |
+| `intervalMinutes` | `60` | Actualizar la cadencia; los valores positivos por debajo de 15 se fijan a 15. `0` desactiva la actualización. |
+
+Cada actualización observa el catálogo incluido del entorno de ejecución Codex seleccionado, luego calienta las listas de modelos Codex autenticadas antes de converger en la lista servida. Las fallas de origen utilizan la evidencia existente y vuelven a intentarlo en una marca posterior. Las ediciones de cadencia y habilitación tienen efecto en una marca posterior.
+
+Un modelo nativo de OpenAI que la lista de Codex de su cuenta ChatGPT enumera, pero que esta versión OpenCodex aún no conoce, se agrega con los metadatos que se publican para ella (nombre, niveles de razonamiento, ventana de contexto). OpenCodex recuerda tales modelos en `discovered-native-models.json` en su directorio de inicio y olvida uno que no se ha visto durante 14 días. Un lanzamiento posterior que envía el modelo se hace cargo de su fila.
+
+La ejecución de Codex sesiones conserva una lista de modelos en memoria. Cuando el conjunto servido cambia mientras se están ejecutando Codex servidores de aplicaciones, el proxy registra una sugerencia de reinicio y registra `reloadRequired` en su estado de actualización automática. Ejecute `ocx sync --restart-codex` cuando esté listo para reiniciar esas sesiones. La actualización automática nunca los reinicia.
+
+Cuando una actualización en segundo plano cambia el conjunto servido, OpenCodex también actualiza las integraciones de clientes que ya ha escrito: un bloque Grok Build existente, el perfil de puerta de enlace Claude Desktop que aplicó (solo mientras ese perfil aún está seleccionado y sin editar, manteniendo su modo estático, híbrido o de descubrimiento), y los bloques propios de integraciones de archivos como OpenCode, Kilo, Pi, omo y Aside. Nunca se conecta a un cliente por primera vez, nunca actualiza Cline (detenga Cline y ejecute `ocx sync` en su lugar) y se salta clientes locales en un concentrador sin el oyente de bucle invertido. Un cliente que no pudo actualizar se cuenta en el registro proxy; `ocx sync` lo vuelve a intentar.
+
+<a id="quota-reset-notifications-quotaresetnotify"></a>
+
+## Notificaciones de restablecimiento de cuotas (`quotaResetNotify`)
+
+Desactivado por defecto. Cuando la sección está ausente, no se ejecuta ninguna detección, no se inicia ningún temporizador y no se escribe ningún archivo de estado.
+
+Habilite que se le diga cuando se restablece una ventana de uso, tanto el rollover programado que puede predecir como un restablecimiento fuera de banda que no puede:
+
+```json
+{
+  "quotaResetNotify": {
+    "enabled": true,
+    "webhookUrl": "https://hooks.slack.com/services/...",
+    "kinds": ["scheduled", "surprise"],
+    "pollSeconds": 900
+  }
+}
+```
+
+| Campo | Predeterminado | Descripción |
+| --- | --- | --- |
+| `enabled` | `false` | Interruptor maestro. También requiere al menos un fregadero, abajo. |
+| `kinds` | ambos | `scheduled` (la fecha límite pasó) o `surprise` (cuota devuelta antes). |
+| `pollSeconds` | `900` | Intervalo de sondeo inactivo; piso 600. `0` solo observa tráfico en vivo. |
+| `webhookUrl` | — | `https` Objetivo POST para el evento JSON. tratado como un secreto. |
+| `allowPrivateNetwork` | `false` | Permitir un destino de bucle invertido o de red privada. |
+| `timeoutMs` | `5000` | Tiempo de espera de Webhook. |
+| `command` | — | Array Argv se ejecuta con el evento JSON en stdin. |
+
+`enabled: true` sin que `webhookUrl` ni `command` se resuelvan: un subsistema habilitado sin ningún lugar para entregar es una configuración incorrecta, no un estado medio encendido.
+
+El piso es de 600 segundos porque una encuesta más rápida no puede ver nada nuevo: la observación está limitada por la caché de 10 minutos por cuenta, por lo que un intervalo más corto solo agrega carga a un punto final de cuota que limita la tasa. Se adopta un valor configurado en la siguiente marca sin reiniciar.
+
+Establezca `pollSeconds` a `0` solo si acepta que se note un restablecimiento mientras el proxy está inactivo en la próxima solicitud en lugar de cuando suceda. La encuesta existe porque el caso de la noche a la mañana es el que vale la pena conocer.
+
+<a id="the-delivered-event"></a>
+
+### El evento entregado
+
+```json
+{
+  "type": "quota_reset",
+  "kind": "surprise",
+  "scope": "codex",
+  "accountTag": "k3f9x2ab",
+  "window": "weekly",
+  "percentBefore": 96,
+  "percentAfter": 4,
+  "previousResetAt": 1772000000000,
+  "resetAt": 1772400000000,
+  "detectedAt": 1771900000000
+}
+```
+
+`accountTag` es un hash salado por instalación, no un identificador de cuenta: distingue sus cuentas entre sí sin decirle al receptor quiénes son. No se incluye ningún correo electrónico, token, ruta o URL.
+
+`detectedAt` es cuando el proxy AVISO, no cuando el restablecimiento ocurrió. La observación está limitada por la caché del proveedor de 5 minutos y la caché de 10 minutos por cuenta, por lo que el instante de reinicio solo se puede entre corchetes entre dos observaciones.
+
+<a id="security-notes"></a>
+
+### Notas de seguridad
+
+`webhookUrl` es una credencial - para Slack y Discord, mantener la URL es suficiente para publicar - por lo que se redacta por `ocx config show` y se excluye de `ocx config export`.
+
+Un destino webhook que se resuelve a una dirección privada o loopback es rechazado a menos que establezca `allowPrivateNetwork: true`. El proxy puede llegar a los hosts que su navegador no puede, incluidos los puntos finales de metadatos en la nube, por lo que el valor predeterminado asume un receptor externo.
+
+`webhookUrl` debe utilizar `https`. La carga útil y la URL en sí son sensibles, y un objetivo `http` los pondría en texto claro; un valor `http` se rechaza cuando la configuración se escribe en lugar de degradarse en silencio.
+
+Se rechaza una redirección en lugar de seguirla. La verificación de destino anterior valida la URL que configuró, por lo que después de un `3xx` entregaría la carga útil en algún lugar no validado: un punto final público podría rebotar el POST en loopback o una dirección de metadatos. Configure directamente la URL final; un informe de entrega redirigido `blocked-destination`.
+
+`command` es una matriz argv y nunca se pasa a través de una carcasa, por lo que sus valores no pueden convertirse en una superficie de inyección de carcasa. La entrega se intenta una vez; no hay reintento.
+
+Lea las detecciones recientes con `ocx provider resets` o `GET /api/quota-resets`.
+
+<a id="api-surfaces-apisurfaces"></a>
+
+## API superficies (`apiSurfaces`)
+
+Responses (`/v1/responses`) y Chat Completions (`/v1/chat/completions`) siempre se sirven. El Messages API (`/v1/messages` y `/v1/messages/count_tokens`) se puede cerrar por sí solo.
+
+| Clave | Tipo | Predeterminado | Descripción |
+| --- | --- | --- | --- |
+| `apiSurfaces.messages.enabled?` | `boolean` | herede | `true` sirve el Messages API, `false` rechaza ambas rutas con 403. Unset hereda `claudeCode.enabled`, por lo que una integración Claude que está desactivada también cierra Messages. |
+
+Un valor presente pero mal formado (un no objeto `apiSurfaces` o `messages`, o un no booleano `enabled`) cierra el Messages API en lugar de volver al valor heredado. Ambas rutas siempre están de acuerdo.
+
+La página API del panel de control muestra una tarjeta por cada API con la fuente de la configuración (explícita, heredada de la configuración Claude o no válida) y una palanca para Messages. Desactivar Messages allí escribe `apiSurfaces.messages.enabled: false` **y** `claudeCode.enabled: false` en el mismo guardar, por lo que una versión proxy más antigua que este ajuste, que solo lee `claudeCode.enabled`, mantiene el punto final cerrado después de una degradación. Encenderlo escribe solo `apiSurfaces.messages.enabled: true`; una versión anterior sigue `claudeCode.enabled` y puede mantener Messages cerrado, que es la dirección segura.
+
+<a id="protocol-paths-protocols"></a>
+
+## Vías de protocolo (`protocols`)
+
+Cómo una solicitud Chat Completions o Messages puede comunicarse con un proveedor. Todos los valores predeterminados para el comportamiento antes de que existieran estas claves; consulte [Rutas de protocolo](/es/guides/protocol-paths/) para los modos de entrega, la vista previa y el seguimiento por solicitud.
+
+| Clave | Tipo | Predeterminado | Descripción |
+| --- | --- | --- | --- |
+| `protocols.unrepresentable?` | `"legacy" \| "reject"` | `"legacy"` | `legacy` envía una solicitud cuya ruta deja caer una característica y registra la pérdida en la traza. `reject` lo rechaza con HTTP 400 antes de cualquier envío, nombrando solo las claves de función. |
+| `protocols.rollout.nativeChatCombos?` | `boolean` | `false` | Enviar un candidato de chat elegible dentro de un combo de forma nativa desde su propia copia del cuerpo del cliente. |
+| `protocols.rollout.managedMessagesNative?` | `boolean` | `false` | Envía Messages nativo a un proveedor directo Anthropic apto o un hijo Anthropic compatible con clave o oficial en un combo failover estricto sin esfuerzo predeterminado. Las demás estrategias, políticas y reescrituras exclusivas del puente conservan el puente. |
+| `protocols.rollout.managedMessagesNativeOAuth?` | `boolean` | `false` | Nativo Messages para el proveedor `anthropic` OAuth en `api.anthropic.com`, incluyendo grupos de cuentas almacenadas. Requiere `managedMessagesNative`. Para el proveedor `anthropic` establecido, un grupo habilitado proporciona verdadero para banderas nativas ausentes cuando `anthropicAccountPool.nativeMessages` está ausente o verdadero. Los indicadores explícitos falsos/malformados y una preferencia de grupo falso/malformado permanecen desactivados. Otros proveedores y pool-off mantienen el comportamiento de despliegue explícito. Las solicitudes agrupadas elegibles retienen la selección compartida, la afinidad y la recuperación previa de salida limitada. Los UUID de cuenta JSON-string `metadata.user_id` reconocidos están alineados con la credencial OAuth de servicio; se conservan los campos de dispositivo y sesión. |
+| `protocols.rollout.directEncoders?` | `boolean` | `false` | Codifique el chat y las respuestas Messages de un flujo ascendente no Responses directamente de los eventos del adaptador. |
+| `protocols.rollout.antigravityDirect?` | `boolean` | `true` | Envíe una solicitud de chat o Messages a una sola ruta Google Antigravity sin el cuerpo interno Responses en cualquier dirección. La configuración de la solicitud aún pasa por las políticas habituales, y una solicitud que el carril no puede llevar usa el puente. Establecer `false` para apagarlo. |
+| `protocols.rollout.shadowPlan?` | `boolean` | `false` | Compare cada ruta de Chat o solicitud Messages con el plan que predice una vista previa y marque un desacuerdo como `planMismatch` en su fila de registro. No envía nada extra. |
+
+Los bloques de protocolo mal formados conservan una directiva nativa deshabilitada conservadora cuando se cargan desde el disco. Las banderas nativas ausentes válidas pueden heredar valores predeterminados de grupo Anthropic elegibles; las banderas falsas o malformadas explícitas permanecen desactivadas. Las escrituras validadas rechazan la entrada malformada.
+
+```json
+{
+  "protocols": {
+    "unrepresentable": "legacy",
+    "rollout": { "shadowPlan": true }
+  }
+}
+```
+
+`ocx api policy` muestra los valores resueltos y los cambia a través del proxy de ejecución (`--unrepresentable <legacy|reject>`, `--rollout <switch>=<on|off>`, `--messages <on|off>` para [`apiSurfaces`](#api-surfaces-apisurfaces)). Escribe solo cuando se da una bandera de ajuste. Las páginas API y `PATCH /api/protocols/settings` del panel de control utilizan la misma validación.
+
+## Claude Code (`claudeCode`)
+
+Esta configuración rige `/v1/messages`, `/v1/messages/count_tokens`, el lanzador `ocx claude` y la página del panel de control Claude. Si el Messages API se sirve en absoluto se decide por [`apiSurfaces`](#api-surfaces-apisurfaces), que hereda `claudeCode.enabled` mientras que unset.
+
+| Clave | Tipo | Predeterminado | Descripción |
+| --- | --- | --- | --- |
+| `claudeCode.bodyStallSec?` | `number` | `90` | El presupuesto de inactividad del cuerpo pasa a través de nativo en segundos mientras una lectura está pendiente, no la duración total. Mínimo 1; exactamente `0` desactiva. |
+| `claudeCode.bodyMaxBytes?` | `number` | `67108864` | Tapa corporal de paso natural acumulativa para respuestas transmitidas y tamponadas. Exactamente `0` se deshabilita. |
+| `claudeCode.compatibility?` | `"shadow" \| "enforce"` | Sin configurar | Admisión de compatibilidad opcional para solicitudes `/v1/messages` traducidas. `shadow` registra características no compatibles y continúa; `enforce` devuelve un 400 en forma de Anthropic antes de la inferencia. El paso a través de Native Anthropic permanece sin cambios. |
+| `claudeCode.authMode?` | `"proxy" \| "subscription"` | Automático | Cómo maneja el lanzamiento el `ANTHROPIC_AUTH_TOKEN`. Detecta automáticamente cada lanzamiento; nunca se anula un valor explícito. |
+| `claudeCode.authModeMigratedAt?` | `string` | Sin configurar | Marcador interno de actualización única. No lo configure manualmente. |
+| `claudeCode.classifierModel?` | `string` | Sin configurar | Objetivo explícito para los giros del clasificador de modo automático Claude Code, como `provider/model` calificado (por ejemplo `RelayA/claude-opus-5`). El modo automático envía controles de seguridad desnudos como el `claude-opus-5` sin proveedor, por lo que sin esto caen a través del `defaultProvider`, que puede no hablar Anthropic en absoluto. No se infiere nada automáticamente: solo se utiliza un objetivo que usted declara aquí. |
+| `claudeCode.classifierFallbacks?` | `string[]` | Sin configurar | Se utilizan los objetivos de clasificador ordenados cuando no se establece `classifierModel`. El mismo formulario clasificado `provider/model`; la primera entrada utilizable gana. Una entrada explícita `modelMap` para el modelo clasificador todavía supera a ambos. |
+| `claudeCode.desktopModelVisibility?` | `{ mode: "include" \| "exclude"; routes: string[] }` | Sin configurar | Rutas `provider/model` que figuran en la lista de la pasarela de Claude Desktop. `include` muestra solo `routes` y mantiene ocultos los modelos nuevos; `exclude` muestra todas salvo `routes` y añade los nuevos. Sin configurar, muestra todos los modelos disponibles. Si la selección no deja ninguno disponible, el escritor recurre a todos, incluidas las rutas normalmente ocultas; ajusta la selección para limitarla de nuevo. Solo afecta a las listas estáticas e híbridas de Claude Desktop; se configura desde **Conectar → Claude Desktop**. |
+| `claudeCode.subagentEffort?` | `"low" \| "medium" \| "high" \| "xhigh" \| "max"` | herede | Esfuerzo escrito a `~/.claude/agents/ocx-*.md` generado; separado de la guía de Codex y de los límites del proxy. Reiniciar a través de `ocx claude` para regenerar. |
+
+La política de compatibilidad se aplica a Claude Code, Desktop y otros clientes que utilizan Messages traducido, incluidas `?beta=true` y solicitudes que no son de transmisión. Todos los objetivos traducidos utilizan la misma política conservadora, incluidos los adaptadores Anthropic y Responses nativos. Rechaza el contenido del documento, la repetición de pensamiento/reflexión, las herramientas de búsqueda y ejecución alojadas, las referencias de búsqueda de herramientas, la carga diferida activa, las herramientas estrictas, los modos de llamada no predeterminados, los formatos de salida estructurada, la intención explícita del nivel de servicio, las características del conector MCP, la gestión de contexto, los contenedores, la colocación de inferencias y los campos o bloques de protocolo no compatibles.
+
+Unset conserva la traducción heredada. Las sugerencias de caché, los ejemplos de entrada de herramientas y la configuración de pensamiento/esfuerzo ordinario se admiten deliberadamente con una posible degradación: esta configuración no garantiza puntos de interrupción de caché o TTL, ejemplos retenidos, presupuestos de pensamiento exactos o traducción sin pérdidas. Los encabezados beta por sí solos no se validan para el soporte de características. La evidencia de sombra contiene solo códigos de protocolo fijos y razones derivadas, retenidos en los registros de solicitudes y `usage.jsonl` y restaurados al reiniciar. Un modo no válido no desactivado devuelve un error de configuración 503 fijo en la traducción Messages. Configure el valor en `config.json` y reinicie el proxy para cargarlo; no hay un setter de GUI dedicado. Los tokens de conteo y las APIs directas Responses /Chat están fuera de esta política; el conteo exitoso de tokens no implica la admisión Messages. Esta configuración no agrega un límite de autorización global.
+
+Auto auth selecciona la suscripción cuando se encuentra la autenticación Claude almacenada, proxy cuando no se encuentra ninguna y suscripción con una advertencia cuando la detección no es concluyente. Véase [Claude Code modo auth](/es/guides/claude-code/#auth-mode).
+
+<a id="retained-requests-after-compaction"></a>
+
+## Solicitudes retenidas después de la compactación
+
+Para los proveedores traducidos y las puertas de enlace Responses enrutadas, OpenCodex enmarca automáticamente las solicitudes de usuario de texto plano antes del último punto de control Codex legible como contexto histórico. Pide que no se repitan los informes de los puestos de control completados; el texto retenido sigue estando disponible para los trabajos pendientes dentro de su autorización vigente. La entrada posterior del usuario tiene prioridad, incluidas pausas, cancelaciones y cambios de alcance. Un punto de control no otorga ningún permiso nuevo.
+
+Esto está habilitado de forma predeterminada y no necesita configuración. Se conservan el texto original de la solicitud y el historial canónico de hilos/reproducción. El paso nativo OpenAI Responses, los giros de resumen, los envoltorios de contexto, las imágenes/archivos y los elementos de asistente/herramienta no se modifican. El encuadre se aplica a los puntos de control de texto sin formato que comienzan con el prefijo de resumen de Codex; los puntos de control decodificados de OpenCodex conservan su guía de continuación existente. El sintetizador del lado del cliente gira usando el indicador de compactación estándar de Codex también evita el encuadre. El encuadre es una instrucción rápida, por lo que el comportamiento del modelo puede variar.
+
+<a id="compaction-routing"></a>
+
+## Enrutamiento de compactación
+
+En **Tablero → Visión de conjunto → Enrutamiento de compactación**, elija un modelo, que activa que se aplica a, un esfuerzo de razonamiento opcional, y si la anulación cubre todos los modelos de origen o sólo fuentes seleccionadas. Para las fuentes seleccionadas, compruebe los modelos individuales o las entradas `provider/*` de todo el proveedor y, a continuación, haga clic en **Guardar**. Seleccione **Usar el modelo de conversación** y guarde para eliminar la anulación. Los cambios se aplican a la siguiente solicitud de compactación sin reiniciar el proxy.
+
+Establecer `compactionRouting` en OpenCodex `config.json` para anular las solicitudes de compactación del modelo Codex. La configuración está desactivada cuando se omite.
+
+```json
+{
+  "compactionRouting": {
+    "model": "provider/model-id",
+    "reasoningEffort": "low",
+    "triggers": ["manual"]
+  }
+}
+```
+
+`model` acepta ID de modelo nativo, ID de modelo calificado por proveedor y combos configurados. La opción `sourceModels` limita la anulación a los ID de modelo entrantes exactos o a los patrones `provider/*`, por ejemplo, `["kimi/*", "google-antigravity/*"]`. El emparejamiento es sensible a las mayúsculas. Omítelo por el comportamiento existente de todo modelo; las listas vacías, duplicadas o mal formadas no son válidas. El selector de alcance de fuente del panel de control puede editar la lista de permisos y conserva los selectores guardados ausentes del catálogo actual. La lista de verificación del modelo muestra como máximo 300 entradas coincidentes; use su campo de búsqueda para estrechar catálogos grandes sin eliminar las selecciones guardadas. También puede editarlo a través de `config.json` o `PUT /api/settings`. Esto comprueba el modelo de compactación entrante, no un modelo de conversación inferido. Si Codex envía un modelo de compactación nativo desnudo para un hilo enrutado, no coincide con esos patrones de proveedor y mantiene su ruta existente. Este comportamiento conservador protege GPT, pero puede dejar algunas compactaciones automáticas en la ruta nativa. Los turnos ordinarios de no compactación nunca cambian.
+
+`reasoningEffort` es opcional; omítelo para preservar el esfuerzo entrante. Las declaraciones admitidas son `none`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max` y `ultra`. Las reglas de esfuerzo del proveedor existentes aún se aplican. El punto final nativo `/responses/compact` mantiene su comportamiento existente y no reenvía los ajustes de razonamiento.
+
+`triggers` indica a qué solicitudes de compactación se aplica la anulación, usando los propios valores de `compaction.trigger` de Codex: `"manual"` para un `/compact` que usted escribió, `"auto"` para la compactación automática que Codex ejecuta cuando un hilo se acerca a su límite de contexto. Si omite `triggers`, la anulación se aplica solo al `/compact` manual, y la compactación automática sigue exactamente donde se enruta hoy. Use `["auto"]` o `["manual", "auto"]` para enrutar también la compactación automática.
+
+Enrutar la compactación automática es lo que permite que un hilo largo en un proveedor enrutado siga adelante cuando se agota la cuota canónica de OpenAI. Codex elige un modelo nativo sin calificar para el turno de compactación, y OpenCodex lo reserva para un proveedor canónico `openai` habilitado siempre que exista, de modo que la compactación falla con un error de cuota antes de que empiece el turno enrutado aunque el hilo en sí se ejecute en otro sitio. Nombrar `"auto"` aquí dirige la compactación a un modelo calificado por proveedor con sus propias credenciales y cuota solo cuando se omite `sourceModels` o este coincide con el modelo entrante. Una lista que contenga solo entradas `provider/*` no cubre un modelo de compactación nativo sin calificar.
+
+OpenCodex solo modifica las solicitudes con metadatos explícitos de `request_kind: "compaction"` cuyo `compaction.trigger` sea uno de los valores que indicó, enviadas a `/v1/responses/compact` o a `/v1/responses` con un elemento de entrada `compaction_trigger`. Con `codexClientCompaction` activado, el prompt de punto de control local también coincide cuando los metadatos especifican `compaction.implementation` como `"responses"`; sigue siendo una solicitud normal de resumen de texto. Los turnos posteriores de la conversación conservan su enrutamiento y configuración originales. Los metadatos ausentes, mal formados o conflictivos no activan la anulación, incluso en clientes antiguos sin metadatos de activación; cuando se envían varias copias de los metadatos, deben nombrar el mismo activador. Las solicitudes WebSocket usan los metadatos de cada trama en lugar de los metadatos de enlace anteriores de la conexión.
+
+El proveedor del modelo seleccionado recibe toda la conversación para resumirla, incluidas las conversaciones que normalmente se ejecutan en otro proveedor. Un combo selecciona un objetivo por su estrategia de enrutamiento y puede volver a intentar la misma conversación en otro objetivo después de un fallo reintentable, por lo que uno o más objetivos pueden recibirlo. El panel de control indica esto junto al selector de modelos y nombra al proveedor de destino, o a los proveedores de destino del combo, una vez que se elige un modelo. Cuando la anulación cubre la compactación automática, esa transferencia ocurre sin que usted la solicite, en cualquier punto que Codex decida compactar; el panel del tablero también lo dice. La anulación reutiliza los manejadores de compactación y los formatos de resumen existentes. Cuando el modelo seleccionado comparte el proveedor del modelo de conversación y la identidad de enrutamiento de cuenta (nombre del proveedor, modo de cuenta Codex y espacio de nombres de cuenta), la solicitud mantiene la credencial del llamante y puede usar el punto final compacto nativo de ese backend. De lo contrario, incluso cuando cualquiera de los lados es un combo o el modelo de conversación se recuerda como un objetivo combinado, OpenCodex ejecuta el sintetizador portátil en su lugar, por lo que el resumen permanece legible cuando la conversación se reanuda en su propio modelo, y la credencial de la persona que llama no se cruza con el otro proveedor. El modelo seleccionado debe admitir el tamaño de entrada y el contenido. Para los resúmenes portátiles Responses, los elementos de historial `web_search_call` alojados se etiquetan como notas de referencia del asistente, porque la solicitud de resumen no tiene herramientas. Estado conocido, consultas de búsqueda, URLs visitadas, patrones de búsqueda y metadatos de origen se conservan, con valores largos y listas cortadas y como máximo 64 KiB de notas por solicitud de resumen; se omiten el estado opaco y los campos desconocidos o mal formados. Estas notas describen las acciones de búsqueda anteriores, no el contenido de la página ni las nuevas instrucciones. El texto de la respuesta existente, las citas y los resultados de la herramienta ordinaria siguen estando disponibles. Las solicitudes Lite retienen `parallel_tool_calls=false`, que el flujo ascendente requiere incluso sin declaraciones de herramientas. Esto cambia solo la solicitud de resumen, no el historial almacenado o la compactación nativa; un resumen fallido no reemplaza el historial. Reinicie el proxy después de editar `config.json` a mano. Las reservas del panel de control se aplican de inmediato.
+
+<a id="reasoning-retention-during-compaction"></a>
+
+### Razonamiento de retención durante la compactación
+
+La retención de razonamiento legible requiere activación explícita como opción avanzada y está **desactivada de forma predeterminada**. Solo `reasoningRetention.enabled: true` lo habilita; un bloque omitido, `enabled: false`, o límites heredados sin `enabled: true` dejan sin cambios el comportamiento de compactación ordinario. Cuando se habilita para las solicitudes v1 `POST /v1/responses/compact` y v2 `compaction_trigger` enrutadas, el razonamiento legible permanece local mientras que el modelo seleccionado resume otro contexto. Después de que un resumen legible tenga éxito, el texto retenido exacto regresa junto con él en mensajes de contexto histórico enmarcados, no como un nuevo razonamiento o instrucciones auxiliares. La compactación repetida retiene esos mensajes de nuevo. Los giros posteriores ordinarios los repiten como historia.
+
+```json
+{
+  "reasoningRetention": {
+    "enabled": true,
+    "maxContextPercent": 20,
+    "maxTokens": 100000
+  }
+}
+```
+
+Ambos límites son opcionales y, **cuando la retención está habilitada**, usan de forma predeterminada `20` por ciento y `100000` tokens estimados. Se aplica el menor entre el porcentaje de la ventana de contexto del modelo de compactación y el límite absoluto de tokens; si se desconoce esa ventana, solo se aplica el absoluto. La estimación incluye el marco de contexto histórico de cada mensaje retenido, no solo su razonamiento.
+
+Si se supera el límite, el texto legible se guarda íntegramente en `reasoning-archive/`, dentro del directorio de OpenCodex resuelto (normalmente `~/.opencodex/reasoning-archive/`). El modelo que resume recibe una nota con la ruta en lugar del texto, y el resumen legible final identifica ese archivo. Los archivos nuevos son privados para el usuario en POSIX. Un archivo es provisional hasta que un historial de reemplazo correcto devuelve su ruta, en el resumen legible o en un aviso junto a un resultado nativo tras la conmutación de un Combo v1 enrutado. Los errores, cancelaciones y resúmenes inválidos eliminan el archivo del intento actual. Los reintentos internos lo reutilizan y se conservan los archivos anteriores que sí terminaron correctamente. Una compactación fallida no devuelve un historial de reemplazo.
+
+Los límites de porcentaje y tokens acotan el razonamiento que vuelve al contexto, **no el almacenamiento acumulado de archivos**. Cada archivo contiene solo el razonamiento legible admitido en esa solicitud; su tamaño de entrada está limitado por `maxInboundBodyBytes` (256 MiB de forma predeterminada, configurable hasta 512 MiB), más pequeños separadores entre bloques.
+
+El directorio de archivos tiene un límite independiente, fijado en el código, de **512 MiB y 256 archivos**. Incluye los archivos completos, los restos provisionales y los demás archivos regulares del directorio. Un recorrido acotado y en streaming se detiene cuando ya es seguro que debe rechazar la operación; las entradas que no sean archivos regulares o que no puedan inspeccionarse provocan un rechazo seguro. Una transacción SQLite en un archivo adyacente serializa el recorrido, la creación exclusiva, la escritura y el cierre entre los procesos que usan este mecanismo. La capacidad se comprueba **antes de escribir el contenido de un archivo nuevo**; adquirir el bloqueo y registrar la propiedad local todavía puede escribir archivos de bloqueo o metadatos. Este límite no garantiza que haya espacio físico libre ni controla las escrituras de versiones anteriores o herramientas externas. **No hay vencimiento automático ni limpieza de archivos en segundo plano**.
+
+Si el almacenamiento está lleno, la compactación enrutada rechaza el contenido nuevo con HTTP 503 `reasoning_archive_quota_exceeded`: revisa y elimina manualmente los archivos antiguos antes de reintentar la misma solicitud. HTTP 503 `reasoning_archive_busy` indica que otro proceso mantiene el bloqueo; espera a que termine y reintenta. HTTP 503 `reasoning_archive_unavailable` requiere comprobar los permisos del directorio y el estado del almacenamiento. Estas respuestas no exponen rutas del sistema de archivos ni causas internas y no inventan un plazo Retry-After. Un archivo rechazado no trunca el razonamiento ni elimina archivos anteriores; una compactación fallida no devuelve un historial de reemplazo.
+
+Los límites de porcentaje/token volvieron en contexto, **Almacenamiento de archivo no acumulativo**. Cada archivo contiene solo razonamiento legible admitido en esa solicitud; la admisión de la solicitud está limitada por `maxInboundBodyBytes` (256 MiB por defecto, configurable hasta 512 MiB), además de pequeños separadores de bloques. El directorio del archivo tiene un techo compilado separado en **512 MiB y 256 archivos**, contando archivos comprometidos, remanentes provisionales y otros archivos regulares en ese directorio. Una exploración de transmisión limitada se detiene una vez que el rechazo es seguro; las entradas no regulares o no inspectables se niegan a cerrarse. Una transacción hermana SQLite serializa el escaneo, la creación exclusiva, la escritura y el cierre entre los escritores que cooperan. La comprobación de capacidad se ejecuta **antes de que se escriba una nueva carga útil de archivo**; adquirir el bloqueo y grabar la propiedad local aún puede escribir archivos de bloqueo o metadatos. Este límite no es una garantía física de espacio libre y no impone escrituras por compilaciones antiguas o herramientas externas. Hay **sin caducidad automática o limpieza de archivo de fondo**.
+
+El directorio de archivos tiene un límite independiente, fijado en el código, de **512 MiB y 256 archivos**. Incluye los archivos completos, los restos provisionales y los demás archivos regulares del directorio. Un recorrido acotado y en streaming se detiene cuando ya es seguro que debe rechazar la operación; las entradas que no sean archivos regulares o que no puedan inspeccionarse provocan un rechazo seguro.
+Una transacción SQLite en un archivo adyacente serializa el recorrido, la creación exclusiva, la escritura y el cierre entre los procesos que usan este mecanismo. La capacidad se comprueba **antes de escribir el contenido de un archivo nuevo**; adquirir el bloqueo y registrar la propiedad local todavía puede escribir archivos de bloqueo o metadatos.
+Este límite no garantiza que haya espacio físico libre ni controla las escrituras de versiones anteriores o herramientas externas. **No hay vencimiento automático ni limpieza de archivos en segundo plano**.
+
+Si el almacenamiento está lleno, la compactación enrutada rechaza el contenido nuevo con HTTP 503 `reasoning_archive_quota_exceeded`: revisa y elimina manualmente los archivos antiguos antes de reintentar la misma solicitud. HTTP 503 `reasoning_archive_busy` indica que otro proceso mantiene el bloqueo; espera a que termine y reintenta. HTTP 503 `reasoning_archive_unavailable` requiere comprobar los permisos del directorio y el estado del almacenamiento. Estas respuestas no exponen rutas del sistema de archivos ni causas internas, y no inventan un plazo Retry-After. Un archivo rechazado no trunca el razonamiento ni elimina archivos anteriores; una compactación fallida no devuelve un historial de reemplazo.
+
+Los archivos seleccionados permanecen hasta que elimine manualmente sus archivos, incluso después de deshabilitar la retención o restablecer la configuración. Son texto plano, contienen razonamientos de conversación potencialmente sensibles y comparten la casa OpenCodex resuelta de esa instancia proxy. Eliminar un archivo hace que cualquier notificación de ruta existente no pueda recuperar su contenido; guarde primero todo lo que necesite. Un bloqueo de proceso o una escritura / limpieza del sistema de archivos fallida también pueden dejar un archivo provisional que requiere limpieza manual.
+
+
+
+**Dashboard → Overview → Configuración avanzada → Razonamiento retención** proporciona el interruptor explícito y ambos límites; **Reiniciar y apagar** elimina la anulación y desactiva la retención. GET/PUT `/api/settings` expone `reasoningRetention`: null borra el bloque, y la omisión lo conserva. `enabled` debe ser un booleano cuando esté presente. Los porcentajes deben ser mayores que 0 y como máximo 100; los límites de token deben ser enteros positivos y los campos desconocidos son rechazados. Las ediciones de mano no válidas deshabilitan solo este bloque con una advertencia, manteniendo la configuración y los proveedores no relacionados.
+
+El texto cifrado y las firmas de proveedores privados no se descifran ni se copian en mensajes retenidos portátiles. Una respuesta de compactación opaca nativa aguas arriba conserva su elemento de salida y texto cifrado exactos. Si la conmutación por error combinada v1 enrutada alcanza un resultado nativo después de retener el razonamiento legible, el historial de reemplazo también incluye los mensajes históricos retenidos o un aviso que nombra su archivo. Los puntos finales nativos compactos mantienen su comportamiento existente.
+
+La ruta v2 todavía devuelve exactamente un elemento de compactación. Su sobre propiedad de proxy `ocx2:` almacena el resumen y el razonamiento histórico retenido por separado como JSON / Base64; esto es codificación, no encriptación del proveedor. Las solicitudes posteriores restauran mensajes históricos separados, y la compactación repetida retiene el razonamiento nuevamente. Los viejos resúmenes `ocx1:` permanecen apoyados. La recuperación de compactación de emergencia opt-in también conserva esta separación para JSON y SSE. La recuperación explícita de la historia nativa también restaura mensajes de razonamiento histórico y resumen separados.
+
+<a id="memory-routing"></a>
+
+## Enrutamiento de memoria
+
+En **Dashboard → Visión de conjunto → Enrutamiento de memoria**, elija un modelo y un esfuerzo de razonamiento opcional para cada una de las dos fases de memoria de Codex, luego haga clic en **Guardar**. Seleccione **Off** y guarde para eliminar la anulación. Los cambios se aplican a la siguiente solicitud de memoria sin reiniciar el proxy.
+
+Establecer `memoryModels` en OpenCodex `config.json` para enrutar esas solicitudes. Con el bloque omitido, ambas fases mantienen su ruta existente. Las fases son independientes: configurar una deja a la otra sola.
+
+```json
+{
+  "memoryModels": {
+    "extract": { "model": "provider/model-id", "reasoningEffort": "low" },
+    "consolidation": { "model": "provider/model-id", "reasoningEffort": "medium" }
+  }
+}
+```
+
+`extract` es el pase que resume una sesión terminada en una memoria en bruto; `consolidation` es la ejecución de un solo agente que fusiona esas memorias en bruto en los archivos bajo `$CODEX_HOME/memories`. `model` acepta identificadores de modelo nativos, identificadores de modelo calificados por el proveedor y combos configurados. `reasoningEffort` es opcional; omítelo para mantener el esfuerzo Codex solicitado. Las declaraciones admitidas son `none`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max` y `ultra`. Codex códigos duros `low` para extracto y `medium` para consolidación, por lo que un esfuerzo configurado reemplaza ese valor.
+
+OpenCodex reconoce estas solicitudes de metadatos de giro propio de Codex: `request_kind: "memory"` en el encabezado `x-codex-turn-metadata` marca un pase de extracto, y `thread_source:
+"memory_consolidation"` marca el hilo de consolidación. En HTTP, una solicitud cuyos nombres de cabecera `x-openai-subagent` `memory_consolidation` cuenta como un pase de consolidación solo cuando los metadatos de turno están ausentes. Los metadatos explícitos no relacionados con la memoria ganan sobre esa reserva. El identificador del modelo no es deliberadamente una señal: el paso de extracción se ejecuta en el mismo modelo de ayudante Codex que se usa para los títulos y los mensajes de confirmación, por lo que una regla basada en el modelo también capturaría las llamadas de ayudante ordinarias. Los metadatos faltantes, mal formados o conflictivos no activan la anulación; cuando se suministran varias copias de los metadatos, deben nombrar la misma fase. WebSocket solicitudes utilizan metadatos de cada trama en lugar de metadatos de enlace anterior de la conexión - el puente vuelve a unir la cabecera `x-openai-subagent` del enlace a cada trama, de modo que la cabecera nombra la conexión, no el paso actual, y no es una señal websocket.
+
+Una fase configurada gana cuando `shadowCallIntercept` coincide con la misma solicitud. Una fase omitida mantiene su enrutamiento actual, incluida cualquier regla de llamada a la sombra existente que coincida con su modelo. El proveedor del modelo seleccionado recibe el texto de sesión Codex que resume la memoria, incluidas las sesiones que normalmente se ejecutan en otro proveedor; el panel del panel lo indica junto a los selectores de modelos. Una fase cuyo objetivo dejó de resolverse (el proveedor está deshabilitado o eliminado, o su combo ya no existe) falla esa llamada de memoria con `409` y el código de error `memory_model_target_unavailable` en lugar de volver al proveedor predeterminado. El registro de solicitudes nombra la fase (`memory-extract` o `memory-consolidation`) como la razón de enrutamiento. Reinicie el proxy después de editar `config.json` a mano. Las reservas del panel de control se aplican de inmediato.
+
+<a id="shadow-calls"></a>
+
+## Llamadas de sombra
+
+Codex utiliza modelos auxiliares pequeños para títulos y mensajes de commit. Activa `shadowCallIntercept` para redirigir prefijos reconocidos a otro modelo configurado, conservando el esfuerzo de razonamiento. El panel lista los orígenes admitidos y guarda un interruptor por origen mediante `PUT /api/shadow-call-settings`; `GET` devuelve `sourceModels` activos y el inventario `sourceModelOptions`. Un `sourceModels` no vacío reemplaza los prefijos predeterminados: incluye `gpt-6-luna` y, para clientes 0.145.0–0.153.x, `gpt-5.6-luna` si aún deben interceptarse. La API rechaza prefijos vacíos, duplicados, con espacios o calificados por proveedor; admite hasta 32 de 128 caracteres y rechaza un destino que se cruce con los orígenes seleccionados. Una lista rechazada devuelve `code: "shadow_call_source_invalid"` y un conflicto de destino `code: "shadow_call_target_invalid"`, para mostrar el mensaje adecuado en lugar de confundir cada `400` con un fallo de red. Debe quedar al menos un origen activo; el interruptor principal detiene todos.
+
+La consolidación de memoria es independiente: Codex pide Terra y `memoryModels.consolidation` controla esa fase. Terra también es un modelo normal de primer plano y subagentes, por lo que sus interruptores están desactivados por defecto. Seleccionar la generación Terra activa solo redirige la consolidación al destino de sombra si no hay un modelo de consolidación configurado; una fase de Memory Routing configurada prevalece. El inventario conserva `gpt-6.1-terra` y `gpt-5.6-terra`, etiquetados como `Memory`.
+
+Los ids de modelo sin proveedor que coincidan son elegibles para interceptación, pero los turnos explícitos de usuario conservan su modelo: `x-codex-turn-metadata` debe contener `request_kind: "turn"` y `thread_source: "user"`. Los hijos generados también conservan el modelo cuando los identifica `x-openai-subagent: collab_spawn` en la conexión HTTP o WebSocket, o `subagent_kind: "thread_spawn"` en los metadatos. En WebSocket solo se usan los metadatos de cada trama `client_metadata["x-codex-turn-metadata"]`; los del upgrade no clasifican tramas posteriores. Los metadatos ausentes o inválidos conservan el comportamiento de interceptación. Los auxiliares también pueden llevar `request_kind: "turn"`, por lo que ese campo solo no los exime. La procedencia de mantenimiento, como `x-openai-subagent: compact` / `review` o `thread_source: "memory_consolidation"`, sigue siendo elegible, sujeta al enrutamiento de memoria configurado. Estas reglas se aplican a destinos concretos y combos.
+
+```json
+{
+  "shadowCallIntercept": {
+    "enabled": true,
+    "model": "gpt-5.5",
+    "sourceModels": ["gpt-6-luna", "gpt-5.6-luna"]
+  }
+}
+```
+
+<a id="when-the-target-is-unavailable"></a>
+
+### Cuando el objetivo no está disponible
+
+El reemplazo es el único destino que eligió el operador, por lo que un objetivo que deja de resolver falla la llamada de ayuda en lugar de enviarla a otro lugar. Cuando el proveedor del objetivo está desactivado o eliminado, o su combo ya no existe, una solicitud interceptada devuelve `409` con el código de error `intercept_target_unavailable` antes de que algo se envíe aguas arriba. El registro de solicitudes registra el mismo código. La solicitud no se pasa al modelo de ayudante nativo y no vuelve al proveedor predeterminado, porque cualquiera de los dos cambiaría el destino, las credenciales y el costo sin su elección. Un objetivo combinado o de perfil de enrutamiento aún falla entre sus propios miembros. Un objetivo calificado como `provider/model` cuyo segmento de proveedor no designa nada configurado se trata de la misma manera, y la configuración API se niega a guardar uno. Un ID de modelo desnudo que se resuelve a través del proveedor predeterminado sigue siendo válido.
+
+Deshabilitar (`PATCH /api/providers?name=<provider>` con `disabled: true`) o eliminar un proveedor que el objetivo resuelve que aún tiene éxito; la respuesta agrega `dependentShadowIntercept: { model, enabled }` y el panel de control muestra una advertencia. Volver a habilitar al proveedor, o elegir otro objetivo, restaura la intercepción.
+
+<a id="sidecars"></a>
+
+## Sidecares
+
+### `images` (`OcxImagesConfig`)
+
+| Campo | Tipo | Predeterminado | Descripción |
+| --- | --- | --- | --- |
+| `provider?` | `string` | selección automática OpenAI | Proveedor `openai-responses` explícito personalizado con clave API para `/v1/images/generations` y `/v1/images/edits`. Los ids gestionados por el registro son rechazados. |
+| `timeoutMs?` | `number` | `300000` | Tiempo de espera de solicitud completa para una solicitud de imágenes independiente. |
+
+La selección explícita falla cuando el proveedor falta, está inhabilitado, es incompatible o carece de una clave utilizable; nunca vuelve a caer en otra cadena de pago. El punto final debe implementar las OpenAI Imágenes API trayectorias y la forma de respuesta esperada por Codex.
+
+Ambos bucles de búsqueda mantienen `web_search` declarado después de que se agote el presupuesto de búsqueda. Las llamadas adicionales reciben un resultado emparejado de límite alcanzado sin otra búsqueda física; como máximo, las iteraciones del modelo `maxSearchesPerTurn + 3` se ejecutan antes de un error de terminal. Las herramientas ordinarias de llamadas y la cancelación aún terminan el ciclo. La recuperación de respuesta vacía elimina todas las herramientas.
+
+### `webSearchSidecar` (`OcxWebSearchSidecarConfig`)
+
+Los adaptadores RunTurn también utilizan el sidecar de búsqueda configurado. Los giros de búsqueda preservan los latidos del corazón de progreso. Un primer evento OAuth 429 rota la cuenta en la solicitud inicial y en cada solicitud de respuesta posterior a la búsqueda. La repetición mantiene la herramienta de búsqueda y los resultados recopilados. Con `emptyCompletionRetry: true`, una respuesta vacía antes del límite de búsqueda recibe un reintento usando la conversación actual y los resultados recopilados. La recuperación sin herramientas existente después del límite de búsqueda sigue estando disponible independientemente de esa configuración. Las fallas aguas arriba detienen el turno en lugar de desencadenar otra búsqueda.
+
+| Campo | Tipo | Predeterminado | Descripción |
+| --- | --- | --- | --- |
+| `enabled?` | `boolean` | encendido cuando usable | Interruptor maestro. Cuando false, OpenCodex deja de interceptar `web_search` Y la integración Codex escribe `web_search = "disabled"` en `~/.codex/config.toml`. |
+| `backend?` | `"openai" \| "anthropic" \| "xai" \| "gemini" \| "exa"` | `openai` | La selección explícita tiene prioridad; si se omite, se usa `openai`. `anthropic` y `xai` se ejecutan solo cuando están configurados explícitamente; `gemini` y `exa` permanecen reservados hasta que sus ejecutores naveguen. |
+| `model?` | `string` | backend-dependiente | `gpt-5.6-luna` para OpenAI, `claude-sonnet-5` para Anthropic o `grok-4.6` para xAI. `gpt-5.4-mini` explícito heredado migra al inicio. |
+| `exaApiKey?` | `string` | Ninguno | Clave de operador para el backend `exa`. Solo escritura: las lecturas de administración nunca devuelven el valor almacenado. |
+| `xSearch?` | `object` | omitido | Opt-in exclusivo de xAI para el `x_search` alojado: `enabled`, matrices mutuamente excluyentes `allowedXHandles` / `excludedXHandles` (máximo 20), y `fromDate` / `toDate` en ISO (`YYYY-MM-DD`). |
+| `reasoning?` | `string` | `low` | Esfuerzo de sidecar. `minimal` es rechazado con búsqueda web. |
+| `maxSearchesPerTurn?` | `number` | `3` | Búsquedas reales permitidas por turno de modelo principal. |
+| `routedModelStallTimeoutMs?` | `number` | `200000` | Fecha límite de inactividad del modelo raw-body. Entero 1-2147483647; cada fragmento no vacío lo restablece. |
+| `timeoutMs?` | `number` | `60000` | Fecha límite para una búsqueda alojada. |
+
+El backend OpenAI requiere un inicio de sesión de ChatGPT y un proveedor `forward` de ChatGPT habilitado. Las repeticiones entrantes de Claude enrutadas inyectan la autenticación principal de ChatGPT en la solicitud interna. El backend Anthropic usa la credencial almacenada activa de un proveedor habilitado Anthropic OAuth. Un backend Anthropic explícitamente seleccionado sin cuenta utilizable falla cerrado en lugar de retroceder. El ejecutor Anthropic utiliza su herramienta nativa `web_search_20250305`. El backend xAI requiere una cuenta Grok OAuth almacenada utilizable, utiliza `web_search` alojado y agrega `x_search` alojado cuando `xSearch.enabled` es verdadero. La entrada de gestión `xSearch` mal formada devuelve `400`; un bloque persistente mal formado falla cerrado durante la planificación. Los carriles `gemini` y `exa` nunca se activan a partir del descubrimiento de credenciales o reserva; el operador debe seleccionarlos explícitamente. `exaApiKey` se acepta en escrituras pero se omite de las respuestas de administración.
+
+Cuatro relojes rigen la búsqueda: base `stallTimeoutSec`, `connectTimeoutMs`, inactividad del modelo enrutado y tiempo de espera de búsqueda alojada. El supervisor del puente efectivo es el máximo más 30 segundos. El puesto en ruta es un guardia de inactividad, no un plazo de generación total.
+
+### `visionSidecar` (`OcxVisionSidecarConfig`)
+
+| Campo | Tipo | Predeterminado | Descripción |
+| --- | --- | --- | --- |
+| `enabled?` | `boolean` | encendido cuando usable | Interruptor maestro de descripción de imágenes. |
+| `backend?` | `"openai" \| "anthropic"` | Automático | La selección explícita tiene prioridad; si se omite, se prefiere una credencial Anthropic OAuth almacenada y utilizable y, de lo contrario, `openai`. |
+| `model?` | `string` | backend-dependiente | `gpt-5.6-luna` para OpenAI o `claude-sonnet-5` para Anthropic. |
+| `maxDescriptionsPerTurn?` | `number` | `8` | Descripciones nuevas sin acierto de caché admitidas por turno principal. `0` deshabilita las llamadas; los valores no válidos usan el valor predeterminado. |
+| `timeoutMs?` | `number` | `45000` | Traer tiempo fuera. Entero 1-2147483647. |
+
+La visión se activa solo para las imágenes enviadas a un modelo en el `noVisionModels` de su proveedor. OpenAI tiene los mismos requisitos de inicio de sesión/reenvío que la búsqueda; Anthropic explícitamente seleccionado falla cerrado sin una credencial utilizable. Las descripciones exitosas de `data:` usan una caché limitada en clave por backend, modelo, detalle, bytes de imagen y contexto de mensaje normalizado. Los hits y duplicados del mismo turno no consumen el límite. Las imágenes remotas `https:` y las descripciones fallidas o vacías no se almacenan en caché.
+
+Anthropic OAuth sidecars reutilización opencodex existentes Claude Code OAuth huella dactilar. Realice una prueba prolongada con la cuenta y la carga de trabajo previstas.
+
+<a id="remote-hub-keys-and-defaults"></a>
+
+## Claves y valores predeterminados del concentrador remoto
+
+`runtimeRole` valores predeterminados a `standalone`. Un concentrador usa `hub.managementPublicOrigin`, `hub.managementIngress` de solo bucle (`enabled:false` cuando está ausente) y `remoteGui.allowedTailscaleUsers` exacto (vacío cuando está ausente). Una clave de datos de cliente vive en `service-api-token`, nunca `config.json`; la rotación puede crear temporalmente `service-api-token.prev`. Las tiendas de uso no se reflejan.
+
+| Clave | Tipo | Predeterminado cuando está ausente | Lo que hace |
+| --- | --- | --- | --- |
+| `hub.managementPublicOrigin` | cadena | Sin configurar | Origen canónico de administración que anuncia un hub y que puede abrirse en un navegador, por ejemplo, la URL HTTPS mostrada por Tailscale Serve. Es el valor que `/readyz` informa como `managementUrl` cuando `runtimeRole` es `hub`. Si no se configura, el hub usa el origen por el que llegó cada solicitud; un cliente detrás de otro frontend podría recibir una dirección inaccesible. |
+| `hub.dataPublicOrigin` | cadena | Sin configurar | El origen canónico de un cliente remoto debe marcar para el plano **datos**, por ejemplo, el origen HTTPS un frontend TLS publica delante de la red Tailscale. Solo asesoramiento: nunca es una dirección de enlace y cambiarla no mueve ningún socket. `ocx hub invite` lo imprime como el URL posicional de la línea `ocx connect`, que se remonta a `http://<hostname>:<port>`, que es una dirección LAN / tailnet que una máquina remota puede no ser capaz de alcanzar más de TLS, así que configúralo en cualquier concentrador con un frontend. A diferencia de la mayoría de las claves opcionales, **no** se deja caer silenciosamente cuando se forma mal: se rechaza un error tipográfico en el momento de la escritura, porque volver a la dirección bind es exactamente lo que el campo existe para evitar. |
+| `hub.managementIngress` | `{enabled:false}` o `{enabled:true, port}` | `{enabled:false}` | Un oyente adicional solo de administración para un frontend local HTTPS. El nombre de host no es configurable: cuando está habilitado, el socket siempre enlaza `127.0.0.1`, y solo se admiten las rutas GUI, session-bootstrap y de administración API. Las rutas del plano de datos se rechazan antes del envío. |
+| `remoteGui.allowedTailscaleUsers` | string[] | `[]` (vacío - nadie) | Se permite que las identidades de inicio de sesión exactas de Tailscale se emitan en una sesión GUI remota automática. Los `Tailscale-User-Login` El encabezado es de confianza **solo** en la entrada de gestión separada; una lista vacía significa que ninguna identidad remota puede acuñar una sesión, que es el valor predeterminado seguro en lugar de un descuido. Las identidades se comparan exactamente, por lo que un error tipográfico niega silenciosamente el acceso. |
+| `remoteGui.allowInsecureHttp` | booleano | Sin configurar | **Jubilado - no tiene efecto.** Una vez permitió un intercambio de emparejamiento de una sola vez sobre el texto sin bucle HTTP. Una concesión de emparejamiento ahora solo cruza loopback o autenticado HTTPS. La clave todavía se analiza para que un `config.json` existente siga cargando (el esquema es estricto, y dejar caer la clave directamente haría que una configuración más antigua no se cargue por completo); un `true` persistente se informa una vez y luego se ignora. Elimínelo de su configuración. |
+
+Un concentrador al que se puede acceder desde un navegador necesita `hub.managementPublicOrigin` y al menos una entrada en `remoteGui.allowedTailscaleUsers`. Establecer el origen sin la lista de usuarios produce un concentrador que se anuncia a sí mismo correctamente y luego rechaza cada sesión; establecer la lista de usuarios sin el origen produce sesiones apuntadas a cualquier origen que la solicitud haya utilizado.
+
+`dataPublicOrigin` y `managementPublicOrigin` son dos anuncios independientes, y en una implementación real son dos sockets diferentes: la administración es el ingreso solo de bucle publicado en 443, los datos son el enlace de red trasera publicado en su propio puerto HTTPS. Son las dos mitades de lo que `ocx hub invite` imprime, y `managementPublicOrigin` es el más estricto de los dos: una concesión de emparejamiento lo registra como el origen del propio servidor de la concesión y el intercambio se compara con él, por lo que `ocx hub invite --management-url` solo puede *confirmar* el valor configurado y rechaza uno que difiera. `--data-url` realmente es una anulación, porque nada está ligado a ella. Con ni `dataPublicOrigin` ni `--data-url` establecidos, `invite` vuelve a la dirección de enlace - y en un enlace de loopback o comodín, donde eso resolvería el propio loopback de esta máquina, rechaza en lugar de anunciar una dirección que la otra máquina no puede usar.
+
+Un centro que sirve a sus propios clientes locales también establece [`unauthenticatedLoopbackListener`](#local-clients-that-cannot-receive-the-token). Su forma complementaria sin puerto es lo que hace que un hub sea un despliegue de puerto único, y se rechaza en un loopback o comodín `hostname`, donde el oyente público ya tiene `127.0.0.1:<port>`.
+
+
+<a id="experimental-native-response-controls"></a>
+
+## Controles de respuesta nativos experimentales
+
+`codexNativeSteering` y `codexNativeInjection` habilitan rutas de control nativo por WebSocket independientes y **desactivadas de forma predeterminada**. Consulta la guía sobre [rutas y ajustes de control compatibles](/es/guides/codex-integration/#steering-continuation-settings), [resultados tipados y aprobaciones explícitas](/es/guides/codex-integration/#rich-tool-results-and-explicit-approvals-after-response-completion) y [plazos de confirmación y contexto conservado](/es/guides/codex-integration/#steering-confirmation-deadlines-and-retained-context).
+
+<a id="forced-claude-code-subagent-model"></a>
+
+### Modelo de subagente forzado Claude Code
+
+La página Subagentes ofrece **Forzar un modelo para todos los subagentes**, una opción **desactivada de forma predeterminada**. Selecciona un identificador disponible en la lista, como `combo/tev-auto`, y después activa la opción. Primero se ofrece la lista de modelos; las entradas guardadas que ya no estén disponibles no se pueden usar como destino forzado.
+
+`ocx agent subagents force combo/tev-auto` conjuntos `claudeCode.subagentModelForce`; `ocx agent subagents force -` lo aclara. `ocx agent status` informa de la configuración. `GET /api/subagent-models` devuelve `force`, `forceAvailable` y `forceStatus`; `PUT` acepta `{ "force": "combo/tev-auto" }` o `{ "force": null }` sin cambiar la lista. Omitir `force` lo deja sin cambios. Los objetivos inválidos o no expuestos son rechazados en la escritura; los objetivos obsoletos son reportados y omitidos en el lanzamiento.
+
+Esto tiene efecto en el **siguiente inicio enrutado de `ocx claude`**, inyectando `CLAUDE_CODE_SUBAGENT_MODEL` como un alias proxy explícito (con `[1m]` solo para una ventana autorizada de un millón de tokens; los objetivos nativos Claude usan un alias nativo reversible) y `CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1`. Cada variable no vacía exportada por el shell gana independientemente. Los lanzamientos nativos no inyectan ninguna variable; el plano `claude` no se ve afectado. No hay archivos de plugin o `settings.json` se modifican por esta configuración.
+
+Claude Code **2.1.257 o más reciente** es necesario para la fuerza. Los argumentos de modelo de complemento y agentes incorporados (incluyendo Explorar/Planear) y por llamada se anulan. Las bifurcaciones y las habilidades de subagente con `model: inherit` mantienen el modelo de conversación principal. El bucle principal y los sidecars de pequeño-rápido no se ven afectados. Los archivos de la lista existentes permanecen disponibles.
+
+El panel de control advierte sobre versiones antiguas o desconocidas de CLI, objetivos no disponibles y cualquiera de las variables ya presentes en `settings.json` → `env` (que anula env de lanzamiento). La detección es de solo lectura y local en el servidor: no puede inspeccionar otro shell de lanzamiento, otra máquina o la configuración local del proyecto. Un resultado desconocido no es prueba de apoyo a la fuerza.
+
+<a id="historical-pool-continuity"></a>
+
+## Continuidad histórica de los grupos
+
+Los techos de grupo de proveedores usan el proveedor enrutado canónico. Para cada proveedor `P` actualmente configurado, OpenCodex enlaza automáticamente su alias de grupo salado, `h(pool, P)`, a `P` cuando se leen saldos. No se necesita un automapeo manual o cálculo de sal para los techos de proveedores independientes. Esta regla también se aplica a los saldos históricos retenidos con ese alias exacto.
+
+Los registros de solicitudes todavía usan etiquetas de visualización específicas de la cuenta. Una etiqueta histórica diferente, incluyendo una cuenta ordinal, no establece la propiedad del proveedor. Con `spend.pool.maxTokens`, cada saldo original contribuye una vez a su grupo de proveedores vinculados o, cuando aún no está unido y es positivo, a cada grupo de candidatos. El uso establecido, reservado y no resuelto cuenta; el uso desconocido no es un reembolso. Por lo tanto, el historial no vinculado puede restringir un grupo que de otro modo no se usaría. El orden de la cuenta corriente y los nombres que se muestran no resuelven ese historial. Los techos de raíz e identidad siguen siendo independientes.
+
+Para etiquetas históricas distintas cuya propiedad haya verificado, agregue asignaciones al objeto `spendPoolAliases` de nivel superior en `config.json`. Cada clave es un alias hexadecimal en minúsculas de 32 caracteres exacto del diario de esta instalación; cada valor es el ID exacto de un proveedor canónico verificado y configurado actualmente, sin espacio en blanco circundante. Mantenga la evidencia para el mapeo y mantenga el diario y la sal en privado.
+
+Vinculaciones automáticas y asignaciones explícitas se aplican solo cuando se leen los saldos. No mueven saldos originales ni persisten vínculos de identidad en la revista. La eliminación de un mapeo histórico explícito hace que el historial se desvincule de nuevo a menos que su alias sea el propio alias de un proveedor actualmente configurado. Mantenga el `spendPoolAliases` fuera del `spend`, porque las versiones anteriores rechazan campos desconocidos dentro de esa sección estricta. Las asignaciones no válidas se rechazan en escrituras; las ediciones de mano inválidas retienen los techos y la admisión de grupos de rechazos. Un alias de grupo salado de un proveedor configurado no puede asignarse a otro proveedor. Esto se comprueba de nuevo cuando el proveedor establece cambios. La validación lee una sal existente sin crear una.
+
+El historial no vinculado expira solo después de que su última actividad sea estrictamente más antigua que `spend.retentionDays`. La presión de capacidad no puede acortar ese intervalo para la historia positiva desconocida. Las reservas en vivo y los objetivos iniciales permanecen protegidos, incluso a cero tokens. La limpieza persiste en un registro de eliminación de diario normal antes de la admisión utiliza el total reducido. Los grupos conocidos mantienen las protecciones ordinarias activas/agotadas. Ninguna herramienta automática reconstruye asignaciones no verificables.
+
+<a id="token-reservations-and-reporting"></a>
+
+### Reservas de tokens e informes
+
+Cuando se aplica un techo de raíz, identidad o grupo, el primer envío físico de cada destino/clave seleccionado requiere una reserva de capacidad normal. Si esa reserva no puede registrarse, el envío se rechaza antes de llegar aguas arriba. Los reintentos estables reutilizan los ámbitos de esa reserva; un destino/clave distinto necesita una nueva. `L` es el límite de envíos físicos de toda la solicitud, fijado cuando esta comienza (cuatro por defecto; el perfil acotado existente de solicitudes OAuth permite hasta dieciocho). Cada envío físico adicional comparte este límite finito.
+
+El estado de aplicación, los límites de token de raíz/identidad/grupo aplicables y `L` se capturan cuando se inicia cada solicitud. Los cambios de configuración se aplican solo a las solicitudes iniciadas después del cambio. Las solicitudes que ya se están ejecutando mantienen su política de partida para todos los reintentos y continuaciones: habilitar o bajar un techo no las aprieta, y elevar o quitar un techo no las relaja. Una solicitud que se inició en modo de solo observación permanece solo observación hasta que finaliza.
+
+Los informes retrasados retienen el uso ya iniciado. La liquidación de la terminal espera a los reporteros, y las identificaciones de envío se olvidan solo después de que su contabilidad sea duradera; olvidar una identificación no elimina su saldo. Los límites de límite se reintentan, no la factura final: el uso real o los reintentos ya iniciados pueden exceder una estimación de token, y su responsabilidad total sigue siendo contada. Sin límite máximo aplicable, el comportamiento se mantiene solo en observación, incluidas las reservas omitidas cuando la capacidad de seguimiento está llena. No se agregan puntos de control de identidad para el tráfico no configurado.
+
+Claude CLI, CodeBuddy y Qoder cuentan cada invocación CLI como un envío. Su primera invocación todavía necesita una reserva normal y se rechaza si esa reserva no se puede obtener. Los intentos internos de CLI y los giros de herramientas no consumen por separado este límite de envío de toda la solicitud; su costo se establece a partir del uso informado real, incluidas las cantidades por encima de la estimación inicial. Esta excepción preserva el uso de CLI con techos de gasto configurados mientras limita el número de invocaciones secundarias.
+
+<a id="rollback-to-2800-contract-c"></a>
+
+### Retroceder a 2.80.0: contrato C
+
+Los nuevos registros utilizan el formato v1 existente y el dominio alias `pool`. **2.80.0 sin modificar los lee usando sus propias reglas por etiqueta**, incluyendo la compactación y retención ordinaria. No hay necesidad de backport, valla lanzador o comando de reconciliación. Mantenga el diario actual y sal: restaurar una copia anterior pierde el gasto registrado desde esa copia.
+
+Esto no preserva la agregación canónica después de la degradación, ni promete la misma asignación restante que 2.80.0 habría calculado para el mismo tráfico sin la actualización. Puede reservar nuevo tráfico bajo etiquetas de cuenta. En la re-actualización, las auto-vinculaciones actuales del proveedor configurado y las asignaciones explícitas de alias se aplican a los saldos originales aún retenidos por 2.80.0. Los puntos de control nuevos no contienen metadatos de enlaces de identidad que un lector antiguo debe conservar.
+
+Las revistas escritas por compilaciones experimentales no publicadas con `pool-current` alias o `poolContinuity` metadatos están excluidas de este contrato de compatibilidad, incluidos los puntos de control posteriores que llevan esos alias. Sus saldos originales y los objetivos de envío siguen siendo un historial no vinculado conservador hasta que expira la retención normal; no se convierten ni se eliminan inmediatamente.
+
+Un registro de diario no válido completo (incluyendo un `null` final) hace que la admisión configurada se rechace. La compactación aún puede preservar la contabilidad válida en un punto de control limpio; el rechazo en vivo permanece hasta que un reinicio limpio lo reproduce. Una línea final desgarrada e inconmensurable mantiene el comportamiento de recuperación existente. Las denegaciones de almacenamiento / corrupción usan `workflow_spend_undurable`; los archivos inseguros y las fallas de propiedad siguen siendo errores de almacenamiento. Los fallos de validación de Alias utilizan `workflow_pool_history_unresolved`.
+
+<a id="local-upstream-timeout-classification"></a>
+
+## Clasificación de plazos para proveedores locales
+
+La localidad es una política de plazos, no una autorización de acceso a la red. Se clasifica el destino HTTP(S) configurado sin consultar DNS: `localhost` exacto sin distinguir mayúsculas y con punto final opcional, `0.0.0.0`, IPv4 loopback (127/8), direcciones privadas RFC 1918 y link-local (169.254/16), IPv6 loopback, link-local (fe80::/10), unique-local (fc00::/7), equivalentes IPv4 mapeados y nombres terminados en `.local` o `.lan`. Otros nombres DNS mantienen los plazos públicos aunque resuelvan a loopback; destinos mal formados y esquemas no admitidos también. `localhost.example` es público.
+
+Desactivar el reloj de encabezados conserva la cancelación del cliente y cualquier plazo global envolvente. Un `stallTimeoutSec` positivo explícito sigue limitando el silencio local del cuerpo; sin configurar los relojes locales no hay límite automático antes de los encabezados. Las lecturas JSON locales nativas Chat/Messages usan el presupuesto local de silencio; las públicas conservan `max(connectTimeoutMs ?? 200000, 5000)`. Las lecturas del cuerpo compacto mantienen 300 segundos por defecto, incluso localmente. Los presupuestos de los sidecars de imagen y búsqueda no cambian.
+
+`opencodeClientExport` opcional controla `headerTimeoutMs`, `chunkTimeoutMs` y `timeoutMs` del proveedor OpenCode generado: milisegundos positivos o `false` para desactivar. Omitirlos conserva los valores de OpenCode y los inválidos no se emiten. Se escriben para todo el proveedor en opciones V1 y settings V2. Consulta [modelos locales lentos](/es/guides/opencode/#slow-local-models-prefill-timeouts).
+
+El ajuste opcional `omoClientExport.api`, disponible solo en el archivo de configuración, selecciona el protocolo del bloque de proveedor administrado de omo, basado en Pi: `openai-completions` (predeterminado) u `openai-responses`. Se ignoran los demás valores. Solo omo lo utiliza. Después de añadir, cambiar o eliminar la clave, reinicia el proxy (`ocx service restart` si usa un servicio, o `ocx stop` y después `ocx start`) y actualiza **Conectar → omo** en el dashboard. Actualizar usa la configuración del proxy en ejecución; no vuelve a cargar el archivo. Consulta [Integraciones](/es/guides/integrations/).
+
+
+Las reservas de tokens se devuelven de inmediato si una admisión física rechaza antes de iniciar el envío; los envíos iniciados y reservas pendientes siguen contabilizados. Los rechazos de continuación nativa conservan HTTP 429 en el registro y en el error.
+
+Una tarea inactiva retiene su plaza mientras haya envíos o historial de hijos aún vigentes, aunque no agotara el límite. Solo se reutilizan plazas sin turno activo, historial restante ni presupuesto agotado. Si deben conservarse las 512, la nueva tarea recibe HTTP 429 `workflow_tracking_exhausted`. Las ventanas de recuento caducan normalmente y son del proceso; el techo persistente de tokens es independiente.
+
+Las etiquetas de cuentas OAuth, incluidas Claude, Grok y Kiro, siguen `privacy.maskEmails`: enmascaradas por defecto, completas solo con `false`. Un alias prevalece; Overview y diálogos de restablecimiento, cupones y borrado usan la misma etiqueta. La bandeja Desktop conserva la máscara en ambos casos.
+
+Si todos los destinos de un combo de compactación están en enfriamiento, falla rápido con `combo_unavailable` y el plazo más cercano, por ejemplo `(retry in ~2m)`. Un rechazo de una cuenta local Pool enfría el destino solo con el backoff corto del combo. Para reintentar todos sin esperar un `Retry-After` largo, usa [recuperación explícita](/es/guides/combos/#retry-all-cooled-targets-opt-in), como `{"cooldownReprobe": {"enabled": true, "intervalMs": 300000}}`. Solo actúa ante demanda y respeta cuotas y admisión; no permite servir a una cuenta agotada.
diff --git a/docs-site/src/content/docs/es/reference/inbound-body-admission.md b/docs-site/src/content/docs/es/reference/inbound-body-admission.md
new file mode 100644
index 00000000000..b2cbbe5267f
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/inbound-body-admission.md
@@ -0,0 +1,67 @@
+---
+title: "Admisión de cuerpos de solicitudes entrantes"
+description: "Cómo los límites elevados del cuerpo afectan a la concurrencia HTTP, los reintentos y la contabilización de memoria."
+---
+
+La [referencia de configuración de proveedores](/es/reference/configuration/providers/) describe `maxInboundBodyBytes`, el tamaño máximo decodificado de un cuerpo JSON entrante. Su valor predeterminado sigue siendo 256 MiB y el intervalo configurable va de 1 MiB a 512 MiB. Reinicia el proxy después de cambiarlo para que el servidor HTTP y los lectores apliquen el mismo límite.
+
+Conservar el presupuesto compartido predeterminado de 512 MiB no elimina los compromisos de espera y duración de las respuestas descritos más abajo.
+
+<a id="choose-the-shared-budget-explicitly"></a>
+
+## Elegir explícitamente el presupuesto compartido
+
+`maxConcurrentInboundBodyBytes` es una opción de nivel superior de `config.json`, en bytes. Su valor predeterminado es **512 MiB (`536870912`)**, igual al presupuesto anterior. Omitirla, usar `0` o un valor inválido conserva ese valor. Los enteros positivos válidos se limitan al intervalo **512 MiB–2 GiB (`536870912`–`2147483648`)** al utilizarlos. Reinicia el proxy después de cambiarla. Todos los listeners de un proceso comparten el presupuesto; es independiente de `appOwnedMemoryBudgetMb`.
+
+Para elegir un límite de 512 MiB por solicitud y activar explícitamente un presupuesto compartido de 2 GiB, incorpora estos campos al nivel superior de `config.json` y reinicia:
+
+```json
+{
+  "maxInboundBodyBytes": 536870912,
+  "maxConcurrentInboundBodyBytes": 2147483648
+}
+```
+
+Esta decisión del operador aumenta el pico potencial de memoria. El proxy no detecta automáticamente la RAM disponible ni elige un presupuesto en función de ella.
+
+<a id="raising-the-limit-changes-concurrency"></a>
+
+## Aumentar el límite cambia la concurrencia
+
+Cuando el límite efectivo supera 256 MiB, cada solicitud HTTP cubierta debe reservar toda su capacidad por solicitud **antes de leer el cuerpo**. Las reservas comparten el presupuesto del proceso `maxConcurrentInboundBodyBytes`, cuyo valor predeterminado sigue siendo **512 MiB**.
+
+Antes de terminar el análisis JSON acotado, un `Content-Length` pequeño o un cuerpo comprimido pequeño no reduce la reserva: ninguno demuestra el tamaño del JSON decodificado o normalizado.
+
+Tras un análisis JSON acotado correcto, la reserva se reduce al mayor tamaño observado entre bytes de transporte, bytes decodificados y la medición existente de JSON normalizado cuando el traductor aporta un presupuesto para ella. La reserva solo disminuye, hasta la capacidad original; una medición normalizada mayor nunca la aumenta. La cantidad de bytes de entrada no sustituye al tamaño normalizado potencialmente mayor; se mantienen las comprobaciones de UTF-8 y JSON vuelto a serializar.
+
+Con **512 MiB compartidos** y **512 MiB por solicitud**, solo **una carga sin analizar** puede reservar toda su capacidad. Aunque el análisis reduzca la reserva a **un byte**, queda menos de 512 MiB, por lo que la siguiente solicitud debe esperar. El valor predeterminado **no** resuelve el problema original de concurrencia con 512 MiB por solicitud.
+
+Establecer explícitamente `maxConcurrentInboundBodyBytes` en `2147483648` elige **2 GiB** y admite hasta **cuatro cargas completas de 512 MiB** antes del análisis y las reducciones medidas. Después del análisis no es un límite fijo de cuatro solicitudes: por ejemplo, **ocho solicitudes pequeñas pueden transmitir simultáneamente** si sus reservas reducidas dejan espacio para nuevas admisiones, dentro del presupuesto y los demás límites.
+
+La reserva reducida se mantiene durante el trabajo asíncrono y la espera del proveedor hasta el fin del flujo, un error o la cancelación completada. Analizar el cuerpo no la libera. Si el cliente se desconecta, se conserva hasta que termina la cancelación del productor. Se libera exactamente una vez, incluso si compiten errores, abortos y cancelaciones.
+
+Los destinos POST cubiertos son `/v1/responses`, `/v1/responses/compact`, `/v1/chat/completions`, `/v1/messages`, `/v1/messages/count_tokens`, `/v1/images/generations`, `/v1/images/edits` y `/v1/alpha/search`. Las imágenes, la búsqueda y el recuento de tokens conservan sus límites configurables por cuerpo. Las llamadas internas de traducción directa y de Combos no reservan una segunda capacidad HTTP. No cambian los límites de administración, audio, historial de contexto ni WebSocket.
+
+Este control adicional solo se activa cuando `maxInboundBodyBytes` efectivo supera 256 MiB. Omitir esa opción o usar `0` conserva los 256 MiB predeterminados y deja el control inactivo. Omitir o poner a cero `maxConcurrentInboundBodyBytes` elige los 512 MiB compartidos predeterminados; no desactiva un control que ya esté activo. Se mantienen los demás límites de solicitudes y recursos.
+
+<a id="temporary-refusal-versus-an-oversized-body"></a>
+
+## Rechazo temporal y cuerpo demasiado grande
+
+Si no hay capacidad completa disponible, la solicitud puede entrar en una **cola FIFO de hasta 32 solicitudes**, con un **plazo de espera de 120 segundos**. La aplicación no lee los cuerpos en cola. La capacidad liberada por una reducción medida o una liberación final admite las solicitudes en orden FIFO. Si una solicitud en espera se aborta, se retira y se cancela su cuerpo sin consumirlo.
+
+Una cola llena o una espera vencida produce HTTP **503**, `Retry-After: 1` y `server_busy`, antes de analizar el cuerpo o enviar la solicitud al proveedor. Los cuerpos sin leer se cancelan. Los clientes Messages y de recuento de tokens reciben el formato Anthropic con `overloaded_error`; los clientes OpenAI reciben `server_error`. Las comprobaciones de autenticación y origen preceden a la admisión y la cola.
+
+Respeta el encabezado de reintento y la espera progresiva del cliente. La espera acotada y las reservas medidas reducen rechazos evitables, pero no eliminan todos los 503. Aumentar el límite por solicitud no resuelve el agotamiento sostenido.
+
+Un cuerpo que supere su límite por solicitud sigue recibiendo HTTP **413**. Si el tamaño declarado excede el límite, se mantiene esa respuesta en lugar del rechazo por capacidad ocupada.
+
+<a id="what-the-budget-measures"></a>
+
+## Qué mide el presupuesto
+
+El presupuesto contabiliza unidades de admisión: capacidades completas antes del análisis y reservas medidas después. **No preasigna 2 GiB** ni la cantidad configurada y **no limita la memoria RSS ni el heap de objetos analizados**. La decodificación, las cadenas, los objetos, las copias y otros estados consumen memoria adicional; el uso real puede superar el presupuesto.
+
+Elegir 2 GiB en vez de 512 MiB permite cuatro veces la reserva total. Con 512 MiB por solicitud, admite hasta cuatro cargas completas antes del análisis en lugar de una y aumenta el pico potencial de memoria. Elige según el margen de memoria del despliegue. Un límite por solicitud de 256 MiB o menos deja inactivo este control adicional, independientemente del presupuesto compartido.
+
+Conserva el límite por solicitud predeterminado siempre que sea posible. Auméntalo deliberadamente para flujos con mucho historial, considerando el mayor pico de memoria y la espera acotada.
diff --git a/docs-site/src/content/docs/es/reference/management-api.md b/docs-site/src/content/docs/es/reference/management-api.md
new file mode 100644
index 00000000000..44d8f344860
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/management-api.md
@@ -0,0 +1,661 @@
+---
+title: "API de administración"
+description: "Autenticación, errores y endpoints del plano de administración de opencodex."
+---
+
+El Management API es el plano de control de opencodex. El panel de control en `http://localhost:10100` es un cliente de él; los proveedores, modelos, combos, cuentas, configuraciones, diagnósticos y comandos del ciclo de vida de `ocx` sin cabeza también son clientes. El API solo está disponible mientras el proxy se está ejecutando.
+
+Utilice el [Panel de control web](/es/guides/web-dashboard/) para un cliente interactivo, o esta referencia al construir la automatización. Los valores persistentes siguen en última instancia [Configuración](/es/reference/configuration/).
+
+<a id="authentication-model"></a>
+
+## Modelo de autenticación
+
+El Management API tiene su propia credencial de administración, independientemente de las claves del plano de datos API. En el inicio, opencodex lo resuelve en este orden:
+
+1. `OPENCODEX_ADMIN_AUTH_TOKEN`, cuando se establece.
+2. Un token `ocx_admin_*` generado en un archivo secreto endurecido.
+
+El token respaldado por archivos se acepta solo después de que se hayan endurecido sus permisos de directorio y archivo o ACL. Si eso no se puede garantizar, la autenticación de administración falla y el API devuelve 503 hasta que se suministra un token de entorno o se repara el estado del archivo.
+
+Envíe el token de administración en cualquier forma:
+
+```http
+X-OpenCodex-API-Key: <admin-token>
+```
+
+```http
+Authorization: Bearer <admin-token>
+```
+
+:::caution
+El administrador token debe diferir de cada credencial del plano de datos. Startup rechaza una gestión Credencial que entra en conflicto con una clave de admisión proxy. No ponga el administrador token en Codex, Claude Code, u otro cliente modelo; autoriza mutaciones en el plano de control.
+:::
+
+<a id="loopback-dashboard-sessions"></a>
+
+### Sesiones de panel de Loopback
+
+En un enlace de loopback, el cuadro de mandos puede recibir una credencial `ocx_session_*` de corta duración. Cada sesión dura cinco minutos y está vinculada al origen exacto del panel de control. Las solicitudes seguras deben coincidir con ese origen. Los métodos inseguros también requieren el navegador `Origin` y el token CSRF de la sesión.
+
+Cuando se requiere autenticación de plano de datos, que incluye enlaces remotos, la secuencia de arranque de bucle de retorno no acuña una sesión. Un panel de control remoto obtiene una sesión de 12 horas solo a través de una identidad Tailscale de confianza (`remoteGui.allowedTailscaleUsers` en la entrada de administración Tailscale) o una concesión de emparejamiento de un solo uso; cada solicitud autorizada la extiende. De lo contrario, un operador remoto se autentica con el token de administración sin procesar y el panel de control lo solicita nuevamente después de una recarga porque la sesión solo vive en la memoria de la página. Véase [Hub remoto](/es/guides/remote-hub/).
+
+<a id="common-errors"></a>
+
+## Errores comunes
+
+Todas las filas de punto final por debajo heredan estos errores de límite. La columna "Errores notables" muestra resultados adicionales específicos de la ruta en lugar de repetir esta tabla.
+
+| Situación | Tipo o código | Descripción |
+| --- | --- | --- |
+| 401 | `opencodex admin token required` | La sesión de token de administrador o GUI no se encuentra, no es válida, ha caducado, no coincide con el origen o falta evidencia de CSRF |
+| 403 | `cross-origin request blocked` | El origen de la solicitud está fuera de la lista de permisos de administración |
+| 403 | `code: "remember_requires_direct_origin"` | Solo `POST /api/session/remember`: esta dirección no puede guardar un dispositivo recordado. Un proxy TLS independiente necesita `dashboardTrustedProxy`; la solicitud debe proceder de sus `proxyAddresses` y coincidir con el host, esquema y `Origin` de su `origin`. Inicia sesión sin Recordar. Si falla la comprobación de origen, `error` es `cross-origin request blocked`; si pasa esa comprobación pero la ruta rechaza la dirección o falta Origin coincidente, es `Remember requires a direct HTTPS dashboard (or loopback) and matching Origin`. Identifica el caso por `code`. |
+| 404 | `not_found` | Ninguna ruta de administración coincide con el método y la ruta |
+| 413 | `request body too large` | Un cuerpo POST, PUT o PATCH excede el límite de administración de 2 MiB |
+| 503 | `management API unavailable` | La inicialización o endurecimiento de credenciales de administrador no está disponible |
+| 503 | `oauth_mutation_busy` | Otra mutación de la credencial OAuth sostiene al escritor; la respuesta incluye `Retry-After: 1` |
+| 503 | `catalog_busy` | La recolección de catálogos ya está a su capacidad; la respuesta incluye `Retry-After: 1` |
+
+<a id="health-during-local-credential-updates"></a>
+
+### Salud durante una actualización local de credenciales
+
+Si una actualización asíncrona de perfil nativo espera que otro proceso libere el bloqueo de publicación de credenciales, `/healthz` puede seguir respondiendo. Se mantiene el plazo de diez segundos para adquirir el bloqueo y no se escribe hasta obtenerlo.
+
+### Uso por aplicación, dispositivo y cuenta
+
+Los intentos y filas del pool Anthropic OAuth incluyen `accountTag`: `p` seguido de seis dígitos hexadecimales minúsculos. `anthropic-p2e22d0` lleva `p2e22d0`. Identifica la cuenta que sirvió cada intento, incluida una sustitución por failover, sin correo, ID de cuenta ni credenciales, y sin cambiar `accountLogLabel` ni los resúmenes por cuenta. Filas antiguas, valores inválidos o proveedores sin sufijo omiten el campo.
+
+`GET /api/usage` permite combinar `client` y `device`. Los clientes son `all`, `codex`, `claude_code`, `claude_desktop`, `grok`, `opencode`, `aside`, `other` y `unknown`; los dispositivos son `all`, `no-key`, `key` y `unconfigured`. `key` exige exactamente un `apiKeyId` sensible a mayúsculas. Requieren `surface=all` u omitir surface y no se combinan con proyecciones JEV o de fallos. Opciones repetidas o inválidas devuelven 400. La respuesta confirma `sourceFilter` y `legacyUnclassifiedRequests`. Registros sin app permanecen sin clasificar: la opción Codex incluye los antiguos de su superficie sin inventarles una aplicación. `no-key` incluye registros antiguos y admitidos por entorno; no prueba un dispositivo físico.
+
+`unconfigured` requiere sesión de dashboard y selecciona filas de admisión configurada cuyo ID ya no está en la lista actual, sin probar eliminación ni dispositivo y sin incluir filas sin metadatos de admisión. `/api/usage/source-facets` requiere esa sesión y devuelve conteos para una ventana capturada de 30 días, confirmación de filtros y estado de lectura incompleta. El conteo de apps respeta el dispositivo elegido y viceversa; las claves individuales se limitan a las configuradas. Su `legacyUnclassifiedRequests` siempre es el subconjunto Codex del dispositivo elegido. Este endpoint y los informes unconfigured usan `no-store`.
+
+IDs no seleccionables exactamente, incluidos los rodeados por espacios, permanecen en la instantánea configurada y cuentan en `unavailableConfiguredKeys`, sin recortarse ni clasificarse como no configurados. Una sesión que caduca durante un escaneo autorizado produce 401; una credencial sin alcance dashboard produce 403. Se rechazan instantáneas con más de 1.024 claves, IDs de más de 256 caracteres o más de 65.536 caracteres de IDs en total, sin truncar.
+
+Las etiquetas son clasificaciones aproximadas de encabezados, no autenticación; no se guardan encabezados crudos para esta atribución. Se reconocen firmas documentadas de Codex, Claude y OpenCode, pero Grok, Aside y otras apps Chat no identificadas siguen como unknown. `/v1/usage` acepta client y confirma el alcance de su clave sin exponer el ID. El relay Remote Link solo admite los nuevos filtros para su propia clave autenticada. Los límites de instantáneas filtradas describen filas coincidentes. El Child exige que Home confirme el alcance y rechaza una respuesta sin confirmar; HEAD filtrado por Child devuelve 405 porque carece del cuerpo necesario. Las consultas sin las nuevas dimensiones conservan su comportamiento.
+
+Los escaneos fríos ceden entre registros para que continúen las comprobaciones de salud; cada registro se procesa atómicamente. Los filtros por proveedor, modelo, apiKeyId, origen y ventana personalizada usan el índice derivado `~/.opencodex/usage-filter-index.sqlite`: guarda offsets de filas completas y sus campos. La primera consulta con índice ausente o inválido ingiere el ledger completo; después solo los bytes nuevos. Los totales son los mismos que leyendo `usage.jsonl`, que sigue siendo la única autoridad y nunca se trunca ni reescribe. Un ledger reemplazado, truncado o reescrito reconstruye el índice.
+
+El índice es privado y reconstruible. No se sobrescribe un archivo ajeno que ocupe su ruta. Sin permisos, espacio o acceso al índice, o si está dañado, se vuelve a leer el ledger directamente con iguales totales. Un Child pasivo solo usa un índice ya actualizado, sin crearlo ni modificarlo. `client=all&device=all` sin otro filtro todavía debe leer todas las filas de la ventana: el índice reduce trabajo repetido para filtros selectivos, no el costo de un informe completo.
+
+<a id="endpoint-matrix"></a>
+
+## Matriz de punto final
+
+<a id="agent-and-client-settings"></a>
+
+### Configuración de agente y cliente
+
+| Método y ruta | Finalidad | Errores notables |
+| --- | --- | --- |
+| `GET, PUT /api/v2` | Leer o cambiar la configuración nativa del modo v2 y el subproceso de múltiples agentes | 400 ajustes no válidos; 502 Fallo de transición o persistencia |
+| `GET, PUT /api/injection-model` | Leer o configurar el modelo de subagente inyectado, los ajustes de esfuerzo, prompt y orientación | 400 modelo, esfuerzo o cuerpo no válidos |
+| `POST /api/injection-model/suggest` | Dimensionar una carga de trabajo delegada descrita y proponer un modelo de delegación y esfuerzo sin escribir | 400 trabajos o modelos no válidos; 409 sin modelo de tamaño |
+| `GET, PUT /api/effort-caps` | Leer o establecer límites globales y de esfuerzo de razonamiento de subagentes | 400 valor de escalera no válido |
+| `GET, PUT /api/subagent-models` | Leer u ordenar los modelos anunciados a los sub-agentes | 400 lista inválida o más de cinco modelos |
+| `GET, PUT /api/subagent-model-fallback` | Leer o establecer la cadena de reserva ordenada y el intervalo de sondeo | 400 lista inválida o intervalo de sondeo |
+| `GET /api/grok` | Leer el estado de configuración administrada Grok y los modelos candidatos | Error de lectura de 400 estados |
+| `PUT /api/grok/selection` | Persisten los modelos Grok excluidos | 400 selección no válida o sobredimensionada |
+| `POST /api/grok/apply` | Aplicar configuración persistente Grok a través de la sincronización administrada | 409 `grok_apply_busy`; 400/500 aplican fracaso |
+| `GET /api/grok/reset-coupons?accountId=...` | Leer los tokens de restablecimiento de facturación Grok restantes y las ventanas de validez para la cuenta xAI activa o especificada | 400 falta la cuenta; 401 no autenticado; 502 error de gRPC-Web en el servidor ascendente |
+| `POST /api/grok/reset-coupons/consume` | Canjee un cupón de reinicio elegible. Cuerpo `{ accountId?, tokenId?, operationId? }`. Opcional `operationId` (UUIDv4) hace que la redención sea idempotente: repetir el mismo ID reproduce el resultado duradero sin doble redención. | 400 inválido JSON /UUID; 401 no autenticado; 409 `operation_id_owned_by_another_account` / `coupon_unavailable` / `operation_token_mismatch` / `operation_state_changed` / `attempt_in_progress` / `attempt_unresolved`; 502 error ascendente; 503 capacidad del libro mayor / `ledger_unavailable`; 500 `attempt_mark_failed` |
+| `GET /api/anthropic/reset-grants?accountId=...` | Lea las concesiones de restablecimiento de límite de uso Claude de una cuenta Anthropic OAuth: elegibilidad, restablece izquierda de cada concesión, ventana de validez y las ventanas que se borra, además de cualquier intento no confirmado todavía reintentable | 400 sin cuenta de juego; 401 Re-autenticación necesaria; 502 aguas arriba no disponible |
+| `POST /api/anthropic/reset-grants/consume` | Gasta una subvención de reinicio. Cuerpo `{ accountId, grantId, operationId }`; `operationId` es un UUIDv4 enviado aguas arriba como el ID de solicitud, por lo que repetirlo vuelve a intentar la misma reivindicación. Requiere una sesión de panel. Un `reset` establecido levanta el tiempo de reutilización local de la cuenta solo cuando es un rechazo de cuota registrado antes de que la reclamación se publicara por primera vez y las ventanas que la subvención informó cubren cada ventana que la negativa nombró (ambas ventanas cuando no nombró ninguna). Una denegación registrada mientras la reclamación estaba en vuelo, una denegación de derecho o una ventana descubierta permanece, incluso en una repetición del mismo ID. La cuota en caché se elimina y el uso se vuelve a leer con una nueva solicitud, por lo que el grupo puede seleccionar la cuenta antes de la fecha límite anterior. Las exclusiones de familias modelo permanecen hasta que esa relectura prueba que una familia ya no es rechazada. | 400 cuerpos inválidos; 401 Re-autenticación necesaria; 403 `session_required`; 409 `grant_not_usable`, `in_flight`, `unresolved_prior_operation`, `unknown_outcome_expired`, `operation_identity_mismatch`; 500 `journal_write_failed`; 502 `unknown_outcome`; 503 diario ocupado, no disponible, o lleno |
+| `GET, PUT /api/claude-desktop` | Lee o guarda el perfil enrutado/nativo y la visibilidad de modelos de Claude Desktop. PUT requiere un `profile` válido, incluso al configurar o borrar `visibility` (omitirlo conserva el valor; `null` lo borra). Un cuerpo que solo incluya visibilidad devuelve 400. | 400 perfil ausente o no válido, asignación no válida o no disponible, visibilidad no válida o que oculte todos los modelos disponibles; 409 cambio del perfil o de la visibilidad enviada durante el descubrimiento/guardado |
+| `POST /api/claude-desktop/apply` | Escribe el perfil guardado en la configuración administrada de Claude Desktop | 400/500 fracaso de escritura |
+| `GET /api/codex/desktop-compatibility/authorization` | Devuelve HTTP 200 con `{ ok: true, supported, authorized, rememberedSession }`; la ausencia de alcance Desktop se informa como `authorized: false` | Solo errores comunes del límite de administración; la falta de alcance Desktop no es un 403 específico de la ruta |
+| `POST /api/codex/desktop-compatibility/authorization` | Consume `{ grant }` de `ocx gui pair --desktop` para la sesión local independiente existente durante un máximo de cinco minutos; devuelve HTTP 200 con `{ ok: true, authorized: true }` | 400 `invalid_json` o `invalid_request`; 403 `desktop_authorization_required` si se rechaza el intercambio, incluidos códigos de emparejamiento ordinarios o remotos y sesiones recordadas del panel |
+| `GET, POST /api/codex/desktop-compatibility/certificate` | Inspeccione o prepare explícitamente el certificado de compatibilidad Windows | 403 `desktop_authorization_required` para POST; 409 estado rancio, ocupado o incompleto |
+| `GET, POST /api/codex/desktop-compatibility/runtime` | Inspeccionar o iniciar, detener, iniciar o ejecutar una prueba de compatibilidad nativa limitada | 403 `desktop_authorization_required` para POST; 409 compilación sin soporte, certificado no confiable o estado incompleto |
+| `GET, POST /api/codex/desktop-compatibility/settings` | Leer o guardar la preferencia de observación del siguiente inicio con su revisión actual | 403 `desktop_authorization_required` para POST; 409 Configuración obsoleta, inválida o no confirmada |
+| `GET /api/claude-desktop/status` | Compara el perfil guardado con el aplicado, consulta el estado de Desktop y devuelve `appliedModels: { name: string; label: string }[] \| null`. Es la lista estática del perfil seleccionado en disco; no verifica el proceso de Desktop. `null` indica que no hay un perfil de pasarela aplicado o una lista estática legible, incluido el modo de solo descubrimiento; no significa que la lista esté vacía. | 400 fallo al leer el estado |
+| `GET, PUT /api/claude-code` | Leer o actualizar la configuración de la puerta de enlace Claude Code, el modo de autenticación, el mapa de modelos, el contexto, el agente y el sidecar | 400 campo o forma no válidos |
+
+`tokenId`, cuando se suministra, debe ser una cadena no vacía; los valores no válidos devuelven `400 invalid_token_id` antes de que se lean las credenciales o se abra el libro mayor. Dentro de la ventana de retención de 30 días, un reintento con el mismo `operationId` que omite `accountId` usa la cuenta registrada, incluso si la cuenta activa cambió. Un reintento ejecutable de `open` que omite `tokenId` usa su token registrado. Una cuenta o un token distintos y explícitos se siguen rechazando. Un fallo definitivo despeja en el panel una retención pendiente especulativa que coincida, lo que permite un nuevo intento confirmado explícitamente; los resultados realmente desconocidos siguen retenidos.
+
+Un intento es reclamado de manera duradera antes de la redención. Solo una respuesta de canje confirmada puede registrar `redeemed`; un cupón que falta en la lista restante no prueba que esta operación haya tenido éxito. Después de un tiempo de espera o de un acuerdo perdido, los reintentos inspeccionan la disponibilidad sin volver a canjear y devuelven `attempt_unresolved`; un intento reciente devuelve `attempt_in_progress`. Una negativa de inspección tardía establece solo una operación `open`. En la misma transacción, un ganador de terminal definitivo que coincida con la identidad se reproduce con HTTP 200 y su código original; un ganador no resuelto o con identidad no coincidente devuelve `operation_state_changed`, preservando la guía de recuperación del mismo ID. Un libro mayor ilegible o bloqueado devuelve `ledger_unavailable` sin enviar una redención.
+
+Una vez que quien llama suministra un `operationId`, toda respuesta que no pueda demostrar que la operación ha quedado resuelta lleva ese `operationId` en el nivel superior y mantiene a quien llama aferrado a él: `attempt_unresolved`, `attempt_in_progress`, `attempt_reconcile_failed`, `operation_state_changed`, `operation_token_mismatch`, `attempt_mark_failed`, `ledger_unavailable` y `capacity` del libro mayor (el libro mayor completo no puede reservar el ID, así que una solicitud anterior que lo retiene todavía podría abrirlo más tarde). Esto incluye los rechazos anteriores a la apertura del libro mayor: un `tokenId` mal formado, una cuenta desconocida o una consulta de cuenta fallida bajo un ID suministrado devuelven 409 `attempt_in_progress` con ese ID, porque otra solicitud puede estar reteniendo ya esa operación. Un rechazo de autenticación definitivo se registra de forma atómica como una operación `failed` vinculada al cupón solicitado, de modo que un reintento la reproduce; una operación existente para un cupón distinto nunca se reproduce. Una lista de reinicios restantes fallida resuelve una operación no reclamada como `fetch_resets_failed`. Una respuesta de canje solo cuenta como confirmada cuando su tramado gRPC-Web está completo y cada `grpc-status` que lleva tiene el mismo valor válido; estados en conflicto o bytes posteriores al tráiler devuelven 502 `attempt_unresolved` y dejan la operación en `attempted`.
+
+Un canje no confirmado devuelve HTTP 502 con `error.code: "attempt_unresolved"` y el `operationId` efectivo. Conserve ese ID; un ID de reemplazo iniciaría una operación distinta. El CLI crea el ID antes de enviar e imprime la guía `--operation-id` si la entrega o la respuesta es incierta. Los registros heredados `open` de la versión 1 y los registros `redeem_failed` no confirmados se ponen en cuarentena como inciertos; nunca autorizan otra redención.
+
+El panel de control en **Prestadores xAI Grok** enumera los cupones restantes y sus ventanas de validez de la insignia de boleto de cada cuenta. Envía un `operationId` acuñado por el cliente. Después de una entrega incierta o una respuesta de resultado desconocido, el panel retiene ese intento para la sesión de pestaña del navegador, incluso en el cuadro de diálogo cerrar / volver a abrir, navegación de página y recarga. La retención se escribe antes de que la solicitud se envíe y se borre solo mediante una respuesta definitiva para el mismo `operationId`. Disponibilidad actualiza el problema GET solamente y nunca autorizar otro consumir POST. `ocx account grok-reset-coupons` es el terminal equivalente.
+
+Los restablecimientos de uso de Claude funcionan de la misma manera en **Providers > Anthropic > Accounts**. Cada cuenta iniciada muestra una insignia con los restablecimientos restantes y el diálogo consume uno tras una segunda confirmación. Las concesiones difieren en vencimiento y en los límites que restablecen: el diálogo preselecciona la concesión utilizable que vence antes, muestra deshabilitadas las concesiones que no se pueden usar en ese momento, junto con el motivo y confirma la concesión elegida, su vencimiento y sus límites antes de enviar el `grantId`. El servidor vuelve a comprobarla y rechaza una concesión inutilizable con `409 grant_not_usable`. El restablecimiento rellena los límites cubiertos por esa concesión (normalmente los de 5 horas y semanales), sin cambiar el día de reinicio semanal. Si una reclamación no responde, el diálogo conserva su `operationId` y ofrece reintentar con el mismo ID durante diez minutos, como hace el cliente Claude Code; hasta entonces se rechaza una nueva operación en esa cuenta para cualquier concesión. El consumo solo está disponible en el dashboard: el token de administración por sí solo recibe `403 session_required`.
+
+Para ver los conceptos detrás de la lista de modelos y el comportamiento cifrado de la tarea del trabajador, consulte [Superficie del subagente](/es/guides/sub-agent-surface/).
+
+<a id="client-integration-rollback-journal"></a>
+
+### Diario de reversión de la integración del cliente
+
+| Método y ruta | Finalidad | Errores notables |
+| --- | --- | --- |
+| `GET /api/client-integrations/journal?client=...` | Lista de operaciones de reversión, opcionalmente para un cliente. Cada fila incluye el indicador `deletable` calculado por servidor. | 400 clientes no válidos |
+| `DELETE /api/client-integrations/journal?opId=...` | Retire una operación de reversión anterior y elimine su instantánea cuando sea posible. El éxito regresa `snapshotRemoved`; `false` significa que se retuvo la limpieza para el reintento de mantenimiento. | Faltan 400 `opId`; 404 operación faltante o ya retirada; 409 nueva operación para ese cliente |
+
+La eliminación agrega una lápida en lugar de reescribir el diario. La operación más reciente para cada cliente está protegida en el lado del servidor, por lo que el punto de deshacer actual permanece disponible. Para Aside, la protección es por perfil, y las filas del diario incluyen `profileId`.
+
+<a id="aside-profile-controls"></a>
+
+### Aside controles de perfil
+
+Utilice estas rutas dedicadas con un proxy compatible. `{profileId}` es un ID de cuenta entero no negativo registrado devuelto por la lista de perfiles; no es una ruta del navegador.
+
+| Método y ruta | Finalidad | Errores notables |
+| --- | --- | --- |
+| `GET /api/client-integrations/aside/profiles` | Lista `profiles[]`, deseado `enabledCount` / `allEnabled`, actual `appliedCount`, y `total` | HTTP 200 puede contener un agregado vacío e inseguro con un `error` cuando el descubrimiento no está disponible |
+| `PUT /api/client-integrations/aside/profiles` | Establezca el estado deseado de cada perfil registrado y aplíquelo; cuerpo `{ "enabled": true }`, con `overwriteConflict` opcional al habilitar | 400 cuerpos inválidos; 409 operación ocupada; 500 preferencia-salvar fracaso; 207 denegaciones por perfil |
+| `GET /api/client-integrations/aside/profiles/{profileId}` | Lea el perfil deseado `enabled` y el estado de integración real | 400 ID no válido; 404 perfil no registrado |
+| `PUT /api/client-integrations/aside/profiles/{profileId}` | Cambiar un perfil con el mismo cuerpo que el PUT a granel, dejando las preferencias de los hermanos sin cambios | 400 cuerpo/ID no válido; 404 perfil desconocido; 409 ocupado o rechazo; 500 fallos de escritura/guardar |
+| `GET /api/client-integrations/aside/profiles/journal` | Historial de listas en todos los perfiles registrados de Aside | Las filas incluyen `profileId`, disponibilidad de instantáneas, `undoable` y `deletable` |
+| `GET /api/client-integrations/aside/profiles/{profileId}/journal` | Enumerar el historial de un perfil, incluidas las operaciones heredadas coincidentes | 400 ID no válido; 404 perfil desconocido |
+| `DELETE /api/client-integrations/aside/profiles/journal?opId=...` | Retirar una operación anterior, resolviendo su perfil de la historia | 400 falta el id; 404 falta la operación; 409 la operación es la más reciente de su perfil |
+| `DELETE /api/client-integrations/aside/profiles/{profileId}/journal?opId=...` | Retirar una operación anterior que pertenezca al perfil seleccionado | Los mismos errores de eliminación; una operación no puede apuntar a un perfil diferente |
+| `POST /api/client-integrations/aside/profiles/{profileId}/restore` | Deshacer una operación usando `{ "opId": "..." }`; opcional `confirmDrift: true` permite reemplazar ediciones posteriores | 404 Falta la operación/perfil; 409 ocupado, desajuste o confirmación de deriva requerida; 410 instantánea expirada; 500 fallos de escritura/guardar |
+| `POST /api/client-integrations/aside/sync` | Actualizar perfiles habilitados a través del propietario de la mutación del servidor; cuerpo `{}` | 400 selector de cuerpo/perfil no vacío; 409 ocupados; 207 denegaciones por perfil |
+
+<a id="previewing-an-integration-change"></a>
+
+## Vista previa de un cambio de integración
+
+Una vista previa informa lo que un cambio haría sin hacerlo. Estas rutas no escriben nada: sin instantáneas, sin registro de propiedad, sin fila de diario, sin bloqueo y sin mantenimiento o recuperación.
+
+| Ruta | Finalidad | Respuestas notables |
+| --- | --- | --- |
+| `POST /api/client-integrations/preview` | Plan `apply`, `overwrite` o `disable` para un cliente; cuerpo `{ "clientId": "...", "operation": "..." }` | 400 cliente no válido u operación; 400 `invalid_aside_profile_path`; 409 `integration_preview_unavailable` |
+| `POST /api/client-integrations/restore/preview` | Planificar un deshacer; cuerpo `{ "opId": "...", "confirmDrift": false }` | 404 operación desconocida; 400 `invalid_aside_profile_path`; 409 `integration_preview_unavailable` |
+| `POST /api/client-integrations/aside/profiles/{profileId}/preview` | Planifique un cambio en el perfil de Aside, incluyendo `restore` con un `opId` | 400 cuerpo inválido o solicitud no especificada; 404 perfil u operación desconocidos, 409 `integration_preview_unavailable` |
+
+Un plan lleva `version`, `clientId`, `operation`, `state`, `foreignEdit`, una lista `changes` de `kind` y `path` pares, un `fingerprint`, `canApply`, `willChange` opaco y un `refusalReason` y `profileId` opcionales. Las rutas son rutas de esquema gestionadas o los marcadores fijos `$snapshot`, `$ownership` y `$journal`; una posición elegida en entorno de ejecución aparece como `*`. No se devuelve ningún valor de configuración, ubicación del archivo o identidad del miembro seleccionado.
+
+`canApply: true` con `willChange: false` significa que la operación tiene éxito y no cambia nada en el documento del cliente administrado, como aplicar lo que ya se aplica.
+
+Un cambio de perfil de Aside aún guarda una cosa en ese caso. Confirmar que registra la preferencia de sincronización deseada para ese perfil antes de que se toque cualquier documento de cliente, deshabilitando así un perfil cuyo bloque administrado ya está ausente almacena la preferencia y deja el documento y su historial intactos.
+
+`integration_preview_unavailable` significa que actualmente no se conserva ninguna lista de modelos utilizables. Un proxy recién iniciado es una forma de estar en ese estado; una lista retirada porque la configuración o la caché del proveedor movida es otra. La lectura `GET /api/client-integrations` establece uno cuando el descubrimiento tiene éxito y la configuración puede ser identificada, por lo que es el remedio habitual en lugar de una garantía.
+
+<a id="confirming-a-previewed-change"></a>
+
+## Confirmar un cambio previsualizado
+
+Las rutas de mutación aceptan `operation` y `planFingerprint` junto con su cuerpo existente. Envíe ambos o ninguno: se rechaza una solicitud que lleve uno, al igual que una cuya `operation` no esté de acuerdo con el cambio solicitado. Aparte de las vinculaciones se aplican a un solo perfil, porque una huella dactilar no puede describir varios archivos que cambian independientemente.
+
+El servidor vuelve a planificar antes de escribir nada y devuelve `409 integration_preview_stale` con un `plan` recién calculado cuando la confirmación ya no describe lo que sucedería. Decidir de nuevo en contra del nuevo plan; la solicitud no se vuelve a intentar automáticamente.
+
+Una huella digital es un cheque optimista, nunca una autorización. La autenticación de la administración y cada regla de propiedad aún deciden si un cambio puede ocurrir.
+
+Bulk PUT devuelve `{ ok, clientId, changed, state, message, results }`; cada resultado identifica su `profileId` e informa el resultado del escritor. La sincronización devuelve `{ ok, clientId, results }`, con resultados de actualización por perfil. Ambos devuelven HTTP 200 cuando todos los intentos devueltos tienen éxito y HTTP 207 con `ok: false` cuando cualquier intento se niega. HTTP 207 es un sobre de resultado parcial, incluso cuando todos los intentos de perfil se niegan: inspeccione cada resultado en lugar de tratar una respuesta 2xx como un éxito completo. Un no-op exitoso puede tener `changed: false`; la sincronización no intenta desactivar los perfiles. El perfil único escribe y restaura el retorno HTTP 200 en caso de éxito o el estado de error correspondiente en caso de rechazo.
+
+Los cambios explícitos guardan las preferencias deseadas antes de escribir archivos. Un fallo de guardado de preferencias deja los archivos de perfil sin cambios. Un rechazo de archivo posterior preserva la intención guardada y escribe con éxito; inspeccione el perfil afectado antes de volver a intentarlo. Los rechazos pueden incluir `snapshotPath` y `residual: true` cuando la recuperación no terminó. Restaurar también reconcilia el estado deseado del perfil de destino, por lo que la siguiente sincronización no invierte Deshacer. Devolución `snapshotRemoved`; `false` significa que la limpieza de instantáneas aún necesita mantenimiento.
+
+Los alias heredados `GET, PUT /api/client-integrations/aside` siguen disponibles. Los clientes nuevos deben usar las rutas dedicadas anteriores para que un proxy antiguo no pueda ignorar un selector de perfil. Consulte [Aparte de controles de perfil](/es/guides/integrations/#aside-profile-controls) para ver las órdenes CLI y la secuencia de actualización, reinicio y reintento del proxy.
+
+<a id="remote-workspace"></a>
+
+### Espacio de trabajo remoto
+
+Requiere el modo Hub y `OCX_REMOTE_WORKSPACE_ENABLED=1` en el proceso Hub. El estado de deshabilitado es legible; las mutaciones se niegan sin inicializar los servicios del espacio de trabajo.
+
+| Método y ruta | Finalidad | Errores notables |
+| --- | --- | --- |
+| `GET /api/remote-workspace` | Lea equipos emparejados, capacidades actuales, tiempos de ejecución de Hub e instantáneas de sesión | Estado desactivado cuando el rol de Hub o el opt-in explícito están ausentes |
+| `POST /api/remote-workspace/pairing` | Crear un código de inscripción de un solo uso de diez minutos | Sesión de GUI emparejada por el operador solamente; 429 capacidad de emparejamiento |
+| `GET /api/remote-workspace/runtimes` | Leer Codex, Claude Code, y la disponibilidad de Pi en el Hub | — |
+| `GET, POST /api/remote-workspace/sessions` | Listar sesiones o iniciar una vinculada a un dispositivo, root, tiempo de ejecución y modo de acceso | POST requiere una sesión de GUI emparejada por el operador; 409 objetivo fuera de línea/no disponible/no válido |
+| `POST /api/remote-workspace/sessions/{id}/prompt` | Continuar la sesión del modelo vinculado | Sesión de GUI emparejada por el operador solamente; 409 turno activo, ejecutor sin conexión o falla de reanudación |
+| `DELETE /api/remote-workspace/sessions/{id}` | Detener el tiempo de ejecución del modelo y la sesión de Ejecutor encriptado | Sesión de GUI emparejada por el operador solamente; 404 sesión desconocida |
+| `DELETE /api/remote-workspace/devices/{id}` | Revocar una computadora y detener sus sesiones | Sesión de GUI emparejada por el operador solamente; 404 - Artículo no encontrado |
+
+La inscripción del ejecutor intercambia un código de un solo uso en `POST /remote-workspace/pair` y luego abre `/remote-workspace/agent` como un WebSocket saliente autenticado por el portador. Esos dos puntos finales de máquina no son la autoridad de gestión general API. El portador tiene alcance de dispositivo, y cada sesión de trabajo agrega un apretón de manos E2EE firmado. Diez códigos de emparejamiento fallidos de un retorno de pares observado en el núcleo `429` con `Retry-After` para el resto de la ventana fija de diez minutos. Los clientes de Tailscale Serve comparten el bucket de pares de loopback del oyente de administración; el encabezado de identidad no se usa para la regulación porque un proceso local directo podría forjarlo. Consulte [Espacio de trabajo remoto](/es/guides/remote-workspace/) para conocer los límites de confianza y flujo del usuario final.
+
+Las instantáneas de sesión incluyen `resumable`. Se vuelve cierto sólo después de que el entorno de ejecución del agente de codificación seleccionado tenga un historial duradero; en particular, una nueva sesión Claude Code permanece falsa hasta que se complete su primer aviso.
+
+### Combos
+
+| Método y ruta | Finalidad | Errores notables |
+| --- | --- | --- |
+| `GET /api/combos` | Lista de combos normalizados y sus ID de modelo público | El trabajo del catálogo puede devolver `catalog_busy` |
+| `PUT /api/combos` | Crea, sustituye o renombra un combo. | 400 si el identificador, destino, configuración o cambio de nombre son inválidos, o hay una colisión ordinaria; un 400 de validación también identifica el primer campo superior inválido en `field`, por ejemplo `targets` o `decisionProvider`. 409 si hay colisión con el espacio de nombres de una cuenta Codex. |
+| `DELETE /api/combos?id=...` | Eliminar un combo y borrar su estado de selección/enfriamiento | 400 id ausente; 404 combo desconocido |
+
+Consulte [Combos](/es/guides/combos/) para conocer las estrategias de destino, los tiempos de reutilización, los alias y los fallos de enrutamiento.
+
+<a id="codex-prompt-layers"></a>
+
+### Capas de aviso Codex
+
+| Método y ruta | Finalidad | Errores notables |
+| --- | --- | --- |
+| `GET /api/codex-prompt` | Lea la instantánea de la capa de solicitud: capas, variantes base, selección y estado de deriva | — |
+| `GET /api/codex-prompt/text` | Sondear el texto visible por el modelo mediante `codex debug prompt-input`; un único presupuesto por cliente incluye metadatos, espera compartida y ejecución; los metadatos síncronos se comprueban al regresar por si venció el plazo | Un sondeo no disponible degrada a un estado en el cuerpo, no a un error HTTP; el timeout conserva las instrucciones base leídas localmente; una cancelación externa anterior sigue cancelada |
+| `PUT /api/codex-prompt/toggle` | Habilitar o deshabilitar una capa conmutable | 400 cuerpo inválido o capa desconocida; 409 `stale_revision`, `layer_not_toggleable` |
+| `PUT /api/codex-prompt/custom` | Reemplazar el conjunto de capas personalizadas | 400 cuerpo inválido, `invalid_characters`, `body_too_large` cuando una capa UTF-8 normalizada excede 65.536 bytes, `composed_too_large` sobre 131.072 bytes; 409 `stale_revision` |
+| `PUT /api/codex-prompt/base/select` | Seleccione el indicador de base predeterminado o una variante almacenada | 400 cuerpo no válido, `unknown_layer` para una identificación que no coincide con ninguna variante almacenada; 409 `stale_revision`, `developer_instructions_not_owned` cuando la base actual es externa |
+| `PUT /api/codex-prompt/base` | Crear (`id` omitido o `id: null`), editar o eliminar (`delete: true`) una variante base. Un `id` suministrado es solo de edición y debe hacer referencia a una variante almacenada. `body` se normaliza (pestañas expandidas, CR/CRLF doblado a LF) antes de medirse o almacenarse | 400 cuerpo inválido, `unknown_layer` para el id `default` o un id que no coincide con ninguna variante almacenada, `body_too_large` cuando el cuerpo UTF-8 normalizado excede 65.536 bytes; 409 `stale_revision` |
+| `POST /api/codex-prompt/adopt` | Importar `developer_instructions` desde `config.toml` como capa personalizada | 400 cuerpo inválido, `invalid_characters`, `body_too_large`, `composed_too_large`; 409 `config_unreadable`, `nothing_to_adopt`, `adopt_unsupported_form`, `stale_revision` |
+| `POST /api/codex-prompt/repair` | La deriva de reparación entre `config.toml` y la proyección propia | 400 cuerpos inválidos; 409 `config_unreadable`, `nothing_to_repair`, `repair_unsupported`, `stale_revision` |
+
+Vea [Codex capas de solicitud](/es/guides/codex-prompt/) para el modelo de capa y las claves que escribe cada capa.
+
+<a id="configuration-startup-sync-and-updates"></a>
+
+### Configuración, inicio, sincronización y actualizaciones
+
+| Método y ruta | Finalidad | Errores notables |
+| --- | --- | --- |
+| `GET /api/config` | Devolver el DTO de configuración redactado y seguro para la administración | — |
+| `PUT /api/config` | Deshabilitado protector de reemplazo de configuración completa | 405; use endpoints enfocados en su lugar |
+| `GET, PUT /api/settings` | Lea la configuración de tiempo de ejecución/arranque o actualice el inicio automático, el modo de transmisión, el presupuesto de memoria propiedad de la aplicación y `codexAccountPickerEnabled` | 400 actualización no válida, no objeto o vacía |
+| `GET, PUT /api/native-reasoning-retention` | Leer resuelto booleanos modelo/cuenta razonamiento-retención; PUT parcial conserva campos omitidos, JSON `null` restaura valores predeterminados. Véase [Retención de razonamiento nativo](/es/reference/configuration/server/#native-reasoning-retention). | 400 campo desconocido, tipo no válido o cuerpo no-objeto/no-nulo |
+| `GET, PUT /api/workflow-budget/settings` | Leer los límites efectivos por tarea, sus valores predeterminados y rangos permitidos; un PUT parcial conserva los campos omitidos y JSON `null` restaura los predeterminados. Consulta [Límites del flujo de trabajo](/es/reference/configuration/server/#workflow-limits). | 400 campo desconocido, valor no entero o fuera de rango, o cuerpo que no sea objeto ni null |
+| `GET /api/startup-health` | Leer servicio en caché/salud de inicio de shim | — |
+| `POST /api/startup-action` | Instalar o reparar el servicio o la cuña Codex | 400 acciones inválidas; Fracaso de 500 acciones |
+| `GET, POST /api/windows-tray` | Leer el estado de la bandeja Windows o instalar/iniciar/detener/desinstalar | 400 plataforma/acción no soportada; 500 fallo de operación |
+| `GET /api/diagnostics/project-config` | Leer las advertencias de configuración del proyecto en caché | — |
+| `POST /api/sync` | Sincronice el catálogo de modelos actual en Codex | 500 sincronización fallida |
+| `GET /api/update/check` | Compruebe de forma asíncrona el canal de paquetes `latest` o `preview` y actualice la caché del paquete en caso de éxito | 400 etiqueta inválida |
+| `POST /api/update/run` | Comprobar de forma asíncrona una versión nueva e iniciar su actualización, opcionalmente seguida de reinicio | 400 cuerpo inválido; 409 `update_restart_unsupervised` si el proxy se ejecuta dentro de una unidad systemd distinta del servicio de usuario de OpenCodex, o el proceso de actualización no puede salir de su cgroup (con o sin reinicio, porque la actualización detiene primero el proxy); otros estados de conflicto o error del trabajo |
+| `GET /api/update/status` | Consultar periódicamente un trabajo de actualización por su id | 404 trabajo desconocido |
+| `GET, PUT /api/sidecar-settings` | Lea o actualice la configuración del modelo/backend del sidecar de la visión y la búsqueda web | 400 forma inválida, backend o límite |
+| `GET, PUT /api/shadow-call-settings` | Leer o actualizar la interceptación de llamadas de sombra, incluido `sourceModels`; GET también devuelve el inventario `sourceModelOptions` del entorno | 400 forma o valor inválido, incluidos prefijos vacíos, duplicados, con espacios o proveedor, más de 32 prefijos o más de 128 caracteres por prefijo; los fallos de lista llevan `code: shadow_call_source_invalid` y los conflictos de destino `code: shadow_call_target_invalid` |
+
+<a id="logs-usage-and-storage"></a>
+
+### Registros, uso y almacenamiento
+
+Los registros de solicitud retienen `servedModel` cuando el flujo ascendente identifica el modelo que respondió, y `wireModel` cuando el modelo enviado flujo ascendente difiere del modelo orientado al cliente. El panel de control muestra `wire → served` cuando esas identidades difieren; su descripción conserva ambos valores. La evidencia del modelo ascendente faltante permanece ausente en lugar de inferirse del modelo solicitado.
+
+Las filas de solicitudes fallidas pueden incluir diagnósticos `upstreamErrorType`, `upstreamErrorCode` y `upstreamRequestId`. En la ruta Codex aguas arriba WebSocket, un error desnudo seguido de EOF retiene los códigos de límite de velocidad, sobrecarga o rechazo de cliente reconocidos en el terminal fallido sintetizado. Los registros de solicitudes registran estos como 429 para `rate_limit_exceeded` / `rate_limit_error`, 503 para `server_is_overloaded` / `overloaded_error`, y 400/401/403/404 para `invalid_request_error` / `authentication_error` / `permission_error` / `not_found_error`. Un tipo reconocido sin un código usa el mismo estado. En la ruta de transmisión, un código explícito desconocido registra el estado 5xx de la envoltura Codex WebSocket como un entero de nivel superior `status` o `status_code` (uno de los dos, no ambos); de lo contrario, y para los llamantes JSON almacenados en memoria intermedia, sigue siendo un fallo genérico 502. El terminal de cliente mantiene `upstream_server_error` para códigos desconocidos de cualquier manera. El estado de error desnudo es provisional: un terminal genuino completado, fallido o incompleto lo reemplaza antes de la grabación de salud de la cuenta. La prioridad de rechazo no cambia. Este mapeo de diagnóstico no agrega reproducción o reintento automático.
+
+`GET /api/logs` acepta un opaco opcional `cursor` de su respuesta anterior. La envoltura conserva `logs`, `total`, `generatedAt` y `timeZone`, y añade `cursor` y `reset`. Sin un cursor devuelve la ventana filtrada completa. Un prefijo válido sin cambios devuelve solo las filas anexas; `reset: true` reemplaza la ventana del cliente después de editar, desalojar, consultar cambios o reiniciar. Los cursores no válidos devuelven HTTP 400 con `error.code: "invalid_cursor"`. La autenticación no ha cambiado. El panel de control vuelve a las instantáneas completas de los servidores más antiguos. Esto reduce los bytes de respuesta para ventanas estables; la proyección del servidor permanece limitada por el tamaño de ventana actual.
+
+Los valores `/api/logs` `displayMetrics.decodeTokPerSecond` exitosos llevan `timingBasis: "generation-window" | "legacy-post-visible-output"` junto con `kind`, `value` y `estimated: true`; los valores de intento identifican su propia ventana. Los resultados no disponibles mantienen su `reason` existente y sin base de tiempo. El campo se deriva solo en el tiempo de lectura: el JSONL almacenado, el `tokPerSecond` de extremo a extremo, los DTO de historial de solicitudes y el rendimiento agregado no cambian. Los DTO más antiguos pueden omitir el campo; los clientes deben tratar la base de tiempo como desconocida en ese caso. El panel de control nombra estos métodos **Ventana de generación** y **Después de la salida visible**, con **Tiempo desconocido** para una base faltante o desconocida. Los detalles de la solicitud muestran **Velocidad de salida durante la generación (est.)**, **Velocidad de salida después de la primera salida visible (est.)** o **Tasa de salida (est.; método de temporización desconocido)** y una explicación visible del método de temporización cuando hay una tasa disponible.
+
+| Método y ruta | Finalidad | Errores notables |
+| --- | --- | --- |
+| `GET /api/logs` | Registros de solicitud en memoria filtrados por consulta | — |
+| `GET, PUT /api/debug` | Leer indicadores de depuración; establecer, borrar o restablecer categorías de captura | 400 actualización no válida o vacía |
+| `GET /api/debug/logs` | Leer entradas de registro de proveedor/debug limitadas | — |
+| `GET /api/debug/usage-logs` | Leer entradas de depuración de uso limitadas | — |
+| `GET /api/debug/injection-logs` | Leer las entradas de depuración de inyección de guía limitadas | — |
+| `GET /api/claude/inbound-debug` | Leer el estado y las entradas de depuración entrantes Claude | — |
+| `GET /api/usage` | Escanee el libro mayor de uso en agregados compactos de filas legibles, luego pliegue gradualmente los apéndices verificados; resuma por ventana personalizada preestablecida o inclusiva y superficie del cliente, con un desglose de `accounts` Codex codificado por etiquetas de registro no PII estables. | 400 límites personalizados no válidos; 500 `{ "error": "read_failed" }` si el almacenamiento no se puede leer |
+| `GET /api/usage/devices` | Enumera los IDs y alias actuales de claves Remote Link para una sesión de dashboard autorizada | 403 sin la sesión requerida; 503 si no se puede leer el almacén de enlaces |
+| `GET /api/usage/source-facets` | Cuenta opciones recientes de aplicación y dispositivo para una sesión autorizada | 400 filtros inválidos; 403 sin la sesión requerida; 503 si el escaneo o inventario no está disponible |
+| `GET /api/usage?jev=1` | El proyecto persistía las decisiones JEV y su objetivo físico envía. Opcional `comboId` selecciona un Combo; `range` acepta `7d`, `30d` o `all` (por defecto `30d`). | 400 inválido `comboId`; 500 `{ "error": "read_failed" }` si el libro mayor no se puede leer |
+| `GET /api/usage/timeline` | Uso por modelo/cuenta; acepta `hours`, `bucketMinutes`, `metric`, `aggregation`, `grouping`, `models` separados por comas y filtros `hiddenProvider` repetidos | 400 consultas o límites no válidos |
+| `GET /api/metrics` | Devuelve métricas de texto de Prometheus locales para solicitudes y cuota Kiro en caché. Kiro cuentas utilizan etiquetas de resumen opacas limitadas; los identificadores de cuentas y credenciales en bruto nunca se exportan. | 404 cuando `metricsExport.enabled` no era cierto al inicio; se requiere autenticación de administración ordinaria y las credenciales del plano de datos no otorgan acceso |
+| `GET /api/storage` | Escanear el uso de almacenamiento Codex por cubo | Devuelve una carga útil de `error: "scan_failed"` en caso de error de escaneo |
+| `POST /api/storage/cleanup/preview` | Vista previa de la limpieza de la sesión archivada y devuelve un resumen vinculante | 400 `invalid_json` o `invalid_percent` |
+| `POST /api/storage/cleanup` | Cuarentena o eliminar permanentemente el conjunto archivado previamente | 400 entradas no válidas; 409 estado viciado/ocupado/referenciado; 500 sistema de archivos/error de base de datos |
+| `GET /api/storage/trash` | Lista de entradas de limpieza en cuarentena | 500 `trash_list_failed` |
+| `POST /api/storage/trash/restore` | Restaurar una entrada en cuarentena | 400 identificación inválida; Error 404: Faltan los archivos 409 conflicto ocupado/destino; 500 falla de restauración |
+| `GET /api/storage/trash/restore/test-stream` | Gancho de corriente de restauración de solo prueba | 404 `not_available` cuando los ganchos de prueba están apagados |
+| `GET, PUT /api/storage/cleanup-policy` | Leer o actualizar la política de limpieza programada y el estado del trabajo | 400 Política inválida |
+| `POST /api/storage/cleanup-policy/run` | Iniciar una ejecución manual de política de limpieza | 409 `already_running`; 500 `cleanup_failed` |
+| `GET /api/storage/cleanup-policy/test-stream` | Solo prueba de la política de flujo de gancho | 404 `not_found` cuando no está disponible |
+
+Los identificadores del modelo de línea de tiempo se dividen en la primera barra, por lo que se admiten los identificadores nativos anidados, como `github-models/openai/gpt-4.1`. Las exclusiones del proveedor se aplican antes de que el exceso de series se pliegue en `other`; el objeto aditivo `appliedFilters` se hace eco de los filtros de modelo/proveedor normalizados. La cubeta final incluye el intervalo parcial actual. Los ajustes complementarios no se aplican implícitamente a las llamadas generales API.
+
+`GET /api/metrics` devuelve `Content-Type: text/plain;version=0.0.4`. Los contadores e histogramas se reinician cuando se reinicia el proceso; `opencodex_metrics_process_start_time_seconds` identifica ese límite. Los cubos del histograma son acumulativos y terminan con `le="+Inf"`, igual a la cuenta de la familia.
+
+| Familia métrica | Etiquetas | Descripción |
+| --- | --- | --- |
+| `opencodex_logical_requests_total` | `protocol`, `result` | Una observación por solicitud lógica finalizada. |
+| `opencodex_physical_sends_total` | `protocol` | El flujo ascendente real envía sumas de intentos finalizados. |
+| `opencodex_recoveries_total` | `protocol`, `recovery` | Diferentes tipos de recuperación observados por intento, proyectados a una clase cerrada. |
+| `opencodex_request_failures_total` | `protocol`, `cause` | Solicitudes finalizadas que no entregaron respuesta, por la causa que derivó la grabadora. Solo contra; ningún histograma lleva una causa. |
+| `opencodex_request_duration_seconds` | `protocol`, `result` | Histograma de duración de cubo fijo para solicitudes finalizadas. |
+| `opencodex_ttft_seconds` | `protocol`, `result` | Histograma TTFT de cubo fijo para solicitudes con primera salida observada. |
+| `opencodex_ttft_missing_total` | `protocol`, `result` | Conteo complementario para solicitudes sin TTFT observado. |
+| `opencodex_metrics_process_start_time_seconds` | Ninguno | Límite de reinicio local del proceso. |
+| `opencodex_kiro_quota_{used_credits,limit_credits,used_percent,seconds_to_reset}` | `account` (opaco `o` más seis dígitos hexadecimales; como máximo 32 cuentas reales distintas) | Lecturas de plan Kiro en caché coincidentes con identidad. Las lecturas faltantes, rancias, de fecha futura o pasadas por reajuste no emiten muestras; el raspado nunca escudriña aguas arriba. |
+
+La etiqueta `recovery` toma una de un conjunto fijo de clases: `transient`, `connection`, `credential`, `rate_limit`, `quota`, `policy`, `ciphertext`, `payload`, `empty_completion`, `effort_downgrade`, `fast_downgrade` y `other`. El conjunto de recuperación está cerrado; Kiro Los indicadores de cuotas usan solo la etiqueta de resumen de cuenta opaca descrita anteriormente, nunca un identificador de cuenta en bruto. `fast_downgrade` registra un rechazo rápido Anthropic reparado a velocidad estándar; es distinto de la clase `effort_downgrade` de esfuerzo de razonamiento. `rate_limit`, `quota`, `policy` y `ciphertext` están separados porque la respuesta del operador difiere: esperar el límite, pasar a otra cuenta, cambiar el mensaje o dejar caer el estado cifrado obsoleto. Una mancha de razonamiento opaca rechazada cuenta como `ciphertext` en lugar de `payload`.
+
+Si una fila escaneada excede el límite de tamaño del analizador existente, `GET /api/usage` y `GET /api/keys` mantienen los agregados de la fila legible y agregan `usageIncomplete: true` con `usageIncompleteReason: "oversized_rows"` al nivel de respuesta. Este diagnóstico sobrevive a las respuestas almacenadas en caché y añade incrementales, incluidos los resultados vacíos o no coincidentes; una reconstrucción lo vuelve a calcular. Ningún proveedor, modelo o identificador de clave API se acorta para hacer un ajuste de fila. Una bandera ausente no es prueba de que todos los registros del libro mayor fueran válidos. Esto está separado de `historyTruncated`, `entriesTruncated` y cobertura de medición de token.
+
+La proyección JEV informa de recuentos y puertas de decisión, aplicados frente a elecciones abiertas por error, latencia/confianza de decisión, tokens de decisión informados con TypeSafe, recuentos de envío de destino físico, totales de token/caché de modelo disponibles, selecciones de esfuerzo de razonamiento y solicitudes enviadas a un objetivo que no sea la elección inicial de JEV. `attempts` se suman de cada intento persistente `sendCount`; una fila de envío cero no es una reserva. Un objeto de uso reportado se cuenta una vez incluso cuando se vuelve a intentar, por lo que el recuento de intentos medidos puede ser menor que el recuento de envíos físicos. La cardinalidad del modelo está limitada; una fila explícita de desbordamiento agrega identidades adicionales sin dejar caer los totales de resumen.
+
+Las estadísticas JEV utilizan el mismo libro mayor de solo apéndice `usage.jsonl` y escáner cooperativo como uso ordinario. Las lecturas en frío escanean el libro mayor actual, las encuestas sin cambios no leen ningún archivo y el crecimiento verificado dobla solo el sufijo adjunto. Las solicitudes idénticas simultáneas comparten una exploración. El registro JEV persistente está cerrado y libre de contenido: ID combinado, proveedor/modelo/esfuerzo seleccionado, puerta de decisión, latencia, confianza/probabilidad opcional y uso de decisión numérica opcional. Nunca almacena mensajes, encabezados, credenciales, argumentos de herramientas o respuestas TypeSafe sin procesar. Las filas sobredimensionadas conservan el mismo diagnóstico positivo `usageIncomplete` que el punto final de uso ordinario.
+
+Los nuevos intentos xAI en `usage.jsonl` incluyen un tiempo de solicitud `credentialSource`: `grok-oauth` para el transporte de llaves resuelto Grok CLI OAuth, o `xai-api-key` para el transporte público xAI API. Esta etiqueta fija no contiene credenciales ni identificador de cuenta. Pertenece a cada elemento en `attempts`, por lo que el total de tokens agregados de un combo no debe atribuirse a su proveedor final. Los destinos personalizados y las filas históricas omiten el campo; los consumidores no deben inferir el uso de la suscripción desde la configuración actual, el nombre del modelo o la clave entrante API. El registro informa el uso, no los montos de la factura de suscripción.
+
+Los intentos de clave API también registran `accountLogLabel` como `k` seguido de 32 dígitos hexadecimales en minúsculas. La etiqueta es los primeros 128 bits de SHA-256 sobre
+`JSON.stringify(["ocx-key-account-v1", providerName, entryId ?? null, reference])`. La referencia es el valor de clave configurado que se captura para la solicitud física, antes de la resolución del entorno o del llavero. Las claves sin procesar, las referencias y los identificadores de grupo no se escriben en el campo de etiqueta. Un consumidor puede derivar la misma etiqueta de su configuración local sin resolver secretos. Cambiar una clave o referencia literal cambia la etiqueta; sustituir el secreto detrás de una referencia sin cambios mantiene la misma cuenta lógica. Los registros sin etiquetar más antiguos no se pueden atribuir de forma fiable.
+
+La selección de claves se registra después de que las solicitudes en cola se han reconstruido para la selección actual. Cuando un reintento cambia claves, `attempts` retiene un registro separado para la clave anterior, incluyendo el uso reportado de respuestas fallidas. El uso faltante sigue sin ser reportado. Los terminales adaptadores encaminados se observan antes de que los bucles de imagen/búsqueda o las protecciones de continuación combinen su uso. Los consumidores suman los intentos planos por proveedor / cuenta y no vuelven a agregar el combo total de padres. Estos registros identifican el uso; los porcentajes de cuotas de proveedores permanecen separados de las observaciones anteriores.
+
+`GET /api/usage` lee `~/.opencodex/usage.jsonl` desde el principio hasta la instantánea del libro mayor actual en un arranque en frío. Procesa fragmentos fijos de 1 MiB y conserva el estado agregado compacto en lugar de cada fila de solicitud normalizada. Las actualizaciones posteriores validan el límite de línea anterior y solo doblan filas completas recién añadidas. Las llamadas simultáneas comparten la misma actualización. Los predicados de rango y superficie se aplican al agregado de la fila legible, por lo que la ventana de bytes de lectura anterior y la tapa de la fila analizada no pueden omitir un prefijo de archivo anterior de los totales de 7 días, 30 días o todos los historiales. `managementUsageMaxReadBytes` sigue siendo aceptado para la compatibilidad con lectores heredados limitados, pero cambiarlo ya no expande o reduce el historial resumido por este punto final.
+
+Pase `since` y `until` para seleccionar un intervalo personalizado inclusivo. Cada uno acepta la época Unix de enteros **milisegundos**, o una fecha ISO completa con una zona horaria explícita. Se rechazan las fechas no válidas, los valores negativos o fuera de rango, los límites invertidos y un único límite. Los límites personalizados anulan `range`; la respuesta mantiene el campo preestablecido `range` para compatibilidad y agrega `customWindow: true`, el `since` exacto y `until`. `generatedAt` sigue siendo el momento en que se produjo el informe.
+
+Las ventanas personalizadas filtran las entradas del libro mayor individuales antes de la agregación diaria, incluidos los primeros y últimos días parciales. Conservan los filtros `surface`, `provider`, `model` y `apiKeyId` y nunca reutilizan o sobrescriben los resúmenes preestablecidos sin filtrar. El gráfico diario permanece limitado a 366 días calendario locales; los totales cubren el intervalo completo solicitado. Los campos de ventana instantánea describen el libro mayor escaneado antes del filtro de tiempo, para que puedan extenderse más allá de los límites solicitados.
+
+La página Uso acepta entradas locales de fecha/hora. Su minuto final seleccionado incluye todo el minuto hasta `:59.999`. Elegir un ajuste preestablecido o borrar la ventana personalizada restaura el comportamiento del ajuste preestablecido. Esto agrega una selección exacta del rango y estimaciones de costos existentes; no agrega depósitos de gráficos por hora ni informes fuera de línea.
+
+El libro mayor en entorno de ejecución es solo para anexar. Reemplazarlo o truncarlo, o cambiar los precios locales / entradas de zona horaria, desencadena una reconstrucción completa. Si edita manualmente una fila anterior en su lugar mientras el proxy se está ejecutando, reinicie el proxy (o reemplace el archivo) antes de confiar en el nuevo total; las actualizaciones incrementales verifican el límite del apéndice, no todos los bytes agregados previamente.
+
+La respuesta todavía incluye `historyTruncated`, `truncatedPrefixBytes`, `entriesTruncated` y `entriesDropped` para que los clientes más antiguos puedan consumir la misma forma de cable. Un escaneo de libro entero exitoso reporta `false`, `0`, `false` y `0`, respectivamente. Estos son campos de compatibilidad heredados, no una señal de que el punto final lee solo una cola de tamaño configurado.
+
+Para `GET /api/usage?range=30d&surface=codex`, `accounts` contiene una fila por cada etiqueta de grupo Codex observada. Cada fila reporta `accountLogLabel`, totales de tokens, `usageCoverageRatio` y un `estimatedCostUsd` opcional basado en el precio de visualización actualmente configurado. Las superposiciones del usuario activo `modelCosts` tienen prioridad sobre el catálogo verificado incluido y las reservas de precios, y el uso histórico se vuelve a estimar a partir del precio activo cuando se lee el resumen. Esta es una estimación equivalente a la API, no un cargo por suscripción. Las nuevas solicitudes del grupo principal usan la etiqueta reservada `main`; las filas `openai` desnudas heredadas permanecen en un cubo ambiguo en lugar de reasignarse de la configuración actual.
+
+Los precios de los modelos manuales también se pueden editar desde **Modelos → Precio**. Una insignia de precio manual sobrevive a las recargas de catálogo. Los precios se almacenan en `providers.<name>.modelCosts` y sobreviven a la sincronización del catálogo. Tasas de usuario explícitas de todo cero significan una estimación conocida de cero; **Restablecer a automático** elimina la anulación y restaura el catálogo habitual. Estos siguen siendo estimaciones de pantalla, no facturas.
+
+`GET /api/providers/{provider}/model-costs` devuelve `{ provider, modelCosts }`, con entradas de cuatro velocidades desinfectadas y su directiva opcional `promptLengthPricing`, tecleada por el ID exacto del modelo ascendente. `PUT` en la misma ruta acepta `{ modelId, cost }`, donde `cost` contiene `{ input, output, cacheRead, cacheWrite }` y opcionalmente `promptLengthPricing`, o es `null` para reiniciar. Las cuatro tarifas deben ser números finitos de 0 a 1,000,000, en USD por tokens de 1M. Los campos desconocidos y las tasas malformadas son rechazadas. Una escritura conserva las anulaciones de otros modelos y devuelve `{ ok: true, provider, modelId, cost }`; reset devuelve `cost: null`.
+
+El cuadro de diálogo **Precio del modelo** ofrece **Automático**, **Tarifa fija** y **Umbral personalizado** precios de duración rápida. Automático (también el valor predeterminado cuando la directiva está ausente) conserva las reglas de contexto de catálogo con las tasas base guardadas. Flat desactiva los ajustes de contexto. Custom selecciona cuatro tarifas alternativas absolutas utilizando un número entero seguro positivo `thresholdTokens` y `comparison` (`"gt"` para `>`, `"gte"` para `≥`). Todos los tokens de prompt cuentan, incluidas las lecturas y escrituras en caché; la salida no. Las tarifas seleccionadas se aplican a toda la solicitud, incluida la salida, no solo a los tokens en exceso. Custom reemplaza la regla de contexto del catálogo tanto por debajo como por encima de su umbral. Las tarifas personalizadas son tarifas de velocidad estándar: se aplica un ajuste rápido / prioritario aplicable una vez después de la selección de la tarifa y sigue la relación de prioridad del catálogo para ese modelo. Solo un modelo cuya relación de catálogo es `lower-bound` informa `priorityLowerBound: true`; un modelo sin regla de catálogo aplica cualquier multiplicador de prioridad una vez. `{ "mode": "automatic" }` se acepta en la escritura y se almacena como una política ausente, por lo que los recibos GET y PUT nunca lo contienen. **Restablecer a automático** elimina toda la anulación, incluidas las tasas base y la política. Ver el [ejemplo de configuración](../configuration/providers/#prompt-length-pricing).
+
+```bash
+ocx models price ollama/custom-model --json
+ocx models set-price ollama/custom-model --input 0.50 --output 1.50
+ocx models set-price ollama/custom-model --input 0 --output 0
+ocx models set-price ollama/custom-model --auto
+```
+
+Omitió CLI tasas de lectura en caché/escritura en caché predeterminadas a cero. Use `--cache-read` y `--cache-write` para establecerlos explícitamente. Un nombre de proveedor sigue siendo una identidad de configuración exacta; las etiquetas de visualización de cuentas no son nombres de proveedor editables.
+
+Las filas en `models`, `providers` y `days[].models` también llevan `cacheHitRate`: la parte de tokens de entrada servidos de la memoria caché del proveedor, sujetada a `[0, 1]`. Es `null` - nunca `0` - cuando el proveedor informó que no hay telemetría de caché o la fila no tiene tokens de entrada, porque "no hay datos de caché" y "una tasa de éxito genuina del 0%" son hechos diferentes y un gráfico que los hace similares es engañoso.
+
+:::caution
+Los puntos finales de limpieza de almacenamiento pueden mover o eliminar permanentemente los datos de sesión archivados. Siempre vista previa primero y presentar el resumen devuelto. Prefiera la cuarentena cuando sea necesaria la recuperación.
+:::
+
+Los manifiestos de recuperación de limpieza se publican atómicamente, conservando el registro completo anterior si un reemplazo falla antes de la publicación. Esto no revierte una purga permanente: la restauración aún puede fallar cuando una sesión grabada no tiene ningún archivo de implementación sobreviviente.
+
+<a id="models-and-catalog"></a>
+
+### Modelos y catálogo
+
+| Método y ruta | Finalidad | Errores notables |
+| --- | --- | --- |
+| `GET /api/catalog` | Devuelve el documento de catálogo Codex instalado. Los clientes remotos deberían preferir el plano de datos `GET /v1/catalog`, que aún requiere una credencial de plano de datos ordinaria pero no un token de administración. | 404, catálogo no encontrado |
+| `GET /api/models` | Devolver el tablero de instrumentos/ filas del modelo CLI | `catalog_busy` cuando la recolección está saturada |
+| `GET /api/client-config?client=...` | Cree una configuración de cliente de solo lectura para cualquier integración de archivos compatible | 400 clientes no admitidos; 503 catálogo no disponible |
+| `PUT /api/disabled-models` | Reemplazar la lista de modelos compartidos deshabilitados | 400 inválido JSON |
+| `PUT /api/model-visibility` | Cambiar atómicamente la visibilidad a nivel de proveedor o modelo | 400 proveedor, alcance, objetivo o entidad no válidos; 409 `initial_model_selection_pending` (refresque la lista de modelos y vuelva a intentarlo) |
+| `GET, POST /api/custom-models` | Listar modelos personalizados o agregar uno | 400 campos no válidos; Falta el proveedor 404; 409 modelo duplicado |
+| `PUT, DELETE /api/custom-models/{id}` | Editar o eliminar un modelo personalizado | 400 identificación/campos no válidos; Error: 404 Artículo no encontrado 409 modelo duplicado |
+| `GET, PUT /api/selected-models` | Leer listas de proveedores y disponibilidad, o reemplazar una lista de proveedores | 400 proveedores/cuerpo ausentes; 404 proveedor desconocido; PUNTO 409 `initial_model_selection_pending` |
+| `GET, PUT /api/model-presets` | Leer resúmenes preestablecidos o elegir el modo preestablecido/todo/personalizado | 400 modo no válido o preajuste no compatible; 404 proveedor desconocido; PUNTO 409 `initial_model_selection_pending` |
+| `PUT /api/model-settings` | Editar los ejes de capacidad de un modelo enrutado en su lugar | 400 proveedores que faltan / modelId, proveedores desconocidos o nativos / combo, campo mal formado, campo desconocido, ID de modelo no exacto o un esfuerzo predeterminado no válido para la escalera resultante; 500 cuando no se pudo guardar la configuración (la configuración en vivo no se modificó) |
+
+`PUT /api/model-settings` toma `{ provider, modelId }` más cualquiera de `contextWindow`, `inputModalities`, `responsesCustomTools`, `reasoningEfforts` y `defaultReasoningEffort`. Escribe los mapas por modelo a nivel de proveedor que ya lee el entorno de ejecución (`modelContextWindows`, `modelCapabilities.<modelId>.inputModalities`, `modelCapabilities.<modelId>.responsesCustomTools`, `modelReasoningEfforts`, `modelDefaultReasoningEfforts`), por lo que una fila editada mantiene su procedencia de descubrimiento en lugar de ser reemplazada por un modelo personalizado. `inputModalities` acepta `text`, `image` y `audio`; `reasoningEfforts` debe ser un subconjunto de los esfuerzos que conoce el entorno de ejecución. Los campos de solicitud desconocidos se rechazan por nombre. `modelId` debe ser exacto, sin espacios en blanco circundantes, caracteres de control, longitud excesiva o un nombre de propiedad de objeto reservado. `contextWindow` debe ser `null` o un entero seguro positivo.
+
+Cada campo es opcional, y `null` **borra** la declaración en lugar de escribir un valor predeterminado, que devuelve el hecho al registro, el catálogo y el proveedor. Una matriz `inputModalities` vacía también se borra, mientras que una matriz `reasoningEfforts` vacía se almacena como una anulación explícita de "este modelo no tiene peldaños de razonamiento". El borrado `inputModalities` también elimina la entrada `modelInputModalities` heredada exacta para ese modelo, por lo que una restauración no puede dejar una declaración anterior en vigor; las claves familiares compartidas con otros modelos permanecen. Se elimina un mapa por modelo vaciado en lugar de dejarlo como `{}`. Una solicitud que no cambia nada responde `changed: false` con el estado almacenado. El recibo también reporta `saved` (si esta solicitud publicó la configuración), `hasOverrides` (si permanece almacenado algún eje editable) y `catalogRefresh` (`committed`, `skipped` o `failed`). Estos campos distinguen una opción prohibida con declaraciones almacenadas de un modelo sin nada que restaurar. Una solicitud cambiada persiste atómicamente; un fallo de guardado no publicado deja la configuración viva sin cambios. Después de la publicación, el servidor elimina el resultado `/models` almacenado en caché del proveedor e informa el resultado del catálogo. Una escritura publicada seguida de un error de contabilidad devuelve `saved: true` con una actualización omitida. El conjunto hornea pistas resueltas en las filas que almacena en caché, y un golpe de caché solo puede bajar una ventana configurada, por lo que una anulación elevada o desactivada devolvería la respuesta anterior para todo el TTL. Solo los proveedores encaminados son direccionables: `openai` es el carril de paso nativo y `combo` es una fila sintética, por lo que tampoco lo es un proveedor cuyos mapas por modelo provienen de estos hechos. Mostrar nombre no es parte de esta ruta; use `PUT /api/providers/{provider}/model-display-names`.
+
+`GET /api/models` informa el `contextWindowDeclared` almacenado exacto por separado del `contextWindow` efectivo. El editor de Modelos comienza desde la declaración y muestra la ventana efectiva como una pista heredada cuando no existe ninguna declaración. Si se desconoce un resultado de guardado, o se ha realizado el guardado correctamente, pero la lista de modelos no se ha recargado, el cuadro de diálogo deshabilita las escrituras adicionales y ofrece una recarga de solo lectura. Después de una recarga exitosa, vuelva a abrir la fila para inspeccionar los valores almacenados. Un `catalogRefresh` que falló, o se omitió con `retryable: true`, deja el guardar en su lugar y muestra una advertencia para ejecutar Sync; un salto no reintentable significa que no se administró el catálogo Codex y es un guardar limpio.
+
+Un modelo manual reemplaza la fila del panel Modelos con el mismo proveedor e ID de modelo. Para OpenAI, la fila manual mantiene `openai/<model>` y admite los mismos controles de visibilidad que otros modelos enrutados; al eliminarlo, se restaura la fila del panel de control nativa. Las filas nativas con calificación de cuenta explícita permanecen separadas. Esto no cambia el nombre de las rutas nativas ni cambia los derechos de cuenta. Los objetivos de visibilidad no nativos OpenAI deben coincidir con un modelo manual configurado.
+
+Las solicitudes PUT válidas a `/api/selected-models` y `/api/model-presets` devuelven HTTP 409 con el código `initial_model_selection_pending` hasta que esté disponible una lista de modelos inicial confiable. Actualizar el descubrimiento del modelo (por ejemplo, `GET /api/models`) y volver a intentarlo después de que tenga éxito.
+
+La visibilidad/selección exitosa escribe a `/api/disabled-models`, `/api/model-visibility`, `/api/selected-models` y `/api/model-presets` para informar los resultados de seguimiento en `catalogRefresh` y `clientIntegrations` cuando se ejecuta esa ruta de actualización. HTTP 200 y `ok: true` confirman la selección guardar; no garantizan todos los catálogos de clientes actualizados. Inspeccione `clientIntegrations[]` para `ok: false`, `client`, opcional Aparte `profileId`, y el rechazo `reason`; los detalles de recuperación también pueden incluir `refusalReason`, `snapshotPath` y `residual`. La página Modelos mantiene la selección guardada y muestra una advertencia de actualización del cliente por separado. Inspeccione las integraciones y resuelva el problema notificado antes de volver a intentar `ocx sync`. Los campos de resultado que faltan de un servidor antiguo no establecen una recuperación exitosa.
+
+<a id="oauth-accounts-provider-keys-and-data-plane-keys"></a>
+
+### Cuentas OAuth, claves de proveedor y claves de plano de datos
+
+OAuth filas de cuenta siempre incluyen `plan`: una etiqueta de suscripción validada o `null` cuando se desconoce. Anthropic niveles de perfil informan etiquetas como `max_20x`, `max_5x` o `pro`; Antigravity prefiere el nivel pagado (por ejemplo `g1-pro-tier`) sobre el nivel actual. Las etiquetas se leen al iniciar sesión/importar o actualizar, nunca se infieren de los porcentajes de cuota.
+
+| Método y ruta | Finalidad | Errores notables |
+| --- | --- | --- |
+| `GET /api/oauth/providers` | Enumerar proveedores con flujos de inicio de sesión públicos OAuth | — |
+| `GET /api/key-providers` | Lista de proveedores configurados mediante inicio de sesión con clave API | — |
+| `POST /api/oauth/login` | Inicie un inicio de sesión o flujo de adición de cuenta OAuth. `mode: "code"` inicia un inicio de sesión de visualización de código (solo Anthropic) y devuelve `mode`, `flowId`, `expiresAt` | 400 proveedor desconocido/inválido, `mode` inválido, `code_mode_unsupported`; `oauth_mutation_busy` |
+| `POST /api/oauth/login/code` | Envía una URL de devolución de llamada manual o un código de autorización. Para un flujo de visualización de código (con `flowId`) devuelve el resultado de intercambio de token `{ok, account}` / `{ok:false, error}` | 400 proveedor/código no válido, `state_mismatch`, `invalid_or_expired_code`, `provider_unreachable`, `malformed_input`; 409 `no_pending_login`; `oauth_mutation_busy` |
+| `POST /api/oauth/login/cancel` | Cancelar un flujo público en curso OAuth o descartar su fallo establecido; un `flowId` opcional nombra un flujo de visualización de código (se rechaza un flujo de otro proveedor) | 400 proveedor desconocido |
+| `GET /api/oauth/status` | Sondear el flujo OAuth de un proveedor | 400 proveedor desconocido |
+| `POST /api/oauth/logout` | Eliminar la credencial de proveedor seleccionada | 400 proveedor desconocido; `oauth_mutation_busy` |
+| `GET /api/oauth/accounts` | Lista de cuentas enmascaradas; Anthropic y OAuth filas de cuentas genéricas incluyen su estado `paused`. Kiro filas incluyen `autoSelectable` y un `skipReason` cerrado cuando se excluyen de la selección automática; un singleton activo todavía puede enviar. La cuota sigue siendo opt-in. | 400 proveedor no válido |
+| `DELETE /api/oauth/accounts` | Eliminar una cuenta | 400 proveedor/identificador no válido; 404 falta la cuenta; `oauth_mutation_busy` |
+| `PUT /api/oauth/accounts/active` | Selecciona la cuenta OAuth activa | 400 proveedor/cuenta inválidos; 404 cuenta ausente; 409 cuenta pausada; `oauth_mutation_busy`; 503 `affinity_reset_not_persisted` en Anthropic con `selectionCommitted: true`, `retryable: true`: el cambio se guardó; repite la misma solicitud aunque ya esté activa |
+| `PUT /api/oauth/accounts/pause` | Pausa o reanuda una cuenta Anthropic o genérica OAuth. Cuerpo `{ provider, accountId, paused }`; pausar la activa selecciona la siguiente utilizable cuando existe. Es durable e independiente del pool; reanudar conserva salud y credenciales | 400 proveedor o cuerpo inválidos; 404 cuenta ausente; `oauth_mutation_busy`; 503 `affinity_reset_not_persisted` en Anthropic con `pauseCommitted: true`, `retryable: true`: conserva cuenta y pausa, añade `retryAffinityReset: true` y reintenta confirmar el reset incluso después de reiniciar |
+| `GET, PUT, PATCH /api/pool/settings` | Leer o actualizar la política del grupo para cualquier tipo (Codex, Anthropic, genérico); responde con las mismas claves para los tres y declara en `supported` que la clase honra | 400 proveedor desconocido, un campo que el tipo no admite, o un valor no válido |
+| `GET, PUT, PATCH /api/oauth/accounts/pool` | Política heredada por grupo para Anthropic y proveedores genéricos OAuth; reemplazada por `/api/pool/settings` y mantenida para clientes existentes | 400 proveedor de Codex o de clave API, o política inválida |
+| `POST /api/oauth/accounts/clear-cooldown` | Borrar el enfriamiento de ejecución de una cuenta OAuth | 400 proveedor/cuenta no válido |
+| `PUT /api/oauth/accounts/alias` | Establecer o borrar un alias de cuenta OAuth | 400 proveedor/cuenta/alias no válido |
+| `GET, POST, DELETE /api/providers/keys` | Enumerar las claves de proveedor enmascaradas, agregar/activar una o eliminar una | 400 entrada no válida; 404 falta el proveedor o la clave |
+| `PUT /api/providers/keys/active` | Seleccione la clave activa de un proveedor | 400 entrada no válida; 404 falta el proveedor o la clave |
+| `PUT /api/providers/keys/alias` | Establecer o borrar un alias de clave de proveedor | 400 entrada no válida; 404 falta el proveedor o la clave |
+| `PUT /api/providers/keys/pause` | Pausa o reanuda una clave API. Cuerpo `{ name, id, paused }`; al pausar la activa elige la siguiente utilizable del anillo. Éxito incluye `activeAccountId` —o null— y `activeAccountChanged` | 400 entrada inválida; 404 proveedor o clave ausente |
+| `GET, POST, PATCH, DELETE /api/keys` | Listar, crear, editar o eliminar claves de admisión de plano de datos | 400 cuerpo o id no válido; 404 falta la clave |
+| `PUT /api/oauth/accounts/affinity-reset` | Confirma el reset de afinidad de sesión de todo el proveedor sin exigir cuentas. Cuerpo `{ provider }`; éxito incluye `affinityResetConfirmed: true`. CLI: `ocx account reset-affinity anthropic --json`; admite `anthropic2` | 400 cuerpo/proveedor inválidos; 503 `affinity_reset_not_persisted`, `retryable: true` |
+
+`POST /api/oauth/login/cancel` también puede descartar el intento de inicio de sesión fallido establecido seleccionado. Deja intactas las credenciales almacenadas y los resultados de inicio de sesión exitosos; el estado luego informa el flujo restante o inactivo. La cancelación de un intento en curso aún registra su resultado cancelado.
+
+Para Anthropic, `routes` es una matriz ordenada de `{name, match, accounts, fallback?}` reglas en ambos puntos finales de configuración. Los ecos GET y de escritura incluyen `routes` (`null` cuando están ausentes); los DTO unificados exponen `routes: null` para otros tipos. Se rechaza un `routes` suministrado de otro tipo. La omisión preserva las reglas, `[]` no coincide con nada, y `null` las limpia. Los valores `accounts` se almacenan ID; los ID eliminados siguen siendo válidos en una regla, por lo que volver a agregar una cuenta puede restaurar el enrutamiento. Las respuestas de gestión conservan nombres configurados válidos; los registros de solicitudes identifican una coincidencia solo como `route:#<n>` (posición de lista basada en 1). Si una regla almacenada editada a mano no es válida, ambos ajustes GET devuelven `routes: null` y un diagnóstico `routesError` en lugar de presentar esa regla como válida; el valor almacenado permanece disponible para corrección. Reglas válidas o ausentes omiten `routesError`.
+
+Las respuestas de la lista de credenciales se enmascaran deliberadamente. Los tokens de acceso OAuth y las claves completas del proveedor API no se devuelven a los clientes del panel de control.
+
+<a id="protocol-paths"></a>
+
+### Rutas de protocolo
+
+| Método y ruta | Finalidad | Errores notables |
+| --- | --- | --- |
+| `GET /api/protocols` | Devuelve la versión del contrato de protocolo, qué API se sirven, la configuración del protocolo, la revisión de directiva actual y las características de la solicitud que entiende una vista previa | — |
+| `GET /api/protocols?provider=<name>` | El mismo cuerpo más `provider`: `{ name, adapter, adapterSource, authMode, upstream, modelOverrides: [{ model, adapter, source }] }` — el cable que recibe el proveedor y quién lo decidió (`hard-pin`, `operator`, `registry`, `provider-default`), con hasta 64 modelos en un cable diferente (`modelOverridesTruncated: true` más allá de eso). Ninguna credencial o base URL | 400 caracteres vacíos, repetidos, más de 200 caracteres o caracteres de control; 404 ningún proveedor con ese nombre |
+| `POST /api/protocols/plan` | Vista previa de la ruta que tomaría una solicitud: `{ "model": "...", "inbound": "responses" \| "chat" \| "messages", "features": [...] }` devuelve la ruta de solicitud y respuesta de cada candidato de ruta, el modo de entrega, la fidelidad, los efectos de características y las razones | 400 inválido JSON, campo desconocido, modelo de más de 200 caracteres, desconocido entrante, o más de 24 / características desconocidas |
+| `PATCH /api/protocols/settings` | Cambiar la configuración del protocolo: `{ "messagesEnabled"?: boolean, "unrepresentable"?: "legacy" \| "reject", "rollout"?: { ...boolean switches } }`. Devuelve el mismo cuerpo que `GET /api/protocols`. Cierre Messages también establece `claudeCode.enabled` a `false` en el mismo salvo; al abrirlo escribe solamente `apiSurfaces.messages.enabled` | 400 inválido JSON, cuerpo vacío, campo desconocido, tipo incorrecto, o `rollout.managedMessagesNativeOAuth` sin `rollout.managedMessagesNative`; 409 configuración ocupada; 500 guardar falló (nada cambia) |
+
+Una vista previa se calcula a partir de la configuración sola. No envía nada a ningún proveedor, no cuesta nada, no avanza la rotación combinada y no se registra. La página API en el panel muestra la misma vista previa en **Solicitar vista previa de ruta**. Un modo de entrega de `native` describe cómo se desplaza la solicitud; no es una verificación de compatibilidad.
+
+El formulario `?provider=` respalda la sección **Protocolo del proveedor** de la configuración de un proveedor. Informa el formato opencodex enviado a ese proveedor; no abre ni cierra ningún cliente API. Para cambiar el adaptador para todo el proveedor, guarde la configuración del proveedor como de costumbre (`PATCH /api/providers`).
+
+`PATCH /api/protocols/settings` es el único escritor aquí y respalda la palanca Messages en la página API. El CLI conduce estas rutas con `ocx api protocols`, `ocx api explain` y `ocx api policy`. Los interruptores de despliegue están por etapas y desactivados por defecto ([Rutas de protocolo](/es/guides/protocol-paths/#rollout-switches)); consulte [API superficies](/es/reference/configuration/server/#api-surfaces-apisurfaces) para ver cómo interactúa la configuración Messages con `claudeCode.enabled` a través de actualizaciones y degradaciones.
+
+<a id="home-identity-and-the-served-by-header"></a>
+
+### Identidad del Home y encabezado served-by
+
+`GET /healthz` incluye `instanceId`, el identificador opaco del Home de esta instalación: `home_` seguido de 32 caracteres hexadecimales, generado al azar una sola vez por instalación. Coincide con `producer.homeId` de `GET /api/quota-pool`, se conserva entre reinicios y nunca es un nombre de equipo ni se deriva de él. Cada respuesta a `GET /v1/models` incluye ese mismo valor en el encabezado `x-opencodex-served-by`, para identificar el Home que respondió sin leer registros. Un Remote Link Child retransmite el encabezado del Home sin cambios; Codex en un cliente en modo Hub consulta directamente la respuesta del Hub. Así, el encabezado identifica el Home que sirvió la lista de modelos desde cualquier dispositivo. `GET /readyz` anuncia `served-by-header` en `features` cuando la compilación lo admite.
+
+Justo después del primer arranque, antes de que exista el archivo de identidad, o cuando ese archivo no se pueda leer, se omiten tanto `instanceId` como el encabezado; nunca se envía un valor vacío. Borrar `quota-pool-identity.json` del directorio de OpenCodex cambia el identificador y todas las referencias de cuentas del pool de cuotas en el siguiente arranque. Un proxy en ejecución sigue informando el identificador que ya leyó.
+
+<a id="providers"></a>
+
+### Proveedores
+
+| Método y ruta | Finalidad | Errores notables |
+| --- | --- | --- |
+| `GET /api/providers` | Listar la configuración del proveedor redactado y el estado de descubrimiento | — |
+| `POST /api/providers` | Agregar o reemplazar un proveedor validado y, opcionalmente, hacerlo predeterminado | 400 destino o configuración no válido/peligroso; 409 Colisión de espacio de nombres |
+| `PATCH /api/providers?name=...` | Actualizar los campos de proveedor permitidos (incluido un bloque `headers` combinado), estado habilitado/por defecto o modo de cuenta OpenAI | 400 campo no válido o transición; 404 proveedor desconocido |
+| `DELETE /api/providers?name=...` | Eliminar un proveedor, reasignar el valor predeterminado cuando sea posible | 404 proveedor desconocido; 409 `last_provider`; 409 `provider_has_dependent_combos` |
+| `POST /api/providers/test?name=...` | Realizar una sonda de conectividad/descubrimiento de proveedor en vivo limitada | 404 proveedor desconocido; las fallas normalmente se devuelven como evidencia `ok: false` |
+| `GET /api/provider-quotas` | Leer los informes de cuotas de proveedores; `refresh=1` fuerzas refrescan | — |
+| `GET /api/quota-pool` | Consultar el pool pasivo de cuotas `ocx.quota-pool/1`, con ventanas por cuenta y agrupadas y referencias opacas de cuentas. Solo usa datos en caché: nunca realiza sondeos ni actualiza las cuotas, e ignora `refresh`. Las ventanas agrupadas son una estimación ponderada por plan de las lecturas de los últimos 30 minutos de las cuentas enrutables, más una ventana `availability` cuando ninguna cuenta puede trabajar. También está disponible desde un Child de Remote Link o un cliente de Hub en `/api/machine/hub-relay/api/quota-pool` | — |
+| `GET /api/quota-resets` | Listar los restablecimientos de la ventana de cuota detectados recientemente y si la detección está habilitada; `limit=<n>` limita el conteo | 400 inválido `limit` |
+| `GET /api/fallback` | Consultar el estado `ocx.fallback/1`: ajustes globales efectivos, excepciones por proveedor y ruta, dispositivos con permiso de fallback local y los últimos 20 fallbacks ejecutados o rechazados. También se puede consultar desde un Remote Link Child mediante `/api/machine/hub-relay/api/fallback` (se omiten los alias de enlaces) | — |
+| `PUT /api/fallback` | Establecer o eliminar ajustes: una escritura `{ scope: "global"\|"provider"\|"route"\|"device", key?, setting: "model"\|"provider"\|"localFallback", value: true\|false\|null }`, o `{ writes: [ … ] }` con hasta 8 escrituras aplicadas en una sola modificación de configuración; `localFallback` es por dispositivo; la clave de dispositivo puede ser un alias de enlace. Devuelve el estado nuevo | 400 cuerpo inválido; 404 `unknown_device` (no se escribe nada); 409 `config_unavailable` |
+| `GET, PUT /api/provider-context-caps` | Leer o actualizar los límites de contexto globales, de todos los proveedores o de un solo proveedor | 400 solicitud inválida; 404 proveedor desconocido |
+| `GET /api/provider-presets` | Devolver preajustes de proveedor de GUI derivados del registro en tiempo de ejecución | — |
+
+Las respuestas de consulta de proveedores incluyen el booleano opcional `inferContextWindow` cuando está configurado. PATCH solo acepta un booleano o `null` para quitar este ajuste; omitirlo conserva el valor anterior. Un POST con el mismo nombre también conserva el ajuste omitido, incluido un `false` guardado; un booleano enviado explícitamente tiene prioridad. Consulta [Ventanas de contexto en proveedores personalizados](/es/reference/configuration/providers/#context-windows-on-custom-providers): esta opción solo se aplica a proveedores personalizados y está desactivada de forma predeterminada.
+
+Cuando el punto final de cuota-resumen de Antigravity no tiene una respuesta utilizable, los informes de cuota también pueden incluir ventanas de uso de Cloud Code Assist por modelo cuando la respuesta de descubrimiento de modelo los proporciona. Estas mediciones son de diagnóstico; una ventana de modelo ausente no establece que el modelo no está disponible.
+
+Con `quota=1`, una fila de cuenta de Anthropic o Antigravity cuya consulta no haya obtenido cuota incluye `quotaUnavailable: true` y, si se conoce la causa, un código fijo `quotaFailure`: `account_unavailable` (vuelve a iniciar sesión), `access_denied`, `rate_limited`, `timeout`, `transport_error`, `upstream_error` o `response_unusable` (reintenta más tarde), entre otros. El código nunca contiene texto del proveedor y un fallo de cuota nunca cambia el `health` de la fila.
+
+La respuesta de límite de contexto del proveedor incluye `caps` (límites activos) y `values` (últimos valores seleccionados, retenidos mientras están desactivados). Habilitar un proveedor sin `value` restaura su selección, o utiliza el `contextCapValue` global en la primera habilitación. Esto también se aplica a OpenAI: el interruptor no selecciona un modo especial 922k. Una tapa activa limita cada ventana nativa; los modelos con una ventana de contexto largo compatible pueden expandirse solo hasta su propio techo compatible. La actualización del valor global con `{ "value": 600000, "setAll": true }` cambios solo permitió límites de proveedores; los proveedores deshabilitados mantienen sus selecciones recordadas cuando se habilitan más tarde. Por el contrario, `{ "setAll": true }` sin `value` permite a cada proveedor configurado el valor global actual, reemplazando sus selecciones recordadas. Desactivar una tapa no activa su valor recordado ni borra la selección.
+
+
+`provider_has_dependent_combos` es una barrera de seguridad: eliminar o editar los combos dependientes antes de eliminar a su proveedor.
+
+<a id="sidebar-and-consent-bound-actions"></a>
+
+### Acciones de barra lateral y vinculadas al consentimiento
+
+| Método y ruta | Finalidad | Errores notables |
+| --- | --- | --- |
+| `GET /api/github/star` | Leer el estado de la estrella del repositorio a través de la sesión `gh` del usuario | Códigos de resultados fijos específicos del estado |
+| `POST /api/github/star` | Protagoniza el repositorio solo desde una acción humana autenticada | 403 `agent_consent_required` para personas que llaman por agentes sin evidencia de sesión en el panel de control |
+| `GET /api/update/badge` | Lee la insignia del paquete almacenado en caché sin una búsqueda del registro; la caché faltante, de canal incorrecto o de 40 horas de edad devuelve `unknown: true`. `surface=desktop&session=<id>` solo lee esa sesión de aplicación de escritorio. | 400 superficie no válida; la sesión de escritorio faltante o caducada devuelve `unknown: true` |
+| `POST /api/update/desktop-snapshot` | El shell de escritorio publica su estado de visualización actualizador de Tauri a través del cliente proxy vinculado | 403 si está presente una cabecera `Origin` o el principal no es el `admin-token` sin procesar; 400 campos no válidos; 413 sobre 1 KiB |
+
+La instantánea del escritorio es un estado de visualización temporal, no una solicitud de instalación. El proxy almacena un máximo de 32 sesiones en memoria y expira un segundo 180 después de su último latido. Un navegador normal sin surface-desktop continúa leyendo la insignia del paquete.
+
+El proxy comprueba la instalación de un paquete elegible después del inicio cuando falta su caché o tiene más de 20 horas, y comprueba la frescura cada hora. Configure `OCX_DISABLE_UPDATE_CHECK=1` para deshabilitar las comprobaciones automáticas. Las solicitudes explícitas de verificación y ejecución aún funcionan.
+
+:::caution
+La autenticación de administración prueba el acceso al proxy; no prueba el consentimiento para gastar el proxy. identidad del usuario. Un agente no debe recorrer `agent_consent_required`. El usuario debe elegir si se debe estrellar el repositorio.
+:::
+
+<a id="system-lifecycle"></a>
+
+### Ciclo de vida del sistema
+
+`POST /api/system/restart` mantiene el drenaje de 60 segundos por defecto, incluyendo solicitudes sin cuerpo o `{}`. Una persona que llama autenticada puede enviar explícitamente un cuerpo JSON tal como `{"drainGraceMs":2000}` para elegir una gracia de solicitud activa/drenaje con alcance más corta. El valor debe ser un entero de 1 a 60000 milisegundos. Los cuerpos o valores inválidos devuelven 400 antes de iniciar un drenaje; el límite de cuerpo de gestión estándar todavía se aplica. La capacidad de reinicio local de destino conserva la gracia predeterminada; la configuración de esta opción de cuerpo requiere una sesión de administración o token de administración (de lo contrario, 403). La respuesta `drainTimeoutMs` reporta la gracia aceptada. Las llamadas repetidas conservan la gracia del primer reinicio aceptado y no cambian su fecha límite.
+
+La gracia se mide a partir de la aceptación, incluyendo el retraso de la respuesta. El organismo de control de limpieza permanece 60 segundos y la preparación para el reemplazo conserva su presupuesto separado de 70 segundos. Una gracia corta puede interrumpir un giro que ya se ha ejecutado aguas arriba. Verifique su resultado antes de volver a enviarlo; OpenCodex no agrega repetición automática de trabajo ambiguo, y un reemplazo saludable no prueba que el reenvío sea seguro. El tablero de instrumentos, CLI, la bandeja y los reinicios automáticos continúan usando el valor predeterminado de 60 segundos.
+
+Durante un drenaje de reinicio, las nuevas solicitudes de plano de datos reciben HTTP 503 con JSON `error.type: "server_error"`, `error.code: "server_restarting"`, y el mensaje "OpenCodex se está reiniciando; reintente esta solicitud". Responses retiene `Retry-After: 5` y la política CORS del oyente receptor. Este código permite que cada versión Codex vuelva a intentar el 503 sin informar la capacidad del modelo; los errores de sobrecarga del proveedor conservan su asignación separada.
+
+| Método y ruta | Finalidad | Errores notables |
+| --- | --- | --- |
+| `GET /api/system/memory` | Devuelve métricas de proceso escalar, montón, flujo, estado de respuesta, vigilancia y turno activo. Los diagnósticos del estado de respuesta incluyen el estado de desbordamiento-escritura, fallas consecutivas, clase de falla segura de privacidad fija y últimas marcas de tiempo de falla / éxito. `spillLastWriteFailureOrigin` es `retry_returned_timeout`, `timeout_memo_refusal`, o nulo; acumulativo `spillAclRetryReturnedTimeouts` y `spillAclTimeoutMemoRefusals` cuentan publicaciones fallidas; acumulativo `spillCapacityRefusals` y `spillHeadroomEvictions` cuentan continuaciones rechazadas en el techo del derrame y continuaciones desalojadas para hacer espacio para una más nueva. Véase [Windows diagnósticos de derrames](/es/troubleshooting/windows-memory/) para la semántica local de procesos. Los errores crudos y los caminos nunca son devueltos. | — |
+| `POST /api/system/restart` | Iniciar un reinicio del proceso consciente de drenaje sin quitar la inyección del cliente; opcional JSON `drainGraceMs` acorta explícitamente la gracia predeterminada de 60s | Devuelve 202; las llamadas repetidas informan de la gracia existente; 400 cuerpo inválido o gracia |
+| `POST /api/stop` | Detenga el servicio, restaure el Codex nativo, elimine la inyección administrada Grok y drene el proxy | 409 conflicto de propiedad del servicio; 409 `respawnable_service` cuando un contenedor Windows Task Scheduler podría reenviar el proxy y el llamante no es `ocx stop` (no se cambia nada); 409 `self_unload_service` cuando este proxy se está ejecutando como el servicio instalado launchd / systemd, porque detener el administrador desde dentro terminaría el proceso antes de que se restaure el Codex nativo - ejecute `ocx stop` en su lugar (no se cambia nada); 409 cuando el administrador instalado se niega a detenerse; 409 `service_state_unknown` cuando no se puede leer el estado del Programador de tareas (no se cambia nada; reparar la consulta y volver a intentarlo) |
+| `GET /api/system/codex-app-server` | Informe si los servidores de aplicaciones Codex en ejecución son anteriores al catálogo actual del modelo | — |
+| `POST /api/system/codex-restart` | Actualiza el catálogo y después reinicia los app-servers de Codex. Si Codex Desktop está abierto, intenta reiniciarlo para recargar el selector; los campos de `desktopApp` informan si se rechazó el reinicio, quedaron procesos activos o falló el relanzamiento. Aunque Desktop haya iniciado después de la fecha del catálogo, `desktopApp.pickerState: "unknown"` indica que no se puede confirmar qué enlace `model_catalog_json` cargó: una sincronización anterior pudo cambiar el enlace de un catálogo ya existente. Si Desktop no es más reciente que el catálogo, o esta solicitud cambió su enlace, el estado es `stale`. Si está cerrado, devuelve `desktopApp.reason: "no_targets"`; `pickerState` puede ser `not_running` o `stale` si esta solicitud cambió el enlace. Si el proxy se ejecuta dentro de Codex App, se rechaza el reinicio de Desktop en lugar de delegarlo. | Devuelve 200 con `code: partially_stopped` si algún proceso sigue activo. |
+
+<a id="codex-authentication-delegation"></a>
+
+### Delegación de autenticación Codex
+
+`GET /api/settings` reporta el efectivo `codexAccountPickerEnabled` booleano. Un `PUT` que contiene ese booleano estricto inicializa los selectores de cuenta seguros para la privacidad al habilitar un mapa vacío, conserva las etiquetas de selector existentes al deshabilitar o volver a habilitar, persiste primero y luego solicita una convergencia de catálogo limitada solo cuando cambia la visibilidad efectiva del selector. La respuesta exitosa incluye `catalogRefreshPending`: `false` significa que la confirmación del catálogo se completó (o no se necesitó actualización), mientras que `true` significa que se guardó la configuración, pero `POST /api/sync` se debe usar para volver a intentar la actualización del catálogo. La persistencia o el fallo de asignación de selector devuelve la configuración en memoria y no ejecuta la convergencia.
+
+El despachador de administración raíz delega cada solicitud `/api/codex-auth/*` al administrador de cuentas Codex. Sus rutas son:
+
+| Método y ruta | Finalidad | Errores notables |
+| --- | --- | --- |
+| `GET, POST, DELETE /api/codex-auth/accounts` | Listar/actualizar o eliminar cuentas Codex. POST se mantiene como un punto final de compatibilidad deshabilitado; las respuestas de DELETE exitosas incluyen `catalogRefreshPending`. | POST siempre devuelve 403 `manual_import_disabled`; 400 entrada de DELETE inválida |
+| `PUT /api/codex-auth/accounts/alias` | Establecer o borrar un alias de cuenta | 400 cuenta/alias inválidas |
+| `PUT /api/codex-auth/accounts/pause` | Pausa o reanuda manualmente una cuenta y sus entradas principales/de grupo coincidentes existentes; devuelve `affectedAccountIds` | 400 cuenta/estado no válido; 404 Cuenta perdida 503 identidad principal ocupada o ilegible |
+| `PUT /api/codex-auth/accounts/pause-exhausted` | Pausa las cuentas cuya cuota se ha agotado | Los fallos de bloqueo de mutación se convierten en 503 |
+| `PUT /api/codex-auth/accounts/credits` | Permitir o dejar de gastar ChatGPT créditos después del límite de uso. Cuerpo `{ id, creditsAfterLimit }` para una cuenta, incluyendo `__main__`: true agrega el id a `creditCodexAccountIds`, false lo elimina. Cuerpo `{ all }` para el conmutador global: listas verdaderas `__main__` y cada cuenta de grupo, false borra la lista. Se aplica a la siguiente selección. | 400 ID no válido o valor no booleano; 404 falta la cuenta |
+| `PUT /api/settings` con `codexQuotaAutoRefresh: { id, window, enabled }` | Habilitar o deshabilitar la activación automática de ventana de 5 horas o semanal para una cuenta | 400 id/ventana/estado no válidos; 404 Cuenta perdida 409 Ventana no disponible |
+| `POST /api/codex-auth/accounts/clear-cooldown` | Borrar el tiempo de reutilización en tiempo de ejecución para una cuenta o todas las cuentas | 400 ID no válido |
+| `GET, PUT /api/codex-auth/active` | Leer o seleccionar la cuenta activa | 400 cuenta inválida o faltante; 409 conflicto pausado/fila de legado o `account_selection_unavailable` |
+| `PUT /api/codex-auth/auto-switch` | Establezca el umbral de cuota global con `{ threshold }`, o una anulación de cuenta con `{ id, threshold }`; `null` restaura la herencia global, y `__main__` selecciona el inicio de sesión del escritorio | 400 identificación inválida/umbral; 404 falta la cuenta |
+| `GET /api/codex-auth/preserve-signed-in` | Lea la política, actual `affectedAccountIds`, `identityKnown`, `nextAccountId`, `nextUsesSignedInQuota` (próxima opción real, incluso cuando está desactivado), `pinnedAccountId`, `bindings`, `priorityFailbackEnabled` y `fallbackConsumesSignedInQuota` | 503 perfil nativo ocupado/ilegible |
+| `PUT /api/codex-auth/preserve-signed-in` | Estricto `{ enabled: boolean, applyToBound?: boolean }`; explícito `applyToBound: true` requiere habilitado, libera fijaciones afectadas/pin para la próxima solicitud; informes `releasedPin` | 400 cuerpos inválidos; 503 perfil nativo ocupado/ilegible |
+| `PUT, PATCH /api/codex-auth/pool-strategy` | Actualizar la estrategia de selección de grupos de cuentas Codex | 400 estrategia/configuración no válida |
+| `PUT /api/codex-auth/failover` | Establecer el umbral de conmutación por error de la cuenta | 400 umbral inválido |
+| `GET /api/codex-auth/quota` | Leer el estado de la cuota en caché por cuenta | — |
+| `GET /api/codex-auth/low-quota-events?limit=20` | Lea solo los últimos eventos de registro/aviso y pausa-guardar de 0-100 cuotas bajas de este servidor (por defecto 20); incluye el ID de cuenta y el estado (`logged` para la alerta de solo registro predeterminada o un host sin un notificador compatible); `delivered` cuando el notificador del sistema operativo aceptado aceptó la notificación; `failed` cuando falló o se agotó el tiempo; `cancelled` cuando su episodio terminó primero; `succeeded` para una reserva de pausa completada) | 400 límite no válido; se requiere autenticación de administración |
+| `GET /api/codex-auth/reset-credits` | Inspeccione la elegibilidad de reset-credit para una cuenta | 400 ID de cuenta faltante; paso de estado ascendente; Fallo de búsqueda 500 |
+| `POST /api/codex-auth/reset-credits/consume` | Consume un crédito de reinicio elegible. Opcional `operationId` (UUIDv4) hace que la redención sea idempotente: el mismo id reproduce un resultado duradero en lugar de gastar un segundo crédito. | 400 identificación de cuenta faltante o inválida `operationId`; 409 `identity_mismatch` cuando el id pertenece a otra cuenta; paso de estado ascendente; 503 `server_busy`, `capacity`, o `unavailable`; 500 consumen fracaso |
+| `POST /api/codex-auth/login` | Iniciar inicio de sesión o reautenticación Codex | 400 solicitudes no válidas; estados de inicio de sesión conflictivos/ocupados |
+| `POST /api/codex-auth/login/code` | Envíe un código manual para un flujo de inicio de sesión Codex | 400 flujo/código no válido |
+| `POST /api/codex-auth/login/cancel` | Cancele solo el inicio de sesión pendiente Codex identificado por `{ "flowId": "..." }` | 400 ID de flujo faltante, desconocido o no pendiente |
+| `GET /api/codex-auth/login-status` | Sondear un flujo o estado de inicio de sesión de la cuenta. Un flujo de cuenta nueva completado incluye `catalogRefreshPending: true` solo cuando se necesita recuperación. | Informe de flujos desconocidos `expired`; no hay informes de flujo activo `idle` |
+
+`PUT /api/codex-auth/active` requiere `{ "accountId": "<id>" }` o un `{ "accountId": null }` explícito para borrar la selección. La reselección de la cuenta actual es una selección explícita incluso si otro proceso cambió la cuenta guardada. El servidor conserva la configuración guardada no relacionada y rechaza los objetivos eliminados o pausados desde que se cargó el panel de control. Una configuración guardada no disponible o no válida deja sin cambios la selección en vivo y la afinidad anteriores; vuelve a cargar los ajustes antes de volver a intentarlo. Una respuesta exitosa describe la selección comprometida. Las reglas de cuota y conmutación por error existentes aún pueden liberar un pin; `pinDrained` reporta una razón de drenaje actualmente conocida.
+
+Para el consumo de crédito de reposición, se suministra un `operationId` diferente mientras que la misma cuenta física tiene una operación inconclusa que se une a esa operación como un alias. Su reintento utiliza el ID de solicitud de flujo ascendente original y registra el resultado bajo esa misma identidad, por lo que las solicitudes posteriores con el ID original o un alias conocido reproducen el resultado almacenado sin otra solicitud de consumo. Una identificación nunca antes vista proporcionada después de la liquidación inicia un nuevo canje explícito; los clientes que reintententan una acción existente deben mantener su identificación.
+
+Después de un manual confirmado `reset`, OpenCodex comprueba el uso nuevo para esa misma cuenta y puede conciliar su tiempo de reutilización derivado del reinicio compartido preexistente elegible de inmediato. Las cuentas en pausa, las cuentas que requieren reautenticación y los tiempos de reutilización que ya son propiedad de una sonda en vuelo permanecen excluidas de esta recuperación; se conservan sus tiempos de reutilización. El uso comenzó antes del restablecimiento, el uso incompleto o agotado, una cuenta cambiada y un fallo de cuota más reciente no califican. Las respuestas de uso de cuenta principal más antiguas no pueden reemplazar una observación publicada más reciente. Si el uso necesita actualización de credenciales, la recuperación requiere el linaje confirmado de esa actualización; una credencial reemplazada externamente no califica simplemente porque pertenece a la misma cuenta. Se conservan `Retry-After` explícitos, los tiempos de reutilización de reserva, los ajustes de pausa, los pines y la cuenta seleccionada. `already_redeemed` y la repetición duradera no prueban un nuevo restablecimiento y no obtienen este comportamiento de recuperación.
+
+Una actualización de uso fallido o ocupado después de un `reset` o `already_redeemed` confirmado no convierte el consumo completado en un error: la respuesta sigue siendo HTTP 200 con su consumo `code`, omitiendo `remaining` cuando no se obtuvo un recuento fresco. Esta respuesta confirma el resultado de consumo, no que la cuenta ahora esté enrutable. Actualizar el uso para comprobar la disponibilidad; no consuma otro crédito para reintentar una actualización de uso fallido.
+
+Si se guarda una nueva fila de configuración de cuenta pero la configuración de credenciales no puede finalizar, OAuth `login-status` informa `status: "error"` con `code: "codex_credential_persistence_failed"`, `accountId`, `needsReauth: true` y `catalogRefreshPending: true` opcional; los detalles del error de almacenamiento no están expuestos. La fila de la cuenta permanece guardada: vuelva a autenticarla o eliminarla antes de volver a intentar la creación de la cuenta.
+
+Tiempos de espera de bloqueo de escritura de configuración o actualización de credenciales bajo esta declaración de familia delegada HTTP 503 con código `CONFIG_MUTATION_LOCK_UNAVAILABLE`. Los clientes deben volver a intentarlo en breve en lugar de tratar esa respuesta como un fracaso permanente de la cuenta.
+
+Creación y eliminación de credenciales/configuración de confirmación de cuenta antes de la convergencia del catálogo. Un intento de catálogo fallido o diferido nunca hace retroceder la mutación de la cuenta duradera y nunca refleja los detalles internos del proveedor, la cuenta, la ruta o la credencial; los clientes reciben solo el booleano de finalización. La eliminación de una cuenta conserva su enlace selector para rutas exactas fallan cerrado mientras la cuenta está ausente y el mismo selector se restaura si se agrega esa cuenta id nuevo.
+
+<a id="desktop-authorization"></a>
+
+## Autorización de Desktop
+
+Las mutaciones de compatibilidad de Desktop requieren una concesión de un solo uso destinada a Desktop además de una sesión local actual del panel. En el equipo del proxy ejecuta `ocx gui pair --desktop --origin <dashboard-origin>` con el origen loopback exacto del panel y envía allí el código. Un código ordinario de `ocx gui pair` o una sesión ya emparejada no proporciona alcance Desktop. Una sesión loopback actual emitida automáticamente puede recibir este alcance tras un intercambio válido; no necesita convertirse en una sesión emparejada por el operador.
+
+`POST /api/codex/desktop-compatibility/authorization` acepta exactamente `{ "grant": "<code>" }` y, si tiene éxito, devuelve HTTP 200 con `{ "ok": true, "authorized": true }`. Añade alcance a la sesión existente del navegador sin emitir ni reemplazar sus credenciales. Un JSON o cuerpo mal formado devuelve 400; un intercambio rechazado devuelve 403 `desktop_authorization_required`. La concesión debe estar sin usar, vigente, destinada a Desktop y vinculada a este origen local independiente. Los tokens de administración sin procesar, las sesiones de administrador recordadas y los contextos Hub y de cliente conectado no pueden intercambiarla. En el equipo del proxy, una ventana privada separada del navegador en el mismo origen local apto puede obtener una nueva sesión loopback y canjear una nueva concesión.
+
+El panel llama después a `GET /api/codex/desktop-compatibility/authorization`. Tras la admisión común de administración, esta lectura devuelve HTTP 200 con `{ "ok": true, "supported": boolean, "authorized": boolean, "rememberedSession": boolean }`, incluso cuando falta el alcance Desktop (`authorized: false`) o el contexto no está admitido (`supported: false`, `authorized: false`). Las credenciales de administración ausentes o caducadas aún pueden fallar en el límite común de autenticación; GET no lo omite ni devuelve el error específico de ruta `desktop_authorization_required`.
+
+El alcance Desktop dura como máximo cinco minutos y no más que la sesión actual. No se renueva automáticamente, no establece un emparejamiento general ni cambia los permisos de Remote Link o divulgación de claves de datos. El panel verifica el alcance, actualiza el estado del certificado y del entorno de ejecución y la revisión de configuración de inicio, y requiere una nueva acción y consentimiento. La autorización nunca repite una mutación anterior. Los POST de certificado, entorno de ejecución y configuración vuelven a comprobar el alcance y devuelven 403 `desktop_authorization_required` si no está disponible.
+
+<a id="windows-compatibility-certificate-setup"></a>
+
+## Configuración del certificado de compatibilidad Windows
+
+`GET /api/codex/desktop-compatibility/certificate` devuelve el estado del certificado público: soporte, estado, huella digital, caducidad, aviso de renovación, observación de confianza y cualquier operación activa. La respuesta también informa `mutationAuthorized` para la sesión y entrada actuales; es una orientación de solo lectura y cada mutación comprueba de nuevo la autorización. Nunca genera una clave, descifra material privado o registra la confianza del sistema operativo. La confianza del certificado por sí sola no significa que se esté ejecutando un relé de compatibilidad o que se haya verificado la clave privada en este proceso.
+
+POST acepta `action: "prepare" | "trust" | "remove-trust" | "renew"` y `confirmed: true`. Las acciones de confianza también requieren la mayúscula exacta SHA-256 `fingerprint` devuelta por estado. Estas mutaciones requieren una sesión GUI actual con [autorización de Desktop](#desktop-authorization) desde una entrada loopback independiente confiable. Un token de administración o una sesión sin alcance Desktop recibe 403 `desktop_authorization_required`. Ninguna sesión puede hacer mutaciones antes de completar esta autorización adicional: una sesión loopback emitida automáticamente puede intercambiar la concesión, pero se rechaza aquí hasta consumirla, de modo que el consentimiento lo aporta la concesión y no el modo de emisión de la sesión. El intercambio rechaza una sesión recordada del panel antes de leer el cuerpo, ya que esa cookie acredita el token de administración duradero, no la presencia del operador en el equipo. Estas acciones están destinadas a una confirmación local, no a la inscripción desatendida de certificados.
+
+Prepare almacena una autoridad restringida de 30 días con una clave privada protegida por DPAPI del usuario actual Windows. Las preparaciones posteriores lo reutilizan. Las acciones de confianza nunca crean un estado faltante ni reemplazan silenciosamente una raíz caducada. La eliminación se niega mientras Codex se está ejecutando o no se puede establecer la propiedad del proceso. La cancelación o la finalización incierta del comando del sistema operativo se comprueba contra el almacén de certificados real. El estado desconocido sigue siendo un error en lugar de autorizar un reintento automático. Las respuestas no contienen PEM, claves privadas, datos de cuenta o salida de subproceso.
+
+La renovación requiere la huella digital actual y una aplicación Codex ausente. Verifica la eliminación de la confianza del certificado anterior antes de publicar un reemplazo cifrado validado. La eliminación rechazada o incierta conserva la identidad antigua. El reemplazo está preparado pero no es de confianza; regístrelo con una confirmación separada de `trust` utilizando su nueva huella digital. Un intento obsoleto no puede reemplazar la nueva identidad de nuevo. No se conserva ninguna cadena de copia de seguridad de certificado.
+
+Esta configuración API no habilita un relé, cambia el inicio de sesión, altera el uso, reinicia Codex o instala un vigilante. La protección de CurrentUser no aísla los secretos de otros procesos que se ejecutan como el mismo usuario del sistema operativo.
+
+<a id="experimental-windows-compatibility-runtime"></a>
+
+## Experimental entorno de ejecución de compatibilidad Windows
+
+`GET /api/codex/desktop-compatibility/runtime` es una lectura de estado inerte. POST requiere una sesión GUI local actual con [autorización de Desktop](#desktop-authorization) —la sesión se rechaza hasta consumir una concesión destinada a Desktop— y `{ action, confirmed: true }`, donde la acción es `start`, `stop`, `observe`, `launch` o `apply`. Solo `apply` requiere adicionalmente `accountWideConsent: true`. El punto final es experimental. El panel de control lo expone bajo **Codex Set → Compatibilidad con equipos de escritorio**; el conmutador **Reanudar la observación cuando se inicia OpenCodex** guarda la preferencia opcional `desktopCompatibility.startOnProxyStart`. El modo cliente administrado OpenCodex no ofrece estos controles locales ni los envía al concentrador compartido.
+
+Abre el panel en su origen loopback configurado y completa el [intercambio de concesión de Desktop](#desktop-authorization) con el comando del panel `ocx gui pair --desktop --origin "<dashboard-origin>"`. El código es una concesión para Desktop: añade alcance Desktop a la sesión actual del navegador durante un máximo de cinco minutos y no crea una sesión de emparejamiento general. Los controles permanecen desactivados hasta verificar ese alcance; ni la concesión ni su intercambio cambian la confianza del certificado, el estado del entorno ni la preferencia de inicio automático.
+
+Start requiere un certificado de confianza ya preparado, un inicio de sesión basado en archivos nativos recién verificados ChatGPT y la versión evaluada Codex Windows build `26.924.2738.0`. Comienza en el modo Observar. HTTP / HTTPS y los proxys de salida SOCKS5 autenticados usan la misma selección explícita para HTTP, verificación de identidad y sockets actualizados. NO_PROXY es honrado; los fracasos nunca vuelven a intentarlo directamente. Una configuración no válida o no compatible devuelve `egress_proxy_invalid`. Start nunca registra un certificado o cambia el inicio de sesión. Launch conserva la identidad del paquete y rechaza una aplicación que ya se está ejecutando. Los puertos PAC y CONNECT persisten después de la primera vinculación exitosa y se reutilizan en el reinicio. `connection_unavailable` significa fallo de enlace; `connection_invalid` o `connection_changed` significa que la identidad de punto final almacenada no podría aceptarse. Estos fallos nunca giran silenciosamente los puertos ni sobrescriben el registro de conexión existente. Reiniciar vuelve a Observar, no a Aplicar. `native_routing_unverified` significa que el enrutamiento raíz/perfil nativo no se puede emparejar con el oyente OpenCodex vinculado a este proceso. El estado de entorno de ejecución puede exponer `contextFailure` para esta condición o `build_unverified`. Estos estados desactivan la corrección de respuesta sin reclamar una reparación de la aplicación.
+
+Una respuesta de estado también puede llevar `buildAssessment`, los metadatos públicos de la última comprobación de compilación completada: `assessedVersion` (el paquete exacto contra el que se evaluó este entorno de ejecución), `observedVersion`, `verified` y `completedAt`. Registra una observación pasada, no una lectura de instalación en vivo: un entorno de ejecución detenido, una actualización de la aplicación o una verificación pendiente o interrumpida pueden dejarla más antigua que el paquete instalado, y solo una verificación completa la reemplaza. `observedVersion` es nulo a menos que el descubrimiento coincida con la familia de paquetes evaluados y el punto de entrada; una compilación más nueva identificada mantiene su propia versión con `verified` false, y `verified` siempre describe el paquete observado en `completedAt`, nunca lo que se instale más tarde. El campo está ausente hasta que el servicio crea su sonda durante el inicio y `null` hasta que la sonda termina una comprobación; el estado de lectura nunca inicia una.
+
+Aplicar requiere una instantánea de agotamiento elegible observada recientemente y dura como máximo tres minutos en la capa de respuesta. Cambia dos banderas de puerta de cuenta-UI, no porcentajes de uso, créditos, restricciones de gasto o límites de servidor. La respuesta de uso no identifica el modelo seleccionado: esta prueba no puede prometer un efecto limitado a modelos externos. Una activación aceptada o una respuesta producida no prueba que la aplicación haya aceptado la nueva instantánea o habilitado su compositor. Un registro de uso original disponible o protegido devuelve el controlador a Observar e invalida las correcciones pendientes. El agotamiento posterior requiere otra solicitud de aplicación explícita. El enrutamiento raíz/proveedor/retroceso modificado invalida el contexto de observación del entorno de ejecución hasta que se detiene/inicia; revertir esa configuración no la reactiva.
+
+Observar desactiva la corrección y actualiza solo los flujos de uso validados. Stop cierra los oyentes y las conexiones de este entorno de ejecución; el PAC incluye `DIRECT` de reserva. El certificado permanece instalado para su reutilización. Detenga el entorno de ejecución y cierre Codex antes de eliminar la confianza o renovar el certificado. Informes de limpieza fallidos `cleanup-required`; no afirma que el entorno de ejecución esté apagado. El inicio de sesión del sistema operativo, la configuración del proxy del sistema y los archivos de aplicación no se modifican con estos comandos de entorno de ejecución.
+
+El punto final de configuración independiente devuelve `{ startOnProxyStart, revision }`. POST requiere `{ startOnProxyStart: boolean, revision, confirmed: true }` de una sesión GUI actual con [autorización de Desktop](#desktop-authorization) en una entrada loopback independiente confiable; una sesión sin alcance Desktop recibe 403 `desktop_authorization_required`. Una revisión obsoleta rechaza la escritura; una actualización válida conserva los campos de configuración no relacionados y verifica el resultado persistente. Esta preferencia afecta el siguiente inicio proxy, nunca el estado actual en entorno de ejecución, el inicio de la aplicación o una prueba de Aplicar. Una respuesta incierta debe ser seguida por GET, no un intento automático de POST. La configuración no válida o faltante se conserva en lugar de recrearse.
+
+<a id="choosing-a-client"></a>
+
+## Elegir un cliente
+
+Para la administración ordinaria, el [Panel de control web](/es/guides/web-dashboard/) ofrece el flujo de trabajo guiado más seguro. Para hosts sin cabeza y automatización, use los comandos correspondientes `ocx`: llaman a esto mismo en vivo API y devuelven un resultado distinto de cero cuando el proxy es inalcanzable o la operación falla. Direct HTTP es más útil para integraciones que necesitan los contratos de punto final exactos anteriores.
+
+<a id="remote-sessions-and-data-key-rotation"></a>
+
+## Sesiones remotas y rotación de datos
+
+`POST /api/keys/rotate {id}` inicia una superposición de diez minutos y devuelve el nuevo secreto de datos una vez. `POST /api/keys/rotate/commit {id,rotationId}` lo compromete; `DELETE /api/keys/rotate {id,rotationId}` lo aborta. Todos requieren autenticación de administración; las claves de datos no pueden llamarlos. `POST /api/session/logout` requiere el `gui-session` actual, que coincida con Origin y CSRF. Un token de administración recibe 403 y nunca puede acuñar o intercambiar en una sesión de consentimiento.
+
+<a id="anthropic-account-usage-threshold"></a>
+
+## Umbral de uso de la cuenta Anthropic
+
+`PUT /api/oauth/accounts/auto-switch`
+
+Anthropic OAuth solamente; `{ provider: "anthropic", accountId, threshold }` acepta el número entero 0-100 o nulo para heredar. El umbral faltante no es válido. La anulación almacenada sobrevive al reinicio y se elimina con la cuenta.
+
+Los DTO de la lista de cuentas incluyen `autoSwitchThresholdOverride` (entero/nulo), `autoSwitchThreshold` (por defecto del grupo) y `effectiveAutoSwitchThreshold`. 0 deshabilita solo la conmutación basada en el uso; nunca deshabilita la pausa o la recuperación 429.
+
+HTTP: 400 inválido/no soportado; 404 Cuenta perdida `oauth_mutation_busy` en la contención de bloqueo.
+
+<a id="forced-claude-code-subagent-model"></a>
+
+### Modelo de subagente forzado Claude Code
+
+La página Subagentes ofrece **Forzar un modelo para todos los subagentes**, una opción **desactivada de forma predeterminada**. Selecciona un identificador disponible en la lista, como `combo/tev-auto`, y después activa la opción. Primero se ofrece la lista de modelos; las entradas guardadas que ya no estén disponibles no se pueden usar como destino forzado.
+
+`ocx agent subagents force combo/tev-auto` conjuntos `claudeCode.subagentModelForce`; `ocx agent subagents force -` lo aclara. `ocx agent status` informa de la configuración. `GET /api/subagent-models` devuelve `force`, `forceAvailable` y `forceStatus`; `PUT` acepta `{ "force": "combo/tev-auto" }` o `{ "force": null }` sin cambiar la lista. Omitir `force` lo deja sin cambios. Los objetivos inválidos o no expuestos son rechazados en la escritura; los objetivos obsoletos son reportados y omitidos en el lanzamiento.
+
+Esto tiene efecto en el **siguiente inicio enrutado de `ocx claude`**, inyectando `CLAUDE_CODE_SUBAGENT_MODEL` como un alias proxy explícito (con `[1m]` solo para una ventana autorizada de un millón de tokens; los objetivos nativos Claude usan un alias nativo reversible) y `CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1`. Cada variable no vacía exportada por el shell gana independientemente. Los lanzamientos nativos no inyectan ninguna variable; el plano `claude` no se ve afectado. No hay archivos de plugin o `settings.json` se modifican por esta configuración.
+
+Claude Code **2.1.257 o más reciente** es necesario para la fuerza. Los argumentos de modelo de complemento y agentes incorporados (incluyendo Explorar/Planear) y por llamada se anulan. Las bifurcaciones y las habilidades de subagente con `model: inherit` mantienen el modelo de conversación principal. El bucle principal y los sidecars de pequeño-rápido no se ven afectados. Los archivos de la lista existentes permanecen disponibles.
+
+El panel de control advierte sobre versiones antiguas o desconocidas de CLI, objetivos no disponibles y cualquiera de las variables ya presentes en `settings.json` → `env` (que anula env de lanzamiento). La detección es de solo lectura y local en el servidor: no puede inspeccionar otro shell de lanzamiento, otra máquina o la configuración local del proyecto. Un resultado desconocido no es prueba de apoyo a la fuerza.
+
+### Herramientas por modelo y recuperación de afinidad
+
+`responsesCustomTools` admite booleano o null para heredar del proveedor. El dashboard no tiene un control para este eje: Restaurar borra contexto, modalidades y razonamiento, pero lo conserva. Bórralo con `responsesCustomTools: null` o `ocx models set <provider/model> --reset`, que restablece todos los ejes. En false, la compactación Responses nativa también rebaja el historial de herramientas custom; si no puede representarlo de forma segura, devuelve HTTP 400 con `invalid_request_error` antes de enviar al proveedor.
+
+El dashboard conserva la advertencia de reset de afinidad no confirmado aunque desaparezca la cuenta guardada. Si la carga falla o la cuenta sigue pausada o bloqueada por reautenticación, conserva el reintento con su resultado. Una lista cargada que confirma ausencia permite usar el endpoint de reset de proveedor y solo borra la advertencia tras confirmar éxito. Elimina todos los vínculos, incluidos los creados tras el primer fallo, sin seleccionar ni reanudar cuentas y con lista vacía. Una eliminación con reset pendiente envía `retryAffinityReset=true`; un fallo devuelve 503 con `affinity_reset_not_persisted`, `deletionCommitted: true` y `retryable: true`: la cuenta ya se eliminó; reintenta el reset, no la eliminación. Una eliminación normal conserva afinidad de cuentas supervivientes. La limpieza solo se admite en instancias Anthropic OAuth registradas y mantiene las comprobaciones de autenticación y origen.
+
+### Cuota observada de Claude CLI
+
+Para el adaptador `claude-cli`, el informe es la última observación de suscripción guardada, `observed: true`, solo de la cuenta con sesión en Claude Code; no es un sondeo activo. `refresh=1` relee la identidad local y esa instantánea sin iniciar la CLI ni contactar Anthropic, aunque otros proveedores pueden hacer sus sondeos habituales. La fila aparece cuando una comprobación de uso registra ventanas de cuota. Salir o cambiar cuenta la borra al instante con refresh y en hasta un minuto con caché normal. Una nueva observación, incluso sin ventanas, reemplaza la anterior en la siguiente lectura. Las lecturas pasivas usan lo ya registrado, sin resolver credenciales ni sondear. `GET /api/quota-pool` no relee la sesión: puede conservar la cuenta anterior hasta otra lectura de dashboard o un turno Claude; tras reiniciar no muestra fila hasta esa lectura.
diff --git a/docs-site/src/content/docs/es/reference/platform-support.md b/docs-site/src/content/docs/es/reference/platform-support.md
new file mode 100644
index 00000000000..59d96da5437
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/platform-support.md
@@ -0,0 +1,73 @@
+---
+title: "Compatibilidad por plataforma"
+description: "Qué puede hacer OpenCodex en macOS, Windows y Linux, y por qué algunas funciones dependen de la plataforma."
+---
+
+OpenCodex funciona en macOS, Windows y Linux. La mayor parte se comporta igual en las tres plataformas; algunas funciones dependen de mecanismos del sistema operativo. Esta página explica cuáles y por qué.
+
+<a id="everywhere"></a>
+
+## En todas las plataformas
+
+| Función | Notas |
+| --- | --- |
+| Proxy, enrutamiento y adaptadores de proveedores | El entorno de ejecución principal es independiente de la plataforma. |
+| Servicio en segundo plano | Tres mecanismos nativos: launchd en macOS, Programador de tareas **o** WinSW en Windows y una unidad de usuario de systemd en Linux. |
+| Inicio de sesión en el navegador | Se abre mediante el mecanismo del sistema operativo. |
+| Detección de clientes | Las instalaciones de Cursor, Claude Desktop, Kiro y Codex se localizan según la plataforma. |
+
+<a id="provider-keys-in-the-os-credential-store"></a>
+
+### Claves de proveedores en el almacén de credenciales del sistema
+
+Se admite en las tres plataformas **cuando hay un servicio de credenciales del sistema desbloqueado y disponible**: Llavero en macOS, Administrador de credenciales en Windows y libsecret en Linux. Un llavero bloqueado o una sesión sin interfaz gráfica pueden carecer de ese servicio; en ese caso el almacén no está disponible y OpenCodex lo indica, sin cambiar de método silenciosamente. Consulta [Proveedores](/es/reference/configuration/providers/) para conocer las reglas de almacenamiento.
+
+<a id="macos-only"></a>
+
+## Solo en macOS
+
+<a id="claude-code-auto-connect"></a>
+
+### Conexión automática de Claude Code
+
+La inyección de `ANTHROPIC_BASE_URL` y de los controles de Claude Code en tu sesión se hace mediante el dominio de usuario de launchd, que no tiene un equivalente único en las demás plataformas.
+
+En Linux, los tres mecanismos posibles alcanzan grupos distintos de procesos: `systemctl --user set-environment` solo llega a las unidades creadas por systemd; `~/.profile`, a los intérpretes de comandos de inicio de sesión; y `~/.bashrc`, a los intérpretes interactivos que no son de inicio de sesión. No existe un único punto que cubra toda la sesión del usuario.
+
+En Windows, el equivalente es `HKCU\Environment`, que persiste entre reinicios. Esto trasladaría un token bearer desde un ámbito que se vacía al reiniciar a una sección del registro que lo conserva. Cambiaría cuánto tiempo permanece la credencial en disco y quién puede leerla; esa decisión requiere revisión de seguridad, no una simple adaptación entre plataformas.
+
+El resto de lo que necesita Claude Code funciona en todas las plataformas. Puedes establecer las mismas variables manualmente o ejecutar `ocx claude`, que las pasa directamente al proceso hijo.
+
+<a id="import-versus-paste"></a>
+
+## Importar o pegar una clave
+
+<a id="meta-muse-code"></a>
+
+### Meta Muse Code
+
+En macOS, el inicio de sesión normal intenta primero importar la clave API guardada por `muse login`. Si no hay una disponible, o si se usa otra plataforma, OpenCodex inicia la aprobación mediante dispositivo sin abrir Muse CLI. Añadir una cuenta o volver a autenticarla omite la importación. Si el inicio mediante dispositivo falla sin haberse cancelado, puede ofrecerse una clave manual cuando el cliente admita introducirla. Las claves pegadas se someten a la misma validación de formato y de la API de modelos que las importadas. Ambas vías de adquisición mediante la API de administración requieren una sesión del panel; consulta la [guía de proveedores](/es/guides/providers/).
+
+El aviso del Llavero de macOS aparece en el equipo que ejecuta el proxy, que puede ser distinto del equipo del navegador. OpenCodex permite hasta 120 segundos para aprobarlo. Cancelar el inicio en el panel detiene la lectura pendiente. La ausencia de entradas, el acceso denegado, la interacción no disponible con el Llavero, el tiempo agotado, las credenciales mal formadas y los fallos de validación de la API de modelos tienen mensajes de recuperación distintos. Si se bloquea la importación, el panel ofrece pegar una clave API existente de Muse Code; no inicia automáticamente otra autorización de dispositivo. Para iniciar sesión desde el navegador, elige **Añadir cuenta** en un proveedor ya configurado. OpenCodex no cambia los controles de acceso del Llavero.
+
+Si el inicio sigue fallando, informa el error exacto de Muse (incluido el estado HTTP), la versión de OpenCodex, `muse --version`, si el panel y el proxy están en equipos distintos y cuánto tiempo estuvo visible el aviso. En las herramientas de desarrollador del navegador → Red, copia solo el campo `error` de `/api/oauth/login` o `/api/oauth/status?provider=meta-muse`. No compartas archivos HAR, encabezados de solicitudes, archivos de autenticación, salidas del Llavero, datos de la cuenta ni el resto de la respuesta de estado. Estos diagnósticos permiten distinguir fallos de importación local y de validación de Meta sin volcar credenciales.
+
+En las solicitudes Responses a Meta se admite omitir la selección de herramientas o usar `auto`. Un `none` explícito envía `tools: []` y elimina los elementos `additional_tools` de la entrada. Las selecciones forzadas, por nombre y `allowed_tools` devuelven HTTP 400 antes de llegar a Meta, porque Muse solo acepta `auto`. Los demás destinos Responses conservan su comportamiento de selección de herramientas.
+
+<a id="windows-notes"></a>
+
+## Notas de Windows
+
+La actualización npm del lanzador Node requiere Windows 10 o posterior con atributos de creación
+de procesos Job List. Si no se dispone de supervisión atómica, informa `EINSTALLJOIN` y no inicia npm.
+Actualiza Windows antes de reintentarlo.
+
+El servicio de Windows puede usar el Programador de tareas o un servicio nativo de WinSW; ambos métodos son excluyentes. `ocx service repair` rechaza la reparación si encuentra estado de los dos, para evitar que dos proxies terminen compitiendo por el mismo puerto.
+
+En una instalación de Windows que no esté en inglés, la salida de consola usa la página de códigos del sistema en lugar de UTF-8. OpenCodex la decodifica según esa página para resolver correctamente nombres de cuenta con caracteres no ASCII.
+
+<a id="when-something-is-unavailable"></a>
+
+## Cuando una función no está disponible
+
+OpenCodex indica la causa real en lugar de desactivar un control silenciosamente. Si una función no está disponible en tu plataforma, el error o el panel explica qué mecanismo falta y cuál es la alternativa admitida. Si no lo hace, conviene informar el problema.
diff --git a/docs-site/src/content/docs/es/reference/proxy-formats.md b/docs-site/src/content/docs/es/reference/proxy-formats.md
new file mode 100644
index 00000000000..e297bffe59b
--- /dev/null
+++ b/docs-site/src/content/docs/es/reference/proxy-formats.md
@@ -0,0 +1,617 @@
+---
+title: "Formatos de API del proxy"
+description: "Formatos de protocolo de Responses, Chat Completions, Anthropic Messages, catálogo de modelos, WebSocket, tiempo real y compactación."
+---
+
+opencodex presenta un proxy local en varios dialectos de cliente. Un cliente Codex puede hablar el Responses API, una aplicación compatible con OpenAI puede hablar Chat Completions, y Claude Code puede hablar Anthropic Messages sin requerir que cada proveedor de origen implemente todos los formatos.
+
+La ruta de traducción normal es:
+
+```text
+client dialect → internal Responses model → provider adapter → provider wire format
+provider events → internal adapter events → client dialect
+```
+
+La representación Responses es el centro del puente. Las rutas nativas compatibles pueden omitir partes de la traducción y pasar una solicitud, pero la autenticación, el enrutamiento, el control de admisión y la seguridad de la respuesta aún ocurren en el límite del proxy. Configure el oyente y las claves de admisión en [Configuración](/es/reference/configuration/); use [Combos](/es/guides/combos/) cuando un identificador de modelo público seleccione entre varios objetivos.
+
+<a id="required-tools-on-buffered-native-combo-routes"></a>
+
+## Herramientas obligatorias en rutas nativas de combo sin streaming
+
+Un combo comprueba los resultados JSON nativos `openai-responses` almacenados antes de entregarlos
+cuando `tool_choice` es `required` o selecciona una función o herramienta personalizada por nombre.
+Un resultado completo sin la llamada requerida se convierte en HTTP 502 con
+`error.code: "required_tool_contract_unsatisfied"`. El combo puede probar otro destino elegible
+antes de entregar la respuesta, respetando la política de fallback y el presupuesto de envíos.
+Si ninguno termina correctamente, el cliente recibe el error tipado en vez de una finalización falsa.
+Una llamada alojada a una capacidad declarada puede cumplir `required`. Una llamada alojada que
+no coincide devuelve HTTP 400 con el mismo código y `x-should-retry: false`, porque la acción
+podría haberse ejecutado. En ese caso no hay fallback y el consumo sigue registrado.
+Las elecciones auto/none, los resultados incompletos y los contratos desconocidos conservan su
+comportamiento. Las rutas nativas directas siguen siendo un ámbito separado. Las rutas Chat traducidas tienen su propia comprobación, descrita más abajo.
+
+<a id="required-tools-on-streaming-native-combo-routes"></a>
+
+## Herramientas obligatorias en rutas nativas de combo con streaming
+
+Con `stream: true`, los destinos nativos Responses de un combo también rechazan una elección obligatoria o por nombre incumplida con `required_tool_contract_unsatisfied`. La elección del cliente sigue siendo vinculante aunque un destino filtre la herramienta o reduzca la elección saliente a `none`. Las sustituciones configuradas por imágenes alojadas solo satisfacen la elección original si se aplican a la solicitud realmente enviada, también después de revalidarla en cola. Una respuesta completa de solo texto retenida puede avanzar a otro destino elegible. Los eventos conocidos de razonamiento se retienen como máximo un segundo desde el primero; los siguientes no amplían el plazo. Al vencer, se libera el flujo y se fija el destino, conservando cualquier lectura pendiente del proveedor. El texto, los eventos de herramientas, la salida opaca o desconocida y los límites del búfer también fijan el destino. Los selectores de namespace y los ecos de llamadas comparten la restauración autorizada de alias. Después de ese límite, la ausencia de llamadas produce `response.failed` sin solicitar otro destino; la salida y el uso ya entregados se conservan. La evidencia de ejecución alojada también impide la repetición aunque la instantánea final la omita. Auto/none, los resultados incompletos y los contratos desconocidos conservan sus reglas.
+
+<a id="required-tools-on-translated-chat-routes"></a>
+
+## Herramientas obligatorias en rutas Chat traducidas
+
+Una respuesta OpenAI Chat traducida debe contener una llamada completa a la herramienta de cliente
+seleccionada cuando `tool_choice` es obligatorio, nombra una herramienta o usa una selección
+obligatoria de herramientas permitidas. Si el proveedor termina normalmente sin esa llamada,
+el turno falla con `required_tool_not_called` y conserva el consumo. El texto ya enviado sigue
+visible; el proxy no repite la solicitud ni cambia de destino después de esa salida. En Responses
+con streaming, termina con `response.failed`. Un sobre Responses admitido y almacenado puede tener
+`status: "failed"` aunque HTTP sea 200: comprueba el estado del sobre.
+Las elecciones auto/none y los resultados truncados mantienen su comportamiento. Este control
+cubre catálogos de herramientas del cliente en rutas Chat traducidas. Los catálogos con sidecars
+ejecutados por el proxy, el passthrough nativo y otros adaptadores conservan sus reglas de finalización.
+
+<a id="mimo-bare-tool-call-recovery"></a>
+
+## Recuperar llamadas sin estructura de MiMo
+
+En las rutas de chat OpenAI traducidas, los identificadores de modelo `mimo-v2` y `mimo-v2.*` punteados pueden recuperar un bloque completo de `<tool_call>` como una llamada a una herramienta de forma libre declarada exacta cuando la respuesta no contiene llamadas de herramienta estructurada. Se conserva la prosa alrededor del bloque; los ejemplos de código cercado e inline, encabezados anidados, herramientas no declaradas y envolturas identificadas siguen siendo literales. La recuperación está limitada a 128 llamadas, 4 MiB en total y 2 MiB por candidato. La prosa larga puede liberar el marcado original antes de la recuperación de la terminal; los errores nunca envían llamadas recuperadas.
+
+<a id="upstream-redirects"></a>
+
+## Redirecciones ascendentes
+
+Las solicitudes de modelo, imagen, video y búsqueda que contienen credenciales no siguen automáticamente las redirecciones de HTTP, incluidas las redirecciones del mismo origen. Configure la URL final de API en lugar de un alias de redirección. Una redirección no hace que el servidor vuelva a enviar las credenciales o el cuerpo de la solicitud a su destino. El propietario de la respuesta conserva su error existente o comportamiento de retransmisión; las rutas nativas Responses y compactas pueden devolver los 3xx y `Location` originales al cliente. El comportamiento de la redirección del cliente es independiente de esta política de transporte del servidor.
+
+<a id="console-upload-rejections"></a>
+
+## Rechazos de carga de consola
+
+Una consola exacta o una consola Go `Invalid upload request.` HTTP 400 desde un punto final canónico de generación OpenCode Zen/Go recibe un reintento después de 800 ms. El proxy reutiliza la misma solicitud serializada y registra la recuperación en Logs. Otros 400 errores, destinos personalizados, cancelaciones y rechazos repetidos de carga siguen siendo fallas. Esto no reintenta respuestas de modelo filtradas o flujos interrumpidos.
+
+<a id="codex-native-ordinary-lite-hosted-search-history"></a>
+
+## Historial de búsquedas alojadas de Codex-nativo Lite ordinario
+
+Cuando la solicitud de salida final no declara ninguna herramienta de búsqueda alojada (no hay ninguna entrada `web_search` o `web_search_preview` en `tools` o en un contenedor Lite `additional_tools`, incluso después de que se eliminaron las herramientas alojadas no admitidas del proveedor), cada destino Responses recibe el historial `web_search_call` repetido sin referencia como las mismas notas de referencia de asistente etiquetadas que se describen a continuación, con o sin la aceptación. Native Sol respondió a dicho historial con un genérico `server_error` (#7250), por lo que una conversación que se buscó en otro modelo puede continuar en una ruta cuya solicitud actual no tiene herramienta de búsqueda. Una herramienta de función llamada `web_search` no es una declaración alojada. No se agrega ninguna herramienta de búsqueda, no se vuelve a ejecutar la búsqueda y no se inventa ningún resultado; las celdas `item_reference` de la misma entrada permanecen estructurales. Una solicitud que declare la búsqueda alojada mantiene el historial estructural a menos que se aplique la opción de aceptación a continuación.
+
+Las solicitudes ordinarias que declaran la búsqueda alojada conservan el historial de búsqueda alojada estructural de forma predeterminada, incluidas las solicitudes Responses Lite. Para optar por las notas de referencia con pérdida, establezca `providers.openai.projectResponsesLiteHostedSearchHistory: true` en `config.json` (un booleano real, no la cadena `"true"`). El ajuste por defecto por proveedor se desactiva; omisión o `false` mantiene el historial estructural. Incluso cuando está habilitado, la proyección se aplica a giros ordinarios y solicitudes nativas v2 `compaction_trigger` cuyo destino final es exactamente canónico ChatGPT Codex `/responses` y cuya intención de solicitud efectiva selecciona explícitamente Responses Lite. Convierte el historial restante `web_search_call` sin referencia en notas de referencia de asistente etiquetadas. El encabezado final `x-openai-internal-codex-responses-lite` selecciona Lite solo cuando su valor es exactamente `true`; un `false` explícito anula los metadatos de la trama. Sin un valor de cabecera reconocido, se utiliza un valor de `client_metadata.ws_request_header_x_openai_internal_codex_responses_lite` de mapa de cadenas válido de `true`, que coincide con el manejo de metadatos WS existente. La intención efectiva no-Lite o no reconocida retiene el historial estructural; los metadatos mal formados no anulan un HTTP `true` explícito. Los nombres de modelo, la autenticación de suscripción, las declaraciones alojadas que faltan y `additional_tools` solos no seleccionan esta directiva; no se reescribe ningún encabezado o metadatos para que se aplique. Una vez habilitado, se aplica a nuevos hilos/bifurcaciones, continuaciones de modelos cruzados y errores/reiniciaciones de caché, sin configuración de diagnóstico. Solo una nota puente válida del mismo alcance demuestra una llamada/resultado de función original que se puede restaurar primero; un prefijo de ID, nombre de modelo o nota faltante no puede determinar el emisor. Se conserva una celda alojada exactamente referenciada por una misma entrada `item_reference.id`. `store:false` elimina las referencias anteriores, y su historial alojado restante puede ser proyectado. Las declaraciones de herramientas/Lite `additional_tools`, las opciones, los pares de llamadas/resultados del cliente, el texto cifrado de razonamiento/nativo, el orden no alojado y el historial sin procesar de la persona que llama conservan sus contratos existentes.
+
+Dentro de ese límite de Lite opcional, esto es una **política explícita de historial con pérdida**, no la afirmación de que las llamadas alojadas tengan un esquema no válido ni de que todos los errores ascendentes estén corregidos. Las notas llevan metadatos de estado/acción no confiables y URL/título/tipo permitidos tanto de fuentes de acción como de nivel superior, nunca instrucciones o cuerpos de página recuperados: 2.048 unidades UTF-16 por cadena, 20 entradas por lista, 65.536 bytes seriados para todas las notas proyectadas, luego una nota de omisión. Los ID y los campos desconocidos se eliminan de las celdas convertidas. HTTP / SSE y WS comparten el constructor ordinario final.
+
+Aparte de la regla de la ausencia de declaración anterior, OpenAI API público y otros destinos no ganan proyección ordinaria o nativa compacta. Native `/responses/compact` sigue siendo su ruta de salida opaca oficial/oficial/endpoint/account-scrub y conserva el historial estructural alojado. Los resúmenes portátiles/enrutados reutilizan su comportamiento de activación de proyección y referencia predeterminado existente; el renderizador compartido también conserva las fuentes de nivel superior listadas allí. No se introduce ningún nuevo reintento, clasificación de fuentes o resumen de compactación.
+
+<a id="empty-search-answers"></a>
+
+## Respuestas de búsqueda vacías
+
+Después de la búsqueda alojada, un pase de respuesta forzada limpio pero vacío recibe un intento de respuesta adicional con herramientas eliminadas y resultados existentes retenidos. Esto puede dar lugar a otra solicitud de modelo. Una segunda respuesta vacía falla; las llamadas mal formadas y los resultados de rechazo o truncamiento del proveedor se conservan sin este reintento.
+
+<a id="xai-policy-refusals"></a>
+
+## Rechazos de política xAI
+
+Algunos xAI Chat Completions denegaciones llegan como HTTP 403 con un modelo exacto de sentencia de denegación como `I can't help with that request.` en lugar de HTTP 200 más `finish_reason: content_filter`. Codex trata un 403 como un fallo de transporte, por lo que el turno del usuario nunca se registra y se vuelve a intentar la misma solicitud.
+
+En un no-combo Responses solicitud, OpenCodex reescrituras que permiten incluir 403 en un
+HTTP 200 Responses Carga útil con `status: "incomplete"` y
+`incomplete_details.reason: "content_filter"`. La reescritura se ejecuta en el openai-chat ruta del adaptador y en el paso de respuestas abiertas (grok-4.6 / grok-4.5 OAuth). Streaming utiliza el mismo límite incompleto. Vacío o espacios en blanco 403 cuerpos permanecen Errores. Suscripción, crédito, derecho y `not allowed to use this
+model` 403 errores de permanencia. La conmutación por error combinada sigue viendo el HTTP 403 original.
+
+<a id="cursor-context-overflow"></a>
+
+## Desbordamiento de contexto Cursor
+
+El primer desbordamiento de contexto desnudo de Cursor se muestra al cliente. Las solicitudes elegibles posteriores con un hilo de cliente estable pueden recuperarse con hasta tres repeticiones de conversación por alcance retenido. La asignación en memoria expira después de una hora de inactividad, desalojo o reinicio. Las solicitudes sin un hilo estable, ayudantes aislados, reanudaciones de resultados de herramientas, salida parcial, compactación y errores de cuota no utilizan esta recuperación. Los desbordamientos elegibles continuos mantienen activa la asignación existente incluso después de agotarse; no la reponen. Esto no infiere si una tarea está progresando.
+
+<a id="live-sideband-connection-failures"></a>
+
+## Fallos de conexión de banda lateral en vivo
+
+El proxy completa el protocolo de enlace de banda lateral en directo ascendente antes de aceptar el cliente WebSocket. Un rechazo ascendente falla la actualización con 502; un tiempo de espera de enlace de diez segundos devuelve 504, y la cancelación del cliente devuelve 499. Bun no expone el estado de enlace ascendente exacto, por lo que un 404/410 ascendente no puede reenviarse actualmente con precisión. Una conexión exitosa conserva los marcos de sesión iniciales en orden. Esta política de apretón de manos está separada del transporte Responses WebSocket.
+
+Al terminar una conexión de banda lateral, el proxy concede un segundo para cerrar ordenadamente
+el transporte del proveedor y después termina el que no responda. Solo libera la capacidad de
+llamadas activas de la cuenta cuando ese transporte ya está cerrado, incluso si falla la
+actualización de protocolo del cliente.
+
+<a id="undeclared-tool-calls"></a>
+
+## Llamadas de herramientas no declaradas
+
+En el punto final Responses, cuando una solicitud declara un catálogo de herramientas, una respuesta de paso a través nativa que llama a una herramienta ejecutada por el cliente fuera de ese catálogo falla el turno en lugar de retransmitir la llamada: un evento `response.failed` con el código de error `undeclared_tool_call`, luego `data: [DONE]`; JSON almacenado en memoria intermedia devuelve HTTP 502 con el mismo código. El rechazo se ejecuta antes de que la respuesta pueda entrar en estado de continuación, y se desactiva solo para `authMode: "forward"` proveedores o una solicitud sin catálogo declarado.
+
+Los puntos finales Chat Completions y Messages honran catálogos de herramientas diferidos: esos clientes pueden declarar un catálogo parcial y descubrir el resto en entorno de ejecución a través de su propio registro de herramientas, que, no la instantánea del catálogo traducida, posee el límite de declaración completo. Una llamada fuera de la lista declarada se retransmite para que el cliente valide; una llamada inventada contra un `tools: []` explícitamente vacío todavía se rechaza, porque no existe ningún registro diferido bajo una declaración vacía. Esto se aplica a las rutas nativas administradas y las respuestas traducidas, incluidas las llamadas de herramientas de cliente en las respuestas finales de búsqueda alojada, imagen o video. Solo se aplica la declaración del turno actual; los catálogos omitidos, parciales y solo alojados mantienen su comportamiento existente. Las rutas de reenvío de llamadas conservan su exención y las operaciones internas alojadas no se ven afectadas. Esas denegaciones mantienen el código `undeclared_tool_call` en cada cable:
+
+- **Chat Completions:** una trama `data:` que contiene un objeto OpenAI-estilo `error` que lleva el código, entonces el flujo se cierra sin una finalización satisfactoria o `[DONE]`; JSON almacenado en memoria intermedia devuelve HTTP 502 con el código.
+- **Messages:** un Anthropic `event: error` marco cuyo cuerpo es
+  `{ "type": "error", "error": { "type": "api_error", "code": "undeclared_tool_call", ... } }`, sin éxito `message_stop` o `[DONE]`; almacenado en memoria intermedia JSON devuelve HTTP 502 `api_error`
+  con el código. Una violación del catálogo determinista nunca se informa como una violación reintentable.
+  `overloaded_error` (HTTP 529).
+
+Native Messages también reconoce definiciones de herramientas de mensajes de sistema en línea junto con `tools: []`. Esos nombres permanecen accesibles hasta que se eliminen permanentemente; una declaración en línea no autoriza herramientas de cliente no relacionadas. Alojado MCP llamadas y servidor-herramienta argumento arroyos conservan su forma nativa.
+
+Por separado, en cada cable de entrada, una llamada con espacio de nombres `default.` del proveedor se normaliza de nuevo al nombre de la herramienta desnuda que declaró la solicitud (`default.Read` → `Read`).
+
+<a id="endpoint-overview"></a>
+
+## Visión general de punto final
+
+| Superficie del cliente | Punto final | Resultado exitoso no-stream | Resultado de transmisión o socket exitoso |
+| --- | --- | --- | --- |
+| OpenAI Responses | `POST /v1/responses` | Responses JSON | Responses SSE o Responses JSON marcos de texto sobre WebSocket |
+| OpenAI Chat Completions | `POST /v1/chat/completions` | `chat.completion` JSON | `chat.completion.chunk` SSE terminado en `[DONE]` |
+| Anthropic Messages | `POST /v1/messages` | Anthropic `message` JSON | Anthropic Messages SSE |
+| Anthropic recuento de tokens | `POST /v1/messages/count_tokens` | `{ "input_tokens": number }` | No se requiere |
+| Descubrimiento del modelo | `GET /v1/models` | Catálogo o instantánea de escritorio explícita | No se requiere |
+| Transcripción de archivos | `POST /v1/audio/transcriptions` | `{ "text": string }` o texto sin formato | No se admite en este punto final de archivo |
+| Dictado de streaming | `WS /v1/audio/transcriptions/stream` | No se requiere | Dictado de escritorio JSON eventos |
+| Voz y tiempo real | `POST /v1/live`, `POST /v1/realtime/calls` | Respuesta retransmitida de creación de llamadas | Una banda lateral separada WebSocket retransmite tramas en ambas direcciones |
+| Responses compactación | `POST /v1/responses/compact` | Historial de reemplazo JSON | No se requiere |
+
+<a id="file-transcription"></a>
+
+## Transcripción de archivos
+
+Conexiones > Las claves API tienen **Dictado** y **Voz en vivo** bloques. Introduzca una clave de datos OpenCodex, no una clave de proveedor o administración. Cargas de dictado el archivo que seleccione y ofrece cancelación y copia de la transcripción. Voz en vivo
+**Comprobar la conexión** abre una sesión sin acceso al micrófono ni a los marcos de audio, espera el reconocimiento de la sesión del proveedor y se desconecta después de un minuto o cuando salga del panel. La clave solo queda en la memoria de ese panel.
+**Configurado, no verificado** describe la configuración del proveedor, no la cuenta salud o derecho. Utilice la acción explícita para observar un resultado. Los ejemplos usan nunca incluya el secreto ingresado. Un servidor más antiguo sin metadatos de audio deja estos controles no disponibles.
+
+`POST /v1/audio/transcriptions` acepta una clave de plano de datos OpenCodex en `Authorization: Bearer`, `x-opencodex-api-key` o `x-api-key`, incluso en un oyente local. Se rechaza una clave no válida suministrada explícitamente. Suba un archivo de audio como multiparte `file` y proporcione `model=gpt-4o-transcribe` para una cuenta ChatGPT conectada. OpenCodex resuelve la credencial ascendente; nunca proporcione un token ChatGPT como la clave API del cliente.
+
+```bash
+curl "$OPENCODEX_BASE_URL/audio/transcriptions" \
+  -H "Authorization: Bearer $OPENCODEX_API_KEY" \
+  -F 'model=gpt-4o-transcribe' \
+  -F 'file=@recording.wav' \
+  -F 'language=ko'
+```
+
+Configure `OPENCODEX_BASE_URL` en su URL de proxy que termina en `/v1`. Los campos opcionales son `prompt`, `language`, y `response_format` ( `json`, el valor predeterminado, o `text` ). El resultado JSON contiene `text` solamente. Los archivos no deben estar vacíos y no deben tener más de 25.000.000 bytes; los cuerpos de varias partes están limitados a 32 MiB y los campos de texto a 16 KiB. El límite del cuerpo del oyente configurado puede imponer un techo más pequeño. Los campos duplicados o sin soporte, incluyendo `stream`, son rechazados. Este punto final no promete marcas de tiempo, diarización, subtítulos o metadatos de uso de tokens.
+
+La ruta de suscripción ChatGPT usa `gpt-4o-transcribe` como identificador de compatibilidad y no envía un nombre de modelo al punto final de transcripción privado. No es evidencia del modelo interno del backend. Un proveedor de claves OpenAI API habilitado también admite `gpt-4o-mini-transcribe` y `whisper-1`; cuando se selecciona un proveedor ChatGPT, un fallo de autenticación no cambia silenciosamente a ese proveedor pagado. El modo Direct utiliza la cuenta principal almacenada según las reglas de admisión de perfil existentes; El modo Pool utiliza la cuenta almacenada seleccionada. Las credenciales faltantes, caducadas o que se agotan devuelven un error. La cancelación detiene la solicitud de salida y el contenido de audio no está escrito para solicitar el historial.
+
+<a id="streaming-dictation"></a>
+
+## Dictado de streaming
+
+`WS /v1/audio/transcriptions/stream` es una extensión OpenCodex para una cuenta ChatGPT conectada. Está separado del protocolo público de transcripción en tiempo real de OpenAI. Autenticar con los mismos encabezados de clave proxy que la transcripción de archivos. Los clientes del navegador en su lugar ofrecen estos dos WebSocket subprotocolos:
+
+```text
+opencodex-audio
+opencodex-key.<canonical-base64url-of-UTF8-proxy-key>
+```
+
+Solo `opencodex-audio` es seleccionado en la respuesta. La codificación es la sintaxis de transporte, no el cifrado. Las cabeceras de credenciales explícitas HTTP tienen prioridad. Los tokens de ChatGPT permanecen en el proxy; un flujo ascendente que solo admita clave API no puede servir este protocolo de dictado.
+
+Después de conectar, envíe:
+
+```json
+{"type":"session.start","config":{"input_audio_format":"pcm16","sample_rate_hz":48000,"num_channels":1,"max_buffer_size_bytes":4194304,"max_utterance_duration_ms":30000,"session_ttl_ms":300000,"provider_mode":"streaming_sse","transcript_delivery_mode":"segment","vad":{"type":"server_vad","threshold":0.5,"prefix_padding_ms":300,"silence_duration_ms":500}}}
+```
+
+Usa la frecuencia real del audio PCM16 mono. Espera `session.started` y envía `{"type":"audio.append","audio":"<base64 PCM bytes>"}` en texto JSON, no WAV ni frames binarios. Se aceptan de 8.000 a 192.000 Hz según el servicio y la cuenta. Cada frame de cliente tiene un límite de 64 KiB. Los campos de configuración o eventos mal formados cierran el stream con código 1008.
+
+`transcript.segment` y `transcript.final` contienen `utterance_id`, `revision` y `text`. Reemplace el texto anterior por la misma expresión cuando su revisión aumente; no concatene las revisiones. Terminar con `{"type":"session.close"}` y esperar el texto final y `session.updated` con `session.status="closed"`.
+
+El proxy permite diez minutos (600.000 ms) de grabación desde que se conecta el relay. Un `session.close` válido antes del plazo sustituye ese temporizador por una ventana independiente de 60 segundos para transcripciones finales; mantén abierto el WebSocket durante la finalización. `config.session_ttl_ms` acepta de 1 a 600.000 y se reenvía sin cambios, sin fijar el temporizador del proxy. Son límites de OpenCodex, no límites oficiales demostrados de OpenAI. GPT Live y los demás transportes de audio conservan sus plazos.
+
+ScribeTray admite además este inicio; sustituye los UUID de ejemplo por identificadores generados por el cliente:
+
+```json
+{"type":"session.start","dictation_session_id":"78d201cb-1b49-40e1-a5b5-e06a8f8489a1","attempt_id":"8b3c2e4f-d501-4a66-b123-456789abcdef","config":{"input_audio_format":"pcm16","sample_rate_hz":16000,"num_channels":1,"max_buffer_size_bytes":4194304,"max_utterance_duration_ms":30000,"session_ttl_ms":300000,"provider_mode":"streaming_sse","transcript_delivery_mode":"final_only","session_asset_mode":"none","vad":{"type":"server_vad"}},"client_capabilities":["server_stop_requested"]}
+```
+
+Los IDs son opcionales, no vacíos y de hasta 128 bytes UTF-8. `client_capabilities` acepta un array vacío o solo `"server_stop_requested"`. `config.language` es opcional, no vacío y de hasta 64 bytes UTF-8, por ejemplo `"it"`; estas cadenas no admiten controles. `config.session_asset_mode` solo acepta `"none"`. VAD solo necesita `{"type":"server_vad"}`; si se incluyen, `threshold` debe ser finito de 0 a 1, `prefix_padding_ms` un entero de 0 a 1.000 y `silence_duration_ms` de 0 a 5.000.
+
+Tras iniciar se acepta y reenvía `{"type":"audio.flush"}` sin cerrar la sesión: puede seguir audio hasta `session.close`. ScribeTray envía `audio.flush`, luego cierre y espera los resultados finales. No implica que flush sea obligatorio frente al cierre solo. Después del cierre no se acepta más audio ni eventos del cliente. Los payloads anteriores siguen admitidos; campos o capacidades desconocidos se rechazan.
+
+## `POST /v1/responses`
+
+Esta es la forma nativa del plano de datos opencodex. El cuerpo de la solicitud debe ser un objeto JSON con un `model` no vacío. `input` puede ser una cadena o una matriz de Responses artículos.
+
+<a id="caller-conversation-header"></a>
+
+### Cabecera de conversación de llamante
+
+Para HTTP `POST /v1/responses`, `POST /v1/messages`, y `POST /v1/chat/completions`, un cliente puede enviar un estable
+`x-session-id` para cada conversación. Cuando no `session_id`, `session-id`, o `thread-id`
+está presente, opencodex promueve el marcador para `session_id`. Identidad Grok administrada en Responses también tiene prioridad. Incluso un encabezado explícito vacío suprime la promoción.
+
+Use 1-128 letras ASCII, dígitos, `.`, `_`, `:` o `-`, comenzando con una letra o dígito. Se recortan los espacios en blanco circundantes; se ignoran los marcadores no válidos o faltantes. La admisión de Loopback preserva el marcador. La admisión autenticada deriva un identificador opaco del marcador y el principal de credenciales admitido, por lo que las credenciales diferentes no comparten un identificador recién promovido. La rotación cambia este identificador; las solicitudes autenticadas sin un principal de confianza se dejan sin cambios.
+
+Utilice marcadores distintos para conversaciones distintas. Esto preserva la continuidad de la conversación para los consumidores intermedios, pero no garantiza un éxito de caché ascendente o ahorros medidos. WebSocket marcos, compactos, y count_tokens no utilizan esta promoción.
+
+En el despacho canónico de Responses respaldado por ChatGPT, un `session_id` explícito no vacío gana. De lo contrario, el primer alias no vacío entre `session-id`, luego `thread-id`, suministra `session_id` si su valor es seguro; un alias ganador no válido suprime la identidad más débil. Los valores de cabecera vacíos se eliminan antes de este paso en cada ruta (selección de cabecera de autenticación Responses y los puentes Claude Messages y Chat Completions), por lo que una cabecera vacía cuenta como ausente: una `session-id` vacía permite una victoria `thread-id` válida. La sesión derivada de metadatos Claude solo se aplica cuando no queda ninguna cabecera canónica no vacía o alias. Los alias mantienen sus nombres originales en el cable; sus valores de llamada sin procesar validados se reenvían como un `session_id` explícito, sin el alcance principal utilizado para el `x-session-id` promocionado. Esta conversión de salida no cambia la afinidad de entrada. Los destinos personalizados y los de clave API no cambian, y no se inventa ninguna identidad para las solicitudes sin un marcador de conversación.
+
+Para clientes de terceros, mantenga un marcador de propiedad de la persona que llama por conversación, incluidas las solicitudes repetidas de `curl`. Un prefijo de sistema/herramientas compartido `prompt_cache_key` o idéntico es una cohorte de caché, no prueba de que dos solicitudes pertenezcan a una conversación. Las solicitudes sin un marcador de conversación no reciben una sesión estable inventada. OpenCodex tampoco se hace pasar por Codex sintetizando un `originator`; un originador suministrado por la persona que llama conserva sus reglas de reenvío normales. La continuidad del encabezado no establece un éxito de caché: compare los tokens de entrada en caché informados del flujo ascendente para sus propias solicitudes de prefijo repetido. Un recuento de escritura en caché omitido no es evidencia de no escritura.
+
+<a id="accepted-request-fields"></a>
+
+### Campos de solicitud aceptados
+
+| Zona | Forma aceptada |
+| --- | --- |
+| Modelo y entrada | Requerido `model` no vacío; cadena opcional `input` o una matriz de elementos |
+| Elementos del mensaje | `user`, `developer`, `system` y `assistant` mensajes; contenido de cadena o bloques de contenido mecanografiado apropiados para el rol |
+| Bloques de contenido | Texto, imágenes de entrada, archivos de entrada, texto de salida, rechazos y bloques de resumen/texto de razonamiento donde su elemento principal los permita |
+| Historial de herramientas | `function_call`, `function_call_output`, `custom_tool_call`, y `custom_tool_call_output` artículos |
+| Herramientas | Herramientas de función más entradas de herramientas incorporadas o alojadas sueltas; `tool_choice` acepta `auto`, `none`, `required`, opciones de función / personalizadas con nombre, opciones alojadas o `allowed_tools` |
+| Razonamiento | `reasoning.effort` y `reasoning.summary` (`auto`, `concise`, `detailed` o `none`) |
+| Continuación y almacenamiento en caché | `previous_response_id`, `store`, y `prompt_cache_key` |
+| Controles de generación | `max_output_tokens`, `temperature`, `top_p`, `stop`, `presence_penalty`, y `frequency_penalty` |
+| Servicio y ejecución | `stream`, `service_tier`, `parallel_tool_calls`, `instructions`, `metadata`, y `user` |
+| Campos extendidos Responses | `background`, `include`, `prompt`, `text` y `truncation` se aceptan para rutas compatibles |
+
+Los tipos de elementos desconocidos se aceptan como elementos de tipo suelto para la compatibilidad directa. Los adaptadores traducidos manejan solo los tipos de artículos que reconocen y pueden rechazar una característica que su proveedor no puede representar. En la ruta canónica ChatGPT Codex hacia adelante, los mensajes de entrada de solo texto `system` se pliegan en el nivel superior `instructions`, y se elimina `truncation` porque ese destino rechaza ambas formas públicas Responses. Otros Responses destinos los preservan. El mismo límite canónico elimina los marcadores `prompt_cache_breakpoint` anidados solo para el cliente y elimina las entradas `item_reference` solo en las continuaciones `store: false`; el emparejamiento de llamada de herramienta/resultado no cambia. `metadata` se elimina en cada ruta de avance para la compatibilidad con el canónico ChatGPT backend, que lo rechaza. `max_output_tokens` se elimina solo en esa ruta canónica, que rechaza el campo por completo; cada otro destino directo recibe el límite de salida del llamante sin cambios, pero el límite limita el giro solo cuando el destino lo impone.
+
+Los ID de archivo de imagen son referencias con alcance de proveedor, no bytes de imagen portátiles. Responses passthrough los conserva; los adaptadores de traducción reciben un marcador de texto `[image: file_id]` para partes de imagen solo de archivo en mensajes o salidas de función / herramienta personalizada. Utilice una URL de imagen o una URL de datos base64 cuando el modelo traducido necesite ver la imagen. Los artículos alojados `computer_call_output` requieren una ruta de paso Responses; las rutas traducidas devuelven HTTP 400 en lugar de dejar caer silenciosamente la captura de pantalla. Para una observación de captura de pantalla sin semántica de herramienta informática alojada, use un usuario `input_image`.
+
+<a id="json-and-sse-output"></a>
+
+### Salida JSON y SSE
+
+Con `stream: true`, la respuesta es `text/event-stream`. El puente emite Responses eventos como `response.created`, elementos de salida y deltas de texto / herramienta, y exactamente un terminal `response.completed`, `response.failed` o `response.incomplete` evento. Una corriente normal termina con `data: [DONE]`.
+
+Con `stream: false` o no `stream`, los mismos eventos del adaptador se recopilan en un objeto Responses JSON. Ambas formas conservan el modelo seleccionado, los elementos de salida, el estado del terminal y el uso. La ruta canónica ChatGPT Codex todavía usa `stream: true` en su solicitud de solo flujo ascendente porque ese destino es SSE solo; OpenCodex valida de manera limitada y pliega el flujo de terminales de nuevo a la forma JSON que el cliente solicitó. Esta coerción de transporte no altera un valor `store` explícito. El primer terminal debe ser válido; un terminal posterior no puede reemplazar uno no válido. Los índices de salida deben ser contiguos y estar cubiertos por un elemento completado o la salida del terminal, por lo que un delta de texto / herramienta dejado abierto por un terminal disperso falla cerrado en lugar de convertirse en JSON parcial. La ruta limita cada trama a 4 MiB, cada transcripción y fuente de reconstrucción a 32 MiB, la corriente a 100.000 tramas y la salida reconstruida a 10.000 elementos. El `stallTimeoutSec` configurado gobierna tanto el primer byte de cuerpo aguas arriba como los espacios silenciosos posteriores. Cuando ese reloj de parada está desactivado (`0`, incluido el valor predeterminado para un flujo ascendente local), no caduca inmediatamente; solo permanece el techo de giro almacenado de 15 minutos independiente. Un EOF, trama mal formada o sobredimensionada, error de lectura, bloqueo, cancelación o terminal faltante devuelve un error en lugar de JSON parcial con HTTP 200. Las llamadas de streaming no han cambiado.
+
+Cuando un proveedor filtra o trunca una respuesta, una llamada de herramienta inconclusa permanece `incomplete` tanto en JSON como en SSE. La salida parcial se conserva, y el puente no emite un evento de finalización de argumento para esa llamada abierta. Las llamadas ya completadas mantienen su estado. Esto preserva el resultado del proveedor.
+
+En el cable de transmisión de Responses, una parada explícita de filtro de contenido no reproducible de Anthropic (`refusal` / `content_filter`) o Kiro (`CONTENT_FILTERED` / `GUARDRAIL_INTERVENED`) termina con `response.failed`, `error.code: "invalid_prompt"` y `retryable: false`. Esto evita que los clientes que reintentan flujos incompletos vuelvan a enviar el contexto rechazado. Se conservan el uso y la salida parcial. Los sidecars de búsqueda e imagen web se detienen sin ejecutar llamadas de esa iteración rechazada o preguntar al modelo nuevamente, en cada cable entrante.
+
+Responses JSON almacenado temporalmente retiene `status: "incomplete"`; Chat Completions retiene `finish_reason: "content_filter"`, y Messages retiene `stop_reason: "refusal"`. Un filtro de contenido sin un veredicto explícito no reintentable, límites de token, puestos y EOF mantienen su comportamiento incompleto existente.
+
+Las razones explícitas de respuesta incompleta usan el mismo vocabulario en las respuestas con adaptador y en Responses nativo por JSON, SSE y WebSocket. Los alias de límite de salida como `length` y `max_tokens` se convierten en `max_output_tokens`; los de rechazo o filtro como `refusal`, en `content_filter`. Las demás razones, la posibilidad de reintento y el uso no cambian. Las salidas Responses y Messages conservan el mensaje del proveedor; los fallos de Chat Completions usan texto redactado por el proxy. Los codificadores directos de Chat y Messages aplican la misma conversión de razones.
+
+En la implementación pendiente de `dev` para #4112, un final aguas arriba HTTP 413 en esta superficie se clasifica como `invalid_request_error` / `context_length_exceeded`. Los llamantes que no son de flujo continuo retienen HTTP 413 con un JSON `error`; los llamantes de flujo continuo retienen el fallo del terminal SSE. Ambos usan un mensaje fijo en lugar de exponer el cuerpo de error ascendente. La compactación sintética enrutada propaga el fallo clasificado; esto no reduce la entrada ni vuelve a intentar la compactación. Los errores de transferencia compacta nativa y de límite de admisión local retienen sus contratos separados.
+
+Para el paso a través de HTTP / SSE nativo, una cancelación de cliente sin un terminal ascendente observado se registra como `499` con `closeReason: "client_cancel"` y no penaliza el grupo de cuentas. Esto se aplica tanto a la inspección de salida como al relé ansioso, incluido el tráfico de reescritura Windows, incluso cuando la lectura aguas arriba se rechaza antes de que se ejecute el gancho de cancelación del cuerpo de respuesta. Un terminal capturado durante el drenaje de desconexión posterior limitado conserva su resultado real.
+
+Si falla la reescritura de paso a través nativa, incluso cuando excede el presupuesto de la memoria intermedia de traducción, el relé informa del fallo sin esperar a que finalice la inspección ascendente. Cancela el trabajo ascendente y emite `response.failed` seguido de `data: [DONE]`; un desbordamiento de presupuesto utiliza el código de error `translation_buffer_limit`.
+
+Responses SSE acepta terminaciones de líneas CR, LF y CRLF, incluidas las terminaciones mixtas y la división de CRLF en trozos de red. La validación de herramientas, la traducción de chat, la inspección de terminales y la proyección WebSocket utilizan los mismos límites de eventos. Una terminación solo CR no espera a que se cierre la conexión ascendente.
+
+Los fotogramas Responses SSE orientados al cliente están limitados a 4 MiB por fotograma, medidos en bytes sin procesar antes del delimitador de bloques SSE. En HTTP, una trama aguas arriba no terminada que excede el límite falla cerrada con un evento sintético `response.failed` seguido por `data: [DONE]`. En el puente Responses WebSocket, la misma condición emite un 502 `websocket_protocol_error` y cancela el lector aguas arriba. Una trama de terminal completa Responses es autoritativa: bytes posteriores sobredimensionados o malformados después de que ese terminal se caiga en lugar de reemplazar el giro completo con un fallo de transporte.
+
+:::note
+Para passthrough nativo, un evento terminal Responses tiene autoridad. Un prematuro `data: [DONE]` es mantenido hasta ese evento. En la ruta nativa ordinaria, un HTTP 200 EOF limpio sin un terminal analizado Emite una `response.incomplete` con `incomplete_details.reason: "adapter_eof"`, seguido por un
+`data: [DONE]`; terminal sintácticamente válido sin delimitador JSON se acepta exactamente una vez, mientras JSON mal formado o truncado permanece incompleto. Para los proveedores que optaron por el terminal de modelo reparación, sufijos tipo terminal sin marco y un prematuro `data: [DONE]` en el error EOF cerrado con
+`missing_terminal_event` cuando no se puede promover un candidato del ciclo de vida completo; un candidato completo Se promueve para `response.completed`. Alta confianza `cyber_policy`
+Las formas de terminal se normalizan `response.failed` con `error.code: "cyber_policy"` por semántica registro/contabilidad (estado 400), mientras que una respuesta HTTP transmitida ya iniciada sigue siendo 200. Esto El límite de petición comprometida no vuelve a intentarlo ni a reproducirse y no resuelve
+[#2423](https://github.com/lidge-jun/opencodex/issues/2423) o
+[#2486](https://github.com/lidge-jun/opencodex/issues/2486).
+:::
+
+Para la transmisión directa canónica ChatGPT, el sistema estable Bun 1.4.0 o posterior puede usar de forma transparente el transporte WebSocket aguas arriba de Codex. En el paquete Bun 1.3.14, las versiones preliminares y las identidades de entorno de ejecución no verificables usan HTTP / SSE. El adaptador WS aguas arriba mantiene el mismo contrato aguas abajo SSE, limita tanto el marco JSON sin procesar como su envolvente SSE a 4 MiB, y cierra el flujo arriba cuando su cola de bytes de 8 MiB se desbordaría. Ese desbordamiento emite un evento `response.failed` terminal aguas abajo seguido por `[DONE]`.
+
+El WebSocket aguas arriba comprueba `NO_PROXY` / `no_proxy` primero. De lo contrario, utiliza el primer valor no vacío `HTTPS_PROXY`, `https_proxy`, `ALL_PROXY` o `all_proxy`; `HTTP_PROXY` por sí solo no proxy una conexión WSS. HTTP y HTTPS URL proxy se pasan a Bun. Si el valor seleccionado no es válido o utiliza un protocolo no compatible, opencodex omite el intento WebSocket y utiliza HTTP / SSE en lugar de marcar el flujo ascendente directamente.
+
+Estas reglas pertenecen al transporte WebSocket ascendente, independientemente del proveedor seleccionado. adaptador. HTTP Las solicitudes fetch basadas en Responses, incluida la reserva SSE, utilizan el
+[fetch de salida configurada](/es/reference/configuration/server/#server-fields). Un servidor proxy SOCKS5 — conjunto con `config.proxy` o heredado de un SOCKS5 `ALL_PROXY` — utiliza el túnel incorporado de OpenCodex cuando
+`NO_PROXY`/`no_proxy` No exime al objetivo. Esquema específico
+`HTTP_PROXY`/`HTTPS_PROXY` Los valores retienen el manejo nativo de HTTP(S) de Bun, mientras que un manejo que no es SOCKS
+`ALL_PROXY` No es un nativo HTTP fetch ruta. `config.proxy` llena faltante
+`HTTP_PROXY`/`HTTPS_PROXY` valores; el valor específico del esquema resultante también tiene prioridad sobre Un existente `ALL_PROXY` para WebSocket. Para un HTTPS de origen que requiere un proxy, establezca
+`HTTPS_PROXY` o `config.proxy`; `HTTP_PROXY` solo deja tanto WSS y su HTTPS reserva sin un proxy de esquema coincidente.
+
+Cada objeto de uso del terminal Responses incluye ambos objetos de detalle, incluso cuando el proveedor no informó esos detalles:
+
+```json
+{
+  "input_tokens": 0,
+  "output_tokens": 0,
+  "total_tokens": 0,
+  "input_tokens_details": { "cached_tokens": 0 },
+  "output_tokens_details": { "reasoning_tokens": 0 }
+}
+```
+
+Cuando esté disponible, `input_tokens_details` También puede incluir `cache_write_tokens`. El siempre presente Los objetos de detalle son una garantía de compatibilidad para clientes Responses estrictos; cero puede significar "no" No necesariamente "el proveedor no realizó tal trabajo".
+
+Para Anthropic aguas arriba, un `usage.output_tokens_details.thinking_tokens` reportado se conserva como Responses `output_tokens_details.reasoning_tokens` y Chat `completion_tokens_details.reasoning_tokens`, para JSON y respuestas de transmisión. Ya está incluido en el total del token de salida, no se agrega nuevamente; los detalles faltantes o no válidos no se estiman a partir del texto de pensamiento visible. Véase [Contrato de uso de Anthropic](https://platform.claude.com/docs/en/build-with-claude/thinking-steering-and-cost).
+
+<a id="correlating-a-response-with-its-request-log"></a>
+
+### Correlacionar una respuesta con su registro de solicitudes
+
+Cada respuesta HTTP Responses admitida lleva un encabezado `x-opencodex-request-id` que contiene un id generado por proxy del formulario `ocx-<32 hex>`. Es la clave que vincula una respuesta a su fila en el registro de solicitudes y en los informes de uso.
+
+El proxy siempre genera este valor y sobrescribe cualquier id suministrado por el llamante o devuelto por el flujo ascendente, por lo que es único para este proxy y seguro para confiar como una clave de correlación. El encabezado se nombra en `Access-Control-Expose-Headers`, que es lo que permite al navegador JavaScript leerlo de origen cruzado: un encabezado personalizado `x-` es invisible para `response.headers.get()` incluso cuando está en el cable.
+
+Responses rechazado en la autenticación o la admisión de origen nunca llegan a este envoltorio y no llevan ninguna identificación.
+
+Las respuestas registradas `POST /v1/chat/completions` también llevan `x-opencodex-request-id`, expuesto a través de CORS, para JSON, transmisión, errores de controlador y rechazos de pre-controlador registrados. Este es el id de la historia de la puerta de enlace, independiente del id de finalización del cuerpo de respuesta. Los valores de llamada y ascendente no pueden reemplazarlo. Los rechazos sin un propietario de registro de solicitudes, incluidos los rechazos de autenticación, origen, drenaje y giro activo, no llevan identificación. Los encabezados de transmisión identifican la fila del historial final antes de guardar el uso final.
+
+Las respuestas `POST /v1/messages` registradas llevan el mismo identificador de historial de solicitudes de OCX en **ambos** `request-id` y `x-opencodex-request-id`. Esto se aplica a las respuestas nativas y traducidas, streaming y JSON, y los rechazos registrados. Claude Code puede usar sus metadatos `requestId` persistentes de `request-id` para unir transcripciones futuras a esa fila de historia de OCX.
+
+Se omiten los identificadores de solicitud del proveedor. Las respuestas Messages registradas solo exponen `request-id` y `x-opencodex-request-id` del proxy; ambos siguen siendo legibles mediante CORS junto con los demás encabezados expuestos.
+
+No se agrega ningún ID de OCX a los rechazos de autenticación, origen, drenaje o giro activo que no tienen propietario de registro de solicitudes, o al count_tokens. Los encabezados de transmisión identifican la fila del historial final del turno; no dan fe de que el uso final ya se haya guardado. Las transcripciones antiguas sin una clave compartida permanecen sin vincular; la marca de tiempo o la similitud de token no es una unión exacta.
+
+<a id="websocket-upgrade-on-the-same-path"></a>
+
+### Actualización WebSocket en la misma ruta
+
+Cuando `websockets` está habilitado, un cliente puede actualizar `/v1/responses` en lugar de abrir un POST HTTP. La autenticación y la admisión de origen ocurren durante el apretón de manos WebSocket. No se repiten dentro de cada cuadro.
+
+Esta actualización orientada al cliente es independiente de la selección transparente ascendente ChatGPT WebSocket descrita anteriormente; la configuración `websockets` controla solo el punto final orientado al cliente.
+
+El cliente envía JSON marcos de texto:
+
+```json
+{
+  "type": "response.create",
+  "model": "provider/model",
+  "input": "Hello",
+  "tools": [],
+  "generate": true
+}
+```
+
+Todo excepto `type` se convierte en el cuerpo de solicitud Responses, y el proxy fuerza la transmisión para el giro. Un nuevo `response.create` reemplaza y cancela el giro anterior en ese zócalo. `response.processed` se acepta como un acuse de recibo sin opción. Se ignoran los tipos de fotogramas no analizables o no relacionados.
+
+Los marcos de servidor son marcos de texto JSON. La salida de transmisión exitosa utiliza las mismas JSON cargas útiles que aparecerían en SSE `data:` líneas, sin la envolvente SSE o `[DONE]`. Un resultado interno que no es de flujo continuo se vuelve a enmarcar como `response.created`, cero o más tramas `response.output_item.done`, luego una trama terminal. Los errores usan este sobre:
+
+```json
+{
+  "type": "error",
+  "status": 502,
+  "error": {
+    "type": "upstream_error",
+    "message": "..."
+  },
+  "headers": {}
+}
+```
+
+Un marco de calentamiento con `generate: false` no llama a un flujo ascendente. Devuelve un `response.created` sintético seguido de `response.completed`, ambos con un id de respuesta vacío y sin salida.
+
+:::note
+Cuando WebSockets está desactivado, un intento de actualización recibe HTTP 426 con código
+`upgrade_required`. Codex trata ese resultado de apretón de manos como una señal para volver a HTTP para el sesión. No es un giro modelo fallido.
+:::
+
+## `POST /v1/chat/completions`
+
+Este punto final acepta solicitudes de Chat Completions compatibles con OpenAI con un `model` obligatorio y un array `messages` no vacío. Traduce los mensajes del sistema, usuario, asistente y herramienta en los elementos internos Responses; traduce las herramientas de función, la elección de herramientas, imágenes, esfuerzo de razonamiento y formatos de respuesta compatibles; ejecuta el canal de enrutamiento Responses normal; luego traduce el resultado de nuevo.
+
+Las URL de imagen y las URL de datos base64 usan partes de contenido de Chat `image_url`. La traducción conserva los valores soportados `detail` (`auto`, `low`, `high`). En las rutas traducidas, OpenCodex también acepta matrices de resultados de herramientas portadoras de imágenes como una extensión de compatibilidad: Responses rutas retienen la salida estructurada, mientras que el adaptador `openai-chat` envía imágenes de herramientas en un mensaje de usuario siguiente porque el contenido de la herramienta de chat es de solo texto. Otros adaptadores posteriores tienen su propia ubicación específica del proveedor. Los resultados de texto sin formato siguen siendo cadenas. El passthrough nativo sigue su contrato ascendente; el soporte de imágenes aún depende del modelo seleccionado y la configuración del proveedor.
+
+El razonamiento es parte de esa traducción. `reasoning_effort` (o `reasoning.effort`) se convierte en interno `reasoning.effort`. Debido a que el analizador sintáctico Responses oculta el pensamiento a menos que se establezca `reasoning.summary` y no sea `none`, Chat Completions solicita que se solicite un esfuerzo por defecto a `reasoning.summary: "auto"`, por lo que los flujos de pensamiento se devuelven como `delta.reasoning_content`. Los clientes todavía pueden ocultar rastros con `include_reasoning: false` o `reasoning.summary: "none"`. Un `reasoning.summary` explícito de `auto`, `concise`, `detailed`, o `none` gana sobre `include_reasoning`.
+
+Sin opciones de razonamiento, el razonamiento sin procesar ya devuelto por el proveedor se entrega como `delta.reasoning_content` en streaming o `message.reasoning_content` en respuestas almacenadas, sin añadir opciones a la solicitud saliente. Desactivar explícitamente el pensamiento con `thinking.type: "disabled"` o `reasoning.enabled: false`, o usar el esfuerzo `none`, también oculta ese texto; un booleano explícito de activación prevalece sobre el esfuerzo. Sigue aplicándose `hideRawReasoning` del proveedor. La visibilidad de resúmenes del proveedor mantiene sus valores predeterminados; los clientes Responses y Anthropic Messages no cambian.
+
+Cuando el modelo es Claude, la respuesta también incluye `reasoning_details` con el formato que usa OpenRouter: `{"type": "reasoning.text", "text", "signature", "format": "anthropic-claude-v1"}` para cada bloque de pensamiento firmado y `{"type": "reasoning.encrypted", "data", ...}` para cada bloque redactado, en `message` o como `delta.reasoning_details` (cada entrada llega completa en un solo fragmento). Devuelve el array sin cambios en el mensaje del asistente, junto a sus `tool_calls`, para que Claude conserve el razonamiento entre pasos de herramientas. La firma es opaca y coincide con la que reciben los clientes de `/v1/messages`. OpenCodex solo lo reproduce cuando el modelo se enruta directamente a la API de Anthropic (`api.anthropic.com`) como ruta única. En cualquier otro destino, o si una entrada está mal formada (tipo o formato desconocidos, o falta de firma), el turno usa el texto simple de `reasoning_content`. Una entrada cuyo texto o firma se haya modificado se reenvía tal como está y Anthropic la rechaza; devuelve el array exactamente como lo recibiste.
+
+La salida estructurada es parte de esa traducción: `response_format` con `json_object` o `json_schema` se reenvía a los modelos `openai-chat` enrutados. En `POST /v1/responses` el campo de petición equivalente es `text.format`: rutas nativas Responses lo conservan en el cuerpo bruto Responses, y se traduce a `response_format` cuando el modelo se dirige a un proveedor `openai-chat`. Un modelo listado en el `noStructuredOutputModels` del proveedor omite `response_format` en ese cable de chat; los modelos hermanos mantienen la traducción. Los backends no clasificados reciben el campo y devuelven su propio error en lugar de que el proxy adivine su capacidad.
+
+La salida de no transmisión tiene `object: "chat.completion"`. La salida de transmisión utiliza SSE objetos con `object: "chat.completion.chunk"`, deltas de elección, una opción de terminal con `finish_reason` y `data: [DONE]`. La información de llamada de herramientas y de uso se traducen de vuelta donde los eventos de origen los llevan.
+
+Las respuestas y tramas de error de este endpoint usan mensajes redactados por el proxy. Se clasifica el fallo del proveedor en una condición fija: límite de tasa, cuota o créditos agotados, exceso de contexto, modelo no disponible, ubicación no admitida o verificación de cuenta requerida. Los rechazos de políticas, los de reproducción y los límites del proxy tienen sus propios mensajes fijos. El estado HTTP, `error.type`, `error.code` y `Retry-After` mantienen su significado, de modo que los clientes que distinguen `context_length_exceeded`, `insufficient_quota` o `rate_limit_exceeded` se comportan como antes.
+
+Si una solicitud de Chat de flujo continuo recibe un resultado JSON Responses completo aguas arriba, el proxy sintetiza SSE desde la finalización convertida. Conserva el contenido de respuesta y razonamiento, las llamadas de herramienta de función (con un flujo separado `index` para cada llamada), el uso y el convertido `finish_reason`, incluidos `tool_calls` y `length`. Este respaldo entrega el resultado completado en trozos; no puede proporcionar entrega token por token antes de que llegue la respuesta JSON aguas arriba. No emite una solicitud de inferencia adicional. Una respuesta incompleta causada por el límite de token de salida o el filtrado de contenido retiene `length` o `content_filter`, incluso si incluye la salida de la herramienta. Otros límites incompletos devuelven un error ascendente en lugar de reclamar un final normal.
+
+El texto de rechazo permanece separado del texto de respuesta: las finalizaciones JSON usan `message.refusal` anulable, y los fragmentos de transmisión usan `delta.refusal`. Las conversiones nativas de Chat de JSON a SSE y de SSE a JSON conservan ese campo; el relé de transmisión nativa conserva los deltas de rechazo del proveedor. En los flujos traducidos de Responses, las partes de rechazo se almacenan en búfer hasta el evento terminal y se emiten una vez en su orden original de salida y contenido. Las instantáneas repetidas o dispersas compatibles no duplican ni borran el texto. Las instantáneas de rechazo contradictorias y el desbordamiento del búfer producen un error tipado sin una finalización exitosa ni `[DONE]`. Esto preserva el rechazo ascendente; no introduce una decisión de política de proxy.
+
+Debido a que la ruta de ejecución interna está basada en Responses, un adaptador de proveedor puede imponer un conjunto de características más estrecho. Por ejemplo, una característica de solicitud que no puede ser representada por el adaptador seleccionado se devuelve como un error en lugar de cambiar silenciosamente su significado.
+
+<a id="post-v1messages-and-count_tokens"></a>
+
+## `POST /v1/messages` y `count_tokens`
+
+Estos puntos finales hablan el dialecto Anthropic Messages utilizado por Claude Code y clientes compatibles. La mayoría de las solicitudes se traducen a Responses, se enrutan normalmente, luego se traducen a Anthropic JSON o Anthropic SSE.
+
+Los flujos SSE nativos y de reenvío del cliente solo normalizan errores cuando el primer campo que no sea comentario de un bloque es exactamente `event:error` o `event: error`. Los comentarios iniciales pasan sin ocupar esa posición. Los bloques que comienzan por data, id, retry, otro evento o un campo desconocido conservan sus bytes y tiempos de entrega, aunque un campo posterior nombre error; sus datos de error quedan fuera de esta normalización. El error final normalizado contiene solo la declaración de error, los campos data y el terminador. Se omiten los campos id, retry, comentarios, desconocidos y eventos repetidos posteriores a la declaración, incluso cuando data está vacío. No se retiene ningún prefijo de un posible evento. Los delimitadores CR/LF divididos conservan la entrega de eventos posteriores y el cierre del flujo.
+
+Tras una declaración apta se retiene un sufijo de error de hasta 1 MiB. Dentro de ese límite, si el evento cambia después a un nombre que no es error, el sufijo original se reproduce sin cambios después de decidir el límite del bloque; ese sufijo sí se demora. En los demás casos, el diagnóstico completo seleccionado por el SDK determina el mensaje fijo y la recuperación. Si se supera el límite, incluso un cambio de nombre posterior fuerza api_error sin código y la frase fija `The provider stream reported an error.`, sin indicación de compactación. Esta excepción OVERSIZE-1M cambia los datos y el reconocimiento del error sin modificar el estado HTTP. La excepción independiente FOLD-502 cambia de 200 a 502 los sobres nativos sin streaming que contienen errores recopilados, conservando la presentación de su contenido. Los cuerpos correctos de passthrough almacenados en búfer mantienen sus bytes originales.
+
+En las solicitudes Messages traducidas, la repetición razonada comparte el presupuesto de traducción de la solicitud. La admisión del sobre incluye la sobrecarga de la copia de codificación/decodificación, no solo la longitud de la firma original. Las solicitudes que excedan este presupuesto devuelven HTTP 413 con `translation_buffer_limit`; las firmas y los datos de razonamiento opacos nunca se truncan para hacer que una solicitud se ajuste. Native Anthropic passthrough conserva su contrato de tamaño de cuerpo separado.
+
+Las fuentes de imagen Base64 y URL se traducen en mensajes de usuario y resultados de herramientas anidados. Las imágenes respaldadas por archivos (`source.type: "file"`) requieren un paso nativo de Anthropic; las rutas traducidas devuelven un error fijo de HTTP 400 que solicita la entrada de base64 o URL. OpenCodex no resuelve el almacenamiento de archivos de otro proveedor ni carga la imagen referenciada en nombre del llamante.
+
+Cuando el historial de reproducción contiene un resultado de herramienta portadora de imagen sin su llamada adyacente, los adaptadores Anthropic y Command Code retienen la imagen en un portador de usuario etiquetado con procedencia en lugar de incrustar sus bytes en el texto de solicitud. No inventan una llamada de herramientas exitosa. Los resultados para llamadas pendientes válidas todavía preceden a estos operadores, preservando el contrato de emparejamiento ascendente.
+
+Para los modelos externos Cursor, las capturas de pantalla data-URL en el lote activo de resultados de herramientas de seguimiento se adjuntan a la solicitud de continuación. El límite de conexión activa de 12 imágenes existente se aplica a todo el lote. Las etiquetas de origen delimitadas permanecen al lado de los archivos adjuntos, incluso si se poda la historia anterior. El manejo de Native Composer/ MCP, la recuperación de imágenes históricas y la política de omisión de URL remota no se modifican; esto no promete que todos los modelos puedan ver todas las fuentes de imágenes.
+
+El pase nativo Anthropic solo es elegible cuando todos estos son verdaderos:
+
+- passthrough nativo no ha sido deshabilitado en la configuración Claude Code;
+- el modelo solicitado comienza con `claude` o `anthropic`;
+- la solicitud lleva un portador nativo Anthropic o una credencial `x-api-key`;
+- en un oyente que no es de bucle de retorno, la solicitud también incluye una admisión de proxy válida solo en `x-opencodex-api-key`; y
+- ningún alias configurado o mapa de modelo reclama ese id de modelo para un destino encaminado.
+
+Una solicitud elegible se reenvía en el dialecto Anthropic para que los encabezados beta nativos, las firmas de pensamiento y la identidad de suscripción se conserven de extremo a extremo. De lo contrario, la solicitud hace el recorrido de ida y vuelta de Responses.
+
+El encabezado de admisión dedicado nunca se reenvía. También se eliminan los secretos de admisión proxy encontrados en `Authorization` o `x-api-key`; se conserva una credencial Anthropic genuina separada. Las cabeceras de credenciales unidas por coma ambiguas fallan en lugar de ser reenviadas.
+
+`POST /v1/messages/count_tokens` sigue la misma resolución de modelo y decisión de paso. Una solicitud elegible nativa se reenvía al punto final de recuento de Anthropic. Otras solicitudes utilizan la estimación documentada local sobre el contenido, los mensajes y las herramientas del sistema y devuelven:
+
+```json
+{ "input_tokens": 123 }
+```
+
+Un ID de escritorio en forma de fecha no resuelto también puede ser un modelo nativo genuino que falta en el descubrimiento. Messages y count-tokens devuelven HTTP 503 con el error `desktop_model_mapping_unavailable` fijo cuando la evidencia disponible no puede resolver ese ID; esto no establece que el modelo no es válido. Los alias de hash heredados desconocidos todavía devuelven HTTP 400. Ninguno de los casos quita la fecha o vuelve a otra ruta. Los ID conocidos, las asignaciones registradas y las coincidencias exactas `modelMap` mantienen su comportamiento existente, incluidos los ID nativos reales reconocidos. Actualizar el descubrimiento del modelo o volver a aplicar el perfil del concentrador conectado antes de volver a intentarlo; reintentar solo no garantiza la resolución.
+
+## `GET /v1/models`
+
+Sin `format=desktop-config`, los contratos de catálogo ordinarios son:
+
+| Contrato | Desencadenante | Forma de nivel superior | Comportamiento de ID de modelo |
+| --- | --- | --- | --- |
+| Anthropic lista de modelos | `anthropic-version` o `?flavor=anthropic`, sin `client_version` | `{ "data": [...] }` con entradas de información del modelo Anthropic | Claude Code recibe identificadores legibles; Desktop puede recibir su familia de alias específica de perfil |
+| Catálogo Codex | `client_version` parámetro de consulta | `{ "models": [...] }` | Las entradas nativas y enrutadas llevan los más ricos campos de catálogo Codex, visibilidad, esfuerzo, WebSocket y metadatos de agentes múltiples. |
+| Plain OpenAI lista | Ninguno de los gatillos | `{ "object": "list", "data": [...] }` | Los id nativos visibles están desnudos; los id enrutados son alias o `provider/model` |
+
+<a id="desktop-configuration-snapshot"></a>
+
+### Instantánea de configuración del escritorio
+
+`GET /v1/models?ids=desktop&format=desktop-config` selecciona explícitamente la instantánea de escritorio, independientemente de la detección de agente de usuario. La respuesta es `{ "version": 1, "models": [...] }` con `Cache-Control: no-store`. El cliente conectado envía `Accept: application/json`, `anthropic-version: 2023-06-01` y su credencial de datos existente; no se involucra la carga de tokens o perfiles de administrador. Las entradas son los modelos de configuración de escritorio emitidos por el concentrador, no las filas de catálogo Codex.
+
+La combinación de este formato con `ids=cli` o cualquier `client_version` devuelve HTTP 400. Sin el selector de formato, los contratos ordinarios anteriores permanecen sin cambios. Cuando Claude está deshabilitado, la instantánea es `{ "version": 1, "models": [] }`; Connected Desktop apply trata esto como no disponible y no escribe un perfil de reemplazo. Los antiguos hubs que devuelven un catálogo ordinario en lugar de la versión 1 no son compatibles; el cliente no recurre a los ID generados localmente.
+
+La instantánea sigue siendo un contrato de lista de modelos de solo lectura; no es una rotación de claves ni una carga de perfil API. La migración, recuperación y desconexión de claves de escritorio conectadas funcionan a través del ciclo de vida del cliente existente. La rotación conserva las entradas y selecciones del modelo; CLI `rotation` distingue `committed` de `rolled_back`. Desconectar restaura la configuración propia o informa de una reserva estándar heredada conocida, preservando los campos de usuario y selecciones válidas posteriores. Los conflictos o la recuperación incompleta impiden una reclamación de finalización. Reinicie el escritorio para cargar los cambios de disco; la desconexión no revoca automáticamente la clave de concentrador. Véase [Claude Desktop ciclo de vida](/es/guides/claude-code/). La repetición de pensamiento y el trabajo de caché rápida permanecen separados en [#3719](https://github.com/lidge-jun/opencodex/issues/3719).
+
+<a id="post-v1live-and-realtime-sideband"></a>
+
+## `POST /v1/live` y banda lateral en tiempo real
+
+<a id="external-api-keys"></a>
+
+### Claves API externas
+
+Los clientes externos usan una clave OpenCodex en cualquier encabezado de credencial de audio compatible, o el par de subprotocolos del navegador descrito anteriormente. Independiente `WS /v1/live?model=gpt-live-1-codex` utiliza el protocolo Frameless; un modelo omitido por defecto a ese identificador y `gpt-live-1` es su alias proxy. Esta no es una afirmación de que cada clave pública OpenAI Realtime SDK o API sea compatible con GPT-Live.
+
+Para una nueva conexión independiente, envíe la inicialización compatible con la fuente a continuación después de que se abra el socket y espere a `session.started` con un `session.id` no vacío. Un evento de sesión actualizada con la misma forma también es aceptado por el cliente nativo.
+
+```json
+{"type":"session.update","session":{"instructions":"","audio":{"output":{"voice":"cove"}},"delegation":{"type":"client"}}}
+```
+
+Frameless utiliza `input_audio.append` y `output_audio.delta`, a diferencia del dictado `audio.append`. Una comprobación solo de conexión no necesita micrófono ni marcos de audio; envíe `{"type":"session.close"}` y cierre el zócalo después de la preparación. Los eventos de delegación son solicitudes de trabajo, no señales de preparación, y el cliente externo posee su ejecución y respuestas.
+
+Para WebRTC, publique una oferta de SDP a `/v1/live` como multiparte `sdp` y opcional JSON `session`, JSON `{sdp, session?}` o `application/sdp` en bruto. La respuesta contiene la respuesta y un proxy relativo `Location` con un ID de llamada `rtc_ocx_` opaco. Unirse a esa ubicación utilizando la misma clave proxy. El proxy resuelve el proveedor de creación y la cuenta física incluso si cambia la selección Pool. Los alias desconocidos, caducados u otras claves fallan antes de una conexión ascendente. La rotación de claves del cliente conserva la propiedad por ID de clave; la sustitución de una credencial ascendente con clave requiere una nueva llamada. Las bandas laterales de llamada existentes no necesitan otra actualización de sesión.
+
+Los enlaces de llamadas duran 30 minutos, están limitados a 1024 entradas por servidor y finalizan en el reinicio del servidor. Los tiempos de vida del socket están limitados de forma independiente; los medios viajan directamente sobre WebRTC y no están representados. El proxy nunca ejecuta solicitudes de delegación. La disponibilidad de la cuenta OpenAI se establece por la respuesta ascendente real, no por la presencia de un nombre de modelo en el panel de control.
+
+<a id="native-codex-compatibility"></a>
+
+### Compatibilidad nativa con Codex
+
+Las personas que llaman en modo clave nativo API en el oyente local de confianza pueden usar la credencial exacta configurada para el nivel canónico OpenAI API. Otros valores de soporte presentados requieren una clave proxy registrada o un par de token/cuenta ChatGPT explícito, coincidente; un prefijo de clave arbitraria no es prueba de credenciales nativas. Las llamadas nativas locales de confianza sin credenciales conservan su comportamiento existente.
+
+`POST /v1/live` acepta la superficie de creación de llamadas sin marco de la aplicación ChatGPT / Codex. `POST /v1/realtime/calls` acepta la superficie de creación de llamadas en tiempo real OpenAI. opencodex selecciona una ruta de familia OpenAI elegible, normaliza la solicitud de creación de llamada para el modo de autenticación ascendente y retransmite la respuesta limitada.
+
+Después de la creación de la llamada, los clientes pueden unirse a una banda lateral WebSocket usando cualquier formulario entrante admitido:
+
+- `/v1/live/{callId}`
+- `/v1/realtime/calls/{callId}`
+- `/v1/realtime?call_id={callId}`
+
+El proxy normaliza la URL de conexión aguas arriba y luego retransmite de forma transparente el texto y los marcos binarios en ambas direcciones. Los encabezados de protocolo del cliente se conservan, mientras que la autenticación aguas arriba sigue siendo propiedad del proxy.
+
+La creación de la llamada y la conexión de banda lateral deben usar la misma cuenta de OpenAI; de lo contrario, el servidor de origen rechaza la conexión (`404`). Ambas operaciones llevan los encabezados `session-id` y `thread-id` de Codex. En Pool, la cuenta queda vinculada a ese par dentro del proceso: la conexión reutiliza la cuenta que creó la llamada. Direct reenvía la credencial bearer actual de quien realiza la solicitud en ambas operaciones. Los encabezados de cliente retransmitidos son exactamente `openai-alpha`, `x-session-id`, `session-id`, `thread-id`, `originator`, `x-oai-attestation`, `x-codex-turn-metadata` y `voice-session-id`, que identifica la sesión de voz del cliente y es distinto del `x-session-id` de tiempo real (`LIVE_CLIENT_PROTOCOL_HEADERS` en `src/server/live.ts`). Cada encabezado solo se retransmite si lo envió el cliente; no se inventa ninguno. El proxy controla `Authorization` y el ID de cuenta de ChatGPT en sus rutas: Pool usa la cuenta guardada y Direct la credencial validada del cliente; un proveedor con clave API usa su propia credencial bearer. Codex solo envía esta conexión al proxy cuando `experimental_realtime_ws_base_url` apunta a él. `ocx start` inyecta esa clave junto con `openai_base_url`; consulta [Integración con Codex](/es/guides/codex-integration/).
+
+<a id="checkpoint-replay-on-routed-providers"></a>
+
+## Reproducción de checkpoints en proveedores enrutados
+
+Cuando un modelo enrutado recibe un checkpoint portátil legible (`ocx1:`/`ocx2:`) o de texto plano, OpenCodex identifica como contexto histórico las solicitudes anteriores del usuario que solo contienen texto. Así se distingue el trabajo completado del pendiente, conservando los detalles originales y el contenido del checkpoint. La entrada posterior sigue siendo actual, incluidas pausas, cancelaciones y tareas de reemplazo. El texto de checkpoints o herramientas no concede nuevas autorizaciones y los permisos pendientes siguen vigentes. Este encuadre del prompt no restaura los envoltorios externos de tareas que el cliente haya omitido ni garantiza qué tarea elegirá el modelo.
+
+## `POST /v1/responses/compact`
+
+La compactación devuelve el historial de reemplazo para los clientes que necesitan acortar una larga conversación Responses.
+
+| Tipo de ruta | Comportamiento |
+| --- | --- |
+| Canonical ChatGPT o ruta oficial OpenAI | Prueba el punto final nativo `/responses/compact` con la autenticación de cuenta y modelo resuelta; HTTP 404 vuelve a caer a un giro de compactación regular Responses |
+| Puerta de enlace `openai-responses` explícitamente incorporada | `supportsNativeCompactEndpoint: true` intenta el punto final v1 nativo para la clave/local/directa usando el transporte Responses normal del proveedor; HTTP 404 utiliza respaldo portátil; OAuth conserva la compactación enrutada y la resolución de credenciales |
+| Otro modelo ruteado | Ejecuta un giro de compactación interno, sin transmisión, sin herramientas con un `compaction_trigger`; requiere exactamente un artículo sintético `compaction` cuyo `encrypted_content` es un sobre `ocx1:`; decodifica ese resumen en el historial de reemplazo v1 |
+
+La capacidad de punto final v1 personalizada es independiente de la v2 `supportsNativeCompactionTrigger` y de la `decodesNativeCompactionBlobs` para la reproducción. Ninguno otorga la identidad canónica OpenAI o el reenvío de credenciales de llamada. Las anulaciones de proveedores cruzados siguen siendo portátiles; el éxito v2 solo no establece soporte para `/responses/compact`. Véase [configuración del proveedor](/es/reference/configuration/providers/).
+
+Si el punto final compacto nativo devuelve HTTP 404, OpenCodex vuelve a intentar la compactación a través de un giro regular Responses con el mismo selector de modelo y encabezados de sesión. Los turnos de reserva de Canonical ChatGPT usan SSE aguas arriba; quien llama a la compactación sigue recibiendo JSON. Un elemento de compactación opaco nativo completado se conserva, mientras que un resumen `ocx1:` se decodifica en el historial de usuario de reemplazo. Los turnos de reserva fallidos o incompletos devuelven un error en lugar del historial de reemplazo. Otros estados compactos nativos conservan su manejo existente.
+
+Codex nombra un modelo de la familia OpenAI (por ejemplo `gpt-5.6-sol`) para sus vueltas de compactación, independientemente de a qué proveedor se dirija el operador. Las solicitudes ordinarias reservan dichos identificadores para el proveedor canónico `openai`. En la superficie de compactación solamente - `POST
+/v1/responses/compact` y un giro `POST /v1/responses` que lleva un `compaction_trigger` - un modelo nativo desnudo sin un proveedor canónico `openai` habilitado vuelve al `defaultProvider` configurado como el resumen en lugar de devolver 404. La alternativa se aplica solo cuando el proveedor predeterminado está habilitado y no es en sí mismo una entrada de la familia OpenAI; los selectores calificados para la cuenta como `side/gpt-5.6-sol` aún fallan. El proxy registra un aviso por proveedor cuando se activa esta reserva. Las configuraciones con un proveedor canónico `openai` habilitado no cambian.
+
+Los cuerpos entrantes tanto en `/v1/responses` como en `/v1/responses/compact` conservan el límite de admisión de 256 MiB de cable/descompresión compartido. El rechazo de tamaño a nivel de aplicación devuelve HTTP 413 con `type` y `code` ambos `invalid_request_error`. Su mensaje incluye un sufijo de diagnóstico limitado, por ejemplo:
+
+```text
+Decompressed request body exceeds 268435456 bytes [measurement=decoded_lower_bound; bytes=268435457]
+```
+
+| Medición | Significado de `bytes` |
+| --- | --- |
+| `declared_wire` | `Content-Length` numérico declarado por el remitente; rechazado antes de la lectura, no un tamaño decodificado medido |
+| `observed_wire_lower_bound` | Bytes recibidos hasta detener la lectura; el cuerpo completo puede ser más grande |
+| `decoded_exact` | Tamaño exacto de la memoria intermedia suministrada al descodificador de identidad o devuelta por un descodificador |
+| `decoded_lower_bound` | Límite de admisión más uno después de abortar la inflación; un límite inferior, nunca el tamaño decodificado exacto |
+
+El sufijo contiene solo una categoría fija y un valor de byte numérico finito. Los cuerpos rechazados no se leen ni se inflan más, se analizan para el recuento de artículos o se retienen para el diagnóstico. Los errores heredados sin procedencia de medición retienen el mensaje de solo límite. El oyente de Bun puede rechazar un cuerpo recibido que supera el límite antes de que se ejecute el diagnóstico de la aplicación, por lo que no cada 413 lleva este sufijo. Un diagnóstico de límite inferior no puede establecer el tamaño completo de la carga útil compacta. El límite de admisión y el comportamiento de reintento no cambian.
+
+Las respuestas compactas nativas se almacenan en búfer con un máximo separado de 32 MiB, incluidas las respuestas cuyos `Content-Length` declarados ya exceden el límite. Los fallos específicos de los compactos incluyen:
+
+| Situación | Tipo o código | Descripción |
+| --- | --- | --- |
+| 400 | `invalid_request_error` | Inválido JSON /forma del cuerpo o modelo faltante |
+| 404 | `invalid_request_error` | El modelo solicitado no se puede enrutar |
+| 499 | `client_cancelled` | El cliente canceló mientras reenviaba o almacenaba búfer |
+| 502 | `compact_response_too_large` | La salida compacta nativa superó los 32 MiB |
+| 502 | `upstream_error` | Fallo de conexión, lectura o compactación sintética |
+| 502 | `invalid_response_error` | El giro sintético no produjo exactamente un artículo de compactación `ocx1:` válido y no vacío. |
+
+<a id="authentication-matrix"></a>
+
+## Matriz de autenticación
+
+En un enlace de solo loopback, la admisión del plano de datos no requiere una clave configurada. En un enlace remoto, utilice la matriz siguiente. "Dedicado" significa `X-OpenCodex-API-Key`; las demás columnas significan `Authorization: Bearer ...` y `x-api-key`.
+
+| Superficie | Dedicado | Bearer | `x-api-key` |
+| --- | --- | --- | --- |
+| `/v1/responses` HTTP y WebSocket | Aceptado | Aceptado | Rechazado |
+| `/v1/responses/compact` | Aceptado | Aceptado | Rechazado |
+| `/v1/chat/completions` | Aceptado | Aceptado | Rechazado |
+| `/v1/messages` y `/v1/messages/count_tokens` | Aceptado | Aceptado | Aceptado |
+| `/v1/models` | Aceptado | Aceptado | Aceptado |
+| `/v1/live`, `/v1/realtime/calls` y las uniones por banda lateral | Aceptado | Aceptado | Aceptado |
+
+Las solicitudes de la familia Responses y de Chat aceptan una clave del proxy en el encabezado dedicado o en el campo Bearer. En las rutas nativas, la credencial Codex almacenada y seleccionada sustituye al bearer de admisión; en las demás rutas se elimina. Nunca es una credencial aguas arriba. Utilice el encabezado dedicado cuando también envíe un bearer de proveedor distinto.
+
+Una ruta de Cursor sin clave y que no usa OAuth puede utilizar ese bearer del llamante distinto, pero nunca un secreto del proxy ni el enriquecimiento automático con la cuenta principal de ChatGPT. La selección de Combo o de política y las reescrituras reales de shadow/creación de hilos no transfieren las credenciales sin procesar del llamante a los nuevos destinos. El enrutamiento canónico de OpenAI puede restaurar el único bearer no perteneciente al proxy del llamante tras un cambio de ruta interno solo cuando su JWT lleva una reclamación de cuenta de ChatGPT y cualquier encabezado de cuenta explícito coincide con esa reclamación. Reenviar la autenticación del llamante a los sidecars opcionales de OpenAI exige un único JWT y un `chatgpt-account-id` explícito que coincida. Los bearers opacos no se restauran tras los cambios de ruta, ni siquiera con un encabezado de cuenta explícito. De lo contrario, el destino final necesita su propia credencial configurada, OAuth o almacenada; si no la tiene, falla localmente. Un marcador de creación de hilo por sí solo no elimina las credenciales.
+
+El enriquecimiento opcional de Chat con la cuenta principal almacenada para una solicitud de Cursor sin clave se aplaza hasta que de verdad se planifique un ayudante de OpenAI y haya un candidato Direct canónico disponible. Una solicitud de Cursor no relacionada no adquiere una reclamación de cuenta principal nativa mediante este enriquecimiento, así que no retrasa el cambio de perfil. Las credenciales del ayudante siguen obedeciendo las barreras de inicio y de cambio y permanecen separadas del bearer de Cursor. Los ayudantes de Pool y los cualificados por cuenta conservan su selección de cuenta existente.
+
+La repetición de Claude retiene la autenticación principal solo como una instantánea en memoria reclamada por el turno y la reconstruye únicamente para una ruta canónica final de ChatGPT.
+
+:::caution
+Las claves del plano de datos no son credenciales de administración. La API de administración usa un secreto de administrador distinto; consulte [API de administración](/es/reference/management-api/). Nunca reutilice un mismo secreto para ambos planos.
+:::
+
+<a id="common-error-vocabulary"></a>
+
+## Vocabulario de error común
+
+Los errores usan la envolvente del dialecto del cliente cuando es necesario, pero estos significados de estado/código son estables:
+
+| Situación | Tipo o código | Descripción |
+| --- | --- | --- |
+| 401 | `authentication_error` | Una credencial de admisión proxy requerida no está disponible o no es válida |
+| 403 | `origin_rejected` | Una solicitud de plano de datos Responses / OpenAI o una actualización WebSocket provienen de un origen no permitido |
+| 503 | `combo_unavailable` | Todos los objetivos del combo seleccionado no están disponibles, en tiempo de reutilización, desactivados o no son elegibles |
+| 400 | `unreadable_encrypted_agent_task` | Una tarea de trabajador encriptada v2 no tiene un objetivo canónico ChatGPT elegible o un objetivo de autenticación de clave directa Responses explícitamente confiable con `allowEncryptedV2AgentTasks: true` que puede consumirlo |
+| 426 | `upgrade_required` | El Responses WebSocket transporte está desactivado o la actualización falló; use HTTP |
+
+Los fallos de origen de Anthropic se representan con la envolvente de error de Anthropic, por lo que un rechazo de origen es un 403 `permission_error` en ese dialecto en lugar del cuerpo `origin_rejected` al estilo de OpenAI.
+
+<a id="encrypted-content-hygiene"></a>
+
+## Higiene de contenido cifrado
+
+El proxy trata el texto cifrado de backend genuino como opaco. El texto cifrado estructuralmente válido se conserva byte por byte: opencodex no lo descifra, traduce su contenido o lo vuelve a cifrar para otro proveedor.
+
+Algunos ganchos de agentes han colocado históricamente texto de control en una ranura `encrypted_content`. Por compatibilidad, el proxy separa ese texto plano en partes de texto mientras conserva cualquier Fernet estructuralmente válido que se ejecute sin cambios. Si un `agent_message` pierde todas las partes encriptadas durante esa reparación, se convierte en un mensaje de usuario normal. Si una tarea v2 actual permanece genuinamente encriptada pero el destino enrutado seleccionado no puede leer el texto cifrado nativo ChatGPT, opencodex falla con `unreadable_encrypted_agent_task` en lugar de enviar bytes ilegibles a ese proveedor. Consulte [Superficie del subagente](/es/guides/sub-agent-surface/) para conocer el comportamiento del cliente en torno a las tareas de los trabajadores.
+
+La historia también se maneja, y de manera diferente, porque perder un mensaje repetido no debe terminar una conversación. Un `agent_message` reproducido que mezcla texto legible con texto cifrado de extremo posterior no se puede bajar a un mensaje público, por lo que un destino Responses encaminado recibiría de otro modo el texto cifrado junto con un tipo de elemento que solo declara el extremo posterior ChatGPT. Antes del envío, opencodex reemplaza ese texto cifrado con `[encrypted content omitted]`, el mismo marcador que ya sustituye después de un fallo de descifrado ascendente, lo que deja el elemento bajable y el texto legible intacto. El proveedor nunca ve el texto cifrado o el elemento privado, y la conversación continúa. Los objetivos combinados se reparan individualmente, ya que cada uno recibe su propia copia de la solicitud. El canónico ChatGPT Codex backend está exento porque es el destino que acuña y puede leer esos bytes; un proveedor `forward` señaló a cualquier otro origen no está exento. Las rutas `allowEncryptedV2AgentTasks` de confianza explícita y los cables Chat o Anthropic traducidos no se ven afectados, al igual que otros tipos de elementos, como los blobs de razonamiento y de salida de herramientas, que mantienen su recuperación de fallo de descifrado existente.
+
+<a id="switching-providers-in-an-existing-conversation"></a>
+
+### Cambiar de proveedor en una conversación existente
+
+Un elemento de razonamiento repetido lleva `encrypted_content` que solo el proveedor y la credencial que lo produjo pueden leer. Cuando opencodex sabe que la conversación fue atendida por última vez por un proveedor diferente, elimina esa mancha antes de enviarla y guarda el resumen del artículo. Si ese proveedor también usó un punto final o una credencial diferente, el identificador `rs_…` del elemento también se elimina, porque nombra un elemento que el nuevo destino no puede buscar. Cuando no puede saber, por ejemplo después de un reinicio proxy, el nuevo destino rechaza el blob en su lugar: OpenAI y Azure OpenAI responden `400 invalid_encrypted_content`. opencodex luego reenvía la solicitud una vez sin el estado de razonamiento del proveedor anterior. El blob se va, y también lo hace el id `rs_…` del elemento de razonamiento, porque ese id nombra un elemento que el proveedor anterior almacenó y el nuevo destino respondería `Item with id 'rs_…' not found`.
+
+Esta recuperación se aplica a todos los adaptadores que hablan el cable Responses, así `openai-responses` y
+`azure-openai` Comportarse de la misma manera. Después de una recuperación exitosa, los giros posteriores de esa conversación en el mismo destino, deje caer el estado extranjero antes del primer envío para los próximos cinco minutos, sin otro viaje rechazado. El reenvío cuenta con el presupuesto de envío normal de la solicitud. Un ordinario 400 y un 429 nunca se vuelven a intentar de esta manera, y tampoco lo es un 5xx, con una estrecha. excepción: un 502 cuyo cuerpo es la herramienta encriptada exacta descifra el rechazo, enviado para una solicitud que lleva la salida de la herramienta cifrada, obtiene el mismo reenvío único. Un segundo rechazo llega a cliente sin cambios. Si eso sucede, inicie una nueva conversación en el proveedor de destino.
+
+<a id="malformed-tool-call-history"></a>
+
+### Historial de llamadas de herramientas mal formado
+
+Las solicitudes enrutadas toleran los argumentos de función serializados mal formados como un objeto vacío. Dos reparaciones de historial acotado preservan argumentos utilizables: falta un prefijo de objeto JSON, y el rastro de MiMo `</function></tool_call>` sobre con una cita de cierre o soporte que falta. Una reparación debe decodificar a un objeto JSON. Se conservan los valores válidos de JSON que contienen esas etiquetas.
+
+### Validación de herramientas y compactación
+
+Al traducir Chat Completions a Responses de OpenAI o al backend ChatGPT, las herramientas de función mantienen el valor no estricto de Chat: si se omite `strict`, se envía false; los booleanos explícitos se conservan. Las `functions` heredadas tampoco se vuelven estrictas. Los argumentos opcionales —incluidos los selectores alternativos de índice y coordenadas de `computer_use`— siguen siendo opcionales. No se reescribe el esquema ni cambian los predeterminados de Responses nativo, destinos Chat o proveedores Responses externos.
+
+Una entrada de compactación retenida de OpenCodex mal formada (`ocx2:`) devuelve HTTP 400 con `error.type: "invalid_request_error"` antes de enrutar, elegir cuenta, refrescar credenciales o enviar al proveedor. No provoca reintentos ni registra un fallo contra una cuenta Codex del pool.
diff --git a/docs-site/src/content/docs/es/troubleshooting/codex-cannot-sign-in.md b/docs-site/src/content/docs/es/troubleshooting/codex-cannot-sign-in.md
new file mode 100644
index 00000000000..742a2299b5b
--- /dev/null
+++ b/docs-site/src/content/docs/es/troubleshooting/codex-cannot-sign-in.md
@@ -0,0 +1,93 @@
+---
+title: "Codex no puede iniciar sesión ni cargar"
+description: "Qué comprobar si Codex no puede iniciar sesión o si todas las solicitudes fallan después de configurar opencodex."
+---
+
+Si Codex se detiene en una pantalla de inicio de sesión, informa que no puede cargar los requisitos de inicio de sesión o falla en todas las solicitudes de modelo después de configurar opencodex, la causa más probable es que Codex todavía esté apuntado al proxy opencodex mientras el proxy no se está ejecutando. Esto se informó como [#5261](https://github.com/lidge-jun/opencodex/issues/5261).
+
+<a id="why-this-happens"></a>
+
+## Por qué sucede esto
+
+En la configuración de loopback predeterminada, opencodex no le da a Codex un proveedor separado. Apunta el propio proveedor Codex incorporado de `openai` en el proxy, escribiendo una anulación de raíz en `$CODEX_HOME/config.toml` (`%USERPROFILE%\.codex` en Windows):
+
+```toml
+model_catalog_json = "/absolute/path/to/opencodex-catalog.json"
+# Auto-injected by opencodex (undo: ocx restore)
+openai_base_url = "http://127.0.0.1:10100/v1"
+# Auto-injected by opencodex (undo: ocx restore)
+experimental_realtime_ws_base_url = "http://127.0.0.1:10100/v1"
+```
+
+Esas líneas están en el disco, por lo que sobreviven a un reinicio. Si el proxy no se está ejecutando cuando se inicia Codex, esa dirección no responde a nada, y Codex no tiene un segundo punto final al que recurrir. La pantalla que obtienes no dice nada sobre opencodex, por lo que es fácil malinterpretar el estado como un problema Codex.
+
+El proxy puede estar ausente por razones ordinarias. La aplicación de la integración Codex no instala un servicio en segundo plano, es decir, un paso separado `ocx service install`, por lo que después de un reinicio puede no haber nada para recuperar el proxy. Una tarea programada registrada Windows comienza en el inicio de sesión en lugar de en el arranque, y también se puede deshabilitar, no iniciar o perder el puerto a otro proceso.
+
+<a id="get-codex-working-again"></a>
+
+## Haga que Codex vuelva a funcionar
+
+Elija el resultado que desee. Ambos son seguros para ejecutar mientras el proxy está abajo.
+
+**Mano Codex a su propia cuenta y puntos finales:**
+
+```bash
+ocx restore
+```
+
+Esto elimina el enrutamiento inyectado, la anulación en tiempo real y el puntero de catálogo opencodex, y no necesita proxy en ejecución, ninguna sesión de panel de control ni red. Codex se registra y corre normalmente después. Cuando se quiere opencodex atrás, `ocx restore back` vuelve a señalar Codex en el proxy.
+
+**O vuelva a iniciar el proxy:**
+
+En una primera terminal, inicie el proxy en primer plano y déjela abierta:
+
+```bash
+ocx start
+```
+
+En una segunda terminal, compruebe que `ocx ready --json` indique `ready: true` antes de instalar el servicio. Después, repita las comprobaciones para verificar el servicio resultante:
+
+```bash
+ocx ready --json
+ocx status --json
+ocx service install   # keep it running across restarts
+ocx ready --json
+ocx status --json
+ocx service status --json
+```
+
+La instalación explícita del servicio detiene el proxy independiente registrado antes de iniciar el servicio administrado; por eso la primera terminal puede finalizar durante la instalación. Si esa limpieza no puede completarse de forma segura, la instalación se rechaza. Después comprueba que un entorno OpenCodex responda en el puerto del servicio instalado. La consulta de disponibilidad anterior a la instalación solo verifica el proxy independiente. Usa las comprobaciones posteriores de disponibilidad, estado del proxy y estado del servicio para verificar el cambio de supervisor.
+
+`ocx status` informa si el proxy está respondiendo y si Codex está actualmente enrutado a través de él. `ocx doctor` explica el mismo estado con más detalle y nombra la reparación que recomienda.
+
+<a id="if-ocx-is-not-available"></a>
+
+## Si ocx no está disponible
+
+Puede deshacer el enrutamiento a mano. Abra `$CODEX_HOME/config.toml` y elimine tres cosas: la línea `openai_base_url`, la línea `experimental_realtime_ws_base_url` y cualquier línea `model_catalog_json` que termine en `opencodex-catalog.json`. Elimina el comentario `# Auto-injected by opencodex` que se encuentra directamente encima de cada uno de los dos primeros junto con ellos.
+
+Vaya por el nombre de la clave, no por el comentario. opencodex utiliza el mismo comentario de propiedad sobre otras claves que administra, como una `developer_instructions` inyectada, y eliminarlas no le ayudará a iniciar sesión mientras le cuesta la configuración que desee recuperar.
+
+Los comentarios de propiedad independientes repetidos no cambian los valores TOML ni el enrutamiento. La reinyección y eliminación en la mesa del proveedor consumen el marcador desnudo exacto o su forma `(undo: ocx restore)` inmediatamente por encima de `[model_providers.opencodex]`. El texto del marcador dentro de otro comentario de usuario o una cadena multilínea se conserva; los comentarios existentes separados de la tabla no son reclamados por esa transformación. La propiedad de enrutamiento raíz utiliza un marcador adyacente exacto en una asignación raíz estructural. Un valor inyectado coincidente registrado en la revista también demuestra la propiedad después de que una aplicación Codex reescriba comentarios. Citar el marcador en un comentario de usuario o una cadena multilínea no prueba la propiedad. Los reemplazos administrados `web_search` registran la asignación original completa, incluidos los valores multilínea, por lo que volver a encenderla o restaurarla de nuevo puede devolverla. La eliminación y la captura validan las asignaciones completas sin convertir un entero válido de 64 bits en un número JavaScript. La propiedad basada en el valor todavía requiere una decodificación de valor exitosa; se rechazan las asignaciones inválidas o incompletas. La eliminación de retroceso compacta las líneas en blanco del documento fuera de los valores multilínea, preservando las líneas en blanco dentro de esos valores.
+
+Elimine la línea `model_catalog_json` **con** el enrutamiento, no por sí solo. Un `model_catalog_json` que nombra un archivo que ya no existe hace que Codex no cargue su configuración, que se parece al mismo bloqueo por una razón diferente.
+
+<a id="accounts-that-would-not-add-or-display"></a>
+
+## Cuentas que no agregarían ni mostrarían
+
+Las fallas al agregar cuentas al grupo, o las cuentas agregadas que no aparecen, son un asunto separado del bloqueo anterior, incluso cuando ocurren en la misma sesión. El grupo de cuentas es servido por la administración del proxy API, por lo que tanto el flujo `ocx account login openai` como la lista del panel de control necesitan un proxy en ejecución antes de que cualquier otra cosa pueda funcionar. El inicio de sesión del navegador también vuelve a `http://localhost:1455/auth/callback`, una dirección fija que no puede moverse a otro puerto. Si algo más contiene el puerto 1455, o no se puede iniciar un navegador, utilice el flujo de dispositivos en su lugar:
+
+```bash
+ocx account login openai --device
+```
+
+Consulte [Codex Integración](/es/guides/codex-integration/) para conocer qué escribe la inyección y cómo se elige el enrutamiento.
+
+<a id="oauth-refresh-capacity-reached"></a>
+
+## Capacidad de actualización OAuth alcanzada
+
+Si una solicitud Responses reporta `OAuth token refresh capacity reached`, espere al menos un segundo antes de volver a intentarlo. El proxy limita el trabajo de actualización pendiente OAuth a 256 consumidores por proceso, incluidas las solicitudes que esperan la misma actualización. Una solicitud desconectada mantiene su reserva de actualización hasta que se resuelve el trabajo; las solicitudes que usan credenciales nuevas en caché aún pueden continuar.
+
+Antes de que comience una respuesta, este rechazo temporal devuelve HTTP 503 con `Retry-After: 1`. Un flujo que ya ha comenzado en su lugar termina con un error del servidor. El rechazo de capacidad no marca la cuenta como necesaria de reautenticación, por lo que el inicio de sesión de nuevo no es necesario para este error. Una actualización que nunca se asienta puede seguir ocupando capacidad; el límite no impone un plazo de actualización.
diff --git a/docs-site/src/content/docs/es/troubleshooting/disk-usage-temp-files.md b/docs-site/src/content/docs/es/troubleshooting/disk-usage-temp-files.md
new file mode 100644
index 00000000000..511e0002133
--- /dev/null
+++ b/docs-site/src/content/docs/es/troubleshooting/disk-usage-temp-files.md
@@ -0,0 +1,92 @@
+---
+title: "Uso del disco por archivos temporales"
+description: "Qué son los archivos responses-state.json.ocx.*.tmp, por qué podrían acumularse y cómo recuperarlos."
+---
+
+Algunos usuarios encontraron muchos gigabytes de archivos nombrados como `responses-state.json.ocx.<pid>.<seq>.tmp` en su hogar opencodex (`~/.opencodex` por defecto), creciendo después de cada reinicio.
+
+<a id="what-these-files-are"></a>
+
+## Qué son estos archivos
+
+opencodex mantiene una caché de continuación para que las cadenas `previous_response_id` sobrevivan a un reinicio proxy. Escribe esa instantánea atómicamente: el contenido va primero a un archivo temporal y luego reemplaza el archivo real en un solo paso. Eso es lo que impide que una caída a mitad de la escritura deje una instantánea a mitad de la escritura.
+
+El archivo temporal se elimina normalmente en cuanto termina el reemplazo. Si el proceso termina entre ambos pasos, ese archivo permanece en el disco.
+
+Cada archivo puede ser de hasta 24 MB porque la instantánea se reescribe entera, no anexada. Por lo tanto, unos pocos cientos de archivos abandonados se suman rápidamente.
+
+**Son caché, no un estado duradero.** Eliminarlos no cuesta nada, excepto que las cadenas de conversación en vuelo pueden volver a enviar el contexto una vez. No hay configuración, credenciales o historial vivo en estos archivos.
+
+<a id="why-they-could-accumulate"></a>
+
+## Por qué se pueden acumular
+
+Una limpieza ya existía, pero se ejecutó en un solo momento: cuando un proxy cargó la caché de continuación por primera vez, lo que sucede *antes* ese proceso escribe cualquier cosa. Dos consecuencias siguieron.
+
+Al reiniciarse tras un fallo, el proxy ejecutaba la limpieza demasiado pronto para detectar el archivo temporal de su predecesor: hay un período de gracia de 15 minutos para no tocar archivos que aún se están escribiendo. Después no volvía a comprobarlos durante el resto de su ejecución. Así, cada reinicio podía dejar otro archivo.
+
+Peor aún, la limpieza omitió cualquier archivo cuyo ID de proceso de posesión todavía estaba vivo. Después de un reinicio, el sistema operativo vuelve a emitir rutinariamente los mismos ID de proceso, por lo que un archivo antiguo podría confundirse permanentemente con uno que pertenece a un proceso en ejecución. Es por eso que el crecimiento rastreó reinicios.
+
+<a id="what-opencodex-does-now"></a>
+
+## Lo que opencodex hace ahora
+
+La limpieza se repite en el temporizador de fondo normal del proxy en lugar de ejecutarse una vez en el inicio, por lo que un proxy en ejecución reclama archivos abandonados por sí solo. También ignora la verificación de ID de proceso para los archivos más antiguos que el arranque actual, ya que ningún proceso en ejecución puede poseerlos.
+
+Las reglas de seguridad no cambian: un archivo menor de 15 minutos nunca se elimina, y el proxy nunca elimina un archivo que está escribiendo.
+
+<a id="how-often-the-snapshot-is-written"></a>
+
+## Con qué frecuencia se escribe la instantánea
+
+Las escrituras se agrupan tras un período sin cambios. La espera se calcula a partir del tamaño de la **última instantánea realmente escrita**: con un archivo pequeño, la siguiente escritura se programa unos dos segundos después del cambio; cerca del límite de 24 MB, la espera aumenta hasta un máximo de treinta segundos. Si la caché acaba de crecer, todavía usa una vez la espera corta: el intervalo más largo se aplica desde la escritura siguiente. Solo se omite un guardado cuando este proceso ya escribió los mismos bytes en el mismo archivo, el contenido de disco sigue coincidiendo y, fuera de Windows, los permisos siguen siendo exclusivos del propietario. Un proceso nuevo reescribe una vez incluso una instantánea idéntica. Si otro proceso cambia el contenido o los permisos, se vuelve a escribir mediante la ruta que asegura los permisos.
+
+Cada cadencia de fondo ordinaria realiza como máximo una reescritura atómica completa. Si la memoria caché de continuación cambia mientras esa escritura está en progreso, opencodex programa un seguimiento de la cadencia retardada normal en lugar de volver a escribir la instantánea completa de inmediato. El apagado elegante mantiene su comportamiento de reintento limitado después de que las solicitudes en vuelo se hayan agotado para que la instantánea final pueda ponerse al día antes de que salga el proceso.
+
+En conjunto, estas reglas mantienen aproximadamente constante la frecuencia de escritura al crecer la caché, en lugar de volver a serializar y reemplazar todo el archivo cada dos segundos.
+
+Un apagado elegante se descarga inmediatamente en lugar de esperar el temporizador, por lo que la espera más larga amplía principalmente la ventana en la que una muerte dura pierde las entradas de continuación más recientes, que son caché, como se mencionó anteriormente. Esa descarga sigue siendo una escritura de disco y puede fallar como cualquier otra, por lo que un apagado en un volumen completo o de solo lectura puede perder las mismas entradas.
+
+<a id="reclaiming-files-that-already-accumulated"></a>
+
+## Recuperar archivos que ya se han acumulado
+
+Si el proxy se ejecuta, esto sucede automáticamente en uno o dos minutos.
+
+Si el proxy **no se inicia**, que es cuando la acumulación puede crecer más rápido, comprueba y recupera el espacio desde la línea de comandos:
+
+```bash
+ocx doctor
+```
+
+La sección "Response-state temp files" informa cuántos archivos son recuperables y cuánto espacio ocupan. Solo informa; no cambia nada.
+
+Para eliminarlos realmente:
+
+```bash
+ocx doctor --reclaim-response-temps
+```
+
+Ambos comandos funcionan sin un proxy en ejecución. Los archivos actualmente bloqueados por otro proceso se informan en lugar de forzarse. Se vuelven a intentar en la siguiente recuperación: automáticamente mientras se ejecuta el proxy, de lo contrario, la próxima vez que ejecute este comando.
+
+Si un backlog muy grande excede una pasada, el comando dice cuántos archivos quedan para que pueda ejecutarlo de nuevo.
+
+Esta limpieza solo cubre los archivos temporales de las instantáneas del estado de respuestas. Los archivos temporales de otros componentes, aunque tengan nombres similares, no se modifican.
+
+<a id="spill-files-responses-state-spill"></a>
+
+## Archivo de derrames (`responses-state-spill/`)
+
+Un directorio hermano, `~/.opencodex/responses-state-spill/`, mantiene continuaciones de conversación derramadas. Cuando la memoria caché de continuación en memoria supera su presupuesto residente, opencodex mueve las cargas útiles más antiguas a estos archivos y mantiene solo un pequeño stub en `responses-state.json`. Esto es lo que mantiene la instantánea pequeña sin dejar caer largas cadenas `previous_response_id`.
+
+El almacén está limitado, por lo que este directorio no puede crecer sin límite mientras se ejecuta el proxy:
+
+- como máximo **1 GiB** de carga útil derramada,
+- como máximo **1000** respuestas almacenadas,
+- Cada entrada expira **24 horas** después de que se almacenó.
+
+Cuando se golpea un límite, las entradas más antiguas son desalojadas y sus archivos de derrame se eliminan con ellas.
+
+**Reiniciar conserva cada archivo de derrame que la instantánea todavía hace referencia.** Un reinicio recarga los stubs y vuelve a poseer los archivos detrás de ellos, por lo que no se pierde nada al reiniciar. Un archivo se convierte en basura solo cuando ya no se hace referencia (desplome de las sobras y limpiezas fallidas) y opencodex las recupera después de un período de gracia de 15 minutos.
+
+**No borre los archivos de derrame manualmente.** Los archivos a los que todavía se hace referencia son parte de una cadena de continuación en vivo, y la recuperación ya maneja los no referenciados. `ocx doctor` reporta la división sin tocar nada: una sección de "Response-state spill files" muestra el total de archivos y bytes en el disco, cuánto todavía es propiedad de la tienda o la instantánea persistente, y cuánto se asienta como candidatos huérfanos recuperables. Las mismas cuentas están en la gestión API en `/api/system/memory` bajo `responseSpill`.
diff --git a/docs-site/src/content/docs/es/troubleshooting/spend-ledger-synced-folder.md b/docs-site/src/content/docs/es/troubleshooting/spend-ledger-synced-folder.md
new file mode 100644
index 00000000000..39146d2c496
--- /dev/null
+++ b/docs-site/src/content/docs/es/troubleshooting/spend-ledger-synced-folder.md
@@ -0,0 +1,50 @@
+---
+title: "Registro de gastos rechazado en una carpeta sincronizada"
+description: "Por qué puede rechazarse el registro de gastos dentro de iCloud Drive u otra carpeta sincronizada y cómo recuperar un almacenamiento seguro."
+---
+
+Los rechazos de almacenamiento del registro de gastos devuelven HTTP 503 con el tipo `server_error` y el código `spend_ledger_storage_unavailable`. Es un problema de almacenamiento local: no afecta al estado de salud del proveedor ni de la cuenta. Los registros de solicitudes lo clasifican como `local-refusal`. Si la respuesta ya está en streaming, su evento de error final lleva el mismo código. Otras solicitudes de la misma sesión pueden funcionar si la condición del archivo es temporal.
+
+Las versiones anteriores devolvían HTTP 502 con el prefijo engañoso "Provider unreachable". Las versiones actuales identifican el archivo y la comprobación que impidió abrirlo, por ejemplo:
+
+```text
+Spend-ledger storage could not be opened safely (journal: extra-hard-link).
+```
+
+<a id="what-the-check-is"></a>
+
+## Qué se comprueba
+
+opencodex guarda un registro de gastos en su directorio de estado (`~/.opencodex` de forma predeterminada, o `OPENCODEX_HOME`): el diario `spend-ledger.jsonl` y el archivo de sal `spend-ledger.salt`. Antes de escribir, comprueba que cada archivo sea regular, no sea un enlace simbólico y tenga exactamente una entrada de directorio. Fuera de Windows también comprueba que pertenezca al usuario; en Windows no se realiza esa comparación de propietario. Un segundo enlace duro permitiría leer o modificar los mismos bytes desde otro nombre del volumen. Ante cualquier enlace inesperado, opencodex rechaza la escritura. La comprobación es estricta de forma deliberada.
+
+| Condición en el mensaje | Descripción |
+| --- | --- |
+| `extra-hard-link` | Otra entrada de directorio apunta al mismo archivo. |
+| `symbolic-link` | El archivo del registro de gastos es un enlace simbólico. |
+| `not-regular-file` | La ruta del registro de gastos contiene algo que no es un archivo regular. |
+| `foreign-owner` | El archivo pertenece a un usuario diferente; se comprueba fuera de Windows. |
+| `invalid-salt` | El archivo de sal existe pero su contenido no es una sal válida. |
+
+El tipo de archivo que indica el mensaje es `journal`, `journal-compaction` (el archivo temporal que se escribe al compactar el diario) o `salt`.
+
+<a id="why-a-synced-folder-triggers-it"></a>
+
+## ¿Por qué una carpeta sincronizada lo desencadena?
+
+Los servicios de sincronización de macOS, incluido iCloud Drive con la opción de sincronizar Escritorio y Documentos y los clientes de File Provider como OneDrive, Dropbox y Google Drive, pueden crear brevemente un segundo enlace mientras preparan o suben un cambio. Si el directorio de estado está dentro de una carpeta sincronizada, el diario puede tener dos enlaces durante un instante tras una escritura normal. Una solicitud que coincida con ese instante se rechaza; la siguiente puede funcionar. Cuando termina la sincronización, el archivo vuelve a tener un solo enlace, por lo que una inspección posterior puede no detectar ningún problema.
+
+Al iniciarse, opencodex advierte si el directorio de estado se resuelve dentro de iCloud Drive (`~/Library/Mobile Documents`), de una carpeta File Provider (`~/Library/CloudStorage`), de Escritorio o Documentos cuando parece estar activa su sincronización con iCloud, o de Escritorio o Documentos cuando parece usarse Google Drive para escritorio. Para detectar este último caso busca `~/Library/CloudStorage/GoogleDrive-*` o `~/Library/Application Support/Google/DriveFS`. No consulta qué carpetas se han seleccionado en Google Drive: su mera presencia puede generar el aviso aunque Documentos no esté seleccionado. El aviso es orientativo. La detección se basa en la estructura de carpetas y puede tanto advertir sin que exista el problema como no detectarlo cuando sí existe.
+
+<a id="fix"></a>
+
+## Solución
+
+Mantén el directorio de estado fuera de las carpetas sincronizadas. El directorio predeterminado `~/.opencodex` no está sincronizado.
+
+1. Detén opencodex.
+2. Mueve o copia el directorio de estado a una ubicación sin sincronización, por ejemplo `~/.opencodex-trial`.
+3. Establece `OPENCODEX_HOME` en esa ubicación, o elimina esa variable para usar la predeterminada, y vuelve a iniciar opencodex.
+
+No borres el diario, no relajes sus permisos ni elimines la comprobación para ocultar el error. El diario contiene los gastos registrados; la comprobación impide escribir a través de un enlace inesperado.
+
+Si el mensaje indica una condición distinta de `extra-hard-link`, o el directorio de estado no está en una carpeta sincronizada, abre una issue con el mensaje completo de rechazo. El mensaje no contiene rutas, cuentas ni contenido de las solicitudes.
diff --git a/docs-site/src/content/docs/es/troubleshooting/update-failed.md b/docs-site/src/content/docs/es/troubleshooting/update-failed.md
new file mode 100644
index 00000000000..80ee6d44daf
--- /dev/null
+++ b/docs-site/src/content/docs/es/troubleshooting/update-failed.md
@@ -0,0 +1,162 @@
+---
+title: "Fallo de actualización en Windows"
+description: "En qué estado se encuentra una instalación de OpenCodex después de que la actualización ocx falle durante el paso de instalación de npm, cómo finalizar la actualización de forma segura y qué carpetas sobrantes puede eliminar."
+---
+
+Esta página es para una actualización del panel de control o `ocx update` que se detiene parcialmente, con mayor frecuencia en Windows, con un resultado como este (informado como el problema [#5624](https://github.com/lidge-jun/opencodex/issues/5624)):
+
+```text
+update command failed (1)
+exit 1 · code: ENOTDIR · syscall: mkdir
+```
+
+y, después, una carpeta junto al paquete que no se puede eliminar porque `bunx.exe` está en uso (`EPERM`).
+
+<a id="what-state-you-are-in"></a>
+
+## En qué estado estás
+
+El actualizador detiene el proxy, instala y verifica la nueva versión en una carpeta de preparación separada y solo entonces la sustituye. Si falla la instalación, no hay sustitución: la versión anterior sigue instalada y ejecutable. Antes de salir, el actualizador reinicia el servicio o proxy anterior cuando las comprobaciones de propiedad y del directorio del servicio autorizan la recuperación.
+
+Si la comprobación inicial del directorio del servicio no es concluyente, por ejemplo porque falta Bun o falla la consulta del servicio, el actualizador puede sustituir un paquete inactivo sin detener ni reiniciar el proxy. Una actualización correcta de solo paquete indica que hace falta reiniciar manualmente y explica que no pudo verificarse la propiedad del servicio. Revisa `ocx service status` y la instalación registrada antes de reiniciar. Los cambios de autoridad, una propiedad persistente del entorno desconocida, la supervisión de Desktop, un proceso activo del paquete o un recibo de cierre sin resolver siguen bloqueando la sustitución del paquete; una comprobación inconclusa no autoriza a controlarlos.
+
+Compruebe esto con:
+
+```bash
+ocx --version
+ocx status
+```
+
+El trabajo del panel de control solo registra el estado de salida, ya que la propia salida del instalador puede contener rutas locales. La ejecución de `ocx update` en un terminal muestra el paso que falló y el siguiente paso a tomar.
+
+<a id="finish-the-update"></a>
+
+## Finalizar la actualización
+
+<a id="if-npm-staging-times-out"></a>
+
+### Si la instalación npm de preparación agota el plazo
+
+En Windows, la instalación npm de preparación de `ocx update` tiene un plazo de tres minutos.
+Si lo supera, informa `ETIMEDOUT` con ese presupuesto. El actualizador termina todo el árbol de
+procesos del instalador y confirma su salida antes de retirar el directorio de preparación y
+recuperar el servicio anterior. No sigue extrayendo archivos a un directorio eliminado después
+de que comience la recuperación.
+
+Si no puede confirmar la salida del instalador, la actualización falla y conserva ese directorio
+y su marcador de propiedad. Antes de eliminarlo, confirma que ningún proceso del instalador ni
+de OpenCodex se esté ejecutando desde él. Un directorio conservado no impide volver a actualizar.
+
+Si la instalación supera repetidamente el plazo, comprueba la conexión con el registro y
+reintenta `ocx update`. No hace falta ampliar el plazo para limpiar con seguridad una instalación
+que lo agotó. La garantía de salida del árbol completo se aplica a las actualizaciones npm de
+Windows. POSIX conserva su tratamiento anterior de plazos; allí sigue pendiente la limpieza
+completa del árbol tras agotar el plazo.
+
+<a id="retry-or-reinstall"></a>
+
+### Reintentar o reinstalar
+
+1. Cierre cualquier cosa que aún pueda ejecutar archivos OpenCodex: la aplicación Codex, los terminales que iniciaron `ocx` o `bunx` y la bandeja OpenCodex. Un `bun.exe` o `bunx.exe` en ejecución mantiene sus archivos bloqueados en Windows.
+2. Vuelva a ejecutar `ocx update` desde una terminal.
+3. Si falla de la misma manera, ejecute `ocx status` y deje que termine cualquier recuperación en progreso. Si el actualizador reinició el proxy, deténgalo a través de su propietario (`ocx stop`, su servicio o la aplicación de escritorio) y confirme que se ha detenido. Vuelva a instalar con el mismo administrador de paquetes que posee la instalación; para una instalación npm administrada por el servicio OpenCodex:
+
+   ```bash
+   ocx stop
+   npm install -g --allow-scripts=bun @bitkyc08/opencodex@latest
+   ocx service restart
+   ```
+
+   Reinicie a través del servicio propietario o la aplicación de escritorio después de que se complete la instalación; use `ocx start` cuando no se administre. Reemplace `latest` con `preview` si sigue el canal de vista previa.
+
+<a id="leftover-folders"></a>
+
+## Carpetas sobrantes
+
+Se sientan al lado del paquete en la carpeta global de npm, generalmente `%APPDATA%\npm\node_modules\@bitkyc08\` en Windows.
+
+| Carpeta | Creado por | Qué hacer |
+|---|---|---|
+| `.opencodex-<random>` | npm en sí, mientras que la sustitución del paquete durante un `npm install -g` directo | Elimínelo una vez que no se ejecute el proceso OpenCodex |
+| `.ocx-staging-<timestamp>` | la instalación del actualizador OpenCodex | Se informa de una etapa marcada de más de media hora, pero se deja en su lugar; elimínelo a mano una vez que no se ejecute ningún proceso OpenCodex. Una etapa sin un marcador `.ocx-update-owner.json` tiene un origen no verificado: una actualización interrumpida puede dejarla, pero también puede hacerlo cualquier otra cosa que elija el prefijo, así que confirme que pertenece a OpenCodex antes de eliminarlo |
+| `.ocx-backup-<timestamp>` | copia del actualizador de la versión anterior | Déjalo; se elimina automáticamente después de que la nueva versión comience saludable y se restaura si no lo hace. |
+
+Ninguna carpeta sobrante bloquea por su nombre la siguiente actualización: cada intento usa un directorio de preparación nuevo. Sin embargo, sus archivos siguen ocupando espacio y pueden hacer que una copia posterior falle con `ENOSPC`. El actualizador conserva esos directorios en los intentos posteriores e informa los que tengan más de media hora y un marcador de propiedad verificable. Elimina uno solo después de confirmar que pertenece a OpenCodex y que ningún proceso lo está usando.
+
+Si una carpeta no se elimina, un proceso sigue ejecutándose desde ella. Al cerrar la sesión o reiniciar Windows, se libera el bloqueo.
+
+<a id="if-every-update-and-sync-says-update-in-flight"></a>
+
+## Si todas las actualizaciones y sincronizaciones dicen update-in-flight
+
+Si `ocx update` y `ocx sync` siguen rechazando `update-in-flight` tras esperar, reiniciar servicio o equipo, puede quedar un marcador de una actualización interrumpida ([#8524](https://github.com/lidge-jun/opencodex/issues/8524)): `update-orchestrated.json` en `%USERPROFILE%\.opencodex` o `~/.opencodex`.
+
+Las versiones actuales registran al supervisor del instalador Windows y limpian el marcador tras el plazo de 15 minutos cuando supervisor y launcher ya no existen. Hasta 2.100.x no se registraba ese supervisor; tras cerrar consola, Ctrl+C, suspensión o corte de energía, ese marcador no se puede verificar y no se limpia solo. Ante esa causa, la terminal muestra ruta y comando para renombrarlo; dashboard, Desktop y Remote Link solo muestran el código. Ejecuta `ocx update` en una terminal para ver las instrucciones.
+
+Antes de renombrar, verifica que no haya una actualización activa:
+
+1. Ningún `ocx update` ni actualización de dashboard en otra ventana.
+2. Ninguna instalación global `npm`, `pnpm` o Bun. En Windows inspecciona `node.exe` ejecutando npm y `powershell.exe` con `npm-install-job.ps1` en sus argumentos.
+3. Solo entonces renombra, conservando una copia, y vuelve a actualizar:
+
+   ```bat
+   ren "%USERPROFILE%\.opencodex\update-orchestrated.json" update-orchestrated.json.stale
+   ```
+
+   ```bash
+   mv -n ~/.opencodex/update-orchestrated.json ~/.opencodex/update-orchestrated.json.stale
+   ```
+
+Usa la ruta exacta del error si configuraste `OPENCODEX_HOME`. Si tiene caracteres que el shell expande o interpreta, o caracteres no ASCII en Windows, el error solo identifica el archivo: renómbralo manualmente. Un marcador aún dentro del plazo o con su proceso registrado activo no muestra estas instrucciones; espera a que termine. No renombres un marcador de una actualización vigente.
+
+
+<a id="if-the-update-reports-an-unsupervised-proxy"></a>
+
+## Si la actualización informa de un proxy UNSUPERVISED
+
+Cuando el servicio en segundo plano no se puede actualizar después de una actualización, el actualizador primero pide a launchd (macOS) o al administrador de usuarios systemd (Linux) que reinicie el servicio que ya tiene. Si eso no trae de vuelta un proxy propiedad del servicio, el actualizador inicia el proxy directamente para que no se quede sin uno, imprime una advertencia de que el proxy se está ejecutando sin supervisión y sale con un estado distinto de cero. Ese proxy funciona, pero nada lo reinicia después de un bloqueo, y un inicio de servicio posterior puede competir con él por el puerto. Ejecute `ocx service repair` para devolverlo al servicio de fondo, luego marque `ocx status`.
+
+Las actualizaciones iniciadas desde el panel siguen el mismo orden. Si solo el inicio directo devuelve el proxy, el panel de control informa que la actualización falló con el mismo mensaje UNSUPERVISED aunque la nueva versión esté instalada y respondiendo; ejecute la misma reparación para borrarla.
+
+<a id="if-the-proxy-answers-503-after-a-manual-install"></a>
+
+## Si el proxy responde 503 después de una instalación manual
+
+La instalación sobre un proxy en ejecución hace que responda `503` con `package_tree_changed` hasta que se reinicie. Las versiones después de 2.64.0 pueden reiniciarse después de unos segundos una vez que el árbol de paquetes y su entorno de ejecución Bun se hayan completado. Una instalación posterior incompleta o fallida de Bun impide esa recuperación. `ocx restart` o `ocx service restart` pueden encontrar un proxy en ese estado, pero reiniciar aún requiere un entorno de ejecución completo y un árbol de paquetes. Con 2.64.0 y anteriores, el proxy permanece en ese estado, y `ocx restart` puede informar que no se está ejecutando ningún proxy mientras el antiguo aún mantiene el puerto; use `ocx service restart` o finalice el proceso cuya respuesta `pid` muestra la respuesta `/healthz` y luego ejecute `ocx start`.
+
+Si el instalador ha salido o ha fallado, inspeccione su error y ejecute `ocx status`. Deje que cualquier recuperación en curso termine, detenga cualquier proxy en ejecución a través de su propietario (`ocx stop`, su servicio o la aplicación de escritorio) y confirme que se ha detenido. Vuelva a instalar con el mismo administrador de paquetes, permitiendo que se complete la postinstalación de Bun, luego comience de nuevo a través del servicio propietario o la aplicación de escritorio (`ocx start` cuando no se administre).
+
+<a id="if-the-update-stops-at-the-npm-cache-check"></a>
+
+## Si la actualización se detiene en la comprobación de caché npm
+
+`ENOTDIR` en `mkdir` significa que npm intentó crear una carpeta donde un componente de ruta era un archivo, o un enlace cuyo destino ya no existe. Una causa confirmada ([#6288](https://github.com/lidge-jun/opencodex/issues/6288)) es una unión `%LOCALAPPDATA%\npm-cache` que apuntaba a otra unidad después de que la carpeta de destino se hubiera eliminado o la unidad se hubiera eliminado.
+
+El actualizador comprueba la carpeta de caché de npm antes de detener el proxy, y la instalación de estadificación npm utiliza la misma carpeta que `npm config get cache` informa. Si no se puede usar la carpeta de caché, la actualización se detiene con `cache_root_dangling_link` o `cache_root_not_directory` y deja el proxy en ejecución:
+
+- `cache_root_dangling_link`: la carpeta de caché es un enlace o unión cuyo objetivo falta. Vuelva a crear la carpeta de destino o elimine el enlace para que npm pueda crear una carpeta normal.
+- `cache_root_not_directory`: la carpeta de caché, o una carpeta encima de ella, es un archivo o se encuentra en una unidad que no está disponible. Mueva el archivo a un lado, o el punto npm en otra caché con `npm config set cache <folder>`.
+
+Luego ejecuta `ocx update` de nuevo. Si `ENOTDIR` persiste después de que pase la comprobación, abra un problema con la salida completa del terminal de `ocx update` y la salida de `npm config get prefix` y `npm config get cache`.
+
+<a id="desktop-app-update-stalls-or-fails-on-installing-update"></a>
+
+## La actualización de Desktop se detiene o falla en «Instalar actualización…»
+
+En la aplicación de escritorio OpenCodex, **Instalar actualización** descarga el instalador desde GitHub Releases antes de reemplazar la aplicación y reiniciarla. Una descarga o instalación fallida con una versión conocida muestra una sugerencia de descarga manual y un enlace a la página de lanzamiento de esa versión.
+
+Si `Installing update…` no avanza o agota el plazo, es posible que la red esté ralentizando o bloqueando las descargas de GitHub Releases. Abre el enlace a la versión exacta que muestra el error, o busca esa misma versión en la [página de versiones de OpenCodex](https://github.com/lidge-jun/opencodex/releases). Descarga manualmente el instalador correspondiente a tu sistema operativo y arquitectura. Las versiones preview tienen sus propias páginas; elige la versión que ofrece la aplicación.
+
+Antes de ejecutar el instalador, detenga el proxy a través de su propietario y confirme que se ha detenido:
+
+1. Salga de la aplicación de escritorio OpenCodex de su menú de bandeja para detener un proxy propiedad de la aplicación.
+2. Si un servicio posee el proxy, deténgalo a través de los controles del servicio (`ocx stop` para un servicio administrado OpenCodex). Para un proxy de terminal no administrado, deténgalo en ese terminal.
+3. En Windows, use este listado de procesos para ayudar a identificar cualquier entorno de ejecución restante:
+
+   ```powershell
+   Get-Process -Name ocx, opencodex-desktop, bun, bunx -ErrorAction SilentlyContinue
+   ```
+
+   El listado no establece qué aplicación posee un proceso. Identifique el entorno de ejecución OpenCodex y deténgalo a través de su aplicación o servicio propietario; un proceso `bun` puede pertenecer a otra aplicación. Espere a que la aplicación propietaria y el proxy salgan antes de instalar.
+
+Ejecute el instalador descargado y, a continuación, vuelva a abrir la aplicación de escritorio o reinicie el servicio propietario.
diff --git a/docs-site/src/content/docs/es/troubleshooting/windows-acl-timeouts.md b/docs-site/src/content/docs/es/troubleshooting/windows-acl-timeouts.md
new file mode 100644
index 00000000000..26d5e1d24fc
--- /dev/null
+++ b/docs-site/src/content/docs/es/troubleshooting/windows-acl-timeouts.md
@@ -0,0 +1,28 @@
+---
+title: Tiempos de espera al proteger permisos de archivos en Windows
+description: Cómo se recuperan las escrituras atómicas después de un bloqueo temporal de icacls.
+---
+
+En Windows, opencodex usa `icacls` para proteger los archivos temporales antes de
+escribir configuraciones, credenciales o datos de caché. Si no consigue aplicar
+los permisos requeridos, la escritura falla y el destino anterior se conserva.
+
+Un tiempo de espera temporal de `icacls` no exige reiniciar el proxy. Una escritura
+atómica posterior al mismo destino puede realizar un intento de recuperación. Si
+también agota el plazo, se rechazan las escrituras posteriores a ese destino hasta
+que hayan pasado cinco minutos desde el inicio del intento de recuperación. La
+siguiente escritura podrá volver a intentar aplicar los permisos. La recuperación
+ocurre cuando se solicita una escritura; no hay un temporizador que la ejecute.
+
+Si un proceso anterior de `icacls` sigue activo después de que venza el plazo de
+quien lo inició y aún no se ha recogido su terminación, se rechazan las escrituras
+al mismo destino, incluso después de los cinco minutos. Esos rechazos se devuelven
+pronto y conservan el siguiente intento de recuperación. Las escrituras simultáneas
+sin problemas pueden continuar, incluso mientras otra aplica permisos a su archivo
+temporal o espera para renombrarlo.
+
+Cada intento de recuperación debe completar la protección de permisos antes de
+publicar el archivo. Los errores de permiso denegado siguen siendo fallos y no
+activan un reintento automático. Limpiar una escritura fallida no consume el intento
+de recuperación de la siguiente. Cada destino mantiene su propio seguimiento de
+tiempos de espera.
diff --git a/docs-site/src/content/docs/es/troubleshooting/windows-memory.md b/docs-site/src/content/docs/es/troubleshooting/windows-memory.md
new file mode 100644
index 00000000000..721f45b3c64
--- /dev/null
+++ b/docs-site/src/content/docs/es/troubleshooting/windows-memory.md
@@ -0,0 +1,212 @@
+---
+title: "Crecimiento de memoria en Windows"
+description: "Por qué puede crecer la memoria de Bun en Windows, cómo inspeccionarla y qué mecanismos de mitigación ofrece opencodex."
+---
+
+Algunos usuarios de Windows observan que el proceso `bun` de opencodex alcanza muchos
+gigabytes de RSS durante sesiones largas de transmisión, como se informó en la incidencia
+[#314](https://github.com/lidge-jun/opencodex/issues/314). Esta página explica las causas
+conocidas, las mitigaciones disponibles y sus límites.
+
+<a id="root-cause-upstream-bun-runtime-issues"></a>
+
+## Causa raíz: problemas del entorno de ejecución de Bun
+
+Las versiones anteriores de OpenCodex incluían Bun **1.3.14**. La tabla siguiente recoge
+la investigación del 23 de julio de 2026: es evidencia histórica, no el estado actual de
+las incidencias de Bun. El paquete actual incluye Bun **1.4.4** y el control de
+compatibilidad reconoce Bun estable 1.4.0 o posterior como portador de la corrección de
+cancelación async-pull. Esto no demuestra que se hayan resuelto todas las causas del
+crecimiento de memoria en Windows.
+
+| Incidencia de Bun | Estado (comprobado el 2026-07-23) |
+|---|---|
+| [#28035](https://github.com/oven-sh/bun/issues/28035) — la contrapresión de recepción de `fetch()` no está vinculada al consumo de JavaScript | Corregida mediante [PR #29831](https://github.com/oven-sh/bun/pull/29831); **no se ha verificado qué versión incluye la corrección**; se supone que Bun 1.3.14, incluido en el paquete de entonces, no la contiene |
+| [#32111](https://github.com/oven-sh/bun/issues/32111) — fallo cuando un cliente cancela un flujo async-pull | La corrección [PR #32120](https://github.com/oven-sh/bun/pull/32120) se integró el 2026-06-21; no se presupone que esté incluida en Bun 1.3.14. Este fallo **no es específico de Windows**: también se reprodujo en macOS y Linux |
+| [PR #31654](https://github.com/oven-sh/bun/pull/31654) — fuga de handles de sockets en `node:net` | Todavía **abierto** en Bun |
+
+En entornos antiguos, Windows usaba la ruta conservadora basada en tee para evitar el
+fallo de cancelación async-pull. Un cliente lento podía dejar datos en memoria nativa
+que JavaScript no podía limitar. Con el entorno estable actual, Windows selecciona el
+relé acotado en `auto` cuando no hace falta reescribir la respuesta para el cliente.
+Un `legacy-tee` explícito conserva la ruta anterior. En macOS, `auto` sigue usando tee
+y el relé requiere activación explícita. Compruebe el entorno seleccionado y la decisión
+efectiva de transmisión antes de diagnosticar el crecimiento de memoria.
+
+<a id="what-opencodex-does-today"></a>
+
+## Lo que opencodex hace hoy
+
+La mitigación acotada y las herramientas de observación ayudan a diagnosticar la
+retención, pero no demuestran que todos los casos de crecimiento de memoria estén
+corregidos:
+
+- **Supervisión de memoria**: el proxy muestrea su propia memoria cada minuto y emite
+  una advertencia con frecuencia limitada cuando la memoria observada supera 4 GiB.
+  La memoria observada es el mayor valor entre RSS, `external` y `arrayBuffers`,
+  sin sumarlos. En Windows, los contadores del conjunto de trabajo y RSS pueden mostrar
+  menos memoria de la que realmente está comprometida para retención externa.
+- **`ocx doctor`**: la sección «Memoria / entorno de ejecución» muestra la versión de
+  Bun del proceso del *servicio*, RSS, los contadores external/ArrayBuffers, el contexto
+  del heap de JavaScript y la decisión del modo de transmisión. En entornos antiguos
+  de Bun 1.3.14, `heapUsed` y `jscHeap` por sí solos no permiten identificar una fuga.
+  Compare la memoria observada con `responseState` y con muestras repetidas antes de
+  atribuir una fuga a la aplicación.
+- **`GET /api/system/memory`**: ofrece los mismos datos mediante la API de gestión
+  autenticada para paneles o scripts. Junto a los contadores RSS/heap/external, devuelve
+  un bloque escalar `responseState` para el almacén de continuaciones
+  `previous_response_id` que el proxy mantiene en memoria. Incluye el número de
+  entradas, el total y el máximo de bytes serializados y la antigüedad de la entrada
+  más antigua.
+
+  Si `responseState.totalBytes` aumenta junto con la memoria observada, eso apunta
+  a la retención de conversaciones: cadenas largas `store:false` que se expanden de
+  nuevo en cada turno. Si `responseState` permanece estable mientras aumenta la
+  memoria observada, la causa probablemente está fuera de ese almacén. Los valores
+  son únicamente escalares, sin cuerpos de solicitud, tokens, rutas ni identificadores
+  de cuenta. La lectura no tiene efectos secundarios: nunca elimina entradas.
+
+  El estado de las escrituras de desbordamiento en disco se informa por separado
+  dentro de ese bloque. `spillWriteStatus` comienza como `initial`, pasa a
+  `degraded` tras una publicación fallida y vuelve a `healthy` después de la
+  siguiente publicación correcta. `spillWriteConsecutiveFailures`, la hora del
+  último fallo y la del último éxito muestran si los fallos se acumulan o si el mismo
+  proceso se está recuperando. El último fallo se representa mediante una clase fija
+  que protege la privacidad, como `EACCES`, `ENOSPC`, `ETIMEDOUT` o
+  `EACLRETRYEXHAUSTED`. Nunca se devuelven mensajes de error sin filtrar ni rutas
+  del sistema de archivos.
+
+  `spillLastWriteFailureOrigin` añade un origen fijo o null:
+  `retry_returned_timeout` significa que el segundo intento de escritura de
+  desbordamiento existente devolvió un tiempo de espera agotado;
+  `timeout_memo_refusal` significa que el auxiliar de ACL rechazó la operación
+  debido al estado de tiempo de espera que tenía memorizado. Otros fallos usan null.
+  Los contadores acumulativos `spillAclRetryReturnedTimeouts` y
+  `spillAclTimeoutMemoRefusals` cuentan publicaciones que terminaron en fallo,
+  no comandos ACL individuales ni primeros intentos que fallaron transitoriamente.
+
+  Cuando una nueva continuación no cabe dentro del límite de desbordamiento de
+  1 GiB, el proxy elimina primero las continuaciones almacenadas más antiguas para
+  liberar espacio, siempre que eso permita alojarla. Si aun así no cabe, la rechaza.
+  El contador acumulativo `spillHeadroomEvictions` cuenta las continuaciones
+  eliminadas para liberar espacio; `spillCapacityRefusals` cuenta las rechazadas
+  porque no se pudo hacer espacio dentro del límite. Cada rechazo también es una
+  publicación fallida de clase `ECAPACITY`. Si `spillCapacityRefusals` aumenta
+  mientras la memoria se mantiene en valores normales, el conjunto de continuaciones
+  persistentes está lleno de espacio que el proxy no puede recuperar, como
+  publicaciones en curso o archivos que quedaron tras una eliminación fallida.
+
+  Un éxito reinicia la racha de fallos, pero conserva los campos del último fallo
+  y los contadores acumulativos. Un fallo posterior no relacionado establece el
+  último origen en null. Estos valores pertenecen a cada proceso: compare
+  instantáneas del mismo proceso. Ninguno de los orígenes identifica un comando
+  del sistema operativo. El presupuesto de tiempo del intento puede agotarse antes
+  de iniciar un comando, y una inspección opcional de cumplimiento puede ejecutarse
+  antes del rechazo basado en el estado memorizado. Que una operación tenga éxito
+  en otro proceso no demuestra que se haya recuperado el estado memorizado del
+  proceso en ejecución. Estas observaciones no añaden reintentos, no borran estados
+  memorizados, no debilitan las ACL requeridas ni reinician automáticamente el servicio.
+
+  Estos diagnósticos permanecen en el endpoint de gestión autenticado y están
+  deliberadamente ausentes de `/healthz`, que sigue siendo una señal de actividad.
+  La tarjeta **Observabilidad de la memoria** del panel muestra los campos de
+  memoria y tamaño de las continuaciones. Su acción **Drenar y reiniciar** requiere
+  confirmación: muestra el número de turnos activos, espera hasta 60 s a que terminen
+  y después cancela los que sigan activos. Reutiliza la respuesta de drenaje
+  HTTP 503 JSON `server_restarting` y `Retry-After: 5`.
+
+  El proxy en ejecución controla la autorización de reinicio y coordina el drenaje
+  antes de salir. Si corresponde, el gestor de servicios instalado inicia el proceso
+  de reemplazo. La acción solo informa de éxito cuando un proceso diferente, cuya
+  identidad se ha verificado, responde correctamente en el mismo puerto, sin
+  desmontar la inyección de Codex. Este reciclaje es más largo y proporciona más
+  información que el drenaje breve de `POST /api/stop`.
+
+  Para obtener una instantánea completa de la respuesta autenticada mediante un
+  script, ejecute `ocx observe memory --json`. La CLI devuelve los mismos campos
+  de estado de las respuestas.
+- **Una ruta de transmisión alternativa con control de compatibilidad**: un relé
+  con un solo lector limita el almacenamiento en búfer. En Windows, `auto`
+  selecciona esta ruta cuando el entorno compatible y la forma de la respuesta lo
+  permiten; `legacy-tee` conserva explícitamente la ruta tee. En macOS, `auto`
+  mantiene tee y `eager-relay` requiere activación explícita. Compruebe la decisión
+  efectiva del entorno de ejecución seleccionado.
+
+Las lecturas de metadatos del catálogo usan el último catálogo incluido que se confirmó
+para el entorno de ejecución seleccionado. Las selecciones nuevas o modificadas se
+actualizan mediante sondeos asíncronos de versión y modelos, de modo que esos sondeos
+no bloquean el bucle de eventos del proxy. Las actualizaciones compartidas tienen un
+plazo de 45 segundos. Si falla una actualización iniciada por una solicitud, se
+conservan las filas coincidentes y se espera 60 segundos antes de reintentar.
+La cancelación de una solicitud libera la contabilidad del traductor, incluso cuando
+no se ha leído el cuerpo de la respuesta. Estas mejoras de actividad no demuestran
+que se haya resuelto la retención de flujos nativos en Windows
+([#6671](https://github.com/lidge-jun/opencodex/issues/6671)).
+
+La mejora real de RSS con estos cambios **sigue pendiente de verificación por parte de
+usuarios de Windows**. No afirmamos que la fuga esté corregida.
+
+El reinicio automático al superar un umbral **no está implementado**, por decisión
+del proyecto. Si el proceso falla, los gestores de servicios (Task Scheduler/WinSW,
+launchd o systemd) ya lo reinician.
+
+<a id="your-options"></a>
+
+## Sus opciones
+
+1. **Compruebe el entorno y la ruta de transmisión efectivos.** El paquete actual
+   incluye Bun 1.4.4 y el control de compatibilidad acepta versiones estables desde
+   1.4.0. En Windows, `auto` ya puede seleccionar el relé acotado cuando corresponde;
+   no es necesario esperar otra actualización para habilitarlo. Una selección
+   explícita de `legacy-tee` conserva tee. Esto no demuestra que estén resueltas
+   todas las causas del crecimiento de memoria.
+
+2. **Ejecute un entorno de ejecución Bun en el que confíe con `OPENCODEX_BUN_PATH`.**
+   Configure la variable antes de iniciar `ocx` desde ese shell y, después,
+   ejecute `ocx service repair` para guardar el entorno seleccionado en la definición
+   del servicio. Un archivo `.env` del proyecto que se cargue después no modifica
+   esa selección. Cambiar la variable de entorno por sí solo tampoco actualiza un
+   servicio que ya está instalado.
+
+3. **Seleccione el relé acotado con `streamMode: "eager-relay"`.** Puede editar
+   `config.json` para añadir `"streamMode": "eager-relay"` o enviar
+   `PUT /api/settings` con `{"streamMode":"eager-relay"}`. El cambio por API se
+   aplica a turnos nuevos sin reiniciar. El aviso de fallo de Bun 1.3.14 es
+   histórico: esa versión usaba la forma de transmisión afectada por #32111 y
+   podía fallar en cualquier sistema operativo, interrumpiendo las solicitudes
+   activas aunque el servicio se reiniciara. `"legacy-tee"` fuerza la ruta tee
+   anterior. En Windows, `"auto"` usa el control de compatibilidad del entorno
+   y las condiciones de la respuesta; en macOS, `"auto"` conserva tee y
+   `"eager-relay"` es la activación explícita.
+
+Si prueba alguna de estas opciones con una carga real en Windows, comparta las
+secciones de memoria de `ocx doctor` de antes y después en
+[#314](https://github.com/lidge-jun/opencodex/issues/314). Esa es la verificación
+que esta mitigación todavía necesita.
+
+<a id="windows-selected-runtime-write-refusal"></a>
+
+## Rechazo de escritura del entorno seleccionado en Windows
+
+La instalación y reparación del servicio de Windows, así como la instalación y
+actualización del shim de Codex, comprueban si el ejecutable seleccionado puede crear
+y eliminar un directorio dentro de la raíz de configuración de OpenCodex. Es una
+comprobación de la política de escritura, no una corrección del problema de memoria.
+Si falla, la operación se rechaza antes de detener el servicio, descargar archivos,
+preparar la instalación o escribir tokens o lanzadores.
+
+La reparación automática del shim se pospone y muestra instrucciones, mientras el
+inicio continúa. Los shims que funcionan correctamente o están desactivados no realizan
+la comprobación. No se busca otro entorno de ejecución. En una primera instalación
+con el Programador de tareas, la tarea se registra y se asume la propiedad de la raíz
+de configuración antes de la comprobación. Si se rechaza la operación, ese registro
+nuevo se revierte y la raíz de configuración queda bajo la propiedad adquirida para
+un nuevo intento.
+
+> El entorno de ejecución Bun seleccionado no pudo crear y eliminar un directorio
+> dentro del directorio de configuración de OpenCodex. La política de aplicaciones
+> de Windows puede impedir la escritura desde la ubicación de este ejecutable.
+> Configure OPENCODEX_BUN_PATH con un ejecutable Bun de confianza permitido por su
+> política antes de iniciar ocx, o reinstale opencodex con
+> npm install -g @bitkyc08/opencodex y vuelva a intentarlo. No se seleccionó otro
+> entorno de ejecución.
diff --git a/docs-site/src/content/docs/fr/getting-started/for-agents.md b/docs-site/src/content/docs/fr/getting-started/for-agents.md
index 671d1d01e02..682a642a2f7 100644
--- a/docs-site/src/content/docs/fr/getting-started/for-agents.md
+++ b/docs-site/src/content/docs/fr/getting-started/for-agents.md
@@ -17,7 +17,11 @@ npm install -g --allow-scripts=bun @bitkyc08/opencodex
 ocx --version
 ```
 
-Choisissez une façon d'exécuter le proxy :
+Exécutez `ocx init` dans un terminal interactif avant de démarrer le proxy pour utiliser le port choisi :
+
+```bash
+ocx init
+```
 
 ```bash
 # Foreground: blocks this terminal until stopped.
@@ -27,13 +31,6 @@ ocx start
 ocx service
 ```
 
-Exécutez `ocx init` dans un terminal interactif. Si `ocx start` occupe le premier plan, utilisez un
-deuxième terminal :
-
-```bash
-ocx init
-```
-
 L’assistant écrit `$OPENCODEX_HOME/config.json` (généralement
 `~/.opencodex/config.json`). Il peut aussi injecter l’adresse du proxy dans le `config.toml` de Codex et
 installer le shim facultatif de démarrage automatique de Codex. `ocx init` ne démarre jamais le proxy.
@@ -82,10 +79,12 @@ en fait le fournisseur par défaut :
 
 ```bash
 ocx provider add anthropic-apikey \
-  --api-key "$ANTHROPIC_API_KEY" \
+  --api-key '${ANTHROPIC_API_KEY}' \
   --set-default
 ```
 
+Conservez les guillemets simples : ils transmettent la référence littéralement, sans placer le secret dans les arguments du processus ni enregistrer sa valeur dans la configuration. Fournissez `ANTHROPIC_API_KEY` au proxy avant son démarrage et aux commandes qui résolvent les identifiants, comme la synchronisation des modèles. Un export ultérieur dans un autre terminal ne modifie pas un proxy déjà lancé. Pour un service en arrière-plan, configurez son environnement de démarrage puis redémarrez-le ; l’installation du service ne conserve pas automatiquement les variables de fournisseur du terminal.
+
 `ocx provider add` écrit la configuration locale. Ajoutez `--sync` si un proxy est déjà actif et que vous
 souhaitez synchroniser immédiatement les modèles avec Codex ; sinon, exécutez `ocx sync` ultérieurement.
 Les fournisseurs personnalisés absents du registre exigent à la fois `--adapter` et `--base-url`.
@@ -104,17 +103,11 @@ le routage persistant et le comportement de basculement.
 
 ## Liaisons à distance et LAN
 
-La liaison de bouclage par défaut n’exige aucun identifiant du plan de données. Une liaison hors bouclage,
-telle que `0.0.0.0`, exige soit `OPENCODEX_API_AUTH_TOKEN`, soit au moins une entrée `apiKeys` configurée.
-L’installation du service exige spécifiquement `OPENCODEX_API_AUTH_TOKEN` et l’enregistre pour le processus
-du service. Définissez donc cette variable avant `ocx service install` :
+Les routes de modèle locales en bouclage n’exigent pas de token de données. Une liaison hors bouclage, telle que `0.0.0.0`, exige une clé client configurée dans `config.apiKeys` ou un token partagé provenant de `OPENCODEX_API_AUTH_TOKEN`, de `OCX_API_TOKEN_FILE` ou du fichier privé `service-api-token`. `ocx service install` peut créer ce fichier s’il est absent. Si vous fournissez un token par variable d’environnement, définissez-la avant `ocx start` ou `ocx service install` :
 
 ```bash
 export OPENCODEX_API_AUTH_TOKEN="your-secret-token"
 ocx service install
 ```
 
-Les requêtes de modèle `/v1/*` utilisent cet identifiant propre au plan de données. Les requêtes de contrôle
-`/api/*` exigent l’identifiant administrateur distinct décrit dans l’[API de gestion](/fr/reference/management-api/)
-et ne doivent jamais réutiliser un identifiant du plan de données. Consultez aussi les règles d’accès à
-distance dans [Configuration](/fr/reference/configuration/) avant d’exposer OpenCodex au-delà de la machine locale.
+Les requêtes de modèle utilisent les identifiants du plan de données. La gestion utilise un identifiant indépendant : `OPENCODEX_ADMIN_AUTH_TOKEN` ou le token administrateur généré dans un fichier protégé. Un token de données ne donne aucun accès de gestion. Le tableau de bord suit les règles de session et d’accès de l’[API de gestion](/fr/reference/management-api/#authentication-model). Ne donnez jamais le token administrateur à un client de modèle. Consultez l’[accès à distance](/fr/reference/configuration/server/#remote-access) avant d’exposer le proxy hors de la machine locale.
diff --git a/docs-site/src/content/docs/fr/getting-started/quickstart.md b/docs-site/src/content/docs/fr/getting-started/quickstart.md
index bf01104632d..b3bd6b72cef 100644
--- a/docs-site/src/content/docs/fr/getting-started/quickstart.md
+++ b/docs-site/src/content/docs/fr/getting-started/quickstart.md
@@ -34,11 +34,20 @@ annoncent une fenêtre de contexte utilisable de 372 000 jetons ; Cursor con
 
 ## 2. Démarrez le proxy
 
+Exécutez une seule de ces alternatives ; le proxy reste au premier plan :
+
 ```bash
 ocx start            # utilise le port 10100 par défaut
+```
+
+Autre possibilité : choisissez un autre port :
+
+```bash
 ocx start --port 8080
 ```
 
+Gardez ce terminal ouvert. Exécutez les commandes suivantes de statut et de tableau de bord dans un second terminal avec le même `OPENCODEX_HOME`.
+
 Au démarrage, opencodex :
 
 - écrit son PID à `~/.opencodex/ocx.pid` (et refuse de démarrer deux fois),
@@ -46,10 +55,7 @@ Au démarrage, opencodex :
   le catalogue de modèles de Codex**,
 - écoute sur `http://localhost:<port>/v1`.
 
-Si le port demandé est occupé, `ocx start` s’arrête et indique ce qui l’occupe : exécutez d’abord
-`ocx stop` si un processus opencodex y répond, ou démarrez sur un port libre avec
-`ocx start --port <port>`. La commande ne change jamais de port d’elle-même : auparavant, ce
-comportement laissait deux proxys en cours d’exécution et redirigeait Codex vers le plus récent.
+Une instance opencodex active avec le même `OPENCODEX_HOME` empêche un second démarrage, même sur un port libre. Arrêtez cette instance avec `ocx stop` ou choisissez un autre `OPENCODEX_HOME`. Une instance sœur sert les requêtes directes sur son port, mais ne modifie pas le routage partagé de Codex, Grok ou Claude. Si un processus sans rapport occupe le port, `ocx start` le signale ; choisissez un port libre avec `ocx start --port <port>`. La commande ne change jamais de port automatiquement.
 
 Vérifiez-le :
 
diff --git a/docs-site/src/content/docs/fr/guides/codex-app-models.md b/docs-site/src/content/docs/fr/guides/codex-app-models.md
index e6a653f337d..c30d893908a 100644
--- a/docs-site/src/content/docs/fr/guides/codex-app-models.md
+++ b/docs-site/src/content/docs/fr/guides/codex-app-models.md
@@ -222,8 +222,7 @@ Codex trie les entrées visibles du sélecteur par `priority` croissante et prop
 remplacements de modèle pour `spawn_agent`. La page **Sous-agents** du tableau de bord permet de choisir et
 d'enregistrer jusqu'à cinq identifiants natifs non qualifiés ou identifiants routés `provider/model`.
 `subagentModels`, lorsqu'il est configuré manuellement, accepte aussi les identifiants qualifiés par compte
-`<selector>/<native-openai-model>`, mais le tableau de bord ne propose pas ces identifiants exacts ; enregistrer
-la page remplace la liste par les choix visibles dans le tableau de bord. opencodex attribue des priorités de
+`<selector>/<native-openai-model>`. Le tableau de bord conserve ces identifiants exacts lors de l’enregistrement de la liste, même si les modèles ne sont plus disponibles dans le catalogue actuel. opencodex attribue des priorités de
 catalogue basses dans l'ordre choisi. Lorsque les lignes qualifiées par compte sont activées, les sélections
 natives non qualifiées s'étendent en groupes qualifiés par sélecteur. Les autres modèles restent accessibles
 par leur identifiant exact.
diff --git a/docs-site/src/content/docs/fr/guides/grok-build.md b/docs-site/src/content/docs/fr/guides/grok-build.md
index 1adeb25c599..eb8ae90a175 100644
--- a/docs-site/src/content/docs/fr/guides/grok-build.md
+++ b/docs-site/src/content/docs/fr/guides/grok-build.md
@@ -130,12 +130,11 @@ model = "anthropic/claude-opus-4-8"
 model_provider = "opencodex"
 ```
 
-Pour un proxy joignable sur le réseau, pointez `base_url` vers l’adresse que `grok` peut réellement
-joindre et utilisez votre jeton d’entrée :
+Configurez un frontal TLS avant de fournir le jeton et utilisez son URL HTTPS, ou passez par un tunnel local sur l’interface de bouclage. Grok enregistre la valeur littérale de `api_key` dans `~/.grok/config.toml` : limitez l’accès à ce fichier et excluez-le du contrôle de version et des sauvegardes partagées.
 
 ```toml
 [model_providers.opencodex]
-base_url = "http://192.168.1.10:10100/v1"   # the reachable host, not 127.0.0.1
+base_url = "https://proxy.example.com/v1"   # configured TLS frontend
 api_backend = "responses"
 api_key = "your-OPENCODEX_API_AUTH_TOKEN"
 
diff --git a/docs-site/src/content/docs/fr/guides/minimax.md b/docs-site/src/content/docs/fr/guides/minimax.md
index db609619b8e..25810daf391 100644
--- a/docs-site/src/content/docs/fr/guides/minimax.md
+++ b/docs-site/src/content/docs/fr/guides/minimax.md
@@ -14,6 +14,11 @@ Installez MiniMax Code et connectez-vous d’abord en suivant les instructions d
 
 ```bash
 ocx start
+```
+
+Laissez le proxy fonctionner dans ce terminal. Dans un deuxième terminal, activez l’intégration et lancez MiniMax Code :
+
+```bash
 ocx integration client enable --client mcode
 ocx mcode
 ```
diff --git a/docs-site/src/content/docs/fr/guides/model-routing.md b/docs-site/src/content/docs/fr/guides/model-routing.md
index 273e2d19011..6a5ce01d681 100644
--- a/docs-site/src/content/docs/fr/guides/model-routing.md
+++ b/docs-site/src/content/docs/fr/guides/model-routing.md
@@ -60,8 +60,8 @@ rabattent jamais les unes sur les autres.
    | `claude-`, `claude-sonnet-`, `claude-opus-`, `claude-haiku-` | `anthropic` |
    | `llama-`, `mixtral-`, `gemma-` | `groq` |
 
-   Cette correspondance repose sur le nom et, contrairement aux recherches dans `defaultModel` et `models[]`,
-   ne filtre actuellement pas un fournisseur correspondant dont l'indicateur `disabled` vaut true.
+   Cette correspondance repose sur le nom et, comme les recherches dans `defaultModel` et `models[]`,
+   ignore un fournisseur correspondant dont l'indicateur `disabled` vaut true.
 
 7. **`models[]` d'un fournisseur** — si aucune règle de préfixe ne s'est appliquée et qu'un fournisseur actif
    répertorie l'identifiant dans son tableau `models[]`, ce fournisseur est utilisé. La règle 4 a déjà acheminé
diff --git a/docs-site/src/content/docs/fr/guides/opencode.md b/docs-site/src/content/docs/fr/guides/opencode.md
index a645fb882b4..6990b6880af 100644
--- a/docs-site/src/content/docs/fr/guides/opencode.md
+++ b/docs-site/src/content/docs/fr/guides/opencode.md
@@ -102,9 +102,11 @@ Exemple de bouclage :
 
 Exemple sans bouclage :
 
+Cet exemple se configure manuellement sur le client distant. Configurez d’abord un frontal TLS, puis utilisez son URL HTTPS ; OpenCodex ne termine pas TLS et ne découvre pas cette URL pour `ocx opencode`. Le HTTP en clair sur le réseau local expose l’identifiant pendant le transport. Vous pouvez aussi garder le proxy sur l’interface de bouclage et utiliser un tunnel SSH local. Voir [TLS pour le listener de données](/fr/guides/remote-hub/#giving-the-data-listener-tls).
+
 ```json
 "options": {
-  "baseURL": "http://192.168.1.10:10100/v1",
+  "baseURL": "https://proxy.example.com/v1",
   "headers": {
     "x-opencodex-api-key": "{env:OPENCODEX_OPENCODE_API_KEY}"
   }
diff --git a/docs-site/src/content/docs/fr/guides/pi.md b/docs-site/src/content/docs/fr/guides/pi.md
index 9a195dc2df4..80696ef3aba 100644
--- a/docs-site/src/content/docs/fr/guides/pi.md
+++ b/docs-site/src/content/docs/fr/guides/pi.md
@@ -3,10 +3,7 @@ title: Pi
 description: Utilisez n’importe quel modèle routé depuis Pi — ocx export produit un bloc de fournisseur personnalisé pour le fichier models.json de Pi, relié au proxy en cours d’exécution.
 ---
 
-Pi lit ses fournisseurs dans un fichier JSON global unique plutôt que dans des variables d’environnement ;
-opencodex ne lance donc pas Pi. À la place, `ocx export` sérialise le bloc du fournisseur `opencodex` —
-URL de base, liste des modèles et référence de variable d’environnement interpolée par Pi — que vous fusionnez ensuite dans votre
-propre configuration.
+Pi lit ses fournisseurs dans un fichier JSON global unique. opencodex ne lance pas Pi : `ocx export` sérialise le bloc du fournisseur `opencodex`, avec l’URL de base, les modèles et une valeur de clé locale non secrète, puis vous le fusionnez dans votre configuration.
 
 ## Démarrage rapide
 
@@ -14,11 +11,15 @@ Démarrez le proxy, puis imprimez la configuration :
 
 ```bash
 ocx start
+```
+
+Laissez ce processus en cours. Dans un second terminal, affichez la configuration :
+
+```bash
 ocx export --client pi
 ```
 
-La sortie commence par le JSON, puis affiche le chemin de destination, l’avertissement de fusion, la ligne
-d’exportation de la variable d’environnement et le nombre de modèles dotés de limites de contexte faisant autorité.
+La sortie commence par le JSON, puis affiche le chemin de destination, l’avertissement de fusion, une indication d’utilisation locale et le nombre de modèles dont les limites de contexte sont connues. Cet export prend uniquement en charge un proxy de bouclage sans authentification ; il ne configure pas l’accès distant.
 
 ```json
 {
@@ -26,7 +27,7 @@ d’exportation de la variable d’environnement et le nombre de modèles dotés
     "opencodex": {
       "baseUrl": "http://127.0.0.1:10100/v1",
       "api": "openai-completions",
-      "apiKey": "$OPENCODEX_API_KEY",
+      "apiKey": "opencodex-loopback",
       "compat": {
         "sendSessionAffinityHeaders": true,
         "supportsDeveloperRole": false
@@ -85,27 +86,7 @@ fournisseur ou modification de la visibilité du modèle, et fusionnez le nouvea
 
 ## La clé d'admission
 
-Deux clés différentes sont ici faciles à confondre, et seule la première apparaît dans ce fichier :
-
-| Clé | Qu'est-ce que c'est | Où il vit |
-| --- | --- | --- |
-| Clé d'admission proxy | Les propres informations d'identification de opencodex, générées dans l'onglet **API** du tableau de bord | référencé par `apiKey` comme `$OPENCODEX_API_KEY` ; la valeur reste dans votre environnement |
-| Clé du fournisseur | votre touche Anthropic / OpenAI / OpenRouter | La propre configuration de opencodex, selon [Fournisseurs](/fr/guides/providers/) |
-
-La configuration exportée ne contient que la référence, jamais le secret. Pi interpole une valeur simple de la forme `$NAME` ;
-la variable est :
-
-```bash
-export OPENCODEX_API_KEY=<your key>
-```
-
-Ce nom est propre à Pi. opencode utilise une autre variable
-(`OPENCODEX_OPENCODE_API_KEY`, sous la forme `{env:…}`) — voir le [guide opencode](/fr/guides/opencode/).
-
-**Un proxy lié à l’interface de bouclage n’a besoin d’aucune clé.** Par défaut, opencodex se lie à `127.0.0.1` et n’y exige
-aucune authentification ; la référence `$OPENCODEX_API_KEY` est donc inerte et la variable peut rester indéfinie.
-Cela n'a d'importance que lorsque `hostname` est défini au-delà du bouclage, ce qui est également le cas lorsque le proxy
-refuse de démarrer sans jeton — voir [Accès à distance](/fr/reference/configuration/server/#accès-à-distance).
+La valeur `apiKey` exportée est `opencodex-loopback`, un marqueur non secret. Aucune variable de clé n’est à exporter. L’exportateur accepte uniquement un proxy de bouclage sans authentification et refuse les proxys distants ou protégés par jeton. Les identifiants des fournisseurs restent dans la configuration d’opencodex, comme décrit dans [Fournisseurs](/fr/guides/providers/) ; ne placez jamais de clé du fournisseur dans ce bloc Pi. Pour un accès distant, utilisez une intégration qui prend en charge les identifiants d’accès au proxy. Modifier le marqueur n’active pas l’export Pi distant.
 
 ## Métadonnées du modèle
 
diff --git a/docs-site/src/content/docs/fr/guides/remote-hub.md b/docs-site/src/content/docs/fr/guides/remote-hub.md
index 1d3e22389ef..3d843042511 100644
--- a/docs-site/src/content/docs/fr/guides/remote-hub.md
+++ b/docs-site/src/content/docs/fr/guides/remote-hub.md
@@ -12,7 +12,13 @@ Un hub conserve les identifiants fournisseur, le catalogue et l’usage sur un h
 `standalone` réunit données et gestion. `hub` possède les secrets fournisseur et l’usage. `client` ne conserve que l’état de connexion et une clé de données dédiée.
 
 ```bash
-ocx connect https://hub-name.tailnet-name.ts.net --pairing-code-stdin
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the one-time code without echoing it or putting it in shell history.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+  --management-url https://hub-name.tailnet-name.ts.net \
+  --pairing-code-stdin
+unset pairing_code
 ocx connect status
 ocx sync
 ```
@@ -66,6 +72,8 @@ tailscale serve status
 
 `/healthz` ne prouve que la vie du processus. Validez aussi `/readyz`, `GET /v1/catalog` authentifié et une vraie réponse routée. Le port de gestion doit écouter uniquement sur `127.0.0.1`. Pour un proxy TLS privé, utilisez `tailscale cert hub-name.tailnet-name.ts.net` et ne fabriquez jamais d’en-têtes `Tailscale-User-*`; utilisez l’association à usage unique.
 
+<a id="giving-the-data-listener-tls"></a>
+
 ### Donner du TLS à l'écoute de données
 
 Le mappage Serve ci-dessus ne publie que l'entrée de **gestion**. Celle-ci ne sert jamais `/v1/*`, `/healthz` ni `/readyz` : à elle seule, elle ne donne donc à un client distant aucun plan de données utilisable. opencodex ne termine par ailleurs aucun TLS : l'écoute est en HTTP clair et le HTTPS vient toujours d'un frontal détenu par l'opérateur.
@@ -86,9 +94,13 @@ Serve n'accepte qu'un jeu limité de ports HTTPS; confirmez avec `tailscale serv
 Connectez-vous ensuite en énonçant les deux origines séparément. L'URL positionnelle est l'origine **de données** — c'est là que sont récupérés `/readyz` et `/v1/catalog` — et `--management-url` est l'origine du tableau de bord, utilisée pour l'association et l'émission de clé. Elles ne partagent pas nécessairement le même port :
 
 ```bash
-ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the management admin token without echoing it.
+read -r -s -p 'Admin token: ' admin_token; printf '\n'
+printf '%s\n' "$admin_token" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
   --management-url https://hub-name.tailnet-name.ts.net \
   --admin-token-stdin
+unset admin_token
 ```
 
 Quand `--management-url` est omis, il est repris de la réponse `/readyz`, qui rapporte `hub.managementPublicOrigin`. L'indiquer explicitement est plus clair lorsque les deux origines diffèrent.
@@ -102,10 +114,16 @@ Une fois Serve en place, rejouez les contrôles d'acceptation sur l'origine de d
 ## OAuth, rotation et déconnexion
 
 ```bash
-ocx config set oauthOpenBrowser false
-ocx connect rotate --pairing-code-stdin
-# uniquement en HTTPS :
-ocx connect rotate --admin-token-stdin
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: choose one authority source.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect rotate --pairing-code-stdin
+unset pairing_code
+
+# Alternatively, only over HTTPS, use the management admin token:
+read -r -s -p 'Admin token: ' admin_token; printf '\n'
+printf '%s\n' "$admin_token" | ocx connect rotate --admin-token-stdin
+unset admin_token
 ```
 
 Démarrez OAuth avec `POST /api/oauth/login`; si le rappel ne rejoint pas le hub, envoyez l’URL finale ou le code à `POST /api/oauth/login/code` sous `{provider,input}`. Ne placez jamais le code OAuth dans argv ou les journaux.
diff --git a/docs-site/src/content/docs/fr/guides/remote-workspace.md b/docs-site/src/content/docs/fr/guides/remote-workspace.md
index 707c61bfa13..5a4a61df237 100644
--- a/docs-site/src/content/docs/fr/guides/remote-workspace.md
+++ b/docs-site/src/content/docs/fr/guides/remote-workspace.md
@@ -35,9 +35,16 @@ Hub.
 L'ordinateur 1 détient toutes les connexions aux agents de programmation et toutes les sessions
 de modèle. Installez et connectez-y les agents voulus, puis démarrez OpenCodex comme Hub :
 
+Laissez le Hub fonctionner au premier plan dans ce terminal :
+
 ```bash
 ocx config set runtimeRole hub
 OCX_REMOTE_WORKSPACE_ENABLED=1 ocx start
+```
+
+Pendant que le Hub fonctionne, ouvrez un second terminal et lancez le tableau de bord :
+
+```bash
 ocx gui
 ```
 
@@ -69,20 +76,43 @@ ne configurez pas simultanément l'ancien bac à sable et un profil d'autorisati
 Le parcours manuel équivalent est :
 
 ```bash
+# Bash only: if using zsh, run bash first in this terminal.
 cd /path/to/project
-printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
-  --pairing-code-stdin --root "$PWD"
-ocx remote-workspace agent
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" || pairing_status=$?
+  unset pairing_code
+  if [ "$pairing_status" -eq 0 ]; then ocx remote-workspace agent; fi
+  unset pairing_status
+else
+  unset pairing_code
+fi
 ```
 
 Sous Windows PowerShell, utilisez la commande affichée dans le tableau de bord. Sa forme
 manuelle équivalente est :
 
 ```powershell
-$pairingCode = 'ONE-TIME-CODE'
-$pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
-  --pairing-code-stdin --root (Get-Location).Path
-if ($LASTEXITCODE -eq 0) { ocx remote-workspace agent }
+$pairingSecret = Read-Host 'Pairing code' -AsSecureString
+$pairingBuffer = [IntPtr]::Zero
+$pairingExitCode = 1
+try {
+  $pairingBuffer = [Runtime.InteropServices.Marshal]::SecureStringToBSTR($pairingSecret)
+  $pairingCode = [Runtime.InteropServices.Marshal]::PtrToStringBSTR($pairingBuffer)
+  $pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
+    --pairing-code-stdin --root (Get-Location).Path
+  $pairingExitCode = $LASTEXITCODE
+} finally {
+  if ($pairingBuffer -ne [IntPtr]::Zero) {
+    [Runtime.InteropServices.Marshal]::ZeroFreeBSTR($pairingBuffer)
+  }
+  $pairingSecret.Dispose()
+  Remove-Variable pairingCode, pairingSecret, pairingBuffer -ErrorAction SilentlyContinue
+}
+if ($pairingExitCode -eq 0) { ocx remote-workspace agent }
+Remove-Variable pairingExitCode
 ```
 
 L'exécutable OCX Bun actuel est ajouté automatiquement comme fichier unique en lecture seule
@@ -91,9 +121,17 @@ hors des chemins système, associez-la explicitement sans exposer le reste du r
 personnel :
 
 ```bash
-printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
-  --pairing-code-stdin --root "$PWD" \
-  --toolchain-root "$HOME/.nvm/versions/node/v24/bin"
+# Bash only: if using zsh, run bash first in this terminal.
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" \
+    --toolchain-root "$HOME/.nvm/versions/node/v24/bin" || pairing_status=$?
+  unset pairing_code pairing_status
+else
+  unset pairing_code
+fi
 ```
 
 Le code source de l'assistant natif est fourni pour examen. Le compiler n'active pas les
diff --git a/docs-site/src/content/docs/fr/guides/subagent-v1-default.md b/docs-site/src/content/docs/fr/guides/subagent-v1-default.md
index d93aa422837..c153742b1d9 100644
--- a/docs-site/src/content/docs/fr/guides/subagent-v1-default.md
+++ b/docs-site/src/content/docs/fr/guides/subagent-v1-default.md
@@ -41,8 +41,9 @@ En v2, le parent émet la tâche sous forme de `encrypted_content`, produit par
 le backend ChatGPT. La clé reste dans ce backend. OpenCodex ne l'a jamais eue :
 le proxy ne peut donc rien déchiffrer ni réécrire. La valeur est réellement du
 texte chiffré, et non du texte clair caché derrière un indicateur. La limite
-est structurelle, pas un défaut de configuration, et aucun réglage du proxy
-ne peut y remédier.
+est structurelle, pas un défaut de configuration : aucun réglage du proxy ne permet le déchiffrement local.
+
+Aucun réglage du proxy ne permet le déchiffrement local. L’option expérimentale `agentTaskRecovery` peut demander au backend ChatGPT de récupérer les tâches éligibles ; elle ne les déchiffre pas localement. Les règles d’autorisation, d’éligibilité et d’échec décrites plus haut restent applicables.
 
 Trois configurations restent possibles, ce qui éclaire la forme de l'échec :
 
diff --git a/docs-site/src/content/docs/fr/guides/video-bridge.md b/docs-site/src/content/docs/fr/guides/video-bridge.md
index d82df5e741f..2e9cca845ac 100644
--- a/docs-site/src/content/docs/fr/guides/video-bridge.md
+++ b/docs-site/src/content/docs/fr/guides/video-bridge.md
@@ -23,14 +23,12 @@ achèvement, puis télécharge le résultat.
 > ```json
 > {
 >   "providers": {
->     "xai": { "adapter": "openai-chat", "apiKey": "xai-…", "authMode": "key" }
+>     "xai": { "adapter": "openai-chat", "apiKey": "${XAI_API_KEY}", "authMode": "key" }
 >   }
 > }
 > ```
 >
-> Si vous avez configuré xAI avec `ocx login xai` (OAuth), le fournisseur reste en `authMode: "oauth"`
-> et le pont ne s'activera pas, sans produire d'erreur. Définissez `XAI_API_KEY` dans l'environnement
-> **ou** enregistrez directement la clé comme dans l'exemple ci-dessus.
+> Définissez `XAI_API_KEY` dans l’environnement de démarrage du proxy et gardez `${XAI_API_KEY}` avec `authMode: "key"`. Une exportation dans un autre terminal ne change pas un proxy actif : redémarrez-le via Desktop, son service ou son terminal propriétaire. Ne partagez pas les clés littérales.
 
 ## Configuration
 
diff --git a/docs-site/src/content/docs/fr/guides/web-dashboard.md b/docs-site/src/content/docs/fr/guides/web-dashboard.md
index a90aad41e04..c41206b5afe 100644
--- a/docs-site/src/content/docs/fr/guides/web-dashboard.md
+++ b/docs-site/src/content/docs/fr/guides/web-dashboard.md
@@ -22,6 +22,11 @@ l'interface contre un proxy déjà actif :
 
 ```bash
 ocx start
+```
+
+Laissez le proxy actif dans ce terminal. Dans un second terminal, lancez le serveur de développement du dashboard :
+
+```bash
 bun run dev:gui
 ```
 
diff --git a/docs-site/src/content/docs/fr/reference/architecture.md b/docs-site/src/content/docs/fr/reference/architecture.md
index 14885a808ee..d79b88e192b 100644
--- a/docs-site/src/content/docs/fr/reference/architecture.md
+++ b/docs-site/src/content/docs/fr/reference/architecture.md
@@ -88,7 +88,7 @@ Les implémentations OAuth se trouvent dans `oauth/`. Les jetons d’accès sont
 
 Par défaut, `server/index/serve-options.ts` sert HTTP/SSE sur `/v1/responses`. Si Codex tente une mise à niveau WebSocket de Responses alors que `websockets` vaut `false`, opencodex renvoie `426 upgrade_required` ; Codex revient alors à HTTP pour cette session. Lorsque `"websockets": true` est défini, le même point de terminaison accepte la mise à niveau et utilise le pont WebSocket.
 
-Indépendamment de ce réglage côté client, les requêtes canoniques transmises à ChatGPT avec `stream: true` à la racine peuvent utiliser le transport WebSocket en amont de Codex avec une version stable de Bun 1.4.0 ou ultérieure. La version intégrée Bun 1.3.14, les préversions et les identités de runtime impossibles à vérifier utilisent HTTP/SSE. Les réponses WS en amont qui réussissent conservent le contrat SSE en aval et contournent `tee()` au moyen d’un relais borné à lecteur unique et avide (4 MiB par trame brute/enveloppée et une file de production de 8 MiB). Le dépassement de la file ferme la connexion en amont et émet en aval un événement terminal `response.failed`, suivi de `[DONE]`.
+Indépendamment de ce réglage côté client, les requêtes canoniques transmises à ChatGPT avec `stream: true` à la racine peuvent utiliser le transport WebSocket en amont de Codex avec une version stable de Bun 1.4.0 ou ultérieure. Le package actuel inclut Bun **1.4.4**. Les anciennes versions intégrées, comme Bun 1.3.14, les préversions et les identités de runtime impossibles à vérifier utilisent HTTP/SSE. Les réponses WS en amont qui réussissent conservent le contrat SSE en aval et contournent `tee()` au moyen d’un relais borné à lecteur unique et avide (4 MiB par trame brute/enveloppée et une file de production de 8 MiB). Le dépassement de la file ferme la connexion en amont et émet en aval un événement terminal `response.failed`, suivi de `[DONE]`.
 
 Pour le modèle sortant final `gpt-5.3-codex-spark`, la transmission canonique à ChatGPT
 désactive explicitement Responses Lite dans l’en-tête HTTP et les métadonnées natives des
diff --git a/docs-site/src/content/docs/fr/reference/configuration/agents.md b/docs-site/src/content/docs/fr/reference/configuration/agents.md
index 6053240fb55..1d6fab85615 100644
--- a/docs-site/src/content/docs/fr/reference/configuration/agents.md
+++ b/docs-site/src/content/docs/fr/reference/configuration/agents.md
@@ -11,7 +11,7 @@ Les paramètres des agents déterminent la surface de collaboration Codex annonc
 | --- | --- | --- | --- |
 | `multiAgentMode?` | `"v1" \| "default" \| "v2"` | `"default"` | `v1` marque tous les modèles du catalogue comme compatibles v1 ; `v2` les marque tous comme compatibles v2. `default` rétablit les choix imposés en amont (Sol/Terra en v2, Luna en v1) et suit sinon l’indicateur natif `multi_agent_v2`. S’applique aux nouvelles sessions. |
 | `keepNativeChatGptOnV1?` | `boolean` | `false` | Lorsque `multiAgentMode` vaut `"v2"`, marque les lignes natives ChatGPT (Sol/Terra et les autres modèles du backend ChatGPT) comme v1. Les parents routés restent en v2. Utilisez cette option pour qu'un parent ChatGPT puisse encore lancer Grok ou Claude — les tâches enfants v2 natives sont chiffrées par le service en amont ([#92](https://github.com/lidge-jun/opencodex/issues/92)). Ignoré en `v1` et `default`. |
-| `subagentModels?` | `string[]` | `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6-luna` | Jusqu’à cinq identifiants de modèles natifs non qualifiés, qualifiés par un compte sous la forme `<selector>/<native-openai-model>`, ou routés sous la forme `provider/model`, affichés en tête du sélecteur de sous-agents. Le tableau de bord ne propose que les identifiants natifs non qualifiés et les identifiants routés ; lors de l’enregistrement, il omet les choix exacts qualifiés par un compte. Pour les définir, utilisez `ocx agent subagents set` ou modifiez la configuration. Après la [migration unique vers Astra](/reference/configuration/agents/#astra-roster-upgrade), une liste explicitement vide est conservée. |
+| `subagentModels?` | `string[]` | `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6-luna` | Jusqu’à cinq identifiants natifs non qualifiés, qualifiés par un compte `<selector>/<native-openai-model>` ou routés `provider/model`, affichés en tête du sélecteur de sous-agents. Le tableau de bord propose les identifiants natifs non qualifiés et routés pour les nouveaux choix. Lors de l’enregistrement, il conserve les identifiants exacts de compte déjà configurés, même absents du catalogue actuel. Pour ajouter un nouvel identifiant exact de compte, utilisez `ocx agent subagents set` ou modifiez la configuration. Après la [migration unique vers Astra](/reference/configuration/agents/#astra-roster-upgrade), une liste explicitement vide est conservée. |
 | `injectionModel?` | `string` | — | Modèle de sous-agent natif ou routé privilégié dans les consignes de délégation v2 produites par le proxy. |
 | `injectionEffort?` | `string` | — | Niveau d’effort privilégié (de `low` à `ultra`), pertinent uniquement avec `injectionModel`. |
 | `injectionPrompt?` | `string` | — | Remplace le corps des consignes v2 intégrées. Accepte `{{model}}`, `{{effort}}`, `{{roster}}` et `{{fallback}}`. La présence d’un `injectionModel` suffit pour produire le prompt personnalisé. |
@@ -65,13 +65,13 @@ opencodex ignore les candidats désactivés, non routables, en mauvais état, en
 ```json
 {
   "multiAgentMode": "v2",
-  "subagentModels": ["gpt-5.5", "anthropic/claude-sonnet-5"],
-  "injectionModel": "gpt-5.5",
+  "subagentModels": ["gpt-6.1-sol", "anthropic/claude-sonnet-5"],
+  "injectionModel": "gpt-6.1-sol",
   "injectionEffort": "high",
   "syncCodexSubagentDefaults": true,
-  "subagentModelFallback": ["gpt-5.6-luna"],
+  "subagentModelFallback": ["gpt-6-luna"],
   "subagentModelFallbackByModel": {
-    "gpt-5.5": ["gpt-5.6-luna"]
+    "gpt-6.1-sol": ["gpt-6-luna"]
   },
   "subagentModelFallbackPollMs": 60000,
   "subagentEffortCap": "high"
diff --git a/docs-site/src/content/docs/fr/reference/configuration/server.md b/docs-site/src/content/docs/fr/reference/configuration/server.md
index cc7ddafbcac..41f0d92be18 100644
--- a/docs-site/src/content/docs/fr/reference/configuration/server.md
+++ b/docs-site/src/content/docs/fr/reference/configuration/server.md
@@ -11,7 +11,7 @@ exécute des fonctionnalités d'assistance autour des demandes du fournisseur.
 | Champ | Type | Par défaut | Signification |
 | --- | --- | --- | --- |
 | `port` | `number` | `10100` | Port d'écoute proxy. |
-| `hostname?` | `string` | `"127.0.0.1"` | Adresse de liaison. Les liaisons hors bouclage nécessitent `OPENCODEX_API_AUTH_TOKEN`. |
+| `hostname?` | `string` | `"127.0.0.1"` | Adresse d’écoute. Hors bouclage, il faut une clé client `config.apiKeys` ou un token de données résolu depuis `OPENCODEX_API_AUTH_TOKEN`, puis `OCX_API_TOKEN_FILE`, puis le fichier privé installé `service-api-token`. Voir [Accès à distance](#remote-access). |
 | `proxy?` | `string` | — | URL du proxy HTTP(S) ou SOCKS5 sortant (`socks5://host:port`) ou `${ENV_VAR}`. Les URL HTTP s’appliquent à `HTTP_PROXY` / `HTTPS_PROXY` si elles sont vides. Les URL SOCKS5 utilisent le tunnel SOCKS5 intégré et sont aussi exposées via `ALL_PROXY` (`ocx start --socks5`); `HTTP(S)_PROXY` héritées sont effacées dans ce processus. Le bouclage reste dans `NO_PROXY`. |
 | `emptyCompletionRetry?` | `boolean` | `false` | Active une nouvelle tentative Responses identique lorsqu’une réponse ne contient ni texte ni appel d’outil. Cette tentative peut être facturée. `OCX_EMPTY_COMPLETION_RETRY=0` la désactive sans modifier la configuration ; les combinaisons et les tours de compactage routés restent exclus. |
 | `stallTimeoutSec?` | `number` | `300` (public) / désactivé (local) | Secondes sans progression utile en amont (Responses et Chat natif) avant la coupure du flux. Sans réglage, un amont **local** (loopback, privé ou nom `.local`/`.lan`) est désactivé par défaut et un amont public vaut 300 s ; une valeur positive s'applique aux deux (minimum 1 s) ; `0` désactive partout le watchdog de silence. Pour Responses qui replie le SSE canonique ChatGPT en JSON non-streaming, un plafond total indépendant de 15 minutes subsiste même lorsque ce watchdog est désactivé. Les lectures de corps en attente de `/v1/responses/compact` partagent ce budget mais valent 300 s par défaut même pour un amont local ; une valeur explicite, y compris `0`, prime. |
@@ -41,20 +41,18 @@ La commande réétiquette chaque ligne `opencodex` contenant un message utilisat
 
 Le Chat natif utilise aussi `stallTimeoutSec` pendant l’attente de la sortie amont. Le texte non vide, le raisonnement, le refus, les mises à jour d’outils et les événements de fin renouvellent ce délai ; les commentaires de maintien de connexion, le rôle seul et les statistiques seules ne le renouvellent pas. L’attente d’un client lent suspend le décompte. Un blocage produit `upstream_stall_timeout` : un événement d’erreur en streaming, ou HTTP 502 sans streaming. Une annulation avant le résultat terminal renvoie une erreur d’annulation plutôt qu’une réponse partielle réussie. Le Chat sans streaming accepte les délimiteurs SSE LF et CRLF et les champs data multilignes.
 
+<a id="remote-access"></a>
+
 ## Accès à distance
 
-La liaison par défaut à `127.0.0.1` est limitée au bouclage. Une adresse hors bouclage telle que `0.0.0.0`
-exige un identifiant pour le plan de données : `OPENCODEX_API_AUTH_TOKEN` ou au moins une entrée `apiKeys`
-configurée. Pour utiliser le jeton d’environnement, exportez-le avant le démarrage :
+La liaison par défaut à `127.0.0.1` est limitée au bouclage. Hors bouclage, par exemple sur `0.0.0.0`, les requêtes de modèle exigent une clé client configurée dans `config.apiKeys` ou un token de données partagé. Les routes de gestion `/api/*` utilisent l’identifiant indépendant `OPENCODEX_ADMIN_AUTH_TOKEN` ou le token administrateur généré, y compris en bouclage. Un identifiant de données ne donne aucun accès de gestion ; ne donnez jamais le token administrateur à un client de modèle.
 
 ```bash
 export OPENCODEX_API_AUTH_TOKEN="your-secret-token"
 ocx start
 ```
 
-Le proxy refuse une liaison distante sans identifiant du plan de données. L’installation d’un service exige
-spécifiquement `OPENCODEX_API_AUTH_TOKEN` ; exportez-le avant `ocx service install` afin que launchd, systemd
-ou le Planificateur de tâches le reçoive. Les clients du plan de données peuvent envoyer :
+L’exemple utilise un token d’environnement. L’export est facultatif si un token est déjà disponible dans `OCX_API_TOKEN_FILE` ou le fichier privé `service-api-token`, ou si une clé client valide est configurée. `ocx service install` peut créer le fichier de token manquant ; il n’exige pas que cette variable soit exportée. Les clients de modèles peuvent envoyer :
 
 ```text
 x-opencodex-api-key: your-secret-token
@@ -66,15 +64,13 @@ indépendant décrit dans la [documentation de l’API de gestion](/fr/reference
 
 | Point de terminaison | `Authorization: Bearer` | `x-opencodex-api-key` | `x-api-key` |
 | --- | --- | --- | --- |
-| `/v1/responses` | non accepté | **obligatoire** | non accepté |
-| `/v1/chat/completions` | non accepté | **obligatoire** | non accepté |
+| `/v1/responses` | accepté | accepté | non accepté |
+| `/v1/chat/completions` | accepté | accepté | non accepté |
 | `/v1/messages` | accepté | accepté | accepté |
 | `/v1/messages/count_tokens` | accepté | accepté | accepté |
 | `/v1/models` | accepté | accepté | accepté |
 
-Responses et Chat Completions réservent `Authorization` à un éventuel transfert direct vers Codex ; seul
-l'en-tête d'admission dédié y est donc accepté. Les `apiKeys` générées depuis le tableau de bord peuvent remplacer le
-jeton d'environnement après le démarrage ; les valeurs candidates sont comparées en temps constant.
+Responses et Chat Completions acceptent un identifiant reconnu du plan de données dans `x-opencodex-api-key` ou, si cet en-tête dédié est absent ou vide après suppression des espaces, dans `Authorization: Bearer`. Un en-tête dédié non vide après suppression des espaces est prioritaire même s’il est invalide ; un bearer valide ne corrige pas son refus. Un bearer sans rapport ne donne aucun accès au proxy et `x-api-key` n’est pas accepté sur ces routes. Les `apiKeys` générées par le tableau de bord et le token de données partagé sont comparés en temps constant ; les identifiants de gestion ne donnent pas accès aux modèles.
 
 Messages et `count_tokens` continuent d'accepter les trois formes d'admission pour assurer la compatibilité avec les clients routés. Le
 transfert natif vers Anthropic est plus strict sur une liaison hors bouclage : l'admission du proxy doit utiliser
diff --git a/docs-site/src/content/docs/fr/reference/management-api.md b/docs-site/src/content/docs/fr/reference/management-api.md
index 5dc6a6212b0..a6edeed53c6 100644
--- a/docs-site/src/content/docs/fr/reference/management-api.md
+++ b/docs-site/src/content/docs/fr/reference/management-api.md
@@ -11,6 +11,8 @@ proxy est en cours d'exécution.
 Utilisez le [tableau de bord web](/fr/guides/web-dashboard/) comme client interactif, ou cette référence pour
 créer des automatisations. Les valeurs persistantes obéissent en dernier ressort à la [configuration](/fr/reference/configuration/).
 
+<a id="authentication-model"></a>
+
 ## Modèle d'authentification
 
 L'API de gestion possède son propre identifiant d'administrateur, indépendant des clés API du plan de données. Au démarrage,
diff --git a/docs-site/src/content/docs/getting-started/for-agents.md b/docs-site/src/content/docs/getting-started/for-agents.md
index 9bba3f1bfc1..c960e471627 100644
--- a/docs-site/src/content/docs/getting-started/for-agents.md
+++ b/docs-site/src/content/docs/getting-started/for-agents.md
@@ -17,7 +17,11 @@ npm install -g --allow-scripts=bun @bitkyc08/opencodex
 ocx --version
 ```
 
-Choose one way to run the proxy:
+Run `ocx init` in an interactive terminal before starting the proxy, so it listens on the port selected in setup:
+
+```bash
+ocx init
+```
 
 ```bash
 # Foreground: blocks this terminal until stopped.
@@ -27,13 +31,6 @@ ocx start
 ocx service
 ```
 
-Run `ocx init` in an interactive terminal. If `ocx start` is occupying the foreground, use a
-second terminal:
-
-```bash
-ocx init
-```
-
 The wizard creates `$OPENCODEX_HOME/config.json` (normally
 `~/.opencodex/config.json`) only if it is missing. Rerunning init keeps an existing config; it has
 no force/overwrite flag. Invalid or concurrently created config is preserved and setup stops.
@@ -83,10 +80,12 @@ makes it the default provider:
 
 ```bash
 ocx provider add anthropic-apikey \
-  --api-key "$ANTHROPIC_API_KEY" \
+  --api-key '${ANTHROPIC_API_KEY}' \
   --set-default
 ```
 
+Keep the single quotes: they pass the environment reference literally instead of putting the secret in process arguments or saving its value in config. Make `ANTHROPIC_API_KEY` available to the proxy before it starts and to CLI processes that resolve provider credentials, such as model sync. Exporting it later in another terminal does not update a running proxy. For a background service, configure its startup environment and restart it; service installation does not automatically retain arbitrary provider variables from your shell.
+
 `ocx provider add` writes local configuration. Add `--sync` if a live proxy is already running and
 you want to sync models to Codex immediately; otherwise run `ocx sync` later. Custom providers that
 are not in the registry require both `--adapter` and `--base-url`.
@@ -95,7 +94,7 @@ Once all target providers are configured and the proxy is running, create a fail
 
 ```bash
 ocx combo set main \
-  --targets anthropic/claude-opus-4-8,openai/gpt-5.6-sol \
+  --targets anthropic-apikey/claude-opus-4-8,openai/gpt-5.6-sol \
   --strategy failover
 ```
 
@@ -105,14 +104,11 @@ behavior.
 
 ## Remote and LAN binds
 
-The default loopback bind does not require an API token. A non-loopback bind, such as `0.0.0.0`,
-requires `OPENCODEX_API_AUTH_TOKEN`; the proxy refuses to start without it. Set the variable before
-`ocx start`, or before `ocx service install` so the service receives it:
+Normal loopback model routes do not require a data token. A non-loopback bind, such as `0.0.0.0`, requires a data-admission credential: a client API key configured in `config.apiKeys`, or a shared token resolved from `OPENCODEX_API_AUTH_TOKEN`, `OCX_API_TOKEN_FILE`, or the owner-only `service-api-token` file. `ocx service install` can provision that file when absent. If supplying an environment token, set it before `ocx start` or `ocx service install`:
 
 ```bash
 export OPENCODEX_API_AUTH_TOKEN="your-secret-token"
 ocx service install
 ```
 
-Clients must then authenticate their management and model requests. Read the remote-access rules in
-[Configuration](/reference/configuration/) before exposing opencodex beyond the local machine.
+Model requests use data-plane authentication. Management uses an independent credential: `OPENCODEX_ADMIN_AUTH_TOKEN` or the generated admin token in a hardened file; a data token does not grant management access. The dashboard follows the session and access rules in [Management API](/reference/management-api/#authentication-model). Never give the admin token to a model client. Read [Remote access](/reference/configuration/server/#remote-access) before exposing the proxy beyond the local machine.
diff --git a/docs-site/src/content/docs/getting-started/how-it-works.mdx b/docs-site/src/content/docs/getting-started/how-it-works.mdx
index 6b4873676fb..1c19c498dfa 100644
--- a/docs-site/src/content/docs/getting-started/how-it-works.mdx
+++ b/docs-site/src/content/docs/getting-started/how-it-works.mdx
@@ -80,11 +80,12 @@ fields and can disable the entire activation settings block.
 
 ## Sub-agent model selection
 
-On a fresh install, `subagentModels` features `gpt-6-astra`, the GPT-5.6 Sol/Terra/Luna trio, and
-`gpt-5.5` in Codex's sub-agent picker. The dashboard can reorder or replace up to five entries
-with native or routed models. For v1 collaboration requests, optional `injectionModel` and
-`injectionEffort` settings add developer guidance that tells `spawn_agent` which model and reasoning
-effort to use; v2 requests keep Codex's native multi-agent guidance.
+On a fresh install, `subagentModels` features `gpt-6-astra`, `gpt-6.1-sol`, and `gpt-6-luna`
+in Codex's sub-agent picker. The dashboard can reorder or replace up to five entries with
+native or routed models. Optional `injectionModel` and `injectionEffort` settings describe
+preferred subagent choices in proxy-authored guidance; they are advisory unless native-default
+sync is enabled. See [Agent configuration](/reference/configuration/agents/) for the v1/v2
+guidance rules and native-default sync.
 
 ## The lifecycle
 
@@ -98,9 +99,10 @@ effort to use; v2 requests keep Codex's native multi-agent guidance.
    base64 text.
 
 2. **Route** — `router.ts` maps the requested model id to a configured provider using a fixed
-   precedence: explicit `provider/model` → a provider's `defaultModel` → built-in prefix patterns
-   (`claude-`, `gpt-`, `o1-`/`o3-`/`o4-`, `llama-`/`mixtral-`/`gemma-`) → a provider's `models[]` →
-   the `defaultProvider` fallback. See [Model Routing](/guides/model-routing/).
+   precedence: configured routing policy → exact Codex account selector → configured combo id or alias → explicit
+   `provider/model` → bare native OpenAI-family id (`gpt-`, `o1-`/`o3-`/`o4-`) → a provider's
+   `defaultModel` → built-in prefixes (`claude-`, `llama-`/`mixtral-`/`gemma-`) → a provider's
+   `models[]` → the `defaultProvider` fallback. See [Model Routing](/guides/model-routing/).
 
 3. **Authenticate** — for an `oauth` provider, opencodex swaps in a fresh, auto-refreshed access
    token as the bearer key, so the existing adapters authenticate unchanged. For ChatGPT/Codex pool
diff --git a/docs-site/src/content/docs/getting-started/installation.md b/docs-site/src/content/docs/getting-started/installation.md
index a2660d4c128..2f73cdc6c40 100644
--- a/docs-site/src/content/docs/getting-started/installation.md
+++ b/docs-site/src/content/docs/getting-started/installation.md
@@ -130,6 +130,8 @@ ocx update --tag preview
 
 To hack on opencodex itself:
 
+Building from a source checkout requires a separate Bun executable on PATH before running `bun install`. The npm package exposes `ocx` and `opencodex`, not a global `bun` command.
+
 ```bash
 git clone https://github.com/lidge-jun/opencodex.git
 cd opencodex
@@ -160,8 +162,7 @@ under `$CODEX_HOME` (default `~/.codex`).
 | `$CODEX_HOME/opencodex-catalog.json` | Synced native and routed model catalog used by Codex. |
 
 :::note
-opencodex never deletes your Codex config. Every injection is reversible — `ocx stop`, `ocx restore`,
-or `ocx eject` strip exactly the lines opencodex added and restore native Codex.
+opencodex preserves your Codex configuration. On the owning standalone instance, `ocx stop`, `ocx restore` and `ocx eject` remove the managed lines and restore native Codex. A connected Hub client keeps its routing, and stopping a sibling leaves shared client configuration unchanged. See [lifecycle and ownership](/reference/cli/lifecycle/#runtime-ownership) before relying on restoration.
 :::
 
 ## Next
diff --git a/docs-site/src/content/docs/getting-started/quickstart.md b/docs-site/src/content/docs/getting-started/quickstart.md
index cfb968ec901..978214ccaae 100644
--- a/docs-site/src/content/docs/getting-started/quickstart.md
+++ b/docs-site/src/content/docs/getting-started/quickstart.md
@@ -9,8 +9,9 @@ use. Steps 1 and 2 are the same for every tool; step 3 has one short branch per
 
 ## Standalone binary (no npm)
 
-You can also use a release archive containing the `ocx` binary and Bun runtime without npm.
-Extract it with its `gui/dist` directory beside the binary, then run `./ocx start`.
+You can also use a release archive containing the `ocx` binary and Bun runtime without npm. Extract it with `gui/dist` beside the binary. Run the following setup steps using that executable.
+
+For the remaining commands, add the extracted binary directory to your terminal’s PATH, or replace `ocx` with the executable’s full path. Keep `gui/dist` beside it.
 
 ## 1. Run the setup wizard
 
@@ -81,11 +82,20 @@ adapter metadata.
 
 ## 2. Start the proxy
 
+Run one of these alternatives; each keeps the proxy in the foreground:
+
 ```bash
 ocx start            # defaults to port 10100
+```
+
+Alternatively, choose a different port:
+
+```bash
 ocx start --port 8080
 ```
 
+Keep that proxy terminal open. Run the following status and dashboard commands in a second terminal with the same `OPENCODEX_HOME`.
+
 On start, opencodex:
 
 - writes its PID to `~/.opencodex/ocx.pid` (and refuses to start twice),
@@ -93,10 +103,11 @@ On start, opencodex:
   Codex's model catalog**,
 - listens on `http://localhost:<port>/v1`.
 
-If the requested port is busy, `ocx start` stops and tells you what holds it: run `ocx stop` first
-when the holder is an opencodex, or start on a free port with `ocx start --port <port>`. It does not
-move to another port by itself — that is what used to leave two proxies running with Codex pointed
-at the newer one.
+A live opencodex instance using the same `OPENCODEX_HOME` prevents a second start, even on a free port. Stop that instance first with `ocx stop`, or use a separate `OPENCODEX_HOME` for an independent instance. If an unrelated process holds the requested port, `ocx start` identifies it; choose a free port with `ocx start --port <port>`. It never changes ports automatically, which avoids leaving two proxies running with Codex pointed at the newer one.
+
+
+A separate `OPENCODEX_HOME` permits a sibling proxy, but does not independently route shared Codex, Grok or Claude configuration. The sibling serves direct requests on its own port while shared clients keep their existing proxy. A connected Hub client keeps its route on stop; stopping a sibling does not restore shared configuration. See [runtime ownership](/reference/cli/lifecycle/#runtime-ownership).
+
 
 Check it:
 
@@ -172,16 +183,12 @@ ocx integration client enable --client <id>
 
 Each tool's config file and when the change takes effect are listed in
 [Integrations](/guides/integrations/). Any other tool that accepts a custom endpoint can use the
-OpenAI-compatible base URL `http://localhost:10100/v1` or the Anthropic base URL
-`http://localhost:10100`.
+OpenAI-compatible base URL `http://localhost:<port>/v1` or the Anthropic base URL
+`http://localhost:<port>`.
 
 ## Choose sub-agent models (optional)
 
-A fresh config features five native models in Codex's sub-agent picker: `gpt-5.5`,
-`gpt-5.6-sol`, `gpt-5.6-terra`, `gpt-5.6-luna`, and `gpt-6-astra`. Open `ocx gui` to replace or
-reorder up to five native or routed models. The dashboard can also set one preferred sub-agent model
-and reasoning effort. See [Sub-agent Surface](/guides/sub-agent-surface/) to choose v1/base/v2 and
-understand when guidance, native defaults, and fallback apply.
+A fresh config includes `gpt-6-astra`, `gpt-6.1-sol`, and `gpt-6-luna` in Codex's sub-agent picker. Open `ocx gui` to replace or reorder up to five native or routed models. The dashboard can also set one preferred sub-agent model and reasoning effort. See [Sub-agent Surface](/guides/sub-agent-surface/) to choose v1/base/v2 and understand when guidance, native defaults, and fallback apply.
 
 ## Logging in instead of pasting a key
 
@@ -198,7 +205,7 @@ credentials straight through (see [Providers](/guides/providers/)).
 ## Stopping & restoring
 
 ```bash
-ocx stop          # stop the proxy and restore native Codex
+ocx stop      # stop this instance; restoration depends on ownership (see below)
 ocx restore       # restore native Codex without stopping (alias: ocx eject)
 ocx restore back  # route Codex through the still-running proxy again
 ```
diff --git a/docs-site/src/content/docs/guides/codex-app-models.md b/docs-site/src/content/docs/guides/codex-app-models.md
index 2f5805d7b49..272883ca0a1 100644
--- a/docs-site/src/content/docs/guides/codex-app-models.md
+++ b/docs-site/src/content/docs/guides/codex-app-models.md
@@ -415,8 +415,8 @@ Ultra Fast increases usage/cost, and Codex's own feature requirements still appl
 Codex sorts picker-visible catalog entries by ascending `priority` and advertises the first five as
 `spawn_agent` model overrides. The dashboard Subagents page can select and save up to five bare
 native ids or routed `provider/model` ids. Manually configured `subagentModels` also accepts
-account-qualified `<selector>/<native-openai-model>` ids, but the dashboard does not offer those
-exact ids; saving the page replaces the list with dashboard-visible choices. opencodex assigns low
+account-qualified `<selector>/<native-openai-model>` ids. The dashboard retains these exact saved
+ids, including models missing from the current catalog, when saving the roster. opencodex assigns low
 catalog priorities in the selected order; when account-qualified picker rows are enabled, bare native selections
 expand into selector-qualified groups. Other models remain callable by exact id.
 
diff --git a/docs-site/src/content/docs/guides/codex-prompt.md b/docs-site/src/content/docs/guides/codex-prompt.md
index 5ecd7f46cd4..be13c9063a7 100644
--- a/docs-site/src/content/docs/guides/codex-prompt.md
+++ b/docs-site/src/content/docs/guides/codex-prompt.md
@@ -263,7 +263,7 @@ does not recognise is left alone rather than removed.
 An absent key reads as its default rather than as `false`. The panel shows the
 value your file actually holds, and says when a key is not set.
 
-A row that carries an explicit value also offers **Reset to <default>**, which
+A row that carries an explicit value also offers **Reset to &lt;default&gt;**, which
 deletes the key line rather than writing the default back. That is the only
 state that keeps following the default if Codex changes it later — writing
 `key = true` would freeze today's default as an override.
diff --git a/docs-site/src/content/docs/guides/combos.md b/docs-site/src/content/docs/guides/combos.md
index f512988cdb1..0819609df69 100644
--- a/docs-site/src/content/docs/guides/combos.md
+++ b/docs-site/src/content/docs/guides/combos.md
@@ -385,9 +385,11 @@ models remain available in their normal picker groups.
 For headless setup, store the key explicitly or reference the TypeSafe environment variable:
 
 ```bash
-ocx provider add jev --api-key "${TYPESAFE_API_KEY}"
+ocx provider add jev --api-key '${TYPESAFE_API_KEY}'
 ```
 
+Keep the single quotes so the shell passes the reference instead of the secret. Set `TYPESAFE_API_KEY` in the proxy's startup environment and restart it if it is already running; a background service needs its own configured environment.
+
 When the provider has no saved key, the decision client also accepts `TYPESAFE_API_KEY` directly and
 the standard provider-derived alias `JEV_API_KEY` printed by `ocx provider add`.
 
@@ -943,8 +945,16 @@ A native parent can send a newly spawned worker's task only as ciphertext minted
 ChatGPT backend. An external provider cannot read that payload.
 
 For such a request, a combo filters its eligible targets to canonical native ChatGPT routes,
-including after a retryable failure. If the combo has no decrypt-capable target, opencodex stops
-before dispatch and returns HTTP 400:
+including after a retryable failure. Direct-key Responses routes explicitly trusted with
+`allowEncryptedV2AgentTasks: true` can also receive the encrypted task when selected directly,
+outside a combo; the opt-in does not make them eligible combo targets.
+If no canonical native target is selectable, or native attempts are exhausted, explicitly enabled
+`agentTaskRecovery` may recover an eligible spawned task and continue through an available routed
+combo target. The [encrypted v2 task delivery restrictions](/guides/sub-agent-surface/#encrypted-v2-task-delivery)
+still apply, including loopback-only operation, the incoming native credential and no plaintext
+persistence. If recovery is unavailable or fails and no native attempt has occurred, opencodex
+stops before dispatch and returns HTTP 400; after failed native attempts, their last error is retained.
+The initial unreadable-task response is:
 
 ```json
 {
@@ -996,7 +1006,7 @@ ocx combo remove <id> --yes
 ```
 
 `set` also accepts `--strategy`, `--sticky`, `--effort`, `--alias`, `--native-alias`,
-`--allow-metered-targets on|off`, `--display-name`, `--description`, `--decision-provider`, `--decision-timeout`, and `--rename-from`. Use `-` as the
+`--allow-metered-targets on|off`, `--cooldown-reprobe on|off`, `--cooldown-reprobe-interval`, `--display-name`, `--description`, `--decision-provider`, `--decision-timeout`, and `--rename-from`. Use `-` as the
 value of `--effort`, `--alias`, `--display-name`, `--description`, `--decision-provider`, or `--decision-timeout` to
 clear that field. The two decision flags apply only when the effective strategy is JEV: `--strategy jev`, or a stored JEV combo when `--strategy` is omitted. On an existing combo, `--targets` replaces only
 the target list: without `--strategy` the stored strategy and its JEV settings stay as they are. `--native-alias` requires a currently supported bare native
@@ -1137,8 +1147,9 @@ failover budget; failures record fresh cooldowns. Account quota checks, disabled
 providers, request compatibility, metered-spend permissions and cancellation remain
 enforced. Explicit provider Retry-After values may therefore be retried early only
 when the operator enables this option. Preview/list operations never clear cooldowns.
-The interval is tracked per combo in memory and resets on proxy restart or combo
-selection-state reset. Existing cooldown-wait behavior is unchanged when disabled.
+Each recovery pass's interval reservation is tracked per combo in memory and resets on proxy
+restart or combo selection-state reset; the cooldowns themselves stay persisted. Existing
+cooldown-wait behavior is unchanged when disabled.
 
 A recovery pass belongs only to the request that reserved it; other requests still
 observe the saved cooldowns. That reservation follows the request through cooldown
diff --git a/docs-site/src/content/docs/guides/cursor-private-inference.md b/docs-site/src/content/docs/guides/cursor-private-inference.md
index 28995eb9f47..fcad9c8b0d6 100644
--- a/docs-site/src/content/docs/guides/cursor-private-inference.md
+++ b/docs-site/src/content/docs/guides/cursor-private-inference.md
@@ -64,7 +64,7 @@ end up in the same place.
 | Field | Value |
 |---|---|
 | Base URL | `http://127.0.0.1:10100/v1` (include `/v1`; plain `http://` loopback is accepted) |
-| API Key | the value of `OPENCODEX_API_AUTH_TOKEN` if your service uses API auth, otherwise any placeholder such as `opencodex-loopback` |
+| API Key | an accepted OpenCodex key when API-key admission is enabled: `OPENCODEX_API_AUTH_TOKEN` or a configured client API key; use `opencodex-loopback` only when the configuration accepts that placeholder |
 
 Click **Refresh model list**. The picker fills with opencodex's `/v1/models`; switch on the
 rows you want.
@@ -207,7 +207,7 @@ itself.
 
 | Symptom | Check |
 |---|---|
-| 401 from the gateway | the API Key does not match `OPENCODEX_API_AUTH_TOKEN`; for a loopback bind without API auth any value works |
+| 401 from the gateway | the credential does not match an accepted data token or client API key; use an authorized key. The placeholder applies only to loopback configurations that accept unauthenticated model requests |
 | picker is empty | opencodex is not running, or the Base URL is missing `/v1`; press Refresh model list after fixing |
 | models listed but no Reasoning control | opencodex older than v2.41, or the id is not in Cursor's table (the dashboard marks it —); turn on `cursorEffortRows` or set a provider default |
 | a schema change is not picked up | Cursor caches `/models` per Base URL string with no expiry; Refresh model list re-reads it, otherwise restart the app or temporarily save a different spelling of the URL (`localhost` vs `127.0.0.1`) |
diff --git a/docs-site/src/content/docs/guides/fallback-off.md b/docs-site/src/content/docs/guides/fallback-off.md
index 424b158e01f..bc6a7d6c918 100644
--- a/docs-site/src/content/docs/guides/fallback-off.md
+++ b/docs-site/src/content/docs/guides/fallback-off.md
@@ -104,7 +104,7 @@ Home is unreachable, a Child answers a retryable `503` (and a Hub client's dashb
 { "error": "link tunnel unavailable", "code": "home_unreachable", "message": "The Home is unreachable, and OpenCodex did not serve this request from this device's local providers. …" }
 ```
 
-Nothing is sent to a local provider, and the link key and the request body never leave the device.
+Nothing is sent to a local provider. If the failure occurs before forwarding starts, neither the link key nor the request body leaves the device. If forwarding has started, the Home may already have received or processed the request: the result is uncertain. Inspect the Home before deciding whether to retry; OpenCodex does not automatically replay a dispatched request.
 
 ### Per-device settings
 
diff --git a/docs-site/src/content/docs/guides/grok-build.md b/docs-site/src/content/docs/guides/grok-build.md
index eb9281a86f9..5fa76916b9d 100644
--- a/docs-site/src/content/docs/guides/grok-build.md
+++ b/docs-site/src/content/docs/guides/grok-build.md
@@ -106,6 +106,14 @@ outside the managed markers, where nothing opencodex does can clobber them. See
 `base_url` (a host that is actually reachable from where you run `grok`) and `api_key`
 (your `OPENCODEX_API_AUTH_TOKEN`).
 
+**An enabled `unauthenticatedLoopbackListener` is the exception.** When that listener is on,
+opencodex writes the managed block after all, pointing at `127.0.0.1` on the listener's port,
+because loopback requests there need no admission token regardless of how the public listener is
+bound. A port-less companion listener shares the proxy port, and OpenCodex accepts that shape only
+on a specific non-loopback address; on the wildcards `0.0.0.0` or `::` it refuses the pair, so give
+the loopback listener a distinct `port` to use this exception. The manual recipe below still
+applies when you want to manage those entries yourself.
+
 Do not replace `api_key` with `env_key` here. An `env_key` that fails to resolve does not
 stop the request — Grok falls through to your xAI session
 token and sends it to whatever `base_url` the entry names, which for a LAN deployment is a
@@ -118,9 +126,9 @@ contact xAI directly.
 
 ## Manual recipe (without auto-registration)
 
-If you manage `~/.grok/config.toml` yourself — or opencodex is on a non-loopback bind — add
-a `[model_providers.opencodex]` block and per-model tables that reference it, outside the
-`# >>> opencodex managed block` markers:
+If you manage `~/.grok/config.toml` yourself — or opencodex is on a non-loopback bind with the
+loopback listener off — add a `[model_providers.opencodex]` block and per-model tables that
+reference it, outside the `# >>> opencodex managed block` markers:
 
 ```toml
 [model_providers.opencodex]
@@ -133,12 +141,14 @@ model = "anthropic/claude-opus-4-8"
 model_provider = "opencodex"
 ```
 
-For a proxy reachable over the network, point `base_url` at the address `grok` can actually
-dial and use your admission token:
+For a proxy reachable over the network, configure a TLS frontend before supplying your admission
+token, then point `base_url` at its HTTPS address. Alternatively, use a local tunnel and its
+loopback address. Grok stores the literal `api_key` in `~/.grok/config.toml`; restrict access to
+that file and keep it out of version control and shared backups.
 
 ```toml
 [model_providers.opencodex]
-base_url = "http://192.168.1.10:10100/v1"   # the reachable host, not 127.0.0.1
+base_url = "https://proxy.example.com/v1"   # configured TLS frontend
 api_backend = "responses"
 api_key = "your-OPENCODEX_API_AUTH_TOKEN"
 
diff --git a/docs-site/src/content/docs/guides/image-bridge.md b/docs-site/src/content/docs/guides/image-bridge.md
index 2f81d9a1f4d..95670fdb573 100644
--- a/docs-site/src/content/docs/guides/image-bridge.md
+++ b/docs-site/src/content/docs/guides/image-bridge.md
@@ -20,8 +20,10 @@ xAI Grok Imagine, so the model you're actually chatting with can still generate
   The same `bridgeEnabled` flag does arm the separate Codex `/v1/images` relay so the built-in
   `image_gen` client can call Imagine with the Grok CLI grant — see
   [Built-in image generation](/guides/codex-integration/#built-in-image-generation-image_gen).
-  If that grant (or an xAI API key) is missing, `/v1/images` returns an error instead of
-  falling through to ChatGPT.
+  If an xAI provider exists but has neither that grant nor an API key, `/v1/images`
+  returns an error instead of falling through to ChatGPT. If no xAI provider exists,
+  the relay does not handle the request; normal image-provider selection can still
+  choose a configured ChatGPT image provider.
 
   The relay only owns the route when no image provider is configured: it runs when
   `images.bridgeEnabled` is `true` **and** `images.provider` is omitted. Setting
@@ -95,10 +97,7 @@ perspective, image generation works with any routed provider instead of silently
 ## Limitations
 
 - **Only xAI Grok Imagine is supported.** DALL-E and other image providers may be added later.
-- **Web search takes priority** on adapters that support the web-search sidecar loop. If both web
-  search and image generation are requested in the same turn, web-search runs and image
-  generation is skipped. Cursor/`runTurn` adapters cannot use that sidecar today, so the image
-  bridge may still run for those dual-tool turns.
+- **Web search takes priority** when the request is eligible for the web-search loop. If both web search and image generation are requested in an eligible turn, search runs and image generation is skipped. This includes eligible `runTurn` adapters such as Cursor through `runTurnWebSearchLoop`. The image bridge can handle a dual-tool turn only when web search is not eligible.
 - **xAI costs apply.** Image generation via xAI requires an active xAI subscription or API credits.
 - **Streaming only.** The bridge works by intercepting the SSE response stream; requests with
   `stream: false` are rejected with a 400 error.
diff --git a/docs-site/src/content/docs/guides/macos-menu-bar.md b/docs-site/src/content/docs/guides/macos-menu-bar.md
index c5da2bd6ce3..89ab7089dbd 100644
--- a/docs-site/src/content/docs/guides/macos-menu-bar.md
+++ b/docs-site/src/content/docs/guides/macos-menu-bar.md
@@ -55,4 +55,4 @@ bun run build:local
 
 ## Uninstall
 
-Turn off **Start at Login** in the tray menu if you enabled it, then move `OpenCodex.app` from Applications to the Trash. This removes the bundled CLI and widget extension, but does not remove the proxy's `$OPENCODEX_HOME` state or a separately installed `ocx` service. The desktop app also writes an installation ID and login-item markers in its app configuration directory, plus a widget snapshot under `~/Library/Containers/com.opencodex.desktop.widget/Data/Library/Application Support/OpenCodex/snapshot.json`; moving the app to the Trash does not delete those files.
+Turn off **Start at Login** in the tray menu if you enabled it. If you installed the managed terminal command, choose **Remove terminal command** before moving `OpenCodex.app` from Applications to the Trash; otherwise its shim and ownership data remain outside the app bundle and the command no longer works. This removes the bundled CLI and widget extension, but does not remove the proxy's `$OPENCODEX_HOME` state or a separately installed `ocx` service. The desktop app also writes an installation ID and login-item markers in its app configuration directory, plus a widget snapshot under `~/Library/Containers/com.opencodex.desktop.widget/Data/Library/Application Support/OpenCodex/snapshot.json`; moving the app to the Trash does not delete those files.
diff --git a/docs-site/src/content/docs/guides/minimax.md b/docs-site/src/content/docs/guides/minimax.md
index 121bf88c9c1..9654b4dbe90 100644
--- a/docs-site/src/content/docs/guides/minimax.md
+++ b/docs-site/src/content/docs/guides/minimax.md
@@ -22,6 +22,11 @@ OpenCodex and connect the reversible file integration:
 
 ```bash
 ocx start
+```
+
+Keep the proxy running in this terminal. In a second terminal, enable the integration and launch MiniMax Code:
+
+```bash
 ocx integration client enable --client mcode
 ocx mcode
 ```
diff --git a/docs-site/src/content/docs/guides/model-routing.md b/docs-site/src/content/docs/guides/model-routing.md
index 91f19d0410a..87e3ca11777 100644
--- a/docs-site/src/content/docs/guides/model-routing.md
+++ b/docs-site/src/content/docs/guides/model-routing.md
@@ -15,6 +15,10 @@ through to one another.
 
 ## Precedence
 
+Before these model rules, an explicit `policy/<id>` or configured routing-profile alias
+evaluates the policy and routes its selected concrete candidate. An unknown reserved
+policy selector fails instead of falling through to provider or default routing.
+
 1. **Exact Codex account selector** — if the id is
    `<selector>/<native-openai-model>` and the selector is configured in `codexAccountNamespaces`,
    the request uses only the mapped stored account and sends the bare native model upstream.
@@ -57,8 +61,8 @@ through to one another.
    | `claude-`, `claude-sonnet-`, `claude-opus-`, `claude-haiku-` | `anthropic` |
    | `llama-`, `mixtral-`, `gemma-` | `groq` |
 
-   This matcher is name-based and, unlike the `defaultModel` / `models[]` scans, currently does not
-   filter a matching provider whose `disabled` flag is true.
+   This matcher is name-based; like the `defaultModel` / `models[]` scans, it skips a matching
+   provider whose `disabled` flag is true.
 
 7. **A provider's `models[]`** — if no prefix rule won and an active provider lists the id in its
    `models[]`, that provider is used. Rule 4 already sends a bare `gpt-*` id to the canonical enabled
diff --git a/docs-site/src/content/docs/guides/opencode.md b/docs-site/src/content/docs/guides/opencode.md
index 0465f6b079f..951f53ece07 100644
--- a/docs-site/src/content/docs/guides/opencode.md
+++ b/docs-site/src/content/docs/guides/opencode.md
@@ -141,8 +141,8 @@ catalog. Re-run `ocx export` after you add a provider or change model visibility
 Alternatively, [enable the managed integration](/guides/integrations/): `ocx sync` safely
 refreshes its already-owned blocks, leaving hand-edited or removed blocks untouched.
 
-Once merged, export the admission key before launching opencode — unless the proxy is on loopback,
-where none is needed:
+Once merged, export the admission key before launching opencode if the inference listener requires
+authentication. A listener bound only to loopback does not require it:
 
 ```bash
 export OPENCODEX_OPENCODE_API_KEY=<your key>
@@ -166,9 +166,11 @@ Loopback example:
 
 Non-loopback example:
 
+This is a manually configured remote-client example. Configure a TLS frontend first, then use its HTTPS URL; OpenCodex does not terminate TLS or discover that URL for `ocx opencode`. Plain LAN HTTP exposes the admission credential in transit. Alternatively, keep the proxy on loopback and use a local SSH tunnel. See [TLS for the data listener](/guides/remote-hub/#giving-the-data-listener-tls).
+
 ```json
 "options": {
-  "baseURL": "http://192.168.1.10:10100/v1",
+  "baseURL": "https://proxy.example.com/v1",
   "headers": {
     "x-opencodex-api-key": "{env:OPENCODEX_OPENCODE_API_KEY}"
   }
@@ -179,8 +181,10 @@ The real value is passed only through the child process environment.
 `OPENCODEX_API_AUTH_TOKEN` takes precedence, then the hardened service token file, then
 a configured API key — which is what a non-loopback bind requires.
 
-A loopback bind (`127.0.0.1`, the default) authenticates nothing, so the `{env:…}` reference is
-inert and you can leave the variable unset. It matters only when `hostname` is set beyond loopback;
+A listener bound to loopback (`127.0.0.1`, the default) does not require a data-plane key, even
+when client API keys are configured, so the `{env:…}` reference can remain unset for that listener.
+A loopback URL alone does not establish this: a public listener bound to `0.0.0.0` still requires
+an accepted key when reached through `127.0.0.1`. Export the key when `hostname` is set beyond loopback;
 see [Remote access](/reference/configuration/server/#remote-access). This admission key is opencodex's
 own, and is unrelated to the upstream provider keys configured under
 [Providers](/guides/providers/).
diff --git a/docs-site/src/content/docs/guides/pi.md b/docs-site/src/content/docs/guides/pi.md
index 4df367fbdf4..e4e7eec97e2 100644
--- a/docs-site/src/content/docs/guides/pi.md
+++ b/docs-site/src/content/docs/guides/pi.md
@@ -5,7 +5,7 @@ description: Use any routed model from Pi — ocx export writes a custom provide
 
 Pi reads its providers from a single global JSON file rather than environment variables, so
 opencodex does not launch it. Instead, `ocx export` serializes the `opencodex` provider block —
-base URL, model list, and the env reference Pi interpolates — and you merge it into your own
+base URL, model list, and a non-secret loopback key placeholder — and you merge it into your own
 config.
 
 ## Quickstart
@@ -14,11 +14,17 @@ Start the proxy, then print the config:
 
 ```bash
 ocx start
+```
+
+Leave that process running. In a second terminal, print the configuration:
+
+```bash
 ocx export --client pi
 ```
 
-The output leads with the JSON, then prints the destination path, the merge warning, the env
-export line, and how many models carry authoritative context limits.
+The output leads with the JSON, then prints the destination path, the merge warning, a loopback
+usage hint, and how many models carry authoritative context limits. This export supports only
+an unauthenticated loopback proxy; it does not configure remote admission.
 
 ```json
 {
@@ -26,7 +32,7 @@ export line, and how many models carry authoritative context limits.
     "opencodex": {
       "baseUrl": "http://127.0.0.1:10100/v1",
       "api": "openai-completions",
-      "apiKey": "$OPENCODEX_API_KEY",
+      "apiKey": "opencodex-loopback",
       "compat": {
         "sendSessionAffinityHeaders": true,
         "supportsDeveloperRole": false
@@ -86,27 +92,13 @@ provider or changing model visibility, and merge the new block over the old one.
 
 ## The admission key
 
-Two different keys are easy to confuse here, and only the first one appears in this file:
-
-| Key | What it is | Where it lives |
-| --- | --- | --- |
-| Proxy admission key | opencodex's own credential, generated on the dashboard's **API** tab | referenced by `apiKey` as `$OPENCODEX_API_KEY`; the value stays in your environment |
-| Provider key | your Anthropic / OpenAI / OpenRouter key | opencodex's own config, per [Providers](/guides/providers/) |
-
-The exported config carries only the reference, never a secret. Pi interpolates a bare `$NAME`, so
-the variable is:
-
-```bash
-export OPENCODEX_API_KEY=<your key>
-```
-
-That name is Pi's alone. opencode uses a different variable
-(`OPENCODEX_OPENCODE_API_KEY`, in `{env:…}` form) — see the [opencode guide](/guides/opencode/).
-
-**A loopback proxy needs no key at all.** opencodex binds `127.0.0.1` by default and authenticates
-nothing there, so the `$OPENCODEX_API_KEY` reference is inert and you can leave the variable unset.
-It matters only when `hostname` is set beyond loopback, which is also the case where the proxy
-refuses to start without a token — see [Remote access](/reference/configuration/server/#remote-access).
+The exported `apiKey` is the non-secret placeholder `opencodex-loopback`. No
+`OPENCODEX_API_KEY` export is emitted or required. This exporter supports only an
+unauthenticated loopback proxy and refuses a remote or token-protected listener.
+Provider credentials remain in opencodex's own configuration, as described in
+[Providers](/guides/providers/); never put an upstream provider key in this Pi block.
+For remote access, use a client integration that supports proxy admission credentials;
+changing this placeholder does not enable remote Pi export.
 
 ## Model metadata
 
@@ -116,7 +108,7 @@ window. When it does not, both fields are omitted for that model and Pi applies
 
 Output limits use the model’s known maximum from catalog or generated metadata. Only unknown limits fall back to `32000`. The output limit is always clamped to the context window, including known limits below `32000`.
 
-Two fields are deliberately absent. `cost` requires all four price fields and opencodex has no
+`cost` is deliberately absent. It requires all four price fields and opencodex has no
 price data for routed models — emitting zeros would assert that every model is free.
 
 `reasoning` is the one field that used to be absent and now is not: Pi stores a boolean while the
diff --git a/docs-site/src/content/docs/guides/protocol-paths.md b/docs-site/src/content/docs/guides/protocol-paths.md
index 209e1490768..b2961725a04 100644
--- a/docs-site/src/content/docs/guides/protocol-paths.md
+++ b/docs-site/src/content/docs/guides/protocol-paths.md
@@ -9,8 +9,7 @@ wire, decided by its adapter. When the client API and the upstream wire differ,
 converted on the way in and the answer is converted on the way back. This page explains how that
 path is named, how to see it before and after a request, and which settings change it.
 
-Every setting on this page is off by default. With the defaults, requests travel exactly as they
-did before these settings existed.
+The settings on this page are off by default except `antigravityDirect`, which is on, and the two managed-Messages switches on a recognized Anthropic instance whose account pool is enabled. `antigravityDirect` enables the direct Antigravity path when applicable, and a pooled instance derives `managedMessagesNative` and `managedMessagesNativeOAuth` unless its `anthropicAccountPool.nativeMessages` is `false`. Every other switch requires explicit activation, and an explicit rollout `false` disables either pooled default.
 
 ## Delivery modes
 
@@ -94,7 +93,7 @@ each candidate and skips one that cannot carry the request.
 
 ## Rollout switches
 
-These switches stage the new paths. Each defaults to off except `antigravityDirect`, and a switch that is off changes nothing.
+These switches stage the new paths. Each defaults to off except `antigravityDirect` and, on a recognized Anthropic instance with its account pool enabled, the two managed-Messages switches. A pooled instance enables `managedMessagesNative` and `managedMessagesNativeOAuth` unless `anthropicAccountPool.nativeMessages` is `false`; an explicit rollout `false` still turns either off. A switch that is off changes nothing.
 
 | Switch | When on |
 | --- | --- |
@@ -155,6 +154,10 @@ These paths still use the internal Responses bridge or are not covered:
 - Managed native Messages to first-party Anthropic preserve a coherent observed Claude Code CLI
   user agent, session UUID and allowlisted SDK headers across token refresh and account selection,
   for foreground (`X-App: cli`) and background (`claude --bg`, `X-App: cli-bg`) sessions alike.
+  The required bundle includes a recognized `User-Agent`, `X-App: cli` or `X-App: cli-bg`, a UUID
+  `X-Claude-Code-Session-Id`, `X-Stainless-Lang: js`, and `X-Stainless-Runtime: node`.
+  Optional SDK fields are preserved only from the identity allowlist; operator-configured headers
+  retain precedence.
   Credential placement remains proxy-owned and beta allowlisting still applies. Missing or invalid
   identity uses the existing compatibility headers; compatible hosts and generated Responses retain
   their current behavior. Headers alone do not authorize requests or establish official support.
diff --git a/docs-site/src/content/docs/guides/providers.md b/docs-site/src/content/docs/guides/providers.md
index 9b61b2b5783..5f8ee7555f3 100644
--- a/docs-site/src/content/docs/guides/providers.md
+++ b/docs-site/src/content/docs/guides/providers.md
@@ -838,7 +838,6 @@ region-pinned EU routes, is at [opper.ai/models](https://opper.ai/models). Opper
 | Umans AI · Neuralwatt | `https://api.code.umans.ai` · `https://api.neuralwatt.com/v1` |
 | Mistral | `https://api.mistral.ai/v1` |
 | MiniMax · MiniMax (CN) | `https://api.minimax.io/v1` · `https://api.minimaxi.com/v1` |
-
 | DeepSeek | `https://api.deepseek.com` |
 | Cerebras | `https://api.cerebras.ai/v1` |
 | Chutes | `https://llm.chutes.ai/v1` |
diff --git a/docs-site/src/content/docs/guides/remote-hub.md b/docs-site/src/content/docs/guides/remote-hub.md
index cee0ea5a84d..498ae198ca6 100644
--- a/docs-site/src/content/docs/guides/remote-hub.md
+++ b/docs-site/src/content/docs/guides/remote-hub.md
@@ -60,7 +60,13 @@ Connect with exactly one transient authority source. The authority is read from
 written to config or the token file:
 
 ```bash
-ocx connect https://hub-name.tailnet-name.ts.net --pairing-code-stdin
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the one-time code without echoing it or putting it in shell history.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+  --management-url https://hub-name.tailnet-name.ts.net \
+  --pairing-code-stdin
+unset pairing_code
 ocx connect status
 ocx sync
 ```
@@ -89,9 +95,16 @@ to the Hub with `https://` (or use loopback HTTP when both sides are on the same
 Rotate a connected client with a fresh transient authority:
 
 ```bash
-ocx connect rotate --pairing-code-stdin
-# or, only over HTTPS:
-ocx connect rotate --admin-token-stdin
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: choose one authority source.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect rotate --pairing-code-stdin
+unset pairing_code
+
+# Alternatively, only over HTTPS, use the management admin token:
+read -r -s -p 'Admin token: ' admin_token; printf '\n'
+printf '%s\n' "$admin_token" | ocx connect rotate --admin-token-stdin
+unset admin_token
 ```
 
 Rotation keeps the old and new data keys valid for at most ten minutes under the same `apiKeyId`.
@@ -148,6 +161,17 @@ a page you visit can make your browser connect to `127.0.0.1`. The listener ther
 same `Host` and `Origin` checks as an ordinary loopback bind.
 :::
 
+:::caution[Create the `hub` and `remoteGui` objects only when they are absent]
+`ocx config set hub '{…}'` and `ocx config set remoteGui '{…}'` replace the whole object, so on an
+existing installation they silently drop the settings already there. Check first: `ocx config get hub`
+and `ocx config get remoteGui` answer `config path not found` when the object is absent, and print it
+when it exists. Only then is the `'{}'` seed line below safe to run; when the object exists, skip it
+and use the nested `hub.<field>` form, which itself fails with `config parent path not found: hub`
+when a parent is genuinely missing. Setting a nested array or object field such as
+`hub.managementIngress` or `remoteGui.allowedTailscaleUsers` also replaces that field rather than
+merging into it, so read the current value before you overwrite one.
+:::
+
 ```bash
 ocx config set runtimeRole hub
 ocx config set hostname 100.64.0.10
@@ -180,11 +204,11 @@ ocx config set hub '{"managementPublicOrigin":"https://hub-name.tailnet-name.ts.
 ocx config set remoteGui '{"allowedTailscaleUsers":["operator@example.com"]}'
 ```
 
-Use that form only when the object does not exist yet. A whole-object set **replaces** the object
-rather than merging into it, so running the line above against a config that already had
-`hub.managementIngress` silently drops the ingress. When you are adapting an existing
-configuration, set one field at a time — the parent is already there, so the nested form works and
-touches nothing else.
+Use that form only when the object does not exist yet, as the `ocx config get` check above decides.
+A whole-object set **replaces** the object rather than merging into it, so running it against a
+config that already had `hub.managementIngress` silently drops the ingress. When you are adapting an
+existing configuration, set one field at a time — the parent is already there, so the nested form
+works and touches nothing else. Setting a nested array or object field replaces that field too.
 
 Two details that decide whether a line is accepted. The value is parsed as JSON first and falls
 back to the raw string, which is why a URL is written as `'"https://…"'`: objects, arrays, booleans
@@ -332,7 +356,7 @@ a session. Verify both directions:
 # Negative: the loopback-only port must not be reachable through the node's tailnet address.
 curl --fail --connect-timeout 3 http://100.64.0.10:10101/ && echo "unexpected exposure"
 
-# Positive: the HTTPS dashboard loads through Serve from an allowed tailnet user.
+# Transport only: an identity-required dashboard may reject curl; verify it in an allowed user's browser.
 curl --fail --silent --show-error https://hub-name.tailnet-name.ts.net/ >/dev/null
 ```
 
@@ -387,10 +411,13 @@ it is where `/readyz` and `/v1/catalog` are fetched — and `--management-url` i
 origin used for pairing and key issuance. They do not have to share a port:
 
 ```bash
-# This is exactly the line `ocx hub invite` prints, with the code filled in.
-echo '<pairing-code>' | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the one-time code without echoing it or putting it in shell history.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
   --management-url https://hub-name.tailnet-name.ts.net \
   --pairing-code-stdin
+unset pairing_code
 ```
 
 Record those two origins on the hub as `hub.dataPublicOrigin` and `hub.managementPublicOrigin`, and
@@ -443,11 +470,15 @@ Run this on the hub rather than writing an `ocx connect` line by hand:
 ocx hub invite
 ```
 
-It mints a single-use, short-lived pairing code and prints the command to run on the other machine:
+It mints a single-use, short-lived pairing code and prints the command to run on the other machine.
+To keep the code out of shell history, read it silently and pass it through stdin:
 
-```text
-# Run on the other machine:
-echo '<code>' | ocx connect https://hub-name.tailnet-name.ts.net:8443 --management-url https://hub-name.tailnet-name.ts.net --pairing-code-stdin
+```bash
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash, on the other machine:
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect https://hub-name.tailnet-name.ts.net:8443 --management-url https://hub-name.tailnet-name.ts.net --pairing-code-stdin
+unset pairing_code
 ```
 
 The data origin comes from `--data-url`, then `hub.dataPublicOrigin`, then the bind address. That
@@ -688,18 +719,31 @@ Remote access is an explicit opt-in. Set `OPENCODEX_BIND_ADDRESS` to the host's
 IP, or use `0.0.0.0` to publish on **all** host interfaces:
 
 ```bash
-OPENCODEX_BIND_ADDRESS=0.0.0.0 docker compose up -d
+OPENCODEX_PORT=10190 OPENCODEX_BIND_ADDRESS=0.0.0.0 docker compose up -d
 ```
 
 Use a firewall and an authenticated TLS/tailnet frontend before exposing the port. The bind
 override changes only the host publication; the container listener remains `0.0.0.0:10100`.
-Keep the same bind override on subsequent Compose invocations that recreate the hub. To update
+Each of these variables applies only to the command that carries it, so keep both overrides on
+every later Compose invocation that recreates the hub — or persist them in the Compose
+environment — or the recreated service returns to the default port. To update
 an existing deployment, run `docker compose build` and recreate the hub with `docker compose up -d`;
 do not repeat the one-time token initialization.
 
 Configure providers with the dashboard through an operator-owned management frontend, or with
-one-shot CLI commands that share the state volume. The commands below show the existing Remote Hub
-settings; replace the example origin and identity before enabling them:
+one-shot CLI commands that share the state volume. The commands below distinguish first-run initialization from later field updates.
+Replace the example origins and identity before enabling them:
+
+**Fresh volume only:** the seed declares runtimeRole=hub, but has no `hub` or `remoteGui` object. The token bootstrap does not create them. The initial whole-object writes below **replace** those objects: do not run them on a configured volume, where they could erase `hub.managementIngress` or other saved settings. Replace both example origins and the allowed identity first; the CORS origin is the joining machine's local proxy port.
+
+```bash
+docker compose run --rm hub bun run src/cli/index.ts config set hub '{"managementPublicOrigin":"https://hub-name.tailnet-name.ts.net","dataPublicOrigin":"https://hub-name.tailnet-name.ts.net:8443","managementIngress":{"enabled":true,"port":10101}}'
+docker compose run --rm hub bun run src/cli/index.ts config set remoteGui '{"allowedTailscaleUsers":["operator@example.com"]}'
+docker compose run --rm hub bun run src/cli/index.ts config set corsAllowOrigins '["http://localhost:10100"]'
+docker compose restart hub
+```
+
+On an already configured volume, inspect the saved objects first and update only the intended fields instead. The nested writes preserve sibling fields; the allowed-user array replaces that array, so include every identity you intend to keep. If an object is absent, use the fresh-volume initializer for that absent object only. For an existing CORS list, retain its current entries and add the joining origin as described under [Inviting another machine](#inviting-another-machine).
 
 ```bash
 docker compose run --rm hub bun run src/cli/index.ts config set hub.managementPublicOrigin '"https://hub-name.tailnet-name.ts.net"'
@@ -708,13 +752,9 @@ docker compose run --rm hub bun run src/cli/index.ts config set remoteGui.allowe
 docker compose restart hub
 ```
 
-These nested sets work because the image seeds a first-run `hub` configuration, so the object
-already exists. On a fresh standalone install it does not, and the same lines fail until you create
-it — see [Linux systemd or macOS launchd](#linux-systemd-or-macos-launchd) above.
-
 The container listener binds `0.0.0.0`, so it is already reachable on the container's own loopback
 address and the companion form of `unauthenticatedLoopbackListener` does not apply there — it is
-refused on a wildcard bind. The token bootstrap below is the container equivalent of the service's
+refused on a wildcard bind. The token bootstrap above is the container equivalent of the service's
 own provisioning step, and it likewise runs once.
 
 Do not put a token in `ARG`, `ENV`, `COPY`, Compose YAML, image history, or command arguments. Do not
@@ -775,7 +815,7 @@ on the node; use a narrower supported removal command when unrelated mappings ex
 tailscale serve status
 tailscale serve reset
 ocx config set hub.managementIngress '{"enabled":false}'
-ocx service repair
+ocx service restart
 ```
 
 For a container rollback, retain both named state volumes and their mappings. An older image
diff --git a/docs-site/src/content/docs/guides/remote-link.md b/docs-site/src/content/docs/guides/remote-link.md
index 3ea379a065d..84716188591 100644
--- a/docs-site/src/content/docs/guides/remote-link.md
+++ b/docs-site/src/content/docs/guides/remote-link.md
@@ -70,7 +70,7 @@ The **Child** role also requires a standalone OpenCodex runtime running on its c
 - **Failed** means the link needs attention. Check SSH authentication, the confirmed host key, forwarding, or the timeout reason shown in the dashboard. The side that runs the SSH tunnel keeps retrying by itself, after sleep, an outage or a restart: Home for a Child it added, and the Child for a link it joined from its own dashboard. After a timeout or forwarding error the Home retries a Child it added every minute, so a laptop that slept reconnects within about a minute of waking; a Child that joined from its own dashboard retries after one minute and doubles the wait after each retry that fails again, up to five minutes. After an authentication error either side retries every five minutes. A changed host key is never retried. To try again at once, select **Retry** in the Home's dashboard or run `ocx link reconnect --link-id <id>` on the Home. It restarts that link's tunnel without restarting OpenCodex.
 
 A failed link does not silently switch to a local provider.
-The Child returns a retryable `503` without forwarding the link key or request when its tunnel is failed, stopped, or not supervised.
+If the tunnel is failed, stopped, or not supervised before forwarding starts, the Child returns a retryable `503` without forwarding the link key or request. A failure after forwarding starts is different: the Home may already have received or processed the request, so inspect that uncertain result before retrying.
 It also keeps the key local when another process owns the tunnel port; free that port so the Child's SSH tunnel can bind it.
 
 On a Child, `GET /healthz` only says that OpenCodex is running. `GET /readyz` (and `ocx ready`) also says whether the link can carry a request right now: while it cannot, it answers `503` with `Retry-After: 1`, `"status": "pending"` and a `link` object such as `{ "state": "unavailable", "reason": "home_unreachable" }`, and while it can, `200` with `"status": "ready"` and `{ "state": "available" }`. The reasons are `tunnel_connecting`, `tunnel_failed`, `tunnel_idle`, `tunnel_unavailable`, `sidecar_invalid`, `home_unreachable`, `home_unauthorized`, `link_auth_failed`, `link_credential_unavailable`, `link_unverified` and `client_state_changed`. A Child that joined from its own dashboard answers from its tunnel. A Child that its Home added has no tunnel of its own to look at, so it asks the Home through the tunnel with the same credential-free check every relayed request starts with; it repeats that check at most once every five seconds, and answers `link_unverified` when the Home has not replied within half a second.
@@ -96,7 +96,7 @@ ocx link routes order --link-id <id> --routes <alias,alias,...>
 
 - **Every route reaches the same machine.** The link's own alias is its *pin*: its confirmed host key is the only key any route may present, and it stays in the list. Before `ocx link routes add` stores a route, the Home connects over it with strict host-key checking against that one key; a route that answers with another key, refuses the login or does not answer is not stored (`route_unproven` with the cause `hostkey`, `auth`, `forward` or `transient`). The Home also refuses the add when its private link `known_hosts` file trusts any key for the alias other than the link's own (`pin_mismatch`, `trust_file_unexpected`). Adding a Child checks the same file: a wildcard, host-list or marker line in it, which OpenCodex never writes, makes it fail with `trust_file_unexpected`; remove that line, then probe and confirm the host again. Hashed lines are fine: releases before 2.89 recorded them on Homes whose SSH configuration hashes known hosts, and each one counts for the alias it hashes; several lines for the alias are fine as long as they all carry the link's key. Confirming a different host key for an alias that a Home-initiated link already uses is refused (`link_pin_conflict`); to trust a replaced machine, remove the link and add it again. If the Home stores a route edit but its running tunnels fail to pick it up, the command fails with `routes_stored_reload_failed`; the edit is kept, and restarting OpenCodex on the Home applies it.
 - **A new route goes before the alias** unless you pass `--position`, so direct routes come first and the relay alias stays last.
-- **How the Home picks a route.** At each connection it tries the routes in order (10 seconds each). A route counts as working only once the Child's sshd accepted the tunnel and the Child fetched the Home's catalog through it with its link key; until then the link reads **Connecting**. Each route has 30 seconds for its sshd to accept the tunnel and then another 30 seconds for that check. A route that fails rests for a while (seconds after a network error, one minute after a forwarding refusal, five minutes after an authentication failure, ten minutes after a wrong host key) and the Home moves down the list. The link fails on the host key only when every route presented a wrong key.
+- **How the Home picks a route.** At each connection it probes the routes in order, allowing 10 seconds for each initial probe. If a probe succeeds, the Home starts a candidate tunnel with up to 30 seconds for the Child's sshd to grant its remote listener, followed by another 30 seconds to prove readiness. A route counts as working only once the Child fetches the Home's catalog through that tunnel with its link key; until then the link reads **Connecting**. A route that fails rests for a while (seconds after a network error, one minute after a forwarding refusal, five minutes after an authentication failure, ten minutes after a wrong host key) and the Home moves down the list. The link fails on the host key only when every route presented a wrong key.
 - **A stale tunnel blocks a link with several routes.** If the Home stopped without stopping a link's ssh, the link reads **failed** with the reason "stale tunnel may hold the port" until that ssh exits; stop it (its pid is in `<config dir>/link/<link id>.pid`). If that pid now belongs to an unrelated program, first make sure no ssh for the link is still running, then delete the `.pid` file and restart OpenCodex on the Home. If OpenCodex cannot read the `.pid` file at all, the link stays blocked the same way, also after a restart. Make the file readable again, and the link waits for the ssh it names to exit, as above; or, once no ssh for the link is running, delete the file, and the link starts within a second, or when its retry is due.
 - **Returning to a better route.** Adding or reordering routes does not move a running tunnel, and a link connected on a later route stays there while it works. The Home tries the list from the top again at the next connection: after the tunnel drops, or when you run `ocx link reconnect --link-id <id>`, which interrupts requests that are running on that link.
 - **Status.** `ocx link status --json` shows, for a link with several routes, `route` (the route in use and since when), `routes` (each route, when it may be tried again and the last outcome) and `routeBlocked`.
@@ -339,7 +339,7 @@ The check covers the intent folder and record. It does not protect against repla
 
 On the Home, run `ocx link probe child-a --json` to inspect the offered SSH fingerprint, key type and OpenCodex version. Verify the fingerprint through a trusted source. Then run `ocx link add child-a --expect-fingerprint SHA256:… --json`. The command probes again and refuses a mismatch before storing trust or issuing a key. Without the fingerprint flag, it requires an interactive terminal and an explicit `yes` after showing the fingerprint. It never prints the link key.
 
-Home-initiated connections now restart the Child after saving its connection, including capable older Child installations. The Child must already serve standalone OpenCodex on its configured port and expose bound restart support. POSIX Children need curl; Windows uses a bounded loopback HTTP request through .NET. Update or disconnect a Child that fails this preflight. On macOS and Linux Children, Home first runs the OpenCodex installation that most recently started serving the Child, including an npm install under a custom prefix, even when another installed copy is newer. An older desktop app or PATH copy no longer answers for it. If that installation is gone or cannot report its version, Desktop and system OpenCodex installations take precedence over generic PATH shims; broken candidates are skipped. Windows x64 Children use encoded PowerShell commands without consuming key stdin. The preflight reads `ocx config show --json` under the runner's 4 MiB capture limit, so a Child with a large saved configuration still accepts a link; output past that limit answers `child_preflight_output_limit` and names the command to trim. When a phase fails, `ocx link add` prints the phase together with the Child's own reason, for example an invalid saved configuration or the failing command's last error line. That reason is shortened and has OpenCodex keys and URL query strings removed.
+For a full OpenCodex installation, Home-initiated connections restart the Child after saving its connection, including capable older Child installations. That Child must already serve standalone OpenCodex on its configured port and expose bound restart support; update or disconnect it if it fails this preflight. A clean detached lightweight Child needs no running daemon; see [Ephemeral Child machines](#ephemeral-child-machines-ocx-child). POSIX Children need curl; Windows uses a bounded loopback HTTP request through .NET. On macOS and Linux Children, Home first runs the OpenCodex installation that most recently started serving the Child, including an npm install under a custom prefix, even when another installed copy is newer. An older desktop app or PATH copy no longer answers for it. If that installation is gone or cannot report its version, Desktop and system OpenCodex installations take precedence over generic PATH shims; broken candidates are skipped. Windows x64 Children use encoded PowerShell commands without consuming key stdin. The preflight reads `ocx config show --json` under the runner's 4 MiB capture limit, so a Child with a large saved configuration still accepts a link; output past that limit answers `child_preflight_output_limit` and names the command to trim. When a phase fails, `ocx link add` prints the phase together with the Child's own reason, for example an invalid saved configuration or the failing command's last error line. That reason is shortened and has OpenCodex keys and URL query strings removed.
 
 ### Ephemeral Child machines (`ocx-child`)
 
diff --git a/docs-site/src/content/docs/guides/remote-workspace.md b/docs-site/src/content/docs/guides/remote-workspace.md
index ade9bc5ed6b..2925bd8c320 100644
--- a/docs-site/src/content/docs/guides/remote-workspace.md
+++ b/docs-site/src/content/docs/guides/remote-workspace.md
@@ -42,9 +42,16 @@ accepts inclusive values from 1 through 120,000 milliseconds.
 Computer 1 owns every coding-agent login and model session. Install and log in to whichever agents
 you want to use there, then run OpenCodex as a Hub:
 
+Keep the Hub running in the foreground in this terminal:
+
 ```bash
 ocx config set runtimeRole hub
 OCX_REMOTE_WORKSPACE_ENABLED=1 ocx start
+```
+
+While the Hub is running, open a second terminal and launch the dashboard:
+
+```bash
 ocx gui
 ```
 
@@ -106,19 +113,42 @@ trust changes. Those remain the separate dashboard/session workflows below.
 The equivalent manual flow is:
 
 ```bash
+# Bash only: if using zsh, run bash first in this terminal.
 cd /path/to/project
-printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
-  --pairing-code-stdin --root "$PWD"
-ocx remote-workspace agent
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" || pairing_status=$?
+  unset pairing_code
+  if [ "$pairing_status" -eq 0 ]; then ocx remote-workspace agent; fi
+  unset pairing_status
+else
+  unset pairing_code
+fi
 ```
 
 On Windows PowerShell, use the command shown in the dashboard. The equivalent manual form is:
 
 ```powershell
-$pairingCode = 'ONE-TIME-CODE'
-$pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
-  --pairing-code-stdin --root (Get-Location).Path
-if ($LASTEXITCODE -eq 0) { ocx remote-workspace agent }
+$pairingSecret = Read-Host 'Pairing code' -AsSecureString
+$pairingBuffer = [IntPtr]::Zero
+$pairingExitCode = 1
+try {
+  $pairingBuffer = [Runtime.InteropServices.Marshal]::SecureStringToBSTR($pairingSecret)
+  $pairingCode = [Runtime.InteropServices.Marshal]::PtrToStringBSTR($pairingBuffer)
+  $pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
+    --pairing-code-stdin --root (Get-Location).Path
+  $pairingExitCode = $LASTEXITCODE
+} finally {
+  if ($pairingBuffer -ne [IntPtr]::Zero) {
+    [Runtime.InteropServices.Marshal]::ZeroFreeBSTR($pairingBuffer)
+  }
+  $pairingSecret.Dispose()
+  Remove-Variable pairingCode, pairingSecret, pairingBuffer -ErrorAction SilentlyContinue
+}
+if ($pairingExitCode -eq 0) { ocx remote-workspace agent }
+Remove-Variable pairingExitCode
 ```
 
 The current OCX Bun executable is added as one read-only file to the Linux sandbox automatically. If
@@ -126,9 +156,17 @@ the project needs a user-installed toolchain outside the system paths, pair it e
 exposing the rest of the home directory:
 
 ```bash
-printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
-  --pairing-code-stdin --root "$PWD" \
-  --toolchain-root "$HOME/.nvm/versions/node/v24/bin"
+# Bash only: if using zsh, run bash first in this terminal.
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" \
+    --toolchain-root "$HOME/.nvm/versions/node/v24/bin" || pairing_status=$?
+  unset pairing_code pairing_status
+else
+  unset pairing_code
+fi
 ```
 
 The native helper source is packaged for review. Building it does not enable Windows or macOS
diff --git a/docs-site/src/content/docs/guides/sidecars.md b/docs-site/src/content/docs/guides/sidecars.md
index 0ff80e36279..3f3cd27baaa 100644
--- a/docs-site/src/content/docs/guides/sidecars.md
+++ b/docs-site/src/content/docs/guides/sidecars.md
@@ -10,12 +10,13 @@ Anthropic OAuth provider; web search can additionally use stored Grok OAuth thro
 whole turn.
 
 :::note[Automatic backend selection]
-Explicit `backend` config wins. The two sidecars default differently when `backend` is unset:
-**web search** always defaults to `openai` — `anthropic` runs only when explicitly configured.
-**Vision** defaults to `anthropic` if an enabled Anthropic OAuth provider has an active account not
-marked `needsReauth`, otherwise `openai`. Explicit `anthropic` without that credential fails
-closed. Explicit `xai` requires a usable stored Grok OAuth account and does not fall back. `openai`
-requires both ChatGPT login auth and an enabled `forward` provider.
+Explicit `backend` configuration wins. When it is unset, each sidecar has its own default:
+**Web search** defaults to `openai`; `anthropic` and `xai` run only when explicitly configured.
+The web-search `xai` backend requires a usable stored Grok OAuth account and does not fall back.
+**Vision** defaults to `anthropic` when an enabled Anthropic OAuth provider has an active account
+not marked `needsReauth`, otherwise `openai`. Explicit `anthropic` without that credential fails
+closed. Vision accepts only `openai`, `anthropic` and `routed`; eligible xAI vision models use
+`routed`. For either sidecar, `openai` requires ChatGPT login auth and an enabled `forward` provider.
 :::
 
 On file load, a retired OpenCode Free model target in global or `claudeCode` overrides of
@@ -23,7 +24,7 @@ On file load, a retired OpenCode Free model target in global or `claudeCode` ove
 its other settings. Select a supported target before re-enabling it. Healthy targets and the defaults
 for absent sidecar sections are unchanged.
 
-### Additional web-search backends (explicit-only)
+## Additional web-search backends (explicit-only)
 
 Three more web-search backends exist beyond the ChatGPT and Claude paths. Each is
 **explicit-only** — it never activates from credential presence — and **fails closed**:
diff --git a/docs-site/src/content/docs/guides/sub-agent-surface.md b/docs-site/src/content/docs/guides/sub-agent-surface.md
index eab0c0000b8..e4a98fb0c04 100644
--- a/docs-site/src/content/docs/guides/sub-agent-surface.md
+++ b/docs-site/src/content/docs/guides/sub-agent-surface.md
@@ -165,9 +165,10 @@ developer item exists in that prefix. When guidance changes, leading tool protoc
 the replacement is inserted before current conversational input.
 
 These are instructions to the main agent, not a proxy-side spawn router. On v2, a full-history fork
-inherits the parent model and rejects model or effort overrides. Guidance therefore tells Codex to
-use `fork_turns: "none"` (or a positive partial turn count such as `"3"`) when passing `model` or
-`reasoning_effort`, and to make the task message self-contained.
+inherits the parent model and rejects model or effort overrides. The generated guidance names the
+preferred model and roster but does not prescribe `fork_turns`; when you want that combination
+yourself, the spawn must set `fork_turns: "none"` (or a positive partial turn count such as `"3"`)
+alongside `model` or `reasoning_effort`, with a self-contained task message.
 
 Custom `injectionPrompt` text can use all four placeholders:
 
diff --git a/docs-site/src/content/docs/guides/subagent-v1-default.md b/docs-site/src/content/docs/guides/subagent-v1-default.md
index ab8c6654c6f..f97a8484b00 100644
--- a/docs-site/src/content/docs/guides/subagent-v1-default.md
+++ b/docs-site/src/content/docs/guides/subagent-v1-default.md
@@ -7,9 +7,12 @@ OpenCodex installs with the sub-agent surface set to **v1**. The Dashboard, Mode
 pages all ask you to confirm before moving to **base** or **v2**, and this page is what that
 confirmation links to. The CLI does not prompt.
 
-The reason is narrow and specific: on v2, a task handed from a ChatGPT-native model to a routed
+The reason is narrow and specific: by default on v2, a task handed from a ChatGPT-native model to a routed
 model cannot be read by the routed model. That is the single most common way people delegate —
-a GPT parent spawning a Grok, Claude or GLM child — and on v2 it fails every time.
+a GPT parent spawning a Grok, Claude or GLM child — and on v2 it fails by default.
+Explicit exceptions are `keepNativeChatGptOnV1`, which keeps native ChatGPT entries on v1 while
+routed entries use v2; an authorized destination that can process the encrypted task with
+`allowEncryptedV2AgentTasks: true`; or experimental `agentTaskRecovery`, described below.
 
 ## What you see when it happens
 
@@ -37,14 +40,16 @@ routed child receives something it can act on.
 On v2 the parent emits the task as `encrypted_content`, minted by the ChatGPT backend. The key
 stays in that backend. OpenCodex never had it, so there is nothing for a proxy to decrypt and
 nothing to rewrite — the value really is ciphertext, not plaintext behind a flag. That is why
-this is structural rather than a misconfiguration, and why no proxy-side setting can fix it.
+this is structural rather than a misconfiguration: no proxy-side setting enables local decryption.
+
+No proxy-side setting enables local decryption. Experimental `agentTaskRecovery` can instead ask the ChatGPT backend to recover eligible tasks; it does not decrypt their ciphertext locally. Its authorization, eligibility and failure limits described above still apply.
 
 Three topologies are unaffected, which is worth stating because it explains the shape of the
 failure rather than the failure being mysterious:
 
 | Topology | v1 | v2 |
 | --- | --- | --- |
-| ChatGPT parent to routed child | works | **fails** |
+| ChatGPT parent to routed child | works | **fails by default**; exceptions: `keepNativeChatGptOnV1` keeps the native parent on v1, an authorized destination uses `allowEncryptedV2AgentTasks: true`, or experimental `agentTaskRecovery` recovers the task |
 | Routed parent to routed child | works | works |
 | ChatGPT parent to ChatGPT child | works | works — the backend can decrypt what it minted |
 
diff --git a/docs-site/src/content/docs/guides/video-bridge.md b/docs-site/src/content/docs/guides/video-bridge.md
index 4d0c4930f13..aa894dbd113 100644
--- a/docs-site/src/content/docs/guides/video-bridge.md
+++ b/docs-site/src/content/docs/guides/video-bridge.md
@@ -22,14 +22,12 @@ job to xAI, polls until completion, and downloads the result.
 > ```json
 > {
 >   "providers": {
->     "xai": { "adapter": "openai-chat", "apiKey": "xai-…", "authMode": "key" }
+>     "xai": { "adapter": "openai-chat", "apiKey": "${XAI_API_KEY}", "authMode": "key" }
 >   }
 > }
 > ```
 >
-> If you onboarded via `ocx login xai` (OAuth), the provider stays in `authMode: "oauth"`
-> and the bridge silently won't activate. Set `XAI_API_KEY` in the environment **or**
-> hard-code the key as shown above.
+> Set `XAI_API_KEY` in the proxy startup environment, keep the `${XAI_API_KEY}` reference and explicitly select `authMode: "key"`. Exporting it in another terminal does not change an already running proxy; restart through its owning Desktop app, service, or foreground terminal so it inherits the value. Keep literal keys out of commits, logs and shared reports.
 
 ## Configuration
 
@@ -78,7 +76,7 @@ The `video_gen` tool accepts:
 
 - **xAI only**: Video generation is only available through xAI's Grok Imagine Video API
 - **Asynchronous**: Video generation takes 30-120 seconds
-- **Cost**: Video generation is a paid xAI feature (~$0.05/sec @480p, ~$0.07/sec @720p)
+- **Cost**: video generation is a paid xAI feature. Check the [official pricing](https://docs.x.ai/developers/pricing) before using it.
 - **One video per call**: Each `video_gen` call produces one video
 - **Coexists with Image Bridge**: Both bridges can be enabled simultaneously
 - **Web search priority**: When a web search sidecar is active for a turn (non-`runTurn` adapter), the video bridge is skipped — the two cannot run concurrently. A `console.warn` is emitted so you can detect this in logs.
diff --git a/docs-site/src/content/docs/guides/web-dashboard.md b/docs-site/src/content/docs/guides/web-dashboard.md
index 2b72a64bd15..ac68dae8d42 100644
--- a/docs-site/src/content/docs/guides/web-dashboard.md
+++ b/docs-site/src/content/docs/guides/web-dashboard.md
@@ -21,6 +21,11 @@ you can run the GUI dev server separately against a running proxy:
 
 ```bash
 ocx start
+```
+
+Keep the proxy running in that terminal. In a second terminal, start the GUI dev server:
+
+```bash
 bun run dev:gui
 ```
 
@@ -198,7 +203,7 @@ is visible) and never forces an upstream refresh.
 | **Providers** | Add, edit, set the default (enabled providers only), enable/disable, and remove providers; manage OAuth account pools and API-key pools where supported. Removing the current default switches to the first remaining enabled provider when one exists; otherwise deletion is refused and the current default is kept. Provider Settings can disable live model discovery for endpoints with missing, slow, or oversized `/models` catalogs. For Claude (Anthropic) OAuth pools, each logged-in account shows its own 5-hour and weekly rate-limit bars (usage is per credential); a failed probe keeps the last-known bars and marks them unavailable until the next successful refresh. Refreshing quota skips paused OAuth accounts and disabled API keys; skipped rows without a cached reading remain unavailable but do not affect the refresh result. Refreshing reports failure when an unpaused OAuth account or enabled API key that supports quota reads has an unavailable reading. The Provider Overview shown when no provider is selected carries a **Refresh all quotas** control that forces one server-side re-read of every configured provider; a provider whose upstream probe fails keeps its last-good row, so the status line reports that the check completed rather than claiming every value is fresh, and each row's own age stays the per-provider freshness signal. Unsaved Settings and JSON edits are kept in memory per logical dashboard server: switching servers parks the draft, saving writes only to the server where editing began, and a changed saved configuration asks you to keep your draft or use the saved values. Keeping a JSON draft merges only your changes into the latest config and names any field changed on both sides; Settings saves only the fields you changed. On a relay that predates target-bound saves, the dashboard checks the target immediately before sending but cannot verify it atomically, and says so once; update the proxy for the stronger guarantee. Closing or reloading the dashboard discards these drafts. |
 | **Add provider** | One search above the tabs reaches all four at once — Accounts, Free, Local, Paid. While a query is live the results are grouped by tab with a count each, and the selected tab stays put rather than jumping. Press ArrowDown in the search box to focus the first available result action, skipping disabled buttons; if no action is available, focus stays in the search box. Local runtimes (Ollama, vLLM, LM Studio, LiteLLM) have their own tab, and a long provider note clamps to two lines with the full text one click away. Claude Code CLI (subscription) sits under Paid with a Subscription CLI badge, and selecting it warns that it bills the signed-in Claude subscription through `claude -p` and never uses an API key (use `anthropic-apikey` for key billing). |
 | **Codex Auth** | Add ChatGPT/Codex pool accounts, select the next-session account, refresh 5h / weekly / 30d quotas, enable or disable quota auto-switch, set its 1–100% threshold, and configure transient-failure failover. |
-| **Subagents** | Feature up to five bare native or namespaced routed models in the `spawn_agent` override list. The **Workflow limits for subagents** panel sets how many turns one task may run in parallel and how many model requests and distinct subagents it may use per 10-minute window. See [workflow limits](/reference/configuration/server/#workflow-limits). |
+| **Subagents** | Set the first five `spawn_agent` priorities through `subagentModels`, using bare native or namespaced routed models. This is not an allowlist: unused positions may be filled from visible catalog rows. The **Workflow limits for subagents** panel sets how many turns one task may run in parallel and how many model requests and distinct subagents it may use per 10-minute window. See [workflow limits](/reference/configuration/server/#workflow-limits). |
 | **Models** | Toggle native GPT and routed models, set provider allowlists and context caps, choose v1/base/v2, and configure the v2 thread limit. The page distinguishes a catalog saved on the hub, a catalog fetched by this client, and activation in a running client. A fetch timestamp does not prove it includes the latest hub save, and runtime activation is shown as unverified. Configured providers stay visible as zero-model groups when discovery is off or returns no rows. |
 | **Logs** | Auto-refresh recent requests with tokens, requested effort and (when available) effective outbound effort, resolved model, provider, status, request id, duration, and error details. The detail view includes the exact reasoning wire field when the adapter emits one. Filter by opaque conversation/session id (when the client sends one) to total tokens and estimated list-price cost for the currently loaded Logs ring. |
 | **Usage / Debug** | Inspect token-usage coverage and trends. The Usage page's Models table also breaks each model down into input tokens, output tokens, cache hits, cache writes, and cache hit rate; a dash means cache telemetry for that metric is unavailable. Or enable opt-in provider transport and usage-extraction diagnostics. |
@@ -309,20 +314,23 @@ upgrade and restart that proxy before retrying. Resetting a manual model price a
 model, preserving other rates saved independently.
 The **Usage** summary and Models/Providers tables show end-to-end output throughput from usage history for the selected range and filters: summed output tokens divided by summed wall-clock seconds, not an average of individual rates. The sample count is measured attempts (or requests for legacy rows without attempts); samples lacking positive finite output tokens or duration are excluded. An em dash means no sample qualified or the server returned an unusable rate. This includes pre-decode waiting and is not estimated decode speed.
 
-The **Usage** Models and Providers tables show the estimated priced portion for each row. Requests
-without a matching price or usable usage are counted as excluded beside that amount when the proxy
-reports pricing coverage fields. Usage that was only partly measured (`unreported` or `unsupported`)
-is not priced, and one excluded part excludes the whole request from that row's priced count. A
-leg that reached no upstream, or that upstream refused with an HTTP error before any output, spent
-nothing and does not; a client cancellation (499), or a leg whose response began or ended without
-a status but reported no usage, may have been billed, so it does. A refusal followed by a measured
-successful send contributes that send's cost to the summary even when the aggregate usage status
-is `unreported`. A row with only excluded requests shows an em dash with that count
-instead of a zero-dollar estimate, and a displayed zero-dollar value is a confirmed priced estimate.
-An older proxy that reports no coverage fields keeps a bare em dash with no count, so missing
-coverage stays distinct from an all-excluded row and from a confirmed zero estimate.
-These are not billing receipts or evidence of an actual charge; subscription usage or provider credits
-may apply instead.
+The **Usage** Models and Providers tables show the estimated priced portion for each row.
+Requests without a matching price or usable usage count as excluded beside that amount when
+the proxy reports pricing coverage fields. Partly measured usage (`unreported` or `unsupported`)
+is not priced; one potentially billable, unpriceable part excludes the whole request from that
+row's priced count. A usage-less leg that never reached an upstream, or was refused with an
+HTTP error before any output and without an aborted stream, is a known zero: it adds no cost
+and does not exclude another measured part of the same request. A client cancellation (499),
+or a leg whose response began or ended without a status and reported no usage, may have been
+billed; its unknown cost does exclude the request from the priced count. A refusal followed
+by a measured successful send contributes that send's cost to the summary even when the
+aggregate usage status is `unreported`. In the overall summary, requests containing only known-zero
+refusals remain unmetered, rather than becoming confirmed zero-dollar estimates. A row with only excluded
+requests shows an em dash with that count instead of a zero-dollar estimate. A displayed
+zero-dollar value is a confirmed priced estimate. An older proxy that reports no coverage
+fields keeps a bare em dash with no count, distinguishing missing coverage, an all-excluded
+row, and a confirmed zero estimate. These are price-list estimates, not billing receipts or
+evidence of an actual charge; subscription usage or provider credits may apply instead.
 
 Provider model rows may include **unresolved requested model usage**: the saved route sent the
 requested name unchanged to the default provider. These tokens belong to that serving provider,
@@ -370,11 +378,7 @@ badges and discovery information remain separate from that count.
 
 ## Delegation picker vs spawn routing
 
-The Dashboard's **Sub-agent delegation** picker stores `injectionModel` and, optionally,
-`injectionEffort`. **OpenCodex multi-agent guidance** independently controls the delegation
-instructions that use those values. On eligible v2 turns, that guidance tells the parent
-agent which exact model and reasoning effort to pass to `spawn_agent`; clearing the model also clears
-the stored effort.
+The Dashboard's **Sub-agent delegation** picker stores advisory `injectionModel` and optional `injectionEffort` preferences. **OpenCodex multi-agent guidance** independently controls whether they appear in delegation guidance on eligible v2 turns. The built-in text names preferences without ordering model overrides; it does not guarantee what Codex passes to `spawn_agent`. Clearing the model also clears the effort.
 
 The default-off **Use as native Codex subagent defaults** switch applies the same selection to Codex's
 native `[agents]` defaults on the next sync/restart when OpenCodex manages the active Codex routing.
@@ -431,10 +435,7 @@ original server revalidates its key list. Pending rotations remain available for
 
 The dashboard's management plane is separate from direct client→hub model traffic. **Connect → API Keys** shows pending rotations, displays a replacement secret only once, and requires explicit commit or abort. Browser logout invalidates only the current remote session. Connected usage is the hub store filtered by the client's `apiKeyId`; disconnected usage is local, with no mirroring.
 
-The spawn override guarantee applies to the **built-in** v2 guidance text. A custom
-`injectionPrompt` replaces that text entirely and must include `{{model}}` and `{{effort}}`
-placeholders (and optionally `{{roster}}`) or those values will not appear in the injected
-guidance.
+The **built-in** v2 guidance presents advisory preferences, not a guaranteed spawn override. A custom `injectionPrompt` replaces that text entirely and must include `{{model}}` and `{{effort}}` placeholders, and optionally `{{roster}}`, for those values to appear.
 
 The picker offers enabled native and routed models plus the global Codex effort ladder. The API
 validates the selected effort globally; Codex still validates a spawn effort against the target
@@ -526,7 +527,9 @@ allowed to answer for you:
   similar). The one-time marker stays unwritten, so the real prompt still shows up on your
   next hand-typed run. The agent is told to ask you instead — and to ask as a plain Yes/No
   choice you have to answer, not as a soft aside it can slip past you. If you never get
-  around to answering, the agent is told to re-ask rather than treat your silence as a no.
+  around to answering, silence remains deferred: the agent must not repeat the question in
+  later replies or sessions. A later version may re-arm the CLI deferral under the timing
+  policy in `AGENTS_INSTALL.md`.
 - `POST /api/github/star` answers `403` with `code: "agent_consent_required"` when the proxy
   runs under an agent session and the request has no dashboard browser session. Possessing
   the admin token is not consent: an agent on your machine can read that file.
diff --git a/docs-site/src/content/docs/ja/getting-started/for-agents.md b/docs-site/src/content/docs/ja/getting-started/for-agents.md
index db3261538f7..61f48397b2f 100644
--- a/docs-site/src/content/docs/ja/getting-started/for-agents.md
+++ b/docs-site/src/content/docs/ja/getting-started/for-agents.md
@@ -14,7 +14,11 @@ npm install -g --allow-scripts=bun @bitkyc08/opencodex
 ocx --version
 ```
 
-プロキシを実行する方法を 1 つ選択します。
+設定したポートで起動するよう、プロキシを起動する前に対話型端末で `ocx init` を実行してください:
+
+```bash
+ocx init
+```
 
 ```bash
 # Foreground: blocks this terminal until stopped.
@@ -24,12 +28,6 @@ ocx start
 ocx service
 ```
 
-対話型端末で `ocx init` を実行します。 `ocx start` がフォアグラウンドを占有している場合は、2 番目の端末を使用します。
-
-```bash
-ocx init
-```
-
 ウィザードは `$OPENCODEX_HOME/config.json` (通常は `~/.opencodex/config.json`) を書き込みます。プロキシアドレスを Codex の `config.toml` に挿入し、任意で Codex の自動起動 shim をインストールすることもできます。`ocx init` 自体はプロキシを起動しません。完全に非対話型でセットアップする場合は、ウィザードを操作せず、以下のように `ocx provider add` でプロバイダーを設定します。
 
 :::caution[GitHub スターの同意]
@@ -56,17 +54,19 @@ ocx health --json
 
 ```bash
 ocx provider add anthropic-apikey \
-  --api-key "$ANTHROPIC_API_KEY" \
+  --api-key '${ANTHROPIC_API_KEY}' \
   --set-default
 ```
 
+シングルクォートを残してください。参照を文字列のまま渡すことで、秘密値をプロセス引数や設定ファイルに含めずに済みます。`ANTHROPIC_API_KEY` はプロキシの起動前に、その起動環境と、モデル同期など認証情報を解決する CLI プロセスの環境に設定してください。別のターミナルで後から export しても、起動済みのプロキシには反映されません。バックグラウンドサービスの場合は起動環境を設定して再起動してください。サービスのインストールだけでは、任意のプロバイダー変数は引き継がれません。
+
 `ocx provider add` はローカル設定を書き込みます。稼働中のプロキシがすでに実行中で、モデルを Codex にすぐに同期したい場合は、`--sync` を追加します。それ以外の場合は、後で `ocx sync` を実行します。レジストリにないカスタム プロバイダーには、`--adapter` と `--base-url` の両方が必要です。
 
 すべてのターゲット プロバイダーが構成され、プロキシが実行されたら、フェイルオーバー コンボを作成します。
 
 ```bash
 ocx combo set main \
-  --targets anthropic/claude-opus-4-8,openai/gpt-5.6-sol \
+  --targets anthropic-apikey/claude-opus-4-8,openai/gpt-5.6-sol \
   --strategy failover
 ```
 
@@ -74,11 +74,11 @@ ocx combo set main \
 
 ## リモートとLANのバインド
 
-デフォルトのループバック バインドには API トークンは必要ありません。 `0.0.0.0` などの非ループバック バインドには `OPENCODEX_API_AUTH_TOKEN` が必要です。プロキシはそれなしでは起動を拒否します。変数を `ocx start` の前、または `ocx service install` の前に設定して、サービスがそれを受け取るようにします。
+通常のループバック上のモデルルートにはデータトークンは不要です。`0.0.0.0` などの非ループバックへのバインドには、`config.apiKeys` に設定したクライアントキー、または `OPENCODEX_API_AUTH_TOKEN`、`OCX_API_TOKEN_FILE`、所有者だけが読める `service-api-token` ファイルから解決される共有トークンが必要です。ファイルがなければ `ocx service install` が作成できます。環境変数でトークンを渡す場合は、`ocx start` または `ocx service install` より前に設定します。
 
 ```bash
 export OPENCODEX_API_AUTH_TOKEN="your-secret-token"
 ocx service install
 ```
 
-その後、クライアントは管理リクエストとモデルリクエストを認証する必要があります。 opencodex をローカル マシンの外に公開する前に、[構成](/reference/configuration/) のリモート アクセス ルールを読んでください。
+モデルリクエストはデータプレーン認証を使います。管理には独立した認証情報である `OPENCODEX_ADMIN_AUTH_TOKEN` または保護されたファイル内の生成済み管理トークンを使います。データトークンで管理アクセスはできません。ダッシュボードには[管理 API](/ja/reference/management-api/#authentication-model)のセッション・アクセス規則が適用されます。管理トークンをモデルクライアントに渡さないでください。外部公開前に[リモートアクセス](/ja/reference/configuration/server/#remote-access)を確認してください。
diff --git a/docs-site/src/content/docs/ja/getting-started/quickstart.md b/docs-site/src/content/docs/ja/getting-started/quickstart.md
index cfd4f95bca9..61d3d130d04 100644
--- a/docs-site/src/content/docs/ja/getting-started/quickstart.md
+++ b/docs-site/src/content/docs/ja/getting-started/quickstart.md
@@ -34,11 +34,20 @@ ocx init
 
 ## 2.プロキシを開始します
 
+次のどちらか一方を実行します。プロキシはフォアグラウンドで動作します。
+
 ```bash
 ocx start            # defaults to port 10100
+```
+
+別のポートを使う場合はこちらを実行します。
+
+```bash
 ocx start --port 8080
 ```
 
+この端末は開いたままにしてください。続く状態確認とダッシュボードのコマンドは、同じ `OPENCODEX_HOME` を設定した別の端末で実行します。
+
 開始時、opencodex:
 
 - PID を `~/.opencodex/ocx.pid` に書き込みます (そして 2 回起動を拒否します)。
@@ -46,7 +55,7 @@ ocx start --port 8080
 Codex のモデル カタログ**、
 - `http://localhost:<port>/v1`で聴いています。
 
-要求されたポートが使用中の場合、`ocx start` は停止し、そのポートを使用しているプロセスを通知します。opencodex が応答している場合は先に `ocx stop` を実行し、空いているポートで起動する場合は `ocx start --port <port>` を使用してください。`ocx start` が自動で別のポートへ移ることはありません。以前はこの動作によって 2 つのプロキシが同時に動作し、Codex が後から起動した方を指すことがありました。
+同じ `OPENCODEX_HOME` を使う opencodex が動作中なら、空いているポートでも 2 つ目は起動できません。先に所有インスタンスを `ocx stop` で停止するか、別の `OPENCODEX_HOME` を選んでください。兄弟インスタンスは専用ポートへの直接要求を処理しますが、Codex、Grok、Claude の共有ルーティングは変更しません。無関係なプロセスがポートを使っている場合、`ocx start` が通知します。`ocx start --port <port>` で空いているポートを指定してください。自動で別のポートに切り替わることはありません。
 
 確認してください:
 
diff --git a/docs-site/src/content/docs/ja/guides/codex-app-models.md b/docs-site/src/content/docs/ja/guides/codex-app-models.md
index daa8fc7eabf..402e793c51b 100644
--- a/docs-site/src/content/docs/ja/guides/codex-app-models.md
+++ b/docs-site/src/content/docs/ja/guides/codex-app-models.md
@@ -107,7 +107,7 @@ fast_mode = true
 
 ## サブエージェントの選択
 
-Codex は、ピッカーに表示されるカタログ エントリを `priority` の昇順で並べ替え、最初の 5 つを `spawn_agent` モデル オーバーライドとしてアドバタイズします。ダッシュボードの Subagents ページでは、bare native id または routed `provider/model` id を最大 5 つ選択して保存できます。手動で設定した `subagentModels` は account-qualified `<selector>/<native-openai-model>` id も受け付けますが、ダッシュボードにはこれらの exact id が表示されません。ページを保存すると、リストはダッシュボードに表示される選択肢で置き換えられます。opencodex は選択順に低いカタログ priority を割り当てます。account-qualified picker 行が有効な場合、bare native の選択は selector-qualified グループに展開されます。他のモデルは引き続き正確な ID で呼び出すことができます。
+Codex は、ピッカーに表示されるカタログ エントリを `priority` の昇順で並べ替え、最初の 5 つを `spawn_agent` モデル オーバーライドとしてアドバタイズします。ダッシュボードの Subagents ページでは、bare native id または routed `provider/model` id を最大 5 つ選択して保存できます。手動で設定した `subagentModels` は account-qualified `<selector>/<native-openai-model>` id も受け付けます。ダッシュボードは、現在のカタログにないモデルも含め、保存済みの正確な id をリストの保存時にも保持します。opencodex は選択順に低いカタログ priority を割り当てます。account-qualified picker 行が有効な場合、bare native の選択は selector-qualified グループに展開されます。他のモデルは引き続き正確な ID で呼び出すことができます。
 
 注目モデルのリストは、ダッシュボードの **サブエージェント委任** の選択とは別のものです。 Codex が提供するものを最初にオーバーライドするものを制御します。モデルを選択したり、委任をトリガーしたりすることはありません。
 
diff --git a/docs-site/src/content/docs/ja/guides/grok-build.md b/docs-site/src/content/docs/ja/guides/grok-build.md
index 794fb839946..243b1aefe35 100644
--- a/docs-site/src/content/docs/ja/guides/grok-build.md
+++ b/docs-site/src/content/docs/ja/guides/grok-build.md
@@ -102,11 +102,11 @@ model = "anthropic/claude-opus-4-8"
 model_provider = "opencodex"
 ```
 
-ネットワーク経由で到達可能なプロキシの場合は、`grok` が実際にダイヤルしてアドミッション トークンを使用できるアドレスに `base_url` を指定します。
+トークンを設定する前に TLS フロントエンドを構成し、その HTTPS URL を使ってください。代わりにローカルトンネルのループバックアドレスも使えます。Grok は `api_key` の値を `~/.grok/config.toml` に保存するため、アクセス権を制限し、バージョン管理や共有バックアップに含めないでください。
 
 ```toml
 [model_providers.opencodex]
-base_url = "http://192.168.1.10:10100/v1"   # the reachable host, not 127.0.0.1
+base_url = "https://proxy.example.com/v1"   # configured TLS frontend
 api_backend = "responses"
 api_key = "your-OPENCODEX_API_AUTH_TOKEN"
 
diff --git a/docs-site/src/content/docs/ja/guides/image-bridge.md b/docs-site/src/content/docs/ja/guides/image-bridge.md
index 07044143014..78d9b976ec9 100644
--- a/docs-site/src/content/docs/ja/guides/image-bridge.md
+++ b/docs-site/src/content/docs/ja/guides/image-bridge.md
@@ -12,7 +12,7 @@ OpenAI 以外のモデル (Claude、Gemini、Grok など) を介して Codex を
 - **設定で `images.bridgeEnabled: true` を設定してブリッジを有効にします** (これはオフになっています)
 予期しない xAI 請求を避けるためのデフォルト — 以下の [構成](#構成) を参照してください)。
 - **API キー**を持つ `xai` プロバイダー エントリ。ブリッジはフルフィルメントをレジストリ xAI に固定します
-画像エンドポイント (`https://api.x.ai/v1`);設定された `baseUrl` オーバーライドは、イメージ呼び出しでは無視されます。 OAuth / `ocx login xai` だけではこのサイドカー・ループは有効になりません。同じ `bridgeEnabled` フラグは、別系統の Codex `/v1/images` リレーを有効にし、組み込みの `image_gen` クライアントが Grok CLI の認可で Imagine を呼べるようにします。認可（または xAI API キー）が無い場合、`/v1/images` は ChatGPT にフォールスルーせずエラーを返します。詳細は [組み込み画像生成](/guides/codex-integration/#built-in-image-generation-image_gen) を参照してください。このリレーが経路を持つのは、`images.bridgeEnabled` が `true` で、かつ `images.provider` が未指定のときだけです。`images.provider` を明示すると `/v1/images` はそのプロバイダーが担当し、そのバリデーションエラーは xAI で再試行されずそのまま返ります。
+画像エンドポイント (`https://api.x.ai/v1`);設定された `baseUrl` オーバーライドは、イメージ呼び出しでは無視されます。 OAuth / `ocx login xai` だけではこのサイドカー・ループは有効になりません。同じ `bridgeEnabled` フラグは、別系統の Codex `/v1/images` リレーを有効にし、組み込みの `image_gen` クライアントが Grok CLI の認可で Imagine を呼べるようにします。xAI プロバイダーはあるものの認可も API キーもない場合、`/v1/images` は ChatGPT にフォールスルーせずエラーを返します。xAI プロバイダー自体がなければリレーは処理せず、通常の選択で設定済み ChatGPT 画像プロバイダーを使える場合があります。詳細は [組み込み画像生成](/guides/codex-integration/#built-in-image-generation-image_gen) を参照してください。このリレーが経路を持つのは、`images.bridgeEnabled` が `true` で、かつ `images.provider` が未指定のときだけです。`images.provider` を明示すると `/v1/images` はそのプロバイダーが担当し、そのバリデーションエラーは xAI で再試行されずそのまま返ります。
 
 「`json { "providers": { "xai": { "adapter": "openai-chat", "apiKey": "xai-…", "authMode": "key" } } } `」
 
diff --git a/docs-site/src/content/docs/ja/guides/minimax.md b/docs-site/src/content/docs/ja/guides/minimax.md
index 58859011f09..88e334e13a8 100644
--- a/docs-site/src/content/docs/ja/guides/minimax.md
+++ b/docs-site/src/content/docs/ja/guides/minimax.md
@@ -14,6 +14,11 @@ MiniMax は異なる 2 つのコマンドライン製品を提供しています
 
 ```bash
 ocx start
+```
+
+このターミナルでプロキシを実行したままにします。別のターミナルで連携を有効にし、MiniMax Code を起動します。
+
+```bash
 ocx integration client enable --client mcode
 ocx mcode
 ```
diff --git a/docs-site/src/content/docs/ja/guides/model-routing.md b/docs-site/src/content/docs/ja/guides/model-routing.md
index 900185715a3..2f5d550ff81 100644
--- a/docs-site/src/content/docs/ja/guides/model-routing.md
+++ b/docs-site/src/content/docs/ja/guides/model-routing.md
@@ -57,8 +57,8 @@ model ID は変更しません。`openai-apikey/<model>` は API key transport 
    | `claude-`、`claude-sonnet-`、`claude-opus-`、`claude-haiku-` | `anthropic` |
    | `llama-`、`mixtral-`、`gemma-` | `groq` |
 
-   この検査は名前のみを見ます。`defaultModel` / `models[]` 検査と異なり、現在は名前が一致したプロバイダーの
-   `disabled` 値が true でもスキップしません。
+   この検査は名前のみを見ます。`defaultModel` / `models[]` 検査と同じく、名前が一致したプロバイダーの
+   `disabled` 値が true ならスキップします。
 
 7. **プロバイダーの `models[]`** — プレフィックスルールに一致せず、有効なプロバイダーの `models[]` に ID が
    あればそのプロバイダーを使います。ルール 4 により、bare `gpt-*` ID は別の provider の
diff --git a/docs-site/src/content/docs/ja/guides/opencode.md b/docs-site/src/content/docs/ja/guides/opencode.md
index b0a428584ef..9f3d49c1c98 100644
--- a/docs-site/src/content/docs/ja/guides/opencode.md
+++ b/docs-site/src/content/docs/ja/guides/opencode.md
@@ -75,9 +75,11 @@ export OPENCODEX_OPENCODE_API_KEY=<your key>
 
 非ループバックの例:
 
+これはリモートクライアントを手動で設定する例です。先に TLS フロントエンドを設定し、その HTTPS URL を使ってください。OpenCodex は TLS を終端せず、`ocx opencode` もその URL を自動検出しません。LAN 上でも平文 HTTP では転送中の認証情報が露出します。代わりにプロキシをループバックにバインドし、ローカル SSH トンネルを使うこともできます。[データリスナーの TLS](/ja/guides/remote-hub/#giving-the-data-listener-tls) を参照してください。
+
 ```json
 "options": {
-  "baseURL": "http://192.168.1.10:10100/v1",
+  "baseURL": "https://proxy.example.com/v1",
   "headers": {
     "x-opencodex-api-key": "{env:OPENCODEX_OPENCODE_API_KEY}"
   }
diff --git a/docs-site/src/content/docs/ja/guides/pi.md b/docs-site/src/content/docs/ja/guides/pi.md
index 4609289109e..4d0caf1c28a 100644
--- a/docs-site/src/content/docs/ja/guides/pi.md
+++ b/docs-site/src/content/docs/ja/guides/pi.md
@@ -3,7 +3,7 @@ title: 円周率
 description: Pi からルーティングされたモデルを使用します。ocx エクスポートは、実行中のプロキシに接続された Pi の models.json のカスタム プロバイダー ブロックを書き込みます。
 ---
 
-Pi は環境変数ではなく単一のグローバル JSON ファイルからプロバイダーを読み取るため、opencodex はそれを起動しません。代わりに、`ocx export` は `opencodex` プロバイダー ブロック (ベース URL、モデル リスト、Pi が補間する環境参照) をシリアル化し、それを独自の設定にマージします。
+Pi は単一のグローバル JSON ファイルからプロバイダーを読み込みます。opencodex は Pi を起動せず、`ocx export` でベース URL、モデル一覧、秘密ではないローカルキーのプレースホルダーを含む `opencodex` プロバイダーブロックを出力します。そのブロックを既存の設定にマージしてください。
 
 ## クイックスタート
 
@@ -11,10 +11,15 @@ Pi は環境変数ではなく単一のグローバル JSON ファイルから
 
 ```bash
 ocx start
+```
+
+このプロセスを実行したまま、別のターミナルで設定を表示します。
+
+```bash
 ocx export --client pi
 ```
 
-出力は JSON で始まり、宛先パス、マージ警告、env エクスポート行、および権威コンテキスト制限を持つモデルの数を出力します。
+JSON に続いて、保存先、マージに関する警告、ループバックでの使用方法、確定したコンテキスト上限を持つモデル数が表示されます。このエクスポートは認証不要のループバックプロキシ専用で、リモートアクセスの認証は設定しません。
 
 ```json
 {
@@ -22,7 +27,7 @@ ocx export --client pi
     "opencodex": {
       "baseUrl": "http://127.0.0.1:10100/v1",
       "api": "openai-completions",
-      "apiKey": "$OPENCODEX_API_KEY",
+      "apiKey": "opencodex-loopback",
       "compat": {
         "sendSessionAffinityHeaders": true,
         "supportsDeveloperRole": false
@@ -70,22 +75,7 @@ ocx export --client pi --json > ~/opencodex-pi-models.json   # or redirect the b
 
 ## アドミッションキー
 
-ここでは 2 つの異なるキーが混同されやすいため、このファイルには最初のキーのみが表示されます。
-
-|キー |それは何ですか |それが住んでいる場所 |
-| --- | --- | --- |
-|プロキシ アドミッション キー | opencodex 自身の認証情報。ダッシュボードの **API** タブで生成されます。 `apiKey` では `$OPENCODEX_API_KEY` として参照されます。値は環境内に残ります。
-|プロバイダーキー | Anthropic / OpenAI / OpenRouter キー | opencodex 独自の設定、[プロバイダー](/guides/providers/) ごと |
-
-エクスポートされた設定には参照のみが含まれ、シークレットは含まれません。 Pi は裸の `$NAME` を補間するため、変数は次のようになります。
-
-```bash
-export OPENCODEX_API_KEY=<your key>
-```
-
-その名前はパイだけです。 opencode は別の変数 (`OPENCODEX_OPENCODE_API_KEY`、`{env:…}` 形式) を使用します。[オープンコードガイド](/guides/opencode/) を参照してください。
-
-**ループバック プロキシにはキーはまったく必要ありません。** opencodex はデフォルトで `127.0.0.1` をバインドし、そこでは何も認証しないため、`$OPENCODEX_API_KEY` 参照は不活性であり、変数を設定しないままにすることができます。これは、`hostname` がループバックを超えて設定されている場合にのみ問題になります。これは、プロキシがトークンなしでの開始を拒否する場合でもあります。[リモートアクセス](/ja/reference/configuration/server/#リモートアクセス) を参照してください。
+出力される `apiKey` は秘密ではないプレースホルダー `opencodex-loopback` です。キー用の環境変数をエクスポートする必要はありません。エクスポーターは認証不要のループバックプロキシだけを許可し、リモートまたはトークンで保護されたプロキシを拒否します。プロバイダーの認証情報は [プロバイダー](/ja/guides/providers/) に示す opencodex の設定内に保持されます。Pi のこのブロックに上流プロバイダーのキーを入れないでください。リモート接続にはプロキシへのアクセス認証に対応した別の連携を使ってください。プレースホルダーを変えても Pi のリモートエクスポートは有効になりません。
 
 ## モデルのメタデータ
 
@@ -93,7 +83,11 @@ export OPENCODEX_API_KEY=<your key>
 
 出力上限にはカタログまたは生成メタデータの既知のモデル上限を使用します。不明な場合のみ `32000` を使用します。出力上限は常にコンテキストウィンドウ以下に制限され、`32000` 未満の既知の上限も維持されます。
 
-2 つのフィールドは意図的に省略されています。 `cost` には 4 つの価格フィールドがすべて必要ですが、opencodex にはルーティング モデルの価格データがありません。ゼロを出力すると、すべてのモデルが無料であると主張されます。 `reasoning` は Pi のブール値ですが、カタログにはエフォート ラダーが記載されており、一方をもう一方にマッピングするのは推測になります。
+`cost` は意図的に省略します。4 つの価格フィールドがすべて必要ですが、opencodex にはルーティング先モデルの価格データがなく、ゼロを出すと無料だと誤認させます。
+
+カタログのエフォート段階が**空でない**場合は `"reasoning": true` を出力します。段階がない場合や明示的に空の場合は出力しません。`thinkingLevelMap` では対応先のない Pi の段階を `null` にし、未宣言の値を提示・送信しないようにします。`ultra` があり `max` がない場合、Pi の `max` を `ultra` に対応させます。別の対応が必要なら、Pi の説明に従って `thinkingLevelMap` を手動編集します。
+
+`reasoning` はカタログ由来の Pi UI メタデータであり、プロバイダーのネイティブ対応を証明しません。実際の `reasoning_effort` はアダプターとモデルに応じて転送、変換、制限、エミュレート、または省略されます（例：`noReasoningModels`）。このブール値は Pi が操作項目を表示するかだけを決めます。
 
 ## スキーマのステータス
 
diff --git a/docs-site/src/content/docs/ja/guides/remote-hub.md b/docs-site/src/content/docs/ja/guides/remote-hub.md
index e73af96b026..3e52cbad97a 100644
--- a/docs-site/src/content/docs/ja/guides/remote-hub.md
+++ b/docs-site/src/content/docs/ja/guides/remote-hub.md
@@ -12,7 +12,13 @@ Remote Hub はプロバイダー認証情報、カタログ、使用量を一台
 `standalone` は一台で完結し、`hub` はプロバイダー秘密情報と使用量を所有し、`client` は接続状態とクライアント専用データキーだけを保存します。
 
 ```bash
-ocx connect https://hub-name.tailnet-name.ts.net --pairing-code-stdin
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the one-time code without echoing it or putting it in shell history.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+  --management-url https://hub-name.tailnet-name.ts.net \
+  --pairing-code-stdin
+unset pairing_code
 ocx connect status
 ocx sync
 ```
@@ -66,6 +72,8 @@ tailscale serve status
 
 `/healthz` の `200` はプロセスの生存確認にすぎません。`/readyz`、認証済み `GET /v1/catalog`、実際のモデル応答も確認してください。独自 TLS プロキシでは `tailscale cert hub-name.tailnet-name.ts.net` を使い、`127.0.0.1:10101` のみに転送します。`Tailscale-User-*` を偽造せず、信頼できる ID がない場合は一度限りのペアリングを使います。
 
+<a id="giving-the-data-listener-tls"></a>
+
 ### データリスナーに TLS を付ける
 
 上の Serve マッピングが公開するのは**管理**入口だけです。管理入口は `/v1/*`、`/healthz`、`/readyz` を提供しないため、それだけではリモートクライアントが使えるデータプレーンになりません。opencodex 自身は TLS を終端しません。リスナーは平文 HTTP で、HTTPS は常に運用者が用意するフロントエンドの役目です。
@@ -86,9 +94,13 @@ Serve が受け付ける HTTPS ポートは限られています。通ったと
 接続時は二つの origin を別々に指定します。位置引数の URL が**データ** origin で、`/readyz` と `/v1/catalog` はここから取得されます。`--management-url` はペアリングとキー発行に使うダッシュボードの origin です。ポートが同じである必要はありません。
 
 ```bash
-ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the management admin token without echoing it.
+read -r -s -p 'Admin token: ' admin_token; printf '\n'
+printf '%s\n' "$admin_token" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
   --management-url https://hub-name.tailnet-name.ts.net \
   --admin-token-stdin
+unset admin_token
 ```
 
 `--management-url` を省略すると `/readyz` の応答が返す `hub.managementPublicOrigin` が使われます。二つの origin が異なる場合は明示したほうが明快です。
@@ -102,10 +114,16 @@ Serve が立ち上がったら、HTTPS のデータ origin に対して `/readyz
 ## OAuth、キー更新、切断
 
 ```bash
-ocx config set oauthOpenBrowser false
-ocx connect rotate --pairing-code-stdin
-# HTTPS のみ:
-ocx connect rotate --admin-token-stdin
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: choose one authority source.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect rotate --pairing-code-stdin
+unset pairing_code
+
+# Alternatively, only over HTTPS, use the management admin token:
+read -r -s -p 'Admin token: ' admin_token; printf '\n'
+printf '%s\n' "$admin_token" | ocx connect rotate --admin-token-stdin
+unset admin_token
 ```
 
 OAuth は `POST /api/oauth/login` で開始し、コールバックできない場合は最終 URL またはコードを `{provider,input}` として `POST /api/oauth/login/code` へ渡します。コードを argv やログに残さないでください。
diff --git a/docs-site/src/content/docs/ja/guides/remote-workspace.md b/docs-site/src/content/docs/ja/guides/remote-workspace.md
index be1812cdafc..d3fa8d160a3 100644
--- a/docs-site/src/content/docs/ja/guides/remote-workspace.md
+++ b/docs-site/src/content/docs/ja/guides/remote-workspace.md
@@ -23,9 +23,16 @@ Remote Workspace は明示的に有効化する機能で、実運用向けの公
 
 コンピューター 1 がすべてのコーディングエージェントのログインとモデルセッションを所有します。使いたいエージェントをそこにインストールしてログインし、OpenCodex を Hub として実行します。
 
+このターミナルで Hub をフォアグラウンド実行したままにします。
+
 ```bash
 ocx config set runtimeRole hub
 OCX_REMOTE_WORKSPACE_ENABLED=1 ocx start
+```
+
+Hub を実行したまま別のターミナルを開き、ダッシュボードを起動します。
+
+```bash
 ocx gui
 ```
 
@@ -45,27 +52,58 @@ Codex Remote Workspace は現行の App Server 権限プロファイルを使い
 手動での同等の手順は次のとおりです。
 
 ```bash
+# Bash only: if using zsh, run bash first in this terminal.
 cd /path/to/project
-printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
-  --pairing-code-stdin --root "$PWD"
-ocx remote-workspace agent
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" || pairing_status=$?
+  unset pairing_code
+  if [ "$pairing_status" -eq 0 ]; then ocx remote-workspace agent; fi
+  unset pairing_status
+else
+  unset pairing_code
+fi
 ```
 
 Windows PowerShell ではダッシュボードに表示されたコマンドを使います。同等の手動操作は次のとおりです。
 
 ```powershell
-$pairingCode = 'ONE-TIME-CODE'
-$pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
-  --pairing-code-stdin --root (Get-Location).Path
-if ($LASTEXITCODE -eq 0) { ocx remote-workspace agent }
+$pairingSecret = Read-Host 'Pairing code' -AsSecureString
+$pairingBuffer = [IntPtr]::Zero
+$pairingExitCode = 1
+try {
+  $pairingBuffer = [Runtime.InteropServices.Marshal]::SecureStringToBSTR($pairingSecret)
+  $pairingCode = [Runtime.InteropServices.Marshal]::PtrToStringBSTR($pairingBuffer)
+  $pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
+    --pairing-code-stdin --root (Get-Location).Path
+  $pairingExitCode = $LASTEXITCODE
+} finally {
+  if ($pairingBuffer -ne [IntPtr]::Zero) {
+    [Runtime.InteropServices.Marshal]::ZeroFreeBSTR($pairingBuffer)
+  }
+  $pairingSecret.Dispose()
+  Remove-Variable pairingCode, pairingSecret, pairingBuffer -ErrorAction SilentlyContinue
+}
+if ($pairingExitCode -eq 0) { ocx remote-workspace agent }
+Remove-Variable pairingExitCode
 ```
 
 現在の OCX Bun 実行ファイルは、Linux サンドボックスに読み取り専用のファイル 1 件として自動追加されます。プロジェクトでシステムパス外のユーザーインストール済みツールチェーンが必要なら、ホームディレクトリ全体を公開せず、明示的にペアリングします。
 
 ```bash
-printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
-  --pairing-code-stdin --root "$PWD" \
-  --toolchain-root "$HOME/.nvm/versions/node/v24/bin"
+# Bash only: if using zsh, run bash first in this terminal.
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" \
+    --toolchain-root "$HOME/.nvm/versions/node/v24/bin" || pairing_status=$?
+  unset pairing_code pairing_status
+else
+  unset pairing_code
+fi
 ```
 
 ネイティブヘルパーのソースはレビュー用に同梱されています。ビルドしても、この段階では Windows や macOS のコマンドは有効になりません。`--executor-helper` はレビュー済みヘルパーを選ぶための指定のままであり、バイナリの存在やパスの設定だけではコマンド対応の証明になりません。
diff --git a/docs-site/src/content/docs/ja/guides/subagent-v1-default.md b/docs-site/src/content/docs/ja/guides/subagent-v1-default.md
index ab3814d4e71..9643e73c7dc 100644
--- a/docs-site/src/content/docs/ja/guides/subagent-v1-default.md
+++ b/docs-site/src/content/docs/ja/guides/subagent-v1-default.md
@@ -28,7 +28,9 @@ HTTP 400 が返され、暗号文は応答に含まれません。読めない
 
 v1 では親が子のタスクを平文として出力します。OpenCodex がそれを読み、ルーティングし、子は実行可能な内容を受け取ります。
 
-v2 では親が ChatGPT バックエンドで生成された `encrypted_content` としてタスクを出力します。鍵はそのバックエンドに残ります。OpenCodex は鍵を持っていないため、プロキシが復号したり書き換えたりすることはできません。値はフラグの裏に隠れた平文ではなく、本物の暗号文です。そのため設定ミスではなく構造上の問題であり、プロキシ側の設定では修正できません。
+v2 では親が ChatGPT バックエンドで生成された `encrypted_content` としてタスクを出力します。鍵はそのバックエンドに残ります。OpenCodex は鍵を持っていないため、プロキシが復号したり書き換えたりすることはできません。値はフラグの裏に隠れた平文ではなく、本物の暗号文です。そのため設定ミスではなく構造上の問題であり、プロキシ側の設定でローカル復号を有効にはできません。
+
+プロキシ側の設定でローカル復号を有効にはできません。実験的な `agentTaskRecovery` は ChatGPT バックエンドに対象タスクの回復を依頼できますが、暗号文をローカルで復号するものではありません。上記の承認、適格性、失敗時の制約は引き続き適用されます。
 
 影響を受けない構成は 3 つあります。失敗する境界を理解するために区別してください。
 
diff --git a/docs-site/src/content/docs/ja/guides/video-bridge.md b/docs-site/src/content/docs/ja/guides/video-bridge.md
index 0c59ae681e1..7c1e77ca85c 100644
--- a/docs-site/src/content/docs/ja/guides/video-bridge.md
+++ b/docs-site/src/content/docs/ja/guides/video-bridge.md
@@ -18,15 +18,13 @@ Video Bridge を使用すると、opencodex によってルーティングされ
 >
 > ```json
 > {
->   「プロバイダー」: {
->     "xai": { "adapter": "openai-chat", "apiKey": "xai-…", "authMode": "key" }
+>   "providers": {
+>     "xai": { "adapter": "openai-chat", "apiKey": "${XAI_API_KEY}", "authMode": "key" }
 >   }
 > }
 > ```
 >
-> `ocx login xai` (OAuth) 経由でオンボードした場合、プロバイダーは `authMode: "oauth"` のままになります。
-> ブリッジは静かに起動しません。 **または**環境で`XAI_API_KEY`を設定します
-> 上に示したようにキーをハードコーディングします。
+> プロキシの起動環境に `XAI_API_KEY` を設定し、`${XAI_API_KEY}` と `authMode: "key"` を維持してください。他の端末での export は稼働中のプロキシに届きません。所有する Desktop、サービスまたは前景端末から再起動します。キーをコミットやログに残さないでください。
 
 ## 構成
 
diff --git a/docs-site/src/content/docs/ja/guides/web-dashboard.md b/docs-site/src/content/docs/ja/guides/web-dashboard.md
index 247860ed73b..6e609a51310 100644
--- a/docs-site/src/content/docs/ja/guides/web-dashboard.md
+++ b/docs-site/src/content/docs/ja/guides/web-dashboard.md
@@ -18,6 +18,11 @@ ocx gui
 
 ```bash
 ocx start
+```
+
+そのターミナルでプロキシを実行したまま、別のターミナルで GUI の開発サーバーを起動します。
+
+```bash
 bun run dev:gui
 ```
 
diff --git a/docs-site/src/content/docs/ja/reference/configuration/agents.md b/docs-site/src/content/docs/ja/reference/configuration/agents.md
index 19644ea5da2..d0623c713d8 100644
--- a/docs-site/src/content/docs/ja/reference/configuration/agents.md
+++ b/docs-site/src/content/docs/ja/reference/configuration/agents.md
@@ -10,7 +10,7 @@ description: マルチエージェント サーフェス、委任ガイダンス
 |フィールド |タイプ |デフォルト |意味 |
 | --- | --- | --- | --- |
 | `multiAgentMode?` | `"v1" \| "default" \| "v2"` | `"default"` | `v1` はすべてのカタログ モデルを v1 としてスタンプします。 `v2` はすべてのモデルを v2 としてスタンプします。 `default` はアップストリーム ピン (Sol/Terra v2、Luna v1) を復元し、それ以外の場合はネイティブの `multi_agent_v2` フラグに従います。新しいセッションに適用されます。 |
-| `subagentModels?` | `string[]` | `gpt-6-astra`、`gpt-6.1-sol`、`gpt-6-luna` |最大 5 つの bare native id、account-qualified `<selector>/<native-openai-model>` id、または routed `provider/model` id をサブエージェント ピッカーで優先表示します。Subagents ページで選べるのは bare native id と routed id だけで、保存時には exact account-qualified の選択が除外されます。exact の選択には `ocx agent subagents set` を使用するか、設定を直接編集してください。[Astra への一度限りの移行](/reference/configuration/agents/#astra-roster-upgrade)後は、明示的な空リストも保持されます。 |
+| `subagentModels?` | `string[]` | `gpt-6-astra`、`gpt-6.1-sol`、`gpt-6-luna` | 最大 5 つの bare native id、account-qualified `<selector>/<native-openai-model>` id、または routed `provider/model` id をサブエージェントの選択欄に優先表示します。新しく選べるのは bare native id と routed id です。保存時には、現在のカタログにないものも含め、設定済みの正確な account-qualified id を保持します。新しい正確な account-qualified id を追加するには `ocx agent subagents set` を使うか設定を編集してください。[Astra への一度限りの移行](/reference/configuration/agents/#astra-roster-upgrade)後は明示的な空リストも保持されます。 |
 | `injectionModel?` | `string` | — |プロキシ作成の v2 委任ガイダンスで使用される、優先されるネイティブまたはルーティングされたサブエージェント モデル。 |
 | `injectionEffort?` | `string` | — |優先努力 (`low` ～ `ultra`)。`injectionModel` でのみ意味があります。 |
 | `injectionPrompt?` | `string` | — | 組み込みの v2 ガイダンス本文を置き換えます。`{{model}}`、`{{effort}}`、`{{roster}}`、`{{fallback}}`をサポートします。`injectionModel` が設定されていればカスタムプロンプトが生成されます。 |
@@ -68,13 +68,13 @@ opencodex は、無効、ルーティング不能、異常、冷却期間、ま
 ```json
 {
   "multiAgentMode": "v2",
-  "subagentModels": ["gpt-5.5", "anthropic/claude-sonnet-5"],
-  "injectionModel": "gpt-5.5",
+  "subagentModels": ["gpt-6.1-sol", "anthropic/claude-sonnet-5"],
+  "injectionModel": "gpt-6.1-sol",
   "injectionEffort": "high",
   "syncCodexSubagentDefaults": true,
-  "subagentModelFallback": ["gpt-5.6-luna"],
+  "subagentModelFallback": ["gpt-6-luna"],
   "subagentModelFallbackByModel": {
-    "gpt-5.5": ["gpt-5.6-luna"]
+    "gpt-6.1-sol": ["gpt-6-luna"]
   },
   "subagentModelFallbackPollMs": 60000,
   "subagentEffortCap": "high"
diff --git a/docs-site/src/content/docs/ja/reference/configuration/server.md b/docs-site/src/content/docs/ja/reference/configuration/server.md
index 1a3028c97db..346a2f127a9 100644
--- a/docs-site/src/content/docs/ja/reference/configuration/server.md
+++ b/docs-site/src/content/docs/ja/reference/configuration/server.md
@@ -10,7 +10,7 @@ description: リスナー、リモート アクセス、アドミッション 
 |フィールド |タイプ |デフォルト |意味 |
 | --- | --- | --- | --- |
 | `port` | `number` | `10100` |プロキシリッスンポート。 |
-| `hostname?` | `string` | `"127.0.0.1"` |バインドアドレス。非ループバック バインドには `OPENCODEX_API_AUTH_TOKEN` が必要です。 |
+| `hostname?` | `string` | `"127.0.0.1"` | バインド先。非ループバックでは `config.apiKeys` のクライアントキー、または `OPENCODEX_API_AUTH_TOKEN` → `OCX_API_TOKEN_FILE` → 所有者専用のインストール済み `service-api-token` から解決される共有データトークンが必要です。[リモートアクセス](#remote-access)を参照してください。 |
 | `proxy?` | `string` | — |送信 HTTP(S) または SOCKS5 プロキシ URL（`socks5://host:port`）または `${ENV_VAR}`。HTTP URL は未設定時のみ `HTTP_PROXY` / `HTTPS_PROXY` に適用されます。SOCKS5 URL は組み込みの SOCKS5 トンネルを使用し、`ALL_PROXY` にも適用されます（`ocx start --socks5`）。このプロセスで継承した `HTTP(S)_PROXY` はクリアされます。ループバックは `NO_PROXY` に残ります。 |
 | `emptyCompletionRetry?` | `boolean` | `false` | テキストもツール呼び出しもない Responses ターンを、ターミナルイベント前にストリームが終了した場合も含め、同一リクエストで 1 回再試行するよう明示的に有効化します。再試行は課金対象になる場合があります。`OCX_EMPTY_COMPLETION_RETRY=0` で設定を変更せず無効化できます。combo と routed-compaction turn は対象外です。 |
 | `dropCodexSafetyBuffering?` | `boolean` | `false` | Codex Responses パススルーから Codex の safety-buffering ヒントを除去します。対象は `x-codex-safety-buffering-enabled` / `x-codex-safety-buffering-faster-model` 応答ヘッダー、`safety_buffering` 型の `response.metadata` SSE イベント、およびその他の SSE イベントにある `safety_buffering` フィールドです。Codex TUI はこれらを、既定の操作でセッションをより弱いモデルに切り替える「より高速なモデルで再試行」プロンプトとして表示します。その他の `x-codex-*` ヘッダーと SSE イベントの内容は、そのフィールドの除去を除いて変更せずに転送されます。既定ではオフです。 |
@@ -41,16 +41,18 @@ description: リスナー、リモート アクセス、アドミッション 
 
 ネイティブ Chat も上流出力の待機に `stallTimeoutSec` を使用します。空でないテキスト、推論、拒否内容、ツール更新、完了イベントは待機時間を更新しますが、キープアライブのコメント、ロールのみのイベント、使用量のみのイベントは更新しません。低速クライアントの読み取り待ちは計時を停止します。タイムアウト時は `upstream_stall_timeout` が返り、ストリーミングではエラーイベント、非ストリーミングでは HTTP 502 になります。終端結果より前のキャンセルは成功した部分回答ではなくキャンセルエラーになります。非ストリーミング Chat は LF、CRLF、複数行 data の SSE に対応します。
 
+<a id="remote-access"></a>
+
 ## リモートアクセス
 
-デフォルトの `127.0.0.1` バインドはループバックのみです。 `0.0.0.0` などの非ループバック アドレスには、`/api/*` とデータ プレーンの両方でトークン認証が必要です。開始する前にトークンをエクスポートします。
+既定の `127.0.0.1` はループバック専用です。`0.0.0.0` などへの非ループバックバインドでは、モデルリクエストに `config.apiKeys` のクライアントキーまたは共有データトークンが必要です。管理ルート `/api/*` はループバックでも独立した `OPENCODEX_ADMIN_AUTH_TOKEN` または生成済み管理トークンを使います。データ認証情報で管理アクセスはできません。管理トークンをモデルクライアントに渡さないでください。
 
 ```bash
 export OPENCODEX_API_AUTH_TOKEN="your-secret-token"
 ocx start
 ```
 
-プロキシは、この変数がないとリモート バインドを拒否します。バックグラウンド サービスの場合は、`ocx service install` の前にエクスポートして、launchd、systemd、またはタスク スケジューラがそれを受信できるようにします。クライアントは以下を送信する必要があります:
+例は環境トークンを使います。`OCX_API_TOKEN_FILE` または所有者専用の `service-api-token` にトークンがある場合や、有効なクライアントキーを設定済みの場合、変数のエクスポートは不要です。`ocx service install` は不足するトークンファイルを作成でき、この変数のエクスポートを必須にしません。モデルクライアントは次のヘッダーを送れます。
 
 ```text
 x-opencodex-api-key: your-secret-token
@@ -58,13 +60,13 @@ x-opencodex-api-key: your-secret-token
 
 |エンドポイント | `Authorization: Bearer` | `x-opencodex-api-key` | `x-api-key` |
 | --- | --- | --- | --- |
-| `/v1/responses` |受け入れられません | **必須** |受け入れられません |
-| `/v1/chat/completions` |受け入れられません | **必須** |受け入れられません |
+| `/v1/responses` | 受け入れられる | 受け入れられる | 受け入れられません |
+| `/v1/chat/completions` | 受け入れられる | 受け入れられる | 受け入れられません |
 | `/v1/messages` |受け入れられました |受け入れられました |受け入れられました |
 | `/v1/messages/count_tokens` |受け入れられました |受け入れられました |受け入れられました |
 | `/v1/models` |受け入れられました |受け入れられました |受け入れられました |
 
-応答とチャット完了では、Codex Direct パススルーの可能性のために `Authorization` を予約しているため、そこでは専用のアドミッション ヘッダーのみが受け入れられます。ダッシュボードで生成された `apiKeys` は、起動後に環境トークンを置き換える可能性があります。候補値は定数時間で比較されます。
+Responses と Chat Completions は、認識されたデータプレーン認証情報を `x-opencodex-api-key`、またはその専用ヘッダーがないか、前後の空白を除去すると空になる場合は `Authorization: Bearer` で受け付けます。前後の空白を除去して空でない専用ヘッダーがあれば、無効でも優先され、有効な bearer でその拒否を回避できません。無関係な bearer はプロキシへのアクセスを許可せず、この経路は `x-api-key` を受け付けません。生成された `apiKeys` と共有データトークンは定数時間で比較されます。管理認証情報はモデルアクセスを許可しません。
 
 Messages と `count_tokens` はルーティングクライアントとの互換性のために 3 つの admission 形式を引き続き受け入れます。
 ただし非ループバック bind のネイティブ Anthropic パススルーでは、プロキシ admission は
diff --git a/docs-site/src/content/docs/ja/reference/management-api.md b/docs-site/src/content/docs/ja/reference/management-api.md
index f71ccfb2d99..acecf682ced 100644
--- a/docs-site/src/content/docs/ja/reference/management-api.md
+++ b/docs-site/src/content/docs/ja/reference/management-api.md
@@ -7,6 +7,8 @@ Management API は opencodex のコントロール プレーンです。 `http:/
 
 対話型クライアントには [ウェブダッシュボード](/guides/web-dashboard/) を使用するか、自動化を構築する場合はこのリファレンスを使用します。永続値は最終的に [構成](/reference/configuration/) に従います。
 
+<a id="authentication-model"></a>
+
 ## 認証モデル
 
 Management API には、データプレーン API キーとは独立した独自の管理者資格情報があります。起動時に、opencodex は次の順序で解決します。
diff --git a/docs-site/src/content/docs/ko/getting-started/for-agents.md b/docs-site/src/content/docs/ko/getting-started/for-agents.md
index b79ffdd7f06..eabf88a00fa 100644
--- a/docs-site/src/content/docs/ko/getting-started/for-agents.md
+++ b/docs-site/src/content/docs/ko/getting-started/for-agents.md
@@ -14,7 +14,11 @@ npm install -g --allow-scripts=bun @bitkyc08/opencodex
 ocx --version
 ```
 
-프록시를 실행하는 방법은 하나를 선택합니다:
+설정에서 선택한 포트를 사용하도록 프록시를 시작하기 전에 대화형 터미널에서 `ocx init`을 실행하세요:
+
+```bash
+ocx init
+```
 
 ```bash
 # Foreground: blocks this terminal until stopped.
@@ -24,12 +28,6 @@ ocx start
 ocx service
 ```
 
-대화형 터미널에서 `ocx init`를 실행합니다. `ocx start`가 포그라운드를 차지하고 있으면 두 번째 터미널을 사용합니다:
-
-```bash
-ocx init
-```
-
 이 마법사는 `$OPENCODEX_HOME/config.json`를 작성합니다(보통 `~/.opencodex/config.json`). 또한 프록시 주소를 Codex의 `config.toml`에 주입하고, 선택적 Codex 자동 시작 shim을 설치할 수 있습니다. `ocx init`는 프록시를 절대 시작하지 않습니다. 완전히 비대화형으로 설정하려면 아래처럼 마법사를 진행하지 말고 `ocx provider add`로 공급자를 구성하세요.
 
 :::caution[GitHub 별표 동의]
@@ -56,17 +54,19 @@ ocx health --json
 
 ```bash
 ocx provider add anthropic-apikey \
-  --api-key "$ANTHROPIC_API_KEY" \
+  --api-key '${ANTHROPIC_API_KEY}' \
   --set-default
 ```
 
+작은따옴표를 유지하세요. 참조를 그대로 전달하므로 비밀 값이 프로세스 인수나 설정 파일에 들어가지 않습니다. `ANTHROPIC_API_KEY`를 프록시 시작 전에 시작 환경에 설정하고, 모델 동기화처럼 자격 증명을 해석하는 CLI 프로세스에도 제공하세요. 나중에 다른 터미널에서 export해도 실행 중인 프록시는 갱신되지 않습니다. 백그라운드 서비스는 시작 환경을 설정한 뒤 재시작하세요. 서비스 설치만으로 터미널의 임의 공급자 변수가 보존되지는 않습니다.
+
 `ocx provider add`는 로컬 설정을 기록합니다. 라이브 프록시가 이미 실행 중이고 모델을 즉시 Codex와 동기화하려면 `--sync`를 추가하세요. 그렇지 않으면 나중에 `ocx sync`를 실행하면 됩니다. 레지스트리에 없는 커스텀 공급자는 `--adapter`와 `--base-url`이 모두 필요합니다.
 
 모든 대상 공급자가 설정되고 프록시가 실행되면 failover 콤보를 만듭니다:
 
 ```bash
 ocx combo set main \
-  --targets anthropic/claude-opus-4-8,openai/gpt-5.6-sol \
+  --targets anthropic-apikey/claude-opus-4-8,openai/gpt-5.6-sol \
   --strategy failover
 ```
 
@@ -74,11 +74,11 @@ ocx combo set main \
 
 ## 원격 및 LAN 바인드
 
-기본 루프백 바인드에는 API 토큰이 필요하지 않습니다. `0.0.0.0` 같은 비루프백 바인드는 `OPENCODEX_API_AUTH_TOKEN`이 필요하며, 이 토큰이 없으면 프록시가 시작을 거부합니다. `ocx start`를 실행하기 전에, 또는 `ocx service install`을 실행하기 전에 변수를 설정해야 서비스가 이를 전달받습니다:
+일반적인 루프백 모델 경로에는 데이터 토큰이 필요하지 않습니다. `0.0.0.0` 같은 비루프백 바인드에는 `config.apiKeys`에 설정한 클라이언트 키나 `OPENCODEX_API_AUTH_TOKEN`, `OCX_API_TOKEN_FILE`, 소유자만 읽을 수 있는 `service-api-token` 파일에서 확인한 공유 토큰이 필요합니다. 파일이 없으면 `ocx service install`이 생성할 수 있습니다. 환경 변수로 토큰을 제공한다면 `ocx start` 또는 `ocx service install` 전에 설정하세요:
 
 ```bash
 export OPENCODEX_API_AUTH_TOKEN="your-secret-token"
 ocx service install
 ```
 
-그다음 클라이언트는 관리 요청과 모델 요청을 인증해야 합니다. 로컬 머신 밖으로 opencodex를 노출하기 전에 원격 액세스 규칙은 [Configuration](/reference/configuration/)에서 확인하세요.
+모델 요청에는 데이터 플레인 인증을 사용합니다. 관리에는 별도 자격 증명인 `OPENCODEX_ADMIN_AUTH_TOKEN` 또는 보호된 파일에 생성된 관리자 토큰을 사용합니다. 데이터 토큰은 관리 접근 권한을 부여하지 않습니다. 대시보드는 [관리 API](/ko/reference/management-api/#authentication-model)의 세션 및 접근 규칙을 따릅니다. 관리자 토큰을 모델 클라이언트에 제공하지 마세요. 외부에 공개하기 전에 [원격 접근](/ko/reference/configuration/server/#remote-access)을 확인하세요.
diff --git a/docs-site/src/content/docs/ko/getting-started/quickstart.md b/docs-site/src/content/docs/ko/getting-started/quickstart.md
index bceda554cfe..e91d5865ad2 100644
--- a/docs-site/src/content/docs/ko/getting-started/quickstart.md
+++ b/docs-site/src/content/docs/ko/getting-started/quickstart.md
@@ -33,18 +33,27 @@ ocx init
 
 ## 2. 프록시 시작
 
+다음 두 방법 중 하나만 실행합니다. 프록시는 포그라운드에서 실행됩니다.
+
 ```bash
 ocx start            # defaults to port 10100
+```
+
+다른 포트를 사용하려면 다음 명령을 대신 실행합니다.
+
+```bash
 ocx start --port 8080
 ```
 
+이 터미널을 열어 두세요. 뒤에 나오는 상태 확인 및 대시보드 명령은 같은 `OPENCODEX_HOME`을 사용하는 두 번째 터미널에서 실행하세요.
+
 시작하면 opencodex는:
 
 - PID를 `~/.opencodex/ocx.pid`에 기록하고 중복 시작을 거부하며,
 - 프로바이더가 지원하는 경우 실시간 모델을 찾아 네이티브와 라우팅 항목을 **Codex 모델 카탈로그에 동기화**하고,
 - `http://localhost:<port>/v1`에서 수신 대기합니다.
 
-요청한 포트가 이미 사용 중이면 `ocx start`는 실행을 멈추고 무엇이 포트를 점유하고 있는지 알려 줍니다. opencodex가 응답하면 먼저 `ocx stop`을 실행하고, 빈 포트에서 시작하려면 `ocx start --port <port>`를 사용하세요. 이제 다른 포트로 자동 이동하지 않습니다. 이전 동작은 프록시 두 개를 동시에 실행한 채 Codex가 나중에 시작한 프록시를 가리키게 했습니다.
+동일한 `OPENCODEX_HOME`을 사용하는 opencodex가 실행 중이면 빈 포트라도 두 번째로 시작할 수 없습니다. 먼저 해당 인스턴스를 `ocx stop`으로 중지하거나 다른 `OPENCODEX_HOME`을 선택하세요. 형제 인스턴스는 자신의 포트에서 직접 요청을 처리하지만 Codex, Grok, Claude의 공유 라우팅은 변경하지 않습니다. 무관한 프로세스가 포트를 사용하면 `ocx start`가 알립니다. `ocx start --port <port>`로 빈 포트를 지정하세요. 포트는 자동으로 바뀌지 않습니다.
 
 확인:
 
diff --git a/docs-site/src/content/docs/ko/guides/codex-app-models.md b/docs-site/src/content/docs/ko/guides/codex-app-models.md
index f06017e0268..0c36e1478f7 100644
--- a/docs-site/src/content/docs/ko/guides/codex-app-models.md
+++ b/docs-site/src/content/docs/ko/guides/codex-app-models.md
@@ -266,9 +266,7 @@ Ultra Fast는 사용량·비용이 더 크며 Codex 자체 기능 제한도 계
 Codex는 선택기에 보이는 카탈로그 항목을 `priority` 오름차순으로 정렬한 뒤 처음 다섯 개를
 `spawn_agent` model override로 노출합니다. 대시보드 Subagents 페이지에서는 bare native id 또는
 routed `provider/model` id를 최대 다섯 개 선택하고 저장할 수 있습니다. 수동으로 설정한
-`subagentModels`는 account-qualified `<selector>/<native-openai-model>` id도 지원하지만,
-대시보드는 이러한 exact id를 제공하지 않으며 페이지를 저장하면 목록이 대시보드에 표시되는 선택 항목으로
-교체됩니다. opencodex는 선택한 순서대로 낮은 카탈로그 priority를 부여합니다. 계정 한정 선택기 행이
+`subagentModels`는 account-qualified `<selector>/<native-openai-model>` id도 지원합니다. 대시보드는 현재 카탈로그에 없는 모델을 포함하여, 저장된 정확한 id를 목록을 저장할 때도 유지합니다. opencodex는 선택한 순서대로 낮은 카탈로그 priority를 부여합니다. 계정 한정 선택기 행이
 활성화되어 있으면 bare native 선택은 selector-qualified 그룹으로 확장됩니다. 다른 모델도 정확한 id로
 직접 호출할 수 있습니다.
 
diff --git a/docs-site/src/content/docs/ko/guides/grok-build.md b/docs-site/src/content/docs/ko/guides/grok-build.md
index 26ab7598158..6311e9097b2 100644
--- a/docs-site/src/content/docs/ko/guides/grok-build.md
+++ b/docs-site/src/content/docs/ko/guides/grok-build.md
@@ -97,11 +97,11 @@ model = "anthropic/claude-opus-4-8"
 model_provider = "opencodex"
 ```
 
-네트워크에서 닿을 수 있는 프록시라면 `base_url`을 `grok`가 실제로 연결할 수 있는 주소로 두고 승인 토큰을 사용합니다:
+토큰을 제공하기 전에 TLS 프런트엔드를 구성하고 HTTPS URL을 사용하거나, 로컬 터널의 루프백 주소를 사용하세요. Grok은 `api_key` 값을 `~/.grok/config.toml`에 그대로 저장하므로 접근 권한을 제한하고 버전 관리와 공유 백업에서 제외하세요.
 
 ```toml
 [model_providers.opencodex]
-base_url = "http://192.168.1.10:10100/v1"   # the reachable host, not 127.0.0.1
+base_url = "https://proxy.example.com/v1"   # configured TLS frontend
 api_backend = "responses"
 api_key = "your-OPENCODEX_API_AUTH_TOKEN"
 
diff --git a/docs-site/src/content/docs/ko/guides/image-bridge.md b/docs-site/src/content/docs/ko/guides/image-bridge.md
index 7b520a8e78c..52a985f58cc 100644
--- a/docs-site/src/content/docs/ko/guides/image-bridge.md
+++ b/docs-site/src/content/docs/ko/guides/image-bridge.md
@@ -10,7 +10,7 @@ Codex를 Claude, Gemini, Grok 같은 OpenAI가 아닌 모델로 라우팅하면
 ## 사전 조건
 
 - 구성에서 `images.bridgeEnabled: true`로 설정해 브리지를 켭니다. 예상치 못한 xAI 요금을 피하려고 기본값은 꺼져 있습니다. 아래 [Configuration](#설정)을 참고합니다.
-- API 키가 있는 `xai` provider 항목이 필요합니다. 브리지는 처리를 레지스트리의 xAI Images endpoint (`https://api.x.ai/v1`)에 고정하며, 이미지 호출에서는 설정된 `baseUrl` override를 무시합니다. OAuth / `ocx login xai`만으로는 이 sidecar 루프가 켜지지 않습니다. 같은 `bridgeEnabled` 플래그는 별도의 Codex `/v1/images` relay를 켜서, 내장 `image_gen` 클라이언트가 Grok CLI grant로 Imagine을 호출할 수 있게 합니다. 그 grant(또는 xAI API key)가 없으면 `/v1/images`는 ChatGPT로 넘어가지 않고 오류를 반환합니다. 이 relay가 경로를 맡는 건 `images.bridgeEnabled`가 `true`이고 `images.provider`를 비워둔 경우뿐입니다. `images.provider`를 지정하면 `/v1/images`는 그 provider가 담당하고, 그쪽 검증 오류는 xAI로 재시도하지 않고 그대로 반환합니다. [Built-in image generation](/guides/codex-integration/#built-in-image-generation-image_gen)을 참고하세요.
+- API 키가 있는 `xai` provider 항목이 필요합니다. 브리지는 처리를 레지스트리의 xAI Images endpoint (`https://api.x.ai/v1`)에 고정하며, 이미지 호출에서는 설정된 `baseUrl` override를 무시합니다. OAuth / `ocx login xai`만으로는 이 sidecar 루프가 켜지지 않습니다. 같은 `bridgeEnabled` 플래그는 별도의 Codex `/v1/images` relay를 켜서, 내장 `image_gen` 클라이언트가 Grok CLI grant로 Imagine을 호출할 수 있게 합니다. xAI provider가 있지만 grant와 API key가 모두 없으면 `/v1/images`는 ChatGPT로 넘어가지 않고 오류를 반환합니다. xAI provider 자체가 없으면 relay는 요청을 처리하지 않으며, 일반 선택 과정에서 설정된 ChatGPT 이미지 provider를 사용할 수 있습니다. 이 relay가 경로를 맡는 건 `images.bridgeEnabled`가 `true`이고 `images.provider`를 비워둔 경우뿐입니다. `images.provider`를 지정하면 `/v1/images`는 그 provider가 담당하고, 그쪽 검증 오류는 xAI로 재시도하지 않고 그대로 반환합니다. [Built-in image generation](/guides/codex-integration/#built-in-image-generation-image_gen)을 참고하세요.
 
   ```json
   {
diff --git a/docs-site/src/content/docs/ko/guides/minimax.md b/docs-site/src/content/docs/ko/guides/minimax.md
index 78acfcf5e7b..55c795542d8 100644
--- a/docs-site/src/content/docs/ko/guides/minimax.md
+++ b/docs-site/src/content/docs/ko/guides/minimax.md
@@ -14,6 +14,11 @@ MiniMax는 서로 다른 두 명령줄 제품을 제공합니다. opencodex는 
 
 ```bash
 ocx start
+```
+
+이 터미널에서 프록시를 계속 실행하세요. 다른 터미널에서 통합을 활성화하고 MiniMax Code를 시작하세요:
+
+```bash
 ocx integration client enable --client mcode
 ocx mcode
 ```
diff --git a/docs-site/src/content/docs/ko/guides/model-routing.md b/docs-site/src/content/docs/ko/guides/model-routing.md
index d20f8320c7d..e63c7c1d1aa 100644
--- a/docs-site/src/content/docs/ko/guides/model-routing.md
+++ b/docs-site/src/content/docs/ko/guides/model-routing.md
@@ -56,8 +56,8 @@ fallback하지 않습니다.
    | `claude-`, `claude-sonnet-`, `claude-opus-`, `claude-haiku-` | `anthropic` |
    | `llama-`, `mixtral-`, `gemma-` | `groq` |
 
-   이 검사는 이름만 봅니다. `defaultModel` / `models[]` 검사와 달리, 현재는 이름이 일치한 프로바이더의
-   `disabled` 값이 true여도 건너뛰지 않습니다.
+   이 검사는 이름만 봅니다. `defaultModel` / `models[]` 검사와 마찬가지로, 이름이 일치한 프로바이더의
+   `disabled` 값이 true이면 건너뜁니다.
 
 7. **프로바이더의 `models[]`** — 프리픽스 규칙과 일치하지 않고 활성 프로바이더의 `models[]`에 id가
    있으면 그 프로바이더를 사용합니다. 규칙 4가 bare `gpt-*` id를 다른 provider의 `models[]`가
diff --git a/docs-site/src/content/docs/ko/guides/opencode.md b/docs-site/src/content/docs/ko/guides/opencode.md
index 0d2f11cd119..4c9b5f2168a 100644
--- a/docs-site/src/content/docs/ko/guides/opencode.md
+++ b/docs-site/src/content/docs/ko/guides/opencode.md
@@ -107,9 +107,11 @@ export OPENCODEX_OPENCODE_API_KEY=<your key>
 
 루프백이 아닌 예시:
 
+원격 클라이언트에서 수동으로 설정하는 예시입니다. 먼저 TLS 프런트엔드를 구성하고 해당 HTTPS URL을 사용하세요. OpenCodex는 TLS를 종료하지 않으며 `ocx opencode`가 이 URL을 자동으로 찾지도 않습니다. LAN에서도 평문 HTTP는 전송 중 자격 증명을 노출합니다. 대신 프록시를 루프백에 바인딩하고 로컬 SSH 터널을 사용할 수 있습니다. [데이터 리스너 TLS](/ko/guides/remote-hub/#giving-the-data-listener-tls)를 참고하세요.
+
 ```json
 "options": {
-  "baseURL": "http://192.168.1.10:10100/v1",
+  "baseURL": "https://proxy.example.com/v1",
   "headers": {
     "x-opencodex-api-key": "{env:OPENCODEX_OPENCODE_API_KEY}"
   }
diff --git a/docs-site/src/content/docs/ko/guides/pi.md b/docs-site/src/content/docs/ko/guides/pi.md
index 254acf0c504..d973d6e7aaf 100644
--- a/docs-site/src/content/docs/ko/guides/pi.md
+++ b/docs-site/src/content/docs/ko/guides/pi.md
@@ -3,10 +3,7 @@ title: Pi
 description: Pi에서 라우팅된 모델을 그대로 쓸 수 있습니다. `ocx export`가 Pi의 `models.json`에 맞는 커스텀 provider 블록을 내보내고, 실행 중인 프록시에 연결합니다.
 ---
 
-Pi는 provider를 환경 변수 대신 하나의 전역 JSON 파일에서 읽기 때문에,
-opencodex가 Pi를 직접 실행하지 않습니다. 대신 `ocx export`가 `opencodex` provider 블록,
-즉 base URL, 모델 목록, 그리고 Pi가 치환하는 환경 변수 참조를 직렬화해서 사용자가
-자신의 설정에 병합하도록 합니다.
+Pi는 하나의 전역 JSON 파일에서 공급자를 읽습니다. opencodex가 Pi를 실행하는 대신 `ocx export`가 기본 URL, 모델 목록, 비밀이 아닌 로컬 키 자리표시자가 담긴 `opencodex` 공급자 블록을 출력합니다. 이 블록을 기존 설정에 병합하세요.
 
 ## 빠른 시작
 
@@ -14,11 +11,15 @@ opencodex가 Pi를 직접 실행하지 않습니다. 대신 `ocx export`가 `ope
 
 ```bash
 ocx start
+```
+
+이 프로세스를 실행한 상태로 두고, 두 번째 터미널에서 설정을 출력하세요.
+
+```bash
 ocx export --client pi
 ```
 
-출력은 JSON으로 시작하고, 이어서 대상 경로, 병합 경고, 환경 변수 export 줄, 그리고
-공식 context limit이 있는 모델 수를 보여줍니다.
+출력에는 JSON 다음으로 대상 경로, 병합 경고, 루프백 사용 안내와 확인된 컨텍스트 한도가 있는 모델 수가 나옵니다. 이 내보내기는 인증이 없는 루프백 프록시만 지원하며 원격 접근 인증을 설정하지 않습니다.
 
 ```json
 {
@@ -26,7 +27,7 @@ ocx export --client pi
     "opencodex": {
       "baseUrl": "http://127.0.0.1:10100/v1",
       "api": "openai-completions",
-      "apiKey": "$OPENCODEX_API_KEY",
+      "apiKey": "opencodex-loopback",
       "compat": {
         "sendSessionAffinityHeaders": true,
         "supportsDeveloperRole": false
@@ -84,28 +85,7 @@ ocx export --client pi --json > ~/opencodex-pi-models.json   # or redirect the b
 
 ## 인증 키
 
-여기서는 서로 헷갈리기 쉬운 키가 두 개 있고, 이 파일에 등장하는 것은 첫 번째뿐입니다.
-
-| 키 | 무엇인지 | 어디에 있는지 |
-| --- | --- | --- |
-| Proxy admission key | opencodex의 자체 인증 정보이며, 대시보드의 **API** 탭에서 생성됩니다 | `apiKey`로 `$OPENCODEX_API_KEY`를 참조하며, 값은 환경 변수에 둡니다 |
-| Provider key | Anthropic / OpenAI / OpenRouter 키입니다 | opencodex의 자체 config에 있으며, [Providers](/guides/providers/)마다 따로 둡니다 |
-
-내보낸 config에는 비밀값이 아니라 참조만 들어갑니다. Pi는 `$NAME` 형태를 그대로
-치환하므로 변수는 다음과 같습니다.
-
-```bash
-export OPENCODEX_API_KEY=<your key>
-```
-
-이 이름은 Pi 전용입니다. opencode는 다른 변수를 씁니다
-(`OPENCODEX_OPENCODE_API_KEY`, `{env:…}` 형식) - 자세한 내용은 [opencode 가이드](/guides/opencode/)를 보세요.
-
-**루프백 프록시는 키가 전혀 필요 없습니다.** opencodex는 기본적으로 `127.0.0.1`에
-바인드하고 그곳에서는 아무 것도 인증하지 않으므로, `$OPENCODEX_API_KEY` 참조는
-실제로는 비어 있어도 됩니다. 이 값은 `hostname`이 루프백 바깥으로 설정될 때만
-의미가 있으며, 그 경우에는 프록시가 토큰 없이 시작하지 않습니다. 자세한 내용은
-[Remote access](/ko/reference/configuration/server/#remote-access)를 보세요.
+내보낸 `apiKey`는 비밀이 아닌 자리표시자 `opencodex-loopback`입니다. 키 환경 변수를 내보낼 필요가 없습니다. 내보내기는 인증이 없는 루프백 프록시만 허용하며 원격 또는 토큰으로 보호된 프록시는 거부합니다. 공급자 자격 증명은 [공급자](/ko/guides/providers/)에 설명된 opencodex 설정에 남습니다. 이 Pi 블록에 상위 공급자의 키를 넣지 마세요. 원격 접근에는 프록시 접근 인증을 지원하는 통합을 사용하세요. 자리표시자를 바꿔도 Pi 원격 내보내기가 활성화되지 않습니다.
 
 ## 모델 메타데이터
 
@@ -115,10 +95,11 @@ export OPENCODEX_API_KEY=<your key>
 
 출력 한도는 카탈로그 또는 생성된 메타데이터의 알려진 모델 한도를 사용합니다. 알 수 없는 경우에만 `32000`을 사용합니다. 출력 한도는 항상 context window 이하로 제한되며, `32000`보다 작은 알려진 한도도 유지됩니다.
 
-의도적으로 빠진 필드도 두 개 있습니다. `cost`는 네 개의 가격 필드가 모두 있어야
-하는데, opencodex는 라우팅된 모델의 가격 데이터를 갖고 있지 않습니다. 0을 넣으면
-모든 모델이 무료라고 주장하는 꼴이 됩니다. `reasoning`은 Pi에서는 boolean이지만
-카탈로그는 effort 단계 체계를 들고 있으므로, 둘을 1:1로 맞추는 것은 추측입니다.
+`cost`는 의도적으로 생략합니다. 네 가격 필드가 모두 필요하지만 opencodex에는 라우팅 모델의 가격 데이터가 없으므로, 0을 출력하면 모든 모델이 무료라는 잘못된 의미가 됩니다.
+
+카탈로그의 effort 단계가 **비어 있지 않을 때** `"reasoning": true`를 출력합니다. 단계가 없거나 명시적으로 비어 있으면 출력하지 않습니다. `thinkingLevelMap`은 대응 대상이 없는 Pi 단계를 `null`로 숨겨 선언되지 않은 값을 제안하거나 보내지 않게 합니다. `max` 없이 `ultra`만 선언되면 Pi의 `max`를 `ultra`에 매핑합니다. 다른 매핑은 Pi 문서에 따라 `thinkingLevelMap`을 직접 편집하세요.
+
+`reasoning`은 카탈로그에서 파생된 Pi UI 메타데이터이며 공급자의 네이티브 지원 증거가 아닙니다. 실제 `reasoning_effort`는 어댑터와 모델에 따라 전달, 변환, 제한, 에뮬레이션되거나 생략됩니다(예: `noReasoningModels`). 이 불리언은 Pi가 제어 항목을 제공할지만 결정합니다.
 
 ## 스키마 상태
 
diff --git a/docs-site/src/content/docs/ko/guides/remote-hub.md b/docs-site/src/content/docs/ko/guides/remote-hub.md
index 204cefb5ef1..ae1cc5d462d 100644
--- a/docs-site/src/content/docs/ko/guides/remote-hub.md
+++ b/docs-site/src/content/docs/ko/guides/remote-hub.md
@@ -31,7 +31,13 @@ Codex와 Claude 요청은 클라이언트에서 허브의 데이터 리스너로
 임시 권한은 stdin으로만 전달하며 설정 파일이나 토큰 파일에 저장되지 않습니다.
 
 ```bash
-ocx connect https://hub-name.tailnet-name.ts.net --pairing-code-stdin
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the one-time code without echoing it or putting it in shell history.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+  --management-url https://hub-name.tailnet-name.ts.net \
+  --pairing-code-stdin
+unset pairing_code
 ocx connect status
 ocx sync
 ```
@@ -170,6 +176,8 @@ tailscale serve status
 
 관리 포트는 `127.0.0.1:10101`에서만 보여야 합니다. `hub.managementPublicOrigin`은 Serve가 표시한 정확한 HTTPS Origin으로 설정하세요. 직접 TLS 프록시를 운영한다면 `tailscale cert hub-name.tailnet-name.ts.net`으로 ts.net 전체 FQDN 인증서만 발급하고 `127.0.0.1:10101`로만 프록시하세요. 임의의 `Tailscale-User-*` 헤더를 만들지 말고, 신뢰할 수 있는 Tailscale 신원이 없으면 일회용 pairing을 사용하세요.
 
+<a id="giving-the-data-listener-tls"></a>
+
 ### 데이터 리스너에 TLS 붙이기
 
 위의 Serve 매핑은 **관리** 인그레스만 공개합니다. 그 인그레스는 `/v1/*`, `/healthz`, `/readyz`를 제공하지 않으므로 그것만으로는 원격 클라이언트에게 쓸 수 있는 데이터 플레인이 생기지 않습니다. opencodex는 자체적으로 TLS를 종료하지 않습니다. 리스너는 평문 HTTP이고 HTTPS는 항상 운영자가 소유한 프런트엔드입니다.
@@ -192,10 +200,14 @@ Serve가 허용하는 HTTPS 포트는 제한적입니다. 포트가 실제로 
 그다음 두 Origin을 따로 지정해 연결합니다. 위치 인자 URL이 **데이터** Origin이고(`/readyz`와 `/v1/catalog`를 가져오는 곳), `--management-url`이 pairing과 키 발급에 쓰는 대시보드 Origin입니다. 두 Origin이 같은 포트일 필요는 없습니다.
 
 ```bash
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the one-time code without echoing it or putting it in shell history.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
 # `ocx hub invite`가 코드까지 채워서 출력해 주는 바로 그 줄입니다.
-echo '<pairing-code>' | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+printf '%s\n' "$pairing_code" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
   --management-url https://hub-name.tailnet-name.ts.net \
   --pairing-code-stdin
+unset pairing_code
 ```
 
 `--management-url`을 생략하면 `/readyz` 응답이 보고하는 `hub.managementPublicOrigin`을 씁니다. 두 Origin이 다르면 명시하는 편이 분명합니다. 두 Origin을 허브에 `hub.dataPublicOrigin`과 `hub.managementPublicOrigin`으로 기록해 두면 `ocx hub invite`가 대신 출력해 줍니다.
@@ -218,9 +230,12 @@ ocx hub invite
 
 일회용 단기 pairing 코드를 발급하고, 다른 컴퓨터에서 실행할 명령을 출력합니다.
 
-```text
-# Run on the other machine:
-echo '<code>' | ocx connect https://hub-name.tailnet-name.ts.net:8443 --management-url https://hub-name.tailnet-name.ts.net --pairing-code-stdin
+```bash
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash, on the other machine:
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect https://hub-name.tailnet-name.ts.net:8443 --management-url https://hub-name.tailnet-name.ts.net --pairing-code-stdin
+unset pairing_code
 ```
 
 데이터 Origin은 `--data-url` → `hub.dataPublicOrigin` → 바인드 주소 순서로 결정됩니다. 마지막 대체는 바인드가 다른 컴퓨터가 실제로 호출할 수 있는 주소일 때만 쓸 수 있습니다. 루프백이나 와일드카드 바인드에서는 `http://localhost:<port>`가 되어 상대 컴퓨터가 자기 자신을 호출하게 되고 일회용 코드가 헛되게 소모되므로, `invite`는 대신 거부하고 `ocx config set hub.dataPublicOrigin` 줄(그리고 이번 초대에만 적용하는 `--data-url` 형태)을 출력합니다. 명시한 `--data-url`이나 `hub.dataPublicOrigin`은 되묻지 않습니다. SSH 터널에서는 루프백 데이터 Origin이 정당합니다.
@@ -284,9 +299,16 @@ ocx config set oauthOpenBrowser false
 ## 키 교체와 연결 해제
 
 ```bash
-ocx connect rotate --pairing-code-stdin
-# HTTPS에서만:
-ocx connect rotate --admin-token-stdin
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: choose one authority source.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect rotate --pairing-code-stdin
+unset pairing_code
+
+# Alternatively, only over HTTPS, use the management admin token:
+read -r -s -p 'Admin token: ' admin_token; printf '\n'
+printf '%s\n' "$admin_token" | ocx connect rotate --admin-token-stdin
+unset admin_token
 ```
 
 기존 키와 새 키는 같은 `apiKeyId`로 최대 10분 동안 함께 유효합니다. 클라이언트는 기존 키를 `service-api-token.prev`에 백업하고, 새 키를 원자적으로 적용해 `/v1/catalog`로 확인한 다음 확정합니다. 결과가 불확실하면 임시 권한을 다시 넣어 같은 명령을 실행하세요. 현재 파일과 `.prev`를 모두 확인한 뒤 확정하거나 복원합니다.
diff --git a/docs-site/src/content/docs/ko/guides/remote-workspace.md b/docs-site/src/content/docs/ko/guides/remote-workspace.md
index 1dcdf4564ad..eab2511c43c 100644
--- a/docs-site/src/content/docs/ko/guides/remote-workspace.md
+++ b/docs-site/src/content/docs/ko/guides/remote-workspace.md
@@ -23,9 +23,16 @@ Executor에는 opencodex만 필요합니다. Codex, Claude Code, Pi, ChatGPT 로
 
 컴퓨터 1이 모든 코딩 에이전트 로그인과 모델 세션을 소유합니다. 사용할 에이전트를 이 컴퓨터에 설치하고 로그인한 뒤 opencodex를 Hub로 실행하세요.
 
+이 터미널에서 Hub를 포그라운드로 계속 실행합니다.
+
 ```bash
 ocx config set runtimeRole hub
 OCX_REMOTE_WORKSPACE_ENABLED=1 ocx start
+```
+
+Hub를 실행한 상태에서 다른 터미널을 열고 대시보드를 시작합니다.
+
+```bash
 ocx gui
 ```
 
@@ -45,27 +52,58 @@ Codex 원격 작업 공간은 현재 App Server 권한 프로필을 사용합니
 같은 작업을 수동으로 하려면 다음을 실행하세요.
 
 ```bash
+# Bash only: if using zsh, run bash first in this terminal.
 cd /path/to/project
-printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
-  --pairing-code-stdin --root "$PWD"
-ocx remote-workspace agent
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" || pairing_status=$?
+  unset pairing_code
+  if [ "$pairing_status" -eq 0 ]; then ocx remote-workspace agent; fi
+  unset pairing_status
+else
+  unset pairing_code
+fi
 ```
 
 Windows PowerShell에서는 대시보드에 표시되는 명령을 사용하세요. 수동 명령은 다음과 같습니다.
 
 ```powershell
-$pairingCode = 'ONE-TIME-CODE'
-$pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
-  --pairing-code-stdin --root (Get-Location).Path
-if ($LASTEXITCODE -eq 0) { ocx remote-workspace agent }
+$pairingSecret = Read-Host 'Pairing code' -AsSecureString
+$pairingBuffer = [IntPtr]::Zero
+$pairingExitCode = 1
+try {
+  $pairingBuffer = [Runtime.InteropServices.Marshal]::SecureStringToBSTR($pairingSecret)
+  $pairingCode = [Runtime.InteropServices.Marshal]::PtrToStringBSTR($pairingBuffer)
+  $pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
+    --pairing-code-stdin --root (Get-Location).Path
+  $pairingExitCode = $LASTEXITCODE
+} finally {
+  if ($pairingBuffer -ne [IntPtr]::Zero) {
+    [Runtime.InteropServices.Marshal]::ZeroFreeBSTR($pairingBuffer)
+  }
+  $pairingSecret.Dispose()
+  Remove-Variable pairingCode, pairingSecret, pairingBuffer -ErrorAction SilentlyContinue
+}
+if ($pairingExitCode -eq 0) { ocx remote-workspace agent }
+Remove-Variable pairingExitCode
 ```
 
 현재 OCX Bun 실행 파일은 Linux 샌드박스에 읽기 전용 파일 하나로 자동 추가됩니다. 프로젝트에 시스템 경로 밖에 사용자 설치 도구 체인이 필요하다면 홈 디렉터리 전체를 노출하지 말고 명시적으로 페어링하세요.
 
 ```bash
-printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
-  --pairing-code-stdin --root "$PWD" \
-  --toolchain-root "$HOME/.nvm/versions/node/v24/bin"
+# Bash only: if using zsh, run bash first in this terminal.
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" \
+    --toolchain-root "$HOME/.nvm/versions/node/v24/bin" || pairing_status=$?
+  unset pairing_code pairing_status
+else
+  unset pairing_code
+fi
 ```
 
 네이티브 헬퍼 소스는 검토할 수 있도록 패키지에 포함됩니다. 빌드해도 이번 변경에서 Windows나 macOS 명령이 활성화되지는 않습니다. `--executor-helper`는 검토된 헬퍼를 선택하는 옵션입니다. 바이너리가 존재하거나 경로가 설정되어 있다는 사실만으로 명령 지원이 입증되지는 않습니다.
diff --git a/docs-site/src/content/docs/ko/guides/subagent-v1-default.md b/docs-site/src/content/docs/ko/guides/subagent-v1-default.md
index dbf8fee9103..61343fbe441 100644
--- a/docs-site/src/content/docs/ko/guides/subagent-v1-default.md
+++ b/docs-site/src/content/docs/ko/guides/subagent-v1-default.md
@@ -28,7 +28,9 @@ HTTP 400을 반환하며 암호문은 응답에 포함하지 않습니다. 읽
 
 v1에서는 부모가 자식 작업을 평문으로 내보냅니다. opencodex가 이를 읽고 라우팅하므로 자식이 실행할 수 있는 작업을 받습니다.
 
-v2에서는 부모가 ChatGPT 백엔드에서 만든 `encrypted_content`로 작업을 내보냅니다. 키는 그 백엔드에만 있습니다. opencodex에는 키가 없으므로 프록시가 복호화하거나 다시 쓸 수 없습니다. 플래그 뒤에 숨은 평문이 아니라 실제 암호문입니다. 따라서 설정 오류가 아니라 구조적인 문제이며 프록시 설정으로 해결할 수 없습니다.
+v2에서는 부모가 ChatGPT 백엔드에서 만든 `encrypted_content`로 작업을 내보냅니다. 키는 그 백엔드에만 있습니다. opencodex에는 키가 없으므로 프록시가 복호화하거나 다시 쓸 수 없습니다. 플래그 뒤에 숨은 평문이 아니라 실제 암호문입니다. 따라서 설정 오류가 아니라 구조적인 문제이며 프록시 설정으로 로컬 복호화를 활성화할 수 없습니다.
+
+프록시 설정으로 로컬 복호화를 활성화할 수는 없습니다. 실험적인 `agentTaskRecovery`는 적격 작업을 ChatGPT 백엔드에 요청해 복구할 수 있지만 로컬에서 암호문을 해독하지는 않습니다. 위의 승인, 적격성 및 실패 제한은 그대로 적용됩니다.
 
 영향받지 않는 연결 방식은 세 가지입니다. 어떤 경계에서 실패하는지 보면 이유가 드러납니다.
 
diff --git a/docs-site/src/content/docs/ko/guides/video-bridge.md b/docs-site/src/content/docs/ko/guides/video-bridge.md
index 325837848b8..b16113d1d09 100644
--- a/docs-site/src/content/docs/ko/guides/video-bridge.md
+++ b/docs-site/src/content/docs/ko/guides/video-bridge.md
@@ -19,14 +19,12 @@ Video Bridge는 opencodex가 라우팅한 OpenAI가 아닌 모델로 xAI의 Grok
 > ```json
 > {
 >   "providers": {
->     "xai": { "adapter": "openai-chat", "apiKey": "xai-…", "authMode": "key" }
+>     "xai": { "adapter": "openai-chat", "apiKey": "${XAI_API_KEY}", "authMode": "key" }
 >   }
 > }
 > ```
 >
-> `ocx login xai`(OAuth)로 연결했다면 provider는 계속 `authMode: "oauth"`
-> 상태이며, 브리지는 아무 경고 없이 활성화되지 않습니다. 환경 변수로 `XAI_API_KEY`를
-> 설정하거나, 위처럼 키를 직접 넣으십시오.
+> `XAI_API_KEY`는 프록시 시작 환경에 설정하고 `${XAI_API_KEY}`와 `authMode: "key"`를 유지하세요. 다른 터미널의 export는 실행 중인 프록시를 바꾸지 않습니다. 소유한 Desktop, 서비스 또는 전경 터미널을 통해 재시작하세요. 키를 커밋이나 로그에 넣지 마세요.
 
 ## 구성
 
diff --git a/docs-site/src/content/docs/ko/guides/web-dashboard.md b/docs-site/src/content/docs/ko/guides/web-dashboard.md
index 68c796201c7..42df1f4afb3 100644
--- a/docs-site/src/content/docs/ko/guides/web-dashboard.md
+++ b/docs-site/src/content/docs/ko/guides/web-dashboard.md
@@ -18,6 +18,11 @@ ocx gui
 
 ```bash
 ocx start
+```
+
+해당 터미널에서 프록시를 계속 실행한 상태로 두고, 두 번째 터미널에서 GUI 개발 서버를 시작하세요:
+
+```bash
 bun run dev:gui
 ```
 
diff --git a/docs-site/src/content/docs/ko/reference/architecture.md b/docs-site/src/content/docs/ko/reference/architecture.md
index 17941510af7..d608e078271 100644
--- a/docs-site/src/content/docs/ko/reference/architecture.md
+++ b/docs-site/src/content/docs/ko/reference/architecture.md
@@ -133,7 +133,7 @@ Responses 항목 타입으로 구분됩니다 — 따라서 MCP 네임스페이
 엔드포인트가 업그레이드를 받아들이고 WebSocket 브리지를 사용합니다.
 
 이 클라이언트 설정과 별개로, 루트 `stream: true`인 canonical ChatGPT forward 요청은
-stable Bun 1.4.0 이상에서 Codex 업스트림 WebSocket을 사용할 수 있습니다. 번들 Bun 1.3.14,
+stable Bun 1.4.0 이상에서 Codex 업스트림 WebSocket을 사용할 수 있습니다. 현재 패키지에는 Bun **1.4.4**가 포함됩니다. Bun 1.3.14 같은 이전 번들,
 prerelease, 또는 검증할 수 없는 런타임 identity는 HTTP/SSE를 사용합니다. 성공한 업스트림 WS
 응답은 같은 downstream SSE 계약을 유지하며, 원시 JSON WebSocket 프레임과 downstream SSE
 envelope를 각각 4 MiB로 제한하고 8 MiB producer queue 상한이 있는 bounded eager single-reader
diff --git a/docs-site/src/content/docs/ko/reference/configuration/agents.md b/docs-site/src/content/docs/ko/reference/configuration/agents.md
index 60a0af24f67..67e758e90f6 100644
--- a/docs-site/src/content/docs/ko/reference/configuration/agents.md
+++ b/docs-site/src/content/docs/ko/reference/configuration/agents.md
@@ -10,7 +10,7 @@ description: 멀티 에이전트 표면, 위임 안내, 선호 모델, 대체 
 | 필드 | 형식 | 기본값 | 의미 |
 | --- | --- | --- | --- |
 | `multiAgentMode?` | `"v1" \| "default" \| "v2"` | `"default"` | `v1`은 카탈로그의 모든 모델에 v1을 표시하고, `v2`는 모든 모델에 v2를 표시합니다. `default`는 상위 고정값(Sol/Terra는 v2, Luna는 v1)을 복원하고, 그 외에는 네이티브 `multi_agent_v2` 플래그를 따릅니다. 새 세션에 적용됩니다. |
-| `subagentModels?` | `string[]` | `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6-luna` | 최대 다섯 개의 bare native id, account-qualified `<selector>/<native-openai-model>` id 또는 routed `provider/model` id를 서브에이전트 선택기에서 우선 표시합니다. Subagents 페이지는 bare native와 routed id만 제공하며 저장할 때 exact account-qualified 선택을 제외합니다. exact 선택은 `ocx agent subagents set`을 사용하거나 설정을 직접 편집하세요. [Astra 최초 업그레이드](/reference/configuration/agents/#astra-roster-upgrade) 이후에는 빈 목록도 그대로 보존됩니다. |
+| `subagentModels?` | `string[]` | `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6-luna` | 최대 다섯 개의 bare native id, account-qualified `<selector>/<native-openai-model>` id 또는 routed `provider/model` id를 서브에이전트 선택기에 우선 표시합니다. 새 선택 항목으로는 bare native와 routed id를 제공합니다. 저장할 때는 현재 카탈로그에 없는 항목을 포함하여 이미 설정된 정확한 account-qualified id를 보존합니다. 새 정확한 account-qualified id를 추가하려면 `ocx agent subagents set`을 사용하거나 설정을 편집하세요. [Astra 최초 업그레이드](/reference/configuration/agents/#astra-roster-upgrade) 이후에는 명시적으로 빈 목록도 보존됩니다. |
 | `injectionModel?` | `string` | — | 프록시가 작성한 v2 위임 안내에서 사용하는 선호 네이티브 또는 라우팅된 서브에이전트 모델입니다. |
 | `injectionEffort?` | `string` | — | 선호 노력(`low`부터 `ultra`까지)입니다. `injectionModel`이 있을 때만 의미가 있습니다. |
 | `injectionPrompt?` | `string` | — | 내장 v2 안내 본문을 대체합니다. `{{model}}`, `{{effort}}`, `{{roster}}`, `{{fallback}}`를 지원합니다. `injectionModel`만 설정되어 있어도 사용자 정의 프롬프트가 발동합니다. |
@@ -68,13 +68,13 @@ opencodex는 비활성, 라우팅 불가, 비정상, 쿨다운 중, 또는 할
 ```json
 {
   "multiAgentMode": "v2",
-  "subagentModels": ["gpt-5.5", "anthropic/claude-sonnet-5"],
-  "injectionModel": "gpt-5.5",
+  "subagentModels": ["gpt-6.1-sol", "anthropic/claude-sonnet-5"],
+  "injectionModel": "gpt-6.1-sol",
   "injectionEffort": "high",
   "syncCodexSubagentDefaults": true,
-  "subagentModelFallback": ["gpt-5.6-luna"],
+  "subagentModelFallback": ["gpt-6-luna"],
   "subagentModelFallbackByModel": {
-    "gpt-5.5": ["gpt-5.6-luna"]
+    "gpt-6.1-sol": ["gpt-6-luna"]
   },
   "subagentModelFallbackPollMs": 60000,
   "subagentEffortCap": "high"
diff --git a/docs-site/src/content/docs/ko/reference/configuration/server.md b/docs-site/src/content/docs/ko/reference/configuration/server.md
index 5b71745b457..29cfc6dcddb 100644
--- a/docs-site/src/content/docs/ko/reference/configuration/server.md
+++ b/docs-site/src/content/docs/ko/reference/configuration/server.md
@@ -10,7 +10,7 @@ description: 리스너, 원격 접근, admission 키, 타임아웃, 저장소, 
 | 필드 | 형식 | 기본값 | 의미 |
 | --- | --- | --- | --- |
 | `port` | `number` | `10100` | 프록시 수신 포트입니다. |
-| `hostname?` | `string` | `"127.0.0.1"` | 바인드 주소입니다. 루프백이 아닌 바인드에는 데이터 admission 토큰이 필요하며, `OPENCODEX_API_AUTH_TOKEN` → `OCX_API_TOKEN_FILE` → 설치된 owner-only `service-api-token` 순서로 결정됩니다. 손으로 내보낼 값은 없습니다. [Remote access](#remote-access)를 보세요. |
+| `hostname?` | `string` | `"127.0.0.1"` | 바인드 주소입니다. 비루프백에서는 `config.apiKeys`의 클라이언트 키 또는 `OPENCODEX_API_AUTH_TOKEN` → `OCX_API_TOKEN_FILE` → 설치된 소유자 전용 `service-api-token` 순서로 확인한 공유 데이터 토큰이 필요합니다. [원격 접근](#remote-access)을 참고하세요. |
 | `proxy?` | `string` | — | 송신용 HTTP(S) 또는 SOCKS5 프록시 URL(`socks5://host:port`) 또는 `${ENV_VAR}`입니다. HTTP URL은 해당 변수가 비어 있을 때 `HTTP_PROXY` / `HTTPS_PROXY`에 적용됩니다. SOCKS5 URL은 내장 SOCKS5 터널을 사용하고 `ALL_PROXY`에도 적용되며(`ocx start --socks5`), 이 프로세스에서 상속된 `HTTP(S)_PROXY`를 지웁니다. 루프백은 `NO_PROXY`에 그대로 남습니다. |
 | `emptyCompletionRetry?` | `boolean` | `false` | 텍스트나 도구 호출이 없는 Responses 턴을, 터미널 이벤트 전에 스트림이 종료된 경우를 포함해 동일한 요청으로 한 번 재시도하도록 선택합니다. 재시도에는 비용이 발생할 수 있습니다. `OCX_EMPTY_COMPLETION_RETRY=0`은 설정을 바꾸지 않고 비활성화하며, combo 및 routed-compaction turn은 제외됩니다. |
 | `dropCodexSafetyBuffering?` | `boolean` | `false` | Canonical Codex Responses 응답의 선택적 safety-buffering 헤더 두 개와 SSE 힌트를 제거합니다. 공급자의 안전 정책이나 거절 응답은 바뀌지 않습니다. Native WS 메타데이터와 compact는 제외됩니다. |
@@ -43,7 +43,7 @@ description: 리스너, 원격 접근, admission 키, 타임아웃, 저장소, 
 
 ## Remote access
 
-기본 `127.0.0.1` 바인드는 루프백 전용입니다. `0.0.0.0`이나 tailnet IP처럼 루프백이 아닌 주소는 `/api/*`와 데이터 플레인 모두에서 토큰 인증이 필요합니다.
+기본 `127.0.0.1` 바인드는 루프백 전용입니다. `0.0.0.0`이나 tailnet IP 같은 비루프백 주소의 모델 요청에는 `config.apiKeys`에 설정한 클라이언트 키 또는 공유 데이터 토큰이 필요합니다. 관리 경로 `/api/*`는 루프백에서도 별도의 `OPENCODEX_ADMIN_AUTH_TOKEN` 또는 생성된 관리자 토큰을 사용합니다. 데이터 자격 증명은 관리 접근을 허용하지 않습니다. 관리자 토큰을 모델 클라이언트에 제공하지 마세요.
 
 토큰을 직접 만들 필요는 없습니다. 루프백이 아닌 바인드에서 `ocx service install`이 다음 순서로 토큰을 준비합니다: 설치하는 셸의 `OPENCODEX_API_AUTH_TOKEN` → 기존 owner-only `service-api-token` 파일 → 무작위 32바이트 새 값. 결과는 `0600`으로 기록되고 실행 래퍼(launchd plist, systemd unit, Windows 래퍼)가 시작할 때 그 파일을 읽으므로, 값이 서비스 정의나 argv에 들어가지 않습니다. 포그라운드 `ocx start`도 같은 우선순위(환경 변수 → `OCX_API_TOKEN_FILE` → 설치된 `service-api-token`)를 적용하므로 토큰을 내보내지 않아도 루프백이 아닌 hostname에 바인드합니다.
 
@@ -64,13 +64,13 @@ x-opencodex-api-key: your-secret-token
 
 | 엔드포인트 | `Authorization: Bearer` | `x-opencodex-api-key` | `x-api-key` |
 | --- | --- | --- | --- |
-| `/v1/responses` | 허용되지 않음 | **필수** | 허용되지 않음 |
-| `/v1/chat/completions` | 허용되지 않음 | **필수** | 허용되지 않음 |
+| `/v1/responses` | 허용 | 허용 | 허용되지 않음 |
+| `/v1/chat/completions` | 허용 | 허용 | 허용되지 않음 |
 | `/v1/messages` | 허용됨 | 허용됨 | 허용됨 |
 | `/v1/messages/count_tokens` | 허용됨 | 허용됨 | 허용됨 |
 | `/v1/models` | 허용됨 | 허용됨 | 허용됨 |
 
-Responses와 Chat Completions는 `Authorization`을 향후 Codex Direct 패스스루 용도로 예약해 두므로, 여기서는 전용 admission 헤더만 허용됩니다. 대시보드에서 생성한 `apiKeys`는 시작 후 환경 토큰을 대체할 수 있으며, 후보 값은 상수 시간으로 비교합니다.
+Responses와 Chat Completions는 인식된 데이터 플레인 자격 증명을 `x-opencodex-api-key`에서 받으며, 이 전용 헤더가 없거나 앞뒤 공백을 제거한 값이 비어 있을 때는 `Authorization: Bearer`에서도 받습니다. 앞뒤 공백을 제거한 전용 헤더 값이 비어 있지 않으면 잘못된 값이어도 우선하므로, 유효한 bearer로 그 거부를 우회할 수 없습니다. 무관한 bearer는 프록시 접근을 허용하지 않으며 이 경로는 `x-api-key`를 받지 않습니다. 생성된 `apiKeys`와 공유 데이터 토큰은 상수 시간으로 비교됩니다. 관리 자격 증명은 모델 접근 권한을 부여하지 않습니다.
 
 Messages와 `count_tokens`는 라우팅 클라이언트 호환성을 위해 세 admission 형식을 계속 허용합니다. 하지만 비루프백
 바인드의 네이티브 Anthropic 패스스루는 프록시 admission을 `x-opencodex-api-key`로만 받고,
diff --git a/docs-site/src/content/docs/ko/reference/management-api.md b/docs-site/src/content/docs/ko/reference/management-api.md
index 95ad687b796..c292db38354 100644
--- a/docs-site/src/content/docs/ko/reference/management-api.md
+++ b/docs-site/src/content/docs/ko/reference/management-api.md
@@ -7,6 +7,8 @@ Management API는 opencodex의 제어 평면입니다. `http://localhost:10100`
 
 대화형 클라이언트가 필요하면 [Web Dashboard](/guides/web-dashboard/)를 사용하고, 자동화를 만들 때는 이 참고 문서를 사용하십시오. 영속 값은 결국 [Configuration](/reference/configuration/)을 따릅니다.
 
+<a id="authentication-model"></a>
+
 ## 인증 모델
 
 Management API에는 데이터 평면 API 키와는 독립된 자체 관리자 자격 증명이 있습니다. 시작 시 opencodex는 다음 순서로 이를 확인합니다.
diff --git a/docs-site/src/content/docs/reference/adapters.md b/docs-site/src/content/docs/reference/adapters.md
index 825d9046ec7..6126f279cac 100644
--- a/docs-site/src/content/docs/reference/adapters.md
+++ b/docs-site/src/content/docs/reference/adapters.md
@@ -3,8 +3,7 @@ title: Adapters
 description: The provider adapters — what each targets, how it builds requests, and its quirks.
 ---
 
-An **adapter** translates between opencodex's internal request/response model and one provider wire
-format. Every adapter implements the `ProviderAdapter` interface (`src/adapters/base.ts`):
+An **adapter** translates between opencodex's internal request/response model and one provider wire format. Every adapter implements `ProviderAdapter`. The following excerpt is abbreviated; the complete, authoritative interface is in `src/adapters/base.ts`:
 
 ```ts
 interface ProviderAdapter {
diff --git a/docs-site/src/content/docs/reference/architecture.md b/docs-site/src/content/docs/reference/architecture.md
index 8d636575e41..d2d82f11203 100644
--- a/docs-site/src/content/docs/reference/architecture.md
+++ b/docs-site/src/content/docs/reference/architecture.md
@@ -68,7 +68,9 @@ the `server/responses.ts` facade and its `server/responses/*.ts` modules:
 6. For routed models with a hosted `web_search` tool, `web-search/` exposes a synthetic function,
    executes the real search through the configured backend (the OpenAI/ChatGPT sidecar or Anthropic),
    feeds results back to the routed model, and repeats within the configured loop limit. This loop
-   supports only the standard HTTP path; adapters that implement `runTurn`, such as Cursor, bypass it.
+   uses the fetch-based path for ordinary HTTP adapters. Adapters that implement `runTurn`,
+   including Cursor, use the separate `runTurnWebSearchLoop` in
+   `server/responses/run-turn-execution.ts` when the search plan is eligible.
 7. `bridge/sse.ts` / `bridge/response-json.ts` produces Responses SSE or JSON. `server/request-log.ts` and `usage/` collect terminal
    status, latency, provider/model labels, and best-effort token usage without changing the response.
 
@@ -142,9 +144,12 @@ single non-streaming response object from the same events.
 `server/management/*.ts`. Its `/api/*` routes cover safe config/settings,
 provider CRUD and key pools, model selection/context caps/v2 controls, catalog sync, diagnostics and
 debug logs, usage and quotas, sidecar settings, updates, generated client API keys, OAuth login/status/
-logout and account selection, Codex account management, and graceful stop. `server/auth-cors.ts`
-requires `OPENCODEX_API_AUTH_TOKEN` for both `/api/*` and `/v1/*` when the proxy binds beyond
-loopback; configured `corsAllowOrigins` entries extend the local-origin allowlist.
+logout and account selection, Codex account management, and graceful stop. Management access to
+`/api/*` uses the separate `OPENCODEX_ADMIN_AUTH_TOKEN` or generated admin token; the dashboard
+uses management sessions. Model admission on `/v1/*` uses data-plane credentials, such as
+`OPENCODEX_API_AUTH_TOKEN` or configured client API keys. `server/auth-cors.ts` requires a data
+credential when binding beyond loopback; a model token does not grant management access.
+Configured `corsAllowOrigins` entries extend the local-origin allowlist.
 
 OAuth implementations live in `oauth/`; access tokens are loaded or refreshed immediately before a
 routed call, while `oauth/token-guardian.ts` can proactively refresh only providers whose policy
@@ -173,7 +178,7 @@ later quota updates are attributed to the serving account, not retroactively
 added to headers already sent. A failure after a WS request was sent does not
 trigger an automatic HTTP resend. These mappings do not enable the client-facing
 WebSocket setting or change other providers' transport selection.
-Bundled Bun 1.3.14, prereleases, and unverifiable runtime identities use HTTP/SSE. Successful
+The current package bundles Bun **1.4.4**. Older bundles such as Bun 1.3.14, prereleases, and unverifiable runtime identities use HTTP/SSE instead of that upstream WS optimization. Successful
 upstream WS responses keep the downstream SSE contract and bypass `tee()` through a bounded eager
 single-reader relay (4 MiB per raw/enveloped frame and an 8 MiB producer queue). Queue overflow
 closes the upstream and emits a terminal downstream `response.failed` event followed by `[DONE]`.
@@ -251,8 +256,9 @@ keepalives do not reset the adapter-event stall watchdog. The default stall
 timeout stays 300 seconds; encrypted compaction content is preserved unchanged.
 
 Native compact response buffering also enforces a body-byte inactivity deadline
-using `stallTimeoutSec` (300 seconds for a public upstream, disabled for a local one,
-and disabled everywhere when set to `0`). Nonempty chunks reset that
+using `stallTimeoutSec`. Unlike streaming, this route keeps its 300-second default even
+for a local upstream, because it buffers the whole body while holding an active-turn
+lease; an explicit value, including `0`, still wins. Nonempty chunks reset that
 deadline; a stalled body returns HTTP 504, client cancellation retains HTTP 499,
 and cleanup does not wait for a stuck upstream cancellation promise. The 32 MiB
 response ceiling and the original body bytes are preserved.
diff --git a/docs-site/src/content/docs/reference/cli.md b/docs-site/src/content/docs/reference/cli.md
index 3a895890dcc..8fee3e60814 100644
--- a/docs-site/src/content/docs/reference/cli.md
+++ b/docs-site/src/content/docs/reference/cli.md
@@ -87,7 +87,8 @@ fallback, capability JSON, and provider-specific error handling retain their exi
 `ocx message send (--thread <uuid> | --name <exact-name>) --stdin [--json]`
 submits one correlated peer message, without starting a daemon or resuming a thread.
 See [Local Codex Messaging](/reference/cli/messaging/) for sender context, kinds,
-the tested runtime and `not_sent`/`queued`/`unknown` receipts. No remote transport is included.
+the tested runtime and `not_sent`/`queued`/`unknown` receipts. Without `--host`, these operations are local.
+[Remote peer messaging over SSH](/reference/cli/messaging/#explicit-remote-peers) requires an enrolled host and `--host`; it does not autostart the receiver or automatically resend messages.
 
 ### `ocx provider`
 
diff --git a/docs-site/src/content/docs/reference/cli/agents.md b/docs-site/src/content/docs/reference/cli/agents.md
index f3058e22e2c..e105c217f29 100644
--- a/docs-site/src/content/docs/reference/cli/agents.md
+++ b/docs-site/src/content/docs/reference/cli/agents.md
@@ -76,14 +76,15 @@ ocx agent sidecar web --model gpt-5.6-luna
 ocx agent sidecar web --enabled off
 ```
 
-`--enabled off` is the same switch as the Dashboard's Off row: OpenCodex stops running the
-sidecar and the Codex integration writes `web_search = "disabled"` into `~/.codex/config.toml`,
-which is what lets an MCP search server be the only search path. `--enabled on` removes that
-marker-owned line again. When the save actually moves the switch, the command reports the
-Codex-side write it triggered (`codexWebSearch` in `--json`, a trailing `Codex config:` line
-otherwise) and points at `ocx sync` when it could not happen; a save that leaves the switch
-where it was has nothing to report and prints no `Codex config:` line. The flag works for
-`vision` too.
+For the web-search sidecar, `--enabled off` is the same switch as the dashboard's Off row:
+OpenCodex stops running the sidecar and the Codex integration writes `web_search = "disabled"`
+into `~/.codex/config.toml`, allowing an MCP search server to be the only search path.
+`--enabled on` removes that marker-owned line. A save that actually changes the switch reports
+the attempted native Codex application in `codexWebSearch` with `--json`, or a trailing
+`Codex config:` line otherwise. A successful receipt confirms the rewrite. A saved setting
+whose native application was deferred or refused reports the reason and the applicable next
+step, such as `ocx sync`; inspect that reason before retrying. An unchanged save has no native
+write to report and prints no `Codex config:` line. The enablement flag also works for `vision`.
 
 ### Injection defaults and sidecar runtime settings
 
@@ -469,9 +470,9 @@ Inspect proxy requests, usage, storage, memory, and debug data. The direct alias
 
 | Alias | Equivalent resource |
 | --- | --- |
-| `ocx logs [filters] [--follow] [--json|--jsonl|--events]` | `ocx observe logs` |
-| `ocx usage [--range <today|1d|7d|30d|all>] [--since <timestamp> --until <timestamp>] [--surface <all|codex|claude|grok>] [--provider <name>] [--model <id>] [--api-key-id <id>] [--search <text>] [--top <1-1000>] [--json]` | `ocx observe usage` |
-| `ocx usage compare [--range <today|1d|7d|30d>] [--json]` | `ocx observe usage compare` |
+| `ocx logs [filters] [--follow] [--json\|--jsonl\|--events]` | `ocx observe logs` |
+| `ocx usage [--range <today\|1d\|7d\|30d\|all>] [--since <timestamp> --until <timestamp>] [--surface <all\|codex\|claude\|grok>] [--provider <name>] [--model <id>] [--api-key-id <id>] [--search <text>] [--top <1-1000>] [--json]` | `ocx observe usage` |
+| `ocx usage compare [--range <today\|1d\|7d\|30d>] [--json]` | `ocx observe usage compare` |
 | `ocx storage [--json]` | `ocx observe storage` |
 | `ocx memory [--json]` | `ocx observe memory` |
 
@@ -569,10 +570,12 @@ maximum; unavailable values fail active speed filters. Protocol none includes
 absent or invalid traces. Conversation matching uses the same hash-aware IDs as
 ordinary logs. Interception selects string-valued rewrite markers.
 
-Unknown/repeated/conflicting flags, invalid bounds, and follow/events fail before
-discovery. Malformed, oversized or failed reads are nonzero, not empty results.
-To reduce response size, reduce the scan limit; reducing output limit does not
-change the fetch. For streaming use the separate follow forms below.
+Unknown, repeated or conflicting flags, invalid bounds, and unsupported follow/events options
+are refused before discovery: they write an error to stderr and exit 2. Operational failures,
+including discovery failures and malformed, oversized, refused or transport-failed reads, write
+an error to stderr and exit 1. These failures are not zero values or empty results.
+To reduce response size, reduce the scan limit; reducing output limit does not change the fetch.
+For streaming use the separate follow forms below.
 
 ### Search usage model rows
 
@@ -810,7 +813,7 @@ about a newly selected key.
 
 Transcription requires a nonempty regular file of at most 25,000,000 bytes with a
 30-second local read limit, and a multipart body capped at 32 MiB. Models are
-gpt-4o-transcribe, gpt-4o-mini-transcribe or whisper-1, subject to target support.
+`gpt-4o-transcribe`, `gpt-4o-mini-transcribe` or `whisper-1`, subject to target support.
 Upload/response share 130 seconds; response is capped at 2 MiB. Success returns
 only `{text}`, including empty text, with exact-key redaction. Failure leaves
 stdout empty and prints fixed stderr/nonzero; no JSON error envelope or raw body.
diff --git a/docs-site/src/content/docs/reference/code-signing.md b/docs-site/src/content/docs/reference/code-signing.md
index 420f398eb4c..2303b1e8032 100644
--- a/docs-site/src/content/docs/reference/code-signing.md
+++ b/docs-site/src/content/docs/reference/code-signing.md
@@ -6,14 +6,18 @@ description: How OpenCodex signs its Windows binaries through SignPath Foundatio
 OpenCodex is moving its Windows downloads, the standalone `ocx.exe` and the desktop installer
 `OpenCodex-<version>-windows-x64.msi`, to Authenticode code signing through
 [SignPath Foundation](https://signpath.org). A signed file tells Windows, SmartScreen and antivirus
-products who published it and that nobody changed it after the build, which is what stops
-unsigned-binary false positives like the one reported in
+products who published it and that nobody changed it after the build. Signing can reduce
+unsigned-binary warnings and false positives like the one reported in
 [#7207](https://github.com/lidge-jun/opencodex/issues/7207).
+It does not guarantee SmartScreen acceptance or prove that a file is safe:
+[Microsoft explains](https://learn.microsoft.com/windows/apps/package-and-deploy/smartscreen-reputation)
+that newly signed binaries can still trigger reputation warnings.
 
 Signing is rolling out. The release workflow is wired, and SignPath is validating it with a test
 certificate. Until the production certificate is issued, Windows release files stay unsigned, and
-SmartScreen may ask once (**More info → Run anyway**). Releases published after that switch carry
-a signature from **SignPath Foundation**.
+SmartScreen may ask once (**More info → Run anyway**). After that switch, the workflow attempts
+production signing through **SignPath Foundation**. If signing or verification fails, the release
+can still contain the original unsigned file, as described below.
 
 ## Code signing policy
 
@@ -81,7 +85,8 @@ Signing never blocks a release. What a run does depends on the policy:
 | `release-signing` | Signed and verified as trusted | Signed and verified as trusted |
 
 If a signing request fails, times out or is rejected, or if verification fails, the job logs a
-warning and ships the unsigned file together with its original updater signature.
+warning and ships the original unsigned file. An MSI retains its original updater signature
+when present; the standalone `ocx.exe` has no updater signature.
 
 **Switching to the production certificate.** Once SignPath issues it, set the repository variable
 `SIGNPATH_SIGNING_POLICY_SLUG` to `release-signing` (Settings → Secrets and variables → Actions →
diff --git a/docs-site/src/content/docs/reference/configuration/advisor.md b/docs-site/src/content/docs/reference/configuration/advisor.md
index 5576824297a..5e4a283baed 100644
--- a/docs-site/src/content/docs/reference/configuration/advisor.md
+++ b/docs-site/src/content/docs/reference/configuration/advisor.md
@@ -66,10 +66,11 @@ consent is missing: it prints this disclosure and stops. `ocx advisor set` does
   When the worker has produced its first orientation evidence (an assistant tool call OR a tool
   result after the latest user message), the proxy consults the advisor and injects the advice
   before the worker's next turn — even if the worker never calls the tool. The trigger is a
-  deterministic, documented approximation, not a semantic "model is stuck" detector. An
-  attempted consultation that FAILS is not silently treated as advice: the task retries after
-  the failure's ledger entry expires, so a temporary advisor outage does not permanently
-  silence the policy.
+  deterministic, documented approximation, not a semantic "model is stuck" detector. A
+  failed consultation does not inject valid advice or block the worker's task. A later
+  consultation becomes eligible after the failure's ledger entry expires, so a temporary
+  advisor outage does not permanently silence the policy. Dispatched failures report an
+  unavailable notice as described below; they do not restart the worker's task.
 - **`adaptive`** — adds failed-repair consultations to the initial preflight attempt. The proxy
   must observe a completed failing validation, a subsequent successful file-edit tool result,
   and a new execution of the **same command in the same working directory** failing again.
diff --git a/docs-site/src/content/docs/reference/configuration/agents.md b/docs-site/src/content/docs/reference/configuration/agents.md
index 3ba3ee04605..4943edfce3d 100644
--- a/docs-site/src/content/docs/reference/configuration/agents.md
+++ b/docs-site/src/content/docs/reference/configuration/agents.md
@@ -47,7 +47,7 @@ still depends on upstream support for your account.
 | --- | --- | --- | --- |
 | `multiAgentMode?` | `"v1" \| "default" \| "v2"` | `"default"` | `v1` stamps every catalog model as v1; `v2` stamps every model as v2. `default` restores upstream pins (Sol/Terra v2, Luna v1) and otherwise follows the native `multi_agent_v2` flag. Applies to new sessions. |
 | `keepNativeChatGptOnV1?` | `boolean` | `false` | When `multiAgentMode` is `"v2"`, disable the global V2 override, stamp ChatGPT-native rows as v1, and keep routed rows on v2. Codex resolves the global override before catalog pins, so both parts are required for a ChatGPT parent to spawn routed children without backend-encrypted tasks ([#92](https://github.com/lidge-jun/opencodex/issues/92)). Ignored in `v1` and `default`. |
-| `subagentModels?` | `string[]` | `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6-luna` | Up to five bare native, account-qualified `<selector>/<native-openai-model>`, or routed `provider/model` ids featured first in the sub-agent picker. The dashboard offers only bare native and routed ids and omits exact account-qualified choices when it saves; use `ocx agent subagents set` or edit the configuration for exact choices. After the [one-time Astra upgrade](#astra-roster-upgrade), an explicit empty list is preserved. |
+| `subagentModels?` | `string[]` | `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6-luna` | Up to five bare native, account-qualified `<selector>/<native-openai-model>`, or routed `provider/model` ids featured first in the sub-agent picker. The dashboard offers bare native and routed ids as new choices and preserves already-configured exact account-qualified ids when saving, including ids unavailable in the current catalog. To add a new exact account-qualified id, use `ocx agent subagents set` or edit the configuration. After the [one-time Astra upgrade](#astra-roster-upgrade), an explicit empty list is preserved. |
 | `injectionModel?` | `string` | — | Preferred native or routed sub-agent model used in proxy-authored v2 delegation guidance. |
 | `injectionEffort?` | `string` | — | Preferred effort (`low` through `ultra`), meaningful only with `injectionModel`. |
 | `injectionPrompt?` | `string` | — | Replaces the built-in v2 guidance body. Supports `{{model}}`, `{{effort}}`, `{{roster}}`, and `{{fallback}}`. A configured `injectionModel` is sufficient to render the custom prompt. |
@@ -181,13 +181,13 @@ on a mid-thread model switch.
 ```json
 {
   "multiAgentMode": "v2",
-  "subagentModels": ["gpt-5.5", "anthropic/claude-sonnet-5"],
-  "injectionModel": "gpt-5.5",
+  "subagentModels": ["gpt-6.1-sol", "anthropic/claude-sonnet-5"],
+  "injectionModel": "gpt-6.1-sol",
   "injectionEffort": "high",
   "syncCodexSubagentDefaults": true,
-  "subagentModelFallback": ["gpt-5.6-luna"],
+  "subagentModelFallback": ["gpt-6-luna"],
   "subagentModelFallbackByModel": {
-    "gpt-5.5": ["gpt-5.6-luna"]
+    "gpt-6.1-sol": ["gpt-6-luna"]
   },
   "subagentModelFallbackPollMs": 60000,
   "subagentEffortCap": "high"
diff --git a/docs-site/src/content/docs/reference/configuration/catalog.md b/docs-site/src/content/docs/reference/configuration/catalog.md
index bc6bed900fd..a756bf9da4f 100644
--- a/docs-site/src/content/docs/reference/configuration/catalog.md
+++ b/docs-site/src/content/docs/reference/configuration/catalog.md
@@ -57,7 +57,7 @@ account-selector rows; an account-qualified disable omits only that selector row
 The native inheritance template is validated and captured before omission, so routed
 rows keep the same input and tool metadata, including when the only template row is disabled.
 
-Absent, false, or malformed values preserve the default hidden-row behavior.
+Absent, false, or malformed values preserve the default behavior without this additional omission.
 Existing native-alias omission remains independent of this flag. This setting controls
 discovery only: direct requests to disabled native ids still route normally, and unchanged
 sync output keeps its existing no-op write and mtime behavior.
diff --git a/docs-site/src/content/docs/reference/configuration/providers.md b/docs-site/src/content/docs/reference/configuration/providers.md
index 0c34372fb24..9efd9a5d9b0 100644
--- a/docs-site/src/content/docs/reference/configuration/providers.md
+++ b/docs-site/src/content/docs/reference/configuration/providers.md
@@ -522,13 +522,13 @@ and `modelContextWindows` for that exact id when needed. Unknown ids are not gue
 | New destination, field omitted | Not kept; registry defaults for the new destination may apply | Not kept |
 | Field sent in the request | The request's value | The request's value |
 
-The destination is the adapter, the base URL (scheme and host compared without regard to case, trailing slashes ignored) and, when the request names one, the auth mode. Moving a provider to another destination drops the fourteen settings because they describe the previous upstream, and drops the key pool because its keys were issued for it. A save never merges the rest of the old row into the new one. The provider-level `modelDiscovery` block follows the same destination rule: a same-destination save that omits it keeps it, and a move drops it.
+The destination is the adapter, the base URL (scheme and host compared without regard to case, trailing slashes ignored) and, when the request names one, the auth mode. Moving a provider to another destination drops these settings because they describe the previous upstream, and drops the key pool because its keys were issued for it. A save never merges the rest of the old row into the new one. The provider-level `modelDiscovery` block follows the same destination rule: a same-destination save that omits it keeps it, and a move drops it.
 
 `hideRawReasoning` is an operator display policy, so a save of the same provider name keeps its stored value whenever the request omits it, including after a destination move. A value sent in the request wins, including `false`.
 
 The optional `inferContextWindow` setting also survives same-name saves that omit it, including destination moves. Its read, update, and clear behavior is described under [Context windows on custom providers](#context-windows-on-custom-providers).
 
-`PATCH /api/providers?name=<provider>` changes only the fields it names and keeps every other stored field, whatever the destination. It accepts all fourteen settings; `null` clears one. It also accepts `modelDiscovery`, where `null` or `{}` clears it. It also accepts a boolean `hideRawReasoning` or `null` to clear it. For the two reasoning lists an empty array is stored as an explicit opt-out rather than removed.
+`PATCH /api/providers?name=<provider>` changes only the fields it names and keeps every other stored field, whatever the destination. It accepts all these settings; `null` clears one. It also accepts `modelDiscovery`, where `null` or `{}` clears it. It also accepts a boolean `hideRawReasoning` or `null` to clear it. For the two reasoning lists an empty array is stored as an explicit opt-out rather than removed.
 
 With `webSearchBridge` enabled, a search continuation stays bound to the API-key selection that served the first request. Changing the selected key, its reference or resolved value, authentication
 mode, or base URL during search or provider pacing ends the turn with a bridge error before another
diff --git a/docs-site/src/content/docs/reference/configuration/routing.md b/docs-site/src/content/docs/reference/configuration/routing.md
index cb08fc072a5..f90abf16c40 100644
--- a/docs-site/src/content/docs/reference/configuration/routing.md
+++ b/docs-site/src/content/docs/reference/configuration/routing.md
@@ -87,7 +87,7 @@ account removal or policy change); until then the notifier is bounded by a five-
 opencodex resolves the requested model in this order:
 
 1. A configured `policy/<id>` or routing-profile alias, executing the policy evaluator and routing
-   the selected candidate. An unresolved `policy/<id>` falls through to the later rules.
+   the selected candidate. An unknown reserved `policy/<id>` fails before later rules.
 2. A configured `<account-selector>/<native-openai-model>` namespace, routed through exactly the
    mapped stored Codex account. An invalid or unavailable exact target fails closed.
 3. A canonical `combo/<id>` or configured combo alias. Canonical ids win before alias matching.
@@ -178,7 +178,7 @@ namespace, and cannot use reserved bare native families such as `gpt-*`, `o1-*`,
 | `allowMeteredTargets?` | `boolean` | `false` | Operator consent for local callers on a loopback-only proxy. A non-loopback listener disables this flag; configured-key and linked callers still need key consent. |
 | `strategy?` | `"failover" \| "round-robin" \| "random" \| "least-used" \| "reset-window" \| "jev"` | `"failover"` | Selection strategy. Target order is failover priority; weights shape round-robin and random draws; least-used follows recorded successes; reset-window follows the soonest quota reset; JEV makes one bounded decision for the initial eligible target and effort, then uses ordinary ordered fallback. |
 | `stickyLimit?` | `number` | `1` | Successful requests retained in one round-robin batch. Range 1–100. Applies only to round-robin. |
-| `cooldownMs?` | `number` | unset → upstream fallback (5 s for request-rate 429 codes `1302`/`1305`, otherwise 60 s) | Range 1–600000. When set, applies whenever no usable upstream `Retry-After` or Codex reset signal exists, including request-rate 429s; when unset, uses the upstream fallback. Upstream signals take precedence. An explicit upstream `Retry-After` is capped at 24 hours; reset-derived, configured, and fallback cooldowns are capped at 10 minutes. |
+| `cooldownMs?` | `number` | unset → 5 s for request-rate 429 codes `1302`/`1305`; 10 min for a spent usage window or provider-wide credential/billing failure; otherwise 60 s | Range 1–600000. When set, applies whenever no usable upstream `Retry-After` or Codex reset signal exists, including request-rate 429s; when unset, uses the upstream fallback. Upstream signals take precedence. An explicit upstream `Retry-After` is capped at 24 hours; reset-derived, configured, and fallback cooldowns are capped at 10 minutes. |
 | `waitForCooldownMs?` | `number` | `0` | Maximum wait for the earliest eligible cooling target on each selection attempt. Range 0–600000; an abort cancels the wait. A single-target combo with a nonzero wait holds the request up to this ceiling and retries the same target instead of failing immediately; if no target was ever dispatched the wait ends in `combo_unavailable`, otherwise the last upstream failure is returned. |
 | `cooldownWaitPolicy?` | `"before-last-resort"` | unset | Defers targets marked `lastResort`: they are used only when no normal target is available, for every strategy. `waitForCooldownMs` only adds the wait for a cooling normal target, so at its `0` default nothing waits and the last resort is used as soon as no normal target is available. The deferral and the ordinary wait share one `waitForCooldownMs` budget per selection attempt. Only that exact string opts in; `lastResort` is inert without it. |
 | `defaultEffort?` | `"low" \| "medium" \| "high" \| "xhigh" \| "max" \| "ultra" \| null` | unset | `defaultEffort` fills an absent `reasoning.effort` in fallback mode, or overrides valid caller effort in explicit force mode when the combo has a non-null default and the selected target has a known, nonempty supported ladder. If the target supports the configured value, it is retained; otherwise the highest supported rung at or below it is used, or the lowest supported rung when none is lower. Unknown or empty ladders omit the default. |
@@ -263,7 +263,8 @@ Ollama's `tev1` (Ollama 0.35+, `POST /v1/systemone`, no API key):
 }
 ```
 
-The row's `baseUrl` is the full decision endpoint and must end in `/systemone`; its model is
+The row's `baseUrl` is the full decision endpoint. Local plain-HTTP endpoints must end in
+`/systemone`; HTTPS endpoints may use their configured path, including `/v1/decisions`. Its model is
 `defaultModel`, else `models[0]` (a row with neither fails open without a request). Loopback needs
 the row's own explicit `allowPrivateNetwork: true`, and plain `http:` is accepted only for `localhost`
 or a loopback/RFC 1918/ULA address literal reached without a proxy. Only the row's own `apiKey` is
diff --git a/docs-site/src/content/docs/reference/configuration/server.md b/docs-site/src/content/docs/reference/configuration/server.md
index e1fd35aebb7..02f714a0fc2 100644
--- a/docs-site/src/content/docs/reference/configuration/server.md
+++ b/docs-site/src/content/docs/reference/configuration/server.md
@@ -21,7 +21,7 @@ passthrough, including native WebSocket output, retain their existing stop behav
 | --- | --- | --- | --- |
 | `completeOnMaxOutputTokens?` | `boolean` | `false` | Opt in to completing eligible token-limited translated Responses text output. Text stays truncated; see the eligibility and exclusions above. |
 | `port` | `number` | `10100` | Proxy listen port. |
-| `hostname?` | `string` | `"127.0.0.1"` | Bind address. A non-loopback bind requires a data-admission token, resolved from `OPENCODEX_API_AUTH_TOKEN`, then `OCX_API_TOKEN_FILE`, then the installed owner-only `service-api-token` — nothing has to be exported by hand. See [Remote access](#remote-access). |
+| `hostname?` | `string` | `"127.0.0.1"` | Bind address. A non-loopback bind requires a configured client key in `config.apiKeys` or a shared data token, resolved from `OPENCODEX_API_AUTH_TOKEN`, then `OCX_API_TOKEN_FILE`, then the installed owner-only `service-api-token`. See [Remote access](#remote-access). |
 | `proxy?` | `string` | — | Outbound HTTP(S) or SOCKS5 proxy URL (`socks5://host:port`), `${ENV_VAR}`, or `"auto"`. HTTP URLs apply to `HTTP_PROXY` / `HTTPS_PROXY` when those are unset. SOCKS5 URLs use OpenCodex's real SOCKS5 transport and are also exposed through `ALL_PROXY` (`ocx start --socks5`); inherited `HTTP(S)_PROXY` is cleared in this process. Loopback stays in `NO_PROXY`. `"auto"` reads Windows WinINET or macOS static HTTP/HTTPS settings once at startup. Inherited HTTP(S) proxy variables skip discovery; on macOS, inherited `ALL_PROXY`/`all_proxy` also skips it. Windows keeps separate `http=` and `https=` entries; a bare `ProxyServer` applies to both. macOS translates IP literals, `*`, and a valid `*.<domain>` glob to Bun's `.<domain>` bypass. That glob also bypasses the bare apex `<domain>`. The exact link-local ranges `169.254/16`, `169.254.0.0/16`, and `fe80::/10` are omitted with a diagnostic: link-local IP literals use the proxy. Other CIDRs, globs, and simple-host exceptions refuse discovery without changing the proxy environment. Disabled, malformed, PAC/WPAD, SOCKS-only, and live changes are not followed. Restart after changing system settings. |
 | `noProxy?` | `string \| string[]` | — | Hosts that bypass `proxy`, merged with inherited `NO_PROXY` and loopback entries. A string may use comma-separated `NO_PROXY` syntax or `${ENV_VAR}`. |
 | `emptyCompletionRetry?` | `boolean` | `false` | Opt in to one identical Responses retry when a turn has no text or tool call, including a stream that ends before a terminal event and a Vertex AI `MALFORMED_FUNCTION_CALL` failure that arrives before any output. The retry may be billable. `OCX_EMPTY_COMPLETION_RETRY=0` disables it without changing config; combo and routed-compaction turns remain excluded. |
@@ -44,7 +44,6 @@ passthrough, including native WebSocket output, retain their existing stop behav
 | `metricsExport.enabled?` | `boolean` | `false` | Enable process-local aggregate request metrics at authenticated `GET /api/metrics`. Restart required; disabled mode returns 404 and starts no exporter activity. |
 | `serviceHealthRecovery.enabled?` | `boolean` | `false` | Opt-in recovery for the background service: a small sentinel process probes `/healthz` and, when the proxy stays alive but answers nothing for about a minute of back-to-back probes, terminates it so the service manager (Task Scheduler, launchd, systemd, WinSW) restarts it. Only the managed service child starts one; requests the stuck process held are not replayed. At most three recoveries per hour. Restart required. Automatic recovery requires a numeric bind address (or the default localhost/wildcard mapping); DNS bind names are not monitored. A changed recorded address or port stops monitoring. |
 | `spend?` | `{ root?: { maxTokens?: number }; identity?: { maxTokens?: number }; pool?: { maxTokens?: number }; retentionDays?: number }` | unset | Durable token ceilings, off unless you write one. Each scope bounds settled spend plus in-flight reservations plus unresolved spend: `root` is one task including its whole fan-out, `identity` is one account across every task it serves, and `pool` is one provider pool. They intersect, so a request is admitted only when all three have room — which is what holds a ceiling against a client that mints a new task id per request. A reservation is the request's whole input plus its enforceable output ceiling, counted as if every cached prefix misses. Observe-only mode still journals, so every server owns the state directory's single-writer lease; an explicit sibling must use a separate `OPENCODEX_HOME`. Spend survives an ordinary process restart when its writes reached the filesystem, but the journal does not promise survival across host power loss because each append is not fsynced. Raising or removing a ceiling changes the allowance for requests started afterward; requests already running keep their starting policy. `maxTokens` must be a positive integer (0 would refuse everything), `retentionDays` is 1–365 and defaults to 7, and an unknown key in this section is rejected rather than ignored. A refusal is a local HTTP 429 carrying `x-opencodex-local-refusal: workflow_spend_exhausted`, and its message names the scope and the ceiling; no provider is contacted. With an applicable ceiling, dispatch is also refused if its token reservation cannot be booked, including full tracking capacity. Requests without an applicable ceiling remain observe-only. |
-
 | `codexAutoStart?` | `boolean` | `true` | Let the Codex shim run `ocx ensure` before launching Codex. False makes ensure a no-op. |
 | `codexShimAutoRestore?` | `boolean` | `true` | Restore an installed shim after a completed external Codex update replaces it. Environment opt-out: `OPENCODEX_CODEX_SHIM_AUTO_RESTORE=0`. |
 | `codexDesktopAuthless?` | `boolean` | `false` | Opt-in authless Codex Desktop routing on a loopback bind: inject the dedicated `opencodex` provider with `requires_openai_auth = false` so Desktop opens without a ChatGPT login. Ignored on non-loopback binds. `ocx system settings --desktop-authless on`. See [Codex integration](/guides/codex-integration/#authless-codex-desktop-opt-in). |
@@ -298,8 +297,7 @@ need it.
 
 ## Remote access
 
-The default `127.0.0.1` bind is loopback-only. A non-loopback address such as `0.0.0.0` or a tailnet
-IP requires token authentication on both `/api/*` and the data plane.
+The default `127.0.0.1` bind is loopback-only. A non-loopback address such as `0.0.0.0` or a tailnet IP requires a data-admission credential for model requests: a configured client key in `config.apiKeys` or a shared data token. Management routes `/api/*` use the independent `OPENCODEX_ADMIN_AUTH_TOKEN` or generated admin token, including on loopback. A data credential does not grant management access; never give the admin token to a model client.
 
 You do not have to produce that token. `ocx service install` provisions one on a non-loopback bind,
 in this order: `OPENCODEX_API_AUTH_TOKEN` from the installing shell, then an existing owner-only
@@ -331,15 +329,13 @@ x-opencodex-api-key: your-secret-token
 
 | Endpoint | `Authorization: Bearer` | `x-opencodex-api-key` | `x-api-key` |
 | --- | --- | --- | --- |
-| `/v1/responses` | not accepted | **required** | not accepted |
-| `/v1/chat/completions` | not accepted | **required** | not accepted |
+| `/v1/responses` | accepted | accepted | not accepted |
+| `/v1/chat/completions` | accepted | accepted | not accepted |
 | `/v1/messages` | accepted | accepted | accepted |
 | `/v1/messages/count_tokens` | accepted | accepted | accepted |
 | `/v1/models` | accepted | accepted | accepted |
 
-Responses and Chat Completions reserve `Authorization` for possible Codex Direct passthrough, so only
-the dedicated admission header is accepted there. Dashboard-generated `apiKeys` may replace the
-environment token after startup; candidates are compared in constant time.
+Responses and Chat Completions accept a recognized data-plane credential in `x-opencodex-api-key` or, when that dedicated header is absent, empty or whitespace-only, in `Authorization: Bearer`. A nonempty dedicated header, after trimming whitespace, takes precedence even if invalid; a valid bearer does not rescue it. An unrelated bearer is not a proxy admission credential, and `x-api-key` is not accepted on these routes. Dashboard-generated `apiKeys` and the shared data token are compared in constant time; management credentials do not grant model admission.
 
 Messages and `count_tokens` keep accepting all three admission forms for routed-client compatibility. Native
 Anthropic passthrough is stricter on a non-loopback bind: proxy admission must use
diff --git a/docs-site/src/content/docs/ru/getting-started/for-agents.md b/docs-site/src/content/docs/ru/getting-started/for-agents.md
index c443d881925..df2ec243992 100644
--- a/docs-site/src/content/docs/ru/getting-started/for-agents.md
+++ b/docs-site/src/content/docs/ru/getting-started/for-agents.md
@@ -18,7 +18,11 @@ npm install -g --allow-scripts=bun @bitkyc08/opencodex
 ocx --version
 ```
 
-Выберите один из способов запуска прокси:
+Перед запуском прокси выполните `ocx init` в интерактивном терминале, чтобы использовать выбранный при настройке порт:
+
+```bash
+ocx init
+```
 
 ```bash
 # Foreground: blocks this terminal until stopped.
@@ -28,13 +32,6 @@ ocx start
 ocx service
 ```
 
-Запустите `ocx init` в интерактивном терминале. Если `ocx start` уже занимает передний план,
-используйте второй терминал:
-
-```bash
-ocx init
-```
-
 Мастер записывает `$OPENCODEX_HOME/config.json` (обычно `~/.opencodex/config.json`). Он также может
 вставить адрес прокси в `config.toml` Codex и установить необязательный shim автозапуска Codex.
 `ocx init` никогда не запускает прокси. Для полностью неинтерактивной настройки вместо мастера
@@ -77,10 +74,12 @@ API-ключом и делает его провайдером по умолча
 
 ```bash
 ocx provider add anthropic-apikey \
-  --api-key "$ANTHROPIC_API_KEY" \
+  --api-key '${ANTHROPIC_API_KEY}' \
   --set-default
 ```
 
+Сохраните одинарные кавычки: они передают ссылку буквально, не помещая секрет в аргументы процесса и не сохраняя его значение в конфигурации. Задайте `ANTHROPIC_API_KEY` в окружении прокси до его запуска, а также для команд CLI, разрешающих учётные данные, например синхронизации моделей. Последующий export в другом терминале не меняет окружение работающего прокси. Для фоновой службы настройте её окружение запуска и перезапустите её: установка службы не сохраняет автоматически произвольные переменные провайдера из терминала.
+
 `ocx provider add` записывает локальную конфигурацию. Добавьте `--sync`, если живой прокси уже
 работает и вы хотите сразу синхронизировать модели в Codex; иначе позже выполните `ocx sync`.
 Пользовательские провайдеры, которых нет в registry, требуют одновременно `--adapter` и
@@ -90,7 +89,7 @@ ocx provider add anthropic-apikey \
 
 ```bash
 ocx combo set main \
-  --targets anthropic/claude-opus-4-8,openai/gpt-5.6-sol \
+  --targets anthropic-apikey/claude-opus-4-8,openai/gpt-5.6-sol \
   --strategy failover
 ```
 
@@ -100,15 +99,11 @@ ocx combo set main \
 
 ## Удалённые и LAN-привязки
 
-Привязка к loopback по умолчанию не требует API-токена. Для не-loopback-привязки, например
-`0.0.0.0`, требуется `OPENCODEX_API_AUTH_TOKEN`; без него прокси откажется запускаться. Задайте
-эту переменную перед `ocx start` или перед `ocx service install`, чтобы служба тоже её получила:
+Обычные модельные маршруты на loopback не требуют токена данных. Для привязки вне loopback, например `0.0.0.0`, нужен клиентский ключ из `config.apiKeys` либо общий токен из `OPENCODEX_API_AUTH_TOKEN`, `OCX_API_TOKEN_FILE` или доступного только владельцу файла `service-api-token`. Если файла нет, `ocx service install` может его создать. Если токен передаётся через переменную окружения, задайте её до `ocx start` или `ocx service install`:
 
 ```bash
 export OPENCODEX_API_AUTH_TOKEN="your-secret-token"
 ocx service install
 ```
 
-После этого клиенты должны аутентифицировать запросы как к management API, так и к модели.
-Прежде чем открывать opencodex за пределы локальной машины, прочитайте правила удалённого доступа
-в разделе [Конфигурация](/reference/configuration/).
+Запросы моделей используют учётные данные плоскости данных. Для управления нужен отдельный `OPENCODEX_ADMIN_AUTH_TOKEN` или созданный токен администратора в защищённом файле. Токен данных не даёт доступа к управлению. Панель следует правилам сеансов и доступа [API управления](/ru/reference/management-api/#authentication-model). Никогда не передавайте токен администратора модельному клиенту. Перед внешним доступом изучите [удалённый доступ](/ru/reference/configuration/server/#remote-access).
diff --git a/docs-site/src/content/docs/ru/getting-started/quickstart.md b/docs-site/src/content/docs/ru/getting-started/quickstart.md
index 33aae9d93b5..d4b43be9049 100644
--- a/docs-site/src/content/docs/ru/getting-started/quickstart.md
+++ b/docs-site/src/content/docs/ru/getting-started/quickstart.md
@@ -43,11 +43,20 @@ API-ключу, OpenRouter и экспериментального адапте
 
 ## 2. Запустите прокси
 
+Выполните один из двух вариантов; прокси остаётся на переднем плане:
+
 ```bash
 ocx start            # defaults to port 10100
+```
+
+Для другого порта используйте этот вариант:
+
+```bash
 ocx start --port 8080
 ```
 
+Оставьте этот терминал открытым. Следующие команды проверки состояния и открытия панели выполняйте во втором терминале с тем же `OPENCODEX_HOME`.
+
 При запуске opencodex:
 
 - записывает свой PID в `~/.opencodex/ocx.pid` (и отказывается запускаться повторно),
@@ -55,10 +64,7 @@ ocx start --port 8080
   маршрутизируемые записи в каталог моделей Codex**,
 - слушает `http://localhost:<port>/v1`.
 
-Если запрошенный порт занят, `ocx start` останавливается и сообщает, какой процесс его удерживает:
-если там отвечает opencodex, сначала выполните `ocx stop`; либо запустите прокси на свободном порту
-через `ocx start --port <port>`. Команда не переходит на другой порт сама — раньше из-за этого два
-прокси продолжали работать одновременно, а Codex перенаправлялся на более новый.
+Работающий opencodex с тем же `OPENCODEX_HOME` не позволяет запустить второй экземпляр, даже на свободном порту. Сначала остановите владельца через `ocx stop` либо выберите другой `OPENCODEX_HOME`. Соседний экземпляр обслуживает прямые запросы на своём порту, не меняя общую маршрутизацию Codex, Grok и Claude. Если порт занят посторонним процессом, `ocx start` сообщает об этом; выберите свободный порт через `ocx start --port <port>`. Автоматического переключения порта нет.
 
 Проверьте:
 
diff --git a/docs-site/src/content/docs/ru/guides/codex-app-models.md b/docs-site/src/content/docs/ru/guides/codex-app-models.md
index e1f95d377a7..76dea3f4d8e 100644
--- a/docs-site/src/content/docs/ru/guides/codex-app-models.md
+++ b/docs-site/src/content/docs/ru/guides/codex-app-models.md
@@ -160,9 +160,7 @@ capability-гейтом — `service_tier` удаляется только ко
 Codex сортирует видимые в picker'е записи каталога по возрастанию `priority` и рекламирует первые
 пять как model-override для `spawn_agent`. Страница Subagents в дашборде позволяет выбрать и
 сохранить до пяти bare native-id или routed provider-id `provider/model`. Настроенный вручную
-`subagentModels` также принимает account-qualified id `<selector>/<native-openai-model>`, но
-дашборд не предлагает эти точные id; сохранение страницы заменяет список вариантами, доступными в
-дашборде. opencodex назначает им низкие приоритеты каталога в выбранном порядке; при включённых
+`subagentModels` также принимает account-qualified id `<selector>/<native-openai-model>`. При сохранении списка дашборд сохраняет эти точные id, включая модели, которых нет в текущем каталоге. opencodex назначает им низкие приоритеты каталога в выбранном порядке; при включённых
 строках picker'а с указанием аккаунта bare native-выбор разворачивается в группы selector-qualified строк. Остальные
 модели всё равно можно вызывать по точному id.
 
diff --git a/docs-site/src/content/docs/ru/guides/grok-build.md b/docs-site/src/content/docs/ru/guides/grok-build.md
index 93a8c29e797..97e053ed9be 100644
--- a/docs-site/src/content/docs/ru/guides/grok-build.md
+++ b/docs-site/src/content/docs/ru/guides/grok-build.md
@@ -129,12 +129,11 @@ model = "anthropic/claude-opus-4-8"
 model_provider = "opencodex"
 ```
 
-Для прокси, доступного по сети, укажите в `base_url` адрес, до которого `grok` реально может
-дозвониться, и используйте свой admission token:
+Перед передачей токена настройте TLS-фронтенд и используйте его HTTPS URL либо loopback-адрес локального туннеля. Grok сохраняет значение `api_key` в `~/.grok/config.toml`: ограничьте доступ к файлу и не включайте его в систему контроля версий или общие резервные копии.
 
 ```toml
 [model_providers.opencodex]
-base_url = "http://192.168.1.10:10100/v1"   # the reachable host, not 127.0.0.1
+base_url = "https://proxy.example.com/v1"   # configured TLS frontend
 api_backend = "responses"
 api_key = "your-OPENCODEX_API_AUTH_TOKEN"
 
diff --git a/docs-site/src/content/docs/ru/guides/minimax.md b/docs-site/src/content/docs/ru/guides/minimax.md
index 0601bf39d65..feaede6a7f8 100644
--- a/docs-site/src/content/docs/ru/guides/minimax.md
+++ b/docs-site/src/content/docs/ru/guides/minimax.md
@@ -17,6 +17,11 @@ OpenCodex и подключите обратимую файловую интег
 
 ```bash
 ocx start
+```
+
+Оставьте прокси работать в этом терминале. Во втором терминале включите интеграцию и запустите MiniMax Code:
+
+```bash
 ocx integration client enable --client mcode
 ocx mcode
 ```
diff --git a/docs-site/src/content/docs/ru/guides/model-routing.md b/docs-site/src/content/docs/ru/guides/model-routing.md
index 117802629dc..da693fba0f7 100644
--- a/docs-site/src/content/docs/ru/guides/model-routing.md
+++ b/docs-site/src/content/docs/ru/guides/model-routing.md
@@ -59,9 +59,8 @@ description: Как opencodex решает, какой провайдер буд
    | `claude-`, `claude-sonnet-`, `claude-opus-`, `claude-haiku-` | `anthropic` |
    | `llama-`, `mixtral-`, `gemma-` | `groq` |
 
-   Этот сопоставитель работает только по имени и, в отличие от проверок `defaultModel` /
-   `models[]`, в настоящее время не отфильтровывает совпавшего провайдера, у которого флаг
-   `disabled` равен true.
+   Этот сопоставитель работает только по имени и, как и проверки `defaultModel` /
+   `models[]`, пропускает совпавшего провайдера, у которого флаг `disabled` равен true.
 
 7. **`models[]` провайдера** — если ни одно правило префикса не сработало, а активный провайдер
    перечисляет id в своём `models[]`, используется этот провайдер. По правилу 4 id `gpt-*` без
diff --git a/docs-site/src/content/docs/ru/guides/opencode.md b/docs-site/src/content/docs/ru/guides/opencode.md
index 12a1b04ea10..77ebba83440 100644
--- a/docs-site/src/content/docs/ru/guides/opencode.md
+++ b/docs-site/src/content/docs/ru/guides/opencode.md
@@ -105,9 +105,11 @@ upstream-заголовка `Authorization`.
 
 Пример для не-loopback:
 
+Это пример ручной настройки удалённого клиента. Сначала настройте TLS-фронтенд и используйте его HTTPS URL: OpenCodex не завершает TLS и не определяет этот URL для `ocx opencode`. Обычный HTTP в локальной сети раскрывает учётные данные при передаче. Либо оставьте прокси на loopback и используйте локальный SSH-туннель. См. [TLS для слушателя данных](/ru/guides/remote-hub/#giving-the-data-listener-tls).
+
 ```json
 "options": {
-  "baseURL": "http://192.168.1.10:10100/v1",
+  "baseURL": "https://proxy.example.com/v1",
   "headers": {
     "x-opencodex-api-key": "{env:OPENCODEX_OPENCODE_API_KEY}"
   }
diff --git a/docs-site/src/content/docs/ru/guides/pi.md b/docs-site/src/content/docs/ru/guides/pi.md
index 620c2b67dca..5497abe3344 100644
--- a/docs-site/src/content/docs/ru/guides/pi.md
+++ b/docs-site/src/content/docs/ru/guides/pi.md
@@ -3,10 +3,7 @@ title: Pi
 description: Используйте любую маршрутизируемую модель из Pi — ocx export создаёт пользовательский блок провайдера для models.json Pi, направленный на работающий прокси.
 ---
 
-Pi читает провайдеров из одного глобального JSON-файла, а не из переменных окружения, поэтому
-opencodex не запускает его сам. Вместо этого `ocx export` сериализует блок провайдера
-`opencodex` — base URL, список моделей и env-ссылку, которую интерполирует Pi, — а вы сливаете
-его в свою конфигурацию.
+Pi читает провайдеров из одного глобального JSON-файла. opencodex не запускает Pi: `ocx export` выводит блок провайдера `opencodex` с базовым URL, списком моделей и несекретным заполнителем локального ключа. Объедините этот блок со своей конфигурацией.
 
 ## Быстрый старт
 
@@ -14,11 +11,15 @@ opencodex не запускает его сам. Вместо этого `ocx ex
 
 ```bash
 ocx start
+```
+
+Оставьте этот процесс работающим. Во втором терминале выведите конфигурацию:
+
+```bash
 ocx export --client pi
 ```
 
-Сначала выводится JSON, затем путь назначения, предупреждение о merge, строка `export` для
-переменной окружения и число моделей, для которых есть авторитетные контекстные лимиты.
+После JSON выводятся путь назначения, предупреждение об объединении, подсказка по работе через loopback и число моделей с подтверждёнными пределами контекста. Этот экспорт поддерживает только loopback-прокси без аутентификации и не настраивает удалённый доступ.
 
 ```json
 {
@@ -26,7 +27,7 @@ ocx export --client pi
     "opencodex": {
       "baseUrl": "http://127.0.0.1:10100/v1",
       "api": "openai-completions",
-      "apiKey": "$OPENCODEX_API_KEY",
+      "apiKey": "opencodex-loopback",
       "compat": {
         "sendSessionAffinityHeaders": true,
         "supportsDeveloperRole": false
@@ -86,28 +87,7 @@ ocx export --client pi --json > ~/opencodex-pi-models.json   # or redirect the b
 
 ## Admission key
 
-Здесь легко перепутать два разных ключа, и в этом файле появляется только первый:
-
-| Ключ | Что это | Где хранится |
-| --- | --- | --- |
-| Ключ допуска прокси | собственная учётная запись opencodex, генерируемая на вкладке **API** в дашборде | указывается в `apiKey` как `$OPENCODEX_API_KEY`; само значение остаётся в окружении |
-| Ключ провайдера | ваш ключ Anthropic / OpenAI / OpenRouter | хранится в конфигурации самого opencodex, см. [Провайдеры](/guides/providers/) |
-
-Экспортируемая конфигурация несёт только ссылку, а не секрет. Pi интерполирует голый `$NAME`,
-поэтому переменная должна выглядеть так:
-
-```bash
-export OPENCODEX_API_KEY=<your key>
-```
-
-Это имя переменной относится только к Pi. opencode использует другую переменную
-(`OPENCODEX_OPENCODE_API_KEY` в форме `{env:…}`) — см. [руководство по opencode](/guides/opencode/).
-
-**Прокси на loopback вообще не требует ключа.** По умолчанию opencodex привязывается к
-`127.0.0.1` и ничего там не аутентифицирует, поэтому ссылка `$OPENCODEX_API_KEY` инертна и
-переменную можно не задавать. Она нужна только когда `hostname` выходит за пределы loopback — а
-именно в этом случае прокси и отказывается запускаться без токена; см.
-[Удалённый доступ](/ru/reference/configuration/server/#удалённый-доступ).
+Экспортируемый `apiKey` — несекретный заполнитель `opencodex-loopback`. Экспортировать переменную окружения с ключом не требуется. Экспортёр допускает только loopback-прокси без аутентификации и отказывает для удалённых или защищённых токеном прокси. Учётные данные провайдеров остаются в конфигурации opencodex, как описано в [Провайдерах](/ru/guides/providers/); не помещайте ключ вышестоящего провайдера в этот блок Pi. Для удалённого доступа используйте интеграцию с поддержкой аутентификации на прокси. Изменение заполнителя не включает удалённый экспорт Pi.
 
 ## Метаданные моделей
 
@@ -117,10 +97,11 @@ export OPENCODEX_API_KEY=<your key>
 
 Лимит вывода берётся из каталога или сгенерированных метаданных модели. Значение `32000` используется только при неизвестном лимите. Лимит всегда ограничен окном контекста; известные значения ниже `32000` сохраняются.
 
-Два поля намеренно отсутствуют. `cost` требует всех четырёх ценовых полей, а у opencodex нет
-данных о ценах для маршрутизируемых моделей — вывести нули означало бы заявить, что каждая модель
-бесплатна. `reasoning` в Pi — булево поле, тогда как каталог несёт целую лестницу effort, и
-отображать одно на другое пришлось бы догадкой.
+`cost` намеренно отсутствует: нужны все четыре ценовых поля, а у opencodex нет цен для маршрутизируемых моделей. Нули ошибочно означали бы бесплатность всех моделей.
+
+При **непустой** лестнице effort в каталоге экспортируется `"reasoning": true`; без лестницы или при явно пустой лестнице поле не объявляется. `thinkingLevelMap` скрывает уровни Pi без объявленной цели значением `null`, чтобы Pi не предлагал и не отправлял неподдержанные уровни. Если объявлен `ultra`, но не `max`, уровень Pi `max` отображается в `ultra`. Для другой схемы отредактируйте `thinkingLevelMap` вручную по документации Pi.
+
+`reasoning` — метаданные интерфейса Pi из каталога, а не доказательство нативной поддержки у провайдера. Фактический `reasoning_effort` зависит от адаптера и модели: значение может передаваться, преобразовываться, ограничиваться, эмулироваться или опускаться, например при `noReasoningModels`. Булево поле решает только, показывать ли элемент управления.
 
 ## Статус схемы
 
diff --git a/docs-site/src/content/docs/ru/guides/remote-hub.md b/docs-site/src/content/docs/ru/guides/remote-hub.md
index fda4a76d40b..3610ffb7ff0 100644
--- a/docs-site/src/content/docs/ru/guides/remote-hub.md
+++ b/docs-site/src/content/docs/ru/guides/remote-hub.md
@@ -12,7 +12,13 @@ Remote Hub хранит учётные данные провайдеров, ка
 `standalone` объединяет всё на одной машине; `hub` владеет секретами и статистикой; `client` хранит только состояние подключения и отдельный ключ данных.
 
 ```bash
-ocx connect https://hub-name.tailnet-name.ts.net --pairing-code-stdin
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the one-time code without echoing it or putting it in shell history.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+  --management-url https://hub-name.tailnet-name.ts.net \
+  --pairing-code-stdin
+unset pairing_code
 ocx connect status
 ocx sync
 ```
@@ -66,6 +72,8 @@ tailscale serve status
 
 `/healthz` подтверждает только работу процесса. Проверьте также `/readyz`, авторизованный `GET /v1/catalog` и реальный ответ модели. Собственный TLS-прокси должен использовать `tailscale cert hub-name.tailnet-name.ts.net` и проксировать только на `127.0.0.1:10101`. Не подделывайте `Tailscale-User-*`; без доверенной идентификации используйте одноразовое pairing.
 
+<a id="giving-the-data-listener-tls"></a>
+
 ### TLS для слушателя данных
 
 Показанное выше сопоставление Serve публикует только **управляющий** вход. Он никогда не отдаёт `/v1/*`, `/healthz` и `/readyz`, поэтому сам по себе не даёт удалённому клиенту работоспособного плана данных. opencodex к тому же не терминирует TLS: слушатель работает по открытому HTTP, а HTTPS всегда обеспечивает фронтенд на стороне оператора.
@@ -86,9 +94,13 @@ Serve принимает ограниченный набор HTTPS-портов;
 Затем подключайтесь, указывая оба origin по отдельности. Позиционный URL — это origin **данных**, именно оттуда берутся `/readyz` и `/v1/catalog`; `--management-url` — origin панели, который используется для pairing и выдачи ключа. Совпадение портов не требуется:
 
 ```bash
-ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the management admin token without echoing it.
+read -r -s -p 'Admin token: ' admin_token; printf '\n'
+printf '%s\n' "$admin_token" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
   --management-url https://hub-name.tailnet-name.ts.net \
   --admin-token-stdin
+unset admin_token
 ```
 
 Если `--management-url` опущен, он берётся из ответа `/readyz`, который сообщает `hub.managementPublicOrigin`. Когда origin различаются, указать его явно понятнее.
@@ -102,10 +114,16 @@ ocx connect https://hub-name.tailnet-name.ts.net:8443 \
 ## OAuth, ротация и отключение
 
 ```bash
-ocx config set oauthOpenBrowser false
-ocx connect rotate --pairing-code-stdin
-# только HTTPS:
-ocx connect rotate --admin-token-stdin
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: choose one authority source.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect rotate --pairing-code-stdin
+unset pairing_code
+
+# Alternatively, only over HTTPS, use the management admin token:
+read -r -s -p 'Admin token: ' admin_token; printf '\n'
+printf '%s\n' "$admin_token" | ocx connect rotate --admin-token-stdin
+unset admin_token
 ```
 
 OAuth запускается через `POST /api/oauth/login`. Если callback недоступен, передайте итоговый URL или код как `{provider,input}` в `POST /api/oauth/login/code`. Не помещайте код в argv или логи.
diff --git a/docs-site/src/content/docs/ru/guides/remote-workspace.md b/docs-site/src/content/docs/ru/guides/remote-workspace.md
index 4fca322dff6..fbf19c88b2d 100644
--- a/docs-site/src/content/docs/ru/guides/remote-workspace.md
+++ b/docs-site/src/content/docs/ru/guides/remote-workspace.md
@@ -34,9 +34,16 @@ Linux предоставляет файловые инструменты и вы
 На компьютере 1 находятся все входы агентов разработки и сессии моделей. Установите
 нужных агентов, войдите в них и запустите OpenCodex в роли Hub:
 
+Оставьте Hub работающим на переднем плане в этом терминале:
+
 ```bash
 ocx config set runtimeRole hub
 OCX_REMOTE_WORKSPACE_ENABLED=1 ocx start
+```
+
+Пока Hub работает, откройте второй терминал и запустите панель управления:
+
+```bash
 ocx gui
 ```
 
@@ -68,19 +75,42 @@ Codex на новую схему; не задавайте одновременн
 Эквивалентная ручная последовательность:
 
 ```bash
+# Bash only: if using zsh, run bash first in this terminal.
 cd /path/to/project
-printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
-  --pairing-code-stdin --root "$PWD"
-ocx remote-workspace agent
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" || pairing_status=$?
+  unset pairing_code
+  if [ "$pairing_status" -eq 0 ]; then ocx remote-workspace agent; fi
+  unset pairing_status
+else
+  unset pairing_code
+fi
 ```
 
 На Windows PowerShell используйте команду из дашборда. Её ручной эквивалент:
 
 ```powershell
-$pairingCode = 'ONE-TIME-CODE'
-$pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
-  --pairing-code-stdin --root (Get-Location).Path
-if ($LASTEXITCODE -eq 0) { ocx remote-workspace agent }
+$pairingSecret = Read-Host 'Pairing code' -AsSecureString
+$pairingBuffer = [IntPtr]::Zero
+$pairingExitCode = 1
+try {
+  $pairingBuffer = [Runtime.InteropServices.Marshal]::SecureStringToBSTR($pairingSecret)
+  $pairingCode = [Runtime.InteropServices.Marshal]::PtrToStringBSTR($pairingBuffer)
+  $pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
+    --pairing-code-stdin --root (Get-Location).Path
+  $pairingExitCode = $LASTEXITCODE
+} finally {
+  if ($pairingBuffer -ne [IntPtr]::Zero) {
+    [Runtime.InteropServices.Marshal]::ZeroFreeBSTR($pairingBuffer)
+  }
+  $pairingSecret.Dispose()
+  Remove-Variable pairingCode, pairingSecret, pairingBuffer -ErrorAction SilentlyContinue
+}
+if ($pairingExitCode -eq 0) { ocx remote-workspace agent }
+Remove-Variable pairingExitCode
 ```
 
 Текущий исполняемый файл OCX Bun автоматически добавляется в песочницу Linux как
@@ -89,9 +119,17 @@ if ($LASTEXITCODE -eq 0) { ocx remote-workspace agent }
 не открывая весь домашний каталог:
 
 ```bash
-printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
-  --pairing-code-stdin --root "$PWD" \
-  --toolchain-root "$HOME/.nvm/versions/node/v24/bin"
+# Bash only: if using zsh, run bash first in this terminal.
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" \
+    --toolchain-root "$HOME/.nvm/versions/node/v24/bin" || pairing_status=$?
+  unset pairing_code pairing_status
+else
+  unset pairing_code
+fi
 ```
 
 Исходный код нативного помощника поставляется для проверки. Его сборка не
diff --git a/docs-site/src/content/docs/ru/guides/subagent-v1-default.md b/docs-site/src/content/docs/ru/guides/subagent-v1-default.md
index 8cbc5f3a39a..4375754c998 100644
--- a/docs-site/src/content/docs/ru/guides/subagent-v1-default.md
+++ b/docs-site/src/content/docs/ru/guides/subagent-v1-default.md
@@ -40,7 +40,9 @@ v2 он каждый раз завершается ошибкой.
 backend ChatGPT. Ключ остаётся там. У OpenCodex его никогда не было, поэтому
 прокси нечего расшифровывать или переписывать: это действительно шифротекст,
 а не скрытый флагом обычный текст. Это свойство устройства системы, а не ошибка
-настройки; исправить его настройкой прокси нельзя.
+настройки; настройка прокси не позволяет расшифровать его локально.
+
+Настройки прокси не включают локальную расшифровку. Экспериментальная `agentTaskRecovery` может запросить восстановление подходящей задачи у backend ChatGPT, но не расшифровывает её локально. Описанные выше требования разрешения, допустимости и обработки сбоев сохраняются.
 
 Три схемы не затронуты. Их полезно перечислить, чтобы стало ясно, где именно
 возникает ошибка:
diff --git a/docs-site/src/content/docs/ru/guides/video-bridge.md b/docs-site/src/content/docs/ru/guides/video-bridge.md
index 850c5b0ebe1..88b575fff11 100644
--- a/docs-site/src/content/docs/ru/guides/video-bridge.md
+++ b/docs-site/src/content/docs/ru/guides/video-bridge.md
@@ -24,14 +24,12 @@ Video Bridge позволяет использовать генерацию xAI
 > ```json
 > {
 >   "providers": {
->     "xai": { "adapter": "openai-chat", "apiKey": "xai-…", "authMode": "key" }
+>     "xai": { "adapter": "openai-chat", "apiKey": "${XAI_API_KEY}", "authMode": "key" }
 >   }
 > }
 > ```
 >
-> Если вы подключали его через `ocx login xai` (OAuth), провайдер останется в
-> `authMode: "oauth"`, и bridge просто не активируется. Задайте `XAI_API_KEY` в окружении
-> **или** укажите ключ прямо в конфигурации, как выше.
+> Задайте `XAI_API_KEY` в окружении запуска прокси, сохраняя `${XAI_API_KEY}` и `authMode: "key"`. Экспорт в другом терминале не меняет работающий прокси; перезапустите через владеющее им Desktop, службу или терминал. Не публикуйте ключи в коммитах и журналах.
 
 ## Конфигурация
 
diff --git a/docs-site/src/content/docs/ru/guides/web-dashboard.md b/docs-site/src/content/docs/ru/guides/web-dashboard.md
index cc2edac1a84..ea7e3c8ea86 100644
--- a/docs-site/src/content/docs/ru/guides/web-dashboard.md
+++ b/docs-site/src/content/docs/ru/guides/web-dashboard.md
@@ -21,6 +21,11 @@ ocx gui
 
 ```bash
 ocx start
+```
+
+Оставьте прокси работающим в этом терминале. Во втором терминале запустите сервер разработки GUI:
+
+```bash
 bun run dev:gui
 ```
 
diff --git a/docs-site/src/content/docs/ru/reference/configuration/agents.md b/docs-site/src/content/docs/ru/reference/configuration/agents.md
index 6b0afa7d7fe..ef8a4da0d81 100644
--- a/docs-site/src/content/docs/ru/reference/configuration/agents.md
+++ b/docs-site/src/content/docs/ru/reference/configuration/agents.md
@@ -11,7 +11,7 @@ description: Multi-agent surface, guidance при делегировании, pr
 | Поле | Тип | По умолчанию | Значение |
 | --- | --- | --- | --- |
 | `multiAgentMode?` | `"v1" \| "default" \| "v2"` | `"default"` | `v1` штампует все модели как v1; `v2` штампует все модели как v2. `default` восстанавливает upstream pin'ы (Sol/Terra — v2, Luna — v1) и для остальных следует native flag `multi_agent_v2`. Применяется к новым сессиям. |
-| `subagentModels?` | `string[]` | `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6-luna` | До пяти bare native-id, account-qualified id `<selector>/<native-openai-model>` или routed-id `provider/model`, которые показываются первыми в picker'е подагентов. Страница Subagents предлагает только bare native- и routed-id и при сохранении исключает точные account-qualified варианты; для точного выбора используйте `ocx agent subagents set` или отредактируйте конфигурацию. После [однократного обновления Astra](/reference/configuration/agents/#astra-roster-upgrade) явный пустой список сохраняется. |
+| `subagentModels?` | `string[]` | `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6-luna` | До пяти bare native-id, account-qualified id `<selector>/<native-openai-model>` или routed-id `provider/model`, которые показываются первыми в списке подагентов. Для нового выбора панель предлагает bare native- и routed-id. При сохранении она сохраняет уже настроенные точные account-qualified id, включая отсутствующие в текущем каталоге. Для добавления нового точного account-qualified id используйте `ocx agent subagents set` или измените конфигурацию. После [однократного обновления Astra](/reference/configuration/agents/#astra-roster-upgrade) явно пустой список сохраняется. |
 | `injectionModel?` | `string` | — | Предпочитаемая native- или routed-модель подагента, которую proxy использует в собственном guidance v2. |
 | `injectionEffort?` | `string` | — | Предпочитаемый effort (`low`–`ultra`), имеющий смысл только вместе с `injectionModel`. |
 | `injectionPrompt?` | `string` | — | Заменяет встроенное тело guidance для v2. Поддерживает `{{model}}`, `{{effort}}`, `{{roster}}` и `{{fallback}}`. Настроенного `injectionModel` достаточно, чтобы отобразить пользовательский prompt. |
@@ -110,13 +110,13 @@ native ChatGPT-target'ами и прямыми key-auth Responses-маршрут
 ```json
 {
   "multiAgentMode": "v2",
-  "subagentModels": ["gpt-5.5", "anthropic/claude-sonnet-5"],
-  "injectionModel": "gpt-5.5",
+  "subagentModels": ["gpt-6.1-sol", "anthropic/claude-sonnet-5"],
+  "injectionModel": "gpt-6.1-sol",
   "injectionEffort": "high",
   "syncCodexSubagentDefaults": true,
-  "subagentModelFallback": ["gpt-5.6-luna"],
+  "subagentModelFallback": ["gpt-6-luna"],
   "subagentModelFallbackByModel": {
-    "gpt-5.5": ["gpt-5.6-luna"]
+    "gpt-6.1-sol": ["gpt-6-luna"]
   },
   "subagentModelFallbackPollMs": 60000,
   "subagentEffortCap": "high"
diff --git a/docs-site/src/content/docs/ru/reference/configuration/server.md b/docs-site/src/content/docs/ru/reference/configuration/server.md
index 5fe2a1736d6..7005847694e 100644
--- a/docs-site/src/content/docs/ru/reference/configuration/server.md
+++ b/docs-site/src/content/docs/ru/reference/configuration/server.md
@@ -11,7 +11,7 @@ description: Listener, удалённый доступ, admission key, тайм
 | Поле | Тип | По умолчанию | Значение |
 | --- | --- | --- | --- |
 | `port` | `number` | `10100` | Порт, который слушает прокси. |
-| `hostname?` | `string` | `"127.0.0.1"` | Адрес bind'а. Не-loopback bind требует `OPENCODEX_API_AUTH_TOKEN`. |
+| `hostname?` | `string` | `"127.0.0.1"` | Адрес привязки. Вне loopback нужен клиентский ключ из `config.apiKeys` либо общий токен данных: `OPENCODEX_API_AUTH_TOKEN`, затем `OCX_API_TOKEN_FILE`, затем установленный файл `service-api-token`, доступный только владельцу. См. [Удалённый доступ](#remote-access). |
 | `proxy?` | `string` | — | URL исходящего HTTP(S) или SOCKS5-прокси (`socks5://host:port`) или `${ENV_VAR}`. HTTP URL пишутся в `HTTP_PROXY` / `HTTPS_PROXY`, если те не заданы. SOCKS5 используют встроенный SOCKS5-туннель и также пишутся в `ALL_PROXY` (`ocx start --socks5`); унаследованные `HTTP(S)_PROXY` сбрасываются в этом процессе. Loopback всегда остаётся в `NO_PROXY`. |
 | `emptyCompletionRetry?` | `boolean` | `false` | Явно включает один идентичный повтор Responses, если в turn нет ни текста, ни tool call, включая случай, когда stream завершается до terminal event. Повтор может тарифицироваться. `OCX_EMPTY_COMPLETION_RETRY=0` отключает его без изменения config; combo и routed-compaction turn исключены. |
 | `dropCodexSafetyBuffering?` | `boolean` | `false` | Удаляет подсказки Codex safety-buffering из passthrough-ответов Codex Responses: заголовки `x-codex-safety-buffering-enabled` / `x-codex-safety-buffering-faster-model`, SSE-события `response.metadata` типа `safety_buffering` и поле `safety_buffering` в других SSE-событиях. Codex TUI отображает их как предложение повторить запрос с более быстрой моделью, действие по умолчанию в котором переключает сессию на более слабую модель. Остальные заголовки `x-codex-*` и содержимое других SSE-событий передаются без изменений, кроме удаления этого поля. По умолчанию выключено. |
@@ -44,19 +44,18 @@ native-provider history.
 
 Нативный Chat также использует `stallTimeoutSec` при ожидании вывода upstream. Непустой текст, рассуждения, отказ, обновления инструментов и события завершения обновляют время ожидания; комментарии keepalive, только роль и только статистика использования его не обновляют. Ожидание чтения медленным клиентом приостанавливает отсчёт. При зависании возникает `upstream_stall_timeout`: событие ошибки для потокового клиента или HTTP 502 без потоковой передачи. Отмена до конечного результата возвращает ошибку отмены вместо успешного частичного ответа. Непотоковый Chat поддерживает SSE с LF, CRLF и многострочными полями data.
 
+<a id="remote-access"></a>
+
 ## Удалённый доступ
 
-По умолчанию bind `127.0.0.1` доступен только на loopback. Не-loopback-адрес, например
-`0.0.0.0`, требует token-auth и для `/api/*`, и для data plane. Экспортируйте токен перед стартом:
+Привязка по умолчанию `127.0.0.1` ограничена loopback. Вне loopback, например на `0.0.0.0`, запросы моделей требуют клиентского ключа из `config.apiKeys` или общего токена данных. Маршруты управления `/api/*` используют отдельный `OPENCODEX_ADMIN_AUTH_TOKEN` или созданный токен администратора, в том числе на loopback. Учётные данные плоскости данных не дают доступа к управлению; не передавайте токен администратора модельному клиенту.
 
 ```bash
 export OPENCODEX_API_AUTH_TOKEN="your-secret-token"
 ocx start
 ```
 
-Без этой переменной прокси откажется подниматься на удалённом bind'е. Для фоновой службы
-экспортируйте её до `ocx service install`, чтобы launchd, systemd или Task Scheduler получили
-значение. Затем клиенты должны отправлять:
+В примере используется токен окружения. Экспорт не нужен, если уже есть токен из `OCX_API_TOKEN_FILE` или приватного `service-api-token` либо настроен действующий клиентский ключ. `ocx service install` может создать отсутствующий файл токена и не требует обязательного экспорта этой переменной. Модельные клиенты могут отправлять:
 
 ```text
 x-opencodex-api-key: your-secret-token
@@ -64,15 +63,13 @@ x-opencodex-api-key: your-secret-token
 
 | Эндпоинт | `Authorization: Bearer` | `x-opencodex-api-key` | `x-api-key` |
 | --- | --- | --- | --- |
-| `/v1/responses` | not accepted | **required** | not accepted |
-| `/v1/chat/completions` | not accepted | **required** | not accepted |
+| `/v1/responses` | принимается | принимается | не принимается |
+| `/v1/chat/completions` | принимается | принимается | не принимается |
 | `/v1/messages` | accepted | accepted | accepted |
 | `/v1/messages/count_tokens` | accepted | accepted | accepted |
 | `/v1/models` | accepted | accepted | accepted |
 
-Responses и Chat Completions резервируют `Authorization` под возможный passthrough Codex Direct,
-поэтому там принимается только dedicated admission-header. Сгенерированные в дашборде `apiKeys`
-могут после старта заменить env-token; сравнение кандидатов выполняется constant-time.
+Responses и Chat Completions принимают распознанные учётные данные плоскости данных в `x-opencodex-api-key` либо, если этот заголовок отсутствует или пуст после удаления пробелов, в `Authorization: Bearer`. Непустой после удаления пробелов выделенный заголовок приоритетен даже с неверным значением; действующий bearer не отменяет отказ. Посторонний bearer не даёт доступа к прокси, а `x-api-key` на этих маршрутах не принимается. Сгенерированные `apiKeys` и общий токен данных сравниваются за постоянное время; административные данные не дают доступа к моделям.
 
 Messages и `count_tokens` ради совместимости routed-клиентов по-прежнему принимают все три формы admission. Но на
 non-loopback bind нативный passthrough Anthropic принимает proxy admission только через
diff --git a/docs-site/src/content/docs/ru/reference/management-api.md b/docs-site/src/content/docs/ru/reference/management-api.md
index 53562100a0f..75df4de85d5 100644
--- a/docs-site/src/content/docs/ru/reference/management-api.md
+++ b/docs-site/src/content/docs/ru/reference/management-api.md
@@ -11,6 +11,8 @@ Management API — это control plane opencodex. Дашборд на `http://l
 нужен, когда вы строите automation. В конечном счёте постоянные значения следуют
 [Конфигурации](/reference/configuration/).
 
+<a id="authentication-model"></a>
+
 ## Модель аутентификации
 
 У Management API свой admin credential, независимый от data-plane API-key'ов. При старте
diff --git a/docs-site/src/content/docs/tr/getting-started/for-agents.md b/docs-site/src/content/docs/tr/getting-started/for-agents.md
index 7e4f295b692..597a0871ed8 100644
--- a/docs-site/src/content/docs/tr/getting-started/for-agents.md
+++ b/docs-site/src/content/docs/tr/getting-started/for-agents.md
@@ -19,7 +19,11 @@ npm install -g --allow-scripts=bun @bitkyc08/opencodex
 ocx --version
 ```
 
-Proxy'yi çalıştırmak için bir yol seçin:
+Kurulumda seçilen portu kullanmak için proxy başlamadan önce etkileşimli terminalde `ocx init` çalıştırın:
+
+```bash
+ocx init
+```
 
 ```bash
 # Ön plan: durdurulana kadar bu terminali kilitler.
@@ -29,13 +33,6 @@ ocx start
 ocx service
 ```
 
-Etkileşimli bir terminalde `ocx init` komutunu çalıştırın. Eğer `ocx start` ön
-planı işgal ediyorsa, ikinci bir terminal kullanın:
-
-```bash
-ocx init
-```
-
 Sihirbaz `$OPENCODEX_HOME/config.json` (normalde `~/.opencodex/config.json`)
 dosyasını yazar. Ayrıca proxy adresini Codex'in `config.toml` dosyasına enjekte
 edebilir ve isteğe bağlı Codex otomatik başlatma dolgusunu (shim) kurabilir.
@@ -91,10 +88,12 @@ anahtarı önayarını ekler ve onu varsayılan sağlayıcı yapar:
 
 ```bash
 ocx provider add anthropic-apikey \
-  --api-key "$ANTHROPIC_API_KEY" \
+  --api-key '${ANTHROPIC_API_KEY}' \
   --set-default
 ```
 
+Tek tırnakları koruyun: başvuruyu aynen geçirerek sırrın işlem argümanlarına veya yapılandırmaya değer olarak yazılmasını önler. `ANTHROPIC_API_KEY` değişkenini proxy başlamadan önce başlangıç ortamına ve model eşitleme gibi kimlik bilgilerini çözen CLI işlemlerine sağlayın. Sonradan başka bir terminalde export etmek çalışan proxy'yi güncellemez. Arka plan hizmetinde başlangıç ortamını yapılandırıp hizmeti yeniden başlatın; hizmet kurulumu terminaldeki rastgele sağlayıcı değişkenlerini otomatik olarak saklamaz.
+
 `ocx provider add` yerel yapılandırmayı yazar. Canlı bir proxy zaten çalışıyorsa
 ve modelleri hemen Codex ile senkronize etmek istiyorsanız `--sync` ekleyin;
 aksi takdirde daha sonra `ocx sync` çalıştırın. Kayıt defterinde olmayan özel
@@ -105,7 +104,7 @@ devretme (failover) kombosu oluşturun:
 
 ```bash
 ocx combo set main \
-  --targets anthropic/claude-opus-4-8,openai/gpt-5.6-sol \
+  --targets anthropic-apikey/claude-opus-4-8,openai/gpt-5.6-sol \
   --strategy failover
 ```
 
@@ -116,19 +115,11 @@ bakın.
 
 ## Uzak ve LAN Bağlantıları
 
-Varsayılan geri döngü (loopback) bağlantısı bir API belirteci gerektirmez.
-`0.0.0.0` gibi geri döngü olmayan bir bağlantı `OPENCODEX_API_AUTH_TOKEN`
-gerektirir; proxy bu olmadan başlamayı reddeder. Değişkeni `ocx start` öncesinde
-veya servisin alabilmesi için `ocx service install` öncesinde ayarlayın:
+Normal loopback model yolları veri token’ı gerektirmez. `0.0.0.0` gibi loopback dışı bir adrese bağlanmak için `config.apiKeys` içinde tanımlı bir istemci anahtarı veya `OPENCODEX_API_AUTH_TOKEN`, `OCX_API_TOKEN_FILE` ya da yalnızca sahibinin okuyabildiği `service-api-token` dosyasından çözümlenen ortak bir token gerekir. Dosya yoksa `ocx service install` oluşturabilir. Token’ı ortam değişkeniyle veriyorsanız `ocx start` veya `ocx service install` öncesinde ayarlayın:
 
 ```bash
 export OPENCODEX_API_AUTH_TOKEN="gizli-tokeniniz"
 ocx service install
 ```
 
-İstemciler daha sonra yönetim ve model isteklerinin kimliğini doğrulamalıdır.
-opencodex'i yerel makinenin ötesine açmadan önce
-[Yapılandırma](/tr/reference/configuration/) içindeki uzaktan erişim kurallarını
-okuyun.
-
-
+Model istekleri veri düzlemi kimlik doğrulamasını kullanır. Yönetim için ayrı `OPENCODEX_ADMIN_AUTH_TOKEN` veya korumalı dosyada oluşturulan yönetici token’ı kullanılır; veri token’ı yönetim erişimi vermez. Pano, [Yönetim API’sindeki](/tr/reference/management-api/#authentication-model) oturum ve erişim kurallarını izler. Yönetici token’ını hiçbir model istemcisine vermeyin. Proxy’yi dışarı açmadan önce [uzak erişimi](/tr/reference/configuration/server/#remote-access) okuyun.
diff --git a/docs-site/src/content/docs/tr/getting-started/quickstart.md b/docs-site/src/content/docs/tr/getting-started/quickstart.md
index e346dcca33a..66f13861755 100644
--- a/docs-site/src/content/docs/tr/getting-started/quickstart.md
+++ b/docs-site/src/content/docs/tr/getting-started/quickstart.md
@@ -41,11 +41,20 @@ penceresi bildirir; Cursor kendi adaptör meta verilerini korur.
 
 ## 2. Proxy'yi başlatın
 
+Aşağıdaki seçeneklerden yalnızca birini çalıştırın; proxy ön planda kalır:
+
 ```bash
 ocx start            # varsayılan port 10100
+```
+
+Farklı bir bağlantı noktası için alternatif:
+
+```bash
 ocx start --port 8080
 ```
 
+Bu terminali açık bırakın. Sonraki durum ve kontrol paneli komutlarını aynı `OPENCODEX_HOME` ile ikinci bir terminalde çalıştırın.
+
 Başlatıldığında opencodex:
 
 - PID'sini `~/.opencodex/ocx.pid` dosyasına yazar (ve iki kez başlamayı
@@ -54,10 +63,7 @@ Başlatıldığında opencodex:
   yönlendirilen girdileri Codex'in model kataloğuna senkronize eder**,
 - `http://localhost:<port>/v1` üzerinde dinler.
 
-İstenen port meşgulse `ocx start` durur ve portu neyin tuttuğunu bildirir: orada bir
-opencodex yanıt veriyorsa önce `ocx stop` çalıştırın veya `ocx start --port <port>` ile
-boş bir portta başlatın. Kendiliğinden başka bir porta geçmez; önceki davranış, iki
-proxy'nin yan yana çalışmasına ve Codex'in daha yeni olana yönlendirilmesine neden oluyordu.
+Aynı `OPENCODEX_HOME` ile çalışan opencodex, boş bir port olsa bile ikinci kez başlatılamaz. Önce sahip örneği `ocx stop` ile durdurun veya farklı bir `OPENCODEX_HOME` seçin. Kardeş örnek kendi portunda doğrudan istekleri işler; Codex, Grok ve Claude ortak yönlendirmesini değiştirmez. Portu ilgisiz bir süreç tutuyorsa `ocx start` bunu bildirir; `ocx start --port <port>` ile boş bir port seçin. Port kendiliğinden değişmez.
 
 Kontrol edin:
 
diff --git a/docs-site/src/content/docs/tr/guides/codex-app-models.md b/docs-site/src/content/docs/tr/guides/codex-app-models.md
index 3cb5b1380c7..00801700483 100644
--- a/docs-site/src/content/docs/tr/guides/codex-app-models.md
+++ b/docs-site/src/content/docs/tr/guides/codex-app-models.md
@@ -254,9 +254,7 @@ sıralar ve ilk beşini `spawn_agent` model geçersiz kılmaları olarak bildiri
 Kontrol paneli Alt Ajanlar sayfası en fazla beş yalın yerel kimliği veya
 yönlendirilen `provider/model` kimliğini seçip kaydedebilir. Manuel olarak
 yapılandırılan `subagentModels` ayrıca hesap nitelikli
-`<seçici>/<yerel-openai-modeli>` kimliklerini de kabul eder, ancak kontrol
-paneli bu tam kimlikleri sunmaz; sayfayı kaydetmek listenin yerine kontrol
-panelinde görünen seçenekleri koyar. opencodex seçilen sırada düşük katalog
+`<selector>/<native-openai-model>` kimliklerini de kabul eder. Kontrol paneli, geçerli katalogda bulunmayan modeller dahil, kaydedilmiş bu tam kimlikleri listeyi kaydederken korur. opencodex seçilen sırada düşük katalog
 öncelikleri atar; hesap nitelikli seçici satırları etkinleştirildiğinde yalın
 yerel seçimler seçici nitelikli gruplara genişler. Diğer modeller tam kimlikle
 çağrılabilir durumda kalır.
diff --git a/docs-site/src/content/docs/tr/guides/fallback-off.md b/docs-site/src/content/docs/tr/guides/fallback-off.md
index 878e4e23d41..fbc4fb9ca28 100644
--- a/docs-site/src/content/docs/tr/guides/fallback-off.md
+++ b/docs-site/src/content/docs/tr/guides/fallback-off.md
@@ -103,7 +103,7 @@ aktarıcısı ise `502` döndürür:
 { "error": "link tunnel unavailable", "code": "home_unreachable", "message": "The Home is unreachable, and OpenCodex did not serve this request from this device's local providers. …" }
 ```
 
-Yerel sağlayıcıya hiçbir şey gönderilmez; bağlantı anahtarı ve istek gövdesi cihazdan çıkmaz.
+Yerel sağlayıcıya hiçbir şey gönderilmez. Hata yönlendirme başlamadan önce oluşursa bağlantı anahtarı ve istek gövdesi cihazdan çıkmaz. Yönlendirme başladıysa Home isteği almış veya işlemiş olabilir; sonuç belirsizdir. Yeniden denemeden önce Home’daki durumu kontrol edin. OpenCodex gönderilmeye başlanmış isteği otomatik olarak tekrarlamaz.
 
 ### Cihaz ayarları
 
diff --git a/docs-site/src/content/docs/tr/guides/grok-build.md b/docs-site/src/content/docs/tr/guides/grok-build.md
index 44cb78f6036..43f70dbe72a 100644
--- a/docs-site/src/content/docs/tr/guides/grok-build.md
+++ b/docs-site/src/content/docs/tr/guides/grok-build.md
@@ -142,12 +142,11 @@ model = "anthropic/claude-opus-4-8"
 model_provider = "opencodex"
 ```
 
-Ağ üzerinden erişilebilen bir proxy için `base_url`'i `grok`'un gerçekten
-bağlanabileceği adrese yönlendirin ve kabul belirtecinizi kullanın:
+Tokenı sağlamadan önce bir TLS ön ucu yapılandırıp HTTPS URL'sini kullanın veya yerel tünelin loopback adresini kullanın. Grok, `api_key` değerini `~/.grok/config.toml` içinde saklar; dosya erişimini kısıtlayın, sürüm kontrolüne ve paylaşılan yedeklere eklemeyin.
 
 ```toml
 [model_providers.opencodex]
-base_url = "http://192.168.1.10:10100/v1"   # 127.0.0.1 değil, erişilebilir ana bilgisayar
+base_url = "https://proxy.example.com/v1"   # configured TLS frontend
 api_backend = "responses"
 api_key = "OPENCODEX_API_AUTH_TOKEN_DEGERINIZ"
 
diff --git a/docs-site/src/content/docs/tr/guides/minimax.md b/docs-site/src/content/docs/tr/guides/minimax.md
index ada887c0e1c..0a417a4084d 100644
--- a/docs-site/src/content/docs/tr/guides/minimax.md
+++ b/docs-site/src/content/docs/tr/guides/minimax.md
@@ -16,6 +16,11 @@ OpenCodex'i başlatıp geri alınabilir dosya bütünleştirmesini bağlayın:
 
 ```bash
 ocx start
+```
+
+Proxy bu terminalde çalışmaya devam etsin. İkinci bir terminalde entegrasyonu etkinleştirip MiniMax Code’u başlatın:
+
+```bash
 ocx integration client enable --client mcode
 ocx mcode
 ```
diff --git a/docs-site/src/content/docs/tr/guides/model-routing.md b/docs-site/src/content/docs/tr/guides/model-routing.md
index c3183bdcb6d..424f7b05410 100644
--- a/docs-site/src/content/docs/tr/guides/model-routing.md
+++ b/docs-site/src/content/docs/tr/guides/model-routing.md
@@ -67,9 +67,8 @@ devre dışı bırakılmışsa bu açık form yönlendirmek yerine hata fırlat
    | `claude-`, `claude-sonnet-`, `claude-opus-`, `claude-haiku-` | `anthropic` |
    | `llama-`, `mixtral-`, `gemma-` | `groq` |
 
-Bu eşleştirici ada dayalıdır ve `defaultModel` / `models[]` taramalarından
-farklı olarak şu anda `disabled` bayrağı true olan eşleşen bir sağlayıcıyı
-filtrelemez.
+Bu eşleştirici ada dayalıdır ve `defaultModel` / `models[]` taramaları gibi
+`disabled` bayrağı true olan eşleşen bir sağlayıcıyı atlar.
 
 7. **Bir sağlayıcının `models[]`'i** — hiçbir önek kuralı kazanmadıysa ve aktif
    bir sağlayıcı kimliği kendi `models[]` içinde listeliyorsa, o sağlayıcı
diff --git a/docs-site/src/content/docs/tr/guides/opencode.md b/docs-site/src/content/docs/tr/guides/opencode.md
index 05f6f256a30..aa66dca9f62 100644
--- a/docs-site/src/content/docs/tr/guides/opencode.md
+++ b/docs-site/src/content/docs/tr/guides/opencode.md
@@ -114,9 +114,11 @@ Geri döngü örneği:
 
 Geri döngü olmayan örnek:
 
+Bu örnek uzak istemcide elle yapılandırılır. Önce bir TLS ön ucu yapılandırın ve HTTPS URL'sini kullanın; OpenCodex TLS sonlandırmaz ve `ocx opencode` bu URL'yi otomatik bulmaz. LAN üzerinde düz HTTP, kimlik bilgisini aktarım sırasında açığa çıkarır. Alternatif olarak proxy'yi loopback üzerinde tutup yerel bir SSH tüneli kullanın. Bkz. [Veri dinleyicisi için TLS](/tr/guides/remote-hub/#giving-the-data-listener-tls).
+
 ```json
 "options": {
-  "baseURL": "http://192.168.1.10:10100/v1",
+  "baseURL": "https://proxy.example.com/v1",
   "headers": {
     "x-opencodex-api-key": "{env:OPENCODEX_OPENCODE_API_KEY}"
   }
diff --git a/docs-site/src/content/docs/tr/guides/pi.md b/docs-site/src/content/docs/tr/guides/pi.md
index bf0d2c54f45..a101aefdb64 100644
--- a/docs-site/src/content/docs/tr/guides/pi.md
+++ b/docs-site/src/content/docs/tr/guides/pi.md
@@ -3,13 +3,7 @@ title: "Pi Entegrasyonu"
 description: "Inflection Pi ve hafif sohbet modellerini OpenCodex üzerinden bağlama rehberi."
 ---
 
-Pi reads its providers from a single global JSON file rather than environment
-variables, so
-opencodex does not launch it. Instead, `ocx export` serializes the `opencodex`
-provider block —
-base URL, model list, and the env reference Pi interpolates — and you merge it
-into your own
-config.
+Pi, sağlayıcılarını tek bir genel JSON dosyasından okur. opencodex Pi’yi başlatmaz; `ocx export`, temel URL, model listesi ve gizli olmayan yerel anahtar yer tutucusunu içeren `opencodex` sağlayıcı bloğunu üretir. Bu bloğu mevcut yapılandırmanızla birleştirin.
 
 ## Quickstart
 
@@ -17,12 +11,15 @@ Start the proxy, then print the config:
 
 ```bash
 ocx start
+```
+
+Bu işlemi çalışır durumda bırakın. İkinci bir terminalde yapılandırmayı yazdırın:
+
+```bash
 ocx export --client pi
 ```
 
-The output leads with the JSON, then prints the destination path, the merge
-warning, the env
-export line, and how many models carry authoritative context limits.
+JSON’dan sonra hedef yol, birleştirme uyarısı, loopback kullanım ipucu ve doğrulanmış bağlam sınırları olan model sayısı yazdırılır. Bu dışa aktarım yalnızca kimlik doğrulamasız loopback proxy’sini destekler; uzak erişim kimlik doğrulamasını yapılandırmaz.
 
 ```json
 {
@@ -30,7 +27,7 @@ export line, and how many models carry authoritative context limits.
     "opencodex": {
       "baseUrl": "http://127.0.0.1:10100/v1",
       "api": "openai-completions",
-      "apiKey": "$OPENCODEX_API_KEY",
+      "apiKey": "opencodex-loopback",
       "compat": {
         "sendSessionAffinityHeaders": true,
         "supportsDeveloperRole": false
@@ -95,34 +92,7 @@ provider or changing model visibility, and merge the new block over the old one.
 
 ## The admission key
 
-Two different keys are easy to confuse here, and only the first one appears in
-this file:
-
-| Key | What it is | Where it lives |
-| --- | --- | --- |
-| Proxy admission key | opencodex's own credential, generated on the dashboard's **API** tab | referenced by `apiKey` as `$OPENCODEX_API_KEY`; the value stays in your environment |
-| Provider key | your Anthropic / OpenAI / OpenRouter key | opencodex's own config, per [Providers](/guides/providers/) |
-
-The exported config carries only the reference, never a secret. Pi interpolates
-a bare `$NAME`, so
-the variable is:
-
-```bash
-export OPENCODEX_API_KEY=<your key>
-```
-
-That name is Pi's alone. opencode uses a different variable
-(`OPENCODEX_OPENCODE_API_KEY`, in `{env:…}` form) — see the [opencode
-guide](/guides/opencode/).
-
-**A loopback proxy needs no key at all.** opencodex binds `127.0.0.1` by default
-and authenticates
-nothing there, so the `$OPENCODEX_API_KEY` reference is inert and you can leave
-the variable unset.
-It matters only when `hostname` is set beyond loopback, which is also the case
-where the proxy
-refuses to start without a token — see [Remote
-access](/tr/reference/configuration/server/#uzaktan-erişim).
+Dışa aktarılan `apiKey`, gizli olmayan `opencodex-loopback` yer tutucusudur. Anahtar için ortam değişkeni dışa aktarmanız gerekmez. Dışa aktarıcı yalnızca kimlik doğrulamasız loopback proxy’sine izin verir; uzak veya token ile korunan proxy’leri reddeder. Sağlayıcı kimlik bilgileri [Sağlayıcılar](/tr/guides/providers/) sayfasında açıklanan opencodex yapılandırmasında kalır. Üst sağlayıcının anahtarını bu Pi bloğuna koymayın. Uzak erişim için proxy erişim kimlik doğrulamasını destekleyen bir entegrasyon kullanın. Yer tutucuyu değiştirmek Pi için uzak dışa aktarımı etkinleştirmez.
 
 ## Model metadata
 
@@ -134,13 +104,11 @@ its own defaults;
 
 Çıktı sınırı, katalogdaki veya oluşturulan meta verilerdeki bilinen model sınırını kullanır. Yalnızca sınır bilinmiyorsa `32000` kullanılır. Çıktı sınırı her zaman bağlam penceresiyle sınırlanır; `32000` altındaki bilinen sınırlar da korunur.
 
-Two fields are deliberately absent. `cost` requires all four price fields and
-opencodex has no
-price data for routed models — emitting zeros would assert that every model is
-free. `reasoning` is
-a boolean in Pi while the catalog carries an effort ladder, and mapping one onto
-the other would be
-a guess.
+`cost` bilerek atlanır: dört fiyat alanının tamamını gerektirir ve opencodex yönlendirilen modellerin fiyatlarını bilmez. Sıfır yazmak bütün modellerin ücretsiz olduğunu yanlış biçimde belirtirdi.
+
+Katalogdaki effort listesi **boş değilse** `"reasoning": true` dışa aktarılır; liste yoksa veya açıkça boşsa bu özellik bildirilmez. `thinkingLevelMap`, hedefi tanımlanmamış Pi düzeylerini `null` ile gizler; Pi listede olmayan düzeyleri sunmaz veya göndermez. `max` olmadan `ultra` tanımlanmışsa Pi’nin `max` düzeyi `ultra` ile eşleşir. Başka bir eşleme için Pi belgelerine göre `thinkingLevelMap` alanını elle düzenleyin.
+
+`reasoning`, katalogdan türetilen Pi arayüz metaverisidir; sağlayıcının yerel desteğini kanıtlamaz. Gerçek `reasoning_effort`, adaptöre ve modele göre aktarılabilir, dönüştürülebilir, sınırlandırılabilir, emüle edilebilir veya atlanabilir (örneğin `noReasoningModels`). Bu boolean yalnızca Pi’nin kontrolü sunup sunmayacağını belirler.
 
 ## Schema status
 
diff --git a/docs-site/src/content/docs/tr/guides/remote-hub.md b/docs-site/src/content/docs/tr/guides/remote-hub.md
index 8ced721095e..e1387925eb4 100644
--- a/docs-site/src/content/docs/tr/guides/remote-hub.md
+++ b/docs-site/src/content/docs/tr/guides/remote-hub.md
@@ -12,7 +12,13 @@ Remote Hub sağlayıcı kimlik bilgilerini, kataloğu ve kullanım kayıtların
 `standalone` her şeyi tek makinede tutar; `hub` sağlayıcı sırları ve kullanımı yönetir; `client` yalnızca bağlantı durumunu ve istemciye özel veri anahtarını saklar.
 
 ```bash
-ocx connect https://hub-name.tailnet-name.ts.net --pairing-code-stdin
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the one-time code without echoing it or putting it in shell history.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+  --management-url https://hub-name.tailnet-name.ts.net \
+  --pairing-code-stdin
+unset pairing_code
 ocx connect status
 ocx sync
 ```
@@ -66,6 +72,8 @@ tailscale serve status
 
 `/healthz` yalnızca işlemin yaşadığını gösterir. `/readyz`, kimlik doğrulamalı `GET /v1/catalog` ve gerçek bir model yanıtını da doğrulayın. Kendi TLS proxy'niz için `tailscale cert hub-name.tailnet-name.ts.net` kullanın ve yalnızca `127.0.0.1:10101` hedefine yönlendirin. `Tailscale-User-*` başlıkları uydurmayın; güvenilir kimlik yoksa tek kullanımlık eşleştirme kullanın.
 
+<a id="giving-the-data-listener-tls"></a>
+
 ### Veri dinleyicisine TLS vermek
 
 Yukarıdaki Serve eşlemesi yalnızca **yönetim** girişini yayımlar. Bu giriş `/v1/*`, `/healthz` veya `/readyz` sunmaz; dolayısıyla tek başına uzak bir istemciye kullanılabilir bir veri düzlemi vermez. opencodex kendi TLS'ini de sonlandırmaz: dinleyici düz HTTP'dir ve HTTPS her zaman operatörün kendi ön ucudur.
@@ -86,9 +94,13 @@ Serve sınırlı bir HTTPS portu kümesini kabul eder; portun izinli olduğunu v
 Ardından iki origin'i ayrı ayrı belirterek bağlanın. Konumsal URL **veri** origin'idir; `/readyz` ve `/v1/catalog` oradan alınır. `--management-url` ise eşleştirme ve anahtar verme için kullanılan pano origin'idir. Aynı portu paylaşmaları gerekmez:
 
 ```bash
-ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the management admin token without echoing it.
+read -r -s -p 'Admin token: ' admin_token; printf '\n'
+printf '%s\n' "$admin_token" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
   --management-url https://hub-name.tailnet-name.ts.net \
   --admin-token-stdin
+unset admin_token
 ```
 
 `--management-url` atlandığında, `hub.managementPublicOrigin` değerini bildiren `/readyz` yanıtından alınır. İki origin farklıysa açıkça yazmak daha nettir.
@@ -102,10 +114,16 @@ Serve ayağa kalktıktan sonra kabul denetimlerini HTTPS veri origin'ine karşı
 ## OAuth, döndürme ve bağlantı kesme
 
 ```bash
-ocx config set oauthOpenBrowser false
-ocx connect rotate --pairing-code-stdin
-# yalnızca HTTPS:
-ocx connect rotate --admin-token-stdin
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: choose one authority source.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect rotate --pairing-code-stdin
+unset pairing_code
+
+# Alternatively, only over HTTPS, use the management admin token:
+read -r -s -p 'Admin token: ' admin_token; printf '\n'
+printf '%s\n' "$admin_token" | ocx connect rotate --admin-token-stdin
+unset admin_token
 ```
 
 OAuth'u `POST /api/oauth/login` ile başlatın. Callback hub'a ulaşamıyorsa son URL'yi veya kodu `{provider,input}` olarak `POST /api/oauth/login/code` yoluna gönderin. OAuth kodunu argv veya loglara koymayın.
diff --git a/docs-site/src/content/docs/tr/guides/remote-workspace.md b/docs-site/src/content/docs/tr/guides/remote-workspace.md
index 65797d801eb..798fe63f647 100644
--- a/docs-site/src/content/docs/tr/guides/remote-workspace.md
+++ b/docs-site/src/content/docs/tr/guides/remote-workspace.md
@@ -35,9 +35,16 @@ Bilgisayar 1 tüm kodlama ajanı girişlerini ve model oturumlarını tutar.
 Kullanmak istediğiniz ajanları oraya kurup giriş yapın, ardından OpenCodex'i
 Hub olarak çalıştırın:
 
+Hub bu terminalde ön planda çalışmaya devam etsin:
+
 ```bash
 ocx config set runtimeRole hub
 OCX_REMOTE_WORKSPACE_ENABLED=1 ocx start
+```
+
+Hub çalışırken ikinci bir terminal açın ve kontrol panelini başlatın:
+
+```bash
 ocx gui
 ```
 
@@ -68,20 +75,43 @@ ayarlamayın.
 Eşdeğer el ile akış:
 
 ```bash
+# Bash only: if using zsh, run bash first in this terminal.
 cd /path/to/project
-printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
-  --pairing-code-stdin --root "$PWD"
-ocx remote-workspace agent
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" || pairing_status=$?
+  unset pairing_code
+  if [ "$pairing_status" -eq 0 ]; then ocx remote-workspace agent; fi
+  unset pairing_status
+else
+  unset pairing_code
+fi
 ```
 
 Windows PowerShell'de kontrol panelinin gösterdiği komutu kullanın. Eşdeğer
 el ile biçim:
 
 ```powershell
-$pairingCode = 'ONE-TIME-CODE'
-$pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
-  --pairing-code-stdin --root (Get-Location).Path
-if ($LASTEXITCODE -eq 0) { ocx remote-workspace agent }
+$pairingSecret = Read-Host 'Pairing code' -AsSecureString
+$pairingBuffer = [IntPtr]::Zero
+$pairingExitCode = 1
+try {
+  $pairingBuffer = [Runtime.InteropServices.Marshal]::SecureStringToBSTR($pairingSecret)
+  $pairingCode = [Runtime.InteropServices.Marshal]::PtrToStringBSTR($pairingBuffer)
+  $pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
+    --pairing-code-stdin --root (Get-Location).Path
+  $pairingExitCode = $LASTEXITCODE
+} finally {
+  if ($pairingBuffer -ne [IntPtr]::Zero) {
+    [Runtime.InteropServices.Marshal]::ZeroFreeBSTR($pairingBuffer)
+  }
+  $pairingSecret.Dispose()
+  Remove-Variable pairingCode, pairingSecret, pairingBuffer -ErrorAction SilentlyContinue
+}
+if ($pairingExitCode -eq 0) { ocx remote-workspace agent }
+Remove-Variable pairingExitCode
 ```
 
 Geçerli OCX Bun yürütülebiliri Linux sandbox'ına otomatik olarak tek salt okunur
@@ -90,9 +120,17 @@ kurulmuş bir araç zinciri gerektiriyorsa ev dizininin geri kalanını açmadan
 onu açıkça eşleştirin:
 
 ```bash
-printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
-  --pairing-code-stdin --root "$PWD" \
-  --toolchain-root "$HOME/.nvm/versions/node/v24/bin"
+# Bash only: if using zsh, run bash first in this terminal.
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" \
+    --toolchain-root "$HOME/.nvm/versions/node/v24/bin" || pairing_status=$?
+  unset pairing_code pairing_status
+else
+  unset pairing_code
+fi
 ```
 
 Yerel yardımcı kaynak kodu inceleme için paketlenmiştir. Derlemek, bu taşıma
diff --git a/docs-site/src/content/docs/tr/guides/subagent-v1-default.md b/docs-site/src/content/docs/tr/guides/subagent-v1-default.md
index 11ebaff1e56..9a282fdb27c 100644
--- a/docs-site/src/content/docs/tr/guides/subagent-v1-default.md
+++ b/docs-site/src/content/docs/tr/guides/subagent-v1-default.md
@@ -40,7 +40,9 @@ v2'de ebeveyn, ChatGPT arka ucunun ürettiği `encrypted_content` olarak görevi
 verir. Anahtar o arka uçta kalır. OpenCodex anahtara hiç sahip olmadığından
 proxy'nin çözebileceği veya yeniden yazabileceği bir şey yoktur: değer, bir
 bayrağın arkasındaki düz metin değil gerçekten şifreli metindir. Bu yüzden
-sorun yapılandırma hatası değil yapısaldır ve proxy tarafı ayarlarla çözülemez.
+sorun yapılandırma hatası değil yapısaldır; proxy tarafı ayarlar yerel şifre çözmeyi etkinleştiremez.
+
+Hiçbir proxy ayarı yerel şifre çözmeyi etkinleştirmez. Deneysel `agentTaskRecovery`, uygun görevleri kurtarmak için ChatGPT arka ucuna başvurabilir; şifreli metni yerel olarak çözmez. Yukarıdaki yetkilendirme, uygunluk ve hata sınırları geçerlidir.
 
 Üç topoloji etkilenmez; bu, hatanın şeklini açıklar:
 
diff --git a/docs-site/src/content/docs/tr/guides/video-bridge.md b/docs-site/src/content/docs/tr/guides/video-bridge.md
index b002f88e14e..d0a47297375 100644
--- a/docs-site/src/content/docs/tr/guides/video-bridge.md
+++ b/docs-site/src/content/docs/tr/guides/video-bridge.md
@@ -27,12 +27,12 @@ indirir.
 > ```json
 > {
 >   "providers": {
->     "xai": { "adapter": "openai-chat", "apiKey": "xai-…", "authMode": "key" }
+>     "xai": { "adapter": "openai-chat", "apiKey": "${XAI_API_KEY}", "authMode": "key" }
 >   }
 > }
 > ```
 >
-> `ocx login xai` (OAuth) ile katıldıysanız sağlayıcı `authMode: "oauth"` modunda kalır ve köprü sessizce devreye girmez. Ortamda `XAI_API_KEY` ayarlayın **veya** anahtarı yukarıda gösterildiği gibi sabit kodlayın.
+> `XAI_API_KEY` değerini proxy başlangıç ortamında ayarlayın; `${XAI_API_KEY}` ve `authMode: "key"` korunsun. Başka terminalde export, çalışan proxy’yi değiştirmez; sahibi Desktop, hizmet veya ön plan terminalinden yeniden başlatın. Anahtarları commit ve günlüklere koymayın.
 
 ## Yapılandırma
 
diff --git a/docs-site/src/content/docs/tr/guides/web-dashboard.md b/docs-site/src/content/docs/tr/guides/web-dashboard.md
index e316b91c6e4..74117ab9b53 100644
--- a/docs-site/src/content/docs/tr/guides/web-dashboard.md
+++ b/docs-site/src/content/docs/tr/guides/web-dashboard.md
@@ -22,6 +22,11 @@ sunucusunu çalışan bir proxy'ye karşı ayrı olarak çalıştırabilirsiniz:
 
 ```bash
 ocx start
+```
+
+Proxy bu terminalde çalışmaya devam etsin. İkinci bir terminalde GUI geliştirme sunucusunu başlatın:
+
+```bash
 bun run dev:gui
 ```
 
diff --git a/docs-site/src/content/docs/tr/reference/code-signing.md b/docs-site/src/content/docs/tr/reference/code-signing.md
index 05ca5399ca9..7367cbd5739 100644
--- a/docs-site/src/content/docs/tr/reference/code-signing.md
+++ b/docs-site/src/content/docs/tr/reference/code-signing.md
@@ -13,7 +13,7 @@ dosyalardan kaynaklanan yanlış alarmları önlemeye yardımcı olur.
 Geçiş sürüyor. Yayın iş akışı hazır; SignPath bunu test sertifikasıyla doğruluyor.
 Üretim sertifikası verilene kadar Windows yayın dosyaları imzasız kalır ve
 SmartScreen bir kez **Ek bilgi → Yine de çalıştır** seçimini isteyebilir.
-Geçişten sonra yayımlanan sürümler **SignPath Foundation** imzası taşır.
+Geçişten sonra iş akışı **SignPath Foundation** ile üretim imzalamayı dener. İmzalama veya doğrulama başarısız olursa, aşağıda açıklandığı gibi özgün imzasız dosya yine de yayımlanabilir.
 
 ## Kod imzalama ilkesi
 
@@ -82,7 +82,8 @@ SignPath çıktı yapılandırmaları: `windows-standalone-zip` (ZIP kökünde t
 | `release-signing` | İmzalanır ve güvenilirliği doğrulanır | İmzalanır ve güvenilirliği doğrulanır |
 
 İstek başarısız olur, zaman aşımına uğrar veya reddedilirse ya da doğrulama
-başarısız olursa iş uyarı kaydeder; imzasız dosyayı özgün güncelleyici imzasıyla yayımlar.
+başarısız olursa iş uyarı kaydeder ve özgün imzasız dosyayı yayımlar. MSI, varsa özgün
+güncelleyici imzasını korur; bağımsız `ocx.exe` dosyasının güncelleyici imzası yoktur.
 
 **Üretim sertifikasına geçiş:** SignPath sertifikayı verince depo değişkeni
 `SIGNPATH_SIGNING_POLICY_SLUG` değerini `release-signing` yapın
diff --git a/docs-site/src/content/docs/tr/reference/configuration/agents.md b/docs-site/src/content/docs/tr/reference/configuration/agents.md
index e57200c9cd1..b3cfd1e3dfa 100644
--- a/docs-site/src/content/docs/tr/reference/configuration/agents.md
+++ b/docs-site/src/content/docs/tr/reference/configuration/agents.md
@@ -12,7 +12,7 @@ kontrol eder.
 | Alan | Tip | Varsayılan | Anlamı |
 | --- | --- | --- | --- |
 | `multiAgentMode?` | `"v1" \| "default" \| "v2"` | `"default"` | `v1` her katalog modelini v1 olarak damgalar; `v2` her modeli v2 olarak damgalar. `default` yukarı akış sabitlemelerini geri yükler (Sol/Terra v2, Luna v1) ve aksi takdirde yerel `multi_agent_v2` bayrağını takip eder. Yeni oturumlara uygulanır. |
-| `subagentModels?` | `string[]` | `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6-luna` | Alt ajan seçicisinde ilk olarak öne çıkan en fazla beş yalın yerel, hesap nitelikli `<secici>/<yerel-openai-modeli>` veya yönlendirilen `saglayici/model` kimliği. Kontrol paneli yalnızca yalın yerel ve yönlendirilen kimlikleri sunar ve kaydederken tam hesap nitelikli seçimleri atlar; tam seçimler için `ocx agent subagents set` kullanın veya yapılandırmayı düzenleyin. [Tek seferlik Astra yükseltmesinden](/reference/configuration/agents/#astra-roster-upgrade) sonra açık bir boş liste korunur. |
+| `subagentModels?` | `string[]` | `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6-luna` | Alt ajan seçicisinde öne çıkan en fazla beş yalın yerel, hesap nitelikli `<selector>/<native-openai-model>` veya yönlendirilen `provider/model` kimliği. Kontrol paneli yeni seçimler için yalın yerel ve yönlendirilen kimlikleri sunar. Kaydederken, geçerli katalogda bulunmayanlar dahil, önceden yapılandırılmış tam hesap nitelikli kimlikleri korur. Yeni bir tam hesap nitelikli kimlik eklemek için `ocx agent subagents set` kullanın veya yapılandırmayı düzenleyin. [Tek seferlik Astra yükseltmesinden](/reference/configuration/agents/#astra-roster-upgrade) sonra açıkça boş bırakılan liste korunur. |
 | `injectionModel?` | `string` | — | Proxy kaynaklı v2 yetkilendirme rehberliğinde kullanılan tercih edilen yerel veya yönlendirilen alt ajan modeli. |
 | `injectionEffort?` | `string` | — | Yalnızca `injectionModel` ile anlamlı olan tercih edilen çaba (`low` ile `ultra` arası). |
 | `injectionPrompt?` | `string` | — | Yerleşik v2 rehberlik gövdesinin yerini alır. `{{model}}`, `{{effort}}`, `{{roster}}` ve `{{fallback}}` destekler. Yapılandırılmış bir `injectionModel`, özel istemi oluşturmak için yeterlidir. |
@@ -134,13 +134,13 @@ kurtarır.
 ```json
 {
   "multiAgentMode": "v2",
-  "subagentModels": ["gpt-5.5", "anthropic/claude-sonnet-5"],
-  "injectionModel": "gpt-5.5",
+  "subagentModels": ["gpt-6.1-sol", "anthropic/claude-sonnet-5"],
+  "injectionModel": "gpt-6.1-sol",
   "injectionEffort": "high",
   "syncCodexSubagentDefaults": true,
-  "subagentModelFallback": ["gpt-5.6-luna"],
+  "subagentModelFallback": ["gpt-6-luna"],
   "subagentModelFallbackByModel": {
-    "gpt-5.5": ["gpt-5.6-luna"]
+    "gpt-6.1-sol": ["gpt-6-luna"]
   },
   "subagentModelFallbackPollMs": 60000,
   "subagentEffortCap": "high"
diff --git a/docs-site/src/content/docs/tr/reference/configuration/server.md b/docs-site/src/content/docs/tr/reference/configuration/server.md
index 0b6a6138590..fb1a3262eb7 100644
--- a/docs-site/src/content/docs/tr/reference/configuration/server.md
+++ b/docs-site/src/content/docs/tr/reference/configuration/server.md
@@ -12,7 +12,7 @@ yardımcı özellikleri nasıl çalıştıracağını kontrol eder.
 | Alan | Tip | Varsayılan | Anlamı |
 | --- | --- | --- | --- |
 | `port` | `number` | `10100` | Proxy dinleme portu. |
-| `hostname?` | `string` | `"127.0.0.1"` | Bağlama adresi. Geri döngü olmayan bağlamalar `OPENCODEX_API_AUTH_TOKEN` gerektirir. |
+| `hostname?` | `string` | `"127.0.0.1"` | Bağlama adresi. Loopback dışında `config.apiKeys` içinde istemci anahtarı veya sırasıyla `OPENCODEX_API_AUTH_TOKEN`, `OCX_API_TOKEN_FILE`, kurulu ve yalnızca sahibinin okuyabildiği `service-api-token` dosyasından çözülen ortak veri token’ı gerekir. [Uzaktan erişime](#remote-access) bakın. |
 | `proxy?` | `string` | — | Giden HTTP(S) veya SOCKS5 proxy URL'si (`socks5://host:port`) ya da `${ENV_VAR}`. HTTP URL'leri değişkenler boşsa `HTTP_PROXY` / `HTTPS_PROXY`'ye yazılır. SOCKS5 URL'leri yerleşik gerçek SOCKS5 tünelini kullanır ve `ALL_PROXY`'ye de yazılır (`ocx start --socks5`); bu süreçte miras `HTTP(S)_PROXY` temizlenir. Geri döngü `NO_PROXY` içinde kalır. |
 | `emptyCompletionRetry?` | `boolean` | `false` | Metin veya araç çağrısı içermeyen bir Responses tamamlamasını aynı istekle bir kez yeniden denemeyi açıkça etkinleştirir. Yeniden deneme ücretlendirilebilir. `OCX_EMPTY_COMPLETION_RETRY=0`, yapılandırmayı değiştirmeden devre dışı bırakır; combo ve routed-compaction turları hariçtir. |
 | `stallTimeoutSec?` | `number` | `300` (public) / kapalı (local) | Akış kesilmeden önce anlamlı üst sunucu ilerlemesi olmadan geçen saniye (Responses ve yerel Chat). Ayarlanmamışsa **yerel** üst sunucu (loopback, private, `.local`/`.lan` adı) için varsayılan kapalı, genel üst sunucu için 300 sn; pozitif değer ikisine de uygulanır (en az 1 sn); `0` sessizlik watchdog'unu her yerde kapatır. Canonical ChatGPT SSE'yi akışsız JSON'a katlayan Responses isteklerinde watchdog kapalı olsa bile bağımsız 15 dakikalık toplam tur sınırı kalır. `/v1/responses/compact` için bekleyen gövde okumaları bu bütçeyi paylaşır ama yerel üst sunucuda bile varsayılan 300 sn'dir; açık değer (`0` dahil) önceliklidir. |
@@ -43,20 +43,18 @@ Komut, geçerli dedicated-provider geçmişi de dahil olmak üzere kullanıcı i
 
 Yerel Chat de üst sunucu çıktısını beklerken `stallTimeoutSec` kullanır. Boş olmayan metin, akıl yürütme, ret içeriği, araç güncellemeleri ve bitiş olayları süreyi yeniler; bağlantıyı canlı tutan yorumlar, yalnızca rol ve yalnızca kullanım bilgileri yenilemez. Yavaş istemcinin okumasını beklemek süreyi duraklatır. Zaman aşımı `upstream_stall_timeout` üretir: akış istemcileri hata olayı, akışsız istemciler HTTP 502 alır. Sonuç tamamlanmadan iptal edilen istek, başarılı bir kısmi yanıt yerine iptal hatası döndürür. Akışsız Chat, LF ve CRLF ayraçlarını ve çok satırlı data alanlarını destekler.
 
+<a id="remote-access"></a>
+
 ## Uzaktan erişim
 
-Varsayılan `127.0.0.1` bağlaması yalnızca geri döngüdür. `0.0.0.0` gibi geri
-döngü olmayan bir adres hem `/api/*` hem de veri düzleminde belirteç kimlik
-doğrulaması gerektirir. Başlamadan önce belirteci dışa aktarın:
+Varsayılan `127.0.0.1` yalnızca loopback’e bağlanır. `0.0.0.0` gibi loopback dışı adreslerde model istekleri `config.apiKeys` içindeki istemci anahtarını veya ortak veri token’ını gerektirir. `/api/*` yönetim yolları loopback’te de ayrı `OPENCODEX_ADMIN_AUTH_TOKEN` ya da oluşturulan yönetici token’ını kullanır. Veri kimlik bilgileri yönetim erişimi sağlamaz; yönetici token’ını model istemcisine vermeyin.
 
 ```bash
 export OPENCODEX_API_AUTH_TOKEN="your-secret-token"
 ocx start
 ```
 
-Proxy bu değişken olmadan uzak bir bağlamayı reddeder. Bir arka plan servisi
-için launchd, systemd veya Görev Zamanlayıcı'nın alması amacıyla `ocx service
-install`'dan önce dışa aktarın. İstemciler şunu göndermelidir:
+Örnek bir ortam token’ı kullanır. `OCX_API_TOKEN_FILE` veya özel `service-api-token` dosyası zaten token sağlıyorsa ya da geçerli bir istemci anahtarı ayarlıysa dışa aktarma gerekmez. `ocx service install` eksik token dosyasını oluşturabilir; bu değişkenin dışa aktarılması zorunlu değildir. Model istemcileri şunu gönderebilir:
 
 ```text
 x-opencodex-api-key: your-secret-token
@@ -64,16 +62,13 @@ x-opencodex-api-key: your-secret-token
 
 | Uç nokta | `Authorization: Bearer` | `x-opencodex-api-key` | `x-api-key` |
 | --- | --- | --- | --- |
-| `/v1/responses` | kabul edilmez | **gerekli** | kabul edilmez |
-| `/v1/chat/completions` | kabul edilmez | **gerekli** | kabul edilmez |
+| `/v1/responses` | kabul edilir | kabul edilir | kabul edilmez |
+| `/v1/chat/completions` | kabul edilir | kabul edilir | kabul edilmez |
 | `/v1/messages` | kabul edilir | kabul edilir | kabul edilir |
 | `/v1/messages/count_tokens` | kabul edilir | kabul edilir | kabul edilir |
 | `/v1/models` | kabul edilir | kabul edilir | kabul edilir |
 
-Responses ve Chat Completions, olası Codex Direct doğrudan geçişi için
-`Authorization`'ı ayırır, bu nedenle orada yalnızca özel kabul başlığı kabul
-edilir. Kontrol paneli tarafından oluşturulan `apiKeys`, başlangıçtan sonra
-ortam belirtecinin yerini alabilir; adaylar sabit zamanda karşılaştırılır.
+Responses ve Chat Completions, tanınan veri düzlemi kimlik bilgisini `x-opencodex-api-key` üzerinden; bu özel başlık yoksa veya kenar boşlukları silinince boş kalıyorsa `Authorization: Bearer` üzerinden kabul eder. Kenar boşlukları silindikten sonra boş olmayan özel başlık, geçersiz olsa da önceliklidir; geçerli bearer bu reddi gidermez. İlgisiz bearer proxy erişimi vermez ve bu yollar `x-api-key` kabul etmez. Oluşturulan `apiKeys` ve ortak veri token’ı sabit zamanda karşılaştırılır; yönetici kimlik bilgileri model erişimi sağlamaz.
 
 Messages ve `count_tokens`, yönlendirilen istemci uyumluluğu için üç kabul
 formunu da kabul etmeye devam eder. Yerel Anthropic doğrudan geçişi geri döngü
diff --git a/docs-site/src/content/docs/tr/reference/management-api.md b/docs-site/src/content/docs/tr/reference/management-api.md
index 95d8270c1b3..fccd18a96d2 100644
--- a/docs-site/src/content/docs/tr/reference/management-api.md
+++ b/docs-site/src/content/docs/tr/reference/management-api.md
@@ -12,6 +12,8 @@ Etkileşimli bir istemci için [Web Kontrol Panelini](/tr/guides/web-dashboard/)
 veya otomasyon oluştururken bu referansı kullanın. Kalıcı değerler nihai olarak
 [Yapılandırma](/tr/reference/configuration/) bölümünü takip eder.
 
+<a id="authentication-model"></a>
+
 ## Kimlik doğrulama modeli
 
 Yönetim API'sinin, veri düzlemi API anahtarlarından bağımsız kendi yönetici
diff --git a/docs-site/src/content/docs/troubleshooting/codex-cannot-sign-in.md b/docs-site/src/content/docs/troubleshooting/codex-cannot-sign-in.md
index e1f84d88b7c..45e8341e6c0 100644
--- a/docs-site/src/content/docs/troubleshooting/codex-cannot-sign-in.md
+++ b/docs-site/src/content/docs/troubleshooting/codex-cannot-sign-in.md
@@ -52,11 +52,25 @@ back, `ocx restore back` re-points Codex at the proxy.
 
 **Or bring the proxy back instead:**
 
+In one terminal, start the foreground proxy and leave that terminal open:
+
 ```bash
 ocx start
+```
+
+In a second terminal, confirm that `ocx ready --json` reports `ready: true` before installing the service. Then repeat the checks to verify the resulting service:
+
+```bash
+ocx ready --json
+ocx status --json
 ocx service install   # keep it running across restarts
+ocx ready --json
+ocx status --json
+ocx service status --json
 ```
 
+An explicit service install stops the tracked foreground proxy before starting the managed service, so the first terminal may exit during installation. It refuses installation if that cleanup cannot be completed safely, then checks that an OpenCodex runtime answers on the installed service port. The pre-install readiness check only verifies the foreground proxy; use the post-install readiness, proxy status and service status together to check the handover.
+
 `ocx status` reports whether the proxy is answering and whether Codex is
 currently routed through it. `ocx doctor` explains the same state in more
 detail and names the repair it recommends.
diff --git a/docs-site/src/content/docs/troubleshooting/spend-ledger-synced-folder.md b/docs-site/src/content/docs/troubleshooting/spend-ledger-synced-folder.md
index 4e8cb7b2d07..91a4a00abdb 100644
--- a/docs-site/src/content/docs/troubleshooting/spend-ledger-synced-folder.md
+++ b/docs-site/src/content/docs/troubleshooting/spend-ledger-synced-folder.md
@@ -19,8 +19,9 @@ Spend-ledger storage could not be opened safely (journal: extra-hard-link).
 
 opencodex keeps a spend ledger in its state directory (`~/.opencodex` by default, or
 `OPENCODEX_HOME`): a journal file, `spend-ledger.jsonl`, and a salt file, `spend-ledger.salt`.
-Before every write it checks that each file is a regular file owned by you, is not a symbolic
-link, and has exactly one directory entry. A second hard link would mean another name elsewhere
+Before every write it checks that each file is regular, is not a symbolic link,
+and has exactly one directory entry. Outside Windows it also checks that you own the file;
+the owner comparison is not performed on Windows. A second hard link would mean another name elsewhere
 on the volume can see or change the same bytes, so opencodex refuses instead of writing through
 it. This check stays strict on purpose.
 
@@ -29,7 +30,7 @@ it. This check stays strict on purpose.
 | `extra-hard-link` | Another directory entry points at the same file. |
 | `symbolic-link` | The ledger file is a symbolic link. |
 | `not-regular-file` | Something other than a regular file sits at the ledger path. |
-| `foreign-owner` | The file belongs to a different user. |
+| `foreign-owner` | The file belongs to a different user (checked outside Windows). |
 | `invalid-salt` | The salt file exists but its content is not a valid salt. |
 
 The role in the message is `journal`, `journal-compaction` (the temporary file written while
diff --git a/docs-site/src/content/docs/troubleshooting/windows-memory.md b/docs-site/src/content/docs/troubleshooting/windows-memory.md
index 50bb093fd21..d6c5526e500 100644
--- a/docs-site/src/content/docs/troubleshooting/windows-memory.md
+++ b/docs-site/src/content/docs/troubleshooting/windows-memory.md
@@ -10,9 +10,7 @@ what is actually happening and what you can do about it, honestly.
 
 ## Root cause: upstream Bun runtime issues
 
-opencodex bundles the Bun runtime (currently **1.3.14**). The memory growth is
-driven by known upstream Bun issues, not by JavaScript-level leaks in the
-proxy:
+Older OpenCodex versions bundled Bun **1.3.14**. The issue table below records the investigation as of July 23, 2026; it is historical evidence, not a statement of current upstream issue status. The current package bundles Bun **1.4.4**, and the stream-capability gate recognizes stable Bun 1.4.0 or newer as carrying the async-pull cancellation fix. This does not prove that every source of Windows memory growth is resolved.
 
 | Bun issue | State (checked 2026-07-23) |
 |---|---|
@@ -20,15 +18,11 @@ proxy:
 | [#32111](https://github.com/oven-sh/bun/issues/32111) — crash when a client aborts an async-pull stream | Fix [PR #32120](https://github.com/oven-sh/bun/pull/32120) merged 2026-06-21; not assumed present in 1.3.14. Note: this crash is **not Windows-specific** (it also reproduced on macOS/Linux) |
 | [PR #31654](https://github.com/oven-sh/bun/pull/31654) — `node:net` socket handle leak | Still **open** upstream |
 
-On Windows, opencodex must keep streaming responses on a conservative code
-path to avoid the #32111 crash, and that path is the one most exposed to the
-backpressure issue: a slow or stalled client can leave the runtime buffering
-upstream data in native memory that JavaScript cannot bound.
+On older runtimes, Windows used the conservative tee path to avoid the async-pull cancellation crash; a slow client could still leave native buffering that JavaScript cannot bound. With the current stable runtime, Windows `auto` selects the bounded eager relay when no client rewrite is needed. An explicit `legacy-tee` keeps the old path. On macOS, `auto` still keeps tee and eager relay requires explicit opt-in. Inspect the selected runtime and actual stream-mode decision before diagnosing memory growth.
 
 ## What opencodex does today
 
-Bounded mitigation and visibility — **not a fix**. On the bundled 1.3.14
-runtime the leak itself remains an upstream problem:
+Bounded mitigation and visibility help diagnose retention; they do not establish that every memory-growth report is fixed:
 
 - **Memory watchdog** — the proxy samples its own memory every minute and logs a
   rate-limited warning when observed memory crosses 4 GiB. Observed memory is
@@ -37,7 +31,7 @@ runtime the leak itself remains an upstream problem:
   retention.
 - **`ocx doctor`** — a "Memory / runtime" section shows the *service*
   process's Bun version, RSS, external/ArrayBuffers counters, JS-heap context,
-  and stream-mode decision. On the bundled Bun 1.3.14 runtime, `heapUsed` /
+  and stream-mode decision. On older Bun 1.3.14 runtimes, `heapUsed` /
   `jscHeap` alone are not a leak discriminator; compare observed memory with
   `responseState` and repeated samples before assigning an app-level leak.
 - **`GET /api/system/memory`** — the same data over the authenticated
@@ -97,11 +91,7 @@ runtime the leak itself remains an upstream problem:
 
   For a scriptable snapshot of the complete authenticated payload, run
   `ocx observe memory --json`; the CLI forwards the same response-state fields.
-- **A gated alternative stream path** — a bounded single-reader relay that
-  removes the unbounded buffering shape entirely. On Windows it becomes the
-  default automatically once a bundled Bun release verifiably carries the
-  #32111 fix; today it is opt-in only (see below). On macOS it stays opt-in
-  even after such a release — flipping macOS `auto` is a separate decision.
+- **A gated alternative stream path** — a bounded single-reader relay. On Windows, `auto` selects it when the supported runtime and response shape permit; explicit `legacy-tee` preserves the tee path. On macOS, `auto` stays on tee and `eager-relay` remains opt-in. Check the actual decision for the selected runtime.
 
 Catalog metadata reads use the selected runtime's last confirmed bundled catalog.
 Cold or changed selections refresh through asynchronous version/model probes, so
@@ -120,22 +110,11 @@ restart it.
 
 ## Your options
 
-1. **Wait for a bundled runtime update.** Once a Bun release verifiably
-   carries the fixes, opencodex will bump the bundled runtime and the safer
-   stream path turns on automatically on Windows (macOS keeps requiring the
-   explicit opt-in below).
+1. **Check the selected runtime and actual stream decision.** The current package bundles Bun 1.4.4 and the capability gate accepts stable releases from 1.4.0. Windows `auto` can already select bounded eager relay when applicable; another bundled update is not required to enable it. An explicit `legacy-tee` selection preserves tee. This does not prove every source of memory growth is fixed.
 
 2. **Run a Bun runtime you trust with `OPENCODEX_BUN_PATH`.** Set the variable before launching `ocx` from that shell, then run `ocx service repair` to bake the selected runtime into the service definition. A later project `.env` does not change selection; changing the environment alone does not update an installed service.
 
-3. **Opt into the bounded relay with `streamMode: "eager-relay"`.** Two ways:
-   edit `config.json` (add `"streamMode": "eager-relay"`), or call the
-   management API — a `PUT /api/settings` with `{"streamMode":"eager-relay"}`
-   applies to new turns without a restart. **Crash risk warning:** on Bun
-   1.3.14 this uses the stream shape affected by #32111, which can crash the
-   process mid-stream (on any OS, not just Windows). The service manager will
-   restart it, but in-flight requests fail. `"legacy-tee"` pins the current
-   default. On Windows, `"auto"` (default) lets the runtime gate decide. On
-   macOS, `"auto"` always stays on tee; explicit `"eager-relay"` is the opt-in.
+3. **Select the bounded relay with `streamMode: "eager-relay"`.** Edit `config.json` (add `"streamMode": "eager-relay"`) or call `PUT /api/settings` with `{"streamMode":"eager-relay"}`; the API change applies to new turns without a restart. The Bun 1.3.14 crash warning is historical: that release used the stream shape affected by #32111 on any OS, interrupting in-flight requests even when the service restarted. `"legacy-tee"` explicitly forces the old tee path. On Windows, `"auto"` uses the runtime gate and response conditions; on macOS, `"auto"` stays on tee and `"eager-relay"` is the opt-in.
 
 If you try any of these on a real Windows workload, please report the before
 and after `ocx doctor` memory sections on
diff --git a/docs-site/src/content/docs/zh-cn/getting-started/for-agents.md b/docs-site/src/content/docs/zh-cn/getting-started/for-agents.md
index 182b79a38ab..3d607bbf285 100644
--- a/docs-site/src/content/docs/zh-cn/getting-started/for-agents.md
+++ b/docs-site/src/content/docs/zh-cn/getting-started/for-agents.md
@@ -14,7 +14,11 @@ npm install -g --allow-scripts=bun @bitkyc08/opencodex
 ocx --version
 ```
 
-选择一种方式运行代理：
+启动代理前，在交互式终端运行 `ocx init`，以使用设置时选择的端口：
+
+```bash
+ocx init
+```
 
 ```bash
 # Foreground: blocks this terminal until stopped.
@@ -24,12 +28,6 @@ ocx start
 ocx service
 ```
 
-在交互式终端中运行 `ocx init`。如果 `ocx start` 正占用前台，请使用第二个终端：
-
-```bash
-ocx init
-```
-
 该向导会写入 `$OPENCODEX_HOME/config.json`（通常是 `~/.opencodex/config.json`）。它还可以把代理地址注入 Codex 的 `config.toml`，并安装可选的 Codex 自动启动 shim。`ocx init` 从不启动代理。若要完全非交互式地完成设置，请改用下面所示的 `ocx provider add` 来配置提供方，而不是运行向导。
 
 :::caution[GitHub star consent]
@@ -56,17 +54,19 @@ ocx health --json
 
 ```bash
 ocx provider add anthropic-apikey \
-  --api-key "$ANTHROPIC_API_KEY" \
+  --api-key '${ANTHROPIC_API_KEY}' \
   --set-default
 ```
 
+请保留单引号，以便按字面传递环境变量引用，而不是把密钥值放入进程参数或保存到配置中。启动代理前，请在其启动环境中设置 `ANTHROPIC_API_KEY`，并为模型同步等会解析凭据的 CLI 进程提供该变量。稍后在另一终端中 export 不会更新正在运行的代理。后台服务需要配置启动环境并重启；安装服务不会自动保留终端中的任意提供商变量。
+
 `ocx provider add` 会写入本地配置。如果已经有正在运行的代理，并且你希望立刻把模型同步到 Codex，请加上 `--sync`；否则之后再运行 `ocx sync`。不在注册表中的自定义提供方同时需要 `--adapter` 和 `--base-url`。
 
 在所有目标提供方都配置好且代理正在运行后，创建一个故障转移 combo：
 
 ```bash
 ocx combo set main \
-  --targets anthropic/claude-opus-4-8,openai/gpt-5.6-sol \
+  --targets anthropic-apikey/claude-opus-4-8,openai/gpt-5.6-sol \
   --strategy failover
 ```
 
@@ -74,11 +74,11 @@ ocx combo set main \
 
 ## 远程和 LAN 绑定
 
-默认的回环绑定不需要 API token。非回环绑定，例如 `0.0.0.0`，则需要 `OPENCODEX_API_AUTH_TOKEN`；没有它，代理会拒绝启动。请在 `ocx start` 之前设置该变量，或者在 `ocx service install` 之前设置，这样服务就能接收到它：
+普通回环模型路由不需要数据令牌。绑定到 `0.0.0.0` 等非回环地址时，需要 `config.apiKeys` 中配置的客户端密钥，或从 `OPENCODEX_API_AUTH_TOKEN`、`OCX_API_TOKEN_FILE`、仅所有者可读的 `service-api-token` 文件解析出的共享令牌。文件不存在时，`ocx service install` 可以创建它。如果通过环境变量提供令牌，请在 `ocx start` 或 `ocx service install` 之前设置：
 
 ```bash
 export OPENCODEX_API_AUTH_TOKEN="your-secret-token"
 ocx service install
 ```
 
-之后，客户端必须对其管理请求和模型请求进行身份验证。在把 opencodex 暴露到本机之外之前，请先阅读 [Configuration](/reference/configuration/) 中的远程访问规则。
+模型请求使用数据平面认证。管理使用独立凭据：`OPENCODEX_ADMIN_AUTH_TOKEN` 或受保护文件中生成的管理员令牌；数据令牌不授予管理访问权。仪表板遵循[管理 API](/zh-cn/reference/management-api/#authentication-model)的会话和访问规则。切勿把管理员令牌交给模型客户端。向本机之外开放代理前，请阅读[远程访问](/zh-cn/reference/configuration/server/#remote-access)。
diff --git a/docs-site/src/content/docs/zh-cn/getting-started/quickstart.md b/docs-site/src/content/docs/zh-cn/getting-started/quickstart.md
index dd1dc17cced..1e793740e95 100644
--- a/docs-site/src/content/docs/zh-cn/getting-started/quickstart.md
+++ b/docs-site/src/content/docs/zh-cn/getting-started/quickstart.md
@@ -33,18 +33,27 @@ ocx init
 
 ## 2. 启动代理
 
+运行以下两种方式之一；代理会保持在前台运行：
+
 ```bash
 ocx start            # defaults to port 10100
+```
+
+也可以改用其他端口：
+
+```bash
 ocx start --port 8080
 ```
 
+保持此终端打开。后续状态检查和仪表板命令需在另一个设置相同 `OPENCODEX_HOME` 的终端中运行。
+
 启动时，opencodex 会：
 
 - 将其 PID 写入 `~/.opencodex/ocx.pid`（并拒绝重复启动）；
 - 在 provider 支持时发现实时模型，并**把原生与已路由条目同步进 Codex 的模型目录**；
 - 监听 `http://localhost:<port>/v1`。
 
-如果请求的端口已被占用，`ocx start` 会停止并告知你是什么占用了该端口：如果那里响应的是 opencodex，请先运行 `ocx stop`；也可以使用 `ocx start --port <port>` 在空闲端口上启动。它不会自行切换到其他端口；旧行为会让两个代理同时运行，并将 Codex 重新指向后启动的代理。
+使用同一 `OPENCODEX_HOME` 的 opencodex 正在运行时，即使端口空闲，也无法再次启动。请先用 `ocx stop` 停止所属实例，或选择另一个 `OPENCODEX_HOME`。兄弟实例在自己的端口处理直接请求，不会改变 Codex、Grok 或 Claude 的共享路由。若无关进程占用端口，`ocx start` 会说明情况；请用 `ocx start --port <port>` 选择空闲端口。它不会自动切换端口。
 
 检查它：
 
diff --git a/docs-site/src/content/docs/zh-cn/guides/codex-app-models.md b/docs-site/src/content/docs/zh-cn/guides/codex-app-models.md
index fcfa28dffac..ec68c22333d 100644
--- a/docs-site/src/content/docs/zh-cn/guides/codex-app-models.md
+++ b/docs-site/src/content/docs/zh-cn/guides/codex-app-models.md
@@ -120,7 +120,7 @@ fast_mode = true
 
 ## 子代理选择
 
-Codex 会按 `priority` 升序对选择器可见的目录条目排序，并把前五个作为 `spawn_agent` 模型 override 暴露出来。仪表盘 Subagents 页面最多可以选择并保存五个裸原生 id 或路由 `provider/model` id。手动设置的 `subagentModels` 也支持账户限定的 `<selector>/<native-openai-model>` id，但仪表盘不会提供这些精确 id；保存该页面会用仪表盘中可见的选项替换整个列表。opencodex 会按所选顺序分配较低的目录 priority；启用账户限定的选择器行时，裸原生选择会展开为 selector-qualified 分组。其他模型仍然可以通过精确 id 调用。
+Codex 会按 `priority` 升序对选择器可见的目录条目排序，并把前五个作为 `spawn_agent` 模型 override 暴露出来。仪表盘 Subagents 页面最多可以选择并保存五个裸原生 id 或路由 `provider/model` id。手动设置的 `subagentModels` 也支持账户限定的 `<selector>/<native-openai-model>` id。保存列表时，仪表盘会保留这些已保存的精确 id，包括当前目录中已不可用的模型。opencodex 会按所选顺序分配较低的目录 priority；启用账户限定的选择器行时，裸原生选择会展开为 selector-qualified 分组。其他模型仍然可以通过精确 id 调用。
 
 精选模型列表与 Dashboard 的 **Sub-agent delegation** 选择彼此独立。它只决定 Codex 先提供哪些 override；它不会自己选择模型，也不会触发委派。
 
diff --git a/docs-site/src/content/docs/zh-cn/guides/grok-build.md b/docs-site/src/content/docs/zh-cn/guides/grok-build.md
index 498361a75be..85bb552b2bd 100644
--- a/docs-site/src/content/docs/zh-cn/guides/grok-build.md
+++ b/docs-site/src/content/docs/zh-cn/guides/grok-build.md
@@ -93,11 +93,11 @@ model = "anthropic/claude-opus-4-8"
 model_provider = "opencodex"
 ```
 
-如果代理可通过网络访问，请把 `base_url` 指向 `grok` 实际可以连接的地址，并使用你的接入令牌：
+提供令牌前，请先配置 TLS 前端并使用其 HTTPS URL，或使用本地隧道的回环地址。Grok 会把 `api_key` 的字面值保存到 `~/.grok/config.toml`；请限制文件访问权限，并将其排除在版本控制和共享备份之外。
 
 ```toml
 [model_providers.opencodex]
-base_url = "http://192.168.1.10:10100/v1"   # the reachable host, not 127.0.0.1
+base_url = "https://proxy.example.com/v1"   # configured TLS frontend
 api_backend = "responses"
 api_key = "your-OPENCODEX_API_AUTH_TOKEN"
 
diff --git a/docs-site/src/content/docs/zh-cn/guides/image-bridge.md b/docs-site/src/content/docs/zh-cn/guides/image-bridge.md
index 8b7b8c24f4f..72722b56f56 100644
--- a/docs-site/src/content/docs/zh-cn/guides/image-bridge.md
+++ b/docs-site/src/content/docs/zh-cn/guides/image-bridge.md
@@ -10,7 +10,7 @@ description: 在使用非 OpenAI 提供方时，将 image_generation 托管工
 ## 前提条件
 
 - **启用桥接**：在配置中设置 `images.bridgeEnabled: true`（默认关闭，以避免意外产生 xAI 费用 - 见下文的 [配置](#配置)）。
-- 配置一个带有 **API 密钥** 的 `xai` provider 条目。桥接会将执行固定到注册表中的 xAI Images 端点（`https://api.x.ai/v1`）；任何已配置的 `baseUrl` 覆盖都会被图像调用忽略。仅有 OAuth / `ocx login xai` **不会** 启用这条 sidecar 循环。同一项 `bridgeEnabled` 会启用另一条 Codex `/v1/images` 中继，让内置 `image_gen` 客户端用 Grok CLI 授权调用 Imagine — 见 [内置图像生成](/guides/codex-integration/#built-in-image-generation-image_gen)。若该授权（或 xAI API key）缺失，`/v1/images` 会返回错误，而不会落到 ChatGPT。只有在 `images.bridgeEnabled` 为 `true` 且未设置 `images.provider` 时，这条中继才拥有该路由；显式设置 `images.provider` 后，`/v1/images` 归该 provider 处理，其校验错误按原样返回，不会改由 xAI 重试。
+- 配置一个带有 **API 密钥** 的 `xai` provider 条目。桥接会将执行固定到注册表中的 xAI Images 端点（`https://api.x.ai/v1`）；任何已配置的 `baseUrl` 覆盖都会被图像调用忽略。仅有 OAuth / `ocx login xai` **不会** 启用这条 sidecar 循环。同一项 `bridgeEnabled` 会启用另一条 Codex `/v1/images` 中继，让内置 `image_gen` 客户端用 Grok CLI 授权调用 Imagine — 见 [内置图像生成](/guides/codex-integration/#built-in-image-generation-image_gen)。若存在 xAI provider 但既没有该授权也没有 API key，`/v1/images` 会返回错误，不会回退到 ChatGPT。若根本没有 xAI provider，中继不处理该请求，常规选择仍可能使用已配置的 ChatGPT 图像 provider。只有在 `images.bridgeEnabled` 为 `true` 且未设置 `images.provider` 时，这条中继才拥有该路由；显式设置 `images.provider` 后，`/v1/images` 归该 provider 处理，其校验错误按原样返回，不会改由 xAI 重试。
 
   ```json
   {
diff --git a/docs-site/src/content/docs/zh-cn/guides/minimax.md b/docs-site/src/content/docs/zh-cn/guides/minimax.md
index ca0b375156e..7cbffc00b50 100644
--- a/docs-site/src/content/docs/zh-cn/guides/minimax.md
+++ b/docs-site/src/content/docs/zh-cn/guides/minimax.md
@@ -18,6 +18,11 @@ Combo 的“图片 / 多模态”开关才可用。该开关控制图片附件
 
 ```bash
 ocx start
+```
+
+让代理在此终端中继续运行。在另一个终端中启用集成并启动 MiniMax Code：
+
+```bash
 ocx integration client enable --client mcode
 ocx mcode
 ```
diff --git a/docs-site/src/content/docs/zh-cn/guides/model-routing.md b/docs-site/src/content/docs/zh-cn/guides/model-routing.md
index 1b51859ec35..41a44d9fee6 100644
--- a/docs-site/src/content/docs/zh-cn/guides/model-routing.md
+++ b/docs-site/src/content/docs/zh-cn/guides/model-routing.md
@@ -51,8 +51,8 @@ transport；这些凭证路径互不 fallback。
    | `claude-`、`claude-sonnet-`、`claude-opus-`、`claude-haiku-` | `anthropic` |
    | `llama-`、`mixtral-`、`gemma-` | `groq` |
 
-   该匹配器只检查名称。与 `defaultModel` / `models[]` 扫描不同，目前即使匹配提供商的 `disabled`
-   为 true，它也不会跳过该提供商。
+   该匹配器只检查名称。与 `defaultModel` / `models[]` 扫描一样，匹配提供商的 `disabled` 为 true
+   时会跳过该提供商。
 
 7. **某个提供商的 `models[]`** —— 如果前缀规则没有命中，而某个启用的提供商在 `models[]` 中列出
    该 id，则使用该提供商。规则 4 已经会在其他 provider 的 `models[]` 声明匹配前，把 bare `gpt-*`
diff --git a/docs-site/src/content/docs/zh-cn/guides/opencode.md b/docs-site/src/content/docs/zh-cn/guides/opencode.md
index 1210e7ea5f8..6fc3feb6931 100644
--- a/docs-site/src/content/docs/zh-cn/guides/opencode.md
+++ b/docs-site/src/content/docs/zh-cn/guides/opencode.md
@@ -75,9 +75,11 @@ loopback 示例：
 
 非 loopback 示例：
 
+这是远程客户端的手动配置示例。请先配置 TLS 前端，再使用其 HTTPS URL；OpenCodex 本身不终止 TLS，`ocx opencode` 也不会自动发现该 URL。即使在局域网中，明文 HTTP 也会在传输时暴露准入凭据。另一种方式是让代理绑定回环地址，并使用本地 SSH 隧道。参见[数据监听器的 TLS](/zh-cn/guides/remote-hub/#giving-the-data-listener-tls)。
+
 ```json
 "options": {
-  "baseURL": "http://192.168.1.10:10100/v1",
+  "baseURL": "https://proxy.example.com/v1",
   "headers": {
     "x-opencodex-api-key": "{env:OPENCODEX_OPENCODE_API_KEY}"
   }
diff --git a/docs-site/src/content/docs/zh-cn/guides/pi.md b/docs-site/src/content/docs/zh-cn/guides/pi.md
index a7df3b9cfa1..e979c205f9c 100644
--- a/docs-site/src/content/docs/zh-cn/guides/pi.md
+++ b/docs-site/src/content/docs/zh-cn/guides/pi.md
@@ -3,7 +3,7 @@ title: Pi
 description: 在 Pi 中使用任意已路由模型 - `ocx export` 会为 Pi 的 `models.json` 写入一个自定义 provider 块，并连接到正在运行的代理。
 ---
 
-Pi 从一个全局 JSON 文件而不是环境变量中读取 providers，所以 opencodex 不会启动它。相反，`ocx export` 会序列化 `opencodex` provider 块 - 基础 URL、模型列表，以及 Pi 会插值的 env 引用 - 然后你把它合并到自己的配置中。
+Pi 从单个全局 JSON 文件读取提供商。opencodex 不会启动 Pi；`ocx export` 输出 `opencodex` 提供商块，其中包含基础 URL、模型列表和非秘密的本地密钥占位符。请将其合并到现有配置中。
 
 ## 快速开始
 
@@ -11,10 +11,15 @@ Pi 从一个全局 JSON 文件而不是环境变量中读取 providers，所以
 
 ```bash
 ocx start
+```
+
+保持此进程运行。在另一个终端中输出配置：
+
+```bash
 ocx export --client pi
 ```
 
-输出会先显示 JSON，然后打印目标路径、合并警告、env 导出行，以及有多少模型带有权威上下文窗口限制。
+JSON 之后会显示目标路径、合并警告、回环使用提示，以及具有已确认上下文限制的模型数量。此导出仅支持无需认证的回环代理，不会配置远程访问认证。
 
 ```json
 {
@@ -22,7 +27,7 @@ ocx export --client pi
     "opencodex": {
       "baseUrl": "http://127.0.0.1:10100/v1",
       "api": "openai-completions",
-      "apiKey": "$OPENCODEX_API_KEY",
+      "apiKey": "opencodex-loopback",
       "compat": {
         "sendSessionAffinityHeaders": true,
         "supportsDeveloperRole": false
@@ -70,22 +75,7 @@ ocx export --client pi --json > ~/opencodex-pi-models.json   # or redirect the b
 
 ## 准入密钥
 
-这里有两个很容易混淆的 key，但这个文件里只会出现第一个：
-
-| Key | 它是什么 | 它存放在哪里 |
-| --- | --- | --- |
-| 代理准入密钥 | opencodex 自己的凭据，在仪表盘的 **API** 选项卡中生成 | 通过 `apiKey` 以 `$OPENCODEX_API_KEY` 形式引用；实际值保存在你的环境中 |
-| Provider key | 你的 Anthropic / OpenAI / OpenRouter key | opencodex 自己的配置中，见 [Providers](/guides/providers/) |
-
-导出的配置只包含引用，从不包含 secret。Pi 会插值裸的 `$NAME`，所以变量是：
-
-```bash
-export OPENCODEX_API_KEY=<your key>
-```
-
-这个名字只属于 Pi。opencode 使用不同的变量（`OPENCODEX_OPENCODE_API_KEY`，以 `{env:…}` 形式出现） - 见 [opencode 指南](/guides/opencode/)。
-
-**回环代理根本不需要 key。** opencodex 默认绑定 `127.0.0.1`，在那里不做任何认证，所以 `$OPENCODEX_API_KEY` 引用是无效的，你可以不设置这个变量。它只在 `hostname` 超出回环范围时才有意义，而这也是代理会在没有 token 的情况下拒绝启动的时候 - 见 [远程访问](/zh-cn/reference/configuration/server/#远程访问)。
+导出的 `apiKey` 是非秘密占位符 `opencodex-loopback`，无需导出密钥环境变量。导出器只允许无需认证的回环代理，会拒绝远程代理或受令牌保护的代理。提供商凭证保留在 opencodex 配置中，参见[提供商](/zh-cn/guides/providers/)；不要把上游提供商密钥放入此 Pi 配置块。远程访问应使用支持代理访问凭证的集成。修改占位符不会启用 Pi 的远程导出。
 
 ## 模型元数据
 
@@ -93,7 +83,11 @@ export OPENCODEX_API_KEY=<your key>
 
 输出上限使用目录或生成元数据中已知的模型上限，仅在未知时回退到 `32000`。输出上限始终不超过 context window；已知低于 `32000` 的上限也会保留。
 
-有两个字段是刻意省略的。`cost` 需要全部四个价格字段，而 opencodex 没有已路由模型的价格数据 - 如果输出 0，会等于断言所有模型都是免费的。`reasoning` 在 Pi 里是一个布尔值，而目录里是一个 effort 层级，把二者互相映射只能是猜测。
+`cost` 有意省略：它要求完整的四个价格字段，而 opencodex 没有路由模型的价格数据。输出零会误称所有模型都免费。
+
+当目录的 effort 层级**非空**时，导出 `"reasoning": true`；层级缺失或显式为空时则不声明推理支持。`thinkingLevelMap` 用 `null` 隐藏没有已声明目标的 Pi 层级，防止显示或发送列表之外的值。若声明了 `ultra` 而没有 `max`，则把 Pi 的 `max` 映射到 `ultra`。需要其他映射时，请按 Pi 文档手动修改 `thinkingLevelMap`。
+
+`reasoning` 是从目录派生的 Pi 界面元数据，不证明上游原生支持推理参数。实际 `reasoning_effort` 取决于适配器和模型，可被透传、转换、限制、模拟或省略（例如 `noReasoningModels`）。此布尔值只决定 Pi 是否提供该控件。
 
 ## Schema 状态
 
diff --git a/docs-site/src/content/docs/zh-cn/guides/remote-hub.md b/docs-site/src/content/docs/zh-cn/guides/remote-hub.md
index 7abc9f4f45e..16c2d899308 100644
--- a/docs-site/src/content/docs/zh-cn/guides/remote-hub.md
+++ b/docs-site/src/content/docs/zh-cn/guides/remote-hub.md
@@ -12,7 +12,13 @@ Remote Hub 将提供商凭据、模型目录和使用记录保存在一台主机
 `standalone` 在一台机器上运行全部功能；`hub` 保存提供商密钥和使用记录；`client` 只保存连接状态和专属数据密钥。
 
 ```bash
-ocx connect https://hub-name.tailnet-name.ts.net --pairing-code-stdin
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the one-time code without echoing it or putting it in shell history.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+  --management-url https://hub-name.tailnet-name.ts.net \
+  --pairing-code-stdin
+unset pairing_code
 ocx connect status
 ocx sync
 ```
@@ -65,6 +71,8 @@ tailscale serve status
 
 `/healthz` 只证明进程存活。还必须验证 `/readyz`、经过身份验证的 `GET /v1/catalog` 和一次真实模型响应。管理端口只能监听 `127.0.0.1`。自建 TLS 代理应使用 `tailscale cert hub-name.tailnet-name.ts.net`，并仅代理到 `127.0.0.1:10101`。不要伪造 `Tailscale-User-*`；没有可信身份时请使用一次性配对。
 
+<a id="giving-the-data-listener-tls"></a>
+
 ### 为数据监听器提供 TLS
 
 上面的 Serve 映射只发布**管理**入口。该入口从不提供 `/v1/*`、`/healthz` 或 `/readyz`，因此仅凭它并不能让远程客户端获得可用的数据平面。opencodex 自身也不终结 TLS：监听器是明文 HTTP，HTTPS 始终由运维方自建的前端负责。
@@ -85,9 +93,13 @@ Serve 只接受有限的几个 HTTPS 端口。请用 `tailscale serve status` 
 连接时把两个 origin 分开写。位置参数 URL 是**数据** origin，`/readyz` 和 `/v1/catalog` 都从这里获取；`--management-url` 是用于配对和密钥签发的控制台 origin。两者不必共用端口：
 
 ```bash
-ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the management admin token without echoing it.
+read -r -s -p 'Admin token: ' admin_token; printf '\n'
+printf '%s\n' "$admin_token" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
   --management-url https://hub-name.tailnet-name.ts.net \
   --admin-token-stdin
+unset admin_token
 ```
 
 省略 `--management-url` 时，它取自 `/readyz` 响应，而该响应报告的正是 `hub.managementPublicOrigin`。两个 origin 不同时，显式写出更清楚。
@@ -101,10 +113,16 @@ Serve 就绪后，请针对 HTTPS 数据 origin 重新执行验收检查：`/rea
 ## OAuth、密钥轮换与断开
 
 ```bash
-ocx config set oauthOpenBrowser false
-ocx connect rotate --pairing-code-stdin
-# 仅限 HTTPS：
-ocx connect rotate --admin-token-stdin
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: choose one authority source.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect rotate --pairing-code-stdin
+unset pairing_code
+
+# Alternatively, only over HTTPS, use the management admin token:
+read -r -s -p 'Admin token: ' admin_token; printf '\n'
+printf '%s\n' "$admin_token" | ocx connect rotate --admin-token-stdin
+unset admin_token
 ```
 
 通过 `POST /api/oauth/login` 启动 OAuth。如果回调无法到达 hub，将最终 URL 或授权码作为 `{provider,input}` 发送到 `POST /api/oauth/login/code`。不要把 OAuth 码放入 argv 或日志。
diff --git a/docs-site/src/content/docs/zh-cn/guides/remote-workspace.md b/docs-site/src/content/docs/zh-cn/guides/remote-workspace.md
index 950e6bf3bfa..08ed9315207 100644
--- a/docs-site/src/content/docs/zh-cn/guides/remote-workspace.md
+++ b/docs-site/src/content/docs/zh-cn/guides/remote-workspace.md
@@ -23,9 +23,16 @@ Remote Workspace 需要主动启用，尚未面向生产环境发布。Linux 提
 
 计算机 1 保存所有编程代理的登录和模型会话。先在其上安装并登录所需代理，然后以 Hub 身份运行 OpenCodex：
 
+在此终端中让 Hub 持续在前台运行：
+
 ```bash
 ocx config set runtimeRole hub
 OCX_REMOTE_WORKSPACE_ENABLED=1 ocx start
+```
+
+保持 Hub 运行，打开另一个终端并启动仪表板：
+
+```bash
 ocx gui
 ```
 
@@ -45,27 +52,58 @@ Codex Remote Workspace 使用当前 App Server 权限配置文件。如果 Hub 
 等效的手动流程如下：
 
 ```bash
+# Bash only: if using zsh, run bash first in this terminal.
 cd /path/to/project
-printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
-  --pairing-code-stdin --root "$PWD"
-ocx remote-workspace agent
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" || pairing_status=$?
+  unset pairing_code
+  if [ "$pairing_status" -eq 0 ]; then ocx remote-workspace agent; fi
+  unset pairing_status
+else
+  unset pairing_code
+fi
 ```
 
 在 Windows PowerShell 上，请使用仪表盘显示的命令。等效的手动写法为：
 
 ```powershell
-$pairingCode = 'ONE-TIME-CODE'
-$pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
-  --pairing-code-stdin --root (Get-Location).Path
-if ($LASTEXITCODE -eq 0) { ocx remote-workspace agent }
+$pairingSecret = Read-Host 'Pairing code' -AsSecureString
+$pairingBuffer = [IntPtr]::Zero
+$pairingExitCode = 1
+try {
+  $pairingBuffer = [Runtime.InteropServices.Marshal]::SecureStringToBSTR($pairingSecret)
+  $pairingCode = [Runtime.InteropServices.Marshal]::PtrToStringBSTR($pairingBuffer)
+  $pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
+    --pairing-code-stdin --root (Get-Location).Path
+  $pairingExitCode = $LASTEXITCODE
+} finally {
+  if ($pairingBuffer -ne [IntPtr]::Zero) {
+    [Runtime.InteropServices.Marshal]::ZeroFreeBSTR($pairingBuffer)
+  }
+  $pairingSecret.Dispose()
+  Remove-Variable pairingCode, pairingSecret, pairingBuffer -ErrorAction SilentlyContinue
+}
+if ($pairingExitCode -eq 0) { ocx remote-workspace agent }
+Remove-Variable pairingExitCode
 ```
 
 在 Linux 沙箱中，当前 OCX Bun 可执行文件会自动以单个只读文件形式加入。如果项目需要系统路径之外的用户安装工具链，请明确配对该工具链，而不要暴露主目录的其他部分：
 
 ```bash
-printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
-  --pairing-code-stdin --root "$PWD" \
-  --toolchain-root "$HOME/.nvm/versions/node/v24/bin"
+# Bash only: if using zsh, run bash first in this terminal.
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" \
+    --toolchain-root "$HOME/.nvm/versions/node/v24/bin" || pairing_status=$?
+  unset pairing_code pairing_status
+else
+  unset pairing_code
+fi
 ```
 
 原生辅助程序源码随包提供，供审查。构建它并不会在本次交付中启用 Windows 或 macOS 命令。`--executor-helper` 仍用于选择经过审查的辅助程序；二进制存在或路径已配置，都不能证明命令可用。
diff --git a/docs-site/src/content/docs/zh-cn/guides/subagent-v1-default.md b/docs-site/src/content/docs/zh-cn/guides/subagent-v1-default.md
index 58fa0890419..2f1894cfa2f 100644
--- a/docs-site/src/content/docs/zh-cn/guides/subagent-v1-default.md
+++ b/docs-site/src/content/docs/zh-cn/guides/subagent-v1-default.md
@@ -28,7 +28,9 @@ OpenCodex 安装后的子代理界面默认为 **v1**。Dashboard、Models 和 S
 
 在 v1 上，父代理以纯文本发出子代理的任务。OpenCodex 读取并路由它，子代理因而收到可执行的内容。
 
-在 v2 上，父代理以 ChatGPT 后端生成的 `encrypted_content` 发出任务。密钥留在该后端，OpenCodex 从未持有它，因此代理既无法解密也无法改写；该值确实是密文，并不是由标志隐藏的明文。这是结构限制，而非配置错误，代理端的设置无法修复。
+在 v2 上，父代理以 ChatGPT 后端生成的 `encrypted_content` 发出任务。密钥留在该后端，OpenCodex 从未持有它，因此代理既无法解密也无法改写；该值确实是密文，并不是由标志隐藏的明文。这是结构限制，而非配置错误；代理端设置无法启用本地解密。
+
+代理设置无法启用本地解密。实验性 `agentTaskRecovery` 可以请求 ChatGPT 后端恢复符合条件的任务，但不会在本地解密其密文。上述授权、适用条件和失败处理限制仍然有效。
 
 有三种拓扑不受影响；了解它们也有助于理解失败发生的位置：
 
diff --git a/docs-site/src/content/docs/zh-cn/guides/video-bridge.md b/docs-site/src/content/docs/zh-cn/guides/video-bridge.md
index 39eb79c50ba..3bea2a0c95f 100644
--- a/docs-site/src/content/docs/zh-cn/guides/video-bridge.md
+++ b/docs-site/src/content/docs/zh-cn/guides/video-bridge.md
@@ -18,12 +18,12 @@ Video Bridge 允许你通过 opencodex 路由的任意非 OpenAI 模型使用 xA
 > ```json
 > {
 >   "providers": {
->     "xai": { "adapter": "openai-chat", "apiKey": "xai-…", "authMode": "key" }
+>     "xai": { "adapter": "openai-chat", "apiKey": "${XAI_API_KEY}", "authMode": "key" }
 >   }
 > }
 > ```
 >
-> 如果你是通过 `ocx login xai` 接入的（OAuth），provider 会保持在 `authMode: "oauth"`，桥接就会静默不启用。请在环境中设置 `XAI_API_KEY`，或者像上面那样直接硬编码密钥。
+> 在代理的启动环境中设置 `XAI_API_KEY`，保留 `${XAI_API_KEY}` 并明确使用 `authMode: "key"`。在其他终端导出不会改变已运行的代理；请通过所属 Desktop、服务或前台终端重启。不要将密钥写入提交、日志或共享报告。
 
 ## 配置
 
diff --git a/docs-site/src/content/docs/zh-cn/guides/web-dashboard.md b/docs-site/src/content/docs/zh-cn/guides/web-dashboard.md
index 0222d683539..e7422191cfb 100644
--- a/docs-site/src/content/docs/zh-cn/guides/web-dashboard.md
+++ b/docs-site/src/content/docs/zh-cn/guides/web-dashboard.md
@@ -17,6 +17,11 @@ ocx gui
 
 ```bash
 ocx start
+```
+
+保持代理在该终端中运行。在第二个终端中启动 GUI 开发服务器：
+
+```bash
 bun run dev:gui
 ```
 
diff --git a/docs-site/src/content/docs/zh-cn/reference/configuration/agents.md b/docs-site/src/content/docs/zh-cn/reference/configuration/agents.md
index 32b76f3bb5c..961bbf33c61 100644
--- a/docs-site/src/content/docs/zh-cn/reference/configuration/agents.md
+++ b/docs-site/src/content/docs/zh-cn/reference/configuration/agents.md
@@ -10,7 +10,7 @@ description: 多代理界面、委派引导、首选模型、回退链、原生
 | 字段 | 类型 | 默认值 | 含义 |
 | --- | --- | --- | --- |
 | `multiAgentMode?` | `"v1" \| "default" \| "v2"` | `"default"` | `v1` 会把目录中的每个模型都标记为 v1；`v2` 会把每个模型都标记为 v2。`default` 会恢复上游固定值（Sol/Terra 为 v2，Luna 为 v1），否则遵循原生 `multi_agent_v2` 标志。适用于新会话。 |
-| `subagentModels?` | `string[]` | `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6-luna` | 最多五个裸原生 id、账户限定的 `<selector>/<native-openai-model>` id 或路由 `provider/model` id 会优先显示在子代理选择器中。Subagents 页面只提供裸原生和路由 id，保存时会省略精确的账户限定选项；如需精确选择，请使用 `ocx agent subagents set` 或直接编辑配置。[Astra 一次性升级](/reference/configuration/agents/#astra-roster-upgrade)后，显式空列表会被保留。 |
+| `subagentModels?` | `string[]` | `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6-luna` | 最多五个原生 id、账户限定的 `<selector>/<native-openai-model>` id 或路由 `provider/model` id，优先显示在子代理选择器中。新增选项只提供原生和路由 id；保存时会保留已配置的精确账户限定 id，包括当前目录中不可用的 id。如需添加新的精确账户限定 id，请使用 `ocx agent subagents set` 或编辑配置。[Astra 一次性升级](/reference/configuration/agents/#astra-roster-upgrade)后，显式空列表会被保留。 |
 | `injectionModel?` | `string` | — | 在代理生成的 v2 委派引导中使用的首选原生或路由后的子代理模型。 |
 | `injectionEffort?` | `string` | — | 首选 effort（`low` 到 `ultra`），只有在 `injectionModel` 存在时才有意义。 |
 | `injectionPrompt?` | `string` | — | 替换内置 v2 指引正文。支持 `{{model}}`、`{{effort}}`、`{{roster}}` 和 `{{fallback}}`。只要配置了 `injectionModel`，自定义提示词就会触发。 |
@@ -68,13 +68,13 @@ opencodex 会跳过已禁用、不可路由、不健康、处于冷却中，或
 ```json
 {
   "multiAgentMode": "v2",
-  "subagentModels": ["gpt-5.5", "anthropic/claude-sonnet-5"],
-  "injectionModel": "gpt-5.5",
+  "subagentModels": ["gpt-6.1-sol", "anthropic/claude-sonnet-5"],
+  "injectionModel": "gpt-6.1-sol",
   "injectionEffort": "high",
   "syncCodexSubagentDefaults": true,
-  "subagentModelFallback": ["gpt-5.6-luna"],
+  "subagentModelFallback": ["gpt-6-luna"],
   "subagentModelFallbackByModel": {
-    "gpt-5.5": ["gpt-5.6-luna"]
+    "gpt-6.1-sol": ["gpt-6-luna"]
   },
   "subagentModelFallbackPollMs": 60000,
   "subagentEffortCap": "high"
diff --git a/docs-site/src/content/docs/zh-cn/reference/configuration/server.md b/docs-site/src/content/docs/zh-cn/reference/configuration/server.md
index 127a689b455..f421675b46d 100644
--- a/docs-site/src/content/docs/zh-cn/reference/configuration/server.md
+++ b/docs-site/src/content/docs/zh-cn/reference/configuration/server.md
@@ -11,7 +11,7 @@ description: 监听、远程访问、准入密钥、超时、存储、侧车、
 | 字段 | 类型 | 默认值 | 含义 |
 | --- | --- | --- | --- |
 | `port` | `number` | `10100` | 代理监听端口。 |
-| `hostname?` | `string` | `"127.0.0.1"` | 绑定地址。非回环绑定需要 `OPENCODEX_API_AUTH_TOKEN`。 |
+| `hostname?` | `string` | `"127.0.0.1"` | 绑定地址。非回环绑定需要 `config.apiKeys` 中的客户端密钥，或依次从 `OPENCODEX_API_AUTH_TOKEN`、`OCX_API_TOKEN_FILE`、已安装且仅所有者可读的 `service-api-token` 解析的共享数据令牌。参见[远程访问](#remote-access)。 |
 | `proxy?` | `string` | — | 出站 HTTP(S) 或 SOCKS5 代理 URL（`socks5://host:port`），或 `${ENV_VAR}`。HTTP URL 仅在未设置时写入 `HTTP_PROXY` / `HTTPS_PROXY`。SOCKS5 URL 使用内置的真实 SOCKS5 隧道，也会写入 `ALL_PROXY`（`ocx start --socks5`）；并清除本进程继承的 `HTTP(S)_PROXY`。回环地址始终保留在 `NO_PROXY` 中。 |
 | `emptyCompletionRetry?` | `boolean` | `false` | 显式启用：当 Responses turn 既无文本也无工具调用时，使用相同请求重试一次，包括流在终止事件之前结束的情况。重试可能产生费用。`OCX_EMPTY_COMPLETION_RETRY=0` 可在不修改配置的情况下禁用；combo 与 routed-compaction turn 不参与。 |
 | `dropCodexSafetyBuffering?` | `boolean` | `false` | 从 Codex Responses 透传响应中移除 Codex safety-buffering 提示：`x-codex-safety-buffering-enabled` / `x-codex-safety-buffering-faster-model` 响应头、类型为 `safety_buffering` 的 `response.metadata` SSE 事件，以及其他 SSE 事件中的 `safety_buffering` 字段。Codex TUI 会将这些提示显示为“使用更快模型重试”的提示框，其默认操作会把会话切换到较弱的模型。其他 `x-codex-*` 响应头和其他所有 SSE 事件内容均保持不变，但会移除该字段。默认关闭。 |
@@ -43,18 +43,18 @@ description: 监听、远程访问、准入密钥、超时、存储、侧车、
 
 原生 Chat 等待上游输出时也使用 `stallTimeoutSec`。非空文本、推理、拒绝内容、工具更新和完成事件会重置等待额度；保活注释、仅角色事件和单独的用量信息不会。等待慢客户端读取期间暂停计时。超时产生 `upstream_stall_timeout`：流式请求收到错误事件，非流式请求返回 HTTP 502。在终态结果到达前取消请求会返回取消错误，而不会把部分答案当作成功。非流式 Chat 支持 LF、CRLF 及多行 data 的 SSE 格式。
 
+<a id="remote-access"></a>
+
 ## 远程访问
 
-默认的 `127.0.0.1` 绑定仅限回环地址。像 `0.0.0.0` 这样的非回环地址需要
-在 `/api/*` 和数据平面上都启用令牌认证。启动前先导出令牌：
+默认的 `127.0.0.1` 仅绑定回环地址。绑定到 `0.0.0.0` 等非回环地址时，模型请求需要 `config.apiKeys` 中的客户端密钥或共享数据令牌。管理路由 `/api/*` 使用独立的 `OPENCODEX_ADMIN_AUTH_TOKEN` 或生成的管理员令牌，在回环上也一样。数据凭据不授予管理访问权；切勿把管理员令牌交给模型客户端。
 
 ```bash
 export OPENCODEX_API_AUTH_TOKEN="your-secret-token"
 ocx start
 ```
 
-如果没有这个变量，代理会拒绝远程绑定。对于后台服务，请在运行
-`ocx service install` 之前导出它，这样 launchd、systemd 或 Task Scheduler 都能接收到。客户端应发送：
+示例使用环境变量令牌。如果 `OCX_API_TOKEN_FILE` 或私有 `service-api-token` 已提供令牌，或已配置有效的客户端密钥，就不必导出该变量。`ocx service install` 可以创建缺失的令牌文件，不强制要求导出此变量。模型客户端可以发送：
 
 ```text
 x-opencodex-api-key: your-secret-token
@@ -62,14 +62,13 @@ x-opencodex-api-key: your-secret-token
 
 | 端点 | `Authorization: Bearer` | `x-opencodex-api-key` | `x-api-key` |
 | --- | --- | --- | --- |
-| `/v1/responses` | 不接受 | **必需** | 不接受 |
-| `/v1/chat/completions` | 不接受 | **必需** | 不接受 |
+| `/v1/responses` | 接受 | 接受 | 不接受 |
+| `/v1/chat/completions` | 接受 | 接受 | 不接受 |
 | `/v1/messages` | 接受 | 接受 | 接受 |
 | `/v1/messages/count_tokens` | 接受 | 接受 | 接受 |
 | `/v1/models` | 接受 | 接受 | 接受 |
 
-Responses 和 Chat Completions 会保留 `Authorization`，以便将来可能支持 Codex Direct 透传，因此这里只接受专用的准入头。仪表板生成的 `apiKeys` 可以在启动后替换
-环境令牌；候选项按常量时间比较。
+Responses 和 Chat Completions 接受 `x-opencodex-api-key` 中已识别的数据平面凭据；仅当该专用请求头缺失或去除首尾空白后为空时，也接受 `Authorization: Bearer`。去除首尾空白后非空的专用请求头具有优先权，即使其值无效，有效 bearer 也不能补救。无关 bearer 不授予代理访问权，这些路由不接受 `x-api-key`。生成的 `apiKeys` 和共享数据令牌以常量时间比较；管理凭据不授予模型访问权。
 
 Messages 和 `count_tokens` 为兼容路由客户端仍接受三种准入形式。但在非回环绑定上，原生 Anthropic 透传只通过
 `x-opencodex-api-key` 接受代理准入，并把 `Authorization` 和 `x-api-key` 保留给 Anthropic
diff --git a/docs-site/src/content/docs/zh-cn/reference/management-api.md b/docs-site/src/content/docs/zh-cn/reference/management-api.md
index 06a7a28d384..73c78e12265 100644
--- a/docs-site/src/content/docs/zh-cn/reference/management-api.md
+++ b/docs-site/src/content/docs/zh-cn/reference/management-api.md
@@ -7,6 +7,8 @@ Management API 是 opencodex 的控制平面。`http://localhost:10100` 上的
 
 请使用 [Web 仪表板](/guides/web-dashboard/) 作为交互式客户端，或者在构建自动化时参考本文档。持久化值最终遵循 [配置](/reference/configuration/)。
 
+<a id="authentication-model"></a>
+
 ## 身份验证模型
 
 Management API 有自己独立的管理员凭证，与数据平面 API 密钥无关。启动时，opencodex 会按以下顺序解析它：
diff --git a/docs-site/src/content/docs/zh-tw/getting-started/for-agents.md b/docs-site/src/content/docs/zh-tw/getting-started/for-agents.md
index 1438fab0353..2f42f661b28 100644
--- a/docs-site/src/content/docs/zh-tw/getting-started/for-agents.md
+++ b/docs-site/src/content/docs/zh-tw/getting-started/for-agents.md
@@ -14,7 +14,11 @@ npm install -g --allow-scripts=bun @bitkyc08/opencodex
 ocx --version
 ```
 
-選擇一種執行代理的方式：
+啟動代理前，請在互動式終端執行 `ocx init`，以使用設定時選擇的連接埠：
+
+```bash
+ocx init
+```
 
 ```bash
 # 前景：佔用此終端機直到停止。
@@ -24,12 +28,6 @@ ocx start
 ocx service
 ```
 
-在互動終端機執行 `ocx init`。若 `ocx start` 佔用了前景，請用第二個終端機：
-
-```bash
-ocx init
-```
-
 精靈會寫入 `$OPENCODEX_HOME/config.json`（通常為
 `~/.opencodex/config.json`）。它也可將代理位址注入 Codex 的 `config.toml`，並安裝可選的 Codex 自動啟動 shim。`ocx init` 永不啟動代理。若要完全非互動的設定，請改用下方所示的 `ocx provider add` 設定供應商，而非驅動精靈。
 
@@ -60,17 +58,19 @@ Registry 供應商可依名稱新增。例如，以下新增 Anthropic API-key 
 
 ```bash
 ocx provider add anthropic-apikey \
-  --api-key "$ANTHROPIC_API_KEY" \
+  --api-key '${ANTHROPIC_API_KEY}' \
   --set-default
 ```
 
+請保留單引號，以便原樣傳遞環境變數參照，而不是把金鑰值放入程序引數或儲存到設定中。啟動代理前，請在其啟動環境中設定 `ANTHROPIC_API_KEY`，並為模型同步等會解析憑證的 CLI 程序提供該變數。稍後在另一終端中 export 不會更新執行中的代理。背景服務需要設定啟動環境並重新啟動；安裝服務不會自動保留終端中的任意供應商變數。
+
 `ocx provider add` 寫入本機設定。若已有即時代理在執行且你想立即將模型同步到 Codex，請加上 `--sync`；否則稍後執行 `ocx sync`。不在 registry 中的自訂供應商需要同時提供 `--adapter` 與 `--base-url`。
 
 所有目標供應商設定完成且代理執行後，建立一個 failover combo：
 
 ```bash
 ocx combo set main \
-  --targets anthropic/claude-opus-4-8,openai/gpt-5.6-sol \
+  --targets anthropic-apikey/claude-opus-4-8,openai/gpt-5.6-sol \
   --strategy failover
 ```
 
@@ -79,12 +79,11 @@ ocx combo set main \
 
 ## 遠端與 LAN 綁定
 
-預設的回送綁定不需要 API token。非回送綁定（例如 `0.0.0.0`）需要
-`OPENCODEX_API_AUTH_TOKEN`；代理在沒有它時拒絕啟動。請在 `ocx start` 前，或在 `ocx service install` 前設定該變數，以便服務接收它：
+一般回環模型路由不需要資料權杖。繫結至 `0.0.0.0` 等非回環位址時，需要 `config.apiKeys` 中設定的用戶端金鑰，或從 `OPENCODEX_API_AUTH_TOKEN`、`OCX_API_TOKEN_FILE`、僅擁有者可讀的 `service-api-token` 檔案解析出的共用權杖。檔案不存在時，`ocx service install` 可以建立它。若透過環境變數提供權杖，請在 `ocx start` 或 `ocx service install` 之前設定：
 
 ```bash
 export OPENCODEX_API_AUTH_TOKEN="your-secret-token"
 ocx service install
 ```
 
-客戶端隨後必須認證其管理與模型請求。在將 opencodex 暴露到本機以外之前，請閱讀[設定](/zh-tw/reference/configuration/)中的遠端存取規則。
+模型請求使用資料平面驗證。管理使用獨立憑證：`OPENCODEX_ADMIN_AUTH_TOKEN` 或受保護檔案中產生的管理員權杖；資料權杖不授予管理存取權。儀表板遵循[管理 API](/zh-tw/reference/management-api/#authentication-model)的工作階段與存取規則。切勿將管理員權杖交給模型用戶端。向本機以外開放代理前，請閱讀[遠端存取](/zh-tw/reference/configuration/server/#remote-access)。
diff --git a/docs-site/src/content/docs/zh-tw/getting-started/quickstart.md b/docs-site/src/content/docs/zh-tw/getting-started/quickstart.md
index 1b97eb24aaf..fbb253e6e22 100644
--- a/docs-site/src/content/docs/zh-tw/getting-started/quickstart.md
+++ b/docs-site/src/content/docs/zh-tw/getting-started/quickstart.md
@@ -34,20 +34,27 @@ OpenRouter 預設會宣告 922,000 token 的可用 context window；Cursor 則
 
 ## 2. 啟動代理
 
+執行下列兩種方式之一；代理會持續在前景執行：
+
 ```bash
 ocx start            # 預設埠 10100
+```
+
+也可以改用其他連接埠：
+
+```bash
 ocx start --port 8080
 ```
 
+保持此終端開啟。後續狀態檢查與儀表板命令需在另一個設定相同 `OPENCODEX_HOME` 的終端中執行。
+
 啟動時,opencodex 會:
 
 - 將其 PID 寫入 `~/.opencodex/ocx.pid`(並拒絕重複啟動),
 - 在 provider 支援時發現即時模型，並**把原生與已路由條目同步進 Codex 的模型目錄**，以及
 - 在 `http://localhost:<port>/v1` 上監聽。
 
-如果請求的埠已被佔用，`ocx start` 會停止並告訴你是什麼佔用了該埠：如果回應的是
-opencodex，請先執行 `ocx stop`；也可以使用 `ocx start --port <port>` 在空閒埠上啟動。
-它不會自行切換到其他埠；舊行為會讓兩個代理同時執行，並將 Codex 重新指向後啟動的代理。
+使用同一 `OPENCODEX_HOME` 的 opencodex 正在執行時，即使有空閒埠，也無法再次啟動。請先用 `ocx stop` 停止擁有者執行個體，或選擇另一個 `OPENCODEX_HOME`。同層執行個體在自己的埠處理直接請求，不會改變 Codex、Grok 或 Claude 的共用路由。若無關程序佔用該埠，`ocx start` 會說明情況；請用 `ocx start --port <port>` 選擇空閒埠。它不會自動切換埠。
 
 檢查它:
 
diff --git a/docs-site/src/content/docs/zh-tw/guides/codex-app-models.md b/docs-site/src/content/docs/zh-tw/guides/codex-app-models.md
index bccd018f77b..65e63d31577 100644
--- a/docs-site/src/content/docs/zh-tw/guides/codex-app-models.md
+++ b/docs-site/src/content/docs/zh-tw/guides/codex-app-models.md
@@ -157,8 +157,7 @@ DeepSeek 與 Volcengine Ark 歸類為 `false`），而未分類的自訂 gateway
 
 Codex 會按 `priority` 升序排列選擇器中可見的目錄條目，並將前五個顯示為 `spawn_agent` 模型
 override。儀表板的 Subagents 頁面可以選擇並儲存最多五個裸原生 id 或路由的 `provider/model`
-id。手動設定的 `subagentModels` 也接受帳號限定的 `<selector>/<native-openai-model>` id，但
-儀表板不提供這些精確 id；儲存頁面時會把列表替換為儀表板可見的選擇。opencodex 會按所選順序
+id。手動設定的 `subagentModels` 也接受帳號限定的 `<selector>/<native-openai-model>` id。儲存列表時，儀表板會保留這些已儲存的精確 id，包括目前目錄中已無法使用的模型。opencodex 會按所選順序
 賦予較低的目錄 priority；啟用帳號限定選擇器列時，裸原生選擇會展開為選擇器限定群組。其他模型
 仍可透過精確 id 直接呼叫。
 
diff --git a/docs-site/src/content/docs/zh-tw/guides/grok-build.md b/docs-site/src/content/docs/zh-tw/guides/grok-build.md
index 2724955548a..5576f91b549 100644
--- a/docs-site/src/content/docs/zh-tw/guides/grok-build.md
+++ b/docs-site/src/content/docs/zh-tw/guides/grok-build.md
@@ -92,11 +92,11 @@ model = "anthropic/claude-opus-4-8"
 model_provider = "opencodex"
 ```
 
-對於可經由網路連線的代理程式，將 `base_url` 指向 `grok` 實際可撥號的位址，並使用你的 admission token：
+提供權杖前，請先設定 TLS 前端並使用其 HTTPS URL，或使用本機通道的回環位址。Grok 會把 `api_key` 的原始值儲存到 `~/.grok/config.toml`；請限制檔案存取權，並將其排除於版本控制和共用備份之外。
 
 ```toml
 [model_providers.opencodex]
-base_url = "http://192.168.1.10:10100/v1"   # the reachable host, not 127.0.0.1
+base_url = "https://proxy.example.com/v1"   # configured TLS frontend
 api_backend = "responses"
 api_key = "your-OPENCODEX_API_AUTH_TOKEN"
 
diff --git a/docs-site/src/content/docs/zh-tw/guides/minimax.md b/docs-site/src/content/docs/zh-tw/guides/minimax.md
index 24a14379044..d02e101f140 100644
--- a/docs-site/src/content/docs/zh-tw/guides/minimax.md
+++ b/docs-site/src/content/docs/zh-tw/guides/minimax.md
@@ -14,6 +14,11 @@ MiniMax 提供兩款不同的命令列產品。OpenCodex 依各自實際提供
 
 ```bash
 ocx start
+```
+
+讓代理在此終端機中繼續執行。在另一個終端機中啟用整合並啟動 MiniMax Code：
+
+```bash
 ocx integration client enable --client mcode
 ocx mcode
 ```
diff --git a/docs-site/src/content/docs/zh-tw/guides/model-routing.md b/docs-site/src/content/docs/zh-tw/guides/model-routing.md
index 0a716351eea..e63ed1e0bd3 100644
--- a/docs-site/src/content/docs/zh-tw/guides/model-routing.md
+++ b/docs-site/src/content/docs/zh-tw/guides/model-routing.md
@@ -32,8 +32,8 @@ OpenAI 的 bare `gpt-*` 使用單一 `openai` provider。`codexAccountMode` 在
    | `gpt-`、`o1-`、`o3-`、`o4-` | bare id 使用已設定的 `openai` 帳號模式；API key 顯式使用 `openai-apikey/` |
    | `llama-`、`mixtral-`、`gemma-` | `groq` |
 
-   該匹配器只檢查名稱。與 `defaultModel` / `models[]` 掃描不同，目前即使匹配供應商的 `disabled`
-   為 true，它也不會跳過該供應商。
+   該匹配器只檢查名稱。與 `defaultModel` / `models[]` 掃描一樣，匹配供應商的 `disabled` 為 true
+   時會跳過該供應商。
 
 4. **某個供應商的 `models[]`** —— 如果字首規則沒有命中，而某個啟用的供應商在 `models[]` 中列出
    該 id，則使用該供應商。這個順序很重要：只要設定了 OpenAI 名稱的供應商，裸 `gpt-*` id 就會在
diff --git a/docs-site/src/content/docs/zh-tw/guides/opencode.md b/docs-site/src/content/docs/zh-tw/guides/opencode.md
index 4ac25254e51..88a3244a71d 100644
--- a/docs-site/src/content/docs/zh-tw/guides/opencode.md
+++ b/docs-site/src/content/docs/zh-tw/guides/opencode.md
@@ -82,9 +82,11 @@ Loopback 範例：
 
 非 loopback 範例：
 
+這是遠端用戶端的手動設定範例。請先設定 TLS 前端，再使用其 HTTPS URL；OpenCodex 本身不終止 TLS，`ocx opencode` 也不會自動探索該 URL。即使在區域網路中，明文 HTTP 也會在傳輸時暴露准入憑證。另一種方式是讓代理繫結回環位址，並使用本機 SSH 通道。請參閱[資料監聽器的 TLS](/zh-tw/guides/remote-hub/#giving-the-data-listener-tls)。
+
 ```json
 "options": {
-  "baseURL": "http://192.168.1.10:10100/v1",
+  "baseURL": "https://proxy.example.com/v1",
   "headers": {
     "x-opencodex-api-key": "{env:OPENCODEX_OPENCODE_API_KEY}"
   }
diff --git a/docs-site/src/content/docs/zh-tw/guides/pi.md b/docs-site/src/content/docs/zh-tw/guides/pi.md
index f18e0cdab22..a2b09f5c3cb 100644
--- a/docs-site/src/content/docs/zh-tw/guides/pi.md
+++ b/docs-site/src/content/docs/zh-tw/guides/pi.md
@@ -3,7 +3,7 @@ title: Pi
 description: 使用 Pi 的任何路由模型 — ocx export 會為 Pi 的 models.json 寫入自訂供應商區塊，連接到執行中的代理。
 ---
 
-Pi 從單一全域 JSON 檔案而非環境變數讀取其供應商，因此 opencodex 不會啟動它。相反地，`ocx export` 序列化 `opencodex` 供應商區塊 — base URL、模型清單，以及 Pi 會插入的環境參考 — 然後你將其合併到自己的設定中。
+Pi 從單一全域 JSON 檔案讀取供應商。opencodex 不會啟動 Pi；`ocx export` 輸出 `opencodex` 供應商區塊，包含基底 URL、模型清單及非機密的本機金鑰預留位置。請將此區塊合併到現有設定。
 
 ## 快速入門
 
@@ -11,10 +11,15 @@ Pi 從單一全域 JSON 檔案而非環境變數讀取其供應商，因此 open
 
 ```bash
 ocx start
+```
+
+讓此程序繼續執行。在另一個終端機中輸出設定：
+
+```bash
 ocx export --client pi
 ```
 
-輸出以 JSON 開頭，接著印出目標路徑、合併警告、環境匯出行，以及有多少模型帶有權威的上下文限制。
+JSON 之後會顯示目的地路徑、合併警告、回環使用提示，以及具有已確認內容視窗限制的模型數量。此匯出僅支援不需驗證的回環代理，不會設定遠端存取驗證。
 
 ```json
 {
@@ -22,7 +27,7 @@ ocx export --client pi
     "opencodex": {
       "baseUrl": "http://127.0.0.1:10100/v1",
       "api": "openai-completions",
-      "apiKey": "$OPENCODEX_API_KEY",
+      "apiKey": "opencodex-loopback",
       "compat": {
         "sendSessionAffinityHeaders": true,
         "supportsDeveloperRole": false
@@ -71,23 +76,7 @@ ocx export --client pi --json > ~/opencodex-pi-models.json   # 或重導逐字
 
 ## 認證金鑰
 
-這裡有兩種不同的 key 容易混淆，且只有第一個出現在此檔案中：
-
-| Key | 是什麼 | 位於何處 |
-| --- | --- | --- |
-| 代理認證 key | opencodex 自身的憑證，在儀表板的 **API** 分頁產生 | 由 `apiKey` 以 `$OPENCODEX_API_KEY` 參照；值留在你的環境中 |
-| 供應商 key | 你的 Anthropic / OpenAI / OpenRouter key | opencodex 自身的設定，見[供應商](/zh-tw/guides/providers/) |
-
-匯出的設定僅帶有參照，絕不帶金鑰。Pi 會插入裸 `$NAME`，因此該變數為：
-
-```bash
-export OPENCODEX_API_KEY=<your key>
-```
-
-該名稱是 Pi 專屬的。opencode 使用不同的變數
-（`OPENCODEX_OPENCODE_API_KEY`，採 `{env:…}` 形式）— 見 [opencode 指南](/zh-tw/guides/opencode/)。
-
-**回送代理完全不需要 key。** opencodex 預設綁定 `127.0.0.1` 且在那裡不認證任何東西，因此 `$OPENCODEX_API_KEY` 參照是無效的，你可以讓變數未設定。它只在 `hostname` 設定到回送以外時才重要，這也是代理在沒有 token 時拒絕啟動的情況 — 見[遠端存取](/zh-tw/reference/configuration/server/#遠端存取)。
+匯出的 `apiKey` 是非機密預留值 `opencodex-loopback`，不需要匯出金鑰環境變數。匯出器只允許不需驗證的回環代理，會拒絕遠端代理或受權杖保護的代理。供應商憑證保留在 opencodex 設定中，請參閱[供應商](/zh-tw/guides/providers/)；不要把上游供應商金鑰放入此 Pi 區塊。遠端存取應使用支援代理存取憑證的整合。修改預留值不會啟用 Pi 遠端匯出。
 
 ## 模型後設資料
 
@@ -95,7 +84,11 @@ export OPENCODEX_API_KEY=<your key>
 
 輸出上限使用目錄或產生的中繼資料中已知的模型上限，僅在未知時回退到 `32000`。輸出上限始終不超過 context window；已知低於 `32000` 的上限也會保留。
 
-有兩個欄位刻意省略。`cost` 需要全部四個價格欄位，而 opencodex 對路由模型沒有價格資料 — 發出零值會斷言每個模型都是免費的。`reasoning` 在 Pi 中是 boolean，而目錄帶有 effort 階梯，將兩者互相映射會是猜測。
+`cost` 刻意省略：它需要完整的四個價格欄位，而 opencodex 沒有路由模型的價格資料。輸出零值會誤稱所有模型都免費。
+
+當目錄的 effort 階梯**非空**時，匯出 `"reasoning": true`；階梯缺少或明確為空時則不宣告推理支援。`thinkingLevelMap` 以 `null` 隱藏沒有已宣告目標的 Pi 層級，防止顯示或傳送清單以外的值。若宣告了 `ultra` 而沒有 `max`，就將 Pi 的 `max` 對應至 `ultra`。需要其他對應時，請依 Pi 文件手動修改 `thinkingLevelMap`。
+
+`reasoning` 是從目錄衍生的 Pi 介面中繼資料，不證明上游原生支援推理參數。實際 `reasoning_effort` 取決於適配器與模型，可被轉送、轉換、限制、模擬或省略（例如 `noReasoningModels`）。此布林值只決定 Pi 是否提供該控制項。
 
 ## Schema 狀態
 
diff --git a/docs-site/src/content/docs/zh-tw/guides/remote-hub.md b/docs-site/src/content/docs/zh-tw/guides/remote-hub.md
index cde286eaed8..5df638b238c 100644
--- a/docs-site/src/content/docs/zh-tw/guides/remote-hub.md
+++ b/docs-site/src/content/docs/zh-tw/guides/remote-hub.md
@@ -12,7 +12,13 @@ Remote Hub 把供應商憑證、模型目錄與用量記錄保存在一台主機
 `standalone` 在同一台機器上執行全部功能；`hub` 保存供應商金鑰與用量；`client` 只保存連線狀態與專屬資料金鑰。
 
 ```bash
-ocx connect https://hub-name.tailnet-name.ts.net --pairing-code-stdin
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the one-time code without echoing it or putting it in shell history.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+  --management-url https://hub-name.tailnet-name.ts.net \
+  --pairing-code-stdin
+unset pairing_code
 ocx connect status
 ocx sync
 ```
@@ -65,6 +71,8 @@ tailscale serve status
 
 `/healthz` 只證明程序仍在執行。還必須驗證 `/readyz`、已驗證的 `GET /v1/catalog` 與一次真實模型回應。管理連接埠只能監聽 `127.0.0.1`。自管 TLS proxy 應使用 `tailscale cert hub-name.tailnet-name.ts.net`，並只代理到 `127.0.0.1:10101`。不要偽造 `Tailscale-User-*`；沒有可信身分時請使用一次性配對。
 
+<a id="giving-the-data-listener-tls"></a>
+
 ### 為資料監聽器提供 TLS
 
 上面的 Serve 對應只發布**管理**入口。該入口從不提供 `/v1/*`、`/healthz` 或 `/readyz`，因此光靠它並不能讓遠端用戶端取得可用的資料平面。opencodex 本身也不終結 TLS：監聽器是明文 HTTP，HTTPS 一律由維運方自建的前端負責。
@@ -85,9 +93,13 @@ Serve 只接受有限的幾個 HTTPS 連接埠。請用 `tailscale serve status`
 連線時把兩個 origin 分開寫。位置參數 URL 是**資料** origin，`/readyz` 與 `/v1/catalog` 都從這裡取得；`--management-url` 則是用於配對與金鑰簽發的儀表板 origin。兩者不必共用連接埠：
 
 ```bash
-ocx connect https://hub-name.tailnet-name.ts.net:8443 \
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: enter the management admin token without echoing it.
+read -r -s -p 'Admin token: ' admin_token; printf '\n'
+printf '%s\n' "$admin_token" | ocx connect https://hub-name.tailnet-name.ts.net:8443 \
   --management-url https://hub-name.tailnet-name.ts.net \
   --admin-token-stdin
+unset admin_token
 ```
 
 省略 `--management-url` 時，它取自 `/readyz` 回應，而該回應回報的正是 `hub.managementPublicOrigin`。兩個 origin 不同時，明確寫出更清楚。
@@ -101,10 +113,16 @@ Serve 就緒後，請對 HTTPS 資料 origin 重新執行驗收檢查：`/readyz
 ## OAuth、金鑰輪替與中斷連線
 
 ```bash
-ocx config set oauthOpenBrowser false
-ocx connect rotate --pairing-code-stdin
-# 僅限 HTTPS：
-ocx connect rotate --admin-token-stdin
+# Bash only: if using zsh, run bash first in this terminal.
+# Bash: choose one authority source.
+read -r -s -p 'Pairing code: ' pairing_code; printf '\n'
+printf '%s\n' "$pairing_code" | ocx connect rotate --pairing-code-stdin
+unset pairing_code
+
+# Alternatively, only over HTTPS, use the management admin token:
+read -r -s -p 'Admin token: ' admin_token; printf '\n'
+printf '%s\n' "$admin_token" | ocx connect rotate --admin-token-stdin
+unset admin_token
 ```
 
 透過 `POST /api/oauth/login` 啟動 OAuth。若 callback 無法連到 hub，請把最終 URL 或授權碼以 `{provider,input}` 傳送到 `POST /api/oauth/login/code`。不要把 OAuth 碼放入 argv 或記錄。
diff --git a/docs-site/src/content/docs/zh-tw/guides/remote-workspace.md b/docs-site/src/content/docs/zh-tw/guides/remote-workspace.md
index a63a80285b6..95da83cdf1b 100644
--- a/docs-site/src/content/docs/zh-tw/guides/remote-workspace.md
+++ b/docs-site/src/content/docs/zh-tw/guides/remote-workspace.md
@@ -23,9 +23,16 @@ Remote Workspace 是須自行啟用的實驗基礎功能，尚未用於正式環
 
 電腦 1 擁有所有程式碼代理的登入與模型工作階段。在該電腦安裝並登入要使用的代理，然後以 Hub 角色執行 OpenCodex：
 
+在此終端機中讓 Hub 持續於前景執行：
+
 ```bash
 ocx config set runtimeRole hub
 OCX_REMOTE_WORKSPACE_ENABLED=1 ocx start
+```
+
+保持 Hub 執行，開啟另一個終端機並啟動儀表板：
+
+```bash
 ocx gui
 ```
 
@@ -45,27 +52,58 @@ Codex Remote Workspace 使用目前的 App Server 權限設定檔。若 Hub 選
 等效的手動流程如下：
 
 ```bash
+# Bash only: if using zsh, run bash first in this terminal.
 cd /path/to/project
-printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
-  --pairing-code-stdin --root "$PWD"
-ocx remote-workspace agent
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" || pairing_status=$?
+  unset pairing_code
+  if [ "$pairing_status" -eq 0 ]; then ocx remote-workspace agent; fi
+  unset pairing_status
+else
+  unset pairing_code
+fi
 ```
 
 在 Windows PowerShell 上，請使用儀表板顯示的指令。等效的手動形式如下：
 
 ```powershell
-$pairingCode = 'ONE-TIME-CODE'
-$pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
-  --pairing-code-stdin --root (Get-Location).Path
-if ($LASTEXITCODE -eq 0) { ocx remote-workspace agent }
+$pairingSecret = Read-Host 'Pairing code' -AsSecureString
+$pairingBuffer = [IntPtr]::Zero
+$pairingExitCode = 1
+try {
+  $pairingBuffer = [Runtime.InteropServices.Marshal]::SecureStringToBSTR($pairingSecret)
+  $pairingCode = [Runtime.InteropServices.Marshal]::PtrToStringBSTR($pairingBuffer)
+  $pairingCode | ocx remote-workspace pair 'https://your-hub.example' `
+    --pairing-code-stdin --root (Get-Location).Path
+  $pairingExitCode = $LASTEXITCODE
+} finally {
+  if ($pairingBuffer -ne [IntPtr]::Zero) {
+    [Runtime.InteropServices.Marshal]::ZeroFreeBSTR($pairingBuffer)
+  }
+  $pairingSecret.Dispose()
+  Remove-Variable pairingCode, pairingSecret, pairingBuffer -ErrorAction SilentlyContinue
+}
+if ($pairingExitCode -eq 0) { ocx remote-workspace agent }
+Remove-Variable pairingExitCode
 ```
 
 目前的 OCX Bun 可執行檔會自動以單一唯讀檔案加入 Linux sandbox。若專案需要位於系統路徑之外、由使用者安裝的工具鏈，可明確配對該路徑，而不用公開 home 目錄其餘部分：
 
 ```bash
-printf '%s\n' 'ONE-TIME-CODE' | ocx remote-workspace pair 'https://your-hub.example' \
-  --pairing-code-stdin --root "$PWD" \
-  --toolchain-root "$HOME/.nvm/versions/node/v24/bin"
+# Bash only: if using zsh, run bash first in this terminal.
+if read -r -s -p 'Pairing code: ' pairing_code; then
+  printf '\n'
+  pairing_status=0
+  printf '%s\n' "$pairing_code" | ocx remote-workspace pair 'https://your-hub.example' \
+    --pairing-code-stdin --root "$PWD" \
+    --toolchain-root "$HOME/.nvm/versions/node/v24/bin" || pairing_status=$?
+  unset pairing_code pairing_status
+else
+  unset pairing_code
+fi
 ```
 
 原生 helper 原始碼隨套件提供，供審查使用。建置它不會在本次移植中啟用 Windows 或 macOS 指令。`--executor-helper` 仍是已審查 helper 的選擇器；二進位檔存在或路徑已設定，都不能證明支援指令。
diff --git a/docs-site/src/content/docs/zh-tw/guides/subagent-v1-default.md b/docs-site/src/content/docs/zh-tw/guides/subagent-v1-default.md
index bdab9f109f1..73f37355dab 100644
--- a/docs-site/src/content/docs/zh-tw/guides/subagent-v1-default.md
+++ b/docs-site/src/content/docs/zh-tw/guides/subagent-v1-default.md
@@ -28,7 +28,9 @@ OpenCodex 安裝後，子代理介面預設為 **v1**。Dashboard、Models 與 S
 
 在 v1 上，父代理會以純文字送出子代理任務。OpenCodex 能讀取並路由，子代理也能收到可執行的內容。
 
-在 v2 上，父代理送出的任務是由 ChatGPT 後端產生的 `encrypted_content`。金鑰留在該後端；OpenCodex 從未持有，所以代理無從解密或重寫。這個值是真正的密文，而非旗標掩蓋下的明文。因此這是結構性限制，不是設定錯誤，也無法靠代理端設定修復。
+在 v2 上，父代理送出的任務是由 ChatGPT 後端產生的 `encrypted_content`。金鑰留在該後端；OpenCodex 從未持有，所以代理無從解密或重寫。這個值是真正的密文，而非旗標掩蓋下的明文。因此這是結構性限制，不是設定錯誤；代理端設定無法啟用本機解密。
+
+代理設定無法啟用本機解密。實驗性 `agentTaskRecovery` 可以要求 ChatGPT 後端復原符合條件的任務，但不會在本機解密其密文。上述授權、適用條件和失敗處理限制仍然有效。
 
 有三種拓撲不受影響；了解它們有助於釐清失敗範圍：
 
diff --git a/docs-site/src/content/docs/zh-tw/guides/video-bridge.md b/docs-site/src/content/docs/zh-tw/guides/video-bridge.md
index caa500077b2..fbfadba0ad3 100644
--- a/docs-site/src/content/docs/zh-tw/guides/video-bridge.md
+++ b/docs-site/src/content/docs/zh-tw/guides/video-bridge.md
@@ -19,12 +19,12 @@ Video Bridge 讓你透過 opencodex 路由的任何非 OpenAI 模型，使用 xA
 > ```json
 > {
 >   "providers": {
->     "xai": { "adapter": "openai-chat", "apiKey": "xai-…", "authMode": "key" }
+>     "xai": { "adapter": "openai-chat", "apiKey": "${XAI_API_KEY}", "authMode": "key" }
 >   }
 > }
 > ```
 >
-> 若你是透過 `ocx login xai`（OAuth）接入，供應商會停留在 `authMode: "oauth"`，bridge 不會悄悄啟用。請在環境中設定 `XAI_API_KEY`，**或**如上所示直接寫入 key。
+> 在代理的啟動環境設定 `XAI_API_KEY`，保留 `${XAI_API_KEY}` 並明確使用 `authMode: "key"`。其他終端的匯出不會變更執行中的代理；請透過所屬 Desktop、服務或前景終端重新啟動。不要將金鑰寫入提交、紀錄或共用報告。
 
 ## 設定
 
diff --git a/docs-site/src/content/docs/zh-tw/guides/web-dashboard.md b/docs-site/src/content/docs/zh-tw/guides/web-dashboard.md
index b848a78aa77..dfbadd971f4 100644
--- a/docs-site/src/content/docs/zh-tw/guides/web-dashboard.md
+++ b/docs-site/src/content/docs/zh-tw/guides/web-dashboard.md
@@ -17,6 +17,11 @@ ocx gui
 
 ```bash
 ocx start
+```
+
+讓代理在該終端中持續執行。在第二個終端中啟動 GUI 開發伺服器：
+
+```bash
 bun run dev:gui
 ```
 
diff --git a/docs-site/src/content/docs/zh-tw/reference/configuration/agents.md b/docs-site/src/content/docs/zh-tw/reference/configuration/agents.md
index 6f417dffa89..88e5f4208ba 100644
--- a/docs-site/src/content/docs/zh-tw/reference/configuration/agents.md
+++ b/docs-site/src/content/docs/zh-tw/reference/configuration/agents.md
@@ -10,7 +10,7 @@ Agent 設定控制要廣告哪個 Codex 協作介面，以及 opencodex 如何
 | 欄位 | 型別 | 預設值 | 意義 |
 | --- | --- | --- | --- |
 | `multiAgentMode?` | `"v1" \| "default" \| "v2"` | `"default"` | `v1` 將每個目錄模型標記為 v1；`v2` 將每個模型標記為 v2。`default` 還原上游 pin（Sol/Terra v2、Luna v1），否則遵循原生的 `multi_agent_v2` 旗標。套用於新 session。 |
-| `subagentModels?` | `string[]` | `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6-luna` | 最多五個原生或路由 id，在子代理 picker 中優先顯示。[Astra 一次性升級](/reference/configuration/agents/#astra-roster-upgrade)後，明確的空清單會被保留。 |
+| `subagentModels?` | `string[]` | `gpt-6-astra`, `gpt-6.1-sol`, `gpt-6-luna` | 最多五個原生 id、帳號限定的 `<selector>/<native-openai-model>` id 或路由 `provider/model` id，優先顯示在子代理選擇器中。新增選項只提供原生和路由 id；儲存時會保留已設定的精確帳號限定 id，包括目前目錄中無法使用的 id。如需新增精確帳號限定 id，請使用 `ocx agent subagents set` 或編輯設定。[Astra 一次性升級](/reference/configuration/agents/#astra-roster-upgrade)後，明確的空清單會被保留。 |
 | `injectionModel?` | `string` | — | 在代理撰寫的 v2 委派指引中使用的偏好原生或路由子代理模型。 |
 | `injectionEffort?` | `string` | — | 偏好 effort（`low` 到 `ultra`），僅在搭配 `injectionModel` 時有意義。 |
 | `injectionPrompt?` | `string` | — | 取代內建指引本文。支援 `{{model}}`、`{{effort}}`、`{{roster}}` 與 `{{fallback}}`。觸發閘門保持不變。 |
@@ -55,11 +55,11 @@ opencodex 會跳過已停用、不可路由、不健康、冷卻中或達到配
 ```json
 {
   "multiAgentMode": "v2",
-  "subagentModels": ["gpt-5.5", "anthropic/claude-sonnet-5"],
-  "injectionModel": "gpt-5.5",
+  "subagentModels": ["gpt-6.1-sol", "anthropic/claude-sonnet-5"],
+  "injectionModel": "gpt-6.1-sol",
   "injectionEffort": "high",
   "syncCodexSubagentDefaults": true,
-  "subagentModelFallback": ["gpt-5.6-luna"],
+  "subagentModelFallback": ["gpt-6-luna"],
   "subagentModelFallbackPollMs": 60000,
   "subagentEffortCap": "high"
 }
diff --git a/docs-site/src/content/docs/zh-tw/reference/configuration/server.md b/docs-site/src/content/docs/zh-tw/reference/configuration/server.md
index 52c16285cab..73a7f0f583e 100644
--- a/docs-site/src/content/docs/zh-tw/reference/configuration/server.md
+++ b/docs-site/src/content/docs/zh-tw/reference/configuration/server.md
@@ -10,7 +10,7 @@ description: 監聽器、遠端存取、許可金鑰、逾時、儲存、sidecar
 | 欄位 | 型別 | 預設值 | 意義 |
 | --- | --- | --- | --- |
 | `port` | `number` | `10100` | 代理監聽連接埠。 |
-| `hostname?` | `string` | `"127.0.0.1"` | 綁定位址。非回送綁定需要 `OPENCODEX_API_AUTH_TOKEN`。 |
+| `hostname?` | `string` | `"127.0.0.1"` | 繫結位址。非回環繫結需要 `config.apiKeys` 中的用戶端金鑰，或依序從 `OPENCODEX_API_AUTH_TOKEN`、`OCX_API_TOKEN_FILE`、已安裝且僅擁有者可讀的 `service-api-token` 解析的共用資料權杖。參閱[遠端存取](#remote-access)。 |
 | `proxy?` | `string` | — | 對外 HTTP(S) 或 SOCKS5 代理 URL（`socks5://host:port`）或 `${ENV_VAR}`。HTTP URL 僅在那些變數未設定時套用至 `HTTP_PROXY` / `HTTPS_PROXY`。SOCKS5 URL 使用內建的真實 SOCKS5 通道，也會套用至 `ALL_PROXY`（`ocx start --socks5`），並清除此行程繼承的 `HTTP(S)_PROXY`。回送保留在 `NO_PROXY` 中。 |
 | `emptyCompletionRetry?` | `boolean` | `false` | 明確啟用：當 Responses 完成時沒有文字或工具呼叫，以相同請求重試一次。重試可能產生費用。`OCX_EMPTY_COMPLETION_RETRY=0` 可在不變更設定的情況下停用；combo 與 routed-compaction turn 不適用。 |
 | `stallTimeoutSec?` | `number` | `300`（public）/ 停用（local） | 上游無有效進展（Responses 與原生 Chat）多少秒後切斷串流。未設定時**本地**上游（loopback、private、`.local`/`.lan` 名稱）預設停用，公網上游預設 300 秒；正值對兩者生效（最小 1 秒）；`0` 全面停用靜默 watchdog。對於把 canonical ChatGPT SSE 折疊為非串流 JSON 的 Responses 請求，即使 watchdog 已停用，仍保留獨立的 15 分鐘整體上限。`/v1/responses/compact` 的擱置回應本文讀取共用此預算，但即使本地上游也預設 300 秒；明確值（含 `0`）優先。 |
@@ -39,16 +39,18 @@ description: 監聽器、遠端存取、許可金鑰、逾時、儲存、sidecar
 
 原生 Chat 等待上游輸出時也使用 `stallTimeoutSec`。非空文字、推理、拒絕內容、工具更新及完成事件會重設等待額度；保活註解、僅角色事件及單獨的用量資訊不會。等待慢速用戶端讀取時暫停計時。逾時產生 `upstream_stall_timeout`：串流請求收到錯誤事件，非串流請求回傳 HTTP 502。終態結果到達前取消請求會回傳取消錯誤，不會將部分答案當成成功。非串流 Chat 支援 LF、CRLF 與多行 data 的 SSE 格式。
 
+<a id="remote-access"></a>
+
 ## 遠端存取
 
-預設的 `127.0.0.1` 綁定僅限回送。如 `0.0.0.0` 的非回送位址需要在 `/api/*` 與 data plane 上都進行 token 認證。在啟動前匯出 token：
+預設的 `127.0.0.1` 僅繫結回環位址。繫結至 `0.0.0.0` 等非回環位址時，模型請求需要 `config.apiKeys` 中的用戶端金鑰或共用資料權杖。管理路由 `/api/*` 使用獨立的 `OPENCODEX_ADMIN_AUTH_TOKEN` 或產生的管理員權杖，在回環上也一樣。資料憑證不授予管理存取權；切勿將管理員權杖交給模型用戶端。
 
 ```bash
 export OPENCODEX_API_AUTH_TOKEN="your-secret-token"
 ocx start
 ```
 
-代理在沒有此變數時拒絕遠端綁定。對於背景服務，請在 `ocx service install` 前匯出它，以便 launchd、systemd 或 Task Scheduler 接收它。客戶端應發送：
+範例使用環境變數權杖。若 `OCX_API_TOKEN_FILE` 或私有 `service-api-token` 已提供權杖，或已設定有效的用戶端金鑰，就不必匯出該變數。`ocx service install` 可以建立缺少的權杖檔案，不強制要求匯出此變數。模型用戶端可以傳送：
 
 ```text
 x-opencodex-api-key: your-secret-token
@@ -56,13 +58,13 @@ x-opencodex-api-key: your-secret-token
 
 | 端點 | `Authorization: Bearer` | `x-opencodex-api-key` | `x-api-key` |
 | --- | --- | --- | --- |
-| `/v1/responses` | 不接受 | **必填** | 不接受 |
-| `/v1/chat/completions` | 不接受 | **必填** | 不接受 |
+| `/v1/responses` | 接受 | 接受 | 不接受 |
+| `/v1/chat/completions` | 接受 | 接受 | 不接受 |
 | `/v1/messages` | 接受 | 接受 | 接受 |
 | `/v1/messages/count_tokens` | 接受 | 接受 | 接受 |
 | `/v1/models` | 接受 | 接受 | 接受 |
 
-Responses 與 Chat Completions 為可能的 Codex Direct passthrough 保留 `Authorization`，因此那裡僅接受專屬的許可標頭。儀表板生成的 `apiKeys` 可在啟動後取代環境 token；候選值以常數時間比對。
+Responses 與 Chat Completions 接受 `x-opencodex-api-key` 中已識別的資料平面憑證；僅當該專用標頭缺少或移除前後空白後為空時，也接受 `Authorization: Bearer`。移除前後空白後非空的專用標頭具有優先權，即使其值無效，有效 bearer 也不能補救。無關 bearer 不授予代理存取權，這些路由不接受 `x-api-key`。產生的 `apiKeys` 與共用資料權杖以常數時間比較；管理憑證不授予模型存取權。
 
 Messages 與 `count_tokens` 為相容路由客戶端仍接受三種許可形式。但在非回環綁定上，原生 Anthropic 透傳只透過
 `x-opencodex-api-key` 接受代理許可，並將 `Authorization` 與 `x-api-key` 保留給 Anthropic
diff --git a/docs-site/src/content/docs/zh-tw/reference/management-api.md b/docs-site/src/content/docs/zh-tw/reference/management-api.md
index 8f668df783d..c2405560e68 100644
--- a/docs-site/src/content/docs/zh-tw/reference/management-api.md
+++ b/docs-site/src/content/docs/zh-tw/reference/management-api.md
@@ -7,6 +7,8 @@ description: opencodex 控制平面的認證、錯誤與端點參考。
 
 使用[網頁儀表板](/zh-tw/guides/web-dashboard/)作為互動式客戶端，或在建構自動化時使用此參考。持久值最終遵循[設定](/zh-tw/reference/configuration/)。
 
+<a id="authentication-model"></a>
+
 ## 認證模型
 
 管理 API 有自己的管理憑證，獨立於 data-plane API 金鑰。在啟動時，opencodex 依此順序解析它：
diff --git a/docs-site/src/data/code-block-locale.ts b/docs-site/src/data/code-block-locale.ts
new file mode 100644
index 00000000000..31adf1115ea
--- /dev/null
+++ b/docs-site/src/data/code-block-locale.ts
@@ -0,0 +1,12 @@
+/** Resolve Expressive Code UI language from content files, including encoded Windows URLs. */
+export function codeBlockLocale(file: { path?: string; url?: URL }): string {
+  for (const candidate of [file.path, file.url?.pathname]) {
+    if (!candidate) continue;
+    let path = candidate.replaceAll("\\", "/");
+    try { path = decodeURIComponent(path); } catch { /* Keep a malformed escape literal. */ }
+    const relative = path.split("/src/content/docs/").at(1) ?? path.replace(/^\//, "");
+    const locale = /^([a-z]{2}(?:-[a-z]{2})?)\//.exec(relative)?.[1];
+    if (locale) return locale.replace(/-([a-z]{2})$/, (_, region: string) => `-${region.toUpperCase()}`);
+  }
+  return "en";
+}
diff --git a/docs-site/src/data/frontier-i18n.ts b/docs-site/src/data/frontier-i18n.ts
index b9991be6257..cf780aa7b28 100644
--- a/docs-site/src/data/frontier-i18n.ts
+++ b/docs-site/src/data/frontier-i18n.ts
@@ -1,8 +1,114 @@
 // Generated from PR #144 (gui/src/i18n/{en,ko,zh}.ts) — frontier.* keys only.
-// German strings from the PR are dropped: the docs-site ships en/fr/ko/zh-CN/zh-TW/ru/ja/tr.
+// German strings from the PR are dropped: the docs-site ships en/es/fr/ko/zh-CN/zh-TW/ru/ja/tr.
 export const FRONTIER_STRINGS = {
+  es: {
+  "frontier.subtitle": "Compara modelos en pruebas públicas de agentes de programación: capacidad frente a costo por tarea. Elige un dominio y una tabla. Son instantáneas que se actualizan con las versiones de OpenCodex, no mediciones en tiempo real.",
+  "frontier.updated": "Instantánea del {date}",
+  "frontier.tasks": "{count} tareas",
+  "frontier.domainsAria": "Dominios de tarea",
+  "frontier.domainHint": "Los dominios agrupan las tablas según lo que miden: programación, frontend, terminal, seguridad o inteligencia general.",
+  "frontier.domain.all": "Todos",
+  "frontier.domain.coding": "Programación",
+  "frontier.domain.frontend": "Frontend",
+  "frontier.domain.terminal": "Terminal",
+  "frontier.domain.security": "Seguridad",
+  "frontier.domain.intelligence": "Inteligencia",
+  "frontier.benchmarksAria": "Tablas de pruebas comparativas",
+  "frontier.chartAria": "Gráfico comparativo de modelos",
+  "frontier.chartKindsAria": "Tipo de gráfico",
+  "frontier.chart.scatter": "Dispersión",
+  "frontier.chart.costStack": "Costos apilados",
+  "frontier.chart.score": "Por puntuación",
+  "frontier.chart.efficiency": "Por valor",
+  "frontier.chart.reasoning": "Por razonamiento",
+  "frontier.chartHint.scatter": "Costo frente a puntuación: los puntos más altos y a la izquierda suelen ofrecer mejor valor.",
+  "frontier.chartHint.costStack": "Costo por tarea de Intelligence Index, apilado por respuesta, razonamiento, escritura en caché, aciertos de caché y entrada.",
+  "frontier.chartHint.score": "Clasificación horizontal por puntuación de referencia.",
+  "frontier.chartHint.efficiency": "Clasificación horizontal por puntuación / $ (más alto es mejor valor).",
+  "frontier.chartHint.reasoning": "Puntuación frente a costo por ejecución: cada línea representa un modelo con distintos esfuerzos de razonamiento. Pasa el puntero por un punto para ver su nivel; el nombre aparece en el punto de máxima puntuación.",
+  "frontier.effortViewAria": "Vista del esfuerzo de razonamiento",
+  "frontier.effortView.best": "El mejor modo de razonamiento",
+  "frontier.effortView.all": "Todos los niveles de razonamiento",
+  "frontier.effortViewDisabled": "Esta tabla solo tiene un nivel de esfuerzo por modelo; alternar entre Mejor y Todos no cambia los resultados.",
+  "frontier.tableAria": "Tabla de clasificación de modelos",
+  "frontier.filter.models": "Modelos",
+  "frontier.filter.effort": "Esfuerzo",
+  "frontier.filter.price": "Rango de precios",
+  "frontier.filter.tags": "Caso de uso",
+  "frontier.price.lt3": "Menos de $3",
+  "frontier.price.mid": "$3–8",
+  "frontier.price.gt8": "Más de $8",
+  "frontier.tag.workhorse": "Uso habitual",
+  "frontier.tag.planner": "Planificador",
+  "frontier.tag.frontier": "Frontera",
+  "frontier.tag.cheapSubagent": "Subagente económico",
+  "frontier.tag.fast": "Rápido",
+  "frontier.ranking": "Clasificación",
+  "frontier.rankingHint": "Ordenado por puntuación / $ (más alto es mejor valor)",
+  "frontier.col.model": "Modelo",
+  "frontier.col.effort": "Esfuerzo",
+  "frontier.col.cost": "Costo / tarea",
+  "frontier.col.efficiency": "Puntuación / $",
+  "frontier.col.tags": "Caso de uso",
+  "frontier.bestValue": "La mejor relación calidad-precio",
+  "frontier.bestScore": "Mejor puntuación",
+  "frontier.sourceLink": "Fuente",
+  "frontier.costKindEstimated": "Los costos de esta tabla son estimaciones o combinaciones de precios de API. La clasificación por puntuación/$ y Mejor valor se deshabilitan hasta que todas las filas tengan un costo por tarea medido por la fuente.",
+  "frontier.chartValueDisabled": "Por valor requiere una tabla en la que todos los costos por tarea estén medidos por la fuente, sin estimaciones.",
+  "frontier.rankingHintScoreOnly": "Ordenado solo por puntuación: los costos de esta tabla no se midieron de manera uniforme.",
+  "frontier.col.costEstimated": "Costo est.",
+  "frontier.col.efficiencyNa": "Puntuación / $",
+  "frontier.empty": "No hay datos de referencia cargados.",
+  "frontier.noMatches": "No hay modelos que coincidan con estos filtros.",
+  "frontier.noCostParts": "Esta tabla no desglosa el costo de los tokens. Abre AA Intelligence Index para ver las barras apiladas de respuesta, razonamiento, caché y entrada.",
+  "frontier.boardNoCostParts": "Esta tabla no tiene desglose de costos. Está disponible en Costos apilados para las tablas que desglosan el costo de los tokens.",
+  "frontier.noMultiEffort": "Esta tabla no tiene varios niveles de esfuerzo para comparar.",
+  "frontier.boardNoMultiEffort": "Esta tabla no compara varios niveles de esfuerzo. Abre FrontierCode u otra tabla con varios niveles.",
+  "frontier.col.harness": "Entorno de evaluación",
+  "frontier.filter.harness": "Entorno de evaluación",
+  "frontier.board.deepswe.title": "DeepSWE",
+  "frontier.board.deepswe.xLabel": "Costo medio por tarea (USD)",
+  "frontier.board.deepswe.yLabel": "Pass@1",
+  "frontier.board.deepswe.sourceNote": "Instantánea ilustrativa de la tabla de clasificación pública de DeepSWE (mini-swe-agent). Las puntuaciones y los costos no son mediciones en vivo de OpenCodex.",
+  "frontier.board.aa-coding-agent.title": "AA Coding Agent",
+  "frontier.board.aa-coding-agent.xLabel": "Costo por tarea (USD)",
+  "frontier.board.aa-coding-agent.yLabel": "Coding Agent Index",
+  "frontier.board.aa-coding-agent.sourceNote": "Instantánea de Coding Agent Index de Artificial Analysis, posterior a la disponibilidad general de GPT-5.6 (2026-07-09). Consulta provenance.url. No son mediciones en tiempo real de OpenCodex.",
+  "frontier.board.aa-intelligence-index.title": "AA Intelligence Index",
+  "frontier.board.aa-intelligence-index.xLabel": "Costo por tarea de índice de inteligencia (USD)",
+  "frontier.board.aa-intelligence-index.yLabel": "Intelligence Index",
+  "frontier.board.aa-intelligence-index.sourceNote": "Instantánea ilustrativa basada en el costo por tarea de Intelligence Index de Artificial Analysis: respuesta, razonamiento, escritura y aciertos de caché, y entrada. Los totales coinciden con las cifras publicadas donde se indica; los segmentos son aproximaciones para el gráfico. No son mediciones en tiempo real de OpenCodex.",
+  "frontier.board.frontiercode.title": "FrontierCode",
+  "frontier.board.frontiercode.xLabel": "Costo medio por ejecución (USD)",
+  "frontier.board.frontiercode.yLabel": "Puntuación de fusionabilidad",
+  "frontier.board.frontiercode.sourceNote": "Instantánea ilustrativa de cognition.com/frontiercode (FrontierCode 1.1 Main, julio de 2026). La puntuación evalúa si el cambio puede integrarse; el costo es el promedio de USD por ejecución. Las vistas del mejor nivel y de todos los niveles de razonamiento corresponden al selector de la clasificación de Cognition. No son mediciones en tiempo real de OpenCodex.",
+  "frontier.board.frontierswe.title": "FrontierSWE",
+  "frontier.board.frontierswe.xLabel": "Costo relativo de API (mezcla $/MTok)",
+  "frontier.board.frontierswe.yLabel": "Dominancia",
+  "frontier.board.frontierswe.sourceNote": "Instantánea ilustrativa de frontierswe.com (dominancia Mean@5). El eje X combina precios públicos de API en $/MTok como referencia de costo relativo; no mide $/tarea. No son mediciones en tiempo real de OpenCodex.",
+  "frontier.board.terminal-bench-2.1.title": "Terminal Bench 2.1",
+  "frontier.board.terminal-bench-2.1.xLabel": "Costo estimado (USD, ilustrativo)",
+  "frontier.board.terminal-bench-2.1.yLabel": "Precisión",
+  "frontier.board.terminal-bench-2.1.sourceNote": "Combinación ilustrativa de resultados de Terminal-Bench 2.1 verificados por Snorkel y cifras publicadas de GPT-5.6. Los costos son aproximaciones basadas en coincidencias con DeepSWE o estimaciones de precios de API. No son mediciones en tiempo real de OpenCodex.",
+  "frontier.board.program-bench.title": "Program Bench",
+  "frontier.board.program-bench.xLabel": "Costo medio por tarea (USD)",
+  "frontier.board.program-bench.yLabel": "Casi resuelto",
+  "frontier.board.program-bench.sourceNote": "Instantánea de la clasificación ampliada de programbench.com (mini-SWE-agent, 200 tareas). La puntuación indica tareas casi resueltas, con al menos el 95 % de las pruebas correctas. El costo es el promedio publicado de API en $/tarea. No son mediciones en tiempo real de OpenCodex.",
+  "frontier.board.swe-marathon.title": "SWE Marathon",
+  "frontier.board.swe-marathon.xLabel": "Costo relativo estimado por ejecución (USD)",
+  "frontier.board.swe-marathon.yLabel": "Tasa de resolución",
+  "frontier.board.swe-marathon.sourceNote": "Instantánea ilustrativa de swe-marathon.org (pass@1 en 20 tareas de horizonte muy largo). El eje de costo muestra una estimación relativa por ejecución con trayectorias largas; no se publica $/tarea. No son mediciones en tiempo real de OpenCodex.",
+  "frontier.board.frontend-code-arena.title": "Frontend Code Arena",
+  "frontier.board.frontend-code-arena.xLabel": "Costo relativo de API (mezcla $/MTok)",
+  "frontier.board.frontend-code-arena.yLabel": "Arena Elo",
+  "frontier.board.frontend-code-arena.sourceNote": "Instantánea ilustrativa de arena.ai Code Arena | WebDev: Elo basado en votos humanos a ciegas sobre tareas de frontend, del 16 de julio de 2026. El eje X combina precios públicos de API en $/MTok; el Elo de preferencias no mide $/tarea. No son mediciones en tiempo real de OpenCodex.",
+  "frontier.board.cybench.title": "Cybench",
+  "frontier.board.cybench.xLabel": "Costo relativo estimado por ejecución (USD)",
+  "frontier.board.cybench.yLabel": "% resuelto no guiado",
+  "frontier.board.cybench.sourceNote": "Instantánea ilustrativa de cybench.github.io: porcentaje resuelto sin guía en tareas profesionales de CTF. Muchas filas proceden de fichas técnicas del sistema o de subconjuntos, no de una ejecución uniforme de toda la suite. Los costos son estimaciones relativas por ejecución del agente; Cybench no publica $/tarea. No son mediciones en tiempo real de OpenCodex."
+},
   en: {
-  "frontier.subtitle": "Compare models on public coding-agent benchmarks: capability vs cost per task. Pick a domain, then a board; filter by model, effort, price, or use-case. Snapshot data — update with OpenCodex releases, not live metering.",
+  "frontier.subtitle": "Compare models on public coding-agent benchmarks: capability vs cost per task. Pick a domain, then a board. Snapshot data — update with OpenCodex releases, not live metering.",
   "frontier.updated": "Snapshot {date}",
   "frontier.tasks": "{count} tasks",
   "frontier.domainsAria": "Task domains",
@@ -108,7 +214,7 @@ export const FRONTIER_STRINGS = {
   "frontier.board.cybench.sourceNote": "Illustrative snapshot from cybench.github.io (unguided % solved on professional CTF tasks). Many rows are system-card / subset results, not one uniform full-suite run. Costs are relative agent-run estimates — Cybench does not publish $/task. Not live OpenCodex metering."
 },
   fr: {
-  "frontier.subtitle": "Comparez les modèles sur des bancs d’essai publics d’agents de programmation, selon leurs capacités et leur coût par tâche. Choisissez un domaine, puis un tableau, et filtrez par modèle, niveau de raisonnement, prix ou cas d’usage. Il s’agit d’instantanés mis à jour avec les versions d’OpenCodex, et non de mesures en direct.",
+  "frontier.subtitle": "Comparez les modèles sur des bancs d’essai publics d’agents de programmation, selon leurs capacités et leur coût par tâche. Choisissez un domaine, puis un tableau. Il s’agit d’instantanés mis à jour avec les versions d’OpenCodex, et non de mesures en direct.",
   "frontier.updated": "Instantané du {date}",
   "frontier.tasks": "{count} tâches",
   "frontier.domainsAria": "Domaines de tâches",
@@ -214,7 +320,7 @@ export const FRONTIER_STRINGS = {
   "frontier.board.cybench.sourceNote": "Instantané indicatif de cybench.github.io : pourcentage de tâches CTF professionnelles résolues sans aide. De nombreuses lignes proviennent de fiches système ou de sous-ensembles, et non d’une exécution uniforme de la suite complète. Les coûts sont des estimations relatives d’exécution d’agent, car Cybench ne publie pas de coût par tâche. Il ne s’agit pas de mesures OpenCodex en direct.",
 },
   ko: {
-  "frontier.subtitle": "공개 코딩 에이전트 벤치마크에서 모델을 비교합니다: 능력 vs 작업당 비용. 도메인을 고른 뒤 보드를 선택하고 모델·노력·가격·용도로 필터하세요. 스냅샷 데이터이며 OpenCodex 릴리스 때 갱신합니다(실시간 계측 아님).",
+  "frontier.subtitle": "공개 코딩 에이전트 벤치마크에서 모델을 비교합니다: 능력 vs 작업당 비용. 도메인을 고른 뒤 보드를 선택하세요. 스냅샷 데이터이며 OpenCodex 릴리스 때 갱신합니다(실시간 계측 아님).",
   "frontier.updated": "스냅샷 {date}",
   "frontier.tasks": "작업 {count}개",
   "frontier.domainsAria": "작업 도메인",
@@ -320,7 +426,7 @@ export const FRONTIER_STRINGS = {
   "frontier.board.cybench.sourceNote": "Cybench unguided 해결률 예시. 비용은 상대 추정입니다. 재게시 시 Cybench를 인용하세요. OpenCodex 실시간 미터링 아님."
 },
   "zh-cn": {
-  "frontier.subtitle": "在公开编程代理基准上比较模型：能力 vs 每任务成本。先选领域再选榜单，并按模型、推理力度、价格或用途筛选。为快照数据，随 OpenCodex 发版更新，非实时计量。",
+  "frontier.subtitle": "在公开编程代理基准上比较模型：能力 vs 每任务成本。先选领域再选榜单。为快照数据，随 OpenCodex 发版更新，非实时计量。",
   "frontier.updated": "快照 {date}",
   "frontier.tasks": "{count} 项任务",
   "frontier.domainsAria": "任务领域",
@@ -426,7 +532,7 @@ export const FRONTIER_STRINGS = {
   "frontier.board.cybench.sourceNote": "Cybench unguided 解决率示意。成本为相对估计。转载请引用 Cybench。非 OpenCodex 实时计量。"
 },
   "zh-tw": {
-  "frontier.subtitle": "在公開程式設計代理基準上比較模型：能力 vs 每任務成本。先選領域再選榜單，並按模型、推理力度、價格或用途篩選。為快照資料，隨 OpenCodex 發版更新，非即時計量。",
+  "frontier.subtitle": "在公開程式設計代理基準上比較模型：能力 vs 每任務成本。先選領域再選榜單。為快照資料，隨 OpenCodex 發版更新，非即時計量。",
   "frontier.updated": "快照 {date}",
   "frontier.tasks": "{count} 項任務",
   "frontier.domainsAria": "任務領域",
@@ -532,7 +638,7 @@ export const FRONTIER_STRINGS = {
   "frontier.board.cybench.sourceNote": "Cybench unguided 解決率示意。成本為相對估計。轉載請引用 Cybench。非 OpenCodex 即時計量。"
 },
   ru: {
-  "frontier.subtitle": "Сравнивайте модели на публичных бенчмарках кодинг-агентов: способности против стоимости задачи. Выберите область, затем доску; фильтруйте по модели, уровню рассуждений, цене или назначению. Данные — снапшот: обновляются с релизами OpenCodex, а не в реальном времени.",
+  "frontier.subtitle": "Сравнивайте модели на публичных бенчмарках кодинг-агентов: способности против стоимости задачи. Выберите область, затем доску. Данные — снапшот: обновляются с релизами OpenCodex, а не в реальном времени.",
   "frontier.updated": "Снапшот {date}",
   "frontier.tasks": "{count} задач",
   "frontier.domainsAria": "Области задач",
@@ -638,7 +744,7 @@ export const FRONTIER_STRINGS = {
   "frontier.board.cybench.sourceNote": "Иллюстративный снапшот с cybench.github.io (% профессиональных CTF-задач, решённых без подсказок, unguided). Многие строки — результаты из system card или на подмножествах, а не один единый прогон полного набора. Стоимости — относительные оценки агентных прогонов: Cybench не публикует $/task. Это не учёт OpenCodex в реальном времени.",
   },
   ja: {
-  "frontier.subtitle": "公開のコーディングエージェントベンチマークでモデルを比較します: 能力 vs タスクあたりコスト。ドメインを選び、次にボードを選択し、モデル・推論負荷・価格・用途でフィルタします。スナップショットデータで OpenCodex リリース時に更新されます(ライブ計測ではありません)。",
+  "frontier.subtitle": "公開のコーディングエージェントベンチマークでモデルを比較します: 能力 vs タスクあたりコスト。ドメインを選び、次にボードを選択します。スナップショットデータで OpenCodex リリース時に更新されます(ライブ計測ではありません)。",
   "frontier.updated": "スナップショット {date}",
   "frontier.tasks": "{count} タスク",
   "frontier.domainsAria": "タスクドメイン",
@@ -744,7 +850,7 @@ export const FRONTIER_STRINGS = {
   "frontier.board.cybench.sourceNote": "cybench.github.io の参考スナップショット(プロフェッショナル CTF タスクの unguided 解決率)。多くの行は system card の結果またはサブセットの結果であり、一つの統一フルスイート実行ではありません。コストはエージェント実行の相対推定です — Cybench は $/task を公開していません。OpenCodex のライブ計測ではありません。",
   },
   tr: {
-  "frontier.subtitle": "Modelleri genel kodlama ajanı kıyaslamalarında karşılaştırın: yetenek ve görev başına maliyet. Bir alan ve ardından bir pano seçin; modele, akıl yürütme seviyesine, fiyata veya kullanım senaryosuna göre filtreleyin. Anlık görüntü verileri — canlı ölçüm değil, OpenCodex sürümleriyle güncellenir.",
+  "frontier.subtitle": "Modelleri genel kodlama ajanı kıyaslamalarında karşılaştırın: yetenek ve görev başına maliyet. Bir alan ve ardından bir pano seçin. Anlık görüntü verileri — canlı ölçüm değil, OpenCodex sürümleriyle güncellenir.",
   "frontier.updated": "Anlık Görüntü {date}",
   "frontier.tasks": "{count} görev",
   "frontier.domainsAria": "Görev alanları",
diff --git a/docs-site/src/data/telemetry-dashboard-i18n.ts b/docs-site/src/data/telemetry-dashboard-i18n.ts
index 19ed927000a..064fb40da83 100644
--- a/docs-site/src/data/telemetry-dashboard-i18n.ts
+++ b/docs-site/src/data/telemetry-dashboard-i18n.ts
@@ -1,5 +1,6 @@
 export const TELEMETRY_DASHBOARD_LOCALES = [
   "en",
+  "es",
   "fr",
   "ko",
   "zh-cn",
@@ -215,6 +216,98 @@ export const TELEMETRY_DASHBOARD_STRINGS: Readonly<
       "Visual design and contribution heatmap patterns adapted from",
     creditSuffix: "(MIT License).",
   },
+  es: {
+    "title": "Panel de uso",
+    "subtitle": "Estadísticas diarias anónimas de todo el proyecto, comunicadas por las instalaciones de opencodex. Se activan de forma predeterminada después de que una persona vea el aviso de privacidad, salvo rechazo o desactivación.",
+    "rangeAria": "Periodo del informe",
+    "range7d": "7 d",
+    "range30d": "30 d",
+    "range90d": "90 d",
+    "range365d": "365 d",
+    "updatedPrefix": "Actualizado",
+    "updatedPending": "Esperando una instantánea",
+    "privacyBadge": "Solo estadísticas anónimas",
+    "selfReportedLabel": "Datos comunicados por instalaciones de opencodex",
+    "privacyBody": "La telemetría está activada de forma predeterminada y no envía nada hasta que una persona vea el aviso. Los informes incluyen recuentos diarios de categorías predefinidas y un hash de instalación que cambia a diario; nunca prompts, respuestas de modelos, claves API, identificadores de cuenta, rutas de archivos ni direcciones IP.",
+    "privacyOptOutHint": "Desactívala cuando quieras con ocx telemetry disable, OCX_TELEMETRY=0 o DO_NOT_TRACK=1.",
+    "privacyGuideLink": "Guía de telemetría y privacidad",
+    "stateLoadingTitle": "Cargando la telemetría del proyecto…",
+    "stateLoadingBody": "Obteniendo las estadísticas de uso de telemetry.opencodex.me.",
+    "stateEmptyTitle": "El recolector aún no está desplegado",
+    "stateEmptyBody": "El recolector público de telemetry.opencodex.me aún no está desplegado o no ha registrado estadísticas diarias para este periodo.",
+    "stateErrorTitle": "No se pudo cargar la telemetría en vivo",
+    "stateErrorBody": "La solicitud a telemetry.opencodex.me no terminó; puede que el recolector aún no esté desplegado o no esté disponible temporalmente.",
+    "retryButton": "Reintentar",
+    "kpiSectionAria": "Métricas principales de uso",
+    "kpiActiveInstalls": "Promedio de instalaciones activas al día",
+    "kpiNewInstalls": "Instalaciones nuevas",
+    "kpiRequests": "Solicitudes",
+    "kpiTokens": "Tokens totales",
+    "kpiActiveHours": "Horas activas",
+    "tokenMixTitle": "Distribución de tokens",
+    "tokenMixSubtitle": "Categorías de tokens sin solapamiento para todas las familias de modelos comunicadas; los segmentos suman el 100% de los tokens.",
+    "tokenInput": "Entrada",
+    "tokenCacheRead": "Lectura de caché",
+    "tokenCacheWrite": "Escritura de caché",
+    "tokenOutput": "Salida",
+    "tokenReasoning": "Razonamiento",
+    "heatmapTitle": "Mapa de actividad de 365 días",
+    "heatmapSubtitle": "Instalaciones que envían informes cada día durante las últimas 52 semanas (UTC).",
+    "heatmapActiveDays": "{count} días activos",
+    "heatmapPeakDay": "Máximo: {date} ({count})",
+    "heatmapLess": "Bajo",
+    "heatmapMore": "Alto",
+    "heatmapTooltipUnit": "instalaciones activas",
+    "heatmapKeyboardHint": "Usa las flechas para consultar los días contiguos, Inicio y Fin para ir a los extremos del periodo, y Escape para cerrar la información.",
+    "dailyChartTitle": "Uso diario por tipo de proveedor",
+    "dailyChartSubtitle": "Volumen diario acumulado durante el periodo seleccionado.",
+    "metricTokens": "Tokens",
+    "metricRequests": "Solicitudes",
+    "providersTitle": "Tipos de proveedor",
+    "providersSubtitle": "Participación de cada proveedor de la lista predefinida en tokens y solicitudes.",
+    "modelsTitle": "Familias de modelos",
+    "modelsSubtitle": "Participación de las familias generales de modelos en tokens y solicitudes.",
+    "colProvider": "Tipo de proveedor",
+    "colModel": "Familia de modelos",
+    "colRequests": "Solicitudes",
+    "colTokens": "Tokens",
+    "colShare": "Porcentaje de tokens",
+    "versionsTitle": "Versiones",
+    "versionsSubtitle": "Instalaciones activas y que informan por primera vez, por versión.",
+    "platformsTitle": "Plataformas",
+    "platformsSubtitle": "Distribución por sistema operativo y arquitectura de CPU.",
+    "channelsTitle": "Canales de instalación",
+    "channelsSubtitle": "Cómo se instalaron los proxies que envían informes.",
+    "colVersion": "Versión",
+    "colPlatform": "Plataforma",
+    "colChannel": "Canal",
+    "colInstalls": "Instalaciones",
+    "colNewInstalls": "Nuevas",
+    "colInstallShare": "Porcentaje",
+    "reliabilityTitle": "Fiabilidad y resultados",
+    "reliabilitySubtitle": "Proporción de resultados y principales causas de fallo de la lista predefinida.",
+    "completionRateLabel": "Tasa de finalización",
+    "outcomeCompleted": "Finalizadas",
+    "outcomeIncomplete": "Incompletas",
+    "outcomeAborted": "Canceladas",
+    "outcomeFailed": "Fallidas",
+    "topErrorsTitle": "Principales causas de fallo",
+    "colErrorCause": "Causa del fallo",
+    "colErrorCount": "Cantidad",
+    "noErrorsRecorded": "No se registraron causas de fallo en este periodo.",
+    "downloadsTitle": "Descargas de paquetes y versiones",
+    "downloadsSubtitle": "Recuentos de descargas en vivo de npm (@bitkyc08/opencodex) y de archivos de versiones de GitHub (lidge-jun/opencodex).",
+    "npmWeeklyLabel": "npm (últimos 7 días)",
+    "npmMonthlyLabel": "npm (últimos 30 días)",
+    "npmYearlyLabel": "npm (últimos 365 días)",
+    "githubTotalLabel": "Archivos de versiones de GitHub (total)",
+    "githubLatestLabel": "Archivos de la última versión",
+    "downloadsPartial": "parcial",
+    "downloadsUnavailable": "No disponible",
+    "noDataInTable": "No se comunicaron datos para este periodo.",
+    "creditPrefix": "Diseño visual y patrones del mapa de contribuciones adaptados de",
+    "creditSuffix": "(licencia MIT)."
+},
   fr: {
     title: "Tableau de bord d’utilisation",
     subtitle:
diff --git a/docs-site/src/data/telemetry-leaderboard-i18n.ts b/docs-site/src/data/telemetry-leaderboard-i18n.ts
index 2b754008c5f..984d7038660 100644
--- a/docs-site/src/data/telemetry-leaderboard-i18n.ts
+++ b/docs-site/src/data/telemetry-leaderboard-i18n.ts
@@ -1,9 +1,9 @@
 /**
  * Copy for the opencodex.me leaderboard section (TelemetryLeaderboard.astro): connected public
- * profiles only. Same 8 locales as the anonymous dashboard copy, kept in a separate table because
+ * profiles only. Same locales as the anonymous dashboard copy, kept in a separate table because
  * profiles are something a person connects, while the anonymous telemetry is on by default.
  */
-export const TELEMETRY_LEADERBOARD_LOCALES = ["en", "fr", "ko", "zh-cn", "zh-tw", "ru", "ja", "tr"] as const;
+export const TELEMETRY_LEADERBOARD_LOCALES = ["en", "es", "fr", "ko", "zh-cn", "zh-tw", "ru", "ja", "tr"] as const;
 export type TelemetryLeaderboardLocale = (typeof TELEMETRY_LEADERBOARD_LOCALES)[number];
 
 export interface TelemetryLeaderboardCopy {
@@ -64,6 +64,34 @@ export const TELEMETRY_LEADERBOARD_STRINGS: Record<TelemetryLeaderboardLocale, T
     profileClose: "Close",
     howToJoin: "Connect a profile from the Home screen of your opencodex dashboard, or run ocx telemetry profile connect. Disconnecting deletes it.",
   },
+  "es": {
+    "title": "Clasificación",
+    "subtitle": "Perfiles que sus propietarios conectaron desde su dashboard de opencodex. Los totales diarios son datos comunicados por cada instalación.",
+    "periodAria": "Periodo de la clasificación",
+    "periodDay": "Día",
+    "periodWeek": "Semana",
+    "periodMonth": "Mes",
+    "metricAria": "Ordenar por",
+    "metricTokens": "Tokens",
+    "metricRequests": "Solicitudes",
+    "colRank": "Posición",
+    "colProfile": "Perfil",
+    "colTokens": "Tokens",
+    "colRequests": "Solicitudes",
+    "loading": "Cargando la clasificación…",
+    "empty": "Aún no hay perfiles públicos.",
+    "error": "No se pudo cargar la clasificación.",
+    "retry": "Reintentar",
+    "findLabel": "Buscar un perfil por su nombre público",
+    "findButton": "Buscar",
+    "findInvalid": "El nombre debe tener entre 3 y 24 letras minúsculas, dígitos o guiones.",
+    "profileNotFound": "No hay ningún perfil público con ese nombre.",
+    "profileRankOf": "N.º {rank} de {of}",
+    "profileNotRanked": "Sin clasificar",
+    "profileFamilies": "Familias de modelos principales de este mes",
+    "profileClose": "Cerrar",
+    "howToJoin": "Conecta un perfil desde Inicio en tu dashboard de opencodex, o ejecuta ocx telemetry profile connect. Desconectarlo lo elimina."
+},
   "fr": {
     title: "Classement",
     subtitle: "Profils connectés par leurs propriétaires depuis leur tableau de bord opencodex. Les totaux quotidiens sont autodéclarés.",
@@ -272,4 +300,3 @@ export function resolveTelemetryLeaderboardLocale(locale: string | null | undefi
 export function getTelemetryLeaderboardCopy(locale: string | null | undefined): TelemetryLeaderboardCopy {
   return TELEMETRY_LEADERBOARD_STRINGS[resolveTelemetryLeaderboardLocale(locale)];
 }
-
diff --git a/scripts/client-support-matrix/locales.ts b/scripts/client-support-matrix/locales.ts
index 537f68b5548..e0c2e05d86a 100644
--- a/scripts/client-support-matrix/locales.ts
+++ b/scripts/client-support-matrix/locales.ts
@@ -73,6 +73,39 @@ export const LOCALES = {
     maintenanceHeading: "Keeping this page current",
     maintenance: "This page is generated by `scripts/generate-client-support-matrix.ts` from the export, managed-integration and native-integration registries. To add a client, add its entry in `scripts/client-support-matrix/metadata.ts` and run `bun run docs:clients`; `bun run docs:clients:check` fails while the committed page is stale.",
   },
+  es: {
+    title: "Compatibilidad con clientes",
+    description: "Qué herramientas de programación conecta opencodex, cómo se conecta cada una y qué protocolo utiliza.",
+    intro: "opencodex es una única pasarela local para tus herramientas de programación con IA y tus modelos. Configura algunas herramientas de forma nativa; para las demás, exporta o administra un archivo de configuración que las dirige al proxy local. Esta página se genera a partir de los registros del código, por lo que enumera exactamente lo que ofrece la versión actual.",
+    levelsHeading: "Niveles de compatibilidad",
+    implementedDefinition: "el cliente figura en el registro. Para las configuraciones exportadas, el protocolo mostrado se lee de la configuración que genera opencodex, y la generación falla si cambia. Un protocolo marcado como *revisado* indica un endpoint determinado mediante una revisión, en lugar de obtenerse de la propia configuración (clientes nativos y clientes que convierten un ajuste en un endpoint concreto); el generador comprueba que el código revisado siga presente. Las filas «Compatible con OpenAI» no afirman que se use un endpoint concreto.",
+    testCoveredDefinition: "cumple implemented y enlaza un caso de prueba elegido durante la revisión que ejercita este cliente. El generador solo comprueba que la prueba siga existiendo y esté habilitada; léela para saber qué verifica.",
+    clientsHeading: "Clientes",
+    columns: { client: "Cliente", native: "Nativo", configExport: "Exportación de configuración", managed: "Integración mediante archivo administrado", protocol: "Protocolo de entrada", level: "Nivel de compatibilidad", runtime: "Verificado en ejecución", notes: "Notas" },
+    runtimeDefinition: "una observación histórica: una persona ejecutó el producto cliente y la versión exactos que se indican con la versión de opencodex mostrada, en el escenario y la fecha señalados, y enlazó la evidencia. No demuestra nada sobre otras versiones o productos. La evidencia se revisa al añadir el resultado; el generador no vuelve a ejecutar la prueba. Un guion significa que no hay ningún resultado registrado.",
+    evidenceLink: "evidencia",
+    runtimeMore: "(+{n} más registrados)",
+    yes: "Sí",
+    curated: "revisado",
+    nativeOpenaiCondition: "solo modelos nativos de OpenAI",
+    openaiCompatible: "Compatible con OpenAI (endpoint elegido por el cliente)",
+    testLink: "prueba",
+    guideLink: "guía",
+    notes: {
+      native: "Configurado por el propio opencodex, sin archivo de configuración exportado.",
+      loopbackOnly: "Solo escucha local.",
+      remoteWithKey: "El exportador también admite la escucha remota (añade la cabecera de clave API).",
+      currentStore: "Escribe en el almacén actual de proveedores del cliente.",
+      sourcePreservingYaml: "Solo edita su propio bloque YAML.",
+      writerLock: "Las escrituras se coordinan mediante un archivo de bloqueo junto a la configuración.",
+      validateApply: "Antes de aplicar los cambios, se ejecuta una comprobación específica del cliente que puede rechazarlos.",
+      clientSelected: "El cliente elige el endpoint a partir de este ajuste (revisado según el comportamiento documentado del cliente).",
+    },
+    endpointsHeading: "Endpoints de entrada",
+    endpointsIntro: "El proxy acepta estos protocolos. Una herramienta que no figure arriba puede conectarse si permite configurar un endpoint personalizado para alguno de ellos.",
+    maintenanceHeading: "Mantener esta página actualizada",
+    maintenance: "Esta página se genera mediante `scripts/generate-client-support-matrix.ts` a partir de los registros de exportación, integración administrada e integración nativa. Para añadir un cliente, añade su entrada en `scripts/client-support-matrix/metadata.ts` y ejecuta `bun run docs:clients`; `bun run docs:clients:check` falla mientras la página guardada en el repositorio esté desactualizada.",
+  },
   fr: {
     title: "Clients pris en charge",
     description: "Les outils de code auxquels opencodex se connecte, la façon dont chacun est relié et le protocole qu’il utilise.",
diff --git a/scripts/test-layout/layout-docs.json b/scripts/test-layout/layout-docs.json
new file mode 100644
index 00000000000..ee1d1d0add4
--- /dev/null
+++ b/scripts/test-layout/layout-docs.json
@@ -0,0 +1,3 @@
+{
+  "docs-spanish-localization.test.ts": "ci-workflows"
+}
diff --git a/scripts/test-layout/layout.json b/scripts/test-layout/layout.json
index 980ea7769da..9d4a792a93a 100644
--- a/scripts/test-layout/layout.json
+++ b/scripts/test-layout/layout.json
@@ -1,7 +1,7 @@
 {
   "version": 1,
   "root": "tests",
-  "explicitShards": ["layout-file-identity.json", "layout-clients.json", "layout-codex-collision.json", "layout-native-profiles.json", "layout-agent-assertion.json", "layout-chat.json", "layout-replay.json", "layout-adapters.json", "layout-jev.json", "layout-workbuddy.json", "layout-combos.json", "layout-credit-renewal.json", "layout-server-inbound.json", "layout-providers.json", "layout-responses.json", "layout-exec-boundary.json", "layout-persistent-dashboard.json", "layout-start-ownership.json", "layout-config.json", "layout-kiro-usage.json", "layout-usage.json", "layout-docs-guides.json", "layout-claude-keychain.json"],
+  "explicitShards": ["layout-file-identity.json", "layout-clients.json", "layout-codex-collision.json", "layout-native-profiles.json", "layout-agent-assertion.json", "layout-chat.json", "layout-replay.json", "layout-adapters.json", "layout-jev.json", "layout-workbuddy.json", "layout-combos.json", "layout-credit-renewal.json", "layout-server-inbound.json", "layout-providers.json", "layout-responses.json", "layout-exec-boundary.json", "layout-persistent-dashboard.json", "layout-start-ownership.json", "layout-config.json", "layout-kiro-usage.json", "layout-usage.json", "layout-docs-guides.json", "layout-docs.json", "layout-claude-keychain.json"],
   "explicit": { "cli-message-mcp-resume.test.ts": "cli", "messaging-mcp-resume.test.ts": "codex-integration", "pr-gates-workflow.test.ts": "ci-workflows", "kimi-monthly-quota.test.ts": "providers", "sync-fanout.test.ts": "cli", "sync-command-fanout.test.ts": "cli", "link-pinned-sync-argv.test.ts": "clients", "sync-link-status.test.ts": "cli", "sync-fanout-process.test.ts": "cli", "codex-installation-acl.test.ts": "codex-integration", "codex-installation-id.test.ts": "codex-integration", "codex-installation-wire.test.ts": "codex-integration", "codex-installation-failover.test.ts": "responses", "service-desktop-recovery.test.ts": "service", "catalog-omit-disabled-native.test.ts": "codex-integration", "provider-input-modalities.test.ts": "providers", "combo-description.test.ts": "routing", "combo-description-catalog.test.ts": "codex-integration", "codex-provider-routing.test.ts": "codex-integration", "config-native-reasoning-retention.test.ts": "config", "server-native-reasoning-retention-merge.test.ts": "server", "server-native-reasoning-retention.test.ts": "server", "config-workflow-budget.test.ts": "config", "server-workflow-budget-settings.test.ts": "server", "responses-retained-reasoning-stream-recovery.test.ts": "responses", "openai-native-hosted-search-history.test.ts": "adapters/openai", "responses-native-compact-search-history.test.ts": "responses", "config-hosted-search-projection.test.ts": "config", "gcp-credential-boundary.test.ts": "adapters/google", "gcp-sa-marker.test.ts": "adapters/google", "gcp-sa-adapter.test.ts": "adapters/google", "management-gcp-credential-input.test.ts": "server", "codex-preserve-signed-in.test.ts": "codex-integration", "cli-account-preservation.test.ts": "cli", "cli-provider-list-active.test.ts": "cli", "service-state-isolation.test.ts": "service", "compaction-history-framing.test.ts": "responses", "catalog-native-max-context.test.ts": "codex-integration", "protocol-argon-thought-boundary.test.ts": "responses", "service-log.test.ts": "service", "messages-native-empty-inline.test.ts": "claude-integration", "catalog-auto-review-override.test.ts": "codex-integration", "management-auto-review-settings.test.ts": "server", "management-auto-review-auth.test.ts": "server", "prefer-model-alias-ids.test.ts": "server", "responses-mimo-envelope.test.ts": "responses", "responses-call-id-linkage.test.ts": "responses", "bridge-terminal-refusal.test.ts": "adapters", "loop-terminal-refusal.test.ts": "images", "web-search-terminal-refusal.test.ts": "web-search", "combo-terminal-refusal.test.ts": "routing", "server-terminal-refusal-wiring.test.ts": "server", "incomplete-reason-normalization.test.ts": "responses", "advisor-retention.test.ts": "advisor", "responses-native-key-cooldown.test.ts": "responses", "responses-run-turn-key-readmission.test.ts": "responses", "qoder-spawn-readmission.test.ts": "adapters", "api-key-selection-cooldown.test.ts": "providers", "api-key-auto-pause-distribution.test.ts": "providers", "explicit-key-pause-oauth-boundary.test.ts": "providers", "server-chat-native-key-selection.test.ts": "server", "compact-key-selection.test.ts": "responses", "messages-native-key-selection.test.ts": "claude-integration", "coding-agent-windows-dispatch.test.ts": "adapters", "coding-agent-native-empty-argv.test.ts": "windows",
     "stop-restore-history-ownership.test.ts": "service",
     "cli-stop-refusal-transport.test.ts": "cli",
diff --git a/structure/ops/docs-and-release.md b/structure/ops/docs-and-release.md
index 11c7210a4ed..8b166a4c9c4 100644
--- a/structure/ops/docs-and-release.md
+++ b/structure/ops/docs-and-release.md
@@ -69,7 +69,7 @@ the persisted values/default, initial refusal, non-direct repair withholding, di
 behavior, and content-free diagnostics. English and all translated copies change together.
 
 The public documentation site lives in `docs-site/` and is built with Astro + Starlight. English is
-served at the site root, with French under `/fr`, Korean under `/ko`, Simplified Chinese under `/zh-cn`, Traditional Chinese under `/zh-tw`, Russian under `/ru`, Japanese under `/ja`, and Turkish under `/tr`. `docs-site/astro.config.mjs` is the locale source of truth.
+served at the site root, with Spanish under `/es`, French under `/fr`, Korean under `/ko`, Simplified Chinese under `/zh-cn`, Traditional Chinese under `/zh-tw`, Russian under `/ru`, Japanese under `/ja`, and Turkish under `/tr`. `docs-site/astro.config.mjs` is the locale source of truth.
 
 Internal links are checked in two places. `docs-site/src/integrations/internal-links.mjs` runs inside the
 Astro build, so the CI `docs` job and Deploy Docs both refuse a site whose generated HTML carries an
@@ -83,15 +83,15 @@ Server-configuration credential rows in English and every locale copy distinguis
 Proxy-format, adapter, and provider documentation distinguishes server-level SOCKS5 configured outbound fetch from scheme-specific HTTP(S) routing, and every locale copy carrying that claim stays aligned. The public pages own the runtime detail rather than duplicating it here.
 
 Manual navigation is defined in `docs-site/astro.config.mjs`. When adding a public page, update the
-sidebar and either add localized copies or intentionally accept Starlight fallback behavior.
+sidebar and either add localized copies or intentionally accept Starlight fallback behavior. Use slugs for local pages, including Platform Support and OS Keychain, so navigation preserves the selected locale. `tests/ci-workflows/docs-spanish-localization.test.ts` guards canonical Spanish coverage, literal provider-key references, protected remote examples, foreground quickstart alternatives, separate-terminal and Bash/stdin pairing recipes, Pi reasoning metadata, and the data/management credential and admission-header distinctions across shipped locale copies, including empty-header bearer fallback. `tests/ci-workflows/docs-remote-hub-claims.test.ts` validates Docker initialization against the image seed and configuration schema; `tests/ci-workflows/docs-bun-source-requirement.test.ts` checks current bundle claims against the package pin.
 
 Provider preset totals are recounted from the current registry when a preset lands. The
 documented split is 107 total: 86 key-based, 17 OAuth, three local, and one default
-ChatGPT-forward preset. The English provider guide, all seven translated copies, and all eight
-quickstarts carry the same counts.
+ChatGPT-forward preset. The English provider guide, every translated copy, and every locale's
+quickstart carry the same counts.
 
-That recount is no longer a manual obligation. Seventeen places restate these numbers and sixteen
-of them drifted once already — the English guide reached 95 while every translation and every
+That recount is no longer a manual obligation. These numbers are repeated across the guides and
+quickstarts and drifted once already — the English guide reached 95 while every translation and every
 quickstart, the English one included, still said 94. Both numbers read as plausible, so nothing
 caught it. `tests/ci-workflows/docs-provider-preset-counts.test.ts` now derives the total and the
 key-based split from `PROVIDER_REGISTRY` and asserts them against each page, so the next preset
@@ -118,7 +118,7 @@ sharing a model-name fragment remain distinct from current Codex-native support.
 The Remote Hub guide distinguishes selected-runtime readiness from general runtime diagnostics;
 `tests/cli/cli-connect-readiness.test.ts` exercises that boundary and general status's single discovery pass with isolated executable fixtures.
 
-The provider guide's OrcaRouter login section in English and all seven translated sources follows
+The provider guide's OrcaRouter login section in English and every translated source follows
 the [bounded ingestion contract](../transports/inventory.md#bounded-response-ingestion-and-orcarouter-login):
 64 KiB of valid UTF-8 JSON and one 30-second deadline covering headers and body. These are login
 limits, so the public guide does not apply them to inference payloads.
diff --git a/structure/ops/test-sandbox-cleanup.md b/structure/ops/test-sandbox-cleanup.md
index 1438659d308..5aeb06085c3 100644
--- a/structure/ops/test-sandbox-cleanup.md
+++ b/structure/ops/test-sandbox-cleanup.md
@@ -110,6 +110,11 @@ draining producers/reaps and restoring or removing a home. The helper does not r
 fixture-specific cleanup or claim OS ACL coverage for synthetic tests.
 The response-state stalled-runner child proves queue settlement while its synthetic runner remains held, then releases and drains that work before removing its home.
 
+The CC-Switch fixtures in `tests/providers/cc-switch-import.test.ts` close connections with
+uncached prepared statements using `Database.close(true)`. This finalizes those statements and
+releases Windows file handles before unlinking hard-link aliases or removing the fixture home;
+cleanup does not depend on garbage collection. The real-home removal guard remains in force.
+
 `tests/helpers/fixture-teardown.ts` owns management-auth, OAuth live-update, Codex quota-auto-refresh
 case roots (`tests/codex-integration/codex-quota-auto-refresh.test.ts`), and Anthropic instance
 root removal (`tests/helpers/anthropic-instance-fixture.ts`).
diff --git a/tests/ci-workflows/docs-429-failover-claims.test.ts b/tests/ci-workflows/docs-429-failover-claims.test.ts
index a45bd97c44e..2bdccf92e1e 100644
--- a/tests/ci-workflows/docs-429-failover-claims.test.ts
+++ b/tests/ci-workflows/docs-429-failover-claims.test.ts
@@ -15,7 +15,7 @@ import { describe, expect, test } from "bun:test";
 
 const CONFIG_REFERENCE = "docs-site/src/content/docs/reference/configuration/providers.md";
 const CLI_REFERENCE = "docs-site/src/content/docs/reference/cli/providers-accounts.md";
-const TRANSLATED = ["ko", "ja", "zh-cn", "zh-tw", "fr", "ru", "tr"] as const;
+const TRANSLATED = ["es", "ko", "ja", "zh-cn", "zh-tw", "fr", "ru", "tr"] as const;
 
 describe("429 failover docs", () => {
   test("the config reference states the failover is not gated and not disableable", async () => {
@@ -69,6 +69,7 @@ describe("429 failover docs", () => {
     // stale sentence would satisfy both. So each locale bans the phrase pattern that actually
     // attributed failover to the pool, which is the thing that has to stay gone.
     const bannedByLocale: Record<string, RegExp> = {
+      "es/": /a[ñn]ade[\s\S]{0,80}(?:respaldo|conmutaci[oó]n)[\s\S]{0,40}429/i,
       "": /adds sticky[\s\S]{0,80}429/i,
       "zh-tw/": /加入[\s\S]{0,40}429\s*冷卻(故障轉移|容錯移轉)/,
       "tr/": /bağlılığı ve 429[\s\S]{0,60}yük devretmesi ekler/i,
diff --git a/tests/ci-workflows/docs-bun-source-requirement.test.ts b/tests/ci-workflows/docs-bun-source-requirement.test.ts
index ff34387f8bb..33cefc7f092 100644
--- a/tests/ci-workflows/docs-bun-source-requirement.test.ts
+++ b/tests/ci-workflows/docs-bun-source-requirement.test.ts
@@ -60,4 +60,36 @@ test("contributor docs report the test and shipped Bun pins from package.json",
     const versions = /The suite uses Bun (\d+\.\d+\.\d+) \([^)]*testRunnerBun[^)]*\) while the shipped runtime is (\d+\.\d+\.\d+)\./.exec(text);
     expect(versions?.slice(1)).toEqual([pkg.testRunnerBun, pkg.dependencies.bun]);
   }
+  const spanish = await Bun.file(repoPath("docs-site/src/content/docs/es/contributing.md")).text();
+  const versions = /La suite usa Bun (\d+\.\d+\.\d+),[^\n]*entorno de ejecución distribuido es (\d+\.\d+\.\d+)\./.exec(spanish);
+  expect(versions?.slice(1)).toEqual([pkg.testRunnerBun, pkg.dependencies.bun]);
+});
+
+test("architecture transport notes identify the current bundle and historical runtime", async () => {
+  const pkg = await Bun.file(repoPath("package.json")).json();
+  for (const [path, statement] of [
+    ["reference/architecture.md", /current package bundles Bun \*\*(\d+\.\d+\.\d+)\*\*/],
+    ["es/reference/architecture.md", /paquete actual incluye Bun \*\*(\d+\.\d+\.\d+)\*\*/],
+    ["fr/reference/architecture.md", /package actuel inclut Bun \*\*(\d+\.\d+\.\d+)\*\*/],
+    ["ko/reference/architecture.md", /현재 패키지에는 Bun \*\*(\d+\.\d+\.\d+)\*\*/],
+  ] as const) {
+    const text = await Bun.file(repoPath(`docs-site/src/content/docs/${path}`)).text();
+    expect(statement.exec(text)?.[1], path).toBe(pkg.dependencies.bun);
+    expect(text, path).not.toMatch(/Bundled Bun 1\.3\.14|El Bun 1\.3\.14 incluido/);
+  }
+});
+
+test("Windows memory guidance reports the shipped runtime in every current-bundle statement", async () => {
+  const pkg = await Bun.file(repoPath("package.json")).json();
+  const cases = [
+    ["troubleshooting/windows-memory.md", /current package bundles Bun\s*\**(\d+\.\d+\.\d+)/g],
+    ["es/troubleshooting/windows-memory.md", /(?:paquete actual incluye Bun|incluye Bun)\s*\**(\d+\.\d+\.\d+)/g],
+  ] as const;
+  for (const [path, statement] of cases) {
+    const text = await Bun.file(repoPath(`docs-site/src/content/docs/${path}`)).text();
+    const versions = [...text.matchAll(statement)].map(match => match[1]);
+    expect(versions.length, `${path} intro and recovery guidance`).toBe(2);
+    expect(versions, path).toEqual([pkg.dependencies.bun, pkg.dependencies.bun]);
+    expect(text, `${path} historical investigation remains historical`).toContain("1.3.14");
+  }
 });
diff --git a/tests/ci-workflows/docs-developer-role-policy.test.ts b/tests/ci-workflows/docs-developer-role-policy.test.ts
index 0e666e37d78..fcd61e00cbf 100644
--- a/tests/ci-workflows/docs-developer-role-policy.test.ts
+++ b/tests/ci-workflows/docs-developer-role-policy.test.ts
@@ -71,7 +71,7 @@ const POLICY =
 const STRUCTURE_DOC = "structure/providers/chat-compat.md";
 const ENGLISH_REFERENCE = "docs-site/src/content/docs/reference/configuration/providers.md";
 const ENGLISH_GUIDE = "docs-site/src/content/docs/guides/claude-code.md";
-const LOCALES = ["fr", "ja", "ko", "ru", "tr", "zh-cn", "zh-tw"] as const;
+const LOCALES = ["es", "fr", "ja", "ko", "ru", "tr", "zh-cn", "zh-tw"] as const;
 
 const referencePage = (locale: string): string =>
   "docs-site/src/content/docs/" + locale + "/reference/configuration/providers.md";
diff --git a/tests/ci-workflows/docs-gjc-reasoning-export.test.ts b/tests/ci-workflows/docs-gjc-reasoning-export.test.ts
index 6391e88ee6b..5028baecfd2 100644
--- a/tests/ci-workflows/docs-gjc-reasoning-export.test.ts
+++ b/tests/ci-workflows/docs-gjc-reasoning-export.test.ts
@@ -1,7 +1,7 @@
 import { expect, test } from "bun:test";
 import { repoPath } from "../helpers/repo-root";
 
-const locales = ["", "fr/", "ja/", "ko/", "ru/", "tr/", "zh-cn/", "zh-tw/"] as const;
+const locales = ["", "es/", "fr/", "ja/", "ko/", "ru/", "tr/", "zh-cn/", "zh-tw/"] as const;
 
 test("each integration guide explains GJC reasoning export", async () => {
   for (const locale of locales) {
diff --git a/tests/ci-workflows/docs-link-targets.test.ts b/tests/ci-workflows/docs-link-targets.test.ts
index 8f6d9318472..d7f4d422329 100644
--- a/tests/ci-workflows/docs-link-targets.test.ts
+++ b/tests/ci-workflows/docs-link-targets.test.ts
@@ -135,7 +135,7 @@ describe("docs link targets", () => {
   });
 
   test("locale URLs fall back to English pages, and the old project prefix does not resolve", () => {
-    expect(LOCALES).toEqual(expect.arrayContaining(["fr", "ja", "ko", "ru", "tr", "zh-cn", "zh-tw"]));
+    expect(LOCALES).toEqual(expect.arrayContaining(["es", "fr", "ja", "ko", "ru", "tr", "zh-cn", "zh-tw"]));
     expect(resolvesOnSite(sitePathOf("https://opencodex.me/guides/macos-menu-bar/"))).toBe(true);
     expect(resolvesOnSite(sitePathOf("https://opencodex.me/ko/guides/desktop-app/"))).toBe(true);
     expect(resolvesOnSite(sitePathOf("https://opencodex.me/opencodex/guides/macos-menu-bar/"))).toBe(false);
diff --git a/tests/ci-workflows/docs-provider-discovery-limits.test.ts b/tests/ci-workflows/docs-provider-discovery-limits.test.ts
index ab160372431..969c6b9b72a 100644
--- a/tests/ci-workflows/docs-provider-discovery-limits.test.ts
+++ b/tests/ci-workflows/docs-provider-discovery-limits.test.ts
@@ -21,6 +21,7 @@ import { repoPath } from "../helpers/repo-root";
 
 /** English plus every translated guide that ships, matching docs-site/astro.config.mjs. */
 const GUIDES = [
+  { locale: "es", path: "docs-site/src/content/docs/es/guides/providers.md" },
   { locale: "en", path: "docs-site/src/content/docs/guides/providers.md" },
   { locale: "fr", path: "docs-site/src/content/docs/fr/guides/providers.md" },
   { locale: "ja", path: "docs-site/src/content/docs/ja/guides/providers.md" },
diff --git a/tests/ci-workflows/docs-provider-preset-counts.test.ts b/tests/ci-workflows/docs-provider-preset-counts.test.ts
index a849660065b..22d2fa15c9e 100644
--- a/tests/ci-workflows/docs-provider-preset-counts.test.ts
+++ b/tests/ci-workflows/docs-provider-preset-counts.test.ts
@@ -24,6 +24,7 @@ const KEY_PRESETS = PROVIDER_REGISTRY.filter(entry => entry.authKind === "key").
 
 /** Guides state the total and the key-based split on one line. */
 const GUIDES = [
+  { locale: "es", path: "docs-site/src/content/docs/es/guides/providers.md", anchor: "preajustes integrados" },
   { locale: "en", path: "docs-site/src/content/docs/guides/providers.md", anchor: "opencodex ships" },
   { locale: "ja", path: "docs-site/src/content/docs/ja/guides/providers.md", anchor: "組み込みプリセットが" },
   { locale: "ko", path: "docs-site/src/content/docs/ko/guides/providers.md", anchor: "빌트인 프리셋이" },
@@ -36,6 +37,7 @@ const GUIDES = [
 
 /** Quickstarts state the total only. */
 const QUICKSTARTS = [
+  { locale: "es", path: "docs-site/src/content/docs/es/getting-started/quickstart.md", anchor: "preajustes del registro integrado" },
   { locale: "en", path: "docs-site/src/content/docs/getting-started/quickstart.md", anchor: "built-in registry presets" },
   { locale: "ja", path: "docs-site/src/content/docs/ja/getting-started/quickstart.md", anchor: "組み込みレジストリプリセット" },
   { locale: "ko", path: "docs-site/src/content/docs/ko/getting-started/quickstart.md", anchor: "내장 레지스트리 프리셋" },
diff --git a/tests/ci-workflows/docs-remote-hub-claims.test.ts b/tests/ci-workflows/docs-remote-hub-claims.test.ts
index b4ca0e4f6ed..4b0e4b49d4d 100644
--- a/tests/ci-workflows/docs-remote-hub-claims.test.ts
+++ b/tests/ci-workflows/docs-remote-hub-claims.test.ts
@@ -31,7 +31,7 @@ import { repoPath } from "../helpers/repo-root";
 
 const GUIDE = repoPath("docs-site/src/content/docs/guides/remote-hub.md");
 const KO_GUIDE = repoPath("docs-site/src/content/docs/ko/guides/remote-hub.md");
-const TRANSLATED = ["ko", "ja", "zh-cn", "zh-tw", "fr", "ru", "tr"] as const;
+const TRANSLATED = ["es", "ko", "ja", "zh-cn", "zh-tw", "fr", "ru", "tr"] as const;
 const LOCALE_GUIDES: ReadonlyArray<readonly [string, string]> = [
   ["en", GUIDE],
   ...TRANSLATED.map(locale => [locale, repoPath(`docs-site/src/content/docs/${locale}/guides/remote-hub.md`)] as const),
@@ -75,9 +75,17 @@ describe("remote hub guide", () => {
   test("ocx connect is shown with a data origin and a separate management origin", async () => {
     // The positional URL is where /readyz and /v1/catalog are fetched; --management-url is where
     // pairing and key issuance go. They need not share a port, and the macOS recipe relies on that.
-    const source = await Bun.file(GUIDE).text();
-    expect(source).toContain("ocx connect https://hub-name.tailnet-name.ts.net:8443");
-    expect(source).toContain("--management-url https://hub-name.tailnet-name.ts.net");
+    for (const [locale, file] of LOCALE_GUIDES) {
+      const source = await Bun.file(file).text();
+      // Shell continuations belong to the same command, including its management-origin flag.
+      const examples = source.replace(/\\\r?\n[ \t]*/g, " ").split(/\r?\n/)
+        .filter(line => line.includes("ocx connect https://hub-name.tailnet-name.ts.net"));
+      expect(examples.length, locale).toBeGreaterThan(0);
+      for (const example of examples) {
+        expect(example, locale).toContain("ocx connect https://hub-name.tailnet-name.ts.net:8443");
+        expect(example, locale).toMatch(/--management-url https:\/\/hub-name\.tailnet-name\.ts\.net(?=\s|$)/);
+      }
+    }
   });
 
   test("the macOS Serve constraint and the loopback-bind trap are both documented", async () => {
@@ -89,11 +97,34 @@ describe("remote hub guide", () => {
     expect(source).toContain("X-Forwarded-Host");
   });
 
-  test("the Docker section does not contradict the standalone parent-object rule", async () => {
-    // Compose seeds a hub object, so its nested sets work. Without saying so, the two sections
-    // read as two different rules and the reader cannot tell which applies to them.
-    const source = await Bun.file(GUIDE).text();
-    expect(source).toContain("because the image seeds a first-run");
+  test("Docker initialization creates missing objects before nested updates", async () => {
+    const { validateConfigCandidate } = await import("../../src/config");
+    const seed = await Bun.file(repoPath("docker/config.json")).json();
+    for (const locale of ["", "es"]) {
+      const path = repoPath(`docs-site/src/content/docs/${locale ? locale + "/" : ""}guides/remote-hub.md`);
+      const source = await Bun.file(path).text();
+      const config = structuredClone(seed);
+      const commands = [...source.matchAll(/^docker compose run --rm hub bun run src\/cli\/index\.ts config set (\S+) '([^']+)'$/gm)];
+      expect(commands.length, path).toBeGreaterThan(0);
+      for (const command of commands) {
+        const segments = command[1]!.split(".");
+        let parent = config;
+        for (const segment of segments.slice(0, -1)) {
+          expect(parent[segment], `${locale || "en"}: missing parent before ${command[1]}`).toBeDefined();
+          parent = parent[segment];
+        }
+        parent[segments.at(-1)!] = JSON.parse(command[2]!);
+        expect(validateConfigCandidate(config).ok, command[1]).toBe(true);
+      }
+      expect(config.hub.managementIngress).toEqual({ enabled: true, port: 10101 });
+      expect(config.remoteGui.allowedTailscaleUsers).toEqual(["operator@example.com"]);
+      expect(config.providers).toEqual(seed.providers);
+      // A whole-object initializer is explicitly limited to a fresh volume.
+      const initializer = source.indexOf("docker compose run --rm hub bun run src/cli/index.ts config set hub '{");
+      const warning = source.slice(Math.max(0, initializer - 1100), initializer);
+      expect(warning, path).toMatch(/\*\*/);
+      expect(warning, path).toContain("hub.managementIngress");
+    }
   });
 
   test("the retired --allow-insecure-http flag is not offered", async () => {
diff --git a/tests/ci-workflows/docs-spanish-localization.test.ts b/tests/ci-workflows/docs-spanish-localization.test.ts
new file mode 100644
index 00000000000..2eaaf4adbbb
--- /dev/null
+++ b/tests/ci-workflows/docs-spanish-localization.test.ts
@@ -0,0 +1,545 @@
+import { describe, expect, test } from "bun:test";
+import { existsSync, readdirSync, readFileSync } from "node:fs";
+import { join, relative } from "node:path";
+import { repoPath } from "../helpers/repo-root";
+import { FRONTIER_STRINGS } from "../../docs-site/src/data/frontier-i18n";
+import { codeBlockLocale } from "../../docs-site/src/data/code-block-locale";
+
+const root = repoPath("docs-site/src/content/docs");
+const source = (path: string): string => readFileSync(path, "utf8").replace(/\r\n/g, "\n");
+const config = source(repoPath("docs-site/astro.config.mjs"));
+// Use the configured locale directories rather than freezing today's page count.
+const localeFolders = new Set([...config.matchAll(/^\s*["']?([a-z]{2}(?:-[a-z]{2})?)["']?:\s*\{\s*label:/gm)]
+  .map(match => match[1]!));
+/** List Markdown pages, excluding configured translation trees only at the canonical root. */
+function pages(directory: string, canonical = false): string[] {
+  return readdirSync(directory, { withFileTypes: true }).flatMap(entry => {
+    if (entry.isDirectory() && canonical && localeFolders.has(entry.name)) return [];
+    const path = join(directory, entry.name);
+    return entry.isDirectory() ? pages(path).map(child => `${entry.name}/${child}`)
+      : /\.mdx?$/.test(entry.name) ? [entry.name] : [];
+  }).sort();
+}
+/** Locate quoted or indented fences; a close needs the same marker and at least its opening length. */
+function fencedBlocks(markdown: string): { start: number; end: number; content: string }[] {
+  const lines = [...markdown.matchAll(/[^\n]*(?:\n|$)/g)].filter(line => line[0].length);
+  const blocks: { start: number; end: number; content: string }[] = [];
+  const unquote = (line: string): string => line.replace(/^(?:[ \t]*>[ \t]?)+/, "");
+  const quoteDepth = (line: string): number => (line.match(/^(?:[ \t]*>[ \t]?)+/)?.[0].match(/>/g) ?? []).length;
+  for (let i = 0; i < lines.length; i++) {
+    const depth = quoteDepth(lines[i]![0]);
+    const opening = /^[ \t]*(`{3,}|~{3,})([^\n]*)\n?$/.exec(unquote(lines[i]![0]));
+    if (!opening || (opening[1]![0] === "`" && opening[2]!.includes("`"))) continue;
+    const start = lines[i]!.index!;
+    const contentStart = start + lines[i]![0].length;
+    let closing = i + 1;
+    for (; closing < lines.length; closing++) {
+      if (quoteDepth(lines[closing]![0]) !== depth) continue;
+      const fence = /^[ \t]*(`+|~+)[ \t]*\n?$/.exec(unquote(lines[closing]![0]))?.[1];
+      if (fence?.[0] === opening[1]![0] && fence.length >= opening[1]!.length) break;
+    }
+    const contentEnd = lines[closing]?.index ?? markdown.length;
+    const end = closing < lines.length ? contentEnd + lines[closing]![0].length : markdown.length;
+    blocks.push({ start, end, content: markdown.slice(contentStart, contentEnd) });
+    i = closing;
+  }
+  return blocks;
+}
+/** Preserve fenced example bytes so translations cannot silently change executable commands. */
+function codeBlocks(markdown: string): string[] {
+  return fencedBlocks(markdown).map(block => block.content);
+}
+/** Remove the same detected fence ranges before checking identifiers in translated prose. */
+function withoutFencedCode(markdown: string): string {
+  let prose = "", previous = 0;
+  for (const block of fencedBlocks(markdown)) {
+    prose += markdown.slice(previous, block.start) + "\n";
+    previous = block.end;
+  }
+  return prose + markdown.slice(previous);
+}
+/** Read prose code spans, respecting escaped openers, matching backtick runs and wrapped lines. */
+function inlineCode(markdown: string): Set<string> {
+  const prose = withoutFencedCode(markdown);
+  const values = new Set<string>();
+  const escaped = (at: number): boolean => {
+    let slashes = 0;
+    for (let i = at - 1; i >= 0 && prose[i] === "\\"; i--) slashes++;
+    return slashes % 2 === 1;
+  };
+  for (let at = 0; at < prose.length; at++) {
+    if (prose[at] !== "`" || escaped(at)) continue;
+    let length = 1;
+    while (prose[at + length] === "`") length++;
+    const closing = new RegExp("(?<!`)`{" + length + "}(?!`)", "g");
+    closing.lastIndex = at + length;
+    // Backslashes are literal inside code spans, including immediately before the closing run.
+    const match = closing.exec(prose);
+    if (!match || /\n[ \t]*\n/.test(prose.slice(at + length, match.index))) { at += length - 1; continue; }
+    // Markdown code spans can cross lines; their rendered whitespace is normalized.
+    values.add(prose.slice(at + length, match.index).replace(/\s*\n\s*/g, " ").trim());
+    at = match.index + length - 1;
+  }
+  return values;
+}
+/** Read backslash-escaped code spans, which render as literal backtick-delimited text, not <code>. */
+function escapedCodeSpans(markdown: string): Set<string> {
+  const prose = withoutFencedCode(markdown);
+  const values = new Set<string>();
+  for (let at = 0; at < prose.length; at++) {
+    if (prose[at] !== "\\" || prose[at + 1] !== "`") continue;
+    const closing = prose.indexOf("\\`", at + 2);
+    if (closing < 0) break;
+    const value = prose.slice(at + 2, closing);
+    if (!/[\n]/.test(value)) values.add(value.trim());
+    at = closing + 1;
+  }
+  return values;
+}
+/** Find exact canonical code identifiers absent from the translation, across all model families. */
+function missingInlineIdentifiers(english: string, spanish: string): string[] {
+  const translated = inlineCode(spanish);
+  return [...inlineCode(english)].filter(value => !translated.has(value));
+}
+
+describe("Spanish documentation localization", () => {
+  test("code spans keep a trailing backslash literal without swallowing later identifiers", () => {
+    const english = "Paths `~\\` and `~/` keep `models` unchanged.";
+    const spanish = "Las rutas `~\\` y `~/` conservan `models`.";
+    expect([...inlineCode(english)]).toEqual(["~\\", "~/", "models"]);
+    expect(missingInlineIdentifiers(english, spanish)).toEqual([]);
+    expect(missingInlineIdentifiers(english, spanish.replace("`~\\`", "`wrong-path`"))).toEqual(["~\\"]);
+    expect(missingInlineIdentifiers(english, spanish.replace("`models`", "`other-models`"))).toEqual(["models"]);
+    expect([...inlineCode("\\`ordinary prose\\` then `models`.")]).toEqual(["models"]);
+  });
+
+  test("code-block controls use the content locale on Windows and POSIX", () => {
+    expect(codeBlockLocale({ path: "C:\\Work\\Docs Site\\src\\content\\docs\\es\\guides\\pi.md" })).toBe("es");
+    expect(codeBlockLocale({ url: new URL("file:///C:/Work/Docs%20Site/src/content/docs/es/guides/pi.md") })).toBe("es");
+    expect(codeBlockLocale({ path: "/workspace/docs-site/src/content/docs/zh-cn/guides/pi.md" })).toBe("zh-CN");
+    expect(codeBlockLocale({ url: new URL("https://opencodex.me/es/guides/pi/") })).toBe("es");
+    expect(codeBlockLocale({ path: "/workspace/docs-site/src/content/docs/guides/pi.md" })).toBe("en");
+    expect(codeBlockLocale({})).toBe("en");
+    expect(config).toContain("getBlockLocale");
+  });
+
+  test("compares list-indented command fences and excludes them from inline prose", () => {
+    for (const [indent, fence] of [["", "```"], ["  ", "```"], ["   ", "~~~"], ["\t", "````"]]) {
+      const canonical = ["1. Run `droid exec`:", "", `${indent}${fence}bash`,
+        `${indent}droid exec --model glm-5.2 'Reply with DROID_OK only.'`,
+        `${indent}printf '\`fenced-code-only\`'`, `${indent}${fence}`, ""].join("\n");
+      expect(codeBlocks(canonical)).toHaveLength(1);
+      expect(codeBlocks(canonical.replace("glm-5.2", "wrong-model"))).not.toEqual(codeBlocks(canonical));
+      expect([...inlineCode(canonical)]).toEqual(["droid exec"]);
+    }
+  });
+
+  test("longer closing fences cannot hide changed commands or leak code into prose", () => {
+    for (const indent of ["", "  ", "   ", "\t"]) {
+      for (const marker of ["`", "~"]) {
+        const markdown = ["Run `ocx export`:", "", `${indent}${marker.repeat(3)}bash`,
+          `${indent}ocx export --client pi`, `${indent}echo '\`code-only\`'`,
+          `${indent}${marker.repeat(4)}`, "", "Then use `models.json`."].join("\n");
+        expect(codeBlocks(markdown)).toHaveLength(1);
+        expect(codeBlocks(markdown.replace("--client pi", "--client wrong"))).not.toEqual(codeBlocks(markdown));
+        expect([...inlineCode(markdown)]).toEqual(["ocx export", "models.json"]);
+        expect(withoutFencedCode(markdown)).not.toContain("code-only");
+      }
+    }
+  });
+
+  test("shorter or mixed fences stay inside the block and an unclosed block reaches EOF", () => {
+    for (const marker of ["`", "~"]) {
+      const other = marker === "`" ? "~" : "`";
+      const body = ["ocx start", marker.repeat(3), other.repeat(5), "echo '`code-only`'", ""].join("\n");
+      const opening = marker.repeat(4) + "bash\n";
+      expect(codeBlocks(opening + body + marker.repeat(4) + "\n")).toEqual([body]);
+      expect(codeBlocks(opening + body)).toEqual([body]);
+      expect([...inlineCode(opening + body)]).toEqual([]);
+    }
+    expect(codeBlocks("```not `an opening`\nordinary prose\n")).toEqual([]);
+  });
+
+  test("checks commands inside quoted examples and removes them from prose", () => {
+    const markdown = ["Read `config.json`:", "", "> ```bash", "> ocx start", "> echo '`quoted-code`'", "> ````", ""].join("\n");
+    expect(codeBlocks(markdown)).toEqual(["> ocx start\n> echo '`quoted-code`'\n"]);
+    expect(codeBlocks(markdown.replace("ocx start", "ocx wrong"))).not.toEqual(codeBlocks(markdown));
+    expect([...inlineCode(markdown)]).toEqual(["config.json"]);
+  });
+
+  test("closing fences must match the opening quote context", () => {
+    for (const quote of ["", "> ", "> > "]) {
+      for (const marker of ["`", "~"]) {
+        const fence = marker.repeat(3);
+        const body = [`${quote}> ${fence}`, `${quote}ocx start`, `${quote}echo '\`code-only\`'`, ""].join("\n");
+        const markdown = [`Read \`config.json\`:`, "", `${quote}${fence}text`, body + `${quote}${fence}`,
+          "", "Then use `models.json`."].join("\n");
+        expect(codeBlocks(markdown)).toEqual([body]);
+        expect(codeBlocks(markdown.replace("ocx start", "ocx wrong"))).not.toEqual(codeBlocks(markdown));
+        expect([...inlineCode(markdown)]).toEqual(["config.json", "models.json"]);
+        expect(withoutFencedCode(markdown)).not.toContain("code-only");
+      }
+    }
+  });
+
+  test("registers Spanish and covers every current canonical documentation path", () => {
+    expect(localeFolders.has("es")).toBe(true);
+    expect(config).toMatch(/es:\s*\{\s*label:\s*["']Español["'],\s*lang:\s*["']es["']/);
+    const english = pages(root, true);
+    expect(english.length).toBeGreaterThan(50);
+    expect(pages(join(root, "es"))).toEqual(english);
+  });
+
+  test("foreground proxy recipes separate subsequent terminal commands in every locale", () => {
+    let checked = 0;
+    for (const [guide, start, next] of [
+      ["guides/remote-workspace.md", "OCX_REMOTE_WORKSPACE_ENABLED=1 ocx start", "ocx gui"],
+      ["guides/web-dashboard.md", "ocx start\n", "bun run dev:gui"],
+      ["guides/minimax.md", "ocx start\n", "ocx integration client enable --client mcode\nocx mcode"],
+    ] as const) {
+      for (const locale of ["", ...localeFolders]) {
+        const path = join(root, locale, guide);
+        if (!existsSync(path)) continue;
+        const blocks = codeBlocks(source(path));
+        const foreground = blocks.find(block => block.includes(start));
+        expect(foreground, path).toBeDefined();
+        expect(foreground, `${path} foreground start blocks later shell commands`).not.toContain(next);
+        expect(blocks, `${path} next command runs in a separate terminal block`).toContain(next + "\n");
+        checked++;
+      }
+    }
+    expect(checked).toBeGreaterThan(1);
+  });
+
+  test("quickstart presents foreground start commands as separate alternatives in every locale", () => {
+    for (const locale of ["", ...localeFolders]) {
+      const path = join(root, locale, "getting-started/quickstart.md");
+      const blocks = codeBlocks(source(path));
+      const defaultStart = blocks.find(block => /^ocx start[ \t]+#/m.test(block));
+      expect(defaultStart, path).toBeDefined();
+      expect(defaultStart, path).not.toContain("ocx start --port 8080");
+      expect(defaultStart, path).not.toContain("ocx status");
+      expect(defaultStart, path).not.toContain("ocx gui");
+      expect(blocks, path).toContain("ocx start --port 8080\n");
+      const portRecovery = source(path).split(/\n\s*\n/)
+        .find(block => block.includes("`ocx start --port <port>`"));
+      expect(portRecovery, `${path} same-home recovery`).toContain("OPENCODEX_HOME");
+      expect(portRecovery, `${path} stop owning instance first`).toContain("`ocx stop`");
+    }
+  });
+
+  test("agent setup runs init before binding a listener and uses the configured combo provider", () => {
+    for (const locale of ["", ...localeFolders]) {
+      const path = join(root, locale, "getting-started/for-agents.md");
+      const commands = codeBlocks(source(path)).join("\n");
+      const init = commands.search(/^ocx init\s*$/m);
+      const start = commands.search(/^ocx (?:start|service)\s*$/m);
+      expect(init, `${path} interactive setup`).toBeGreaterThanOrEqual(0);
+      expect(start, `${path} setup before listener bind`).toBeGreaterThan(init);
+      expect(commands, path).toMatch(/ocx provider add anthropic-apikey\b/);
+      expect(commands, path).toContain("anthropic-apikey/claude-opus-4-8");
+      expect(commands, path).not.toContain("anthropic/claude-opus-4-8");
+    }
+  });
+
+  test("edit links target the current development branch", () => {
+    expect(config).toContain('baseUrl: "https://github.com/lidge-jun/opencodex/edit/dev/docs-site/"');
+    expect(config).not.toContain("/edit/main/");
+  });
+
+  test("escaped code spans stay escaped wherever the canonical page escapes them", () => {
+    // An escaped span renders literal backticks, so a translation that emits a real <code> span changes the page.
+    const markdown = ["Escaped \\`openai-model\\` and real `models.json`.", "",
+      "```sh", "printf '\\`fenced\\`'", "```", ""].join("\n");
+    expect([...escapedCodeSpans(markdown)]).toEqual(["openai-model"]);
+    expect([...inlineCode(markdown)]).toEqual(["models.json"]);
+    expect([...escapedCodeSpans("plain `models.json` only")]).toEqual([]);
+    let escapedPages = 0;
+    for (const path of pages(root, true)) {
+      const spanish = source(join(root, "es", path));
+      const canonical = escapedCodeSpans(source(join(root, path)));
+      if (canonical.size === 0) continue;
+      escapedPages++;
+      const translated = escapedCodeSpans(spanish);
+      expect([...canonical].filter(value => !translated.has(value)), `${path} escaped code spans`).toEqual([]);
+      expect([...canonical].filter(value => inlineCode(spanish).has(value)), `${path} escaped code became a code span`)
+        .toEqual([]);
+    }
+    expect(escapedPages).toBeGreaterThan(0);
+  });
+
+  test("keeps executable examples and frontmatter in the current English shape", () => {
+    for (const path of pages(root, true)) {
+      const english = source(join(root, path));
+      const spanish = source(join(root, "es", path));
+      expect(spanish, path).toMatch(/^---\ntitle:\s*\S/);
+      expect(spanish, path).toMatch(/\ndescription:\s*\S/);
+      expect(codeBlocks(spanish), `${path} code examples`).toEqual(codeBlocks(english));
+      // Exact code spans cover every model family and namespace without a family allowlist.
+      expect(missingInlineIdentifiers(english, spanish), `${path} inline and model identifiers`).toEqual([]);
+      const htmlCode = (text: string): string[] => [...text.matchAll(/<code\b[^>]*>([\s\S]*?)<\/code>/g)].map(match => match[1]!);
+      expect(htmlCode(spanish), `${path} HTML code`).toEqual(htmlCode(english));
+      const directives = (text: string): string[] => [...text.matchAll(/^:::(\w*)/gm)].map(match => match[1]!);
+      expect(directives(spanish), `${path} admonition structure`).toEqual(directives(english));
+      const prose = withoutFencedCode;
+      const tables = (text: string): number => [...prose(text).matchAll(/^\s*\|?\s*:?-{3,}:?\s*\|\s*:?-{3,}:?/gm)].length;
+      const items = (text: string): number => [...prose(text).matchAll(/^\s*(?:[-*]|[1-9]\d*\.)\s+/gm)].length;
+      expect(tables(spanish), `${path} complete tables`).toBe(tables(english));
+      const tableShapes = (text: string): number[][] => prose(text).split(/\n\s*\n/)
+        .filter(block => /^\s*\|?\s*:?-{3,}:?\s*\|\s*:?-{3,}:?/m.test(block))
+        .map(block => block.split("\n").filter(line => line.trimStart().startsWith("|"))
+          .map(line => [...line.matchAll(/(?<!\\)\|/g)].length));
+      expect(tableShapes(spanish), `${path} table rows and columns`).toEqual(tableShapes(english));
+      expect(items(spanish), `${path} complete instruction lists`).toBeGreaterThanOrEqual(items(english));
+      expect(spanish, path).not.toMatch(/ZXQ\d|QXZ|\u2047|\uFFFD/);
+      expect(spanish, path).not.toMatch(/locale=["']en["']/);
+      expect(relative(root, join(root, "es", path)).replaceAll("\\", "/")).toBe(`es/${path}`);
+    }
+  });
+
+  test("provider quickstarts pass environment references without shell expansion", () => {
+    for (const locale of ["", ...localeFolders]) {
+      const examples = codeBlocks(source(join(root, locale, "getting-started/for-agents.md"))).join("\n");
+      expect(examples, `${locale || "en"} provider CLI reference`).toContain("--api-key '${ANTHROPIC_API_KEY}'");
+    }
+    for (const locale of ["", "es"]) {
+      const examples = codeBlocks(source(join(root, locale, "guides/combos.md"))).join("\n");
+      expect(examples, `${locale || "en"} JEV CLI reference`).toContain("--api-key '${TYPESAFE_API_KEY}'");
+    }
+  });
+
+  test("remote credential examples require a protected transport in every locale", () => {
+    for (const locale of ["", ...localeFolders]) {
+      const opencode = codeBlocks(source(join(root, locale, "guides/opencode.md")))
+        .find(block => block.includes('"x-opencodex-api-key"'));
+      expect(opencode, `${locale || "en"} OpenCode example`).toBeDefined();
+      const options = JSON.parse(`{${opencode}}`).options;
+      expect(new URL(options.baseURL).protocol, `${locale || "en"} OpenCode transport`).toBe("https:");
+      expect(options.headers["x-opencodex-api-key"]).toBe("{env:OPENCODEX_OPENCODE_API_KEY}");
+      const grok = codeBlocks(source(join(root, locale, "guides/grok-build.md")))
+        .find(block => block.includes("[model_providers.opencodex]")
+          && /api_key = "(?!opencodex-loopback")[^"]+"/.test(block));
+      expect(grok, `${locale || "en"} Grok remote example`).toBeDefined();
+      expect(grok, `${locale || "en"} Grok transport`).toMatch(/base_url = "https:\/\//);
+    }
+  });
+
+  test("Video Bridge key-auth examples parse and reference the environment in every locale", () => {
+    for (const locale of ["", ...localeFolders]) {
+      const path = join(root, locale, "guides/video-bridge.md");
+      if (!existsSync(path)) continue;
+      const block = codeBlocks(source(path)).find(text => text.includes('"xai"'));
+      expect(block, path).toBeDefined();
+      const config = JSON.parse(block!.replace(/^[ \t]*>[ \t]?/gm, ""));
+      expect(config.providers.xai, path).toMatchObject({ apiKey: "${XAI_API_KEY}", authMode: "key" });
+      expect(source(path).match(/`authMode: "key"`/g)?.length ?? 0, path).toBeGreaterThan(0);
+    }
+  });
+
+  test("Executor pairing examples read secrets silently and clear variables in every locale", () => {
+    for (const locale of ["", ...localeFolders]) {
+      const path = join(root, locale, "guides/remote-workspace.md");
+      if (!existsSync(path)) continue;
+      const blocks = codeBlocks(source(path)).filter(text => text.includes("ocx remote-workspace pair"));
+      expect(blocks.length, path).toBeGreaterThan(0);
+      for (const block of blocks) {
+        expect(block, path).not.toContain("ONE-TIME-CODE");
+        expect(block, path).toMatch(/read -r -s|Read-Host [^\n]+-AsSecureString/);
+        expect(block, path).toContain("--pairing-code-stdin");
+        expect(block, path).toMatch(/unset pairing_code|Remove-Variable pairingCode/);
+        if (block.includes("read -r -s -p")) {
+          expect(block, `${path} requires an actual Bash session`).toContain("# Bash only: if using zsh, run bash first in this terminal.");
+        }
+      }
+    }
+  });
+
+  test("Hub pairing recipes provide stdin authority before connecting in every locale", () => {
+    for (const locale of ["", ...localeFolders]) {
+      const path = join(root, locale, "guides/remote-hub.md");
+      const examples = codeBlocks(source(path)).filter(block => block.includes("ocx connect")
+        && /--(?:pairing-code|admin-token)-stdin/.test(block));
+      expect(examples.length, path).toBeGreaterThan(0);
+      for (const block of examples) {
+        expect(block, path).toContain("read -r -s");
+        expect(block, path).toMatch(/printf '%s\\n' "\$[a-z_]+" \| ocx connect/);
+        expect(block, path).toMatch(/unset (?:pairing_code|admin_token)/);
+      }
+    }
+  });
+
+  test("Pi and agent quickstarts retain current reasoning and separate credential planes", () => {
+    for (const locale of ["", ...localeFolders]) {
+      const pi = source(join(root, locale, "guides/pi.md"));
+      for (const identifier of ['"reasoning": true', "thinkingLevelMap", "noReasoningModels"]) {
+        expect(pi, `${locale || "en"} Pi reasoning metadata`).toContain(identifier);
+      }
+      const agents = source(join(root, locale, "getting-started/for-agents.md"));
+      for (const identifier of ["config.apiKeys", "OCX_API_TOKEN_FILE", "service-api-token", "OPENCODEX_ADMIN_AUTH_TOKEN"]) {
+        expect(agents, `${locale || "en"} agent credential planes`).toContain(identifier);
+      }
+      const server = source(join(root, locale, "reference/configuration/server.md"));
+      for (const identifier of ["config.apiKeys", "OCX_API_TOKEN_FILE", "service-api-token", "OPENCODEX_ADMIN_AUTH_TOKEN"]) {
+        expect(server, `${locale || "en"} remote-access credential planes`).toContain(identifier);
+      }
+    }
+  });
+
+  test("Responses admission treats empty dedicated headers as absent and rejects nonempty invalid credentials", async () => {
+    const { resolveResponsesApiAuth } = await import("../../src/server/auth-cors");
+    const config = { hostname: "0.0.0.0", providers: {}, port: 10100,
+      apiKeys: [{ id: "docs-key", name: "docs", key: "docs-secret", createdAt: "2026-11-04T00:00:00Z" }],
+    } as Parameters<typeof resolveResponsesApiAuth>[1];
+    const resolve = (dedicated: string) => resolveResponsesApiAuth(new Request("https://proxy.test/v1/responses", {
+      headers: { authorization: "Bearer docs-secret", "x-opencodex-api-key": dedicated },
+    }), config);
+    for (const empty of ["", " ", "\t  "]) {
+      expect(resolve(empty)).toMatchObject({ kind: "configured", keyId: "docs-key", source: "bearer" });
+    }
+    expect(resolve(" invalid-secret ")).toBeNull();
+    expect(resolve(" docs-secret ")).toMatchObject({ kind: "configured", keyId: "docs-key", source: "dedicated" });
+  });
+
+  test("Responses admission tables match the implemented header matrix in every locale", async () => {
+    const { AUTH_MATRIX } = await import("../../src/server/auth-cors");
+    const accepted = new Set(["accepted", "aceptado", "accepté", "허용", "허용됨", "受け入れられる", "受け入れ", "принимается", "kabul edilir", "接受"]);
+    const rejected = new Set(["not accepted", "no aceptado", "non accepté", "허용되지 않음", "受け入れられません", "не принимается", "kabul edilmez", "不接受"]);
+    for (const locale of ["", ...localeFolders]) {
+      const text = source(join(root, locale, "reference/configuration/server.md"));
+      for (const endpoint of ["/v1/responses", "/v1/chat/completions"]) {
+        const row = text.split("\n").find(line => line.startsWith(`| \`${endpoint}\` |`));
+        expect(row, `${locale || "en"} ${endpoint}`).toBeDefined();
+        const cells = row!.split("|").slice(2, -1).map(cell => cell.replace(/\*/g, "").trim());
+        expect(cells.every(cell => accepted.has(cell) || rejected.has(cell)), `${locale || "en"} recognized admission labels`).toBe(true);
+        const actual = AUTH_MATRIX.find(item => item.endpoint === endpoint)!;
+        expect(cells.map(cell => accepted.has(cell)), `${locale || "en"} ${endpoint}`)
+          .toEqual([actual.bearer, actual.dedicated, actual.xApiKey].map(value => value === "accepted"));
+      }
+    }
+  });
+
+  test("model identifier parity rejects extended tokens across families and namespaces", () => {
+    const identifiers = ["gpt-6-astra", "whisper-1", "claude-opus-5", "o1-mini", "o3-mini", "o4-mini",
+      "codex-mini-latest", "qwen/qwen3-coder-plus", "tev1:4b"];
+    const canonical = identifiers.map(id => `\`${id}\``).join(", ");
+    expect(missingInlineIdentifiers(canonical, canonical)).toEqual([]);
+    for (const id of identifiers) {
+      const extended = canonical.replace(`\`${id}\``, `\`${id}-translated\``);
+      expect(missingInlineIdentifiers(canonical, extended)).toEqual([id]);
+    }
+  });
+
+  test("keeps literal model names intact in surrounding prose", () => {
+    for (const path of pages(root, true)) {
+      const english = source(join(root, path));
+      const spanish = source(join(root, "es", path));
+      const identifiers = [...inlineCode(english)].filter(value =>
+        /^(?:[a-z0-9._-]+\/)*[a-z][a-z0-9._-]*-[a-z0-9._-]+$/i.test(value) && /\d/.test(value));
+      for (const identifier of identifiers) {
+        const escaped = identifier.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");
+        const token = new RegExp(`(?<![\\w./*-])${escaped}(?![\\w./*-])`, "g");
+        expect(spanish.match(token)?.length ?? 0, `${path} model ${identifier}`)
+          .toBeGreaterThanOrEqual(english.match(token)?.length ?? 0);
+      }
+    }
+  });
+
+  test("keeps client product names recognizable in the integration table and metadata", () => {
+    const english = source(join(root, "guides/integrations.md"));
+    const spanish = source(join(root, "es/guides/integrations.md"));
+    const clientNames = (text: string): string[] => {
+      const table = text.split(/\n\s*\n/).find(block => /^\|[^\n]+\n\|[-:| \t]+\|/.test(block));
+      return table?.split("\n").slice(2).map(row => row.split("|")[1]?.trim() ?? "").filter(Boolean) ?? [];
+    };
+    const names = clientNames(english);
+    expect(names.length).toBeGreaterThan(10);
+    expect(clientNames(spanish)).toEqual(names);
+    const metadata = (text: string): string => text.match(/^---\n[\s\S]*?\n---/)?.[0] ?? "";
+    for (const name of names.filter(name => metadata(english).includes(name))) {
+      expect(metadata(spanish), `client product name ${name}`).toContain(name);
+    }
+  });
+
+  test("preserves external links, references and API response status codes", () => {
+    const targets = (text: string): string[] => [...text.matchAll(/\]\((https?:\/\/[^\s)]+)\)/g)]
+      .map(match => match[1]!.replace(/^(https:\/\/opencodex\.me)\/es\//, "$1/")).sort();
+    for (const path of pages(root, true)) {
+      const english = source(join(root, path));
+      const spanish = source(join(root, "es", path));
+      expect(targets(spanish), `${path} external links`).toEqual(targets(english));
+      const references = spanish.match(/#\d+\b/g) ?? [];
+      for (const reference of english.match(/#\d+\b/g) ?? []) {
+        const index = references.indexOf(reference);
+        expect(index, `${path} reference ${reference}`).toBeGreaterThanOrEqual(0);
+        if (index >= 0) references.splice(index, 1);
+      }
+      const apiRows = (text: string): string[][] => text.split("\n")
+        .filter(line => /^\|\s*`(?:GET|POST|PUT|PATCH|DELETE)\b/.test(line))
+        .map(line => line.split(/(?<!\\)\|/).slice(1, -1).map(cell => cell.trim()));
+      const rowKey = (row: string[]): string => [...inlineCode(row[0] ?? "")].join("\u0000");
+      const translatedRows = new Map<string, string[][]>();
+      for (const row of apiRows(spanish)) {
+        const key = rowKey(row);
+        translatedRows.set(key, [...translatedRows.get(key) ?? [], row]);
+      }
+      for (const row of apiRows(english)) {
+        const translated = translatedRows.get(rowKey(row))?.shift();
+        expect(translated, `${path} API row ${row[0]}`).toBeDefined();
+        for (const status of row.at(-1)?.match(/\b[1-5]\d{2}\b/g) ?? []) {
+          expect(translated?.at(-1), `${path} ${row[0]} status ${status}`).toMatch(new RegExp(`\\b${status}\\b`));
+        }
+      }
+    }
+  });
+
+  test("landing, language navigation, metadata and benchmark copy include Spanish", () => {
+    for (const file of ["Landing.astro", "Header.astro", "SiteJsonLd.astro"]) {
+      const text = source(repoPath(`docs-site/src/components/${file}`));
+      expect(text, file).toContain("'es'");
+    }
+    expect(source(join(root, "es/index.mdx"))).toContain('<Landing locale="es" />');
+    expect(source(repoPath("docs-site/src/components/Header.astro"))).toContain("Español");
+    expect(source(repoPath("docs-site/src/data/frontier-i18n.ts"))).toMatch(/\bes:\s*\{/);
+    const landing = source(repoPath("docs-site/src/components/Landing.astro"));
+    const decodeKey = (key: string): string => key.replace(/\\(['"\\])/g, "$1");
+    const keys = (block: string): string[] => [...block.matchAll(/^\s*(?:"((?:\\.|[^"\\])*)"|'((?:\\.|[^'\\])*)')\s*:/gm)]
+      .map(match => decodeKey(match[1] ?? match[2] ?? "")).sort();
+    const french = keys(landing.match(/const fr = \{([\s\S]*?)^\}(?: as const)?;/m)?.[1] ?? "");
+    const spanish = keys(landing.match(/const es:[^=]+ = \{([\s\S]*?)^\};/m)?.[1] ?? "");
+    expect(french.length).toBeGreaterThan(0);
+    expect(spanish).toEqual(french);
+    for (const call of landing.matchAll(/\bt\((?:"((?:\\.|[^"\\])*)"|'((?:\\.|[^'\\])*)')/g)) {
+      expect(french, "visible or accessible landing copy").toContain(decodeKey(call[1] ?? call[2] ?? ""));
+    }
+  });
+
+  test("every translated Pi quickstart keeps the non-secret loopback export contract", () => {
+    for (const locale of localeFolders) {
+      const text = source(join(root, locale, "guides/pi.md"));
+      const examples = codeBlocks(text);
+      const provider = examples.find(block => block.includes('"providers"'));
+      expect(provider, `${locale} Pi provider example`).toBeDefined();
+      expect(JSON.parse(provider!).providers.opencodex.apiKey, `${locale} Pi apiKey`).toBe("opencodex-loopback");
+      expect(examples.join("\n"), `${locale} Pi export commands`).not.toContain("export OPENCODEX_API_KEY");
+    }
+  });
+
+  test("benchmark names and placeholders retain their canonical meaning", () => {
+    const english = FRONTIER_STRINGS.en;
+    const spanish = FRONTIER_STRINGS.es;
+    expect(Object.keys(spanish).sort()).toEqual(Object.keys(english).sort());
+    for (const key of Object.keys(english) as (keyof typeof english)[]) {
+      expect(spanish[key].trim(), key).not.toBe("");
+      expect(spanish[key].match(/\{\w+\}/g) ?? [], key).toEqual(english[key].match(/\{\w+\}/g) ?? []);
+      if (key.endsWith(".title")) expect(spanish[key], key).toBe(english[key]);
+    }
+  });
+
+  test("documents the current archive limits and recoverable refusal codes", () => {
+    const spanish = source(join(root, "es/reference/configuration/server.md"));
+    expect(spanish).toContain('<a id="native-reasoning-retention"></a>');
+    for (const value of ["512 MiB", "256", "reasoning_archive_quota_exceeded", "reasoning_archive_busy", "reasoning_archive_unavailable"]) {
+      expect(spanish).toContain(value);
+    }
+  });
+});
diff --git a/tests/ci-workflows/docs-telemetry-dashboard.test.ts b/tests/ci-workflows/docs-telemetry-dashboard.test.ts
index 88974ef6d1a..067441428e3 100644
--- a/tests/ci-workflows/docs-telemetry-dashboard.test.ts
+++ b/tests/ci-workflows/docs-telemetry-dashboard.test.ts
@@ -735,17 +735,11 @@ describe("telemetry dashboard formatting and bucketing helpers", () => {
     expect(parseGithubNextLink(null)).toBeNull();
   });
 
-  test("all 8 site locales carry complete dashboard copy and component markup contains no secrets", () => {
-    expect(TELEMETRY_DASHBOARD_LOCALES).toEqual([
-      "en",
-      "fr",
-      "ko",
-      "zh-cn",
-      "zh-tw",
-      "ru",
-      "ja",
-      "tr",
-    ]);
+  test("all configured site locales carry complete dashboard copy and component markup contains no secrets", () => {
+    const configured = ["en", ...readFileSync(repoPath("docs-site/astro.config.mjs"), "utf8")
+      .matchAll(/^\s*["']?([a-z]{2}(?:-[a-z]{2})?)["']?:\s*\{\s*label:/gm)]
+      .map(value => typeof value === "string" ? value : value[1]!);
+    expect([...TELEMETRY_DASHBOARD_LOCALES].sort()).toEqual(configured.sort());
     const enKeys = Object.keys(TELEMETRY_DASHBOARD_STRINGS.en).sort();
     const optInPattern = /\bopt(?:ed)?[-\s]?in\b|オプトイン|참여에\s*동의한/i;
     const hangulPattern = /[\uac00-\ud7af\u1100-\u11ff\u3130-\u318f]/;
diff --git a/tests/ci-workflows/docs-telemetry-leaderboard.test.ts b/tests/ci-workflows/docs-telemetry-leaderboard.test.ts
index 4f03b92a0ba..6635be88c5c 100644
--- a/tests/ci-workflows/docs-telemetry-leaderboard.test.ts
+++ b/tests/ci-workflows/docs-telemetry-leaderboard.test.ts
@@ -49,7 +49,10 @@ describe("docs-site leaderboard", () => {
   });
 
   test("every site locale carries complete leaderboard copy", () => {
-    expect(TELEMETRY_LEADERBOARD_LOCALES).toEqual(["en", "fr", "ko", "zh-cn", "zh-tw", "ru", "ja", "tr"]);
+    const configured = ["en", ...readFileSync(repoPath("docs-site/astro.config.mjs"), "utf8")
+      .matchAll(/^\s*["']?([a-z]{2}(?:-[a-z]{2})?)["']?:\s*\{\s*label:/gm)]
+      .map(value => typeof value === "string" ? value : value[1]!);
+    expect([...TELEMETRY_LEADERBOARD_LOCALES].sort()).toEqual(configured.sort());
     const keys = Object.keys(TELEMETRY_LEADERBOARD_STRINGS.en).sort();
     const hangul = /[\uac00-\ud7af]/;
     for (const locale of TELEMETRY_LEADERBOARD_LOCALES) {
@@ -148,4 +151,3 @@ describe("docs-site leaderboard", () => {
     expect(mdx.indexOf("<TelemetryDashboard />")).toBeLessThan(mdx.indexOf("<TelemetryLeaderboard />"));
   });
 });
-
diff --git a/tests/cli/cli-role-suggestion-history.test.ts b/tests/cli/cli-role-suggestion-history.test.ts
index 10e76e8153a..46668ce4b00 100644
--- a/tests/cli/cli-role-suggestion-history.test.ts
+++ b/tests/cli/cli-role-suggestion-history.test.ts
@@ -8,7 +8,7 @@ import type { RoleModelChange } from "../../src/codex/role-model-history";
 import { handleManagementAPI } from "../../src/server/management-api";
 import type { OcxConfig } from "../../src/types";
 import { ManagementRequest } from "../helpers/management-auth";
-import { STORE_BUDGET_MS } from "../helpers/test-budget";
+import { BULK_DURABLE_IO_BUDGET_MS, STORE_BUDGET_MS } from "../helpers/test-budget";
 import { removeTreeWithRetry } from "../helpers/remove-tree";
 
 const saved = { CODEX_HOME: process.env.CODEX_HOME, OPENCODEX_HOME: process.env.OPENCODEX_HOME,
@@ -134,6 +134,8 @@ async function restoreBatch(changes: RoleModelChange[]): Promise<string> {
 }
 
 describe("CLI role suggestions preserve bounded whole-batch history", () => {
+  // Fifty applies and fifty restores each durably rewrite role config and history.
+  // That I/O is the assertion, so use the existing bounded bulk-write budget.
   test("50 real writes share one listed batch and every role restores after the source leaves the listing", async () => {
     const proposals = seed(50);
     const mirrorBefore = JSON.parse(readFileSync(mirrorPath, "utf8"));
@@ -157,7 +159,7 @@ describe("CLI role suggestions preserve bounded whole-batch history", () => {
     const latest = await listedHistory();
     expect(latest).toHaveLength(50);
     expect(new Set(latest.map(c => c.batch))).toEqual(new Set([restored]));
-  }, { timeout: STORE_BUDGET_MS });
+  }, { timeout: BULK_DURABLE_IO_BUDGET_MS });
 
   test.each([false, true])("51 changed roles are refused before any PUT or file change (json=%s)", async json => {
     const proposals = seed(51);
diff --git a/tests/fixtures/test-layout-expected.json b/tests/fixtures/test-layout-expected.json
index 2c0c5bcc8dc..8e03cbbc019 100644
--- a/tests/fixtures/test-layout-expected.json
+++ b/tests/fixtures/test-layout-expected.json
@@ -872,6 +872,7 @@
   "docs-gjc-reasoning-export.test.ts": "ci-workflows", "docs-provider-billing-claims.test.ts": "ci-workflows",
   "docs-provider-discovery-limits.test.ts": "ci-workflows", "docs-provider-preset-counts.test.ts": "ci-workflows",
   "docs-readme-memory-inventory.test.ts": "ci-workflows", "docs-readme-translation-parity.test.ts": "ci-workflows",
+  "docs-spanish-localization.test.ts": "ci-workflows",
   "docs-remote-hub-claims.test.ts": "ci-workflows", "doctor-codex-envkey-readiness.test.ts": "service",
   "doctor-bun-install.test.ts": "service",
   "doctor-oauth.test.ts": "service", "doctor-provider-apikey.test.ts": "service",
diff --git a/tests/providers/cc-switch-import.test.ts b/tests/providers/cc-switch-import.test.ts
index d152fcee1ef..64f83b76c37 100644
--- a/tests/providers/cc-switch-import.test.ts
+++ b/tests/providers/cc-switch-import.test.ts
@@ -888,7 +888,8 @@ describe("CC-Switch keyless provider import", () => {
         );
       }
     } finally {
-      db.close();
+      // Uncached prepare() statements otherwise defer releasing the Windows file handle.
+      db.close(true);
     }
 
     // Compact JSON placing WORD_CANARY inside bytes 0..15 of the file header AND in secret fields,
@@ -1094,11 +1095,11 @@ describe("CC-Switch keyless provider import", () => {
         expect(cliJsonOut.join("\n")).not.toContain(aliasDbPath);
         expect(JSON.parse(cliJsonOut[0]!)).toMatchObject({ error: "sqlite_hardlink_refused" });
       } finally {
-        writer.close();
+        writer.close(true);
         unlinkSync(aliasDbPath);
       }
     } finally {
-      try { writer.close(); } catch { /* already closed */ }
+      writer.close(true);
     }
 
     // Reopen and checkpoint cleanly (simulating CC-Switch closing/checkpointing); retry now succeeds with updated data.