Frequently Asked Questions

Grapthway is a developer-first Virtual Private Server (VPS) platform built on a decentralized agent network. Instead of a traditional centralised data center, your VPS runs on physical nodes operated by independent node operators who register with the Grapthway network. You get root SSH access, a public IPv4, configurable port ranges, and full control over your server — billed by the month and paid with on-chain tokens.

Visit the Register page and sign up with your email address and password. After verifying your email you will be redirected to the dashboard. From there you need to create a wallet (Wallet → Create) before deploying your first VPS — the wallet holds the tokens used to pay for subscriptions.

Three things:

Once those are ready, head to VPS → Deploy and follow the four-step wizard (Tier → Node → Configure → Confirm).

A tier defines the CPU sharing ratio applied to your VPS. The platform organises tiers into three classes:

The exact ratio for each tier and the resource caps (max CPU / RAM / disk) are configured by the platform and shown on the product page and at the first step of the deploy wizard. Pricing is denominated in the token of your choice and previewed before you commit.

Available nodes depend on which operators have joined the Grapthway network. The Node step in the deploy wizard shows all active nodes with their country, city, and available slots in real time. Use the Region, Country, and City dropdowns to filter. New regions appear automatically as operators register — there is no fixed list.

Deploying a VPS is a four-step wizard:

The system runs a pre-check before charging your wallet, then triggers the provisioning pipeline. A live log viewer shows provisioning progress.

After provisioning completes (typically 1–3 minutes), your VPS card in the dashboard shows an SSH command:

Use the root password you set during the deploy confirm step. You can also reset your SSH root password at any time via VPS → Reset SSH Password without needing to redeploy.

Yes. Open the Scale VPS modal from your VPS card. You can increase CPU, RAM, or disk independently — you do not have to scale all three at once. If a resource is fully exhausted on the node (no headroom), that slider is locked at your current value and shown in red, but you can still scale the other resources that have headroom. A pro-rated charge for the remaining subscription days is deducted from your wallet at the time of scaling.

Yes via Downscale VPS. You can independently reduce CPU, RAM, or disk. Downscaling is free — no additional charge is made. The new lower spec takes effect once the job completes. Note: disk reductions require the OS to release that space first; make sure your data fits the new size before downscaling disk.

Yes. The VPS card shows live CPU and memory usage fetched from the node agent. Click into your VPS details to see a panel with CPU percentage, memory usage, and disk info. Monitoring is available for running VPS instances only — stopped or provisioning VPS do not expose live stats.

From the VPS card click Delete. A confirmation modal will appear. Once confirmed, the platform sends a termination job to the node agent, which removes the container and releases all resources. Remaining subscription days are not refunded — deletion is permanent. Make sure you have backed up any data you need before deleting.

Go to your VPS card → Reset SSH Password. Enter and confirm your new password (minimum 8 characters). The platform sends a secure password-reset job to the node agent. The new password is effective as soon as the job completes (usually under 30 seconds). You do not need to redeploy your VPS.

Every background operation (deploy, scale, delete, password reset) creates a Job. You can view all your jobs and their detailed log output at Jobs in the sidebar. Log lines from both stdout and stderr are streamed in real time while the job is running. Failed jobs show the error output in red to help you diagnose what went wrong.

Folder Management is a built-in Finder/Explorer for your VPS filesystem — no SSH required. Open it from VPS → Folder Management (or the Files entry in the VPS menu) and pick a running VPS.

What you can do:

Good to know:

The page also has an in-app "How it works" explainer with these details.

During deployment you choose an SSH host port (1024–65535). The platform checks it live against all occupied ports and port ranges already allocated on that node. If the port is taken, a red indicator appears and you must choose another. This avoids conflicts between VPS instances sharing the same physical node IP.

Port ranges let you reserve a block of host ports that are NAT-forwarded to your VPS. Each VPS can reserve up to 1,000 ports total across multiple ranges. To configure them:

Use these ports to expose services (databases, game servers, custom APIs) through the node's public IPv4 without SSH tunnelling.

The platform performs a real-time conflict check before accepting any port assignment — both for the SSH port during deploy and for port range bookings in the Ports tab. If a conflict is detected you will see a clear error message identifying the conflicting range. Simply choose a different port or range.

