AI Coding Assistants Integration¶

Connect your favorite AI coding assistants to Amazon Bedrock models through stdapi.ai—three client-side changes: the base URL, the API key, and — where the name differs from what the assistant already sends — the model name, now picked from every provider in the catalogue rather than one vendor's list. Get intelligent code completions, chat assistance, and codebase understanding with powerful AWS models like Claude, Kimi thinking, and Qwen3 Coder Next—no vendor lock-in required.

About AI Coding Assistants¶

AI coding assistants are IDE extensions and terminal tools that leverage large language models to enhance developer productivity. These tools provide real-time code completions, intelligent suggestions, natural language code generation, and interactive chat capabilities directly within your coding environment—acting as AI pair programmers that understand your codebase context.

What AI coding assistants can do:

• Real-time completions - Autocomplete code as you type with context awareness
• Interactive chat - Ask questions about your codebase, get explanations
• Code generation - Natural language to code conversion
• Refactoring - Intelligent code improvements and optimization suggestions
• Documentation - Auto-generate comments, docstrings, and READMEs
• Testing - Create unit tests, debug issues, suggest fixes
• Git integration - Generate commit messages, review diffs
• Multi-language - Support for Python, JavaScript, TypeScript, Go, Rust, Java, and more

Why AI Coding Assistants + stdapi.ai?¶

%%{init: {'flowchart': {'htmlLabels': true}} }%%
flowchart LR
  ide["<img src='../styles/logo_vscode.svg' style='height:64px;width:auto;vertical-align:middle;' /> IDE + AI Assistant"] --> stdapi["<img src='../styles/logo.svg' style='height:64px;width:auto;vertical-align:middle;' /> stdapi.ai"]
  stdapi --> bedrock["<img src='../styles/logo_amazon_bedrock.svg' style='height:64px;width:auto;vertical-align:middle;' /> Amazon Bedrock"]

Connect Your Own Instance¶

Point any coding assistant—CLI, IDE plugin, or terminal tool—at your stdapi.ai gateway, wherever it runs. Nothing below requires the AWS sample in Part 2.

Prerequisites¶

OpenAI-Compatible Coding Assistants¶

Popular Tools: Cline | OpenCode | Pi Agent | OpenAI Codex CLI | Qwen Code | Zed | JetBrains AI Assistant

Most IDE coding assistants use the OpenAI-compatible API. Configure them by pointing to stdapi.ai's /v1 endpoint.

Configuration¶

Most AI coding assistants follow a similar configuration pattern. The exact menu location and field names may vary, but the core settings remain consistent.

[model_providers.stdapi]
name = "stdapi.ai"
base_url = "https://YOUR_STDAPI_URL/v1"
env_key = "STDAPI_API_KEY"
wire_api = "responses"

[profiles.stdapi]
model_provider = "stdapi"
model = "anthropic.claude-fable-5"
# Codex asks for web search on every request unless this is set.
web_search = "disabled"

export OPENAI_API_KEY=YOUR_STDAPI_KEY
export OPENAI_BASE_URL=https://YOUR_STDAPI_URL/v1
export OPENAI_MODEL=anthropic.claude-fable-5

{
  "security": {
    "auth": {
      "selectedType": "openai"
    }
  }
}

{
  "providers": {
    "stdapi": {
      "baseUrl": "https://YOUR_STDAPI_URL/v1",
      "api": "openai-completions",
      "apiKey": "YOUR_STDAPI_API_KEY",
      "models": [
        { "id": "anthropic.claude-fable-5" }
      ]
    }
  }
}

pi --model stdapi/anthropic.claude-fable-5

Chat Completions¶

All coding assistants use chat completions for interactive conversations, code generation, and explanations.

Tool Calling Support¶

stdapi.ai fully supports tool calling (function calling) through the chat completions API, which is essential for autonomous and efficient coding agents.

Code Completions¶

Some coding assistants support dedicated code completion endpoints for real-time suggestions as you type.

Anthropic-Compatible Coding Assistants¶

Popular Tools: Claude Code | OpenCode | Zed | Factory Droid

Tools that use the Anthropic messages API natively can be connected to stdapi.ai's /anthropic endpoint, enabling them to use Claude models via Amazon Bedrock.

