LLM Gateway Icon: Choosing the Right Symbol for Diagrams

Why people search for "LLM gateway icon"

There's no official, universally recognized icon for an "LLM gateway" the way there is for a database (cylinder) or a load balancer (the classic triangle-with-arrows). Most people landing on this search are trying to do one of two things: draw a system architecture diagram that includes an LLM gateway as a component, or find a visual asset (badge, logo, favicon) to represent a gateway service in docs, a README, or a product UI.

This article covers both. If you're diagramming, you'll get practical icon conventions and a ready-to-use example. If you're building or documenting a gateway product, you'll get guidance on picking something clear and reusable rather than inventing a new visual language nobody recognizes.

There's no standard symbol — and that's fine

Unlike networking diagrams (which inherited decades of Cisco iconography) or cloud architecture diagrams (which have AWS, Azure, and GCP's official icon libraries), "LLM gateway" is a newer category. It sits at the intersection of a few things that do have established symbols:

• API gateway — usually a funnel, a shield, or a hexagon with an arrow through it
• Reverse proxy — an arrow bouncing off a box, or a diamond
• Key/auth layer — a keyhole or padlock
• LLM/model — increasingly drawn as a chip, brain, or sparkle icon

An LLM gateway is functionally an API gateway in front of one or more model providers, so the cleanest, most legible choice is to reuse the API gateway convention and layer on an LLM indicator (a small brain, chip, or "AI" badge) next to it. Reviewers and engineers will recognize the shape immediately without needing a legend.

Practical icon choices by tool

If you're building the diagram in a specific tool, here's where to look:

• draw.io / diagrams.net — search "API Gateway" in the AWS or Azure shape libraries (both ship with the tool by default). Combine it with a generic "Cloud" or "Service" shape labeled with the provider name (Claude, GPT, etc.).
• Lucidchart — the "Network" and "AWS" shape sets both include gateway icons; pair with a text label rather than hunting for an LLM-specific glyph.
• Font Awesome / Material Icons — key, shield-check, route, or arrows-left-right work well for the gateway itself; robot or sparkles for the model side.
• Mermaid diagrams (for docs and READMEs) — no real icon support, but a labeled node with a distinct shape communicates the same thing in plain text-based diagrams that render in GitHub and most static site generators.

A minimal example diagram

Here's a Mermaid diagram you can drop straight into a README or docs page — no image assets required, which is often the more maintainable choice than sourcing an icon:

flowchart LR
    App[Your Application] -->|HTTPS + API key| GW[LLM Gateway]
    GW -->|routes request| Claude[Claude / Model Provider]
    GW -->|logs usage, enforces auth| Meta[(Usage & Metadata)]
    Claude -->|response| GW
    GW -->|streamed or JSON| App

This communicates the role of the gateway — routing, auth, usage tracking — without needing a custom icon. For most internal architecture docs, a labeled box like GW[LLM Gateway] is clearer than an icon anyway, since readers scan text faster than they parse unfamiliar glyphs.

When you're documenting your own integration

If the "icon" you're after is really about explaining what the gateway does in your own docs (rather than finding a graphic), the clearest way is to show the request shape. A gateway's job is to take a normal HTTPS call and route it to a model provider while handling auth, streaming, and usage metadata — so show that directly:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "messages": [
      { "role": "user", "content": "Summarize this changelog." }
    ]
  }'

That single code block does more work than any icon — it shows exactly what "gateway" means in practice: one endpoint, one key, a normal HTTPS request, a JSON response.

If you're building the gateway instead of drawing it

Some searches for "LLM gateway icon" come from people evaluating whether to build a gateway in-house — including its dashboard, branding, and yes, its icon — versus using an existing one. If you're at that decision point, it's worth pausing on the build side of that tradeoff first.

A gateway that turns your Claude access into a proper HTTPS API needs: application-scoped API keys, streaming support, tool use, usage metadata per key, and team seat management. That's a real amount of surface area before you even get to picking a logo. SubToAPI handles all of it — Solo, Team, and Scale plans with a free trial at signup, so you get sub_live_... keys, streaming, and per-key usage tracking without maintaining the infrastructure yourself. Check the quickstart to see the whole flow in a few requests, or the pricing page if you're comparing build-vs-buy costs.

Either way, the icon is the smallest part of the decision — the routing, auth, and observability underneath it are what actually matter.

FAQs

Is there an official icon for LLM gateways? No. There's no standardized symbol like the database cylinder or load balancer triangle. The most legible approach is reusing existing API gateway icons (funnel, shield, hexagon-with-arrow) from libraries like draw.io or Font Awesome, since engineers already recognize that shape.

What icon should I use in an architecture diagram? Pair a generic API gateway icon (funnel or shield shape) with a small AI/model indicator (chip, brain, or sparkle) next to the provider box. If you're writing docs in Markdown, a labeled Mermaid node is often clearer than any icon and needs no image asset.

Do I need to design branding for my own LLM gateway? Only if you're building and shipping a standalone product. If you just need Claude access exposed as an API for your own app or team, a hosted option like SubToAPI skips that work entirely — you get keys, streaming, and a dashboard without designing or maintaining any of it.