Yes. The Setup Domain modal lets you configure a subdomain (e.g. app.yourdomain.com) that proxies traffic to your VPS. Provide your domain, the internal port your service listens on, and the protocol. The platform creates a proxy rule on the node agent. You must then point your DNS A record to the node's public IPv4 address. TTL changes propagate in 5–60 minutes depending on your DNS provider.

Each node has one public IPv4 address that is shared between all VPS running on it. Your VPS is differentiated by its SSH port and any reserved port ranges. If you need traffic isolation, choose a node with low active VPS count, or contact support to discuss dedicated-IP node arrangements.

Grapthway uses prepaid monthly subscriptions. When you deploy a VPS you pay upfront for the number of months you selected (1 to 36). The cost is calculated as:

All prices are denominated in the token you selected at deploy time. Longer subscriptions may qualify for automatic discounts shown on the pricing page.

Open your VPS card → Extend Subscription. Select the number of additional months, review the total cost, and confirm. Payment is deducted immediately. Your subscription end date is pushed forward by the chosen duration. You can extend at any time — you do not need to wait until expiry.

Yes. Each VPS subscription has its own Auto-Renewal setting that you can toggle on or off from the VPS card. When enabled, the platform automatically charges your wallet for another billing period before the current one ends. If the renewal succeeds, the VPS keeps running uninterrupted and an `auto_renewed` event is recorded. If your wallet does not have enough balance, the renewal is marked `auto_renewal_failed` and the subscription proceeds to expire normally — so you still get the grace period to top up and renew manually. Auto-renewal uses the same token the subscription was originally created with.

When a subscription expires the VPS enters a suspended state. The VPS process on the node is halted but data is preserved for a grace period (typically 7 days). During this period you can extend the subscription to bring the VPS back online. After the grace period the VPS is permanently deleted and all data is lost. You will receive email reminders before expiry.

When you scale up mid-subscription, you pay the difference in monthly cost pro-rated for the remaining days. The formula is:

This charge is shown in the Scale VPS preview before you confirm. The charge is deducted from your wallet balance in the token associated with your subscription.

Yes. Discount programs are available for multi-month subscriptions. The applicable discount is shown automatically in the configurator when you select the billing period. Discounts stack with the base pricing and are applied to the total before payment. Check the product pricing page for the latest discount schedule.

The payment token is locked at deploy time and tied to the subscription record. Extension and scaling charges use the same token as the original subscription. To use a different token you would need to deploy a new VPS. This ensures consistent billing across the subscription lifetime.

The Grapthway wallet is an on-chain account address on the Grapthway Protocol network. It holds your token balances (IDRG, USDG, and others) which are used to pay for VPS subscriptions. Your wallet address is generated when you create a wallet inside the platform — it is unique to your account and recorded on-chain.

Grapthway uses native tokens pegged 1:1 to real-world currencies. The tokens currently active on the platform are:

Additional currency-pegged tokens can be registered by the platform admins over time. The authoritative list of tokens you can hold and pay with is always the Wallet → Overview page — it shows every token currently enabled for your account. Not all tokens are accepted by every tier; the deploy wizard filters tiers by the currency you want to pay in.

Go to Wallet → Deposit. Select the token you want to deposit and the amount. Choose your preferred payment method:

After payment, upload your proof of payment (screenshot). An admin reviews and approves the deposit, which triggers minting of the equivalent token amount to your on-chain wallet. Approval typically takes a few minutes during business hours.

Grapthway uses a fiat-to-token bridge: real money is received through Midtrans (QRIS or Virtual Account) and an equivalent amount of on-chain tokens is minted to your wallet after verification. The approval step ensures the payment was received and the correct amount is minted. This is a safety check against failed transactions, wrong amounts, or duplicate submissions.

Your wallet balance is shown in the Wallet badge in the navigation bar (top right) as well as on the Wallet page Overview tab. Balances for all held tokens are listed. The balance refreshes automatically when you navigate to the wallet page or after a transaction completes.

