Blog

How the OpenAI Codex Team Builds Codex With 10-Bullet Specs
The OpenAI Codex team is not merely building an AI coding agent. It is also using that agent to compress the way product work gets done: product managers submit pull requests, designers write production code, engineers explore requirements directly against the repository, and formal specifications are reserved for the coordination problems that genuinely need them.

That is the central lesson from a 43-minute Behind the Craft interview with Codex product lead Alexander Embiricos and OpenAI developer-experience lead Romain Huet. The most repeated headline from the conversation—“the entire Codex product has a ten-bullet spec”—is too strong. What Embiricos actually said was that the team writes very few specs and, when one is needed, it may be only “like 10 bullets or something.”

The distinction matters. The Codex approach is not “never document.” It is to delay documentation until the work exceeds what one empowered owner, working with an agent, can understand and execute.

The original WeChat article framed the interview as a tutorial from the Codex team. Source artwork preserved for provenance.

What the OpenAI Codex Team Revealed

The interview describes an operating model built around five linked ideas:
1. Write a spec only when complexity or coordination requires one.
2. Plan concrete work for no more than about eight weeks, while keeping a looser long-term direction.
3. Let the people closest to the code make more decisions.
4. Treat product management as missing-work coverage, not automatic command authority.
5. Hire for agency and evidence of shipped work.
These are statements about one unusually technical, fast-growing team. Some details—such as the approximate team size or comparisons between designer and engineer output—are anecdotes from the speakers, not independently audited productivity metrics. The useful question is therefore not whether every company should copy Codex, but which conditions make this model viable.

Peter Yang interviewed Codex product lead Alexander Embiricos and developer-experience lead Romain Huet. Watch the original conversation on YouTube.

Five operating principles discussed in the interview. The team-size and PM-count figures are approximate interview statements.

Why Codex Uses 10-Bullet Product Specs

Traditional product development often separates discovery, requirements, design, implementation, and validation among several roles. Each handoff creates a need for more explicit documentation. Codex changes the economics of those handoffs because a single person can ask an agent to inspect the repository, trace dependencies, propose options, implement a small change, run tests, and prepare a pull request.

Embiricos said the team writes a spec when the problem becomes too large for one person to hold in their head or when several people need to coordinate. Even then, the document can be extremely short. The objective is not completeness for its own sake; it is enough shared context to unblock a decision.

Huet demonstrated the same principle through Codex Plan Mode. He pointed the agent at an iOS project and asked what the team should build next. Rather than starting from a blank planning template, the agent inspected the actual codebase and proposed directions grounded in the product’s current state.

This shifts product discovery closer to executable evidence. A plan can be challenged against code, tests, interfaces, and technical constraints before a large group commits to it.

The interview does not claim that one ten-bullet document specifies all of Codex. It says the team writes few specs and keeps them short when they are needed.

How PMs and Designers Use Codex to Explore Ideas

Embiricos described three practical modes for a product manager:
- For a small change, submitting a good pull request may be faster than negotiating for engineering priority.
- For a medium-size change, Codex can produce an implementation plan for review.
- For a vague or complex idea, the agent can explore the repository and help the PM build a mental model—even if the generated implementation is never shipped.
That third mode is the most important. The output is not always code. It can be better questions, clearer trade-offs, or an explanation that helps an engineer understand why a direction matters.

The interview also claims that Codex designers now contribute more code than an engineer did six months earlier. That should be read as a qualitative observation from the product lead, not a benchmark. The broader point is credible: once generating a working change becomes easier, role boundaries move. The scarce work becomes selecting the right change, defining quality, reviewing behavior, and owning the result.

The team says most of its code is agent-generated, yet it does not present this as carefree “vibe coding.” Humans still provide system design, judgment, verification, and accountability. Teams adopting the same pattern need authority controls for AI coding agents so that faster execution does not silently expand risk.

Codex can be an implementation tool, a planning tool, or a way to explore a problem before handing the insight to an engineer.

Why OpenAI Plans for Eight Weeks—or the Distant Future

Embiricos relayed advice from an OpenAI researcher named Andre: plan near term or long term, but avoid the middle. He described near-term planning as a concrete goal with an absolute maximum horizon of roughly eight weeks. Long-term planning is more directional: assume models become more capable, more tasks can be delegated, and many agents can work in parallel.

The missing middle is a conventional feature roadmap. When model behavior changes rapidly, a detailed six-month sequence can encode assumptions that expire before the work begins.

This was presented as advice that shaped the Codex team—not as a formally published OpenAI policy. It also has limits. A regulated product, hardware program, enterprise migration, or multi-party launch may require commitments far beyond eight weeks. The transferable principle is to match planning detail to the stability of the underlying constraints.

A useful planning frame for a rapidly changing model layer: specific near-term commitments and a flexible long-term direction.

How Parallel Agents Led to the Codex App

The Codex desktop app illustrates how product direction, model capability, and user behavior interacted.

OpenAI released GPT-5.2-Codex on December 18, 2025, describing it as optimized for long-horizon work, context compaction, large refactors, and reliable long-running tasks. Embiricos said this generation crossed an important practical threshold: users could delegate longer tasks and expect more one-shot completions.

Advanced users responded by running many terminal sessions in parallel. In the interview, Embiricos approximated one widely shared setup as “like 18 terminals” across three displays. The desktop app made that multi-agent pattern visible and manageable for people who would not build a tmux command center.

But model progress did not create the app idea from nothing. Embiricos also described discussing a delegation-oriented interface with Peter Steinberger in October, before GPT-5.2-Codex shipped. The more accurate causal story is that better models and observable power-user behavior validated and accelerated an existing direction.

OpenAI launched the Codex app for macOS on February 2, 2026, later adding Windows. The official launch post said Codex usage had doubled since the mid-December model release and that more than one million developers had used Codex in the preceding month. By March 19, OpenAI reported more than two million weekly active Codex users.

The app productized a power-user pattern: several delegated coding tasks progressing in parallel.

Why Power Users Shape the Product Roadmap

Codex is unusually exposed to its most advanced users because its core is open source. Users can inspect code, enable experimental behavior, fork the project, and develop workflows before the product team has simplified them for a broader audience.

That makes power users an early-warning system for product demand. It can also make the product inaccessible if every advanced control is promoted into the default interface.

The team’s answer is layered design: keep the core interaction minimal, provide sensible standard behavior, and let experts discover configuration, forks, and experimental features over time. The metaphor in the interview was a game that reveals deeper mechanics as the player progresses.

This is a stronger strategy than simply copying whatever power users do. The team watches the frontier, identifies repeated behavior, then decides which parts deserve a safer and simpler product surface.

Layering lets experts reach advanced controls without forcing every new user to understand them on day one.

Inside the Codex Team's “Pirate Ship” Operating Model

When Yang suggested the Codex group had roughly 50 to 100 people, Embiricos said that sounded about right. He also said the rapidly growing team had only recently added a second product manager and intentionally operated a little like a “pirate ship,” with limited cross-functional alignment and simple reporting lines.

He described switching between two modes. In execution mode, he uses Codex to understand feedback, inspect the repository, prepare changes, and help the team launch. In coordination mode, he spends more time forming direction and communicating trade-offs.

This structure works partly because the builders are also users. Engineers, designers, and PMs can evaluate the product through daily experience, while an active open-source community supplies constant external feedback. A team serving unfamiliar users, complex buyers, or multiple regulated stakeholders cannot assume the same degree of shared intuition.

The “pirate ship” is a speaker metaphor, and the 50–100-person range is approximate—not a formal organization chart.

Codex as a Developer-Platform Entry Point

Huet argued that Codex is becoming an entry point to the broader OpenAI developer platform. Instead of publishing only hand-written integration guides, developer-experience teams can package knowledge as Skills and teach builders to use Codex to work with image generation, Sora, speech-to-speech systems, APIs, and external tools such as Linear.

This idea expands Codex from a code generator into an orchestration surface: the agent can read documentation, modify an application, run commands, and connect the developer’s intent to several platform capabilities.

The architecture supports that direction. The open-source Codex repository is primarily Rust, and its documented core contains shared business logic. The app-server documentation says it powers rich interfaces such as the VS Code extension. In the interview, Huet said the desktop app, IDE extension, and CLI communicate with the same open-source harness.

For readers who want the command-line foundation, the Codex CLI guide explains the lower-level workflow. Teams coordinating several agents should also consider a file-first multi-agent collaboration protocol so that parallel work remains inspectable.

Huet described Codex plus Skills as a practical way to teach developers to use a wider platform.

Is AI Eliminating the Product Manager Role?

Embiricos offered the interview’s most provocative position: he sees product management as a gap-filling role rather than inherently a leadership role. As agents let engineers, designers, and PMs perform more of one another’s work, the gaps change.

The useful interpretation is not “fire every PM.” Embiricos explicitly preserved a place for people who spend serious time with users, understand a market, and operate in a sufficiently large organization. Every problem still needs an owner; the owner does not always need the PM title.

Huet recalled that Stripe reached about 250 employees with no PMs before modern AI tools, because engineers were building an API they personally wanted to use. That is an interview recollection rather than a separately audited staffing record, but it highlights the dependency: the closer builders are to users and the product, the less translation work is required.

AI compresses the talent stack most effectively when people possess judgment outside their original role. A PM who can inspect code, a designer who can ship an implementation, and an engineer who can interview customers can make decisions with fewer handoffs. But eliminating coordination without distributing those skills merely hides the work.

The gap-filler framing is conditional: customer insight and coordination remain essential in large or unfamiliar markets.

What Other Product Teams Can—and Cannot—Copy

Most teams can copy the mechanics before copying the organization:
- Give one owner an agent and access to the real repository.
- Ask for a plan grounded in code before scheduling a large planning meeting.
- Let non-engineers prepare small, reviewable pull requests.
- Keep near-term goals concrete and revise medium-term assumptions frequently.
- Separate agent speed from human approval, testing, security, and ownership.
- Observe advanced user workflows, then productize only repeated and valuable patterns.
What they should not copy blindly is the staffing ratio or lack of formal coordination. Codex benefits from technical users, employees who use their own product, an open-source feedback loop, strong model expertise, and a platform changing quickly enough to punish rigid roadmaps. A healthcare workflow, enterprise procurement product, or consumer service for unfamiliar users has different constraints.

The right experiment is small and measurable: choose one bounded feature, let a cross-functional owner use Codex from discovery through pull request, and compare lead time, defects, review burden, and user outcome with the existing process.

A Practical AI-First Product Development Playbook

