Some AI features start as a button.
Paste a URL. Click summarize. Get the important points back.
That sounds simple until you think about the infrastructure behind it. You need somewhere to receive the request, fetch the webpage, extract the text, call an LLM, return a useful response, and ideally avoid paying the model again when someone asks for the same URL five minutes later.
The usual answer is to add more pieces: a web server, a cache, a queue, a worker, maybe a database.
For a lot of internal tools and demos, that is more infrastructure than the idea deserves.
This example shows a smaller pattern: a URL summarizer running on Telnyx Edge Compute Stateful Actors. One edge function accepts a URL, summarizes it with Telnyx AI Inference, and stores the summary in actor storage so repeat requests come back instantly.
Code:
What the app does
The app exposes a small HTTP API:
POST /summarizesummarizes a URLGET /summarize/cached?url=...returns a cached summary without calling the modelPOST /summarize/refreshinvalidates a URL so it can be summarized againGET /statsreturns cache hit and miss statsGET /cachedlists cached URLsGET /health/livenessandGET /health/readinesssupport health checks
The first request for a URL is a cache miss. The app fetches the page, strips the HTML down to text, sends the first chunk to Telnyx AI Inference, and stores the result.
The second request for that same URL is a cache hit. No model call. No repeated page fetch. The response comes back from the Stateful Actor's storage.
Conceptually, the flow looks like this:
POST /summarize
-> check actor storage
-> cache hit: return saved summary
-> cache miss: fetch URL
-> extract text
-> call Telnyx AI Inference
-> store summary in actor storage
-> return summary
That is the part I like about this example. It makes caching feel like part of the application, not a separate service you have to wire up before the idea is even useful.
Why Stateful Actors are a good fit here
Edge functions are usually described as stateless.
That is great for simple request handlers, but a lot of real applications need a little memory. Not always a full database. Sometimes just enough state to remember what happened before.
This URL summarizer is a good example.
If ten people summarize the same product page, documentation page, or release note, the app should not repeat the same work ten times. It should remember the summary and reuse it until you decide to refresh it.
The sample uses a single actor instance named global. Inside that actor, summaries and stats are stored with ctx.storage.
The actor keeps:
- a map of URL to cached summary
- total request count
- cache hit count
- cache miss count
- number of unique URLs
- a short list of cached URLs
That gives you a simple edge-native cache without adding Redis, Postgres, or another hosted service to the demo.
The AI call
When the app has a cache miss, it calls Telnyx AI Inference through:
POST /v2/ai/chat/completions
The current sample uses:
zai-org/GLM-5.2
The prompt asks the model to return JSON only:
{
"bullets": [
"point 1",
"point 2",
"point 3"
]
}
Keeping the output structured matters because the API response is meant to be consumed by another app. You can render it in a dashboard, send it to Slack, attach it to a CRM note, or store it alongside an article queue.
The response from /summarize looks like this:
{
"url": "https://example.com/article",
"title": "Example Article",
"bullets": [
"The article explains the main problem.",
"The author walks through the implementation.",
"The final section covers production tradeoffs."
],
"word_count": 1234,
"generated_at": "2026-08-04T12:00:00Z",
"cached": false
}
Call it again with the same URL and cached becomes true.
Running it
Clone the examples repo:
git clone https://github.com/team-telnyx/telnyx-code-examples.git
cd telnyx-code-examples/edge-url-summarizer
Authenticate the Edge CLI and store your API key as a secret:
telnyx-edge auth api-key set <YOUR_API_KEY>
telnyx-edge secrets add TELNYX_API_KEY "KEY0123..."
Install dependencies and deploy:
npm install
telnyx-edge ship
The deploy command prints a URL like:
https://edge-url-summarizer-<id>.telnyxcompute.com
Check that the function is live:
curl -sS --retry 30 --retry-delay 5 \
https://edge-url-summarizer-<id>.telnyxcompute.com/health/liveness
Then summarize a URL:
curl -X POST https://edge-url-summarizer-<id>.telnyxcompute.com/summarize \
-H "Content-Type: application/json" \
-d '{"url":"https://telnyx.com/blog"}'
Run the same request again and check the cached field.
You can also inspect the cache:
curl https://edge-url-summarizer-<id>.telnyxcompute.com/stats
curl https://edge-url-summarizer-<id>.telnyxcompute.com/cached
Where this pattern goes next
A URL summarizer is useful by itself, but the more interesting part is the reusable shape.
The same pattern works for:
- internal research tools
- support knowledge base summaries
- release note digests
- sales enablement briefs
- developer documentation summaries
- content intake queues
- customer-specific article feeds
You can also extend the sample pretty naturally:
- add a TTL so summaries refresh after a set amount of time
- normalize URLs so tracking parameters do not create duplicate cache entries
- add authentication for internal use
- rate limit requests before they reach the model
- support summary styles like "TL;DR", "executive", or "developer notes"
- store richer metadata for search and analytics
The takeaway is not that every AI app should be a URL summarizer.
The takeaway is that AI features often need a little state. With Telnyx Edge Compute Stateful Actors, that state can live right next to the request handler that uses it.
One function. One actor. One model call on the first request. Instant responses after that.