The Wallet page has a Transactions tab showing your complete payment history — deposits, VPS subscription payments, scale charges, and any refunds. Each entry shows the date, amount, token, and transaction type. You can also see a detailed view under Transactions in the sidebar which includes subscription-level billing events.

The Wallet page → Deposits tab lists all your deposit requests with their current status:

Tap any deposit row to see details including the proof of payment you uploaded.

Root access is provided for maximum flexibility. For better security we recommend:

Grapthway provides root access as a starting point — securing it further is your responsibility.

Yes. After your first password login, add your public key to ~/.ssh/authorized_keys on the VPS. You can then disable password auth in /etc/ssh/sshd_config (set PasswordAuthentication no) and restart sshd. SSH keys are significantly more secure than passwords and immune to brute-force attacks.

All SSH sessions are encrypted in transit using standard SSH encryption (AES-256). Data at rest on the VPS disk is not encrypted by default — if you need at-rest encryption, you can set up LUKS or similar block-level encryption inside your VPS. The Grapthway platform itself communicates internally over encrypted channels.

Migration moves an existing VPS onto a different plan (tier) and/or a different node, without rebuilding your server by hand. It runs in two phases: first we copy your VPS to a brand-new one on the destination while your old VPS keeps serving (zero downtime); the new VPS comes up as a fully-working preview in a ready-to-switch state. Then, when you've re-pointed DNS and verified it, you click Switch to make the new VPS authoritative after a brief final sync. You start the migration from VPS → Migrate Plan and follow the four-step wizard (Destination Tier → Destination Node → Configure → Confirm).

Phase 1 (pre-copy): when you confirm, we take a consistent snapshot of your VPS and stream it to the destination node while your old VPS keeps running and serving traffic — there is no downtime. The new VPS comes up live and testable but not yet authoritative. Phase 2 (Switch): after you've re-pointed DNS and verified the new VPS, you click Switch now in the VPS page and confirm. We do a brief final sync of only the data that changed since the pre-copy, then promote the new VPS to your live server. You decide exactly when the short cutover happens.

Everything on your disk. The entire VPS filesystem — your files, installed packages, system configuration, and the inner Docker data directory — is streamed to the destination node as a verified, checksummed copy. The transfer is chunked and resumable, so a network hiccup never corrupts or loses data. Nothing is wiped: migration copies your disk, it does not reset it. At Switch, a final delta sync carries over anything that changed on the old VPS since the pre-copy.

Yes. Your containers, images, and volumes live inside the VPS disk, so they travel with it automatically as part of the disk copy. On top of that, their records — repositories, container configs, and deployment history — are re-pointed to the new VPS and started during the pre-copy, so the preview is a complete working mirror you can test. Git tokens are stored per-account (not per-VPS), so they keep working on the new VPS with no extra steps.

Yes. Every port range booked on your source VPS is automatically re-booked and opened on the destination node during the pre-copy — there is no manual re-mapping, so your custom ports answer on the preview too. The configure step also keeps your SSH port (you can change it if it clashes with something already booked on the destination node, and the wizard checks availability live).

When the pre-copy finishes, your new VPS shows a ready to switch badge: it's a fully-working preview, live on its own IP and SSH, with your containers, ports and domain config already set up — but it is not yet your authoritative server. Test it as much as you like via its IP / SSH while your old VPS keeps serving real traffic. Important: do your real writes on the OLD VPS until you Switch. Any data you write to the preview before switching is overwritten by the final cutover sync, which copies the latest data from the old VPS.

During the pre-copy the new node already serves your domain config and HTTPS certificates, so it answers the moment DNS points at it. The one manual step left to you is updating your DNS A-record to the new node's IP before you Switch — until you do, visitors keep reaching the old VPS, which is fine because it serves until the moment you Switch. At Switch, the domain authority is re-pointed to the new VPS.

Your old VPS keeps running and fully active right up until you click Switch — there is no rush. Only after the cutover does it enter a 3-day fallback window, then it is removed automatically. Because migration moves your subscription to the new VPS, the old one is not meant to be extended or renewed — it is a temporary safety net, not a second server. Treat the new VPS as your live one and switch over when you're ready.