Claude Code¶

Claude Code is Anthropic's agentic coding tool that runs in the terminal.

Configuration¶

Create or edit ~/.claude/settings.json:

{
  "env": {
    "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY",
    "ANTHROPIC_BASE_URL": "https://YOUR_STDAPI_URL/anthropic",
    "ANTHROPIC_DEFAULT_FABLE_MODEL": "anthropic.claude-fable-5",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "anthropic.claude-opus-5",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "anthropic.claude-sonnet-5",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "anthropic.claude-haiku-4-5-20251001-v1:0"
  }
}

• Replace YOUR_STDAPI_URL with your stdapi.ai deployment URL (e.g., https://api.example.com or http://localhost:8000 for local)
• Replace YOUR_API_KEY with your stdapi.ai API key
• The /anthropic path prefix is configured via the ANTHROPIC_ROUTES_PREFIX setting (default: /anthropic)
• The ANTHROPIC_DEFAULT_*_MODEL variables pin each model tier to a specific Bedrock model ID, so Claude Code stops resolving the fable/opus/sonnet/haiku aliases itself — an alias moves to a new model whenever Anthropic ships one, while a pinned model ID only changes when you edit it. Haiku's current Bedrock ID carries a dated snapshot (claude-haiku-4-5-20251001-v1:0) for the most granular pin; Sonnet, Opus, and Fable 5 don't yet have a separate dated ID in the Bedrock catalog, so pinning to their generation ID (e.g. anthropic.claude-sonnet-5) is the most specific option available today. stdapi.ai also accepts the short alias names (e.g. claude-sonnet-5) as a convenience.

Effort-Based Reasoning¶

Claude Code supports effort levels that control how much reasoning the model applies — lower effort is faster and cheaper; higher effort provides deeper thinking for complex tasks.

Supported models via stdapi.ai:

Setting effort level:

# Per session at launch
claude --model sonnet --effort high

# Persist across sessions (env var takes precedence over all other settings)
export CLAUDE_CODE_EFFORT_LEVEL=high

# Or add to claude.json

{
  "effortLevel": "medium"
}

During a session, use /effort low, /effort medium, /effort high, or /effort max to change levels on the fly.

Declaring Model Capabilities¶

When you pin a non-Claude Bedrock model ID, Claude Code may not recognize it and will silently disable effort and thinking features. Use ANTHROPIC_DEFAULT_*_MODEL_SUPPORTED_CAPABILITIES to declare what the model actually supports:

Example — Nova 2 with effort enabled:

{
  "env": {
    "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY",
    "ANTHROPIC_BASE_URL": "https://YOUR_STDAPI_URL/anthropic",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "amazon.nova-2-lite-v1:0",
    "ANTHROPIC_DEFAULT_SONNET_MODEL_NAME": "Nova 2 Lite",
    "ANTHROPIC_DEFAULT_SONNET_MODEL_SUPPORTED_CAPABILITIES": "effort",
    "DISABLE_PROMPT_CACHING": "1"
  }
}

Example — Claude with full capabilities declared (e.g. for a Bedrock ARN or inference profile):

{
  "env": {
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "arn:aws:bedrock:us-east-1:123456789012:application-inference-profile/my-opus",
    "ANTHROPIC_DEFAULT_OPUS_MODEL_NAME": "Opus via Bedrock",
    "ANTHROPIC_DEFAULT_OPUS_MODEL_SUPPORTED_CAPABILITIES": "effort,max_effort,thinking,adaptive_thinking,interleaved_thinking"
  }
}

Using Non-Claude Models¶

Claude Code is optimized for Claude models and enables reasoning by default. When routing non-Claude models through stdapi.ai, incompatible reasoning parameters are silently ignored — no special configuration is needed to avoid API errors.

Models with effort support (Nova 2, DeepSeek V3) — declare effort capability:

{
  "env": {
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "amazon.nova-2-lite-v1:0",
    "ANTHROPIC_DEFAULT_SONNET_MODEL_SUPPORTED_CAPABILITIES": "effort"
  }
}

Common configuration issues with non-Claude models:

• Prompt caching — Claude Code sends cache_control headers that can cause errors on models that handle caching differently. Set DISABLE_PROMPT_CACHING=1 to suppress them.
• Output token limit — Claude Code defaults to requesting up to 32,000 output tokens, which exceeds the maximum for many non-Claude models. Set CLAUDE_CODE_MAX_OUTPUT_TOKENS to a value within the model's limit to avoid max_tokens validation errors.

{
  "env": {
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "moonshot.kimi-k2-thinking",
    "DISABLE_PROMPT_CACHING": "1",
    "CLAUDE_CODE_MAX_OUTPUT_TOKENS": "128000"
  }
}

Adding a Model to the Picker¶

Use ANTHROPIC_CUSTOM_MODEL_OPTION to add a single custom entry to the /model picker without replacing the built-in aliases. Useful for testing a specific Bedrock model ID alongside the standard Claude tiers:

{
  "env": {
    "ANTHROPIC_CUSTOM_MODEL_OPTION": "moonshot.kimi-k2-thinking",
    "ANTHROPIC_CUSTOM_MODEL_OPTION_NAME": "Kimi K2 Thinking",
    "ANTHROPIC_CUSTOM_MODEL_OPTION_DESCRIPTION": "Moonshot Kimi K2 Thinking via stdapi.ai"
  }
}

Claude Code skips validation for this model ID, so any Bedrock model ID accepted by stdapi.ai works here.

Other Anthropic-Compatible Tools¶

Any tool using the Anthropic SDK or messages API can be configured the same way—set the ANTHROPIC_BASE_URL to https://YOUR_STDAPI_URL/anthropic and ANTHROPIC_API_KEY (or equivalent) to your stdapi.ai API key.

pi also speaks this API: register its provider with api: "anthropic-messages" and the /anthropic base URL, as shown in the pi configuration above.

MCP (Model Context Protocol)¶

stdapi.ai can act as an MCP server, exposing its API endpoints as tools that MCP-capable clients call directly using the Model Context Protocol. Enable MCP on your stdapi.ai deployment by setting the appropriate environment variable:

Configuration¶

Many MCP clients—including Claude Code and Cline—configure servers via a mcpServers JSON block:

{
  "mcpServers": {
    "stdapi": {
      "type": "http",
      "url": "https://YOUR_STDAPI_URL/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

• Replace YOUR_STDAPI_URL with your stdapi.ai deployment URL (e.g., https://api.example.com or http://localhost:8000 for local)
• The Authorization header (and YOUR_API_KEY) is only required if your deployment uses API key authentication; omit the headers block for local development without a key
• For Claude Code, add this to ~/.claude.json

Tool Selection¶

By default, all tools are exposed. Restrict the tool set for better performance — LLMs work better with fewer choices, and many providers cap active tools per session.

Choose the model-calling tool by task shape:

• openai_completion (/v1/completions) — the smallest schema and smallest token footprint per tool call. Recommended for text-first coding agents: code generation, completion, refactoring, explanation, Q&A. Supports batch prompts, streaming, and a single-request multimodal collapse (["instruction", <file>, …]) for analysing screenshots or reference documents.
• openai_chat_completion (/v1/chat/completions) — use when the agent needs multi-turn conversations with system prompts, built-in function calling, or structured multimodal messages.
• openai_response (/v1/responses) — modern API with tool calling, structured output, and optional server-side storage.
• anthropic_message (/anthropic/v1/messages) — Anthropic SDK compatibility; same Bedrock models, different protocol.

Always include search_models — it lets the agent discover available model IDs dynamically rather than relying on hardcoded values. Use it instead of openai_model_list or anthropic_model_list: it returns richer metadata and supports capability-based filtering (by modality, route, region, and more).

The examples below use the OpenAI tools; replace with the matching anthropic_* tools if you prefer the Anthropic protocol.

Coding agent (text and code only) — completions, model discovery, and file operations; no image/audio, no destructive tools:

export MCP_INCLUDE_TOOLS="openai_completion,search_models,openai_embedding,openai_file,openai_file_list,openai_files_get,openai_file_content"

Coding agent with tool calling / multi-turn chat — when your agent uses OpenAI-style function calling or stateful conversations:

export MCP_INCLUDE_TOOLS="openai_chat_completion,search_models,openai_embedding,openai_file,openai_file_list,openai_files_get,openai_file_content"

Coding agent with image support — completions plus image generation and editing:

export MCP_INCLUDE_TOOLS="openai_completion,search_models,openai_embedding,openai_file,openai_file_list,openai_files_get,openai_file_content,openai_image_generation,openai_image_edit,openai_image_variation"

Coding agent with audio support — completions plus transcription, translation, and speech synthesis:

export MCP_INCLUDE_TOOLS="openai_completion,search_models,openai_embedding,openai_file,openai_file_list,openai_files_get,openai_file_content,openai_audio_transcription,openai_audio_translation,openai_audio_speech"

Coding agent with your own documentation — completions plus semantic search over a vector store holding your design docs, runbooks, or an internal API reference:

export MCP_INCLUDE_TOOLS="openai_completion,search_models,openai_vector_store_list,openai_vector_store_search,openai_file,openai_file_list,openai_files_get,openai_file_content"

openai_vector_store_search returns the matching passages with their file names and scores, so the agent looks a fact up instead of guessing at it — and it works whatever wire format the assistant chats with, since the search is a tool call rather than a request field. Indexing the corpus is a one-off, covered in the RAG Pipelines guide.

In all cases, file deletion tools (openai_files_delete, anthropic_files_delete) are intentionally omitted — add them only when your workflow explicitly requires cleanup.

See Configuration Reference → MCP for the full tool list and selection guidance.

One Key for the Team, or One Identity per Developer¶

An assistant configured with the deployment's API key makes every developer's calls indistinguishable on the AWS bill. A deployment can authenticate callers with Amazon Cognito user pool tokens instead — alongside the API key or in place of it — so each developer reaches the gateway with a credential of their own. With per-user cost attribution enabled, their model calls then run under a short-lived role session of their own, and Cost Explorer and the Cost and Usage Report show what each of them spent, from the invoice rather than an estimate.

The assistant needs no feature for this beyond sending the token it was given: whichever field holds the API key today (ANTHROPIC_AUTH_TOKEN, OPENAI_API_KEY, a provider entry) carries the access token instead. Renewal is the thing to plan for — an access token expires where an API key does not — so favour a tool that reads its credential from the environment, or from a helper command, on each run over one that stores a key once in a settings file.

Running stdapi.ai Locally¶

stdapi.ai works well when running locally with Docker, making it ideal for your development environment.

API Base URL: http://localhost:8000/v1
API Key: your_stdapi_key

ANTHROPIC_BASE_URL: http://localhost:8000/anthropic
ANTHROPIC_AUTH_TOKEN: your_stdapi_key

Deploy the Gateway on AWS¶

There is no application to deploy here, and no per-developer infrastructure either — every IDE and terminal assistant on the team points at the same shared gateway. The Terraform sample below is one worked example of a credible AWS deployment for that gateway, not the only architecture that works — it is a normal HTTPS service, so any deployment that gets a URL and a credential to every developer's machine works the same way.

Architecture¶

The diagram below is the topology the getting_started_production sample builds, putting a public Application Load Balancer in front of the gateway so it is reachable from outside the VPC.

%%{init: {'flowchart': {'htmlLabels': true, 'nodeSpacing': 20, 'rankSpacing': 40, 'subGraphTitleMargin': {'top': 8, 'bottom': 10}}} }%%
flowchart TB
  dev["<img src='../styles/logo_vscode.svg' style='height:40px;width:auto;vertical-align:middle;' /> Developer workstations<br/>IDE / terminal + coding assistant"]

  waf["<img src='../styles/logo_amazon_waf.svg' style='height:40px;width:auto;vertical-align:middle;' /> AWS WAF (optional)<br/>rate limit · anonymous-IP block"]

  subgraph public["Your VPC · public subnets"]
    alb["<img src='../styles/logo_amazon_load_balancing.svg' style='height:40px;width:auto;vertical-align:middle;' /> Application Load Balancer<br/>HTTPS · ACM certificate<br/>custom domain via Route 53"]
  end

  subgraph private["Your VPC · private app subnets — no inbound route from the internet"]
    gateway["<img src='../styles/logo.svg' style='height:40px;width:auto;vertical-align:middle;' /> stdapi.ai gateway<br/>ECS Fargate · stateless"]
    egress["<img src='../styles/logo_amazon_vpc.svg' style='height:40px;width:auto;vertical-align:middle;' /> NAT gateways · one per AZ<br/>+ free S3 gateway endpoint"]
  end

  subgraph regional["AWS service endpoints · your account, the regions you configure"]
    bedrock["<img src='../styles/logo_amazon_bedrock.svg' style='height:40px;width:auto;vertical-align:middle;' /> Amazon Bedrock"]
    s3["<img src='../styles/logo_amazon_s3.svg' style='height:40px;width:auto;vertical-align:middle;' /> Amazon S3<br/>SSE-KMS"]
    cw["<img src='../styles/logo_amazon_cloudwatch.svg' style='height:40px;width:auto;vertical-align:middle;' /> Amazon CloudWatch<br/>logs · metrics · alarms"]
    bedrock ~~~ s3
  end

  dev -->|"HTTPS · TLS 1.2+<br/>API key or Cognito token"| alb
  waf -.->|"optional · alb_waf_enabled"| alb
  alb -->|"HTTP · private subnet"| gateway
  gateway -->|"S3 gateway endpoint<br/>always provisioned"| s3
  gateway --> egress
  egress -->|"HTTPS · SigV4"| bedrock
  egress --> cw

The Application Load Balancer, optionally fronted by AWS WAF, is the only address any developer's machine ever reaches — everything past it lives in private app subnets with no inbound route from the internet. Source code sent for a completion or a chat turn crosses the ALB, reaches the gateway task over the private network, and leaves again over SigV4-signed HTTPS straight to Amazon Bedrock; the gateway container is stateless and keeps no request body or completion on disk once the response is sent.

What Each AWS Service Does Here¶

Security Measures in This Flow¶

• Authentication — see One Key for the Team, or One Identity per Developer above for the choice between a shared API key and a per-developer credential.
• Encryption in transit — HTTPS from every workstation to the ALB, whose listener supports TLS 1.2 and 1.3; a private-subnet hop from the ALB to the gateway task; SigV4-signed HTTPS from the gateway to Amazon Bedrock.
• Encryption at rest — SSE-KMS on the S3 bucket(s), with automatic key rotation.
• Least privilege — the gateway's task role carries only the model and AI-service actions it calls, and its security group accepts inbound traffic only from the ALB's security group, on the container port.
• Content policy — an optional Bedrock guardrail applies to every route a coding assistant reaches, chat included, and stays in force unless the deployment explicitly allows a per-request override.
• Data handling — the gateway is stateless and holds request bodies in memory only; CloudWatch receives request metadata, not the source code or the model's replies, unless payload logging is explicitly turned on for debugging.

What It Costs to Run¶

Coding assistants resend large amounts of repeated context — the system prompt, tool definitions, and often the same files — on every turn, which makes prompt caching the main lever on that variable charge; see the caching notes under Using Non-Claude Models above for when cache_control helps and when DISABLE_PROMPT_CACHING=1 is the right call instead. Read a model's price before you send anything to it with GET /model_pricing. Setting COST_TRACKING=true additionally puts a per-request cost on each usage entry — estimated from published AWS prices, not read back from your invoice.

What to Watch¶

The gateway writes one structured request (or request_stream for streamed replies) event per call, carrying the request id, path, status code, execution_time_ms, the model that served it, and the AWS-billed token counts — including cached_tokens and cache_write_tokens from Bedrock prompt caching. Turning on CLOUDWATCH_METRICS republishes those counts as EMF metrics in the stdapi namespace, dimensioned by Model. On a shared deployment, the useful first question is which developer and which model are driving the traffic:

fields aws_role_session_name, model_id
| filter type = "request" and ispresent(aws_role_session_name)
| stats count(*) as calls, pct(execution_time_ms, 95) as p95_ms by aws_role_session_name, model_id
| sort calls desc

aws_role_session_name is the identity AWS billed the call under, and it is populated by per-user cost attribution — which is an enforced boundary only with AUTHENTICATION_MODE=cognito. Under a shared API key the field is absent, and the request_user_id an assistant declares is a label rather than a boundary; on that setup, group by model_id alone and read the per-team split from Cost Explorer instead.

Next Steps¶