An AI-first workflow inspired by the OpenAI Codex team can be expressed as seven steps:
1. Start from the repository. Let the agent inspect current behavior before proposing a feature.
2. Name one accountable owner. The agent can execute tasks, but a person owns the decision and result.
3. Use the lightest useful artifact. A short plan or ten bullets may be sufficient; add detail only when coordination requires it.
4. Delegate exploration before implementation. Ask the agent for alternatives, dependencies, tests, and failure modes.
5. Keep work bounded and verifiable. Use clear permissions, tests, review gates, and rollback paths.
6. Share the mental model. Preserve the reasoning and trade-offs, not only the generated patch.
7. Measure outcomes, not code volume. Faster code generation matters only if the team ships the right behavior at acceptable quality.
That approach also explains the team’s hiring preference. Embiricos emphasized links, ideas, agency, and visible work over credentials. Agent leverage rewards people who notice an important problem, learn what they need, and carry the work through verification.

“Show me what you built” summarizes the interview’s preference for agency and demonstrated work.

Conclusion

The OpenAI Codex team offers a compelling preview of product development after code generation becomes cheap. Specifications shrink because exploration happens against the codebase. Roles blur because more people can make working changes. Planning becomes shorter because the model layer moves quickly. Product management shifts toward whichever gaps still require human judgment.

The model is powerful, but it is not universal. Its success depends on technically fluent builders, direct contact with users, strong verification, and clear ownership. The durable lesson is not “use exactly ten bullets.” It is to remove coordination that no longer creates value while making accountability more explicit wherever an agent increases execution speed.

This article is a substantially rewritten English analysis based on BaoyuAI's original WeChat article, “Interview: How the Codex Team Uses Its Own Product to Build Codex”, the original interview, and the primary sources below.

Primary Sources
Frequently Asked Questions

Does the entire Codex product have one 10-bullet spec?

No. Embiricos said the team writes very few specs and that a spec, when needed, may be roughly ten bullets. He did not say one ten-bullet document specifies the entire product.

Does the Codex team have no product managers?

No. The interview said the team had only recently added a second PM. The broader argument was that product ownership and leadership do not automatically have to belong to a PM.

Did GPT-5.2-Codex create the Codex app idea?

Not by itself. The team was already discussing a delegation-oriented interface before the model launched. Better long-horizon capability and visible parallel-terminal workflows helped validate and accelerate the app.

Can any company replace its roadmap with eight-week plans?

Not safely. The approach fits a rapidly changing software and model environment. Products with regulatory, hardware, contractual, or multi-company dependencies may require longer commitments and more formal documentation.

What is the most transferable lesson from the OpenAI Codex team?

Put planning and implementation closer together. Give a responsible owner access to the real codebase, use agents to explore and execute, and add documentation or coordination only when complexity justifies it.
July 16, 2026

Sonnet 5 vs Fable 5 for Repository Tasks: Model or Context System?

Choose Claude Sonnet 5 as the practical default for frequent repository work; evaluate Claude Fable 5 for the hardest, longest-running tasks that justify higher cost and additional operational constraints. Both have one-million-token context windows, so the deciding evidence should be task completion, review effort, latency, cost, and recovery—not window size alone.

Neither model automatically understands a repository. Claude Code, project rules, search, source files, architecture documents, tests, permissions, and any external knowledge layer determine what evidence the model can use. A stronger model cannot recover design intent that the team never recorded.

Quick Verdict

Anthropic positions Sonnet 5 as a fast, capable model for regular coding and agent workflows, while Fable 5 is its most capable widely released model for demanding long-horizon work. That makes Sonnet the lower-friction starting point and Fable the escalation candidate.

Decision factor	Claude Sonnet 5	Claude Fable 5
Practical role	Frequent edit-test loops and broad team use	Ambitious, long-running, high-difficulty work
Context window	1M tokens	1M tokens
Maximum output	128K tokens	128K tokens
Listed API price at verification	Introductory $2 input / $10 output per million tokens through August 31, 2026; then $3 / $15	$10 input / $50 output per million tokens
Key operational difference	Faster, lower-cost default	Higher-cost escalation with model-specific safeguards and retention rules
Evidence standard	Private repository pilot	Same pilot, with long-horizon and failure-recovery tasks

Prices, access, and model behavior are volatile. Anthropic’s current documentation should be checked again before publication or procurement.

What Repository Tasks Need

Repository tasks combine several capabilities that a short coding benchmark may not isolate.

The model must discover relevant files without opening the whole repository. It must trace relationships across modules, distinguish source from generated code, understand build and test commands, preserve public contracts, and recognize when a change crosses an ownership or architecture boundary.

Multi-file refactoring adds consistency demands. A renamed interface may affect implementations, tests, generated clients, documentation, telemetry, and external consumers. Repository analysis also requires negative evidence: a model should say when it cannot verify a runtime path rather than inventing one.

Long-running coding agents need operational memory across planning, editing, tests, failures, and revisions. They also need permission controls, isolated branches, reproducible commands, and a human acceptance rule. These are properties of the agent system, not only the model.

A fair comparison therefore includes at least:

localized bugs with hidden tests;
cross-module interface changes;
architecture-constrained refactors;
impact analysis without editing;
build or CI diagnosis;
interrupted tasks that must resume from saved evidence;
incorrect initial hypotheses that require recovery.

Run those tasks from equivalent clean sessions and keep the repository revision, tool permissions, instructions, reasoning settings, and time budget fixed. Score navigation accuracy, missed dependencies, test-driven corrections, unsupported claims, reviewer intervention, latency, and total cost. Without that control, teams may mistake a better-prepared prompt or an easier task for a model advantage.

Model Capability vs Context Infrastructure

Anthropic says Fable 5 improves on Opus 4.8 in long-horizon autonomy, dense technical vision, code review, debugging, and search across codebases and repository history. Anthropic also positions it for large migrations, complex implementations, and multi-day agent sessions. These are vendor claims and should be tested on the target repository.

Sonnet 5 shares the same nominal one-million-token context window and 128K maximum output. Anthropic positions it as a speed-and-intelligence balance for coding and agentic work. The practical difference is not that Fable can “see the repository” while Sonnet cannot. It is whether Fable’s additional capability changes outcomes enough to justify its price, latency, safeguards, and usage model.

Context infrastructure often dominates both.

Claude Code can search files, run commands, edit code, and use project instructions. Architecture documents explain boundaries that source alone may not reveal. A code knowledge graph can expose callers, imports, tests, and cross-document relationships. Tests and build systems provide executable evidence.

This infrastructure remains useful when the model changes. Graphify’s guide to knowledge graphs for AI coding assistants explains why a reusable relationship layer can reduce repeated discovery. The Claude Sonnet 5 large-codebase guide covers the limits of context capacity in more detail.

The right model receives selected evidence from these layers. It should not be asked to infer the entire system from a flat dump of files.

Multi-File Refactoring Scenarios

For a routine refactor with clear ownership and tests, start with Sonnet 5. Examples include moving a helper, tightening a type, updating a well-documented API inside one service, or repairing a regression with a narrow failing test. Lower latency and cost can matter more than maximum model capability when the feedback loop is short.

Escalate to Fable 5 when the task has several compounding difficulties:

the migration crosses many packages or services;
the implementation spans hours or days;
the plan must be revised after test or deployment evidence;
the agent must coordinate parallel investigations;
visual artifacts or dense technical documents are important;
the repository history is needed to understand a regression;
earlier models repeatedly miss interactions under the same harness.

Do not escalate merely because the repository is large. A ten-million-line monorepo with a well-indexed, isolated change may be easier than a small service with dynamic wiring and no tests.

For either model, use a repository task contract:

freeze the starting commit;
define allowed directories and commands;
provide architecture and generated-file rules;
require an impact plan before broad edits;
run hidden regression tests;
inspect dependency and contract changes;
record reviewer corrections and recovery actions.

If context cost becomes a bottleneck, pxpipe is a separate option rather than a model feature. It can render selected bulky context as images and defaults to Fable 5 based on project-run reading tests. Its lossy representation is unsuitable for exact code and identifiers. See the planned pxpipe context analysis after that page is published.

Limits and Claims to Verify

First, verify availability and policy. Fable 5 launched on June 9, 2026, was suspended on June 12 after a US government directive, and was restored globally starting July 1. Anthropic currently lists it in Claude Code and the Claude Platform, but plan, provider, region, safeguards, usage credits, and retention rules can affect access.

Second, verify data handling. Anthropic’s Fable documentation states that the model requires 30-day retention and is not available under zero-data-retention terms. A team with stricter code or customer-data requirements may need a different model or deployment path.

Third, account for refusals. Fable 5 includes safety classifiers and can return stop_reason: "refusal" for covered requests. Anthropic documents fallback options. Repository pilots should include legitimate security maintenance if that workload matters, because a general coding success rate will not reveal safeguard friction.

Fourth, treat benchmarks as bounded evidence. A benchmark can measure patch completion under a harness; it rarely measures architecture comprehension, ownership, rollback safety, or reviewer effort. The pxpipe project’s small Fable SWE-bench trials are evidence about its compression path, not evidence that Fable is universally superior to Sonnet for repository work.

Finally, do not assume that equal context windows imply equal effective recall, cost, or behavior. Tokenizers, reasoning settings, tool use, client scaffolding, caching, and model updates change the result. Record exact model IDs and dates.

FAQ

What benchmark would reflect repo analysis?

Use private tasks that require dependency discovery, impact analysis, architecture constraints, hidden tests, and explanation of uncertainty. Include non-editing tasks and score missed consumers, unnecessary files, reviewer corrections, and regressions. Public patch benchmarks can supplement this set but should not replace it.

How should teams compare long-running agents?

Freeze the repository, task, permissions, tools, and acceptance tests. Run multiple trials with Sonnet 5 and Fable 5. Record completion, elapsed time, turns, cost, context compactions, retries, safeguard refusals, test outcomes, human interventions, review minutes, and recovery from wrong plans.

When should a graph layer be model-independent?

Keep it model-independent when several agents or model versions need the same repository structure, when model switching is common, or when architecture and ownership knowledge must survive individual sessions. Store provenance and refresh information so every model can verify graph results against current source.

Conclusion

The durable answer to Sonnet 5 vs Fable 5 coding is a routing policy, not a permanent ranking. Use Sonnet 5 as the default candidate for frequent repository analysis and edit-test work. Escalate to Fable 5 when difficult, long-running tasks show measurable gains under the same repository harness.

