Private beta terms of use

1. What GunTech Cloud is, and what it is not

GunTech Cloud is a small, founder-operated gateway that sits between an application and Anthropic's Messages API. It issues project-scoped credentials, enforces a per-key request-per-minute rule and an approximate monthly token ceiling, forwards validated requests to the model, and records request-level usage metadata without storing prompt bodies in that usage ledger. Access is by manual invitation during a private beta.

It is equally important to be precise about what this is not:

• Not a model provider. GunTech Cloud does not train, host, serve, fine-tune or own a model. Every completion comes from Anthropic's service.
• Not an official Anthropic service. GunTech Cloud is an independent product. It is not affiliated with, endorsed by, sponsored by, certified by or operated by Anthropic, and it is not part of the Anthropic startup program or any Anthropic partner programme by virtue of existing. The names Anthropic and Claude are used here only to identify the upstream service. Anthropic's own terms govern that service and your use of it.
• Not a billing, payment or reseller service. No tokens are sold, resold, brokered or priced here. There is no checkout, no invoice and no subscription. Anthropic's charges are separate and, in the current architecture, are borne by the operator's own Anthropic account.
• Not a guarantee of availability. The beta carries no service level agreement, no uptime commitment, no maintenance window and no support-hours commitment. No availability figure is published or promised. See section 8.
• Not a compliance or certification product. No certification, audit report, regulatory approval or enterprise assurance is claimed. See the privacy statement.
• Not a hard spend limit. The token ceiling is not a monetary cap and must not be relied on as one. Section 5 explains this in full, and it is the section to read first.
• Not a multi-provider router. One model is configured per deployment, requests are non-streaming and plain-text only, and unsupported parameters are rejected rather than translated. See section 6.

Nothing on the website is an offer of service. A pilot request is a request for review, not an order, an entitlement or a contract.

2. Private beta conditions

• Access is by manual invitation. There is no self-service signup, no automated provisioning, no public plan and no published price. The operator reviews each request by hand and decides whether to proceed.
• The operator may decline or withdraw access. A request may be declined, deferred, or granted and later withdrawn, including after credentials have been issued. Reasons can include data sensitivity, poor fit with the beta, capacity, abuse signals, security concerns, or legal and provider-account grounds. Where practical, a brief reason will be given, but no reason is owed.
• Ending a pilot. When a pilot ends, whether by the operator's decision or the pilot's, the project keys are revoked and the operator will say that it has happened. Section 4 describes what revocation does.
• Support is best effort. Support is provided by the same person who operates the service, alongside everything else. Response times are not contractual and no target is offered. There is no 24/7 cover, no telephone support and no guaranteed escalation path.
• Release gates can suspend a pilot. This project holds explicit security, legal and deployment gates. If a gate fails, the operator may suspend access rather than continue operating in a state the gates say is unsafe. That is a property of the beta, not a breach of it.
• No fees. No payment is requested or accepted during the private beta. Section 9 sets out what would have to exist before that changed.

3. Acceptable use

The following are prohibited, and the list is not a formality: the gateway holds a shared upstream credential, so misuse by one pilot reaches beyond that pilot.

• Do not try to circumvent the rate or token rules. This includes splitting a workload to slip past the per-minute window, creating additional projects or keys in order to pool around a ceiling, or retrying in a loop in a way that defeats the policy's purpose.
• Do not share one project key across unrelated parties. A key belongs to one project and one integration boundary. Client projects, environments and separate teams need separate projects, and the operator will say so during onboarding.
• Do not submit data you are not permitted to send to a third-party model provider. That means no personal data about other people, no sensitive or regulated data, and no confidential third-party material, unless the operator has explicitly agreed to it in writing after the relevant review is complete. The cross-border nature of the transfer is described in the privacy statement.
• No unlawful content or use. Nothing may be sent through the gateway that is unlawful, infringing or intended to cause harm, and the pilot must comply with Anthropic's usage policies, because the request is ultimately served by Anthropic.
• Do not attempt to extract the operator's upstream credential, or to reach Anthropic through this gateway by any path other than the documented request route. Attempting to probe, infer, reuse or exfiltrate that credential, or to make the gateway act as an open relay, is a breach and will end the pilot.
• Do not automate abuse of the pilot request form. Scripted submissions, bulk entries, scraping through the form, or using it as a message relay are prohibited. The form is protected by a check for automated submissions and by a field no human fills in; evading either is a breach.

Consequences are proportionate and factual: the operator may revoke keys, stop forwarding requests, withdraw access, and, where a legal obligation or a provider's terms require it, report the matter. The gateway validates requests against an allowlist, so unsupported parameters are rejected before reaching the model; finding another way to send unsupported input is also a breach of these terms.

4. Credentials: issue, custody and revocation