Yes. While the new VPS is in the ready-to-switch state (before you Switch), the VPS page shows a Cancel migration button. Cancelling removes the preview VPS and refunds your migration charge; your original VPS is completely unchanged and stays fully active on its current plan. If you never switch, the migration also auto-cancels after 3 days, with the same teardown and refund.

Yes — migration is also a chance to resize. On the Configure step you can raise or lower CPU, RAM, and disk on the destination plan, within the destination node's capacity. Disk can only shrink down to the space your data already uses: an over-shrink is rejected up front, before any charge, so your data is never at risk. The wizard shows a red floor on the disk slider when you go below the safe minimum.

Migration charges a discounted first month on the destination plan plus a migration fee (equal to a second discounted first month) — so the total due now is roughly 2× the discounted first month, billed upfront when you start. The destination starts a fresh 1-month period; the source subscription's remaining time is not transferred. Global program and voucher discounts apply just like a fresh deploy. If you cancel before switching (or it auto-expires after 3 days), you are refunded. The full price breakdown is shown on the Configure and Confirm steps before you commit.

Once you confirm, the pre-copy runs as a durable background job — you can safely close the dialog and leave. The time depends on how much data is on your disk: a near-empty VPS finishes in minutes, while a multi-GB disk takes longer. The job is resumable, so it survives interruptions, and we email you the moment the new VPS is ready to switch. Your old VPS stays usable the whole time. The Switch itself is brief — seconds of downtime for a low-write VPS — and you trigger it when you're ready.

Your source disk is never modified — the copy and the final delta are read-only — and every failure path leaves a working VPS. If the pre-copy fails, your old VPS never went down: the half-built preview is torn down and your migration charge is refunded. If the Switch fails, your old VPS is still serving as the fallback and the Switch is retryable — nothing is destroyed. So your data and original VPS are always safe.

The token payment selector highlights your balance in red when it falls below the quoted total. Deposit the required amount and wait for admin approval before retrying. Make sure you are selecting the correct token — e.g. if your subscription tier accepts IDR, you need an IDRG balance, not GCU.

Nodes with zero CPU, RAM, or disk are automatically hidden from the node selection list. If the node you prefer is not showing, it means it has no capacity for the selected tier. Options:

Deposits are reviewed by admins, typically within a few hours during business hours. If your deposit has been pending for more than 24 hours:

The Grapthway Protocol is the decentralized execution substrate that the whole platform runs on. It is several things in one:

The web platform sends every request to a Grapthway node rather than to services directly, and node operators register their physical servers as Grapthway agents that execute provisioning and lifecycle jobs.

Nodes are operated by independent node operators — individuals or organisations that register their physical servers with Grapthway. Each operator runs the Grapthway agent software which accepts provisioning jobs from the platform. Operators are vetted before their nodes are made available to users. The platform tracks node status, resource allocation, and uptime through the node-host microservice.

Grapthway targets 99.9% platform (control-plane) availability. Individual node uptime depends on the node operator. Each node carries one of four statuses tracked by the platform:

Only Active nodes appear in the deploy wizard. If a node goes Offline unexpectedly, the platform monitoring system detects it and the operations team is alerted; users with affected VPS are contacted directly.

The Grapthway backend is a fleet of independent Go services that all talk to each other through the Grapthway Protocol. Roughly grouped:

Domain microservices

Orchestration & edge

Workers (background)

All services communicate through Grapthway Protocol routing for atomic multi-step operations.

Your VPS data (files, databases, applications) lives on the physical disk of the node operator's server in the region you chose. Platform metadata (account, subscription, billing records) is stored in the Grapthway cloud database. Payment and wallet data is recorded on the Grapthway Protocol blockchain. Review our Privacy Policy for full details on data handling.

Use the Language toggle available on every page — look for the dropdown button in the top navigation bar or in the top-right corner of the page (on pages without a navbar). Click it to open the language selector and choose your preferred language. The change is applied instantly across the entire interface. If you are logged in, your preference is saved to your account and synced across devices.

Open the Preferences panel via the gear icon in the navbar. Toggle between Dark and Light theme. The theme is saved to your account and applied on every subsequent login.