Keep project understanding outside the model choice: maintained instructions, architecture records, search, structural graphs, source links, tests, and review. Then replace or route models without forcing each new model to rediscover the repository’s truth from scratch.

July 16, 2026

Claude Sonnet 5 for Large Codebases: What Context Still Misses

Claude Sonnet 5 is a credible option for large-codebase work because Anthropic gives it a one-million-token context window and positions it for complex, multi-file coding. That capacity can keep more source, documentation, and tool history available during a task. It does not automatically reveal architecture, dependency boundaries, ownership, or the reasons behind past design decisions.

The practical question is therefore not whether Sonnet 5 can ingest a large repository. It is whether your Claude Code workflow supplies the right evidence, lets the model navigate selectively, and verifies changes against the repository’s actual constraints.

Why Large Codebases Stress Coding Models

Large repositories are difficult because relevant knowledge is distributed rather than merely long. A change that looks local may depend on a schema, generated client, build rule, feature flag, deployment contract, or convention defined elsewhere.

Repository work also contains several kinds of context:

Source context: functions, types, tests, configuration, and generated artifacts.
Structural context: imports, calls, inheritance, data flow, package boundaries, and service dependencies.
Operational context: build commands, CI rules, deployment order, observability, and rollback requirements.
Institutional context: ownership, accepted patterns, rejected alternatives, and design intent.

A model can read source without knowing which relationships matter. For example, finding every textual reference to a type is not the same as identifying every runtime consumer of the data it represents. Large-codebase work stresses retrieval, prioritization, planning, execution, and regression control at the same time.

Claude Code can reduce some friction because it lets the model inspect files, search the repository, edit code, and run commands. However, tool access changes the workflow, not the truth available inside the repository. Missing documentation and weak tests remain missing evidence.

What a Larger Context Window Can Help With

Anthropic’s current documentation lists Claude Sonnet 5 as claude-sonnet-5, with a one-million-token context window by default and up to 128,000 output tokens. Anthropic also says the model is available through Claude Code, Claude.ai, the Claude API, and supported cloud platforms.

That larger working space can help in four practical ways.

First, it reduces premature eviction. The agent can retain more of the issue, inspected files, tool results, plans, and test failures before it must compress or discard earlier material.

Second, it supports wider evidence gathering. A migration task may require reading interface definitions, several implementations, representative tests, and build configuration together.

Third, it gives long-running tool workflows more room. Planning, editing, testing, diagnosing, and revising all consume context. A larger window can preserve continuity across those steps.

Fourth, it can make cross-file comparison easier. Anthropic describes Sonnet 5 as suitable for reasoning across complex multi-file codebases and large-scale refactors. This is a vendor capability claim, not independent proof for every repository, but it is consistent with the model’s intended use.

Nominal window size still needs interpretation. Anthropic says Sonnet 5 uses a new tokenizer that can produce roughly 30% more tokens for the same text than Sonnet 4.6. A “one-million-token repository” is therefore not a stable number of files, lines, or modules across models.

What Context Windows Still Miss

A context window stores selected material for a run. It does not turn that material into a maintained model of the system.

The window does not inherently know:

which service owns a shared contract;
whether an import is architectural or incidental;
which dependency is loaded dynamically;
why a team rejected an apparently simpler design;
which generated files must never be edited;
which downstream repository consumes an API;
whether a passing unit test misses a production invariant.

More raw text can even create a selection problem. Loading broad directory trees may bury the critical interface among duplicated fixtures, generated code, vendored packages, and stale documents. Attention is finite even when capacity is large.

Long-context evaluations reinforce this distinction. They can measure retrieval or reasoning over long inputs, but accepting a long prompt is not equivalent to perfect recall, correct impact analysis, or compliance with undocumented conventions.

The safest workflow treats context capacity as room for evidence, not as proof that the evidence is complete or correctly organized.

Where Code Knowledge Graphs Fit

A code knowledge graph can act as a query layer over repository structure. Instead of repeatedly asking the model to rediscover relationships from raw files, the workflow can expose nodes such as symbols, modules, APIs, tests, owners, and documents, connected by typed relationships.

This changes the initial question from “Which files should fit in the prompt?” to “Which entities and relationships are relevant to this change?” The graph can identify a smaller evidence set, while Sonnet 5 reads the underlying code and reasons about the requested task.

A useful division of labor is:

Layer	Best use
Context window	Hold task-specific source, plans, tool output, and current reasoning
Repository search	Find exact text, filenames, symbols, and recent changes
Code knowledge graph	Query dependencies, callers, ownership, tests, and cross-module paths
Project documentation	Explain architecture, policy, and design intent
Test and build system	Verify behavior and detect regressions

Graphs have limits too. A stale graph can confidently return obsolete relationships. Dynamic calls, reflection, generated code, runtime configuration, and external consumers may be incomplete. Graph results should point the model toward source evidence, not replace source inspection.

For a practical setup, see how to help Claude Code understand a complex repository and the broader comparison of context windows and code graphs.

What to Verify Before Relying on Sonnet 5

Do not select a coding model for a large repository from its advertised context window or a single leaderboard score. Run a private pilot against work that resembles your team’s real changes.

Use a frozen repository commit and a balanced task set:

a localized bug with clear tests;
a cross-module change involving a public interface;
a refactor constrained by architecture rules;
a CI or build failure with environmental dependencies;
an impact-analysis task that does not require editing.

Record the model ID, Claude Code version, effort setting, tool permissions, network policy, starting prompt, context supplied, commands, patch, test results, elapsed time, and token cost. Repeat each task because one successful trajectory does not establish reliability.

Benchmark evidence needs similar care. OpenAI reported in February 2026 that SWE-bench Verified had contamination and flawed-test problems. In July, it estimated that roughly 30% of SWE-Bench Pro tasks were broken. Those findings do not make repository benchmarks useless; they mean teams should inspect task design and avoid treating a headline pass rate as a universal measure of codebase understanding.

Human review should focus on dependency impact, unnecessary edits, missing consumers, test adequacy, and violations of repository conventions. Architecture-sensitive or production-critical changes should require approval even when the patch passes its visible tests.

FAQ

What repo docs should be prepared first?

Prepare a short repository map, build and test commands, module ownership, architecture boundaries, public contracts, generated-file rules, and links to current design decisions. Keep instructions concise and route deeper details through linked documents so the model can retrieve them when relevant.

How should teams test large-repo behavior?

Use private tasks from the target repository, hidden acceptance and regression tests, isolated environments, and repeated runs. Include both editing and analysis tasks. Compare correctness, regression rate, review effort, diff size, latency, and cost rather than context size alone.

When should model output require architecture review?

Require architecture review when a change crosses service or package boundaries, alters a public contract, changes persistence or security behavior, introduces a new dependency, modifies deployment topology, or relies on an inferred relationship that the repository does not verify automatically.

Conclusion

Claude Sonnet 5 gives Claude Code substantially more working room and is officially aimed at demanding coding and agent workflows. That makes it useful for large repositories, but not self-sufficient.

Use its long context to hold the evidence selected by repository search, documentation, and structured code relationships. Then use tests and human review to verify the result. The decision rule is simple: choose Sonnet 5 when it improves real repository outcomes under your harness—not because one million tokens sounds large enough to contain the codebase.

July 16, 2026

GLM-5.2 Context Window vs Code Knowledge Graphs

GLM-5.2’s one-million-token context window and a code knowledge graph are not substitutes. The context window holds source, instructions, tool results, and reasoning for the current run. A graph stores selected repository entities and relationships so agents can query structure across runs. Large-repository workflows usually benefit from both.

The useful comparison is therefore not “Which one understands code?” It is “Which information should stay in working memory, and which relationships should remain reusable outside the prompt?”

Quick Verdict

Use GLM-5.2’s long context when a task requires reading substantial primary evidence together: multiple implementations, tests, specifications, logs, or a long coding-agent trajectory. Use a code knowledge graph when the task begins with structural questions such as which components call an API, which tests cover a symbol, or which modules sit downstream of a schema.

The two layers work best as a retrieval-and-reasoning loop:

the graph narrows the relevant entities and paths;
the agent retrieves the authoritative source files;
GLM-5.2 reasons over those files and the active task;
tests and human review verify the change;
the repository index refreshes after accepted changes.

Long context lowers the pressure to discard evidence. A graph lowers the cost of rediscovering relationships. Neither guarantees correct code.

Evaluate both layers with repeatable repository tasks. Measure discovery time, irrelevant files retrieved, missed dependencies, unsupported relationship claims, and corrections after tests. Those metrics distinguish genuine navigation gains from the simple ability to place more text inside one request.

What a 1M Context Window Can Help With

Z.ai launched GLM-5.2 on June 16, 2026 and officially documents a one-million-token context window. Its Coding Plan instructions identify GLM-5.2[1m] as the selection for enabling the one-million-token mode in Claude Code, so teams should confirm the actual model mode used in a trial.

A large window can improve a coding workflow in several concrete situations:

comparing an interface with many implementations and tests;
keeping a long issue description, repository evidence, and execution plan together;
retaining tool output across repeated build, test, and debugging cycles;
analyzing large logs alongside the relevant code;
completing long-horizon tasks without compressing the trajectory as early.

Z.ai reports results for GLM-5.2 on coding and long-horizon evaluations, including SWE-bench Pro, NL2Repo, Terminal-Bench 2.1, FrontierSWE, PostTrainBench, and SWE-Marathon. These numbers are vendor-reported results under disclosed but different harnesses. They support the claim that Z.ai designed the model for coding-agent work; they do not prove that every task used one million tokens or that the model understood every repository relationship.

The distinctions matter. Z.ai says several standard coding runs used 256K or 400K context, while its named long-horizon runs used 1M. A benchmark result belongs to its model, harness, prompt, effort setting, tool policy, timeout, resources, and dataset version—not to context length alone.

GLM-5.2 is also available as open weights under an MIT license. The official model card lists approximately 753 billion parameters and documents several serving frameworks. That makes self-hosting possible in principle, but “local” should not be confused with laptop-scale deployment.

Why Raw Context Still Lacks Structure

Raw context is ordered tokens. Repository structure is a set of typed, changing relationships.

Suppose an agent must change a request object used by five services. Loading a million tokens might include the type definition, several callers, documentation, and tests. It may also include generated code, duplicate fixtures, old migration paths, and unrelated vendor packages. The model must still identify which evidence is authoritative.

Context alone does not explicitly answer:

Which callers are reachable in production?
Which implementation owns the contract?
Which tests cover the affected path?
Which service deploys first?
Which dependency is dynamic rather than imported directly?
Which design decision explains the current boundary?