• Issued once. A project key is cryptographically random, prefixed gt_live_, and displayed exactly once, in the response that creates it. The stored value is a SHA-256 digest, so the operator cannot recover it or display it again. Treat the value you were shown as the only copy that will ever exist.
• Transmitted once, over an agreed channel. The operator transmits the key a single time through a channel agreed during onboarding, and does not send it again unrequested.
• The recipient is responsible for safekeeping. Do not commit the key to version control, paste it into a public issue, embed it in client-side code, or place it anywhere reachable by anyone outside the integration that needs it. Store it where the application's other secrets live, and remove it from any place it should no longer be.
• The recipient is responsible for requests made with the key until revocation takes effect. Authentication is resolved against the stored digest on every request, so a revoked key stops working on the next call it makes.
• A compromised key must be reported immediately, through the contact route described in the privacy statement or the channel used during onboarding. The operator will revoke it, verify that subsequent calls are rejected, issue a replacement, and record the incident with timestamps. That sequence is the documented recovery path, and it depends on being told.
• The operator may revoke at any time for security, policy, capacity or pilot-closure reasons. A revoked or unknown key receives 401 and no request is forwarded.

6. Request handling limits

The gateway's application-facing contract is one route: POST /v1/messages. It accepts a deliberately narrow subset of the upstream contract, and this deployment is configured for a single model, currently claude-sonnet-5-5.

• model must equal the configured model. A different model is rejected; the gateway never substitutes one silently.
• max_tokens must be an integer between 16 and 4096.
• messages must contain between 1 and 20 entries, each with a role of user or assistant and non-blank text content.
• system is optional, must be a string, and is limited to 12,000 characters. Combined content across the request is limited to 40,000 characters.
• Only plain-text, non-streaming requests are supported. Streaming, images, content blocks, tool use, batches, prompt-caching parameters and any other top-level field are rejected with 422 before the request reaches Anthropic, and the unsupported parameter is named in the error. A body larger than the gateway's size cap, which is 256 KiB in the current implementation, is rejected as well.
• The upstream call has a timeout of roughly 55 seconds in the current implementation; a slower response is reported as a gateway timeout rather than being retried. The gateway does not retry requests on your behalf, because an implicit retry could be billed twice.

A request can be rejected for quota, rate or validation reasons. The codes are specific, and this is what they mean:

7. Disclaimer and limitation of liability

The service is provided as is and as available, as a private beta, without warranties of any kind, whether express or implied, including any implied warranty of merchantability, fitness for a particular purpose, title or non-infringement, and without any warranty that the service will be uninterrupted, timely, secure or free of errors, that defects will be corrected, or that any data will be preserved.

• Model output. The operator does not control, verify or endorse what the model returns. Output can be wrong, incomplete or unsuitable. Evaluate it before you depend on it. The gateway passes through what Anthropic returned or reports an honest error; it never fabricates a completion. Decisions taken on model output are yours.
• No content record. Because prompt bodies and response bodies are not stored, the operator cannot restore them, cannot replay a request, and cannot investigate what a call contained. Do not treat this gateway as the only record of anything you need to keep.
• No backstop. No guarantee is given against data loss, configuration error, provider outage or provider account action. Keep your own copy of anything you cannot afford to lose.
• Limitation of liability. To the maximum extent permitted by applicable law, the operator's total aggregate liability arising out of or relating to these terms or the service is limited to the amount actually paid to the operator for the service, which during the private beta is zero because no fees are charged. The operator is not liable for indirect, incidental, special, consequential, exemplary or punitive damages, or for lost profits, revenue, data, goodwill or business opportunity, and is not liable for charges Anthropic or any other provider applies to any account.
• What cannot be excluded. Nothing in this section excludes or limits liability that cannot lawfully be excluded or limited. Some jurisdictions do not permit certain exclusions, so parts of this section may not apply to you. This is a draft clause and requires professional review.

8. Availability, suspension and changes to the service

• The operator may change, suspend or end the service, or any part of it, at any time during the beta. That includes the configured model, which may change if the upstream model identifier or its availability changes; the request limits in section 6; and the default policy values applied to new projects.
• No availability commitment is made. No uptime figure is published or promised, no service credit is offered for downtime, and no notice period is guaranteed for a change or a shutdown, although the operator will try to give notice where a change affects an active pilot.
• Maintenance, provider outages, provider rate limits and security work can each interrupt the service without notice.

9. Fees

No fees are charged during the private beta, no prices are published, and no checkout exists. In the current architecture the operator bears Anthropic's API charges on the operator's own account; those charges are between the operator and Anthropic and are not resold to a pilot as tokens. If a paid service is introduced, it will be a separate agreement with its own terms, a real refund position, a tax position and a support workflow in place before any payment is requested. Nothing in these terms obliges a pilot to pay anything, and no charge can arise from continued use of the beta.

10. Changes to these terms

The operator may revise these terms. A revision is published on this page with a new version number and date, and a material change affecting an active pilot will also be raised through the channel used to reach that pilot. Continued use of the service after a change is published means the change is accepted. A pilot that does not accept a change can ask the operator to withdraw its access, and the project keys will be revoked under section 4. This is draft version 0.1, dated 8 October 2026, and it is not in force.

11. Governing law and disputes

These terms are intended to be governed by the laws of the Republic of Indonesia, and disputes are intended to be subject to the courts of Indonesia. That is a draft position for professional review, including whether a different venue, a language of proceeding or an arbitration clause is appropriate, and nothing here waives any mandatory protection available to you under the law of your own jurisdiction. No choice of law has been agreed with any pilot yet, and this paragraph will not be relied on as a settled term until that review is complete.

12. Operator status

13. Related documents

• Privacy statement — what is stored, what is never stored, retention, and how to make a data request.
• API documentation — the exact request contract, supported parameters and error behaviour.
• guntech.cloud — what the product is, and what it is not.