One agent setup across three repositories

You have a website in one repository, an API in another, and a small background worker in a third. Each needs occasional changes. You would like to open a terminal in any of them and use a coding agent without repeating the same setup every time.

A useful starting point is to separate the settings you carry between projects from the information that belongs to each project. Your provider connection and personal preferences can usually stay with your user account on the computer. Build commands, project conventions, and deployment details belong with the repository.

Start with one working connection. Choose the coding tool you want to use, such as Claude Code, Codex, or Gemini CLI. Configure its provider connection using the tool’s supported settings, then try a small task in a single repository. Asking it to explain a function is enough to check that requests reach the model.

Vana API can supply that connection through https://api.vanaapi.com. It provides an OpenAI-compatible endpoint and also supports Anthropic Messages and Gemini native protocols. That makes it usable with these coding tools and applications built with an OpenAI SDK. The exact configuration fields depend on the client, so follow the instructions for your chosen tool.

Keep the API key in the tool’s supported credential storage or an environment variable. Avoid putting it in a tracked project file. If you work on another computer, configure credentials there separately. Sharing a repository should never require sharing your personal key.

Give each repository a small instruction file. A coding agent needs a few facts before it can work safely: what the project does, how to run it, and how to check a change. Put those facts in the repository instruction file your tool recognizes. Names and discovery rules vary between tools; check which files your client reads automatically.

Start with a short list:

• The command that installs dependencies.
• The command that starts the application locally.
• The test and formatting commands.
• The folders that contain the main application code.
• Any generated files that should be updated through a command.

Keep personal preferences, such as asking for concise explanations, in user-level instructions if the tool supports them. Keep project facts beside the code, where other contributors can review and maintain them. This also reduces conflicting copies of the same guidance.

Make the active repository explicit. Open the agent from the repository you intend to change and state the task in concrete terms. For example: “In the API repository, add the delivery status field and run the relevant tests.” Before accepting edits, check which directory the agent is using and review its proposed scope.

When a task crosses repositories, explain the relationship. A website may depend on a response field supplied by the API. Ask the agent to inspect both sides before changing either, and make sure its workspace permissions allow the necessary access. A shared provider connection does not automatically give an agent access to every repository or knowledge of previous sessions.

For your first few tasks, finish and review one repository’s changes before moving to the next. If you later work on several tasks at once, separate checkouts or Git worktrees can keep their edits apart. Each task should still have a clear directory, branch, and set of checks.

Review each repository on its own terms. Read the diff, run the relevant checks, and confirm that related changes agree. Passing API tests does not establish that the website handles the new response correctly. Tell the agent which checks matter, and ask it to report anything it could not run.

Vana API bills usage per real token with no monthly fee, so you can use the same service connection as you move between projects. Create a Vana API account when you are ready to connect your chosen tool. Begin with one repository, then carry the working connection to the others while adding their own project instructions.