These questions require navigation and interpretation. A long window can hold the answer after it is found, but it does not ensure the correct files were selected.

Long prompts also create operational costs. Prefill latency, cache capacity, inference memory, and token billing can grow with the supplied material. Z.ai’s own architecture discussion describes the serving challenges created by one-million-token workloads. The right goal is not to maximize prompt occupancy. It is to maximize relevant evidence per task.

Code Knowledge Graphs as a Query Layer

A code knowledge graph represents repository entities as nodes and meaningful relationships as edges. Depending on the index, nodes may include files, symbols, modules, endpoints, schemas, tests, owners, commits, and design documents.

An agent can use that graph to ask focused questions before opening raw files:

Repository question	Possible graph relation
What calls this function?	symbol → caller
What breaks if this schema changes?	schema → consumer
Which tests exercise this endpoint?	endpoint → test
Who owns this package?	module → owner
Which design note explains this dependency?	component → decision document

The graph is a query layer, not the final source of truth. The agent should follow graph results to current code, configuration, and tests. This protects the workflow from stale or incomplete indexes.

Graphs are particularly useful across model changes. A repository team can switch from GLM-5.2 to another coding model without rebuilding every piece of project memory inside a new prompt. The model-specific context remains temporary; the repository relationship layer remains reusable.

Graphify’s role in this design is to provide structured code knowledge for navigation and impact analysis, while the coding model performs task-specific reasoning. This is complementary to GPT context and repository understanding, not a claim that a graph can replace source reading.

What to Verify About GLM-5.2

Verify the exact endpoint and mode before publishing or acting on a “1M context” result. Record whether the trial used hosted Z.ai access, a Coding Plan integration, or self-hosted weights, plus the model ID, serving framework, quantization, context limit, effort setting, and agent harness.

Then test the complete system on private repository tasks. A useful evaluation matrix includes:

a focused bug fix;
cross-module impact analysis;
a multi-file feature;
an architecture-constrained refactor;
a long test-and-debug trajectory.

Use frozen commits and isolated environments. Keep acceptance tests hidden from the agent, run regression tests, repeat tasks, and retain the full trajectory. Check for grader gaming as well as normal failure. Z.ai specifically documents anti-hacking controls because coding agents can attempt to read protected artifacts, fetch known solutions, or optimize the evaluator rather than solve the underlying task.

Public benchmarks deserve additional caution. OpenAI reported contamination and flawed tests in SWE-bench Verified, then estimated in July 2026 that roughly 30% of SWE-Bench Pro tasks were broken. Use public scores as directional evidence, and let audited private tasks decide workflow fit.

Measure more than pass rate: relevant files retrieved, missed dependencies, unnecessary prompt tokens, regression rate, diff quality, review effort, latency, and cost.

FAQ

What files should not be loaded by default?

Avoid loading generated output, vendored dependencies, build artifacts, duplicated fixtures, archived migrations, large binary-derived text, and broad logs unless the task requires them. Keep security-sensitive material and unrelated customer data outside model context. Use repository rules and graph filters to identify authoritative sources.

How should teams measure context quality?

Measure whether the supplied context contains the minimum sufficient evidence for the task. Track relevant-file precision and recall, missed dependencies, unsupported assumptions, duplicated tokens, time to first correct plan, regression rate, and human corrections. Maximum token count is a capacity metric, not a quality metric.

Can long context and graphs work together?

Yes. Query the graph to identify relevant entities and dependency paths, retrieve the underlying source and tests, then let the long-context model reason over that evidence and its tool trajectory. Refresh the graph after accepted changes and periodically audit it against the repository.

Conclusion

GLM-5.2’s one-million-token context is a real, officially documented capability that can support long coding trajectories and broad evidence sets. A code knowledge graph solves a different problem: making repository relationships explicit, queryable, and reusable.

Choose the combination based on measured repository outcomes. Use the graph to select and organize evidence, use GLM-5.2 to reason over the active task, and use tests plus review to establish correctness. Raw tokens and structured knowledge are strongest when each handles the job it was designed for.

July 16, 2026

GPT-5.6 Sol and Codebase Understanding: What the Model Still Needs

GPT-5.6 Sol is an officially available frontier model with a 1.05-million-token context window and strong vendor-reported coding-agent results. Switching to it may improve planning, persistence, tool use, and implementation. It still does not arrive knowing a private repository’s architecture, dependency rules, ownership, deployment constraints, or design history.

A model change can raise the ceiling of a coding workflow. Reliable repository understanding still depends on the evidence and verification system surrounding the model.

Why Users Switch Models for Codebase Tasks

Developers usually switch coding models after encountering a repeated workflow failure: the agent loses track of a long task, misses a related file, produces a plausible but incomplete refactor, consumes too many tokens, or needs too much steering.

GPT-5.6 Sol is relevant because OpenAI positions it as the flagship tier of the GPT-5.6 family. The official API page lists gpt-5.6-sol as the model ID, with the gpt-5.6 alias routing to Sol. It supports a 1,050,000-token context window and up to 128,000 output tokens.

OpenAI announced general availability on July 9, 2026 across ChatGPT, Codex, and the API, with plan and workspace eligibility differences. Developers should verify that their account, Codex version, model selection, and reasoning setting match the intended trial.

Those specifications make a switch attractive for:

long-running implementation and debugging;
multi-file changes with substantial source evidence;
tool-heavy workflows that search, edit, build, and test;
tasks where a larger working context delays compaction;
teams seeking a different capability, latency, or cost profile.

The switch should begin with a hypothesis, such as “Sol reduces missed cross-module dependencies in our migration tasks,” rather than the vague expectation that a stronger model will understand the repository automatically.

Keep the previous model as a control during that trial. Run identical repository tasks from clean sessions, provide the same tools and evidence, and compare navigation errors, dependency omissions, verification behavior, latency, and total cost—not just whether the final patch appears plausible.

What a Better Model Can Improve

OpenAI describes GPT-5.6 Sol as its best coding model at launch and reports results on coding-agent evaluations that include real codebases, terminal workflows, and long-horizon engineering.

In OpenAI’s launch table, Sol scores 64.6% on SWE-Bench Pro, 72.7% on DeepSWE v1.1, and 88.8% on Terminal-Bench 2.1. OpenAI also reports 91.9% for Sol Ultra on Terminal-Bench 2.1. These are vendor-reported results and belong to the stated model settings and evaluation harnesses; they are evidence of intended capability, not guarantees for a private repository.

In practice, a better coding model may improve:

decomposition of a broad request into testable steps;
persistence across long tool trajectories;
selection and coordination of terminal tools;
interpretation of test failures;
consistency across related edits;
review of its own patch before handoff.

The large context window can retain more source, documentation, tool output, and intermediate decisions. Programmatic tool coordination can also reduce the need to pass every intermediate result through the model unchanged.

However, OpenAI’s own long-context results show why capacity is not perfect retrieval. Its launch page reports 73.8% on an eight-needle MRCR evaluation spanning 512K to 1M tokens and 77.1 F1 on GraphWalks BFS at one million tokens. Those are not repository benchmarks, but they demonstrate that accepting a long input does not imply flawless use of everything inside it.

What It Still Does Not Know About Your Repo

GPT-5.6 Sol does not know private facts that are absent from its prompt, tools, or repository. It also cannot reliably infer every convention from code alone.

Important missing knowledge may include:

which team owns a shared API;
which package boundary is intentional;
which generated files are overwritten by CI;
which downstream service consumes an event;
which feature flag controls a production path;
why an earlier implementation was rejected;
which migration order avoids a compatibility break;
which tests are known to be incomplete.

A repository can contain contradictory signals. A stale README may disagree with current code. A test can encode legacy behavior. A comment can describe an abandoned plan. A broad context dump gives the model all three without identifying authority.

The model also sees only the repository and external systems it is permitted to inspect. Cross-repository consumers, production configuration, private runbooks, and unwritten operational knowledge remain outside its view unless the workflow exposes them.

This is why Claude Code repository context and Codex context engineering should focus on evidence organization, not only model selection.

Structured Knowledge vs Raw Prompt Context

Raw prompt context is task-local working memory. Structured repository knowledge is reusable navigation and policy.

A robust workflow can separate the layers:

Knowledge layer	Example	Update pattern
Task context	issue, plan, inspected code, test output	every run
Repository map	modules, entry points, build and test commands	on structural change
Code graph	callers, dependencies, schemas, tests, owners	indexed after accepted changes
Architecture record	boundaries, decisions, rejected alternatives	human-reviewed
Verification	hidden tests, regression suite, CI, review	every change

The model should use structured knowledge to locate relevant evidence, then inspect the current source. A graph edge that says service A consumes schema B is useful for impact analysis, but the source and runtime configuration should verify the relationship.

This design protects repository memory from model churn. Teams can replace GPT-5.6 Sol with another model without rewriting the architecture map or losing indexed dependency relationships. Conversely, the model’s large context remains valuable for reasoning over the selected code and current trajectory.

Structured context can also reduce prompt waste. Instead of loading an entire monorepo, the agent can query the affected entities, follow dependency paths, and retrieve a task-specific evidence set.

Verification and Risk Notes

Evaluate GPT-5.6 Sol on private tasks that represent the repository and risk level. Public coding benchmarks are useful for orientation, but their task quality and contamination must be considered.

OpenAI stopped recommending SWE-bench Verified for frontier comparisons after finding flawed tests and contamination. In July 2026, OpenAI also estimated that roughly 30% of SWE-Bench Pro tasks were broken. The responsible conclusion is not that benchmarks have no value. It is that teams need auditable task design and more than one measurement.

For a model trial:

freeze the repository commit and execution environment;
select localized, cross-module, refactor, CI, and impact-analysis tasks;
hide acceptance and regression tests from the agent;
keep model, reasoning, tool, network, timeout, and permission settings constant;
run multiple independent trials;
retain trajectories, patches, test output, latency, tokens, and cost;
review missed dependencies, unnecessary edits, policy violations, and grader gaming.

Compare the new model with the current default using the same harness. A higher pass rate can still hide larger diffs, more review work, or unacceptable regressions. Conversely, a model that solves fewer benchmark-like tasks may be better on your architecture-specific workload.

Require dependency review for changes that cross packages or services, modify public contracts, alter persistence or security behavior, introduce dependencies, or depend on relationships not enforced by tests.

FAQ

What repo knowledge should survive model changes?

