Can You Send Private Source Code Through an AI API Gateway?

You can consider an AI API gateway for private code when your organization permits the processing involved and the chosen route meets its requirements. A promise that the gateway does not save prompts answers only part of that decision. You also need to understand the model service receiving the request, any connected tools, and the records left by your coding client.

Start with a specific question: Which parts of this repository can I send, to whom, and under which conditions? That is more useful than deciding whether a gateway is “private” in the abstract.

Follow the code beyond your terminal

A client running on your laptop can still send repository material to a remote model. Claude Code's data-usage documentation explicitly describes network transmission of prompts and outputs. It also describes local session transcripts. The location of the executable does not settle where the conversation is processed or stored.

Before connecting a private repository, write down the path your intended task uses:

Part of the workflow	What to identify	Question to resolve
Coding client	Files, conversation context, and tool results included in requests	Can you limit the material selected for this task, and where is local history saved?
API gateway	The service receiving and forwarding the request	What content and metadata does it retain, and for how long?
Upstream inference service	The service actually fulfilling the model request	Which terms apply to this route, account, endpoint, and feature?
Connected tools	Any search, MCP server, remote execution, or other external service you enable	Which tool arguments or results leave the approved processing path?
Troubleshooting and sharing	Logs, exported sessions, screenshots, or support attachments you choose to send	Does that material contain code or credentials that the recipient does not need?

Use this as a worksheet for your own configuration. It is not a claim that every client sends all files or uses every service listed.

Model names alone are insufficient for this map. For example, OpenRouter's provider-logging documentation distinguishes the handling policies of its upstream providers and notes that external server tools and plugins have their own policies. Check the actual path rather than carrying one provider's promise across the whole workflow.

Separate training, retention, and processing location

These questions need separate answers:

• Training: Can submitted content be used to improve models, and under what opt-in or contractual conditions?
• Retention: Which content or records remain after the request, where, and for how long?
• Processing location: Where can each service process or store the relevant data?

OpenAI's API data-controls documentation illustrates why the first two differ. It says API data is not used for training unless the customer opts in, while separately describing abuse-monitoring logs and application state. Its default abuse-monitoring retention is up to 30 days, with stated exceptions. Approved retention controls and endpoint-specific limitations also matter.

That is an example of OpenAI's direct API policy, not a description of every gateway selling access to an OpenAI model. A gateway route needs its own applicable terms and upstream confirmation.

Likewise, a setting such as store: false is not a universal deletion instruction. Where supported, its meaning belongs to the documented API feature. It cannot establish what a separate gateway, a local transcript, or an external tool stores.

Ask about processing location explicitly if your project requires it. A company's registered address and the location where your code is processed are different facts.

What Tokenhot's published policy says

Tokenhot's Privacy Agreement, updated October 12, 2026 and checked October 28, states that its gateway does not persist request or response bodies for standard synchronous API calls, including error-body content. It also says API inputs and outputs are not sold or used to train its own models.

The scope matters. The policy separately allows operational records such as request identifiers, model names, token counts, charges, status, and error codes. It does not specify one fixed deletion period for every record.

Browser tools and uploads are separate: Playground history can remain locally, and an expiring upload link does not itself delete the stored file. Upstream retention, caching, and training practices depend on the service and feature fulfilling the request.

These are published policy commitments, not an independent storage audit or confirmation of the terms for your particular upstream route. If your code has contractual retention or processing-location restrictions, contact Tokenhot Support with the model and intended feature before submitting it.

Start with the smallest useful code sample

Permissions and terms establish whether you may use a service. Reducing the material you send helps you keep the request within that approved scope.

For a hypothetical example, suppose an invoice parser mishandles a date. You may be able to explain the problem with the parsing function, a synthetic invoice record, and the expected output. The model does not necessarily need a production invoice, a database export, or the repository's deployment credentials.

Prepare that smaller reproduction before starting an agent session:

1. Identify the function and behavior you want help with.
2. Replace customer records and internal identifiers with synthetic values that preserve the bug.
3. Remove active credentials and unrelated confidential material from the sample.
4. Check what file-reading and external-tool access the client will have during this task. Use its documented controls to restrict that access where appropriate.
5. Keep troubleshooting material equally small. Share a redacted reproduction and request reference rather than an entire transcript when those are sufficient.

Do not assume a file is excluded from model context merely because it is excluded from Git. Check the coding client's actual access and context controls. A clean sample also stops helping if the agent can subsequently read unrelated files and include them in a tool result.

The point is not to remove the context needed to solve the problem. It is to choose that context deliberately.

Get confirmation for the route you will actually use

A useful question to the provider names the workload and the requirement:

We plan to use this model and endpoint from our coding client for private source-code tasks. Please confirm which upstream service handles the request, the retention and training terms that apply, any relevant storage by optional features, and whether our required processing locations and deletion conditions are supported. Please distinguish request bodies from operational and billing records.

Add the specific restriction your organization requires. “We need EU-only processing” or “Our agreement prohibits retaining submitted source code” gives the provider something concrete to assess. Do not treat either requirement as satisfied until you have the applicable confirmation.

A successful test request can show that a selected configuration works for that request. It cannot demonstrate that remote copies were deleted or that every possible fallback follows the same terms. Confirm permitted fallback routes too, if your configuration uses them.

Once the data-handling decision is settled, use the OpenAI-compatible API migration guide to check the technical behavior your client needs. Keep that functional check separate from approval to send private code. If a required handling condition remains unanswered, use a non-sensitive sample while you resolve it.