On the login page, click Forgot Password. Enter your registered email address and we will send a password reset link. Follow the link in the email to set a new password. The link expires after 24 hours. If you do not receive the email, check your spam folder or contact support.

For general questions, consult this FAQ first. For account-specific issues, billing disputes, or urgent technical problems:

Admin-level issues reported through the platform are handled within business hours.

Container Management is a built-in feature of your Grapthway VPS that lets you build and run Docker containers without leaving the platform. You can connect a Git repository (via URL or personal access token), edit a Dockerfile, auto-detect the technology stack of your project, and control the container lifecycle — all through the VPS dashboard. No external CI/CD pipeline is required to get a containerised application running on your server.

Open your VPS card and navigate to the Container tab. Use the Repository section to connect your project:

Once cloned, the platform auto-detects your project's stack and populates the Dockerfile editor with a sensible starting template. You can pull the latest changes at any time using the Pull button.

Any Git provider that exposes a standard HTTPS clone URL is supported, including:

For private repositories, generate a Personal Access Token (PAT) with at least read access to the repository. On GitHub this is Settings → Developer Settings → Personal Access Tokens. On GitLab it is User Settings → Access Tokens.

After cloning your repository, the platform scans the project files to identify the technology stack:

The detected stack is used to pre-fill the Dockerfile template with the correct base image, dependency install commands, and startup command. You can always edit the generated Dockerfile to customise build steps.

The Dockerfile editor is an in-browser code editor embedded in the Container tab. It lets you write or modify the Dockerfile used to build your container image — no SSH required.

Changes to the Dockerfile are applied only when you trigger a build — the running container is not affected until you explicitly redeploy.

Git Personal Access Tokens (PATs) are stored encrypted on the server using AES-256 encryption. The plaintext token is never written to disk — it is encrypted immediately after you submit the form and only decrypted in memory when a git operation (clone or pull) requires it.

We recommend using tokens with the minimum required scope (read-only repository access) and setting an expiry date on the Git provider.

The Container tab provides lifecycle controls for your running container:

All lifecycle operations are tracked as Jobs — you can view progress and log output in real time in the Jobs section of the sidebar.

The Container Wizard is a step-by-step guided flow that helps you set up a container from scratch without writing any configuration manually:

You can relaunch the wizard at any time from the Container tab to reconfigure from step 1.

Container operations produce two types of logs:

Build logs — Captured during the Docker build phase (docker build). These show each Dockerfile instruction and any errors during image construction. Accessible via the Jobs section — each build triggers a job with a full log stream.

Runtime logs — The live stdout and stderr output of your running container. View these from the Container tab → Logs panel. Logs are streamed in real time and auto-scroll. You can also access historical runtime logs from the Jobs section for completed run jobs.

If a build fails, the error will appear in red in the job log — look for the failing Dockerfile instruction or missing dependency.

Yes. You can create several managed container configs on the same VPS — for example a web app, a backend API, and a database — and deploy each one. They all share your VPS's CPU, RAM, and disk allocation. You still have full root SSH access too, so you can run additional containers with Docker CLI or Docker Compose; those aren't tracked by the Container Management UI.

Your managed containers join a shared user-defined network, so they resolve each other by container name — your backend connects to your database using its container name as the host (no IP addresses). This works because Docker's default "bridge" network has NO built-in DNS; a user-defined network does.

In the create/edit wizard, leave Network as "Default (managed network)" so the container joins the shared network. You can also create your own networks in the Networks tab and pick one in the wizard. If a backend can't resolve its database hostname, make sure both containers are on the same user-defined network (not the default bridge).

Some values must be baked into the image when it is BUILT, not when it runs — the classic example is a Next.js NEXT_PUBLIC_API_BASE_URL, which gets inlined into the browser bundle at build time. Add these as Build arguments in the Docker step of the create/edit wizard (they map to docker build --build-arg). They are saved with your container config and reused on every redeploy.

Use Build arguments for build-time values and Environment variables for runtime values. For example, a frontend's public API URL is a build argument, while a backend's database connection string is a runtime environment variable.