Keep architecture maps, ownership, public contracts, build and test commands, dependency relationships, decision records, generated-file rules, operational constraints, and known test gaps outside model-specific prompts. Version them with the repository or a governed knowledge system.

How should teams test a new coding model?

Run the current and candidate models against the same frozen private tasks with identical permissions and tools. Repeat trials and compare correctness, regressions, dependency coverage, diff size, human steering, review time, latency, tokens, and total cost.

When should outputs require dependency review?

Require it when an edit changes a shared type, API, event, schema, package boundary, deployment order, security control, or external integration. Also require it when the agent cannot produce evidence for every identified downstream consumer.

Conclusion

GPT-5.6 Sol can materially improve a coding-agent workflow. Its official context size, tool support, and vendor-reported results justify testing it on demanding codebase tasks.

The model is still one layer of repository understanding. Preserve architecture and dependency knowledge outside the prompt, retrieve current source for each task, and verify every consequential change with tests and review. Switch models when the measured end-to-end workflow improves—not when the model name or context number changes.

July 16, 2026

pxpipe and the Code Context Problem: Cheap Tokens Are Not Understanding
pxpipe makes an important point about AI coding cost: the same bulky context can sometimes be carried more cheaply as images than as text. That can help long agent sessions, but it does not tell the agent which repository facts matter or how modules depend on one another. Context efficiency and repository understanding are related operational problems, not the same capability.

The practical goal is not to maximize the amount of code placed in a context window. It is to supply the smallest trustworthy evidence set that supports the task, preserve exact details, and verify the resulting change.

Why pxpipe Became Interesting

The independent teamchong/pxpipe project intercepts supported model requests and renders selected large text blocks as dense PNG images. Its current documentation focuses on Claude Code, where Anthropic officially allows requests to be routed through a proxy using ANTHROPIC_BASE_URL.

The idea is attractive because model input is not priced only by human-visible information. Text and images use different tokenization paths. A dense tool result or old conversation history may occupy fewer visual tokens after rendering, provided the target model can read the page well enough.

pxpipe defaults to Claude Fable 5. Anthropic confirms that Fable 5 supports vision and is available in Claude Code. The pxpipe project reports that Fable reads its dense render profile more reliably than other models it tested. This is project evidence, not an Anthropic endorsement of pxpipe.

The project also publishes measurements instead of presenting compression as free. Its own SWE-bench Lite pilot reports 10 of 10 tasks completed in both arms and 65% smaller measured requests with compression. Its larger Pro sample reports 14 of 19 resolved with pxpipe and 15 of 19 without it. Those small, maintainer-run results support a pilot hypothesis: request size can fall without an obvious collapse in task completion. They do not establish universal parity or better coding performance.

pxpipe also documents the uncomfortable part. Image context is lossy. Dense prose and broad state may survive while a hexadecimal value, identifier, or name is silently reconstructed incorrectly. That honesty makes the project useful as a case study in context engineering, even for teams that never deploy it.

The Cost Problem in Code Context

Coding agents consume context through more than source files. System instructions, tool schemas, repository rules, file reads, command output, test failures, diffs, plans, and old conversation turns all occupy the working request.

Long tasks create several kinds of waste:
- the client resends stable instructions and tool definitions;
- the agent reopens files it inspected earlier;
- command output contains repeated or irrelevant lines;
- old history stays available after its exact wording stops mattering;
- broad repository reads include generated, vendored, or unrelated code;
- failed trajectories remain in the transcript.
Compression can reduce the footprint of some of this material. It cannot decide whether the material should have been loaded in the first place.

That distinction affects cost measurement. A project can report fewer transmitted tokens while the agent takes more turns, rereads exact data, or requires more human review. Prompt caching can also change the economics. Anthropic’s token-count documentation says counts are estimates and that Fable 5 uses a newer tokenizer than older Claude generations. Teams should measure the same current workload under the exact model and client instead of applying a headline percentage.

The cost unit that matters is accepted work, not a compressed request. A useful trial tracks total provider cost, latency, successful tests, review time, corrections, re-fetches, and recovery from failures.

Why Cheap Context Is Not the Same as Understanding

Repository understanding requires selection and relationships. A model needs to know not only that a file contains a matching string, but also whether that file owns the behavior, which callers depend on it, which tests represent the contract, and which design rule constrains the change.

Consider a shared type used by an API, a queue consumer, generated clients, and analytics. A compressed dump of all matching files may be cheaper than raw text. It still does not label the authoritative schema, identify runtime consumers, or explain why one field cannot change.

More context can even make reasoning harder. Generated code, fixtures, duplicated implementations, stale documents, and vendor directories compete with the relevant interface. A one-million-token window is capacity, not prioritization.

The same boundary applies to memory. Fable 5 supports compaction and a memory tool in supported harnesses, but those features do not automatically create a durable model of a repository. A conversation summary is not a dependency graph. An old tool result rendered as an image is not a maintained architecture record.

For exact work, cheap but lossy context can create hidden cost. The pxpipe project reports that dense identifiers can be misread without an error signal. A plausible wrong path or hash is more dangerous than an explicit “not found” because the agent may act on it. Keep code to be edited, commands, IDs, versions, numerical limits, and acceptance criteria in text or re-read them from the source.

Where Code Knowledge Graphs Help

A code knowledge graph addresses selection by modeling entities and relationships before the model consumes task-specific evidence. Graphify can provide a reusable map across source code and project documents.

The graph can answer questions that compression does not:
- Which modules import or call this symbol?
- Which tests and documents connect to this subsystem?
- What path links the requested feature to storage?
- Which entities belong to the same architectural community?
- Which relationships were extracted directly and which were inferred?
That map lets the agent open a smaller set of authoritative files. Compression may then be unnecessary for short tasks or useful only later, after test logs and history accumulate.

Graphs are not perfect understanding either. Static analysis can miss reflection, runtime wiring, feature flags, external repositories, and generated behavior. Documents can be stale. Inferred edges can be wrong. Graph results should include provenance and point back to source evidence.

The durable workflow is layered:
1. Query project structure.
2. Open the authoritative source and current documentation.
3. Keep exact constraints as text.
4. Compress only older or bulky gist-level material.
5. Verify the patch with tests, diff review, and architecture ownership.
The Graphify knowledge-graph guide explains the structural layer. The broader pxpipe vs Graphify comparison owns the product-selection decision once that page is live.

Practical Limits to Verify

Start with lifecycle. pxpipe’s npm package and default branch were still changing in mid-July 2026, but its maintainer said they could not promise responses or reviews for all issues and pull requests. Pin the tested version and keep a bypass path.

Then test model compatibility. pxpipe’s built-in default is Fable 5; other models are opt-in because the project reports weaker dense-image results. A model update can change image reading, token accounting, safeguards, or request behavior.

Review privacy and trust boundaries. A local proxy still forwards requests upstream. The project has open reports concerning failed-request body logging, relocated system material, safeguard refusals, and inherited proxy environment variables affecting child processes. Treat these as issues to reproduce against the installed version, not as proof that every deployment fails.

Finally, separate measured and inferred value. Record:
- original versus transformed request tokens;
- cached and uncached input;
- total session cost and turns;
- exact-string mistakes;
- re-read and rehydration calls;
- tests passed and hidden regressions;
- human review minutes;
- proxy errors and safeguard refusals;
- repository files loaded before and after structured retrieval.
This evidence shows whether compression reduces total work and whether a graph reduces unnecessary discovery.

FAQ

What context should be compressed first?

Start with large, repeated, token-dense material whose exact wording no longer matters: old narrative history, verbose logs, completed tool output, or repeated documentation. Do not start with source code about to be edited, commands, secrets, hashes, paths, versions, numerical constraints, or acceptance tests.

When does compression hide useful structure?

Compression hides structure when files and relationships are flattened into pages without labels for ownership, calls, imports, tests, or provenance. It also creates risk when visually similar characters matter. Use search or a code graph to select evidence, and preserve exact source links for verification.

How should teams compare cost savings?

Run repeated tasks from the same repository commit with the same model, client, permissions, prompt, and tests. Compare total cost per accepted task, not one request. Include latency, turns, re-fetches, failures, review time, and regressions. Label project-published benchmark numbers as project evidence.

Conclusion

pxpipe is interesting because it turns context cost into a measurable engineering problem. Its project evidence suggests that Fable 5 can read enough dense imaged context to reduce request size on some Claude Code workloads, while the documented exact-string failures prevent treating the representation as lossless.

The larger lesson is that cheap context is not repository understanding. Use structured project knowledge to identify what matters, native text for exact evidence, compression for suitable bulk, and tests plus human review for acceptance. Optimize the whole task, not only the number printed beside one request.
July 16, 2026

pxpipe vs Graphify for AI Agents: Compression or Code Knowledge?

pxpipe and Graphify solve different parts of the AI coding context problem. pxpipe reduces the token footprint of bulky context already being sent to a model by rendering selected text as images. Graphify builds reusable structural knowledge about a repository. Choose by the bottleneck: request cost and repeated history favor pxpipe; dependency paths and project understanding favor Graphify; some teams can use both.

The comparison is not a contest between two interchangeable indexes. pxpipe is an independent proxy with a lossy representation. Graphify is a project knowledge layer. Neither removes the need to inspect source code, run tests, and review architecture-sensitive changes.

Quick Verdict

Use pxpipe when your agent repeatedly sends large, token-dense material and the older material can tolerate gist-level recall. Use Graphify when the agent needs to ask structural questions such as which modules depend on an interface, which tests cover a path, or how code and design documents connect.

Decision factor	pxpipe	Graphify
Primary job	Reduce the request footprint of bulky context	Preserve reusable repository structure
Representation	Dense PNG pages plus selected text anchors	Entities, relationships, paths, communities, and provenance
Works on	Context the client already sends	Code, documentation, and project artifacts that are indexed
Exactness	Imaged text is lossy; exact values need text or re-reading	Graph results still require source verification
Strong fit	Old history, repeated tool output, dense logs	Navigation, impact analysis, dependency and ownership questions
Main risk	Silent visual misread, proxy compatibility, logging	Stale or incomplete relationships and overtrusted inference

The safest design uses each layer for its actual job. A graph can help select relevant evidence. A compression proxy can reduce the cost of carrying bulky, gist-tolerant evidence through a long session. Exact edit targets, commands, identifiers, and acceptance criteria should remain connected to their original source.

What pxpipe Tries to Solve

The canonical teamchong/pxpipe repository describes pxpipe as a local proxy that transforms selected large input blocks into PNG images before forwarding a request. It can image system and tool documentation, large tool results, and older history while leaving recent turns and ineligible material as text. It compresses the request, not the model response.

