{"slug": "i-cut-80-of-context-overhead-in-my-coding-agent", "title": "I Cut 80%+ of Context Overhead in My Coding Agent", "summary": "A developer reports cutting 80%+ of context overhead in AI coding agents by consolidating tools and dynamically activating them, benchmarking that OpenAI's Codex loads 79 tools and consumes 14,534 tokens on a fresh session with a single \"hi\" message. The approach, implemented in the agent harness Pi, keeps only 4 baseline tools active and places others on standby with TTL cleanup, reducing token waste and improving reasoning.", "body_md": "# How I Cut 80%+ of Context Overhead in My Coding Agent\n\nWhen you start a session in a modern AI coding agent, a huge chunk of your context window is consumed before you type your first message.\n\nBetween system instructions, formatting rules, MCP server integrations, and dozens of registered tool schemas, most agent harnesses dump 10,000 to 25,000+ tokens of static overhead into the context window on every turn.\n\nOn 90% of turns, an agent only needs basic file and shell tools (`read`\n\n, `bash`\n\n, `edit`\n\n, `write`\n\n). Specialized tools like browser automation, image generation, web search, or background task runners are needed occasionally, sometimes only once a week.\n\nLeaving 25 to 80+ tool definitions active in the LLM function schema 100% of the time wastes tokens, increases latency, and degrades model reasoning by polluting the attention space with irrelevant parameters.\n\nI solved this with two design decisions:\n\n**Action-based tool consolidation.** Structuring custom tools from day one to avoid CRUD schema duplication.**Dynamic tool activation in Pi.** Keeping a baseline of 4 tools active, placing everything else on standby, and letting the model or the user activate tools on demand with zero meta-tool schema overhead and automatic TTL cleanup.\n\n## Benchmarking turn zero context across agent harnesses\n\nTo measure the scale of the problem, I tested how different coding agent harnesses handle tool schemas and context on a fresh session by sending a single greeting: `\"hi\"`\n\n.\n\n### 1. Codex: 79 tools and 14.5k tokens by default\n\nI turned off every external plugin and MCP server in Codex, leaving only two custom skills alongside the default built-in setup. Then, I started a fresh session and sent `\"hi\"`\n\n.\n\nThe model answered with a standard one-line greeting (\"Hi! How can I help?\"). The thread status showed that the session had already consumed **14,534 tokens** (6% of the 258k context window gone on turn zero).\n\n*Figure 1: Codex context consumption after sending a single \"hi\". 14,534 tokens consumed before any actual work begins.*\n\nWhen I asked the agent which tools were currently active and callable, it returned **79 active tools**.\n\n## Click to view the full list of 79 active tools loaded in Codex\n\n```\napply_patch\ncodex_app__automation_update\ncodex_app__create_thread\ncodex_app__fork_thread\ncodex_app__get_handoff_status\ncodex_app__handoff_thread\ncodex_app__list_archived_threads\ncodex_app__list_projects\ncodex_app__list_threads\ncodex_app__load_workspace_dependencies\ncodex_app__navigate_to_codex_page\ncodex_app__open_in_codex\ncodex_app__read_thread\ncodex_app__read_thread_terminal\ncodex_app__send_message_to_thread\ncodex_app__set_thread_archived\ncodex_app__set_thread_pinned\ncodex_app__set_thread_title\ncodex_app__share_thread\ncodex_app__wait_threads\ncreate_goal\nexec_command\nget_goal\nimage_gen__imagegen\nlist_available_plugins_to_install\nlist_mcp_resource_templates\nlist_mcp_resources\nmcp__codex_apps__codex_document_control_execute_document_command\nmcp__codex_apps__codex_document_control_get_document_tool_schemas\nmcp__codex_apps__codex_document_control_list_document_sessions\nmcp__codex_apps__plugin_management_get_app_permissions\nmcp__codex_apps__plugin_management_get_plugin_dependencies\nmcp__codex_apps__plugin_management_uninstall_app\nmcp__codex_apps__plugin_management_update_app_permissions\nmcp__codex_apps__safety_settings_get_family_info\nmcp__codex_apps__safety_settings_get_parental_controls\nmcp__codex_apps__safety_settings_get_trusted_contact\nmcp__codex_apps__safety_settings_prepare_parental_control_update\nmcp__codex_apps__safety_settings_update_parental_control\nmcp__codex_apps__sites_add_custom_domain\nmcp__codex_apps__sites_change_site_slug\nmcp__codex_apps__sites_create_site\nmcp__codex_apps__sites_create_source_repository_write_credential\nmcp__codex_apps__sites_deploy_private_site_version\nmcp__codex_apps__sites_deploy_site_version\nmcp__codex_apps__sites_generate_siwc_bypass_token\nmcp__codex_apps__sites_get_deployment_status\nmcp__codex_apps__sites_get_environment_variables\nmcp__codex_apps__sites_get_site\nmcp__codex_apps__sites_get_site_version\nmcp__codex_apps__sites_get_site_worker_logs\nmcp__codex_apps__sites_list_custom_domains\nmcp__codex_apps__sites_list_site_versions\nmcp__codex_apps__sites_list_sites\nmcp__codex_apps__sites_read_database_overview\nmcp__codex_apps__sites_read_database_table_rows\nmcp__codex_apps__sites_refresh_custom_domain_status\nmcp__codex_apps__sites_remove_custom_domain\nmcp__codex_apps__sites_save_site_version\nmcp__codex_apps__sites_update_environment_variables\nmcp__codex_apps__sites_update_site_access\nmcp__codex_apps__sites_update_site_metadata\nmcp__node_repl__js\nmcp__node_repl__js_add_node_module_dir\nmcp__node_repl__js_reset\nmulti_agent_v1__close_agent\nmulti_agent_v1__resume_agent\nmulti_agent_v1__send_input\nmulti_agent_v1__spawn_agent\nmulti_agent_v1__wait_agent\nplugin_management__uninstall_plugin\nread_mcp_resource\nrequest_permissions\nrequest_plugin_install\nupdate_goal\nupdate_plan\nview_image\nweb__run\nwrite_stdin\n```\n\nIf you enable just one or two extra plugins, such as security scanners or GPT apps, the active tool list passes 100 callable tools.\n\n### 2. Gemini and Antigravity: fewer tools, still 19.9k tokens\n\nYou might assume that keeping the tool list shorter avoids context bloat. The Antigravity CLI (`agy`\n\n) with Gemini 3.7 Flash shows that tool count alone is not the whole story.\n\nI ran the exact same test: I opened a fresh session and sent `\"hi\"`\n\n.\n\nThe response was a single line (\"Hello! How can I help you with your project today?\"). The telemetry reported that **19.9k tokens** were consumed immediately on turn zero, with **13.8k tokens** taken up by tool schemas alone.\n\n*Figure 2: Antigravity CLI context breakdown after sending a single \"hi\". 13.8k tokens consumed by tool schemas alone.*\n\nAntigravity had only 17 tools active, not 79. Yet its tool schemas consumed **13.8k tokens** by themselves.\n\n## Click to view the 17 active tools in Antigravity\n\n```\n1. run_command\n2. manage_task\n3. schedule\n4. define_subagent\n5. invoke_subagent\n6. manage_subagents\n7. send_message\n8. write_to_file\n9. replace_file_content\n10. view_file\n11. list_dir\n12. grep_search\n13. find_by_name\n14. search_web\n15. read_url_content\n16. generate_image\n17. ask_question\n```\n\n#### The redundancy problem\n\nWhy create dedicated LLM tools for `list_dir`\n\n, `grep_search`\n\n, and `find_by_name`\n\nwhen the agent already has `run_command`\n\n(native bash)?\n\nAn agent with bash access runs `ls`\n\n, `grep`\n\n, `rg`\n\n, or `find`\n\ndirectly. Building separate function schemas for basic shell operations duplicates capabilities the model already has, while adding thousands of tokens of JSON schema definitions, parameter documentation, and edge-case instructions to every turn.\n\n### 3. Claude Code: built-in baseline and the MCP dilemma\n\nAnthropic recognized this problem in Claude Code and introduced *Deferred Tool Loading*.\n\nOut of the box without any MCP servers, Claude Code maintains a baseline of around 8 to 10 built-in tools (`Bash`\n\n, `View`\n\n/`Read`\n\n, `Edit`\n\n, `Replace`\n\n, `Glob`\n\n, `Grep`\n\n, `Agent`\n\n, `WebSearch`\n\n, `NotebookEdit`\n\n). Combined with system prompts and project instructions, turn zero consumption sits around **3,500 to 5,000+ tokens**.\n\nWhen developers connect multiple MCP servers for databases, issue trackers, or browser automation, the tool registry passes **30 to 40+ tools**, pushing the tool schema payload alone to **over 10,000 to 14,000+ tokens** per turn.\n\nTo handle this, Claude Code splits tools into two tiers when deferrable definitions exceed 10% of the context window:\n\n**Always Loaded:** Core file and search tools plus infrastructure (`Bash`\n\n,`Read`\n\n,`Edit`\n\n,`Write`\n\n,`Glob`\n\n,`Grep`\n\n,`Agent`\n\n,`ToolSearch`\n\n,`Skill`\n\n).**Deferred (Name-only):**`WebSearch`\n\n,`NotebookEdit`\n\n, cron automation tools, and all connected MCP extension tools.\n\n```\nAlways Loaded:\nBash, Read, Edit, Write, Glob, Grep, Agent, ToolSearch, Skill\n\nDeferred (Names only until fetched):\nWebSearch, TodoWrite, NotebookEdit, CronCreate, MCP servers...\n```\n\nWhile deferred loading reduces turn zero bloat when many MCPs are active, its discovery mechanism relies on an LLM meta-tool (`ToolSearch`\n\n):\n\n- When the model needs a deferred tool, it must first execute\n`ToolSearch(\"select:ToolName\")`\n\n. - The backend injects the full schema into the context, and only on the following turn can the model execute the tool.\n- To prevent the model from forgetting loaded tools during context compaction, the runtime maintains custom boundary metadata and compaction recovery logic.\n- Even in its minimal state, Claude Code keeps 9 tools permanently loaded (including redundant search tools and the\n`ToolSearch`\n\nmeta-tool itself), maintaining a baseline overhead of several thousand tokens.\n\n*Note on Claude Code numbers: Because I do not use Claude Code personally, these figures are based on technical analyses, telemetry shared by other engineers, and community discussions online. I used the lower-bound estimates reported by active users across standard setups.\n\n## Why turn zero overhead degrades agent performance\n\nThis design pattern across modern harnesses creates two problems:\n\n**Token cost and context exhaustion.** Burning 14k to 20k tokens on turn zero means you hit context limits and rate quotas faster. Over a multi-turn session with long reasoning chains, you re-send those 17 to 80+ tool schemas on every single request.**Attention dilution and tool confusion.** Models perform best when their decision space is focused. When an LLM sees dozens of similar tools (multiple thread management endpoints, site deployment tools, multi-agent spawners, duplicate search utilities), it burns reasoning capacity sifting through irrelevant options and is more prone to parameter hallucinations or picking the wrong tool.\n\n## Principle 1: action consolidation instead of CRUD APIs\n\nCutting context bloat does not start with runtime tricks. It starts with how you design individual tools from day one.\n\nIn traditional software engineering, REST and CRUD principles encourage creating granular endpoints for every verb:\n\n`memory_read`\n\n`memory_write`\n\n`memory_update`\n\n`memory_delete`\n\nThis makes sense for HTTP APIs because registering an extra endpoint in code has zero runtime payload cost until a client makes a request.\n\nFor AI agents, that assumption fails completely. **Every tool schema is sent across the wire and loaded into the LLM context window on every turn.** Four separate CRUD tools mean four JSON headers, four descriptions, four parameter objects, and four entries crowding the model's decision space.\n\n### Action-based tool consolidation\n\nWhen I design custom tools for agents, I consolidate operations by intent. For memory, I split the interface into at most two tools:\n\n`memory_read`\n\n: Handles semantic search, keyword lookup, and fetching specific memories.`memory_write`\n\n: Handles storing new memories, updating existing entries, and deleting memories by passing an`action`\n\nparameter (`\"create\" | \"update\" | \"delete\"`\n\n).\n\n```\n{\n  \"name\": \"memory_write\",\n  \"description\": \"Create, update, or delete entries in agent memory.\",\n  \"parameters\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"action\": {\n        \"type\": \"string\",\n        \"enum\": [\"create\", \"update\", \"delete\"],\n        \"description\": \"The mutation action to perform.\"\n      },\n      \"id\": {\n        \"type\": \"string\",\n        \"description\": \"Memory ID (required for update or delete).\"\n      },\n      \"content\": {\n        \"type\": \"string\",\n        \"description\": \"Memory content (required for create or update).\"\n      }\n    },\n    \"required\": [\"action\"]\n  }\n}\n```\n\nThe schema for `memory_write`\n\nis only about 15% to 20% larger than a single `memory_create`\n\nschema, but it replaces three separate tool definitions with one. You cut the schema footprint by 50% without losing any functionality.\n\nIf I want to be even more aggressive with token efficiency, I collapse all memory interactions into a single `memory`\n\ntool with an `action`\n\nenum (`search`\n\n, `fetch`\n\n, `create`\n\n, `update`\n\n, `delete`\n\n).\n\nModern LLMs handle action-parameterized tools reliably. I have run tools structured this way for months across diverse tasks, and the models pick the correct action without hesitation.\n\nThese architectural savings take effect **before** dynamic tool activation or prompt injection ever touches the system.\n\n## Principle 2: dynamic tool activation in Pi\n\n### Lessons from denkr.ai\n\nI ran into this exact bottleneck months ago when building my mobile app, [denkr.ai](https://denkr.ai).\n\nOn mobile workflows, context bloat directly degrades latency and unit economics. I built an early variation of dynamic tool routing in Denkr, loading tools contextually based on intent. It proved that models have no issue activating tools when they need them, provided the instructions are clear and the interface is frictionless.\n\nWhen I switched to Pi as my daily coding agent, I wanted the same lean setup. Because Pi is open source and gives developers full control over runtime lifecycle hooks, building this was straightforward.\n\n### How dynamic tool activation works\n\nThe extension (`dynamic-tools`\n\n) operates on four core mechanics:\n\n- A hard default of 4 active tools (\n`read`\n\n,`bash`\n\n,`edit`\n\n,`write`\n\n). - Standby tool registration with zero-schema prompt injection.\n- In-process bash interception for activation (\n`pi-tool`\n\n). - Co-activation groups and automatic TTL pruning.\n\n```\n+-------------------------------------------------------------+\n|                      User Prompt                            |\n+-------------------------------------------------------------+\n                              |\n                              v\n+-------------------------------------------------------------+\n|               Pi Hook: before_agent_start                   |\n|  - Active tools set to: read, bash, edit, write             |\n|  - Injects minimal Markdown standby tool list into prompt   |\n+-------------------------------------------------------------+\n                              |\n                              v\n+-------------------------------------------------------------+\n|             LLM decides to use a standby tool               |\n|            Runs bash: pi-tool activate browser_use          |\n+-------------------------------------------------------------+\n                              |\n                              v\n+-------------------------------------------------------------+\n|                  Pi Hook: tool_call                         |\n|  - Intercepts bash command in-process                       |\n|  - Calls pi.setActiveTools([...defaults, ...browserTools])  |\n|  - Rewrites bash command to safe stdout echo                |\n+-------------------------------------------------------------+\n                              |\n                              v\n+-------------------------------------------------------------+\n|                  Pi Hook: agent_settled                     |\n|  - Decrements run TTL on non-default tools                  |\n|  - Automatically purges expired tools back to 4 defaults    |\n+-------------------------------------------------------------+\n```\n\n## Technical mechanisms under the hood\n\n### 1. Minimal default baseline (4 core tools)\n\nAt startup, the extension forces Pi's active tool schema to only 4 tools:\n\n``` js\nconst DEFAULT_CONFIG = {\n  defaultTools: [\"read\", \"bash\", \"edit\", \"write\"],\n  groups: {\n    web_search: [\"web_search\", \"web_fetch\"],\n    browser_use: [\n      \"browser_open\",\n      \"browser_observe\",\n      \"browser_preview\",\n      \"browser_diagnostics\",\n      \"browser_act\",\n      \"browser_wait\",\n    ],\n    loops: [\"loops_report\", \"loops_create_definition\", \"loops_create_job\", \"loops_inspect\"],\n  },\n  autoResetOnSessionStart: true,\n  toolTtlRuns: 2,\n};\n```\n\nAny extension registered in Pi (via plugins, MCP, or local scripts) is loaded by Pi internally, but excluded from the active LLM schema using `pi.setActiveTools(...)`\n\n.\n\n### 2. Zero-schema overhead: prompt injection instead of meta-tools\n\nA common mistake when building tool managers is creating a dedicated LLM meta-tool (like `activate_tool({ name: string })`\n\n).\n\nAdding a meta-tool adds its own JSON schema overhead, parameter documentation, and function-calling indirection.\n\nInstead, I use Pi's `before_agent_start`\n\nhook to append a plain, lightweight Markdown summary to the system prompt:\n\n``` js\npi.on(\"before_agent_start\", async (event, _ctx) => {\n  await loadConfig();\n  applyActiveTools();\n\n  const standby = getStandbyTools();\n  if (standby.length === 0) return;\n\n  const standbyLines = standby.map((name) => {\n    const group = findGroupForTool(name, config.groups);\n    return group ? `- \\`${name}\\` (part of group: **${group}**)` : `- \\`${name}\\``;\n  });\n\n  const injection = [\n    \"## Dynamic Tool Activation\",\n    `Default active tools: ${config.defaultTools.map((t) => `\\`${t}\\``).join(\", \")}.`,\n    \"Standby tools (not currently in your active schema):\",\n    ...standbyLines,\n    \"\",\n    \"To activate a tool or group, run in bash: `pi-tool activate <name>`\",\n  ].join(\"\\n\");\n\n  return {\n    systemPrompt: `${event.systemPrompt}\\n${injection}`,\n  };\n});\n```\n\nA raw text list of 20 tool names takes around 100 tokens. In contrast, 20 JSON tool schemas with parameters, types, and descriptions consume 4,000 to 10,000 tokens.\n\n### 3. In-process bash interception\n\nSince the agent already has `bash`\n\nenabled by default, it does not need a new tool to activate others. It simply runs:\n\n```\npi-tool activate browser_use\n```\n\nThe extension intercepts the bash call directly inside the Node.js process using `pi.on(\"tool_call\")`\n\n:\n\n``` js\npi.on(\"tool_call\", async (event, _ctx) => {\n  if (event.toolName !== \"bash\") return;\n  const command = event.input?.command;\n  if (typeof command !== \"string\") return;\n\n  const piToolMatch = command.trim().match(/^(?:pi-tools?|activate-tool)(?:\\s+(.*))?$/i);\n  if (!piToolMatch) return;\n\n  // Activate the tools in memory\n  const result = activateTools(targetArgs);\n  const outputMessage = `[dynamic-tools] Activated tool(s): ${result.activated.join(\", \")}`;\n\n  // Rewrite command on the fly so bash executes an immediate echo with exit code 0\n  const escaped = JSON.stringify(outputMessage);\n  event.input.command = `node -e 'console.log(${escaped})'`;\n});\n```\n\nThere is no separate CLI binary installed on the host machine. Pi catches the call, updates `pi.setActiveTools()`\n\n, rewrites the shell command to output the confirmation string, and returns cleanly to the model. On the next turn, the activated tools are in the JSON schema.\n\n### 4. Co-activation groups\n\nTools rarely exist in isolation. When the agent needs browser automation, it needs navigation, observation, and action tools together (`browser_open`\n\n, `browser_observe`\n\n, `browser_act`\n\n, `browser_wait`\n\n).\n\nGrouping them in `config.json`\n\nallows a single call like `pi-tool activate browser_use`\n\n(or activating any single tool inside that group) to bring in the entire bundle at once.\n\n### 5. Automatic TTL pruning\n\nOnce a specialized task is finished, those extra tools should not linger in the prompt for the rest of the day.\n\nThe extension assigns a Time-To-Live (TTL) counter (default: 2 runs) to every activated standby tool.\n\n``` js\npi.on(\"agent_settled\", async (_event, _ctx) => {\n  let changed = false;\n\n  for (const [tool, ttl] of Array.from(toolTtlMap.entries())) {\n    const nextTtl = ttl - 1;\n    if (nextTtl <= 0) {\n      activeToolNames.delete(tool);\n      toolTtlMap.delete(tool);\n      changed = true;\n    } else {\n      toolTtlMap.set(tool, nextTtl);\n    }\n  }\n\n  if (changed) {\n    applyActiveTools();\n  }\n});\n```\n\nIf the agent executes an activated tool during a turn, its TTL refreshes. When the agent returns to standard coding tasks and leaves the tool idle for 2 turns, the tool expires and context snaps back to the lean 4-tool baseline.\n\n### 6. Real-world telemetry in CircaCode\n\nHere is what this looks like on a fresh turn zero greeting (`\"hi\"`\n\n):\n\n*Figure 3: Turn zero context consumption in Pi running inside CircaCode. Only 3.6k tokens processed (3.5k input tokens, 1.3% of the 272k window), including system prompt, persona, skills, and dynamic standby hints.*\n\n*Note: This image was captured from inside my desktop application, CircaCode, which runs Pi as its agent engine.*\n\n### 7. Interactive user slash commands\n\nFor human control, the extension registers native slash commands:\n\n`/activate-tool <name>`\n\n`/deactivate-tool <name>`\n\n`/tool list`\n\n`/tool reset`\n\nThese include auto-completion and interactive terminal select menus (`ctx.ui.select`\n\n), giving both the human and the agent equal control over the active workspace.\n\n## Side-by-side comparison\n\nHere is how all four coding agent environments compare when sending a single `\"hi\"`\n\non turn zero:\n\n| Agent Harness | Default Active Tools | Turn 0 Baseline Context Consumed | Tool Activation Mechanism |\n|---|---|---|---|\nCodex | 79 tools (100+ with plugins) | 14,534 tokens (6.0% of 258k) | Static (all tools always active in schema) |\nAntigravity (Gemini 3.7) | 17 tools | 19,900 tokens (13.8k tools alone) | Static (all tools always active in schema) |\nClaude Code* | 8–10 built-in (30–40+ with MCP) | ~3,500 – 14,000+ tokens | Meta-tool (`ToolSearch` round-trip for deferred tools) |\nPi + Dynamic Tools | 4 core tools (`read` , `bash` , `edit` , `write` ) | 3,600 tokens (1.3% of 272k) | In-process bash interception + auto-TTL |\n\n*Claude Code numbers represent conservative estimates reported by developers and technical documentation online, rather than personal benchmarks.\n\n## Results and takeaways\n\n| Metric | Static Tools Baseline (Codex / Antigravity) | Pi + Dynamic Tool Activation | Reduction |\n|---|---|---|---|\nTurn 0 Context Overhead | 14,500 – 19,900 tokens | 3,600 tokens | -75% to -82% |\nActive Schema Tools | 17 – 79+ tools | 4 core tools | -76% to -95% |\nTool Selection Reliability | Susceptible to schema hallucinations | High precision | Clean decision space |\n\n### 1. Preserving model intelligence and attention\n\nLLMs are sharper when their context window is clean. As the context window fills past 40% to 50% capacity, attention degrades. Models miss subtle instructions, make syntax errors, and produce more tool hallucinations.\n\nStarting every session with 15k to 20k tokens of static tool schemas eats directly into that high-performance zone. By keeping turn zero at 3.6k tokens, the model stays in its sharpest reasoning state for much longer during complex coding sessions.\n\n### 2. Building and connecting tools without context anxiety\n\nBefore dynamic activation, adding a new tool was an architectural compromise. Every new tool meant asking: *\"Is this feature useful enough to justify permanently adding 500 tokens of JSON schema to every single prompt for the rest of time?\"*\n\nWith dynamic activation, that penalty disappears. I can build, connect, and experiment with whatever tools and extensions I want, including browser automation, background task loops, scrapers, voice synthesis, or custom database utilities.\n\nWhen a tool is on standby, it does not load a JSON schema. It costs a single line of plain text in the standby hints list (about 5 to 10 tokens). I get an extensive tool ecosystem without paying the context tax on turns where I just need to edit a file.\n\n### 3. Open agent runtimes win\n\nHarnesses that treat the LLM context as an open, hackable runtime make this kind of optimization possible. Having direct access to lifecycle hooks (`before_agent_start`\n\n, `tool_call`\n\n, `agent_settled`\n\n) lets you tailor the agent environment to your actual workflow instead of being locked into a rigid, static tool schema.", "url": "https://wpnews.pro/news/i-cut-80-of-context-overhead-in-my-coding-agent", "canonical_source": "https://m-reschreiter.at/en/blog/how-i-cut-80-percent-context-overhead-dynamic-tools", "published_at": "2026-08-28 09:22:46+00:00", "updated_at": "2026-08-28 09:48:24.416380+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "large-language-models", "ai-infrastructure"], "entities": ["OpenAI Codex", "Pi"], "alternates": {"html": "https://wpnews.pro/news/i-cut-80-of-context-overhead-in-my-coding-agent", "markdown": "https://wpnews.pro/news/i-cut-80-of-context-overhead-in-my-coding-agent.md", "text": "https://wpnews.pro/news/i-cut-80-of-context-overhead-in-my-coding-agent.txt", "jsonld": "https://wpnews.pro/news/i-cut-80-of-context-overhead-in-my-coding-agent.jsonld"}}