[Feature]: AI Request Logging#437
Conversation
- Replace hand-rolled table, filters, search, and pagination with @wordpress/dataviews for the Request Logs screen - Bundle @wordpress/dataviews and @wordpress/ui (not registered in WP 7.0-RC1) via custom DependencyExtractionWebpackPlugin config - Copy DataViews CSS into build/ and enqueue from PHP with fallback to wp-dataviews style handle when available - Filter unregistered script dependencies in Asset_Loader to prevent wp_enqueue_script notices - Expand AI_Request_Cost_Calculator from 3 providers / 25 models to 8 providers / 50+ models (adds DeepSeek, Mistral, Cohere, Groq, Grok, Ollama; adds o-series reasoning models, Claude 4.5/4.6 IDs) - Add Azure → OpenAI provider alias for cost lookup - Return $0.00 for local providers (Ollama) instead of null - Fix provider tooltip: click-to-toggle instead of hover so links are reachable - Compact operation cell to max 2 rows (code + kind inline) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Fix PHPCS array arrow alignment in cost calculator (phpcbf auto-fix) - Fix PHPStan: cast filemtime() to string for wp_enqueue_style version - Fix ESLint a11y: add role, tabIndex, onKeyDown to provider cell - Fix ESLint prettier: auto-formatted multiline expressions - Fix ESLint import: suppress no-extraneous-dependencies for webpack build-tool requires (dependency-extraction-webpack-plugin, copy-webpack-plugin) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…encies instead of React.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## develop #437 +/- ##
=============================================
+ Coverage 72.24% 73.16% +0.92%
- Complexity 1162 1526 +364
=============================================
Files 68 77 +9
Lines 5609 6867 +1258
=============================================
+ Hits 4052 5024 +972
- Misses 1557 1843 +286
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
dkotter
left a comment
There was a problem hiding this comment.
Overall this looks decent to me but have a couple bigger questions:
- I'd love to not have to manually support a bunch of providers. If possible, I'd suggest we remove any hardcoded provider references and rely on what information we can get from the AI Client
- I'd suggest we drop cost tracking / estimation from this as it gets overly complicated. My opinion is that should be implemented at the provider level
| // Copy DataViews CSS into build/ so the plugin can enqueue it | ||
| // on WP versions where wp-dataviews is not a registered style. |
There was a problem hiding this comment.
If all the code changes in this file are only to support older WP versions, I think we can just remove all of this as we only support 7.0+ anyway
There was a problem hiding this comment.
It seems WP 7.0 doesn't actually register the wp-dataviews stylesheet handle. I tried removing this but the UI ended up breaking.
Is there a different handle for the wp-dataviews stylesheet I should be targeting? Left this in place for now until we figure this out.
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
This is looking good to me. I think final thing needed here is some discussion around the introduction of a new database table in this PR. I don't have any concerns with that but others may. If we decide we're fine with that, I think final step is to ensure we are okay with the structure of the table and the data we are storing as it's harder to change that once this goes live. cc / @jeffpaul |
| $table_name = $this->get_table_name(); | ||
| $charset_collate = $wpdb->get_charset_collate(); | ||
|
|
||
| $sql = "CREATE TABLE {$table_name} ( |
There was a problem hiding this comment.
I asked for feedback on this new table and schema on our last AI call and one question was raised around the logging of cached tokens. We log input and output tokens here but not cached tokens.
Looking into it, I think this will require changes both in the PHP AI Client and within each AI Provider plugin, as right now the AI Client has a TokenUsage class that doesn't consider cached tokens.
And looking at the OpenAI Provider plugin as an example, it removes all usage information after sending it to the TokenUsage class so you can't even manually pull that information yourself.
There was a problem hiding this comment.
Hmmm, that's a good flag. I didn't really even think about cached tokens as a separate metric here. Are cached tokens returned as a value in that usage key? I think supplying them as another parameter to the GenerativeAiResult object would be the best path forward, as that already stores tokenUsage.
Given the GenerativeAiResult object doesn't currently do anything for cached tokens is that something we could add support for in like a phase 2 of this experiment or should we aim to get that squared away now?
There was a problem hiding this comment.
I didn't dive too far into it but I think upstream changes are needed to fully support this, both in the PHP AI Client and in each individual provider plugin. As such, I wouldn't put that as a blocker here
There was a problem hiding this comment.
Yeah I reviewed a bit and that was my understanding as well 👍
|
Using WordPress 7.0-RC4, OAI provider Version 1.0.3, and the latest ZIP here I'm not seeing any data appearing in the AI Request Logs screen. |
|
Tested locally again, still nothing coming through. Tested on Playground with WordPress 7.0-RC4 running, OAI Version 1.0.3, and things worked as expected, so maybe just something off with my local. |
There was a problem hiding this comment.
May end up replacing this with the updated WPORG icon asset from #546
There was a problem hiding this comment.
Ah, yep, good catch. I can update that now that #546 has been merged
There was a problem hiding this comment.
Actually it doesn't look like that icon was even being used, it was already defaulting to the same icon we use everywhere else. I've gone ahead and removed that extra icon file
Added - Request Logging experiment that provides observability for all AI operations Co-authored-by: Jameswlepage <isotropic@git.wordpress.org> Co-authored-by: TylerB24890 <tyb@git.wordpress.org> Co-authored-by: jeffpaul <jeffpaul@git.wordpress.org> Co-authored-by: dkotter <dkotter@git.wordpress.org> Co-authored-by: justlevine <justlevine@git.wordpress.org> Co-authored-by: gohelkunjan <gohelkunjan@git.wordpress.org>
| - tests/ | ||
| - vendor/ | ||
| - includes/Logging/Logging_Integration.php | ||
| - includes/Logging/Logging_Http_Transporter.php |
There was a problem hiding this comment.
I know I'm late here, but I'm not seeing it in the previous comments.
@TylerB24890 @dkotter Why aren't we analyzing these files?
There was a problem hiding this comment.
I believe the issue here is these files reference code coming from the AI Client and that code isn't stubbed yet, so PHPStan throws errors. And the errors thrown were internal to PHPStan so they weren't errors we could suppress individually.
I couldn't find the discussion in a quick search but the idea was we could either stub the AI Client ourselves or ignore those files until the upstream WordPress Core stubs are updated. We decided on the latter but open to revisiting that decision
There was a problem hiding this comment.
Definitely no need to revisit here, we should be able to update to the latest WordPress stubs as soon as wp-cli-stubs cuts a new release. If it's not out this week though, I'll open a PR to add in a # Reason why we're ignoring these
Original PR: #149
What?
Adds a comprehensive AI Request Logging experiment that provides observability for all AI operations:
Closes #345.
Why?
AI operations are opaque—users have no visibility into what requests are being made, how much they cost, or whether they're succeeding. This experiment provides the observability surface needed for debugging, cost tracking, and usage analysis.
How?
Architecture uses the decorator pattern to wrap the SDK's HTTP transporter:
Logging_Integrationwraps the transporter onwp_loaded/admin_initusing the publicsetHttpTransporter()APILogging_Http_Transporterdecorates requests, capturing timing and delegating toLog_Data_ExtractorLog_Data_Extractorparses request/response payloads with 4 filter hooks for extensibility:ai_request_log_providers- customize provider detectionai_request_log_context- filter context dataai_request_log_tokens- custom token extractionai_request_log_kind- request type detectionAI_Request_Log_Managercoordinates schema, repository, and cost calculationAI_Request_Cost_Calculatorestimates costs based on provider pricing tablesUse of AI Tools
Testing Instructions