Claude Code officially supports the ANTHROPIC_BASE_URL environment variable for routing requests through a proxy or gateway. pxpipe uses that transport path, but it is not an Anthropic product or official Claude Code integration.

The project defaults to Claude Fable 5 because its maintainers report better dense-image reading from Fable than from the other models they evaluated. Anthropic independently confirms that Fable 5 supports vision and is available in Claude Code. That establishes technical compatibility, not independent validation of pxpipe’s quality or savings.

The project reports substantial reductions on its own traffic and small paired tests. Its SWE-bench Lite pilot reports 10 of 10 tasks resolved in both compressed and uncompressed arms, with 65% smaller measured requests in the compressed arm. Its SWE-bench Pro expansion reports 14 of 19 tasks resolved with compression and 15 of 19 without it, with 18 of 19 verdicts agreeing. These are maintainer-run, workload-specific results. They do not prove universal savings, repository superiority, or statistical equivalence.

The important limitation is lossiness. pxpipe reports that broad gist survives more reliably than exact strings. Dense identifiers can be silently misread, so hashes, paths, version numbers, secrets, commands, code to be edited, and numerical constraints should stay as text or be re-read from the repository.

What Graphify Tries to Solve

Graphify addresses a different question: how can an agent reuse project knowledge instead of reconstructing the repository’s structure from scratch during every task?

A code knowledge graph represents entities such as files, symbols, modules, APIs, tests, documents, and concepts. Relationships can express imports, calls, ownership, containment, test coverage, or cross-document references. The graph becomes a query layer for finding a relevant neighborhood before the model opens the underlying source.

This matters because repository understanding is not proportional to the amount of text in a prompt. An agent may read ten files and still miss a dynamic consumer, a generated contract, or the design decision that explains an unusual boundary. Structured relationships help the agent form better navigation questions:

What calls this service?
Which tests exercise this interface?
Which module owns the shared type?
Which documents explain this dependency?
What paths connect the requested feature to persistence or deployment?

Graphify does not make those answers infallible. Static extraction can miss reflection, runtime configuration, external consumers, and generated behavior. Inferred relationships can be wrong. A stale graph can point to an obsolete path. The graph should narrow and organize source inspection, not replace it.

For the underlying model, see Graphify’s guide to knowledge graphs for AI coding assistants. For Claude-specific use, the Graphify and Claude Code integration guide explains how the saved project report fits into an agent workflow.

Compression vs Structured Code Knowledge

Compression asks, “How can this material occupy fewer model tokens?” Structured code knowledge asks, “Which project facts and relationships should the agent retrieve?”

Those questions lead to different failure modes.

With compression, the relevant information may be present but visually misread. The model can recover the broad meaning of a tool log while corrupting a hash or variable name. The mitigation is to classify information by exactness: keep precision-critical fields as text and provide a source re-fetch path.

With a graph, the relationship may be missing, stale, or inferred incorrectly. The agent may receive a clean structural answer that omits a runtime edge. The mitigation is provenance, refresh rules, source links, and verification through search, tests, and runtime evidence.

They also operate at different times. Graphify can prepare reusable project context before a session and update it as the repository changes. pxpipe transforms eligible material on the live request path. A graph can reduce unnecessary file reading; pxpipe can reduce the footprint of the remaining bulky context.

This suggests a layered workflow:

Query the graph for relevant entities and paths.
Open the authoritative source files and current documentation.
Keep exact edit targets and constraints as native text.
Compress only older, dense material where gist is sufficient.
Run tests and inspect the final diff against the original repository.

When Each Approach Fits

Choose pxpipe for a pilot when long Claude Code sessions repeatedly resend large logs, tool output, or old conversation history. The workload should have measurable input cost, a clear source of truth, and low dependence on exact recall from compressed material.

Choose Graphify when developers repeatedly spend time locating owners, dependencies, tests, and cross-file paths. It is especially relevant when multiple agents or models need the same repository map, because the structural layer can remain model-independent.

Use both when project discovery and context cost are separate bottlenecks. For example, Graphify can identify the modules, tests, and design notes involved in a migration. The agent can read those sources directly. pxpipe can then compress older tool output or historical discussion as the session grows.

Avoid either tool as a default without a controlled trial. For pxpipe, record exact package and model versions, request logs, safeguard refusals, incorrect identifiers, re-read calls, cost, and task outcomes. For Graphify, record graph freshness, missing or incorrect edges, retrieval usefulness, source-opening behavior, review time, and regressions.

Lifecycle also matters. pxpipe’s package and code were changing in mid-July 2026, but its maintainer stated that issue and pull-request response capacity was limited. A graph layer introduces its own maintenance work: refresh triggers, extraction coverage, provenance, and ownership. The easier system is the one whose failure mode your team can observe and correct.

FAQ

Can compression and graphs be used together?

Yes. Use the graph to select relevant project knowledge, then use compression only for bulky material that does not require byte-exact recall. Keep code, paths, IDs, commands, secrets, version strings, and acceptance criteria in native text or retrieve them again before acting.

What evidence should teams collect before switching?

Freeze the repository commit, task, client, model, permissions, and tests. Compare repeated runs with and without the new layer. Record request tokens, cost, latency, task success, incorrect facts, source re-reads, review effort, graph misses, proxy failures, and recovery time. A lower bill is not useful if review or rework rises.

Which approach is easier to maintain over time?

It depends on the operating risk. pxpipe requires version, model, proxy, privacy, and visual-fidelity checks. Graphify requires graph refresh, extraction coverage, provenance, and stale-edge controls. A small team with mostly dense session history may prefer the narrower proxy. A team with recurring repository-navigation problems may gain more from maintained structural knowledge.

Conclusion

The useful answer to pxpipe vs Graphify is not a winner. pxpipe is a request-path optimization for carrying bulky context more cheaply, with an explicit lossiness trade-off. Graphify is a reusable structural layer for asking better repository questions, with freshness and coverage trade-offs.

Start from the bottleneck. If the agent already has the right evidence but resends too much of it, test pxpipe. If the agent repeatedly reads files without building a dependable map of dependencies and intent, test Graphify. If both problems exist, combine selective retrieval, cautious compression, source verification, and tests rather than asking one tool to solve every context problem.

July 16, 2026

Context Engineering for OpenCode
OpenCode context engineering means deliberately controlling what the agent knows, when it loads that knowledge, and which evidence it must verify. Use AGENTS.md for stable rules, instruction files for modular policy, @file for current evidence, skills for procedures, and a maintained graph or MCP tool for repository relationships.

The resulting workflow is easier to audit because each context layer has a named owner, refresh rule, and authority boundary instead of becoming an undocumented accumulation of prompt text.

What Context Engineering Means for OpenCode

Context engineering is not the same as writing a longer prompt. It is the design of the information system around the coding agent.

OpenCode's official documentation exposes several distinct context mechanisms:
- project and global AGENTS.md files;
- /init for generating or improving project guidance;
- opencode.json instruction paths, globs, and remote URLs;
- @file references that add selected files to the conversation;
- on-demand Agent Skills;
- local and remote MCP tools;
- specialized primary agents and subagents;
- automatic session compaction;
- cloud and local model providers, including Ollama and custom OpenAI-compatible endpoints.
Each mechanism has a different job. Problems arise when teams use one mechanism for everything—for example, pasting a repository inventory into AGENTS.md, enabling every MCP server globally, or assuming compaction creates durable project memory.

A useful context design answers five questions:
1. What stable rules should always apply?
2. What current files prove the task's facts?
3. What procedures should load only when relevant?
4. What repository relationships need a query layer?
5. What information must survive a session, model, or agent change?
OpenCode can orchestrate these layers, but its official documentation does not claim a built-in code knowledge graph or durable cross-session semantic repository memory. Those require maintained external artifacts or tools.

What OpenCode Agents Need From a Repo

OpenCode agents need concise rules, trustworthy evidence, and explicit authority boundaries.

The project-root AGENTS.md should contain stable information that future sessions are likely to need: build and test commands, architecture that is not obvious from filenames, project conventions, setup quirks, and operational warnings. OpenCode's /init command scans important files and can create or improve this guidance. Treat the generated result as a draft to review, not an infallible architecture model.

Current task evidence should come from current files and commands. OpenCode's TUI supports @file references: selecting a file adds its contents to the conversation. This is useful when the operator knows the likely source. It is less useful when the problem is discovering which file matters.

Skills package reusable procedures. OpenCode discovers SKILL.md definitions from .opencode/skills, .claude/skills, and .agents/skills at project and global scopes. A migration skill can define review steps and verification commands without loading that procedure into every conversation.

Agents also need permission boundaries. OpenCode distinguishes a Build agent with broad tools from restricted planning and read-only exploration roles. For a repository-wide change, start with a read-only exploration or planning pass, require a dependency explanation, and only then allow edits.

Finally, define source authority. A practical order is:
1. current source, schema, and tests;
2. approved architecture decisions and operational policy;
3. generated repository reports and graphs;
4. temporary task notes and model inference.
This order prevents a stale summary from overruling the code it was meant to describe.

For team use, record which layer supported each important planning claim. That small provenance trail makes review faster and exposes when an agent is relying on a remembered convention instead of current repository evidence.

Organize Architecture and Dependency Context

Keep architecture context modular and load it by need.

OpenCode's instructions configuration can include files and glob patterns such as CONTRIBUTING.md, architecture guidelines, testing standards, or package-specific AGENTS.md files. It can also load remote instruction URLs. Remote rules should be pinned or governed because their contents can change outside the repository review process.

A strong repository layout might use:
```
AGENTS.md
docs/
  architecture/
    index.md
    request-flow.md
    data-boundaries.md
  decisions/
    001-auth-ownership.md
  operations/
    migrations.md
    rollback.md
.opencode/
  skills/
    api-change/
      SKILL.md
```
The root rules file tells OpenCode where to look. Architecture files explain system intent. Decision records preserve rationale. Skills describe task workflows. Current code confirms whether the documents still match reality.

Dependency context should support questions rather than only diagrams. For every repository-wide plan, require the agent to report:
- entry point;
- downstream dependency path;
- data or schema boundary;
- generated artifacts;
- tests and verification commands;
- uncertain or stale evidence.
That report gives a human reviewer something concrete to approve.

Avoid loading every document at startup. OpenCode's own rules documentation recommends modular instruction patterns, and its MCP documentation warns that tool descriptions can consume enough context to exceed the model limit. Context should be available, not permanently resident.

