Acceptable Use Policy

Effective: 2026-08-10 Last updated: 2026-08-10

What this covers

megaloop, and everything you reach through it: the inference endpoint, the dashboard, the management API, and the MCP server.

"You" is the account holder. "We" is AI PWRD Inc., a Delaware corporation, which operates megaloop. "Provider" is whoever actually runs the model — the service whose subscription you linked.

The rule the rest of this follows from

megaloop runs inference on capacity you already pay for. We hold no inference credits of our own and we never resell inference. Every request that leaves megaloop leaves on a credential you linked, against a subscription in your name.

That is the whole product, and it is why the rules below look the way they do. Almost every prohibition here is a version of one sentence: the accounts in your pool must be yours, and what you do with them must be something you are entitled to do.

What you must not do

1. Link an account you do not own

Only link a provider account that you own or are authorised by its owner to use.

Not allowed: an account borrowed from a friend, an employer's account you were not given for this, an account bought or rented from someone, a credential found or scraped, an account created to get around a limit on another account.

This is the most serious rule on the page, because a linked credential is worth real money to whoever owns it and can be revoked by the provider if it is used in a way they object to. When you link an account you are putting someone's subscription at risk. If it is not yours to risk, do not link it.

2. Resell or share access

Your API key authenticates your pool. Do not sell, rent, sublicense, or resell access to it, and do not hand it to people outside your own control.

Allowed: your own tools, your own agents, your own machines, your own applications — including an application you build for other people, as long as the inference runs on your subscriptions and you are responsible for the traffic.

Not allowed: turning your pool into a service other people buy inference from; distributing your key; running a shared "free API" on top of it; pooling accounts contributed by strangers.

3. Break your agreement with your provider

You have a contract with each provider whose account you linked. That contract is between you and them. megaloop does not evaluate it, does not represent that pooling is permitted by any given provider, and cannot indemnify you if it is not. Read your provider's terms and satisfy yourself that what you are doing is allowed.

Specifically, do not use megaloop to:

• work around a rate limit, quota, or usage cap in a way your provider's terms forbid;
• misrepresent whose account or subscription a request is made on, or make requests appear to come from a person other than you;
• evade a suspension, ban, or restriction a provider placed on you or on an account.

That middle rule used to be broader, and it was narrowed. It read "misrepresent who is making a request", which forbade you from doing something megaloop itself does on every request — it sets a client identity on your traffic, and the notes below say exactly what. A rule the product breaks on your behalf is not a rule, so it now covers only what it was ever meant to cover: whose request it is. Do not pass your traffic off as another person's or another account holder's.

We narrowed the rule rather than writing an exception for each thing megaloop sets. An exception list would have to be kept in step with the code and would quietly go stale the first time the forward path changed; narrowing states the one thing actually prohibited and leaves the client identity to the disclosure below, which is written from the code and must be re-checked against it in any commit that changes the forward path. Narrowing the rule is not a statement that your provider permits what megaloop sets — see the paragraph after the notes.

Five honest notes about what megaloop does to your request, because this rule asks you not to misrepresent whose request it is and you are entitled to know what the software does on your behalf before you agree to it:

• It sets a session identifier on every request, replacing yours if you sent one. The identifier is derived from your tenant and account, so it identifies that account consistently. It is not there to hide anything and it never makes traffic look like it came from a different account — but it is an override, not a fill-in. (The matching identifier in the request body is a fill-in: if your client already put a user id there, megaloop leaves the body alone.)
• When your client does not present a recognised SDK platform block, megaloop supplies one — platform headers, a direct-access flag, and a CLI user-agent if you sent none — so the request has the shape the provider's API expects from a first-party client. When your client does present its own block, megaloop touches neither it nor your user-agent — on the Anthropic path. On the Codex path your user-agent is replaced whatever you sent; that is the note after next. This is a real thing the product does to your traffic, on your own account, and it is disclosed rather than buried.
• On the Anthropic path, megaloop prepends a fixed line to your system prompt. One sentence — You are Claude Code, Anthropic's official CLI for Claude. — is put at the top of the system field of your request body, and your own system prompt is kept and follows it, unchanged and in full. Nothing you wrote is deleted, edited, reordered, or relocated into the message list; if your system is a block array, your blocks and their cache settings are kept behind one new block. If your client already sends that line first, nothing is added and your bytes go out as they arrived; if you sent no system field at all, megaloop creates one holding just that sentence. It is there because the upstream refuses premium-model requests (sonnet, opus) on a subscription credential whose system prompt does not begin with that exact line (packages/providers/src/anthropic/body-marker.ts).
• On the Codex path, megaloop replaces your client's identity with the Codex CLI's, on every request. Your user-agent, originator and version headers are dropped and megaloop's are set instead — originator codex_cli_rs, and a matching codex_cli_rs/<version> user-agent — whether or not you sent any of them. This one is a replacement, not a fill-in: there is no case in which your own user-agent reaches that provider. The backend gates which models an account may reach on the client version reported this way (packages/providers/src/codex/forward.ts).
• It removes forwarding and proxy-hop headers before forwarding, because the provider APIs expect a direct client. That is request fidelity, not anonymity. Do not rely on any of the above to disguise the origin of anything, and do not treat it as megaloop's assurance that your provider permits what you are doing — see the paragraph above.

