{"id":387868,"date":"2026-04-08T09:44:08","date_gmt":"2026-04-08T09:44:08","guid":{"rendered":"https:\/\/www.newsbeep.com\/ie\/387868\/"},"modified":"2026-04-08T09:44:08","modified_gmt":"2026-04-08T09:44:08","slug":"stateful-continuation-for-ai-agents-why-transport-layers-now-matter","status":"publish","type":"post","link":"https:\/\/www.newsbeep.com\/ie\/387868\/","title":{"rendered":"Stateful Continuation for AI Agents: Why Transport Layers Now Matter"},"content":{"rendered":"

\t\t\t\t\t\t\t\t\tKey Takeaways
\n\t\t\t\t\t\t\t\t\t
\n\tAgent workflows make transport a first-order concern. Multi-turn, tool-heavy loops amplify overhead that is negligible in single-turn LLM use.
\n\tStateless APIs scale poorly with context. Re-sending the full history each turn drives linear payload growth and increases latency.
\n\tStateful continuation cuts overhead dramatically. Caching context server-side can reduce client-sent data by 80%+ and improve execution time by 15\u201329% .
\n\tThe benefit is architectural, not protocol-specific. Any approach that avoids retransmitting context can achieve similar gains.
\n\tPerformance comes with trade-offs. Stateful designs introduce challenges in reliability, observability, and portability that must be weighed carefully. <\/p>\n

\t\t\t\t\t\t\t\tThe Airplane Problem<\/p>\n

On a recent flight, I purchased the in-flight internet and tried to use Claude Code. The agent needed to read several files, understand the codebase structure, make edits, and run tests; a typical agentic workflow involving 10-15 tool calls. But the internet was so bad that by the third or fourth turn, the requests were timing out. Each turn was resending the entire conversation history \u2014 the original prompt, every file it had read, every edit it had proposed, every test output \u2014 and the payload had ballooned to hundreds of kilobytes. Over a bandwidth-constrained link, that growing payload was a bottleneck.<\/p>\n

This experience highlighted something that’s becoming increasingly relevant as AI coding agents mature: the transport layer matters more for agentic workflows than for simple chat. A single-turn chat completion sends a prompt and gets a response. An agentic coding session involves 10, 20, or sometimes 50+ sequential turns in which the model reads code, proposes changes, runs tests, reads error output, fixes issues, and iterates. With each turn, the conversation context grows, and over HTTP, that entire growing context must be retransmitted every time.\u00a0<\/p>\n

In February 2026, OpenAI introduced WebSocket mode<\/a> for their responses API, which caches the conversation history in the server memory to solve this problem; I was excited to try it out and see how it performs compared to HTTP.<\/p>\n

The Agentic Coding Loop<\/p>\n

AI coding agents have moved from novelty to daily workflow for many organizations, especially since December 2025. Tools like Claude Code, OpenAI Codex, Cursor, and Cline now routinely perform multi-file edits, run test suites, and iterate on failing builds. OpenAI reports over 1.6 million weekly active users<\/a> on Codex alone, with a typical engineer on the Codex team running 4-8 parallel agents.<\/p>\n

The core of these agents is the “agent loop”: a cycle of model inference and tool execution that repeats until the task is complete:<\/p>\n

\"\"<\/p>\n

The coding agent loop: At every turn, the model either returns a response indicating task completion, or recommends tool calls, whose response is fed back to the model inference until the task is complete<\/p>\n

A single turn of the agent loop typically involves reading several files to understand the codebase, editing some files, and running tests, which involves 10-15 tool calls, often more for complex refactoring. The results of those tool calls are then sent to the LLM inference server. If the problem is solved, the LLM server returns a response with no more tool calls. Otherwise, the LLM server recommends additional tool calls, which starts the next turn of the agent loop, and this process continues until the problem is solved. Each turn requires the model to receive the full context of what’s happened so far.<\/p>\n

The HTTP Overhead Problem<\/p>\n

With HTTP-based APIs, including OpenAI’s Responses API over HTTP and the older Chat Completions API, each turn is a stateless request. The server doesn’t remember what happened on the previous turn, so the client must resend everything:<\/p>\n


\n\tSystem instructions and tool definitions (~2 KB)
\n\tThe original user prompt
\n\tEvery prior model output (including full code blocks that the model wrote)
\n\tEvery tool call result (including file contents, command outputs) <\/p>\n

This means the request payload grows linearly with each turn. In our benchmarks, we measured the actual per-turn bytes sent by the client over HTTP versus WebSocket:<\/p>\n

\"\"<\/p>\n

Average bytes sent per turn across 10 task runs with gpt-4o-mini. HTTP grows linearly; WebSocket stays constant.<\/p>\n

By turn 9, HTTP is sending nearly 10x as much data per request as WebSocket. This is because OpenAI’s WebSocket mode for the Responses API keeps a persistent connection with server-side in-memory state. After the first turn, each subsequent turn sends only:<\/p>\n


\n\tA previous_response_id referencing the cached state (~60 bytes)
\n\tThe new tool call outputs (typically 1-3 KB of file content or command output) <\/p>\n

The payload stays roughly constant regardless of how many turns deep you are.<\/p>\n

What Existing Benchmarks Show<\/p>\n

Before building our own test harness, we reviewed publicly available data.<\/p>\n

OpenAI’s claim: WebSocket mode for the Responses API is built for low-latency, long-running agents with heavy tool calls. For workflows with 20+ tool calls, it delivers up to 40% faster end-to-end execution by eliminating redundant context re-transmission and leveraging server-side in-memory state persistence across turns.<\/p>\n

Cline’s independent validation: The Cline team tested WebSocket mode with GPT-5.2-codex against their standard HTTP API integration and reported<\/a>:<\/p>\n


\n\t~15% faster on simple tasks (few tool calls)
\n\t~39% faster on complex multi-file workflows (many tool calls)
\n\tBest cases hitting 50% faster
\n\tWebSocket handshake adds slight TTFT overhead on the first turn, but it amortizes fast <\/p>\n

The pattern: The speedup scales with workflow complexity. Simple tasks with 1-2 tool calls see minimal benefit (or even slight overhead from the WebSocket handshake). Complex tasks with 10+ tool calls see dramatic improvements because the cumulative savings from not retransmitting context compound with each turn.<\/p>\n

Our Benchmark: Validating the Claims<\/p>\n

To validate these claims with controlled measurements, we built a benchmark harness that simulates realistic agentic coding workflows against OpenAI’s Responses API. The harness<\/a> is open source.<\/p>\n

Methodology<\/p>\n

We defined three coding tasks of varying complexity:<\/p>\n


\n\tFix a failing test \u2014 Read the test file, read the component, fix the bug, run tests (~10-15 turns, 12-17 tool calls)
\n\tAdd a search feature \u2014 Read existing components, implement the feature, run tests (~5-15 turns, 4-21 tool calls)
\n\tRefactor the API layer \u2014 List the project, read files, search for callers, update multiple files, run tests (~6-11 turns, 10-20 tool calls) <\/p>\n

Each task uses simulated tool responses (realistic file contents, test outputs, command outputs) to isolate transport-layer differences. The model makes real API calls to OpenAI and decides which tools to call and when to stop \u2014 the non-determinism is in the model’s behavior, not the tool responses.<\/p>\n

Two test configurations:<\/p>\n


\n\t
\n\t\t
\n\t\t\tCell
\n\t\t\tApproach
\n\t\t\tPer-turn behavior
\n\t\t
\n\t\t
\n\t\t\t1
\n\t\t\tHTTP Responses API
\n\t\t\tFull conversation context is re-sent every turn
\n\t\t
\n\t\t
\n\t\t\t2
\n\t\t\tWebSocket Responses API
\n\t\t\tprevious_response_id + incremental input only
\n\t\t
\n\t <\/p>\n

We measured:<\/p>\n


\n\tTTFT (Time to First Token): How quickly does the model start generating on each turn?
\n\tBytes sent: How much data does the client upload per task?
\n\tBytes received: How much streaming event data comes back?
\n\tTotal time: End-to-end wall-clock time for the full agentic workflow <\/p>\n

Each configuration was run 3 times and aggregated. We tested with two models \u2014 GPT-5.4 (a frontier coding model) and GPT-4o-mini (a smaller, faster model) \u2014 to see whether the transport-layer effects hold across model sizes.<\/p>\n

Results<\/p>\n

Across all runs, tasks averaged roughly 8-11 turns and 9-16 tool calls per task, varying by model and transport mode.<\/p>\n

Relative performance (WebSocket vs HTTP):<\/p>\n


\n\t
\n\t\t
\n\t\t\tMetric
\n\t\t\tGPT-5.4
\n\t\t\tGPT-4o-mini
\n\t\t
\n\t\t
\n\t\t\tTotal time
\n\t\t\t29% faster
\n\t\t\t15% faster
\n\t\t
\n\t\t
\n\t\t\tBytes sent
\n\t\t\t82% less
\n\t\t\t86% less
\n\t\t
\n\t\t
\n\t\t\tFirst-turn TTFT
\n\t\t\t14% lower
\n\t\t\t~same
\n\t\t
\n\t <\/p>\n

Detailed results for GPT-5.4:<\/p>\n


\n\t
\n\t\t
\n\t\t\tMetric
\n\t\t\tGPT-5.4 HTTP
\n\t\t\tGPT-5.4 WebSocket
\n\t\t\tDelta
\n\t\t
\n\t\t
\n\t\t\tAvg total time\/task
\n\t\t\t40.8 s
\n\t\t\t28.9 s
\n\t\t\t\u221229%
\n\t\t
\n\t\t
\n\t\t\tAvg TTFT (all turns)
\n\t\t\t1,253 ms
\n\t\t\t1,111 ms
\n\t\t\t\u221211%
\n\t\t
\n\t\t
\n\t\t\tAvg TTFT (first turn)
\n\t\t\t1,255 ms
\n\t\t\t1,075 ms
\n\t\t\t\u221214%
\n\t\t
\n\t\t
\n\t\t\tAvg bytes sent\/task
\n\t\t\t176 KB
\n\t\t\t32 KB
\n\t\t\t\u221282%
\n\t\t
\n\t\t
\n\t\t\tAvg bytes recv\/task
\n\t\t\t485 KB
\n\t\t\t343 KB
\n\t\t\t\u221229%
\n\t\t
\n\t <\/p>\n

Key Findings<\/p>\n


\n\tWebSocket consistently reduces client-sent data by 80-86%. This is the most reliable finding, independent of model, API variance, or task complexity. HTTP sends 153-176 KB per task; WebSocket sends 21-32 KB. This is a direct consequence of not retransmitting the growing conversation history.
\n\tWebSocket delivers 15-29% faster end-to-end execution. With GPT-5.4, WebSocket was 29% faster \u2014 roughly consistent with Cline’s reported 39% on complex workflows. The speedup comes from a combination of less data to upload per turn and potentially faster server-side processing (no need to re-parse and tokenize the full context).
\n\tFirst-turn TTFT is similar across approaches. The WebSocket handshake doesn’t add meaningful overhead \u2014 first-turn TTFT was within noise of HTTP for both models. The advantage emerges in continuation turns, where WebSocket avoids the growing payload upload.
\n\tThe effect is model-independent. We ran the same benchmarks with GPT-4o-mini (detailed results in the repo<\/a>) and saw consistent bytes-sent savings (86%) and 15% faster end-to-end execution. The time savings were larger for GPT-5.4 (29% vs 15%), likely because the frontier model generates longer responses that accumulate more context per turn. <\/p>\n

Why It’s Faster: The Architecture<\/p>\n

The performance difference is a direct consequence of eliminating redundant data transmission.<\/p>\n

HTTP: Stateless by Design<\/p>\n


\nTurn 1: Client \u2192 [system + prompt + tools] \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0\u2192 Server
\nTurn 2: Client \u2192 [system + prompt + tools + turn1 + output1] \u00a0\u2192 Server
\nTurn 3: Client \u2192 [all of the above + turn2 + output2] \u00a0 \u00a0 \u00a0 \u00a0 \u2192 Server
\n…
\nTurn N: Client \u2192 [system + prompt + tools + ALL prior turns] \u00a0 \u2192 Server<\/p>\n

Each request is independent. The server processes it, returns a response, and forgets everything. The client must reconstruct the full context from scratch.<\/p>\n

WebSocket: Stateful Continuation<\/p>\n


\nTurn 1: Client \u2192 [system + prompt + tools] \u00a0 \u00a0 \u00a0\u2192 Server \u00a0(server caches response)
\nTurn 2: Client \u2192 [prev_id + tool_output] \u00a0 \u00a0 \u00a0 \u00a0 \u2192 Server \u00a0(server loads from cache)
\nTurn 3: Client \u2192 [prev_id + tool_output] \u00a0 \u00a0 \u00a0 \u00a0 \u2192 Server \u00a0(server loads from cache)
\n…
\nTurn N: Client \u2192 [prev_id + tool_output] \u00a0 \u00a0 \u00a0 \u00a0 \u2192 Server \u00a0(constant-size payload)<\/p>\n

The server keeps the most recent response in connection-local memory. Continuations reference that cached state, so the client only sends what’s new.<\/p>\n

The Bandwidth Math: From Our Benchmarks<\/p>\n

Using our actual GPT-5.4 data for a typical 10-turn coding task:<\/p>\n

HTTP total bytes sent (client \u2192 server): 176 KB per task (measured average)<\/p>\n


\n\tGrows from 2 KB on turn 0 to 38 KB on turn 9 as context accumulates <\/p>\n

WebSocket total bytes sent: 32 KB per task (measured average)<\/p>\n


\n\tStays flat at 2-4 KB per turn throughout <\/p>\n

That’s an 82% reduction in client-sent bytes \u2014 144 KB saved per task, compounding across thousands of concurrent sessions.<\/p>\n

Architectural Lessons<\/p>\n

1. API Compatibility vs Performance: The Protocol Tax<\/p>\n

The OpenAI-compatible HTTP API (both the \/chat\/completions and Responses API) is the de facto standard. Every LLM tool, SDK, and orchestration framework speaks it. But this compatibility comes at a cost: the API is inherently stateless, requiring full context to be retransmitted on every request.<\/p>\n

WebSocket mode breaks this compatibility, causing fragmentation.<\/p>\n

Who supports WebSocket today?<\/p>\n


\n\t
\n\t\t
\n\t\t\tProvider \/ Gateway
\n\t\t\tWebSocket API
\n\t\t\tStreaming method
\n\t\t
\n\t\t
\n\t\t\tOpenAI Responses API
\n\t\t\t\u2705 (since Feb 2026)
\n\t\t\tWebSocket frames (JSON)
\n\t\t
\n\t\t
\n\t\t\tGoogle Gemini API
\n\t\t\t <\/p>\n

\u26d4 (text\/coding)

\n\t\t\t\u2705 (audio\/video)<\/p>\n


\n\t\t\t
\n\t\t\tWebSocket frames
\n\t\t
\n\t\t
\n\t\t\tAnthropic Claude API
\n\t\t\t\u26d4
\n\t\t\tServer-Sent Events (SSE)
\n\t\t
\n\t\t
\n\t\t\tOpenRouter
\n\t\t\t\u26d4
\n\t\t\tSSE (OpenAI-compatible)
\n\t\t
\n\t\t
\n\t\t\tCloudflare AI Gateway
\n\t\t\t\u2705 (gateway layer)
\n\t\t\tWebSocket frames
\n\t\t
\n\t\t
\n\t\t\tLocal models (Ollama, vLLM)
\n\t\t\t\u26d4
\n\t\t\tSSE
\n\t\t
\n\t <\/p>\n

Who supports WebSocket among coding agents?<\/p>\n


\n\t
\n\t\t
\n\t\t\tCoding Agent
\n\t\t\tWebSocket support
\n\t\t\tNotes
\n\t\t
\n\t\t
\n\t\t\tOpenAI Codex
\n\t\t\t\u2705 (native)
\n\t\t\tBuilt on the Responses API
\n\t\t
\n\t\t
\n\t\t\tCline
\n\t\t\t\u2705 (OpenAI only)
\n\t\t\tFirst to integrate, reported 39% speedup
\n\t\t
\n\t\t
\n\t\t\tClaude Code
\n\t\t\t\u26d4
\n\t\t\tUses Anthropic SSE API
\n\t\t
\n\t\t
\n\t\t\tCursor
\n\t\t\t\u26d4
\n\t\t\tHTTP-based multi-provider
\n\t\t
\n\t\t
\n\t\t\tWindsurf
\n\t\t\t\u26d4
\n\t\t\tHTTP-based multi-provider
\n\t\t
\n\t\t
\n\t\t\tRoo Code
\n\t\t\t\u26d4
\n\t\t\tCline fork, may inherit support
\n\t\t
\n\t\t
\n\t\t\tOpenCode
\n\t\t\t\u26d4
\n\t\t\tMulti-provider, HTTP-based
\n\t\t
\n\t <\/p>\n

WebSocket is currently an OpenAI-only advantage. If your agent needs to switch between providers, \u00a0say, using Claude for reasoning-heavy tasks and GPT for speed, you would lose the WebSocket performance benefit on every non-OpenAI call.\u00a0<\/p>\n

Google’s Gemini Live API uses WebSocket, but it’s designed for real-time audio\/video streaming rather than text-based agentic workflows. Cloudflare’s AI Gateway offers a WebSocket endpoint that sits in front of multiple providers, but it proxies to HTTP under the hood and doesn’t provide the server-side state caching that makes OpenAI’s implementation fast.<\/p>\n

2. Protocol Overhead at Scale: When Bytes Per Turn Matter<\/p>\n

For a single conversation, the overhead of resending context is negligible. But from the server’s perspective, the scale of agentic coding in 2026 makes this significant.<\/p>\n

Estimating concurrent sessions for a single major provider: OpenAI Codex has 1.6 million weekly active users. GitHub Copilot has 4.7 million paid subscribers. Claude Code is generating $2.5 billion in annualized revenue, suggesting over 1 million active developers. Cline, Cursor, Windsurf, Roo Code, and OpenCode add millions more. Conservatively, 5-10 million developers are actively using AI coding agents weekly. For a single major provider like OpenAI, assuming 10-20% of its users are active during a peak hour with overlapping sessions, we estimate roughly 1 million concurrent agentic coding sessions at peak.<\/p>\n

At that scale, using our measured per-task data:<\/p>\n

HTTP: 1,000,000 sessions \u00d7 176 KB sent per task = 176 GB of client-to-server payload per 40 second task<\/p>\n

WebSocket: 1,000,000 sessions \u00d7 32 KB sent per task = 32 GB of client-to-server payload per 40 second task<\/p>\n

That’s a 144 GB reduction in ingress traffic over a 40-second task, i.e., a 29 Gbps reduction. For a provider processing millions of requests, this reduces load on API gateways, tokenizers (which must re-tokenize the full context on each HTTP request), and network infrastructure. The server-side savings are arguably more important than the client-side savings: less data to receive, parse, and tokenize means faster time-to-first-token for everyone.<\/p>\n

3. Server-Side State: The Real Innovation<\/p>\n

The key insight is that WebSocket isn’t faster because of the protocol \u2014 TCP-based WebSocket has similar framing overhead to HTTP\/2. The speed comes from server-side state management: the WebSocket server stores the most recent response in connection-local volatile memory, enabling near-instant continuation without re-tokenizing the full conversation.<\/p>\n

This has architectural implications:<\/p>\n


\n\tState is ephemeral: It lives only in memory on the specific server handling your connection. If the connection drops, the state is lost (unless store=true).
\n\tNo multiplexing: Each WebSocket connection handles one response at a time. For parallel agent invocations, you need multiple connections.
\n\t60-minute limit: Connections auto-terminate after 1 hour, requiring reconnection logic for sessions longer than 1 hour. <\/p>\n

For architects designing similar systems, the pattern is clear: if your protocol involves many sequential requests that build on prior context, keeping that context server-side (even if only in volatile memory) can dramatically reduce per-request overhead.<\/p>\n

4. The Statefulness Spectrum<\/p>\n

Different approaches to the context accumulation problem offer different trade-offs:<\/p>\n


\n\t
\n\t\t
\n\t\t\tApproach
\n\t\t\tState Location
\n\t\t\tDurability
\n\t\t\tLatency
\n\t\t\tBandwidth
\n\t\t
\n\t\t
\n\t\t\tHTTP (stateless)
\n\t\t\tClient only
\n\t\t\tN\/A
\n\t\t\tHigh (grows with context)
\n\t\t\tHigh (grows with context)
\n\t\t
\n\t\t
\n\t\t\tHTTP + store=true
\n\t\t\tServer (persisted)
\n\t\t\tDurable
\n\t\t\tMedium (server rehydrates from persistent store)
\n\t\t\tLow (incremental input)
\n\t\t
\n\t\t
\n\t\t\tWebSocket + store=false
\n\t\t\tServer (in-memory)
\n\t\t\tVolatile
\n\t\t\tLow (no rehydration)
\n\t\t\tLow (incremental input)
\n\t\t
\n\t\t
\n\t\t\tWebSocket + store=true
\n\t\t\tServer (in-memory + persisted)
\n\t\t\tDurable
\n\t\t\tLow (no rehydration in happy case)
\n\t\t\tLow (incremental input)
\n\t\t
\n\t <\/p>\n

The sweet spot for most agentic workflows is WebSocket + store=false: you get the fastest continuations, your data isn’t persisted on the provider’s servers (important for enterprise compliance with Zero Data Retention policies), and if the connection drops, you restart the task from scratch rather than trying to recover mid-stream.<\/p>\n

5. Parallel Execution: Multiple Connections, Not Multiplexing<\/p>\n

Each WebSocket connection handles one response at a time \u2014 there’s no multiplexing. For parallel tasks (e.g., running 4-8 agents simultaneously, as a typical Codex engineer does), you need separate WebSocket connections. The bandwidth savings from WebSocket still apply per-connection, but concurrent connections may hit API rate limits more aggressively than concurrent HTTP requests due to faster execution times.<\/p>\n

When HTTP Is Still the Right Choice<\/p>\n

WebSocket mode isn’t universally better. Use HTTP for:<\/p>\n


\n\tSimple, few-turn interactions: For 1-2 turn interactions, the context retransmission overhead is negligible and doesn’t justify the added complexity.
\n\tMulti-provider support: If you need to switch among OpenAI, Anthropic, Google, and local models, the standard HTTP API is the common denominator. WebSocket mode is currently OpenAI-specific. Adopting it creates provider lock-in.
\n\tStateless infrastructure: If your backend runs on serverless functions (Lambda, Cloud Functions) that can’t maintain persistent connections, HTTP is your only option.
\n\tDebugging and observability: HTTP requests are easier to log, replay, and debug with standard tools. WebSocket streams require specialized tooling. <\/p>\n

Conclusion<\/p>\n

For agentic coding workflows, the move from stateless HTTP to stateful WebSocket connections delivers meaningful performance improvements: 29% faster end-to-end execution, 82% less client-side data sent, and 11% lower TTFT with GPT-5.4 as validated by our controlled benchmarks against the OpenAI Responses API.<\/p>\n

But the WebSocket advantage comes with a trade-off: it’s currently OpenAI-specific, creating provider lock-in in an ecosystem where developers increasingly want to switch between models. None of the major alternatives \u2014 Anthropic’s Claude API, Google Gemini, OpenRouter, or local model servers \u2014 offer equivalent WebSocket support for text-based agentic workflows.<\/p>\n

The takeaway for architects building agentic systems isn’t to blindly adopt WebSocket. It’s to recognize that as AI workflows shift from single-turn to multi-turn, the transport-layer decisions that were irrelevant for chatbots become material for agents. Any system that avoids retransmitting growing conversation context \u2014 whether through WebSocket, server-side session caching, or a custom stateful protocol \u2014 will see similar wins. The question is whether the industry converges on a standard for stateful LLM continuation, or whether this remains a provider-specific competitive advantage.<\/p>\n

The benchmarking harness and all results are available here<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"Key Takeaways Agent workflows make transport a first-order concern. Multi-turn, tool-heavy loops amplify overhead that is negligible…\n","protected":false},"author":2,"featured_media":387869,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[220,172323,20090,1287,20985,1122,11764,218,14744,8853,128809,61,60,9416,1682,20987,80,172324,172325],"class_list":{"0":"post-387868","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-technology","8":"tag-ai","9":"tag-ai-agent-transport-layer","10":"tag-ai-coding","11":"tag-ai-development","12":"tag-ai-assisted-coding","13":"tag-architecture","14":"tag-architecture-design","15":"tag-artificial-intelligence","16":"tag-code-generation","17":"tag-development","18":"tag-http","19":"tag-ie","20":"tag-ireland","21":"tag-ml-data-engineering","22":"tag-openai","23":"tag-software-development","24":"tag-technology","25":"tag-w3c","26":"tag-websocket"},"_links":{"self":[{"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/posts\/387868","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/comments?post=387868"}],"version-history":[{"count":0,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/posts\/387868\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/media\/387869"}],"wp:attachment":[{"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/media?parent=387868"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/categories?post=387868"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.newsbeep.com\/ie\/wp-json\/wp\/v2\/tags?post=387868"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}