The AI Agent is an autonomous assistant that builds, deploys, and maintains applications directly inside your VPS. You describe what you want in plain language and it writes the code, builds a Docker image, runs it on your server, can set up a domain, and verifies the app is live — like a developer teammate you can watch, steer, or stop at any time. It uses the same actions as the VPS menus (repositories, containers, deploy, networks, domains, ports), so anything it does also shows up in those menus.

Four steps:

Use a high-end (flagship) model — this is the single biggest factor in how well the agent performs. Recommended: Claude Opus or Sonnet (latest), GPT-5.4, Gemini 3 — or any newer / equivalent model.

Avoid small or older tiers (mini, nano, haiku, and similar) for full build-and-deploy work: they tend to loop, produce broken builds, or deploy the wrong thing. They are fine for tiny edits, but for end-to-end app building a stronger model writes better code, recovers from its own errors, and finishes in far fewer steps (which also keeps your provider costs down). You pick the model per project, and the agent runs on your own provider key.

No. You can describe what you want in everyday language ("a portfolio site with a gallery and a contact form") and the agent does the engineering. To get good results without coding:

If you are a software engineer, you can also point it at an existing repository, give precise technical instructions, and review its commits and Dockerfiles.

You are always in control:

The agent works inside your own VPS using your own provider key, which is encrypted at rest, injected only for the duration of a run, and never persisted.

It can scaffold a new app or work on an existing repository, write and edit code, build Docker images and run containers, create networks, expose ports, and add domains with SSL — then verify the app is serving. Beyond the first build it can maintain the app: scheduled dependency updates and automatic self-heal when a deploy or run fails, all within your guardrails and spend cap. Because it uses the same platform tools as the VPS menus, its work shows up in Container Management, Domains, and the Jobs/activity views.

Yes. Just ask it in chat to run a task on a schedule — hourly, daily, a cron expression, or once at a specific time. For example: "every hour, scan my service logs for errors and report," nightly dependency checks, or a periodic health probe. The agent sets up the schedule, runs the task on cadence within your autonomy level and spend cap, and you can ask it to list, change, or cancel your schedules at any time.

It depends on the provider you pick for the chat room. On the built-in Grapthway provider (the default), Grapthway bills you directly: a small platform compute fee per agent turn (iteration), plus the model tokens it uses — fresh input, cached prefix (which is much cheaper), and output, each priced per million tokens. If you Bring Your Own Key (BYOK), the model tokens are billed by your own provider (Anthropic/OpenAI/Google) and Grapthway only adds the per-iteration compute fee. Either way you are charged after each run settles — never mid-step — and a stronger model usually finishes in fewer turns, so it often costs less overall than a weak model that loops. Open a project's Spend & Budget tab to set limits and review your usage.

Open a project's Spend & Budget tab. You have four independent controls: (1) Spend cap — the total ceiling across the compute fee plus tokens; the run stops the instant its projected spend would cross it. (2) Max iterations per run — how many agent turns a single run may take. (3) Max tokens per run. (4) Max time per run. On top of these, a wallet ceiling always applies: a run can never spend more than your wallet balance, so you can never go negative — even on an uncapped or force-continued run. Billing is post-run. The same tab shows your usage per day, model, and currency, with the iteration (compute) charge listed separately from the total so you can see exactly how much your agent turns alone are costing. Tip: start with a modest spend cap and a max-iterations limit while you learn a prompt's cost, then raise them once you trust it.

Yes — all managed in the Agent Files tab, which has four sub-tabs: Skills, Tools, Memory, and Reference uploads.

Auto catalog: .agent-skills, .agent-tools and .memory each keep a catalog.json the agent reads to find what you have. It fills in automatically — a new skill/tool folder's NAME becomes its description until you set one. To customize, edit that catalog.json (or the SKILL.md / TOOL.md) description; your edits are preserved when the catalog rebuilds. Everything lives under /projects, so it survives restart, scale, downscale, and migration. Uploads can be any size — streamed in chunks, with interrupted transfers cleaned up immediately.

Yes. The agent keeps its own MEMORY so you don't have to repeat yourself — and it's organised as a Global → Project tree:

The agent recalls memory before it starts (so it follows past decisions instead of contradicting them) and records new facts, gotchas, and the preferences you state as it works — updating a note when something changes. For example, ask once for "a shopping-list app in light-blue + white, modern but simple, Next.js, mobile + desktop" and it saves project notes like frontend-design-preference, tech-stack, and project-description; on later prompts it reuses them automatically. Memory is SHARED across all projects on that VPS, and the global catalog nests every project so one lookup sees the whole tree. You can read and edit any note from the Agent Files → Memory tab; each is a small <slug>.md file, and the catalog plus a human-readable MEMORY.md index rebuild themselves whenever a note changes. (Your private code and reference uploads are never turned into memory — only the reusable facts and preferences.)

Separate from your own files, the platform keeps a shared catalog of procedures the agents have figured out. When an agent hits a problem the built-in tools don't cover and works out a solution, it saves that procedure to a fast, indexed catalog — and future runs, across every project and user, can search it before reinventing the wheel. It is how the whole fleet gets smarter from real experience: a tricky repo-extraction or a build workaround solved once becomes instantly reusable. You don't manage this catalog yourself; it grows automatically, and the agent is encouraged to contribute whenever it learns something new. (Your private code and reference uploads are never part of it — only the reusable how-to.)

Yes. During a chat the agent can spawn autonomous sub-agents to run work in parallel (e.g. scan logs on a VPS while it keeps building). Before each sub-agent runs, it shows you a budget estimate and asks you to confirm the max iterations and spend cap. Every sub-agent then appears in the "Spawned agents" panel inside the chat, each with its project + chat name and live status. Expand one to watch its messages stream in real time (tool calls, results, and text) exactly like a full chat room, answer a question it asks, steer it, or — after it finishes — follow up so it continues with its context intact. If a sub-agent stops at its spend cap or iteration limit, the parent can still read its recent messages to recover what it did.

Hover a chat in the list to Pin it to the top or Rename it — this works in the AI Agent, AI Chat, and /chat rooms. The small ring in the message box is the context meter: it fills and changes colour as the model's context window is used; click it to see the exact tokens used vs the window. Long chats auto-compact automatically as they approach the limit, on every provider and model (including the managed Grapthway provider), so a room can keep going.

Yes — but only on models that support it. When you attach a file, folder or image in a chat, text and code are read by the agent through its file tools. Images and documents (pdf / docx / pptx / xlsx) are sent to the model as native attachments — provided the selected model is capable. Every model in the picker shows an eye icon when it accepts images and a document icon when it accepts documents; a model with neither can only read text files, not see a picture. On the API gateway the same capability is published per model on GET /v1/models as `supports_vision` and `supports_documents`. Attachment support is auto-detected from the provider catalog and can be overridden by an admin per model.

Three ways, all under the AI section in the sidebar:

Everything is metered against your plan and shown on Spend & Budget. You never need a provider key of your own — the platform hosts the models.

They share the same models and billing but suit different jobs:

Pick AI Agent to build/run software for you, AI Chat to talk to a model in the browser, and API keys to power your own product.

AI Chat (sidebar → AI → AI Chat) is a plain chat room with the platform models — no VPS or project needed. Open it, pick a model, and start chatting. Conversations are saved and lazily reloaded when you come back, so you can continue where you left off. It supports ask-and-wait prompts (the model can ask you a question mid-task and pause for your answer). Each message is metered against your AI plan first, then your wallet — the same meter the AI Agent uses — so watch your remaining budget on Spend & Budget.

Go to sidebar → AI → Plans & Pricing → Plans. Two kinds:

Each card shows the budget you'll be granted and the value (extra budget vs. what you pay). Click Buy to see a confirmation dialog with the full summary, then confirm — your wallet is charged and the plan activates immediately. The purchase is recorded on your Transactions page (with a PDF receipt) and you get an in-app + email confirmation.

Plans & Pricing → Model pricing lists every model active on the platform, priced in your currency (per 1M tokens) for input, cache read, cache write, and output. Click a column header to sort, and use the search box to filter models. The underlying upstream provider is intentionally not shown — every model is served by Grapthway. The same prices apply whether you use the model via the AI Agent, AI Chat, or the API.