Assume your provider treats the last two of those as outside what it permits. Both exist because the upstream checks for a first-party client and refuses or downgrades a request that is not one, and both are megaloop making your request look like one. We are not telling you it is allowed. Rule 3 is the rule it sits under: megaloop does not evaluate your agreement with your provider, does not represent that any of this is permitted, and cannot indemnify you if it is not. The account it lands on is yours, and so is the consequence. If that is not a risk you want to take on a given subscription, do not link it.

4. Send content that is illegal or that harms people

Do not use megaloop to generate, process, or distribute:

• content that is illegal where you are or where we operate — Delaware, United States;
• child sexual abuse material, in any form, ever;
• content intended to harass, threaten, defraud, or impersonate a specific person;
• malware, exploit code intended for use against systems you do not own, or credential-stuffing and phishing material;
• content whose purpose is to cause serious physical harm.

Your provider's own usage policy applies to this content too, and it reaches them, not us — see "What we can and cannot see" below.

5. Attack the service

Do not attempt to:

• read, write, or influence another tenant's data, keys, credentials, or usage;
• extract another tenant's provider credentials, or our encryption key;
• exploit, probe for, or disclose a vulnerability in a way that puts other users' linked accounts at risk;
• take the service down, degrade it for others, or evade its authentication;
• scrape, enumerate, or brute-force the sign-in flow.

Good-faith security research is welcome. Tell us first at support@megaloop.dev and give us a chance to fix it. Do not test against another tenant's data, ever — test against your own.

6. Automate abusively

Do not send traffic whose purpose is something other than getting an answer: load generated to exhaust the service, retry storms, requests engineered to make megaloop the expensive part, or using the endpoint as an open proxy for third parties.

Parallelism itself is not abuse — it is the product. Running ten agents at once against your own pool is exactly what megaloop is for, and if our own queues or limits bite before your subscription's do, that is our bug, not your violation.

What we do not restrict

Said explicitly, because a policy that only lists prohibitions reads as broader than it is:

• how many requests you make in parallel, within what your own subscriptions will serve;
• which models you call, or which client you call them from;
• what you build with the output;
• how many accounts you link, subject to your plan.

What we can and cannot see

This matters for enforcement, so it belongs here rather than only in the privacy disclosure.

We do not store your prompts or the responses. They are not written to the database and not written to a log. What megaloop keeps per request is one row of metadata about the request, never its content. The Privacy Policy (/privacy) lists every column of that row, and it is the authoritative list; this page does not repeat it, because a shorter version of it here would be read as the whole one. See /trust for the same list with the source file to check each claim against.

The consequence is that we cannot police content, and we do not. We have no way to know what you sent. Your provider does — your prompts reach them on your account, and their usage policy and their retention apply there. If a provider acts on your content, they act against your subscription, and megaloop cannot appeal it for you.

What we can see is the shape of traffic and the state of accounts: volume, error rates, how many tokens a provider reported for a request, which accounts are pausing, and whether a provider has started refusing.

What happens if you break these rules

Be aware of how small this operation is. There is no automated abuse detection. Enforcement starts with a human noticing, and every action below is taken by hand.

The measures that actually exist today:

There is no partial "suspended" state on an account — no flag in the database that half-disables one — and no automatic escalation ladder. Revoking the key is the only enforcement measure with an interface; the other two are an operator at a database prompt. That is stated so this page does not read as if a control panel exists behind it.

A pause is also not a lock we hold against you: the management API has a resume route, so an account we pause is one you can put straight back in rotation yourself. It is there because the gateway pauses accounts of its own accord when a provider blocks them, and until that route existed an account taken out by a transient block stayed out for good. Revoking a key is a stop rather than a lock for the same reason — you can mint another from the dashboard. Sustained enforcement is therefore closing the account, and the measures above are how we stop something quickly.

Normally we will contact you first, at the address you sign in with, and give you a chance to explain or fix it. We will tell you what we saw.

Suspension without notice

We may revoke your key or pause a linked account immediately, with no warning, if we believe your use is putting other users' linked accounts at risk — or your own.

This is not boilerplate. A user's linked subscription is worth roughly what they pay for it every month and a provider can revoke it over a pattern of traffic they object to. If something you are doing looks likely to make a provider act against accounts — yours or, through a shared signal, somebody else's — we will stop it first and discuss it afterwards. We will tell you what we did and why, at your sign-in address, as soon as we have done it.

The same applies to anything that threatens the confidentiality of stored credentials, and to anything that endangers the service's availability for other users.

Ending your account

You can stop using megaloop at any time. Unlink your accounts and revoke your keys from the dashboard.

There is no self-serve delete-everything button today. To have your account and its data deleted, ask us at support@megaloop.dev and a human runs it, within 30 days of your request. Two things you should know before you do:

• Unlinking removes our copy of a credential. It does not revoke the access grant at your provider. For an account linked by browser approval, megaloop stays authorised on your provider account until you revoke it there yourself, in their connected-apps settings. Do that too.
• Metadata rows for requests an account already served outlive the account, on purpose, so the history of what ran stays readable. They go when the account is deleted.

We may also close your account, with notice where it is safe to give notice, if you break this policy.

Reporting abuse

If you believe someone is using megaloop against this policy, tell us at support@megaloop.dev. If it involves stolen credentials or a compromised account, say so — that gets handled first. That is the same address as support and security reports: there is one mailbox, and one person reads it.

Changes

We will update this policy as the product changes, and the change will be dated. If a change meaningfully narrows what you are allowed to do, we will tell you at your sign-in address before it takes effect. The current dates are at the top of this policy.