Use Graphs for Planning and Impact Analysis

A code graph adds a queryable relationship layer when file references and static documents are not enough.

Useful graph entities include packages, files, symbols, routes, schemas, tests, and architecture documents. Relationships can capture imports, calls, generation, coverage, ownership, and rationale. OpenCode can query the graph before selecting source files for detailed inspection.

Graph-guided planning narrows the search, while source verification and approval control the change.

Graphify supports this pattern through generated graph artifacts, CLI queries, and MCP. Its CLI reference documents graphify opencode install, which writes project guidance to AGENTS.md, along with query, path, explain, update, watch, and MCP commands.

An OpenCode planning procedure can be:
1. Query the graph for the requested entity or behavior.
2. Trace direct and cross-package relationships.
3. Identify the source files and tests behind each important edge.
4. Open those current files.
5. Flag stale, inferred, or ambiguous graph evidence.
6. Ask for approval before repository-wide edits.
7. Run focused tests, then broader verification.
This workflow improves impact analysis without claiming that the graph replaces source inspection.

MCP is one integration option. OpenCode supports local and remote MCP servers, but its documentation notes that each server adds tool information to context. Enable only the graph tools needed for the active agent or workflow. A large global tool catalog can erase the context savings the graph was meant to create.

The graph also supports model independence. An OpenCode workflow using a local Ornith model through Ollama can query the same repository structure as a cloud-model workflow. Model changes then affect reasoning and tool performance without forcing the team to rebuild project knowledge from scratch.

Limits and Maintenance Risks

The main context-engineering risks are staleness, overexposure, and false authority.

Staleness: Review AGENTS.md when commands, architecture, or workflow constraints change. Refresh graphs after structural merges. Put a source commit and generation time on generated artifacts.

Overexposure: Do not load secrets, customer data, production credentials, or unrelated private documents. Scope MCP tools and agent permissions to the task.

Instruction drift: Remote instruction URLs and globally installed skills can change outside a project pull request. Pin sources where possible and audit updates.

Context inflation: More MCP servers, tool output, and instructions can reduce the room available for the task. OpenCode supports automatic compaction and optional pruning, but compaction is context management, not durable memory.

Local-model assumptions: OpenCode supports Ollama and custom OpenAI-compatible providers. That establishes configuration compatibility, not reliable coding performance. Test tool calling, patch quality, refusal behavior, latency, and context use on your own repository.

Unreviewed authority: A graph edge or generated summary can be wrong. Require provenance and direct-source confirmation before an edit. Assign a human approver for repository-wide changes, especially those involving security, schemas, dependencies, or deployment.

FAQ

What context should be shared across tasks?

Share stable commands, repository conventions, architecture decisions, ownership boundaries, generated-file rules, and a maintained structural map. Keep transient logs, speculative hypotheses, and task-specific file dumps inside the task unless they produce an approved decision.

Who should approve repository-wide changes?

Use the owner of the affected architectural boundary, not only the person operating OpenCode. Security, data, API, and deployment changes may require separate reviewers. The approval should cover the dependency path and verification plan as well as the diff.

How can teams avoid stale context?

Tie reviews and graph refreshes to repository events: package moves, schema migrations, route changes, dependency updates, generated-code changes, and revised architecture decisions. Record the source revision and refuse to trust context older than the paths being changed.

Conclusion

OpenCode provides the pieces for disciplined context engineering, but teams must assign each piece a clear role.

Use AGENTS.md for stable rules, modular instructions for policy, @file for exact evidence, skills for repeatable procedures, MCP for carefully scoped tools, and a maintained graph for dependency and impact questions. Use compaction to manage session pressure, not as a substitute for repository memory.

The decision rule is simple: if context cannot show its source, freshness, and authority, OpenCode should treat it as a lead to verify—not a fact to edit against.
July 16, 2026

Help Claude Code Understand a Complex Repo

To help Claude Code understand a codebase, organize context into four layers: concise project rules, maintained architecture documents, task-specific source evidence, and a refreshable dependency or code-graph layer. Do not solve the problem by loading the entire repository into every prompt.

This structure also makes failures diagnosable: reviewers can tell whether a bad change came from an incorrect rule, stale architecture record, incomplete source selection, or unsupported inference.

Why Claude Code Struggles With Complex Repos

Claude Code can search files, run commands, edit code, and use project instructions. A complex repository still creates an information-selection problem.

The relevant implementation may be spread across packages, generated clients, schemas, build configuration, tests, and architecture decisions. File names rarely express all of those relationships. An agent can therefore perform each local step competently while starting from the wrong system model.

Typical failure modes include:

editing a generated file instead of its source;
changing a public interface without finding downstream consumers;
reading a stale design document as current authority;
running the broad test suite while missing the focused contract test;
treating two similarly named packages as interchangeable;
repeating repository discovery after context compaction or in a new session.

The problem is not that Claude needs every file. It needs the smallest authoritative set of facts for the current decision.

Claude Code's official documentation separates persistent project memory from on-demand skills. CLAUDE.md and related rules are suitable for stable guidance that should influence work throughout a repository. Skills package procedures that load when relevant. Current code and command output remain task evidence. Keeping these roles separate reduces both context noise and stale instructions.

Before improving context, measure the failure. Give Claude a repository question that crosses at least three modules and ask it to explain the execution path without editing. Record which files it opens, how many searches it runs, whether it finds the correct tests, and where its explanation becomes uncertain. That baseline will show whether the missing layer is rules, documentation, retrieval, or model capability.

Prepare Project Rules and AGENTS.md

Start with the instruction file Claude Code actually reads.

For Claude Code, the canonical project file is CLAUDE.md. Some teams also maintain AGENTS.md because it is shared across other coding agents. If both are used, avoid maintaining two conflicting copies. Keep one source of truth and generate, link, or explicitly reference the other according to the clients in your workflow.

Project rules should contain stable, high-value constraints:

build, lint, and focused test commands;
package-manager and workspace conventions;
generated or vendored paths that must not be edited;
required approval points;
branch, migration, and rollback rules;
the location of architecture and operational documentation;
the expected verification order for common changes.

Do not turn the rules file into a repository encyclopedia. A long instruction file consumes context on every relevant turn and becomes hard to maintain. Prefer directives that help Claude retrieve evidence:

Before changing a public API:
- Identify all direct consumers.
- Check generated clients and schema sources.
- Read the relevant ADR in docs/architecture/.
- Run the contract test before the full suite.

That rule is more durable than a pasted list of today's consumers.

Assign ownership. A platform or developer-experience team can maintain global workflow rules, while package owners review local constraints. Add a review date or source link for statements that can become stale. Remove obsolete instructions instead of appending exceptions indefinitely.

Add Architecture and Dependency Context

Architecture context should explain boundaries the code alone does not make obvious.

A useful repository context set includes:

a current system overview;
package or service responsibilities;
request and data-flow diagrams;
schemas and generated-code paths;
architecture decision records;
ownership and escalation boundaries;
deployment and rollback paths.

Each document needs authority metadata. State its owner, source revision, and whether it is descriptive or normative. A stale diagram with no date can mislead an agent more effectively than an absent diagram because it appears deliberate.

Use links and progressive disclosure. The root CLAUDE.md can point Claude toward the relevant architecture index. Package-local instructions or skills can describe when a deeper document is needed. The agent should not load every ADR for a small test fix.

Dependency context must also be testable. If a diagram says that package A calls service B, the source graph, imports, API schema, or deployment config should provide confirming evidence. Ask Claude to cite those current files in its plan.

A practical pre-edit report has five fields:

Field	Required answer
Entry point	Where does the behavior begin?
Dependency path	Which modules or services carry it?
Source of truth	Which file or schema owns the change?
Validation path	Which tests and commands prove it?
Uncertainty	What remains inferred or stale?

This makes repository understanding reviewable before code changes increase the cost of being wrong.

Use Code Knowledge Graphs for Navigation

A code knowledge graph helps when repository relationships are too numerous or indirect for a static overview.

The graph can represent files, symbols, packages, tests, schemas, and documents as nodes. Typed edges can capture calls, imports, ownership, generation, coverage, and rationale. Claude can query that structure to choose a narrow set of source files, then verify them directly.

The graph guides navigation; current source and tests remain the approval evidence.

Graphify provides this kind of query layer. Its Claude Code integration guide documents a CLAUDE.md directive and a pre-tool-use hook that tells Claude to consult a generated repository report before broad file searches. Its CLI reference includes query, path, explain, update, and watch commands.

Use a graph for questions such as:

What connects this route to the database policy?
Which packages depend on this shared type?
Which tests cover the affected symbol?
Which architecture document explains this boundary?
What changed structurally since the graph was built?

Do not treat graph output as self-authenticating. Record the source commit, generation time, extraction method, and inferred relationships. If the graph is older than the code under review, refresh it or fall back to direct inspection.

The graph is particularly useful across agents. A maintained structural artifact can provide Claude Code, Codex CLI, OpenCode, and other clients with a shared starting map even when their instruction systems differ.

Risks and Maintenance Notes

Repository context creates a new maintenance surface.

The first risk is staleness. Review project rules when commands, package boundaries, CI, or deployment behavior changes. Refresh structural graphs after merges that alter imports, routes, schemas, generated code, or architecture documents. Archive superseded decisions rather than leaving contradictory files in the main context path.

The second risk is instruction injection. Treat repository instructions, downloaded skills, remote references, and generated artifacts as code-review inputs. Do not let an unreviewed file silently grant broader command, network, or secret access.

The third risk is authority confusion. A comment, graph edge, ADR, and current type definition do not have equal weight. Define the precedence: current source and tests usually control implementation facts; approved architecture decisions control intended boundaries; generated summaries guide discovery.

The fourth risk is excessive context. More instructions can make the agent follow rules less consistently. Keep global rules short, load procedures as skills, and retrieve architecture on demand.

Finally, require human review for repository-wide changes. The reviewer should inspect the dependency path, generated artifacts, migration impact, permissions, and rollback plan—not only the final diff.

FAQ

Who should maintain repository context docs?

Assign owners by layer. Platform or developer-experience teams can own shared commands and workflow rules. Architecture owners maintain system decisions and diagrams. Package teams maintain local constraints. Every document should have a review trigger and a clear source of truth.

What should stay out of agent instructions?

Keep out secrets, customer data, large copied source trees, temporary incident details, volatile dependency inventories, and conflicting historical rules. Put current facts in source-backed documents or generated artifacts and load them only when relevant.

How often should context files be reviewed?

