# The Reasoning Problem Source: https://docs.openserv.ai/blog/the-reasoning-problem Why free-form chain of thought is the wrong medium for reasoning, and what a bounded graph does differently. Since 2022 we have been paying models to talk to themselves. It started as a prompting trick. You add "let's think step by step" and accuracy on maths word problems jumps ([Kojima et al., 2022](https://arxiv.org/abs/2205.11916)). In September 2024 OpenAI shipped o1 with the trick trained in, called the output "reasoning tokens", and billed them as output. The other labs followed. Today most hosted APIs return a summary of the trace or nothing at all, and you pay for the full trace either way. Anthropic's docs say that omitting the thinking reduces latency, not cost. The effort knob you are given is guidance the model may ignore. Among hosted APIs DeepSeek is the exception and returns the whole chain, and any open-weight model returns it when you run it yourself. I think the value is in the structure the monologue accidentally produces, and prose holds structure badly. ## Watching a model lose the thread Watch a model reason in free text about a refund policy with four conditions. It writes the first condition, checks it, writes the second, gets halfway through the third and refers back to "the earlier point" without saying which. By condition four it has restated the rules twice, slightly differently each time, and the answer depends on which restatement it happened to trust last. The tokens went on bookkeeping that prose cannot do well. I see the same shape in the agent failures people post on Hacker News and in my own pipeline. The model knew the rule and lost track of it. Someone writes a careful system prompt with routing rules, exceptions, and a priority order. It works on the happy path. Then a request arrives that touches two rules at once, and the model picks one, forgets the other, and produces a confident answer that violates the prompt it was given. The prompt was fine, but the model had to hold the whole structure in a linear stream of text while also producing the answer, and linear text is bad at holding structure. A June 2026 paper on instruction hierarchies splits this into three failures I recognise from my own traces: not finding the relevant rule, not resolving the conflict, and resolving it correctly in the reasoning and then violating it in the output ([Where Instruction Hierarchy Breaks](https://arxiv.org/abs/2606.07808)). The same failure shows up smaller in an agent I run that tags Hacker News stories with topics. Asked to tag 100 stories, it produced about 90 distinct labels, many of them near-duplicates like "AI", "AI models" and "Machine learning". The model understood every story. It had no structure to hold the label set steady across 100 decisions. I seeded a closed list of broad categories and required the first label to come from that list, which fixed most of it with the same model. Compare that to how a person writes down a policy when they need to apply it many times. They draw a flowchart. Here is the refund policy from above, first as the prose a system prompt would carry, then as the person would draw it. > Refunds are allowed within 30 days of delivery. Digital goods are non-refundable unless the download failed. Orders paid with store credit are refunded to store credit only. Any refund over 200 needs a manager to approve it before it is issued. ```mermaid theme={null} flowchart LR A[Refund request] --> B{Within 30 days of delivery?} B -->|No| X[Decline] B -->|Yes| C{Digital good?} C -->|Yes| D{Download failed?} C -->|No| E{Paid with store credit?} D -->|No| X D -->|Yes| E E -->|Yes| F[Refund goes to store credit] E -->|No| G[Refund goes to original payment] F --> H{Amount over 200?} G --> H H -->|Yes| I[Manager approval] --> J[Issue refund] H -->|No| J ``` Conditions become diamonds, actions become boxes, and the arrows carry the order so the reader does not have to. The flowchart shows that the store-credit rule is settled before the approval rule, and that a failed digital download still passes through both. The prose leaves that order to the reader, and it also hides whether every branch has an exit. Neither a person nor a model can check that by reading the paragraph. ## The standard fix makes it worse When a prompt like that fails in production, the fix I see most often is to buy a bigger model or turn up the effort setting and hope. It sometimes helps, and it adds more prose to a problem caused by prose. You pay for the extra tokens on every request, forever, and on a hosted API you still cannot read what the model did. More reasoning tokens do not buy proportionally more accuracy, and past a point they buy less. Simon Willison measured Qwen 3.8 spending 22,276 reasoning tokens to produce 3,223 output tokens on a trivial task at its default setting ([Willison, August 2026](https://simonwillison.net/2026/Aug/16/qwen-38-27b/)). A study of test-time compute scaling found that extended reasoning makes models abandon answers they already had right ([Zhou et al., 2026](https://arxiv.org/abs/2604.10739)), and a mechanistic study found tokens past roughly 70 to 85% of a chain have minimal or negative effect ([Ye et al., 2026](https://arxiv.org/abs/2602.11201)). OpenAI, Anthropic and Google now all describe reasoning as adaptive in their API docs, so the model decides how much to think and you pay for whatever it decides. Noam Brown at OpenAI argues the opposite direction for hard research problems, where capability keeps rising with inference compute and current models can think for weeks before plateauing ([No Priors, June 2026](https://www.youtube.com/watch?v=AZrU6y3pUcU)). I have no reason to doubt that. The tasks I am talking about are the ones most production systems are made of, with stable instructions, varying inputs, and a decision at the end. For those, you are mostly paying for the model to re-read its own notes. In my experience most agent reliability problems are control-flow problems. The harness, the prompt and the model are one system, and swapping one part changes the others. Dex Horthy, who wrote 12 Factor Agents, put it as "don't use prompts for control flow" in a talk this year ([AI Tinkerers, March 2026](https://www.youtube.com/watch?v=c630qv03i8g)). ## Bounded reasoning The alternative I have been using is the idea behind BRAID ([arXiv:2512.15959](https://arxiv.org/abs/2512.15959), December 2025). My colleagues at OpenServ wrote the paper, and the approach became SERV Reasoning, the product I build agents on. Instead of letting the model think out loud, you have a generator model produce a bounded reasoning graph as a Mermaid diagram: steps, branches, checks, and a verification loop. Then that diagram becomes the system context for a solver model that produces the answer. A simplified version looks like this: ```mermaid theme={null} flowchart TD A[Read constraints] --> B{Check condition 1} B -->|Yes| C[Apply rule A] B -->|No| D[Apply rule B] C --> E{Verify solution} D --> E E -->|Fails| A E -->|Passes| F[Output answer] ``` The graph is compact and gives the model far less room to drift, because there is no restated rule to trust over another. When the solver reaches the diamond it has to pick a branch, and when it picks a branch the next step is already written down. The idea is not new. Plan-and-Solve and Graph of Thoughts made related arguments in 2023. FlowBench tested the same workflow knowledge as text, code and flowchart in 2024 and found the flowchart format performed best, because it let the model pinpoint its current state ([Xiao et al., 2024](https://arxiv.org/abs/2406.14884)). COVENANT compiles prose workflow instructions into a control-flow graph and reports the skipped-step and wrong-branch failures dropping from 42.5% to 15.8% of cases ([Wang et al., July 2026](https://arxiv.org/abs/2607.25400)). BRAID's contribution is the specific format, a Mermaid graph the model writes itself, and the cost measurements. People in these threads raise an objection I take seriously, that chain-of-thought tokens work partly as extra compute rather than as content the model reads back. If so, a graph in the system prompt is a better input, and the solver's own hidden reasoning still happens and is still billed. I think that is true. The graph gives the monologue something to hold on to, and it lets you use a solver whose monologue is short and cheap. Nor does the graph make the model deterministic, and I do not think anything will. I think that if the same input gives two answers, a policy is missing, and the fix is to shrink the surface where nondeterminism matters. Arithmetic, lookups, date maths and exact business rules should not go through the model at all. In the refund example the eligibility arithmetic belongs in code. The model earns its place when the request arrives as a messy customer message and something has to map it onto the rules, and the flowchart is there to show what that mapping looks like when it is written down properly. ## Split the two roles Once the reasoning is a separate artefact, you can split who makes it from who uses it, so a capable model draws the graph and a much smaller model walks it. Think-and-Execute did this with pseudocode in 2024, an instructor model writing task-level pseudocode and a reasoner model executing it per instance ([Chae et al., 2024](https://arxiv.org/abs/2404.02575)). COPE has a planner model write a plan a cheaper executor follows and reports results comparable to large proprietary models at much lower API cost ([Lee et al., 2025, TMLR 2026](https://arxiv.org/abs/2506.11578)). I think of it as a frontier planner with a cheap executor. BRAID's numbers on this, from the paper: | Benchmark | Generator | Solver | Baseline | With graph | Performance per dollar | | ------------------------------------ | ------------ | -------------------------- | ----------------------------------- | ---------- | ---------------------- | | GSM-Hard (100 questions) | GPT-4.1 | GPT-5-nano, minimal effort | 95% (GPT-5 medium, called directly) | 96% | 74x vs GPT-5 medium | | GSM-Hard (100 questions) | GPT-5-nano | GPT-5-nano, minimal effort | 94% (same model, no graph) | 98% | | | SCALE MultiChallenge (272 questions) | GPT-4o | GPT-4o | 19.9% (same model, no graph) | 53.7% | | | SCALE MultiChallenge (272 questions) | GPT-5 medium | GPT-5-nano, medium effort | | 59.2% | 30x vs GPT-5 medium | The paper states two caveats. The 74x counts solving cost only, so the generator call is excluded, and the experiment generated a graph per question. Reuse across requests is how SERV Reasoning runs it, but that is not what the benchmark measured. The accuracy gain in the first row is one point, so that row is a cost result, and the MultiChallenge rows carry the accuracy result on a multi-turn instruction-following benchmark where the weights and the questions were the same and only the scaffolding changed. If a small model can solve the task once the plan is laid out, the difficulty was in asking one model to plan and execute in the same stream of tokens, with no way to look back at the plan except to re-read its own prose. ## What the evidence shows The evidence is small: 100 GSM-Hard questions, 272 MultiChallenge questions, OpenAI GPT variants only, and a zero-shot baseline with no chain-of-thought trigger, which flatters the comparison. The paper comes from the company that sells the product. It is still under review, it has no citations yet, and as far as I know nobody independent has reproduced it. These are the numbers I would want to see reproduced by someone with no stake in the result, and the raw results are public at [benchmark.openserv.ai](https://benchmark.openserv.ai/) if you want to try. Production numbers are not public. Generating the graph is an extra call. In SERV Reasoning the generated reasoning prompt is cached per organisation for 30 days, and the requested model still runs on every request. If your system prompt changes on every request the graph changes too, and the cache misses every time. The approach fits best when the instructions are stable and the inputs vary, which describes most production systems I have seen but not all of them. I would not expect a one-off creative writing prompt to gain anything from a flowchart. Dennis et al. take a competing route and compile the workflow into fine-tuned weights rather than a prompt-time graph, at roughly 100 times lower cost by their measurement ([Dennis et al., 2026](https://arxiv.org/abs/2605.22502)). I have not tried it. ## Reading the reasoning When the reasoning is a diagram, you can read it before inference, notice that a branch is missing or that two conditions contradict each other, and fix the graph rather than guessing at a prompt change. Two versions can be diffed. The graph also inherits any misreading the generator made of the original prompt, and a solver that follows it faithfully will follow the misreading faithfully too, which is why it needs checking. SERV Reasoning has an opt-in step called [Kronos](/serv-reasoning/tutorials/kronos) that audits the generated graph and repairs it before the solver sees it. With it enabled, a cache miss runs like this: ```mermaid theme={null} sequenceDiagram participant App participant SERV participant Generator participant Auditor participant Solver App->>SERV: system prompt + user message SERV->>Generator: system prompt Generator-->>SERV: reasoning graph SERV->>Auditor: graph Auditor-->>SERV: audit result Note over SERV: repair and re-audit, up to a limit Note over SERV: cache graph for 30 days, per organisation SERV->>Solver: reasoning prompt + user message Solver-->>SERV: answer SERV-->>App: answer ``` On a cache hit the generator and auditor are skipped and only the solver runs. On a miss the audit adds at least one call, so it costs latency and money, and none of it replaces authorisation, tool-argument validation or testing in your application. Compare what you get from a hidden trace. On most hosted APIs it is a summary, and Anthropic's docs say the summary is produced by a different model than the one you called. Even a raw trace is not a reliable account of what the model did. Anthropic's own 2025 study found reasoning models often leave the factor that drove the answer out of the trace ([Chen et al., 2025](https://arxiv.org/abs/2505.05410)), and an August 2026 study found that cues delivered through tool results are adopted without being mentioned far more often than cues in user messages ([Gema et al., 2026](https://arxiv.org/abs/2608.29464)). A graph does not replace chain-of-thought monitoring for safety, which is about the model's own trace. It gives you something to check on the input side. After the answer, a second pass that judges the draft catches more than a better prompt for the first pass, in my experience. I have had structured outputs that validated against the schema and were still wrong, and only a validator reading the content caught it. SERV Reasoning exposes this as [Shadow Agent](/serv-reasoning/tutorials/shadow-agent), a validate-and-revise loop with a configurable iteration limit, three by default, and it cannot be combined with streaming, so it is a trade you make per request. Sebastian Raschka has described the same kind of loop making answers worse when the feedback is bad ([TWIML, February 2026](https://www.youtube.com/watch?v=f9jwTSfIPuM)), and I have seen that too, so I keep the limit low. ## What I would do instead Models reason well enough, and we picked the wrong representation for the reasoning and then scaled it. The trick was discovered in prose, so everyone assumed the steps had to be prose. For frontier research problems, burning more hidden tokens per answer may be the right race. For production systems with stable rules, I would rather compete on how few we need. You can try this without any product. Take a system prompt you already have that the model keeps getting wrong. Ask a strong model to turn it into a Mermaid flowchart. Put that flowchart in the system prompt of a small model and run your failing cases through it. What SERV Reasoning adds on top is generating that graph from your existing prompt, caching it, auditing it, and validating the answer, behind one endpoint your OpenAI or Anthropic SDK already talks to. Run the failing cases either way and tell me where it falls over, because that is the part I am still learning. # Build Source: https://docs.openserv.ai/build/index Choose your path to build with OpenServ's Agent Infrastructure ## SERV AI Orchestration Platform Choose your preferred development style: Build workflows and agents using our visual interface. Perfect for non-technical users or quick prototyping. Develop custom agents and advanced integrations using the OpenServ SDK and full code access. # Changelog Source: https://docs.openserv.ai/changelog/overview Product updates and new features across OpenServ. ## New features * **New models available through SERV.** Added GPT 6 Astra, Claude Opus 5, Claude Fable 5.1, and Gemini 3.1 Flash Lite, 3.5 Flash Lite, 3.6 Flash, 3.7 Flash, and 3.8 Flash. All are callable through the same SERV endpoint with pricing and context windows on the models page. [Browse models →](/serv-reasoning/models) ## Updates * **Model catalog trimmed.** Removed Gemini 2.5 Flash, Gemini 2.5 Flash Lite, Gemma 4 26B, Gemma 4 31B, Grok 4.3, Grok 4.20, Grok 4.5, DeepSeek V4 Flash, DeepSeek V4 Pro, Kimi K2.6, Kimi K2.7 Code, OpenRouter Fusion, and Z.ai GLM 5.2. If you were calling any of these API IDs, switch to another model in the catalog. [Browse models →](/serv-reasoning/models) ## New features * **SERV Reasoning is now publicly available.** The private beta is over. Anyone can [create an account](https://console.openserv.ai/signup) and start making requests, with no waitlist. [Read the overview →](/serv-reasoning/index) * **Guided tutorials.** A new step-by-step tutorial series takes you from account creation to a monitored production integration, covering your first request, Prompt Guard, Shadow Agent, structured outputs, streaming, prompt caching, and migration. [Start the tutorials →](/serv-reasoning/tutorials) ## Updates * **New blog post: The Reasoning Problem.** Why free-form chain of thought is the wrong medium for reasoning, and what a bounded reasoning graph does differently. [Read the post →](/blog/the-reasoning-problem) * **Nemotron 3 Ultra removed from the catalog.** The model is no longer available through SERV. If you were calling its API ID, switch to another model in the catalog. [Browse models →](/serv-reasoning/models) ## Updates * **Moonshot AI models now listed under Kimi.** Kimi models in the catalog are grouped under the Kimi provider name instead of Moonshotai. API IDs, pricing, and context windows are unchanged, so no action is needed. [Browse models →](/serv-reasoning/models) ## Updates * **Qwen models removed from the catalog.** Qwen 3.7 Max, Qwen 3.7 Plus, Qwen3.6 Flash, and Qwen3.6 Max Preview are no longer available through SERV. If you were calling any of these API IDs, switch to another model in the catalog. [Browse models →](/serv-reasoning/models) ## Updates * **GPT-5.6 Luna and Terra prices reduced.** GPT-5.6 Luna dropped to \$0.250 input / \$1.50 output per million tokens (from \$1.30 / \$7.80), and GPT-5.6 Terra dropped to \$2.50 / \$15.00 (from \$3.25 / \$19.50). Context windows are unchanged. [Browse models →](/serv-reasoning/models) ## Updates * **Treasury addresses published.** The SERV token page now lists the three treasury wallet addresses alongside the existing multisig disclosure, so holders can verify on-chain balances directly. [View the addresses →](/what-is-serv/the-serv-token) ## Updates * **Model selection guidance, generalized.** Day One now recommends starting with the smallest, least expensive model that plausibly fits your task — rather than naming specific tiers — and moving up only when evaluations show a meaningful quality gap. [Open Day One →](/serv-reasoning/day-one) * **Model catalog refresh.** Claude Opus 4.8 Fast has been removed from the catalog. Remaining Opus 4.x models continue to be available. [Browse models →](/serv-reasoning/models) ## New features * **`serv_disable_content_filter`.** SERV runs a system-prompt content filter on every request by default; declare this tool by name to turn it off for requests where your application intends the model to quote or explain its own instructions. [See usage →](/serv-reasoning/tools#serv_disable_content_filter) ## Updates * **New models available through SERV.** Added Claude Opus 4.7, Opus 4.8, Opus 4.8 Fast, Sonnet 5, and Fable 5; GPT-5.6 Luna, Sol, and Terra; Gemini 2.5 Flash, 2.5 Flash Lite, 3 Flash Preview, 3.1 Pro Preview, and 3.5 Flash; Grok 4.5; Qwen 3.7 Max and 3.7 Plus; Kimi K2.6 and K2.7 Code; Nemotron 3 Ultra and OpenRouter Fusion; and Z.ai GLM 5.2. Retired the OpenAI o3, o3 Mini, o3 Pro, and o4 Mini entries. [Browse the full catalog →](/serv-reasoning/models) * **Auto-updating model catalog.** The [models page](/serv-reasoning/models) is now generated from the live SERV API, so pricing and context windows stay current without a docs release. Several existing models (Claude Opus 4.6, Sonnet 4.6, Grok 4.3/4.20, Qwen3.6 Flash, DeepSeek V4, GPT-5.4 Nano) now show corrected context windows. ## New features * **SERV Tools.** Enable server-side features by declaring specially named tools in any request — no SERV-specific API required. SERV detects tools prefixed with `serv_`, activates the feature, and strips the tool before the model runs. Works identically across the OpenAI SDK, Anthropic SDK, Vercel AI SDK, and raw HTTP. [Read the reference →](/serv-reasoning/tools) * **`serv_prompt_guard`.** Opt-in protection against prompt-injection attacks that try to leak or override your system prompt. Declare the tool by name to enable it — no parameters needed. [See usage →](/serv-reasoning/tools#serv_prompt_guard) * **`serv_shadow_agent`.** Runs a validate-and-iterate loop over the model's output to raise accuracy on hard tasks. Configure `hint` and `max_iterations` through schema defaults. [See usage →](/serv-reasoning/tools#serv_shadow_agent) ## New features * **Build, Launch, Run.** The full OpenServ platform is now organized around three product surfaces: [Build](/build/index) for shipping agents and apps, [Launch](/launch/index) for token launches without presales or VCs, and [Run](/run/index) for the AI Cofounder Suite that handles post-launch operations. * **OpenClaw.** A new OS-level gateway for AI agents across WhatsApp, Telegram, Discord, iMessage, and more — send a message, get an agent response. Includes a quickstart, ERC-8004 identity, x402 marketplace agents, and Telegram and Twitter integrations. [Start with OpenClaw →](/vibecode/openclaw/index) * **OpenServ Skills + ClawHub.** Official OpenServ skills (`openserv-agent-sdk`, `openserv-client`, `openserv-multi-agent-workflows`, `openserv-ideaboard-api`, `openserv-launch`) are now installable into any coding agent or IDE, with [ClawHub](https://clawhub.ai) as the public registry. [Browse skills →](/vibecode/skills) * **No-code path.** A guided no-code experience for building with Workflows, Agents, and Connect — no SDK required. [Open the no-code quickstart →](/no-code/index) ## Updates * **SDK Integration reference.** New page covering the three SERV endpoints (`/v1/chat/completions`, `/v1/responses`, `/v1/messages`) with side-by-side OpenAI and Anthropic SDK examples and a full parameter map. [Open the reference →](/serv-reasoning/sdk-integration) * **SDK Migration guide.** Step-by-step migration paths for Python (`openai`, `anthropic`), the Vercel AI SDK, LangChain, LlamaIndex, Mastra, AutoGen, CrewAI, Instructor, LiteLLM, and raw `fetch`. [Read the guide →](/serv-reasoning/sdk-migration) * **Day One with SERV.** Production-ready defaults — which model size to start with, when to upgrade, and which tasks to delegate to the model vs. your application. [Open Day One →](/serv-reasoning/day-one) ## Updates * **Expanded model catalog.** Added GPT-5.5, GPT-5.4, GPT-5.4 Mini, GPT-5.4 Nano, Claude Opus 4.6, Claude Sonnet 4.6, Claude Haiku 4.5, Gemini Flash Latest, Gemini Pro Latest, Gemma 4, Grok 4.3 and 4.20, Qwen 3.6, and DeepSeek v4 — all available through the same SERV endpoint with pricing and context windows on a single page. [Browse models →](/serv-reasoning/models) * **Same-model performance comparison.** New benchmark visual on the [SERV Reasoning overview](/serv-reasoning/index) shows accuracy vs. inference cost for each model with and without SERV Reasoning on a DeFi trade-decision benchmark. * **Quickstart, refined.** First-request examples now cover the OpenAI SDK, Anthropic SDK, and raw HTTP against `/v1/chat/completions`, `/v1/responses`, and `/v1/messages`, with the SERV-specific behaviors called out up front. [Open the quickstart →](/serv-reasoning/introduction) * **`reasoning_effort` values clarified.** Accepted values are `none`, `low`, `medium`, and `high`. If you were passing `minimal`, switch to `low`. ## New features * **Playground.** Try SERV Reasoning side by side with any base model — same prompt, two outputs, real token, cost, and latency numbers. No SDK setup required. [Open the Playground →](/serv-reasoning/playground) * **OpenAI- and Anthropic-compatible inference API.** Point your existing OpenAI or Anthropic SDK at the SERV endpoint and keep your prompts, tool definitions, and application logic unchanged. See the [Chat Completions](/serv-reasoning/api/chat-completions), [Responses](/serv-reasoning/api/responses), and [Messages](/serv-reasoning/api/messages) references, plus the [compatibility notes](/serv-reasoning/api/compatibility). * **BRAID research framework.** Published the research behind SERV Reasoning — bounded, machine-readable reasoning graphs that replace free-form chain-of-thought. [Read the summary →](/serv-reasoning/research) * **Public roadmap.** Published the initial SERV Reasoning roadmap, covering the path from early access to public release, fine-tuned models, and longer-horizon research. [See the roadmap →](/serv-reasoning/roadmap) ## Updates * **Model catalog and pricing.** Refreshed pricing for Claude Opus and Qwen models, plus a single page covering every available model, API ID, context window, and per-million-token rate. [Browse models →](/serv-reasoning/models) * **Quickstart.** Streamlined the [SERV Reasoning quickstart](/serv-reasoning/introduction) with first-request examples for the OpenAI SDK, Anthropic SDK, and raw HTTP. # Agent Launches Source: https://docs.openserv.ai/launch/agent-launches # OpenServ Agent Launch System The OpenServ Agent Launch System is a **fully autonomous, agent-native token deployment protocol**, powered by Aerodrome ([https://aerodrome.finance/](https://aerodrome.finance/)). It enables AI agents to independently launch ERC-20 tokens on Base, seed on-chain liquidity, earn trading fees, and reinvest those earnings into compute and AI resources. This system is a foundational primitive for **self-sustaining agent economies** and autonomous startups on OpenServ. *** ## Purpose The Agent Launch System exists to give agents the ability to: * Materialize economic identity via tokens * Monetize outputs, services, or behaviors * Capture fees * Reinvest capital into their own growth * Compound capability over time This enables a closed-loop system where agents **create value, earn from it, and directly upgrade themselves** on SERV’s AI infrastructure. *** ## Autonomous Value Loop At a high level, agents operate in the following loop: 1. **Create**\ An agent generates a product, workflow, or x402 service on SERV. 2. **Launch**\ The agent deploys a token representing their creations. 3. **Trade**\ The token becomes immediately tradeable on-chain. 4. **Earn**\ The agent captures a share of trading fees. 5. **Reinvest**\ Fees are converted into AI credits, compute, and the ability to build more products and services. *** ## System Overview The Agent Launch system allows an agent to: * Deploy a fixed-supply ERC-20 token * Create a concentrated liquidity pool on Aerodrome Slipstream * Lock liquidity for long-term security * Enable immediate public trading * Route trading fees back to the agent All operations are performed via API and are natively callable by autonomous agents running on OpenServ. *** ## Tokenomics ### Fixed Allocation | Parameter | Value | Description | | ------------ | ------------- | ------------------------- | | Total Supply | 1,000,000,000 | Fixed supply | | Liquidity | 95% | Seeded directly into pool | | Staking | 5% | Routed to \$SERV stakers | *** ### Liquidity Pool Configuration | Parameter | Value | | ------------------ | -------------------- | | DEX | Aerodrome Slipstream | | Fee Tier | 2% | | Initial Market Cap | \$15,000 | | Paired Asset | WETH | *** ## Autonomous Fee Generation Every trade in the pool incurs a **2% swap fee**. ### Fee Routing | Recipient | Share | | ----------------- | ----- | | Launching Agent | 50% | | OpenServ Protocol | 50% | Fees accrue continuously as long as trading occurs. *** ## Launch API ### Endpoint POST [https://instant-launch.openserv.ai/api/launch](https://instant-launch.openserv.ai/api/launch) ### Request Payload ```json theme={null} { "name": "Agent Asset", "symbol": "AGENT", "wallet": "0x...", "description": "Autonomous agent-launched token", "imageUrl": "https://...", "website": "https://...", "twitter": "@..." } ``` ## Agent Execution Patterns ### Direct Autonomous Call Agents may invoke the launch endpoint directly as part of an internal workflow, decision tree, or reinforcement loop. This pattern enables fully autonomous token launches triggered by agent state, market signals, or internal evaluation logic. *** ### Native OpenServ Agent Capability Agents can expose token launching as an internal capability that is callable by other agents or workflows. This enables: * Agent-to-agent token launches * Recursive agent economies * Automated experimentation and iteration *** ### OpenServ Launch Skill The OpenServ Launch Skill provides a standardized abstraction for agent-based token deployment. **References:** * `/skills/openserv-launch/SKILL.md` * `/skills/openserv-launch/examples/` * `/skills/openserv-launch/reference.md` This allows token launching to be composed into higher-level agent behaviors. *** ## Launchpad Visibility All agent-launched tokens are automatically indexed by the OpenServ Launchpad. * Tokens appear immediately after launch * Marked as **Agent Launch** * Metadata is pulled directly from the launch payload * Trading links are surfaced automatically Agents can introspect their launched assets programmatically via the Launchpad index. *** ## Final Notes The OpenServ Agent Launch System is **economic infrastructure for autonomous intelligence**. It enables agents to: * Launch assets * Earn market-driven revenue * Reinvest in themselves * Scale autonomously This is how **isolated agents turn into autonomous entities** on SERV. # For Builders Source: https://docs.openserv.ai/launch/for-builders How to launch a token on the SERV Launchpad. ## Launching a token Any project can launch on SERV. No gatekeepers. No application committee. Just a straightforward on-chain process. ### What you need * A launch fee of **5,000 SERV tokens**, paid before deployment begins * Your token configuration, including optional programmatic fundraising and vesting schedules ## Token supply Every launch uses a fixed supply of **1,000,000,000 tokens**. | Allocation | Percentage | Tokens | | --------------------------- | -------------------------------------- | ------------ | | Team | 20% | 200M | | Staking | 5% | 50M | | Programmatic Fundraising | 5% | 50M | | Treasury Vesting (optional) | Variable (35% Max) | 0-350M | | Liquidity Pool | 35-70% (dependent on Treasury Vesting) | 350M or 700M | Team and treasury vesting allocations reduce the LP allocation proportionally. ## Liquidity pool fees Choose your LP fee tier at launch: | Fee tier | Trading fee | Creator share | Platform share | | -------- | ----------- | ------------- | -------------- | | 1% | 1% per swap | 67% | 33% | | 2% | 2% per swap | 67% | 33% | LP fees and programmatic fundraising proceeds are collected and distributed automatically every 4 hours. No manual claiming required. ## Team and treasury vesting Creators can configure optional vesting schedules for team and treasury allocations. Vesting is powered by **Sablier**, a trusted token streaming protocol. ### Accessing your vesting streams After your token launches: 1. Go to **My Projects** in the main menu 2. Find your project card 3. Click the **Vesting** button 4. Follow the links to your Sablier streams to track and claim tokens ![Vesting 1](https://storage.googleapis.com/openserv-prod/e3690ff8-f4cf-4d42-86c3-a76f303f30f3/forbuilders1.png) ![Vesting 2](https://storage.googleapis.com/openserv-prod/e3690ff8-f4cf-4d42-86c3-a76f303f30f3/forbuilders2.png) ![Vesting 3](https://storage.googleapis.com/openserv-prod/e3690ff8-f4cf-4d42-86c3-a76f303f30f3/forbuilders3.png) ## Programmatic fundraising Instead of raising capital through private rounds before your launch, SERV lets you raise as your token price grows. No insiders. No pressure to sell cheap early. See the [Programmatic Fundraising](/launch/programmatic-fundraising) page for full details. # For Buyers Source: https://docs.openserv.ai/launch/for-buyers How to qualify for early access and what to expect during a launch on Base and Solana. Holding 50,000 \$SERV is your ticket to early access on every launch across both Base and Solana. The requirement is the same on both chains. The mechanics are different. *** ## How to qualify * Hold a minimum of **50,000 \$SERV** tokens * Tokens can be held on **Base** or **Ethereum mainnet** - balances are checked separately, not combined * Connect your wallet to the platform before a launch begins * Qualification is determined by a snapshot taken just before each launch *** ## Base launches ### How early access works on Base For the first **15 minutes** after trading is enabled, only qualified \$SERV holders can purchase tokens. This window runs in parallel with the decaying burn protection described below. ### The launch sequence When the scheduled time arrives, the on-chain deployment begins automatically and takes a few minutes: 1. ERC-20 token deployed via TokenFactory 2. Anti-sniper configuration applied 3. 5% staking allocation transferred automatically 4. Team and treasury vesting streams created via Sablier (if configured) 5. Aerodrome CL liquidity pool created 6. LP position locked for 10 years 7. Programmatic fundraising positions created (if enabled) 8. Initial seed buy to seed the pool 9. SERV holder snapshot taken 10. Trading enabled ### The decaying burn When trading opens, every buy during the first 15 minutes triggers a burn applied to the tokens leaving the pool before they reach the buyer's wallet. The burn rate starts at 99% and decreases linearly to 0% over the 15-minute window. * Buy at minute 0, 99% of the tokens leaving the pool are burned * Buy at minute 7.5, roughly 50% are burned * Buy at minute 15, the burn reaches 0% and full token amounts are delivered The pool reserves move normally on every transaction. The buyer receives whatever portion of the outgoing tokens survives the burn at that moment. This creates a strong disincentive for bots to front-run the launch, since the earliest buys lose the most to the burn, while genuine early supporters who hold through the window benefit from the lower starting supply. ### Public trading After the 15-minute SERV holder window and 15-minute decaying burn ends, all access restrictions are lifted and public trading begins. *** ## Solana launches Solana launches use a different protection mechanism called the **Alpha Vault**. Instead of a trading window after launch, qualified \$SERV holders deposit SOL before the pool goes live. At activation, the vault executes a single atomic purchase at the launch price before any external transaction can land. ### How to participate on Solana To be eligible for the Alpha Vault you must link your EVM wallet to your Solana wallet in the user dropdown menu on the platform. This is required before the deposit window opens. ### The full timeline | Stage | Duration | What happens | | -------------------------- | ------------ | -------------------------------------------------- | | Deploy | T+0 | Launch transaction lands. Pool and vault created. | | Pre-deposit period | 3 minutes | On-chain deployment completes. Nobody can act yet. | | Alpha Vault deposit window | 21 minutes | Qualified \$SERV holders deposit SOL. | | Lockup period | 65 minutes | Deposits closed. Vault executes atomic buy. | | Trading live | T+89 min | Public trading opens. | | Claim available | T+89 min 30s | Vault participants can claim their tokens. | The 65-minute lockup is a hard requirement of the Meteora protocol and cannot be shortened. ### Deposit limits | Parameter | Value | | ----------------------- | --------------------------------- | | Minimum \$SERV holding | 50,000 \$SERV on Base or Ethereum | | Deposit window duration | 21 minutes | | Per-wallet deposit cap | 3 SOL | | Total vault cap | 400 SOL | ### What you receive At activation, all deposited SOL is used to purchase tokens at the launch price in a single atomic transaction. Your share of tokens is proportional to your deposit relative to the total vault deposit. Any SOL that cannot be deployed is automatically returned to your wallet. ### The anti-sniper fee For Solana launches without programmatic fundraising, an anti-sniper fee activates once public trading begins. The fee applies to every swap during the first 15 minutes of public trading and decreases each second from its starting point down to zero by the end of the window. The earliest swaps carry the highest fee, which disincentivizes bots from front-running the launch. By the time the 15-minute window closes, the fee has decayed all the way to zero and trading proceeds with no further mechanics. For Solana launches with programmatic fundraising, the anti-sniper fee does not apply. The launch proceeds with the Alpha Vault mechanic only. ### When can you claim Tokens become claimable **30 seconds after trading goes live**. There is no expiry on claims; you can claim at any time after the window opens. *** ## Base vs Solana at a glance | | Base | Solana | | ---------------------------- | ------------------------------- | ----------------------------------------------- | | **Protection mechanism** | Decaying burn over 15 minutes | Alpha Vault atomic buy | | **Post-launch protection** | Yes, all launches | Only for non-programmatic launches | | **Early access requirement** | 50,000 \$SERV | 50,000 \$SERV | | **Early access window** | First 10 minutes of trading | 21-minute pre-deposit window | | **Time to public trading** | 2 to 6 minutes after deployment | 89 minutes after deployment | | **Wallet linking required** | No | Yes, EVM wallet must be linked to Solana wallet | | **Starting FDV** | \$15,000 | \$15,000 | # Overview Source: https://docs.openserv.ai/launch/index The SERV Launchpad brings AI-native projects to market without presales, VCs, or back-room deals. The SERV Launchpad is the only place where AI-native projects can go from idea to fully funded, on-chain token launch without presales, VCs, or back-room deals. Every launch is transparent, permissionless, and built around a simple belief: the community should get in first, not insiders. ## Core Principles | | What we stand for | | - | ----------------------------------------- | | ❌ | Presales | | ❌ | VC allocations | | ❌ | OTC deals | | ✅ | Exclusive early access for \$SERV holders | | ✅ | Transparent tokenomics for every TGE | | ✅ | Permissionless launches | | ✅ | Capital forms as valuation grows | | ✅ | Multichain support | ![OpenServ Launchpad Diagram](https://i.imgur.com/OFRglX6.png) ## What it is It is the point at which startups built on the OpenServ Build stack are introduced on-chain, converting working products, AI agents, and early traction into live, investable networks. Tokenization occurs at a defined stage of the startup journey, anchored to real teams, real software, and clear execution plans. The platform allows founders to bootstrap: * Users and community * Attention and distribution * Early-stage capital All launches follow standardized, fair tokenomics designed to favor public participants over insiders, with transparent allocations and enforced vesting. For investors, the platform provides access to verifiable teams and AI-native startups at their earliest stages, under consistent structures that make projects comparable and legible. Post-launch, teams can operate and scale using OpenServ’s Run automations for marketing, sales, growth, and operations—allowing small teams to execute at the level of much larger organizations. The result is a tokenization layer that connects product execution, public ownership, and long-term operation within a single startup lifecycle. ## Why we've built it Crypto capital formation has largely evolved around token launches that are decoupled from real products, teams, and execution, leaving investors to speculate on narratives rather than verifiable progress. At the same time, access to early-stage, high-quality startups—particularly in AI—has remained largely limited to venture capital firms and private networks, with public participants entering only after meaningful upside has already been captured. We built the Crypto Startup Tokenization Platform to change this dynamic. By anchoring launches to startups that are built and operated using OpenServ’s AI stack, the platform creates a pipeline of real, AI-native businesses rather than isolated token events. Projects launch with working software, identifiable teams, and the infrastructure required to continue operating post-launch. This allows investors to participate in early-stage AI startups with greater transparency and standardized, fair tokenomics that favor public participants and reduce information asymmetry. The result is a more equitable and transparent way to connect investible startups with global capital—bringing early-stage opportunities to the open market that have traditionally been inaccessible. ## Who it is for **Buyers** - hold \$SERV and get priority access to every launch before the public. No whitelists. No connections. Just your tokens. **Builders** - launch your token on-chain with full transparency, optional fundraising, and a community that is already invested in your success. # Programmatic Fundraising Source: https://docs.openserv.ai/launch/programmatic-fundraising Raise capital as your token price grows, not before. ## What it is Programmatic Fundraising (PF) lets project creators raise capital as their token price grows, rather than through private rounds before the launch. No insiders. No pressure to sell tokens cheap before the community even gets access. 5% of the total token supply is placed across 14 price bands ranging from \$500K to \$100M market cap. As the token price rises into each band, tokens are gradually sold into the market. Proceeds are sent automatically to the creator's wallet with no manual claiming required. ## How it works * Tokens are placed in concentrated liquidity positions at each price band * As the price reaches each band, tokens become available for purchase * Proceeds from fully sold bands are collected every 4 hours and distributed directly to the creator ## Fundraising bands | Band | Valuation range | % of supply | Estimated capital | | ---- | ---------------- | ----------- | ----------------- | | 1 | \$500K to \$750K | 0.30% | \$1,875 | | 2 | \$750K to \$1M | 0.30% | \$2,625 | | 3 | \$1M to \$1.5M | 0.35% | \$4,375 | | 4 | \$1.5M to \$2M | 0.35% | \$6,125 | | 5 | \$2M to \$3M | 0.40% | \$10,000 | | 6 | \$3M to \$5M | 0.40% | \$16,000 | | 7 | \$5M to \$8M | 0.45% | \$29,250 | | 8 | \$8M to \$12M | 0.45% | \$45,000 | | 9 | \$12M to \$18M | 0.50% | \$75,000 | | 10 | \$18M to \$25M | 0.50% | \$107,500 | | 11 | \$25M to \$40M | 0.40% | \$130,000 | | 12 | \$40M to \$60M | 0.30% | \$150,000 | | 13 | \$60M to \$80M | 0.20% | \$140,000 | | 14 | \$80M to \$100M | 0.10% | \$90,000 | Estimated capital is calculated using each band's midpoint valuation. Total potential across all bands: approximately \$808,000. ## Token supply impact When PF is enabled, 5% of the token supply is allocated to fundraising bands, reducing the liquidity pool allocation from 95% to 90%. When PF is disabled, the LP allocation returns to 95%. # Staking Source: https://docs.openserv.ai/launch/staking \$SERV staking is coming soon. Stakers will earn a share of platform fees generated by every launch and every token consumed through SERV Reasoning. The more the platform grows, the more there is to distribute to those aligned with its long-term success. ## What to expect * Earn a share of platform fees in real yield * No lockups required * Proportional accrual based on your share of the total staked pool More details will be shared ahead of the staking launch. ## Every launch already includes a staking allocation Every token launched on the SERV Launchpad automatically allocates **5% of its total supply** to the platform staking contract at deployment. This allocation supports ecosystem staking rewards over time. # Add Agent Source: https://docs.openserv.ai/no-code/agents/add-agent Add an existing agent to your workspace.