CC Switch Knowledge Graph Workflow

A reliable CC Switch knowledge graph workflow uses two separate layers: CC Switch selects and connects the provider; an external, revision-bound graph supplies repository relationships. The first layer answers “which model can this agent call?” The second answers “which files, symbols, contracts, tests, and owners are relevant to this task?”

Keeping those responsibilities separate makes Claude, Kimi, Codex, and other providers replaceable without pretending that session reasoning or repository understanding moves between them automatically.

The Two-Layer Workflow

The workflow starts with a hard boundary between access state and evidence state.

Layer	Owned data	Refresh trigger	Primary failure
CC Switch access layer	Provider profiles, active route, protocol format, selected model, MCP and Skills configuration	Provider, credential, model, or routing change	Requests reach the wrong endpoint or use an incompatible protocol
Repository evidence layer	Revision, files, symbols, dependencies, schemas, tests, owners, architecture records, provenance	Source or documentation change	The agent receives stale, incomplete, or unsupported relationships
Task packet	Goal, non-goals, selected graph results, assumptions, approvals, verification plan	Each task or handoff	A provider receives too much context or misses a critical constraint

Run the layers as a sequence:

1. Pin the repository revision and define the task boundary.
2. Query the graph for the smallest useful evidence set.
3. Inspect current source behind high-impact relationships.
4. Select the provider and verify the CC Switch route.
5. Start a new agent session with the reviewed task packet.
6. Edit only after the agent restates scope and unresolved assumptions.
7. Run tests, review the diff, and refresh graph artifacts when structure changed.

This is a model-independent workflow because the durable artifact is not a provider transcript. It is a source-linked evidence packet that another provider can reconstruct and challenge.

CC Switch for Model Access

CC Switch is a third-party provider and configuration manager. Its current repository describes profiles for multiple coding tools, one-click switching, provider presets, synchronized MCP and Skills configuration, session management, and a local proxy with format conversion.

Provider access is not always a direct endpoint substitution. The CC Switch Kimi guide says newer Codex clients use the Responses API while Kimi endpoints can expose Chat Completions. Its local route converts requests and responses between those formats. The Claude routing guide describes a similar bridge between Codex Responses and Anthropic Messages. In both cases, the provider card, local routing service, app-level routing toggle, and restarted Codex process must agree.

A preflight should therefore record:

• the coding client and active CC Switch provider;
• model identifier and provider-specific model mapping;
• direct versus local-route connection;
• upstream protocol and any conversion step;
• credential location and allowed disclosure;
• MCP and Skills enabled for the target client;
• whether the client must restart to reload configuration.

Do not infer model equivalence from a successful route. Protocol conversion can make request shapes interoperable, but it does not make tool behavior, context limits, reasoning, output quality, or provider policies identical.

Security also belongs at this layer. The v3.18.0 release says current diagnostic logging uses redaction and rotation, but it explicitly warns that logs written by earlier versions are not retroactively cleaned. The routing guides keep real provider keys in CC Switch configuration while the local route injects them during forwarding. Teams must still review provider terms, retention, network path, local file permissions, and the exact repository evidence being disclosed.

Knowledge Graphs for System Relationships

The graph layer represents revision-bound system structure. Useful node types include repositories, packages, files, symbols, endpoints, schemas, migrations, tests, owners, and decision records. Useful relationships include imports, calls, implements, generates, validates, owns, and explains.

Each result needs provenance. At minimum, return:

• repository and commit;
• source and target entities;
• relationship type;
• file and location supporting the edge;
• extractor or query version;
• deterministic versus inferred status;
• freshness time and known coverage gaps.

This turns a graph result into inspectable evidence. “Service A depends on schema B” is not enough. “At commit X, symbol A imports generated type B at this path; these contract tests reference the same type” gives the next agent a route to verification.

The graph must not be presented as a native CC Switch feature. CC Switch’s own scope covers provider, configuration, routing, MCP, Skills, and sessions. The graph is an external context layer, optionally reached through an MCP tool or another project workflow. The CC Switch codebase-context guide explains why that boundary matters after a provider change.