Under AI → API keys you can create sk-gw- keys that call an OpenAI-compatible endpoint — so any official OpenAI SDK (Python, Node/TypeScript, Go, Rust, …) works by just pointing base_url at a Grapthway node and using your key. It supports GET /models and POST /chat/completions, including streaming. The full key is shown once at creation; store it safely and revoke it anytime. Requests are funded by your AI plan, then your wallet. See the How to connect tab for copy-paste examples and the API Docs tab for the full endpoint reference.

Two changes to any OpenAI-based code: set base_url to a Grapthway node (shown live on the How to connect and API Docs tabs — e.g. https://node.sg.01.grapthway.com/<your-prefix>/ai-gateway-service/v1) and use your sk-gw- key as the Bearer token. Then call it exactly like OpenAI: list models with GET /models, create a completion with POST /chat/completions, and set "stream": true for server-sent events. The How to connect tab has ready-made snippets for curl, Python, Node, TypeScript, React, Go, and Rust using the official OpenAI SDKs.

No — max_tokens is optional (standard OpenAI behavior). If you omit it, the gateway defaults it to the model's real output cap, automatically clamped to fit the remaining context, so a long reply is never truncated by a low default and never overflows the context window. If you do set max_tokens, your value is used as-is. GET /models also returns each model's context_length and max_output_tokens (a superset of OpenAI) so you can size budgets yourself without hardcoding a per-model table. For long agent/chat conversations the platform also auto-compacts the history before it reaches the context limit.

AI Chat and API-key usage are metered against your AI plan first (subscription / top-up), then your wallet for any overflow — the same meter as the AI Agent. Open AI → Spend & Budget to see your remaining plan balance and a detailed breakdown of what you've spent, filterable by source (AI Agent, AI Chat, API key) and, for API keys, by individual key. When plan and wallet are both exhausted, requests stop until you top up on Plans & Pricing.

Grapthway Flow is an AI-driven Jira: you plan work on kanban boards (projects, backlog, sprints, stories/tasks/bugs/documentation) and AI agents build, test and ship each work-item for you. AI-Chat acts as the manager that plans each item and spawns a sub AI-Chat executor to do the work, walked across the Active-Sprint columns by a worker — gated exactly where you want a human in the loop.

Move an item into READY FOR DEV (or click "Run with AI" on it). A per-project AI-Chat manager room plans it and spawns a sub AI-Chat executor; a worker then walks the item forward — building in IN DEV, validating in TESTING — until it reaches READY FOR SHOW for your review. You can watch, steer, or stop it at any time.

The Active Sprint has seven canonical columns: READY FOR DEV, IN DEV, READY TO TEST, TESTING, READY FOR SHOW, READY FOR BUSINESS SIGN OFF (= ready to production), and ON-HOLD. The Backlog lists everything before it enters a sprint. Boards can be customized, but these ship by default.

Any item can have sub-tasks. A parent cannot advance to a column to the right while a sub-task is still left of READY FOR SHOW — so a finding can be split into a sub-task that must be resolved first. When a parent moves to READY FOR BUSINESS SIGN OFF, its sub-tasks are automatically moved there too.

Yes. Every column has a gate: auto (the worker advances it) or user (it parks until you move it). The common setup is: you drop an item into READY FOR DEV, everything runs automatically through TESTING, then it gates at READY FOR SHOW for your sign-off — or you can gate every step. ON-HOLD parks any item.

Bind a work-item to a repository and git credential — the same repos the AI Agent uses (managed in ms-container) — or leave it as "discover" and let the worker find the right repo. The agent then clones, builds and commits with the standard platform git tools.

Your Flow subscription sets how many agents can run at once (and how many projects you can have). These per-plan limits are configured by an admin (mirroring the Consumer-AI products). Agent pickup pauses automatically when a subscription lapses; in-flight runs are allowed to finish.

The AI Agent is a single autonomous run that builds an app inside a VPS. Flow orchestrates a whole board of work-items — planning each with an AI-Chat manager and delegating to sub AI-Chat executors, then walking them across sprint columns with gating and sub-tasks. Flow is for managing ongoing delivery; the AI Agent is for one build.