Connecting Claude Code to an existing project

Running Claude Code in a project you did not write differs from starting from scratch. The agent does not know the team's conventions, the module layout, or which directories are better left untouched. Below is a sequence for the first run in an existing codebase.

What the agent reads at startup

When launched at the repository root, Claude Code orients itself by the directory contents: folder structure, config files, dependencies. It does not load the whole project into context at once — files are pulled in as needed, when they relate to the current task.

That makes the wording of the first request matter. A vague "figure out this project" sends the agent wandering through the tree. A precise request — "find where authorization is handled and describe the flow" — narrows the scope and saves tokens.

Before the first run, check that the repository has an up-to-date .gitignore. The agent respects its boundaries and will not read what is excluded.

How to limit the scope of work

In a large monorepo there is no reason for the agent to see everything. There are a few ways to narrow it down.

• Launch Claude Code from a subdirectory rather than the root — that subdirectory becomes the working area.
• Name paths explicitly in the request: "work only inside packages/api".
• Ask for a plan first, then changes. The plan can be read and rejected before the agent touches any files.

For the first sessions it is reasonable to keep the agent in a mode where it asks for confirmation before writing. That way it is easier to notice if it is about to edit the wrong module.

The project instructions file

A dedicated instructions file is a way to hand the agent what usually lives in the team's heads: naming conventions, a ban on editing generated code, the command to run tests, the commit style.

The agent reads this file at the start of work and keeps its directions in context. That is more reliable than repeating requirements in every request. One short file at the root removes most of the recurring clarifications.

Keep the contents concrete: not "write good code", but "after changes run npm test, do not touch files in dist/".

Connecting through Zukko

Claude Code takes the gateway address and key from environment variables. Use ANTHROPIC_AUTH_TOKEN, not ANTHROPIC_API_KEY: with ANTHROPIC_API_KEY the client will require signing in to an Anthropic account.

export ANTHROPIC_BASE_URL=https://api.zukko.pro
export ANTHROPIC_AUTH_TOKEN=fetch_...

The base URL is given without the /v1 suffix — the client adds the path itself.

The model is chosen by task and budget. Reference prices per million tokens (input/output):

The model set changes; the current list is GET https://api.zukko.pro/v1/models or the Models page in the dashboard. Note that GLM has a 128K context and no vision; the others have 1M.

For comparison: the official Anthropic price for Claude Opus 5.5 is $4 input and $20 output per million tokens. One caveat: vendors charge ~10% of the input price for prompt-cache reads, while Zukko bills cached tokens at the regular price, so for an agent with a large context the real gap is smaller than a straight comparison suggests.

A first run in someone else's project is better started with a narrow task and a confirmation mode — that way the boundaries become visible before anything changes. Connecting Claude Code through Zukko uses the same variables; access questions go to support at https://t.me/zukkopro?direct↗