Query Context Before Running the Agent

Querying first prevents a new model from spending its opening turns on broad repository scans. It also prevents the opposite failure: pasting an entire repository index into the prompt and burying the task.

Use a task-shaped query:

Task: change the public invoice status transition
Revision: <commit>
Return:
- defining schema and implementation symbols
- direct and two-hop callers
- generated clients or artifacts
- contract, integration, and migration tests
- owners and relevant decision records
- inferred or missing relationships
Limit: paths connected to the invoice transition

Then reduce the result to a handoff with four blocks:

1. Scope: goal, non-goals, revision, allowed paths, acceptance criteria.
2. Evidence: relevant nodes and paths with source locations.
3. Uncertainty: inferred edges, dynamic registration, external consumers, missing generated artifacts.
4. Verification: focused tests, broader required suites, owners, and approval gates.

The agent should inspect source behind every high-impact edge before changing code. Dynamic imports, reflection, runtime configuration, generated output, and consumers outside the indexed repository can defeat a static graph. Treat a graph as a navigation and impact-analysis aid, not as a substitute for source, tests, or review.

Keep Providers Replaceable

A provider is replaceable only when durable knowledge does not depend on its private transcript or proprietary state. Put repository policy in version-controlled instructions, architecture decisions in maintained records, graph evidence in reproducible artifacts, and task conclusions in a reviewed handoff.

Use these controls:

• Stable schema: keep task packets provider-neutral and avoid vendor-specific reasoning fields.
• Explicit adapters: isolate provider endpoints, protocol conversion, model mappings, and tool quirks.
• Least disclosure: query only facts required for the task and filter sensitive paths before retrieval.
• Provenance: attach revision and source locations to every important relationship.
• Freshness gates: reject or rebuild graph results when their revision cannot be reconciled with the worktree.
• Independent verification: make the destination model reopen source and rerun tests.
• Human ownership: require the responsible team to approve policy, security, and high-impact architectural changes.
• Transfer record: document what was provided, omitted, inferred, and disproved.

Avoid using unified history as the portability mechanism. CC Switch’s unified Codex history guide says it normalizes the model_provider tag so sessions share a list. It also says cross-provider resume may fail when encrypted reasoning can only be decrypted by the original backend. A fresh task packet is more portable and easier to audit than an old session whose assumptions may be stale.

FAQ

What should the graph expose to each provider?

Expose only task-relevant entities, relationships, source locations, revision metadata, test paths, and approved decision records. Omit secrets, raw production data, unrelated proprietary modules, private user information, credentials, and full historical transcripts. Give the provider enough evidence to verify the task, not a default copy of the entire repository graph.

How should sensitive repo facts be filtered?

Classify graph nodes and fields during ingestion, then enforce provider- and task-specific retrieval policies before results enter the prompt. Redact secrets rather than merely hiding labels, preserve an audit log of returned entity IDs, and require approval for protected areas. Also review local CC Switch logs and configuration backups before sharing them; current redaction does not retroactively sanitize older files.

When should teams rebuild the graph?

Rebuild when source, generated artifacts, schemas, dependency manifests, ownership, or relevant architecture documents change. Also rebuild when the task worktree cannot be matched to the graph’s commit, an extractor changes, coverage expands, or verification reveals a missing relationship. For large repositories, incremental refresh is acceptable only when the artifact still records one coherent revision and coverage boundary.

Conclusion

The CC Switch knowledge graph workflow is reliable because it does not ask one tool to own two different problems. CC Switch owns provider access, configuration, and protocol routing. A separate graph owns revision-bound repository relationships with provenance and freshness.

Query that graph before launching the selected agent, reduce results to a task packet, and verify important edges in current source. With those controls, teams can replace Claude, Kimi, Codex, or another provider without claiming that private reasoning or repository comprehension transferred automatically.