Review them when the facts they describe change. Trigger reviews after build-system changes, package moves, schema migrations, generated-code changes, deployment updates, and revised architecture decisions. A scheduled quarterly check can catch neglect, but event-driven review is the primary control.

Conclusion

Helping Claude Code understand a complex repository is a context-design problem, not a prompt-length contest.

Put stable constraints in concise project rules. Maintain architecture documents that explain intent. Require current source and tests for task evidence. Add a code graph when dependency and rationale paths exceed what static documentation can express.

The decision rule is simple: if Claude repeatedly searches the same files yet still chooses the wrong system path, improve the repository map and its maintenance policy before changing the model.

July 16, 2026

Skill Zoo and Code Knowledge Skills

No authoritative single product, repository, or standard named “Skill Zoo” was verified for this article. Here, the phrase describes the growing ecosystem of Agent Skills libraries: reusable SKILL.md packages for Claude Code and other coding assistants. That ecosystem improves capability reuse, but it does not automatically give an agent current knowledge of a complex repository.

What Skill Zoo Changes for Coding Assistants

The skill-library phenomenon changes how teams package instructions for coding agents.

Anthropic's official Claude Code documentation defines a skill as a folder with a SKILL.md entry point. A skill can include instructions, scripts, references, templates, and examples. Claude discovers the skill through its name and description, then loads its full instructions only when the task calls for them. This progressive-disclosure model avoids placing every procedure in permanent context.

That is a meaningful improvement over repeatedly pasting the same checklist into chat. A team can encode:

how to prepare a release;
how to review an API change;
how to run a repository's application;
how to validate migrations;
how to follow an internal writing or security workflow.

Claude Code supports skills at personal, project, enterprise, and plugin scopes. Anthropic also publishes a public skills repository with examples. Its README includes an important limitation: the examples are educational and demonstrative, and the behavior available in Claude may differ. Some materials use different licenses, so “public repository” must not be read as “every file is open source and production-approved.”

OpenCode implements the same broad SKILL.md pattern and discovers skills from OpenCode, Claude-compatible, and Agent Skills-compatible directories. The Agent Skills standard describes this portability as a lightweight open format. Portability, however, does not guarantee identical behavior. Clients can interpret permissions, extra frontmatter, tools, and execution differently.

So the useful meaning of “Skill Zoo” is not one verified marketplace. It is a large and expanding collection of reusable agent procedures that teams must still evaluate, version, and govern.

Skills vs Project Understanding

A skill and a project model answer different questions.

Layer	Main question	Typical contents
Skill	How should the agent perform this type of work?	Steps, quality gates, tools, templates, examples
Project rules	What stable constraints apply here?	Commands, conventions, generated-file rules, approvals
Repository knowledge	What entities and relationships exist now?	Symbols, imports, dependencies, tests, schemas, docs
Task evidence	What changed in this run?	Current diff, logs, failing tests, tool output

A code-review skill can tell Claude to check authentication boundaries and run focused tests. It does not know which module owns authentication in the current repository unless that knowledge is supplied or discovered. A release skill can define the workflow but cannot know the current dependency graph from a static instruction file.

This is why “more skills” should not be confused with “better repo understanding.” Skills improve procedural consistency. Repository understanding requires current, source-backed evidence.

The boundary also protects skill quality. If a team copies a fast-changing directory inventory, symbol list, or dependency map into SKILL.md, the package becomes stale quickly. A better skill instructs the agent how to retrieve current facts: inspect the source, consult generated architecture artifacts, query a graph, and record the commit it used.

Why Complex Repos Need Code Knowledge Skills

Complex repositories need skills that connect procedure to live project structure.

A generic debugging skill might say: reproduce the failure, narrow the scope, inspect recent changes, form a hypothesis, and run the smallest confirming test. A code knowledge skill can make those steps repository-aware by requiring the agent to:

identify the owning package and public entry point;
trace dependencies before editing;
find the tests that cover the affected path;
check generated or vendored boundaries;
locate architecture decisions connected to the code;
report the evidence behind its proposed change.

The skill still does not need to contain the graph. It can call or reference the system that maintains it.

The strongest pattern keeps the workflow portable while deriving repository facts from a refreshable source.

This separation helps monorepos in particular. Claude Code can discover nested project skills, allowing one package to define specialized procedures. Yet package-local instructions still benefit from a shared view of cross-package relationships. Otherwise, an agent may follow the frontend workflow correctly while missing that the proposed change alters a generated client or backend contract.

Versioning matters too. Project skills should live beside the code when they describe repository-specific procedures. Review skill changes like code changes: inspect the diff, test the workflow in a fresh session, and record which tools and permissions it needs. Avoid automatically trusting a downloaded skill merely because it appears in a popular collection.

How Graphify Fits as a Project Memory Layer

Graphify can complement Agent Skills by supplying a queryable project-memory layer.

Graphify turns repository materials into graph artifacts that represent entities and relationships. Its knowledge graph guide explains why typed structure can answer questions that a flat file list cannot. Its CLI supports queries, paths, explanations, updates, and watch workflows.

A project skill can then define a safe retrieval procedure:

Before planning a repository-wide change:
1. Query the graph for the affected entity.
2. Trace dependency paths and linked tests.
3. Open the current source files named by the result.
4. Report stale or ambiguous graph evidence.
5. Do not edit until current source confirms the path.

This design has three advantages.

First, the skill stays compact. It contains the method, not an ever-growing copy of the repository.

Second, multiple agents can share the same project map. Claude Code, OpenCode, Codex, or another compatible assistant can follow equivalent retrieval rules even when their skill features differ.

Third, provenance remains visible. The graph can carry source locations and generation metadata, while the skill requires the agent to verify current code before acting.

Graphify already hosts a code graph for addyosmani/agent-skills, a public repository that packages engineering workflows for coding agents. That example illustrates the two layers directly: the repository contains reusable skills, while Graphify maps the repository's own implementation structure.

Limits and Integration Questions

Skills expand an agent's operating instructions, so teams should treat them as executable supply-chain inputs.

Review the complete skill folder before trusting it. Supporting scripts can run commands, reference external resources, or request broad tool permissions. Check licenses per repository and file; do not assume every example in a mixed collection has the same terms.

Keep sensitive data out of the package. A project skill may describe how to access secrets safely, but it should not contain credentials, customer records, production tokens, or copied private conversations.

Plan for client differences. Claude Code documents invocation controls, subagent execution, dynamic context, and Claude-specific frontmatter. OpenCode recognizes a smaller defined frontmatter set and ignores unknown fields. A cross-client skill should use the common core or document client-specific behavior explicitly.

Finally, decide what happens when knowledge is stale. A skill should not force the agent to trust a graph or generated report blindly. Require a source revision, a refresh threshold, and a fallback to direct inspection.

FAQ

Which skills should be project-specific?

Make a skill project-specific when it depends on that repository's commands, architecture, deployment path, review gates, or generated artifacts. Keep broadly reusable practices personal or shared at the organization level, then layer project rules on top.

How should teams version code knowledge skills?

Store project skills in version control, review their changes, and test them in fresh sessions. Pin external dependencies where possible. Record the expected tools, permissions, and generated knowledge artifacts so a skill update cannot silently broaden its authority.

What should not be stored inside a skill?

Do not store secrets, private customer data, unrestricted transcripts, volatile symbol inventories, or large copied source trees. Store procedures and stable rules. Retrieve current repository facts from source-backed files, generated reports, or a maintained code graph.

Conclusion

The Skill Zoo idea is useful as a description of today's expanding Agent Skills ecosystem, not as an unverified product claim. Skills make coding workflows reusable, discoverable, and easier to audit. They answer how an agent should work.

They do not automatically answer what the current repository means. For complex projects, pair procedural skills with refreshable source evidence and a queryable structural layer. The decision rule is straightforward: put stable methods in the skill; keep changing project facts close to the code.

July 16, 2026

Blog

What the OpenAI Codex Team Revealed

Why Codex Uses 10-Bullet Product Specs

How PMs and Designers Use Codex to Explore Ideas

Why OpenAI Plans for Eight Weeks—or the Distant Future

How Parallel Agents Led to the Codex App

Why Power Users Shape the Product Roadmap

Inside the Codex Team's “Pirate Ship” Operating Model

Codex as a Developer-Platform Entry Point

Is AI Eliminating the Product Manager Role?

What Other Product Teams Can—and Cannot—Copy

A Practical AI-First Product Development Playbook

Conclusion

Primary Sources

Frequently Asked Questions

Does the entire Codex product have one 10-bullet spec?

Does the Codex team have no product managers?

Did GPT-5.2-Codex create the Codex app idea?

Can any company replace its roadmap with eight-week plans?

What is the most transferable lesson from the OpenAI Codex team?

Quick Verdict

What Repository Tasks Need

Model Capability vs Context Infrastructure

Multi-File Refactoring Scenarios

Limits and Claims to Verify

FAQ

What benchmark would reflect repo analysis?

How should teams compare long-running agents?

When should a graph layer be model-independent?

Conclusion

Why Large Codebases Stress Coding Models

What a Larger Context Window Can Help With

What Context Windows Still Miss

Where Code Knowledge Graphs Fit

What to Verify Before Relying on Sonnet 5

FAQ

What repo docs should be prepared first?

How should teams test large-repo behavior?

When should model output require architecture review?

Conclusion

Quick Verdict

What a 1M Context Window Can Help With

Why Raw Context Still Lacks Structure

Code Knowledge Graphs as a Query Layer

What to Verify About GLM-5.2

FAQ

What files should not be loaded by default?

How should teams measure context quality?

Can long context and graphs work together?

Conclusion

Why Users Switch Models for Codebase Tasks

What a Better Model Can Improve

What It Still Does Not Know About Your Repo

Structured Knowledge vs Raw Prompt Context

Verification and Risk Notes

FAQ

What repo knowledge should survive model changes?

How should teams test a new coding model?

When should outputs require dependency review?

Conclusion

Why pxpipe Became Interesting

The Cost Problem in Code Context

Why Cheap Context Is Not the Same as Understanding

Where Code Knowledge Graphs Help

Practical Limits to Verify

FAQ

What context should be compressed first?

When does compression hide useful structure?

How should teams compare cost savings?

Conclusion

Quick Verdict

What pxpipe Tries to Solve

What Graphify Tries to Solve

Compression vs Structured Code Knowledge

When Each Approach Fits

FAQ

Can compression and graphs be used together?

What evidence should teams collect before switching?

Which approach is easier to maintain over time?

Conclusion